Description

This article provides an explanation as to how IP traffic is routed both within a Network Domain and outbound traffic leaving the Network Domain, including how Network Domain Static Routes control this traffic and how SNAT (Source NAT) may affect IPv4 traffic.

Managing Static Routes and SNAT Exclusion Lists Requires Enterprise Network Domain

Static Routes and SNAT Exclusion Lists are visible in all Network Domains but management functions are restricted to Enterprise Network Domains. For details on the different types of Network Domains and their capabilities, see Introduction to Cloud Network Domains and VLANs

Content / Solution:

 

Detached VLANs have NO routing capabilities

Detached VLANs do not have any routing capabilities and cannot directly communicate to other VLANs. Server NICs on a Detached VLAN can only communicate with other IP addresses on the same VLAN. Therefore, nothing related to routing in this article applies to Detached VLANs.

Note that it is possible to deploy a Cloud Server to act as an intermediary to route traffic from a Detached VLAN, particularly when done in conjunction with Client Static Routes. For an overview, see Introduction to Detached VLAN Use Cases.

IPv4 and IPv6 Routing Between Attached VLANs Within the Network Domain

In most cases, IPv4 and IPv6 traffic originating from an Attached VLAN in the Network Domain to a destination IPv4 or IPv6 address that is within the IP address range of a different VLAN in the Network Domain will be routed internally to the destination VLAN, subject to the firewall rules of the Network Domain. This is true even if the IP address range of the VLAN is non-RFC 1918 address space. These internal routing rules ensure that "private" IPv4 traffic is routable within the Cloud Network Domain. 

The only exception occurs if a Client Network Domain Static Route has been defined that is more specific (i.e. "smaller") than the IP address range of the VLAN. In that case, traffic will be routed to the next hop address defined by the static route instead of the internal route. Client Network Domain Static Routes are discussed in more detail below.

SNAT (Source NAT) Behavior on a Network Domain

Each Cloud Network Domain has a SNAT (Source NAT) that is designed to allow outbound IPv4 traffic destined for the Public Internet  to originate from a single public IPv4 address associated with that Network Domain. You can identify this public IPv4 address on a given Network Domain as the SNAT IPv4 Address described in Navigating the Network Domain Dashboard in a MCP 2.0 Data Center. This SNAT Is necessary in many circumstances in order for Cloud Servers with private RFC 1918 addresses to communicate with the Public Internet, since their native addresses are not routable.

However, unless bypassed, the SNAT will affect all traffic destined to any IPv4 address routed by the Network Domain, including traffic to and from the Public Internet, CPNC gateway, or any other "next hop" address defined by the Network Domain static route table. The three scenarios where the SNAT is bypassed are:

  1. Traffic flowing through a NAT (either inbound or outbound) will bypass the Route Domain's SNAT
  2. Traffic flowing into a VIP will bypass the Route Domain's SNAT
  3. Traffic destined to any IPv4 address range listed on SNAT Exclusion List will bypass the Route Domain's SNAT

Unless modified, each Network Domain has a SNAT Exclusion List of System enties that is set up to bypass the SNAT for the following scenarios:

  1. All Traffic destined for all RFC 1918 address space bypasses the SNAT
  2. All Traffic destined for Non-RFC 1918 address ranges of Attached VLANs bypasses the SNAT

Users who modify the SNAT Exclusion List on an Enterprise Network Domain should be aware that the SNAT Exclusion applies to all traffic destined for the IPv4 ranges specified on the SNAT Exclusion List whether that traffic originates from VLANs within the Network Domain or is incoming from a CPNC connection. For example:

  • If the RFC 1918 ranges are removed from the SNAT Exclusion list, RFC 1918 traffic between VLANs will now pass through the SNAT and traffic from one VLAN to another will appear to be coming from the SNAT IP address
  • If "public" IPv4 ranges that route to the Public Internet are removed from the SNAT Exclusion list, the traffic will no longer pass through the SNAT and will be dropped as given the source IP address isn't publicly routable

API Only Support for Network Domain Static Routes until February 2019

UI Support for the viewing and management of SNAT Exclusion Lists will not be introduced until February 26, 2019.

Between January 24th and February 26th, users wishing to add or delete a range from the SNAT Exclusion List will need to use the CloudControl API to make the changes via the appropriate API functions. We have provided "API Articles" below to support users who are unfamiliar with using the CloudControl API. Complete UI documentation will be provided in conjunction with the February 2019 UI release. Contact support if you need assistance in managing SNAT Exclusion Lists via API in this time period.

 The SNAT Exclusion List of a Network Domain can be viewed as described in:

On Enterprise Network Domains, the SNAT Exclusion List can be modified as described in

System Network Domain Static Routes Providing External IPv4 Routing

IPv4 traffic from Attached VLANs that is not routed within the Network Domain will be routed externally to the Network Domain based on the IPv4 System Network Domain Static Routes. When a new Network Domain is deployed, it has four System Network Domain Static Routes that direct traffic either to the Public Internet or the gateway associated with the Cloud Private Network Connection (CPNC) service. CPNC allows you to interconnect your Network Domain with external networks such as other Cloud Network Domains (in the same or different data center locations), your corporate network, or our Managed Hosting environments. This service currently must be configured outside the CloudControl system. For more details on the CPNC offering, see Introduction to Cloud Private Network Connection (CPNC)

The four System static routes associated with a new Network Domain look like:

NameDescriptionTypeIP VersionDestination Range

Next Hop Address

(address differs per Network Domain)

cpnc_10.0.0.0_8Network Domain route to CPNCsystemIPv410.0.0.0/8

IPV4_CPNC_GATEWAY_IP

cpnc_172.16.0.0_12Network Domain route to CPNCsystemIPv4172.16.0.0/12IPV4_CPNC_GATEWAY_IP
cpnc_192.168.0.0_16Network Domain route to CPNCsystemIPv4192.168.0.0/16IPV4_CPNC_GATEWAY_IP
inet_default_ipv4Default IPv4 route to InternetsystemIPv40.0.0.0/0IPV4_INTERNET_GATEWAY_ADDRESS

The first three static routes are designed to direct all RFC 1918 traffic that is not directed to a VLAN IPv4 range on the same Network Domain to the CPNC Gateway, where it can be routed to whatever external networks you've enabled for CPNC. The last static route ensures that any non-RFC 1918 traffic not matching another Network Domain Static Route or a deployed VLAN (as described in the section above) is routed to the Public Internet through the IPv4 Internet Gateway. Note the specific IPv4 and CPNC gateway addresses are different for each Network Domain.

These IPv4 System static routes cannot be modified on an Essentials or Advanced Network Domain. The ability to delete System static routes is reserved for Enterprise Network Domains, which also allow you to create new static routes as described in the Client Network Domain Static Routes section below.

System Network Domain Static Routes Providing External IPv6 Routing

IPv6 traffic that is not routed within the Network Domain will be routed externally to the Network Domain based on the IPv6 System Network Domain Static Routes. All IPv6 space on a Cloud Network Domain is publicly routable. Unlike IPv4 traffic, outbound IPv6 traffic will be routed to public Internet destinations without any type of SNAT address translation. 

When a new Network Domain is deployed, it has a single System Network Domain Static Route that directs all IPv6 traffic to the Public Internet:

NameDescriptionTypeIP VersionDestination Range

Next Hop Address

(address differs per Network Domain)

inet_default_ipv6Default IPv6 route to InternetsystemIPv6

::/0

IPV6_INTERNET_GATEWAY_ADDRESS

This IPv6 System static route cannot be modified on an Essentials or Advanced Network Domain. The ability to delete System static routes is reserved for Enterprise Network Domains, which also allow you to create new static routes as described in the Client Network Domain Static Routes section below.

IPv6 Traffic Between Public MCPs is Encrypted. Inter-Public MCP is also WAN Accelerated

IPv6 communication between Cloud Network Domains in different MCP 2.0 Data Center Locations occurs across a site-to-site VPN mesh that interconnects all the data center locations. This applies even if the locations are in different Geographic Regions.

Traffic between public MCP 2.0 locations also uses WAN Optimization technology to improve performance. For most types of unencrypted traffic, this means that when communicating between Public MCP data centers, you will see the best performance when using IPv6 for initiating communication. However, to take full advantage of this capability, make sure you're sending data using unencrypted protocols. The site-to-site VPN will already provide encryption and the WAN optimization functionality works best with unencrypted traffic as it optimizes the traffic prior to the encryption. WAN acceleration applies to traffic between the following public MCP 2.0 locations:

  • North America: NA9, NA12
  • Canada: CA2
  • Europe: EU6, EU7, EU8
  • Africa: AF3
  • Australia: AU9, AU10, AU11
  • Asia-Pacific: AP3, AP4, AP5

Default Firewall Rules Block IPv6 Traffic In and Out of the Network Domain

Note that although IPv6 addresses are publicly routable, the "default" firewall rules on a Cloud Network Domain block such traffic. Clients who want the IPv6 addresses on their Cloud Servers available to the Public Internet will need to modify these default rules. For more information, see What Firewall Rules are in Place when I Deploy a Cloud Network Domain in MCP 2.0.

Client Network Domain Static Routes

Users may choose to implement their own Client Network Domain Static Routes or to modify the System ones. Prior to October 11, 2018, such changes could be made by users opening a support ticket with the details of the request. The resulting static routes were manually configured by the Support team and were not visible within the UI or API. Effective October 11, 2018, such static route changes must be made via CloudControl and the ability to create new Client Network Domain Static Routes or deleting System Network Domain Static routes is restricted to Enterprise Network Domains

Users are allowed to define "Client" Network Domain Static routes that specify the IPv4 or IPv6 range and the Next Hop Address to which the traffic may be directed. The Next Hop Address allows you to route traffic to:

  1. The IPv4 or IPv6 Public Internet Gateway Address (this can be identified as described in Navigating the Network Domain Dashboard in a MCP 2.0 Data Center)
  2. The IPv4 CPNC Gateway Address (also visible in Navigating the Network Domain Dashboard in a MCP 2.0 Data Center)
  3. Any IP Address on an Attached VLAN

In creating such Client Network Domain Static Routes, remember the system will utilize the most specific route, including the Internal routes that support traffic between different VLANs within the Network Domain as described in the IPv4 and IPv6 Routing Between Attached VLANs Within the Network Domain section above. 

Users can create new routes and delete existing ones, but routes cannot be edited in place. The system also provides a function that allows a user to restore a Network Domain to the "standard" System Network Domain Static Routes as described above. This function can be useful if you wish to "play around" with Client Network Domain Static Routes, and then return them to their standard values at some future point. 

See the following articles for more information on how to manage Network Domain Static Routes: