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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
