Hot Downloads

VTP Pruning

Written by Administrator. Posted in Virtual Trunk Protocol (Cisco VTP)



As you would be aware a switched network creates one broadcast domain, similar to that of a VLAN powered network where all nodes belonging to the same VLAN are part of the same broadcast domain, receiving all broadcasts sent on their network.


The Broadcast And Unicast Problem In VLAN Networks

What we are about to see is how these broadcasts can actually create problems by flooding the VLAN network with unnecessary traffic, and depending on your network setup, this can prove to be a huge problem. The reason for this is because the trunk links interconecting your network switches will carry these broadcasts to every switch in the network, regardless of which VLAN the broadcast is intended for.


As shown and described, a host connected to a port configured for VLAN 2 on Switch 1 (first switch on the left), generates a network broadcast. Naturally, the switch will forward the broadcast out all ports assigned to the same VLAN it was received from, that is, VLAN 2.

In addition, the Catalyst switch will forward the broadcast out its trunk link, so it may reach all ports in the network assigned to VLAN 2. The Root switch receives the broadcast through one of it's trunks and immediately forwards it out the other two - towards Switch 2 & 3.

Switch 2 is delighted to receive the broadcast as it does in fact have one port assigned to VLAN 2. Switch 3 however, is a different case - it has no ports assigned to VLAN 2 and therefore will drop the broadcast packet it receives.

In this example, the bandwidth usage was ineffecient because one broadcast packet was sent over all possible trunk links, and was then dropped by Switch 3.

You might ask yourself 'So what's the big deal?'.

The problem here is small and can easily be ignored... but consider a network of fifteen or more 12 port switches (this translates to at least 210 nodes) and you can start to appreciate how serious the problem can get. To make things worse (and more realistic), consider you're using 24 port switches, then you're all of a sudden talking about more than 300 nodes!

To further help understand how serious the problem gets, let's take a look at our example network below:


Here we have a medium sized network powered by Cisco Catalyst switches. The two main switches up the top are the VTP servers and also perform 3rd layer switching by routing packets between the VLANs we've created.

Right below them you'll find our 2950's Catalyst switches which are connected to the core switches via redundant fiber trunk links. Directly below our 2950's are our 2948 Catalyst switches that connect all workstations to the network.

A workstation connected to a port assigned to VLAN 2 decided to send a network broadcast looking for a specific network resource. While the workstation is totally unaware of our network design and complexity, its broadcast is the reason all our trunks will flood with unwanted traffic, consuming valuable bandwidth!

Let's take a look at what happens:


We don't think describing the above is actually required as the diagram shows all the information we need and we're confident you will agree that we dealing with a big problem:)

So how do we fix this mess ?

Keep reading on as you're about to learn........


The Solution: Enabling VTP Pruning

VTP Pruning as you might have already guessed solves the above problem by reducing the unnecessary flooded traffic described previously. This is done by forwarding broadcasts and unknown unicast frames on a VLAN over trunk links only if the receiving end of the trunk has ports in that VLAN.


Looking at the above diagram you will notice that the Root Catalyst 3550 Switch receives a broadcast from Switch 1, but only forwards it out one of it's trunks. The Root Switch knows that the broadcast belongs to VLAN 2 and furthermore it's aware no port is assigned to VLAN 2 on Switch 3, therefore it won't forward it out the trunk that leads to that switch.


Support For VTP Pruning

The VTP Pruning service is supported by both VTP 1 and VTP 2 versions of the VTP protocol. With VTP 1, VTP pruning is possible with the use of additional VTP message types.

When a Cisco Catalyst switch has ports associated with a VLAN, it will send an advertisement to its neighboring switches informing them about the ports it has active on that VLAN. This information is then stored by the neighbors and used to decide if flooded traffic from a VLAN should be forwarded to the switch via the trunk port or not.

Note: VTP Pruning is disabled by default on all Cisco Catalyst switches and can be enabled by issuing the "set vtp pruning enable" command.

If this command is issued on the VTP Server(s) of your network, then pruning is enabled for the entire management domain.

VTP Pruning configuration and commands are covered in section 11.4 as outlined in the VLAN Introduction page, however, we should inform you that you can actually enable pruning for specific VLANs in your network.

When you enable VTP Pruning on your network, all VLANs become eligible for pruning on all trunk links. This default list of pruning eligibility can thankfully be modified to suite your needs but you must first clear all VLANs from the list using the "clear vtp prune-eligible vlan-range" command and then set the VLAN range you wish to add in the prune eligible list by issuing the following command: "set vtp prune-eligible vlan-range" where the 'vlan-range' is the actual inclusive range of VLANs e.g '2-20'.

By default, VLANs 2–1000 are eligible for pruning. VLAN 1 has a special meaning because it is normally used as a management VLAN and is never eligible for pruning, while VLANs 1001–1005 are also never eligible for pruning. If the VLANs are configured as pruning-ineligible, the flooding continues as illustrated in our examples.



VTP Pruning can in fact be an administrator's best friend in any Cisco powered network, increasing available bandwidth by restricting flooded traffic to those trunk links that the traffic must use to reach the destination devices.

At this point, we have also come to the end of the first part of our VLAN presentation. As we are still working on the second and final part of the VLAN topic, we hope these pages will keep you going until it is complete.


Previous - In-Depth Analysis Of VTP                                                                                           Beginning - VTP Introduction & Modes


Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V


  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup