4.6.3 VXLAN Example Testing Summary
The following sections provide an overview of some of the testing conducted to validate using VXLAN to simplify vCloud DR recovery.
4.6.3.1. Test 1 – Prove Connectivity and Verify NAT Configuration
The purpose of this test is to verify that predefining connections to both the production and recovery sites is viable, and that following a disaster recovery scenario the required connectivity can be established to a recovered vApp. The following is the high-level test procedure.
To prove connectivity and verify the NAT configuration
1. Validate connection to the vApp from a client device on the production external network 10.16.133.0/24 (SSH was used).
2. Change the default route defined on the vCloud Networking and Security Edge Gateway from the Internet network to the Internet_DR network and validate connectivity to the vApp. This uses the directly attached network so connectivity is maintained.
3. Fail over the vApp to the recovery site.
4. Validate connection to the vApp from a client device on the production external network 10.16.133.0/24. It fails, because the NAT addressing of the vApp is no longer connected to the directly attached vCloud Networking and Security Edge interface on the 10.16.133.0/24 network.
5. Enable the previously disabled SNAT/DNAT rules and validated connectivity from a client device on the failover external network 192.168.192.0/24 (Internet_DR) to the new address translated with NAT.
6. Remove the original Internet external network so that all connectivity is forced through the desired Internet_DR external interface on the vCloud Networking and Security Edge Gateway.
7. Validate connectivity from the vApp to the original client device on the 10.16.133.0/24 network (Internet) to the original client device (global routing between Internet and Internet_DR network should permit this to take place). This works because the Sophos UTM performs a NAT translation of the 192.168.192.0/24 to 10.16.1333.0/24 network on behalf of the vCloud Networking and Security Edge device.
During testing, the first three steps behave entirely as expected. Network traffic from the Internet network can successfully pass to the virtual machine defined in the vApp. Similarly, if the appropriate DNAT rule is enabled, network traffic can pass from the Internet_DR network.
When attempting to validate step 4,
despite reconfiguring the connection to the Internet_DR network as the default route,
connections are still attempting to leave the vCloud Networking and Security
Edge Gateway device over the original locally attached Internet interface. If the client device is then connected to the Internet_DR network with an appropriate IP address,
then network connections can be established as expected. The following figure
illustrates the end result of this test.
Figure 18. Removed External Network
To make sure that network connections are directed over the correct interfaces on the vCloud Networking and Security Edge Gateway, the only “fail safe” option is to remove the Internet external network, forcing all network traffic over the interface connected to the Internet_DR network.
NoteWhen an external network is removed from an Edge Gateway, any rules associated with it are deleted. In this scenario all predefined SNAT/DNAT rules were deleted.
4.6.3.2. Test 2 – Disable vCloud Networking and Security Edge Gateway vNICs
The purpose of this test is to investigate alternative methods to make sure that network traffic is routed over a specific interface on an Edge Gateway. The approach verifies that disconnecting a virtual adapter takes the interface down. This prevents network traffic from being passed to the incorrect interface. The following is the high level test procedure.
To verify lack of network connectivity
1. Attempt to connect to vCenter Server, navigate the inventory, and edit the Connected status of the virtual machine settings. In vCenter Server the option to edit the configuration of the vCloud Networking and Security Edge (Edge) appliance is disabled.
2. Repeat Step 1 on the ESXi host on which the Edge device is running.
In ESXi the option to edit the configuration of the Edge appliance is enabled
3. Repeat the network connectivity steps defined in Test 1
, Step 4 – Despite disabling the network adapter the Edge device continues
to try to route packets over the original interface.
Although the ability to update the Edge device settings is disabled within vCenter Server, it is still accessible by connecting directly to the ESXi host on which the appliance is running. The key observation is that, despite disabling the virtual adapter for the Edge appliance, the guest OS of the Edge device does not correctly detect that the interface is down. The hardware change is detected as “protocol down, device up.”
4.6.3.3. Test 3 – Prove Connectivity and Verify NAT Configuration Including Failover
This test is a repeat of Test 1, but both the vCloud Networking and Security Edge Gateway (Edge Gateway) and vApp are made to fail and are then brought online at the recovery site. The following figure illustrates the end result of this test.
Figure 19. Test 3 End Result
The result of this test is consistent with the Test 1 result, even with the added changes of failing over the vApp and Edge Gateway device.
Testing and validation results
in a solution that can help simplify the deployment of vCloud Director DR solutions in the absence of stretched Layer 2 networking. Furthermore,
this solution is complementary to the solution already defined in the VMware vCloud Director Infrastructure Resiliency Case Study (
http://www.vmware.com/files/pdf/techpaper/vcloud-director-infrastructure-resiliency.pdf) and can be implemented with relatively few additions to the existing vCloud DR recovery process.
