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.tinka@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.htm...
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.