Skip to content

Spanning Tree Protocol Topology Exercises

The Internet seems to lack a lot of Spanning Tree Protocol topologies for practice.  It is easy to find one or two but finding more than that has been hard. I have put together 8 exercises to be completed. Answers are included as well (pages 9-16). These answers were created by hand so please comment if anything appears to be wrong. Apologies about the messiness as it can get a little cramped.

I hope these are helpful.


Update: I want to express thanks to everyone who commented about possible errors in my topology. Unfortunately I took a famously long time to respond and I apologize for that. Because I haven’t been able to update the topology, I am going to take it down for the time being until it can be fixed and fully validated. Once I know it is correct, I will repost it.

Timer Worksheet

CCNP SWITCH will test one’s knowledge on timers of various protocols. I assembled a worksheet to help with learning the timers which are likely on the test. If a protocol or timer is missing or incorrect, please let me know in the comments. Timers are included relating to the following protocols:

  • Spanning Tree
  • Rapid Spanning Tree
  • HSRP
  • VRRP
  • GLBP
  • UDLD
  • DTP
  • VTP
  • PAgP

Download: CCNP Timers

Update: I have updated the timer worksheet to include another UDLD timer and Errdisable defaults.

VTP Basics

VLAN Trunking Protocol (VTP) is a Cisco proprietary technology. Ask administrators whether they like VTP and you will get varying answers. I don’t think anyone will deny there is a convenience that VTP provides. However, dangers associated with VTP are enough to make an administrator shy away from VTP as well. I’ll go into these risks later and what can be done to avoid them.

VTP is a technology which assists in VLAN configuration and assignment in a layer 2 domain. Without VTP, proper VLANs must be assigned to each trunk port. If a network has 10 switches and a single VLAN is added, it has to be configured on each switch and each trunk port. Not too hard, but a little error prone and tedious. This is where VTP steps in. A VLAN configuration change is made on a switch the VLAN information is sent to all switches in that VTP domain.

A VTP domain defines which VTP enabled switches are allowed to send VLAN information to each other. VTP domains could be created for a data center, another for the first floor, and another for the second floor. A VTP domain is specified with the vtp domain VTPDomain command.

One or more switches in a VTP domain need to be the VTP Server. Switches are assigned the VTP server role by issuing the vtp mode server command. VTP servers can have VLANs configured on them and will push the configuration out to all VTP servers and clients on the VTP domain.

A VTP client is a switch which accepts configurations but doesn’t allow for manual VLAN configuration through its CLI. Any VLAN configuration needs to be done on the VTP server. Immediately after the vlan.dat file is updated on the server, VTP packets are sent through the layer 2 network and clients update their vlan.dat file.

In addition to server and client modes, a third type exists. Transport mode effectively disables VTP on the switch without completely turning it off. VTP packets will be sent through a transparent switch but the packets won’t be processed by the transparent switch.

VTP servers and clients have a “VTP configuration revision number”. When a switch enters VTP server mode, the revision number is set at zero. When a client or server receives a VTP packet, it compares the domain, passwords, and revision numbers. If the domain and passwords match, it accepts the new configuration if the received revision number is higher than the current revision number.

Lets say a brand new switch network is brought up. Four switches are configured as clients while one is a server. A VLAN is created on the server. The VTP server increments the revision number by one and sends the update out. Any switches on the network in that VTP domain receive the update request and accept it because their revision numbers were zero and the new number is one.

The beginning of this article mentioned dangers around VTP. When a switch in server or client mode joins a network it broadcasts its VTP information including its revision number. Pretend there is a stable network with the VTP domain “VTPDomain” and a revision number of 176. An office closed so one of the switches in the office is brought into the active office to add a new floor of employees. The closed office also used the “VTPDomain” name but had a revision of 216. The switch is configured to be a client and is plugged into the network. Immediately it broadcasts its VTP information. All properly configured switches see the higher revision number and replace their VLAN configurations with the VLAN configuration from the closed office. Support calls ensue (that is unless they’re using VoIP on these same switches).

There are a few steps which can be taken to prevent this from happening.

  1. Make sure unique VTP domain names are used for each domain.
  2. Each VTP domain should have a unique password. If unique passwords are set, even if there is a VTP domain conflict, it won’t accept the bad configuration because the password won’t be accepted.
  3. Before plugging any new switches into the network, set the switch to transparent mode and then to client or server mode. This action resets the VTP revision number to 0, guaranteeing it won’t broadcast bad VLAN information.

Configuring VTP is pretty straight forward so I won’t go into what each command does. Here is a basic configuration on a VTP server.

SW1(config)# vtp domain VTPDomain
Setting VTP domain name to VTPDomain.
SW1(config)# vtp mode server
Setting device to VTP Server mode for VLANS.
SW1(config)# vtp version 2
Setting device to VTP version 2.
SW1(config)# vtp password passw0rd
Setting device VLAN database password to passw0rd.

To verify configuration of VTP, run the show vtp status command.

VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 1
VTP Operating Mode : Server
VTP Domain Name : VTPDomain
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x46 0x61 0xA6 0xC8 0x1F 0x9B 0x64 0x6A
Configuration last modified by at 3-1-93 01:34:49
Local updater ID is on interface Vl55 (lowest numbered VLAN interface found)

When two switches on a single network aren’t running VTP properly, compare the MD5 digest on the switches. If they do not match, review the VTP version, the domain, password, and revision numbers.

Packet-Pick-Apart for HSRP

Pre-requisites: HSRP basics

Required link: HSRP and ARP packet capture

When looking at its packets, HSRP is a relatively straight forward protocol. Each router announces its priority and come to an agreement on the active and standby routers. Every second each router sends a Hello UDP packet which declares its state. Notice the active router ( sends state code 16 (active) while the standby router ( sends state code 8 (standby). Alongside the state code is also each router’s priority. As long as the standby router’s priority is lower than the active router’s priority, the pattern goes on until a change occurs.

You will notice there are periodic advertisements sent out by the passive (standby) router. These announcements enable HSRP routers on the network to determine the HSRP state without being a member. These advertisements are also sent when a router is entering or leaving the passive state. Keep this in mind for later.

Packet 13

Pay attention to packet 13. The active router sends out a Hello packet with a priority of 75 instead of 100. When the standby router recognizes it has the highest priority, HSRP goes into action. First the standby router sends an advertise packet announcing it has an active interface (packet 14). Packet 15 then shows a Coup packet. Coup packets are sent when a standby router wants to become the active router. It sends its current state as well as the priority. Another advertisement packet is sent followed by a normal Hello packet, assuming it is the active router.

All this communication has happened between HSRP enables routers, blissfully ignored by downstream routers and hosts. At packet 17, no other devices are aware the HSRP active router has changed. However, the ARP tables and Spanning Tree topologies need to be updated with the path to the new active router. As far as the other devices on the network are concerned, the router was unplugged from one port and plugged into another port. The active router’s HSRP virtual MAC address (in this case 00:00:0c:07:ac:01) is broadcast in packet 18.

Packet 18

Packet 30, 31, and 32 show the HSRP topology stabilizing. The standby router goes through its Speak phase. Each time a Speak packet is sent the active router replies with a Hello packet preventing the Speaking router from becoming active. ARP packets are broadcast after 2 and 4 seconds. After the router goes from Speak to Standby, the topology is stable.

Packets 28 through 39

Packet 43 starts the process of the first router becoming active again because its tracked interface was plugged in bringing its priority back to 100. This is allowed to happen since the routers are configured with preempt, but it is not reflected in packet contents.

Debugging RADIUS Authentication with Zone-Based Firewalls

In my lab network I have a 2801 router acting as the demarc between my Linksys router (home network) and the lab network behind the 2801. All Cisco devices authenticate to a RADIUS install on a server located on my home network. In an effort to keep devices in my lab from accessing my home resources, I set up a zone-based firewall on my 2801. My home network hosts NTP, RADIUS, and TFTP services which the lab network just needs to be pingable and get SSH’d into.

I set up two zones on my router named Lab and Home. Both were assigned to zone pairs while class-maps and policy-maps were properly applied. Or so I thought. When I tried to SSH into lab devices behind the 2801, SSH would work but RADIUS authentication would hang. After analyzing my setup using show run, I decided more troubleshooting was required.

First step was to make sure RADIUS traffic was indeed being blocked by the firewall with debug policy-map type inspect detail. When RADIUS traffic passed, I saw it was indeed dropping packets to or from the standard RADIUS authentication port, 1645. The line to match RADIUS was match protocol radius. My mistake was on relying upon the router to properly detect RADIUS traffic.

RADIUS uses port 1645 for authentication. For reasons I don’t understand, Cisco devices sometimes use 1812. I looked far and wide for a list of applications zone-based firewalls detect and the properties they use for detection, but couldn’t find anything. It became apparent I wasn’t going to defeat this using their built in rules and had to define my own.

I could have created an ACL and applied it to the class-map but wanted to find a cleaner, more ZBF-like way. Cisco includes the ip port-map command which creates custom applications. I defined user-radius (note: user defined applications must begin with user-) which matches to UDP packets from port 1645 to 1646:

Router1(config)# ip port-map user-radius port udp from 1645 to 1646 description Standard RADIUS ports

In very un-Cisco like fashion, my user-radius application even showed in auto-completion when defining my matching protocol. Once the custom protocol was assigned, RADIUS authentication immediately began working.

The lesson for me is not to trust the application definition profiles provided by Cisco in zone-based firewalls.

If you know of a list of zone-based firewall application profiles, please let me know in a comment.

Lab 2: Basic Spanning Tree Topology Calculation

This topology can be seen all over study guides and for good reason as it is a basic topology which distills how STP works on its base level. Find the root switch, and label each interface as a root port, designated port, or blocking port.


This was pretty straight forward.  SW1 becomes the root bridge because it has the lowest root bridge ID (16384.0200.0000.1111). Not only is its MAC address lower, but its priority is lower as well.

Immediately both ports on the root bridge become designated ports since all ports on root bridges are designated. Default settings indicate a Fast Ethernet link has a STP cost of 19. Fa 0/2 has a SW2->SW1 cost of 19 (0 incoming, 19 added at Fa 0/2). Fa 0/1 on SW3 also has the same value because its SW3->SW1 has the same Fast Ethernet link settings back to SW1. This leaves two ports, SW2’s Fa 0/1 and SW3’s  Fa0/2 to find out which is blocking and which is designated.

STP uses four criteria to determine links:

1. Lowest root bridge ID

2. Lowest root path cost to root bridge

3. Lowest sender bridge ID

4. Lowest sender port ID

1 and 2 both are ties so we’ll have to go to the third item to break the tie. In this case, SW2 has a lower bridge ID than SW3 so SW2’s Fa0/1 becomes the designated port leaving SW3’s Fa 0/3 to go into blocking mode.

STP should now be fully converged.

VLAN Trunking Methods

Pre-requisites: VLAN basics

A network could technically have multiple VLANs using only access ports. This design isn’t all that realistic though. It is inevitable that multiple VLANs will have to traverse a single port. When a port is configured to carry multiple VLANs, it is called a trunk port.

There are two methods to allow a trunk port to carry multiple VLANs: ISL and 802.1Q. This document intends to describe both.


Inter-switch Link (ISL) is Cisco’s proprietary method for port trunking. ISL has been around for quite some time but is being phased out in favor of 802.1Q (to be discussed later). When a frame is being prepared to be sent through an ISL enabled port, ISL encapsulates the entire Ethernet frame in an ISL header and ISL CRC footer. Because information is being prepended and appended to the frame, ISL’s tagging method is sometimes called double-tagging.



801.1Q (sometimes called ‘dot one q’) is a standards based method of VLAN trunking. While ISL encapsulates the Ethernet frame, 802.1Q simply adds some information in the Ethernet header (specifically, after the source address). The 802.1Q VLAN tag is comprised of the following elements:

* 2 byte protocol ID (always 0x8100)
* 3 bit user priority (CoS)
* 1 bit canonical indicator
* 12 bit VLAN id

It is in the 12-bit VLAN id where the switch records the VLAN which this frame is assigned.

802.1Q introduces the concept of ‘native VLAN’ which isn’t present in ISL. A native VLAN is the VLAN a switch assumes the frame is a member of if there is no 802.1Q header. By default, the native VLAN is 1. However, security vulnerabilities enabled by an obvious native VLAN make changing it a recommended task.


Dynamic Trunking Protocol (DTP) is a Cisco proprietary protocol which assists in the negotiation of trunking. DTP operates in three modes:

* dynamic desirable – Actively ask neighbor to become a trunk port. This port will also become a trunk if asked by a neighbor who is also dynamic desirable.
* dynamic auto – Will go into trunk mode if it is asked by a neighbor but will not ask neighbors to become trunks.
* nonegotiate – Port permanently becomes a trunk port. These ports will not send DTP packets nor will they pay attention to any incoming DTP packets. The neighbor switch must also be set in no negotiate.

802.1Q Operation

Because ISL is a deprecated technology, I am not going to go into details about how it operates. Instead, 802.1Q’s operational basics will be explained.

Once a trunk link has been brought up and negotiated (if negotiated that is) traffic is sent over the link. Lets say the native VLAN is 2. If traffic is assigned to VLAN 2, the switch will send the frame without a 802.1Q header tag. The receiving switch, assuming it is configured properly, will know it is for VLAN 2 because there is no VLAN header. On the other hand, if a frame includes VLAN information in its Ethernet header, the switches will read the designated VLAN.

A future post will demonstrate how to configure VLAN trunking and some things to watch out for.