VTP not passing on trunk interface

[Ruhtra]

Had an odd issue with VTP not passing on a trunk interface.  All devices are on the same vtp domain.

My VTP server is a 9606 VSS pair running 17.06.04.  Have 100+ C9300 field switch stacks.  Running either 17.12.04 or 17.03.05.  I have a new C9606 VSS pair for server room.  Because I have the high density blades in it, I am running 17.15.01.

I do not have vlan 1 explicitly added to any trunk interface.  However I did have to add vlan 1 to the trunk interface of the new C9606 server room running the new IOS in order for VTP packets to pass.  CDP also uses vlan 1, and I was able to see that before having to explicitly add it.

Nothing in the Cisco bug database about this.  Just want to bring awareness.  Cisco is looking in to it.

[Mark Elsen]

  - @Ruhtra    Well in my opinion you need vlan 1 on every trunk, because it carries the VTP protocol ,

  M.

[Ruhtra]

I don't disagree.  I am pointing out that this is new behavior.  Never needed to explicitly add it to the allowed vlan command before.  vlan 1 was always implied allowed.  The only interface that needs it in my environment is this new 9606 with the 17.15.01 IOS.  I also notice today that 17.15.04 is now a recommended release.  Cisco has only had 17.12.04 for the longest time.

[Cristian Matei]

Hi,

@Ruhtra , @Mark Elsen  In the now very very old code / days of IOS-XE, VLAN 1 could not have been removed from a trunk link, as VTP and other pure layer 2 protocols like CDP, LLDP, DTP, LACP, PAGP, used VLAN 1.

    For also a very long time now, this dependency has been removed, when Cisco added what they called VLAN 1minimization, the option to remove VLAN 1 from being allowed on any trunk link, and all above mentioned pure layer 2 protocols to still function, as these protocols are no longer tied to a VLAN now, it's just protocols that once enabled it will work. And this is the expected outcome in today's codes. What you're seeing is obviously a bug, no matter what Cisco TAC says or claims. Ask for new BUG to filled, documented, and fix release to be known.

Thanks,

Cristian.

[Ruhtra]

I did open a TAC case.  They are in the process of trying to recreate the issue.

[Ruhtra]

I was able to update the 9606 to 17.15.04.  I removed vlan 1 from the trunk and validated that VTP updates were still passing.  So is definitely a bug with 17.15.01 in a very specific hardware configuration.  But looking at my original post I see I need to add some additional information in case anyone cares.  Information I noticed after my original post.

I originally setup the 9606 VSS pair with 17.15.01 because that was the minimum needed to support the C9600X-LC-56YL4C blades.  At the time the only Gold Star IOS was 17.12.04.  17.15.x were all ED.  I used 10/25 SFP's in port 1 of those blades for my Stackwise Link because the 100Gb QSFP were on back order.  At that time VTP updates were working. 

Months later the QSFPs showed up and were installed.  It was a few weeks after that when I needed to add vlans and noticed that VTP wasn't updating on only this 9606 with 17.15.01.  Everything else in my network was fine.  The only change was moving the VSS virtual link to the new QSFPs.  So a very specific configuration where this behavior exhibited.  Glad we have an MD version now supporting these high-density blades.