With CEF, Null0 is a special CEF adjacency - not a CPU interface. So packets black holed to Null0 with "no ip unreachables" turned on the Null0 interface will be get dropped in CEF (on the LC if it is dCEF). For example: interface Null0 no ip unreachables ! ip route <dest to drop> <mask> Null0 ! If you still want to reply to ICMP unreachables, set the "ip icmp rate-limit unreachable" from 500ms to something higher (see below for docs on this feature). On the GSR, "no ip unreachables" did not work until just a few weeks ago. We committed a fix into 12.0(16.5)S (which will be synced into 12.0ST). Barry ----------------------------------- ICMP Unreachables Rate-Limiting ------------------------------ We do have a feature to rate-limit the ICMP Unreachables. The DDTS used to track this is: CSCdp28161 - ICMP error generation rate should be configurable The default is to rate-limit ICMP Unreachables to one per 500 milliseconds since 12.0(8)S. Some people think that this should be set to 1 or 2 seconds. Here are the docs for this feature: A new UI command is introduced to control the icmp unreachable error msg rate. To configure the rate of the icmp unreachable error messages generated, use the ip icmp rate-limit unreachable command. To not rate limit the icmp unreachable error messages, use the no form of this command. ip icmp rate-limit unreachable [DF] <1-4294967295 millisecond> no ip icmp rate-limit unreachable [df] Syntax Description DF to rate limit the icmp unreachable message with code 4, fragmentation needed and DF set. milliseconds rate limit to one message within this milliseconds. Default Both icmp unreachable DF and the rest of icmp unreachable are rate-limited to one per 500 milliseconds. Command Mode Global configuration Examples The following example sets the rate of the icmp unreachable to one message per 10 milliseconds. ip icmp rate-limit unreachable 10 The following example sets no ip icmp rate-limit unreachable DF no rate-limit on the icmp unreachable DF.
-----Original Message----- From: owner-nznog(a)list.waikato.ac.nz [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of James Tyson Sent: Friday, April 06, 2001 6:51 PM To: David Robb Cc: nznog(a)list.waikato.ac.nz Subject: DDOS Attacks, etc.
As people might be aware, adding routes to null0 isn't the most effective way sometimes of dropping flood traffic. Sending it to an IP address, and then staticly associating a bogus mac address to that IP is often better - the router simply forwards the packet out onto the lan, and the ethernet swallows it. This puts less load on the router.
This is because Cisco Routers process switch packets to null0, because it is a CPU interface and not a physical interface. I would suggest that we should all place feature requests with our local Cisco vendor (Logical/Datacraft/Cisco Themselves/whatever). If we all place some pressure on Cisco then we might actually see something done about it. I have seen comments about this on NANOG, so I am sure that the feature request has been placed, but it's probable that Cisco are working with their usual latency to industry requests (ie a committee to form a working group to plan the implementaion of the project brief to be delivered to a team of IOS developers for peer-review, which will then prepare a report to return to the working group, which will then liase with Marketting and do a cost-benefit analysis before eventually deciding to implement it - geez, does this sound like ISOCNZ to anyone else?).
David's idea about BGP seems like a good one, however, and one that we should be looking into.
Also, anyone with the inclination to set up MBGP peering over APE or WIX please contact me at: james.tyson(a)attica.co.nz
Cheers.
James Tyson --- Samizdat New Media Solutions
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog