Thursday, October 4, 2012

QinQ (inQ) Part 1

This week I added 3 x 3560's to my home lab. I don't feel that overall I'm especially weak on the layer 2 topics, in fact I think quite the opposite is true. However, access to 3560's for labbing purposes has always been a bit harder for me so I decided to buy three of them out of my own pocket to help with the preparation. And besides, these are full layer 3 switches so I can also use them to help out with the routing topics as well.

So for anyone counting, that brings my lab to 3 x 1841, 3 x 3560, 1 x 2621xm and 1 x 2621. I do also have a 2950 and a 3500xl, but those are at my office and I'm not currently using them for labbing. This should be enough for me to lab up any tech that I need to.

Seeing as how the 2560's are new to me I of course wanted to play with something on them that I haven't been able to do on my routers. By a purely random selection that ended up being QinQ tunneling.

So without further ado here's an actual blog post!

QinQ tunneling is officially defined by the 802.1ad Provider Bridges standard. This is not to be confused with 802.3ad Link Aggregation (of which LACP is a part of), though later on in this post I will be using some LAG's in the configuration. QinQ tunneling is a method by which frames received on a switchport are tagged with an additional 802.1Q tag to any that are already contained within the layer 2 headers. The goal is to allow providers to transport customer VLAN information across their backbones unmodified. This process is transparent to the customer as two switches (or more) at different sites will appear to be directly connected to each other.

I think that if you're here, and you're reading this post then you likely know what QinQ is, and have seen better explanations that what I just did above. To that end, let's dispense with the chatter and configure this stuff up.

I'm going to start with the following topology:

I'm using routers as the customer equipment here, but that's irrelevant really since all the magic happens on the switches. But, I am using subinterfaces with dot1q encapsulation on the routers to generate tagged frames that will enter the provder network. Here's the simple interface configs I'm using on both routers:

Also preconfigured is the etherchannel between SW1 and SW2. Again, nothing special here, just a simple LACP bundle, and the ports configured for static trunking using 802.1q. Four ports of config is a little long, and I need to work on my usage of show commands, so here's some show commands to illustrate instead!sw1#sh ether 12 sum | beg GroupGroup Port-channel Protocol Ports------+-------------+-----------+-----------------------------------------------12 Po12(SU) LACP Fa0/21(P) Fa0/22(P)

You'll notice that I've created VLAN 99. I've done that because VLAN 99 is going to be the VLAN that I use as the second 802.1Q tag, also called a Metro tag, for the customer frames that traverse my provider network. How exactly do we do this? We do this with a little hard work, determination, and the following commands (the following commands were entered without any hard work or determination).

First we should start with MTU. The Catalyst 3560's I'm using here have a default system MTU of 1500 bytes.

We just did two things here. First off we specified an access VLAN of 99. In this context the switchport access vlan defines the tag that we are going to use as our metro tag as frames move across our backbone. If you think about it this effectively is the same mechanism that you're enabling when you're configuring an access port. The difference here is the mode: switchport mode dot1q-tunnel. By enabling this mode we are telling the interface to allow frames that are entering the interface already tagged to be accepted, and tagged again with the value specified by the switchport access vlan command.

A third command is present in the config; CDP is now disabled. That is something that automatically happens when you enable the dot1q tunneling mode.