BPDU Guard, BPDU Filter, Root Guard, Loop Guard & UDLD

BPDU Guard: Prevents accidental connection of switching devices to PortFast-enabled ports. Connecting switches to PortFast-enabled ports can cause Layer 2 loops or topology changes.

BPDU filtering: Restricts the switch from sending unnecessary BPDUs out access ports.

Root Guard: Prevents switches connected on ports configured as access ports from becoming
the root switch.

Loop Guard: The Loop Guard STP feature improves the stability of Layer 2 networks by preventing bridging loops.

UDLD: UDLD detects and disables unidirectional links.

BPDU Guard

BPDU Guard puts an interface configured for STP PortFast into the err-disable state upon  receipt of a BPDU. The BPDU Guard disables interfaces as a preventive step to avoid a potential
bridging loop. The BPDU Guard feature is used to protect the Spanning Tree domain from external influence. BPDU Guard is disabled by default but is recommended for all ports on which the Port Fast feature has been enabled. This prevents false information from being injected into the Spanning Tree domain on ports that have Spanning Tree disabled.

When a port only has a host device connected to it, we will enable portfast, this will speed up the port initialization process and put the port into forwarding state straight away. This eliminates 30 seconds of delay that would have been encountered if STP was not bypassed and the port went through the Listening and Learning states. Because host is a workstation, it sends no BPDUs and so disabling Spanning Tree on a port like this is not an issue.

If we removed this end host of this port and connected a switch. This new switch will start to generate BPDUs and could take over as been the Root Bridge for the network, or it could cause a loop in our network if it has another link connected into another part of the network.

So what BPDU Guard will provide is a secure response to invalid configurations, or unauthorised switches onto our network,  because the administrator must manually reenable the err-disabled interface after fixing the invalid configuration, or removing the unauthorised switch form the network. It is also possible to set up a time-out interval after which the switch automatically tries to reenable the interface. However, if the invalid configuration, or switch still exists,the switch err-disables the interface again.

To enable BPDU Guard or to disable BPDU Guard on a switch do the following;

switch(config)#[no] spanning-tree portfast edge bpduguard default

switch(config-if)#spanning-tree bpduguard enable

switch#show spanning-tree summary totals                                                                         Root bridge for: none.
PortFast BPDU Guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Default pathcost method used is short

BPDU Filter

When PortFast is enabled on a port, the port will send out BPDUs and will accept and process received BPDUs. The BPDU Guard feature prevents the port from receiving any BPDUs but does not prevent it from sending them. If any BPDUs are received, the port will be errdisabled. The BPDU Filter feature effectively disables STP on the selected ports by preventing them from sending or receiving any BPDUs.

BPDU filtering supports the ability to prevent switches from sending BPDUs on PortFast-enabled interfaces. Ports configured for the PortFast feature typically connect to host devices. Hosts do not participate in STP and hence drop the received BPDUs. As a result, BPDU filtering prevents unnecessary BPDUs from being transmitted to host devices.

When enabled globally, BPDU filtering has the following affects;

  • It affects all operational PortFast ports on switches that do not have BPDU filtering configured on the individual ports.
  • If BPDUs are seen, the port loses its PortFast status, BPDU filtering is disabled, and the STP sends and receives BPDUs on the port as it would with any other STP port on the switch.
  • Upon startup, the port transmits ten BPDUs. If this port receives any BPDUs during that time, PortFast and PortFast BPDU filtering are disabled.

When enabled on an individual port, BPDU filtering has the following affects;

  • It ignores all BPDUs received.
  • It sends no BPDUs.

If you enable BPDU Guard on the same interface as BPDU filtering, BPDU Guard has no effect because BPDU filtering takes precedence over BPDU Guard.

To enable PortFast BPDU filtering;

switch(config)#spanning-tree portfast bpdufilter default

switch(config-if)#spanning-tree bpdufilter enable

switch#show spanning-tree summary
Switch is in pvst mode
Root bridge for: none
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is enabled

switch# show spanning-tree interface fastEthernet 0/1 detail
Port 196 (FastEthernet0/1) of VLAN0010 is forwarding
Port path cost 1000, Port priority 160, Port Identifier
Designated root has priority 32768, address 00d0.00b8.140a
Designated bridge has priority 32768, address 00d0.00b8.140a
Designated port id is 160.196, designated path cost 0
Timers:message age 0, forward delay 0, hold 0
Number of transitions to forwarding state:1
The port is in the portfast mode by portfast trunk
Link type is point-to-point by default
Bpdu filter is enabled
BPDU:sent 0, received 0

Root Guard

Root Guard is useful in avoiding Layer 2 loops during network anomalies. The Root Guard feature forces an interface to become a designated port to prevent surrounding switches from becoming a root switch. In other words, Root Guard provides a way to enforce the root bridge placement in the network. The Root Guard feature prevents a Designated Port from becoming a Root Port. If a port on which the Root Guard feature receives a superior BPDU, it moves the port into a root-inconsistent state (effectively equal to a listening state), thus maintaining the current Root Bridge status.

The Root Guard feature prevents a port from becoming a Root Port, thus ensuring that the port is always a Designated Port. Unlike other STP enhancements, which can also be enabled on a global basis, Root Guard must be manually enabled on all ports where the Root Bridge should not appear. Because of this, it is important to ensure a deterministic topology when designing and implementing STP in the LAN. After the Root Guard feature is enabled on a port, the switch does not enable that port to become an STP root port. The port remains as an STPdesignated
port. In addition, if a better BPDU is received on the port, Root Guard disables (err-disables)
the port rather than processing the BPDU. If an unauthorized device starts sending BPDUs with a better bridge ID, the normal STP process would elect the new switch as the root switch. By disabling the port, the network topology is protected.

Current design recommendation is to enable Root Guard on all access ports so that a root bridge is not established through these ports. After a port stops receiving superior BPDUs, the port unblocks again and goes through regular STP transition of listening and learning, and eventually to the forwarding state. Recovery is automatic; no intervention is required.

To enable Root Guard;

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

switch# show spanning-tree inconsistentports
Name Interface Inconsistency
——————– ———————- ——————
VLAN0001 FastEthernet0/1 Port Type Inconsistent
VLAN0001 FastEthernet0/2 Port Type Inconsistent
VLAN0002 FastEthernet0/1 Port Type Inconsistent
VLAN0002 FastEthernet0/2 Port Type Inconsistent

Loop Guard

Loop Guard provides additional protection against Layer 2 forwarding loops (STP loops). A bridging loop happens when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually occurs because one of the ports of a physically redundant topology (not necessarily the STP blocking port) has stopped receiving STP BPDUs. In STP, switches rely on continuous reception or transmission of BPDUs, depending on the port role. (A designated port transmits BPDUs, whereas a nondesignated port receives BPDUs.)
If the switch link is up and no BPDUs are received (due to a unidirectional link), the switch assumes that it is safe to bring this link up and the port transitions to the Forwarding state and begins relaying received BPUDs. If a switch is connected to the other end of the link, this effectively creates a Spanning Tree loop.

With the Loop Guard feature, switches do an additional check before transitioning to the STP forwarding state. If switches stop receiving BPDUs on a nondesignated port with the Loop Guard feature enabled, the switch places the port into the STP loop-inconsistent blocking state instead of moving through the listening, learning, and forwarding states. If a switch receives a BPDU on a port in the loop-inconsistent STP state, the port transitions through STP states according to the received BPDU. As a result, recovery is automatic, and no manual intervention is necessary.

When implementing Loop Guard, you should be aware of the following implementation  guidelines;

  • Loop Guard cannot be enabled on a switch that also has Root Guard enabled
  • Loop Guard does not affect Uplink Fast or Backbone Fast operation
  • Loop Guard must be enabled on point-to-point links only
  • Loop Guard operation is not affected by the Spanning Tree timers
  • Loop Guard cannot actually detect a unidirectional link
  • Loop Guard cannot be enabled on Port Fast or Dynamic VLAN ports

You configure the Loop Guard feature on a per-port basis, although the feature blocks  inconsistent ports on a per-VLAN basis. For example, on a trunk port, if BPDUs are not received for only one particular VLAN, the switch blocks only that VLAN (that is, moves the port for that VLAN to the loop-inconsistent STP state). In the case of an Ether Channel interface, the channel status goes into the inconsistent state for all the ports belonging to the channel group for the particular VLAN not receiving BPDUs. Enable the Loop Guard feature on all nondesignated ports, and not just for blocking ports. More precisely, Loop Guard should be enabled on root and alternative ports for all possible combinations of active topologies. Before enabling Loop Guard, however, consider all possible failover scenarios.


A unidirectional link occurs when traffic is transmitted between neighbors in one direction only. Unidirectional Link Detection is a Layer 2 protocol. UDLD performs tasks that Layer 1  mechanisms, such as auto negotiation, cannot perform. When UDLD and auto-negotiation are enabled, both Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols. Unidirectional links can cause  spanning-tree topology loops. UDLD enables devices to detect when a unidirectional link exists and also to shut down the affected interface. UDLD is useful on a fiber ports to prevent  network issues resulting in miswiring at the patch panel causing the link to be in up/up status but the BPDUs are lost.

With UDLD enabled, the switch periodically sends UDLD protocol packets to its neighbor and expects the packets to be echoed back before a predetermined timer expires. If the timer  expires, the switch determines the link to be unidirectional and shuts down the port. If messages are not received within the timeout interval (45 seconds), the port is disabled. The messages are sent out every default interval, which is 15 seconds.

The 45 seconds it takes to detect a unidirectional link and errdisable the port is less than the 50 seconds it would take for STP to transition the port to a Forwarding state, which is based on 20 seconds for Max Age + 30 seconds for Listening and Learning. This prevents a loop that would otherwise be caused if STP transitioned the port into the Forwarding state because of a lack of received BPDUs.

UDLD is a Layer 2 protocol enabled between adjacent switches. It uses MAC 01-00-0c-cc-cc-cc with Subnetwork Access Protocol (SNAP) High-Level Data Link Control (HDLC) protocol type 0x0111. UDLD packets contain information about sending the port’s device ID and port ID and the neighbor’s device ID and port ID. Neighbor devices with UDLD enabled send the same hello message. The link is bidirectional if devices on both sides receive each other’s UDLD packets. If the port does not see its own device and port ID in the incoming UDLD packets for a specific duration of time (timeout interval), the link is considered unidirectional and is disabled.

This UDLD echo-algorithm allows for unidirectional link detection due to the following:

  • When the link is up on both sides; however, packets are being received by only one side
  • When receive and transmit Fibers are not connected to the same port on the remote side

A UDLD frame is made up of the following fields;

  • Device ID – This field contains the MAC address of the sending device.
  • Port ID – This field contains the module and port number of the sending device.
  • Echo – This field contains the module and port pair known by the sending device.
  • Message Interval – This field contains the transmit interval of the sending device.
  • Timeout Interval – This field contains the timeout interval of the sending device.
  • Device Name – This field contains the CDP Device ID string of the sending device.
  • Sequence Number – This field contains the number used to validate discovery packets.
  • Reserved – These fields are reserved for future use.

Once the unidirectional link is detected by UDLD, the respective port is disabled and remains disabled until it is manually re-enabled, or until errdisable timeout expires (if configured). UDLD can operate in either normal or aggressive mode.

In Normal mode, UDLD simply changes the UDLD-enabled port to an undetermined state if it stops receiving UDLD messages from its directly connected neighbor. Aggressive mode UDLD is a variation of UDLD, and when a port stops receiving UDLD packets, UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port state changes to the err-disable state, which effectively disables the port.

In UDLD normal mode, when a unidirectional link condition is detected, the port is allowed to continue its operation. UDLD merely marks the port as having an undetermined state and generates a syslog message. In other words, in normal mode, no action is taken by UDLD and the port is allowed to continue behaving according to its Spanning Tree state.

UDLD aggressive mode is configured on point-to-point links. This mode comes into play after a UDLD neighbor stops receiving UDLD updates from its adjacent peer. In aggressive mode, the local device will attempt to re-establish the UDLD connection eight times. If the switch is unable to re-establish the connection within this timeframe, it will proceed and errdisable the port.

Aggressive mode is the preferred method of configuring UDLD. By preventing this one-way
communication, UDLD can be useful in spanning-tree networks. UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional  communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed. UDLD aggressive mode adds additional detection when the port is stuck (one side is neither transmiting nor receives; however, the link is up on both ends) or when the link is up on one side and down on the other side, which is typically seen on Fiber connections only, as Copper ports are normally not susceptible to this type of issue because they use Ethernet link pulses to monitor the link.

To bring a port back up after it has been placed into error-disable state, simply shut and then no shut the affect interface once the error has been corrected.

UDLD can be enabled globally for all fiber interfaces or on a per-interface basis.

To enable UDLD on an interface,

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

To enable UDLD globally on all fiber-optic interfaces,

Switch(config)# udld { enable | aggressive }

To verify UDLD on a port run the following command,

SwitchA#show udld gigabitEthernet 0/1
Interface Gi0/1

Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement – Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1

Expiration time: 38
Device ID: 1
Current neighbor state: Bidirectional
Device name: FOX01590RW1
Port ID: Gi1/1
Neighbor echo 1 device: FOX0872A001
Neighbor echo 1 port: Gi0/1
Message interval: 15
Time out interval: 5
CDP Device name: SwitchB

Comparison Between Aggressive Mode UDLD and Loop Guard

Loop Guard and aggressive mode UDLD functionality overlap insofar as both protect against STP failures caused by unidirectional links. These two features are different, however, in their approach to the problem and in functionality.

Loop Guard Aggressive Mode UDLD
Configuration Per Port Per Port
Action Granularity Per Vlan Per Port
Auto-Recovery Yes Yes with err-diable timeout
Protection against STP failures
caused by unidirectional links
Yes, when enabled on all root ports and alternative port in
redundant topology
Yes, when enabled on all links in redundant topology
Protection against STP failures
caused by software resulting in
designated switch not  sending BPDUs
Yes No
Protection against miss wiring No Yes

The most noticeable difference between aggressive mode UDLD and Loop Guard is with regard to STP. Aggressive mode UDLD cannot detect failures caused by problems in software in the designated switch not sending the BPDU. Aggressive mode UDLD is more robust in its capability to detect unidirectional links on EtherChannel. Loop Guard blocks all interfaces of
the EtherChannel in such a failure by putting the EtherChannel into the loop-inconsistent state for a VLAN or for all VLANs, whereas aggressive mode UDLD disables the single port exhibiting problems. In addition, aggressive mode UDLD is not dependent on STP, so it supports Layer 3 links as well. Loop Guard does not support shared links or interfaces that are unidirectional on switch Bootup. If a port is unidirectional on switch Bootup, the port never receives BPDUs and becomes a designated port. Loop Guard does not support this scenario, because the behavior is not distinguishable from normal STP operation. Aggressive mode UDLD does provide protection against such a failure scenario.

Enabling both aggressive mode UDLD and Loop Guard provides the highest level of protection against bridging loops and black holes in multilayer switched networks.