How to check who blocks ICMP during MTU path negotiation?

Question

So, if markers are hidden on the map, their sidebar item stays visible. I read through the entire gem, and I didn't see any functionality for also hiding the corresponding sidebar element. Anyone have a clue on this one?

Solution 1

MTU is a link-local issue in terms of 'works' vs. 'doesn't work'. If the machines on both ends are configured to use an MTU appropriate to their specific link, then the routers in the middle should fragment packets as appropriate to get data through. Performance will suffer, but you should get traffic, even if ICMPs are being blocked in the middle.

Of course this won't happen if the routers between have one or more links with a misconfigured MTU, but someone would probably have noticed that before now.

As far as checking where / if ICMP is blocked, I suggest traceroute. If you're using Linux, the most recent version in Ubuntu comes with a moderately detailed description of ICMP blocking related issues, and it should give you a good clue as to where the block is coming from. Since you have access on both sides, you should be able to verify in each direction.

Solution 2

You could use a host on a network with a confirmed MTU of >=1500 (to the public internet, not just on the local link) and send large ping requests or other packets with the DF flag set. With a sniffer like Wireshark on that host, you should see an "incoming ICMP fragmentation needed" packet for every packet you send.

I've had some problems with my DSL provider and some webservers, but it turned out that while my provider was sending the ICMP packets, they were apparently filtered by the webservers or their firewalls. It's apparently common with Amazon Web Services and some of the big CDNs.

Comments

[bogumbiker]

Thanks will give it a try. Is this traceroute specific only to Ubuntu or I can get it on other OS as well?

[Will Dixon]

@bogumbiker It's available pretty much everywhere, including Windows - see en.wikipedia.org/wiki/Traceroute

[Vineet Kasat]

Most modern servers set "don't fragment" -- they do this to enable PMTU discovery, so the routers respond with an ICMP message indicating they must fragment. The answer given above is wrong, or at least severely outdated.

[bogumbiker]

What exactly do you mean by checking network on my end? How to check that this is on my end?

[Slartibartfast]

While my answer possibly has errors (in regards to whether connections will in general work vs. don't work with blocked ICMP packets) (oops), the test I proposed should still be useful. Traceroute from both sides with appropriate options should indicate pretty clearly where / whether there is a machine blocking ICMP packets.

[Slartibartfast]

Since traceroute worked for both directions, you know that not all ICMP is blocked. You can check MTUs using --mtu. The default protocol is UDP, but if you want to do the traceroute itself with ICMP pings, you can add -I (maybe not at the same time as --mtu though)

[Dudo]

Hmmm. Thanks, but that doesn't answer my question. I'm well aware of how to customize the sidebar. The example you show is actually quite outdated. You can now (and should) build everything from the controller - github.com/apneadiving/Google-Maps-for-Rails/wiki/Controller . I'm looking specifically to hide a single entry in the sidebar, if that single marker is hidden from the map.

[dunxd]

In my experience, many ISP have some network equipment which has enough of ICMP blocked to break Path MTU Discovery. I suspect some vendor is shipping equipment with this blocked by default. This results in some ISPs having some routers/switches where PMTUD breaks - dynamic routing makes the problem intermittent. Traceroute and ping used correctly can help you determine where the problem arises.

[Navin]

Some routers don't fragment packets at all since fragmenting is so slow.