Private Virtual LANs

It is crucial to allow communication between hosts that require it, but it is also important to
deny communications between hosts that have no such requirements. If hosts are on different
network segments, it is easy to set up a firewall or a router with an access list to block
undesired traffic at the network layer, but when hosts are on the same segment it is more
difficult. A private VLAN is a VLAN feature in which access ports are allowed to
communicate only with certain designated router ports. Private VLANs and normal VLANs
can exist simultaneously in the same chassis. The security implementation with a Private
VLAN is conducted at the hardware layer and does not allow for any frame of any sort to pass
between adjacent access ports within a Private VLAN.

Cisco's implementation of Private Virtual LANs (PVLAN) help ensure that network traffic
only goes where it is supposed to.

A VLAN on a network is a broadcast domain, and all of the hosts on that VLAN can
communicate with the other members of the same VLAN. PVLANs allow traffic to be
segmented at the data-link layer (layer 2) of the OSI model, limiting the size of the broadcast
domain.

Designers usually tend to implement DMZs using a common segment for all servers without
any control over the traffic between them. For example, all servers are located in a common
VLAN. Since nothing is controlling the traffic within the same VLAN, if one of the servers is
compromised, then the same server can be exploited to source an attack to any of the servers
and hosts in the same segment. This clearly facilitates the activity of a potential intruder
conducting a port redirection or Application Layer attack.
Typically, firewalls and packet filters are only used to control incoming connections, but
nothing is usually done to restrict connections originated from the DMZ. Some time ago there
was a well−known vulnerability in a cgi−bin script that allowed an intruder to begin an
X−term session by just sending an HTTP stream; this is traffic that should be allowed by the
firewall. If the intruder was lucky enough, he or she could use another treat to get a root
prompt, typically some kind of buffer overflow attack. Most of the times these kinds of
problems can be avoided by enforcing a proper trust model: First, servers are not supposed to
talk to each other, and second no connections should be originated from these servers to the
outside world. The same comments apply to many other scenarios, going from any regular
un−trusted segment up to server farms at application service providers.

How can PVLANs be implemented in our DMZ scenario?

In our DMZ the servers needs to be available to external connections and possibly internal
connections, but rarely needs to communicate with the other servers on the DMZ. You want
them all to be in one subnet, but at the same time don’t want them to have free network access
to each other. You can configure the switch ports, while remaining in the one overall VLAN,
to be subdivided so that they logically are only allowed to communicate with the default
gateway on the DMZ, denying communication between the servers. If one of the servers was
compromised by a hacker, or infected with a virus, the other servers on the DMZ (the next
logical hop for an attack) would be safe.

A switch port that is part of a PVLAN can be configured in one of three ways:
1) The port can be configured to be promiscuous. A promiscuous port will forward traffic
from any port on the same PVLAN, typically the network’s default gateway.
2) The port can be configured in community mode. A community port can forward traffic to a
Stefan Löfgren 1
Netcenter/IDE
Mälardalens högskola
 Private Virtual LANs

promiscuous port or to other ports in the same community.

3) The port can be configured as isolated. Isolated ports can only forward traffic to
promiscuous ports. (e.g. one PC can't talk to another PC, even though they're in the same
VLAN, but it can talk with the default gateway on the promiscuous port)

A server that is connected to a port set up as an isolated port, can only pass traffic to and from
the router that is its default gateway. A couple of devices in the same community can talk to
each other and the router, but not the other servers in that PVLAN.

In a PVLAN, promiscuous ports are called the primary VLAN, while community and isolated
ports are called secondary VLANs. A PVLAN will only have one primary VLAN, but may
have several secondary VLANS.

In the DMZ example mentioned above, the default gateway (either a router or a firewall)
would be connected to a promiscuous port on the switch, and all of the servers would be
connected to isolated ports (multiple isolated ports can belong to the same secondary VLAN).
This would allow external and internal hosts to connect to the servers on the DMZ, but the
DMZ servers would be unable to communicate with each other. If there was a web server on
the DMZ that needed to access a database server also on the DMZ, both servers could be
connected to ports configured for the same community secondary VLAN, effectively isolating
the two servers from the rest of the DMZ while maintaining database connectivity for the web
server.

When adding VLAN Access Control Lists we do enforce the proper trust model. Servers at
the DMZ are supposed to serve incoming connections only, and they are not expected to
initiate connections to the outside world. A VACL can be applied to their secondary VLAN in
order to control the traffic leaving these servers. It is crucial to note that when using VACLs,
the traffic is dropped in hardware so there is no impact on the CPU of the router nor of the
switch. Even in the case that one of the servers is involved in a Distributed Denial of Service
(DDoS) attack as a source, the switch will drop all illegitimate traffic at wire speed, without
any performance penalty. Similar filters can be applied in the router or firewall where servers
are connected to, but this usually has severe performance implications.

VACLs also fix the well−known security limitation to PVLANs, that a router can route traffic
across isolated ports defeating the purpose of PVLANs. This limitation is due to the fact that
PVLANs are a tool that provides isolation at Layer 2, not at Layer 3. VACLs configured on
the primary VLANs drops the traffic with a source and destination address on the same
subnet.

There are a few issues with PVLANs that should be mentioned. Switches that use PVLANs
must be configured for transparent VTP mode, so they cannot participate in a VTP domain. If
trunking is used to pass PVLAN information between two switches, all of the secondary
VLAN traffic may be passed over the trunk. Plan your configuration with care if you are
using trunking. PVLAN ports cannot be trunk ports, cannot channel, cannot have dynamic
VLAN membership, and cannot be a Switched Port Analyzer (SPAN) destination.

Stefan Löfgren 2
Netcenter/IDE
Mälardalens högskola
 Private Virtual LANs

Critical Voices
Critical Voice 1-
Under the normal VLAN setup you must allocate a block of IP space for each customer. If
you just give them enough to address their single server, like a /30, then when they add
another server you must either give them another /30 or have them renumber into a /29. Now
when you consider that you are really only using 1 IP address per server and only really need
a default address to point at, you end up with many IP address just "laying around unused or
unusable".
How it works - What PublicVLAN allows you to do is use one large IP block, with one
default IP address and one network and broadcast address. All of the other address can be
given to hosts/servers below. The PublicVLAN is basically a layer three decision and does
proxy ARP so that each device can also reach other hosts on the same network.

Critical Voice 2 –
Why go to the bother? The reasoning behind this when it was first thought up is explained
pretty well in the related RFC 3069 ‘Efficient IP Address Aggregation’. This was a feature
written for Service Providers, to allow them to host servers for multiple individual corporate
customers without having to cope with vast quantities of subnets and the requisite complex
subnet masking. Customers didn’t want their services to be on a network shared with others
while ISPs didn’t want to have to create dozens or hundreds of discrete networks to segregate
them. SuperVLANs (another name for PVLAN) were the answer. One logical subnet, but
isolation between devices in any granularity required.
Since then, the idea has worked well. However over-keen vendors have started selling this
technology to enterprise customers too. The need to sell value-add in an effort to add market
share has arguably driven the desire to promote the technology in ways not intended in the the
original design.
Private VLANs are now a security mechanism. Isolate your servers in their own mini-VLANs
and a hacker who violates one server can’t use it as a jumping off point to all the rest in that
subnet. At a basic level that might be true, but it wasn’t designed from the ground up as a
security feature, so should not be thought of as such. We don’t think of basic VLANs as all
that secure, so why private VLANs? Okay, VLANs do add a level of security by their very
nature, but that is not their prime focus, and if that’s all the security you have in your network,
I’d be worried. Similarly with these. A level of security, yes—just be aware of where that
level is.
For instance, they are vulnerable to spoofing. A packet sent from a server on an isolated port
to another server on another isolated port will not be passed by the switch, true. However, a
packet sent from a server to the MAC address of the default gateway will be passed through
the switch. If at an IP layer, it’s addressed to another ‘isolated’ server, the router will pass it
— it has no reason not to. You need access lists as a minimum, or better, firewalling, to
protect against that.
Private VLANs are without doubt a useful tool to have at hand. However they are not a
security panacea, and the main danger they pose is in pretending that they are.

Catalyst 3560 Switch Command Reference, Rel. 12.2(25)SE

Stefan Löfgren 3
Netcenter/IDE
Mälardalens högskola
 Private Virtual LANs

Catalyst 3560 Switch Command Reference, Rel. 12.2(25)SE

private-vlan
Use the private-vlan VLAN configuration command to configure private VLANs and to
configure the association between private-VLAN primary and secondary VLANs. Use the no
form of this command to return the VLAN to normal VLAN configuration.
private-vlan {association [add | remove] secondary-vlan-list | community | isolated |
primary}
no private-vlan {association | community | isolated | primary}
This command is available only if the switch is running the enhanced multilayer image (EMI).
Syntax Description
association Create an association between the primary VLAN and a
secondary VLAN.

secondary- Specify one or more secondary VLANs to be associated

vlan-list with a primary VLAN in a private VLAN.

add Associate a secondary VLAN to a primary VLAN.

remove Clear the association between a secondary VLAN and a

primary VLAN.

community Designate the VLAN as a community VLAN.

isolated Designate the VLAN as a community VLAN.

primary Designate the VLAN as a community VLAN.

Note The switch must be in VTP transparent mode when you configure private VLANs.

Defaults
The default is to have no private VLANs configured.
Command Modes
VLAN configuration
Command History
Release Modification
12.2(20)SE This command was introduced.

Stefan Löfgren 4
Netcenter/IDE
Mälardalens högskola
 Private Virtual LANs

Usage Guidelines
Before configuring private VLANs, you must disable VTP (VTP mode transparent). After you
configure a private VLAN, you should not change the VTP mode to client or server.
VTP does not propagate private-VLAN configuration. You must manually configure private
VLANs on all switches in the Layer 2 network to merge their Layer 2 databases and to
prevent flooding of private-VLAN traffic.
You cannot include VLAN 1 or VLANs 1002 to 1005 in the private-VLAN configuration.
Extended VLANs (VLAN IDs 1006 to 4094) can be configured in private VLANs.
You can associate a secondary (isolated or community) VLAN with only one primary VLAN.
A primary VLAN can have one isolated VLAN and multiple community VLANs associated
with it.
• A secondary VLAN cannot be configured as a primary VLAN.
• The secondary_vlan_list parameter cannot contain spaces. It can contain multiple
comma-separated items. Each item can be a single private-VLAN ID or a hyphenated range
of private-VLAN IDs. The list can contain one isolated VLAN and multiple community VLANs.
• If you delete either the primary or secondary VLANs, the ports associated with the VLAN
become inactive.
A community VLAN carries traffic among community ports and from community ports to the
promiscuous ports on the corresponding primary VLAN.
An isolated VLAN is used by isolated ports to communicate with promiscuous ports. It does
not carry traffic to other community ports or isolated ports with the same primary vlan
domain.
A primary VLAN is the VLAN that carries traffic from a gateway to customer end stations on
private ports.
Configure Layer 3 VLAN interfaces (SVIs) only for primary VLANs. You cannot configure
Layer 3 VLAN interfaces for secondary VLANs. SVIs for secondary VLANs are inactive while
the VLAN is configured as a secondary VLAN.
The private-vlan commands do not take effect until you exit from VLAN configuration mode.
Do not configure private-VLAN ports as EtherChannels. While a port is part of the private-
VLAN configuration, any EtherChannel configuration for it is inactive.
Do not configure a private VLAN as a Remote Switched Port Analyzer (RSPAN) VLAN.
Do not configure a private VLAN as a voice VLAN.
Do not configure fallback bridging on switches with private VLANs.
Although a private VLAN contains more than one VLAN, only one STP instance runs for the
entire private VLAN. When a secondary VLAN is associated with the primary VLAN, the STP
parameters of the primary VLAN are propagated to the secondary VLAN.
See the switchport mode private-vlan command for information about configuring host ports
and promiscuous ports.

Stefan Löfgren 5
Netcenter/IDE
Mälardalens högskola
 Private Virtual LANs

Note For more information about private-VLAN interaction with other features, see the
software configuration guide for this release.

Examples
This example shows how to configure VLAN 20 as a primary VLAN, VLAN 501 as an isolated
VLAN, and VLANs 502 and 503 as community VLANs, and to associate them in a private
VLAN:
Switch# configure terminal
Switch(config)# vlan 20
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# exit
Switch(config)# vlan 501
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# exit
Switch(config)# vlan 502
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# exit
Switch(config)# vlan 503
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# private-vlan association 501-503
Switch(config-vlan)# end

You can verify your setting by entering the show vlan private-vlan or show interfaces
status privileged EXEC command.
Related Commands
Command Description
show interfaces Displays the status of interfaces, including the
status VLANs to which they belong.

show vlan private- Displays the private VLANs and VLAN associations
vlan configured on the switch.

switchport mode Configures a private-VLAN port as a host port or

private-vlan promiscuous port.

private-vlan mapping
Use the private-vlan mapping interface configuration command on a switch virtual interface
(SVI) to create a mapping between a private-VLAN primary and secondary VLANs so that
both VLANs share the same primary VLAN SVI. Use the no form of this command to remove
private-VLAN mappings from the SVI.
private-vlan mapping {[add | remove] secondary-vlan-list}
no private-vlan mapping
This command is available only if the switch is running the enhanced multilayer image (EMI).

Stefan Löfgren 6
Netcenter/IDE
Mälardalens högskola
 Private Virtual LANs

Syntax Description
secondary- Specify one or more secondary VLANs to be mapped to
vlan-list the primary VLAN SVI.

add (Optional) Map the secondary VLAN to the primary VLAN

SVI.

remove (Optional) Remove the mapping between the secondary

VLAN and the primary VLAN SVI.

Note The switch must be in VTP transparent mode when you configure private VLANs.

Defaults
The default is to have no private VLAN SVI mapping configured.
Command Modes
Interface configuration
Command History
Release Modification
12.2(20)SE This command was introduced.

Usage Guidelines
The SVI of the primary VLAN is created at Layer 3.
Configure Layer 3 VLAN interfaces (SVIs) only for primary VLANs. You cannot configure
Layer 3 VLAN interfaces for secondary VLANs. SVIs for secondary VLANs are inactive while
the VLAN is configured as a secondary VLAN.
The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-
separated items. Each item can be a single private-VLAN ID or a hyphenated range of
private-VLAN IDs. The list can contain one isolated VLAN and multiple community VLANs.
Traffic that is received on the secondary VLAN is routed by the SVI of the primary VLAN.
A secondary VLAN can be mapped to only one primary SVI. IF you configure the primary
VLAN as a secondary VLAN, all SVIs specified in this command are brought down.
If you configure a mapping between two VLANs that do not have a valid Layer 2 private-
VLAN association, the mapping configuration does not take effect.
Examples
This example shows how to map the interface of VLAN 20 to the SVI of VLAN 18:
Switch# configure terminal
Switch# interface vlan 18
Switch(config-if)# private-vlan mapping 20
Switch(config-vlan)# end
Stefan Löfgren 7
Netcenter/IDE
Mälardalens högskola
 Private Virtual LANs

This example shows how to permit routing of secondary VLAN traffic from secondary VLANs
303 to 305 and 307 through VLAN 20 SVI:
Switch# configure terminal
Switch# interface vlan 20
Switch(config-if)# private-vlan mapping 303-305, 307
Switch(config-vlan)# end

You can verify your setting by entering the show interfaces private-vlan mapping
privileged EXEC command.
Related Commands
Command Description
show interfaces private- Display private-VLAN mapping information
vlan mapping for the VLAN SVIs.

Stefan Löfgren 8
Netcenter/IDE
Mälardalens högskola