Hi all.
I’m almost there getting IS-IS to work without issue. I’m now faced with the following error log:
2020/04/17 10:02:01 ISIS: IS-IS bpf: could not transmit packet on em0: Input/output error
2020/04/17 10:02:01 ISIS: [EC 67108865] ISIS-Snp (1): Send L2 PSNP on em0 failed
This repeats every second.
Anyone know what this could be?
Systems is FreeBSD-12.1-RELEASE-p3.
Despite the error, IS-IS is running and routing is good, talking to a Cisco IOS XE implementation on the other side. So the error is throwing me off.
No feedback from the Slack feed, Google doesn’t say much, and waiting to hear back from the FRR list.
Mark.
Just shooting in the dark, Isn’t the PSNP padded to some ISIS defined max MTU and that somehow fails due to mismatch on em0 L2 MTU?
adam
So we’ve been discussing this on Slack.
It seems the packet handlers for IS-IS in FRR and how they work on FreeBSD is not completely optimized (not an issue on Linux).
FRR-based IS-IS on FreeBSD is sending PSNP’s that are 6,020 bytes large. However, FreeBSD’s BPF (Berkeley Packet Filter) has a packet data limit of 4,096 bytes. This is what is causing the error.
While it is possible to set the IIH MTU in FRR with the “lsp-mtu” command, there is not way to set the PSNP MTU.
In short, IS-IS on FRR does not understand that there is an MTU limit for PSNP’s on FreeBSD.
I’m working with the IS-IS FRR team, but as of now, no idea on if/when there will be a fix for this.
While routes are being successfully exchanged between FRR and Cisco IOS XE for IS-IS, this is a show-stopper! So for the moment, I cannot recommend anyone runs IS-IS on FRR in production.
As it stands, it appears that this is the only thing standing in the way of a successful deployment, as far as simple Anycast services go.
Will keep you all posted as this develops.
Mark.
Interesting, so it is an MTU problem after all, I take it there’s no way to adjust the BPF (Berkeley Packet Filter) limit to let the 6020B sized PSNPs through?
adam
Probably could - but I’d prefer solutions that don’t mess with the base system, which ensures long term usability of FRR across future upgrades. The BPF man page has an interesting bug note: BUGS The read buffer must be of a fixed size (returned by the BIOCGBLEN ioctl). A file that does not request promiscuous mode may receive promiscuously received packets as a side effect of another file requesting this mode on the same hardware interface. This could be fixed in the kernel with ad- ditional processing overhead. However, we favor the model where all files must assume that the interface is promiscuous, and if so desired, must utilize a filter to reject foreign packets. Data link protocols with variable length headers are not currently sup- ported. Mark.