Spanning Tree Protocol (STP) is designed to preven problems - TopicsExpress



          

Spanning Tree Protocol (STP) is designed to preven problems related to bridging loops. STP solves the problem by blocking redundant paths and allowing single active path. Spanning tree works by selecting a root switch the selecting a loop-free path from the root switch to other switch. To do that, spanning tree must choo single root bridge, one root port for each nonroot and a single designated port for each network seg Several different versions of Spanning Tree have b introduced over the years. Here are a few: Common Spanning Tree (CST) IEEE 802.1D, One instance of spanning tree runs for the entire switc network resulting in low CPU requirements, but suboptimal traffic paths when multiple VLANs are It is also slow to converge. Per VLAN Spanning Tree Plus (PVST+) One instan STP per VLAN, more resources required, slow convergence still, includes portfast, BPDU guard, B filter, Root Guard, and Loop Guard. Rapid STP (RSTP) IEEE 802.1w, One instance of ST very fast convergence time. Still suboptimal traffic because only a single instance for the entire switc network. Multiple Spanning Tree (MST) An IEEE standard t allows you to map multiple VLANS with similar traf requirements into the same spanning-tree instanc also supports RSTP for fast convergence. Each inst supports Portfast, BPDU guard, BPDU filter, Root G and Loop Guard. PVRST+ A Cisco enhancement to RSTP that behave similar to PVST+. It supports a separate instance o for each VLAN and each instance supports Portfast guard, BPDU filter, Root Guard, and Loop Guard. option has the largest CPU and memory requirem Note: MST and PVRST+ have become the dominate spanning-tree protocols of choice and in Cisco swit PVST+ is the default flavor of STP that is enabled VLAN is created. STP Path Selection Spanning tree builds the tree structure attempting the fastest links it has available for the active path uses the following steps to select its paths: 1. Lowest root bridge ID (BID) 2. Lowest path cost to the root 3. Lowest sender bridge ID 4. Lowest sender port ID (PID) STP Definitions Bridge ID – bridge priority + MAC Address Bridge Priority – 0-65,535 Default Priority – 32,768 Port ID – port priority + port number Port Priority – 0-240 (default is 128, increments o Path Cost – The cumulative cost of all links betwe switch and the root bridge STP Convergence 1. Root bridge election Each VLAN elects one root bridge. All ports on the bridge act as designated ports, which send and receive traffic as well as BPDUs. The bridge w lowest priority becomes root. 2. Root ports are determined on all non-root bri Each non-root bridge is assigned a single root port sends and receives traffic. The root port is chosen on the port with the lowest-cost path between the root bridge and the root bridge. If two paths are cost, the port with the lowest port ID (priority + po number) will win. 3. Designated port selection Each segment has a single designated port. Design ports are chosen from non-root ports that have th lowest path cost to the root bridge. In the event the bridge ID acts as a tiebreaker (lowest wins). A on a root bridge are designated ports. STP Port Roles Root port On non-root bridges only Forwards traffic towards the root bridge Only one per switch Can populate the MAC table Designated port On root and non-root bridges All ports on root bridge are designated ports Receives and forwards frames towards the r bridge as needed Only one per segment Can populate the MAC table Nondesignated port Does not forward packets (blocking) Does not populate the MAC table Disabled port A port that is shut down Blocking In nondesignated status and does not forward Receives BPDUs to determine root switch Default 20 seconds in this state (max age) Listening Receives and sends BPDUs 15 seconds (forward delay) Learning Populates the CAM table 15 seconds (forward delay) Forwarding Part of the active topology Forwards frames Sends and receives BPDUs Disabled Does not participate in STP Does not forward frames STP Path Cost Spanning-tree uses a link cost calculation to deter the the root ports on non-root switches. It is calc by adding the costs of all links between the root b and the local switch. 10 Gbps = Cost 2 1 Gbps = Cost 4 100 Mbps = Cost 19 10 Mbps = Cost 100 Rapid Spanning Tree Rapid Spanning Tree Protocol (IEEE 802.1w) was introduced to dramatically speed up STP’s converg when network changes occur. RSTP can revert to 8 (common spanning-tree) to inter-operate with lega bridges on a per-port basis. A rapid version of PVS RPVST+ is a per-VLAN implementation of rapid spa tree. RSTP Port States Discarding Merges the former disabled, blocking, and liste states Prevents the forwarding of frames Seen in both stable/active and synchronization changes Learning Receives frames to populate the MAC table Seen in both stable/active and synchronization changes Forwarding Forwarding ports determine the active topology An agreement process between switches occurs before frames can be forwarded Only seen in stable/active topologies Note: In every RSTP port state, BPDU frames are accepted and processed. Switch A(config-if)# interface fa 0/2 Switch A(config-if)# spanningtree vlan 11-20 port p 20 Switch A(config-if)# switchport mode trunk In this example, VLANs 1-10 would traverse the lef (priority of 20 is less than default of 32)and use th link as a backup only, while VLANs 11-20 would pr the right uplink and use the left link as a backup o This way both uplinks are being used, but only on each VLAN. Make sure you understand how this w because this is a very common implementation de PortFast Spanning Tree Portfast causes layer 2 switch interf enter forwarding state immediately, bypassing the listening and learning states. It should be used on connected directly to end hosts like servers or workstations. Note: If portfast isn’t enabled, DHCP timeouts can occur while STP converges, causing m problems. To configure PortFast: Switch# conf t Switch (config)# int fa 3/1 Switch (config-if)# [no] spanning-tree portfast To verify PortFast on an interface: Switch# sh spanning-tree int fa 3/1 portfast PortFast can be configured globally on an access s for all interfaces to save configuration time. Also, applies to access interfaces, not trunks. Use the spanning-tree portfast trunk command if it is required on a trunk. If you do so, make sure to d it explicitly on uplink interfaces. To configure PortFast globally: Switch# spanning-tree portfast default Switchport Mode Host To configure PortFast and disable both channeling trunking negotiation on an interface: Switch (config-if)# switchport host RPVST+ Configuration 1. Enable RPVST+ globally on all switches Switch (config)#spanning-tree mode rapid-pvst 2. Designate and configire a primary root brigde S (config)#spanning-tree vlan 2 root primary 3. Designate and configire a secondary root brigde Switch(config)#spanning-tree vlan 2 root secondar 4. Verify the configuration Switch#show spanning- vlan 2 Multiple Spanning Tree MST, or 802.1s, expands upon the IEEE 802.1w RS algorithm in an attempt to reduce the number of instances, thus reducing the required CPU cycles o switch. MST enables you to group VLANs and asso them with spanning tree instances. Each instance’ topology can be independent of the rest, allowing to be grouped and load balanced for fault toleranc measures. MST is also backwards compatible with older STP variations. Switches participating in MST that have the same configuration information are referred to as a regi Switches with different MST configurations or that running legacy 802.1D are considered separate MS regions. Note: Switches in the same MST region must have exact same MST configuration to work properly (in revision number). MST is usually not implemented in campus environ because if you follow the local VLAN model (recommended by Cisco), there should not be that VLANs on any given switch because they should on extend to the switch block boundary. That makes a better choice because of it’s simpler configuration. Because MST is still often deployed, definitely still considers it an important topic on th SWITCH exam. Multiple Spanning Tree Regions Each switch that runs MST in the network has a si MST configuration consisting of the following 3 ite Configuration name (alphanumeric) Configuration revision number A 4096-element table that associates each VLA given instance The default MST instance is for all VLANs is MS MST Configuration MST must be manually configured on each particip switch. Apply the following configurations on each that runs MST: Enable MST globally: Switch(config)# spanning-tree mode mst Enter MST Submode: Switch(config)# spanning-tree mst configuration Switch(config-mst)# sh current 1. Define a configuration name: Switch(config-mst)# name XYZ 2. Set the MST revision number: Switch(config-mst)# revision 1 3. Map the VLANs to an MST instance: Switch(config-mst)# instance 1 vlan 3, 5, 7 Switch(config-mst)# instance 2 vlan 2, 4, 6 Display configuration to be applied: Switch(config-mst)# show pending Note: This step is important because without it, y be unable to verify the configuration. Display current running MST configuration : Switch(config-mst)# show current Apply the configuration: Switch(config-mst)# end Cancel the configuration: Switch(config-mst)# abort Assign an MST root bridge: Switch(config)# spanning-tree mst 2 root primary Verification Commands Switch# show spanning-tree mst Switch# show spanning- tree mst 1 (to view MST info for a single instance) Switch# show spanning-tree mst 1 detail Switch# show spanning-tree mst interface fa 0/3 Spanning Tree Enhancements BPDU Guard Prevents problems related to switches accidentally connected to PortFast-enabled ports. Bridging loo would normally instantly occur. It places the port i disable state if it receives a BPDU - disabling the interface. To enable BPDU Guard globally on the switch: Switch(config)# spanning- tree portfast edge bpduguard default To enable BPDU Guard at the interface level: Switch(config)# spanning-tree bpduguard enable BPDU Filtering Prevents BPDUs from being transmitted from PortF enabled interfaces. When enabled globally on the switch: Configures all PortFast ports for BPDU filtering If BPDUs are seen, the port looses its PortFast BPDU filtering is disabled, and STP resumes def operation on the port When the port comes up, it sends 10 BPDUs, if hears any BPDUs during that time PortFast and filtering are disabled When applied to an individual port: It ignores all BPDUs it receives It does not transmit BPDUs Because it ignores incoming BPDUs, this can lea bridging loop scenarios Note: If you enable BPDU Guard and BPDU filteri the same interface, BPDU Guard has no effect bec BPDU filtering has precedence over BPDU Guard. To enable BPDU filtering globally on the switch: Switch(config)# spanning-tree portfast bpdufilter d To enable BPDU filtering at the interface level: Switch(config)# spanning-tree bpdufilter enable To verify: Switch# show spanning-tree summary OR Switch# show spanning-tree interface fa 0/3 detail Root Guard Root guard was developed to control where root b can be located within the network. Switches learn and elect root bridges based on BPDUs they receiv a new switch is added to the environment with a l bridge priority than the current root bridge, the n switch will become root – and in turn disrupt your carefully planned traffic patterns. To prevent this occurring, root guard can be applied to interface root bridge should never been seen. When root guard is applied to an interface, it forc port to essentially always remain a designated inte never allowing it to transition to a root port. If a r guard-enabled port received a superior BPDU, it immediately moves the port to a root-inconsistent STP state (essentially the same as the listening state) a does not forward any traffic out that port. When the root guard protected port stops receivin superior BPDUs, it automatically unblocks the port proceeds through its normal listening, learning, an eventually forwarding states. No intervention is re To enable root guard on an interface: Switch(config)# int fa 4/4 Switch(config-if)# spanning-tree guard root Loop Guard Most bridging loops that occur when STP is active when a port in blocking state stops receiving BPDU the interface and therefore transition the port to forwarding state – creating an all-ports-forwarding It blocks ports on a per-VLAN basis, so on trunks it only block that VLAN – not the whole trunk. Loop guard should be applied to all non-desgnate (ex. root, alternate). To enable loop guard on an interface: Switch(config)# int fa 4/4 Switch(config-if)# spanning-tree guard loop To enable loop guard globally on the switch: Switch(config)# spanning-tree loopguard default To verify: Switch# show spanning-tree interface fa 0/3 detail UDLD UDLD is another loop-prevention mechanism for S tries to discover unidirectional links before they gr bridging loops. This situation is much more comm fiber optic networks where there is a physical Rx/T and a situation can arrise where one is not functio correctly. STP relies on constant and consistant reception of messages. If a switch stops receiving BPDUs on a designated (upstream) port, STP ages out the infor for the port and transistiones it into forwarding sta This will lead to a loop. UDLD sends UDLD protocol packets to its neighbor – 15 seconds is the default. The neighbor is then expected to echo packet the packets before a time expires. If the switch does not hear a reply it wait before finally shutting down the port. There are two UDLD modes: Norma l UDLD simply places the port into an undetermined state if it stops hearing responses fr directly-connected neighbor Aggressive (Preferred) Tries to re-establish the connection up to 8 times, then puts the port in err disable state (essentially shutting down the port) Note: UDLD is enabled by default on all Ethernet optic interfaces. To enable UDLD on an interface: Switch(config)# int fa 4/4 Switch(config-if)# udld port {aggressive} To enable UDLD globally on all fiber ports: Switch(config)# udld {enable | aggressive} Note: While both loop guard and aggressive UDLD many overlapping functions, enabling both provide best protection. Flex Links Flex links is a layer 2 solution that allows you to di STP at the access layer, while maintaining link redundancy and loop avoidance. Flex links allow a convergence time of less than 50 milliseconds (sup fast). Flex links work by combining a pair of links on a co access switch. One link is active, while the other a a backup if the other link fails for any reason. Th interfaces can be physical ports or EtherChannel b Some more details: A single backup port is allowed per active port they must both be on the same switch or stack The active and backup links can be dissimilar t and work just fine (ex. fasteth/gig, gig/ethercha etc..) STP is always disabled on Flex links The configuration is done exclusively on the “active” interface with the following command: Switch(config)# int fa 4/4 Switch(config-if)# switchport backup interface fa 5 To verify: Switch# sh int switchport backup Spanning Tree Best Practices Something to consider with spanning tree is th of multipathing options. STP eliminates loops b creating a tree structure where a single link is c to each switch. This means that even with all t redundant links you put in place, STP will alway allow one – reducing much of your available bandwidth.Because of this and other limitation recommended to use layer 3 at both the distri and core layers. Using layer 3 between the distribution and core allows you to use multipa (up to 16 paths) using Equal-Cost Multipathing without the dependency of STP. Also, be awar the new Nexus 7ks allow layer 2 multipathing two links using virtual port channels. Because a 50 second network convergence dela usually not acceptable in modern networks, RS preferred. STP should absolutely be used on the network to prevent user/wiring errors from propagating throughout the network. A root bridge should be manually assigned in e STP topology. If using PVST+ or RPVST+, assign a root bridge f VLAN using the command: #spanning-tree vlan ID root . If using HSRP, make sure the STP root bridge a HSRP active router are assigned to the same d possible. Use the STP Enhancements (sometimes referre the STP toolkit) to optimize the topology Loop guard - Implement on layer 2 uplink port between access and distribution layer Root guard - Implement on distribution switch facing the access ports UplinkFast- Implement on uplink ports from ac distribution switches BPDU guard or root guard- Implement on acce ports connected to end devices, as is PortFast UDLD -Sometimes implemented on fiber ports between switches Troubleshooting Spanning Tree Duplex Mismatch If one side of a link is set to ha duplex and the other is set to full, then the potent exists that the full duplex side will begin sending l traffic to the half duplex interface. If that happen half duplex interface will experience collisions whe attempts to transmit STP BPDUs. The full duplex interface will therefore never receive them, and as other interfaces on the switch in blocking state ca transfer to a forwarding state – creating a loop. Unidirectional link failure This occurs when a ha failure causes a normally two-way link to become way link. The potential loop problem is the same the duplex mismatch issue, with one side moving f blocking to forwarding because they stop receiving superior BPDUs on the interface. Aggressive UDLD can prevent loops from forming this occurs by putting the offending port into err-d state. Cisco recommends using agressive UDLD on point-point links in a switched environment. Frame Corruption This is a very uncommon cause loops, but it exists when errors on an interface do allow BPDU frames from being received. Again, a moves from blocking to forwarding because they st receiving superior BPDUs on the interface. This cou caused by a duplex mismatch, bad cable, or incorr cable length. Resource Errors If for any reason the CPU of a s over-utilized, there exists the possibility that it will unable to send out BPDUs. STP is generally not ve resource intensive, but be careful when running P PortFast-related Errors PortFast interfaces move into forwarding state, so if a hub or switch gets connected to an edge port configured with PortFas loop will form. BPDU Guard can prevent this cond General STP Troubleshooting Methodology 1. Develop a plan. 2. Isolate the cause and correct an STP problem. 3. Document findings. Develop a plan In order to make a plan, you mus the following parts of the network: The switched topology The location of the root bridge The location of blocking ports Correct the problem The best way to determine is to capture packets on a saturated link and look f duplicate packets. Another option is to look for abnormally high interface utilization values. Some common symptoms include HSRP may complain of duplicate IP addresses, consistent flapping of MAC because MAC addresses should not flap. Restore connectivity Most of the time administra not have the luxury of time to identify the root ca a loop, instead they must stop it as quickly as pos Here are some options: Disable every port that is providing redundanc starting with areas of the network more affecte to disable ports you know should be in blockin if possible. If it is difficult to pin down, increase the level logging on the switches. The loops form when moves into forwarding state, so it can latter be identified. Try this: Switch# debug spanning-tree events To log the events: Switch(config)# logging buffered Check Port Statuses Start with blocking ports firs here are some more guidelines: Make sure both root and blocking ports are rec BPDUs Switch# sh spanning-tree vlan ID detail (enter multiple times to see if the number is increasin Look for duplex mismatch errors using the sho interface command Check port utilization with the show interface command. Look at the load, input/ou values for abnormally high rates. Look for an increase of input error fields using the show interface command. Check for resource errors Resource Errors Use the show process cpu com check whether the CPU utilization is nearing 100%. Disable Unnecessary Features Sometimes it bec easier to identify a solution when the network is simplified. Try disabling unnecessary features to r complexity. Save the configuration before making changes so it can be restored after the issue is res Document Findings It is important to document b your findings and any changes to the network afte dust clears. Current and detailed documentation reduces troubleshooting time in the future.
Posted on: Sat, 14 Sep 2013 06:02:44 +0000

Trending Topics



Recently Viewed Topics




© 2015