Problem with Q-in-Q and untagged traffic
Hello experts
I have an mpls backbone, with asr 920 and sw 3850. I want to connect a customer with a l2 pipe and transport their vlans across the backbone. The topology is: customer sw-asr920-mpls backbone-asr920-sw 3850-customer sw. In the 3850 I connect the customer with a dot1q-tunnel and in the next asr 920 I configure a service-instance with Q-in-Q, so I guess every received dot1q frame with vlan ID 1-4094 will be encapsulated with a second dot1q frame with an outer vlan specific for that customer. That´s clear for me.
My questions:
- let´s say that customer is using switches out of the box, with native vlan 1 for the trunks and vlan 1 for the access ports and it´s not working, those switches cannot see each other...what happens with untagged traffic when reaching the sw 3850? are these frames sent through the tunnel or are discarded at this point? Are they discarded in the asr 920? How are they encapsulated with a second dot1q header if that original frame is untagged and there is no dot1q header?
- Layer 2 protocols are also sent with vlan 1, what happens when reaching the sw 3850 with these traffic?
- what are my options appart from changing the native vlan in the customer side? Is it there a way to handle these untagged traffic to deliver it to the other side?
endpoint A: asr920 - customer sw out of the box
asr 920
interface GigabitEthernet0/0/8
mtu 9216
no ip address
load-interval 30
negotiation auto
no keepalive
service instance 10 ethernet
encapsulation default
l2protocol forward
service-policy input POLICY_CUSTOMER_INGRESS_10
service-policy output POLICY_CUSTOMER_EGRESS_100
xconnect 8.8.8.1 25 encapsulation mpls
endpoint B: asr920 - sw 3850 - customer sw out of the box
asr 920
service instance 50 ethernet
encapsulation dot1q 401 second-dot1q 1-4094
rewrite ingress tag pop 1 symmetric
l2protocol forward
service-policy input POLICY_CUSTOMER_INGRESS_10
service-policy output POLICY_CUSTOMER_EGRESS_100
xconnect 8.8.8.2 25 encapsulation mpls
sw 3850
interface GigabitEthernet1/0/5
switchport access vlan 401
switchport mode dot1q-tunnel
load-interval 30
l2protocol-tunnel cdp
l2protocol-tunnel lldp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
end
customer sw out of the box
Regards
I have an mpls backbone, with asr 920 and sw 3850. I want to connect a customer with a l2 pipe and transport their vlans across the backbone. The topology is: customer sw-asr920-mpls backbone-asr920-sw 3850-customer sw. In the 3850 I connect the customer with a dot1q-tunnel and in the next asr 920 I configure a service-instance with Q-in-Q, so I guess every received dot1q frame with vlan ID 1-4094 will be encapsulated with a second dot1q frame with an outer vlan specific for that customer. That´s clear for me.
My questions:
- let´s say that customer is using switches out of the box, with native vlan 1 for the trunks and vlan 1 for the access ports and it´s not working, those switches cannot see each other...what happens with untagged traffic when reaching the sw 3850? are these frames sent through the tunnel or are discarded at this point? Are they discarded in the asr 920? How are they encapsulated with a second dot1q header if that original frame is untagged and there is no dot1q header?
- Layer 2 protocols are also sent with vlan 1, what happens when reaching the sw 3850 with these traffic?
- what are my options appart from changing the native vlan in the customer side? Is it there a way to handle these untagged traffic to deliver it to the other side?
endpoint A: asr920 - customer sw out of the box
asr 920
interface GigabitEthernet0/0/8
mtu 9216
no ip address
load-interval 30
negotiation auto
no keepalive
service instance 10 ethernet
encapsulation default
l2protocol forward
service-policy input POLICY_CUSTOMER_INGRESS_10
service-policy output POLICY_CUSTOMER_EGRESS_100
xconnect 8.8.8.1 25 encapsulation mpls
endpoint B: asr920 - sw 3850 - customer sw out of the box
asr 920
service instance 50 ethernet
encapsulation dot1q 401 second-dot1q 1-4094
rewrite ingress tag pop 1 symmetric
l2protocol forward
service-policy input POLICY_CUSTOMER_INGRESS_10
service-policy output POLICY_CUSTOMER_EGRESS_100
xconnect 8.8.8.2 25 encapsulation mpls
sw 3850
interface GigabitEthernet1/0/5
switchport access vlan 401
switchport mode dot1q-tunnel
load-interval 30
l2protocol-tunnel cdp
l2protocol-tunnel lldp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
end
customer sw out of the box
Regards
ASKER
Thanks for your answer, I really appreciate it. I´ve read that document
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swtunnel.html
and what I understand is:
- "When IEEE 802.1Q trunks are used in these core switches,...": it refers to the trunk in my 3850 facing the backbone
- "the native VLANs of the IEEE 802.1Q trunks must not match any native VLAN of the nontrunking (tunneling) port on the same switch...": it refers to the native vlan of the trunk in my 3850 facing the backbone that must not match the outer vlan asigned to the customer in the tunneling port facing the customer, wich is an access port
so I understand that
vlan dot1q tag native
would solve the problem in case the outer vlan for the customer and the native vlan in the trunk in the 3850 facing the backbone was the same...am I correct? But is not my case, there´s no overlap between native vlans in the trunks and the customer outer vlan, I´m not sending untagged frames towards the backbone
I´ve been reading more and I found how the edge switch handle the traffic coming from the customer
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swtunnel.html
If traffic coming from a customer network is not tagged (native VLAN frames), these packets are bridged or routed as normal packets. All packets entering the service-provider network through a tunnel port on an edge switch are treated as untagged packets, whether they are untagged or already tagged with IEEE 802.1Q headers. The packets are encapsulated with the metro tag VLAN ID (set to the access VLAN of the tunnel port) when they are sent through the service-provider network on an IEEE 802.1Q trunk port.
but this is confusing for me because the next hop towards the backbone is the asr 920, and the port receiving that traffic is configured with a second vlan tag, that means the inner vlans that are accepted to encapsulate
encapsulation dot1q 401 second-dot1q 1-4094
so what I understand is that the asr 920 receives a frame with a second dot1q header with the outer vlan ID, and...no first dot1q header because the original frame was untagged and it´s discarded at that point because the inner vlan should be 1-4094??
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swtunnel.html
and what I understand is:
- "When IEEE 802.1Q trunks are used in these core switches,...": it refers to the trunk in my 3850 facing the backbone
- "the native VLANs of the IEEE 802.1Q trunks must not match any native VLAN of the nontrunking (tunneling) port on the same switch...": it refers to the native vlan of the trunk in my 3850 facing the backbone that must not match the outer vlan asigned to the customer in the tunneling port facing the customer, wich is an access port
so I understand that
vlan dot1q tag native
would solve the problem in case the outer vlan for the customer and the native vlan in the trunk in the 3850 facing the backbone was the same...am I correct? But is not my case, there´s no overlap between native vlans in the trunks and the customer outer vlan, I´m not sending untagged frames towards the backbone
I´ve been reading more and I found how the edge switch handle the traffic coming from the customer
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swtunnel.html
If traffic coming from a customer network is not tagged (native VLAN frames), these packets are bridged or routed as normal packets. All packets entering the service-provider network through a tunnel port on an edge switch are treated as untagged packets, whether they are untagged or already tagged with IEEE 802.1Q headers. The packets are encapsulated with the metro tag VLAN ID (set to the access VLAN of the tunnel port) when they are sent through the service-provider network on an IEEE 802.1Q trunk port.
but this is confusing for me because the next hop towards the backbone is the asr 920, and the port receiving that traffic is configured with a second vlan tag, that means the inner vlans that are accepted to encapsulate
encapsulation dot1q 401 second-dot1q 1-4094
so what I understand is that the asr 920 receives a frame with a second dot1q header with the outer vlan ID, and...no first dot1q header because the original frame was untagged and it´s discarded at that point because the inner vlan should be 1-4094??
ASKER
I have just finished testing in a lab with the same topology i have in production. What I found is that if layer 2 protocols arrive at the edge switch untagged, that traffic (with the combination of devices I have in this branch, ASR920+sw3850) is not properly encapsulated with the outer vlan to be sent through the backbone. This just happens with native vlan 1 in the customer trunk, I think the reason is that most of layer 2 protocols are sent in vlan 1, so they reach the dot1q-tunnel entry point untagged, and the asr920 expect a frame with a dot1q header with vlan ID 1-4094 to add a second one. And traffic don´t pass from this point. Also vlan dot1q tag native don´t solve the problem. 
This is my conclusion...
I guess it will happen something similar with traffic coming from the lan side if the access vlan is the same than the one on the trunks, I didn´t tested it.
With a different combination of hardware, for example asr920-asr920, it doesn´t matter the native vlan in the customer trunks, could be also different at both ends, in this case traffic can be sent through the backbone in a different way, I have to read a little bit more to understand how.
This is my conclusion...I guess it will happen something similar with traffic coming from the lan side if the access vlan is the same than the one on the trunks, I didn´t tested it.
With a different combination of hardware, for example asr920-asr920, it doesn´t matter the native vlan in the customer trunks, could be also different at both ends, in this case traffic can be sent through the backbone in a different way, I have to read a little bit more to understand how.
Can you paste device configurations?
Regarding protocols and L2 tunneling, by default it is off, need to be configured.
You can find details in articles from previous posts:
Regarding protocols and L2 tunneling, by default it is off, need to be configured.
You can find details in articles from previous posts:
Switch(config)# interface gigabitethernet1/0/11There are more details in articles.
Switch(config-if)# l2protocol-tunnel cdp
Switch(config-if)# l2protocol-tunnel stp
Switch(config-if)# l2protocol-tunnel vtp
Switch(config-if)# l2protocol-tunnel shutdown-threshold 1500
Switch(config-if)# l2protocol-tunnel drop-threshold 1000
Switch(config-if)# exit
Switch(config)# l2protocol-tunnel cos 7
ASKER
Yes, L2 protocols are enabled in the tunnel. The problem is just with untagged traffic entering the sw 3850 coming from the customer side. Looks like this traffic is not properly encapsulated, even that the sw 3850 is supposed to handle all received traffic as untagged, and is supposed to be encapsulated somehow
asr 920 left
!
interface GigabitEthernet0/0/8
description customer p2p
mtu 9216
no ip address
load-interval 30
negotiation auto
no keepalive
service instance 10 ethernet
encapsulation default
l2protocol forward
xconnect 8.8.8.1 25 encapsulation mpls
!
!
asr 920 right
interface GigabitEthernet0/0/22
description link to 3850
mtu 9216
no ip address
load-interval 30
negotiation auto
no keepalive
cdp enable
service instance 50 ethernet
description customer p2p
encapsulation dot1q 401 second-dot1q 1-4094
rewrite ingress tag pop 1 symmetric
l2protocol forward
xconnect 8.8.8.2 25 encapsulation mpls
sw 3850
system mtu 9198
spanning-tree mode pvst
spanning-tree extend system-id
interface GigabitEthernet1/0/5
description customer p2p
switchport access vlan 401
switchport mode dot1q-tunnel
load-interval 30
l2protocol-tunnel cdp
l2protocol-tunnel lldp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
interface GigabitEthernet1/0/11
description link to asr 920 right
switchport trunk native vlan 999
switchport trunk allowed vlan 401
switchport mode trunk
asr 920 left
!
interface GigabitEthernet0/0/8
description customer p2p
mtu 9216
no ip address
load-interval 30
negotiation auto
no keepalive
service instance 10 ethernet
encapsulation default
l2protocol forward
xconnect 8.8.8.1 25 encapsulation mpls
!
!
asr 920 right
interface GigabitEthernet0/0/22
description link to 3850
mtu 9216
no ip address
load-interval 30
negotiation auto
no keepalive
cdp enable
service instance 50 ethernet
description customer p2p
encapsulation dot1q 401 second-dot1q 1-4094
rewrite ingress tag pop 1 symmetric
l2protocol forward
xconnect 8.8.8.2 25 encapsulation mpls
sw 3850
system mtu 9198
spanning-tree mode pvst
spanning-tree extend system-id
interface GigabitEthernet1/0/5
description customer p2p
switchport access vlan 401
switchport mode dot1q-tunnel
load-interval 30
l2protocol-tunnel cdp
l2protocol-tunnel lldp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
interface GigabitEthernet1/0/11
description link to asr 920 right
switchport trunk native vlan 999
switchport trunk allowed vlan 401
switchport mode trunk
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
! Tag native VLAN globally
!
(config)# vlan dot1q tag native
!
! You can remove native VLAN tagging per port
!
interface gi0/0
no switchport trunk vlan native tag
!
system mtu 1504
Show commands to confirm status:
show vlan dot1q tag native | include globally
dot1q native vlan tagging is enabled globally
show interface gi0/0 switchport | include tagging
Administrative Native VLAN tagging: enabled
Operational Native VLAN tagging: disabled
Detailed explanation - Catalyst 3750 Switch Software Configuration Guide, 12.2(25)SEE