NSX and IP routing on IBM Cloud VPC

Public traffic between Tier-0 and VPC

If your workloads need direct public traffic and have inbound public traffic without using any network translation, you must provision the public uplink subnet and public T0 uplink VLAN interfaces. Also, you must configure your T0 with public uplinks as described in the topic Tier-0 gateway previously. As the NSX T0 uses Active-Standby, the HA VIP provides high availability for the routing of public traffic between VPC, T0, and your NSX workloads. When you need public IP addresses, you can order a floating IP address to the HA VIP VLAN interface. Each floating IP address is a single /32 IP address, and you can order as many as you need within VPC Quotas.

VLAN interfaces with Allow IP spoofing and Enable Infrastructure NAT set to false allow public floating IP address to traverse non-NATted to the public uplinks of the T0 gateway. For high availability with NSX T0 gateway, HA VIPs can be used. When you order floating IP address for public uplinks, always use the VIP VLAN interface instead of the uplinks that are reserved for the actual Edge Nodes.

You can use the public IP addresses for the following purposes:

• To perform destination NAT in either Tier-0 or Tier-1 gateways for inbound public traffic to NSX overlay.
• To perform source NAT in either Tier-0 or Tier-1 gateways for outbound public traffic from NSX overlay.
• To establish VPNs in either Tier-0 or Tier-1.

For public IP addresses, you can currently use one or more /32 IP address, but you cannot have subnets, such as /29 or /26.

In this case, your default route 0.0.0.0/0 in NSX T0 gateway must be pointed to the default gateway of the vpc-t0-public-uplink-subnet.

If you do not need inbound traffic from internet, you do not need public uplinks on T0 nor the public VLAN interfaces. Alternatively, you can use Public gateway in IBM Cloud VPC, which provides you with the outbound internet access from NSX overlay segments, and use the T0s private uplinks for this traffic. In this case, your default route 0.0.0.0/0 in NSX T0 gateway must be pointed to the default gateway of the vpc-t0-private-uplink-subnet.

Private traffic between Tier-0 and VPC

If you have both Public and Private Uplinks, first you must create a route in NSX T0 pointing to the Private networks. You must connect it to the VMware workloads attached to NSX overlay segments. These networks must then be reachable through the VPC, or DL/TGW, which the VPC is attached to. The following table shows an example where the private prefix 172.16.0.0/16 is used on-premises and this prefix is known by the VMware Cloud Foundation VPC, either directly or through attached Direct Link (DL) or Transit Gateway (TGW).

If you use only a private route, then your default route 0.0.0.0/0 in NSX T0 gateway routes all traffic to the VPC.

You must define inbound traffic from VPC. Then, you must create a VPC route in the Zone to the IP subnet or prefix that you are using in the NSX overlay. As the NSX T0 uses Active-Standby, the HA VIP provides high availability for the routing of private traffic between VPC and your NSX overlay. Therefore, the next-hop for the VPC route must be the HA VIP, as specified on the following table.

VLAN interfaces with Allow IP spoofing and Enable Infrastructure NAT set to true allow VMware workloads on NSX overlay with private IP addresses to be routed to IBM Cloud VPC. To enable this action, a VPC route is created with IP address of private uplink HA VIP vlan-nic-t0-priv-uplink-vip as the next-hop configured in the IBM Cloud VPC Zone.

When you plan the routing, summarize the NSX overlay subnets or prefixes to keep the number of required routes to a minimum. When you create a route that points to the NSX overlay, the following table provides an example for the required parameters for an NSX overlay subnets 192.168.4.0/24, 192.168.5.0/24, 192.168.6.0/24, and 192.168.7.0/24 attached to T1. Further summarized to a prefix 192.168.4.0/22 and by using NSX HA VIP 192.168.0.10 in Zone us-south-2 as the next-hop. For more information about VPC routes, see VPC routing tables and routes.

VPC routes are Zone specific.

When you create a VPC route, it enables traffic within the Zone or VPC depending on how it is created.

In the interconnectivity use case, an ingress routing table is created.

Ingress routes are also created in the zone where VMware Cloud Foundation is deployed. For example, if the deployment would be on us-south-1 and the overlay prefix would be 192.168.4.0/22:

If you use any of the interconnectivity options, such as Direct Link or Transit Gateway, and you need connectivity from another VPC attached to a TGW, in addition to the VPC route, you can create a VPC (ingress) route with advertise flags. This action allows both DL and TGW to advertise your NSX overlay subnet or prefix to the attached TGW connections or DL.

For more information about VPC routes, see VPC routing tables and routes.

Routing between Tier-0 and Tier-1 gateways

T0 and T1 gateways provide native NSX routing between them, but you must configure that inside NSX. In this model, the workloads are typically connected to NSX overlay segments behind T1, and when T1 is connected to its parent T0, it has a default route that points to the T0. By default, T0 does not see prefixes of the segments that are attached to the T1 gateway, unless route advertisement is enabled in T1 to allow this.

If you want to route natively with IBM Cloud VPC subnets and other connected service without using NAT in T1, enable route advertisement of All Connected Segments & Service Ports in the specific T1. You do not need to configure a routing protocol or static routes between T1 and T0 gateways. After you enable the route advertisement, NSX shows and creates these routes automatically. With this approach, you have all connected segments of your T1 routed to T0, and then you can decide how to proceed with the public and private traffic in T0.

For example, if you have a public floating IP configured and provisioned on your T0's HA VIP, you might decide whether you want to create a NAT rule in T1 or T1. Or create a VPN server endpoint on either of these.

For private traffic, you can configure a subnet that is carved out of the private VPC prefix, for example with prefix 192.168.4.0/22 and configure the subnets 192.168.4.0/26 and 192.168.4.64/26 on two segments that are attached to T1. Then, VPC directs traffic that is destined toward 192.168.4.0/22 to T0's private uplink, and T0 will forward that to the T1. The return path follows the reverse path: T1 sends to T0, which then has the private traffic routes toward the default gateway of the VPC private uplink subnet.

Interconnectivity

Interconnectivity consists of multiple services and offerings that enable customers to connect from their remote network locations to IBM Cloud® deployments and between workloads and services that run in IBM Cloud.

It can be divided into the following categories:

• Interconnecting with on-premises networks
• Interconnecting VPCs and other IBM Cloud infrastructure services

The following diagram shows an overview of the interconnectivity solutions.

With IBM Cloud® Transit Gateway (TGW), you can create a single or multiple transit gateways to connect VPCs together. You can also connect your IBM Cloud classic infrastructure to a Transit Gateway to provide seamless communication with Classic Infrastructure resources. Any new network that you connect to a Transit Gateway is then automatically made available to every other network connected to it.

The IBM Cloud Direct Link service is a routed OSI Layer-3 service. It offers a direct connection to the IBM Cloud private network backbone. IBM Cloud Direct Link can be connected directly to the VPC or you can attach it to your TGW.

For more information, see About IBM Cloud Transit Gateway and About IBM Cloud Direct Link (2.0).

Related links

• IBM Cloud VPC getting started
• IBM Cloud VPC bare metal servers
• IBM Cloud Direct Link overview
• IBM Cloud Transit Gateway overview
• IBM Cloud VPC VPN overview
• VPC IaaS endpoints
• About IBM Cloud Transit Gateway
• About IBM Cloud Direct Link (2.0)