Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
add comment

4 Answers

up vote -2 down vote accepted

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.

share|improve this answer
    
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 3:30
    
@bogumbiker It's available pretty much everywhere, including Windows - see en.wikipedia.org/wiki/Traceroute –  Andrew Jul 20 '10 at 4:39
1  
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 6: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 4:24
show 3 more comments

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.

share|improve this answer
add comment

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?

share|improve this answer
    
What exactly do you mean by checking network on my end? How to check that this is on my end? –  bogumbiker Jul 20 '10 at 12:30
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.