[c-nsp] IS-IS Emergency

[Justin Shore]

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.  :-)

Thanks again
   Justin