Cisco VLAN Trunking Protocol

If you have multiple switches in a network, one of the chores of VLAN configuration is creating the database on each switch. Let’s say you have ten switches and five VLANs, which is far from unreasonable: you must create 50 VLANs in total. After all, each switch must know about the VLAN numbers before you can assign them to ports. Thus, on the first switch, you’d create the five VLANs and name them, before duplicating this effort on the other nine switches. In order to expedite this process, Cisco introduced the VLAN Trunking Protocol (VTP), which causes switches to exchange frames containing VLAN database details. When using VTP, a master switch acts as a server, and any changes to its VLAN database will be forwarded to linked switches, which will forward them to other switches, and so forth.

Here’s a simple topology featuring just three switches. We’ll configure the leftmost switch, S1, as a VTP server, and the remaining two switches as VTP clients. Clients will act upon any VTP updates they receive, changing their VLAN databases accordingly, but you cannot manually edit the VLAN database on a client. As it happens, most Cisco switches default to being VTP servers, meaning you can manually update their databases and these updates will be sent over trunks to neighbouring switches. To see how the VTP settings are currently configured, use:

S1# show vtp status

---Sample output---

VTP Version                      : 2
Configuration Revision           : 0
Maximum VLANs supported locally  : 64
Number of existing VLANs         : 5
VTP Operating Mode:              : Server
VTP Domain Name                  : NULL
VTP Pruning Mode:                : Disabled
VTP V2 Mode:                     : Disabled
VTP Traps Generation:            : Disabled
---Output omitted---

In particular, note the mode is currently Server and the domain is not set. In order for updates to be processed by other switches, they must all share a domain name. The five existing VLANs are those that come baked into the switch. Here’s the VTP configuration for S1:

S1# configure terminal
S1(config)# vtp mode server
S1(config)# vtp password interstellar
S1(config)# vtp domain Jupiter
  Changing VTP domain from NULL to Jupiter

First, I confirm the switch is operating as a VTP server. Next, I set a VTP administrative password, which is entirely optional but very useful. I must now configure this same password on other switches in the domain in order for updates to be applied. This enables me to better control the propagation of VLANs. Lastly, I set a domain name of Jupiter. At this point, I can configure VLANs in the database. I’ll add two:

S1(config)# vlan 2
  VLAN 2 added:
  Name: VLAN0002
S1(config-vlan)# name Sales
S1(config-vlan)# vlan 3
  VLAN 3 added:
  Name: VLAN0003
S1(config-vlan)# name Production
S1(config-vlan)# end

Issuing show vtp status once more reveals important changes:

S1# show vtp status

---Sample output---

VTP Version                      : 2
Configuration Revision           : 4
Maximum VLANs supported locally  : 64
Number of existing VLANs         : 7
VTP Operating Mode:              : Server
VTP Domain Name                  : Jupiter
VTP Pruning Mode:                : Disabled
VTP V2 Mode:                     : Disabled
VTP Traps Generation:            : Disabled
---Output omitted---

With those two extra VLANs added, the number of existing VLANs has increased to seven; also, the domain name is now set. Moreover, Configuration Revision is now four, whereas it was previously zero. Why four? Well, I created two new VLANs, and I set the names of both. That’s four separate changes to the local VLAN database: every time a change is made, the revision number is incremented.

Now we can jump over to S2. First, I’ll check the current VTP details:

S2# show vtp status

---Sample output---

VTP Version                      : 2
Configuration Revision           : 0
Maximum VLANs supported locally  : 64
Number of existing VLANs         : 5
VTP Operating Mode:              : Server
VTP Domain Name                  : NULL
VTP Pruning Mode:                : Disabled
VTP V2 Mode:                     : Disabled
VTP Traps Generation:            : Disabled
---Output omitted---

This switch is, by default, a VTP server as well—and servers receive and apply updates, just like clients. The reason that no update has occurred is because I haven’t configured the VTP administrative password on this device. As soon as I do, S2 will begin acting on the VTP updates coming across the trunk from S1. Let’s do it:

S2# configure terminal
S2(config)# vtp password interstellar

If I issue show vtp status again:

S2(config)# do show vtp status

---Sample output---

VTP Version                      : 2
Configuration Revision           : 4
Maximum VLANs supported locally  : 64
Number of existing VLANs         : 7
VTP Operating Mode:              : Server
VTP Domain Name                  : Jupiter
VTP Pruning Mode:                : Disabled
VTP V2 Mode:                     : Disabled
VTP Traps Generation:            : Disabled
---Output omitted---

I see the switch has set its VTP domain name to match that of S1. The number of existing VLANs is now seven, and running a show vlan would confirm the presence of Sales and Production in the local database. Of special interest is the revision number, which now matches that of S1. The Golden Rule is that a switch will only apply a VTP update if its revision number is higher than the one currently set. Before this update came in from S1, the revision number on S2 was zero. The update had a revision number of four, which was higher, so S2 applied it and updated its own revision number to match.

At this point, both S1 and S2 have matching VLAN databases and revision numbers. Both of them are VTP servers, too. You could make a change to the VLAN database on either and the other should update successfully. For example, let’s say we add another VLAN on S2:

S2(config)# vlan 4
S2(config-vlan)# name Marketing
S2(config-vlan)# exit

This will add the VLAN to the local database and increment the revision number by two (one for the new VLAN, another for giving it a name). Thus, the revision will now be six. If S1 were to send another VTP update at this point, S2 would ignore it, since S1 is using a lower revision of four. Instead, S2 will send an update of its own to S1, with its higher revision number of six; S1 will apply this update and increment its own revision number to match. The two switches are once again synchronised. Let’s confirm this by hopping over to S1 and issuing:

S1# show vtp status

---Sample output---

VTP Version                      : 2
Configuration Revision           : 6
Maximum VLANs supported locally  : 64
Number of existing VLANs         : 8
VTP Operating Mode:              : Server
VTP Domain Name                  : Jupiter
VTP Pruning Mode:                : Disabled
VTP V2 Mode:                     : Disabled
VTP Traps Generation:            : Disabled
---Output omitted---

As expected, the revision number is six and there are now eight VLANs. In order to tighten things up a bit, let’s prevent S2 from being able to directly modify its own database. We’ll make it a VTP client, meaning it will act on updates and pass them on, but cannot change its own VLAN configuration:

S2(config)# vtp mode client
S2(config)# vlan 5
  VTP VLAN configuration not allowed when device is in CLIENT mode.

As you can see, it is no longer possible to make VLAN changes on S2. Finally, let’s complete our topology by bringing S3 into the domain. We’ll make this a client too, then set the administrative password so it can process the updates it receives:

S3# configure terminal
S3(config)# vtp mode client
S3(config)# vtp password interstellar
S3(config)# do show vtp status

---Sample output---

VTP Version                      : 2
Configuration Revision           : 6
Maximum VLANs supported locally  : 64
Number of existing VLANs         : 8
VTP Operating Mode:              : Client
VTP Domain Name                  : Jupiter
VTP Pruning Mode:                : Disabled
VTP V2 Mode:                     : Disabled
VTP Traps Generation:            : Disabled
---Output omitted---

So, we now have three switches working in a VTP domain named Jupiter. Two are clients, meaning the only place we can make further VLAN modifications is on S1. To test this, we’ll delete VLAN 4 and confirm this change occurs throughout our domain:

S1(config)# no vlan 4

S2# show vtp status

---Sample output---

VTP Version                      : 2
Configuration Revision           : 7
Maximum VLANs supported locally  : 64
Number of existing VLANs         : 7
VTP Operating Mode:              : Client
VTP Domain Name                  : Jupiter
VTP Pruning Mode:                : Disabled
VTP V2 Mode:                     : Disabled
VTP Traps Generation:            : Disabled
---Output omitted---

The output on S2 shows the revision number has incremented to seven (any change, even a deletion, causes the revision number to increment) and, by coincidence, the number of VLANs has reduced to seven. A show vlan would confirm that the Marketing VLAN no longer exists. It would be the same story on S3. All that remains to do is assign the right ports into the right VLANs on each switch.

Here, then, is the power of VTP for working with lots of VLANs on many switches. There is, however, a dark side, and it goes by the name of the VTP bomb. Mull over this scenario: you have a network with 30 switches and some 20 VLANs. One switch is acting as master VTP sever, and all the others are clients. One day, a client switch fails. As a temporary replacement, you find an old switch in storage and hook it up. What could possibly go wrong? Well, if that switch happens to have a higher revision number than the others, perhaps because it was previously in use and not fully reset, then the existing switches will synchronise their databases with it. It does not matter whether the stand-in switch is a VTP server or client—as long as it has a higher revision number, all other switches will follow its lead. Assuming that this switch has no VLANs currently configured (or a totally different set of VLANs), you will utterly destroy the VLAN set-up across all the switches; devices will go offline; chaos will ensue. In short: with great power comes great responsibility.

There is a third VTP mode that can be useful: transparent. A switch in this mode will ignore any updates it receives, making it immune to VTP changes. You can manually update its database and such updates will not be sent to neighbours. However, transparent switches will pass on any other updates they hear about. In a small network with a few switches, I would set all of them to transparent mode and manually enter the VLANs on each. The irony is that, as the network gets larger, with more switches, VTP becomes more useful but also more dangerous. You run the risk of the VTP bomb. To avoid this, always ensure that you reset the revision number on any switch newly connected to a VTP domain. To perform a reset, set the VTP mode to transparent and then back to whatever mode you wish to use, e.g.

Switch(config)# vtp mode transparent
Switch(config)# vtp mode client

Having done this, issue show vtp status and confirm the revision number is zero. Now confirm the VTP administrative password (if any) matches and connect the switch to the others.

In summary, VTP is a labour-saving technology that synchronises the VLAN databases of trunked switches. VTP updates are generated by both servers and clients: in fact, the main difference between servers and clients is that you can’t manually alter the local VLAN database of a client. If a switch receives a revision with a higher number, it applies it and updates its own revision number to match. Transparent mode allows a switch to opt out of VTP: it neither applies updates nor generates its own, but will pass on received updates. If you use VTP servers and clients, be careful you aren’t hoist by the VTP bomb.

In my next post, I’ll move on to the basics of inter-VLAN routing.

Leave a Reply

Your email address will not be published. Required fields are marked *