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
