Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

l2vpn MTU

Hi,

I have read somewhere in this forum saying that the 1524 mtu size is a recommendation in an MPLS VPN context but it might not suit a l2vpn deployment. This is because l2vpn such as AToM need mpls mtu 1526 , right?

The problem I am facing right now is, cisco IOS version 12.3.25(S8)in c7500 only allow mpls mtu 1524 configured (Fe interface)

Question is, will my EoMPLS works if our core routers using mtu 1524 as the EoMPLS need 1526

11 REPLIES
Bronze

Re: l2vpn MTU

you will be absolutely fine here mate as long as the customer doesnt chuck DF packets at you. 1524 is more than adequate in my opinion. Hell the network i used to work on had the edge ports configured as 1500 for at least 2 years before the 1st customer complained about it.

New Member

Re: l2vpn MTU

You will encounter problems with an MTU of 1524, especially if you are trying to implement EoMPLS.

Check the Cisco Press "Layer 2 VPN Architecture" book, chapter 7 for more details.

Here is a breakdown of the MPLS MTU:

Ethernet Payload - 1500

802.1q header - 18

AToM Header - 4 (Required for ATM and FR only )

AToM Label - 4

LDP Label - 4

TE Label - 4

MPLS Fast Reroute - 4

Total = 1538

Cisco Employee

Re: l2vpn MTU

Shawn,

What you refer to as the AToM header is actually the Martini encapsulation control word (CW) and is as you say required for ATM and FR but could be there as well for other L2, such as Ethernet, depending on implementations.

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

Re: l2vpn MTU

Thanks for the additional clarification!

New Member

Re: l2vpn MTU

These MTU questions pertain only from the PE inward, not from PE outward, correct?

To clarify - an MTU of 1500 from CE to PE will be fine, but a larger MTU will be required from the PE to [PE | P], correct?

Re: l2vpn MTU

Yes thats correct, a mtu of 1500 between CE-PE is fine in all cases. (except for CSC-CE)

And the higher MTU between your core devices that is PE-P or PE-PE is dependent on the services implemented (L3VPN,MPLS-TE,ATOM).

HTH-Cheers,

Swaroop

New Member

Re: l2vpn MTU

So I've been doing some reading on MTU issues with EoMPLS/ATOM.

I'm trying to understand if setting the mpls mtu on the PEs to 1462 (1500-38) is better than jacking up the MTUs on the physical interfaces on all the devices on an LSP.

Is the mpls mtu functionality what I think it is? If a frame from a CE is received on an ingree PE port and is larger than mpls mtu, it will be fragmented and life will be good?

My topology looks like:

3560 --fe-- 7200(PE1) --ge-- 7200(PE2) --fe-- 3560

Clients connect to the 3560 switch port in a vlan, 7200 has vlan subinterface with xconnect.

Re: l2vpn MTU

If you reduce the MTU between the PE's it wont result in fragmentation if the DF bit is set by the end clients, which is very likely for TCP based traffic.

And secondly looking at your topology and the service you will not face any MTU issues in my honest opinion.

HTH-Cheers,

Swaroop

New Member

Re: l2vpn MTU

That's the part I'm not quite following - I'm a little fuzzy on what does the fragmenting - how I would not have MTU issues? If a client generates a 1500 byte packet, the switch adds the dot1q tag, so the packet is already larger than 1500 bytes when it leaves the switch and heads down the trunk to the PE. Does the PE fragment at that point or does it only fragment if the packet is still larger than 1500 bytes after the dot1q tag has been removed?

So by whatever mechanism, the PE gets the packet from the client via the switch. The PE adds the label stack and all the other packet inflating MPLS bits and sends it to the neighbor PE. Are all the extra bits removed before the packet is checked for size exceeding the MTU?

I read that you couldn't fragment inside L2VPNs?

Re: l2vpn MTU

You gig ethernet is able to handle frames upto 1518 bytes without fragmentation.

And when you are doing a subinterface based xconnect you are not carrying the Dot1Q tag with it, it just a port based Eompls.

So in your topology there wont be fragmentation needed as the end host wont send a packet larger than 1500 with DF bit set.

HTH-Cheers,

Swaroop

2229
Views
5
Helpful
11
Replies
CreatePlease to create content