|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: DOS?
On Sat, 25 Jan 2003, Iljitsch van Beijnum wrote: > 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. Yes, you'd expect this to remain operational.. but the real world 'testing' shows that not to be the case. If the attack has highly random source or destination the log messages get gen'd for each packet :( This causes a little pain (or alot if you qualify dropping routing protocols as alot) on the router :( CPU spikes due to logging large floods are quite common. This I know from very personal experience. > > > 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 me too. > wants to log for a while and then counts hits against the cache until it only for identical packets... so source A:123 -> Dest B:80 x500000 packets gets logged 'once'. One log for the first packet and update logs at 5 min intervals (which may be setable in some ios command, which may only exist in S-train code). If the attack is randomized, sources, destinations, or ports... there is effecively a new 'flow' for each packet and thus a new log message for each... (again, in S-train code or 12.0(21)+ code this is rate-limited to the RP and thus to the logs... somewhat atleast) > 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? S-train code has specific features that don't get propogated to other trains because they aren't 'required' there or aren't applicable, or not asked for. > > > 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. > that may be, but CPE isn't normally vendor J for t1/t3/oc3 customers... never mind dsl/dial/cable customers, eh? The vast majority is cpu based equipment. Whether or not that's a good thing is immaterial, no one is going to upgrade all ruouting gear overnight :( (or in 2 years as we've seen) > > > 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. (-: > well, then.. log vs log-input :) cause log-input is more processing and thus more pain. (and if its 'inbound' on interfaces the 'log-input' is kinda pointless, eh?
|