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

John Neiberger jneiberger at gmail.com
Mon Mar 11 14:35:11 EDT 2013


On Mon, Mar 11, 2013 at 11:29 AM, Bruce Pinsky <bep at whack.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Neiberger wrote:
>
> > 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.
> >
>
> As I mentioned, there is no dampening mechanism on fast fall-over and peers
> are dropped immediately when the next hop is lost.  If the next-hop of the
> routing entries is the same as the peering address, then next-hop tracking
> should be sufficient to cause the routes to flush from the RIB if
> reachability is lost and next-hop tracking has a delay/dampening mechanism
> built in.
>
>
Ah, yes. That makes sense. I was planning on doing selective next-hop
filtering but while I was researching it I ran across fast fall-over, so I
thought I'd better check into it. I think I like the idea of having a
little bit of a delay built in. It sounds like this would be a better
option for what we're trying to do.

Thanks,
John


More information about the cisco-nsp mailing list