On Sat, 25 Jan 2003, Christopher L. Morrow wrote:
" Access list logging does not show every packet that matches an entry. Logging is rate-limited to avoid CPU overload.
either way, the logging for this, ESPECIALLY with log-input, is a dangerous proposition.
Are you saying that I shouldn't believe Cisco's own documentation? Obviously, it's going to take _some_ CPU cycles, but I would expect the box to remain operational.
One thing to keep in mind is that the S-train platforms are different in handling logging than the normal trains...
Ok, I've been working with Cisco equipment for 8 years now and I can configure them in my sleep, but all the version/image/train/feature set is still voodoo to me. Obviously, the router caches the information it wants to log for a while and then counts hits against the cache until it actually logs. This should work very well, and it does as per my tests on a heavily loaded 4500 router. So why would one type of IOS do this right and another version that isn't immediately recognizable by the version number as inferior do it wrong?
possible and happily saturate it :( (Don't log on like a 7500 for instance if the packet rates are over like 5kpps...)
I think today's events show that CPU-based routers have no business handling anything more than 1 x 100 Mbps in and 1 x 100 Mbps out. If a box has 40 FE interfaces or 4 GE interfaces, at some point you'll see 4 Gbps coming in so the box must be able to handle it to some usable degree.
There doesn't seem to be a noticable impact on CPU usage for a C12000 GigE linecard. Can you do Netflow rather than CEF on such a beast without a performance penalty?
One thing to keep in mind is that perhaps you don't care about the logging :) Just drop it and make your customers fix their borked boxes...
That's why I want the logging: to see which customer is spewing out the garbage. (-: