e ninja wrote: Richard,
On the contrary, as I stated below, the 'impact' of BGP scanner (a housekeeping task executed by the main processor) on 'system' performance will continue to diminish as more platforms become modular (distributed architecture) and/or switch packets in hardware (i.e, independent of RP and LC CPU eg in FPGAs) Nothing in the aforementioned suggests that BGP scanner (a critical process for validating the integrity of the BGP table) will EoL anytime soon. Instead, if you note the quotes, Drew is concerned with the impact of the CPU consumed by BGP scanner on 'system' performance. This concern does not exist on modular platforms with distributed packet switching (c12k, hfr etc.) that switch packets independent of main RP CPU. Put simply, even if BGP scanner maxes out an RP CPU at 100% temporarily on a distributed platform, it will have zero effect on packet switching (a la 'system' perf) through the device. Your thoughts below dwell more on enhancing the mechanism to reduce frequency. ------------- Yes, but the confusion in (my mind, anyway) is that sometimes when the RP is at high CPU utilization forwarding performance is affected. i.e. in the case of a DoS attack, although I suppose that the RP being at high CPU utilization is a 'by-product' of the forwarding hardware punting so much crap to the RP and not vice-versa. So when monitoring the CPU for these kinds of events it can be hard to tell in a programmatic way whether it's just BGP scanner, or something more nefarious like a TTL Expiration attack, or any of the other 700 types of DoS/DDoS style attacks which take place these days. I suppose the real question is, what do you monitor on a modular/distributed system in order to gauge the performance, if not the CPU on the Route Processor? are there OIDs for the discrete switching/forwarding engines? I know at least on the GSR platform each line card has its own CPU/memory statistics available, which is at least ??somewhat?? helpful in quickly identifying a problem. -Drew _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
