Showing results for 
Search instead for 
Did you mean: 

Troubleshoot L2 Connectivity Issue : VTP PRUNING

Cisco Employee


First of all a quick note on what VTP Pruning is:

VTP ensures that all switches in the VTP domain are aware of all VLANs. However, there are occasions when VTP can create unnecessary traffic. All unknown unicasts and broadcasts in a VLAN are flooded over the entire VLAN. All switches in the network receive all broadcasts, even in situations in which few users are connected in that VLAN. VTP pruning is a feature that you use in order to eliminate or prune this unnecessary traffic.

To read more, please refer the following link:

In my experience in LAN Switching TAC, I have come across network connectivity problems that have taken a lot of time to solve. Symptoms observed are as follows

  • Intermittent connectivity to host connect to an access switch
  • One way audio in IP telephony
  • Default gateway cannot ping few hosts and when traffic is initiated from host, pings from the default gateway magically starts working and all other devices can ping these host
  • Clients connected to same access switch can ping each other but clients connected to an upstream switch cannot and so on.

Typical setup is as follows

CORE MLS(gi1/1)-----trunk------Access Switch----Clients

In most cases CORE Switch is the default gateway for the Clients.

Typical Troubleshooting is as follows

1)      Is the ARP complete ?

CORE#sh ip arp Address         Age (min) Hardware Addr   Type   InterfaceInternet           100   8cb6.4faa.8a41 ARPA   Vlan93


2)  Is the switch learning mac address ?

CORE# sh mac-address-table address 8cb6.4faa.8a41 <NOT LEARNING MAC ADDRESS>

That should not cause connectivity loss as the packets will be flooded and will make its way to the clients

3)  Lets check the spanning tree status for vlan 93

CORE # show spanning-tree vlan 93<SNIP>Gigabitethernet 1/1 shows forwarding

Well, spanning tree status is forwarding – so my packets are supposed to leave interface Gi1/1

Lets SPAN interface Gi1/1 and see if packets are leaving – Result: SPAN Captures show no packets leave the interface.

Crazy !! so it is the CORE switch that is culprit – lets replace it ??

NO WAY -- Are we sure it is a hardware issue – No

What have we missed ? Hmm.. Lets add a static mac entry and see if that helps

CORE(config)# mac address-table static 8cb6.4faa.8a41 vlan 93 int gi1/1

CORE# ping

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Lets remove the static mac address and now initiate traffic from end client –
mac address learned and everyone in the network can reach the client

From the troubleshhoting performed so far the observations made are as follows:

We intermittently lose connectivity to client. When traffic is initiated from client, we are immediately able to establish
connectivity to client and finally, we observe that the problem is seen when mac address of client ages out on the CORE switch

So what feature can block unicast flooding?

switchport block unicast command on the interface - not configured here

VTP pruning – Ah ha!!

Let us check if any vlan is pruned

CORE#show int gi1/1 trunk

Port          Mode         Encapsulation  Status        Native vlan

Gi1/1        on           802.1q         trunking      1

Port          Vlans allowed on trunk

Gi1/1        1-4094

Port          Vlans allowed and active in management domain

Gi1/1        1,10-18,20-30,32,60-61,90-103,111,138,155-156,201-203,400

Port          Vlans in spanning tree forwarding state and not pruned

Gi1/1        1,10,22

Also check

CORE#show int gi1/1 pruning

Port      Vlans pruned for lack of request by neighbor

Gi1/1    11-18,20-21,23-30,32,60-61,90-103,111,138,155-156,201-203,400 
-> All these VLAN’s are pruned because neighbor did not request for them

Port      Vlan traffic requested of neighbor

Gi1/1    1,10-18,20-30,32,60-61,90-103,111,138,155-156,201-203,400 
-> This is what CORE Switch is requesting from its neighbor switch

So VTP pruning was the culprit – As the mac address of end client aged out, the switch would have to unicast flood the packet to all ports on
VLAN 93, which is not sent on Gi1/1 as VLAN 93 was pruned.

Once VTP pruning is turned off – All connectivity issues are corrected.

When can such a scenario occur ?

1)  In environment which has switches in VTP server/client mode along with switch that maybe in VTP transparent mode

2)  When a non Cisco switch that does not understand VTP is connected to a Cisco Switch which has VTP turned ON (in most cases)

So please keep in mind that VTP pruning can be the cause of connectivity issues.

In an all Cisco environment where all switches are configured to be in VTP server or client mode, you can turn ON VTP pruning as this will help limit unnecessary flooding in the network and is of great help.

After all, VTP pruning need not be a PIA

(PS: For those of you who are wondering what PIA stands for.. Don’t worry about it )

Cisco Employee

very informative. Nice Blog  !!!! Congrats ..


Also worth noting is that when the VTP server in the domain is configured for pruning, all clients will then go into pruning mode.

Good idea to write this - it usually causes even troubleshooting pros to waste a lot of time, so keep it in mind.  Unicast flooding and broadcasts may not pass, but unicast will.  That's the key observation, indeed.

It's also good to consider if pruning is helping even when things are working fine, maybe you can disable VTP pruning.  While we are doing that, maybe VTP isn't that useful day-to-day, after you have provisioned all your VLANs and your network is humming along.  Maybe go to transparent after VLAN changes become infrequent.

Very nice document!! Thanks for posting it


We've hit this problem while changing part our network into vtp transparent mode. We've lost whole next day troubleshooting - in our example, some of IP phones couldn't talk with each other & there was no other network related issues reported. Thanks for this manual rparames!