I have setup VPLS in our network. We discovered that MTU pass thru is only 1478 bytes end to end (CE to CE). Unlike MPLS VPN, end to end is 1500 bytes which is normal (CE to CE). Is this normal for VPLS or EToM?
As what we experineced before in MPLS VPN, if end to end can't achive 1500 bytes, users will having problem to run application and browsing issue.
It looks like your core MTU is falling short to provide the services keeping customer MTU intact.
Yes this is normal for ATOM or VPLS, as it has more overhead compared to a MPLS VPN.
Check this link to estimate the size.
There are quite some intresting previous topics on MTU, which may be helpful in arriving at the right MTU in the core for your network, so that all your customers L3, ATOM/VPLS get the right 1500 MTU end to end.
Thanks for the reply.
Upon my packet calculation:
Core MTU = 1500 + 18 + 4 + (2*4)
EoMPLS port mode
Core MTU = 1500 + 14 + 4 + (2*4)
I have configured MPLS MTU 2000 acrros my MPLS network. Suppose i can transport 1500 bytes end to end right? as its already enoough to support the overhead.
I also tried increase the int mtu itself, but still 1500 bytes can pass thru.
Make sure that all L2 devices used in the core are also configured to allow jumbo frames.
Here's a reference you can use:
Hope this helps,
Since you mentioned you have configured the MPLS MTU to 2000 is your interface MTU also 2000, as if you configure interface mtu 2000 if will default to mpls mtu also 2000, but vice versa is not true.
As I havent really experienced lesser transmit without lower configured MTU.
Do check and let us know of your observations.
I dont configure my int MTU, only modify the MPLS MTU. This is because along the path we are using POS and default MTU is 4470. But there is one part where my router connected to switch thru Ge int. The int MTU is 1500 but I configured MPLS MTU 2000.
Do I need to increased the physical MTU as well?
It depends on the version of code you are running on your 7600s. Setting the mpls mtu used to suffice but the behavior has changed in 12.2(33)SRA. Please refer to the following document for more details:
Yes, I did aware of this. That is why along the path we are using the interface MTU value for MPLS value or we set MPLS MTU lower than the interface MTU value, since we are using POS. No MPLS MTU value larger then its int MTU value set.
There is a part of GE we put larger MPLS MTU value then its int MTU value which is only MPLS MTU 1580 which OK according this doc.
"Cisco IOS software allows the MPLS MTU value to be higher than the interface MTU value only for interfaces that have a default interface MTU value of 1580 or less. "
Unfortunately i can't as the Ge connected to OSPF BROADCAST network. Meaning that other routers connected to the switch are using MTU 1500, if I change the MTU, my IGP on that router will be down.
If this device is in the path of VPLS end points and not the edge then, somehow this looks to be more likely a candidate for mtu optmization.
you can configure ip ospf mtu-ignore on all the interfaces connecting to this broadcast and then change the mtu. the adjacency wont drop off.
Do you by any chance have routed vlans along the path? if so also modify the MTU settings on those and see if it works. I have had similar problems and even though all interfaces had MTU settings modified it did not work.
Thanks for the reply. I am sorry, I dont get what you mean by "Do you by any chance have routed vlans along the path? ". Which MTU i should modify?
Can you share with me your result end to end. Did you get 1500 bytes end to end (CE to CE) thru the VPLS ?
By routed VLANs I mean SVIs which you can create on Layer3 switches. so lets port 1 is a member of vlan 10 and vlan 10 is the svi, even though you modified port 1 with MTU settings, you might want to modified the mtu on the svi as well. As I said before, mine would not work untill I modified the SVI.
I tried to modify SVI mtu but still same ::(
no ip address
xconnect vfi jaring
I still get 1478 end to end.
Thanks for the reply.
I have modified the vlan mtu but still same.
I have double checked and confirm along the path support larger MPLS MTU, as our MPLS VPN also riding on the same path.
I just dont know else where is the bottleneck.