Thursday, December 8, 2016

VLAN Theory

                            Let’s begin our discussion of Vlan’s and VTP and Trunks by reviewing the basics of Vlan’s, that we talk about back in our CCNA Studies, let’s remember what life is like without Vlan’s, instead of having Ethernet Switches we had Ethernet Hubs, and we would go into a building that would be a wiring closure on each floor of building, look like in this example on Picture.
                    Where we have couple of floors and if we wanted to separate departments that co-exists on floor, we would need to give each department their own Hub, here you notice that i got a Switch on floor2 dedicated to sales “S” represent Sales, i got another switch to represent Accounting “A” and same thing on floor1, i got a sales Switch and an Accounting Switch and if i have a 1st Accounting computer that was to talk to this 2nd Accounting computer, how traffic will go.
                  Well the traffic is gonna go into that Floor2 Accounting Switch, down to the Floor 1 Accounting Switch, then out to the 2nd Accounting computer.
                   If i want to talk between an Accounting and Sales, there in different subnets, notice this they going into a different Router Ports, i got a Port going to my Router “S” just for Sales, and other Port just for Accounting “A”. If i want to go from 1st Accounting computer to this 2nd Sales computer, how i do that.
                Well my Packet is going to go into the Accounting Switch on the Second Floor, then it would go down to the Accounting Switch on the First floor, then its gonna go out to the Router.
           Because we have to Route between subnets, their Router is gonna then route me to the Sales subnet and it’s gonna go up to the First-Floor Sales Switch, then it gonna go out to the Sales 2nd Computer on the First Floor.
                And i think it’s obvious that this type of solution doesn’t scale very well, i have only got 2 different departments. What if i had 5 Departments on each Floor, and i had 10 Floors. Suddenly, we have lots of Ethernet Hubs in this building, fortunately we can take Ethernet Switches and group the Ports into different Vlan’s, different Virtual Lan’s, Infect let’s do that with this topology, let’s have a single Switch on Floor2, and the single Switch on Floor1 and simply take the Ports on those individual Switches on Floors, and carved them up into the Separate Vlan’s.
                  Things are already starting to look better to this topology, we don’t have as many Switches on each Floor of Building, we able to support Multiple Subnet or Multiple Vlan’s on a single Switch, this 1st Accounting computer it’s going into a Switchport, that is part of the Accounting Vlan this 1st Sales computer it’s going into a Port that’s the part of Sales Vlan, and if wanted to send traffic from this 1st Sales Computer to this 2nd Accounting Computer what we can do.
                     We would go into our Sales Port on the Floor2 Switch, and still we assuming that we have a Port that’s going out for Sales, Port that’s going out for Accounting, we would go out of the Sales Port down to Switch, again we got an outgoing port for Sales, and Port for Accounting, we would go out of the Sales Port down to the Routers, we have Route between Vlan’s between subnets.
              We would go back into the Floor1 Switch, and we would go out to this 2nd Accounting Computer.
And by taking these Switches on each floor and carving the Ports into the separate Vlan’s.
Ø  We getting some Security
Ø  We get Vlan Separation
Ø  We get different Broadcast Domains.
       Infect we can often think of these terms synonymously, a Vlan typically equal a Subnet and equal to Broadcast Domain.
                    A Broadcast seen in the Accounting Vlan, it’s not gonna be seen in the Sales Vlan, and hopefully you can see where the discussion is going based on your CCNA Studies, even though we got Multiple Vlan’s on a Switch which is fantastic, we still have little bit scalability limitation here because we having to dedicate a Switchport to interconnect with another Switch just for the Sales Vlan, and another Port to connect to with another Switch just for the Accounting Vlan.
                         Later on, in this module we talk about the formation of a Trunk, remember what a Trunk does from your CCNA Studies, “a Trunk is going to allows to have a single connection between Switches and that single connection is gonna be able to carry traffic for multiple Vlans”.
                          What we gonna able to do is, replace these two connections with a Single Trunk connection, more on that later though for now, we focused on Vlan’s and, let’s take a look at a Cisco Catalyst 2960 Series Switch, and see how traffic might flow through that Switch, if we carved the Ports up into a couple of different Vlan’s.
                      Let’s say, that we have got PC attached to fastethernet 0/0/2 Port of my Cisco Catalyst 2960 series Switch, and let’s say that we have got a Server attached to fastetherent 0/0/24 Port and we imagine that these devices are in different subnets, we say that this PC is part of the 10.1.1.0/24 Subnet, and Server is part of 192.168.1.0/24 Subnet, we are in different subnet.
                              We have to Route to get between Subnets No Problem, we can attach a Router to this Layer2 Switch, keeping in mind that some of our Cisco Catalyst Switches are Multilayer or Layer 3 Switches they can do Routing internally, but here we imagine that we got this Router attached.
                 And this Router can go into the Switch with a single Trunk Connection, another words, traffic from Multiple Vlan’s can flow over that single connection, this is often time called a “Router on a Stick” or “Router on a Trunk connection”, and it’s going to allows to Route between Ports that belong to different Vlan’s on the Switch, let’s say that these (0/0/1-0/0/12) Layer 2 Ports are part of Vlan 100, and these (0/0/13 – 0/0/24) Ports are part of Vlan 200.

And let’s remember why we might want to have Vlan Separation
Ø  It can help us with performance to breakout Broadcast domains
Ø  It can help us to with Security, that way we don’t have a somebody on our Vlan doing a packet capture of Unknown unicasts, multicasts and Broadcast on our subnet, there are not able to see in capture these packets because they belong to different Vlan and the different Broadcast Domain.
 Those are couple of design reason of Performance and Security that we might want to break thinks up into a different Vlans but let’s ask the question, how does the PC talk to the Server they are in different Subnets, here the way packet flow goes.
                        This PC is gonna send a packet out destined for Server and it’s going to go into the ingress Switchport, it’s gonna flow across the switches Fabric another word, across the Switch backplane over to this Trunk port.
It’s gonna flow down to the Trunk to the Router.
                      The Router gonna realize that this, Packet needs to gonna go to Vlan 200 and it’s gonna send a back up to Trunk, for its once again, going to flow over the Switch backplane and go to the egress Ports, this time and we gonna go out to the Server.
                  That’s the way that even with a Layer 2 Switch, we can have traffic forwarding between different Vlan;s between different Subnets, and now we talked about Vlan Operation and Theory on this topic, in our next topic, let’s review how e Configure and Verify Vlans.


                   If You Like the Post. Don’t forget 
            to “Subscribe/Share/Comment”. Thank You.
Read More

Monday, December 5, 2016

Features that Increase STP Stability


                       In our previous topic, we talked about a collection of Spanning Tree Protocol features that could help to reduce the Convergence Time with a Spanning Tree Protocol, what here in this topic, we wanna talk about another collection of Spanning Tree features, this time though these features are design to helping increase the stability of the Spanning Tree, and by increasing the stability we talking about things that might help prevent a layer 2 Loop is in example, we got 4 features we wanna talk about in this topic.
The first one is BPDUGuard
                 And this is gonna work typically handed hand with Portfast that we talked about in the previous session, we gonna see this can add some extra Loop Prevention Protection on a port that configured for Portfast, if we accidentally plug in a Switch to that Port, that might potentially cause a loop.
Then we gonna take a look at BPDUFilter
                   And this is an interesting one because normally we think BPDU’s are good think they can help prevent loops but there is a time, we might want to filter out and not send those BPDU, we will see how to do that.
Next, we take a look at Root Guard
                      Let’s imagine that, we got a Spanning Tree Topology and you know that this(SwA) is gonna be a primary Root Bridge and this(SwB) is gonna be secondary Root Bridge, and you don’t want any other Bridges ever becoming the Root, you don’t want somebody accidently or intentionally introducing the Switch on the network with a Superior BPDU and try to take over the Role of the Root, well what we can do is say “if there is a switch of a specific ports claiming to be the Root, we not going to believe that switch”, and feature that often gonna be configured along with Root Guard, is a LoopGuard
                  LoopGuard is another Loop prevention mechanism as you might be able to guess by name but it can help us out to situation for example where, “we have a Unidirectional Link, that stop receiving BPDU’s from a Designated port on a segment, that must mean it’s OK for us to go active, not necessary maybe we have a Unidirectional link failure”, Loop Guard can help us to protect from that.
                     Let’s get ride into a discussion of first of these features BPDU Guard. BPDU Guard can work handed hand with Portfast, remember with Portfast, we can tell an Access Port that, it should not go through the Listening and Learning state, if the device connected to that Port, we were essentially saying “Mr. Port, i promise, i am only going connect End Station”, “i am not going to connect Switch or anything else that might cause a loop”, so please don’t make, a connect device wait through 15 seconds of Listening and 15 Seconds Learning, let’s go active almost immediately, an addition to doing that, Portfast has a Loop prevention mechanism built in, if we have a port enabled for Portfast, and its sees BPDU coming on that port, it realizes that it’s been lying too, it looks like somebody attached a switch to this port and when Portfast starts to see these BPDU’s, it can start Blocking however, it doesn’t happen instantly, there can be a brief time where we do have a loop, and BPDU Guard can help prevent that, temporarily loop that we could have during that time that a Portfast, port transitions into Blocking.
                     And we can enable this globally or we can do a port by port bases, if we enable it Globally, it’s only going to apply to ports that have Portfast enable and we said that, what is gonna do is immediately start Blocking Traffic, we going to specifically go into a “Err-Disabled State” on that port if we receive a BPDU because that Port has been configured for Portfast.
                      We promised, we are not going to attach anything that should be sending a BPDU, if we see that very first BPDU, BPDU Guard is gonna shut that Port down, and go into a Err-Disabled State.
                     By the way how do you recover from an Err-Disabled State, after you correct the issue that was causing a problem, and the first place a way to come out the Err-Disabled State is, to simply some people call it, Bouncing the Port, what i mean by that is, we go into interface Configuration mode and we do a “Shutdown” followed by “No Shutdown”, we administratively take it down, bring it backup, and of the condition causing the error is no longer there, that’s gonna clear out the Err-disabled State, if you take a look at the topology on picture
                   We got port fastetherent 1/0/1, that has Portfast enabled, and if we connect end station.
                    To that port great, that’s really, we intended for, we might have a Laptop with an SSD, instead of regular spinding Hard Disk Drive, it might boot up very very quickly and it might send out a DHCP Broadcast and if Portfast were not enabled, it might not able to obtain an IP Address because that port is not yet active, if it’s sending out that DHCP Broadcast, however, if we accidently or somebody intentionally plugs in a Switch to this port that Switch Sw5 in this case, is gonna be sending BPDU.
                        And which that first BPDU is seen on that port because we now have BPDU Guard enabled that port is immediately go into an Err-Disabled State.
                     Now we understand the theory of BPDU Guard, what it trying to accomplish let’s take a look at configuration of BPDU Guard.
                    That’s how to enable this on interface bases but we can enable it globally, we could say in global configuration mode.
And Verification command, we can issue is

                 Our Next Spanning Tree stability feature is BPDUFilter, and normally we like BPDU, we want BPDU’s to be exchanged between our Switches because the BPDU’s help us to make a Loop-free Spanning Tree topology, what BPDUFilter can do is, prevent a port from sending BPDU’s and we can enable this on a Port by Port bases or we can enable it globally and if we enable it globally, it’s going to apply to ports that have Portfast enabled
                  But the big question is when should we use this, Cisco cautions us, we should only use BPDUFilter when necessary, well when would something like this be necessary, i have sketched on picture here.
                    A couple of different Autonomous System, remember what an Autonomous System is, Autonomous System is simply a network under a single administrative control, these 2 Autonomous System A and B, they could be your company and your Service Provider if you have a Layer 2 Ethernet connection with your Service Provider or maybe its within your Company you got 2 different Department that have their own IT Staff, they manage their own Switches that configure the own STP parameters but they still need to interconnect.
                    Well maybe you don’t want to be exchanging Spanning Tree information between these 2 different Autonomous System, even with in the same company, BPDUFilter can be used to do that, BPDUFilter can be used to prevent one Autonomous System from sending BPDU’s into another Autonomous System, and i mentioned that we could enable this at the Port level or Globally, the behavior is actually bit different and its most dangerous, were in most danger of creating a loop if we enabled this at the Port level.
                     We will talk about the distinguish when we get into the configuration in a movement, but let’s visualize what this might do for us, if we setup the BPDUFilter may be on Switch C in an Autonomous System A.
                   That port on SW C, it’s not going to be able to send out a BPDU, it’s not gonna get down to Autonomous System B, because BPDUFilter is going to filter that out, but think about this, what if Switch D in Autonomous System B were sending a BPDU into a Switch C, with that BPDUFilter that we configured for Switch C, would it ignore that BPDU coming from Switch D.
                  Well the answer of that depends on how we configure it, do we configure it at Port level or do we configure it globally, let’s take a look at configuration and talk about the different behaviors that we get from Port by Port Configuration vs Global Configuration.
First here, how we set it up at the Port Level
                            Here what that does, when we set this up the Port level, it’s very plain and simple, we telling that port do not send any BPDU’s and if you receive any BPDU’s ignore them, and that could be a bit dangerous because we ignoring any incoming BPDU’s, we receiving BPDU indicating that we were connecting to a Switch and we just ignoring those, we might get into Loop Situation, it’s safer if we enable this globally, here how we do that we say.
                      And here what happened if we enable it globally, The Switch is bit more curious, the Switch says “ if i receives BPDU’s on one of these Portfast ports that have been globally enabled for BPDUFilter, if one of those ports receives the BPDU that Ports is gonna lose its Portfast status, so in this case, we not ignoring incoming BPDU’s instead incoming BPDU’s their viewed as warning, look at, we got a Switch attached to the this port maybe we shouldn’t be on Portfast mode anymore, and we gonna transition out of Portfast mode.
                     Infect, when that port first comes up it’s going to try to seek out and see, we have any attach devices that would be sending us BPDU’s and its gonna send “10 BPDU’s of its own”, and if it receives any BPDU’s in returned then it’s going to say “No! we should not be a Portfast Port, and we gonna transition out of the Portfast Mode”, to see if we have a BPDUFilter enabled or not, we can give the command.
                    We can see how many BPDU we sent/received, after we enable the BPDUFilter, the number of BPDU has been sent that should not be incrementing anymore because we are not gonna be sending any additional BPDU’s.

###############################################################
#             Take a Break of Tea/Coffee, then we will go to next feature            #
###############################################################

                   Our next feature is Root Guard, with Root Guard we want to prevent somebody from intentionally or accidentally adding a Switch to network that might send us a superior BPDU and claim to be the Root, for example, i got couple of Switches on Picture.
                   That i don’t mine, if they become the Root, Sw1 that’s gonna be my Primary Root Bridge and Sw2 is gonna be my secondary Root Bridge, however, i would not want Sw3 to become the Root, and we have enable the Root Guard on the bottom ports of Sw1 and Sw3 to say “if i receive the superior BPDU coming into this port, we are not gonna believe”, we gonna go into a Root-inconsistent State, here how we set it up, we gonna configure Ports, that should not connect us to the Root Bridge, and if we do receive us a superior BPDU coming in one of those ports, this ports is gonna start Blocking traffic, Specifically its gonna go into a Root-Inconsistent State.
                 So, let’s imagine that “Sw3 does send a superior BPDU up to Switch Sw1”, when it (Sw1) gets that superior BPDU, it says “i am enable for RootGuard this is a superior BPDU and i am not gonna trust that”, instead i am going to transition this port to a Root-inconsistent State.
                      Until those superior BPDU stop, and as soon as they stop we transition out of the Root Inconsistent State, we don’t have to administratively do anything to recovered from that like we did with the Err-Disabled State, now let’s see how to set this up, Root Guard is only going to be configured at the Port level, you would not want to be Globally enable it, but we going to strategically go into those ports, of a which we would not expect to see the Root Bridge, here we gonna go into interface
                    We would do that all of the ports, of which we would not expect to see the Root Bridge, if we did have a port, that was in the Root-Inconsistent State, here how we can be determined that we could say
   This example, its look like interface fastetherent 1/0/2 is in the Root-Inconsistent State.

                     And our Final feature that, we wanna to talk about in this topic is Loop Guard, this is something that we want to configure in conjunction with Root Guard, what’s its gonna do is, cause a Non-Designated Port to enter a Loop-Inconsistent State which is Blocking State, if it’s stop receiving the BPDU.
                 Here why we do that, normally on a network segment a Designated Port is gonna be sending out BPDU’s and the Non-Designated port receives the BPDU’s, now this Non-Designated Port stops receiving the BPDU’s, it’s assume that the topology is Loop free and it’s start to transition to the forwarding State if it were Blocking.
                    However, maybe its stopped receiving BPDU’s not because, we have a Loop-free topology, may be have in one example, “a Unidirectional link, and if we have Unidirectional Link may be, we were not receiving BPDU’s but we can still send them”, we could create a one way Loop around this topology however, with LoopGuard enabled when the Non-designated  Ports stops receiving BPDU’s it transition into a Loop- Inconsistent state where it blocks traffic, and its gonna remain that state until, it receives the BPDU and then it automatically transitions to the appropriate state maybe Blocking or maybe Forwarding, based on that BPDU and we can enable this on a Port by Port bases, we would probably do that on all ports that did not have a Root Guard enabled if we were using Root Guard or we can turned this on Globally and if we turned it globally, it’s going to apply to all Point-to-Point links.
                      Let’s visualize how this might help us out. On picture notice, we have a link between Sw2 and Sw3 and the port on Sw3 is currently Blocking but we know that every network segment has a Designated Port and that Designated port, in this case is Switch Sw2 fastethernet 1/0/2 interface and let’s say that, we have a Unidirectional Link Failure, we have something like we talked about earlier called a Backhoe fade, here comes big Backhoe Fade into the network and it damaged the Fiber Optic Cable.
                  i am no longer able to receive traffic from Sw2 but we can send traffic and that can cause a Loop if we did not have a Loop Guard enabled, but we do Switch Sw3 says “i am no longer receiving BPDU’s on this link, so i am going to enter Loop-Inconsistent State”.
Let’s see how to set this up, first we can go into Interface Configuration Mode
            That will enable it Port by Port, and to enable it Globally we would say
And to see its enabled or not, we can give Verification Command

                 And you can see the second line of output of bottom it says LoopGuard default, it is enabled that only can force Spanning Tree Protocol feature that can help us increase the stability of our Spanning tree topology, we talked about BPDUGuard, BPDUFilter, RootGuard and the LoopGuard.

That’s the last session of this Spanning Tree Module, now in our upcoming module we will discuss about VLAN’s


                 If You Like the Post. Don’t forget 
         to “Subscribe/Share/Comment”. Thank You.

Read More

Wednesday, November 30, 2016

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


                 If You Like the Post. Don’t forget 
         to “Subscribe/Share/Comment”. Thank You.
Read More