[c-nsp] bgp PIC Edge & neighbor shutdown

James Bensley jwbensley at gmail.com
Fri Aug 25 04:21:21 EDT 2017

On 15 August 2017 at 14:57, Vladimir Troitskiy <ruthenate at gmail.com> wrote:

Hi Vladimir,

> After a significant delay a SW-FIB entry (and probably HW-FIB entry) for
> this prefix was still pointing to disabled neighbor although there was a
> backup path for this prefix.
> It looks like this SW-FIB updating delay differs for different prefixes.
> Of course, the old data-plane path was still operational as Adam mentioned,
> but this delay confused me a little bit.
> After reading some PIC-related BRCARKs I assume the PIC should work only in
> case of data-path failure. Shutting down the BGP neighbor doesn't broke the
> data-path (interface and next-hop remain 'healthy') so there is no PIC
> trigger for that and prefixes may be updated one-by-one during SW
> convergence. I didn't find any significant proofs or any list of PIC
> triggers so it is only my thoughts and assumptions.

That is roughly what I thought (see the post I just made) - I'm not
sure basically but I would guess an update to the data plane coming
from the top down does not have PIC like behaviour. When there is a
control-plane level update the device needs to check if better
routes/paths/NH's have become available. A device might have a "main"
path and a backup path. The "main" path (best NH) might go down, but
also a new NH might become available so it's probably not best to just
switch to the backup path "automatically", probably a RIB walk is
required otherwise the device might switch to the backup path whilst
the RIB is being walked and then change NH again to the new better
"main" path once the RIB has realised (processed) it is there. So the
traffic which flap between forwarding paths and it give unpredictable
failover behaviour.

I could be wrong about any and all of that so I'm keen to hear
corrections if anyone has some.


More information about the cisco-nsp mailing list