Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Hi How does mtu calculation work with L2 VPNs? Sample topology is:


Where and how would you implement MTU calculcation? What will decide how much MTU should be? I have different LSPs running in the MPLS network. Does LSPs have their own MTU and if yes then where do they get this MTU value from?

If I have created a logical L2 interface on top of physical interface, where will i set the mtu? On physical or logical?

Does the mtu calculation also differ based on type of port I have like Sonet/Ethernet/DS3?

Please share your knowledge on this.


share|improve this question

I've attempted the calculation in the past, but to honest these days I use ping -f -l and keep increasing till it returns a fragmentation error. This is generally pretty reliable, though I have my suspicions that sometime intervening routers sometimes ignore the DF flag.


share|improve this answer
The is the only reliable way to calculate MTUs, and the way network stacks have always done it. Set "don't fragment" and increase the payload size until the packet gets bounced. – tylerl Dec 9 '10 at 6:41

In my experience with site-to-site VPN connections, the most important thing is that the two tunnel peers have the same MTU. Depending on vendors, this tends to cause some unexpected behaviors otherwise.

Wikipedia's page on MTU has a pretty good explanation of MTU.

  1. Packets get sent with the senders MTU originally
  2. If any node on the way has a lower MTU it will send an ICMP package back saying that the datagram is too big, asking politely to split the packet up.
  3. If ICMP is blocked (by a firewall f.e.) the packet size isn't changed and the data might get dropped.

Ping is a very useful tool in checking for MTU sizes.

ping -M do -s 1500 <host/ip>

This will send a packet with a specific size to the host and prohibit any fragmentation. If MTU is 1500 the entire way, you will get a response. If it is lower somewhere, you will not. Then simply lower the '-s' variable until you find an acceptable value.

As a work around in VPN situations, you can lower your MTU to this value and see if it helps.

share|improve this answer
  1. If the CE to PE link is a dot1Q trunk and assuming a L3 payload of X bytes , the L2 frame reaching PE will have size of

X + 6+6+2+4+4 = X + 22

If the CE-PE links is an access port it will be

x + 6+6+2+4 = X + 18

Here is the breakup

S-MAC - 6 D-MAC- 6 Type - 2 FCS -4 Dot1q TAG 4

Now for MPLS l2 VPN if the PEs are not back to back , It will need 2 labels which adds 4 + 4 byte (In back to back PE need just oone label)

VC label - 4 byte IGP-PE label 4 byte

Hence the total overhead added to the Original packet x of x byte across the across the MPLS cloud is X + 30 (dot1Q CE-PE , two label senario)

share|improve this answer

Have you tried setting up a machine that uses known PMTU ( and figuring it out from there?

Worst case scenario, work your way up by hand.

share|improve this answer

I agree with JR...

Be aware that if you implement something with encryption later, the packets can grow and cause fragmentation which won't work with encryption. Then you'll have packets disappearing into never never land. Find the breaking point and then give yourself a little room.

share|improve this answer

Your Answer


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