We have data centers in two states, with a six-hour drive between them. Our
normal practice has been to drive from the main DC to the satellite every few
weeks to catch up on maintenance and non-urgent infrastructure changes such as
server installs. For urgent things we have some part-time “remo
We are leaving it at everyone’s discretion where we can. We have a big open
pair of GNOCs with nobody closer than 6 feet by far, and with one or two people
in each while everyone else is WFH, it’s essentially the run of the place.
Anything that can be done at home is generally encouraged - eve
I think that several businesses already have a BCP in place that includes
work from home and a pre-built VPN infrastructure. I can't speak for
business units I'm unfamiliar with, but for Engineering/Ops, this is status
quo.
On Mon, Apr 6, 2020 at 7:52 AM Scott E. MacKenzie
wrote:
> All,
>
> This
On Mon, Apr 6, 2020 at 7:53 AM Scott E. MacKenzie wrote:
>
> All,
>
> This question has arisen and I was wondering if I could request some
> feedback from the community. We operate a 24x7x365 Command and
> Control Centre that provides mission critical services (Security
> Operations, Network Oper
I was watching one of Jim Browning's s Youtube series the other day, the
one where he got into a scam call center's network so completely that he
had access to their entire operation, including CCTV cameras, and
eventually got BBC Panorama involved, which got the place shut down.
He mentioned that
Mark, Thanks for sharing your experiences with FRR. I don't work with
IS-IS, but have found the development to be very active and fixing
reproducible bugs quickly.
It look like FRR put a patch in for the bug you referenced and have a test
build from 3/21 available which allows for up to 16k MTU @
All,
This question has arisen and I was wondering if I could request some
feedback from the community. We operate a 24x7x365 Command and
Control Centre that provides mission critical services (Security
Operations, Network Operations, and Enterprise Management) as does
many on this list.
How many
On 6/Apr/20 14:52, Radu-Adrian Feurdean wrote:
>
> Beware of bad dog^H^H^H NCS model. On NCS5000 (don't know about 5500 - those
> arrived months after me leaving $job[-1]) you will get the nasty surprise of
> discovering that they have some limits to 9150(IP)/9164(eth), even if you can
> set
On Mon, Apr 6, 2020, at 10:58, Mark Tinka wrote:
> Within our core, we run 9,178 bytes (which translates to 9,192 bytes on
> Junos and IOS XR), to support the transport of Jumbo frames for
Beware of bad dog^H^H^H NCS model. On NCS5000 (don't know about 5500 - those
arrived months after me leaving
On 6/Apr/20 12:57, Dale Shaw wrote:
>
> Since vsphere67u3 (ESXi 6.7 U3), you can set an MTU of up to 9,190 bytes:
So we moved from 6.0 to 6.7 last year, when we refreshed the servers.
Not sure why they hid the fact that they can breach the 9,000 mark:
https://docs.vmware.com/en/VMware-vS
Hi Mark,
On Mon, 6 Apr 2020 at 18:51, Mark Tinka wrote:
>
> However, VMware ESXi does not
> support anything larger than 9,000 bytes, and that is where we run our
RR's.
Since vsphere67u3 (ESXi 6.7 U3), you can set an MTU of up to 9,190 bytes:
[root@esxi01o:~] esxcli network vswitch standard lis
On 6/Apr/20 12:47, Saku Ytti wrote:
>
> Good good, if you are particularly concerned, match 8870 etype,
> len>1500 and drop on upstream router :). So should someone do
> something funky on your FRR, at least that's not the moment you test
> what your rest of the network think of large LSPs.
:-
On Mon, 6 Apr 2020 at 13:40, Mark Tinka wrote:
> On these servers, I'm pushing only 2 routes into the IS-IS domain.
Good good, if you are particularly concerned, match 8870 etype,
len>1500 and drop on upstream router :). So should someone do
something funky on your FRR, at least that's not the m
On 6/Apr/20 12:31, Saku Ytti wrote:
> So FRR should have an addition of LSP-MTU which should default
> to 1492B to avoid interoperability issues when it must generate large
> LSP PDU.
A couple of weeks ago, my Google-fu led to me some kind of "lsp-mtu"
command for FRR. I tried it everywhere bu
On Mon, 6 Apr 2020 at 13:12, Mark Tinka wrote:
> > https://github.com/FRRouting/frr/blob/58980443821edf95719984e01f31720bd1dc7f79/isisd/isis_constants.h#L172-L180
> >
> > But as long as you don't pad, your PDU shouldn't exceed 1500B.
>
> Good man, you gave me an idea.
There are other interesting
On 6/Apr/20 12:00, Saku Ytti wrote:
> Aah found it, it does do Cisco hack.
>
> https://github.com/FRRouting/frr/blob/58980443821edf95719984e01f31720bd1dc7f79/isisd/isis_constants.h#L172-L180
>
> But as long as you don't pad, your PDU shouldn't exceed 1500B.
Good man, you gave me an idea.
Ran
On 6/Apr/20 11:58, Saku Ytti wrote:
> Why is PDU 9014, if you don't have padding? I wonder what FRR even
> does at >1500B, I don't see '8870' in source code, so I don't think it
> supports the EthernetII hack.
I wondered about that when I saw it, and just assumed that FRR was
account for the 1
Aah found it, it does do Cisco hack.
https://github.com/FRRouting/frr/blob/58980443821edf95719984e01f31720bd1dc7f79/isisd/isis_constants.h#L172-L180
But as long as you don't pad, your PDU shouldn't exceed 1500B.
On Mon, 6 Apr 2020 at 12:58, Saku Ytti wrote:
>
> From your original post:
>
> > 2
On 6/Apr/20 11:48, Saku Ytti wrote:
>
> Ok, and because this particular FRR VM does more than just ISIS, you
> want the extra mtu between 9k and 8192?
Yes sir.
FRR is just another service running on the box, mainly to pull traffic
toward it.
>
> Change MTU after starting ISIS? :>
Hehe, I'm
>From your original post:
> 2020/03/21 03:12:36 ISIS: isis_send_pdu_bcast: sock_buff size 8192 is less
> than output pdu size 9014 on circuit em0
> 2020/03/21 03:12:36 ISIS: [EC 67108865] ISIS-Adj (1): Send L2 IIH on em0
> failed
Why is PDU 9014, if you don't have padding? I wonder what FRR eve
On Mon, 6 Apr 2020 at 12:43, Mark Tinka wrote:
> Hello Padding is disabled by default in our IS-IS core, so the other
> side isn't doing it already.
>
> The problem you have is IS-IS on FreeBSD won't initialize because it
> sees the physical interface running at 9,000 bytes, and yet its code can
On 6/Apr/20 11:28, Saku Ytti wrote:
> You want to run your physical at high MTU and you also like ISIS to come up?
The services running on the server benefit from the high MTU. That's the
whole point of the server... to run the services, not to run a routing
protocol.
So I don't want to lower
On 6/Apr/20 11:25, Saku Ytti wrote:
> Quite and then you specified but for ISIS you run 8000. I'm only
> talking about your ISIS here, not rest. And that 8k doesn't do
> anything useful,
Except for our CSR1000v on ESXi. We only ever needed it when we went
that route. We didn't need it prior to
On Mon, 6 Apr 2020 at 12:16, Mark Tinka wrote:
> Which is what this whole thread is about. How do I set that, manually,
> without changing the physical interface MTU?
You want to run your physical at high MTU and you also like ISIS to come up?
FRR doesn't seem to support Cisco proprietary Ether
On Mon, 6 Apr 2020 at 12:13, Mark Tinka wrote:
> Ummh, not really. As mentioned, we run 9,178 bytes on IOS and IOS XE,
> and 9,192 bytes on Junos and IOS XR, in our network.
Quite and then you specified but for ISIS you run 8000. I'm only
talking about your ISIS here, not rest. And that 8k doesn
On 6/Apr/20 11:05, Saku Ytti wrote:
> And the only thing this 'ISIS MTU' (think you mean CLNS MTU)...
Yes, I mean "clns mtu".
> does, is
> for some cases make ISIS hellos larger. If you don't pad ISIS hellos,
> or if you have standard compliant ISIS, it doesn't do anything past
> 1500B.
Ag
On 6/Apr/20 10:18, Saku Ytti wrote:
> And to your original question, no, nothing in Mark's ISIS network is
> above 1500, for the same reason.
Ummh, not really. As mentioned, we run 9,178 bytes on IOS and IOS XE,
and 9,192 bytes on Junos and IOS XR, in our network.
The 8,000 bytes we run is do
On Mon, 6 Apr 2020 at 11:50, Mark Tinka wrote:
> and switches can forward up to 9,178 bytes, we set IS-IS MTU to 8,000
> bytes on all of them, as a lowest common denominator so that our RR's
> can participate in the IS-IS domain.
And the only thing this 'ISIS MTU' (think you mean CLNS MTU) does,
On 6/Apr/20 09:58, Radu-Adrian Feurdean wrote:
> I won't speak for Mark, but NO, when you're carrying somebody's else's
> traffic you do your best to have the MTU on each and every backbone link
> "high enough" : preferably in the 9200(bytes) range, so you can easily
> transport 9000(bytes)
On 6/Apr/20 07:51, Saku Ytti wrote:
>
> I'm not sure what 'globally our IS-IS domain runs 8000 bytes' means.
> Your LSP MTU is like 1492B, there isn't a mechanism to fragment and
> reassemble LSP in-transit. ISIS network doesn't support different MTU
> sizes and I've not heard anyone being brav
On 5/Apr/20 21:24, Randy Bush wrote:
> ok, if IS-IS is kinda working on FRR, at least enough to get loopbacks
> and external interfaces around a pop, i gotta ask.
Not for me. I can't get it to even start, i.e., no link adjacencies due
to an inability to agree on MTU.
So if anyone has IS-IS on
On Mon, 6 Apr 2020 at 11:01, Radu-Adrian Feurdean
wrote:
> Ethernet cannot signal MTU. But if you have equipment at both sides of a P2P
> link, you don't need any signalling. You check the MTU suits your needs and
> put it in statically. Same for NNIs : the MTU is signalled in a document
> cal
On Mon, Apr 6, 2020, at 07:51, Saku Ytti wrote:
> I'm not sure what 'globally our IS-IS domain runs 8000 bytes' means.
> Your LSP MTU is like 1492B, there isn't a mechanism to fragment and
> reassemble LSP in-transit. ISIS network doesn't support different MTU
> sizes and I've not heard anyone bei
On Mon, 6 Apr 2020 at 10:36, Anoop Ghanwani wrote:
>> The only thing that is larger in your network is hellos, and I'm not
>> even sure how that works, considering 802.3 cannot signal larger
>> frames than 1500B.
>>
> Probably this method:
> https://en.wikipedia.org/wiki/EtherType#Jumbo_frames
M
On Sun, Apr 5, 2020 at 10:52 PM Saku Ytti wrote:
> The only thing that is larger in your network is hellos, and I'm not
> even sure how that works, considering 802.3 cannot signal larger
> frames than 1500B.
>
> Probably this method:
https://en.wikipedia.org/wiki/EtherType#Jumbo_frames
35 matches
Mail list logo
