On Mon, Mar 11, 2013 at 11:29 AM, Bruce Pinsky <[email protected]> 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
