Network

The HPC Cloud supports virtual network resources such as routers, floating ips, and security groups, which, together with the physical and virtual networks themselves form the communication infrastructure needed by compute instances.

Hint

Networking topics can become quite complex, but many use cases are already covered by local networks combined with the appropriate security group rules. Thus, you may want to skip directly to those sections.

Shared Networks

The HPC Cloud offers multiple shared networks, summarized in the table below. These networks allow communication between projects (only if explicitly allowed by security group rules) as well as traffic to and from the HPC Cloud (subject to some restrictions explained below). IP addresses are assigned randomly from the pool but typically won’t change over the lifetime of the port, i.e. as long as the instance or floating ip is not deleted or released, respectively.

Network

Address Range

Routing

Availability

Supported Port Types

cloud-local-1

10.186.1.XX

mpcdf campus/vpn

all projects

instances

cloud-local-2

10.186.2.XX

mpcdf campus/vpn

all projects

instances

cloud-local-float

10.186.7.XX

mpcdf campus/vpn

all projects

floating ips, routers

cloud-public

130.183.217.XX

global

on request

floating ips, routers, instances 1

Local Networks

The cloud-local networks provide each server with an IP address in the 10.186.XX.XX range and support connections from internal MPCDF networks without the need for a project-specific gateway or jumphost. Note that the reverse is not the case; in general servers on these networks can connect to publicly-available services such as gitlab and datashare, as well as the public internet 2, but not Raven, local clusters, etc. The cloud-local-float network has similar properties but is normally used in combination with private networks.

Public Network

The HPC Cloud includes a single globally-routed network cloud-public for the purpose of hosting internet-accessible services. Access is granted per-project, based on requirements and a discussion between the responsible local admins and MPCDF. In practice this network is normally used via floating ips which are attached to an instance running on a local (or private) network. 1

Private Networks and Routers

Private networking is available to meet more complex requirements, as well conserve IP addresses on the shared networks. The following steps correspond to a typical use case, but by no means cover all the possibilities.

  1. Create a new network and associated subnet via Create Network on Project / Network / Networks, specifying 192.168.0.0/24 as the network address and 130.183.9.32, 130.183.1.21 (one per line) as the DNS name servers.

  2. Create a new router via Create Router on Project / Network / Routers, choosing either cloud-local-float or cloud-public (if available) as the external network.

  3. Select the router, switch to the “Interfaces” tab, and click Add Interface to add a port in the newly-created subnet.

CLI Example

openstack network create NETWORK
openstack subnet create SUBNET --network NETWORK --subnet-range 192.168.0.0/24 --dns-nameserver 130.183.9.32 --dns-nameserver 130.183.1.21
openstack router create ROUTER
openstack router set ROUTER --external-gateway cloud-local-float
openstack router add subnet ROUTER SUBNET

You can now launch instances on the private network, but there is no way to reach the network from outside, and therefore no way to login! 3 To get around this limitation, attach a floating ip to at least one of the servers in the private network.

Floating IPs

Floating ips give a server an alternate ip address without reconfiguring the server itself. This works because the software-defined networking layer implements a one-to-one translation between the fixed address that the operating system “sees” and the floating address. Note that the fixed address will continue to be usable inside the local (or private) subnet, while all other hosts must use the floating ip. 4

  1. Reserve a floating ip via Allocate IP to Project on Project / Network / Floating IPs, selecting either cloud-local-float or cloud-public (if available) as the pool.

  2. Select the floating ip, click Associate Floating IP, and then choose the primary port of the target instance.

Attention

The floating ip’s pool must match the router gateway to successfully associate with a server:
  • For servers on local networks, only floating ips from cloud-public can be used.

  • For servers on private networks, it depends on which external network was chosen for the private router – see step 2 above.

CLI Example

openstack floating ip create cloud-local-float
openstack server add floating ip SERVER 10.186.7.XX

Security Groups

The HPC Cloud provides a flexible per-instance, network-based access control mechanism in the form of security groups. The default security group allows connections between instances in the same project (and network), plus SSH from internal MPCDF networks and ping from anywhere. The recommended way to “open” additional ports is as follows:

  1. Create a new group via Create Security Group on Project / Network / Security Groups.

  2. Select the group, choose Manage Rules, followed by Add Rule, and then add one or more rules, e.g.:

    • Rule: Custom TCP Rule

    • Direction: Ingress

    • Port: 80

    • CIDR: 0.0.0.0/0

  3. Select the desired instance on Project / Compute / Instances, choose Edit Security Groups, and then add the newly created security group. In most cases you should keep, rather than replace, the default security group, unless your new security group includes rules for all necessary ingress and egress traffic.

CLI Example

openstack security group create SECGROUP
openstack security group rule create SECGROUP --protocol tcp --dst-port 80
openstack server add security group SERVER SECGROUP

One thing to keep in mind is that what traffic unlimately reaches the server is determined by the properties of the network and the security group rules. For example, since cloud-local networks are not globally routed, opening a port to all sources only affects traffic from other MPCDF networks. Adding a public floating ip, however, changes the situation dramatically. Thus, it is good practice to choose the CIDR carefully, rather than relying exclusively on the network topology for security.

1(1,2)

Certain applications do not support floating ips, since the operating system detects only the fixed address. On request, it is technically possible to place an instance directly on the public network.

2

Internet access is provided via a NAT gateway. The external address of the gateway (currently 130.183.254.22) may change and should not be used for access control.

3

Unlike many routers used for home internet service, the software-defined routers in the HPC Cloud do not support port forwarding, i.e. directing incoming traffic on a particular port to particular local “behind” the router.

4

One might wonder if local peers can communicate with the floating ip as well. For private networks the answer is yes; for local networks the answer is no.