VTP PRUNING: Troubleshoot L2 Connectivity Issue

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 Cisco 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.

Broadcast traffic in a switched network without pruning

This figure shows a switched network without VTP pruning enabled. Port 1 on Switch A and Port 2 on Switch D are assigned to the Red VLAN. If a broadcast is sent from the host connected to Switch A, Switch A floods the broadcast and every switch in the network receives it, even though Switches C, E, and F have no ports in the Red VLAN.

Broadcast traffic in a switched network with pruning

This figure shows the same switched network with VTP pruning enabled. The broadcast traffic from Switch A is not forwarded to Switches C, E, and F because traffic for the Red VLAN has been pruned on the links shown (Port 5 on Switch B and Port 4 on Switch D).

When VTP pruning is enabled on a VTP server, pruning is enabled for the entire management domain. Making VLANs pruning-eligible or pruning-ineligible affects pruning eligibility for those VLANs on that trunk only (not on all switches in the VTP domain). VTP pruning takes effect several seconds after you enable it. VTP pruning does not prune traffic from VLANs that are pruning-ineligible. VLAN 1 and VLANs 1002 to 1005 are always pruning-ineligible; traffic from these VLANs cannot be pruned. Extended-range VLANs (VLAN IDs greater than 1005) are also pruning-ineligible.

The example:

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 10.10.1.144Protocol Address         Age (min) Hardware Addr   Type   InterfaceInternet 10.10.1.144           100   8cb6.4faa.8a41 ARPA   Vlan93

YES IT IS

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 10.10.1.144

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.1.144, 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.

It is referred from: https://supportforums.cisco.com/blog/150491/troubleshoot-l2-connectivity-issue-vtp-pruning

More about the Cisco configuration, please visit: http://www.3anetwork.com/blog