[c-nsp] Faster iBGP convergance: Tune the timers or use Fast Peering Session Deactivation?

[Sam Stickland]

On Tue, Jun 8, 2010 at 7:31 PM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Tue, Jun 08, 2010 at 05:14:58PM +0100, Sam Stickland wrote:
> > All,
> >
> > I'd appreciate any feedback people have on tuning iBGP for faster
> > convergence, particularly dead peer detection for indirect Loopback to
> > Loopback peerings.
> ...
> > I heard via some other colleges that Cisco do not recommend FPD due to
> IGP
> > instability promoting BGP instability and if we do run into issues with
> > FPD in production, Cisco will recommend we remove it opposed to a
> productive
> > TAC case being endeavoured.
>
> Ideally you wouldn't actually want IBGP to fail, you'd want the next-hop
> the IBGP session points to to fail, thus invaliding the paths to the
> prefixes (especially if you're running code with next-hop indirection
> support). Tearing down the IBGP session accomplishes nothing but burning
> a lot of time and cpu resources bringing it back up later on. If your
> next-hop goes away in IGP you can pull the prefixes from use without
> having to actually kill IBGP quickly, and if you have next-hop
> indirection you can pull the prefixes in a single operation, which
> should vastly improve convergence times.
>
>
Hi Richard,

I see what your getting at, and it makes sense. Unfortunately with the
presence of aggregate covering addresses in the IGP or a default (and we
currently have both), I believe the next-hop won't be invalidated?

We are in the process of labbing all this at the moment, but Cisco are
trying to steer us down the path of very low iBGP timers.

I should point out, this is an 'enterprise' DC environment, using 6500
Sup720s. Each 6500 will probably just have two iBGP session to a
router-reflector (unfortunately also a 6500), and significantly there's less
than 10,000 routes.

Regards,

Sam