Stretch VLANs across routers L2TPv3
Recently, I have been working a good bit with DR network connectivity and other DR DCI concerns. A typical scenario today has a virtual environment in one Site as production and another virtual environment in another site, Site B, as a DR environment which has some type of replicated technology replicating VMs from Prod to DR. However, in most enterprise environments, different subnets are utilized at different sites as for the most part we DON’T want to stretch layer 2 in day to day operations. If you don’t have an SDN solution such as VMware’s NSX to stretch your layer 2, we can also stretch VLANs across routers with L2TPv3. Let’s take a look at the topic stretch VLANs across routers L2TPv3.
Stretch VLANs across routers L2TPv3
So, in a DR situation, you might need to spin servers up in your DR facility that would need to “think” they are on the same IP subnet they existed on in production. We need these VMs to be able to communicate just as they did before with all the other sites, even if it is in the foreign network in the DR site. In steps technologies such as L2TPv3.
The L2TPv3 uses what we think of as a pseudowire much as if you were going to physically stretch a cable from one datacenter to the other datacenter. In my case I was looking at simply stretching VLAN 1 which was carrying data from one site to the other site between (2) other sites. So Site A needed connectivity to Site B and then Site C also needed connectivity to Site B via layer 2 – same subnet.
Let’s look at an overview of the model built in GNS3 for testing. As you can see below, it is a pretty standard layout with (3) routers, a switch at each site and a couple of VPCs for testing.
Configuration
First things first, we have to setup a pseudowire-class, encapsulation, assign the pseudowire to an interface and then bridge the xconnect to a physical interface that we want to bridge traffic to/from. Below is the sample configuration. As you can see, on SiteA there are (2) interfaces which have xconnect configuration on them. The downside with xconnect is that you can’t have more than one xconnect tunnel per interface. So you basically burn an interface with xconnect as you can’t have an IP configuration on that particular interface that is hosting the xconnect tunnel. As you see below, I have Ehternet0/0 and Ethernet0/3 configured with xconnect in SiteA. As you see, these connect up with the other (2) sites.
The other sites, have tunnels back to SiteA via the Loopback0 IPs that you see configured. So xconnect basically bridges the Loopback0 interfaces with the physical interfaces on the router to pass layer 2 traffic to and from.
SiteA pseudowire-class l2tpv3test encapsulation l2tpv3 ip local interface Loopback0 ! ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Ethernet0/1 ip address 192.168.1.1 255.255.255.252 ! ! interface Ethernet0/0 no ip address xconnect 2.2.2.2 1 encapsulation l2tpv3 pw-class l2tpv3test ! interface Ethernet0/2 ip address 10.40.1.1 255.255.254.0 ! interface Ethernet0/3 no ip address xconnect 3.3.3.3 2 encapsulation l2tpv3 pw-class l2tpv3test ! ! SiteB pseudowire-class l2tpv3test encapsulation l2tpv3 ip local interface Loopback0 ! ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Ethernet0/0 ip address 192.168.1.2 255.255.255.252 ! interface Ethernet0/1 ip address 192.168.2.1 255.255.255.248 ! ! interface Ethernet0/2 no ip address xconnect 1.1.1.1 1 encapsulation l2tpv3 pw-class test ! ! SiteC pseudowire-class l2tpv3test encapsulation l2tpv3 ip local interface Loopback0 ! ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Ethernet0/0 ip address 192.168.2.2 255.255.255.252 ! ! interface Ethernet0/1 no ip address xconnect 1.1.1.1 1 encapsulation l2tpv3 pw-class test ! !
Troubleshooting commands
If you run the show xconnect all command you will see the active xconnects and if they are UP or DN. Also the show l2tun session is helpful in troubleshooting.
Also, I found after configuring xconnect on the interfaces in SiteA, I had to shutdown and bring back up the interfaces that xconnect was configured on before I received the “UP” status on the tunnels.
Final Thoughts
Network connectivity is something that often gets missed when thinking about a DR strategy. The focus is so much on how do we make sure our VMs or our data is in our DR facility, network connectivity sometime is an afterthought that only comes up when you are in that DR situation and need to establish connectivity between sites. The L2TPv3 functionality is a good way to do this on hardware that may not support other DCI technologies such as OTV.
