CCIE R&S Written Section 1.10 – Implement STP

This is the first of my Written exam posts to summarize my understanding of the technologies before entering the exam on the 23/12/10.

Here’s the current v4.0 Exam Topics so you can match my rantings with the syllabus.


Phase 1 – Root Bridge Election
Phase 2 – Root Port Election

Switches report STP failures to the root for further propogation.

A non-root bridge only generates BPDUs when it receives one on the root port.

Cisco enhanced the original 802.1D specification with features such as Uplink FastBackbone Fast, and Port Fast to speed up the convergence time of a bridged network. The drawback is that these mechanisms are proprietary and need additional configuration.

The port that receives the best BPDU on a bridge is the root port. This is the port that is the closest to the root bridge in terms of path cost.
A port is designated if it can send the best BPDU on the segment to which it is connected
A blocked port receives a more useful BPDU than the one it sends out on its segment. Remember that a port absolutely needs to receive BPDUs in order to stay blocked.

Port Roles:-


Port States:-
A port moves through these five states as follows with disabled always being a possibility:-
From initialization to blocking
From blocking to listening or to disabled
From listening to learning or to disabled
From learning to forwarding or to disabled
From forwarding to disabled

The timers are :-

20 secs Blocking
15 secs Listening
15 secs Learning


Each switch can report STP failures to the topology, not having to report back to the root as in 802.1d

3 port States:-


RSTP Port Roles:-
Root port: This port role exists in 802.1D (STP), too, and is the best path back to the root bridge; it must exist on all nonroot bridges.
Designated port: This port role exists in 802.1D (STP), too, and there must be a DP on all segments in the topology. By default, all ports on the root bridge are DPs.
Alternative port: This port role is new to 802.1w (RSTP) and is a quickly converging port to the Root port for a system.
Backup port: This port role is new to 802.1w (RSTP) and is a quickly converging port to the current Designated port on a segment.


This distinction is already made internally within 802.1D. This is essentially how Cisco UplinkFast functions. The rationale is that an alternate port provides an alternate path to the root bridge and therefore can replace the root port if it fails. Of course, a backup port provides redundant connectivity to the same segment and cannot guarantee an alternate connectivity to the root bridge. Therefore, it is excluded from the uplink group.

Adjusting the STP Root

(config)#spanning-tree vlan X root primary|secondary
Runs as a macro, simply surveys the current topology and adjusts the configuration as a once off operation.

Or to manually adjust the STP Priority use :-
(config)#spanning-tree vlan X priority  <0-61440>  bridge priority in increments of 4096

Port Priority & Port Cost

Remember this is an interface level configuration to influence the election of Root Ports.

Priority affects the downstream switch, so assuming all costs are equal on the downstream switch, your priority command which is between 0 & 240 in value influences the downstream switches choice of root port.

Cost affects your own switch, assuming you have four Fast Ethernet links costing an equal 19 each, simply setting one of the non-root ports to a cost of 18 will influence your switch into choosing that port as the root port.

Read here for a longer explanation.

Root Port Selection

In order to select a root port (best path towards root bridge) you look at:
1. Lowest cumulative cost to root (this means adding up the link’s costs hopping through the domain to the root)
If a tie between more than one links:
2. Lowest received bridge ID (this is only helpful if you have links to more than one upstream switch. Same switch = same received bridge id)
If a tie here:
3. Port Information – this includes port ID and port priority information To influence these behaviors, you can change the cost of a link locally (local change = local influence) or you can change the port priority remotely (local change = remote influence).
Port priority is evaluated before the port ID is.

Loop and Root Guard

The root guard is mutually exclusive with the loop guard. The root guard is used on designated ports, and it does not allow the port to become non-designated. The loop guard works on non-designated ports and does not allow the port to become designated through the expiration of max_age. The root guard cannot be enabled on the same port as the loop guard. When the loop guard is configured on the port, it disables the root guard configured on the same port.

Loop Guard

The STP loop guard feature provides additional protection against Layer 2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs.
When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes designated and moves to a forwarding state. This situation creates a loop.
The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop.

Per Interface
(config-if)#spanning-tree guard {loop|none|root}

Or globally for Loopguard only
(config)#spanning-tree loopguard default
Then use
(config-if)#spanning-tree guard none
To disable it on ports that you don’t want the global default to affect.

Quick views as to whether LoopGuard is configured:-
#sh spanning-tree summary
Per Interface:-
#sh spanning-tree detail | i Loop
To give you an idea of whether it’s on anywhere.
Root Guard
When root guard is enabled, if spanning-tree calculations cause an interface to be selected as the root port, the interface transitions to the root-inconsistent (blocked) state to prevent the customer’s switch from becoming the root switch.

The configuration of root guard is on a per-port basis. Root guard does not allow the port to become an STP root port, so the port is always STP-designated. If a better BPDU arrives on this port, root guard does not take the BPDU into account and elect a new STP root. Instead, root guard puts the port into the root-inconsistent STP state. You must enable root guard on all ports where the root bridge should not appear. In a way, you can configure a perimeter around the part of the network where the STP root is able to be located.

Per Interface:-

(config-if)#spanning-tree guard root
Quick views as to whether RootGuard is configured:-
#sh spanning-tree detail | i Root

BPDU Guard
The BPDU guard feature provides a secure response to invalid configurations because you must manually put the interface back in service. Use the BPDU guard feature in a service-provider network to prevent an interface from being included in the spanning-tree topology.
Globally (config)#spanning-tree portfast bpduguard default
Then use this command per-interface to disable bpuguard
(config-if)#spanning-tree bpduguard disable
Per interface
(config-if)#spanning-tree bpduguard enable
Quick Views on BPDUGuard activityGlobally:-
#sh spanning-tree summary
Per Interface
#sh run | i bpduguard

Storm Control
Storm control is supported only on physical interfaces – ingress. You can also configure storm control on an EtherChannel. When storm control is configured on an EtherChannel, the storm control settings propagate to the EtherChannel physical interfaces.
On each interface, a maximum threshold can be configured in bits or packets per second, or as a percentage of the interface bandwidth. If incoming traffic of the specified type exceeds its threshold during a polling interval (one second), traffic is blocked until the incoming rate drops below the configured falling interval.
Multicast limits must be higher than Broadcast limits (if they are both configured).
Per Interface:-
(config-if)#storm-control unicast|broadcast|multicast level rising falling

The switch will generate a log message notifying administrators of the detected storm:

%STORM_CONTROL-3-FILTERED: A Broadcast storm detected on Fa0/5. A packet filter action has been applied on the interface.

Additionally you can configure storm control actions which do either or both send snmp traps and/or shut down the interface.
(config-if)#storm-control action shutdown|trap

Quick views on Storm Control configuration:-
#sh storm-control
Further filters on this command simply target the show command onto interfaces or uni\broad\multicasts but do not make the output any more verbose than the base show command.

Unicast Flooding
Current lab IOS and Equipment:-
Currently the lab features only 3560 switching equipment and this command is not available in the 3560 IOS version 12.2(44)SE6 which is being used in my or INE’s reccommended study topologies. It’s only available in the 6500 series switches and above from my understanding.

(config)#mac-address-table unicast-flood {limit kfps} {vlan vlan} {filter timeout | alert | shutdown}

An alternative configuration approach found on some Catalyst model devices (such as the 6500 series) is to use Unknown Unicast Flood Blocking (UUFB), which is configured with the following simple interface command:

(config-if)#switchport block unicast

Hope this is useful to some peeps other than me. I’ll post section 1.20 in the coming days.


One thought on “CCIE R&S Written Section 1.10 – Implement STP”

  1. hi,
    sounds like you’re an expert i can count on!
    i have a question regarding network stability where PVST+ (say 100 vlans) is employed.
    consider a 4-switch topology, full-mesh (a .1q trunk is interconnecting them).
    a root bridge has already been selected. all ports have established their own roles appropriately. later on, i change one of those switches’ bridge-priority so it becomes a new root bridge. some traffic running in the background, say multicast.
    do you expect some “flooding” or “storm” of this multicast packets in the network during and after the new root-bridge established?
    or will PVST+ (STP) have a way to deal with this situation?


    or will

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s