From part one, we know that the purpose of a QinQ tunnel is to extend a VLAN across the WAN or network. But what if site 1 is connected to site 2 and they use different IP schemes (such as 10.1.250.0/24 and 10.100.250.0/24)? Well, making the two talk is actually very simple.

The way I have configured this is to set up a loopback interface on each side to emulate the different network, and set up routes between them. If you recall from part 1, I am using a 3550 on one side and a 3750 on the other.

We start by enabling IP routing on both sides:

3550(config)#ip routing

3750(config)#ip routing

Then we assign a virtual IP address to the VLAN:

3550(config)#int vlan 501
3550(config-if)#ip address 10.250.1.21 255.255.255.0

3750(config)#int vlan 501
3750(config-if)#ip address 10.250.1.20 255.255.255.0

And then we create our loopback interfaces to emulate the different networks:

3550(config)#interface Loopback2
3550(config-if)#ip address 10.1.250.1 255.255.255.0
 
3750(config)interface Loopback2
3750(config-if)#ip address 10.100.250.1 255.255.255.0

Lastly, we set a routing statement with the destination network and the destination IP address, which is the virtual IP address of the VLAN at the other side

3550(config)#ip route 10.100.250.0 255.255.255.0 10.250.1.20

3750(config)#ip route 10.1.250.0 255.255.255.0 10.250.1.21

Now we should be able to ping the loopback in each site:

Pretty neat!

QinQ tunnels are not without their issues, though. Because they operate at layer-2, they ae susceptible to issues with spanning-tree, so it is best (if you do have different subnets at each side) to disable spanning-tree on the interfaces. There are also issues with HSRP, which can really screw up an entire datacenter (or both). There is nothing worse than one datacenter (on a different IP range) thinking that it should be the HSRP master for a different site. You can read about such issues in the third part of this series: Why QinQ tunnels and HSRP do not play well together.