Everything you ever wanted to know about VTP Transparent switch operation

OK, so I’m not really going to go over everything you ever wanted to know.  That was just a catchy title to draw you in.  Most people at the CCNA level and above are pretty well versed in the basics of VTP already.  So I’m not going to talk about the stuff that most people read from their study material.  But there are some details about how the different modes of VTP interact with each other that you might not encounter in your reading.  So I thought that I would share the details of what I discovered about how VTP Transparent mode interacts with Client/Server mode.

For the following examples, we have 3 switches (switches A, B, and C).  Switches A and C are both connected only to Switch B.  Switches A and C are in VTP Server mode and Switch B is in VTP Transparent mode.  So in order for Switches A and C to use VTP to update each other, they have to go through Transparent mode Switch B.

Passing VTP messages through a Transparent mode switch

The first thing that we’ll look at is getting Switch B to allow the other switches to exchange VTP information.  Here is a snippet of the Catalyst 3550 documentation regarding VTP.
Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP
messages for the domain name and version and forwards a message only if the version and domain
name match. Because VTP version 2 supports only one domain, it forwards VTP messages in
transparent mode without inspecting the version and domain name.

Unfortunately, this is not how things actually work.  The VTP transparent mode switch only needs to have the domain match in order to forward on the message.  Also, the domain must match in order to have the transparent mode switch forward the messages regardless of if it is running VTP version 1 or 2.

I ran through tests, where all switches had the same VTP domain, mixing and matching the VTP versions.  I also ran tests where Switch B had  a different domain name than Switches A and C, also mixing and matching versions.  During the tests, I enabled debugging of VTP packets and events to watch what was happening.

Test 1

On the first test, all switches started with the same VTP version, and the same VTP domain name.  Here is the debug info from Switch B when it receives a VTP messages from Switch C.

1d17h: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/24 – in TRANSPARENT MODE (nc = false)

I got these messages on all permutations of VTP versions between the Server and Transparent mode switches.  Also, Switches A and C stayed synced up with their VLANs the whole time.  So as long as the domains are consistent, the transparent mode switch will forward VTP messages regardless of version.

Test 2

The second round of testing was with Switch B using a different VTP domain than switches A and C.  Here is the debug info from Switch B again when it receives VTP messages from switch C.

1d17h: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/24 – not in domain ccie

I then switch between VTP mode 1 and 2 on switch B and the results are the same.  So as long as the transparent mode switch uses a different domain name, it will not forward VTP message regardless of version.

Making it work

So now we know that VTP Transparent switches will not forward VTP messages from other switches in different VTP domains.  You may have seen posters talking about this apparent bug on other blogs or forums.  But I wanted to include it here for those that hadn’t, and for completeness.

So what if the CCIE lab asks you to make it happen?  Well, there is a solution.  You can use layer 2 tunnels to have the transparent mode switch forward the VTP messages without processing them.

The config is actually quite simple.  On Switch B, we first create a new VLAN for the tunnel.  This VLAN should not be used elsewhere in the network to avoid any possible negative side effects.  Then you set the ports that connect to switches A and C to access mode and set up the layer 2 tunnel as shown below.

vlan 999 (create the unique VLAN for tunnel)
int range fa0/20 , fa0/24  (these ports connect to switches A and C)
switchport access vlan 999
switchport mode access
l2protocol-tunnel stp
l2protocol-tunnel vtp
end

Also, on the ports on Switches A and C connecting them to Switch B, you need to force trunking with the “switchport mode trunk” command.

You might wonder why we are pushing STP over the tunnel.  If you don’t, this is what happens.

00:16:08: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet0/20 VLAN999.
00:16:08: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/20 on VLAN0999. Inconsistent port type.

The reason for this is that one end of the link is an access port and the other is a trunk port.  STP doesn’t like that.  Adding STP to the tunnel prevents the ports on Switch B from processing the STP messages.  It just forwards them on through the tunnel.  Also, we could make the Switch B ports trunks as well, but making them access ports simplifies things and helps to avoid issues resulting from loops caused by the tunnels.

VTP Pruning across VTP Transparent mode switches

The last topic for this post will be how going across a Transparent mode switch will affect VTP pruning between VTP Clients/Servers.  The quick explanation is that the transparent mode switch does not affecting things at all.  In our example, it works as if Switches A and C were directly connected.  Switch B will not remove any VLANs from the trunks of Switches A and C, even if Switch B doesn’t even have the VLANs configured.

Here is an output from a “show interface trunk” from Switch A.  Please note that Switch B only has VLANs 1, 10, 20, 30, 40, and 50 configured.  VTP pruning has been enabled on Switches A and C.

Port        Mode         Encapsulation  Status        Native vlan
Fa0/20      desirable    802.1q         trunking      1

Port      Vlans allowed on trunk
Fa0/20      1-4094

Port        Vlans allowed and active in management domain
Fa0/20      1,10,15,20,25,30,35,40,45,50,55

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/20      1,10,15,20,25

So you can see that even though Switch B does not have VLANs 15 and 25 configured, the VLANs do not get pruned across the trunks.  So everything appears to be working fine, but it can cause problems for us humans.  We might look at the trunks on either Switch A or Switch C and think that the VLANs are operating normally between switches.  But since Switch B does not have VLANs 15 or 25, devices on those VLANs will not be able to communicate across Switch B.

The lesson here is that the trunks on Switches A and C won’t remind you about this.  So you either need to make sure that all VLANs get manually configured on the Transparent mode switch, or keep in mind that certain VLANs will not be traversing it.