Aren't most of the 6500 blades the same as the 7600 ones anyway? Between these two IMHO we are looking at a blurry distinction between a router with very good switching capabilities and a L3 switch with very good routing capabilities.
Does the 7600 have the same BGP Scanner problem as the 6509 does?
7600 runs the same code as 6500 with native IOS. It *is* the same box, as has been repeatedly pointed out. Maybe you could expand on the BGP scanner problems - we haven't seen them all the time we've been running 6500 native with full routes (about 1.5 years now). Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Mon, 13 Oct 2003 sthaug@nethelp.no wrote:
Maybe you could expand on the BGP scanner problems - we haven't seen them all the time we've been running 6500 native with full routes (about 1.5 years now).
BGP Scanner taking up close to 100% of CPU on a box periodically. GSR doesn't seem to do it, but a buncha other cisco boxes do. Its more irritating than anything else, especially when customers complain that when they traceroute they see ~200ms latency to the router...
Tom (UnitedLayer) wrote:
On Mon, 13 Oct 2003 sthaug@nethelp.no wrote:
Maybe you could expand on the BGP scanner problems - we haven't seen them all the time we've been running 6500 native with full routes (about 1.5 years now).
BGP Scanner taking up close to 100% of CPU on a box periodically. GSR doesn't seem to do it, but a buncha other cisco boxes do. Its more irritating than anything else, especially when customers complain that when they traceroute they see ~200ms latency to the router...
Doesn't happen here with MSFC2/SupII. Maybe just MSFC1's that are subject to that.
Steve Francis wrote:
BGP Scanner taking up close to 100% of CPU on a box periodically. GSR doesn't seem to do it, but a buncha other cisco boxes do. Its more irritating than anything else, especially when customers complain that when they traceroute they see ~200ms latency to the router...
Doesn't happen here with MSFC2/SupII.
Maybe just MSFC1's that are subject to that.
Every IOS-based device running BGP will have a BGP Scanner process that wakes up once a minute and walks the BGP RIB checking that the next hops are still valid. Whether it makes a noticeable impact on CPU utilization depends on the platform and the size and distribution of the BGP table. Obviously the more powerful the CPU the less the impact. In my experience the distribution of the BGP table can also make a big difference. Adding more specifics of a /8, /16, or /24 prefix seems to have a disproportionate impact; my guess is it has something to do with the data structure used to store the prefixes. (If they use a 256-way mtrie like they do for CEF, more specifics of a /8, /16, or /24 would require creation of an additional internal node.) If you have a recent IOS that supports the 'show proc cpu history' command, often the BGP Scanner spikes are quite obvious. On platforms that do distributed forwarding, the spikes really only affect traffic to/from the router, so additional latency will show up in traceroutes or pings but forwarded traffic will not be affected. On platforms that do centralized forwarding BGP Scanner can impact forwarded traffic. Bradley
Bradley Dunn wrote: [...]
Adding more specifics of a /8, /16, or /24 prefix seems to have a disproportionate impact; my guess is it has something to do with the data structure used to store the prefixes. (If they use a 256-way mtrie like they do for CEF, more specifics of a /8, /16, or /24 would require creation of an additional internal node.)
Good point. I'd made the simple assumption that scanner spikes were due to table churn, as when redistributing connected and/or static routes to unstable interfaces. It happens that most such will be... unnaturally specific. [...] Peter E. Fry
On Mon, Oct 13, 2003 at 02:15:59PM -0700, Tom (UnitedLayer) wrote:
On Mon, 13 Oct 2003 sthaug@nethelp.no wrote:
Maybe you could expand on the BGP scanner problems - we haven't seen them all the time we've been running 6500 native with full routes (about 1.5 years now).
BGP Scanner taking up close to 100% of CPU on a box periodically. GSR doesn't seem to do it, but a buncha other cisco boxes do. Its more irritating than anything else, especially when customers complain that when they traceroute they see ~200ms latency to the router...
On the GSR, dCEF is turned on by default, and the GRP does the bgp processing while the linecards continue to forward packets without interruption (well at least until an update comes in and dCEF starts pointing the packets out the wrong interface at any rate). :P -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
bgp scanner cpu usage == number of neighbors * number of routes in table lots of neighbors would cause this, for longer periods. If running SUP1A/MSFC this could be worse than with MSFC2 (slightly more CPU power), and much worse than SUP2 I'm guessing. Tom (UnitedLayer) wrote:
On Mon, 13 Oct 2003 sthaug@nethelp.no wrote:
Maybe you could expand on the BGP scanner problems - we haven't seen them all the time we've been running 6500 native with full routes (about 1.5 years now).
BGP Scanner taking up close to 100% of CPU on a box periodically. GSR doesn't seem to do it, but a buncha other cisco boxes do. Its more irritating than anything else, especially when customers complain that when they traceroute they see ~200ms latency to the router...
participants (7)
-
Bradley Dunn -
Jason LeBlanc -
Peter E. Fry -
Richard A Steenbergen -
Steve Francis -
sthaug＠nethelp.no -
Tom (UnitedLayer)