Fundamentals: VLANs, Trunks, PVLANs, and VTP

VLAN = a single broadcast domain = logical network segment (subnet)

VLANs are used to segment large broadcast domains into smaller, more manageable sections. By default, all switch ports are assigned to VLAN 1, type Ethernet, and MTU of 1500 bytes.

Note: End user devices associated with a VLAN are unaware that the VLAN even exists.

To create a VLAN:

Switch# conf t
Switch(config)# vlan 43
Switch(config-vlan)# name Marketing
Switch(config-vlan)# exit

Assign it to an interface:

Switch(config)# int fa 1/23
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 43
Switch(config-if)# no shut

To delete a VLAN:

Switch(config)# no vlan 43

There are two types of VLAN configuration, static and dynamic. The most common method is static because it is simple and easy to configure. It must be configured on every interface for every device.

A VLAN Membership Policy Server can be used to dynamically assign ports to a VLAN – based on the source MAC address of the host that is attached to the interface. If the same host moves to another switch port on the network, the new interface is automatically assigned to the proper VLAN.

VLAN Models

End-to-end (or campus-wide VLAN deployments)
Every VLAN is made available to every access switch across the network. In this option, broadcasts must cross the core and suck up valuable trunk resources. Usually use VTP Client/Server modes.

This model is sometimes implemented for two reasons. First, users can connect to any switch port independent of their physical location and be placed on the correct VLAN. Second, resource and security parameters can be defined for all members of a particular VLAN and can be updated from a central location.

Uses layer three at the distribution layer to keep inter-VLAN traffic within that switch block and is better suited for environments where most traffic is not locally destined. Usually uses VTP transparent mode because you don’t want the VLANs propagated around he network (hence, “local”). In this model, a VLAN should not extend past it’s distribution switch.

The 80/20 Rule
Back in the 1990′s when most network resources were local (ex. printers, servers), a design rule developed known as the “80/20 rule”. The rule stated that you should design network boundaries such that 80% of traffic stays within the local subnet (doesn’t cross a backbone or leave the VLAN) and only around 20% of traffic should be destined for remote sites (ex. Internet). Well the enterprise and computing environment has changed dramatically since then with web-based services exploding – and now the new recommendation is the opposite, the 20/80 rule. That means that 20% of traffic is local and 80% traverses the distribution layer/core.

It’s an important concept because the local VLAN model generally follows the opposite approach of the 80/20 rule, where most traffic is is destined remotely. Remember that.

Best practices for VLAN design

  • For the local VLANs model, limit 1-3 VLANs per access switch and limit those VLANs to only a couple access switches and the distribution switches.
  • Avoid using VLAN 1 as the “blackhole” for all unused ports.
  • Try to separate voice, data, management, default, and blackhole VLANs (each assigned their own VLAN ID).
  • In the local VLANs model, avoid VTP (use transparent mode).
  • Turn off DTP on trunk ports and configure them manually – also use IEEE 802.1Q over ISL.
  • Manually configure access ports that are not intended to be trunks by using the switchport mode host command. (disables EtherChannel, disables trunking, and enables PortFast)
  • Prevent all data traffic from VLAN 1.
  • Avoid Telnet on management VLANs, use SSH instead.

User access ports are typically at least Fast Ethernet or Gigabit Ethernet. Links between the access and distribution layers are typically Gigabit Ethernet or faster, layer 2, and have an oversubscription ratio of no more than 20:1. Links between the distribution and core should be Gigabit Etherchannel or 10-Gig Ethernet with an oversubscription ratio of no more than 4:1.

VLAN Troubleshooting Steps

  1. Physical Connection OK?
    No – Check with CDP; fix any cabling or duplex problems
  2. Router and switch configuration OK?
    No – compare configurations and fix inconsistencies
  3. VLAN configuration OK?
    No – Fix VLAN problems

VLAN Verification

To determine the trunking status of an interface:

#show int fa 1/24 trunk

A simpler alternative would be:

#show trunk

For more detailed switchport information:

#show int fa 1/24 switchport

Note: If you are troubleshooting a trunk link with this command and notice that the operational mode description says “down”, the interface itself is shutdown and needs to be started with the no shut command.

To determine the physical status of a link:

#show int fa 1/24 status

To see a list of VLANs and their assigned interfaces:

#show vlan brief

To check if an interface is assigned to a specific VLAN:

#show vlan id 100

This command is especially helpful as it displays all ports belonging to the VLAN as well as the MTU of each assigned port and type.

To see a complete detailed interface list for all VLANs:

#show vlan

Note: The show vlan command does not include trunk ports in its VLAN port output as they carry a variety of VLANs.

VLAN Trunking

There are two frame tagging methods for trunk links:

Cisco proprietary, adds own frame header and CRC.

The ISL header is 26 bytes and it appends and additional CRC which is 4 bytes, for a total of 30 additional bytes to every ISL encapsulated frame. Because it it proprietary, ISL trunk encapsulation will only work with Cisco devices – and not all Cisco switches even support it.

Open standard, inserts its own 4 byte tag within frame and recalculated the CRC value, allows for native VLANs (untagged frames to go through).

802.1Q has become the dominate layer 2 trunking protocol in use today as fewer organizations use Cisco’s proprietary ISL. 802.1Q also adds a 4 byte tag into the Ethernet frame for VLAN tagging and is designed exclusively for point-to-point links. The 4 byte field that is inserted by 802.1Q does not interfere with the original frame header, so the MAC source/destination information is unchanged.

802.1Q is often used by service providers for a tunneling secure VPNs. 802.1Q tunneling feature allows ISPs to segregate different customer’s traffic throughout their infrastructure.

Using 802.1Q or ISL can create problems with their tagging methods. The maximum size for any frame as specified by IEEE 802.3 is 1518 bytes. That means that if a frame entering a trunk port is already near the maximum size, the header and CRC added by ISL or the inserted tag and CRC added by 802.1Q will push the frame size over the IEEE limit. To resolve this conflict, the IEEE 802.3 committee created a subgroup – 802.3ac that extended the maximum Ethernet frame size to 1522 bytes. If you see the “Giants” counter on an interface anything other than zero, this is likely the cause.

DTP (Dynamic Trunking Protocol) is a proprietary protocol for negotiating a common trunking mode between two switches.

To configure a VLAN trunk interface:

Switch(config)# int fa 1/5
Switch(config-if)# switchport
Switch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate}
Switch(config-if)#switchport trunk native vlan 1 (for 802.1Q trunks only)
Switch(config-if)# switchport trunk allowed vlan {list | add list | remove list}
Switch(config-if)# switchport mode {trunk | dynamic {desirable | auto}}

If set to dynamic, it defaults to ISL if not specified.

Trunk links by default allow all active VLANs (those that the switch knows about). Also, all dot1Q trunks use VLAN 1 as the default native VLAN.

It is recommended to specifically allow only VLANs that cross the trunk using the switchport trunk allowed vlan command. Because the switch will forward broadcasts out all ports on that VLAN, frames will be forwarded over the trunk too – which wastes trunk bandwidth.

If an non-trunking port receives an ISL encapsulated frame, it will not be able to remove the ISL header and will by default drop the ISL frames. If a non-trunking port receives an 802.1Q encapsulated frame, it simply reads the destination MAC address and forwards the frame as it would any other layer 2 frame.

Trunking Modes

Make sure you understand how these trunking modes interact because it makes easy test material. Notice that even dynamic desirable (the most aggressive dynamic trunking mode) will still not form a trunk if the other end is configured as an access port.

Trunk – manual permanent trunking mode

Dynamic desirable (default) – the port actively tries to bring up the link as a trunk, sending negotiations with the other end

Dynamic auto – the port can be converted to a trunk link, but only if the far end requests it

Nonegotiate – puts the interface into permanent trunking mode and does not send DTP frames

 Dynamic AutoDynamic DesirableTrunkAccess
Dynamic AutoAccessTrunkTrunkAccess
Dynamic DesirableTrunkTrunkTrunkAccess
TrunkTrunkTrunkTrunkLimited Connectivity
AccessAccessAccessLimited ConnectivityAccess

Trunk Troubleshooting

When troubleshooting a trunk link, all of the following must be set the same on both ends:

  • trunking mode (trunk, dynamic auto, dynamic desirable )
  • encapsulation
  • native VLANs (For dot1Q only and will only break native VLAN traffic if mismatched)
  • allowed VLANs

If you are required to troubleshoot VLAN traffic that is not being passed across a trunk, make sure that the VLAN is in the interface allowed list for each side of the trunk. While all VLANs are allowed by default across trunk links, many organizations explicitly define allowed VLANs over trunks for security and to prevent unnecessary broadcast traffic on the link.

Native VLANs

It is important that the native VLAN is configured correctly on both sides of an 802.1Q trunk. Native VLAN is a “default” VLAN that allows frames to be passed through the trunk untagged. If there were devices in the middle of the trunk that required line access, they could use the native VLAN. This is a rare situation, but worth understanding.


Vlan Trunking Protocol uses layer 2 trunk frames to communicate VLAN information among switches. It manages the addition, deletion, and renaming of VLANs across the network from a single source.

  • Organized into domains (only one per switch). Each switch within that domain must have the same VTP domain name configured otherwise database information will not be synchronized. Because each switch can only be configured with a single VTP domain, it will only listen and act on VTP advertisements it hears that match its own VTP domain name.
  • Advertisements are used to communicate changes to other switches
VTP Modes

Server mode
These switches have full control for creation and changes to VLANs. All changed are advertised out to all other switches. Each domain has at least one VTP server.

Client mode
Cannot create or change VLANs, but they do send periodic advertisements and can change their configurations to match those they hear.

Transparent mode
Do not participate in VTP. In VTP version 1, a switch in transparent mode inspects VTP messages for the domain name and version and forwards a message only if both match. VTP version 2 forwards VTP messages in transparent mode without checking the version – only a matching VTP domain name is required.

VTP Configuration Revision Number

VTP switches use an index called the VTP configuration revision number which is sent with VTP advertisements. The configuration revision number helps to identify changes to the network by increasing by one every time a change occurs. Every switch stores the revision number of the last advertisement they heard. If a switch receives an advertisement with a higher revision number than is stored locally, its configuration is changed to reflect the new advertisement and forwards the advertisement to it’s neighbor switches.

If the revision number is the same as in its database, it simply ignores the advertisement. Finally, if the number in the advertisement is lower than the number stored in its database, the switch will respond back with more current VLAN information.

It is important to set the revision number to 0 before inserting a new switch into a production environment. Transparent mode’s revision number is always 0. There are two ways to do it:

  1. Change it to transparent mode, then back to server.
  2. Change the VTP domain name to a bogus name, then change it back to the original.

If a switch is set to server (the default) or client and is inserted into the environment with a higher rev. number than the last advertisement, a VTP synchronization problem occurs, potentially disabling all VLAN-assigned ports. Note that even a client with a higher revision number can take down the entire network if it propagates its VLAN database to its peers – so be very careful when adding new switches!

Also, VTP information is stored in flash in the vlan.dat file. That way it survives reboots.

To check the VTP revision number:

Switch# show vtp status

VTP Message Types

There are three different types of VTP messages:

Summary advertisements
Sent from all switches every 300 seconds (5 minutes) and after any VLAN-related changes (Added, removed, renamed)

Subset advertisements
VTP servers send subset advertisements after a VLAN change occurs that follow the summary advertisements. The provide more specific details into the changes.

Requests from clients
Clients can requests any VTP information they don’t have. The server will respond with a summary advertisement and subsequent subset advertisements.

VTP Versions

VTP has two versions (1 & 2) that are not interoperable. All that is required to change from v1 to v2 across the network is the change one server switch to v2 and it will send out an advertisement to all other switches to make the change as well. v1 is the default.

To configure a VTP server for v2:

Switch(config)# vtp version 2

VTP v2 has the following enhancements over v1:

  • Token Ring VLAN support
  • TLV support
  • Version-independent message forwarding
  • Performs consistency checks
VTP Pruning

VTP Pruning makes more efficient use of trunk bandwidth by reducing unnecessary flooded traffic over trunk links. Broadcasts and unicast frames are only transmitted over a trunk link if the switch on the receiving end of the trunk has ports in that VLAN.

By default, VTP pruning is disabled; to enable it:

Switch(config)# vtp pruning

When pruning is enabled on a server, it propagates the pruning to all switches in the management domain. (This is generally the quickest way to enable it within your switched network). Also, VLAN 1 is considered pruning ineligible by Cisco. VLANs 2-1000 are eligible for pruning by default.

VTP Configuration

Note: VTP information will not be exchanged without first configuring the VTP domain name.

Configuring a VTP Management Domain:

Switch(config)# vtp domain domain-name
Switch(config)# vtp mode {server | client | transparent}
Switch(config)# vtp password password

Note: If a VTP password is locally configured, the same password must be set on all VTP-participating switches.

After VTP is configured, the switch will begin passing the management domain, configuration revision number, and known VLANs and their parameters through its trunk links.

VTP Example Configuration

To configure a VTP server in Cisco IOS in configuration mode for VTP versions 1 and 2, follow these steps from privileged EXEC mode:

Step 1. Enter global configuration mode:

Switch# configure terminal

Step 2. Configure the VTP mode as server:

Switch(config)# vtp server

Step 3. Configure the domain name:

Switch(config)# vtp domain domain_name

Step 4. (Optional.) Enable VTP version 2:

Switch(config)# vtp version 2

Step 5. (Optional.) Specify a VTP password:

Switch(config)# vtp password password_string

Step 6. (Optional.) Enable VTP pruning in the management domain:

Switch(config)# vtp pruning

Verifying the VTP Configuration

To display information about the VTP configuration:

Switch# show vtp status

The show vtp status command is extremely valuable when troubleshooting a VTP issue. It shows the configuration register number on the switch, the VTP domain name, VTP version number, and VTP mode (ex. server).

To display statistics about the VTP operation:

Switch# show vtp counters

VTP Troubleshooting

Troubleshooting VTP if a switch does not seem to be receiving updates from a VTP server switch:

  1. Make sure the switch is not set to transparent mode.
  2. The link towards the VTP server may not be in trunking mode. Remember that VTP advertisements are only sent over trunked links. Perform a sh int xx/x switchport to verify.
  3. Make sure the VTP domain name matches that of the server (it is case sensitive).
  4. Make sure the VTP version is set the same.
  5. If using VTP passwords, make sure they match on both the server and client.

Private VLANs

Private VLANs allow you to prevent layer 2 connectivity between two devices within the same VLAN. An example would be two web servers that reside on the same network, but for security purposes, should never communicate. This allows a separated environment, but one that conserves IP addresses. Both ISPs and web hosting providers are frequent users of private VLANs.

Private VLAN ports are associated with a set of supporting VLANs. Only when both concepts are combined will private VLANs function properly. The terms Cisco uses are primary and secondary private VLANs. In a nutshell, a normal or primary VLAN can be associated with specially defined secondary private VLANs.

Private VLAN Port Types

There are two secondary private VLAN port types:

Complete layer 2 separation from other ports within the same private VLAN, except for promiscuous ports. All traffic to the port is blocked, except traffic from promiscuous ports. (Ex. a port configured for a highly-secure server)

Communicate among themselves as well as the promiscuous port. Several devices can belong to a common community private VLAN, in which they will only be able to talk to each other and the promiscuous port (ex. default gateway).

Note: All secondary VLANs must be associated with one primary VLAN. Also, VTP does not pass private VLAN information so the private VLAN configuration is only local to the switch they are configured on.

Interface Modes

Each physical switch interface that uses a private VLAN must be configured with a VLAN association.

The interface can be one of two modes:

They can communicate with all other ports within the private VLAN. These are usually assigned to router or VLAN interfaces as they need access to all the networked devices within the private VLAN. A promiscuous port is only part of one primary VLAN, but each promiscuous port can map to more than one secondary Private VLAN.

A switch port that connects to a regular host that resides in a community or isolated VLAN. The port only communicates with the promiscuous port or ports in the same community VLAN.

Private VLAN Configuration

1. Set the VTP mode to Transparent

Switch(config)# vtp mode transparent

2. Define the secondary VLAN(s)

Switch(config)# vlan 20
Switch(config-vlan)# private-vlan {isolated | community}

3. Define the primary VLAN

Switch(config)# vlan 10
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association {secondary-vlan-list | add secondary-vlan-list | remove secondary-vlan-list}

4. Define the physical interface

Switch(config-if)# switchport mode private-vlan {host | promiscuous}
Switch(config-if)# switchport private-vlan host association primary-vlan-id secondary-vlan-id
Switch(config-if)# switchport private-vlan mapping primary-vlan-id secondary-vlan-list | {add secondary-vlan-list} | {remove secondary-vlan-list}

** Interfaces set to promiscuous mode you must “map” the port to primary and secondary VLANs. Just remember that promiscuous ports are “mapped” and host ports are “associated”.

Private VLAN Configuration Example

This is getting messy, so let’s run through an example that configures both isolated and community secondary private VLANs as well as host and promiscuous interfaces:

Switch# conf t
Switch(config)# vtp mode transparent
Switch(config)# vlan 40
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 50
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 60
Switch(config-vlan)# private-vlan isolated
Switch(config)# vlan 100
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 40,50,60
Switch(config-vlan)# exit

Switch(config)# int fastethernet 0/4
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host association 100 40
Switch(config)# int fastethernet 0/5
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host association 100 50
Switch(config)# int fastethernet 0/6
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host association 100 60
Switch(config)# int fastethernet 0/1
Switch(config-if)# switchport mode private-vlan promiscuous
Switch(config-if)# switchport private-vlan mapping 100 40,50,60

Private VLANs on SVIs

On switched virtual interfaces (SVIs) or layer 3 VLANs with IP addresses, an additional map must be inserted. For this example, let’s use layer 3 VLAN 300 as the primary VLAN. Let’s also assume that we have already created and configured secondary private VLANs 80 and 90. These are the additional mapping steps that must occur:

Switch(config)# vlan 80
Switch(config-vlan)# private-vlan isolated
Switch(config)# vlan 90
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 300
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 80,90
Switch(config-vlan)# exit
Switch(config)# interface vlan 300
Switch(config-if)# ip address

At this point, VLAN 300 can communicate at layer 3, but the secondary VLANs (80 & 90) are stuck at layer 2. To allow the secondary VLANs to switch layer 3 traffic as well, you need to insert this mapping on the primary VLAN (SVI) interface:

Switch(config-if)# private-vlan mapping 80,90

Author Aaron

More posts by Aaron

Leave a Reply