Using Redundant Links with STP
Fast EtherChannel and Gigabit EtherChannel allow high-speed redundant links in a spanning tree environment by allowing dual parallel links to be treated as though they were one link. Cisco Fast EtherChannel technology uses the standards-based 802.3 Full-Duplex Fast Ethernet to provide a reliable high-speed solution for the campus network backbone. Fast EtherChannel can scale bandwidth within the campus, providing full-duplex bandwidth at wire speeds of 200Mbps to 800Mbps. It provides high bandwidth, load sharing, and redundancy of links in a switched internetwork.
Broadcast traffic, as well as unicast and multicast traffic, is distributed equally across the links in the channel. Fast EtherChannel also provides redundancy in the event of a link failure. If a link is lost in a Fast EtherChannel network, traffic is rerouted to one of the other links in just a few milliseconds, making the convergence transparent to the user.
Gigabit EtherChannel works in the same fashion that Fast EtherChannel does, except that it's faster. Each device has a limit to the number of ports that can participate but it's in the range of 2 to 8, giving a potential channel size of 16Gbps.
This section will introduce you to the several ways of configuring redundant links. In the part about EtherChannel, you'll learn about the communication protocol that switches use and how load balancing takes place. You will then learn how the switch can violate the usual rules that spanning tree lives by, to create a network that responds faster when there is a problem.
 |
EtherChannel has undergone some changes in the last four years on Cisco switches. It used to be that you had to group the ports together in order to use them in a channel. Ports 1-4 had to be used together, 5-8 had to be used together, and so on. If you were using only two, then they had to be the first two ports in the group of four. Of course, they all had to be on the same blade as well. The first thing an administrator would do when troubleshooting was to make sure the correct ports were being used.
The restrictions aren't quite as difficult now, though. A CatOS version 5.3 or higher system enables you to use whatever ports you want to, as long as they are configured the same.
Different devices will also forward frames across the channel in different ways, and some can be set up to apply rules based on layer 3 or layer 4 headers. The secret to setting up an effective EtherChannel topology is to understand the limitations of your equipment and software.
|
Parallel Fast EtherChannel Links
Fast EtherChannel uses load distribution to share the links in a bundle. A bundle is a group of FastEthernet or Gigabit Ethernet links managed by the Fast EtherChannel process. Should one link in the bundle fail, the Ethernet Bundle Controller (EBC) informs the Enhanced Address Recognition Logic (EARL) ASIC of the failure, and the EARL in turn ages out all addresses learned on that link. The EBC and the EARL use hardware to recalculate the source and destination address pair on a different link.
The convergence time is sometimes referred to as the failover time, which is the time it takes for the new address to be relearned-about 10 microseconds. Windowing flow control techniques can make this process a touch longer, but that depends on the particular application in use. The key is not having the application time out, and the failover time is fast enough to stop the time-out from happening.
EtherChannel Guidelines
EtherChannel does not work under certain circumstances. This is to ensure that no network loops will occur if the bundle comes up. There are certain guidelines to follow when configuring EtherChannel technology:
-
All ports must be in the same VLAN or they must all be trunk ports that belong to the same native VLAN.
-
All ports must be configured as the same trunk mode if trunking is used.
-
When trunking is used, all ports must be configured with the same VLAN range. If it is not the same, packets will be dropped and the ports will not form a channel when set to the auto or desirable mode.
-
All ports must be configured with the same speed and duplex settings.
-
If broadcast limits are configured on the ports, configure the limits for all the ports or packets might be dropped.
-
The ports can not be configured in a channel as dynamic VLAN ports.
-
Port security must be disabled on channeled ports.
-
All ports must be enabled in the channel before the channel can come up. If you disable a port, a link failure occurs.
Configuring EtherChannel
To create an EtherChannel bundle, use the set port channel command. You must first make sure that all the conditions for EtherChannel have been met.
Notice the switch output when we try to configure the ports on our 4000 switch as a bundle to the 2950 switch:
Terry_4000> (enable) set port channel 1/1-2 on Mismatch in trunk mode. Mismatch in port duplex. Mismatch in STP port priority. Failed to set port(s) 1/1-2 channel mode to on. Terry_4000> (enable)
There is a mismatch in trunking, duplex, and STP port priority. All the ports must be configured the same for EtherChannel to work.
To view the configuration of a port, use the show port capabilities slot/port command:
Terry_4000> (enable) show port capabilities 1/1 Model WS-X5509 Port 1/1 Type 100BaseTX Speed 100 Duplex half,full Trunk encap type ISL Trunk mode on,off,desirable,auto,nonegotiate Channel 1/1-2 Broadcast suppression percentage(0-100) Flow control no Security yes Membership static,dynamic Fast start yes Rewrite no Terry_4000> (enable)
The preceding output shows the card model number and the configuration of the port. The easiest way for us to make sure all the ports we want to channel are configured the same is to just clear the configuration. We're not suggesting that you just clear your config whenever any problems come up, but the configuration we created in this chapter is pretty extensive, and it's easier to simply clear it out of the switch to perform the next function:
Terry_4000> (enable) clear config all This command will clear all configuration in NVRAM. This command will cause ifIndex to be reassigned on the next system startup. Do you want to continue (y/n) [n]? y …….. …………….. System configuration cleared. Console> (enable)
Remember that you need to reset the switch after erasing the configuration to clear the configuration. We need to reconfigure the switch with an IP address and trunking on ports 1/1 and 1/2. We're also going to delete the configuration on the 2950, so then we will have both switches back to our STP default:
Terry_2950#erase startup-config Erasing the nvram filesystem will remove all files! Continue? [confirm]
Now that we have both the switches back to their default configurations, we'll just configure the hostnames and IP addresses and turn on trunking on ports 1/1 and 1/2 of the 4000 and ports fa0/1 and fa0/24 of the 2950:
#configure terminal (config)#hostname Terry_2950 Terry_2950(config)#int vlan 1 Terry_2950(config-if)#ip address 172.16.10.2 255.255.255.0 Terry_2950(config-if)#ip default-gateway 172.16.10.1 Terry_2950(config)#int fa 0/1 Terry_2950(config-if)#switchport ? access Set access mode characteristics of the interface host Set port host mode Set trunking mode of the interface nonegotiate Device will not engage in negotiation protocol on this interface port-security Security related command priority Set appliance 802.1p priority protected Configure an interface to be a protected port trunk Set trunking characteristics of the interface voice Voice appliance attributes Terry_2950(config-if)#switchport mode trunk Terry_2950(config-if)#int fa 0/24 Terry_2950(config-if)#switchport mode trunk Terry_2950(config-if)#^Z Console> (enable) set prompt Terry_4000> Terry_4000> (enable) set interface sc0 172.16.10.4 255.255.255.0 Interface sc0 IP address and netmask set. Terry_4000> (enable) set trunk 1/1 on Port(s) 1/1 trunk mode set to on. Terry_4000> (enable) set trunk 1/2 on Port(s) 1/2 trunk mode set to on. Terry_4000> (enable)
To verify that the ports are trunking, use the show trunk command:
Terry_4000> (enable) show trunk Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ---------- ----------- 1/1 on isl trunking 1 1/2 on isl trunking 1
Let's try to configure EtherChannel between the switches again:
Terry_4000> (enable) set port channel 1/1-2 on Port(s) 1/1-2 channel mode set to on. Terry_4000> (enable) 2003 Jul 25 23:08:20 %PAGP-5 PORTFROMSTP:Port 1/1 left bridge port 1/1 2003 Jul 25 23:08:20 %PAGP-5-PORTFROMSTP:Port 1/2 left bridge port 1/2 2003 Jul 25 23:08:20 %PAGP-5-PORTTOSTP:Port 1/1 joined bridge port 1/1-2 2003 Jul 25 23:08:21 %PAGP-5-PORTTOSTP:Port 1/2 joined bridge port 1/1-2
To verify the EtherChannel bundle, use the show port channel command:
Terry_4000> (enable) show port channel Port Status Channel Channel Neighbor Neighbor mode status device port ----- ---------- --------- ----------- --------- ------- 1/1 errdisable on channel 1/2 errdisable on channel ----- ---------- --------- ----------- --------- ------- Terry_4000> (enable)
You can see that the status is error disabled and that no neighbors are found. This is because we still need to configure Fast EtherChannel on the 2950 switch. If this were a remote switch, you would lose contact with the switch and have to go to the site and console into the switch to configure EtherChannel. You should configure the remote site first; then you will lose contact with it until you configure the local switch bundle.
To configure the EtherChannel bundle on a 2950 switch, use the interface command channel- group group_number mode mode_type:
Terry_2950(config)#int fa 0/1 Terry_2950(config-if)#channel-group ? <1-6> Channel group number Terry_2950(config-if)#channel-group 1 ? mode Etherchannel Mode of the interface Terry_2950(config-if)#channel-group 1 mode ? auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only Terry_2950(config-if)#channel-group 1 mode on Terry_2950(config-if)#int fa 0/24 Terry_2950(config-if)#channel-group 1 mode on Terry_2950(config-if)#exit
To view the channel status on the IOS-based switch, use the show etherchannel options command.
Terry_2950#show etherchannel ? <1-6> Channel group number brief Brief information detail Detail information load-balance Load-balance/frame-distribution scheme among ports in port-channel port Port information port-channel Port-channel information summary One-line summary per channel-group Terry_2950#show etherchannel det Channel-group listing: ----------------------- Group: 1 ---------- Group state = L2 Ports: 3 Maxports = 8 Port-channels: 1 Max Port-channels = 1 Ports in the group: ------------------- Port: Fa0/1 ------------ Port state = Up Mstr In-Bndl Channel group = 1 Mode = On/FEC Gcchange = 0 Port-channel = Po1 GC = 0x00010001 Pseudo port-channel = Po1 Port index = 0 Load = 0x00 Age of the port in the current state: 00d:00h:10m:25s Port: Fa0/24 ------------ Port state = Up Mstr In-Bndl Channel group = 1 Mode = On/FEC Gcchange = 0 Port-channel = Po1 GC = 0x00010001 Pseudo port-channel = Po1 Port index = 0 Load = 0x00 Age of the port in the current state: 00d:00h:05m:45s Port-channels in the group: ---------------------- Port-channel: Po1 ------------ Age of the Port-channel = 00d:00h:10m:26s Logical slot/port = 1/0 Number of ports = 2 GC = 0x00010001 HotStandBy port = null Port state = Port-channel Ag-Inuse Ports in the Port-channel: Index Load Port EC state ------+------+------+------------ 0 00 Fa0/1 on 0 00 Fa0/24 on Time since last port bundled: 00d:00h:05m:45s Fa0/24
To verify the EtherChannel on the 4000 series switch, use the show port channel command:
Terry_4000> (enable) show port channel Port Status Channel Channel Neighbor Neighbor mode status device port ----- ---------- --------- ----------- ------------------ ---------- 1/1 connected on channel cisco 2950 Terry_2950 A 1/2 connected on channel cisco 2950 Terry_2950 B ----- ---------- --------- ----------- ------------------ ---------- Terry_4000> (enable)
The preceding switch output shows the port numbers, status, mode, channel status, neighbor device, and neighbor port ID. Our EtherChannel is working!
Port Aggregation Protocol (PAgP)
The Port Aggregation Protocol (PAgP) is used to add more features to the EtherChannel technology. This protocol is used to learn the capabilities of the neighbors' EtherChannel ports. By doing this, it allows the switches to connect via Fast EtherChannel automatically. PAgP has four options when configuring the channel: on, off, desirable, and auto. The first two, on and off, are self-explanatory. A desirable link wants to become a channel, whereas a link set to auto doesn't want to but will if it has to. A channel will form if one of the following combinations are used: on-on, on-desirable, on-auto, desirable-desirable, desirable-auto.
The PAgP protocol groups the ports that have the same neighbor device ID and neighbor group capability into a channel. This channel is then added to the Spanning Tree Protocol as a single bridge port.
For PAgP to work, all the ports must be configured with static, not dynamic, VLANs, and all the ports must also be in the same VLAN or be configured as trunk ports. All ports must be the same speed and duplex as well. In other words, all the ports must be configured the same or PAgP will not work.
If an EtherChannel bundle is already working and you make a change on a port, all ports in that bundle are changed to match the port. If you change the speed or duplex of one port, all ports will then run that speed or duplex.
Load Balancing and Redundancy
Each switch operates a channel in a different fashion, but there are two main issues that all the switches must face. The first is how they forward traffic across the bundle of physical links, and the second is what happens if a link fails. This section will cover the basics. Cisco provides a guide at www.cisco.com/warp/public/473/4.html, detailing how each of the switches deal with these two topics.
Load Balancing
A channel is nothing more than a bundle of circuits that pretend to act like a single cable. Although this is convenient for increasing bandwidth without causing problems with spanning tree, it leaves us wondering which link gets used when a frame wants to cross the channel. The following list shows how each switch approach this task.
The 4000 Will send frames across the channel in a fashion that depends on the source and destination MAC addresses. An X-OR process is run on the last bit in the MAC addresses. The output will be one of 0.0, 0.1, 1.0, or 1.1. All frames where the source and destination MAC addresses end in 1 will use the same circuit. All frames where the last bit in the source is 0 and the last bit in the destination is 1 will use a different circuit. There is no load balancing between the circuits.
The 2950 and 3550 Will also send frames across the channel in a fashion that depends on the source and destination MAC addresses, but with the following caveats. If source-MAC address forwarding is used, frames are sent to hosts across the ports the source MAC address is associated with. If destination-MAC address forwarding is implemented, frames are forwarded according to the destination host's MAC address/port association. In either case, there is symmetry in the frame transfer, with frames following predictable paths according to entries in the bridging tables. Source-based forwarding is enabled by default.
Layer 3+ switches A switch that can recognize layer 3 or higher information can be configured to forward frames based on higher-layer header information. For example, the 6000 series can be configured with hardware that enables it to choose what circuit to use based on source, destination, or both. For addressing, it can use MAC addressing, IP addressing, or port values.
Redundancy
Because of the dynamic, load-balancing nature of 2950 and 3550 switches, redundancy and the management of traffic after a port failure are almost transparent. Frames previously carried over the port that fails are transferred to the port with the least traffic load at the moment of failure.
The 4000 works in a similar fashion, in that frames previously carried over the failed link are switched to the remaining segments within the EtherChannel.
PortFast
By default, the Spanning Tree Protocol (STP) runs on all ports on a switch. Because most of the ports connect to workstations, printers, servers, routers, and so on, it's basically a waste of resources for these point-to-point ports to be running the Spanning Tree Protocol. When a device-let's say, a workstation-powers up, it takes up to 50 seconds before the switch forwards data on the port because the STP is making sure no loops are going to occur when the port is in forwarding mode. Not only is this a waste of time (because a loop does not occur with point-to-point links), but some protocols or applications could time out.
PortFast is used to make a point-to-point port almost immediately enter into forwarding state by decreasing the time of the listening and learning states. This is very helpful for switch ports that have workstations or servers attached, because these devices will connect immediately instead of waiting for the STP to converge. If you connect a hub to a port configured with PortFast and then accidentally connect another port into the switch from the hub, you will have a network loop, and STP will not stop it. It is important to make sure that PortFast is used only on point-to-point links connected only to workstations or servers.
Configuring PortFast
To configure PortFast on a switch, use the set spantree portfast command. The following switch output shows how to configure ports 2/1-12 with PortFast:
Terry_4000> (enable) set spantree portfast ? Usage: set spantree portfast <mod_num/port_num> <enable|disable> set spantree portfast <trcrf> <enable|disable> Terry_4000> (enable) set spantree portfast 2/1-12 enable Warning: Spantree port fast start should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning tree loops. Use with caution. Spantree ports 2/1-12 fast start enabled. Terry_4000> (enable)
Notice the nice warning received on the switch console when PortFast was turned on. Also notice that we were able to turn on all 12 ports of our 10/100 card.
To configure PortFast on an IOS-based switch, use the spanning-tree portfast interface command:
Terry_2950(config)#int fa 0/12 Terry_2950(config-if)#switchport mode access Terry_2950(config-if)#spanning-tree ? 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 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 Terry_2950(config-if)#spanning-tree port Terry_2950(config-if)#spanning-tree portfast ? disable Disable portfast for this interface trunk Enable portfast on the interface even in trunk mode <cr> Terry_2950(config-if)#spanning-tree portfast %Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION %Portfast has been configured on FastEthernet0/12 but will only have effect when the interface is in a non-trunking mode. Terry_2950(config-if)
This parameter must be configured on each port you want to run PortFast. Note the words of caution associated with this command.
|
Some switches support an addition to PortFast called BPDUGuard. When you enable PortFast on a port, there is no guarantee that someone won't add a switch at their desk. Then, for redundancy, they also connect that switch to the LAN drop at their neighbor's desk. Congratulations, you now have a spanning tree loop!
BPDUGuard is a feature that can be set on many switches that enable PortFast. It monitors for BPDUs on that port. If a BPDU arrives, the switch shuts down the port, placing it in the errdisable state, and generates a status message.
|
UplinkFast
UplinkFast is used to minimize network downtime by ensuring that network loops do not occur when the network topology changes. STP convergence time is very time-consuming, so network loops can occur when the convergence is taking place. Additionally, some hosts will not be available for communication during the convergence time because STP has disabled ports on a switch during convergence. The key to both problems is decreased convergence time, which UplinkFast was developed to provide.
UplinkFast enables a blocked port on a switch to begin forwarding frames immediately when a link failure is detected on the root port. For the switch to change a port from blocking to forwarding mode, UplinkFast must have direct knowledge of the link failure: otherwise a loop might occur.
To utilize UplinkFast, several criteria must be met. First, UplinkFast must obviously be enabled on the switch. The switch must have at least one blocked port, and the failure must be on the root port. If the failure is not on a root port, UplinkFast ignores it and normal STP functions will occur.
When a link fault occurs on the primary root link, UplinkFast transitions the blocked port to a forwarding state. UplinkFast changes the port without passing through the listening and learning phases, which enables the switch to skip the normal convergence time and start forwarding in about 3 to 4 seconds instead of the usual 50 seconds.
UplinkFast was designed to work with access-layer switches, not core switches, because the switch running UplinkFast must not be the root bridge.
Configuring UplinkFast
When configuring UplinkFast, remember that all VLANs on the switch are affected and that you can not configure UplinkFast on individual VLANs.
To configure UplinkFast on a set-based switch, use the set spantree uplinkfast command:
Terry_4000> (enable) set spantree uplinkfast ? Usage: set spantree uplinkfast <enable> [rate <station_ update_rate>] [all-protocols <off|on>] set spantree uplinkfast <disable>
The options are really just enable or disable. The station update rate value is the number of multicast packets transmitted per 100 milliseconds (by default, it is set to 15 packets per millisecond). It is not recommended that you change this value.
The switch provides an output describing what the command changed on the switch, as shown here:
Terry_4000> (enable) set spantree uplinkfast enable VLANs 1-1005 bridge priority set to 49152. The port cost and portvlancost of all ports set to above 3000. Station update rate set to 15 packets/100ms. uplinkfast all-protocols field set to off. uplinkfast enabled for bridge. Terry_4000> (enable)
The VLAN priorities are automatically changed to 49152, and the port costs are set to above 3000. These are changed to make it unlikely that the switch will become the root switch.
You can verify the UplinkFast configuration with the show spantree uplinkfast command:
Terry_4000> (enable) show spantree uplinkfast Station update rate set to 15 packets/100ms. uplinkfast all-protocols field set to off. VLAN port list ----------------------------------------------- 1 1/1(fwd) 2 1/1(fwd) 3 1/1(fwd) 4 1/1(fwd) Terry_4000> (enable)
Notice that all four VLANs are changed and that we were not asked which VLANs to run UplinkFast on.
To configure UplinkFast on an IOS-based switch, use the command spanning-tree uplinkfast in global configuration mode:
Terry_2950(config)#spanning-tree ? backbonefast Enable BackboneFast Feature etherchannel Spanning tree etherchannel specific configuration extend Spanning Tree 802.1t extensions loopguard Spanning tree loopguard options mode Spanning tree operating mode pathcost Spanning tree pathcost options portfast Spanning tree portfast options uplinkfast Enable UplinkFast Feature vlan VLAN Switch Spanning Tree Terry_2950(config)#spanning-tree uplinkfast ? max-update-rate Rate at which station address updates are sent <cr> Terry_2950(config)#spanning-tree uplinkfast Terry_2950(config)#
To verify that UplinkFast is configured and running, use the command show spanning-tree uplinkfast:
Terry_2950#show spanning-tree uplinkfast UplinkFast is enabled Station update rate set to 150 packets/sec. UplinkFast statistics ----------------------- Number of transitions via uplinkFast (all VLANs) : 0 Number of proxy multicast addresses transmitted (all VLANs) : 0 Name Interface List -------------------- ------------------------------------ VLAN0001 VLAN0002 VLAN0003 Terry_2950
The default frame generation rate is 150pps, which is displayed with the show uplink-fast command. The next command used to help STP maintain a consistent network is BackboneFast.
BackboneFast
Sometimes a switch might receive a BPDU from another switch that identifies the second switch as the root bridge when a root bridge already exists. This shouldn't happen, except when a new switch comes on line and the BPDU is considered 'inferior.'
BPDUs are considered inferior when a switch has lost its link to the root bridge. The switch transmits the BPDUs with the information that it is now the root bridge as well as the designated bridge. The receiving switch ignores the inferior BPDU for the max age time, to prevent spanning tree loops.
After receiving inferior BPDUs, the receiving switch tries to determine whether there is an alternate path to the root bridge. If the port that the inferior BPDUs are received on is already in blocking mode, then the root port and other blocked ports on the switch become alternate paths to the root bridge. However, if the inferior BPDUs are received on a root port, then all presently blocking ports become the alternate paths to the root bridge. Also, if the inferior BPDUs are received on a root port and there are no other blocking ports on the switch, the receiving switch assumes that the link to the root bridge is down and the max age time expires, which turns the switch into the root switch.
If the switch finds an alternate path to the root bridge, it uses this new alternate path. This new path, and any other alternate paths, will be used to send a Root Link Query BPDU. By turning on BackboneFast, the Root Link Query BPDUs are sent out as soon as an inferior BPDU is received. This can enable faster convergence in the event of a backbone link failure. To ensure proper operation, BackboneFast should be enabled on all switches, including the root, if it is enabled at all.
Configuring and Verifying BackboneFast
Configuring BackboneFast is pretty easy, but it sounds difficult, which is the cool part about this command. You turn it on with the set spantree backbonefast command. Here is an example of this command being enabled:
Terry_4000> (enable) set spantree backbonefast Usage: set spantree backbonefast <enable|disable> Terry_4000> (enable) set spantree backbonefast enable Backbonefast enabled for all VLANs
Notice in the preceding switch output that BackboneFast is enabled for all VLANs, and it must be enabled on all switches in your network to function. To verify that it is running on a switch, use the show spantree backbonefast command:
Terry_4000> (enable) show spantree backbonefast Backbonefast is enabled. Terry_4000> (enable)
The preceding command shows that BackboneFast is enabled. That's all there is to it. It is a little different with the IOS-based switches:
Terry_2950(config)#spanning-tree ? backbonefast Enable BackboneFast Feature etherchannel Spanning tree etherchannel specific configuration extend Spanning Tree 802.1t extensions loopguard Spanning tree loopguard options mode Spanning tree operating mode pathcost Spanning tree pathcost options portfast Spanning tree portfast options uplinkfast Enable UplinkFast Feature vlan VLAN Switch Spanning Tree Terry_2950(config)#spanning-tree backbonefast ? <cr>
Rapid Spanning Tree
In the beginning, all bridges were inherently slow and it was accepted by users and applications developers alike that convergence would be slow. Cisco engineers have worked to develop solutions that overcame the basic flaws in STP that became obvious only when switching matured and took over from legacy bridging. All of the previous enhancements to the STP, such as PortFast, UplinkFast, and BackboneFast, have been proprietary.
Rapid Spanning Tree Protocol (RSTP), which has been standardized as 802.1w, can be regarded as a replacement for the proprietary extensions. Recalling the two core concepts of the 802.1D STP from Chapter 4, let us compare the old with the new.
First, 802.1D specifies that there are five different states that a port can be in. Each state is accompanied by a port mode, so a blocking port, for example, can not be a root or designated port.
RSTP assumes that three of these states can be regarded as essentially the same from the perspective of other switches. Listening, blocking, and disabled modes are all characterized by the facts that they do not forward frames and they do not learn MAC addresses, so RSTP places them all into a new mode, discarding. Learning and forwarding ports remain more or less the same. The effect of this change is to decouple the port states from the port roles.
The second big difference is the timing operation. In 802.1D STP, bridges would only send out a BPDU when they received one on their root port. These legacy bridges essentially act as forwarding agents for BPDUs that are generated by the root. In contrast, 802.1w-enabled switches send out BPDUs every hello time, containing current information.
The combination of these two changes forces spanning tree to operate in a much faster mode, with convergence being achieved in just a few seconds (typically about three times the 2-second update timer), largely because if a switch fails to receive BPDUs on an interface for 6 seconds, it presumes that the port at the other end of the link is down.
This rapid transition to the forwarding state, caused by switches no longer having to wait for the timer mechanism, is similar in concept to the proprietary PortFast mechanism, and only operates on edge ports and point-to-point links. Other enhancements in RSTP, such as the synchronization of root port information and the explicit forwarding authorization granted by switches to other switches, have parallels with the UplinkFast and BackboneFast extensions.
It is likely that, as time passes, greater emphasis will be placed by Cisco on the standardized mechanisms of 802.1w rather than the proprietary extensions to 802.1D.
| Tip | Those wishing to learn more about RSTP than is covered in the CCNP program should visit www.cisco.com/warp/public/473/146.html. |
EAN: 2147483647
Pages: 174