[j-nsp] ISIS flaps caused by MX em0 MTU

[Andrey Kostin]

Hi Nitzan,

Maybe this article could be helpful because it refers to similar 
symptoms:
https://supportportal.juniper.net/s/article/PacketIO-PFE-process-may-drop-small-fragments-of-TCP-and-UDP-packets-destined-to-the-routing-engine
https://prsearch.juniper.net/problemreport/PR1796344

Kind regards,
Andrey

Nitzan Tzelniker via juniper-nsp писал(а) 2024-08-30 05:06:
> Something I discovered a few days ago and I would like to understand if
> others saw it and you mitigate it.
> The em0/em3 (RE to PFE ) on Juniper MX is using a hardcoded MTU of 
> 1500.
> All of the traffic on that interface is encapsulated with Juniper TTP
> protocol
> As a result, any control packet which uses MTU of 1500 is fragmented 
> (SSH
> for example) and there are also some internal predefined telemetry 
> sensors
> that send large packets which are also fragmented.
> I face this after some wired ISIS flaps from Juniper MX BNG to Cisco 
> IOS-XR
> devices that do hello padding by default but it can affect other 
> protocols
> too.
> We saw that the packets arrived to the PFE but not to the RE and we 
> tried
> to find where it was dropped.
> After some time, we found that the issue is related to the hello 
> padding,
> but it took us a long time to find that the issue is the fragmentation 
> on
> the PFE to RE
> Now we are trying to find out if there is any storm of fragments that
> causes these drops.
> 
> The device has a very strict lo0 filter but it is BNG so it still 
> accepts
> some control packets from subscribers.
> 
> Can you check the following command and see if you have fragments 
> drops?
> 
> nitzan at MX> show system statistics ip | match frag | match drop
>          684484 fragments dropped (dup or out of space)
>          128375 fragment sessions dropped (queue overflow)
>          21040072 fragments dropped after timeout
> 
> If anybody want to capture only the fragments you can use the following
> pcap filter on that interface
> monitor traffic interface em0 no-resolve count 100 matching "((ip[6:2] 
> > 0)
> and (not ip[6] = 64))"
> 
> Does anybody face a similar issue ?
> How did you solve it?
> Does anybody know why Juniper didn't increase the MTU on that interface
> over the years (I believe it is some historical setting that no one 
> wants
> to change).
> 
> Nitzan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp