cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3838
Views
15
Helpful
6
Replies

Understanding "QnQ" in XR

Evan Roggenkamp
Level 1
Level 1

I am having a bit of trouble wrapping my head around the "push" operation for EVC model in XR.

I have the following configured:

interface GigabitEthernet0/7/0/13.990 l2transport
 encapsulation dot1q any
 rewrite ingress tag push dot1q 990 symmetric

!
interface TenGigE0/6/0/7.990 l2transport
 encapsulation dot1q 990
!

l2vpn

bridge group local-vlans
  bridge-domain vlan-990
   !
   interface TenGigE0/6/0/7.990 < packet comes in this interface with outer tag 990 and inner tag 1000
   !
   interface GigabitEthernet0/7/0/13.990 < what happens to the packet when it exits this interface destined for a downstream switch with a server on VLAN 1000? Does it make it?

1 Accepted Solution

Accepted Solutions

Ah, I think I see where your confusion comes from:

think this helps, read the command like this:

rewrite ingress: meaning on an incoming packet do something.

symmetric: in the egress direction do the reverse of the incoming operation

 

Another example:

interface X

encap dot1q 100

rewrite ingress tag pop 1 symmetric

>>> when a packet with vlan 100 comes in, it is matches, removed and a plain ip packet is entering the service (eg xcon or bd)

>>>in the reverse direction, a packet, regardless of what encap it has gets the 100 pushed onto it before egressing interface X.

cheers!

xander

View solution in original post

6 Replies 6

Peter L
Level 1
Level 1

Hi Evan

This document is a good place to start when it comes to l2vpn on the ASR9K

http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116453-technote-ios-xr-l2vpn-00.html

From the document

  • The push keyword lets you add a QinQ tag to an incoming dot1q frame:
interface GigabitEthernet0/1/0/3.4 l2transport
 encapsulation dot1q 4
 rewrite ingress tag push dot1q 100 symmetric

An outer QinQ tag 100 is added to the incoming frame with a dot1q tag 4. In the egress direction, the QinQ tag is popped.

Regards Peter

Hi Peter, thanks for the reply.

The confusion comes with this statement:

"The symmetric keyword is accepted only when a single VLAN is configured in encapsulation. If a list of VLANs or a range VLAN is configured in encapsulation, the symmetric keyword is accepted only for push rewrite operations; all other rewrite operations are rejected."

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-1/lxvpn/command/reference/b_lxvpn_cr41asr9k/b_lxvpn_cr41asr9k_chapter_01.html

I just want to verify that using "encapsulation dot1q any" doesn't negate symmetric addition/retraction of the outer tag.

Also, since the incoming ten gig interface is not performing symmetric operation, how does this affect the processing as a double tagged packet flows in, through L2VPN bridge, and out the interface pushing a tag?

To further highlight why I ask this question, the problem is that I see a MAC address in the bridge table of VLAN 990, but not in the bridge table of VLAN 1000 of downstream switches.

 

 

Hi Evan,

because you have a "dot1q any" EFP configured, the only thing we can do is push a tag.

the reason for that is that we can't to a translation or pop tag because we dont keep track of the original vlan for that mac address (unless you use a "Service" like dhcp snooping for instance to keep a full binding of mac and vlan).

in your original config what you'll get happening is: when a vlan X is received on 7/0/13.990 you will PUSH a 990 vlan outer to it.

in the bridge domain it gets switched to 6/0/7.990 as 990/X (so qiq).

on the ingress 6/0/7.990 when we'll get a 990/X/Y or whatever in will result in a switch to 7/0/13.990 whereby the 990 is popped on egress and X/Y is left in tact.

X/Y can either be present or not that doesnt matter, merely meaning that the incoming vlan stack will get 990 removed and rest is forwarded as is.

any other vlan then 990 is not terminated (resulting in a drop in the NP with reason UIDB_TCAM_MISS since there is no EFP for that non 990 VLAN).

there is a good doc on the support forums also with EVC model and rewrite operations. Also check the cisco live ID 2904 from orlando 2013 and sanfran 2014 for more details.

cheers

xander

 

 

because you have a "dot1q any" EFP configured, the only thing we can do is push a tag.

Do you mean on ingress only?

Because this seems to contradict (unless you mean on ingress only):

on the ingress 6/0/7.990 when we'll get a 990/X/Y or whatever in will result in a switch to 7/0/13.990 whereby the 990 is popped on egress and X/Y is left in tact.

So 0/7/0/13.990 DOES pop 990 on a double tagged frame as it exits this interface? Is this because of the symmetric keyword there on the push operation?

Sorry I am confused. Thank you for explaining to me, and the resources. 

Ah, I think I see where your confusion comes from:

think this helps, read the command like this:

rewrite ingress: meaning on an incoming packet do something.

symmetric: in the egress direction do the reverse of the incoming operation

 

Another example:

interface X

encap dot1q 100

rewrite ingress tag pop 1 symmetric

>>> when a packet with vlan 100 comes in, it is matches, removed and a plain ip packet is entering the service (eg xcon or bd)

>>>in the reverse direction, a packet, regardless of what encap it has gets the 100 pushed onto it before egressing interface X.

cheers!

xander

sreenivasgajula
Level 1
Level 1

For this example you mentioned, yes when a packet with outer tag 990 and inner tag 1000 comes into Gi0/6/0/7.990,  990 has to be popped while exiting onto 0/7/0/13.990.

 

interface GigabitEthernet0/7/0/13.990 l2transport
 encapsulation dot1q 990
 rewrite ingress tag pop 1 symmetric

interface TenGigE0/6/0/7.990 l2transport
 encapsulation dot1q 990

l2vpn 

bridge group local-vlans

  bridge-domain vlan-990

   ! 

     interface GigabitEthernet0/7/0/13.990

   !

     TenGigE0/6/0/7.990 

 

This should achieve with what you are trying to do.