RE: 92 Byte ICMP Blocking Problem
When I checked last week 1 in 4 packets was an ICMP message, so we rate limited ICMP ECHO and ICMP ECHO-REPLY messages.. And it only bugged PING'ers and windows traceroute users.. All those low memory alarms are now no longer plaguing our NMS. Mark -- Mark Segal Director, Network Planning FCI Broadband Tel: 905-284-4070 Fax: 416-987-4701 http://www.fcibroadband.com Futureway Communications Inc. is now FCI Broadband -Original Message- From: John Souvestre [mailto:[EMAIL PROTECTED] Sent: September 13, 2003 11:53 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: 92 Byte ICMP Blocking Problem Hi. 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, however. John John Souvestre - Southern Star - (504) 888-3348 - www.sstar.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, September 13, 2003 10:18 PM To: William Devine, II Cc: Nanog Subject: Re: 92 Byte ICMP Blocking Problem Importance: High 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.
Re: 92 Byte ICMP Blocking Problem
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 [EMAIL PROTECTED] To: Steven M. Bellovin [EMAIL PROTECTED] Cc: Nanog [EMAIL PROTECTED] 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 [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 92 Byte ICMP Blocking Problem
Hi. 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, however. John John Souvestre - Southern Star - (504) 888-3348 - www.sstar.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, September 13, 2003 10:18 PM To: William Devine, II Cc: Nanog Subject: Re: 92 Byte ICMP Blocking Problem Importance: High 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.
92 Byte ICMP Blocking Problem
We started blocking 92 Byte ICMP packets on our ingress points on our core backbone routers. This was a recommendation from Cisco to help mitigate the effects of the Nachi worm. Since then, we have been hammered with customer complaints concerning the inability to talk to mail servers and ssh to their servers, as well as other weird network issues, all centering around the time we started blocking 92 Byte ICMP packets. Has anyone else seen this, and if so, is the only resolution to stop the blockage of 92 Byte ICMP Packets..? Thanks Richard
Re: 92 Byte ICMP Blocking Problem
Once upon a time, Richard J.Sears [EMAIL PROTECTED] said: Since then, we have been hammered with customer complaints concerning the inability to talk to mail servers and ssh to their servers, as well as other weird network issues, all centering around the time we started blocking 92 Byte ICMP packets. Has anyone else seen this, and if so, is the only resolution to stop the blockage of 92 Byte ICMP Packets..? Yes. As soon as we put the policy route map in place, we had some people unable to talk via SSH, SMTP, or POP3. It was random: one person here in the office couldn't SSH to a particular server. He could SSH to other servers, and the rest of us could SSH to the server he could not. We had similar experiences with SMTP and POP3. When we took the policy route map back out, the problems went away. This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy route map on the FE interface linking this router to the POP core router; this router has MC-T3 interfaces and ethernets to Ascend TNTs and such. The intent was to stop the 92 byte ICMP echos from reaching the Ascend TNTs, since several of them were rebooting constantly. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
Once upon a time, Steven M. Bellovin [EMAIL PROTECTED] said: In message [EMAIL PROTECTED], Chris Adams writes: Yes. As soon as we put the policy route map in place, we had some people unable to talk via SSH, SMTP, or POP3. It was random: one person here in the office couldn't SSH to a particular server. He could SSH to other servers, and the rest of us could SSH to the server he could not. We had similar experiences with SMTP and POP3. When we took the policy route map back out, the problems went away. This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy route map on the FE interface linking this router to the POP core router; this router has MC-T3 interfaces and ethernets to Ascend TNTs and such. The intent was to stop the 92 byte ICMP echos from reaching the Ascend TNTs, since several of them were rebooting constantly. 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? 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. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
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? william - Original Message - From: Chris Adams [EMAIL PROTECTED] To: Steven M. Bellovin [EMAIL PROTECTED] Cc: Nanog [EMAIL PROTECTED] Sent: Friday, September 12, 2003 1:32 PM Subject: Re: 92 Byte ICMP Blocking Problem Once upon a time, Steven M. Bellovin [EMAIL PROTECTED] said: In message [EMAIL PROTECTED], Chris Adams writes: Yes. As soon as we put the policy route map in place, we had some people unable to talk via SSH, SMTP, or POP3. It was random: one person here in the office couldn't SSH to a particular server. He could SSH to other servers, and the rest of us could SSH to the server he could not. We had similar experiences with SMTP and POP3. When we took the policy route map back out, the problems went away. This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy route map on the FE interface linking this router to the POP core router; this router has MC-T3 interfaces and ethernets to Ascend TNTs and such. The intent was to stop the 92 byte ICMP echos from reaching the Ascend TNTs, since several of them were rebooting constantly. 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? 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. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
Hi Chris, We were having the same exact problem with 4 TNTs that we have. In the end, we shut off ip-route-cache on the TNTs and that fixed the problem with them. Richard On Fri, 12 Sep 2003 12:52:58 -0500 Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Richard J.Sears [EMAIL PROTECTED] said: Since then, we have been hammered with customer complaints concerning the inability to talk to mail servers and ssh to their servers, as well as other weird network issues, all centering around the time we started blocking 92 Byte ICMP packets. Has anyone else seen this, and if so, is the only resolution to stop the blockage of 92 Byte ICMP Packets..? Yes. As soon as we put the policy route map in place, we had some people unable to talk via SSH, SMTP, or POP3. It was random: one person here in the office couldn't SSH to a particular server. He could SSH to other servers, and the rest of us could SSH to the server he could not. We had similar experiences with SMTP and POP3. When we took the policy route map back out, the problems went away. This is with IOS 12.0(25)S1 on a 7513 doing dCEF. We put the policy route map on the FE interface linking this router to the POP core router; this router has MC-T3 interfaces and ethernets to Ascend TNTs and such. The intent was to stop the 92 byte ICMP echos from reaching the Ascend TNTs, since several of them were rebooting constantly. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
Once upon a time, Richard J.Sears [EMAIL PROTECTED] said: We were having the same exact problem with 4 TNTs that we have. In the end, we shut off ip-route-cache on the TNTs and that fixed the problem with them. We were only seeing it on some of our TNTs for some reason. I didn't turn the route cache completely off, but I did limit the size, and that solved it for us. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: 92 Byte ICMP Blocking Problem
There were some posts to this list last week about 75xx's dropping packets outside what was specified in the ip policy route map. -- James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday Phone support 365 days till 10 pm via the Santa Fe office: 505-988-9200 or Toll Free: 888-988-2700
Re: 92 Byte ICMP Blocking Problem
So, the choice is to go from dCEF to CEF or to not block the 92 byte packets at allanyone have an idea as to which is the better route to take..? - Richard On Fri, 12 Sep 2003 10:59:54 -0700 Matt Ploessel [EMAIL PROTECTED] wrote: See http://www.cisco.com/warp/public/707/cisco-sn-20030820-nachi.shtml The policy-routing solutions works great in small routers (26xx, 17xx) and in 7200s. In 7500s it seems OK *UNLESS* dCEF is enabled, then it does what you saw. I'm assuming it's dropping 92-byte TCP packets as well as the ICMP echoes. You can see 1-packet flows of mail getting dropped. Notice that the workaround cannot be used on GSRs because it causes packets to be punted to the CPU... this is as bad a news as that it doesn't work right on dCEF because we use GSRs or 7500s with dCEF where the network is really busy. - Matt Ploessel -Original Message- From: Richard J.Sears [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2003 10:43 AM To: Nanog Subject: 92 Byte ICMP Blocking Problem We started blocking 92 Byte ICMP packets on our ingress points on our core backbone routers. This was a recommendation from Cisco to help mitigate the effects of the Nachi worm. Since then, we have been hammered with customer complaints concerning the inability to talk to mail servers and ssh to their servers, as well as other weird network issues, all centering around the time we started blocking 92 Byte ICMP packets. Has anyone else seen this, and if so, is the only resolution to stop the blockage of 92 Byte ICMP Packets..? Thanks Richard ** Richard J. Sears Vice President American Digital Network [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax I fly because it releases my mind from the tyranny of petty things . . Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching.
