>the rest of the IBGP has to then wait for your BGP timeout to drop. Yes, that is slow. No you don't need to wait for bgp altogether. You can rely on your fast IGP to propagate the NH reachability information throughout the AS. On each router, once the RIB is updated by IGP, RIB will notify BGP to invalidate the particular NH thanks to BGP next-hop-tracking which is enabled by default as the session forms.
adam -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steven Raymond Sent: Monday, March 11, 2013 6:14 PM To: John Neiberger Cc: [email protected] Subject: Re: [c-nsp] BGP neighbor fall-over vs BFD On Mar 11, 2013, at 10:52 AM, John Neiberger wrote: > I was just reading a bit about next-hop tracking and neighbor > fall-over and now I'm a little confused about what fall-over actually > does. The docs say that it enables fast peering session deactivation, > but I can't tell what that really means. The wording in the docs makes > it sound a lot like BFD, but not exactly. In fact, fall-over can be used with BFD. > > Can someone shed some light on this? What is fall-over really doing > and when might it be useful? BFD is useful for detecting failure of links between directly-connected neighbors. Fall-over is useful for immediate notification of distant IBGP neighbors. So while BFD will inform your immediate neighbor of link down, the rest of the IBGP has to then wait for your BGP timeout to drop. Yes, that is slow. FYI, Brocade MLX-series does not have this feature, so in a mixed environment I ended up tweaking the keepalive timers on the Brocade neighbors to compensate. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
