Understanding QinQ and trunk port behaviour

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

Find more posts tagged with

Comments

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.

DANMOH009

Thanks for the reply, I use junos too (at work), but ye im guessing they will be the same.

So I get the configuration aspect of it, im trying to understand the switches lookup process/thinking during it. Sorry i should of made it clearer.

Normally the tagging is done at the trunk port, so im wondering whether or not in QinQ scenario is the tagging done at the access port??

and then does the trunk port just trust whatever tags it receives and when it comes out of the other end of the trunk port, is there something protected on the frame which stops it from stripping it off?

Im not sure if im really looking into it to much, or whether or not i even need to know this information but its really bugging me

tomtom1 wrote: »

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.

i think your right about this, it would make sense to just treat in as a normal frame