802.1 Q-in-Q Tunneling

Leave a Comment / Etherchannels, Networking, Switching / By /

802.1 Q-in-Q tunneling is a technique that can extend a VLAN from one data center to another without AToM or VPLS. Essentially, Q-in-Q tunneling adds another .1q tag to your packet as it traverses the Service Providers network. This keeps your traffic segregated from any other company, following the same principle of how VLANs segregate broadcast domains. Also, companies A and B can have the same VLANs traversing the service provider. Still, this is allowed because the service provider uses a different VLAN for each customer. As we can see from the diagram below, we have two companies participating in a Q-in-Q implementation

The diagram we will be looking at has only one company in it.  We use Q-in-Q tunneling from our NYC data center to our LA data center. Please note if you do plan on implementing this, your service provider must have a layer 2 end-to-end network for this to function correctly.

We are configuring layer 2 reachability from our FTP server in the NYC data center to our management server in the LA data center.

Before we get into the configurations, there are a few things to point out;

  • The service provider must extend their VLANs across their infrastructure
  • You can not dynamically build trunks.
    • You must statically enable them.

Before the configuration, if we tried to ping from the end station, it would fail with the following errors.

FTP_1#ping 14.0.0.4 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 14.0.0.4, timeout is 2 seconds:
*May 1 03:09:13.430: IP: tableid=0, s=14.0.0.1 (local), d=14.0.0.4 (FastEthernet0/0.14), routed via RIB
*May 1 03:09:13.430: IP: s=14.0.0.1 (local), d=14.0.0.4 (FastEthernet0/0.14), len 100, sending
*May 1 03:09:13.430: ICMP type=8, code=0
*May 1 03:09:13.430: IP: s=14.0.0.1 (local), d=14.0.0.4 (FastEthernet0/0.14), len 100, encapsulation failed
*May 1 03:09:13.430: ICMP type=8, code=0.
Success rate is 0 percent (0/1)

We see that we are failing because it can not encapsulate the packet. Now let’s implement the change. All that we would have to concern ourselves with if this was in a production environment is configured on our NYC and LA devices.

Configuration examples

# NYC-DC-SW1 Config
NYC-DC-SW1(config)#vlan 456
NYC-DC-SW1(config-vlan)#exit
NYC-DC-SW1(config)#int fa3/1
NYC-DC-SW1(config-if)#switchport mode dot1q-tunnel
NYC-DC-SW1(config-if)#switchport access vlan 456
NYC-DC-SW1(config-if)#exit
NYC-DC-SW1(config)#int fa3/13
NYC-DC-SW1(config-if)#switchport trunk encap dot1q
NYC-DC-SW1(config-if)#switchport mode trunk
NYC-DC-SW1(config-if)#end
NYC-DC-SW1#

# ISP-PE1 Config
ISP-PE1(config)#interface range fa0/13 , fa0/16
ISP-PE1(config-if-range)#switchport trunk encapsulation dot1q
ISP-PE1(config-if-range)#switchport mode trunk
ISP-PE1(config-if-range)#exit
ISP-PE1(config)#vlan 456
ISP-PE1(config-vlan)#end
ISP-PE1#

# ISP-PE2 Config
ISP-PE2(config)#int range fa0/16 , fa0/19
ISP-PE2(config-if-range)#switchport trunk encapsulation dot1q
ISP-PE2(config-if-range)#switchport mode trunk
ISP-PE2(config)#vlan 456
ISP-PE2(config-vlan)#end
ISP-PE2#

# LA-DC-SW1 Config
LA-DC-SW1(config)#vlan 456
LA-DC-SW1(config-vlan)#exit
LA-DC-SW1(config)#int fa6/19
LA-DC-SW1(config-if)#switchport trunk encap dot1q
LA-DC-SW1(config-if)#switchport mode trunk
LA-DC-SW1(config-if)#exit
LA-DC-SW1(config)#interface fa4/4
LA-DC-SW1(config-if)#switchport mode dot1q-tunnel
LA-DC-SW1(config-if)#switchport access vlan 456
LA-DC-SW1(config-if)#end
LA-DC-SW1#

If we look at a configuration snippet from NYC-DC-SW1, we have to tell the port connecting to the end station OR to the uplink switch to be in switchport mode dot1q-tunnel. We also need to give it the service provider VLAN identifier, which in the above scenario is VLAN 456.

Ping Verification

After implementing Q-in-Q tagging, we will see that the pings are successful.

FTP-1#ping 14.0.0.4 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 14.0.0.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
R1#
*May 1 03:17:57.746: IP: tableid=0, s=14.0.0.1 (local), d=14.0.0.4 (FastEthernet0/0.14), routed via FIB
*May 1 03:17:57.746: IP: s=14.0.0.1 (local), d=14.0.0.4 (FastEthernet0/0.14), len 100, sending
*May 1 03:17:57.746: ICMP type=8, code=0
*May 1 03:17:57.750: IP: tableid=0, s=14.0.0.4 (FastEthernet0/0.14), d=14.0.0.1 (FastEthernet0/0.14), routed via RIB
*May 1 03:17:57.750: IP: s=14.0.0.4 (FastEthernet0/0.14), d=14.0.0.1 (FastEthernet0/0.14), len 100, rcvd 3
*May 1 03:17:57.750: ICMP type=0, code=0

The next blog post will look at Q-in-Q tunneling using EtherChannel.