From: Mark Lasarko (mlasarko@co.ba.md.us)
Date: Sun Mar 19 2006 - 22:23:04 GMT-3
VTP packets are sent in either ISL frames or dot1q frames to the dest. MAC 01-00-0C-CC-CC-CC. The LLC SSAP = AA and DSAP = AA (LLC Header=AAAA) and a (OUI Cisco) SNAP header type of 2003.
Packet length & other info will vary from Summary advertisements, Subset advertisements, Requests, & Joins
And Yes, this situation DID apply exactly as I described it.
The Enginner had a rack, not just a single switch (most of us do???)
(How else could this have happened?)
This persons' rack mocked the install, a little too much.
Apparently this individual had another (server) switch and replicated as much info as possible and then some.
As I noted, this is something I was clear on for many years - not a secret;
And it has been documented for many years, just not as well as some of us would like.
There are a few decent pages on the web, but my best recommendation for packet info would be a packet trace, along with the debugs of course :)
This may cover the differences better that some of generic diagrams available.
Thanx for the feedback,
~M
>>> Carlos Mendioroz <tron@huapi.ba.ar> 03/18/06 12:02 PM >>>
Mark,
this particular experience does not count toward this, because the
switch had to be in server mode for your guy to change vlans in his cube.
Against what Martin says, it is not ALWAYS the case that the thing
happens, and the way it happens seems to vary from IOS version to IOS
version.
For example, it will happen allmost always if the switch was server when
booted, even if it is not server anymore.
But in some revisions it will NOT happen. And you will have a client
with revision 7 (e.g.) connected to a server with revision 5 w/o
interacting. It will require the server to go over revision 8 to get
both in synch.
It is a requirement for a client to be able to change a server because
if not the clients would have to be directly connected to servers for
VTP to work. But the information SHOULD come from a server.
Does anyone have information on VTP protocol ?
(I mean, the bits in the messages, not the functional spec :)
-Carlos
Mark Lasarko @ 16/3/2006 1:55 -0600 dixit:
> 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. Lik
e !
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:39 GMT-3