SWITCH Study Notes – Advanced Spanning Tree Protocol & Etherchannel

OK – So here we go! The advanced Spanning Tree Protocol. Initially it was kind of simple to keep everything in line – Portfast, Uplinkfast, Backbonefast and it was clear and then came the chaos!  BPDU Guard, Root Guard, Loop Guard, BPDU Filtering – and so on. But I held on in there and I think I’ve got the best out of the reading I could for now.

The hardest part of this chapter was the whole RSTP, PVST, PVST+ & RPVST+ business – I mean what the heck. I’ll surely have to go over these again and put together a matrix to review while working out to help me remember the differences.

Etherchannels didn’t seem tough at all – they appear to be more of a thing you have to work with and break-fix to really understand.

Chapter 5 notes.. Chris Bryant’s (@ccie12933) BCMSN study guide! Let’s go!

Advanced Spanning Tree Protocol

Portfast

• Portfast is suitable only for switch ports connected directly to a single host, Portfast allows a port running STP to go directly from blocking to forwarding mode.
  • Do not configure Portfast on a port leading to a switch, router, or other networking device.

• A Portfast-enabled port will not send TCP BPDUs when the port goes into Blocking mode.

• You must put the port into access mode (“non-trunking”) before Portfast will take effect.

• It takes a total of approximately 50 seconds to go from the blocking to forwarding state. This is a loop prevention mechanism

• An excellent real-world usage of Portfast is to allow users to get their IP addresses from a DHCP server. Using Portfast, you can minimize the time it takes hosts to receive an IP address from the server to 30 seconds (listening and learning stages of STP to run) from approximately 50 seconds.

• To configure Portfast:
  • SW1(config)#int fast 0/5
  • SW1(config-if)#spanning-tree Portfast

• Portfast can also be enabled globally:
  • SW2(config)#spanning portfast default

Uplinkfast

• Uplinkfast is the alternative to Portfast when the port you want faster convergence on is connected to a switch, router or other networking device.

• It takes a total of approximately 50 seconds to go from the blocking to forwarding state. This is a loop prevention mechanism

• Uplinkfast is best used on access layer switches.

• Ports that a switch will use to reach a root bridge are collectively referred to as an uplink group.

• The uplink group includes the ports in forwarding and blocking mode. If the forwarding port in the uplink group sees that the link has gone down, another port in the uplink group will be transitioned from blocking to forwarding immediately.

• The actual transition from blocking to forwarding isn’t really “immediate” – it actually takes 1 – 3 seconds. Next to a 50-second delay, that certainly seems immediate!

• Uplinkfast cannot be configured on a root switch.

• When Uplinkfast is enabled, it’s enabled globally and for all VLANs residing on the switch. You can’t run Uplinkfast on some ports or on a per-VLAN basis – it’s all or nothing.

• The original root port will become the root port again when it detects that its link to the root switch has come back up. This does not take place immediately.
  • The switch uses the following formula to determine how long to wait before transitioning the original root port back to the forwarding state: ( 2 x FwdDelay) + 5 seconds

• Uplinkfast will take immediate action to ensure that a switch cannot become the root switch:
  • First, the switch priority will be set to 49,152, which means that if all other switches are still at their default priority, they’d all have to go down before this switch can possibly become the root switch.
  • The STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches.

• To configure Uplinkfast
  • SW2(config)#spanning-tree uplinkfast ?
    max-update-rate Rate at which station address updates are sent

• When there is a direct link failure, dummy multicast frames are sent to the MAC destination address 01-00-0c-cd-cd-cd. The max-update-rate value determines how many of these frames will be sent in a 100-millisecond time period.

Backbonefast

• Backbonefast is Cisco-proprietary

• Backbonefast can help recover from direct link failures
  • If a core switch detects an indirect link failure – a failure of a link that is not directly connected to the core switch in question – Backbonefast goes into action.

• This indirect link failure is detected when an inferior BPDU is received.
  • What is an inferior BPDU?
    • When a switch receives BPDUs from 2 switches claiming to be the root switch. The receiving switch will compare both BPDUs and determine which switch is truly the root switch. The receiving switch will then ignore the port the inferior BPDU is coming from until the MaxAge timer (20 secs. By default) expires/hits zero, the port transitions to the listening state and will start relaying the information contained in the superior BPDU, the BPDU coming from the real root switch.

• When using Backbonefast, you don’t have to wait until the MaxAge timer reaches zero for all of this magic to happen. Typically it will take about 15 seconds (listening and learning stages of STP to run)

• BackboneFast uses the Root Link Query (RLQ) protocol. RLQ uses a series of requests and responses to detect indirect link outages.

• RLQ requests are transmitted via the ports that would normally be receiving BPDUs. The purpose of these RLQ requests is to ensure that the local switch still has connectivity to the root switch. The RLQ request identifies the bridge that is considered the root bridge, and the RLQ response will identify the root bridge that can be accessed via that port. If they’re one and the same, everything’s fine.

• Upon receiving a RLQ request, a switch will answer immediately under one of two conditions:
  • The receiving switch is indeed the root bridge named in the RLQ request
  • The receiving switch has no connectivity to the root bridge named in the RLQ request, because it considers another switch to be the root bridge
  • The receiving switch is not the root, but considers the root switch named in the RLQ request to indeed be the root switch. In that case, the RLQ request is relayed toward the root switch by sending it out the root port.
  • Every switch in the network should be configured for BackboneFast when using this feature. This feature is enabled globally, and it’s simple to configure

• To configure BackboneFast:
  • SW1#conf t
  • SW1(config)#spanning-tree backbonefast

Root Guard

• Root Guard will prevent a new switch coming onto the network from becoming the root switch.

• STP has no default behavior from preventing a switch just introduced onto the network from becoming the root switch – even if you’ve hardcoded it.
  • The “spanning-tree vlan root|secondary” command helps you determine which switches become the root and secondary root, but does nothing to disqualify a switch from becoming the root.

• Root Guard is configured at the port level, and disqualifies any switch that is downstream from that port from becoming the root or secondary root.

• Root Guard will actually block that superior BPDU, discard it, and put the port into root-inconsistent state. When those superior BPDUs stop coming, SW3 will allow that port to transition normally through the STP port states.

• Configuring Root Guard:
  • SW3(config)#int fast 0/24
  • SW3(config-if)#spanning guard root

• To determine which ports are in root-inconsistent state AKA Root Guard enabled run the command:
  • SW1#show spanning-tree inconsistentports

BPDU Guard

• BPDU prevents a port in Portfast mode from accepting BPDUs. If any BPDU comes in on a port that’s running BPDU Guard, the port will be shut down and placed into error disabled state, shown on the switch as err-disabled.

• Configuring BPDU Guard:
  • Specific port:
    • SW1(config)#int fast 0/5
    • SW1(config-if)#spanning-tree bpduguard ?
      disable Disable BPDU guard for this interface
      enable Enable BPDU guard for this interface
    • SW1(config-if)#spanning-tree bpduguard enable
  • Globally / all ports:
    • SW1(config)#spanning-tree portfast bpduguard default

• BPDU Guard can only be configured on ports already running Portfast.

PortFast BPDU Filtering

• Instead of putting a port into err-disables state when it receives a BPDU, it can take filter BPDUs. The filtering action is dependent on how you enable BPDU filtering.

• Globally enabling BPDU Filtering will have a PortFast-enabled port stop running PortFast when the port receives a BPDU.

• Enabling BPDU Filtering on a specific port or ports, rather than enabling it globally, will result in received BPDUs being quietly ignored. Those incoming BPDUs will be dropped, and the port will not send any BPDUs in return.

• To enable BPDU Filtering globally on all Portfast-enabled ports:
  • SW1(config)#spanning portfast bpdufilter ?
    default Enable bdpu filter by default on all portfast ports
  • SW1(config)#spanning portfast bpdufilter default

• To enable BPDU Filtering on a specific port:
  • SW1(config)#int fast 0/5
  • SW1(config-if)#spanning-tree bpdufilter enable

• To verify global configuration of BPDU Filtering:
  • SW1#show spanning-tree summary totals
    <output omitted>
    Portfast BPDU Filter Default is enabled

• To verify configuration of BPDU Filtering on a specific port:
  • SW2#show spanning-tree interface fast0/5 detail
    <output omitted>
    The port is in the portfast mode
    Bpdu filter is enabled by default

Unidirectional Link Detection (UDLD)

• Runs on fiber optic interfaces

• Must be enabled on both involved ports/switches

• Uses a method similar to PING – almost like a Layer 2 PING.
  • A UDLD frame is sent and if a UDLD frame is received in return, there is a bidirectional link.
  • If a UDLD frame is not received, the link is considered unidirectional

• UDLD operates in two modes:
  • Normal: When a unidirectional link is detected, UDLD generates a syslog message but does not shut the port down.
  • Aggressive: the port will be put into error disabled state (err-disabled) after 8 UDLD messages receive no echo from the remote switch?
    • UDLD messages are sent 1 per second when a potential unidirectional link is found.
    • UDLD aggressive mode does not begin until the first it hears it’s first UDLD response from the other switch.

• Can be enabled globally or on a per-port level
  • Globally means it will run on all fiber optic interfaces
    • SW2(config)#udld enable
  • Per-port
    • SW1(config)#int fast 0/11
    • SW1(config-if)#udld ?
      port Enable UDLD protocol on this interface
    • SW1(config-if)#udld port ?
      aggressive Enable UDLD protocol in aggressive mode on this interface
      <cr>

Duplex Mismatches And Switching Loops

• When changing duplex settings on one switch, be sure to change the duplex on the trunking partner switch as well.

• Duplex mismatches are not unidirectional links, but they can lead to switching loops cause by CSMA/CD

• Full duplex ports do not perform CSMA/CD, but half duplex ports will.
  • Half-duplex will listen to the segment for traffic and transmit if it hears nothing.
  • Full-duplex ports sends frames without listening
  • The half-duplex port invokes its random timer and listens to the segment again before trying to send again – this includes BPDU packets.
  • Due to the nature of CSMA/CD, the half-duplex port will be unable to send any packets including BPDUs which may be needed by other switches in order to prevent switching loops.

Loop Guard

• Prevents a blocking port facing another switch from going into forwarding during a unidirectional link issue between the 2 switches.

• During unidirectional link issues, loop guard will transition the port from blocking to loop-inconsisent (still in blocking mode).

• Once the unidirectional link issue is cleared up and SW3 begins to receive

• BPDUs again, the port will come out of loop-inconsistent state and will be treated as an STP port would normally be.

• To configure loop guard
  • Per-port
    • SW2(config-if)#int fast 0/5
    • SW2(config-if)#spanning-tree guard loop
  • Globally
    • SW1(config)#spanning-tree loopguard default

BPDU Skew Detection

• Detects BPDUs that aren’t being relayed as quickly as they should be.

• Sends a syslog message when it detects that BPDUs are not being relayed fast enough
  • The message includes the amount of time between when the BPDU should have arrived and when it did arrive – this is the skew time or BPDU latency.

• Syslog messages are sent every 60 seconds (1 minute) unless “skew time” is modified to critical level setting detection. This level of detection will force a syslog message on each event and eliminate the one-per-minute limit.

• Critical level setting to BPDU Skew means any value greater than ½ of the MaxAge – 10 seconds or greater

• No STP recalculation takes place – this is just a notification mechanism

Rapid Spanning Tree Protocol (RSTP)

• RSTP has Uplinkfast, Portfast and Backbonefast embedded into it by design.

• Defined by IEEE 802.1w, and is considered an extension of 802.1d.

• The difference between STP and RSTP is the port states
  • STP: disabled > blocking > listening > learning > forwarding
  • RSTP: discarding > learning > forwarding
    • disabled > blocking > listening = discarding in RSTP – when transitioning to learning, frames are still discarded, but MACs are being learned

• RSTP elects a Designated Port much like STP does – the best root path cost.

• RSTP doesn’t use the same terminology for blocked ports like STP does – RSTP calls these ports alternate ports.

• A switch running RSTP with 2 separate ports leading to the same physical segment will have a designated port like STP and a backup (BCK) port for redundancy, but doest guarantee the root switch will be accessible.

• Edge port is a port on the edge of the network – usually where a host/pc will plug into. Operated just like an STP port running Portfast
  • RSTP does not consider a Topology change when a Edge port goes into forwarding. This is because a (likely) host plugging in does not change the topology.

• Point-to-point port is any port connected to another switch and is running in full duplex

• Edge ports go into Forwarding state immediately.

• If an Edge port receives a BPDU, it will transition into a normal spanning tree port.

• RSTP-enabled switches generate and send a BPDU every two seconds. In STP only the root bridges is sending BPDUs and non-root bridges forward them.
  • This enhancement increases the effectiveness to detect link failures – each switch expects BPDUs from its neighbor every 2 seconds.
    • When 3 BPDUs are missed (6 seconds) the link is considered down. All information regarding that port is aged out and the STP recalculation process begins

• STP’s error detection takes 20 seconds (MaxAge timer expiration)

• STP and RSTP use the same BPDU format, but RSTP uses all flag bits available whereas STP uses only the Topology Change and Topology Change Ack Flags.

Per-VLAN Spanning Tree PVST And PVST+

• Allows a separate STP instance for each VLAN

• Both are Cisco proprietary

• PVST
  • PVST allows for better fine-tuning than STP
  • PVST requires much more memory and CPU resources from your switch
  • Can only run over Cisco proprietary ISL trunking protocol.

• PVST+
  • Same functionality as PVST but improved by enabling the use over dot1q vs ISL
  • Can serve as an intermediary and enable communication between groups of PVST and CST switches
  • Allows per-VLAN load balancing
  • Enables every VLAN to have its own instance of STP running

Rapid Per-VLAN Spanning Tree Plus (RPVST +) And PVST+

• RPVST+ is a switch running PVST+ and RSTP combined

• To enable RPVST+ :
  • SW1(config)#spanning-tree mode rapid-pvst
    • Enabling will restart all STP processes

• To confirm RPVST+
  • SW1#show spanning-tree vlan 1
    VLAN0001
    Spanning tree enabled protocol rstp
    <output omitted>
    Fa0/18       Altn       BLK 19    128.18     P2p    Peer(STP)

Common Spanning Tree & Multiple Spanning Tree – CST and MST

• The interoperability of MST and CST is that
  • CST will cover the entire network
  • MST is a “subset” of the network.
  • CST is going to maintain a loop-free network only with the links connecting the MST network subnets
  • It’s MST’s job to keep a loopfree topology in the MST region
    • The Internal Spanning Tree (IST) in each region is responsible for keeping communications in the MST Region loop-free
  • CST doesn’t know what’s going on inside the region, and it doesn’t want to know.

• CST
  • When dot1q is in use, CST is in use.
    • All VLANs are using a single instance of STP with dot1q is in use.

• MST
  • Defined in 8021.s
  • Allows multiple VLANs to be mapped to a single instance of STP instead of having an single instance of STP for every VLAN in the network
    • The purpose of MST is to map multiple VLANs to a lesser number of STP instances.
  • MST serves as a middle ground between STP and PVST
  • MST was designed with enterprise networks in mind
  • MST switches are logically dived into regions. Switches in their respective region must agree on:
    • Configuration name
    • Instance-to-VLAN mapping table
    • Configuration revision number

• If any of these values do not match between switches, they will be in different regions
  • Switches send MST BPDUs that contain the configuration name, revision number, and a digest value derived from the mapping table.

• Up to 16 MST instances (MSTIs) can exist in a region, numbered 0 through 15.
  • MSTI 0 is reserved for the IST instance, and only the IST is going to send MST BPDUs.
  • There is not VTP for MST, therefore; each MST switch must be manually configured
    • VLAN mappings in MST must be configures on every switch in the network, they are not automatically advertised.

• Enable MST on the switch:
  • SW2(config)# spanning-tree mode mst

• Configure the name and revision number:
  • SW2(config)# spanning-tree mode mst configuration
  • SW2(config-mst)# name REGION1
  • SW2(config-mst)# revision 1

• To map VLANs to a particular MST instance:
  • SW2(config-mst)# instance 1 10,13, 14-20

• Combination of hyphens and commas can be used to identify VLANs. By default all VLANs will be mapped

STP vs PVST

• Why Does Anyone Run STP Instead Of PVST? Take the below as an example
  • STP: 100 VLANs results in one STP process
  • PVST: 100 VLANs results in 100 STP processes, allowing for greater flexibility with trunk usage (per-VLAN load balancing)

• PVST is resource intensive and must be a concern before deciding to deploy PVST

• Some switches run PVST by default – a clear sign that PVST is OK to run by default. You should keep in mind though that as the network grows, the resource hit will become larger as well.

Etherchannels

• An Etherchannel is the logical bundling/aggregation of 2-8 parallel Ethernet trunks.
  • Provides greater throughput
  • Redundancy – no cease in traffic if a link fails
  • Minimizes wait times between blocking -> forwarding states during link failure

• STP considers an Etherchannel to be one link.

• STP does not recalculate when a port in a Etherchannel fails.

• Etherchannels use the Exclusive OR (XOR) algorithm to determine which channel in the EC to use to transmit data to the remote switch.

• Link Aggregation Control Protocol (LACP)
  • Defined in 802.3ad
  • Industry standard bundling protocol
  • LACP assigns a priority value to each port that has etherchannel capability
  • Up to 16 ports to belong to an LACP-negotiated etherchannel, but only the eight ports with the lowest port priority will be bundled.
    • The other ports will be bundled only if one or more of the bundled ports fails.

• Port Aggregation Protocol (PAgP)
  • Cisco proprietary
  • PAgP packets are sent between Cisco switches via ports that have the capacity to be placed into an etherchannel.
  • PAgP packets check the capabilities of the remote ports against those of the local switch ports.
  • The remote ports are checked for two important values:
    • The remote port group number must match the number configured on the local switch
    • The device ID of all remote ports must be the same – if the remote ports are on separate switches, that would defeat the purpose of configuring an Etherchannel

• PAgP also has the capability of changing a characteristic of the Etherchannel if one of the ports in the etherchannel is changed.
  • If you change the speed of one of the ports in an etherchannel, PAgP will allow the etherchannel to dynamically adapt to this change.

• PAgP and LACP use different terminology to express the same modes.
  • SW1(config-if)#channel-group 1 mode ?
    active Enable LACP unconditionally
    auto Enable PAgP only if a PAgP device is detected
    desirable Enable PAgP unconditionally
    on Enable Etherchannel only
    passive Enable LACP only if a LACP device is detected

• “Active” and desireable” will allow the local port to initiate the Etherchannel
• “Auto” and “passive” if the remote port is going to initiate the Etherchannel
• “On” to enable the Etherchannel with no negotiation
• For an EC to form, LACP must have at least one of the two ports on each physical link set for “active”; if both ports are set to “passive”, no EC will be built. The same can be said for PAgP and the settings “auto” and “desirable” – if both ports are set to auto, the link won’t join the EC.

• Configuring Etherchannels

• To select a particular negotiation protocol, use the channel-protocol command.
  • SW1(config-if)#channel-protocol ?
    lacp Prepare interface for LACP protocol
    pagp Prepare interface for PAgP protocol

• The channel-group command is used to place a port into an etherchannel.
  • SW1(config-if)#channel-group 1 mode ?

• To verify both PAgP and LACP neighbors, you can use the “show pagp neighbor” and “show lacp neighbor” commands

• Etherchannels can be of layer 2 or layer 3 types – you can assign an IP address to a layer 3 etherchannel

Troubleshooting EtherChannels

• Changing the VLAN assignment mode to dynamic. Ports configured for dynamic VLAN assignment from a VMPS cannot remain or become part of an EC.
• The allowed range of VLANs for the EC must match that of the ports.
  02:46:10: %EC-5-CANNOT_BUNDLE2: Fa0/12 is not compatible with Fa0/11 and will be suspended (vlan mask is different)
• Changing a port attribute. Ports need to be running the same speed, duplex, native VLAN, and just about any other value

Any corrections or additions are greatly appreciated! You can download a copy of these notes by clicking the “Printer Friendly” below.

Cheers!

@LBSources