Deployment automation is often a great way to ease procedures and avoid human errors when having to repeat the same tasks multiple times.
Today we are going to focus on VLAN Trunking Protocol, or VTP, which is a Cisco-proprietary protocol used to deploy and manage VLAN databases on most of Catalyst devices. We are going to focus more specifically on when VTP may be useful, what are the particular precautions need to be taken into account in order to avoid breaking your LAN and how switching operations can be optimized by taking advantage of VTP pruning.
The following points will be discussed in this post:
- VTPv2 (VTPv3 coming soon)
- VTP modes : Server, Client and Transparent
- VTP Packet Types
- Manual VLAN Pruning
- VTP Pruning
- Miscellaneous Caveats and Risks
- Additional Information and Resources
Let’s consider the following topology:
The main purpose of VTP is to reduce the administrative tasks load when maintaining VLAN in a switched topology. Before using a particular VLAN, the vlan global configuration command has to be issued to place it into the vlan.dat file.
VTP simplifies VLAN management by informing other switches about VLAN changes performed by an administrator on a single box without having to issue the same command over and over on every device in the network.
VTP is on by default (VTPv3 can be turned off actually, but this is out of the scope of this article) and cannot be turned off. This does not really matter since this protocol is not processor intensive and can run almost transparently when not used.
The VTP diffusion area is defined as the VTP Domain. Each device participating in the VTP exchange must agree on this value (case-sensitive).
The VLAN table version is kept by the configuration revision number. Devices are fully synchronized when the configuration revision number is the same on all switches. Also it is possible to ensure that the information shared between all switches has not been corrupted by looking at the resulting hash with the show vtp status command.
The main difference between VTPv1 and v2 is that version 2 adds support for Token Ring topologies. The map gap resides between VTP version 2 and version 3.
1- VTP Modes
3 modes are available in VTP, to allow / prevent a switch from either originating changes or processing incoming updates:
- Server: VLANs can be added/remove/edited on this device directly. VTP updates will be triggered for other switches in the network. This is the default mode.
- Client: The VLAN database cannot be edited directly from this switch for security reasons. However updates from switches in the ‘Server’ mode are processed. Trying to perform a change locally would raise an error message specifying that the switch is in client mode.
- Transparent: The switch simply does not participate in the VTP conversation. Changes are performed locally and the ‘vlan’ commands are added to the running-config. Notice that transparent switches do forward VTP updates to other devices, so that they do not block VTP traffic in any way.
2- VTP Message Types
The way VTP communicates is fairly straightforward; there are 4 message types:
- Summary advertisement: Switches periodically (every 5 minutes) flood summary information about its VLAN database, including the configuration revision number and the domain name. This message does not contain the VLAN list, which is contained in the subset advertisement. The ‘follower’ field specifies whether the summary advertisement is followed by a subset advertisement, e.g after a VLAN change
Inside a Summary Advertisement
A Summary Advertisement followed by a Subset Advertisement
In this example, can see a change in the topology, advertised by a first summary advertisement with a new configuration number of 5, followed by a subset advertisement, which contains the effective VLAN list. After the situation is back to normal, periodic flooding continues and we can see that 5 minutes later, a summary advertisement has been flooded, without any additional subset advertisement.
- Subset Advertisement: The Subset Advertisement is the actual VTP update message: VLAN information synchronized among the switches are placed into this packet. Since the VLAN database may be pretty large, these Subset Advertisements are defined by sequence number.
- Advertisement Request: The switch actively asks for a Subset Advertisement to be sent to it, for one of the following reasons:
- The switch has rebooted and needs to re-build its VLAN database as quickly as possible
- The VTP domain name has been changed.
- The switch receives a summary advertisement with a higher configuration revision number
- Join/Prune: This message is used to inform other devices of active VLANs on the switch. Refer to the ‘Pruning’ section for more information about this message type.
3- Manual VLAN Pruning
Manual VLAN Pruning means to limit which VLANs are allowed over a specific trunk, by contrast with ‘VTP Pruning’ which uses a protocol to dynamically discover and prune unnecessary broadcast traffic.
Let’s take our initial topology to illustrate manual pruning works:
- Two VLANs are configured here: VLAN 10 (Data at 10.1.10.0/24) and VLAN 99 (Management at 10.1.99.0/24)
- Each switch has two SVI, one for each VLAN with and IP address of 10.1.X.Y, where X is the VLAN number and Y the switch number.
- The hypervisor has an IP address of 10.1.10.10.
- E1/2 on SW4 is a trunk link where all VLANs except VLAN 1 and 10 have been manually pruned.
switchport trunk allowed vlan 1,10
switchport trunk encapsulation dot1q
switchport mode trunk
The show interface Ethernet1/2 switchport and show interface trunk commands allows to verify which VLAN are enabled on the trunk.
show interface Ethernet1/2 switchport
Let’s verify how the behavior changes depending on the VLAN we are generating traffic on. The capture is placed on SW4’s E1/2:
- The ping is successful as VLAN 10 is allowed on the trunk.
- However, when pinging a random IP address in VLAN, no arp request gets flooded though E1/2, confirming that the VLAN is manually pruned on the link:
4- VTP Pruning
The primary goal of VTP pruning is to reduce unnecessary broadcast traffic on trunk links. The concept is based on the fact that allowing a VLAN on trunk manually does not mean that there will always be a device listening for traffic on that link and on this VLAN.
So when two switches are connected over a trunk that allows all VLANs, all VLANs without any device connected to on the downstream switch would get pruned by VTP dynamically, until the switch explicitly requests data traffic for it.
- SW1 and SW4 are connected through a trunk link allowing VLANs from 1 to 100
- All traffic from the hypervisor is part of VLAN 11
- Each switch has an SVI 10.
Based on this topology, it is obvious that broadcast, multicast and unknown unicast flows on VLANs 2-9 and 12-100 won’t lead to a valid destination if SW1 chooses to forward them to SW4.
In order to avoid such flows to be flooded unnecessarilly to SW4, the VTP Join/Prune message contains a list of VLANs that are used by a local switch in order to tell neighbors which VLANs they can prune or not. This list is included in all messages:
- VLAN 1 is pruning-ineligible.
- VLAN corresponds to the SVI on SW4.
- VLAN 11 is E1/2 that connects to the hypervisor.
VTP Pruning configuration is fairly straightforward: enabling the feature with the vtp pruning global configuration command on a VTP server propagates the feature accross the domain. VTP pruning can be configured on a per-interface basis with the switchport trunk pruning vlan command.
The final result can be verified on the switches with the show interface pruning command.
- As seen in the capture, all VLANs allowed on the trunk that were not explicitly asked by SW4 are pruned by SW1. Consequently, bradcast frames belonging to these VLANs will not be flooded out of E1/0 anymore, reducing bandwidth utilization.
- As SW1 has an SVI in VLAN10, it explicitly sends the information to SW4.
- No information is reported as VTP only runs on Trunk links.
- If you configure E1/2 on SW4 as a trunk link, it will wait for VTP messages containing pruning information. If no VTP messages are received, pruning simply allows all VLANs. Consequently VTP Pruning would fail and all VLANs would be allowed on all links over the network. To avoid such behavior, disable VTP on the interface (A dedicated post will be discuss this issue).
5- Miscellaneous and Caveats
- VTP messages are sent on trunk links only.
- VTP domain mismatch causes a DTP negotiation failure if the link is in dynamic mode:
- VTP Pruning only works with standard VLANs.
- VTP version 1 and 2 are known to be error prone and insecure. Indeed, it is pretty easy to bring a new switch in the network without resetting the configuration number (either by changing the VTP or by setting the VTP mode to ‘Transparent’ and then back to ‘Server’). Overriding the VTP configuration will instantly break the whole LAN, which explains why VTP is not that used in real production environments. VTP version 3 fixes these issues by introducing a ‘Primary Master’ role, but this is out of the scope of this post.
- VLAN 1, 1002-1005 are always pruning-ineligible.