cnsp at shreddedmail
Dec 9, 2009, 8:41 AM
Post #3 of 3
(1084 views)
Permalink
|
|
Re: eBGP multihop, link failure, and multi-path IGP (OSPF)
[In reply to]
|
|
FWIW, disabling fast-failover worked fine with no apparent downside.
On Mon, Nov 2, 2009 at 1:34 PM, David Prall <dcp [at] dcptech> 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 [mailto:cisco-nsp-
> > bounces [at] puck] On Behalf Of Rick Ernst
> > Sent: Monday, November 02, 2009 4:04 PM
> > To: cisco-nsp [at] puck
> > 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
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
|
