I am trying to figure out some strange behavior associated with VTP pruning. Specifically, I have a 6500 serving as a VTP server. While most of my switches are in VTP Client, there are a few in Transparent mode. I am aware of the functionality of the three modes, e.g. Transparent passes tagged traffic and propagates advertisements, but does not itself send/receive VTP updates.
In my situation, the VTP server pruned off one of the VLANs. OK, no problem, we corrected this by telling the interface specifically which VLANs to propagate (switchport trunk allowd ... ) and to not prune anything. But today, I noticed that a client (an access point) attached to the transparent switch was unreachable, and determined one VLAN was not included in the list. So I used the "switchport trunk allowed vlan add XX" to include the new vlan. Now the AP is reachable again. So far, so good, right?
Here's where it gets squirrelly ... looking at the trunk link from the VTP Server, the interface is still pruning the VLAN I just added. This despite that fact that the device is now reachable. IN ADDITION, the issue came to light b/c another client device on the transparent switch was unreachable ... except that, when I went to the switch, plugged my laptop into the SAME PORT, I received a DHCP address and could pass traffic.
In a related scenario last week, I had all the same symptoms, but in addition, the client device that was having communication problems was unreachable from WITHIN the same VLAN. Outside of that VLAN, the device was reachable (again, the problem VLAN was being pruned). I'[m guessing ARP requests from within the subnet were being pruned, but why were proxy ARP requests from the gateway sent and responded to? This problem was fixed by moving the switch into client mode, which is not an option with the current scenario.
We have seen this issue repeatedly. I believe it has always been on the border between two different VTP domains or where a transparent switch connects to a server.
We can get the VLANs back on the trunk by shutting/no shutting the interface; but that is not always practical.
We've disabled VTP pruning on boths sides of the link, and specified "switchport trunk pruning vlan none" on the interface. But the probematic VLAN remains pruned until we bounce the interface.
Has anyone else seen this? Is there another workaround?
Had the same issue recently
It occurred between a 6509(vtp server) and a 2950 (vtp transparent)
All the vlans except Vlan1 were pruned on the server side.
We inserted "switchport trunk pruning vlan none" to the trunk interface and it was resolved.