Archive for the ‘spanning tree’ tag
Stubby Post – UplinkFast
I’ve got a few switches daisy chained together with single links and have enabled UplinkFast on them. This switch is not the root bridge; F0/24 is the root port and F0/23 is a blocked alternate port. I’ve got debug spanning-tree uplinkfast on to help out.
SW3#sh span | incl 0/2[34] Fa0/23 Altn BLK 3019 128.23 P2p Fa0/24 Root FWD 3019 128.24 P2p
Now let’s unplug F0/24 and see what happens.
19:05:05: STP FAST: UPLINKFAST: make_forwarding on VLAN0001 FastEthernet0/23 roo t port id new: 128.23 prev: 128.24 19:05:05: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 FastEthernet0/23 moved to Forwarding (UplinkFast). 19:05:05: STP: UFAST: removing prev root port Fa0/24 VLAN0001 port-id 8018 SW3# 19:05:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down SW3# 19:05:07: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down
Before the switch even reports that F0/24 is down, F0/23 is brought into the forwarding state. Now let’s plug F0/24 back in.
19:07:16: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to up SW3# 19:07:17: STP FAST: make_forwarding: via UPLINKFAST: NOT: port FastEthernet0/23 VLAN0001 is: uplink enabled new root FastEthernet0/23 (me)prev root exists(8018/) cur state forwarding role uplink 19:07:17: STP FAST: make_forwarding: via UPLINKFAST: NOT: port FastEthernet0/24 VLAN0001 is: uplink enabled new root FastEthernet0/23 (not me)prev root exists(8018/) cur state blocking role looped 19:07:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to up SW3# 19:07:18: STP FAST: make_forwarding: via UPLINKFAST: NOT: port FastEthernet0/23 VLAN0001 is: uplink enabled new root FastEthernet0/23 (me)prev root exists(8018/) cur state forwarding role uplink SW3#sh span | incl 0/2[34] Fa0/23 Root FWD 3019 128.23 P2p Fa0/24 Altn BLK 3019 128.24 P2p
Notice that the port comes back up, but it isn’t returned as the root port immediately. It should be, though, right? The original STP convergence said that it was the closest to the root bridge, so it makes sense that it should be the root port again, right? Since the port just came up, STP still has to make sure there’s no loop, so it has to step through all the states like any good port does. If we wait a few more seconds, we see this.
19:07:53: STP FAST: UPLINKFAST: make_forwarding on VLAN0001 FastEthernet0/24 root port id new: 128.24 prev: 128.23 19:07:53: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 FastEthernet0/24 moved to Forwarding (UplinkFast). SW3#sh span | incl 0/2[34] Fa0/23 Altn BLK 3019 128.23 P2p Fa0/24 Root FWD 3019 128.24 P2p
Now we’re back to where we were originally. The moral of the story is that UplinkFast already knew the status of both ports, so it could quickly move the blocked port to fowarding when the port failed. Traditional STP would have to send a TCN message to the root bridge, which would then forward them out with the rest of the switches so they can reconverge. UplinkFast skips the whole reconverging thing.
Send any questions my way.
Stubby Post – Path Cost of EtherChannels
I was doing some STP labs tonight and found something that caught me off guard a bit. I had been meddling with some EtherChannels between a pair of 3750s earlier today, and I forgot to reset the configs before starting on the STP stuff. One my secondary root switch, I ran a show spanning-tree vlan 1 to see what status the ports were in, and I noticed the root path cost.
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 24577
Address 001b.d4fa.bb00
Cost 12
This switch is directly connected to the root bridge via a pair of EtherChanneled FastEthernets, so I just assumed I’d get a cost of 19. I surely didn’t expect a cost of 12. I added a third interface to the channel-group and wound up with this.
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 24577
Address 001b.d4fa.bb00
Cost 9
Obviously there’s some internal math going on with the EtherChannel and STP. Guess what happens when I add a fourth link?
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 24577
Address 001b.d4fa.bb00
Cost 8
It’s interesting to see how the path cost changes in a way to seems disproportionate to the bandwidth.
Send any new math formulae comments this way.
SWITCH – STP Exercise #1 Solution
Did you guys have any trouble with the solution to the STP exercise? Let’s work through it and see what happens. I got a few responses to the solution, and everyone seems to get the same answer, so I assume we’re all right.
Before we get started, I wanted to mention the tie breakers since there can be ties in STP. If there is a tie in any calculation, the same tie breakers are used, so I’ll list them here to use as we move through the calculations.
- Lowest root bridge ID (which I hope we’ll never have to use)
- Lowest root path cost
- Lowest bridge ID
- Lowest port ID
In our exercise, we only have to go to the tie breakers once, but, in the wild, you may run into more. I would guess that this is a requirement to know for the SWITCH test.
Before we get started, you can assume that a bridge is a switch since, technically, a switch is a many-ported bridge. Let’s get started. There are only 5 steps to take, so it shouldn’t take long.
1. Find the path costs of each segment
This is done with a table lookup. Each segment (link between switches) gets a cost based on the technology that it is using. For example, GigabitEthernet has a cost of 4 while FastEthernet has a cost of 19. There are other values, but these are the only ones that are used in the network here. I did find a good table on STP path costs at HowStuffWorks.com if you want to take a look at more of them. Let’s put the path costs on the diagram.
2. Find the root bridge
After we find the path costs, we find the root bridge. The root bridge is the switch that has the lowest bridge ID, which is the switch priority and the MAC address concatenated together. Since all the bridges have the same priority, we can just look at the MACs to figure out which one has the lowest bridge ID. Switch E has the lowest MAC (0000.0000.0003), so that’s the root bridge.
3. Find the root ports of each bridge
The root port is a port on a switch that has the lowest total path cost back to the root bridge; every switch has a one and only one root port except for the root bridge itself which has none (it’s the root; it already knows where it is). The root bridge sends out BPDUs that are passed to each switch. When a switch receives it (not sends it), it increments the root path cost field and passes that along, The port on which the lowest root path costs is received is the root port, and the value in the root path cost field is the root path cost for that switch. The finger trace method works for us humans for now; there’s not that many switches involved. Let’s add the root ports along with the root path costs to the diagram.
4. Find the designated ports
Each segment of the network has a designated port. This is a port on the bridge with the lowest root path cost. Since the root bridge always has the shortest path to itself, all of its ports are designated ports. Root ports can’t be designated ports, too, so it’s pretty easy to find the designated ports on segments with root ports. There are two segments (A-B and B-C) that we need to calculate, though. Let’s go to the tie breakers!
All the bridges have the same root bridge ID, so that’s a wash. C has a lower root path cost than B, so it wins that segment. A and B both have the same root path cost, though, so we move down the list to bridge ID. Since A has a lower bridge ID, it wins that segment.
Let’s put all the designated ports on the diagram so you can see them.
5. Find the blocked ports
There aren’t many ports left, are there? There are three actually, and all those go into a blocked state. To get rid of the loops, any port that’s not a root port or a designated port is blocked. Here’s the network with the blocked ports marked.
And we’re done. That wasn’t so hard.
Send me any summer home rentals questions.
Audio commentary:
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
BCMSN Notes — STP States
I’ve decided to take on the CCNP certification, so I’m going to wind up with a few posts will be more my own notes than anything. :)
A switch port on a 2960 comes up with a default configuration on VLAN 1. What happens from the perspective of spanning-tree?
- First, the port comes up on blocking mode. This is to make sure that loops aren’t created without first listening to the network to see what’s going on.
- Next, if the port may be a root or designated port, the port is moved to the listening state. In this state, the port can send and receives BPDUs only. It can’t send traffic, but it can discover the other switches participating in STP.
- After the forwarding delay, the port goes into the learning state. In this state, the port can send and receive BPDUs as in listening, but it can now receive traffic. It can’t yet send any.
- After the forwarding delay again, the port goes into the forwarding state. The port can now send and receive data.
If the port is configured with spanning-tree portfast, the mode goes from blocking directly to forwarding without going through these steps. Obviously you don’t want a switch plugged into a port configured for portfast since you may wind up with a loop.
Here’s the debug spanning-tree events output from one of my labs. F0/3 is configured for portfast. I shut/no shut it to see what happens.
*Mar 8 18:09:51.163: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down sw01# *Mar 8 18:09:51.747: set portid: VLAN0007 Fa0/3: new port id 8003 *Mar 8 18:09:51.747: STP: VLAN0007 Fa0/3 ->jump to forwarding from blocking sw01# *Mar 8 18:09:53.739: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up *Mar 8 18:09:54.739: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up
Notice the “jump to forwarding from blocking”.
Here’s the same output when the port is not in portfast mode. Notice the timestamps. It takes about 30 seconds (2 x default foward delay) to go from blocking to listening to learning to forwarding.
*Mar 8 18:13:05.313: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down sw01# *Mar 8 18:13:06.013: set portid: VLAN0007 Fa0/3: new port id 8003 *Mar 8 18:13:06.013: STP: VLAN0007 Fa0/3 -> listening sw01# *Mar 8 18:13:06.381: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up *Mar 8 18:13:07.381: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up sw01# *Mar 8 18:13:21.013: STP: VLAN0007 Fa0/3 -> learning sw01# *Mar 8 18:13:36.013: STP: VLAN0007 Fa0/3 -> forwarding
Send any obvious corrections and questions my way.