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.… Read More

Welcome to part-5 of the multi-tenancy series. The last post of this series discussed distributed security in NSX Projects and how to implement DFW rules to allow inbound/outbound connection for the project workloads. In this post, I will discuss NSX Virtual Private Clouds (VPCs).

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

1: NSX Multitenancy Introduction

2: Multitenancy Design Models

3: Creating NSX Projects

4: Distributed Security in NSX Project

NSX Virtual Private Clouds (VPCs)

NSX VPC is an abstraction layer that makes it easier to create self-contained virtual private cloud networks within an NSX Project so that networking and security services may be used in a self-service model.

This feature allows each tenant to define its own subnets, networking services, and firewall rules (DFW/Gateway). This simplifies network and security management, giving users a self-service model similar to public cloud environments. … Read More

In the last post of this series, I discussed how to create NSX Projects and apply RBAC and Quota policies to them. I also touched base briefly on the project’s security (DFW) aspect.

In this post, I will discuss the project’s security in greater detail. 

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

1: NSX Multitenancy Introduction

2: Multitenancy Design Models

3: Creating NSX Projects

One of the key purposes of the Project feature is to allow security policy management to be delegated to the project admin to avoid the danger of rules being applied to the wrong virtual machines.

When an NSX project is created by the Enterprise Admin, the system generates default Distributed & Gateway firewall rules to regulate the default behavior of east-west and north-south traffic for the VMs in the NSX project.  The firewall rules in a project apply only to the VMs created in that project and don’t impact VMs created in other projects or the default space.… Read More

Welcome to part-3 of the NSX Multi-tenancy series. Parts 1 & 2 of this series were theoretical and mainly focused on multi-tenancy architecture and design models. This part focuses on hands-on, with topics such as creating NSX projects, applying RBAC policies, and creating networking constructs within the project. 

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

1: NSX Multitenancy Introduction

2: Multitenancy Design Models

Environment Details

This is a full-fledged NSX deployed environment based on the design documented here; thus, I am not covering the implementation details again. 

The lab is deployed as per the below BOM 

I am using the multi-tenancy with shared provider tier-0 gateway design for this post, where tenants will share the tier-0 gateway and the edge clusters from the provider.… Read More

Welcome to part-2 of the NSX Multi-tenancy series. While part-1 focused on the NSX Multi-tenancy solution and its architecture, part 2 will walk you through the multi-tenancy design models.

After the Project is created and the RBAC policies have been applied, the project admin creates the tier-1 gateways and segments for their workloads. Since the tier-0 gateway and edge clusters cannot be created inside a project, the Enterprise Admin is responsible for sharing these objects from the default space with the projects.

Multi-tenancy Design Models

There are 2 design models available as of today for implementing multi-tenancy:

1. Multi-tenancy with shared Provider (T0 / VRF) gateway.
2. Multi-tenancy with dedicated Provider (T0 / VRF) gateway.

In both designs, the data plane is shared. Multi-tenancy with an isolated data plane is not yet supported. 

Based on the design models discussed above, tenants can leverage shared or dedicated edge clusters to create networking constructs in a project.… Read More

What is Multi-tenancy?

Multi-tenancy is an architecture in which a single software application instance serves multiple customers, each called a tenant. A multi-tenant architecture allows several instances of an application to function in a shared environment. This design works because each tenant is physically integrated but logically independent. This means that a single instance of the software will run on one server and then serve multiple tenants.

Multi-tenancy in VMware NSX

Although Multi-tenancy was first introduced in NSX 4.0.1, it has been available at the data plane layer for several years. VMware NSX uses multi-tiered routing model with logical separation between the different gateways (tier-0 & tier-1) to provide networking connectivity, and these gateways, when deployed as per a specific design, provide isolation to user apps from each other.

For e.g, features like VRF, that allows for having a separate routing domain per tenant, or deploying Tier-1 gateways per application/environment (dev/test/prod) to achieve segmentation.… Read More