(Editorial Update: the content of this blog was edited to remove references to NSX+ which is no longer offered by Broadcom.)

How cloud consumption is making its way natively into NSX 

We are excited to introduce Virtual Private Cloud (VPC) for private clouds and VMware Clouds, with the release of NSX 4.1.1.

Thanks to NSX Network Virtualization, customers can operate their networking, security, and services from a single place through the UI or API. This functionality allows one-click deployment of multi-tier network topologies, backed by distributed networking and security. The software-defined networking solution enables large-scale, self-service IaaS initiatives.

In addition, the introduction of native multi-tenancy in NSX 4.1.0 allows multiple users to consume the platform in parallel without the risk of overlap or disruption. This makes it possible to provide users with direct access to NSX, but to segment each within isolated environments where they can configure their own NSX objects and apply rules only to their workloads.

Now we are taking it to the next level!

With the introduction of VPC in NSX, we are both extending the multi-tenancy framework and offering cloud consumption to users natively, both on-premises and in VMware Cloud. Customers can apply the VPC construct on the cloud/s of their choice with efficient and consistent operations. This VPC is a core construct of multi-cloud IaaS – the next frontier in cloud computing.

Recap: The NSX Multi-tenancy Framework

As described in the ‘NSX Multi-tenancy journey’ blog, the introduction of Projects in NSX 4.0.1 and 4.1.0 brought multi-tenancy to the NSX management and monitoring plane.

A Project is analogous to a tenant space; Projects isolate networking and security configurations, ensuring the ability for tenants to work in parallel. Enterprise Admins can segment the platform into Projects, assigning different spaces to different tenants while maintaining full visibility and control.

For example, Projects could be mapped to different lines of business. For a bank, admins might create Projects for retail banking, corporate banking, and so on. They could also set up different Projects for various environments, such as development, testing, and production, or to various customer organizations in a cloud service provider scenario.

 

Among the previously released capabilities was the ability for the Enterprise Admin to share some specific configurations (for example, profiles) as well as to define quotas on what could be configured inside a Project — such as 50 Distributed Firewall Rules, 30 Segments, and so on.

Introducing VPCs

In newly released NSX 4.1.1, we have added a second layer of tenancy to this model via the VPC construct, which allows admins to partition a Project into multiple environments and delegate access to VPC users/admins. For example, the Project Admin of a line of business named “Marketing” can create multiple VPCs for each application and delegate access to the respective VPC Admins (the owner or developer of the applications).

 

As with Projects, it’s possible for the higher-level admins to limit the number of objects created in an NSX-enabled VPC, and to share some configuration with it.

Also, the model is hierarchical, which means that while the VPC Admin can only apply distributed security to a VM inside the VPC, the Project Admin and Enterprise Admin can apply distributed firewall and IDS/IPS rules to the VPC (and other VPCs and Projects) with higher precedence.

Why Introduce VPCs in the Existing Multi-tenancy Framework?

The recipe for success in infrastructure delivery is to be able to automate all the pieces required to deliver an application.

With that goal in mind, NSX VPC aims to provide self-service networking to allow users to create networks, security and services. In addition, it’s all done in a way that is aligned with the architecture and policy defined by the infrastructure teams (networking and security).

The simplified model of NSX VPC management allows simple onboarding to the platform for a wider variety of users so they can experience the full hybrid/multi-cloud experience.

For example, an application owner can now play a major role in shaping the networking and security for his/her application by managing subnets, outside connectivity and both East-West (micro-segmentation) and North-South (VPC perimeter) security.

Description of the VPC

Let’s look in a bit more detail at the NSX-enabled VPC feature set and consumption.

VPC Creation

First, an NSX-enabled VPC is part of a Project created either by the Project Admin or the Enterprise Admin.  They are the ones defining where the VPC connects and what resources are allocated to it so that the VPC users can then consume networking and security in a self-service manner.

To do so, the higher-level admins specify Tier-0/Tier-0 VRF, Edge Cluster and quotas limiting the number of configurations available. They also define shared objects that can be used across multiple VPCs.

Next, let’s look at the allocation of IP blocks that are allocated to the VPC for both internal and external connectivity. This essentially determines which networks get provisioned inside the VPC and which get advertised outside, and it allows automatic DHCP handling.

External IP Block(s) defines the IPs that will be used to advertise workloads through NAT (floating IP use-case) or to advertise subnets to the rest of the environment. To ensure these IPs are assigned in accordance with the networking architecture, they are allocated by the Enterprise Admin to the Project.

 

Private IP Block(s) defines the IPs that will be used for networks routed inside the VPC but not advertised outside it. Workloads with a Private IP will require NAT for ingress or egress connectivity of the VPC. (A VPC can have a default policy to allow egress to all workloads on a network, but ingress needs to be configured explicitly by the customer).

 

Subnet Consumption

Leveraging those IP Blocks (up to 5 for each type), NSX can simplify much of the networking configuration. It offers the ability to create 3 types of subnets inside the VPC:

  • Public Subnets: the network is routed inside the VPC and advertised to the outside world.
  • Private Subnets: the network is routed inside the VPC but not advertised outside of the VPC.
  • Isolated Subnets: standalone network that is not routed in any form by NSX.

As described here, in VPC the access mode of the subnet defines its connectivity and NSX takes care of the rest. It can even manage IP allocation, asking users how many IPs they need on the segment instead of making the user responsible for defining and maintaining usage of the VPC IP space.

 

Without additional configuration, NSX DHCP can allocate IPs for VMs on this subnet within the proper IP range. The user simply needs to deploy the VM and let it take its IP.

Security Consumption

In addition to provisioning networking, the VPC Admin can configure firewalling on the workload by leveraging both North-South firewall, which defines traffic going in/out of the VPC, and East-West firewall, for distributed enforcement at the workload interface.

By default, the VPC allows both communication inside the VPC and egress from the East-West Firewall. The user is then free to add or change rules mapping to their application requirement.

To do so, they can leverage the powerful grouping constructs of NSX (such as tag-based grouping).

 

Thanks to VPC, those most familiar with the application can implement micro-segmentation with ease, defining precisely which flows should be allowed. However, the delegators, both the Enterprise and Project Admin, retain control.

Firstly, the Enterprise and Project Admins can see the rules created in the VPC. Secondly, these rules are created in the Application Category and allow the ability for both the Project and Enterprise Admin to have “provider” rules above.

 

For instance, Telnet can be denied on all the workloads of the NSX deployment for security reasons under a rule that is non-modifiable for the VPC users.

Services and Detailed Breakdown

To add to this, VPC also offers the ability to do NAT, which provides ingress and egress capabilities for VMs on Private networks as well as the configuration of static routes.

Here is a detailed breakdown of the services available to the VPC Admin:

Network connectivity

  • Subnets (public, private, isolated)
  • Static routes

Network services

  • NAT rules
  • Integration with Load Balancer

Security services

  • East-west firewall rules
  • North-south firewall rules

Inventory objects

  • Groups

Conclusion

NSX-enabled VPC offers cloud consumption with a simplified model aligned with cloud management platforms and public cloud. Thanks to this approach, teams can deploy their applications faster with control over networking and security on a cloud of their choice while overarching control is retained by the NSX Enterprise Admin team that determines VPC consumption by defining not only users but also VPC connectivity, IP blocks, and consumption quotas.

To sum up, NSX enabled VPC extends the possibilities available to VMware customers across multiple clouds, providing a second level of multi-tenancy that is purpose-built for developers and self-service consumption.