On 15 August 2017 at 14:57, Vladimir Troitskiy <[email protected]> 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. Cheers, James. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
