EoMPLS MTU issue

[aretsu]

Hello,

I need help with EoMPLS issue. I know EoMPLS uses something like 1530 bytes MTU (due to the 1500bytes frame and all the encapsulations involved) and does not allow for fragmentation.

I have the following scenario:

CE-MetroRing-NPE-P-P-NPE-MetroRing-CE

NPE-7600-Sup7203BXL

P-GSR12006

When I send a ping of 1486bytes from the CE Router everything works ok, BUT When I increase the MTU to 1487bytes it stops working. So I have a 14-byte problem in the network.

The whole network has configured the "mpls mtu 9216" command on all the GE interfaces, BUT all the physical MTU are configured to support 1500Bytes, so here is my question:

Do I have to increase the Physical MTU on the GE interfaces to get this scenario working?

Also, in case I have to increase the MTU, does it mean that the network service is to be interrupted? (maybe OSPF flap becasue to MTU change or may be interface flap).

Thanks!

[Harold Ritter]

You don't need to change the physical interface MTU. Just use the "mpls mtu 1530" command on all the GigE interfaces part of the MPLS core. This should fix the issue.

Hope this helps,

[aretsu]

But I have the MPLS MTU configured for 9216 bytes on all GE Interfaces "mpls mtu 9216"

I just saw while doing some troubleshooting the following:

CE1-MetroRing-NPE1-P-P-NPE2-MetroRing-CE2

Send a 1500bytes ping form CE1

issue a "show mpls l2t vc 101 detail" on NPE1 and see that the send packets increase the same number of pings I sent.

issue a "show interface ge-wan9/1" on NPE2 and see the same number of packets arrive as GIANTS and never get to their destination. The interface ge-wan 9/1 has the MPLS MTU increased to 9216, but the physical MTU fixed at 1500bytes.

I think that may be the interface as it dont see any MPLS frames (they dont have any labels) it treated as normal IP packets and drop them due to the size.

What could be causing this behavior?

Thanks!

[Harold Ritter]

Make sure that the L2 devices in the path also support "baby giants".

Hope this helps,

[aretsu]

That is the strange thing here...there is no L2 device in the network.

The equipment involved are:

7600Sup7203BXL - GSR12006 - GSR12006 - 7600Sup7203BXL

NPE

[aretsu]

Sorry, here is the topology ...

(SVI interface)7600Sup7203BXL(GE-WAN) - (GE Interface)GSR12006(POS) - (POS)GSR12006(GE interface) - (GE-WAN)7600Sup7203BXL(SVI interface)

All the GE-WAN and the GE interfaces are configured with the "mpls mtu 9216", but all of them are configured to a physical mtu of 1500 bytes.

Other test that I have done is send a ping from NPE1 loopback to the NPE2 loopback, with a MTU of 1500bytes with the DNF bit set.... and it works!!!

But inside the L2VPN VC it does not.

Any ideas?

[Harold Ritter]

You do need to enable Jumbo Frame support on the physical GE on the 6500 as stated in this document:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml#subtopic1A

Let me know if that solves the issue,

[aretsu]

OK, That sound good!

Only have one doubt:

On the GE-WAN interface there is a L3 connection running OSPF with the GSR on each city, does change the MTU on the interface have impacts? like reset the interface physically? or cause OSPF to fail?

I think I have seen that when you change MTU on the physical interface, it resets the interface and OSPF get down (unless you use the MTU-ignore feature on OSPF).

I have never tried to do this on a 7600Sup7203BXL, do you?

Thanks a lot for all your help.

[Harold Ritter]

I have never tried it myself but I think you are correct. This would probably reset the ospf adjacency. You need set the "ip mtu 1500" on the interface to avoid the ospf adjacency to be reset.

Hope this helps,

[suresh.krishnamurthy]

hi,

Please set your

ip mtu size=1496

and verify

Regards

Krishnamurthy Suresh

[aretsu]

ip mtu= 1496 only on the NPE devices? or also on the P network Core?

Regards!