Network use cases

Use case 1: Private network within a pod

With this use case, you can establish a private network within a pod that allows communication between the applications that are located in the pod. You can establish a private network within the pod by using the IP address allocation method, Classless Inter-Domain Routing (CIDR).

You can deploy virtual machines in a pod that has a default configuration by using one of the following patterns:

• Affinity: In this pattern, virtual machines are deployed on the same physical host. Therefore, the virtual machines can communicate with each other on the same host through the attached Ethernet switch.
• Anti-affinity: In this pattern, virtual machines are deployed on different physical hosts. A custom configuration is required on the externally connected Ethernet switch to enable communication between virtual machines that are deployed on different physical hosts.

Example

You have a database server and a web server that need to communicate exclusively with each other. You can connect both servers to the same private network to enable communication between them.

Figure 1 describes the private network within a pod type of network setup.

Use case 2: Multiple external connections

With this use case, you can access the external connectivity to and from the virtual machines in a subnet. You can also establish an outbound-only network connectivity through the dynamic Network Address Translation (NAT gateway configuration.

To access the external connectivity, you must create peer interfaces and establish an external subnet in a workspace. The VMs deployed on the workspace can access the external environment.

To access the external connectivity, complete the following steps:

Step 1: Create a peer interface

To create a peer interface, complete the following steps:

1. Create a workspace.

2. Open a support ticket to create a peer interface. The support team sets up a peer interface with one of the following combinations:

   • Layer 2
   • Layer 2 and Layer 3 with BGP route
   • Layer 2 and Layer 3 with static route
   • Layer 3 BGP route
   • Layer 3 static route

   The peer interface combination is based on the type of data network cabling in your infrastructure. If you need a specific combination of peer interface, you must specify the combination in the ticket.

Step 2: Create an external subnet

To create an external subnet, use one of the peer interfaces configured in Step 1. Optionally, if you choose the NAT configuration for Layer 3 (BGP or static) external network, you must provide the NAT source IP address. The source IP address is used in your firewall to allow the traffic. For Layer 2 external networks, NAT configuration is not applicable.

To create an external subnet, select one of the following options to allow NAT gateway configuration:

• Border Gateway Protocol (BGP) only: You can use BGP with or without NAT gateway configuration. You must provide the source IP address and use the same IP address in your firewall to allow the traffic. For more information about the BGP use case with NAT enabled, see Outbound-only. For more information about the BGP use case without NAT enabled, see Bidirectional external connectivity through BGP.
• Static only: You can use static routing with or without NAT gateway configuration. You must provide the source IP address and use the same IP address in your firewall to allow the traffic. For more information about the static route use case with NAT enabled, see Outbound-only. For more information about the static route use case without NAT enabled, see Bidirectional external connectivity through static routes.

NAT gateway configuration is not available with L2 routes. For more information, see Bidirectional external connectivity - Layer 2.

Step 3: Deploy VMs to access external connectivity

To configure your workspace, open a support ticket.

You can deploy VMs on your workspace after you receive the confirmation from the support team about the completion of configuring your workspace. The VMs can access the external environment by using BGP with NAT enabled or static with NAT enabled routes that you selected in Step 2. For more information about configuring the VMs on your workspace, see Configuring a Power Virtual Server instance.

Outbound-only

The outbount-only use cases are applicable only with NAT gateway configuration that is paired with BGP or static routes. For more information see, Multiple external connectivity.

With this use case, you can establish a private network that allows communication between applications within the pod and with external destination points. However, the applications within the pod are not accessible from the destination points on the external network. You can establish an outbound-only network connectivity through dynamic NAT gateway configuration, resembling a network established by using routers.

Example

A virtual machine within a pod downloads and deploys software from the internet.

You can specify the outbound-only network type when you define network requirements before pod installation. For more information, see Network requirement. After pod installation, you can configure the outbound-only network type by using Support Center ticketing system. For more information, see Getting support section.

Figure 2 describes the outbound-only type of network setup.

Bidirectional external connectivity through BGP

With this use case, you can establish a network that allows communication between the applications within the pod and with the destination points on the external network. By setting up the Layer 3 Firewall rules, you can allow both inbound and outbound connections. Configure the BGP manually between the pod router and the corporate network. By using the BGP configuration, establish a connection between the private network and the corporate network. To configure BGP manually, contact the Support Center. For more information, see Getting support section.

Example

You have a database server that is running inside the pod. You need to access the database server from another application that resides outside the pod but within your corporate network. Layer 3 inbound access, you can route the traffic and apply your corporate firewall or routing rules to access the database server. The corporate network can access the pod subnets by using a BGP connection.

Figure 3 describes the bidirectional external connectivity through BGP type of network setup.

Bidirectional external connectivity through static routes

With this use case, you can establish a network that allows communication between applications within the pod and with destination points on the external network. Layer 3 firewall rules, you can allow both inbound and outbound connections. Establish a static route between edge routers that are within the pod and to the next hop router that is within the corporate network. The static route establishes a connection between the pod subnet and the corporate network. To establish the static route connectivity manually, contact the Support Center. For more information, see Getting support section.

Example

You have a database server that is running inside the pod. You need to access the database server from another application that resides outside the pod but within your corporate network. Layer 3 inbound access, you can route the traffic and apply your corporate firewall or routing rules to access the database server. Your corporate network can access the pod subnets through a static route connection.

Figure 4 describes the bidirectional external connectivity through static routes type of network setup.

Bidirectional external connectivity - Layer 2

With this use case, you can create a network that allows communication between applications within the pod and with destination points on the external network. Integrate a Layer 2 firewall with one of your existing corporate networks to allow the outbound connections. In this type of network, bidirectional external connectivity bypasses the router and connect to the IBM Power Virtual Server network fabric. You can establish this type of connectivity when you want the same IP address space on both internal and external networks. All other external networks involve two distinct subnets.

Figure 5 describes the bidirectional external connectivity by using Layer 2 firewall type of network setup.

Use case 3: Network connectivity for full Linux subscription

With this use case, you can establish a network between a virtual machine in the pod and the Red Hat Satellite server on IBM Cloud. The virtual machine has the stock image of Red Hat Enterprise Linux (RHEL) with full Linux subscription.

Connect the virtual machine in the pod to a proxy network in the corporate network environment. Connect the proxy network to the Red Hat Satellite server on IBM Cloud by using either Direct Link or VPN connection. The virtual machine in the pod can access the Linux® satellite server to retrieve software fixes and other artifacts.

The network connectivity for full Linux subscription can be established by providing the network requirements before the installation of the pod. For more information, see Network requirement. Once the pod is installed, you can configure the network connectivity for full Linux subscription by using the Support Center ticketing system. For more information about full Linux subscription, see Full Linux subscription for Power Virtual Server Private Cloud. For more information about contacting the Support Center, see Getting support section.

Figure 6 describes the network connectivity between a virtual machine and a Red Hat Satellite server on IBM Cloud setup.

Use case 4: DHCP network inside the pod

With this use case, you can use the Dynamic Host Configuration Protocol (DHCP) protocol within the pod to dynamically assign an IP address to a virtual machine.

The presence of the DHCP network within the pod is mandatory when you are using the OpenShift Container Platform on the IBM Power Virtual Server Private Cloud in client location environment. The DHCP network is intended for use only in the OpenShift Container Platform.

IBM Power Virtual Server Private Cloud in client location pods can be configured to include a private and hardware-based DHCP network. The edge router within the pod is configured with the DHCP pool and gateway. You can deploy virtual machines in the DHCP network. The virtual machines are assigned IP addresses from the DHCP server.

You can attach only one DHCP network interface card (NIC) to a virtual machine. If you attach more than one DHCP NIC to a virtual machine, only one NIC acquires the IP address from the DHCP server that is assigned to the virtual machine.

When you create a DHCP network, note that the first four IP addresses are reserved. You must configure a network that has more than four IP addresses. For example, if the subnet mask is 255.255.255.248, the total number of IP addresses is eight. You cannot create a network with a subnet mask beyond 255.255.255.248 as it has less than or equal to five IP addresses.