Advanced STP: Loop Guard and UDLD

Lessons Learned:

Loop Guard and UDLD

Prevents Unidirectional links –

Note: Technical Only loop Guard is a Spanning-tree feature.

With Fiber Optic links there can be a case where the send channel from one end of the link is working but the receive channel is not. With optical interfaces there are two fiber strands. One for send – one for receive. There can be a case where one of the pairs breaks. This can create a problem in Spanning-tree, where we can send packets but are able to receive packets.

This would mean that the maximum age would expire on the interface, this could cause two switches to have their ports elected as the designated port at the same time. 

Example: If you have three switches connected together in a full mesh. Switch one will be the root so it will have designated ports pointing downward toward switches two and switch three. Switch one and two would then have their Root ports pointing upstream towards switch one. Switch two and three are connected together – this means the link between SW2 and SW3 – one port will be a Designated port and one will be blocking. On the blocking port –by default – we’re not sending BPDU’s but we’re listening for BPDU’s.

The link between SW2 and 3 has a fiber link – in the link we have a send channel and a receive channel that make up the pair.  If for some reason the send channel on the link goes down, The blocking side of the link can still send but cannot receive. The blocking port will be receiving BPPU and will be waiting for eth MaxAge to expire ( just like the dead interval in OSPF).  After the default 20 seconds the blocking link will start to forward and it will become a designated port. In this case both sides of the link will be forwarding so there will be multiple designated ports on the same segment. Which is a violation of the STP protocol.  STP cannot detect this because it’s a Layer 1 issues.

The solution is to create a layer 1 keep alive –

Both STP loop guard and UDLD create this keep alive. 

UDLD – can be enabled on interfaces that are not running STP.  The loop guard feature in inherit to STP and must be configured on an L2 interface only.

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10596-84.html

Note: Loop guard can prevent against failures in the STP process itself – Basically if the STP feature has a code bug or cashes, Loop guard can figure that out and compensate where UDLD cannot.

Note: Loop Guard cannot prevent against mis-wiring where UDLD can. Ex: The transmit is plugged into the receive port.

For these reasons – it’s recommended to run both at the same time. The difference is that Loop Guard will use the BPDU’s that are already there.  UDLD uses a different keep-alive depending on either aggressive or normal mode.

http://blog.ine.com/2008/07/05/udld-modes-of-operation/

 

Config:

UDLD – on the interface – configure UDLD 9 or UDLD aggressive)

Loop guard:

Global config

#spanning-tree loopguard default

Or under the interface:

#spanning-tree guard loop

You would configure Loop guard or UDLD on both sides of the links. Can be used on Copper but if meant for Fiber links.

For loop  guard you can configure it on a single interface but you would normally want to do it on both sides of the link

 

Advanced STP – STP Root Guard

Lessons learned:

Root Guard –

If superior BPDU is received shut down port.

Normally you enable root guard on the downstream facing interfaces form the sore or distribution layer.

Root Guard basically says check the BPDU’s as they come in (towards the Core / Distro Layers)

Allow Spanning-tree updates to come in but I the case of a Superior BPDU – better cost to the root bridge – Then disable the instance of spanning tree.

Root guard will only care about Superior BPDU’s, unlike BPDUGuard which will disable interfaces that receive BPDU’s.

Configure RootGuard:

From the root switch – on the downstream facing interfaces.

# spanning-tree guard root

configuration for this is at the port level. 

Advanced STP BPDUGuard

Lessons learned:

BPDUGuard:

This is similar to the BPDU filter – instead or reverting out of portfast state. BPDU filter will basically shut the port down and put it in the error-disabled state.

Will prevent against attacks, Improper wiring or a looped cable.

This can als be configured like the BPDUFilter option, either globally or at the interface level.

However the interface level will override the global config.

 

Ex: At the interface level we can configure “no spanning-tree bpdufilter or bpduguard” this will override the global config for this interface.

Link Level command:

#Spanning-tree bpduguard enable  

Then once the link receives a BPDU, it will disable the port.

To recover the port we can shut and then no shut the interface or wait until the Error recovery time expires.

Note; depending on the platform, some devices have the recovery timer on by default but not all of them will.

#sh errdisable recovery.

Will show the global status for errdisabled state.

However you can configure the errdisable recovery timer –

Set the recovery

# errdisable recovery interval 30 (this is 30 seconds)

Set the cause to recover from

#errdisable recovery cause bpduguard

Unless its turned on and the cause is set – the interface will stay disabled. Also it will auto disable again once it receives a BPDU on the interface.

This event can also cause a TCN to go out, if you lose connectivity you’ll need to wait until the globally configured timers expire.

This command can also be run globally in conjunction with portFast.

# Spanning-tree portfast default

#spanning-tree portfast bpduguard default

This again means that portfast is now on all interfaces that are not a trunk. This will however disable the interface if it received a BPDU and not enable portfast like BPDUFilter would.

 

Advanced STP BPDU Filter

Lessons Learned:

BPDU Filter:

Filters BPDU’s in and out. The filter will basically drop BPDU’s as they come in out go out an interface.

The command can be configured on the link level or globally. The command basically will disable spanning-tree either on an interface or if configured globally, on all interfaces.

Typical used at the access-layer down to the end host. This will help to prevent a L2 man-in-the-middle attach or other forms of denial of service attacks. We also don’t want to give out information about who is the root bridge, etc.

Configure feature:

Interface Gi0/1

#Spanning-tree bpdufilter enable

Verify if configured at the link level.

You can verify if the interface is now either sending / receiving BPDUs or not –

#sh spanning-tree int gi0/1 detail | in BPDU

You can also configure BPDUFilter globally in conjunction with portFast.

#spanning-tree portfast default

This now means all interfaces except for Trunk links will now be running portFast.

Verify

#sh spanning-tree int gi0/1 portfast

(will show if enable or not)

We can also configure globally:

#spanning-tree portfast bpdufilter default

This means that for any interface that is in the portfast mode, that interface will not be sending any BPDU’s out.

If configured on the link level we will not be sending BPDU’s in or out.

If configured globally, it will only filter BPDU’s out the interface.

If the interface on the other side starts to send BPDU’s – based on the config above. This will disable the portfast feature in the interface. If you combine portfast default and portfast BPDU default – the switch will automatically figure out which interfaces should be edge ports. It will accomplish this by looking for interfaces where BPDU’s are not coming in the interface.

For the interfaces that do not receive BPDU’s in – the switch will not sent BPDU’s out, This si because the BPDUFIlter feature is enabled. But if the switch does start to receive BPDU’s inbound, it will remove the portfast feature form the interface. This is a way the switch can tell if it should or should not be running spanning-tree on that particular interface.

Basically this will automate which interfaces should or should not run portfast.

This is a potential security issue. It can leave you open to a L2 man in the middle attack.

STP BackboneFast

Lessons Learned:

BackboneFast  - unlike UplinkFast – is used to detect and indirect failure in the network.

Where UplinkFast is used to direct a directly connected port failure.

BackboneFast:

Indirect failures should start recalculating immediately.

It will not converge as quickly as UplinkFast. It will detect our the local root port that someone else’s Root port upstream changed.

Example: 

Sw04 is root, each link between the switches is a FastEthernet link (cost of 19) except for the link Between SW03 and SW04. It’s s 2ooMB port channel, it’s cost will be 12.

So the path to the root from SW01 perspective will go through SW03 o get to SW04.

                     19 Cost

SW01  ---------------  SW02

|                                     |

| 19Cost                         | 19 Cost

|                                       |

SW03==========SW04

                     12 Cost

If we configure backboneFast on SW01 and the port-channel between SW03 ans SW04 goes down. SW03 will start to send “inferior BPDU’s towards SW03. Basically the BPDU’s will advertise a Worse cost to root through SW03.

SW01 realizes upstream that a failure has occurred. SW01 will then take it’s Max-Age Timer – by default is 20 Seconds. Sw01 will immediately expire that and start to recalculate.

The Key is that it’s used to detect indirect failures upstream but it’s only an optimization of 20 seconds.

You MUST configure BackboneFast on all switches because it’s a negotiated parameter between the switched.

From Global Config:

#Spanning-tree backbonefast

Useful commands:

#debug spaning-tree backbonefast

                                        

Note: STP will send a packet called “RLQ” (root link Query) this is specific to backboneFast to find an alternate path to the root.

Note: if the upstream sw only has one path to root and the link fails, it will advertise itself (it’s MAC) as the root.

To speed up Backbonefast – you’d have to literally change the MaxAge command on all switches. The minimum MaxAge command is 6 seconds. 

STP UplinkFast

Lessons Learned:

Direct root port failure should reconverge immediately if alternate port available

Used when you have one primary interface ( the root port) and other upstream interfaces that are blocking but hey could be used as alternate ports to reach the root.

The UplinkFast feature will start forwarding to an Alternate port without recalculating because STP has already determined there is a loop free path.

It does this by implementing two additional features behind the scenes.

1.       It does this my increasing the cost of all its links to try and make sure it will not be used as transit for someone else to reach the root. Basically if you have a very high cost on the links you will most likely be excluded from someone else’s path selection.

2.       The switch will also take the entire CAM table and spoofs the source from the original Root port to the new uplink. It will send the MAC to the upstream switch – which will clear its local arp for the original interface and updates the source to the new uplink. This results in sub-second convergence when the directly root port goes down.

NOTE: Uplinkfast is ONLY for your Directly Connected port failure!!

TO configure from Global config mode:

# Spanning-tree uplinkfast

This will change your priority to a higher numerical value – this will make sure you’re not root of able to be transit to reach root.

Useful commands:

#Debug Spaning-tree uplinkfast

You will see the TCN’s and the port transitions. This Debug is very chatty because it does it for all configured VLANS.

#Service timestamp log uptime. – Will help with viewing logs.

Note: When the original link return to service, This will force the switch transition back to the original root port.

This feature MUST be used in either the Access or Distribution layer. You cannot use in the Core because the switch is increasing it cost and priority values.

STP Timers and STP Portfast.

Lessons Learned:

STP Timers:

Timers effect the transition between port states. (down blocking listening learning and forwarding) default on Catalyst IOS switches is PVST+

These timers are set only on the Root bridge. These timers effect eh convergence time.

 

NOTE: is common spanning-tree and PVSTP – ONLY the root bridge is allowed to generate BPDU’s.  BPDU’s start at the root of the STP and flow down the tree.

 

Hello –

How often configuration BPDU’s are sent – default is 2 seconds.

 

MaxAge –

How long to wait in  a blocking state without hearing a BPDU – default is 20 seconds. This is very similar to the dead interval in OSPF, basically how long to wait until you declare a neighbor down.  If no BPDU’s are heard for the MaxAge time STP will start to recalculate the STP and invalidate any BPDU’s it recently heard. To find a new route to the root bridge.

 

Forward Delay –

How long to wait unitl each listening and learning stage – default is 15 seconds.

Switch listens and learns and populated the CAM table – then forwarding. So the total of listening and learning together is 30 seconds.

 

Again – in Common and PVST these values are all configured on the root bridge.

 

Configuration:

#spanning-tree vlan (vlan) hello-time

#spanning-tree vlan (vlan) Max-age

#spanning-tree vlan (vlan) Forward-time

 

If you change these timers on a switch that is NOT the root bridge, it will not affect anything, Unless that switch becomes the root bridge.

 

Best practice is to leave the values along. If you want to speed up convergence there are several features that can be deployed.

 

PortFast:

Edge ports should not be subject to forward delay –

Also effects TCN generation

Used on end-host, phones etc. Nothing that need to run spanning-tree. This does not mean STP is disabled. Just means you don’t need to go through the forwarding phases.

 

UplinkFast:

Direct root port failure should reconverge immediately if an alternate port is available. 

 

BackboneFast

Indirect failures should start to recalculate immediately

 

Topology Change Notification:

 

This can be watched via: Debug spanning-tree events:

You want to make sure your edge ports are configures for PortFast – PortFast keeps edge ports from generating a TCN.

 

A TCN  - says to flush out your CAM table by setting the CAM ageing time to be equal to the Max age time.

 

Note: The default MAC address table aging time is 300 seconds or 5 minutes by default.

So a MAC address will stay in the table for 5 minutes if it has been Idle. If the MAC address is not in the table, it will flood the frame out all ports in the VLAN, etc.

Switches that are not in the root path and are not forwarding for that VLAN, etc will not have the associated MAC addresses in the CAM Table. So once the TCN event is triggered –  it will flush the MAC from the downed port out of the CAM table.

For example. You have VLAN 10 that is forwarding traffic and you shut and no shut an interface for an end host on that VLAN (a router for example). The switch wil send a TCN. You can verify the MAC has been flushed by once the root bridge replys back to the TCN – This will flush the CAM table for that entire VLAN.  

# sh mac address-table dynamic Vlan 10

Note: When PortFast is on this is does NOT disable Spanning-tree.

A quick PortFast verification is ex: Sh spanning-tree int Gi0/1 portfast

You can also verfy BPDU’s sent out an interface:

EX: SH spanning-tree int gi0/1 detail | in BPDU

PortFast can be enabled globally:

EX: Spanning-tree portfast default.
This is bascially the same as using an interface range for all ports and setting portfast.

For Tunk Interfaces - portfast willnot be on dy default. Even if they're not receive BPDU's.
The only time you'd really want a trunk with portfast is if you had say a VMWare server that needed Vlans trunked.
This can be configured via:
ex: spaning-tree portfast trunk on the interface level. This will ensure that when the interface goes down it will not generate a TCN.