Hi,

As far as i can say, the problem depends on your access/edge MTU into the MPLS cloud. If the access MTU is 1500 (default) then you'll have to make sure that the internal routers in the cloud can bare this MTU plus the labels overhead.

To troubleshoot MTU related problems you can use extended ping and then use the sweep option with the DF bit set.

HTH, please do rate all helpful replies,

Mohammed Mahmoud.

Thanks for responding! I understand the need to make sure the internal MTU can accommodate the 1500 bytes plus MPLS overhead, so our internal MTU is currently set to 1546.

We are doing that using the "mtu 1546" command, and not the "mpls mtu" command - do you consider that to be a problem? My understanding if you do not use the "mpls mtu" command, that it will use the default MTU or the configured mtu under the interface...?

/shawn

Hi,

You are right the default MPLS MTU is the MTU configured for the interface.

As far as i know PMTUD is implemented when you have an IP sender set the "Don't Fragment" (DF) flag in the IP header. If an IP packet with this flag set reaches a router whose next-hop link has too small an MTU to send the packet without fragmentation, that router discards that packet and sends an ICMP "Fragmentation needed but DF set" error to the IP sender. When the IP sender receives this Internet Control Message Protocol (ICMP) message, it learns to use a smaller IP MTU for packets sent to this destination, and subsequent packets are able to get through.

The PMTU discovery process ends when the host's estimate of the PMTU is low enough that its datagrams can be delivered without fragmentation. Or, the host may elect to end the discovery process by ceasing to set the DF bit in the datagram headers; it may do so, for example, because it is willing to have datagrams fragmented in some circumstances. Normally, the host continues to set DF in all datagrams, so that if the route changes and the new PMTU is lower, it will be discovered.

Kindly check the RFC:

http://www.ietf.org/rfc/rfc1191.txt

I hope that i've been informative, please do rate helpful posts,

Mohammed Mahmoud.

Thanks for that.

Without making this entirely a post about PMTU... back to my initial question; what happens to server PMTUD queries when they hit the PE router? Since the internal Core is "hidden" from the end users, is there any negative impact on server PMTUD queries?

Is there a specific command that needs to be configured on the PE router to accommodate PMTUD - specifically on the customer interfaces?

Thanks again!

Hi,

Here you are the guidelines for Setting MPLS MTU and Interface MTU Values when configuring the network to use MPLS:

When configuring the network to use MPLS, set the core-facing interface MTU values greater than the edge-facing interface MTU values, using one of the following methods:

1.Set the interface MTU values on the core-facing interfaces to a higher value than the interface MTU values on the customer-facing interfaces to accommodate any packet labels, such as MPLS labels, that an interface might encounter. Make sure that the interface MTUs on the remote end interfaces have the same interface MTU values. The interface MTU values on both ends of the link must match.

2.Set the interface MTU values on the customer-facing interfaces to a lower value than the interface MTU on the core-facing interfaces to accommodate any packet labels, such as MPLS labels, than an interface might encounter. When you set the interface MTU on the edge interfaces, ensure that the interface MTUs on the remote end interfaces have the same values. The interface MTU values on both ends of the link must match.

HTH, i hope that i was a bit informative,

Mohammed Mahmoud.