Metacloud
In this Solution:
- Connecting a Metacloud network to an external VLAN
- Connectivity issues
- Troubleshooting this scenario
Creating a network segment in which servers on separate networks appear to be on the same subnet is a common practice with various benefits, such as simplification of network design and management. If connectivity issues occur in such a segment between Metacloud VMs in a Neutron network and servers in a virtual LAN (VLAN) in your datacenter, you may need to adjust how traffic is routed.
This solution provides an example of how routing adjustments correct connectivity issues between Metacloud and an external VLAN.
Connecting a Metacloud Network to an External VLAN
For example, a company has a subnet with an address space 192.168.1.0/24. Some IP addresses in this range correspond to physical servers on a VLAN, numbered 1001, in the company's datacenter. Other addresses in the range are floating IPs for VMs in a Metacloud private network.
The VLAN is behind a Cisco Adaptive Security Appliance (ASA) firewall, which is the next-hop default gateway for a Metacloud network Cisco Asynchronous Services Router (ASR). This router provides virtual routing and forwarding (VRF) for the isolated Metacloud network. It also serves as a network address translation (NAT) proxy for the VMs, translating the floating IPs to real IPs for the Metacloud VMs.
Within Metacloud, the VLAN appears as an external network and is intended to be a Level 2 bridge between the physical servers and the VMs.
Connectivity Issues
Despite sharing the IP address space, the physical servers cannot communicate with the VMs. Server1 in the VLAN sends ICMP pings and SSL connection requests to VM1 in the Metacloud network but receives no response. The first troubleshooting step is to verify that the VMs include security groups that permit SSH ingress and don't block ICMP ingress. See Configuring Access and Security for Instances with CLI for more information.
The second step is to examine the routing between the servers on VLAN 1001 and the Metacloud VMs. In a traditional Layer 2 network configuration, computers sharing a network segment exchange packets directly. Server1 sends packets to the floating IP address of VM1, as if that address is the next-hop destination of those packets. However, Server1's outbound packets go through the ASR, which performs NAT and forwards the packets to VM1's actual IP address, 10.10.10.100.
VM1 sends reply packets back to the ASR, which does not use address routing protocol (ARP) lookups to route the packets directly back to Server1. Instead, it uses the next-hop IP address of the default gateway, which is the ASA. By default, the ASA is not configured to provide hairpinning, in which a connection traverses a router to an external network and back in by connecting to an internal resource using its external IP address. The ASA drops the packets from VM1.
The following diagram shows current routing scheme:
Troubleshooting this Scenario
The solution* is to:
- Configure the IP addresses and subnet masks of the affected physical servers, including Server1, so that they are one hop away from VLAN 1001, meaning they are on a different subnet than the VMs. Depending on how networks are configured in your datacenter, it may also involve physically moving and re-cabling the servers to attach them to the new subnet.
- Route outbound traffic from these servers through the ASA, since this firewall is the edge into the Metacloud environment. This involves re-configuring the default gateway on the servers to the IP address of the ASA.
- Ensure that the ASA is configured with security policies and routing information that enable traffic to and from the ASR.
*Note: The customer would be responsible for making these changes to VLAN 1001.