From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Sat Sep 25 21:56:30 2010 Date: Sat, 25 Sep 2010 21:57:53 -0500 Subject: large icmp packet issue From: fedora fedora <fedorafans@gmail.com> To: nanog@nanog.org
I am having problem getting ping to work to a specific destination host when using large size icmp packet and i am hoping someone here can offer some suggestion.
With regular ping, i can ping this remote host without any problem, but if i crank up the packet size to above 1500 (1500 still works), i won't get any icmp reply.
My first thought was this was a pmtu issue. but when I ran tcpdump on this remote host, i saw the incoming ping requests and this host actually sent back icmp replies, so it appears that there is some device in between blocking these large size icmp reply packets.
Here is the question, how can i find out which hop on the path is causing this behavior?
Did you consider doing a traceroute? And then pinging the intermediate machines? with the big packets, that is. you'll get a response from the 'near side' of the problem, but -not- from any machine on the far side of it. Ping with small packets first, to discovr machines that dont respond to pings at all.
Thanks, the thing is How can i be sure even if a device blocks my ping , it might have policy blocking ping at it at all. On Sat, Sep 25, 2010 at 10:18 PM, Robert Bonomi <bonomi@mail.r-bonomi.com>wrote:
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Sat Sep 25 21:56:30 2010 Date: Sat, 25 Sep 2010 21:57:53 -0500 Subject: large icmp packet issue From: fedora fedora <fedorafans@gmail.com> To: nanog@nanog.org
I am having problem getting ping to work to a specific destination host when using large size icmp packet and i am hoping someone here can offer some suggestion.
With regular ping, i can ping this remote host without any problem, but if i crank up the packet size to above 1500 (1500 still works), i won't get any icmp reply.
My first thought was this was a pmtu issue. but when I ran tcpdump on this remote host, i saw the incoming ping requests and this host actually sent back icmp replies, so it appears that there is some device in between blocking these large size icmp reply packets.
Here is the question, how can i find out which hop on the path is causing this behavior?
Did you consider doing a traceroute?
And then pinging the intermediate machines? with the big packets, that is.
you'll get a response from the 'near side' of the problem, but -not- from any machine on the far side of it.
Ping with small packets first, to discovr machines that dont respond to pings at all.
How can i be sure even if a device blocks my ping , it might have policy blocking ping at it at all. Correct in a lot of cases and that is why icmp should not be used by itself when diagnosing issues.
I am having problem getting ping to work to a specific destination host when using large size icmp packet and i am hoping someone here can offer some suggestion. With regular ping, i can ping this remote host without any problem, but if i crank up the packet size to above 1500 (1500 still works), i won't get any icmp reply. My first thought was this was a pmtu issue. but when I ran tcpdump on this remote host, i saw the incoming ping requests and this host actually sent back icmp replies, so it appears that there is some device in between blocking these large size icmp reply packets. It is possible that the MTU for interface facing you and interface facing away from you are different on some middle hop. It is interesting that you state the packet size to be >1500, are you talking about jumbo frames? (and do you mean frame size, not packet size?)
Here is the question, how can i find out which hop on the path is causing this behavior? Robert is correct. You need to use traceroute, or alter the TTL values when you send the icmp requests. By setting dont-fragment and varying ttl & frame sizes, you should find your issue.
participants (3)
-
fedora fedora -
Heath Jones -
Robert Bonomi