QinQ MTU

[antonio.guirado]

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.

[Alexei Kiritchenko]

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

[antonio.guirado]

Hello again,

thanks so much for you reply. I would like understand when you say "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". If you explain more about this phrase would be grateful. I suppose that the idea is the same when you configure QinQ in a c3750 (Catalyst) that system mtu not include 802.1q header and the mtu value is 1504 instead of

1508.

I am confused because when you use:

encapsulation default -> MTU is 1514 and 802.1q frames are allowed with 1 header 802.1q (total size without CRC 1518 bytes)

encapsulation dot1q 900 second-dot1q any -> MTU is 1518 but doble tagged frame are allowed (total size without CRC 1522 bytes)

but when you use

encapsulation dot1q 900 -> MTU is automatically extended to 1518 to receive 8021.q frames with 1 tag whose

real size (without FCS) are 1518 bytes.

Thanks again

[Alexei Kiritchenko]

by any I mean “any” keyword in the config command

encapsulation dot1q 900 second-dot1q any

or

encapsulation dot1q 5 second-dot1q any

i am not sure how c3750 work and can’t really comment on this.

In any case, ASR9k is more intelligent in that term for L2 MTU calculation. It can adjust the MTU automatically based on the VLAN tag encapsulation and the VLAN tag manipulation configuration. The goal is to get your payload MTU which exclude the VLAN tags.

Hence, to be sure how may payload bytes it would pass you’d better to look at XC/BD output.

btw, I’ve found that we actually have this MTU calculation document posted already:

https://supportforums.cisco.com/docs/DOC-15553

Regard,

/A