You remember from your CCNA studies that when a port goes through the transition from blocking to forwarding, you're looking at a 50-second delay before that port can actually begin forwarding frames. Configuring a port with PortFast is one way to get around that, but again, you can only use it when a single host device is found off the port. What if the device connected to a port is another switch?
A switch can be connected to two other switches, giving that local switch a redundant path to the root bridge, and that's great - we always want a backup plan! However, STP will only allow one path to be available, but if the available path to the root switch goes down, there will be a 50-second delay due to the STP timers MaxAge and ForwardDelay before the currently blocked path will be available.
The delay is there to prevent switching loops, and we can't use PortFast to shorten the delay since these are switches, not host devices. What we can use is Uplinkfast.
The ports that SW3 could potentially use to reach the root switch 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. Uplinkfast is pretty much PortFast for wiring closets. (Cisco recommends that Uplinkfast not be used on switches in the distribution and core layers.)
Some additional details regarding Uplinkfast:
The actual transition from blocking to forwarding mode takes about three seconds.
Uplinkfast cannot be configured on a root switch.
Uplinkfast is configured globally. 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 back to the forwarding state:
( 2 x FwdDelay) + 5 seconds
Uplinkfast will take immediate action to ensure that the switch upon which it is configured 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. Additionally, 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.
And you just know there's got to be at least one option with this command, right? Let's run IOS Help and see.
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 0100.0ccd.cdcd. The max-update-rate value determines how many of these frames will be sent in a 100-millisecond time period.
Mastering the details of UplinkFast, BackboneFast, BPDU Guard, and Loop Guard are vital to your success on the CCNP exams, and one or more of these features are in use on almost every network in the world. Learn these features for success in both the exam room and the real world!
Showing posts with label root. Show all posts
Showing posts with label root. Show all posts
Thursday, December 25, 2008
Cisco CCNP / BCMSN Exam Tutorial: Changing Root Bridge Election Results
Your BCMSN and CCNP studies will include mastering the details of Spanning Tree Protocol (STP). While you learned some of these details in your CCNA studies, quite a bit of it may be new to you. Before going on to the intermediate and advanced STP features, let's review the root bridge election process and learn how to change these results.
Each switch will have a Bridge ID Priority value, more commonly referred to as a BID. This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-33-44-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default, the MAC address is the deciding factor.
Switches are a lot like people - when they first arrive, they announce that they are the center of the universe! Unlike some people, the switches will soon get over it. BPDUs will be exchanged until one switch is elected Root Bridge, and it's the switch with the lowest BPDU that will end up being the Root Bridge.
If STP is left totally alone, a single switch is going to be the root bridge for every single VLAN in your network. Worse, that single switch is going to be selected because it has a lower MAC address than every other switch, which isn't exactly the criteria you want to use to select a single root bridge.
The time will definitely come when you want to determine a particular switch to be the root bridge for your VLANs, or when you will want to spread the root bridge workload. For instance, if you have 50 VLANs and five switches, you may want each switch to act as the root bridge for 10 VLANs each. You can make this happen with the spanning-tree vlan root command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
In this example, we've got two switches, and SW1 has been elected the root bridge for VLANs 10, 20, and 30. We'll use the spanning-tree vlan root command on SW2 to make it the root bridge for VLANs 20 and 30.
SW2(config)#spanning-tree vlan 20 root primary
SW2(config)#spanning-tree vlan 30 root primary
SW2#show spanning vlan 20
VLAN0020
Spanning tree enabled protocol ieee
Root ID Priority 24596
Address 000f.90e2.1300
This bridge is the root
SW2#show spanning vlan 30
VLAN0030
Spanning tree enabled protocol ieee
Root ID Priority 24606
Address 000f.90e2.1300
This bridge is the root
SW 2 is now the root bridge for both VLAN 20 and 30. Notice that the priority value has changed from the default of 32768.
In the next CCNP / BCMSN tutorial, we'll take a look at more STP features.
Each switch will have a Bridge ID Priority value, more commonly referred to as a BID. This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-33-44-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default, the MAC address is the deciding factor.
Switches are a lot like people - when they first arrive, they announce that they are the center of the universe! Unlike some people, the switches will soon get over it. BPDUs will be exchanged until one switch is elected Root Bridge, and it's the switch with the lowest BPDU that will end up being the Root Bridge.
If STP is left totally alone, a single switch is going to be the root bridge for every single VLAN in your network. Worse, that single switch is going to be selected because it has a lower MAC address than every other switch, which isn't exactly the criteria you want to use to select a single root bridge.
The time will definitely come when you want to determine a particular switch to be the root bridge for your VLANs, or when you will want to spread the root bridge workload. For instance, if you have 50 VLANs and five switches, you may want each switch to act as the root bridge for 10 VLANs each. You can make this happen with the spanning-tree vlan root command.
SW1(config)#spanning-tree vlan 1 ?
forward-time Set the forward delay for the spanning tree
hello-time Set the hello interval for the spanning tree
max-age Set the max age interval for the spanning tree
priority Set the bridge priority for the spanning tree
root Configure switch as root
In this example, we've got two switches, and SW1 has been elected the root bridge for VLANs 10, 20, and 30. We'll use the spanning-tree vlan root command on SW2 to make it the root bridge for VLANs 20 and 30.
SW2(config)#spanning-tree vlan 20 root primary
SW2(config)#spanning-tree vlan 30 root primary
SW2#show spanning vlan 20
VLAN0020
Spanning tree enabled protocol ieee
Root ID Priority 24596
Address 000f.90e2.1300
This bridge is the root
SW2#show spanning vlan 30
VLAN0030
Spanning tree enabled protocol ieee
Root ID Priority 24606
Address 000f.90e2.1300
This bridge is the root
SW 2 is now the root bridge for both VLAN 20 and 30. Notice that the priority value has changed from the default of 32768.
In the next CCNP / BCMSN tutorial, we'll take a look at more STP features.
Tuesday, December 23, 2008
Cisco CCNA / CCNP Certification: How And Why To Build An Etherchannel
CCNA and CCNP candidates are well-versed in Spanning-Tree Protocol, and one of the great things about STP is that it works well with little or no additional configuration. There is one situation where STP works against us just a bit while it prevents switching loops, and that is the situation where two switches have multiple physical connections.
You would think that if you have two separate physical connections between two switches, twice as much data could be sent from one switch to the other than if there was only one connection. STP doesn't allow this by default, however in an effort to prevent switching loops from forming, one of the paths will be blocked.
SW1 and SW2 are connected via two separate physical connections, on ports fast0/11 and fast 0/12. As we can see here on SW1, only port 0/11 is actually forwarding traffic. STP has put the other port into blocking mode (BLK).
SW1#show spanning vlan 10
(some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Fa0/11 Root FWD 19 128.11 P2p
Fa0/12 Altn BLK 19 128.12 P2p
While STP is helping us by preventing switching loops, STP is also hurting us by preventing us from using a perfectly valid path between SW1 and SW2. We could literally double the bandwidth available between the two switches if we could use that path that is currently being blocked.
The secret to using the currently blocked path is configuring an Etherchannel. An Etherchannel is simply a logical bundling of 2 - 8 physical connections between two Cisco switches.
Configuring an Etherchannel is actually quite simple. Use the command "channel-group 1 mode on" on every port you want to be placed into the Etherchannel. Of course, this must be done on both switches if you configure an Etherchannel on one switch and don't do so on the correct ports on the other switch, the line protocol will go down and stay there.
The beauty of an Etherchannel is that STP sees the Etherchannel as one connection. If any of the physical connections inside the Etherchannel go down, STP does not see this, and STP will not recalculate. While traffic flow between the two switches will obviously be slowed, the delay in transmission caused by an STP recalculation is avoided. An Etherchannel also allows us to use multiple physical connections at one time.
Here's how to put these ports into an Etherchannel:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#interface fast 0/11
SW1(config-if)#channel-group 1 mode on
Creating a port-channel interface Port-channel 1
SW1(config-if)#interface fast 0/12
SW1(config-if)#channel-group 1 mode on
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#channel-group 1 mode on
SW2(config-if)#int fast 0/12
SW2(config-if)#channel-group 1 mode on
The command "show interface trunk" and "show spanning-tree vlan 10" will be used to verify the Etherchannel configuration.
SW2#show interface trunk (some output removed for clarity)
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
SW2#show spanning vlan 10 (some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 12 128.65 P2p
Before configuring the Etherchannel, we saw individual ports here. Now we see "Po1", which stands for the interface "port-channel1". This is the logical interface created when an Etherchannel is built. We are now using both physical paths between the two switches at one time!
That's one major benefit in action let's see another. Ordinarily, if the single open path between two trunking switches goes down, there is a significant delay while another valid path is opened - close to a minute in some situations. We will now shut down port 0/11 on SW2 and see the effect on the etherchannel.
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#shutdown
3w0d: %LINK-5-CHANGED: Interface FastEthernet0/11, changed
state to administratively down
SW2#show spanning vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 19 128.65 P2p
SW2#show interface trunk
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
The Etherchannel did not go down! STP sees the Etherchannel as a single link therefore, as far as STP is concerned, nothing happened.
Building an Etherchannel and knowing how it can benefit your network is an essential skill for CCNA and CCNP success, and it comes in very handy on the job as well. Make sure you are comfortable with building one before taking Cisco's exams!
You would think that if you have two separate physical connections between two switches, twice as much data could be sent from one switch to the other than if there was only one connection. STP doesn't allow this by default, however in an effort to prevent switching loops from forming, one of the paths will be blocked.
SW1 and SW2 are connected via two separate physical connections, on ports fast0/11 and fast 0/12. As we can see here on SW1, only port 0/11 is actually forwarding traffic. STP has put the other port into blocking mode (BLK).
SW1#show spanning vlan 10
(some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Fa0/11 Root FWD 19 128.11 P2p
Fa0/12 Altn BLK 19 128.12 P2p
While STP is helping us by preventing switching loops, STP is also hurting us by preventing us from using a perfectly valid path between SW1 and SW2. We could literally double the bandwidth available between the two switches if we could use that path that is currently being blocked.
The secret to using the currently blocked path is configuring an Etherchannel. An Etherchannel is simply a logical bundling of 2 - 8 physical connections between two Cisco switches.
Configuring an Etherchannel is actually quite simple. Use the command "channel-group 1 mode on" on every port you want to be placed into the Etherchannel. Of course, this must be done on both switches if you configure an Etherchannel on one switch and don't do so on the correct ports on the other switch, the line protocol will go down and stay there.
The beauty of an Etherchannel is that STP sees the Etherchannel as one connection. If any of the physical connections inside the Etherchannel go down, STP does not see this, and STP will not recalculate. While traffic flow between the two switches will obviously be slowed, the delay in transmission caused by an STP recalculation is avoided. An Etherchannel also allows us to use multiple physical connections at one time.
Here's how to put these ports into an Etherchannel:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#interface fast 0/11
SW1(config-if)#channel-group 1 mode on
Creating a port-channel interface Port-channel 1
SW1(config-if)#interface fast 0/12
SW1(config-if)#channel-group 1 mode on
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#channel-group 1 mode on
SW2(config-if)#int fast 0/12
SW2(config-if)#channel-group 1 mode on
The command "show interface trunk" and "show spanning-tree vlan 10" will be used to verify the Etherchannel configuration.
SW2#show interface trunk (some output removed for clarity)
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
SW2#show spanning vlan 10 (some output removed for clarity)
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 12 128.65 P2p
Before configuring the Etherchannel, we saw individual ports here. Now we see "Po1", which stands for the interface "port-channel1". This is the logical interface created when an Etherchannel is built. We are now using both physical paths between the two switches at one time!
That's one major benefit in action let's see another. Ordinarily, if the single open path between two trunking switches goes down, there is a significant delay while another valid path is opened - close to a minute in some situations. We will now shut down port 0/11 on SW2 and see the effect on the etherchannel.
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int fast 0/11
SW2(config-if)#shutdown
3w0d: %LINK-5-CHANGED: Interface FastEthernet0/11, changed
state to administratively down
SW2#show spanning vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Interface Role Sts Cost Prio.Nbr Type
Po1 Desg FWD 19 128.65 P2p
SW2#show interface trunk
Port Mode Encapsulation Status Native vlan
Po1 desirable 802.1q trunking 1
The Etherchannel did not go down! STP sees the Etherchannel as a single link therefore, as far as STP is concerned, nothing happened.
Building an Etherchannel and knowing how it can benefit your network is an essential skill for CCNA and CCNP success, and it comes in very handy on the job as well. Make sure you are comfortable with building one before taking Cisco's exams!
Subscribe to:
Posts (Atom)
