From: Mark Lasarko (mlasarko@co.ba.md.us)
Date: Thu Mar 16 2006 - 04:55:22 GMT-3
As I recall the catch is they have to be in the same VTP domain. This can happen regardess of the switch being a VTP client or a VTP server. A VTP client CAN and WILL erase VLAN info on a VTP server. Just look for the ports in your network going inactive because they are assigned to a VLAN that no longer exists.
I had one of my guys "testing" a switch in his cube a few years back. This individual played around with it for weeks and prior to deployment he forgot to change the modes back and forth to reset the revision #, as I was taught back in my CCNA days, and had posted as a comment in the config notes for my team. Anyway he went to install it at the site - trunked via dot1q, not that it matters, 3 tiers off that site's core 6500. Not two minutes after he plugged in that switch the phone started ringing at the helpdesk and I happened to be in the right place at the right time - MY CW2K console with a telnet session to one of the core 6500's in one window and Ciscoview in the other.... I actually got to see the VLAN's disappear one by one - and Ciscoview green ports started changing colors. We had 60 or so VLAN's at the time, sorted by building, floor, etc... starting in the 600's by the time I got the call we were down to the low 400's - refreshed and saw a couple more gone. Like !
half the network was erased in two or threeminutes, it was incremental. I found it very interesting that it started deleting the VLANs from the highest #, from the top down :)
TAC's Solution for those that care:
"Quickly reconfigure all of the VLANs on a VTP server."
Seriously.
As for the engineer, well... let's say we'll never let him forget that day.
(And we did not let him install a switch for a year as "probation")
>>> "Schulz, Dave" <DSchulz@dpsciences.com> 03/15/06 9:07 AM >>>
This clearly appears to be an error in the code (bug?). Is this running
with the most current IOS?
Dave Schulz
Email: dschulz@dpsciences.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Guyler, Rik
Sent: Wednesday, March 15, 2006 8:51 AM
To: 'ccielab@groupstudy.com'
Subject: RE: VTP client overwriting server ?
VLAN information gets stored in the vlan.dat file. It gets created
whenever
non-default VLANs are created on the device regardless of whether or not
it
is via VTP or manual configuration.
Number two is sadly true. I read this in some obscure doc a couple of
years
ago and was skeptical about it's accuracy so I labbed it up. Here is
what I
just did for you on my 3550 pair (I removed some of the extra stuff we
don't
need):
SW2(config)#do sh vtp st
VTP Version : 2
Configuration Revision : 6
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Client
VTP Domain Name : cisco
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x95 0x2F 0xA2 0xC3 0x98 0x98 0x6E
0xFE
Configuration last modified by 0.0.0.0 at 3-2-93 21:17:22
SW2(config)#do sh vlan
VLAN Name Status Ports
---- -------------------------------- --------- ---------
1 default active
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
40 VLAN0040 active
***************************************************************
SW1#sh vlan
VLAN Name Status Ports
---- -------------------------------- --------- ----------
1 default active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
SW1#sh vtp st
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Transparent
VTP Domain Name : cisco
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x57 0x30 0x6D 0x7A 0x76 0x12 0x7B
0x40
Configuration last modified by 0.0.0.0 at 3-2-93 21:14:23
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#vtp mod ser
Setting device to VTP SERVER mode
SW1(config)#int range f0/23 - 24
SW1(config-if-range)#no shut
SW1(config-if-range)#
1d21h: %LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to up
1d21h: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to up
SW1#
1d21h: %SYS-5-CONFIG_I: Configured from console by console
SW1#
1d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23,
changed state to up
1d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24,
changed state to up
SW1#sh vtp st
VTP Version : 2
Configuration Revision : 6
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Server
VTP Domain Name : cisco
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x95 0x2F 0xA2 0xC3 0x98 0x98 0x6E
0xFE
Configuration last modified by 0.0.0.0 at 3-2-93 21:17:22
Local updater ID is 0.0.0.0 (no valid interface found)
SW1#sh vlan
VLAN Name Status Ports
---- -------------------------------- --------- ---------
1 default active
10 VLAN0010 active
20 VLAN0020 active
30 VLAN0030 active
40 VLAN0040 active
This clearly shows a VTP client with a higher revision number adding
VLANs
to the list on the server. I also set this up again and removed VLANs
from
this client this time and when the interfaces came back up, they removed
VLANs from the server. I don't like this feature and really don't
understand why it would be coded this way but there it is.
Rik
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Carlos Mendioroz
Sent: Monday, March 13, 2006 8:50 PM
To: ccielab@groupstudy.com
Subject: VTP client overwriting server ?
Hi,
I've just received 2 conflicting pieces of information.
Well, both conflicted with what I supposed I knew...
1- IOS VTP clients do keep VLAN information in nvram
2- IOS VTP clients may overwrite a VTP server (so the message was,
beware
even more than what you used to from vlan info from a shelf switch).
#1 I have confirmed. You pass some VLANs to a client, you isolate the
client, you reload the client... and you have your VLANs.
Cisco says you would not... well, at least says so in many places.
#2 I have been unable to reproduce... even having a client with higher
revision number talk to a server does not do the trick.
The client will keep its higher version though...
So here: Does anybody have conclusive info of #2 being true or false ?
In case it is true, would you mind sharing a list of steps to make it ?
Yours truly (confused :)
-Carlos
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:39 GMT-3