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. -- Vinny Abello Network Engineer [EMAIL PROTECTED] (973)940-6100 PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
