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. On Sat, Apr 4, 2020, 11:18 AM Mark Tinka <mark.ti...@seacom.mu> wrote: > > > 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 looks at MTU in order > to work, and if nothing is manually set, it infers the MTU from the > physical interface over which it is enabled. > > While the current IS-IS implementation in FRR is buggy to the extent > that it does not assume MTU can be larger than 8,192 bytes, that does > not prevent an operator from telling it what MTU it should use for IIH > messages, provided the physical interface can support it. > > Suffice it to say, I already have a number of Sysctl and kernel knobs in > FreeBSD to tune the system for the Anycast services we run on them. I'd > be disinclined to mess about with that as I don't think it has any > bearing on an over-the-top service such as IS-IS. > > Quagga runs well (OSFP though, I'll admit), and I'll keep looking for > answers on IS-IS in FRR until it stops making sense. > > Mark. >