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.
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.
- 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...
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.
with "Server mode"."
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.
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.
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 max 1
switchport port-security aging time 5
switchport port-security violation restrict
srr-queue bandwidth limit 10
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 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
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.
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?
I've also never had a problem with VTP in fairly large switching environments and have always wondered what all the angst is about.
bpdufilter does just that, filters bpdu sends & receives.
bpduguard will errdisable the port if bpdu is received on the port.
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
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:
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.
VTP = Broken.
VTP = Broken.