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.
Here are the configs. FYI, we resolved the issue the "proper" way but restricting the # of VLANs propagated from the VTP server. Of interest, one VLAN was left off (Vlan 5 below); I noticed an alarm from WCS that an AP on attached to the switch was unreachable (even though it was passing traffic??). So I added the Vlan back in to the allowed vlan list. It is passing traffic (can ping and telnet to AP), yet the Vlan is still pruned? So this is the part that I am trying to figure out! They are both configured with the same VTP domain, both have ver 2 enabled.
topology
6500 <--trunk--> 2924C-XL <--trunk--> AP, vlan 5
<--access --> client, vlan 8
VTP Server config
interface FastEthernet2/7
description East Gym
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,5,8,9,16,36,49,79
switchport trunk pruning vlan none
switchport mode trunk
no ip address
duplex full
end
VTP Server trunk output
mcmi-013a-core>sh int fa2/7 trun
Port Mode Encapsulation Status Native vlan
Fa2/7 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa2/7 1,5,8-9,16,36,49,79 <--Vlan 5 is allowed
Port Vlans allowed and active in management domain
Fa2/7 1,5,8-9,16,36,49,79 <--Vlan 5 is active
Port Vlans in spanning tree forwarding state and not pruned
Fa2/7 1,8-9,16,36,49,79 <--Notice Vlan 5 is pruned
VTP Transparent config (WS-C2924C-XL)
interface FastEthernet0/23 <--trunk port connecting to VTP server
switchport trunk encapsulation dot1q
switchport mode trunk
switchport priority extend trust
end
interface FastEthernet0/22 <-- Port attached to AP
switchport trunk encapsulation dot1q
switchport trunk native vlan 5
switchport trunk allowed vlan 1,5,9,1002-1005
switchport mode trunk
switchport priority extend trust
end
interface FastEthernet0/21 <-- connecting to original unreachable client
description card-services
switchport access vlan 8
switchport voice vlan 16
switchport priority extend cos 0
spanning-tree portfast
end
VTP Transparent CDP output [ 'sh int trunk' not available on 2924 :- \ ]
east-hall-sw1#sh cdp nei fa0/22 de
-------------------------
Device ID: east-hall-wgb
Entry address(es):
IP address: 10.5.4.91
Platform: cisco AIR-BR1310G-A-K9 , Capabilities: Trans-Bridge
Interface: FastEthernet0/22, Port ID (outgoing port): FastEthernet0
Holdtime : 166 sec
...
As you can see, the AP attached to fa0/22 has a 10.5.x.x address (which corresponds with Vlan 5). It is reachable via ping from both within and out of the subnet. (In some instances, we have seen devices not reachable from within the subnet, but are from outside the same VLAN).
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.
As I said, the problem appears to be resolved, but I have been unable to find any documentation directly addressing this. I have searched the Cisco site and examined most of the VTP documents, but no luck.
