MPLS MTU Here follows a summary of a discussion I had offlist with both Rodney Dunn and o ne of his colleagues

about the whole "mtu" / "tag-switching mtu" set of issues,t heir applicability to the PA-FE / IO-FE hardware and to AToM pseudowire: ------------------------------------------------------------------------1. Both the PA -FE and IO-FE series of interfaces are limited to transmitting up to 1530 bytes of frame "on the wire" 2. "on the wire" refers to the size of the PDU (protocol data unit) when we are talking about PE->P and P->P interfaces, we need to conce rn ourselves with configuring the MTU or MPLS MTU to be the size of the SDU (ser vice data unit) and not the PDU 3. In the case of an 1500B IP payload with two l abels (as per standard RFC2547 L3VPN) on a PE->P or P->P interface the SDU is 15 08 bytes so you configure "mtu 1508" or "mpls mtu 1508" The actual size of the f rame (PDU) would be 1508+14 (1522) or 1508+18 (for dot1q) (1526) which does not violate the PDU limitation of 1530 on these interfaces, the framing bytes which comprise the PDU are "implied" by the driver and hence don't need to be configur ed. 4. PA-FE and IO-FE interfaces can only *currently* have their "mpls mtu" set and not their "mtu" 5. The MPLS MTU was only an interim solution and will be dr opped in 12.2(28)SB and 12.4T, as a result of CSCsc62963 (internal only) the PAFE and IO-FE interfaces will allow for "mtu" to be set in order to allow the fun ctionality to continue. The "tag-switching mtu " or "mpls mtu" will hence no lon ger be configurable over the actual interface "mtu" Prior to this fix being impl emented, we could have configured any "mpls mtu" on the PA-FE/IO-FE interfaces , but if it exceeded the 1530 PDU limit the frame was dropped. An example would h ave been if you were to have four labels and the SDU is 1516 ("tagswitching mtu 1516" on PE->P or P->P interface) which creates a PDU of 1534 on these interface s , exceeding the 1530 limit for PA-FE or IO-FE interfaces and hence would have been dropped. Rodney's view on the "tag-switching mtu" is the following: "it was a hack and shouldn't have been allowed in the first place. These changes are cl osing that hole with the goal of having a more consistent cross platform impleme ntation in regards to MPLS MTU settings. " 6. When using L2VPN MPLS pseudowires (i.e EoMPLS) , the incoming circuit from the customer (called the "Attachment Ci rcuit" or "AC") doesn't require any changing of the MTU at all if we are carryin g the customer's IPoE (1500B IP packet inside Ethernet) An example of this is wh ere we carry a users Ethernet and dot1q over an EoMPLS VLAN pseudowire. The inco ming interface from the customer sees : - IP Payload (1500B) - Ethernet Frame (1 4B) - Dot1Q tag (4B)

Under circumstances such as above we dont need to accept anything bigger from th e customer then would be done normally (i.e without EoMPLS) hence no MTU increas e is required (the SDU is 1500B ) However on the PE->P and P->P interface we are also carrying: - AToM Control word (4B) - Customer's Ethernet Frame (14B) - Cus tomer's dot1q tag (4B) So in total, the egress interface carries: Customer Paylo ad (1500B) AToM Control word (4B) Customer's Ethernet Frame (14B) Customer's dot 1q tag (4B) Service Provider VPN Label (4B) Service Provider LSP Label (4B) 1500+4+14+4+4+4 = 1530 which is the SDU, hence on the PE->P and P->P interface, you are required to use "mpls mtu 1530" (supported at the moment) or "mtu 1530" (preferred method) On the wire, the PDU is actually 1530+14 (1544) or 1530+18 (1 548) (if you have dot1q here) and exceeds the 1530 PDU limit so hence EoMPLS car ried on PE->P or P->P links are not suitable to be carried over PA-FE or IO-FE i nterfaces (but can be carried everywhere elsE) 7. Where you carry something LARG ER than the standard 1500 SDU for the customer on the Attachment Circuit (ingres s CE->PE) for example, some MPLS labels (i.e customer runs MPLS over EoMPLS) you can *only* increase the MTU , you can not increase the "mpls mtu" here as its n ot relevant. (and support for this will be dropped anyway!) The attachment circu it is not tag-switching and hence the MPLS MTU is not relevant here. 8. Increasi ng the MTU on the attachment circuit is fine, you must obviously increase the re mote MTU (for the remote attachment circuit) in order to comply with RFC4447. If we dont, the PW will not be setup 9. This can pose a problem where the Attachme nt Circuit is actually a dot1q subinterface. By increasing the mtu of the main ( trunk) interface you change the MTU for all the subinterfaces and hence where yo u have Pseudowires configured for other customers you affect their setup (and po tentially break it) An potential solution to this is a per-subinterface MTU, but most ethernet interfaces that support dot1q do not currently support this. BugI D CSCeh27672 (externally visible) has been raised to deal with this and is in "A ssigned" state, but no progress has been made on it. I have raised a TAC case wi th regards to this BugID and asked for progression on it, with two potential sol utions: a. Allow per-subinterface MTU for the purpose of PW setup (even if its m eaningless elsewhere) or b. Allow override of the RFC4447 MTU checking as per l2 tpv3 PW setup