I have a server mike at our office communicating with a remote server through a VPN. There have been various problems which seem to be linked to the MTU size. Mike is a RHEL 3 server and the customer server is CentOS 5. I used the tracepath tool to attempt to find the max MTU and got this weird result

[root@mike root]# tracepath
 1:  mike (                                  0.170ms pmtu 552
 1:  mike (                                  0.011ms pmtu 552
 1:  mike (                                  0.010ms pmtu 552

snip - thousands of lines of the same output

 1:  mike (                                  0.025ms pmtu 552
 1: (                        0.405ms
 2: (                        0.876ms
 3: (                         97.1000ms reached
     Resume: pmtu 552 hops 3 back 3

From another server at our office to a different customer I get a far more reasonable looking result

[root@nora ~]# tracepath
 1:  nora (                                0.080ms pmtu 1500
 1: (                      asymm  2   0.813ms
 2:  no reply
 3: (                           73.210ms reached
     Resume: pmtu 1500 hops 3 back 3

So I think it is something to do with mike rather than the routers, firewalls or VPN inbetween. Any ideas?

In response to Daniel Lawson's answer below, here is why I believe that the problem is server mike as nora is able to get the right response

[root@nora ~]# tracepath
 1:  nora (                                0.101ms pmtu 1500
 1: (                      asymm  2   0.863ms
 2:  no reply
 3: (                        111.601ms reached
     Resume: pmtu 1500 hops 3 back 3

In response to Mike Pennington's comment both and are firewalls. The default gateway is which then has a static route for these customers to send the traffic to As they are on the same network I assume that is why the hop count isn't incremented.

  • what are and attached to? mike or another device? still shows up at TTL=1, so I'm not sure how this is happening yet – Mike Pennington Jun 3 '11 at 11:58

From what you've said, the path from the server "mike" to one customer is limited to 552, and a different path, from "nora" to a different customer, is not limited.

You're not comparing the same path, so unless there's more information then I doubt this is specific to the server "mike". The PMTU is the constrained MTU along the path, so if this was specific to mike then it should happen to any machine you tracepath to.

Given that you're using VPN connections, it's not really surprising that you're seeing a constrained PMTU though. I'd check the MTU settings for the VPN configuration to the first customer, and I'd also try checking the MTU direct to the customer's VPN end point (eg, the public IP address that terminates the VPN). One or the other of those is likely to have your answer.


It's quite common from Firewall and VPNs from different vendors - e.g. checkpoint to reduce the MTU below 1500 for some types of traffic.

  • 1
    That wouldn't explain whay it works for one server but not another. There are Juniper SRx firewalls at each end. – mmcg Jun 3 '11 at 11:04
  • Reduced from 1500 might be common, something like 1468 or at least something near 1500, 552 is definitely a strange number, not common at all. – Chris S Jun 3 '11 at 12:29
  • By default the SRX will have an MTU for the tunnel interface of 9192. However, typically people reduce this or set the TCP-MSS option for IPSEC tunnels so devices negotiate down. I actually just learned about this the other day. Setting the TCP-MSS setting to 1350 seemed to cure most of my fragmentation headaches without having to mess with the MTU of the tunnel interface itself. – SpacemanSpiff Jun 3 '11 at 13:37
  • I have the tcp-mss set to 1350 already on both sides. I've tried changing it in the past but didn't seem to make a difference. I'm thinking it is something on the server mike as the mtu and output of the tracepath command is so weird. – mmcg Jun 3 '11 at 14:07

If you have a Windows machine handy you can run mturoute in traceroute mode to determine which link/hop has the low MTU.


  • C:\>mturoute.exe * ICMP Fragmentation is not permitted. * * Speed optimization is enabled. * * Maximum payload is 10000 bytes. * + ICMP payload of 1472 bytes succeeded. - ICMP payload of 1473 bytes is too big. Path MTU: 1500 bytes. – mmcg Jun 3 '11 at 14:17

i think the issue is related to juniper not returning an MTU value in the ICMP Unreachable packet that is part of the PMTUD. i've seen similar issue before with juniper

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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