North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
- From: Iljitsch van Beijnum
- Date: Sat Jan 25 19:09:41 2003
On Sat, 25 Jan 2003, Christopher L. Morrow wrote:
> > 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)
It seems the flow recognition isn't that strict but I might just have
> > 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.
Lovely when others decide what you require.
> > 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...
CPE for T1 would be 2500, T3 3600, OC3 7200 or some such. All are fine
for day-to-day stuff but don't pack enough power to handle today's
events at line rate. But the difference is small enough that it can be
remedied by simply using faster CPUs. Those were available at the time
the boxes were introduced, but I assume a faster CPU would have
increased the cost price too much.
> never mind dsl/dial/cable customers, eh?
Those are slow enough to be done in software easily.
> 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
People are buying GE equipment left right and center too. It doesn't
make much sense to have more computing power in the ethernet chip (GE
over UTP takes a lot of processing power) than in the chip doing the
Maybe its possible to find some middle ground, for instance by doing
some basic flow recognition and rate limiting in hardware but the actual
routing in software. That way, you can build a GE CPE router that can do
100 kpps which is enough for regular traffic but still have some
protection when there is a 1.4 Mpps DoS attack which would otherwise
have killed the CPU.
> > 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?
Good point. The reason it's there is that I didn't know what I was
dealing with when I enabled this logging and I wanted to see the MAC
addresses in case the source IP addresses were spoofed.