Features that Decrease STP Convergences

                   In this topic, we want to take a look at few features on Cisco Catalyst Switches that can help reduce the STP Convergences Time. We saw earlier that if we had a link failure, it might take 50 seconds to Convergences, to start sending traffic around that link failure, and 50 seconds can be a very long time into Production Networks, and we already talked about Rapid Spanning Tree Protocol, and saw how it could dramatically decrease this Convergence Time.

                       However, if we were not running Rapid STP, a couple of these features might help us out.

Here are those 3 features

             UplinkFast: - this is not something you need with Rapid Spanning Tree Protocol, because Rapid Spanning Tree Protocol has a feature similar to this built into the Standard. What this does is, it’s going to allows the Switch to detect a Direct Link failure, if a link fails on a Switch, it’s going to be able to transition a previously Blocking Port into a Forwarding almost immediately and then Reeducate the Switch topology about how to get to the Mac-Addresses that resides of that Switch, we typically see this in Access Layer Switches.

Another feature we wanna talk about, and again this feature is not needed with Rapid STP because it has a similar more feature built into the Standard, but this feature is “Backbone Fast”.

                   And we going to see that “Backbone Fast is going to allow a Switch to reduce Convergence Time when it detect the Link Failure, but not a Direct Link Failure, an indirect Link Failure”.

Finally, a feature that is useful for Rapid Spanning Tree Protocol as well as other flavors of Spanning Tree Protocol, and it’s “Portfast”.

                   When we plugging an End Station into a Switchport, instead of waiting through the Listening and Learning States for that Port to go active, let’s go active almost immediately when we connect.

The first of these 3 features are “UplinkFast”

And UplinkFast is typically going to be configured on an Access Layer Switch, in fact we do not want to configure this on a Switch that is a Transit Switch, another word, it’s a Switch that’s sits in the path between the Root Bridge, and another Switch that can cause issue for use.

            For example, on Picture, we would not want to enable UplinkFast on Sw2 because that was a Transit Switch for Sw4, to get to the Root Bridge but we can enable it on Sw4 that an Access Layer Switch connected to End User devices, and when we enable UplinkFast, we enable it, Globally on the Switch, it’s not a Port Configuration parameter, it’s a Global Switch parameter, and this feature is going to react to a Direct link failure, let me show you an example.

                 Consider Sw4 on Picture, notice it has a Root Port that goes directly up to Sw2, let’s imagine that, that link went down.

                        In response to that, Sw4 has a Blocking Port, and what is Spanning Tree Protocol do, it allows a Blocking Port to transition to a Forwarding State if we lost our Primary path to the Root Bridge like we just did, and we gonna transition almost immediately because we saw that link, that port on our Switch went down. We know that we can no longer get the Root via that port, and what we gonna do is unblock that port that gets us up to Sw3.

However, we still a challenge, and the challenge is the various Switches in our network have learned how to get to the Mac-Addresses that live of that Sw4. I am pretending that we got couple of Laptop’s with Mac-Addresses of All AAAA.AAAA.AAAA and all BBBB.BBBB.BBBB. Switch Sw2 for example, thinks to get to all AAAA.AAAA.AAAA mac-addresses, i am go straight down to this link to Sw4, and Sw3 has been thinking to get to the All AAAA.AAAA.AAAA mac-address, i am gonna go over this link to Sw2, and we would go down to Sw4 but that link between Sw2 and Sw4 it’s not there any longer, and of course over time the mac-address entry would age out and things would get OK.

                       We want to very quickly Reeducate to this topology about, how to get to these Mac-Addresses that live of that Sw4, here is what UplinkFast can do to speed that long. It’s gonna send a series of Dummy Multicast frames, i say Dummy because it doesn’t contain any meaningful data it’s just a frame that we can propagate through out to the network, and notice the Source Mac-Address on these frames.

                  Their Source Mac-Address are gonna be a Mac-addresses of the devices hanging of that Sw4, that’s the way we can quickly Reeducate the topology about how to get these mac-addresses.

Now let see, how to configure UplinkFast, we enable it Globally

            That’s the first of our 3 features “UplinkFast” again it’s not needed, if you are using Rapid Spanning Tree Protocol, because Rapid Spanning Tree Protocol has covered, it has a similar feature that’s built into the Standard.

Our Second feature is “BackboneFast”, and we said that “UplinkFast” should be typically enabled on a Access Layer switches, if we gonna use “BackboneFast” we should enable it everywhere on all of our networks Switches, and when we enable it, we don’t enable it at the Port level, we Globally enable it for the entire Switch and what it can do is, allow a Switch to react to an indirect Link Failure.

                For example, on Picture, Sw3 is about to react to a Link Failure between Sw1 and Sw2, let imagine that, the link between Sw1 and Sw2 goes down.

                 When Sw2 loses that link it’s going to assume that, it is now the Root Bridge, it lost its connection to the Root, it must be the Root. So, what Sw2 will do, it’s going to send out a BPDU to Switch Sw3 saying “i am the Root Bridge”, and this type of BPDU.

                    This type of Bridge Protocol Data Unit is being advertising from a Sw2, that’s known as “Inferior BPDU”.

                      It’s inferior because the Bridge ID that being advertised as the Root, Sw2 is the Bridge ID, is inferior to the Bridge ID is being advertised by Sw1, and Sw3, when it receives this inferior BPDU, it’s gonna notice that paradox and, if Sw3 is configured for BackboneFast, what’s its gonna do, its proactively go out and check if it still has a path to the Root Bridge.

                     And by the way, we did not have a “BackboneFast” enabled, Switch Sw3 would receive this inferior BPDU, what it’s gonna say “that’s inferior and i am going to ignore that”, and that Blocking Port on a Sw3 it would wait for a 20 Seconds Max Age timers before it started to transition to a Forwarding state, it would wait 20 seconds, and it would go out and to Listening and Learning.

What Backbone is going to allow us to do, is eliminate that 20 seconds delay, we getting read of that Max Age timers delay because Sw3 is going to try to determined does it have a path to the Root, and Sw3 is going to do is send a message out of all of its other Non-Designated ports, another word, any ports including the Root Ports that can get back to the Root Bridge and, in this case, we just have one of those ports, it’s the Root port on a Sw3 going directly back to the Root Bridge and it sends out what’s called “RLQ”, a “Root Link Query”.

       And it’s asking “hey do i still have a path to the Root Bridge”, and that query goes into the Root Bridge, and Root Bridge says “Yes you do, yes i am the Path to the Root Bridge and it’s me, it’s Sw1”, this is a “RLQ Reply” or a “Root Link Query Reply”.

                      That goes back to Switch Sw3, and now the Switch Sw3 knows that Sw1 really is the Root it can let, Sw2 know about that, it’s gonna say “hey Sw1 is actually the Root Bridge”.

                      And when Sw2 gets that information, it’s says “ok i realize now, that i had an inferior BPDU, is a better Bridge ID than i have, and as a result “i stand down and i stop claiming to be the Root Bridge”.

                  How do we setup BackboneFast, almost identical to way we setup UplinkFast, with BackboneFast we enabling this globally, go into global configuration mode and say

And our third Switch feature in this topic, actually is useful for Rapid Spanning Tree Protocol, as well as other flavor of Spanning Tree Protocol, in fact we already demonstrated this in previous topic. This was how, we told Rapid Spanning Tree Protocol that a Port is an Edge Port, what we can do is, configure Portfast on Ports that connect out to network End points, Printer, PC’s, Laptops and Wireless AP, another word, we are not connecting to any device that might be sending us a BPDU’s, we are not connecting out to another Switch, and we can enable on Port by Port bases or we might want to just turned it on Globally.

However, when we turned it on globally, it’s only enabled for Non-Trunking Ports, if we got a Ports that doing Trunking Portfast is not going to be enabled for that, and the reasons we huge fans of Portfast is, it allows port to go almost immediately into the Forwarding State, when we connected to a device into a Switch Port.

              For example, Laptop on Picture, if i plugged into this Switch Sw4 fastetherent 1/0/1

              If Portfast not enabled, it might have to wait for 30 seconds before that Ports run active, that Port was not blocking before because it was even up, so we don’t have to wait through the 20 seconds of Blocking, we do after wait through the 15 Seconds of Listening and 15 seconds of Learning for grand total of 30 seconds before this port goes active.

             And with the lots of PC’s and Laptop’s today, that have SSD, they can boot up very quickly, maybe quicker than 30 seconds and they might run into issue, if they boot up in 15 seconds and send out a DHCP Request to get their IP Address and hear no response, and the reason it could happen is, it’s taking 30 seconds for the Switchport to go active.

            What we can do, enable a Portfast, “where we Promising to Switch, that we not going to connect this port to some other Switch or some other Device that might be sending BPDU”, something that might cause a loop. We promising to connect this to something like an End User Workstation and we already seen on the previous topic, how to Configure Portfast on a specific port, let’s do it

                 That’s how we can enable it, on a Port by Port bases but maybe you wanna turned this ON all your access ports, to do that in Global Configuration Mode.

                            And that’s going to enable Portfast on all of our Non-Trunking ports, all of our Access Ports on your Switch and if you want to verify that Portfast is running for a particular Port on Switch we can do

                                    That’s the look at 3 features that might help us to reduce the Convergence Time for Spanning Tree Protocol, again no need to do the UplinkFast and BackboneFast, if we doing Rapid Spanning Tree Protocol it’s already got similar features built in.

 If we were using for example PVST+, these can really help us to reduce Convergence Time and we said for all over flavors of Spanning Tree Protocol “Portfast” might be good option, when we configuring the Port that connect out to an End Station.

Join me on our Next session about

Ø  BPDU Guard

Ø  BPDU Filter

Ø  Root Guard

Ø  Loop Guard

Click Here To Download The PDF File

                 If You Like the Post. Don’t forget 

         to “Subscribe/Share/Comment”. Thank You.

Read More

Rapid-PVST+ Configuration

                             Now the, we talked about the Theory of Rapid-PVST+, let’s see how to set it up, first let’s see

                How to change STP mode to Rapid-PVST+, to do that go to Switch Global Configuration Mode

Ø  Sw1(config)#spanning-tree mode rapid-pvst

Ø  Sw2(config)#spanning-tree mode rapid-pvst

Ø  Sw3(config)#spanning-tree mode rapid-pvst

Now our switches are running Rapid-PVST+, and they should be able to Convergence more quickly, we can confirm that we indeed are in Rapid-PVST+ Mode by saying

Ø  Sw1#show spanning-tree summary

                   And it says that the Switches in a Rapid-PVST Mode and remember, if our trunks are DOT1Q trunks that means we doing Rapid-PVST+, but it looks we running Rapid Spanning Tree Protocol for all our Vlan’s like we did with other Spanning Tree Protocol Variants, if we want to make Switch Sw1 the Root for Vlan’s 100 and 300, we can do that

Ø  Sw1(config)#spanning-tree vlan 100,300 root primary

Primary Root for Vlan’s 100 and 300, and we want to be secondary Root for Vlan 200

Ø  Sw1(config)#spanning-tree vlan 200 root secondary

Let’s go to Switch Sw3 and we say that, we want to be the Primary Root for Vlan 200

Ø  Sw3(config)#spanning-tree vlan 200 root primary

And we want to be the Secondary Root for Vlan’s 100 and 300

Ø  Sw3(config)#spanning-tree vlan 100,300 root secondary

And to confirm this, we can do

Ø  Sw3#show spanning-tree summary

And we can see that we are the Root for Vlan 200 and on Sw1 reissue the command.

Ø  Sw1#show spanning-tree summary

We see that, we are the Root for Vlan’s 100 and 300.

      

 Now let’s assume on one of these Vlan’s and take a look at different link-type we have, let’s do a

Ø  Sw1#show spanning-tree vlan 300

                           And because this is the Root for Vlan 300, you see the Port Roles is Designated Port for each of these Port’s meaning that our status is Forwarding, and the link-type are P2P, Point-to-Point, and the reason these link-type are Point-to-Point is that the Switch made that determination automatically by looking at Duplex of these ports, if we have a port in Full Duplex mode the assumption by the Switches is, we probably connected to a another Switch or may be a Router, and that’s gonna make the link-type P2P, if we were in Half Duplex Mode the Switches going to assume that we connected to a shared media segment, maybe we connected to an Ethernet Hub and that case link-type would be a Shared.

                        But here is a challenge may be, we connected to an End User Station like a PC or here we have a Phone plugged in a fastethernet 1/0/10, and that means fastetherent 1/0/10 should be considered an Edge Port, how we say that Port is an Edge Port.

If we wanted to specify that, this was a Shared link-type, instead of P2P link-type, here we can do that

Ø  Sw1(config)#interface fastethernet 1/0/13

Ø  Sw1(config-if)#spanning-tree link-type

                  Notice here, we have two option Point-to-Point and Shared, but there is no Edge Port option, we can do that to Shared, but I want to show you another approach to that.

Ø  Sw1(config-if)#duplex half

Ø  Sw1(config-if)#end

When we set Duplex to Half Duplex, let’s reissue the command on Sw1

Ø  Sw1#show spanning-tree vlan 300

                 Now look at this it’s says that the link-type is now Shared, the Switch assume that we are connecting into a Shared media Ethernet Hub, and we also want to change fastetherent 1/0/10 to be an Edge Port that connected to a IP Phone, let’s say that is an Edge Port, here we can configure that

                     We going to enable a feature, we going to be talking about more in our upcoming Topic, but its’ called Portfast, instead of plugging in a device to Switchport and waiting through the Listening and the Learning states before we transition to a Forwarding.

                   If we go into a port and say “spanning-tree portfast”, we telling that Switchport to “Mr. Switchport, we promise that we are connecting to you an End Devices”, it’s not something short of Switch that’s going to send any BPDU’s, it’s an End Station and as a result, please do not wait through the Listening and Learning State, here how we do that

Ø  Sw1(config)#interface fastethernet 1/0/10

Ø  Sw1(config-if)#spanning-tree portfast

And now use show command

Ø  Sw1#show spanning-tree vlan 300

                 And now look at this, this time it’s says this is an Edge Port, meaning that when we plugged that IP Phone into a Switch Sw1 fastetherent 1/0/10 interface, it doesn’t have to wait that 30-second’s period of time to Transition from Listening to Learning to a Forwarding.

                       It’s going to go active almost immediately and by the way, we do not have to be running Rapid-PVST+ and order to use that Portfast feature, that can be used with any of our flavors of Spanning Tree Protocol and we gonna be talking more about portfast in upcoming session.

             What this session done, is shown us how to very easily enable Rapid-PVST or Rapid PVST+ on our Cisco Catalyst Switches, we saw that we can influence Root Bridge Selection exactly as we done before, and we saw that Rapid-PVST or Rapid-PVST+ would attempt to automatically determine the appropriate link-type based on Duplex settings but we could go in and override that default settings, we would set the link-type to P2P or Shared. and we could also say that the Port was an Edge Port by enabling Portfast on that Port.

Join me on our next upcoming session about

Ø  Uplink Fast	Ø  BPDU Guard
Ø  Backbone Fast	Ø  BPDU Filter
Ø  Port Fast	Ø  Root Guard
	Ø  Loop Guard

  

        Click Here To Download the PDF File

               If You Like the Post. Don’t forget 

       to “Subscribe/Share/Comment”. Thank You.

Read More

Rapid-PVST+ Theory

             When we were talking about Spanning Tree Protocol earlier, we were talking about a potential 50 seconds delay, for a port to go from Blocking to Forwarding if there was a topology change in a network, and we also hinted in a previous topic that, there was a way to speed that up using a different flavor of Spanning Tree Protocol, called Rapid Spanning Tree Protocol and Cisco’s implementation of that is Rapid-PVST+, we using Rapid Spanning Tree Protocol but each Vlan can have a its own Instances of Rapid  Spanning-Tree Protocol working and,  then our next topic we were going to see, how to configure a Switch to run Rapid PVST+, but for now, we need to defined some terms to better understand

Ø How does it do it’s magic. How does it make things happens so quickly?

Ø We need to defined some terminology to help us to understand that

First let’s talk about some different Port Roles, and some of these are similar to different Port states.

                    We had with Traditional 802.1D Spanning Tree Protocol for example, we are still going to elect a Root Bridge and in this topology.

                      We see that Switch Sw1 has been elected as the Root Bridge, and we know that all the Ports on a Root Bridge are Designated Ports.

                     Remember every segment has one and only one Designated Port and “it’s the Port on that segment that’s closet to Root in terms of Cost”. We mentioned earlier that, we don’t get closer to Root, then actually being on the Root no difference here, we have couple of Designated Ports  on Switch Sw1, now let’s take a look at Switch Sw2, we still have the concept of the Root Port.

                   Remember “ a Root Port is a Port on Non-Root Bridge that was closest to Root in terms of Cost”,  and let’s assume that, Top Port on Switch Sw2 is the Root Port, we still have a Root Port with Rapid-PVST+, and we still might have a Port that is Administratively Shutdown, it’s not gonna be forwarding any data.

                         Notice the Designated Ports and the Root Ports they forwarding, our abbreviated that is “fwd.” The Disabled Port, it’s just down, it’s Administratively Shutdown, it’s not forwarding traffic on either, and on that link between Sw2 and Sw3, we need to have a Designated Port “it’s the Port that’s closet to Root in terms of Cost”, and if the Costs are equals we going to go with the end of the segment connected to Switch, with a lowest Bridge ID.

            And let’s assume that for our discussion, we will say that Switch Sw2 has an Alternate Port and Switch Sw3 has a Designated Port on that segment, and now let’s defined the terms Alternate for movement, we typically just referred to this as a Blocking Port when we talking about regular PVST+, now i am saying that we have an Alternate Port, and “Alternate Port as the name suggests, is an Alternate way of getting to the Root Bridge”.

                  Switch Sw3, it’s gonna have a Root Port and we were saying, it’s that Port going straight up to Sw1, but now where it gets interested, notice Sw3 has a couple of Ports connected to this HUB and since we have Two Port connected to this shared media HUB that means that both of these Ports are probably on the same Vlan and because we connected to a HUB that means that both of these Ports are on the same segment, where on the same shared Ethernet segment, and remember we can only have One Port on a segment that’s a Designated Port and we saying, it’s that First Port on Sw3 that goes up to the HUB but the other port going up to the HUB is labeled as a Backup Port.

                 That’s different then the Alternate Port, both an Alternate Port and a Backup Port are considered to be Ports “that would be Alternate ways of getting us to Root” but we only see a Backup Port then we have a Redundant link to a Shared segment, meaning that about the only time we would see a Backup Ports when we were connected to a Ethernet HUB and as a result, it’s unlikely we don’t gonna see a Backup Port in production networks but we need to know about it because it is the defined in the Standard.

        We also need to know about the Port States used by Rapid-PVST+ or Rapid Spanning Tree Protocol.

                    We got a Discarding State and a Port that in the Discarding State is gonna be Discarding data fames, by the way it’s not discarding a BPDU’s frames it’s still receiving those but it’s discarding data frames and we would see a Port Discarding data frames, if that were an Alternate Port, a Backup Port or a Disabled Port.

                             Another Ports State is Learning, Learning is when we Transitioning from the Discarding State to the Forwarding State, notice here, there is not a Listening State like we had with Traditional 802.1D Spanning Tree Protocol, there is no Listening State, there is a Learning Transitional State, and in the Learning State, a Switchport is Transitional to a forwarding State and it’s Learning Mac-Addresses that live of that Port.

                         And in the Forwarding State Data is being forwarded, Root Ports and Designated Ports, those Ports are in the Forwarding State, and there is one other set of terms that we need to understand before we get into the Configuration.

                          And those are the different link types we gonna have, we gonna see these link types as well as Port Roles, showing up in the output of show commands in our next topic.

Let’s make sure that, we understand, what these terms mean.

 First, we have a Point-to-Point link type.

                           You gonna probably guess that, a PPP link is interconnecting just 2 devices, it’s a link that’s in Full Duplex mode, and it typically interconnects couple of switches in this topology, we got 3 PPP links.

Another link-type is a Shared Link type.

                        Remember the HUB we talked about earlier, unlikely we don’t gonna see a HUB in today’s modern networks, but if we do and we connected to that HUB another word, we connected to a shared media segment, that link is a shared link type

                   And we probably, specially in the Wiring Clauses Switches going to have lots of port’s that connects out to end user stations like laptop’s or PC’s or Printer and Servers, here we can see in Switch Sw2 is connected to a Laptop, what kind of link type connects out to end station, well it’s called an Edge Port.

                      A Port that gets out to the that end station, we referred to that an edge port, and that Edge Port should never connected to another switch, when Rapid Spanning Tree Protocol is doing his calculations, it never considered an Edge Port as a candidate, to get this switch to back to the Root, and when we interconnect our switches, and our end Points and our Hubs may be we have a Half Duplex connection going out to a Hub, the Switch is going to default to a specific link type but we can override that link type Administratively if we want to, but here is an interesting thing.

                  If we go in and tell a Switch that a certain Port is an Edge Port but then later, we forget that we did that possibly, and we connect a Switch in to that Edge Port, well when that Port sees a BDPU arriving from that other Switch, it’s going to realize that it’s not an Edge Port, and it’s going to Transition out of that Edge Ports States, and now we talked about some of these terms, let’s think about how Rapid Spanning Tree Protocol Convergence in the event of a Topology Change.

                  First of all, let’s defined a Topology Change in Rapid Spanning Tree Protocol, when I say Rapid Spanning Tree Protocol, I am also talking about Rapid-PVST+, but Rapid Spanning Tree Protocol only considered a Topology Change to be a Port, that’s not an Edge.

                      Why would be not considered that to a topology change. Well let’s imagine that, a port on a Switch goes down, and there is a Switch connected of that Port, there is a Down Stream Switch another words, the act that Port going down itself does not triggered a topology change, let’s say that, the Down Stream Switch has no other way to get back to the Root, that was it’s only connection and that connection just went down, if that Down Stream switch doesn’t have a another way to get back to the Root, there is only nothing we can do about that, no need to disrupt all our switches to say that, this link went down.

                   However, if that down Switch does have an alternate path to the Root, it should transition its Alternate Port to a Forwarding State, the Active Transitioning is, it’s Alternate Port to a forwarding Port, that’s gonna cause in this example that Down Stream Switch to notify the other Switches in the topology that change is occurred.

In with Traditional 802.1D Spanning Tree Protocol

                         When a Topology Change occurred, the Switch experiencing that change would send a “Topology Change Notification” to the Root Bridge, and the Root Bridge would then send a “Topology Change Acknowledgement” back to the switch that reporting to Topology Change, and then the Root would set to “Topology Change Bit” inside of this BPDU’s, that it sends out to other switches, telling those other Switches that there had been a Topology Change causing them to update their Mac-Address Tables.

However, with Rapid Spanning Tree Protocol

                       We don’t have to notify the Root and get an Acknowledgement, and let the Root tell everybody else, if we are Switch Sw5 and we have experiencing a Topology change, we had a port that was an Alternate Port, now it’s Forwarding Port, we get to the directly tell,  other switches in the topology about that change, we can source the BPDU’s containing the Topology Change information, that can in some cases dramatically speed up Convergence Time,

Now in our next topic, let’s see how it set up Rapid-PVST+

 Click Here To Download The PDF File

               If You Like the Post. Don’t forget 

          to “Subscribe/Share/Comment”. Thank You.

Read More