after upgraded to MPLS backbone -- urgent !!!!!!!!

Unanswered Question
Jul 25th, 2007

After my ISP upgrade their backbone to MPLS we have a internet brower issue wide across my LAN. Some PCs can not brower internet, but some PCs in the same segment can!!!

I do a NAM trace found a HTTP error

" IP packet size limited during capture: HTTP truncated".

Later we tried decrease local pc MTU to 500 it works, they can brower the site which do not open previouly. But still the problems is some PCs local MTU setting is 1300 is working fine ???!!

I really confused?? Is it a MPLS issue or it is my local router setting? Since I have not make any change on my site recently?

Need your help.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
pija Wed, 07/25/2007 - 13:58

MTU on Ethernet interfaces should be increased to 1500 + 4 for each MPLS label. Usually 1512 should be fine.

Some web sites might be protected with firewalls which set DF flag and do not allow fragmentation.

Try to do an extended ping with sweep size from a router towards Internet to probe what is the maximum allowed MTU in your network.

mheusing Thu, 07/26/2007 - 02:56


The proper approach in a MPLS network is to adjust interface MTUs to allow for the additional label overhead as described in the previous post.

A second approach for TCP is to use the "ip tcp adjust-mss " command on router interfaces. The router will then set the Maximum Segment Size during TCP session setup. Thus usually no MTU adjustment in endsystems is required. You might want to try different MSS values to find the largest one not causing issues.

Hope this helps! Please rate all posts.

Regards, Martin

rico_hao40 Thu, 07/26/2007 - 05:21

Thanks for reply.

This command resoved my problem"ip tcp adjust-mss 1400" .

I do some test this morning and found the maxmim MTU a PCs is 1480 and if I set higher like 1490 is do not work.

I want to know is any configure on MPLS network related to this setting ??? Before I call my ISP I need confirm this


pija Thu, 07/26/2007 - 05:53

There are two settings:

1. You can set up MTU on an interface and all packets will have increased MTU.

2. Use MPLS MTU thus only MPLS packets will have a higher MTU.

Anyway in MPLS enabled network you should always increase MTU on switches. I heard about a similar case when sobe web sites were unreachable and adjusting MTU was a solution.

An additional question is how this MPLS network is bult? Are there any pseudo-wire links?

mheusing Fri, 07/27/2007 - 03:29


Usually an ISP sets up his network to deliver 1500 Bytes as MTU for customers end-to-end. You can find the restricting part of the network by using pings with DF bit set to various destinations. Example: ping from a workstation to your local CE and check MTU, then ping to remote CE with same settings or ping CE to CE. If inside your network 1500 bytes are ok, but f.e. CE to CE fails, you should contact your ISP with your results.

Be aware, that on MS workstations the command should look like "ping -f -l 1472 ", as the headers are not counted in size. The above command will generate a 1500 Byte IP/ICMP packet. Vary the size until you get the maximum value allowing you to successfully ping the destination to find MTU.

Hope this helps!

Regards, Martin

vital-group Thu, 11/01/2007 - 09:16


I work for an ISP we did the same thing as your ISP, implemented MPLS on the network and some of our customer started experiencing the same problem as you described. Am trying to simulate the problem by connecting a PC to our MPLS lab but failed to do so. Even after changing the MTU size on my PC to 1500 i cann't simulate the problem. Any suggestion

why this is working. Your suggestion will be much appreciated

william.caban Fri, 11/02/2007 - 09:50

When there are MTU issues, the reason why some machines will have access and not others are severals.

- The OS version: newer OSes have the tcp pmtu discovery on by default

- The best way to do a test for MTU issues is with pings and the DF bit set up (with the -f in Windows or "-M do" in *nix)

You can use the "ip tcp adjust-mss " but me, as a customer, would not accept it.

There are numerous discussions and examples on why not to accept MTU < 1500 for an enterprise. Most people can live with micro MTUs and most of us do (i.e. in our broadband connections).

Each time you have to encapsulate your traffic (i.e. MPLS, GRE, IPSec, L2TP) you will be forced to reduce the effective MTU. Now, if you, as an enterprise, have an MTU < 1500, you will start subtracting from it and the smaller the MTU the grater the overhead in bulk transfers. It is quite complicated to explain, but you will be experiencing and effective bandwidth loss for your bulk transmissions. (See NANOG discussions in this issue as well as numerous reports in ACM/IEEE Transaction of Networking)

Finally, since not all third party devices support the MSS adjustment, the carrier will be forcing some customer to upgrade their infrastructure. Not everyone will have the means to upgrade their infrastructure because the carrier decides to change something.

Hope this give you some ideas.


vital-group Tue, 11/06/2007 - 13:27

Hi William

Thanks for your reply its much appreciated. When i simulated the environment i disabled the tcp pmtu discovery on the server and host. Even after then the client managed to transfer files via the mpls cloud. I believe when you disable the pmtu discovery the MSS is adjusted to an minimum value (mss 540), this is why the client can transfer file via mpls network without packets getting dropped. As you have mentioned some third party devices does not support the mss adjustment. This may be why some clients were experiencing the problem as they were sending packets too large for the network to send without fragmentation. William do you know of any way of adjusting the MSS on a client so that i can simulate the problem. It seems like on windows MSS is based on the mtu size on the NIC.


william.caban Wed, 11/07/2007 - 08:10

You may try Dr.TCP, if I'm not wrong it has a way to setup the MSS and other parameters on Windows machines.

There is a tool named mtutrace (or tracemtu) which is also good for troubleshooting MTU issues from Windows machines. (I don't use Windows so I don't have these tools with me, but you can Google for them.)



This Discussion