[c-nsp] Reasons for "random" ISIS flapping?

[Adam Vitkovsky]

> And we see no input queue drops on the receiving side or output drops on the sending side. 
I see, than the IIHs must be lost internally within the router, maybe a bug causing ISIS process improper handling of fast incoming IIHs in addition to BFD state notifications. 
Or it may be a process scheduling problem where ISIS cannot handle the influx of IIHs -though that should not happen since the hello interval is jittered up to 25% to avoid synchronization. 


adam
-----Original Message-----
From: Peter Rathlev [mailto:peter at rathlev.dk] 
Sent: Wednesday, August 07, 2013 11:19 AM
To: Adam Vitkovsky
Cc: 'cisco-nsp'
Subject: Re: [c-nsp] Reasons for "random" ISIS flapping?

On Wed, 2013-08-07 at 10:34 +0200, Adam Vitkovsky wrote:
> So in case Router-A does not see the hellos for 800ms or 1s it will 
> thorn down the adjacency on his side and will try to reinitialize it 
> by sending the IIH but this time with an empty TLV 6.
> When e.g. Router-B will receive such an IIH it will realize that its 
> neighbor has forgot him and will thorn down the adjacency to 
> participate in the new adjacency formation procedure with Router-A.
> 
> So the question seems to be why Router-A stops receiving IIHs or BFD 
> hellos for a split second from time to time while no one else notices 
> any problems until they learn that Router-A dropped the adjacency.

Ah, thank you (and Saku too) for this explanation. It makes a lot of sense and clearly points at ROUTR-A not receiving (or internally losing) the hello packets.

> Maybe some ingress buffers overruns or some CoPP. 

The device in question has no control-plane policy. (Sub-optimal, I
know.) And we see no input queue drops on the receiving side or output drops on the sending side. Since it's dark fiber between all the devices I consider the possibility of simply "lost" packets low.

--
Peter