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.
... View more
Yes, it appears so: http://www.cisco.com/en/US/products/hw/switches/ps708/products_data_sheet0900aecd8017376e.html You can always check the Product Data Sheets under the particular product to find this type of information.
... View more