Re: IS-IS on FRR - Is Anyone Running It?
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 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 brave enough to increase LSP MTU above 1492B. 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. -- ++ytti
Re: IS-IS on FRR - Is Anyone Running It?
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
Re: COVID-19 vs. peering wars
On Fri, Mar 20, 2020, at 20:31, Matthew Petach wrote: > Netflix, Amazon Prime, Youtube, Hulu, and other video > streaming services cut their bit rates down? > > https://www.bbc.com/news/technology-51968302 > https://arstechnica.com/tech-policy/2020/03/netflix-and-youtube-cut-streaming-quality-in-europe-to-handle-pandemic/ > > It seems that perhaps the fingers, and the regulatory > hammer, are being pointed in the wrong direction at There was not regulation for that. There were some politicians crying out and loud in the media that streaming platforms should reduce bit-rates. Netflix took the opportunity to try (sooner than initially scheduled) new compression schemes/algorithms on their platform. Further, they took the opportunity to say "everything is OK, the new stuff will be deployed full-scale around Europe". In parallel, other streaming platforms took their measures, some of them as simple as "default is one level lower" (720p instead of 1080p, or even 480p instead of 720p). That went as far as platforms that would never be named explicitly by any "responsible" politician (like pornhub and sorts). Chances are the results of the "bitrate reduction" will end up in the US pretty soon. Netflix are also insisting on the fact that it's not a quality reduction, just new compression allowing for lower bitrates over the wire. The French regulator is even very decent in this respect, the official message being : "situation is overall good, in the rare cases and places where there are issues operators will do heir job to fix the issues". In general, there are no new issues, just probably more people realising the issues that already existed for some time. Peering-wise, BAU, nothing new. Only thing is one of the 4 majors ISPs, ~21% market share, over 98% IPv6 deployment on fixed (and 0% on mobile) mono-homed to Cogent and de-peering HE. They are not peering as a general rule.
Re: IS-IS on FRR - Is Anyone Running It?
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 build from 3/21 available which allows for up to 16k MTU > @ https://ci1.netdef.org/browse/FRR-FRRPULLREQ-11364/artifact > > I hope this helps and please continue to share your progress with the > community. Thanks for the feedback, John. It's great to hear this issue is being fixed. So I'm not really trying to get IS-IS to run at a high MTU, as that doesn't really do anything for the data plane. What I am really looking for is a way to tell IS-IS to run a specific MTU. In my network, even though we can carry up to 9,192 bytes in the data 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 am just looking for a way to tell IS-IS, in FRR, to run at 8,000 bytes, which can be done without needing to fix the current bug in 7.2. I just can't seem to find any configuration settings to do this, or anyone that knows what they are. Mark.
