the relationship between Jumboframe and mpls mtu.

[syjeon]

I would like to know the relation between jumbo frame on catalyst switch and mpls mtu running mpls network.

In generally, We configure the jumbo frame to process jumbo frame from CE in giga port on catalyst 6500.

but the mpls mtu is configured like 1534. in generally

if you know. there is mpls mtu on mpls network to avoid packet fragment issue in mpls network so you configure mpls mtu max 1534(included TE FRR).

but My question is , IF jumbo frame is arrived at Catalyst 6500(configured jumbo frame). How can the 6500 act in mpls network?. Jumbo frame is fragemented to each packet per 1534 bytes? or not drop?on L2 VPN network(eompls and h-vpls)

[Giuseppe Larosa]

Hello Sung,

on l2 VPN services I don't think you can see a bigger frame to be fragmented.

The relationship is loose: enabling jumbo frame can be a way to forward MPLS frames for a L2 only device in the data path.

On a L3 device mpls mtu specifies the greatest MPLS frame size.

Hope to help

Giuseppe

[beitland]

Hello Giuseppe, 

I need some additional clarification please. I suspect I am in the same boat as Syjeon (original post) whereby I have a customer that would like a L2 VPN pseudowire between his two sites. He also states that jumbo frames are a requirement as well and I expect to receive jumbo frames from the customer attachment circuit. However, all of my MPLS backbone circuits were designed for a three label deep system mtu = 1534. It is my understanding that if I enable jumbo frames on the attachment circuit to my customer and indeed receive a jumbo frame, when the PE routers tries to label switch it out across its back bone link(s) towards the remote site, given the back bone link system mtu= 1534, the ethernet frame cannot be fragmented and will be dropped as a result. Is this correct?

And to follow the question up with another question (last one I promise), this is more of a general design guidance: "If all of the devices in the MPLS network CAN support jumbo frames, is there      *** ANY *** disadvantage (or any reason NOT) to enable jumbo frames throughout the MPLS network as a general rule? The only thing that I can come up with is the possibility of buffer exhaustion or having to tune buffers given all the frames are now 9k+ in size vice the default 1518 bytes. Any insights, comments or recommendations would be much appreciated.

Thank you,

Brett

[Giuseppe Larosa]

Hello Brett,

I'm sorry for my late answer you have probably already implemented the required changes in mtu in the end to end path to support your customer requirements.

In order to carry L2 ethernet jumbo frames in the order of 9000 bytes your core needs to support an mtu of 9000 + 8 bytes (to accomodate a two mpls label stack that is used by a L2 VPN service either point to point like an EoMPLS or other p2mp service like VPLS or H-VPLS).

The question is that in IOS based devices mtu is a layer 3 concept so the standard mtu is supposed to be 1500 bytes but the meaning at layer 2 is 1518 bytes including the 14 bytes header and the final 4 bytes FCS.

Other platforms like Cisco IOS XR platforms like ASR9000 have a OSI layer 2 concept of mtu so a standard GE interface has an mtu of 1514 bytes (the 4 bytes of the final FCS are not counted), a vlan based subinterface has an mtu of 1518 (4 bytes for the 802.1Q additional header).

So depending on the involved platforms values to be used are different.

But you have to put an upper limit on the size of customer frames in order to be able to carry them in the backbone inside MPLS frames with double label stack.

>> "If all of the devices in the MPLS network CAN support jumbo frames, is there      *** ANY *** disadvantage (or any reason NOT) to enable jumbo frames throughout the MPLS network as a general rule? The only thing that I can come up with is the possibility of buffer exhaustion or having to tune buffers given all the frames are now 9k+ in size vice the default 1518 bytes. Any insights, comments or recommendations would be much appreciated.

Modern network designs take advantage of the fact that there is no real performance penalties on current modern platforms and use an mtu of 9000 or more bytes in all core links in order to be able to support services like L2 transport of jumbo frames.

Buffer tuning is not needed anymore because devices switch frames and MPLS frames in hardware using linecard ASIC chips and only frames punted to the main cpu are handled by the buffers.

For example for a customer we used ME-3600 devices like PE nodes with a central core made of a cluster of two ASR9006. We used an mtu of 9012 bytes on ME-3600 side (IOS XE like IOS) and of 9026 bytes on the ASR 9006 side (IOS XR mtu is layer 2 as explained above).

Hope to help

Giuseppe