That's really weird. I've been running with route-map nachiworm permit 10 match ip address nachilist match length 92 92 set interface Null0 ip access-list extended nachilist permit icmp any any echo permit icmp any any echo-reply ip policy route-map nachiworm on transit interfaces and the virtual-templates of all our access servers that can do it properly (just blocking echo/echo-reply on the older ones that can't do the policy) and haven't heard about any customer complaints other than "I can't ping" in the places where we've blocked all echo/echo-reply. The routers doing this (7200/7500)'s are all running 12.2(1-3)S. Access servers are running mostly 12.1M or 12.2XB code. On Fri, 12 Sep 2003, William Devine, II wrote:
I had the exact same problem. As soon as I turned it on, within minutes I had customers calling that could no longer FTP into Win2k servers and some that couldn't SSH into their Linux servers. I've since turned it off as well. Are there any other known ways to block this?
----- Original Message ----- From: "Chris Adams" <cmadams@hiwaay.net> To: "Steven M. Bellovin" <smb@research.att.com> Cc: "Nanog" <nanog@nanog.org> Sent: Friday, September 12, 2003 1:32 PM Subject: Re: 92 Byte ICMP Blocking Problem
I don't have it in place anymore (because it caused more problems than it fixed), so I can't test this. In any case, the route map only matched 92 byte ICMP echo and ICMP echo-reply packets, which is not what PMTU uses, so it shouldn't have had a problem. Also, I know that the MTU along the path for the person in the office is the same all the way, so PMTU shouldn't come into play there.
---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________