Hello Graham.
Graham Bleach <graham@???> wrote:
> 2009/4/20 Nick Chalk <nick@???>:
>> I'm trying to test methods of mitigating packet
>> flood attacks on Cisco routers, but I'm having
>> trouble with my control test. Despite pushing
>> the 7200 to 100% CPU load, I can't seem to
>> cause much in the way of denial of service -
>> BGP sessions stay up, and it still responds to
>> telnet.
> Are you pinging an address on the router?
I've tried both flooding the router's address, and
a host behind the router.
Until I tried Hugo's suggestion, I couldn't cause
degradation of service with either method. In fact
routing a high rate of very large packets caused a
lower processor load (~25%) than receiving them.
Re-assembly overhead, perhaps?
> Not sure where this fits into the scheduler
> priority on Ciscos; I have been told that
> responding to ICMP echos for a local interface
> address is a lower priority than routing
> traffic, although I can't currently find a
> reference for this.
That can definitely be done, but I think it's a
config option.
It's a bit disconcerting when you see that in
action. Tier 1 carriers use it a lot - you'll see
intermediate routers failing to respond to
traceroute probes, or taking several hundred
milliseconds. That's prioritisation of through
traffic.
> It may be worth testing a ping flood to a
> destination behind the router, to see if this
> makes a difference.
So far, I've only used pktgen targeted at the
router - although that's very effective. I'll also
test how the 7200 handles routing a packet flood,
as that's more representative of real attacks.
> Have you tried many instances of ping -f? I can
> imagine that one single-threaded program would
> be unable to saturate modern links.
Yes, I ended up with three Linux hosts attached to
different router interfaces. One was simulating
another router, with telnet and BGP sessions up,
whilst the other two ran ten instances each of
ping -f with 17.7kB packets. I'm not sure why, but
17.7kB seemed to be the worst case for the Cisco.
> One tool that can reliably saturate reasonably
> high bandwidth links is iperf. I'm not entirely
> convinced it's suitable for simulating a flood
> attack, but it's one of my usual tools for
> network stress testing.
Yes, I played with iperf as well - we use it for
testing link performance, too. Unfortunately,
iperf generates well-behaved traffic, which the
router was quite happy with.
So far, the worst cases for the router seem to be
- A fairly high rate of large packets that need
to be re-assembled.
- A very high rate of small packets.
If I find anything of general interest, I'll post
the results.
Thanks,
Nick.
--
Nick Chalk ................. once a Radio Designer
Confidence is failing to understand the problem.
