[c-nsp] BGP neighbor fall-over vs BFD

[Adam Vitkovsky]

>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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Steven Raymond
Sent: Monday, March 11, 2013 6:14 PM
To: John Neiberger
Cc: cisco-nsp at puck.nether.net
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  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/