92 Byte ICMP Blocking Problem

I wonder if it's a Path MTU problem. Can you turn off Path MTU on some
of the affected hosts and see if it solves the problem?

    --Steve Bellovin, http://www.research.att.com/~smb

Once upon a time, Steven M. Bellovin <smb@research.att.com> said:

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?


There were some posts to this list last week about 75xx's dropping
packets outside what was specified in the ip policy route map.

I believe it to be true that all policy route traffic is processor
switched rather than CEF on the 75xx platform. If so, the 75xx might not
be handling all it's being asked to and dropping stuff in a
non-deterministic way.

* james said:

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.


I've been running with the service policy version and haven't seen any
problem either. I did notice that it seems to block DOS traceroutes,


    John Souvestre - Southern Star - (504) 888-3348 - www.sstar.com