Welcome to part-6 of the NSX Multi-tenancy series. The last post of this series discussed NSX VPC architecture and its use cases and the benefits that it provides.

In this post, I will walk you through how networking works inside an NSX VPC.

If you are not following along, I encourage you to read the earlier parts of this series from the below links:

1: NSX Multi-tenancy Introduction

2: Multi-tenancy Design Models

3: Creating NSX Projects

4: Distributed Security in NSX Project

5: NSX Virtual Private Cloud Overview

VPC Networking Overview

In an NSX Project, each VPC has its own set of networking and security policies. Subnets within an NSX VPC represent independent layer 2 broadcast domains.

The Enterprise Admin creates and allocates IP address blocks (public & private) to the project. These IP blocks are consumed by the workloads in VPC. The application owners do not need to have a thorough understanding of the subnets or know how to create CIDRs for project workloads because the NSX platform handles this automatically.

Whenever a new subnet is created in VPC, the VPC admin chooses from auto-created subnets CIDRs available to them. DHCP is auto configured on the subnet for auto ip-addressing to the VMs that will connect to this subnet.

Note: A subnet in VPC is realized as an overlay segment in the project’s default transport zone on the compute clusters. 

When a VPC is created, an obscured T1 gateway is automatically created with it and this gateway provides routing for the subnets (except for isolated ones) created inside VPC. This Tier-1 gateway is destroyed when a VPC is deleted. An NSX VPC can only consume the Tier-0/VRF gateways and edge clusters that are assigned to the project. 

Subnets in NSX VPC

A subnet in VPC represents an overlay segment created in the project’s default overlay transport zone. Users who are assigned the VPC Admin role or the Network Admin role in the NSX VPC can add subnets in the VPC. 

There are 3 types of subnets in a VPC:

1: Public Subnet: This subnet is advertised from the VPC to the Provider Tier-0 gateway and is routed to the physical fabric by the Tier-0 gateway. A public subnet is accessible from outside the NSX VPC.

The Enterprise administrator creates the IP block (public) in the default space and allocates the IP block to the projects that can be then consumed within the project VPCs. A CIDR is carved out from this block for use in public subnets and NAT rules within the VPC.

2: Private Subnet: As the name implies, a private subnet is accessible only within the NSX VPC. This subnet is used for communication between workloads within the same VPC. Workloads on private subnets can communicate with workloads on other private and public subnets in the same VPC. 

Like a public subnet, a private subnet is also created by the Enterprise Admin and assigned to the project. The CIDR of a VPC subnet cannot overlap with the CIDR of another VPC subnet in the same NSX VPC. However, the subnet IPs can overlap with the subnet in another NSX VPC.

Note: Workloads on private subnets can have outbound access to external networks using SNAT.

3: Isolated Subnet: This subnet is isolated and does not have upstream gateway connectivity. Workloads in an isolated segment can communicate with workloads in the same isolated subnet only.

The CIDR address of an isolated subnet is manually specified by the VPC Admin at the time of the subnet creation.

The following diagram shows a sample logical view of networks in an NSX VPC.

VPCs Default Outbound NAT

At the time of creating an NSX VPC, a setting named “Default Outbound NAT” can be configured on the VPC. If this setting is turned on, a default SNAT rule is created for the NSX VPC to allow traffic from the private subnets to be routed outside the NSX VPC. If this setting is turned off, the traffic from the private subnet cannot be routed outside the NSX VPC.

Whitelisting VPC Public Subnet

To prevent advertising un-approved subnets from a Project, the Enterprise Admin implements route filtering. Any project subnet that is not whitelisted by the Enterprise Admin is not advertised to the northbound routers. As of today, this can be only done via API. 

To implement this, the Enterprise Admin first creates a subnet whitelist and then associate the whitelist with the project’s route filer. The following API’s are used for this purpose:

Creating Subnet Whitelist

Associate Subnet Whitelist to Route Filter

List Whitelisted Subnets for a Project

The list of the approved subnets that are being advertised to the northbound routers can be fetched via the below API

An example is shown below for the reference. This example list approved subnets from a Project named “Engineering” that has a tier-1 gateway named “eng-t1-gw“.

And that’s it for this post. In the next post of this series, I will discuss creating VPCs. Stay tuned!!!

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.