IS-IS Error (FRR)

Sun Apr 19 00:46:40 UTC 2020

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.

On 18/Apr/20 16:34, Tony Li wrote:
>
> No, IIH’s are padded, hot PSNP’s.
>
> Tony
>
>> On Apr 18, 2020, at 3:08 AM, adamv0025 at netconsultings.com wrote:
>>
>> 
>>
>> 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
>>
>> *From:*NANOG <nanog-bounces at nanog.org> *On Behalf Of *Mark Tinka
>> *Sent:* Friday, April 17, 2020 11:05 AM
>> *To:* nanog at nanog.org
>> *Subject:* IS-IS Error (FRR)
>>
>>  
>>
>> 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.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200419/9adc39a8/attachment.html>