IS-IS on FRR - Is Anyone Running It?

Sat Apr 4 17:16:38 UTC 2020

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200404/fd3a05fd/attachment.html>