Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Cisco switch configured as a VTP client doesn't allow traffic on a particular VLAN
I have a brand new Cisco 9300 access layer switch that is trunked to a Dell Force 10 core switch. The core switch is a VTP Server for several VLANs. While the 9300 ports were configured for hosts, it was NOT a VTP client yet so it had no knowledge of our current VLAN structure. To give an example, I had a port configured "switchport access vlan 14." Once the server was brought online as an active access layer switch, it was configured as a VTP Client in our custom VTP domain. However, any device on vlan 14 cannot communicate past the 9300 switch even though the port channel tagged on the Force 10. In fact, I am simply re-using the port channel configured on the core switch to connect the trunk ports to the new 9300 switch. If I do a "show vlan" on the 9300 it shows my vlan 14 with the proper name as it is configured on the VTP server.
My question is, if a port was configured to exist on a particular VLAN before the switch was a VTP client, are there two conflicting VTP entries in the vtp.dat database on my 9300, one local and one obtained from the VTP server? It doesn't seem like this could be happening since "show vlan" looks identical to a different access layer switch that is a vtp client in the same environment.
My question is, if a port was configured to exist on a particular VLAN before the switch was a VTP client, are there two conflicting VTP entries in the vtp.dat database on my 9300, one local and one obtained from the VTP server? It doesn't seem like this could be happening since "show vlan" looks identical to a different access layer switch that is a vtp client in the same environment.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
VTP must match:
- VTP domain name
- VTP password
- VTP version may be significant
To propagate vlans may be needed to add VLAN. One of switches need to be configured as VTP server.
Port between switches need to be configured as trunk.
Move port to transparent mode, configure VTP domain name and VTP password, version and then move VTP to client mode (procedure will reset vtp revision number).
VLAN Configuration Guide, Cisco IOS XE Everest 16.6.x (Catalyst 9300 Switches)
- VTP domain name
- VTP password
- VTP version may be significant
To propagate vlans may be needed to add VLAN. One of switches need to be configured as VTP server.
Port between switches need to be configured as trunk.
Move port to transparent mode, configure VTP domain name and VTP password, version and then move VTP to client mode (procedure will reset vtp revision number).
VLAN Configuration Guide, Cisco IOS XE Everest 16.6.x (Catalyst 9300 Switches)
Well, I opened a case with Cisco just to see what they had to say. The technician said that the cause was VTP pruning because the two lists marked with red arrows below don't match. Cisco's advice was to disable VTP pruning on the Force 10 VTP server core switch and my problem would go away. VLAN 14 was missing as a vlan in spanning tree forwarding state and not pruned. I don't get why it IS pruned right now.
Advice by Cisco was to contact Dell support to disable VTP pruning and the problem will resolve itself.
Advice by Cisco was to contact Dell support to disable VTP pruning and the problem will resolve itself.
Most of the time that is normal output for show interface trunk. On upstream device in root direction all VLANs are listed "in forwarding state and not pruned", but on downstream device VLANs are pruned since none of downstream devices are requesting specific VLANs (no active ports for specific VLAN).
If there are issues that VLANs are pruned and not supposed to be... on vtp server trun off pruning as suggested by TAC.
If there are issues that VLANs are pruned and not supposed to be... on vtp server trun off pruning as suggested by TAC.
Thanks. I am just worried that there may be the possibility of impairing the network by turning off pruning. This is a 24/7 facility so there is really no off-hours to try it and revert if needed. Am I correct with the following thought? Once pruning is turned off on the VTP server, if I issue a "show interfaces trunk" on the switch, I should only see "Vlans allowed and active in management domain and no entries for "Vlans in spanning tree forwarding state and not pruned?" Just curious.
Both lists supposed to be the same without pruning - should list all VLANs on both.
One of next days I will try to test (if I find time) which side exactly drops VLAns, but if I remember correctly it was downstream device. But I will try to test to confirm it.
One of next days I will try to test (if I find time) which side exactly drops VLAns, but if I remember correctly it was downstream device. But I will try to test to confirm it.
Logic behind - upstream device has all VLANs and downstream not - if downstream device requires some VLAN it can just unblock it's own side and - traffic is flowing for that VLAN. It would require more "work" if upstream device dropped VLAN on trunk... but ... it is logic that I remember, but I may be wrong. But, generally, that's the idea. :)
Premium Content
You need an Expert Office subscription to comment.Start Free Trial