MPLS MTU Issue with PA-FE-TX

[flymen331]

Dear All,

I got an ethernet backbone that do not support jumbo frame. The backbone connected my Cisco7206/NPE-G2 and Cisco7507 on each side.

The topology as below:

Cisco7206-Gi0/1<---Ethernet--->Cisco7507-F5/1/0.50 (I am using 802.1q sub-interface)

The config as below:

------------------------------

interface GigabitEthernet0/1

bandwidth 4000

ip address 10.86.40.2 255.255.255.252

no ip redirects

no ip proxy-arp

ip ospf network point-to-point

ip ospf cost 10

ip ospf mtu-ignore

load-interval 30

duplex full

speed 100

media-type rj45

negotiation auto

mpls label protocol ldp

mpls ip

mpls mtu 1508

end

!

interface FastEthernet5/1/0.50

encapsulation dot1Q 50

ip address 10.86.40.1 255.255.255.252

no ip redirects

no ip proxy-arp

ip ospf network point-to-point

ip ospf cost 10

ip ospf mtu-ignore

mpls label protocol ldp

tag-switching mtu 1508

tag-switching ip

end

!

interface FastEthernet5/1/0

description Trunk

no ip address

load-interval 30

full-duplex

end

------------------------------

The problem is when i using "ping vrf NM_TEST x.x.x.x size xxxx", the maximum size can only up to 1498byte. I have increase all of my switchs MTU to 1530, but also cannot ping with 1500byte. Is there any way can help to solve the problem?

Thanks for your kindly help!

Regards

[Giuseppe Larosa]

Hello Sam,

if I remember correctly this type of PA has limitations when speaking of MTU.

the command mtu with size greater then 1500 is not supported.

You should use a PA-2FE if you have one

Hope to help

Giuseppe

[Mohamed Sobair]

Hi,

Because of the Jumbo Frames, you should configure the (MPLS MTU = 1514) including SRC/DEST mac.

At (FastEthernet5/1/0.50), you should add/include another 4Byte for dot1q tag , so the result would be (1518) for the MPLS MTU.

HTH

Mohamed

[flymen331]

Thanks all!

But if my backbone can only support MTU 1500byte(not including 14byte ethernet header), is there is any way can make my MPLS-VPN network to support standard IP MTU 1500byte? I think fragmentation is needed.

[Giuseppe Larosa]

Hello Sam,

unfortunately an MPLS frame cannot be fragmented.

you can only reduce mtu on the client lan side like it is done when using ipsec or ipsec+gre.

Hope to help

Giuseppe

[Mohamed Sobair]

Hi Giuseppe,

I agree with you the MPLS label (Sham) is not fragmented, However , when MPLS label inserted between L2 and L3 headers the Packet is increased and would therfore requires the MPLS MTU to be increased to avoid packet fragmentation.

If he cant increase the MPLS MTU , then he would need to decrease the (IP and Layer-2 MTUs)

Am i correct?

HTH

Mohamed

[Giuseppe Larosa]

Hello Mohamed,

your understanding is correct and the only viable option in this case is to have smaller IP packets on the lan side near the users like for example it is done for a remote branch using ipsec/gre tunnels or with pppoE.

the impact is also on the central site and here may come the problems: the customer likely will complain of this.

Hope to help

Giuseppe

[jdparedes]

hi,

i thingh you have could add an gigaethernet to 7500 and set mtu 2000, because fastethernet work only an 1500 mtu

[mohammedmahmoud]

Hi,

Please allow me to step in, I have a couple of comments; the PA-FE-TX and the MTU issue was solved with certain IOS codes (the mtu could be set up to 1530), however the mpls mtu command should do the trick for you if the interface mtu is not user settable, now all you need to do is to accommodate all the overheads allover your path. Regarding MPLS and fragmentation, MPLS with IP payload is fragmented (unless the DF bit is set), while AToM packets can only be fragmented on the ingress PE routers but not on the intermediate P routers.

I hope that I've been informative.

HTH,

Mohammed Mahmoud.

[Mohamed Sobair]

Mohammed,

On what basis you are saying that in AToM the packet is fragmented in the ingress PE ONLY??

On the other hand, what 1530 MTU represent here?

could you clarify more,

Mohamed

[mohammedmahmoud]

Hi Mohamed,

Its all about the implementation, with AToM, VPLS, MPLS TE, MVPN and any relatively new technology that is still being developed and enhanced you must take care about the vendors' implementations and which standards and RFCs is it complying with and to what level. I've seen codes that do fragmentation for AToM and codes that don't, codes that support out of order recovery and codes that don't. But in the end the RFCs and standards are there, whether you are using a code that supports what you need or not is your call.

Well, taking the AToM fragmentation and reassembly for example, I quote from "RFC 4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly" : "Fragmentation takes place in the transmitting PE immediately prior to PW encapsulation, and reassembly takes place in the receiving PE immediately after PW decapsulation.", in brief it uses the B and E bits in the control word as well as the sequence number, and since the control word is imposed on the ingress PE and then processed on the egress PE, thus the ingress PE would be capable of fragmentation and the egress PE would be capable of reassembly, again its all about the code you are running.

Now to the 1530 MTU point, again I'll take an AToM case (more specifically EoMPLS), the Core MTU must be equal or greater than the summation of: Edge MTU (1500:IP) + Transport Header (14:Ethr + 4:assuming dot1q) + Control Word (4) + MPLS Label Stack (4:LDP + 4:VC), which gives a total of 1530. I believe that the reason behind choosing the value of 1530 in the new codes lies in the fact that it is the most common highest MTU seen in practice, although a value of 1534 is required if EoMPLS VLAN + TE FRR is used, but anyway the MPLS MTU is user settable up to 1580.

I hope that I've been informative.

BR,

Mohammed Mahmoud.

[shivlu jain]

Cisco 12.4(20)T train has been launched which supports MTU of 1600 bytes on FE ports.

regards

shivlu jain

[flymen331]

Hi all,

My MTU issue has been solved. But I found something strange. Actually the problem was not caused by the link, it is related to PA-FE sub-interface. Below two scenario may demonstrate that.

Scenario 1 TOP:

PE1(Gi0/1)<----->(Fa5/1/0.100)PE2(Fa5/1/0.101)<----->(Gi0/1.201)PE3<----->PE4

Scenario 2 TOP:

PE1(Gi0/1)<----->(Gi0/1)PE2(Gi0/2)<----->(Gi0/1.201)PE3<----->PE4

In scenario 1 PE2 connected to PE1 and PE3 both with PA-FE sub-interface. In PE2, I can ping PE4 with 1500byte, that means PA-FE sub-interface can support at least 1522byte MTU. But I cant ping PE4 with 1500byte on PE1. At first, I suspect that was caused by PE1-PE2 link. Unfortunately, although I have increased the link's MTU, the problem has not been solved still. At that time, I was wondering if the problem may be caused by PA-FE restriction. So I replace PE1 Cisco7507 with Cisco7206/NPE-G2, and the problem has been fully resolved after the replacement. Please refer scenario 2 TOP for detail.

My finding is that PA-FE sub-interface inter-switching has some MTU restriction. Am I right?