Protecting STP Topology

I. Root Guard

• The Root Guard feature prevents surrounding switches from announcing themselves as Root Bridges.
  • When configured on a port, this feature forces that port to remain as designated port and prevent it from becoming a root port.
• Imagine a new switch that is introduced into the network with a bridge priority lower than the current root bridge. In a normal STP operation, this new bridge can become the new Root Bridge and disrupt your carefully designed network.
• The way this works is:
  • A switch learns the current Root Bridge’s Bridge ID.
  • If another switch announces a superior (lower) BPDU on a port where root guard is enabled, the local switch will not allow the new switch to become the root.
  • The port that receives the new superior BPDU is then transitioned to a state called root-inconsistent STP state (effectively the same as listening state).
  • No data can be sent or received in this state.
• The recommended design is to enable Root Guard on all access ports so that a root bridge is not established through this port.

Configure Root Guard

• Root Guard can only be enabled on a per-port basis.
  • It affects the entire port. Therefore it applies to all VLANs on that port.
• It is disabled by default.
• Use the following interface configuration command:

Switch(config-if)# spanning-tree guard root

Verification

To verify configuration, use the show running config command on the interface:

Switch#show running-config int Fa0/1
Building Configuration…
!
!
interface FastEthernet0/1
switchport mode access
spanning-tree guard root
end
!

The following command displays switch ports that are in root-inconsistent state.

• Use it to find out if any ports are disabled.

Switch# show spanning-tree inconsistentports

II. BPDU Guard

• BPDU Guard protects ports that have PortFast enabled.
• Theoretically, a port that has PortFast enabled is not expected to be used for another switch or any devices that produces BPDUs. If by mistake or malicious act, a switch is connected to a PortFast enabled port, a potential bridging loop can occur.
  • A BPDU received on this port could potentially advertise a new Root Bridge.
  • BPDU Guard puts the port in err-disable state if a PortFast enabled port receives a BPDU.
• An err-disabled port will have to either be manually enabled or automatically recovered through the err-disable timeout operation.

Configuring BPDU Guard

• BPDU Guard is disabled on all switch ports by default.
  • However, all ports that have PortFast enabled automatically enables BPDU guard.
• It can be enabled:
  1.  Globally so that one command enables all switch ports or;
  2.  On a per-interface basis.

Switch(config)#spanning-tree portfast bpduguard default

Switch(config-if)#[no] spanning-tree bpduguard enable

Verify Configuration

To verify that BPDU Guard is configured:

Switch#show spanning-tree summary total
Root bridge for:Bridge group 10, VLAN1, VLAN6, VLAN1000.
Extended system ID is enabled.
PortFast BPDU Guard is enabled
EtherChannel misconfiguration guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Default pathcost method used is short

III. BPDU Filtering

• BPDU filtering prevents Catalyst switches from sending BPDUs on PortFast-enabled interfaces 
• BPDU Filtering effectively disables STP on the port it is configured on.
• Disabled on all switchports by default.
• According to text, BPDU filtering is not a recommended configuration.

Configuration

• Can be configured globally or per-interface.
  • If configured on an interface, the switch does not send BPDUs and drops all BPDUs it receives.
  • If configured globally, the switch changes the interface back to normal STP operation if the port receives BPDUs on the respective interface.
• To enable globally:

Switch(config)#spanning-tree portfast bpdufilter default

• To enable/disable on specific ports:

Switch(config-if)#spanning-tree bpdufilter {enable | disable}

• To verify:

Switch# show spanning-tree summary totals

Preventing Forwarding Loops and Blackholes

IV. Loop Guard

• With LoopGuard, if a switch stops receiving BPDUs on a non-designated port, the switch places the port into the STP loop-inconsistent blocking state (instead of transitioning through listening, learning and forwarding states.
• A port stops receiving BPDUs in cases like unidirectional link failure.
• When enabled, Loop Guard keeps track of the BPDU activity on non-designated ports.
  • While BPDUs are received, the port is allowed to behave normally.
  • When BPDUs go missing, loop guard moves the port into the loop-inconsistent state.
  • When BPDUs are received on the port again, loop guard allows the port to move through the normal STP states and become active.
• By default, loop guard is disabled on all switch ports.

Configuring Loop Guard

• Loop guard can be enabled on a global or per-interface basis:

Switch(config)#spanning-tree loopguard default

Switch(config-if)#[no] spanning-tree guard loop

• Even when configured on a switchport, it only blocks on a per-VLAN basis instead of blocking the whole port.
• Follow these guidelines when using loop guard:
  • Do not enable loop guard on PortFast-enabled or dynamic VLAN ports.
  • Do not enable PortFast on loop guard-enabled ports.
  • Do not enable loop guard if root guard is enabled.
  • Do not enable loop guard on ports that are connected to a shared link.

V. Uni-Directional Link Detection (UDLD)

• Cisco-proprietary UDLD STP feature helps prevent a situation where a uni-directional traffic causes loops to occur.
• A  unidirectional link is a condition on switch ports where a link remains in the up state but the interface is not passing traffic.
  • A typical occurrence of this happens on GBIC interfaces or Small Form-Factor Pluggable (SFP) modules where.
  • When there is uni-directional link, one end of the link (the one in Blocking state) will not receive BPDUs. When BPDUs are not received on the blocked ports, they will transition through the STP states and start forwarding – when they shouldn’t. This can eventually cause instability on the network or bridging loops to occur.
•  UDLD interactively monitors a port to see if the link is truly bidirectional.
• The goal for UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state.
  • In order to accomplish this, the target time must be less than the Max age timer plus two intervals of the Forward Delay timer
    •  20 + 15 + 15 = 50 seconds.
  • UDLD can detect a unidirectional link after about three times the UDLD message interval
    • 15 x 3 = 45 seconds
• How it works:
  • The switch will send a special Layer 2 UDLD frame identifying its swtich port at regular interval (15 seconds).
  • UDLD expects the other end of the link to echo back those frames, with the far-end switch’s port identification added with it. 
    • The echo must be received within 15 seconds. For 3550s, the default is 7 seconds.
    • If not, the switch determines the link to be unidirectional and err-disables the port.
• UDLD requires both ends of the link to be configured for UDLD.

UDLD modes:

• Normal Mode – when a unidirectional link is detected, the port is allowed to continue operation. UDLD merely marks the port state as undetermined and sends a syslog message.
• Aggressive Mode – The switch takes action to re-establish the link. UDLD sends a message out once a second for 8 seconds. If there is no response (echo) the port is transitioned to err-disabled.

Configuring UDLD

• UDLD is disabled by default.
• It can be configured globally or per-interface.

To enable globally:

• This method enables UDLD on fiber-optic ports only. Enable UDLD on interface configuration if configuring on other port types.

Switch(config)#udld {enable | aggressive} | message time seconds}

• enable – use for normal mode
• aggressive – for aggressive mode
• message time – set the message interval between 7 to 90 seconds.

To enable on the interface:

Switch(config-if)#udld port [aggressive]

References:

1. Spanning-Tree Root Guard Enhancement
2. STP Portfast BPDU Guard Enhancement
3. Understanding How Portfast BPDU Guard Works
4. Understanding How PortFast BPDU Filtering Works
5. Understanding How Loop Guard Works
6. Understanding and Configuring the Unidirectional Link Detection Protocol
7. Configuring UDLD – Catalyst 2960 Software Config Guide 12.2(46)SE

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

Redundant Link Convergence Features

I. PortFast

• PortFast is an STP feature that allows an access port to immediately transition from blocking to forwarding – bypassing the listening and learning states.
• The purpose of PortFast is to minimize the time that access ports wait for STP to converge.
• The idea is that access port almost always have end-workstation plugged into them, therefore bridging loop is not a concern. And as such, there is no need for the protection of the whole STP cycle (listening and learning states).
• Even with PortFast enabled on a port, Spanning-tree detection is still working. If a loop is detected on that port, the port will move into Blocking state.
• On a PortFast enabled port, TCN BPDUs are not sent if it goes up and down.

Configuring PortFast

• PortFast is disabled by default.
• There are two methods that PortFast can be enabled:
  1. Globally – use this if configuring on a switch in the Building Access submodule, where all ports connect only to workstations and servers.
  2. Per interface – use for individual interface.
     • Remember to explicitly disable PortFast on uplink ports that connect to distribution layer switches.

Switch(config)#spanning-tree portfast default

Switch(config-if)# [no] spanning-tree portfast

• A special macro command can be used to simultaneously enable PortFast, set the port to access (non-trunking) mode, and disable PAgP (prevent EtherChannel):

Switch(config)# interface type mod/num
Switch(config-if)# switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled

Verifying PortFast Configuration

Switch# show spanning-tree interface fastethernet 0/1 portfast
VLAN0010      enabled
Switch#

II. UplinkFast

• UplinkFast is an STP feature that allows immediate convergence of a backup uplink when a redundant uplink fails.
  • Consider an access-layer switch with redundant connection to two distribution-layer switches. When one uplink goes down, the other uplink immediately goes off blocking state and starts forwarding.
  • The switchover bypasses the listening and learning states and converges within 5 seconds.
• UplinkFast is enabled for the entire switch and all VLANs.
• It is not allowed on the Root Bridge switch – because the feature works to keep track of possible paths to the root bridge itself.
• UplinkFast makes sure that the switch on with it is turned on does not become the Root Bridge. It also makes sure that the switch doesn’t become a transit switch to get to the Root Bridge.
  • The goal is to keep UplinkFast limited to leaf-node switches that are farthest from the Root.
• It raises the bridge priority to 49,152 – making it unlikely to be elected root bridge.
• All the switch ports cost is incremented by 3,000 to make it less likely to be used as paths towards the root for any downstream switches.

Configuring UplinkFast

• As mentioned earlier, UplinkFast affects all VLANs on the switches.
  • There is no support for configuring UplinkFast on a per-VLAN basis.
• To configure, enter the following global configuration command:

Switch(config)#spanning-tree uplinkfast [max-update-rate packets-per-second]

• The packets-per-second value is the number of multicast packets transmitted per second
  • The default is 150 pps.

Verifying UplinkFast Configuration

Switch# show spanning-tree uplinkfast
UplinkFast is enabled
Station update rate set to 150 packets/sec.
UplinkFast statistics
———————–
Number of transitions via uplinkFast (all VLANs)            : 2
Number of proxy multicast addresses transmitted (all VLANs) : 52
Name                Interface List
——————–   ————————————
VLAN0001            Gi0/1(fwd)
VLAN0010            Gi0/1(fwd)
VLAN0100            Gi0/1(fwd)

III. BackboneFast

• BackboneFast reduces the default convergence time in situations where the root port is lost by an indirect link failure and the backup link leads through a different switch.
  • Indirect link failure occurs when a link that is not directly connected to a switch fails. Can you say, duh?
  • It does not support failure by a direct link.
• The convergence is reduced from 50 seconds to 30 seconds.
  • It doesn’t eliminate the Forward Delay time.
• A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port.
  • A switch considers the BPDU an inferior BPDU when a switch receives the BPDU from a designated bridge that identifies the root bridge and the designated bridge as the same switch.
    • In other words, the designated bridge thinks of itself as the new root, sending the inferior BPDU, because it lost its connection to the root bridge, sending the inferior BPDU.
• The receiver of the inferior BPDU waits the Max Age time before it will respond to the BPDU.
• While waiting for the Max Age timer to expire, BackboneFast begins to determine whether other alternative paths to the Root Bridge exists according to the following port types that received the inferior BPDU:
  • If the inferior BPDU arrives on a port in the Blocking state, the switch considers the Root Port and all other blocked ports to be alternate paths to the Root Bridge.
  • If it arrives on the Root Port, all blocked ports are considered to be alternate paths to the Root.
  • If arrived on Root Port while no other ports are on blocking state, the switch assumes that it has lost connectivity with the Root Bridge and assumes, then, that it has become the Root Bridge. Backbone Fast allows the switch to do so before the Max Age timer expires.
• If alternate paths are available on switches that receive inferior BPDUs, BackboneFast will send Root Link Queries (RLQ) out these alternate paths to see if upstream switches have connection to the Root Bridge.
  • The objective of the RLQ BPDU is to find out whether the current root switch is still up.
  • If the Root Bridge or a switch that has lost connection to the Root Bridge receives an RLQ Request, it will respond with an RLQ Reply. If an RLQ Reply is not heard, the RLQ Request propagates towards the Root Bridge until an RLQ Reply can be generated.
    • On the local switch, if an RLQ Reply is received on its current Root Port, then the path to the Root Bridge is intact and stable.
    • If received on a non-root port, an alternative Root Path must be chosen and the Max Age timer is immediately expired so that a new Root Port can be found.

Configuring BackboneFast

• For BackboneFast to function correctly, it needs to be enabled on all switches in the network.
• Use the following global configuration command:

Switch(config)#spanning-tree backbonefast

Verifying configuration

Switch#show spanning-tree backbonefast
BackboneFast is enabled

References:

1. Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays – Cisco Systems
2. Understanding and Configuring the Cisco UplinkFast Feature – Cisco Systems
3. Understanding and Configuring Backbone Fast on Catalyst Switches- Cisco Systems

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

Congrats to Red Warrior for passing her BCMSN exam.

I’ve been following her blog for quite some time. We’ve actually encouraged each other on towards our pursuits along the way.  What better way for her to encourage me than to see that she has passed and moving on to her last hurdle before gettign the CCNP  – that is, BSCI. Wishing her luck!!!

Well, so far I’m progressing in my readings, albeit very slowly. I keep going back and forth in my indecision as to whether to continue “blogging” my notes. I know for sure that if I don’t take as exhaustive an approach towards my note taking, I could be at least 3 or 4 chapters ahead in my reviews. However, I also feel strongly that the process allows me to drastically slow down the learning process and help me understand the materials better than if I were to just blast through them. I really want to take the exam in mid-July but if I continue with my current pace, I’ll probably need 2 more extra months to finish. My rough calculation puts my study pace at about 3-4 pages of materials per day (if I were to quantify my progress). That’s good for the sake of movement, but not nearly good enough if I were to meet my time goal. Of course, I’ve never really met my initial time goal ever. But still, I have to at least try to meet my first.

For now, I’m sticking with my current ways. I will continue to blog my notes until I can no longer sustain that system without seriously hampering my progress.