3

I am getting MTU problems with connections to my web host provider. The issue is that I am behind ppoe with MTU size set to 1492 which preventing me from using 'scp'. Once changing MTU from 1492 to 1500 the scp works fine however most of other connections do not. Neither web hosting provider nor internet provider confirm blocking of ICMP traffic. Is there any way to check who (which ip on the way) blocks ICMP? Thanks

bogumbiker
  • 87
  • 1
  • 5

4 Answers4

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.

lxgr
  • 563
  • 1
  • 6
  • 18
0

The only real way to determine it is to look at the network traffic on both ends, or at the least look at the traffic on your end. Have you first confirmed you're not the one ignoring them by looking at the network on your end?

Michael Graff
  • 6,588
  • 1
  • 23
  • 36
0

The tools you need are mturoute on windows or tracepath on *nix. Either tool enables you to find the Path MTU between two hosts, and see where the bottleneck is. However, if the problem is that a given hop has ICMP blocked, breaking Path MTU Discovery you'll need to dive a bit deeper to find out where the problem is.

Then of course you have to convince the responsible party to fix their network equipment config.

dunxd
  • 9,482
  • 21
  • 80
  • 117
-2

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.

Slartibartfast
  • 3,265
  • 17
  • 16
  • Thanks will give it a try. Is this traceroute specific only to Ubuntu or I can get it on other OS as well? – bogumbiker Jul 20 '10 at 03:30
  • @bogumbiker It's available pretty much everywhere, including Windows - see http://en.wikipedia.org/wiki/Traceroute – Andrew Jul 20 '10 at 04:39
  • 2
    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. – Michael Graff Jul 20 '10 at 06:04
  • Now I am confused - so how to check where the problem is? – bogumbiker Jul 20 '10 at 12:31
  • 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 Jul 21 '10 at 04:24
  • but the treaceroute from both systems works fine... – bogumbiker Jul 21 '10 at 11:12
  • 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) – Slartibartfast Jul 22 '10 at 03:07
  • 1
    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. – dunxd Sep 19 '13 at 11:36
  • Some routers don't fragment packets at all since fragmenting is so slow. – Navin Jun 05 '16 at 22:24