Stubby Post – Null VTP Domain Scare
Remember a few weeks back when I had a bad day? I was actually at HQ that day to do some work for a project, but that got put off due to the extenuating circumstances. When we finally got back around to do the work, we wound up adding a switch in the data center to extend a VLAN over to a rack.When we cabled the new switch up, the trunks didn't come up immediately. We got a log messages that complained that the VTP domains were mismatched and that the trunks couldn't be negotiated. Here's what we saw.
%DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Gi0/25 because of VTP domain mismatch.
%DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Gi0/26 because of VTP domain mismatch.
That scared me a bit, but, a few seconds later, all the trunks came up and started passing traffic. After a little looksie, we realized that the switch we added had a null VTP domain and was in server mode. When connected to another switch via a trunk, a switch in this configuration will listen out for any VTP information and will add itself to any VTP domain it finds. Since we had an established domain on the upstream switch, the new switch added itself to the domain and brought the trunks up. The scare was little more than a little naivety mixed with a dash of paranoia from the early debacle.
Obviously, this is not the way we want to do switch implementations. Rule #1 for putting a switch on the network: Set the VTP domain and mode before you plug it into the network.
Off topic: This project is seriously cursed.
Send any magic potions questions my way.
https://masto.ai/@aconaway
- Generating Network Diagrams from Netbox with Pynetbox - August 23, 2023
- Out-of-band Management – Useful Beyond Catastrophe - July 13, 2023
- Overlay Management - July 12, 2023
HI. this is my first post here.
On what concerns this phrase in your post "Obviously, this is not the way we want to do switch implementations. Rule #1 for putting a switch on the network: Set the VTP domain and mode before you plug it into the network."
I think, from reading the post, that you did not have passwords set in you VTP switches. Couldn't you have totally blew away the vlans on the whole network by plugging this new switch without changing it's configs? And if you had passwords set for the VTP switches, wouldn't it have prevented trashing the configs?
Sorry for the English (not my mother tongue)
KR
Fernando
Hi, Fernando. Thanks for reading! Your English is great! 🙂
You're absolutely right on both counts. We definitely could have blown away the whole network if things were just a little different, and the switch had a higher version number. Passwords are a great way to prevent that, but my preferred method is to set the mode to transparent since VTP is pretty worthless to us.
Hi Aaron. Thanks for the fast reply! But your answer raises another question: How can it be that VTP is worthless to you? Do you guys work only with native VLANS (don't think so) or do you manually set VLANS on every switch (when in server mode, I guess that's how it's done) than you change it to client before plugging it to the network?
Thanks in advance for the reply!
Hi, Fernando. I totally misspoke when discussing modes. Our fix is to set the switches to transparent mode so they don't participate in VTP with other switches. I mentioned client mode in my comment above. Sorry about that. 🙁
VTP is worthless to us because of the number of switches on which our VLANs reside. At most, we have 5 or 6 switches for any VLAN, so it's not worth the risk of catastrophic failure if VTP bites us. If we had, say, 15 switches, we might reconsider.
All right, now it makes much more sense to me! By the way, great blog and great content! Keep up the good work!!! It is very important to us, network professionals, to have access to other networker's experiences in order to learn!