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

[John Neiberger]

On Mon, Mar 11, 2013 at 11:12 AM, Oliver Boehmer (oboehmer) <
oboehmer at cisco.com> wrote:

>
> >
> >Can someone shed some light on this? What is fall-over really doing and
> >when might it be useful?
>
>
> sorry for the confusion ;-)   neighbor fall-over (without the BFD keyword)
> is for multihop/non-directly-connected peers like the default behaviour
> fast-external-fallover for directly connected neighbours: the session will
> be torn down. It works by monitoring/tracking the next-hop address, so if
> something removes the route to the peer, the session will be torn down. It
> works pretty much the same way as Next-hop-Tracking (monitoring the RIB),
> but it tears down the session (while NHT only declares the nexthop as
> invalid).
>
> "fall-over bfd" isn't monitoring the RIB, it uses BFD to monitor neighbour
> reachability & liveliness, and it will tear down the session if BFD
> signals a failure.
>
> So fall-over is actually much more than a single feature.. did I apologize
> for the confusion? ;-)
>
>         oli
>
>
In the case I'm thinking of using it, we do all over our internal BGP
peering to loopbacks, which are in OSPF. If we enable fallover, it sounds
like the peer will be torn down as soon as that next hop is removed from
the routing table. One problem we have that I'm trying to solve is that we
also have a null0 static route used for aggregation for the loopback
addresses. This static route stops the BGP routes from being invalidated
until the peer goes down because the next hop is technically still
reachable, although via Null0. I'm pondering the use of selective next-hop
filtering so that only /32 routes in OSPF can be used to validate next
hops, but I wonder if just enabling fallover would be better option. We
aren't using BFD right now. Not sure why. It seems like using fallover with
BFD would be an excellent solution to this problem.

Thanks!
John