You are probably familiar with VLAN tagging on switch trunks and how it can be used to separate physical infrastructures into multiple logical networks. With the explosive growth of Metro Ethernet connections the ability of site to site layer two connections has now become common. It’s easy for organizations to implement as network admins are already familiar with Ethernet as a LAN protocol. The setup is simple for the customer but a bit more configuration is needed on the service provider’s side if the customer desires VLAN tagged traffic to flow over the site to site link.
Theory
Before looking at any configuration lets have a look at the frame layout. In an 802.1Q frame you would have something like shown below. 12 bytes of addressing, tag, ethertype and layer three payload.
------------------------------------------------------ | Ethernet | Tag | EtherType | Payload... ------------------------------------------------------ 12 4 2 x
To allow the service provider to continue using all 4096 VLAN ID’s without worrying about interference with customer tags the frame is simply expanded to add an additional tag. In the double tagged frame there are “inner” and “outer” tags known more officially as “S” and “C” tags. You can think “S” for service provider and “C” for customer. You will want to know the “S” and “C” terminology as other vendors reference it by that name in their configurations. The frames look something like this:
---------------------------------------------------------------- | Ethernet | S-Tag | C-Tag | EtherType | Payload... ---------------------------------------------------------------- 12 4 4 2 x
Implementation
Let’s implement this on some real world gear and see how things work. First, we must configure the MTU on the provider switches. This has to be bumped up to 1504 from the typical 1500 because of the added 4 bytes of the “outter” S-Tag.
SP(config)#system mtu 1504 Changes to the system MTU will not take effect until the next reload is done
Be prepared to reload the switch if needed. The MTU settings can then be verified with “show system mtu”.
Our network will be configured like this:
In this design we will configure the interfaces between service provider switches something like this:
SP1(config)# interface gi0/1 SP1(config-if)# switchport trunk encapsulation dot1q SP1(config-if)# switchport mode trunk SP1(config-if)# switchport trunk allowed vlan 100
We are dedicating only VLAN 100 to our customer’s traffic allowing all other VLANs for service provider later use. Now, let’s configure the customer facing edge ports.
SP1(config)# interface f0/1 SP1(config-if)# description Customer XYZ SP1(config-if)# switchport access vlan 100 SP1(config-if)# switchport mode dot1q-tunnel SP1(config-if)# l2protocol-tunnel
Basically what is happening is “access vlan 100” puts everything coming from the customer into VLAN 100 while “mode dot1q-tunnel” allows tags to be preserved rather than stripped as typically the case with access ports. The service provider will tag native VLAN frames as well but only with the “S-Tag” when traversing the providers switches. Additionally, I enabled “l2protocol-tunnel” which allows CDP, VTP and LLDP to flow over the service provider switches between customer switches as if they were directly connected.
A final consideration is if you will be tagging the customers native VLAN. I would suggest enabling this no matter what. This feature is activated with the global configuration mode command:
SP1(config)#vlan dot1q tag native
To verify the above configuration we can issue the “show dot1q-tunnel commands as shown below:
S1# show dot1q-tunnel dot1q-tunnel mode LAN Port(s) ----------------------------- Fa0/1
“show l2protocol-tunnel” will then show us the tunneling statisics of that configuration.
SP1#show l2protocol-tunnel COS for Encapsulated Packets: 5 Drop Threshold for Encapsulated Packets: 0 Port Protocol Shutdown Drop Encaps Decaps Drop Threshold Threshold Counter Counter Counter ------------------- ----------- --------- --------- --------- --------- --------- Fa0/1 cdp ---- ---- 3 3 0 lldp ---- ---- 0 0 0 stp ---- ---- 0 84 0 vtp ---- ---- 0 0 0 --- ---- ---- ---- ---- ---- --- ---- ---- ---- ---- ---- --- ---- ---- ---- ---- ----
From a customer device perspective you can also check the CDP neighbor information to see if the other sites switch is shown.
Site2SW#show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, D - Remote, C - CVTA, M - Two-port Mac Relay Device ID Local Intrfce Holdtme Capability Platform Port ID Site1SW Gig 0/1 131 S I WS-C2560- Gi 0/1
I hope this was helpful to anyone trying to better familiarize themselves with the QinQ concept and configuration!