Tag-switching mtu

anasubra_2 · ‎02-06-2009

Hi All,

We are wondering ,what would be the effect on performance of the traffic,where higher tag-switching mtu values are set (for example 4470 bytes).

I guess we should be fine with a maximum value of 1516 bytes instead of 4470.We are currently set with Tag-switching mtu value of 4470 and considering to change to 1520,is there any perfomance improvement by doing that. Any help would be appreciated.

Thanks

Regards

Anantha Subramanian Natarajan

Giuseppe Larosa · ‎02-06-2009

Hello Anantha,

the right choice depends on applications/services you run in your network.

1520 bytes should be fine

Hope to help

Giuseppe

anasubra_2 · ‎02-06-2009

Hi Giuseppe,

Thanks for the reply. Do you have any links or table which describe,which all common type of traffic would get impacted by having high tag switched MTU sizes ?......The intention for this question is,there are some customers using the MPLS core feel slowness in their application(not sure abt the application) and we are trying to figure out,by having the current tag switched MTU size of 4470 bytes is casuing the problem

Thanks

Regards

Anantha Subramanian Natarajan

Giuseppe Larosa · ‎02-07-2009

Hello Anantha,

4470 is the default MTU size on WAN links like ATM (every speed) and POS or serial (T3 or E3).

But usually on the path of user data the first and the last hop are LAN segments (and there can be intermediate hops when moving data inside a Provider POP).

So a so high MTU is not used actually by user data: at least on the user side the IP MTU is 1500 bytes.

On the server side you can enable jumbo frames for server-to-server communication.

And what is important to take in account is that MPLS frames cannot be fragmented or they can go out a link or they are discarded.

The size can be calculated by thinking of:

an IP MTU of 1500 bytes needs to be carried in any case.

a L3 MPLS VPN would require a two label stacks.

More complex scenarios involving MPLS TE used to carry MPLS VPN traffic require a deeper stack.

Then if you offer Carrier Supporting Carrier sevices for example the stack is longer.

If you provide a EoMPLS service to someone using it to carry an MPLS VPN you may need 1534 bytes MTU (I did some calculations for a merge of two providers)

It is also important to increase the MTU on intervening L2 switches inside your POPs this has to be considered and implemented too.

This can be part of the problem a L2 switch on the path not configured to handle the added MPLS overhead and so causing some packets to be dropped.

The benefit of using an MPLS MTU of 1520 is that you don't leave space to possible ambiguities on what can travel on the MPLS backbone end-to-end.

Hope to help

Giuseppe

anasubra_2 · ‎02-07-2009

Hi Giuseppe,

Thank you very much for the detailed explanation.Can I assume that having 4470 as tag-switching MTU may not be a such a performance issue for the application but may have possible ambiguities of unwanted data traveling the MPLS backbone ?

Also,we planning to have inter-provider connectivity but in the form of option A,where label stack is terminated on the ASBR itself .

Thanks

Regards

Anantha Subramanian Natarajan

Mohamed Sobair · ‎02-07-2009

Hi,

The MTU of ATM interfaces defaults to 4470 because of the layer-2 overhead. the Vpi which is 16 byte detrmines the destination of the next cell.

On another hand, Option (10 A) has nothing to do with ur MTU, Option 10A is one of Inter-AS VPM types. Option 10A demonistrate VRF-to-VRF connectivity between PEs In back to back fashion to carry the VPNv4 routes. Option 10A is the least scalable solution , however , its the most widely deployed type.

HTH

Mohamed

anasubra_2 · ‎02-07-2009

Hi Mohamed,

Thanks for the reply. I am trying to understand,whether the tag-switching MTU set to 4470 bytes will have any performance impact on the application running over the MPLS network instead of setting to 1520 bytes.

Yes, we also aware of the option A non-scalabilty and the reason for planning to use this option becasue,this is what vendor is willing to do with us. The reason to mention option A is ,since in option A labels are not carried from MPLS VPN 1 to MPLS VPN2. Anyway,thanks for the comment on the same.

I would really appreciate,if there is an answer for the performance issue of the application travelling over MPLS network where the tag switched interfaces are assigned with MTU value of 4470 instead of something like 1520 bytes.

Thank You

Regards

Anantha Subramanian Natarajan

Mohamed Sobair · ‎02-07-2009

Anantha,

The MTU in ATM interfaces defaults to 4470 to match exatly FDDI and High Speed Serial links (HSSI) interfaces. Pls have alook at the bellow link:

http://www.cisco.com/application/pdf/paws/10479/mtu_atm.pdf

Another point,In Option 10A, the labels are carried between PEs in Vrf-to-vrf connectivity. The PEs carries the VPNv4 routes which are Labeled routes.

HTH

Mohamed

anasubra_2 · ‎02-07-2009

Mohammed,

Thanks for the reply.Actually the point is,the end users using the application are in ethernet and so they are already been restricted to 1500 bytes even the core may be using ATM interfaces which has an IP MTU of 4470 bytes which is different than tag switched MTU size.

So,I am trying to understand,if we set tag-switching mtu as 4470 bytes in all core interfaces,irrespective of whether it is ATM or ethernet interfaces,do we have any performance issues on the application carried over the backbone.Here,I we are not trying to change the IP MTU size of the tagged interfaces and only the tag-switched interface.

Also,you are right,My understanding is,the labels are carried between PE's in option A but not between the ASBRs,where the back to back VRF scenario come into picture.

Any help would be appreciated regarding the relation between setting tag-switched MTU size setting with 4470 bytes and any performance degradation of application.

Regards

Anantha Subramanian Natarajan