So far we have set up routing on a single site, now we want to emulate a second site and configure a L2VPN tunnel creating a layer 2 stretched network. The idea is to emulate a two site deployment, with site 2 using a standalone edge.
I’m not including any screenshots of the site 2 build, try and built it just using the diagram.
Points to note:
– create a Transport Zone for the site 2, and add compute cluster B to it.
– remove the Web-Tier-LIF from the dLR
– site 2 does not have a dLR, only logical switches and a ESG
– Create a 3rd web server vm and add it to the site2-web-tier logical switch when ready
Configure site to site layer 2 vpn
Once the Site-2 ESG has been set up, we can start to configure a layer 2 vpn
Create the Trunk Interface on the original ESG in site-a
Once done, ping the gateway ip 172.16.10.1, and web-2 172.16.10.11 – both should respond
Ping app-1 172.16.20.10, and web-3 172.16.10.12, neither respond.
Create the SSL cert on the original ESG in site-a
Create Peer Site on Site-1 ESG (Edge Perimeter Gateway)
Set the listener
Enable L2VPN and afterward publish changes
It is now possible to see the Tunnel status, but it will be down as only one side has been configured
Create the Trunk Interface on the original Site2 ESG
Once the Trunk has been added from the VPN tab, change the mode to client
Add the client details, these will be what you used when creating the peer site on the site1 ESG
Don’t forget to enable and publish changes…
After a few seconds you can click on the Fetch Status button and hopefully, the Tunnel will be up
Lets run a few pings to see how it looks
Ping gateway (on ESG)
[root@web-1 ~]# ping 172.16.10.1 -c 2
PING 172.16.10.1 (172.16.10.1) 56(84) bytes of data.
64 bytes from 172.16.10.1: icmp_seq=1 ttl=64 time=9.82 ms
64 bytes from 172.16.10.1: icmp_seq=2 ttl=64 time=1.01 ms
Ping neighbor on same Tier and same site
[root@web-1 ~]# ping 172.16.10.11 -c 2
PING 172.16.10.11 (172.16.10.11) 56(84) bytes of data.
64 bytes from 172.16.10.11: icmp_seq=1 ttl=64 time=5.78 ms
64 bytes from 172.16.10.11: icmp_seq=2 ttl=64 time=1.14 ms
Ping vm in remote site, but on same tier
[root@web-1 ~]# ping 172.16.10.12 -c 2
PING 172.16.10.12 (172.16.10.12) 56(84) bytes of data.
64 bytes from 172.16.10.12: icmp_seq=1 ttl=64 time=11.6 ms
64 bytes from 172.16.10.12: icmp_seq=2 ttl=64 time=3.47 ms
The next test caused a headache, as I had configured configured a default gateway on web-1 [172.16.10.254] and in my case the local egress optimization ip was 172.16.10.1 once I reset the gateway on web-1 to 172.16.10.1, I was able to ping the vms on the other tiers/segments.
[root@web-1 ~]# ping 172.16.20.10 -c 2
PING 172.16.20.10 (172.16.20.10) 56(84) bytes of data.
64 bytes from 172.16.20.10: icmp_seq=1 ttl=62 time=7.48 ms
64 bytes from 172.16.20.10: icmp_seq=2 ttl=62 time=2.01 ms
[root@web-1 ~]# ping 172.16.30.10 -c 2
PING 172.16.30.10 (172.16.30.10) 56(84) bytes of data.
64 bytes from 172.16.30.10: icmp_seq=1 ttl=126 time=1.74 ms
64 bytes from 172.16.30.10: icmp_seq=2 ttl=126 time=1.81 ms
What I haven’t been able to do was reach the app and db tiers from the remote site. I’d image there is a way to do this, but it’s getting more into routing than I want, so I’ll leave it on the side for now
root@web-3 ~]# ping 172.16.10.10 -c 2
PING 172.16.10.10 (172.16.10.10) 56(84) bytes of data.
64 bytes from 172.16.10.10: icmp_seq=1 ttl=64 time=44.1 ms
64 bytes from 172.16.10.10: icmp_seq=2 ttl=64 time=3.10 ms
[root@web-3 ~]# ping 172.16.20.10 -c 2
connect: Network is unreachable
So we have stretched the L2 network, with direct connections to the edge devices in each site, no dLR is used, so the edge is a single point of failure and a possible bottleneck, HA deployment would be advised in Production.
Grateful acknowledgment to Giuliano Bertello, this is an elaboration of his blog, I have added my own diagrams, and my lab is 6.2 – he covers some of the technical aspects in more detail.