STP_3switches2links_Fiber_Fail

The above Topology represents a failure on a Fiber Optic Transmit / Receive cable pair on one cable, on one end of the link, which would leave the link up and Unidirectional.

Here is an example of the SFP Transceiver and Fiber cable connecting to a switch:

Fiber_Connector

Source : This Cisco.com 2960x Fiber Stacking article (good read!)

The module being plugged into the switch is an SFP (Small Form-factor Pluggable) Transceiver, which is basically an adapter module that allows the fiber optic cable to be plugged in as two separate pairs (wires), one Transmit and one Receive link.

This type of link can become Unidirectional if one of the two fiber pair fails, whether a server room rabbit chews through it, or if Tx and Rx are paired incorrectly with the remote side of the link (which is a whole different world of problems at that point).

We all know how rampant an issue server room rabbits chewing through fiber cables are, and have addressed this problem with two mechanisms – Loop Guard and UDLD!

 

Loop Guard vs UDLD (Unidirectional Link Detection)

 

Both Loop Guard and UDLD share the same common goal of identifying when a link becomes Unidirectional or “one-way” communication, Loop Guard using BPDUs, and UDLD using its own polling mechanism of its neighbor explained further below.

Aside from both being configurable globally and per interface, the similarities end here.

One HUGE difference, is that UDLD is NOT a Spanning-Tree feature! It is used to keep the Layer 2 Topology loop-free, but it does not utilize Spanning-Tree to accomplish its task.

In contrast, Loop Guard IS a Spanning-Tree feature, as it functions as a result of BPDUs being missed on a link that is still physically and logically Up.

Another important note for exam day – UDLD is Cisco Proprietary!

Loop Guard can be configured on a single switch, whereas UDLD must be configured on both switches, due to the way it prevents switching loops.

 

What happens when a Unidirectional link goes unchecked in an STP network

 

Rather than chewing through fiber to create a physical failure, I have configured the following Topology, with SW2 Interface Fa1/0/2 configured with BPDU Filter:

STP_SwitchingLoop

There is no direct link failure to trigger the STP Topology change, SW3 will wait the Max-Age timer of missed Hellos on interface Fa1/0/2, and once that expires it will transition from Blocking to Forwarding.

To demonstrate this on the lab (with the Portfast warning removed):

SW3#debug span events
Spanning Tree event debugging is on
SW3#
ASR#2
[Resuming connection 2 to sw2 … ]

SW2#
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int fa1/0/2
SW2(config-if)#span portfast
SW2(config-if)#span bpdufilter enable
SW2(config-if)#
ASR#3
[Resuming connection 3 to sw3 … ]

SW3#
*Mar 1 01:57:03.051: STP: VLAN0001 Fa1/0/2 -> listening
SW3#
*Mar 1 01:57:18.058: STP: VLAN0001 Fa1/0/2 -> learning
SW3#
*Mar 1 01:57:33.065: STP[1]: Generating TC trap for port FastEthernet1/0/2
*Mar 1 01:57:33.065: STP: VLAN0001 sent Topology Change Notice on Fa1/0/3
*Mar 1 01:57:33.065: STP: VLAN0001 Fa1/0/2 -> forwarding
SW3#

So what do we end up with?

A full fledged STP Switching Loop as illustrated in verification of SW1 / SW2 / SW3 below:

SW1

SW1#sh span

VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 1ce6.c7c1.c800
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 1ce6.c7c1.c800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/1 Desg FWD 19 128.3 P2p
Fa1/0/3 Desg FWD 19 128.5 P2p

SW2

SW2#sh span

VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 1ce6.c7c1.c800
Cost 19
Port 3 (FastEthernet1/0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5897.1eab.c800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/1 Root FWD 19 128.3 P2p
Fa1/0/2 Desg FWD 19 128.4 P2p

SW3

SW3#sh span

VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 1ce6.c7c1.c800
Cost 19
Port 5 (FastEthernet1/0/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5897.1eab.ce00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Desg FWD 19 128.4 P2p
Fa1/0/3 Root FWD 19 128.5 P2p

All Forwarding would be nice, but is bad.

So to address this, I’ll back off the BPDU Filter to let STP correct this loop, and will review methods to prevent this from happening upon such a configuration or fiber failure.

 

Spanning-Tree Loop Guard

 

The only more detail I have on Loop Guard not already discussed, once it stops receiving Hellos from the neighbor but the link stays up (link goes Unidirectional), it will put it into a “loop-inconsistent” state rather than allowing it to transition to Forwarding.

IMPORTANT TO NOTE – Loop Guard IS NOT A PORTFAST FEATURE!

Root Guard and BPDU Guard both are Portfast features, but Loop Guard IS NOT!

That is very important to understand for exam day! (And in general, of course!)

Global Loop Guard Configuration

SW3(config)#span ?
backbonefast Enable BackboneFast Feature
etherchannel Spanning tree etherchannel specific configuration
extend Spanning Tree 802.1t extensions
logging Enable Spanning tree logging
loopguard Spanning tree loopguard options

mode Spanning tree operating mode
mst Multiple spanning tree configuration
pathcost Spanning tree pathcost options
portfast Spanning tree portfast options
transmit STP transmit parameters
uplinkfast Enable UplinkFast Feature
vlan VLAN Switch Spanning Tree

SW3(config)#span loopguard ?
default Enable loopguard by default on all ports

SW3(config)#span loopguard default ?
<cr>

SW3(config)#span loopguard default

Running debug on SW3 / Adding BPDU Filter back to SW2

SW3#debug span events
Spanning Tree event debugging is on
SW3#
ASR#2
[Resuming connection 2 to sw2 … ]

SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int fa1/0/2
SW2(config-if)#span portfast
SW2(config-if)#span bpdufilter enable
SW2(config-if)#
ASR#3
[Resuming connection 3 to sw3 … ]

SW3#
*Mar 1 02:44:58.221: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port FastEthernet1/0/2 on VLAN0001.

SW3#

So that is all debugging has to say about that, I’d say remember that for exam day, but that about hits you over the head with a wooden plank with LOOPGUARD written on it!

How else can it be verified? Where can it be seen that it is in Loop Inconsistent state?

SW3#sh span

VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 1ce6.c7c1.c800
Cost 19
Port 5 (FastEthernet1/0/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5897.1eab.ce00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Desg BKN*19 128.4 P2p *LOOP_Inc
Fa1/0/3 Root FWD 19 128.5 P2p

It functions exactly like Root Guard does, in the way that it won’t declare the link down and put it into an err-disable mode, but it will put it into Blocking / Loop Inconsistent state until the physical or logical issue is addressed.

This can also be verified with “sh span incon”

SW3#sh span incon

Name Interface Inconsistency
——————– ———————— ——————
VLAN0001 FastEthernet1/0/2 Loop Inconsistent

Number of inconsistent ports (segments) in the system : 1

SW3#

That is of course where you can check for ports placed in an inconsistent state by either Root Guard or Loop Guard.

Here is a port level configuration of Loop Guard, minus all the verification output:

SW3(config)#int fa1/0/2
SW3(config-if)#span ?
bpdufilter Don’t send or receive BPDUs on this interface
bpduguard Don’t accept BPDUs on this interface
cost Change an interface’s spanning tree port path cost
guard Change an interface’s spanning tree guard mode

link-type Specify a link type for spanning tree protocol use
mst Multiple spanning tree
port-priority Change an interface’s spanning tree port priority
portfast Enable an interface to move directly to forwarding on link up
stack-port Enable stack port
vlan VLAN Switch Spanning Tree

SW3(config-if)#span guard ?
loop Set guard mode to loop guard on interface

none Set guard mode to none
root Set guard mode to root guard on interface

SW3(config-if)#span guard loop ?
<cr>

At the interface level with “span guard …” it can either be configured with root, loop, or none to disable either guard type running on the interface (discussed in previous post).

One final important note for exam day – The time it takes Loop Guard to put a port into Loop Inconsistent state is equal to the Max-Age timer.

 

Not-So-Spanning-Tree UDLD (Unidirectional Link Detection)

 

I believe it is worth repeating in bold text, UDLD IS CISCO PROPRIETARY!

It is lumped in with STP because it helps keep a loop free Layer 2 Topology with STP, by sending UDLD frames between the switches on both sides of the link, every 15 seconds when set in its default mode.

UDLD enabled ports will send out UDLD Frames containing the Device and Port ID of the local switch, and the neighbor switch will respond with a UDLD Echo frame back to its peer, containing the Peers (original switches) Device ID and Port ID – Just like a ping.

This is why both sides must be configured for this to work, as the switch will not respond with a UDLD Echo if it is not configured with UDLD itself.

There are two different types of UDLD modes:

  • Normal – This is the default mode, UDLD Frame sent every 15 seconds, will log error if no echo returned but will not take action, this results in STP Max-Age timer (20 by default) to be reached and the port be transitioned from Blocking to Forwarding
  • Aggressive – Non-default, UDLD Frame sent every 1 second, after 8 missed responses port is placed into err-disabled mode

 

Once configured on Switch A, UDLD will begin sending UDLD Frames out the enabled interface, and will continue to do so forever if it never gets the UDLD “Echo” back.

Once it gets the “Echo” back, that is when it gets in synch with the remote switch exchanging UDLD Frames, and at this point the timers mentioned above for default and aggressive kick in.

So if you configure it on Switch A, you can come back the next day and it will still be sending “probe” frames to Switch B’s interface, waiting for it to be UDLD configured to respond with a UDLD Echo to get things started.

With all that theory out of the way, here are some configurations and verifications:

Global Configuration of UDLD “default” and “aggressive”

SW3(config)#udld ?
aggressive Enable UDLD protocol in aggressive mode on fiber ports except

where locally configured

enable Enable UDLD protocol on fiber ports except where locally

configured

message Set UDLD message parameters

SW3(config)#udld aggressive ?
<cr>

SW3(config)#udld enable ?
<cr>

This will enable UDLD globally, either in its default mode with “udld enable” or in its aggressive mode with “udld aggressive”, and I have no idea what the message sub-command is for so I will leave it at that.

So on an interface level configuration, I’ll demonstrate what happens if either mode is configured, I won’t post each step but I will put SW2 Fa1/0/2 into BPDU Filter mode and jump back to SW3 to catch the reaction.

One important note – I configured one side as default, the other as aggressive, and debugs show that packets are being exchanged every 15 seconds so default will be used if both sides are configured differently.

Here is the default UDLD configuration and output

SW3(config)#int fa1/0/2
SW3(config-if)#udld port ?
aggressive Enable UDLD protocol in aggressive mode on this interface

<cr>

Default will be in blue of course, and aggressive will be in red (obviously).

Unfortunately this cannot be labbed using the “BPDU Filter” and does require an actual Fiber cable failure, as this does not depend on BPDU’s to prevent Spanning-Tree from eventually getting to its Max-Age and transitioning into Forwarding.

So even if BPDU’s are being missed, UDLD continues to get its bi-directional frames exchanging, so it could care less what STP wants to do.

However, I did want to demonstrate one good verification command for UDLD:

SW3#sh udld fa1/0/2

Interface Fa1/0/2

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: 15000
Time out interval: 5000

Entry 1

Expiration time: 44900
Device ID: 1
Current neighbor state: Bidirectional
Device name: FDO1643Y0Z9
Port ID: Fa1/0/2
Neighbor echo 1 device: FDO1643Y0ZG
Neighbor echo 1 port: Fa1/0/2

Message interval: 15
Time out interval: 5
CDP Device name: SW2
SW3#

Lots of good info that doesn’t just pertain to UDLD, like if you were tasked to get a neighboring devices serial number to call support, you have both THIS serial number and the connected devices serial number:

SW3#sh inv
NAME: “1”, DESCR: “WS-C3750V2-24PS”
PID: WS-C3750V2-24PS-S , VID: V08 , SN: FDO1643Y0ZG

So something to keep in mind for exam day.

One last note and I am more done than done could possibly be on this topic:

SW3#udld ?
reset Reset all interfaces which have been shutdown by UDLD

SW3#udld reset ?
<cr>

SW3#udld reset

So if UDLD puts an interface into err-disabled, the command “udld reset” at User Exec level will bring the interfaces back up without a shut / no shut.

Its trivial knowledge, but Cisco exams love trivial knowledge 🙂

So that is about everything you’d ever want to know about Loop Guard, and UDLD!

If you’ve made it this far without falling asleep on your keyboard, congratulations 🙂