[c-nsp] eBGP multihop, link failure, and multi-path IGP (OSPF)

[Rick Ernst]

FWIW, disabling fast-failover worked fine with no apparent downside.

On Mon, Nov 2, 2009 at 1:34 PM, David Prall <dcp at dcptech.com> wrote:

> Turn on PIC-Core
> cef table output-chain build favor convergence-speed ! please be wary of
> platform specific caveats
>
> ip routing protocol purge interface ! purges interface routes and not
> routes
> that followed the interface, this will leave the BGP routes untouched.
>
> This is the only thing I could find discussing it:
>
> http://www.cisco.com/en/US/docs/routers/10000/10008/configuration/guides/bro
> adband/dffsrv.html#wp1191135<http://www.cisco.com/en/US/docs/routers/10000/10008/configuration/guides/bro%0Aadband/dffsrv.html#wp1191135>
>
> It is available on other platforms as well.
>
> David
>
> --
> http://dcp.dcptech.com
>
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Rick Ernst
> > Sent: Monday, November 02, 2009 4:04 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] eBGP multihop, link failure, and multi-path IGP (OSPF)
> >
> > We have some eBGP neighbors that have their peering session reset in
> > the
> > case of link failure (root-cause analysis and problem resolution as a
> > separate subject).  The peers are connected via loopback interfaces and
> > multi-path OSPF.
> >
> > bgp fast-external-failover is supposed to be used for directly
> > connected
> > eBGP peers, but it seems like a link failure on a pair of redundant
> > (layer-3) links is also causing the peer to go down:
> > Nov  1 11:33:12 10.56.205.1 %OSPF-5-ADJCHG: Process 1, Nbr a.b.c.d on
> > FastEthernet8/0/0 from EXSTART to DOWN, Neighbor Down: Interface down
> > or
> > detached
> > Nov  1 11:33:12 10.56.205.1 %BGP-5-ADJCHANGE: neighbor w.x.y.z Down
> > Interface flap
> >
> > The destination to the peer is still in the FIB, and the peer comes
> > back up
> > almost immediately (in this case, about 15 seconds).
> >
> > I'm considering disabling fast-external-failover, but want to better
> > understand the event.  The eBGP peer is not "directly connected" on the
> > interface. It is reachable via a loopback peering IP with multi-path
> > OSPF.
> > Is this expected behavior (any link with a route to the destination
> > going
> > down will cause the session to go down)?
> >
> >
> > Any gotchas with disabling fast-failover?
> >
> > Thanks,
> > _______________________________________________
> > 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/
>
>