You are here: Home / Basics / Basics: Cisco VLAN Trunking Protocol – Transparent discard and passing VTP Packets

Basics: Cisco VLAN Trunking Protocol – Transparent Discard and Passing VTP Packets

11th April 2012 by 7 Comments

It’s a common discussion about when Cisco VTP protocol is actually forwarded through Cisco switches and when it’s isn’t. I’ve always gotten it somewhat confused and when I stumbled across some old notes on the topic I had an ah-hah moment. I’m answering the question about when using VTP in your network, which versions are risky – that’s risky is terms of how do you prevent VTP updates from ‘crossing’ a switch by explaining how each version works.

There are three versions of VTP – Version 1, 2 and 3. Each VTP device is configured in Transparent, Client or Server mode (except VTP v3 which has an extra mode – off).

The purpose of VTP is copy the contents of the VLAN Database to neighbouring switches so that VLAN configuration in a given operational domain are synchronised – that way, all VLANs are consistently configured, VLAN names are the same and much more.

Note that VTP was especially useful when first introduced since configuring VLAN over Token Ring and FDDI interfaces was complex, and it took many years for network administrators to understand VLAN configuration. Importantly, VTP was useful to help stabilise Spanning Tree in the early days by ensuring consistentcy, especially in large networks (well, they were large in 1999 anyway….).

Yes, I’m forcing some history down your throat….

The Modes

A Switch in VTP Server mode will always actively participate in sending and receiving VTP and synchronising the VTP data file. Regardless of version.

A Switch in VTP Client mode will always actively participate in VTP data file synchronisation. Regardless of version.

A switch in VTP v1 Transparent Mode will not send, receive VTP data or participate in file synchronisation.

A switch in VTP v2 Transparent Mode will send, receive VTP data, but doesn’t participate in VTP file synchronisation.

The only configuration that DOES NOT pass VTP packets is a switch configured in VTPv1 Transparent Mode and VTPv3 in off mode.

For VTPv3, the difference is much clearer. VTPv3 has four modes: server, client, transparent and off. The difference between transparent and off is the termination of received VTP messages instead of relaying them. With VTP version 3, off mode can be configured globally or on a per port (for example trunk) base. The off mode was formerly only available with CAT OS. The configuration of off on an interface will apply to all VTP instances.

Also note that VTPv3 will propagate VLANs above 1024, while VTPv1 & 2 do not. Another historical artefact.

The EtherealMind View

I’m a big fan of VTP to reduce the day to day grind of configuring switches but that it isn’t a popular view. I’ve provided some tips for VTP safety in Fate Sharing, Failure Domains and Why VTP Is Awesome and how to mitigate that risk.

I’ve previously looked at VTPv3 in VTP Making a Comeback:VTPv3 which makes VTP safe.

You should take time to have a another look and consider the benefits of better operation instead of focussing on one bad experience.

Move on, people, move on.

Filed Under: Basics, Blog, Operation Tagged With: , ,
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://twitter.com/blinken_lichten Jon Langemak

    Im curious if others use VTP in large scale environments.  To me, it’s an unnecessary risk.  The biggest stretch of VLANs we have is on a set of stack switches or trunking between two IDF data center switches.  The rest is all layer 3.  Running layer 3 to the edge is far better scenario in my mind. 

    Interested to see what others are doing though…
     
    -Jon

  • http://twitter.com/tatersolid Ryan Malayter

    Except… I don’t have an all-Cisco-switch network. Nor do most other SMEs. Which makes VTP – any version – nothing but trouble.

    • Jason Costomiris

      Even if you have an all-cisco switch network, it seems like a huge recipe for trouble.  VLANs are not something that should be dynamically negotiated and provisioned, IMHO.  Far too easy for someone to screw up and accidentally create a huge (and quite unhappy) surprise.  We’re humans, we screw up.  Protocols like VTP magnify the impact in cases like that.

      To me, the safest VTP mode is “off”.

      • http://twitter.com/tatersolid Ryan Malayter

        And of course Cisco defaults VTP to on, and does *not* support standards-based alternatives like GVRP or MVRP on most of thier switches. At least nobody can nuke the whole network with a VLAN distribution protocol here, because you can’t have one in a multi-vendor network that contains Cisco devices too.

  • http://showbrain.blogspot.com Ben Story

    After some of the comments I got for posting an EEM script to automatically backup the vlan.dat file on my blog with a scenario about a misconfigured switch wiping the VLAN DB I was beginning to think I was the only one that still used and LIKED VTP.  Consistency to me is key.  Consistent VLAN names make scripting much easier.  I can also create web interfaces to allow helpdesk staff change port VLANs without worry (as long as it’s one of the VLANs I’m not pruning). Yes a L3 topology would be “better” according to many guides, but in many environments like healthcare, there are application vendors that haven’t discovered IPv4 yet.  

  • Stefan H.

    I never saw another configuration than vtp mode transparent so far. And I know no real-world-scenario where it really would make sense (Not more than 4-5 switches configured with identical vlans).
    Why should I add additional risks, while having nearly no benefit?

  • Guest

    We use VTP with about twenty’ish edge switches and three core all in one VTP domain. Only on switch is VTP server rest is clients and database is protected by password.
    Would not even consider doing manual VLAN definitions on that rather small environment, might just be that we are lazy..