Cloud Networks FAQ
Last updated on: 2017-02-28
Authored by: Sameer Satyam
The Rackspace Cloud contains the following networks:
PublicNet connects a cloud server to the Internet. When you create cloud servers with PublicNet, your servers get an IPv4 address and an IPv6 address. Outbound public traffic is billed according to published rates. You can create a server without a public network; however, access to operating system updates, Cloud Monitoring remote checks, and so on might not work. For more information about the limitations of not having a public network, see Removing Networks from a Cloud Server.
Note: PublicNet is required for RackConnect and Managed Operations service level customers.
ServiceNet is an internal, multi-tenant network within each Rackspace Cloud region. It provides cloud servers access to regional services, such as Cloud Files, Cloud Load Balancers, Cloud Databases, and Cloud Backup, at no cost. ServiceNet is currently IPv4 only. Historically, ServiceNet was used for server-to-server communication, but Cloud Networks is now recommended for this purpose. ServiceNet is also required for Windows cloud server activation. We recommend that cloud servers be connected to ServiceNet and that all new connections inbound to the server be denied by a software firewall such as iptables or Windows Firewall. For more information, see Removing Networks from a Cloud Server.
Note: ServiceNet is required for RackConnect and Managed Operations service level customers.
Cloud networks (isolated)
Cloud networks are isolated networks that can be used for secure communication between your cloud servers. Cloud networks are completely private and single tenant, and can be either IPv4 or IPv6. Cloud networks are recommended for all communication between cloud servers. Like ServiceNet, all bandwidth on cloud networks is provided at no charge.
The Rackspace Cloud has two networking APIs - Neutron and Nova-Network.
Rackspace first introduced networking services that were based on the OpenStack Nova-Network API. This version of the service is now superseded by the current networking API, based on OpenStack Neutron, which offers a richer suite of networking services. Both APIs continue to function, but the Neutron API will be the base for all new networking services that Rackspace offers. For more information, see Networking: Neutron versus Nova-Network in the Cloud Networks Developer Guide.
Every Rackspace Managed Infrastructure account has a default limit of 10 cloud networks per region. To request an increase, please submit a ticket in the Cloud Control Panel with details about how you intend to use the additional networks.
Yes. A maximum of 250 servers can be attached to a single cloud network.
The following list shows all the limits defined for the service:
- Cloud networks per region: 10
- Subnets per network: 2 (one IPv4 and one IPv6)
- DNS name servers per subnet: 2
- Host routes per subnet: 3
- Allocation pools per subnet: 5
- Number of fixed IP addresses per port: 4
- Ports (hosts) per network: 250
- Security groups per port: 5
- Security group rules per security group: 20
- Security group rules per user: 100
Yes. You can add or remove any network (PublicNet, ServiceNet, or cloud network) from a server that is in a Managed Infrastructure service level account. However, Managed Operations service level and RackConnect customers are required to have PublicNet and ServiceNet interfaces. This capability means that you can freely make networking changes to your existing deployments without having to rebuild Cloud Servers.
For more information, see the Virtual Interfaces extension in the Cloud Servers Developer Guide (using the nova-network API) or Boot a new server with your cloud network in the Cloud Networks Getting Started Guide (using the neutron API).
Note: Be aware that removing PublicNet or ServiceNet interfaces might impact certain Rackspace services and capabilities.
Yes. IP addresses on Cloud Networks are usable by any other cloud server on that network.
No. At this time, you cannot transfer a PublicNet or ServiceNet IP address between cloud servers.
Cloud networks are regional in scope and can be attached to any of your cloud servers in a given region.
Security groups are containers for a set of inbound and outbound traffic rules that are directly applied to a Neutron port (PublicNet, ServiceNet or Cloud Network). After you launch an instance, you can assign one or more security groups to ports on that instance. Security groups act as a stateful firewall for your Cloud Server instances.
Security groups act as a distributed firewall for your Cloud Server instances. After you launch an instance, you can assign one or more security groups to ports on that instance.
Security groups enable users to manage the flow of traffic across a group of instances without manually configuring firewall settings. Security groups provide a whitelist-style of allowing traffic. After you’ve applied a security rule, such as restricting IPv4 addresses, port 8080, or all IP addresses, the only traffic allowed to reach the instance must comply with the security rule; all other traffic is stopped.
Yes, the security groups feature is available to all customers.
A security group can’t be added as a child of another security group. You also can’t edit a security group rule - you must add a new security group to replace the old one.
Outbound security group rules can only be created by using the API. You can use the following cURL command but be sure to substitute the variables with the appropriate values for your account:
curl -XPOST https://
-H “Content-type: application/json”
-H “User-Agent: python-novaclient”
-H “Accept: application/json”
Following are descriptions of the variables in the command:
regionis the region you are working in.
yourAuthTokenis the authentication token for your user account (more on that here https://docs.rackspace.com/docs/cloud-networks/v2/getting-started/send-request-ovw/#how-curl-commands-work).
portNumberis the port number that you want to add to the rule (such as
IPv6is which ever ip version you want to use.
desiredProtocolis the protocol you want to use (for example,
yourSGIDis the Security Group UUID that you can get from the Security Group Details Page next to “Group ID”.
securityGroupRuleIDis used later to explain how to delete a rule with cURL.
After you run the cURL command, you get output that provides an outline of the
rule that you have just added in a JSON block. Take note of the
id field in the
output because this is the value that you use for
securityGroupRuleID to delete
Yes. Users can provision security groups via the neutron client.
Yes, but only inbound PublicNet and ServiceNet security groups are currently available in the control panel. To access additional features, you can use either the neutron client or the API.
No. We currently support security groups only for virtual cloud servers.
No default security groups are applied. Users must create a security group themselves and apply it to ports on an instance.
No. Security groups can be applied only after the instance is active.
Traffic that matches the new security group rule is allowed to go through.
Traffic that matches a rule is permitted. Any traffic that is not part of the ruleset for that Security Group is denied or blocked. There is no way to specify that traffic matching a rule should be denied. OpenStack Security Groups API was designed as a white-list. Traffic that doesn’t match any of the rules in the white-list is automatically black-listed.
Very basic network operations, such as DNS responses from Rackspace Provider DNS servers (UDP source port 53), are allowed by default even if a security group does not explicitly allow them. Also the TCP flags ACK and RST are permitted by default.
The following types of traffic can be matched (for both IPv4 and IPv6 addresses):
- TCP traffic
- UDP traffic
- ICMP traffic
- Traffic from a Source IP address
- Traffic from a CIDR
Yes. Such a security group will deny or block all traffic.
Yes, security groups are applied to instances. You are able to associate a number of instances with a security group and those instances automatically inherit all security group rules associated with that security group.
- You can apply up to 5 security groups per port.
- You can have up to 20 security group rules per security group
- You can have up to 100 security group rules (aggregate) per user during the limited availability release.
A shared IP allows for active/passive high availability platforms to share a single IP Address between two instances in our cloud. The IP then moves between the two instances based on instance state (up or down) through the configuration of a high availability protocol such as heartbeat or corosync. Active-standby applications can then achieve full redundancy in our cloud.
Shared IP supports the ability to create, associate, disassociate and delete shared IP addresses.
This feature is supported for all customers except RackConnect customers.
No, this feature is not yet available in the Cloud Control Panel.
The default limit is 10 shared IP Addresses per tenant. A quota increase is currently not supported per tenant via a request, but we may support this in the future.
Some high availability protocols depend on an interface floating MAC address to move with the shared IP during an impacting event, i.e. activating the standby instance in a passive state. These protocols are not supported in our cloud, as our underlying data plane implementation doesn’t support MACs moving between instances. Therefore, high availability protocols such as heartbeat, corosync and other similar protocols are favored to function in our cloud over protocols requiring a floating MAC address.
A shared IP address is used for active/passive high availability (HA), where one IP address is needed between two or more servers for the purpose of redundancy (active-standby). The IP address is owned by one of the servers at any given time, and clients or other servers use this IP address for communication with the HA pair.
Although a floating IP address can be used to solve the active/passive HA problem, it would require monitoring and API calls to achieve the same result. Thus, a shared IP address is the preferred method to solve the active or passive HA problem.
No, the shared IP address is an additional public IP assigned to an instance port. The existing public IP must also reside on each instance for the purpose of active-standby detection from high availability protocols such as heartbeat and corosync.
No, shared IP addresses are currently supported only for virtual cloud servers.
No, shared IP addresses do not work with a RackConnect v3.0 cloud network.
Experience what Rackspace has to offer.
©2020 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License