Public IPv4 Addresses (Public Internet Routable)

In MCP 2.0 locations, Public IPv4 address blocks can be added on to the Cloud Network Domain to provide inbound connectivity from the Public Internet. Cloud Network Domains do not include any public IPv4 addresses by default. They must be added as described in How to Manage Public IPv4 Addresses on a Network or Network Domain. Public Cloud clients are charged for any additional public IPv4 addresses added to the Cloud Network Domain. For more details, see How are Public IP Addresses Billed for on the Cloud

Regardless of pricing, clients are allowed to deploy public IPv4 addresses onto a Cloud Network Domain only up to a maximum ratio of three public IP addresses per deployed Cloud Server. So if a customer has deployed a total of 10 Cloud Servers on a Cloud Network Domain, they are allowed to deploy only a maximum total of 30 public IP addresses on that Cloud Network Domain. This rule is enforced by CloudControl - the system will not allow you to add public IP addresses to a Cloud Network Domain that does not have enough deployed servers to meet the ratio. 

IPv4 VLAN Addressing

VLAN Address Ranges

When users deploy VLANs onto the Cloud Network Domain (as described in How to Deploy a VLAN on a Network Domain), they choose the /private IPv4 range to be associated with that VLAN. Users can choose either RFC 1918 or non-RFC 1918 space for these ranges. From a routing perspective, either type of addressing will function identically, so users should be aware of the potential impacts when choosing non-RFC 1918 space. For more details on routing, see Introduction to Routing, Network Domain Static Routes, and SNAT in MCP 2.0 Locations.

1. RFC 1918 IPv4 Addresses -  The following specific CIDR blocks/IP prefixes cannot be used:
   • 10.0.0.0/8
   • 172.16.0.0/12
   • 192.168.0.0/16
     • Note: This limitation is for these specific blocks only. Smaller blocks (such as 192.168.0.0/24) are permitted
   • Note:  /25 - /28 are 'small VLANs' and are subject to additional restrictions. See Introduction to Cloud Network Domains and VLANs for more details.
     
     
2. Non-RFC 1918 IPv4 Address - The system will allow you to assign non-RFC 1918 address space to VLANs so long as the non-RFC 1918 space does not conflict with any Public IPv4 blocks assigned to the Network Domain or with the system restricted ranges listed below. Additional rules apply:
   
   1. You cannot create VLAN that straddles both RFC 1918 and non-RFC 1918 address space.
   2. Each Network Domain uses a portion of the 100.64.0.0/10 range for transit routing. You cannot use this space for VLANs or any other purpose. It can be identified as the "outsideTransitVlanIpv4Subnet" element. This property is listed on the Network Domain dashboard. See Navigating the Network Domain Dashboard in a MCP 2.0 Data Center to identify where it is located.
   3. The following non-RFC 1918 address ranges also cannot be used for VLANs or any other purpose:

System-Reserved IP Address within VLAN Address Ranges

Although users can define the VLAN's IP address range, there are some restrictions on the use of such private addresses within the VLAN ranges

1. Server NIC IP addresses, Nodes, and NAT internal IP addresses cannot use the following in situations where the IP address being provided is within the IP range of a VLAN already deployed on the same Network Domain:
   1. The Network Address (x.x.x.0) at the start of a VLAN range (example: if you create a VLAN of 10.1.0.0/24, you cannot use 10.1.0.0)
   2. The Broadcast Address (x.x.x.255) at the end of the VLAN range  (example: if you create a VLAN of 10.1.0.0/24, you cannot use 10.1.0.255)
   3. For "Small Size VLANs":
      1. The first three IP addresses after the Network Address at the start of the VLAN range (i.e. the in the first octet) is reserved
      2. Example: if you create a "Small" VLAN of 10.1.0.0/28, you cannot use 10.1.0.1, 10.1.0.2, 10.1.0.3
   4. For "Low Address VLANs" 
      1. The first five IP addresses after the Network Address at the start of the VLAN range (i.e. the in the first octet) is reserved
      2. Example: if you create a "Low Address" VLAN of 10.1.0.0/24, you cannot use 10.1.0.1, 10.1.0.2, 10.1.0.3, 10.1.0.4, and 10.1.0.5.
   5. For "High Address VLANs" 
      1. The last three IP addresses before the Broadcast Address at the end of the VLAN range (i.e in the last octet) is reserved
      2. Example: if you create a "High Address" VLAN of 10.1.0.0/24, you cannot use 10.1.0.252, 10.1.0.253, 10.1.0.254 

IPv6 Addressing and Client-to-Site VPN Connectivity

MCP 2.0 locations provide full support for IPv6. CloudControl will assign a /64 block of IPv6 space to each VLAN deployed on the Cloud Network Domain. Unlike IPv4, the VLAN's IPv6 address space cannot be defined by the user and is assigned automatically by the system. With IPv6 addresses, the system reserves the first 32 IPv6 addresses in a VLAN for its own use, making available x:x:x:32-x:x:x:FFFF for use with NICs, NATs, and Nodes.

All IPv6 space on a Cloud Network Domain is publicly routable. In addition, traffic between different data center locations traverses an encrypted VPN mesh. For more details on routing and these unique capabilities, see Introduction to Routing, Network Domain Static Routes, and SNAT in MCP 2.0 Locations. Users should also be aware the "default" firewall rules on a Cloud Network Domain block much IPv6 traffic. For more information, see What Firewall Rules are in Place when I Deploy a Cloud Network Domain in MCP 2.0.

When a new Cloud Server is deployed, each NIC is assigned an IPv6 address along with the user-defined private IPv4 address. Depending on the deployment method, the NIC may be configured in the Guest OS as part of the deployment method. When a NIC is added to an existing server, the IPv6 address is "assigned" by CloudControl but always needs to be enabled within the Guest OS itself along with the private IPv4 address. For details, see How to Add an Additional NIC to a Cloud Server

 When using the Client-to-Site VPN to access a Cloud Server as described in How to Establish a Secure VPN Connection to Access your Cloud Network and Servers, users must use SSH or RDP to connect to the IPv6 address of the Primary NIC rather than the private IPv4 address used in MCP 1.0. This is necessary since users can use the same private IPv4 address across multiple Cloud Network Domains. Users are free to change IP NIC assignments at any time as described in How to Notify CloudControl of a Change to the IP Addresses of a NIC in a MCP 2.0 Data Center.

IP Uniqueness and Exclusive Reservation of IP Addresses

IP Uniqueness Policy

CloudControl tracks which IP addresses are in use by NIC's attached to Cloud Servers on the Cloud Network Domain. However, users can assign the same IP address to different Cloud Server NICs on the same VLAN. Such behavior has the potential to cause IP conflicts when multiple servers broadcast the same IP address on a VLAN but non-unique address assignments are also required in a variety of scenarios. For example, database and application clusters often involve multiple servers with the same IP address. Network appliances such as firewalls, routers, and load balancers may also use a floating address. Creating a new Cloud Server from a Snapshot will also likely create a server with duplicate IP address.

A few notes and restrictions on the uniqueness policy

1. The system requires a unique IPv4 private address on each NIC when deploying a Cloud Server using Guest OS Customization as described in How to Deploy a Cloud Server from a Guest OS Customization Image. However, once the server has been deployed, users can change the IPv4 addresses and uniqueness is no longer enforced.
2. To help avoid and diagnose IP conflict issues, the system allows you to "disconnect" a NIC while leaving a server powered on, allowing you to remove connectivity to the VLAN while maintaining the server in a powered on state so that you can access the Guest OS to diagnose issues. For details, see Introduction to Cloud Server NICs in MCP 2.0.
3. The UI will notify of potential IP conflicts based on its record of the IPv4 NIC address assignments if the following conditions are met:
   1. Two (or more) devices share the same IP Address
   2. The devices are powered on
   3. The NICs are connected

Therefore, if a change is made to the assigned private IPv4 address or IPv6 of a NIC on a Cloud Server, clients should update the Cloud system record as described in How to Notify CloudControl of a Change to the IP Addresses of a NIC in a MCP 2.0 Data Center.

IP Exclusive Reservations

To avoid IP conflicts, the system allows users to "reserve" IP addresses:

1. "Exclusively reserving" an IPv4 or IPv6 address prevents the use of the IP address going forward from the time of the reservation. This means that once an IP address is exclusively reserved, the system will not allow that IP address to be assigned to a NIC when deploying Cloud Servers, adding a NIC, notifying the system of a change to an IP address, or when creating a new Cloud Server from a Snapshot.
   1. If this address is uniquely used at the time the IP is designated as exclusively reserved, this means it will stay uniquely assigned thereafter.
   2. However, an exclusively reserved address doesn't ensure uniqueness as the IP address may have been used on multiple Cloud Server NICs prior to its designation as exclusively reserved.
2. The system supports entry of a "description" as to why the IP address is being exclusively reserved to help users identify the reason for the reservation.
3. When a Cloud Server or NIC is deleted, if the associated IP address is exclusively reserved and the NIC is the only object known to CloudControl to be using the IP address, the exclusive reservation is removed along with the NIC/server.
4. VLANs cannot be deleted if an IP address is exclusively reserved on them. The reservation must be removed in order to allow deletion.

For more details on exclusive reservations, see:

• How to View the IP Addresses Currently In Use and/or Exclusively Reserved on a VLAN
• How to Exclusively Reserve an IPv4 or IPv6 Address
• How to Unreserve an IPv4 or IPv6 Address

MAC Address Uniqueness

Cloud Server deployments from a Customer or OS Image will result in a Cloud Server with unique MAC addresses on the NICs that are different than the source Image. However, when creating a Cloud Server from a Historical Snapshot as described in How to Create a Snapshot Preview Server from a Local Snapshot, users can choose to maintain the snapshot's MAC address. Preserving the MAC Address opens up the possibility of a MAC address conflict similar to the IP address conflict described above. Users are recommended to use the connected/disconnected NIC functionality to avoid MAC address conflicts in this scenario.

Related Articles

• Page:
  Introduction to SSL Offload, including SSL Domain Certificate, SSL Certificate Chain, and SSL Offload Profiles
• Page:
  Introduction to Security Groups
• Page:
  Introduction to Health Monitors at an MCP 2.0 Data Center
• Page:
  Introduction to Persistence Profiles at an MCP 2.0 Data Center
• Page:
  Introduction to IP Addressing in MCP 2.0