[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IS-IS on FRR - Is Anyone Running It?

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 @

I hope this helps and please continue to share your progress with the

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>