Hi Kevin,

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.

Hi,

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.).

Kevin Dorrell

Luxembourg

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.

Kevin Dorrell

Luxembourg

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?