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.
Steve BantzIT ManagerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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)
Steve BantzIT ManagerAuthor Commented:
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.
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.
Cyber security certifications or degree?

Cyber security is in demand—big-time. So what do you need to build a career in this lucrative field? Is a degree a must-have, or are industry-leading certifications more sought-after? Is it possible to break into cybersecurity without a bachelor’s or master’s degree in the field?

Steve BantzIT ManagerAuthor Commented:
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.
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. :)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Steve BantzIT ManagerAuthor Commented:
I appreciate it.  I get a little antsy dealing with VTP.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.