Moving from VTP Server/Client to VTP Transparent

[lcaruso]

Hi,

We are moving a small network of 3560 and 3750X switches from VTP Server and Client to VTP Transparent. I noticed the vlan database is stored differently depending on the VTP mode.

Is there any chance of losing vlan database on a given switch when moving from Server or Client to Transparent?

Any other known issues with such changes?

Thanks.

[cadet alain · Accepted solution]

Hi,

moving from server/client to transparent will set the config revision to zero.

In transparent mode the vlans are in the vlan.dat and the running-config if my memory is good.

Regards

Alain

Don't forget to rate helpful posts.

[Rchaoua12 · Accepted solution]

My understanding of VTP is that once the vlan.dat file is changed via VTP it must be deleted or cleared manually in order to lose its data. I have a 3560 switch at my desk that is attached to my site's vtp domain as a client. I changed its mode from client to transparent and retained the vlan information. I did not attempt to change it to Server mode.

Personally, if I was attempting this I would change all vtp clients to transparent mode first then change the vtp server last.

Is there a reason you are moving from VTP?

[lcaruso]

Thanks for sharing your experience. It's a small network and was not properly managed in this regard with multiple VTP servers and also some VTP clients and some VTP transparent. We prefer transparent for small networks.

[Bilal Nawaz · Accepted solution]

I agree, its better to use transparent, than server/client mode in a small network.

All changes made to vlans are reflected in the vlan.dat file normally located in flash:

Changing to transparent will not effect any vlans, the addition or removal of any vlan's automatically will not occur any further. It will be manual configuration. It will still pass on VTP messages from servers to clients, but will not participate in updates etc...

Hope this helps

Please rate useful posts and remember to mark any solved questions as answered. Thank you.

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Is there any chance of losing vlan database on a given switch when moving from Server or Client to Transparent?

As also noted by the other posters, there shouldn't be.  Converting server/client to transparent (or off if supported), copies the VLAN database to the local config.

Any other known issues with such changes?

Well if you don't have a consistent VLAN database between switches now, you'll clone the inconsistency.

If you protract the conversion, you might find "incorrectly" configured transparent mode switches won't relay VTP vlan updates.  I.e. a server or client that was sync'ed will no longer be.  Which isn't a problem unless VLANs are changed on a server and it's assumed that other servers/clients are sync'ed before they're converted.

PS:

Personally I prefer VTP server/client rather than transparent/off, but then I also prefer dynamic routing to static routing. 

VTP has gotten much "bad press" for dropping whole L2 topologies (generally due to those using it not fully understanding the technology or some being a bit careless).  V3, VTP, if your platforms support it, makes it much, much more difficult to have VTP "accidents".

[lcaruso]

Hi Joseph,

Thanks for your post and adding some of your experience/perspective.

Here's what happened when we made the VTP changes: out of fifteen 2811 routers at remote sites that were VTP servers to local VTP client switches, we lost the same vlan 35 that had been added in recent months on two of those routers . All other vlans were intact. Wasn't expecting that but it was easy to spot.

[Joseph W. Doherty · Accepted solution]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Ah, using an ISR as your VTP server, interesting!  These 2811 have switch modules in them?  If so, which?  What IOS were you running on them?  Same 2811 hardware and IOS on all 15? Anything different about the two that dropped the same VLAN, 35?  Same kinds of downstream switches, running the same IOS?

Sorry for all the questions, but I've worked with 2811s and with switches.  But haven't generally (ever?) run VTP between ISRs and switches (although have had subinterfaced Ethernet ISR ports connected to trunk switch ports).  Do recall, lots of bugs in the earlier 12.4 IOS for the 2811s.

[lcaruso]

We didn't set this up, but we are trying to clean it up.

Here is one of the routers that ate vlan 35.

sh inventory
NAME: "2811 chassis", DESCR: "2811 chassis"
PID: CISCO2811         , VID: V01 , SN:
NAME: "2nd generation four port FXO voice interface daughtercard on Slot 0 SubSlot 0", DESCR: "2nd generation four port FXO voice interface daughtercard"
PID: VIC2-4FXO=        , VID: V  , SN: 
NAME: "WAN Interface Card - DSU/CSU T1 Fractional (V2) on Slot 0 SubSlot 2", DESCR: "WAN Interface Card - DSU/CSU T1 Fractional (V2)"
PID: WIC-1DSU-T1-V2      , VID: 1.1, SN: 
NAME: "PVDMII DSP SIMM with one DSP on Slot 0 SubSlot 4", DESCR: "PVDMII DSP SIMM with one DSP"
PID: PVDM2-16          , VID: NA  , SN: 
NAME: "PVDMII DSP SIMM with one DSP on Slot 0 SubSlot 5", DESCR: "PVDMII DSP SIMM with one DSP"
PID: PVDM2-16          , VID: NA  , SN: 
NAME: "16 Port 10BaseT/100BaseTX EtherSwitch on Slot 1", DESCR: "16 Port 10BaseT/100BaseTX EtherSwitch"
PID: NM-16ESW=         , VID: 1.0, SN: 
NAME: "Power daughter card for 16 port EtherSwitch NM on Slot 1 SubSlot 0", DESCR: "Power daughter card for 16 port EtherSwitch NM"
PID:                     , VID: 1.0, SN:

#sh version
Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(24)T3, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Tue 23-Mar-10 06:44 by prod_rel_team
ROM: System Bootstrap, Version 12.3(8r)T7, RELEASE SOFTWARE (fc1)
Appleton1 uptime is 32 weeks, 5 days, 12 hours, 29 minutes
System returned to ROM by power-on
System restarted at 08:29:07 CDT Mon Jun 11 2012
System image file is "flash:c2800nm-spservicesk9-mz.124-24.T3.bin"
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
export@cisco.com.
Cisco 2811 (revision 53.51) with 247808K/14336K bytes of memory.
Processor board ID FTX
18 FastEthernet interfaces
1 Serial interface
4 Voice FXO interfaces
DRAM configuration is 64 bits wide with parity enabled.
239K bytes of non-volatile configuration memory.
62720K bytes of ATA CompactFlash (Read/Write)
Configuration register is 0x2102

[lcaruso]

Sorry too busy to answer all questions, but I'll get back to you when I catch up later.

[lcaruso]

Even though we didn't set them up this way, please explain why wouldn't you run a VTP Server on an ISR?

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Even though we didn't set them up this way, please explain why wouldn't you run a VTP Server on an ISR?

Sorry if you thought I was recommending not to run VTP on an ISR.  I haven't seen this because I've rarely used switch modules in ISRs, and the few times I have, it was in lieu of a standalone switch, not in conjunction with a stand alone switch.  This having been my experience, I hadn't run into the situation where using a ISR as a VTP server was even a consideration, which is why I found what you were doing interesting.

That said, in theory an ASR with a switch module should work just fine as VTP server or client.  Why it might not be good to do so in actual practice, might have as much to do with the complexity (?) of supporting VTP on an ISR's IOS, and perhaps a much smaller user base, using this kind of set up, to wring out any possible bugs.