This article serves as an overview of Detached VLANs, including what they are, and how they are designed to be used

Content / Solution:

A Detached VLAN is named because the VLAN is detached from all of the networking capabilities of the Network Domain. Traffic on a Detached VLAN is not routed outside the VLAN and therefore any Cloud Server NIC that is connected to the Detached VLAN can only communicate with other NICs on the same VLAN. The common use cases for Detached VLANs include:

"Heartbeat" VLANs

Clustering and other Database scenarios often require "heartbeat" connectivity where servers communicate to identify whether the other members of the cluster are "active" or not. By deploying a Detached VLAN and using it for the NIC's on each cluster member to communicate with each other, you can avoid unnecessary network connectivity and potential security issues, and the Cluster can better identify a node failure. 


Deploying Cloud Servers as Gateway Devices

If you want to deploy a Cloud Server that will act as an intermediary device between other Cloud Servers and the public Internet or CPNC connection, you can use a Detached VLAN to "force" traffic to route through the intermediary Cloud Server. There are a variety of use cases where this might be useful, including IP Masquerade, Virtual Firewall, or Network Intrusion. 

In these scenarios, you deploy the "outside" interface of the intermediate Cloud Server (usually the Primary NIC) to an Attached VLAN. You then deploy a second NIC to the intermediate server and attach it to the Detached VLAN.  You then deploy Cloud Servers onto the Detached VLAN and set up the Internet Gateway within the OS to direct traffic to the intermediate server's secondary NIC. This directs all outgoing traffic from the Cloud Servers to the intermediate Cloud Server, where it can be configured to route the traffic out through the Attached VLAN onto the Public Internet and/or CPNC.

To support this type of scenario, the Detached VLAN allows you to define the IPv4 and IPv6 Gateway addresses used on Cloud Servers when they are deployed using Guest OS Customization as described in How to Deploy a Cloud Server from a Guest OS Customization Image. When using this deployment method, the Primary NIC of such Cloud Servers will automatically be configured to direct traffic to your Intermediate device. You can manage this Detached VLAN gateway address configuration as described in How to View, Edit, Detach, Attach or Delete a VLAN on a Cloud Network Domain.

Detached VLANs and Static Routes

Because Detached VLANs bypass the Network Domain's routing and networking capabilities, users will often need to use Static Routes in conjunction with Detached VLANs. For example, if a user wanted to combine both the use cases above and wanted the resulting database cluster to be able to communicate with the Cloud Servers sitting behind the intermediate device, a user might need to define a static route such that traffic destined for the Cloud Servers located on the Detached VLAN can be received by the intermediate device and routed to those Servers.

In the example below, the "VNF Firewall" is an intermediate device protecting the Cloud Servers on the Detached VLAN with a IPv4 range. In order to allow the database servers to communicate with those Cloud Servers, a static route is established so that traffic destined to range is routed to the VNF Firewall's IP address on the Attached VLAN. Presumably, the VNF would then be configured to accept the traffic and route it to the Cloud Servers which are "detached" from the rest of the Network Domain.