QinQ MTU

Question

Hello,
we are using the following configuration to a QinQ link in the subinterface to our users:
interface GigabitEthernet0/0/0/3.900 l2transport
description To CUSTOMER - PSEUDOWIRE A
encapsulation default
l2protocol cpsv tunnel
interface TenGigE0/1/0/3.900 l2transport
description To BACKBONE - PSEUDOWIRE A
encapsulation dot1q 900 second-dot1q any
rewrite ingress tag pop 1 symmetric
Everything is working fine and frames with a payload with 1500 bytes is beeing transported. The issue is that
a ethernet frame with a payload of 1500 has a total size of 1518 bytes. I know that IOS XR MTU
concept discard 4 bytes for the ethernet trailer (FCS or CRC). So for Cisco and MTU the original frame size is 1514.
However the frame received in the GigabitEthernet0/0/0/3.900 has a VLAN TAG because we
have a trunk to our customer with multiples VLANS. So the MTU size should be 1518. But if we get the
out of the show interface command:
sh interface GigabitEthernet0/0/0/3.900
Wed Sep 12 12:56:32.130 CEST
GigabitEthernet0/0/0/3.900 is up, line protocol is up
  Interface state transitions: 1
  Hardware is VLAN sub-interface(s), address is 6c9c.ed09.295f
  Description:To CUSTOMER - PSEUDOWIRE A
  Layer 2 Transport Mode
  MTU 1514 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)
     reliability Unknown, txload Unknown, rxload Unknown
  Encapsulation Default,
    Default match
    Ethertype Any, MAC Match src any, dest any
  loopback not set,
  ARP type ARPA, ARP timeout 04:00:00
  Last input never, output never
  Last clearing of "show interface" counters never
     1924812905 packets input, 1293208601922 bytes
     3 input drops, 0 queue drops, 0 input errors
     778056641 packets output, 447390756224 bytes
     0 output drops, 0 queue drops, 0 output errors
sh interface TenGigE0/1/0/3.900          
Wed Sep 12 13:02:26.173 CEST
TenGigE0/1/0/3.900 is up, line protocol is up
  Interface state transitions: 7
  Hardware is VLAN sub-interface(s), address is 4055.3968.7d2b
  Description: BACKBONE - PSEUDOWIRE UPCT-FTALMO
  Layer 2 Transport Mode
  MTU 1518 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
     reliability Unknown, txload Unknown, rxload Unknown
  Encapsulation 802.1Q Virtual LAN,
    Outer Match: Dot1Q VLAN 900
    Inner Match: Dot1Q VLAN any
    Ethertype Any, MAC Match src any, dest any
  loopback not set,
  ARP type ARPA, ARP timeout 04:00:00
  Last input never, output never
  Last clearing of "show interface" counters never
     778152164 packets input, 450515418508 bytes
     31813 input drops, 0 queue drops, 0 input errors
     1902517045 packets output, 1287687321444 bytes
     308359 output drops, 0 queue drops, 0 output errors
We have a 1514 bytes MTU instead of 1518 bytes in GigabitEthernet0/0/0/3.900 and 1518 bytes instead
1522 (there is two 4 bytes tags). Why frames are working fine?. In the following document explains that
by default the MTU are:
1514 bytes for normal frames
1518 bytes for 802.1Q tagged frames
1522 bytes for QinQ frames
http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r3.9/lxvpn/configuration/guide/lesc39ethi.html#wp1200718
How can we explain the 4 bytes difference?.
Thanks.

Answer 1

Hello Antonio,
Here are numbers which are used for L2 MTU calculation:
"encapsulation untagged” and "encapsulation default”  counts 0 tags. >> 1514
“encapsulation dot1q 900 second-dot1q any”. The any keyword used as the innermost tag match does not increase the number of tags in the calculation. This is to ensure consistency with the old style XR VLAN Id semantics. >> 1518
“encapsulation dot1q 900 second-dot1q 900”. No any keyword >> 1522
but for L2VPN we’d use payload MTU to properly transfer our data.  The rationale behind the payload MTU calculation is to get the correct maximum payload size of frames that may be carried over an xconnected PW relative to the L2 MTU of the interface.
Let’s take your example:
interface TenGigE0/1/0/3.900 l2transport
description To BACKBONE - PSEUDOWIRE A
encapsulation dot1q 900 second-dot1q any
rewrite ingress tag pop 1 symmetric
sub-l2-mtu = parent-l2-mtu + (4 * encaps-tag-count)
sub-l2-mtu = 1514 + ( 4 * 1 ) = 1518
sub-l2-payload-mtu = sub-l2-mtu – (14 + (4 * (encaps-pop-tags-count – encaps-push-tags-count)))
sub-l2-payload-mtu = 1518 - (14 + (4 * (1 - 0)))= 1500
So we’d be still forwarding 1500b payload.
You should be able to find your xconnect/BD MTU using “show l2vpn xconnect detail” or “show l2vpn bridge-domain detail”.
Regards,
/A