Understanding QinQ and trunk port behaviour

DANMOH009

I've always took it for granted in understanding how a trunk port does its work, a frame will will travel through the access port hit the trunk port. The trunk port will tag into with the vlan and send it over the link, at the other end of the trunk vlan is stripped off and forwarded to the access port it needs to go to.

Ive started to look at qinq (dot1q tagging). This is configured on the access port and allows a additional tag to be placed in front of the current vlan. This has made me think in more depth on how the trunk port makes its decisions so i was wondering if someone could help me with the following questions?

1. How does the trunk port know which vlan to tag on the frame before it sends it out? is there a table lookup process?

2. when dot1q tagging is enabled on the access port? what if there is no vlan already tag to the frame passing through it (no c-tag)? will this just be treated as a normal frame at the trunk, or does the dot1q tagging feature make the trunk port expect to see something in the ethertype and not let it pass?

3. And lastly when a QinQ frame goes through a trunk port and reaches the other end how does it know not to strip the last tag off? I have read that the last tag is stripped off only on a asymmetric link. So as a trunk port normally strips off the tag and forwards to the access, what tells it not to strip off in a QinQ frame?

Hope these questions make sense.

Thanks

Daniel

tomtom1

First, I've only got experience with dot1q tunneling / Q-in-Q on Juniper switches but I'm guessing the basics are the same.

1) You configure the port towards the customer that is sending you 802.1q tagged frames as an access-port in the S-VLAN (the "tunnel" VLAN). The S-VLAN is then configured on the trunk ports between the switches.

2) I'm guessing here that the port then would work like a normal access port, and when transported across switches there is only 1 802.1q field in the header, the one for the S-VLAN.

3) The switches that actually lead to customer ports (the access ports) have a special configuration for the S-VLAN and as such, they know that they need to be the ones to strip off the S-VLAN when a double tagged frame comes in and forward it as a single tagged towards the customer.

In JunOS the config goes like this:

root@EX2200# set vlans DOT1Q-TUNNEL-VLAN vlan-id 3000 dot1q-tunneling

So if this switch receives a frame with outer tag 3000, it will strip this off and forward it with only 1 802.1q tag towards the customer port, which is an access port in VLAN 3000.

Also a nice real world tip, if you have switches in the path between the customer access ports (for example if 1 end is on a POP location and the other in your DC edge) they need to account for the extra 4 bytes in the frame that double tagging the frame with both the C and S-VLAN requires.