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