Deploy a Network Domain
Cloud Network Domains represent a "Virtual Private Data Center" within the Cloud infrastructure. Within this environment, you will deploy VLANs with user-defined private IPv4 address space and a system-defined IPv6 space. The ability to define the private IPv4 space is a key feature of MCP 2.0 locations. The private IPv4 space is routable within the Cloud Network Domain but is not routable outside a given Cloud Network Domain. This means that you can deploy multiple Cloud Network Domains with overlapping IPv4 addresses without having to worry about IP collisions.
There are two separate types of Cloud Network Domains, each of which has different usage-based pricing structures:
Essentials Network Domains provide the ability to deploy VLANs and Cloud Servers and manage traffic with NAT mappings and Firewall rules.
Advanced Network Domains add the ability to deploy two additional functions, which are:
VIP functions allow you to do load balancing and port translation functions between Public IPv4 addresses on your Network Domain and both private IPv4 and IPv6 addresses associated with the Cloud Network Domain. See Introduction to Virtual Listeners / VIPs in MCP 2.0
Server Anti-Affinity Rules allow you to prevent two Cloud Servers from operating on the same physical host on the CaaS infrastructure. This allows a load-balanced or clustered pair of servers to avoid being affected by the failure of a physical server on the infrastructure.
For details on creating, managing Network Domains, see:
- How to Deploy a Network Domain in a MCP 2.0 Data Center Location
- How to Manage a Network Domain in a MCP 2.0 Data Center
Deploy a VLAN
All Cloud Network Domains include the ability to add VLANs. Users define the RFC 1918 private IPv4 address for each VLAN. The system will then assign an IPv6 address block for the VLAN. The system will ensure that you do not assign the same IPv4 address space to different VLANs within the same Cloud Network Domain. However, if you have a CPNC connection, you must ensure you don't create VLANs that would conflict with private IPv4 space used on a CPNC-connected network. For more details, see Introduction to Cloud Private Network Connection (CPNC).
For details on creating and managing VLANs, see:
- How to Deploy a VLAN on a Network Domain in an MCP 2.0 Data Center
- How to View, Edit, or Delete a VLAN in a MCP 2.0 Data Center location
- How to Expand a VLAN on a Network Domain in a MCP 2.0 Data Center
Deploy a Cloud Server
Cloud Servers in MCP 2.0 locations can have one or more NICs, each of which can be connected to a separate VLAN. Each Cloud Server can have up to 10 NICs, each of which needs to have assigned its own private IPv4 and IPv6 from the IP space associated with the VLAN to which it's connected. Users can choose the private IPv4 address from the available pool in the NIC but the IPv6 address is assigned by the system.
On provisioning of a Cloud Server, users must define a "Primary NIC" for the Cloud Server. This NIC must remain attached to the VLAN for the life of the server and cannot be removed unless the Cloud Server is deleted. CloudControl uses this NIC for services such as Cloud Backup. All other NICs are designated "secondary NICs" and can be added or removed from the Cloud Server. However, changes to the NIC after the initial deployment remove the virtual NIC from the server but do not update the Guest OS of the change. Users will need to configure the Guest OS to deal with additional or removed NIC's after performing the action in CloudControl.
For details on creating and managing Cloud Servers in MCP 2.0, see:
- How to Deploy a Cloud Server from a Guest OS Customization Image
- How to Deploy a Cloud Server from a Non-Guest OS Customization Image
- How to Manage a Cloud Server
- How to Add an Additional NIC to a Cloud Server
- How to Remove a NIC from a Cloud Server
- Introduction to Cloud Server Provisioning, OS Customization, and Best Practices
All Cloud Network Domains include Firewall Rule capabilities that allow you to regulate both IPv4 and IPv6 traffic in and out of the Network Domain as well as to traffic between VLAN's within the Network Domain. As a general rule, traffic within a VLAN or outbound to the Public Internet is allowed, but any other traffic will require a firewall rule in place to allow it.
For more details on default IP traffic behavior and how firewall rules apply to it, we strongly recommend reviewing Introduction to Firewall Rules for Cloud Network Domains in MCP 2.0.
For details on creating and managing firewall rules, see:
In MCP 2.0 locations, the NAT is established on a Cloud Network Domain. In MCP 2.0, you can choose both the public IPv4 address for the NAT and any private IPv4 address within the allowed range (.11 through .254) - even if that private IPv4 address is not associated with a currently deployed VLAN. This means that the system will allow you to establish a NAT with any routed private IPv4 address - including those on external networks connected via a CPNC (Cloud Private Network Connection).
Once established, all IP traffic directed to the public IPv4 address will be routed to the private IPv4 address. In addition, outbound traffic from a Cloud Server associated with the private IPv4 address to any public IP address (even one on the same Network Domain) will appear to come from the public IPv4 associated with the NAT. Traffic to any other private IPv4 address within the Cloud Network Domain will continue to come from the private IPv4 address. IPv6 traffic is unaffected by the NAT as we currently support NAT only for IPv4 traffic. For more information on this aspect of behavior in MCP 2.0, see Introduction to IP Addressing and Routing in MCP 2.0 and How does Outbound IP traffic work on a Cloud Network Domain in MCP 2.0
For details on how to use NAT in MCP 2.0, see:
- How to Create a NAT Rule on a Network or Network Domain
- How to Delete NAT Rules from a Network or Network Domain
In order to securely access your Cloud environment, you can connect to it via Virtual Private Network (VPN).
For details on how to connect to your environment via VPN, see:
The Console Access feature allows you to troubleshoot your Cloud Server if an OS or VM Network failure occurs. Using this feature, you will be able to Console into your server to address issues which may render the Cloud Server unreachable via RDP or SSH.
For details on how to gain Console access, see: