CCNA Rapid PVST+: Root Election, Port Roles and Guards

Rapid PVST+ (Rapid Per-VLAN Spanning Tree Plus) is Cisco's implementation of IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) that runs one separate spanning-tree instance for every VLAN. Each instance elects its own root bridge, chooses its own root, designated and alternate ports, and blocks its own redundant links, so a loop-free Layer 2 topology exists per VLAN while redundant links stay ready as backups.

Spanning tree exists because Ethernet frames have no time-to-live: if two switches are joined by more than one active path, broadcasts circulate forever (a broadcast storm), MAC tables flap and the network stops forwarding. Spanning tree logically blocks just enough ports to leave exactly one active path between any two points, then unblocks a backup port when the active path fails.

SW1(config)# spanning-tree mode rapid-pvst
SW1# show spanning-tree vlan 10
VLAN0010
  Spanning tree enabled protocol rstp

The output line protocol rstp confirms the switch is running Rapid PVST+ for that VLAN. Because every VLAN is its own instance, almost every spanning-tree setting can be made per VLAN: spanning-tree vlan 10 priority …, spanning-tree vlan 10 root primary, and on an interface spanning-tree vlan 10 cost … or spanning-tree vlan 10 port-priority …. The same command without a VLAN number (for example spanning-tree cost 100 on an interface) applies to every VLAN on that port.

Rapid PVST+ keeps the classic timer values for compatibility — hello 2 seconds, forward delay 15 seconds, max age 20 seconds — but in normal operation it rarely waits for them, as later sections explain.

The root bridge is the switch with the lowest bridge ID (BID) in that VLAN. The BID is compared as one number whose high-order part is the bridge priority and whose low-order part is the switch's MAC address, so priority is compared first and the MAC address only breaks a tie. A switch with a lower priority wins no matter how high its MAC address is.

The extended system ID

The 16-bit priority field is split: the top 4 bits are the configurable priority, and the low 12 bits carry the extended system ID, which equals the VLAN number. Two consequences follow:

• You can only configure priorities in multiples of 4096, from 0 to 61440 (16 values). A value such as 5000 or 30000 is rejected.
• show spanning-tree displays the configured priority plus the VLAN number. The default 32768 in VLAN 40 shows as 32808, and 4096 in VLAN 7 shows as 4103. The bracket spells it out:

  Bridge ID  Priority    32808  (priority 32768 sys-id-ext 40)
             Address     5c8a.38f1.2e00

The displayed sum is never something you type; you configure the multiple of 4096 that appears in the bracket.

Why the default election is risky

If no priorities are configured, every switch ties at 32768 plus the VLAN number and the lowest MAC address wins. That is often an old or newly installed access switch rather than the distribution or core switch you want, and the whole tree reshapes around it. When comparing MAC addresses, compare them as hexadecimal numbers digit by digit (hex c is 12, so …2c00 is higher than …2900). Boot order, link speed and path cost play no part in the root election.

root primary and root secondary

Two macros pick a priority for you:

The macro runs once, looking at the roots it can see at that moment, and saves an ordinary spanning-tree vlan X priority N line in the configuration. It does not keep tracking the network: a switch added later with any lower priority still takes over the root. To make a root robust, configure an explicitly low priority (for example 4096 or 0) on the intended root and/or protect the edge of the distribution layer with root guard. If you list several VLANs (spanning-tree vlan 10,20 root primary) the macro computes a value for each VLAN separately and makes the switch root for all of them.

Every non-root switch chooses exactly one root port per VLAN: the port with the lowest root path cost, which is the cumulative cost of the path to the root. Each BPDU carries the sender's own root path cost; the receiving switch adds the cost of the port the BPDU arrived on. The root advertises 0.

Default port costs

The method in use (spanning-tree pathcost method short|long) is shown by show spanning-tree summary; the short values are the ones most CCNA material uses. Either way, faster links cost less.

Work outward from the root

Calculate each switch's best cost before using it as an advertised cost further downstream. A switch with a slow direct link to the root may reach it more cheaply through a neighbour: with a 10 Mbps direct link (100) and a path of three 1 Gbps hops (4 + 4 + 4 = 12), the indirect path wins, and that switch advertises 12, not 100, to the switches below it. A direct connection to the root wins only when its total is lowest.

Tie-breakers

If two ports give the same root path cost, the switch compares, in order:

1. the lowest sender bridge ID (the neighbour that sent the BPDU);
2. the lowest sender port priority (0–240 in steps of 16, default 128);
3. the lowest sender port number.

All three are values from the neighbour's BPDU, never the receiving switch's own port numbers. Sender port priority and number only matter when both links lead to the same neighbour (otherwise the sender bridge IDs already differ). With two parallel links to one switch, the receiving port cabled to the neighbour's lower-numbered port wins; the receiving switch's own port numbers are not compared at all.

Cost versus port priority

So to change a switch's own root port, lower the cost of the port you want (or raise the other) on that switch; changing its own port priority does nothing for its own choice. If only the upstream switch may be changed, lower the port priority on the upstream port you want used. A cost configured on the root's own port has no effect on the downstream choice, because the root advertises 0 and the cost is added by the receiver. Using the per-VLAN form (spanning-tree vlan X cost N) moves one VLAN while the others keep their root port; the form without a VLAN number changes every VLAN on that port.

Reading the result

  Root ID    Priority    8242
             Address     3a7f.91c0.4400
             Cost        12
             Port        26 (GigabitEthernet1/0/26)

The Cost under Root ID is this switch's total root path cost through its root port. The Cost column in the interface table is each port's own cost. Subtracting gives what the neighbour advertised: here, a total of 12 through a port costing 4 means the upstream neighbour advertises 8.

After root ports are chosen, every segment (link) elects one designated port: the port on the switch that advertises the lowest root path cost onto that segment, then the lowest bridge ID, then the lowest port ID. The designated port forwards and sends BPDUs onto the segment. Every other non-root port then gets the alternate or backup role and discards.

• The root bridge advertises cost 0, so it wins every segment it is attached to: all its ports are designated and forwarding (unless two of its own ports sit on the same shared segment).
• On a link between two non-root switches, compare the cost each switch advertises (its own root path cost), not the link's cost. The lower advertised cost wins outright; bridge priority matters only if those costs tie.

RSTP port roles

The alternate/backup distinction is simply whose superior BPDU the port hears. Two ports of one switch plugged into the same hub: one becomes designated (the lower port ID), the other hears its sibling's BPDUs and becomes backup. A port that hears a neighbour switch's better BPDU but would give a worse path to the root than the current root port becomes alternate — it does not replace the root port just because it receives a BPDU.

Rapid PVST+ uses three port states: discarding, learning and forwarding. RSTP grouped the old 802.1D states by what the port does with frames, so disabled, blocking and listening — which all drop user frames and learn nothing — merged into a single discarding state.

In the learning state the port reads source MAC addresses into the MAC table, so the switch does not flood unnecessarily once it starts forwarding, but it still does not pass user frames. Ports in every state keep receiving and processing BPDUs, which is how a discarding alternate port knows it can take over.

Cisco IOS still prints BLK in the Sts column for a discarding port, so Altn BLK means an alternate port in the discarding state. LRN is learning, FWD forwarding, and BKN* a port broken by a guard or inconsistency (explained in the guard section).

Rapid PVST+ converges in about a second or less because it replaces timer waits with pre-computed backups and an explicit handshake. Four mechanisms do the work.

1. Every switch sends BPDUs as keepalives

In 802.1D only the root originated BPDUs on its own timer; other switches sent BPDUs only when the root's BPDU arrived. In RSTP every bridge sends its own BPDUs every hello time (2 seconds) on its designated ports. If a port misses three consecutive hellos (about 6 seconds), the information is aged out at once instead of waiting for the 20-second max age. That ageing is only needed when a link stays up but BPDUs stop; a link that goes physically down is detected immediately.

2. The alternate port is a ready-made root port

Because an alternate port already receives BPDUs that lead to the root, when the root port's link fails the switch moves the alternate port straight to the root role in the forwarding state — no listening or learning.

3. Proposal/agreement and sync

When a designated port comes up on a point-to-point link it sends a proposal. The neighbour, before accepting the port as its root port, syncs: it puts all of its non-edge designated ports into discarding (edge ports are left alone because they lead only to hosts), so forwarding on the new root port cannot create a loop. It then returns an agreement and the upstream port forwards immediately. The neighbour's blocked designated ports repeat the same handshake with their own neighbours, so convergence ripples outward in well under a second.

4. Link type decides whether the handshake can run

The proposal/agreement exchange runs only on point-to-point links, which the switch infers from full duplex. A half-duplex port is treated as shared (Shr) and falls back to the forward-delay timers — about 30 seconds through discarding and learning. Fix a duplex mismatch, or override the inference with spanning-tree link-type point-to-point (or shared) when you know better.

If a neighbour sends legacy 802.1D BPDUs, the port shows Peer(STP) and uses 802.1D behaviour on that link, because an 802.1D switch cannot answer a proposal. After the neighbour is migrated, clear spanning-tree detected-protocols makes the port re-detect it.

Topology changes

RSTP treats a topology change differently from 802.1D: only a non-edge port moving to forwarding triggers one. The switch that sees it flushes MAC addresses learned on its other non-edge ports and sends BPDUs with the TC flag set, and neighbours do the same. A port merely going down does not make that switch originate a topology change (the switch at the other end does, if its alternate port moves to forwarding), and edge ports never generate topology changes, whether they come up or go down — another reason to make every host port an edge port.

PortFast makes a port an edge port that moves to forwarding as soon as the link comes up, skipping discarding and learning. It is meant for ports that connect only to end hosts. Without it, a designated port facing a PC sends proposals that nobody answers, falls back to the forward-delay timer, and spends about 30 seconds discarding and learning — long enough for DHCP requests after a reboot to time out.

Some platforms and software releases spell these spanning-tree portfast edge and spanning-tree portfast edge trunk; the behaviour is the same. An edge port shows Edge in the Type column of show spanning-tree.

PortFast sets the administrative edge status, but the port still listens for BPDUs. If a BPDU arrives — someone plugs a switch into the wall jack — the port immediately loses its operational edge status and takes part in spanning tree as a normal port. That prevents a loop, but it lets an unauthorised switch influence the topology; stopping that is BPDU guard's job. PortFast never affects the root election or port costs.

The three guards protect the spanning tree from different failures. BPDU guard shuts down a port that receives any BPDU; root guard blocks a port that receives a superior BPDU; loop guard blocks a port that stops receiving BPDUs.

BPDU guard

Any BPDU proves a switch is attached to a port that should only see hosts, so the port is err-disabled and logs %SPANTREE-2-BLOCK_BPDUGUARD and %PM-4-ERR_DISABLE. There are two ways to enable it, with different scope:

• The global spanning-tree portfast bpduguard default applies only to ports that are operating as PortFast edge ports. A port without PortFast is not covered, and re-entering the global command does not change that.
• The interface spanning-tree bpduguard enable protects that port whether or not PortFast is configured.

Removing the offending device does not bring the port back. Without errdisable recovery cause bpduguard (which re-enables the port after a recovery interval, 300 seconds by default) an engineer must bounce the interface: err-disable is cleared only by shutdown/no shutdown or by errdisable recovery, never by spanning-tree commands or by changing the port's configuration.

Root guard

Root guard keeps a designated port designated. Inferior BPDUs are processed normally, so the link keeps forwarding with a neighbour that runs spanning tree; only a superior BPDU puts the port into root-inconsistent state (log %SPANTREE-2-ROOTGUARD_BLOCK), and when those stop the port recovers by itself (ROOTGUARD_UNBLOCK). Place it on designated ports facing switches that should sit below it in the tree. Any port that legitimately receives the best BPDUs in the VLAN — a root port, an alternate port, or the path the secondary root relies on — is the wrong place: root guard there blocks the very path to the root it should protect. That is why root guard suits a partner link that must keep exchanging BPDUs, where BPDU guard would err-disable the link on the first ordinary BPDU.

Loop guard

Loop guard handles a unidirectional link, such as a fibre or transceiver fault that stops a port receiving while it can still transmit. Without it, a root or alternate port that stops hearing BPDUs ages out the stored information, becomes designated and forwards toward a switch that is already forwarding — a loop. Loop guard holds the port in loop-inconsistent state instead, and it recovers automatically once BPDUs arrive again. It belongs on the receiving (root/alternate) side; on a designated port it has no BPDUs to miss.

The interface command spanning-tree guard takes one value — loop, root or none — so a port runs root guard or loop guard, not both. This is consistent with their placement: root guard on designated ports, loop guard on root and alternate ports.

show spanning-tree vlan X answers almost every Rapid PVST+ question: the top block identifies the root and this switch, and the interface table lists each port's role, state, cost, port ID and link type.

AS5# show spanning-tree vlan 60
VLAN0060
  Spanning tree enabled protocol rstp
  Root ID    Priority    4156
             Address     3a7f.91c0.4400
             Cost        4
             Port        25 (GigabitEthernet1/0/25)
  Bridge ID  Priority    32828  (priority 32768 sys-id-ext 60)
             Address     5c8a.38f1.2e00

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/0/7          Desg FWD 19        128.7    P2p Edge
Gi1/0/14         Desg FWD 4         128.14   P2p
Gi1/0/25         Root FWD 4         128.25   P2p
Gi1/0/26         Altn BLK 4         128.26   P2p

show spanning-tree interface Gi1/0/20 shows one port across all its VLANs, which is useful for confirming a trunk is (or is not) an edge port, and show spanning-tree summary shows the mode, the path-cost method and which global PortFast, BPDU guard and loop guard defaults are on. Err-disabled ports appear in show interfaces status err-disabled.

Because Rapid PVST+ builds a separate tree per VLAN, you load-share by making different distribution switches root for different VLANs. Each access switch's root port for a VLAN points toward that VLAN's root, so one uplink forwards for some VLANs and the other uplink forwards for the rest, and each uplink is the alternate (backup) for the other's VLANs.

DSW-A(config)# spanning-tree vlan 110 root primary
DSW-A(config)# spanning-tree vlan 120 root secondary
DSW-B(config)# spanning-tree vlan 120 root primary
DSW-B(config)# spanning-tree vlan 110 root secondary

The secondary settings matter: they fix which switch takes over each VLAN if its primary fails. Leave them out and the backup root is whichever default-priority switch has the lowest MAC — possibly an access switch. Configure one root for every VLAN and one uplink sits idle.

When the design does not take effect, compare the priorities per VLAN. If both distribution switches carry the same priority for a VLAN, the lower MAC wins it, so one switch can end up root for everything and every access switch forwards on the same uplink. The root bridge is decided by bridge ID alone, so the fix is always a priority change on the switch that should be root for that VLAN; port costs only decide how other switches reach whichever root was elected.

In show spanning-tree vlan 110 and vlan 120 on an access switch, healthy load sharing looks like the two uplinks swapping roles: Root FWD/Altn BLK in one VLAN and Altn BLK/Root FWD in the other, with the same costs.