[c-nsp] IS-IS Emergency

[Jared Mauch]

On Fri, Jun 22, 2007 at 11:17:54AM -0400, Vinny Abello wrote:
> Justin Shore wrote:
> > Robert Boyle wrote:
> >> At 02:40 PM 6/20/2007, you 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?
> >> This is what we use on our Cisco & Foundry core network. This is 
> >> obviously a Cisco config snippet.
> >>
> >> router isis
> >>  net xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >>  is-type level-2-only
> >>  domain-password xxxxxxxxxxxxxxxx
> >>  metric-style wide
> >>  ip fast-convergence
> >>  set-overload-bit on-startup wait-for-bgp
> >>  max-lsp-lifetime 65535
> >>  lsp-refresh-interval 65000
> >>  no hello padding
> >>  log-adjacency-changes
> >>  passive-interface Loopback0
> >>  maximum-paths 6
> >>
> >> It works very well and we don't have any issues.
> > 
> > Many thanks for the input, Robert.  That's close to what we're doing as 
> > well.  We also have the prc-interval set to 10, increased 
> > max-area-addresses and set NSF to cisco (plus some evil redistribution 
> > that is temporary and will be gone soon).  "ip fast-convergence" isn't 
> > an option on our 7600s.  What platform are you working on?  I'm going to 
> > change up for "on-startup 300" to wait-for-bgp.  We upgraded to SRB1 
> > last night and the overload-bit delay worked flawlessly.  The load on 
> > the Sup pulling down 2 full BGP tables from directly connected routers 
> > took less than 30 seconds, the RIB update was finished in well under a 
> > minute, and the load never exceeded 30%.  This is compared to the load 
> > pegging at 100% for a couple minutes without the delay.  Much better.  :-)
> 
> Just a side note as well:
> 
> As far as the BGP convergence on start-up, you may also want to
> investigate using "ip tcp path-mtu-discovery" in your configurations if
> you don't have it already. Last I knew, the MTU defaults to a very low
> size for BGP sessions. Adding this command will allow it to converge
> faster as more data can be transmitted in each packet when your sessions
> are coming up.
> 
> Our ISIS configuration above that Robert provided was largely based on
> the recommended settings from Cisco that were provided to AOL during
> their OSPF to ISIS migration... maybe minus the ip fast-convergence.
> 
> Our (Cisco) platforms are generally Cat6500 12.2(18)SXF and 7206
> 12.2(28)SB builds.

	Increasing the input hold queue to 4096 on the interfaces
can also speed up convergence.  I usually don't bump them all the way
up for fear of a wedge bug or something strange, so want to have
some room to wiggle, but 3.5k should work for most folks nicely.

	- Jared


-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.