[c-nsp] IS-IS Emergency

[Pete Templin]

Justin Shore wrote:

> That brings up a related question.  Does anyone have any recommendations 
> for using the overload-bit with a startup delay or BGP hold?  We set it 
> to 5 minutes on boot.  I figure that's just enough time for the BGP to 
> settle down.  These 720-3BXLs are in an iBGP mesh with both border 
> routers and get a full Internet table from both.  The RIB Update and BGP 
> Scanner processes don't usually settle down for 3-4 minutes.  Should I 
> set a hard timeframe or should I just set it up to wait for BGP?

(Reference: we use two core routers in every POP; distribution (customer 
access) and edge (upstream connectivity) routers connect to both cores 
and nothing else, cores connect to each other intra-POP and we have 
nearly a full-mesh inter-POP between our 4 main POPs.  Core routers are 
BGP route reflectors, but client to client reflection has been disabled.)

I use a hard setting of 10 minutes, on the basic premise of "why rush"? 
  Other than the corner cases you apparently tickled (which we haven't 
run into), the router is still fully reachable, just not likely on the 
IGP forwarding path.  If the other core router should crash and/or part 
of the topology should fail during that 4-6 minute window after BGP 
converged and before normal metrics are restored, the network can still 
IGP-converge to the first core router if needed.

The obvious exceptions and notes: the first or second core router to 
roll out new code may have the overload bit set manually (and therefore 
removed manually).  For reloads to clear fragmented/lost memory, we'll 
usually 'cop ru st', 'reload at some:time', then 'set-overload-bit'. 
That way, traffic has completely converged off the router in question 
prior to the reload, but we don't have to babysit the router upon 
restoral.  FWIW, we ran into a glitch where some MPLE TE tunnels 
wouldn't re-update their metric after the wait timer expired, but that 
was back in our days of OSPF.

pt