|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Refusing Pings on Core Routers??? A new trend?
On Thu, 19 Oct 2006, Jeremy Chadwick wrote: No, that is not neccessarily true. I know of at least one vendor that punts all ICMP (on certain versions of their HW) to CPU, and the CPU is normally not otherwise involved in packet forwarding, so seeing latencies on ICMP (perhaps due to some housekeeping going on) doesn't at all mean other packets are being delayed. It might, of course.I am absolutely fine with ICMP being prioritised last, but those scenarios induce more questions; "so ICMP is prio'd last, which would mean the router is busy processing other packets, which could mean your router is over-utilised either CPU-wise or iface-wise since we're seeing 250ms at your hop and beyond". 48 hours later, Then we also have the problem of people not understanding how traceroute works, ie sending UDP with low TTL going one way, then getting ICMP back, with the router expiring the TTL and generating the ICMP TTL-exceeded message, perhaps having to punt this to CPU first, or perhaps processing it on a linecard. To understand what you're seeing really means, you have to know all platforms involved in all hops both going there and back (return path perhaps being asymmetrical to the path you're seeing in traceroute). But to your question regardnig filtering, I'd venture to guess that more and more people are going to filter access attempts to their infrastructure to hinder DoS attacks. If I were to build a brand new network today I'd use loopbacks and link addresses that I'd either filter at the border or not announce on the internet at all. Not announcing it at all of course brings the problem of people using "uRPF loose" and dropping these packets, which will break traceroute and other tools. Better might of course be to rate-limit traffic to the infrastructure addresses to a very low number, let's say 2 megabit/s or so. This will limit DoS attacks and break diagnostics during an attack, but will make traceroute work properly during normal conditions. Guess everybody have to make up their mind regarding these prioritizations when designing their networks. It's important to be aware of all aspects of course, and it's good we have these discussions so more people understand the ramifications. Anyone know of a document that describes this operationally? This would be a good thing to include in an "ISP essentials" type of document. -- Mikael Abrahamsson email: [email protected]
|