I am often asked whether AHV supports PVLANs (private VLANs). Usually this question comes in beside a yes or no checkbox in an RFP, and technically, I have to click no. But a real answer here requires more than just a checkbox, so I’d like to take a moment to step back and address the underlying requirement and use case. Basically, with Flow and Nutanix AHV, we can cover this use case without PVLANs.
The Problem: Security and Efficiency
In an enterprise cloud environment, there is a limited number of IP subnets and VLANs. When datacenter architects use the VLAN and IP subnet boundaries to segment environments and even applications within an environment for security, they are placing an arbitrary limit on the possible number of environments and applications. Eventually you’ll run out of VLANs or have to deal with inefficient IP addressing schemes due to the proliferation of unique subnets per application. The sprawl of the resulting environment is complex to operate and manage—and therefore hard to scale.
One Solution: Private VLANs
PVLANs solve this problem by subdividing existing VLANs into smaller isolated logical segments. The Wikipedia article on PVLANs has some great diagrams and a description, but here’s a quick summary.
You can entirely isolate traffic within the subdivided PVLANs (using isolation ports, or I-ports), separating anything in the subdomain from anything else in the subdomain, while traffic can still flow in and out, usually to the Internet. This approach is helpful in a hotel use case, for example, or any untrusted user situation where the user needs Internet access, but you don’t want that user to access any of their neighbors.
In another use case, you can also allow traffic in the subdivided PVLANs to flow freely within the subdomains (using community ports, or C-ports) and to the Internet, while blocking subdomains from talking to each other. This configuration conserves IP addresses and VLANs while also providing separation. With this approach, you don’t need to burn an entire VLAN and subnet for each application; instead, all of the applications can be in the same VLAN and subnet, with the traffic boundaries located inside the PVLAN subdomain. This structure lets the administrator use the limited number of VLANs and IP addresses more efficiently.
PVLANs are great for enabling both of these traffic patterns, but they require vendor-specific switch configuration that isn’t always simple to understand. In the virtual world, they also require matching up the configuration between the hypervisor and the physical switch, which is time consuming and easy to get wrong.
There is a better way!
A Better Solution: Flow
Let’s look at the previous use cases—supporting untrusted users with isolation and creating subdivided groups with community ports—and see how we’d do the same thing with Flow and AHV.
Untrusted Users: AppTier Isolation
To isolate a VM’s traffic from all other VMs in Flow, while still allowing outbound Internet traffic, just assign this VM to the AppTier category inside an application security policy. Within security policies, AppTier has a special property that can disallow communication between all VMs in the same AppTier. This option appears in the UI as “VMs in this tier can not talk to each other.”
In this example, the VM in “AppTier: untrusted” can reach outbound to the defined proxy or to any set of allowed destinations. However, the untrusted VMs in this tier cannot reach any other VM that is untrusted. This capability gives us the exact isolation behavior we thought we needed a PVLAN to achieve, but it only took a single radio button to disallow communication in the tier.
The great thing about this approach is that I don’t have to do any configuration on the network. All of these VMs can be in the same subnet and the same VLAN, and I still get the isolation behavior I want thanks to Flow.
Subdivided Groups: Application Security Policy
To create a subdivided group inside Flow, we can use the same application security policy and change just one parameter on the AppTier. The application policy can block all inbound and outbound communication, while still allowing traffic within the AppTier. We can even add allowed inbound sources and outbound destinations if we want.
VMs in “AppType: A” and “AppTier: Default” in this example can communicate with each other, but not with any other group of VMs, unless we change a setting to explicitly allow that communication.
Changing the Question
Security policies in Flow control VM traffic independent of network address schemes. The administrator or architect can use a flat IP address space and a single VLAN to create many subdivided groups in just a few clicks, with no changes required to the physical network.
Maybe someday we can revise RFPs to have a little more nuance when it comes to PVLANs, but we’re not quite there yet. In the meantime, thanks to Nutanix Flow, we can isolate environments and applications from each other while still allowing defined inbound and outbound communication—all without PVLANs.
Disclaimer: This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.
2018 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).