Private VLAN (PVLAN) support on Layer 2 networks

Introduction

A regular VLAN is a single broadcast domain which is isolated at Layer 2. However, it has two main limitations:

• A switch can have up to a theoretical maximum of 4094 VLANs (as the first and last VLANs are reserved). This maximum number is usually lower, depending on the switch which is used. A traditional isolation solution consists on assigning a VLAN per customer and in some scenarios, this maximum number may not be enough to cover every customer.
• IP address management problem: as IP addresses may not be used completely when assigning a subnet per VLAN.

The private VLAN (PVLAN) architecture tackles these problems providing scalability and IP address management benefits for service providers, as well as Layer 2 security for customers.

PVLANs partition a VLAN domain into subdomains, these subdomains are represented by a pair: (PRIMARY_VLAN_ID, SECONDARY_VLAN_ID). Every pair in a PVLAN share the PRIMARY_VLAN_ID.

There are two types of subdomains: isolated and community subdomains.

Within a PVLAN, there are three types of port designations, corresponding to the PVLAN type:

• Promiscuous: An endpoint connected to a promiscuous port can communicate with any endpoint within the PVLAN
• Isolated: An endpoint connected to an isolated port can only communicate with endpoints connected to promiscuous ports.
• Community: An endpoint connected to a community port can communicate with another endpoint in the same community and can also communicate with any promiscuous port but not with other communities.

The following table summarizes the communication between different PVLAN types:

The PVLAN support already exists in CloudStack only for Shared networks in Advanced zones. This feature allows extending the PVLAN support to Layer 2 (L2) networks in CloudStack.

Feature Specification

References

Pull request (VMware): https://github.com/apache/cloudstack/pull/3732

Pull request (KVM): https://github.com/apache/cloudstack/pull/4040

API

This feature does not introduce any new API, however it extends the 'createNetwork' API:

• A new optional parameter is added: 'isolatedpvlantype'.
  • Possible values: "community", "isolated", "promiscuous"
• The exisiting parameter 'isolatedpvlan' is extended, to allow passing the PVLAN type with the secondary VLAN ID in the same parameter, without needing to set the new parameter:
  • Possible values: "i-VLANID" for isolated type, "c-VLANID" for community type and "p-VLANID" for promiscuous type

Schema changes

The private VLAN type is persisted as a detail on the 'network_details' table

Screenshots

A new dropdown is added to the networks creation dialog, allowing administratos to selected the PVLAN type along with the secondary VLAN ID

Support

This is currently supported in VMware through dvSwitch and in KVM via OpenFlow rules. It requires OVS > 2.9.2. Since XenServer only supports OVS 2.6, PVLAN is unsupported in XenServer.