Huge issue.. We have two VTP domains joined via a single vlan to establish connection between them. Is there anything at all that would cause the domain to swap? We just had this happen while working on the network.
Believe someone telneted in and accidentally changed them but is there anyway to find out this kind of info? I have a 3550 and a 4006 both VTP domain have different names and passwords doesn't make any sense.. Any help would greatlly be appreciated...
History this newly created VTP domain was running fine for the last 2 weeks with no issues.
when the switch recieves a VTP mesage, it compare the domain name in message with its own domain configured. If the 2 doesnt match then VTP messages are not exchanged.
As you said it could have been some human error. However you can secure your vtp domains with passwords. In this case both switches communicate only when both domain name & pwd matches.
hope that clarifies.
pls rate all helpful posts.
That is a real mystery. If the two domains have different names and passwords, then they should not exchange updates.
I am trying to think of exceptional events that might have triggered this change. Here is what I can think of:
1. Was any switch rebooted just before the domains changed? I cannot think of the mechanism behind any problem there, but if there was a reload, then it would be worth thinking it through.
2. Was any brand new switch added about that time. I know that if a brand new switch is added, it takes the first domain it sees.
3. Was any old switch added that might have been used in a lab environment, and might be carrying a higher configuration revision.
4. Do all your switches operate in client/server, or are some of them transparent?
5. Are you operating VTPv1 or VTPv2? (BTW, the show vtp status is misleading on this ... you need to look for "VTP V2 mode", not "VTP Version".)
6. Is there any clue in the "Configuration last modified" or "Local updater ID"?
I cannot think how this could have happened, but any of the above triggers could give us a clue which path to go down.
Nice to see your reply at this time of day. Most of your post's are actually in my eve timezone.
You think like a detective. I'm jst started & need to learn a lot.
I've a few doubts against each of your point's & am putting it accordingly.
1. I understand that when a switch comes up, it listen for vtp msg. But if its already configured for a domain, & see's a vtp msg with different domain then will it not ignore the msg. Assuming the switch was "wr mem" before it went down.
2. Since the domain interchanged on switches on which vtp was alrdy configured, I consider the problem between 2 of them & I'm not considering this point.
3. I've seen a higher config revision switch overwriting lower 1. I even read that a client mode switch with higher config rev num overwrites a server with lower rev num. But does it apply for switches in 2 diff domains.
4. Again, how does this point impact switches in dif domains.
5. how does it help?
6. Worth knowing configuration last modified.
Appreciate your reply.
I had to come into work very early to sort out a (non-)problem before the users got here! I guess you must be in Asia then .. India perhaps?
Thank you for the complement. I have always thought it would be interesting to work in forensics, and network toubleshooting and testing is the nearest I come to it.
The reasons behind this particular event are a mystery because, as you say, if switches are configured for different domains, then they should pay no heed to each other. Nevertheless, it is evident something did happen, and there was a cause.
Strange transient things can happen at boot time, and not always things that the software developer might have considered. Suppose, for example, you have a brand new switch, and you connect it so it can see both domains. You then switch it on for the first time. Which domain will it see first? Will it advertise what it sees to the other connection? I'm not saying that is the cause, but I am saying that if the events coincided then it is worth investigating.
Again, regarding transparent mode, I have always wondered how transparent it really is. If you take two switches in the same domain, and isolated them, then reconnect them through a transparent switch, do they still update each other? In that case, what database is on the transparent switch: the domain, or the local one?
What if the domains are different on each side of a transparent switch? I seem to remember reading somewhere that a VTP transparent switch will pass-through VTP data for a domain that is not its own, but only in VTP version 2. So, what if two different domains are connected via a version 2 transparent switch?
There are so many test cases to be covered, and not enough hours to spend in the lab. I hope Cisco guys have covered them all. But we can always speculate this might be a situation that has hit a bug.
Oh, BTW, on point 3, yes a client can update a server, but not after it is rebooted. I think it depends on the updater ID. That is: take a client, isolate it, make it a server, update the VLANs, put it back in client, and reconnect it ... it will update the domain. But not if it has been re-booted in the meantime. (which is already a change in behavior from older versions.).
Right, I'm from India.
Yes there are so many problems in real-life scenario that are far from theory & remain a mystery.
Regarding the VTP transparent, you are right. I also read in cisco docs & in this forum last month only. In VTP v2, transparent mode switches when recv vtp msg on one port send it out all trunk ports. Even if the switch is in a different domain, it still fwd all msg.
I am rather new myself to all this. Where is the configuration last modified? Is this a show command.
First mystery the brand new switch 3550, I deleted the vlan database to make sure the revision number was lower than our other VTP Domain just incase I made any errors setting it up. This switch is connected via a vlan which has a wireless backhaul unit which shouldn't matter.
The old domain took the name of the new domain but didn't show any vlans in it. The new domain took the old domain name and had all the vlans in it.
All switches should be in client with a server or two controlling the VTP Domains.
To my knowledge no switches were rebooted during this time. Some of the other guys were working on routing traffic for yet another VTP domain, but not sure why this would effect anything.
OK, I shall have to think that through. Sounds like a lab exercise coming on. Did you reboot the switch between deleting the vlan.dat and connecting it to the network? (Just to get the same lab conditions.)
BTW, the best way to get the configuration revision to go to zero is to put it in VTP transparent, come out of config, go back in, then put it in client (or even server) mode. When you move to VTP transparent, it knocks the config revision down to zero, but only when you leave the config prompt.
You say the old domain took the name of the new domain; in fact it soulds like it took its complete config, including its "no vlans". Does that mean the new domain had a name already? That's why I ask if you re-booted ... if you reboot with the vlan.dat deleted, it should come up with no VTP name.
All the running diagnostics you need, like "last updated" should be in show vtp status. I suppose it might depend if your clock was set up correctly at the time of the update.
After deleting vlan.dat switch was rebooted.
But, it was on the live network up and running for about a week. Took it out to the new location hooked it up to the live domain ran fine for a day and a half.
Went out to put people on the 3550 fiber backbone and before we even connected anything anywhere it just changed over.
Revision to zero will setting switch VTP domain to null acomplish the same thing?