The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes private VLAN (PVLAN) support in the Cisco Unified Computing System (UCS), a feature introduced in Release 1.4 of the Cisco UCS Manager (UCSM). It also details the features, the caveats, and the configuration when PVLANs are used in a UCS environment.
THIS DOCUMENT IS FOR USE WITH UCSM VERSION 2.2(2C) AND EARLIER VERSIONS. In versions later than Version 2.2(2C), changes have been made to UCSM and ESXi DVS is supported. There are also changes in how tagging works for the PVLAN NIC.
Cisco recommends that you have knowledge of these topics:
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
A private VLAN is a VLAN configured for L2 isolation from other ports within the same private VLAN. Ports that belong to a PVLAN are associated with a common set of support VLANs, which are used in order to create the PVLAN structure.
There are three types of PVLAN ports:
Refer to RFC 5517, Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment in order to understand the theory, operation, and concepts of PVLANs.
UCS closely resembles the Nexus 5000/2000 architecture, where the Nexus 5000 is analogous to the UCS 6100 and the Nexus 2000 to the UCS 2104 Fabric Extenders.
Many limitations of PVLAN functionality in UCS are caused by the limitations found in the Nexus 5000/2000 implementation.
Important points to remember are:
This document covers several different configurations available for PVLAN with UCS:
The topology for all examples with a distributed switch is:
The topology for all examples with no distributed switch is:
In this configuration, you are passing PVLAN traffic through UCS to a promiscuous port that is upstream. Because you cannot send both primary and secondary VLANs on the same vNIC, you need one vNIC for each blade for each PVLAN, in order to carry the PVLAN traffic.
This procedure describes how to create both the primary and any isolated VLANS.
Note: This example uses 266 as the primary and 166 as the isolated; the VLAN IDs will be determined by the site.
These procedures describe how to configure a Nexus 5K to pass the PVLAN through to an upstream 4900 switch where the promiscuous port is. While this might not be necessary in all environments, use this configuration in the event that you must pass the PVLAN through another switch.
On the Nexus 5K, enter these commands, and check uplink configuration:
Nexus5000-5(config)# feature private-vlan[an error occurred while processing this directive]
Nexus5000-5(config)# vlan 166[an error occurred while processing this directive]
Nexus5000-5(config-vlan)# private-vlan isolated
Nexus5000-5(config-vlan)# vlan 266
Nexus5000-5(config-vlan)# private-vlan primary
Nexus5000-5(config-vlan)# private-vlan association 166[an error occurred while processing this directive]
On the 4900 switch, take these steps, and set up the promiscuous port. The PVLAN ends at the promiscuous port.
Switch(config-if)#switchport mode trunk[an error occurred while processing this directive]
switchport private-vlan mapping 266 166
switchport mode private-vlan promiscuous
On the upstream router, create a subinterface for the VLAN 266 only. At this level, the requirements depend upon the network configuration you are using:
This procedure describes how to test the configuration.
(config)# interface vlan 266[an error occurred while processing this directive]
(config-if)# ip address 209.165.200.225 255.255.255.224
(config-if)# private-vlan mapping 166
(config-if)# no shut
In this configuration, the systems in this isolated VLAN cannot communicate with each other, but can communicate with other systems through the promiscuous port on the 4900 switch. One issue is how to configure downsteam devices. In this case, you are using VMware and two hosts.
Remember that you must use one vNIC for each PVLAN. These vNICs are presented to VMware vSphere ESXi, and you can then create port groups and have guests to these port groups.
If two systems are added to the same port group on the same switch, they can communicate with each other because their communications are switched locally on the vSwitch. In this system, there are two blades with two hosts each.
On the first system, two different port groups have been created - one called 166, and one called 166A. Each is connected to a single NIC, which is configured in the isolated VLAN on UCS. There is currently only one guest for each port group. In this case, because these are separated on ESXi, they cannot talk to each other.
On the second system, there is only one port group called 166. There are two guests in this port group. In this configuration, VM3 and VM4 can communicate with each other even though you do not want this to happen. In order to correct this, you need to configure a single NIC for each virtual machine (VM) that is in the isolated VLAN, and then create a port group attached to that vNIC. Once this is configured, put only one guest into the port group. This is not a problem with a bare metal Windows install because you do not have these underlying vSwitches.
In this configuration, you are passing PVLAN traffic through an N1K then the UCS to a promiscuous port that is upstream. Because you cannot send both primary and secondary VLANs on the same vNIC, you need one vNIC for each PVLAN uplink in order to carry the PVLAN traffic.
This procedure describes how to create both the primary and any isolated VLANS.
Note: This example uses 266 as the primary and 166 as the isolated; the VLAN IDs will be determined by the site.
These procedures describe how to configure a Nexus 5K in order to pass the PVLAN through to an upstream 4900 switch where the promiscuous port is. While this might not be necessary in all environments, use this configuration in the event that you must pass the PVLAN through another switch.
On the Nexus 5K, enter these commands, and check uplink configuration:
Nexus5000-5(config)# feature private-vlan[an error occurred while processing this directive]
Nexus5000-5(config)# vlan 166[an error occurred while processing this directive]
Nexus5000-5(config-vlan)# private-vlan isolated
Nexus5000-5(config-vlan)# vlan 266
Nexus5000-5(config-vlan)# private-vlan primary
Nexus5000-5(config-vlan)# private-vlan association 166[an error occurred while processing this directive]
On the 4900 switch, take these steps, and set up the promiscuous port. The PVLAN ends at the promiscuous port.
Switch(config-if)#switchport mode trunk[an error occurred while processing this directive]
switchport private-vlan mapping 266 166
switchport mode private-vlan promiscuous
On the upstream router, create a subinterface for the VLAN 266 only. At this level, the requirements depend upon the network configuration that you use:
This procedure describes how to configure the N1K as a standard trunk, not a PVLAN trunk.
Switch(config)#port-profile type ethernet pvlan_uplink[an error occurred while processing this directive]
Switch(config-port-prof)# vmware port-group
Switch(config-port-prof)# switchport mode trunk
Switch(config-port-prof)# switchport trunk allowed vlan 166,266
Switch(config-port-prof)# switchport trunk native vlan 266 <-- This is necessary to handle
traffic coming back from the promiscuous port.
Switch(config-port-prof)# channel-group auto mode on mac-pinning
Switch(config-port-prof)# no shut
Switch(config-port-prof)# state enabled
Switch(config)# port-profile type vethernet pvlan_guest[an error occurred while processing this directive]
Switch(config-port-prof)# vmware port-group
Switch(config-port-prof)# switchport mode private-vlan host
Switch(config-port-prof)# switchport private-vlan host-association 266 166
Switch(config-port-prof)# no shut
Switch(config-port-prof)# state enabled
This procedure describes how to test the configuration.
In this configuration, you contain PVLAN traffic to the N1K with only the primary VLAN used upstream.
This procedure describes how to add the primary VLAN to the vNIC. There is no need for PVLAN configuration because you only need the primary VLAN.
Note: This example uses 266 as the primary and 166 as the isolated; the VLAN IDs will be determined by the site.
These procedures describe how to configure the upstream devices. In this case, the upstream switches only need trunk ports, and they only need to trunk VLAN 266 because it is the only VLAN the upstream switches see.
On the Nexus 5K, enter these commands, and check uplink configuration:
Nexus5000-5(config-vlan)# vlan 266[an error occurred while processing this directive]
On the 4900 switch, take these steps:
On the upstream router, create a subinterface for the VLAN 266 only. At this level, the requirements depend upon the network configuration that you use.
This procedure describes how to configure the N1K.
Switch(config)# vlan 166[an error occurred while processing this directive]
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# vlan 266
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 166
Switch(config)#port-profile type ethernet pvlan_uplink[an error occurred while processing this directive]
Switch(config-port-prof)# vmware port-group
Switch(config-port-prof)# switchport mode private-vlan trunk promiscuous
Switch(config-port-prof)# switchport private-vlan trunk allowed vlan 266 <-- Only need to
allow the primary VLAN
Switch(config-port-prof)# switchport private-vlan mapping trunk 266 166 <-- The VLANS must
be mapped at this point
Switch(config-port-prof)# channel-group auto mode on mac-pinning
Switch(config-port-prof)# no shut
Switch(config-port-prof)# state enabled
Switch(config)# port-profile type vethernet pvlan_guest[an error occurred while processing this directive]
Switch(config-port-prof)# vmware port-group
Switch(config-port-prof)# switchport mode private-vlan host
Switch(config-port-prof)# switchport private-vlan host-association 266 166
Switch(config-port-prof)# no shut
Switch(config-port-prof)# state enabled
This procedure describes how to test the configuration.
This is the only supported configuration for community VLAN with UCS.
This configuration is the same as that set up in the Isolated PVLAN on N1K with Promiscuous Port on the N1K Uplink Port-Profile section. The only difference between community and isolated is the configuration of the PVLAN.
In order to configure the N1K, create and associate the VLANs as you did on the Nexus 5K:
Switch(config)# vlan 166[an error occurred while processing this directive]
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 266
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 16
All other configuration is the same as the isolated PVLAN on N1K with promiscuous port on the N1K uplink port-profile.
Once this is configured, you can communicate with all VMs connected to the vEthernet port-profile used for your PVLAN.
This procedure describes how to test the configuration.
Because of the configuration issues on both the DVS and the UCS system, PVLANs with DVS and UCS are not supported prior to Version 2.2(2c).
There are currently no verification procedures available for these configurations.
The previous sections provided information you can use in order to troubleshoot your configurations.
The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output Interpreter Tool in order to view an analysis of show command output.