From: Aaron T. Woland (aaron.woland@ins.com)
Date: Thu Mar 16 2006 - 10:25:49 GMT-3
I had a customer where something similar happened. Their Lab is configured
to mirror production as closely as possible, so the VTP domain & passwords
were the same!
So, middle of a production day, one of the engineers plugs the switch into
the production DataCenter network, and wipes out most of the VLANs...
Here's the fun part: He wiped out the VLAN that the SolarWinds Orion Server
was on, so: NO ONE was paged / no one knew anything went wrong until the
phones started ringing.
Here is some information that you all might find interesting:
----------------
--------------
------------
VTP VERSION 3
VTP Version 3 adds a number of new features to VTP, including some
specifically designed to add protection from the "wrong" database
accidentally being inserted into a VTP domain. These include:
--> Ability to enable/disable VTP processing on a per-port basis
--> Concept of a 'primary' database server, and resistance to changing the
primary once defined (protecting against the 'new switch' scenario):
--> VTP configuration is possible only on a primary server.
--> The identifier (ID) of the primary server that generated the database
is attached to the VTP advertisements.
--> A VTP switch keeps the ID of a primary server and accepts VTP database
updates from its current primary server only.
VTP Version 3 was introduced in CatOS 8.1(1), and all switches in the VTP
domain must run the same version of VTP.
------------
--------------
----------------
Aaron T. Woland | Consultant | INS | Email: aaron.woland@ins.com |
Website: www.ins.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Mark
Lasarko
Sent: Thursday, March 16, 2006 2:55 AM
To: DSchulz@dpsciences.com; ccielab@groupstudy.com; rguyler@shp-dayton.org
Subject: RE: VTP client overwriting server ?
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