You should keep in mind that Cisco routers have a limit on the number of ICMP messages they will originate per second. (My mind fails me as to whether it is 3 or 30). So you might lose a few ICMPs because of this. David -----Original Message----- From: Stephen J. Wilcox To: Curtis Maurand Cc: Leo Bicknell; nanog@merit.edu Sent: 5/12/03 10:49 AM Subject: Re: PMTU and Broken Servers You mean theres routers which get a large packet and silently drop it rather than return an icmp? Curious as to know which vendors? (read fundementally broken!) Steve On Mon, 12 May 2003, Curtis Maurand wrote:
I've had the problem before. Not all routers handle PMTU correctly.
Curtis
On Thu, 8 May 2003, Leo Bicknell wrote:
I've recently had the pleasure of troubleshooting a problem I don't normally have to deal with, and the results don't quite make sense to me. I'm hoping someone can enlighten me as to what is going on. A diagram:
server---internet---fw---tunnelbox1----tunnelbox2----user
The tunnel between the tunnelboxes is a lower (1480) MTU.
Originally
the user couldn't access some servers, turns out the firewall was filtering ICMP Can't Fragment messages, preventing PMTU from working in the server->user direction (tunnelbox1 would generate Can't Fragement, firewall would filter).
That's been corrected. Going to a server I control I see good PMTU in both directions between the server and the user. However, there are still a number of web servers for popular sites that behave just like the firewall was still filtering Can't Fragments. The theory is that the servers are behind a firewall/load balancer that is filtering them on the server side -- but I find it slightly (emphasis on the slightly) that someone would turn on PMTU discovery, and then filter it out right in front of the boxes where they turned it on. Also, it seems to me most DSL users are behind PPPoE links with lower MTU, and should get hit by the same problem.
The temporary hack is to have tunnelbox1 clear the DF bit on all incoming packets, which just causes the packets to get fragmented going down the tunnel. A minor performance hit, but it works.
This is a new problem to me, but I'm sure people have run into it before. Are the servers really that broken (PMTU enabled, ICMP Can't Fragement filtered)? Does the head end box of DSL services generally do something to work around this (ie, clear the DF bit)? Am I just being an idiot and missing something obvious?
Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ThruPoint, Inc.
At 04:38 PM 12-05-03 -0400, Russell, David wrote: Based on: http://www.cisco.com/warp/public/707/GSR-unreachables-pub.shtml "ip icmp rate-limit unreachable n Where n is the number of milliseconds between two consecutive ICMP unreachable packets. The default value is 500. That means that one ICMP unreachable packet is send every 500 ms." Also specified in: "IP Fragmentation and PMTUD" http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00... which was last updated about 10 days ago and covers everything in this thread so far (other than JunOS :-)) -Hank
You should keep in mind that Cisco routers have a limit on the number of ICMP messages they will originate per second. (My mind fails me as to whether it is 3 or 30). So you might lose a few ICMPs because of this.
David
-----Original Message----- From: Stephen J. Wilcox To: Curtis Maurand Cc: Leo Bicknell; nanog@merit.edu Sent: 5/12/03 10:49 AM Subject: Re: PMTU and Broken Servers
You mean theres routers which get a large packet and silently drop it rather than return an icmp?
Curious as to know which vendors? (read fundementally broken!)
Steve
On Mon, 12 May 2003, Curtis Maurand wrote:
I've had the problem before. Not all routers handle PMTU correctly.
Curtis
On Thu, 8 May 2003, Leo Bicknell wrote:
I've recently had the pleasure of troubleshooting a problem I don't normally have to deal with, and the results don't quite make sense to me. I'm hoping someone can enlighten me as to what is going on. A diagram:
server---internet---fw---tunnelbox1----tunnelbox2----user
The tunnel between the tunnelboxes is a lower (1480) MTU.
Originally
the user couldn't access some servers, turns out the firewall was filtering ICMP Can't Fragment messages, preventing PMTU from working in the server->user direction (tunnelbox1 would generate Can't Fragement, firewall would filter).
That's been corrected. Going to a server I control I see good PMTU in both directions between the server and the user. However, there are still a number of web servers for popular sites that behave just like the firewall was still filtering Can't Fragments. The theory is that the servers are behind a firewall/load balancer that is filtering them on the server side -- but I find it slightly (emphasis on the slightly) that someone would turn on PMTU discovery, and then filter it out right in front of the boxes where they turned it on. Also, it seems to me most DSL users are behind PPPoE links with lower MTU, and should get hit by the same problem.
The temporary hack is to have tunnelbox1 clear the DF bit on all incoming packets, which just causes the packets to get fragmented going down the tunnel. A minor performance hit, but it works.
This is a new problem to me, but I'm sure people have run into it before. Are the servers really that broken (PMTU enabled, ICMP Can't Fragement filtered)? Does the head end box of DSL services generally do something to work around this (ie, clear the DF bit)? Am I just being an idiot and missing something obvious?
Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ThruPoint, Inc.
participants (2)
-
Hank Nussbacher -
Russell, David