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:
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.