Should VTP be disabled by default?

One of my readers sent me a question that triggered one of my old grudges:

In my experience, when you first add a new switch (having a NULL domain) on an existing VTP Domain, it inherits the domain name, regardless of it being a VTP Server. I was wondering if this is a feature (i.e. has proved to be a solution in most cases) or a bug (i.e. has proved to cause problems in most cases). I know it's proved to be the latter for us!

In my personal opinion Cisco at one point in time wanted too much plug-and-play and someone had a great idea that you can just plug another switch into your network and it would autoconfigure itself. We've been suffering because of that "insight" ever since (and the CCIE written test has material for a few more interesting questions :).

I strongly believe that VTP should be turned off by default and should generate a warning before being enabled, but it will probably not happen. What do you think?

Disclaimer: I am not a switching person and have no idea about anything below or above layer 3.

16 comments:

  1. I feel just as strongly about this as well, as does pretty much anyone with more than a couple of switches. You're right that VTP should be disabled by default. At least, NOT as a server. The only acceptable default setting is TRANSPARENT.

    If the default is transparent, a new (or even rogue) switch on the network doesn't overwrite other devices, nor does it adopt what it hears. Plus, if you DO use VTP, it won't get in the way of previous operations.

    As an old co-worker always said, VTP is a shining advertisement for Cisco's competitors.
  2. I've been through this pain before when the VTP was "configured" (left at default settings) across the network and new switches would overwrite the settings when they were attached to the network. I fully agree to have VTP configured in TRANSPARENT or CLIENT mode by default (can anyone ask/get Cisco to implement it), but since we are all using the technology as it is, a few protective measures can be put in place to defend against a new (rogue) switch:
    - configure a VTP domain on the network (default: NULL)
    - configure the MD5 hash authentication for that domain (default: none)
    - have at least one VTP server on the network (some stable, fully monitored and locked down switch - not that the others should be left open for everyone's access), while the rest of them are CLIENT or TRANSPARENT (depending on one's choice).
    - shutdown VLAN1 across the board and configure another VLAN as native for the whole network.
    I found the above useful to remember when building new networks or even when a call for help in the middle of the night comes from a desperate buddy...
  3. Cisco switches have many poor default settings and not just VTP. Why don't they sort out all of it by constructing a default config that is more secure?
    However, I think it is a serious process flaw to add switches willy nilly into a network and not expect a failure. A suitable time window needs to be negotiated with business, the switch needs to be prepped off network with an acceptable config and flashed with the relevant firware version.
    I think Cisco deserves rhubarbs for bad defaults but they cannot be held accountable for bad process management.
  4. cat4k people said in 2007 "IOS default setting of the VTP mode is server mode, but when we ship from the manufacturing, we explicitly change the mode to "Transparent". In other words, if you delete the manufacturing default setting and reset the switch, the switch will come back
    with "Server mode"."
  5. I don't have an issue with most of the "plug-and-pray" defaults of the Cisco switches. If you want to pay too much for an unmanaged layer-2 network, by all means buy 3560s and plug them into your network without the aid of so much as a console cable.

    But VTP is dangerous. Before configuring a trunk to anything, you need to know what is going on, and that includes management of your vtp domain. Cisco shipping ALL switches as a VTP server right out of the box is insane.
  6. We leave VTP in transparent mode for nearly all devices. A human screw-up with VTP is potentially catastrophic. In addition, we don't want every switch to know about every VLAN in a VTP domain for reasons of a clean configuration and improved STP topology control. Proper, common sense defaults with VTP would go a long way to making a VTP implementation palatable.

    I have a similar gripe with other defaults, one being that switch interface ports come up enabled instead of shutdown. We've had issues where a stack member in a 3750 stack loses its mind, comes up as a new number and is issued a default configuration from the stack master, and therefore uplinks all ports to VLAN1, including interfaces that may have been part of a cross-stack etherchannel previously. The results are ugly. It would be better for a naked switch to boot with all interfaces in a shutdown state, waiting for a grown up to configure them.

    Cisco trying to make switches "just work" out of the box is pandering to the wrong crowd. Cisco switches are feature-laden and outrageously expensive. They aren't targeted at the home market. In that context, the defaults should be set with the expectation of networking professionals installing them in data networking environments that matter.
  7. When you try to please everyone, you please no one.
    There are several excellent tips mentioned here. There are also other things that can be done as well such placing unused ports in shutdown and/or access mode. With the use of IOS macros and interface range commands, there are easy ways to prevent such issues
    Here is an example of one of our switch macros:

    macro name ROLLBACK
    power inline never
    switchport access vlan 340
    switchport mode access
    switchport port-security
    switchport port-security max 1
    switchport port-security aging time 5
    switchport port-security violation restrict
    bandwidth 10000000
    srr-queue bandwidth limit 10
    priority-queue out
    no mdix auto
    storm-control broadcast level 10.00
    storm-control multicast level 40.00
    storm-control action shutdown
    storm-control action trap
    no cdp enable
    spanning-tree portfast
    spanning-tree bpdufilter enable
    spanning-tree bpduguard enable
    spanning-tree guard root
    ip dhcp snooping limit rate 90

    This allows only 1 mac address on the port and does not participate in mdix
  8. Given the potentially catastrophic consequences I cannot believe that Cisco hasn't taken that step yet.

    As far as I am concerned though, to me VTP behavior is just one of the many ciscocentric default idiosyncrasies one has to be aware of when deploying gear.

    From the switchport mode being dynamic by default to ports having MOP enabled by default, Cisco is no better than Microsoft when it comes to things like that.

    @ironhorse

    I personally prefer disabling CPD altogether with a `no cdp run'.

    Following global configuration commands for access ports come in handy as well.

    spanning-tree portfast default
    spanning-tree portfast bpdufilter default
    spanning-tree portfast bpduguard default

    One thing I've always been curious about, if I have bpdufilter enabled already, isn't bpduguard superflous?
  9. I believe bpduguard and bpdufilter should be mutually exclusive. Configuring one should unconfigure the other, since they have different effects on the same condition.

    I've also never had a problem with VTP in fairly large switching environments and have always wondered what all the angst is about.
  10. Yeah, it may be a little overkill on the bpduguard stuff. I do like to have cdp enabled on my trunk ports that connect to my upstream switches. It helps with diagnostics. I disable it on any client facing interfaces.

    bpdufilter does just that, filters bpdu sends & receives.
    bpduguard will errdisable the port if bpdu is received on the port.
    per Cisco:
    To prevent loops from occurring in a network, the PortFast mode is supported only on nontrunking access ports because these ports typically do not transmit or receive BPDUs. The most secure implementation of PortFast is to enable it only on ports that connect end stations to switches. Because PortFast can be enabled on nontrunking ports connecting two switches, spanning tree loops can occur because BPDUs are still being transmitted and received on those ports.

    The PortFast BPDU guard feature prevents loops by moving a nontrunking port into an errdisable state when a BPDU is received on that port. When the BPDU guard feature is enabled on the switch, spanning tree shuts down PortFast-configured interfaces that receive BPDUs, instead of putting them into the spanning tree blocking state. In a valid configuration, PortFast-configured interfaces do not receive BPDUs. If a PortFast-configured interface receives a BPDU, an invalid configuration exists, such as connection of an unauthorized device. The BPDU guard feature provides a secure response to invalid configurations because the administrator must manually put the interface back in service.
    One other thing I forgot to mention... it helps to keep the network diameter in control
  11. I'm glad other people share the same concerns my original question posed. What's even more perplexing though is that Cisco doesn't even take the extra step in documentation to point out the potential disaster when introducing a new switch to an existing VTP-enabled network..
  12. As far as I know seting the VTP domain/password is enough to prevent accidents and malicious activity.
  13. Turning off CDP at the access level is sometimes a bad idea. Cisco IP phones (79xx) really need it.
  14. I vote to either disable VTP by default, or place VTP in transparent mode by default.

    In Cisco's own Solution Reference Network Design (SRND) document it also said to place the switch in VTP Transparent mode instead of server because "The benefits of dynamic propagation of VLAN information across the network are not worth the potential for unexpected behavior due to operational error. For this reason, VTP transparent mode is the recommended configuration option.".

    Here is the link to the referenced SRND:

    http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html#wp1108226

    Personally I would rather have full control of the switched network itself instead of relying on VTP to control the VLANs across the entire layer-2 switched domain.
  15. Tranparent is the way to go. We always set new switches to this mode before deployment. Besides, when you configure a switchport for a vlan, it adds it into the switch's vlan database.
  16. Personally I believe there is something fundamentally wrong with the way VTP functions. VTP Clients being allowed to update servers in certain scenario's, inheritance and just the thought of someone making a mistake and wiping an entire VTP domain's VLAN's, are just too much of a risk for most production networks.

    VTP = Broken.

    VTP = Broken.
Add comment
Sidebar