Chapter 12. Protecting against bridging loops by using the Spanning Tree Protocol
In the last chapter, you connected two switches—Switch1 and Switch2—via a single Ethernet connection. Imagine for a moment that both of these switches are in a live network and have dozens of end users connected to them. If the link between the switches goes down, devices on Switch1 won’t be able to communicate with devices on Switch2 and vice versa.
The solution is to add a redundant connection between FastEthernet0/23 on Switch1 and Switch2, as shown in figure 12.1. If the original link fails for whatever reason, the switches can communicate across the redundant link.
Figure 12.1. Switch1 and Switch2 with redundant links. Note that the interface numbers are the same on each end of the link.
At first glance, this looks like a wonderful configuration. It appears that by adding an additional connection, you’re adding not only redundancy but additional bandwidth as well. But this configuration isn’t as wonderful as it looks.
When you add a redundant connection, by default you can’t have traffic traversing both links simultaneously. To understand why, consider the following scenario.
Suppose that Executive-PC1 generates a broadcast Ethernet frame and sends it out onto the network. Recall from chapter 2 that Switch2 will forward such a broadcast out every port, including both ports connected to Switch1—FastEthernet0/23 and FastEthernet0/24. Figure 12.2 illustrates what this would look like.
Figure 12.2. If Switch1 and Switch2 were to use both links, a broadcast frame from Executive-PC1 would cause a bridging loop.
Switch1 would receive the same frame on both ports. Seeing that both identical frames are broadcast frames, it would forward them out of all its ports, including the ports connected to Switch2. In short, the frames would bounce back and forth between Switch1 and Switch2 indefinitely. This is called a bridging loop.
Without getting into the nerdy details, a bridging loop results in the original broadcast frame getting multiplied and sent across the inter-switch links over and over again, until all the bandwidth on both links is consumed or each switch’s CPU is overloaded. The ending is always the same: devices connected to both switches lose network connectivity. Ironically, that’s the very problem the redundant connection was supposed to prevent!
12.1. How Spanning Tree works
To solve the problem of bridging loops, a network engineer named Radia Perlman invented something called the Spanning Tree Protocol. Most network folks just call it Spanning Tree or, even more mercifully, STP. Spanning Tree resolves the problem of bridging loops, and on Cisco switches it’s enabled by default. But before you can get a hands-on feel for how it works, you need to create another trunk between your switches.
Connect an Ethernet cable between ports FastEthernet0/23 on Switch1 and Switch2.
On Switch1, configure FastEthernet0/23 to be a VLAN trunk port:
Interface fa0/23 switchport trunk encapsulation dot1q switchport mode trunk
As always, verify your configuration with a show interfaces trunk.
Don’t worry about creating a bridging loop. Remember, Spanning Tree is enabled by default and will prevent this. To see how it does this, look at figure 12.3.
Figure 12.3. Spanning Tree preventing a bridging loop by blocking FastEthernet0/24 on Switch2
Notice that Spanning Tree blocks FastEthernet0/24 on Switch2. By default, Spanning Tree blocks the higher-numbered ports in favor of the lower-numbered ports. It’s important to understand that blocked doesn’t mean shut down, disabled, or disconnected. It just means that the Spanning Tree process on Switch2 blocks Ethernet frames from ingressing or egressing FastEthernet0/24. As always, you can verify this at the command line.
On Switch2, issue a show spanning-tree vlan 700.
You should get some cryptic-looking output:
Although not very obvious, the last line of the output indicates Spanning Tree has placed FastEthernet0/24 in a BLK status, which means blocked. In contrast, it leaves FastEthernet0/23 in a FWD state, meaning forwarding—as in forwarding frames. To use more generic terminology, you can think of FastEthernet0/24 as the standby or backup port and FastEthernet0/23 as the active port.
Spanning Tree is an advanced topic that makes even experienced network administrators scratch their head. This book isn’t going to cover how Spanning Tree determines which ports to block, only how to tweak it to suit your environment.
12.1.1. How Spanning Tree deals with link failures
The point of having two links is to avoid a network outage if one of them goes down. You have two links, but Spanning Tree allows traffic on only one of them: FastEthernet0/23. Now let’s simulate a failure of that link to see how Spanning Tree responds.
On Switch2, shut down the FastEthernet0/23 interface:
interface fa0/23 shutdown
Issue another show spanning-tree vlan 700.
You should see the following:
Notice that FastEthernet0/23, which you just shut down, is nowhere to be found. Instead, you see FastEthernet0/24 in a forwarding state, meaning that Switch2 is now using this link to send traffic to Switch1. By the way, if your output doesn’t indicate a forwarding state for FastEthernet0/24, wait about 30 seconds and try again. I’ll explain why in a moment.
As good as Spanning Tree is, it’s not all roses. There’s another downside that shows up whenever a port goes up or down.
On Executive-PC1, start a continuous ping to Switch1’s VLAN 700 SVI:
Ping 172.31.70.254 -t
On Switch2, bring FastEthernet0/23 back up:
Interface fa0/23 No shut
Wait patiently for 30 seconds.
After about 30 seconds, you should see these few lines of output:
Switch2(config-if)#no shut Switch2(config-if)# *Mar 1 03:07:47.234: %LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to up *Mar 1 03:07:50.883: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23, changed state to up *Mar 1 03:08:19.899: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan900, changed state to up *Mar 1 03:08:19.916: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Pay special attention to the timestamp. The interface came back up at 3:07:47, but the SVIs for VLANs 1 and 900 didn’t come up until 30 seconds later. The reason for this is that Spanning Tree doesn’t place the port back into a forwarding state right away. During these 30 seconds, no traffic can pass between Switch1 and Switch2.
Checking the continuous ping on Executive-PC1 makes this painfully evident:
PS C:\Users\Administrator> ping 172.31.70.254 -t Pinging 172.31.70.254 with 32 bytes of data: Reply from 172.31.70.254: bytes=32 time<1ms TTL=255 Reply from 172.31.70.254: bytes=32 time=1ms TTL=255 Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Reply from 172.31.70.254: bytes=32 time=2ms TTL=255 Reply from 172.31.70.254: bytes=32 time=1ms TTL=255
Although six ping time-outs isn’t earth-shattering, it’s something users would certainly notice. More importantly, Spanning Tree does its job, as indicated by the eventual success of the pings. You can further verify this by checking the Spanning Tree status again.
Verify that FastEthernet0/23 is back in a forwarding state:
Show spanning-tree vlan 700
You should see this output:
Switch2#sh spanning-tree vlan 700
VLAN0700
Spanning Tree enabled protocol ieee
Root ID Priority 33468
Address 0023.ab40.8e00
Cost 19
Port 25 (FastEthernet0/23)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 33468 (priority 32768 sys-id-ext 700)
Address 0024.5088.6d80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- ----
Fa0/21 Desg FWD 19 128.23 P2p
Fa0/23 Root FWD 19 128.25 P2p
Fa0/24 Altn BLK 19 128.26 P2p
Now you can see everything’s back to the way it was immediately after you originally set up the redundant connection.
Again, I’m not going to get into the dirty details of how Spanning Tree works or why. Just know that, by default, Spanning Tree comes with this 30-second delay. The delay is twice the value of the forward delay timer, and it’s possible to shorten this delay to as little as 8 seconds by adjusting the forward delay timer to 4 seconds using the command spanning-tree vlan 1-4094 forward-time 4.
You or the powers that be in your organization might find the 30-second delay unacceptable. In that case, you have another option.
12.2. Rapid Spanning Tree
As you might have guessed, Rapid Spanning Tree Protocol (RSTP) does the same thing as Spanning Tree; it just does it faster. The biggest downside is that you have to manually enable it on all the switches that you want to use it. As a general rule, I recommend using RSTP whenever possible. But if your organization won’t allow it, or if you’re just not comfortable doing it, there’s absolutely no harm in sticking with regular old Spanning Tree.
Enable Rapid Spanning Tree on Switch1 and Switch2 by issuing the following configuration mode command:
spanning-tree mode rapid-pvst
Verify with a show spanning-tree vlan 700.
You should see the following familiar-looking output:
Switch2#sh spanning-tree vlan 700
Notice that the output doesn’t look very different:
The biggest difference is a subtle one: Spanning Tree enabled protocol is rstp—Rapid Spanning Tree Protocol. To really appreciate the difference, you need to see how it behaves when the active link fails.
Shut down interface FastEthernet0/23 on Switch2:
Int fa0/23 Shut
Issue a show spanning-tree vlan 700.
Without any noticeable delay, you should see FastEthernet0/24 in the forwarding state:
Switch2#sh spanning-tree vlan 700
VLAN0700
Spanning Tree enabled protocol rstp
Root ID Priority 33468
Address 0023.ab40.8e00
Cost 19
Port 26 (FastEthernet0/24)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 33468 (priority 32768 sys-id-ext 700)
Address 0024.5088.6d80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- ----
Fa0/21 Desg BLK 19 128.23 P2p
Fa0/24 Root FWD 19 128.26 P2p
If you bring FastEthernet0/23 back up, you should see Rapid Spanning Tree respond just as quickly.
Bring FastEthernet0/23 back up:
Int fa0/23 No shut
As fast as your fingers can type, do another show spanning-tree vlan 700.
You should see everything back to normal:
Switch2#show spanning-tree vlan 700
VLAN0700
Spanning Tree enabled protocol rstp
Root ID Priority 33468
Address 0023.ab40.8e00
Cost 19
Port 25 (FastEthernet0/23)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 33468 (priority 32768 sys-id-ext 700)
Address 0024.5088.6d80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- ----
Fa0/21 Desg BLK 19 128.23 P2p
Fa0/23 Root FWD 19 128.25 P2p
Fa0/24 Altn BLK 19 128.26 P2p
FastEthernet0/23 is once again in the forwarding state. Notice that Spanning Tree seems to prefer FastEthernet0/23 whenever it’s available. By default, all Spanning Tree implementations, Rapid or otherwise, will select the lowest numbered port.
You might be thinking that this still isn’t an optimal configuration. You have redundant connections, but it costs you a port on each switch. It would be nice to be able to use both connections simultaneously without encountering a bridging loop. In the next chapter, I’ll show you how to achieve this.
12.3. PortFast
Because Spanning Tree attempts to prevent bridging loops, it operates on all ports, not just those connected to switches. This has some interesting implications for end-user devices like PCs and IP phones. In an organizational environment, this becomes quite obvious when a user reboots and can’t get on the network for about 30 seconds. The act of rebooting a PC (and certainly turning it off and back on) causes the network interface card (NIC) to reset, which to the switch looks like someone unplugged the Ethernet cable and plugged it back in.
On Executive-PC1, start a continuous ping to the VLAN 700 SVI:
ping 172.31.70.254 -t
On Switch2, bounce the FastEthernet0/21 interface connected to Executive-PC1:
Int fa0/21 Shut No shut
On Executive-PC1, you should see something like this:
PS C:\Users\Administrator> ping 172.31.70.254 -t Pinging 172.31.70.254 with 32 bytes of data: Reply from 172.31.70.254: bytes=32 time<1ms TTL=255 Request timed out. Request timed out. Request timed out. Reply from 172.31.70.50: Destination host unreachable. Reply from 172.31.70.50: Destination host unreachable. Reply from 172.31.70.50: Destination host unreachable. Request timed out. Reply from 172.31.70.50: Destination host unreachable. Request timed out. Reply from 172.31.70.50: Destination host unreachable. Reply from 172.31.70.254: bytes=32 time=2ms TTL=255 Reply from 172.31.70.254: bytes=32 time=1ms TTL=255 Reply from 172.31.70.254: bytes=32 time=1ms TTL=255
There’s a single successful ping, followed by a series of failures, and then finally successful pings again. Spanning Tree doesn’t know what’s connected to that port, so it waits a long time (30 seconds) to make sure that forwarding traffic across that port won’t cause a bridging loop.
As brilliant as Spanning Tree is, it’s not human, and it’s not smart enough to quickly figure out that the only thing connected to that port is a PC. Fortunately, you, being the smart network administrator you are, can tell Spanning Tree not to wait to place the port into a forwarding state.
Cisco switches have as part of their Spanning Tree implementations a feature called PortFast. It’s an appropriate name, given that it causes Spanning Tree to enable the port—fast.
Enable PortFast on FastEthernet0/21:
Int fa0/21 Spanning-tree portfast
You should get a scary-looking warning:
Switch2(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/21 but will only have effect when the interface is in a non-trunking mode.
Translated into non-geek, the warning means that you should never enable PortFast on an interface connected to a switch. If you do, it could cause a bridging loop because it effectively disables Spanning Tree on that port.
By the way, enabling PortFast on an interface has the same effect whether you’re using STP or RSTP. Now that you’ve enabled PortFast, it’s time to test it out.
On Executive-PC1, restart a continuous ping to the VLAN 700 SVI:
ping 172.31.70.254 -t
On Switch2, bounce the FastEthernet0/21 interface connected to Executive-PC1:
Int fa0/21 Shut No shut
You should see no more than one dropped ping:
PS C:\Users\Administrator> ping 172.31.70.254 -t Pinging 172.31.70.254 with 32 bytes of data: Reply from 172.31.70.254: bytes=32 time=1ms TTL=255 Reply from 172.31.70.254: bytes=32 time=1ms TTL=255 Reply from 172.31.70.254: bytes=32 time=1ms TTL=255 Request timed out. Reply from 172.31.70.254: bytes=32 time=1ms TTL=255 Reply from 172.31.70.254: bytes=32 time=1ms TTL=255 Reply from 172.31.70.254: bytes=32 time<1ms TTL=255
Most users wouldn’t even notice this split-second blip in network connectivity. Although you certainly don’t have to enable PortFast on ports connected to end-user devices, it can potentially save you the occasional gripe from a user who has rebooted or kicked a network cable loose.
12.4. Commands in this chapter
Although you didn’t learn a lot of new commands in this chapter, the few you did learn are powerful, so it’s important to be clear on what each one does. Refer to table 12.1 for a refresher.
Table 12.1. Commands used in this chapter
|
Command |
Configuration mode |
Description |
|---|---|---|
| show spanning-tree vlan 700 | N/A | Displays information about the current (R)STP configuration |
| spanning-tree mode rapid-pvst | Global | Enables Rapid Spanning Tree globally |
| spanning-tree portfast | Interface | Enables PortFast, causing (R)STP to place the port into a forwarding state immediately |
Remember, regular Spanning Tree (STP) is enabled by default. It’s stable and works fine, but in the event of a topology change (for example, a link between switches going down) it can take about 30 seconds for STP to catch up. Rapid Spanning Tree (RSTP) doesn’t take as long, hence the name, which is why I recommend using it whenever possible.
12.5. Hands-on lab
- Enable PortFast on the port connected to HR-PC1.
- Physically disconnect the Ethernet cable connected to one of the FastEthernet0/23 ports (it doesn’t matter which). Can Executive-PC1 ping 172.31.70.254?
- Physically disconnect the cable connected to FastEthernet0/24. Can Executive-PC1 still ping 172.31.70.254?
- Reconnect both cables and save your configurations!