On 3/Apr/20 16:28, Jeremy Austin wrote:
> Mark,
>
> I suggest you ask this directly on the FRR slack:
>
> https://frrouting.slack.com/
>
> I’m also interested to know who’s been trying FRR IS-IS in the wild.
> At last check your former guess seemed to be correct and it wasn’t
> under active
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 @
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
>
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
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:
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
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
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
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
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
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:
>
> >
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,
>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
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
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
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
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
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.
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
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)
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
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
>
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
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
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
On Sun, 5 Apr 2020 at 11:07, Mark Tinka wrote:
> plane, we manually set IS-IS to operate at 8,000 bytes. This is due to
> VMware's limitation to address an MTU larger than 9,000, and we use it
> to run CSR1000v for our route reflector. So globally, our IS-IS domain
> runs 8,000 bytes.
I'm not
ok, if IS-IS is kinda working on FRR, at least enough to get loopbacks
and external interfaces around a pop, i gotta ask.
anyone running a ubiquity edgerouter infinity with frr, is-is, and four
or so full bgp feeds?
randy
On 4/Apr/20 19:16, John St.Martin wrote:
> 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
On 3/Apr/20 21:28, Eduardo Schoedler wrote:
> Mark,
>
> Did you tried this:
> https://lists.freebsd.org/pipermail/freebsd-current/2006-December/068011.html
>
> There are some knobs for Freebsd:
> http://nginx.org/en/docs/freebsd_tuning.html
So the problem really isn't FreeBSD itself. IS-IS
Mark,
I suggest you ask this directly on the FRR slack:
https://frrouting.slack.com/
I’m also interested to know who’s been trying FRR IS-IS in the wild. At
last check your former guess seemed to be correct and it wasn’t under
active development.
Regards
Jeremy Austin
On Thu, Apr 2, 2020 at
Hi all.
So I finally decided to start messing around with FRR for a native IS-IS
deployment for some of our FreeBSD-based Anycast services.
I hit an issue that I posted to the FRR list that hasn't progressed
beyond identifying a bug:
2020/03/21 03:12:36 ISIS: isis_send_pdu_bcast: sock_buff size
36 matches
Mail list logo
