BackboneFast: RLQ PDU

Root Link Query Protocol Data Unit:

There are two forms of RLQ PDU, RLQ Requests and RLQ Responses

RLQ Requests are sent out on ports where BPDUs are usually received, so that it can check that the switch is still connected to the Root on that port.   The outbound RLQ Requests defines what Root bridge that switch currently has in its saved BPDU and once it’s sent out a RLQ response comes back with a root bridge that can be accessed through that port.  If the two roots are the same connectivity is still good, if it isn’t that means a failure has occurred.

A switch receiving an RLQ Request immediately answers if it is aware it has lost connection to the root that’s queried because it will have a root bridge different than the one found in the RLQ PDU.

RLQ Responses are flooded on designated ports, the sender of the RLQ Request also include its own bridge ID in the PDU, this allows the sender to confirm that it’s received it’s own response to its request.

The RLQ PDU uses the same packet structure as a normal STP BPDU however there are two different cisco specific SNAP addresses used, one for the request and one for the reply.

BackboneFast must be configured on all switches in the network in order to process these kinds of PDUs.

Spanning Tree Protocol: BackboneFast

BackboneFast is a Cisco proprietary feature that allows all switches on a network to save up to 20 seconds max age time when recovering from indirect link failure.

BackboneFast attempts to get rid of the STP standard of waiting max age seconds for timing out saved BPDUs.  Instead BackboneFast has the ability to detect indirect link failures by tracking inferior BPDUs being sent on designated port when a failure occurs.  It also has a mechanism that allows to it to immediately check if the BPDU information stored on a port is still valid via the Root Link Query PDU (RLQ PDU).

Detecting Link Failures

First the switch detects the inferior BPDU by receiving the new one being sent after a failure occurs and comparing it to the BPDU it already has stored previously.  Instead of ignoring these inferior BPDUs per the STP standard, BackboneFast begins to immediately send RLQ PDUs on all non-designated ports except the port in which the inferior BPDU was received.  Once an RLQ PDU is sent out (request) the port then waits for a RLQ Response.

Once an RLQ response comes back, if the answer is negative the port has lost its connection to the root and its BPDU can be immediately aged out, if all other non-designated ports received a negative answer the whole bridge loses the root and can restart STP calculations.

If the RLQ PDU comes back positive you can immediately age out the port that received the inferior BPDU

 

Spanning Tree Protocol: UplinkFast

UplinkFast improves the convergence time of STP in the event of a failure on an uplink.  UplinkFast is a Cisco proprietary feature and is designed to run in a switch environment with at least one alternate or backup Root port.  Cisco recommends this feature only be enabled for switches with blocked ports, at the access layer.

Consider the above scenario, the Access switch ‘A’ has two redundant connections and the primary connection goes down. Switch A knows immediately that the path through D2 is a unique path to get to the Root bridge, so it places P2 into forwarding IMMEDIATELY violating normal STP guidelines.

Once the switchover occurs, the CAM table is not yet updated, the backup link is brought up so quickly that CAM tables are no longer accurate.  To solve this problem Switch A starts flooding dummy packets with the different MAC addresses it has in its CAM table as a source.  The destination is a Cisco multicast MAC address that ensures the packet is flooded on the whole network and updates the CAM tables on other switches.

What happens when the uplink comes back online?  UplinkFast does not put the P1 path immediately into forwarding.  If the primary uplink is flapping its better to not introduce instability be constantly re-enabling it.  Instead it waits until the port on D1 begins forwarding which is using standard STP rules and will begin forwarding after the listening and learning phase or about 30-35 seconds.

Spanning Tree Protocol: Timers

Spanning Tree Protocol consists of the following timers:

• Hello – This is the time between each BPDU that is transmitted, by default this is set to 2 seconds, this can be tuned between 1 and 10 sec
• Forward Delay – this is the amount of time defined for a port to be in a listening or learning state.  By default this is 15 seconds, but this can be tuned between 4 and 30 sec.
• Max Age – this is the timer that controls the max length of time that passes before a bridge port saves its BPDU information.  By default this is 20 seconds but can be tuned between 6 and 40 sec.
• Message Age – this is not a fixed value this contains the length of time that has passed since the root bridge originated the BPDU.

Other Parameters Spanning Tree uses to determine timers for tuning:

• Diameter of the STP domain (dia) – this is the value of the maximum number of bridges between any two points in a domain.  IEEE recommends a maximum diameter of 7 bridges with default timers.
• Bridge Transit Delay (transit delay) – this is the elapsed time between receiving and transmitting of the same frame by the bridge.  This is basically the latency of traffic through the bridge.  IEEE recommends to consider 1 sec as the max bridge transit delay
• BPDU transmission delay (bpdu_delay) – this is the delay between the time the BPDU is received on a port and the time the config BPDU is transmitted to another port.  IEEE recommends 1 sec as the max BPDU transmission delay
• Message Age increment overestimate (msg_overestimate) – This is the increment value each bridge adds to the message age before forwarding a BPDU.  Cisco switches add 1 second to the message age before the BPDU is forwarded.
• Lost Message (lost_msg) – This is the number of BPDUs that can be lost as it moves through the network.  IEEE recommends to us three as the number of BPDUs lost
• Transmit Halt Delay (Tx_halt_delay) – this is the max amount of time that is needed for a bridge to move a port into blocking after it’s determined that the port must be blocked.   IEEE recommends 1 sec
• Medium Access Delay (med_access_delay) – This is the value of time that is needed for a device to access media for transmission, Specifically the time between the CPU decision to send a frame and the moment the frame begins to leave the bridge.  IEEE recommends 0.5 sec

From these parameters you can calculate other values:

• End-To-End BPDU Propagation delay – This is the amount of time that is needed for a BPDU to travel across the network, assuming the diameter of 7 hops, 3 BPDUs lost, and a Hello time of 2 seconds:

  • End-to-end_BPDU_propa_delay
    = ((lost_msg + 1) x hello) + ((BPDU_Delay x (dia – 1)) 
    = ((3 + 1) x hello) + ((1 x (dia – 1)) 
    = 4 x hello + dia – 1 
    = 4 x 2 + 6 
    = 14 sec

• Message Age Overestimate – this parameter is used to account the age of the BPDU since the origination, assume each bridge increases the message age by 1 sec

  • Message_age_overestimate 
    = (dia – 1) x overestimate_per_bridge 
    = dia – 1 
    = 6

• Maximum Fram Lifetime – This value is the max time that a frame previously sent remains in the network before it reaches the destination.

  • Maximum_frame_lifetime
    = dia x transit_delay + med_access_delay 
    = dia + 0.5 
    = 7.5 
    = 8  (rounded)

• Max Transmission Halt Delay – This is the value of time that is needed for effectively blocking a port after the decision to block is made.  IEEE uses 1 sec as the max for that event:

  • Maximum_transmission_halt_delay
    = 1

Spanning Tree Protocol: Bridge Assurance

Bridge Assurance is only used with RPVST+ and MST and only on point to point links.  Bridge Assurance modifies rules for transmitting BPDUs.  When it is activated on a port the port will always send BPDUs each and every Hello interval, regardless if it is a Root, Designated, Alternate, or Backup port role.  BPDUs basically become Hello messages between pairs of connected switches.

Bridge Assurance ports are required to receive BPDUs, if none are received the port will be put into a BA-Inconsistent blocking state until the port begins receiving BPDUs again.  Bridge Assurances helps to ensure a loop free topology against loops that are introduced by malfunctioning switches when they stop participating in RPVST or MST.

Bridge Assurance can also be activated globally and applies to all the relevant forwarding port roles, the neighboring device must also be configured for Bridge Assurance as well.

Spanning Tree Protocol: Loop Guard

Loop Guard is an added logic to receiving BPDUs on Root and Alternate ports with point to point links.  These ports could move from root or Alternate to Designated possibly creating a switching loop.  Loop Guard presumes that after BPDUs are received on Root and Alternate ports, it is not possible for the ports to suddenly stop receiving BPDUs without them actually going down.  A loss of BPDUs on Root and Alternate ports means that a unidirectional link condition might be occurring.

Loop Guard prevents Root and alternate ports from becoming Designated if loss of incoming BPDUs occurs.  If this happens and the BPDUs stored on the interfaces expire, Loop Guard will put them into a Loop inconsistent blocking state, they’ll come out of this state once BPDUs begin coming in again.

Loop guard can be activated globally or on a per port basis and doesn’t require other switches to be configured with Loop Guard in order for it to work. When activated globally it automatically protects Root and Alternate Ports on STP Point to point link types.  It does not protect shared link types.

Spanning Tree Protocol: Unidirectional Link Detection

UDLD or Unidirectional Link Detection is a cisco proprietary layer 2 messaging protocol that uses echos as a mechanism between a pair of devices.  UDLD messaging allows the switch to advertise its identity and port identifier pair as the message originator, as well as a list of all switch/port pairs heard on the same segment.

UDLD can detect a unidirectional link by doing the following:

• UDLD messaging from a neighbor does not contain the exact switch/port pair matching the receiving switch and its port in the lest of detected neighbors.  this means that the neighbor does not hear this switch at all, or the neighbor’s port sending these UDLD messages is different from that neighbor’s port receiving the switch’s own UDLD messages.
• UDLD messages arriving from a neighbor have the exact same switch/port originator pair used by the receiving switch.  This means there is a self looped port.
• a switch has detected on a single neighbor but its UDLD messages contain more than on switch/port pair in the list of neighbors.  This means  that a shared media interconnection with an issue in its capability to provide full visibility between all connected devices.

Any of these symptoms will trigger UDLD and set the port into an err-disabled state.

UDLD can also sometimes manifest itself with a sudden loss of all incoming UDLD messages without the port going down.  UDLD has two modes of operations regarding sudden loss of arriving UDLD messages.

Normal mode if UDLD messages cease to be received, a switch will try to reconnect with the neighbor up to eight times, if it fails UDLD does nothing and the port will remain up.

In Aggressive mode, UDLD messages stop arriving a switch will still try to reconnect up to eight times, however if it fails it will put the port into an Err’Disabled state.

UDLD can be configured on a per port or global basis, once the port is put into an err-disable state the only way to bring it back up is to shut the port down and bring it back up or using the udld reset command in priv EXEC mode.

Spanning Tree Protocol: BPDU Guard and Root Guard

Sometimes you may want to lock down your switchports so that they don’t allow connections to other switches that could be plugged into the network.

BPDU guard is enabled per port or globally and error disables the port immediately if it receives a BPDU on the configured port.

When activated globally BPDU Guard is enabled only on PortFast ports, you can likewise disable portfast on a per port basis if you enable it globally.

Outside of the Portfast and Global BPDU Guard configuration being dependent on one another, all other configuration methods of implementation are independent of each other.

If a port is taken down into err-disabled state because of BPDU guard it will not recover from err-disabled unless you add configuration to set it back to up in a certain amount of time or by bouncing the port.

Also when spanning-tree bpdufilter enable is configured on a per port basis, this effectively stops the port from sending and receiving BPDUs all together.

Root Guard behaves the same except that instead of blocking all BPDUs it only blocks superior BPDUs, if it receives that port is put into a root-inconsistent blocking state.

Spanning Tree Protocol: Portfast

The PortFast feature is an enhancement in legacy STP and PVST+ and is standardized for RSTP and MST.  Basically it defines ports to be Edge ports.

Edge ports come online in a forwarding state and does not generate topology change events, and is not influenced by the Sync step in a Proposal/Agreement procedure.  Edge ports send BPDUs but do not listen for BPDU’s.

PortFast being applied to access ports is beneficial because it accelerates the port’s transition into forwarding state, and fixes problems with DHCP timeouts, and also prevents the port from being put into a discarding state during the proposal/agreement process.

The main thing to remember is to never enable portfast on trunk ports to other switches.

When you enable portfast on a port that connects to other switches, hubs, or routers…those connections can cause physical loops.  Spanning Tree must go through the full initialization procedure, otherwise a loop can bring the network down.  There can be a window of time when packets are continuously forwarded in such a way that the network will not be able to recover if STP is unable to process packets properly on these port types.

By enabling portfast on a trunk port you’re removing the ability of the switch to send TCN notifications to the Root in the event a trunk goes down.  You do not want to remove the ability for the network to detect a significant event by putting portfast on a trunk carrying important traffic.

Spanning Tree Protocol: MST and Non-MST interactions

In order for MST enabled devices to communicate with IEEE STP/RSTP a single MST instance is chosen for a specific port and represents all other MST regions configured on that port.  Messaging to PVST instances requires that the same port role choice is made across all VLAN STP instances on PVST devices, making the same consistent decision on what the port role will negotiate to across all PVST instances.

PVST Simulation allows for consistent operation between MST and PVST+ regions.

MST > PVST

In this direction MST chooses the IST as the representative, using IST information in all BPDUs generated out to PVST.  All PVST+ instances must receive the same IST information formatted in PVST+ BPDUs.  MST Boundary ports replicate the PVST+ BPDUs to all VLANs, this allows consistent information to be sent on all VLANs.  A PVST neighbor receiving those BPDUs on any port will make an identical consistent choice of that ports role and state for all VLANs.

PVST > MST

In this direction MST uses VLAN 1 as the representative of the entire PVST region.  MST must ensure that all VLAN 1s interaction with MST is consistent across all other VLANs.

This is where consistency citeria are listed for MSTs interaction with PVST:

• PVST+ BPDUs for all VLANs arriving at a Designated boundary port must be inferior to its own BPDUs derived from IST
• PVST+ BPDUs for VLANs other than VLAN 1 arriving at a root boundary port must be identical or superior to PVST+ BPDUs for VLAN 1

If either of these cases if the criteria for a particular port role is not met, the PVST Simulation process will declare a PVST Simulation inconsistency and will keep the port in a blocked state until the consistency criteria for the port’s role is met.

For superior BPDUs received on VLAN 1 MST will become non-designated and be put into a blocking state, there is no need to check for consistency in this instance since if all PVST VLANs declared this port to be a non-designated port, if for some reason the MST device were to declare it something different, then an PVST Simulation inconsistency event would be triggered and the port would be blocked regardless.

It is recommended when working in blended MST/PVST networks to ensure the MST switch’s IST VLAN attains root priority for all VLANs.