The Bryant Advantage CCNP SWITCH Study Guide - Ebook download as PDF File .pdf), Text File .txt) or read book online. Free PDF's. Post navigation. ← Paid PDF's Free CCNA Course · Free CCNP ROUTE & TSHOOT Course · Free CCNP SWITCH & TSHOOT Course · Free. the bryant advantage ccnp pdf the bryant advantage ccnp switch study guide Earn your CCENT, CCNA, CCNP, and Security certifications with Chris Bryant.
|Language:||English, Japanese, French|
|Genre:||Fiction & Literature|
|ePub File Size:||17.37 MB|
|PDF File Size:||8.55 MB|
|Distribution:||Free* [*Registration needed]|
Free videos and tutorials, Study Guides, flash cards, and practice exams. Home - The Bryant Advantage. The Bryant Advantage CCNP SWITCH Study Guide Pdf. Chris Bryant's Ccnp Route Study Guide Pdf security certification lessons covered by other authors the bryant advantage ccnp switch study guide. The Bryant Advantage CCNP ROUTE Study Guide Pdf - eBook PHP The CCNP SWITCH exam is the first hurdle between you and the CCNP, and my.
The only place you'll probably see that full phrase is on the exam. We'll now change that by placing this switch into a domain called CCNP. Watch this command - it is case sensitive. What are the other reasons? You'll see later in this section.
Let's get that VTP domain set Each switch can now successfully advertise its VLAN information to the other, and as switches are added to this VTP domain, those switches will receive these advertisements as well.
A Cisco switch can belong to one and only one VTP domain. It's not unusual for edge switches such as SW1 and SW3 to be available to more people that they should be.
This is the default setting for Cisco switches. Bear with me here. The first reason was a mistyped password - and number three is coming up. This mode can come in handy in certain situations, but be aware of the differences between Transparent and Server mode.
VTP Version 1: The Transparent switch will forward that advertisement's information only if the VTP version number and domain name on that switch is the same as that of downstream switches. SW1's configuration and the resulting output of show vtp status is shown below.
Also, switches do not advertise their VTP mode. You have to decide this for yourself in your production network, but I will share a simple method that's always worked for me - if you can physically secure a switch, make it a VTP server. If multiple admins will have access to the switch, you may consider making that switch a VTP Client in order to minimize the chance of unwanted or unauthorized changes being made to your VLAN scheme.
The only devices that need the VTP advertisements are other switches that are trunking with the local switch, so VTP advertisements are sent out trunk ports only. VTP advertisements are sent when there has been a change in a switch's VLAN database, and this configuration revision number increments by one before it is sent. To illustrate, let's look at the revision number on Sw1.
The current revision number is 1. We'll now go to R2 to check the revision number, add a VLAN, and then check the revision number again. The revision number was 1, then a VLAN was added. The revision number incremented to 2 before the VTP advertisement reflecting this change was sent to this switch's neighbors. Let's check the revision number on SW1 now. The revision number has incremented to 2, as you'd expect. But what exactly happened? Before accepting the changes reflected in the advertisement, SW1 compares the revision number in the advertisement to its own revision number.
Cisco seems to have changed their minds about getting rid of this mode, and while you probably won't see it on your exam, it's a good idea to know these details for dealing with real-world networks. VLAN Design Learning to design anything from a class or study guide can be frustrating, because like snowflakes, no two networks are alike. What works well for "Network A" may be inefficient for "Network B". You need to know about the following VLAN design types for both the exam and the real world, but as always you've got to be able to apply your critical thinking skills knowledge to your particular real-world network's needs.
With VLAN design, we're looking at much the same scenario. If we don't control broadcast and multicast traffic, it can soon affect our network negatively, particularly if we allow it to flow through the core switches. Your VLAN scheme should keep as many broadcasts and multicasts away from the core switches as is possible.
There are two major VLAN designs, end-to-end and local.
The physical location of the user does not matter, as a user is assigned to a single VLAN, and that VLAN will remain the same no matter where the user is. End-to-end VLANs must be accessible on every access-layer switch to accommodate mobile users. Many of today's networks don't lend themselves well to this kind of configuration. Local VLANs assume that 20 percent of traffic is local in scope, while the other 80 percent will traverse the network core.
Let's take a look at the situation first and then come up with a solution. Let's say you've been practicing on a Cisco switch and decide to erase the config. You were working with three VLANs You run write erase to erase the switch startup config and then reload the switch SW1 write erase Erasing the nvram filesystem will remove all configuration file firm] [OK] Erase of nvram: Initalized the geometry of nvram SW1 reload Proceed with reload?
Would you like to enter the initial configuration dialog? After answering no, we're placed at the user exec prompt. We put a few basic commands on the switch The first time you run into this, you might think you somehow erased the config incorrectly, so you do it again. At least I did. DAT file, contained in Flash. For clarity's sake, I've removed the date you'll see next to each file name.
SW1 show flash Directory of flash: The command to do so isn't difficult at all, but the prompt is a little tricky. The command is delete vlan. SW1 delete vlan. As you'd expect, you're asked whether you really want to delete that particular file.
The Bryant Advantage CCNP SWITCH Study Guide
Do NOT answer "yes" or "y" - just hit the Enter key to accept the default answer contained in the brackets. After you do that, you're asked one more question: Delete flash: Again, don't answer "Y" or "yes" - just accept the default answer by hitting the Enter key.
If you don't have a vlan. And you're right, I did - and here's why: After deleting the vlan. SW1 show vlan brief VLAN Name 1 default fddi-default token-ring-default fddinet-default trnet-default.. All Rights Reserved. In our first example, we'll look at a simple two-switch setup and then add to the network to illustrate the importance of VTP.
Here, the only two members of VLAN 10 are found on the same switch. We know that the chances of all the hosts in a VLAN being on one switch are very remote! More realistic is a scenario like the following, where the center or "core" switch has no ports in a certain VLAN, but traffic destined for that VLAN will be going through that very core switch. Considering that most networks have a lot more than three switches, statically configuring every VLAN on every switch would soon take up a lot of your time, as would troubleshooting the network when you invariably leave a switch out!
Chris Bryant, CCIE #12933 http://www.thebryantadvantage.com
Luckily, the major feature of VTP is the transmission of VTP advertisements that notify neighboring switches in the same domain of any VLANs in existence on the switch sending the advertisements. The key phrase there is "in the same domain". By default, Cisco switches are not in a VTP domain. Before working with VTP in a home lab or production network, run show vtp status.
The official term for a VTP domain is "management domain", but we'll just call them domains in this section. The only place you'll probably see that full phrase is on the exam. We'll now change that by placing this switch into a domain called CCNP.
Watch this command - it is case sensitive. What are the other reasons? You'll see later in this section. Let's get that VTP domain set Each switch can now successfully advertise its VLAN information to the other, and as switches are added to this VTP domain, those switches will receive these advertisements as well. A Cisco switch can belong to one and only one VTP domain. It's not unusual for edge switches such as SW1 and SW3 to be available to more people that they should be.
This is the default setting for Cisco switches. Bear with me here. The first reason was a mistyped password - and number three is coming up. This mode can come in handy in certain situations, but be aware of the differences between Transparent and Server mode. VTP Version 1: The Transparent switch will forward that advertisement's information only if the VTP version number and domain name on that switch is the same as that of downstream switches.
VTP Version 2: The Transparent switch will forward VTP advertisements via its trunk port s even if the domain name does not match. SW1's configuration and the resulting output of show vtp status is shown below. Also, switches do not advertise their VTP mode. You have to decide this for yourself in your production network, but I will share a simple method that's always worked for me - if you can physically secure a switch, make it a VTP server.
If multiple admins will have access to the switch, you may consider making that switch a VTP Client in order to minimize the chance of unwanted or unauthorized changes being made to your VLAN scheme. The only devices that need the VTP advertisements are other switches that are trunking with the local switch, so VTP advertisements are sent out trunk ports only.
VTP advertisements are sent when there has been a change in a switch's VLAN database, and this configuration revision number increments by one before it is sent.
To illustrate, let's look at the revision number on Sw1. The current revision number is 1. We'll now go to R2 to check the revision number, add a VLAN, and then check the revision number again.
The revision number was 1, then a VLAN was added. The revision number incremented to 2 before the VTP advertisement reflecting this change was sent to this switch's neighbors. Let's check the revision number on SW1 now. The revision number has incremented to 2, as you'd expect.
But what exactly happened? Before accepting the changes reflected in the advertisement, SW1 compares the revision number in the advertisement to its own revision number. In this case, the revision number on the incoming advertisement was 2 and SW1's revision number was 1.
In the following example, SW2 is sending out an advertisement with revision number The three switches are running VLANs 10, 20, 30, 40, and 50, and everything's just fine. Now, a switch that was at another client site is brought to this client and installed in the CCNP domain. The other switches will receive a VTP advertisement with a higher revision number than the one currently in their VTP database, so they'll synchronize their databases in accordance with the new advertisement.
I've seen this happen with switches that were brought it to swap out with an out-of-service switch. That revision number has to be reset to zero! If you ever see VLAN connectivity suddenly lost in your network, but the switches are all functional, you should immediately check to see if a new switch was recently installed. If the answer is yes, I can practically guarantee that the revision number is the issue. Cisco theory holds that there are two ways to reset a switch's revision number to zero: Change the VTP domain name to a nonexistent domain, then change it back to the original name.
In reality, resetting this number can be more of an art form than a science. The method to use often depends on the model. In the real world, you should use your favorite search engine for a phrase such as reset configuration revision number zero followed by the switch model. In short, every time you introduce a switch to your network and that switch didn't just come out of the box, perform this reset.
And if it did come out of the box, check it anyway. I'm sure you noticed that there are different types of advertisements!
There are three major types of VTP advertisements - here's what they are and what they do. Information included in the summary advertisement: Subset ads give specific information regarding the VLAN that's been changed, including: Why would a client request this information?
Most likely because the VLAN database has been corrupted or deleted. Let's take a look at both, starting with the VTP password.
Earlier in this section, you saw how to place a switch into a VTP domain: The VTP mode is changed with the vtp mode command. VTP allows us to set a password as well. Naturally, the same password should be set on all switches in the VTP domain. Although this is referred to as secure VTP, there's nothing secure about it - the command show vtp password displays the password, and this password can't be encrypted with service password-encryption.
And as you've likely already guesses, a mistyped VTP password is the third of the three reasons your VLANs aren't being properly advertised. To recap: Mistyped VTP Domain by far the most common reason 2. Not realizing you have a Transparent mode VTP switch in your network rare 3. A trunk port will forward broadcasts and multicasts for all VLANs it knows about, regardless of whether the remote switch actually has ports in that VLAN or not!
The Bryant Advantage CCNP SWITCH Study Guide
Both switches are transmitting and receiving broadcasts and multicasts that they do not need. Configuring VTP Pruning allows the switches to send broadcasts and multicasts to a remote switch only if the remote switch actually has ports that belong to that VLAN. This simple configuration will prevent a great deal of unnecessary traffic from crossing the trunk.
Note that SW1 had to be changed to Server mode in order to enable pruning. Verify that pruning is enabled with show vtp status. Enabling pruning on one VTP Server actually enables pruning for the entire domain, but I wanted to show you that a switch has to be in Server mode to have pruning enabled.
It doesn't hurt anything to enter the command vtp pruning on all Servers in the domain, but it's unnecessary. Stopping unnecessary broadcasts might not seem like such a big deal in a two-switch example, but most of our networks have more than two switches!
Consider this example: Without VTP pruning, that's exactly what will happen! Using VTP pruning here will save quite a bit of bandwidth. I'd like to share a real-world troubleshooting tip with you here. If you're having problems with one of your VLANs being able to send data across the trunk, run show interface trunk. Make sure that all vlans shown under "vlans allowed and active in management domain" match the ones shown under "vlans in spanning tree forwarding state and not pruned".
It's a rarity, but now you know to look out for it! The next version was Version 2, and that's the default on many newer models, including the Cisco switches run in Version 1 by default, although most newer switches are V2-capable. If you have a V2-capable switch in a VTP domain with switches running V1, just make sure the newer switch has V2 disabled.
The version can be changed with the vtp version command. Every switch in the domain must have a matching password. CCIE Pretty secure, eh? CCIE That's something to keep in mind! Unless you have a very good reason to put a switch into Transparent mode, stick with Server and Client.
Not only does this ensure that the VTP databases in your network will be synchronized, but it causes less confusion in the future for other network admins who don't understand Transparent mode as well as you do.
Some campus networks will have switches that can be easily secured - the ones in your network control room, for example - and others that may be more accessible to others. Your VTP Servers should be the switches that are accessible only by you and a trusted few.
Don't leave every switch in your VTP domain at the default of Server, or you've made it possible to create and delete VLANs on every switch in your network.
Copyright The Bryant Advantage.
A single point of failure just isn't acceptable today, so we're going to spend quite a bit of time in the SWITCH course learning how to create that redundancy when it doesn't already exist. That's a desirable behavior with routing. With switching, those redundant paths need to be ready to be put into action in case the primary path fails, but they won't be used in addition to the primary path.
If you recently earned your CCNA, much of the first part of this section will seem familiar. If it's been a while since you studied STP, we'll get you back up to speed quickly - and then we'll all dive in to advanced STP features. The source MAC address is the first thing the switch looks at on incoming frames.
As the switch builds the MAC table, it quickly learns the hosts that are located off each port. But what if the switch doesn't know the correct port to forward a frame to? What if the frame is a broadcast or multicast? Glad you asked! Unknown unicast frames are frames destined for a particular host, but there is no MAC address table entry for that destination. Unknown unicast frames are forwarded out every port except the one they came in on.
Under no circumstances will a switch send a frame back out the same port it came in on. Broadcast frames are destined for all hosts, while multicast frames are destined for a specific group of hosts. Broadcast and multicast frames are also forwarded out every port except the one they came in on. Known unicast frames are frames destined for a particular host, and this destination has an entry in the receiving switch's MAC table.
Since we know the right port through which to forward the frame, there's no reason to send it out all ports, so this frame will be unicast via that port listed in the MAC table. To review: Unknown unicast, broadcast, and multicast frames are forwarded out all ports except the one upon which they were originally received Known unicast frames are unicast via the port listed in the MAC address table That all sounds nice and neat, right?
For the most part, it is. But as we all know, production networks are rarely nice and neat. We don't want to have only one known path from "Point A" to "Point B". We want redundancy - that is, if one path between two hosts is unusable, there should be a second path that is almost immediately available. The problem is that with redundant links comes the possibility of a switching loop. What if you decide to turn it off? Let's walk through what would happen in a switching network with redundant paths if STP did not exist.
Now this is redundancy! We've got three separate switches connecting two ethernet segments, so even if two separate switches become unavailable, these hosts would be able to communicate.
But we better have STP on to prevent switching loops. If we didn't, what would happen? None of the switches know where Host C is yet, so the switches will follow the default behavior for an unknown unicast address - they will flood the frame out all ports except the one it came in on.
Just this quickly, without STP, we have a switching loop. The frames are just going to keep going in circles, and that's why we call it a switching loop, or bridging loop. Switching loops cause three problems: It might not have been well-known to you before, but it is now! We've actually got two different BPDU types: The Root Bridge is the "boss" of the switching network - this is the switch that decides what the STP values and timers will be.
The BID has the priority value listed first. For example, if a Cisco switch has the default priority value of 32, and a MAC address of , the BID would be Therefore, if the switch priority is left at the default on all switches, the MAC address is the deciding factor in the root bridge election. Is that a bad thing? Cisco switches are equal, but some are more equal than others.
In any network you're going to have switches that are more powerful than others when it comes to processing power and speed, and your root bridges are going to have a heavier workload than the non-root bridges. Bottom line: Your most powerful switches, which are also hopefully centrally located in your network, should be your root bridges. Note that I said "root bridges".
Not only can we as the network admins determine which of our switches will be the primary root bridge, we can also determine the secondary root bridge - the switch that will become the root bridge if the primary root bridge goes down. After we take a look at the important defaults of the root bridge election, along with several examples, I'll show you exactly how to configure any given Cisco switch in your network as the primary or secondary root bridge.
As the network admins, it's you and I that should decide this election, rather than The Default Root Bridge Election Process 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.
In this example, we'll look at a three-switch network and the Root Bridge election from each switch's point of view. Each switch is running the default priority of , and the MAC address of each switch is the switch's letter 12 times.
Through the magic of technology, all three switches are coming online at the same time, all three believe they are the root bridge, and all three get very busy announcing that fact. Since each of these switches believe it's the root bridge, all six ports in this example will go to the listening state, allowing it to hear BPDUs from other switches.
More about those STP states later in the course - let's focus on the election for now. SW C is in the same situation. Even though these switches have quickly agreed that SW A is the root, this election really never ends.
To see the local switch's BID, as well as that of the current root bridge, run show spanning-tree vlan x. We'll run this command with another network topology, this one a simple two-switch setup with two trunk links connecting the switches. The highlighted text is one - what are the other three?
As you'd expect, the root port is the port a switch will use to reach the port. The root bridge doesn't need a root port, and therefore will not have one All ports are in Forwarding FWD mode.
What do things look like on the non-root bridge, you ask? Let's take a look at the same command's output on SW2. One is highlighted. What are the other three? Notice that only one port in our little two-switch network is in blocking mode, and in this case that's enough to leave only one available path between the switches. No ports on the root bridge will be put into blocking mode. The port that SW2 is using to reach the root bridge is called the root port, and it wasn't selected at random.
Each switch port has an assigned path cost, and this path cost is used to arrive at the root path cost. Yes, I hate it when two different values have practically the same name, too.
Here's a very short chart to help you keep them straight: Path cost: Assigned to an individual port. Strictly a local value and is not advertised to upstream or downstream switches. A port's Path Cost is assigned in accordance with the speed of the port - the faster the port, the lower the Path Cost.
Root path cost: Cumulative value reflecting the overall cost to get to the root. Is advertised to downstream switches via BPDUs. A port's Path Cost is locally significant only and is unknown by downstream switches. That new root path cost value will be reflected in the BPDU that switch then sends out.
The Path Cost is locally significant only. In the previous example, SW3 doesn't have any idea what the Path Cost on SW2's receiving interface is, and doesn't particularly care.
Let's go back to our two-switch example Let's run show spanning-tree vlan 1 again to see what the deciding factor was. That's the default cost for a Mbps port. Remember, the port cost is determined by the speed of the port. Here's the process of choosing a Root Port, and how these steps factored into SW2's decision-making process. Choose the port receiving the superior BPDU. Choose the port with the lowest Root Path Cost to the root bridge. That's a tie here, too. Since the same switch is sending both BPDUs, that's a tie here as well.
Choose the lowest sender Port ID. That was the tiebreaker here. Both ports on SW A will be in forwarding mode, since this is the root bridge. STP isn't quite done, though. Let's add a host to that segment to see why a designated port needs to be chosen.
Let's say that host is transmitting frames that need to be forwarded to SW A. There are two switches that can do this, but to prevent switching loops from possibly forming, we only want one switch to forward the frames.
That's where the Designated Port DP comes in. The switch that has the lowest Root Path Cost will have its port on this shared segment become the Designated Port. Of course, there's a chance that both switches in this example would have the same Root Path Cost. Additionally, all ports on the root bridge are considered Designated Ports.
Here's a clip from show spanning vlan 1 on our root bridge: Assuming that SW B has a priority of It's interesting to note that of the six ports involved in our example, five are in forwarding mode and only one is blocked - but placing that one particular port into blocking mode prevents switching loops from forming. Now we know how root bridges are elected - but this knowledge brings up a couple of interesting questions.
What if our least powerful switch is elected as the root bridge? What if a switch on the very edge of the network is elected? That's likely to be one of our least powerful switches, too. What if we later add a more powerful switch and would now like to make that new switch the root bridge? The bottom line: The MAC address of the switches in our network should not determine the location of the primary and secondary root switches. We - the network admins - should. We have two separate commands that we can use for this: In the meantime, let's have a quick Zen lesson Whether it's for a job interview, a practice exam, or the CCNP SWITCH exam itself, you have to be careful not to jump to the conclusion that the physically shortest path is the logically shortest path.
However, the link speeds will tell a different story. A nonroot bridge will always select the path with the lowest cumulative cost - and here, that path is the physically longest path. Changing A Port's Path Cost Like other STP commands and features, this is another command that you should have a very good reason for configuring before using it.
Make sure to add up the Root Path Cost for other available paths before changing a port's Path Cost to ensure you're getting the results you want Let's take this one step further. Right now on this switch, we have VLANs 1, 20, and We can do this by specifying the VLAN in the cost command. Again, be careful when adjusting these costs - but properly used, this can be a powerful command for exercising total control over the path your switches use to transport data for a given VLAN.
A port doesn't go from Blocking to Forwarding immediately, and for good reason - to do so would invite switching loops. Cisco does officially consider this to be an STP state, though. A disabled port is one that is administratively shut down.
A disabled port obviously isn't forwarding frames, but it's not even officially taking place in STP. Once the port is opened, the port will go into blocking state. As the name implies, the port can't do much in this state - no frame forwarding, no frame receiving, and therefore no learning of MAC addresses.
About the only thing this port can do is accept BPDUs from neighboring switches. A port will then go from blocking mode into listening mode. The obvious question is "listening for what? A port in listening mode still can't forward or receive data frames, and as a result the MAC address table is not yet being updated.
When the port goes into learning mode, it's not yet forwarding frames, but the port is learning MAC addresses by adding them to the switch's MAC address table. The port continues to send and receive BPDUs. Finally, a port enters forwarding mode. Note this is the only state in which the port is actually forwarding frames.
To see the STP mode of a given interface, use the show spanning-tree interface command. What you might not have known is that if you decide to change any and all of these timers, that change must be configured on the root bridge. The root bridge will inform the nonroot switches of the change via BPDUs. We'll prove that very shortly. Right now, let's review the STP timer basics. By default, this is set to 2 seconds. Forward Delay is the length of both the listening and learning STP stages, with a default value of 15 seconds for each stage.
Maximum Age, referred to by the switch as MaxAge, is the amount of time a switch will retain the superior BPDU's contents before discarding it. The default is 20 seconds. The value of these timers can be changed with the spanning-tree vlan command shown below. The timers should always be changed on the root switch, and the current secondary switch as well.
Verify the changes with the show spanning-tree command. SW1 config spanning-tree vlan 1? In the following example, we'll change the STP timers on a nonroot switch and then run show spanning-tree. We'll change the STP timers on this switch. The nonroot switch will allow you to change the STP timers, but these new settings will not be advertised via BPDUs unless this local switch later becomes the root bridge. If you feel the need to change STP timers, it's a good idea to change them on both the root and secondary root switches.
That allows the secondary root to keep the same timers if the root goes down and the secondary then becomes the primary root.
Deterministic Root Switch Placement You might have noticed some other options with the spanning-tree vlan command 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.
You can make this happen with the spanning-tree vlan root command. I've created three new VLANs, as seen in the output of show vlan brief. To make this happen, we'll go to SW 2 and use the spanning-tree vlan root primary command. Notice that the priority value has changed from the default. This command has another option you should be aware of: SW2 config spanning-tree vlan 30 root? If you want a certain switch to take over as root bridge if the current root bridge goes down, run this command with the secondary option.
This will change the priority just enough so that the secondary root doesn't become the primary immediately, but will become the primary if the current primary goes down.
Let's take a look at the root secondary command in action. We have a three-switch topology for this example. Which switch would become the root if SW3 went down? But what if we want SW1 to become the root if SW3 goes down? We use the root secondary command on SW1!
A priority value of is an excellent tipoff that the root secondary command has been used on a switch. The config itself shows this command as well: Ever wondered how the STP process decides what priority should be set when the spanning-tree vlan root command is used? After all, we're not configuring an exact priority with that command. Here's how the STP process handles this: If the current root bridge's priority is greater than 24,, the switch sets its priority to in order to become the root.
You saw that in the previous example. If the current root bridge's priority is less than 24,, the switch subtracts from the root bridge's priority in order to become the root. There is another way to make a switch the root bridge, and that's to change its priority with the spanning-tree vlan priority command. I personally prefer the spanning-tree vlan root command, since that command ensures that the priority on the local switch is lowered sufficiently for it to become the root.
With the spanning-tree vlan priority command, you have to make sure the new priority is low enough for the local switch to become the root switch.
As you'll see, you also have to enter the new priority in multiples of SW2 config spanning-tree vlan 10 priority?
Access switches are those found closest to the end users, and the root bridge should not be an access-layer switch. Ideally, the root bridge should be a core switch, which allows for the highest optimization of STP.
What you don't want to do is just blindly select a centrally located switch, particularly if you're visiting a client who has a configuration like this: Don't be tempted to make SW3 the root switch just because it's got the most connections to other switches.
You should never make an access- layer switch the root switch! The best choice here is one of the core layer switches, which generally will be a physically central switch in your network.
If for some reason you can't make a core switch the root, make it one of the distribution switches. The TCN doesn't say exactly what happened, just that something happened. This indicates to all receiving switches that the aging time for their MAC tables should be changed from the default of seconds to whatever the Forward Delay value is - by default, that's 15 seconds. That allows the switch to quickly rid itself of now-invalid MAC address table entries while keeping entries for hosts that are currently sending frames to that switch.
Portfast-enabled ports cannot result in TCN generation, which makes perfect sense.
The most common usage of Portfast is when a single PC is connected directly to the switch port, and since such a port going into Forwarding mode doesn't impact STP operation, there's no need to alert the entire network about it. And if you're fuzzy on what Portfast is and what it does, that and many other Cisco switch features are covered in the next section!
Let's take a look at the default behavior of a trunk between two switches when we have ten VLANs, and then change this behavior just a bit with the port-priority command. I've created ten VLANs, 11 - 20, for this example. Before we go forward, using your knowledge of switching, how many port or ports in this example will be in STP Blocking mode? Which one s? Let's check with show spanning vlan 11 on both switches. If your answer was "one", you're correct! Don't forget to use the VLAN range option with the spanning-tree command - this will save you quite a bit of typing and time on your exam.
WORD vlan range, example: In many instances, you'll configure an Etherchannel here rather than using port priority to load balance over the trunk lines. In Ciscoland, it's always a good idea to know more than one way to do something - especially when you're studying for an exam!
We're all familiar with show interface x, but there's a slight variation on this command when it comes to Cisco switches that will give you a great deal of helpful information when it comes to troubleshooting - show interface x switchport.
There's actually a very common issue indicated in this output - can you spot it? Enabled Administrative Mode: ALL Protected: This is an excellent VLAN and trunking troubleshooting command. And the problem? I left the interface shut down.
Here's what the output looks like when the interface is open. Here's what the output looks like when a trunk port is specified. The extended VLANs will be numbered - You can't use this feature on all Cisco switches, though. It is enabled by default on and switches with an IOS version of Here's how to disable the Extended System ID: SW2 config no spanning extend system-id You may have noticed something odd about the Bridge ID with the switches used in this section, all of which are running the Extended System ID feature by default: Disabled by default, it can be enabled with the set spantree macreduction command.
Portfast Suitable only for switch ports connected directly to a single host, Portfast allows a port running STP to go directly from blocking to forwarding mode. If you have an issue with a host acquiring an IP address via DHCP, configuring Portfast on the switch port in question just might solve the issue.
A Cisco router will give you an interesting warning when you configure Portfast: Connecting hubs, concentrators, switches, bridges, etc SW1 config-if That is one long warning. Not only will the switch warn you about the proper usage of Portfast, but you must put the port into access mode "non-trunking" before Portfast will take effect. If a switchport has a workstation connected to a port, that workstation will still have to wait 30 seconds for the listening and learning stages of STP to run before it can communicate successfully with the DHCP server.
We all know that 30 seconds seems like 30 minutes to end users, especially first thing in the morning! Running Portfast on the appropriate switch ports did speed up their initial network connectivity. Portfast can also be enabled globally, but we'll get another warning when we do so: You should now disable portfast explicitly on switched ports leading to hubs, switches and bridges as they may create temporary bridging loops.
Personally, I like to configure it on a per-port basis, but make sure you know both ways to configure Portfast. It never hurts to know more than one way to do things on a Cisco exam. There's a command related to portfast that I want to share with you - note the three effects of this command as explained by IOS Help: SW1 config-if switchport host?
Uplinkfast When a port goes through the transition from blocking to forwarding, you're looking at a 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?
SW3 has two paths to the root switch. STP will only allow one path to be available, but if the open path between SW3 and SW1 goes down, there will be approximately a second delay 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 isn't really "immediate" - it actually takes 1 - 3 seconds. Next to a second delay, that certainly seems immediate! Uplinkfast cannot be configured on a root switch. 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 the original root port back to the forwarding state: First, the switch priority will be set to 49,, 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 , 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? The max-update-rate value determines how many of these frames will be sent in a millisecond time period. Where To Apply Uplinkfast As with all the topics in this section, it's not enough to know the definition of Uplinkfast and what it does - you've got to know where to configure it for best results. Uplinkfast is a wiring-closet switch feature - it's not recommended for core and distribution-layer switches.
Uplinkfast should be configured only on access-layer switches. It's a safe bet that the root switches are going to be found in the core layer, and the switches that are farthest away from the root switches will be the access switches. The access switches will be the ones closest to the end users. Backbonefast Uplinkfast and Portfast are great, but they've got limitations on when they can and should be run.
You definitely can't run either one in a network backbone, but the Cisco-proprietary feature Backbonefast can be used to help recover from indirect link failures. The key word there is indirect. If a core switch detects an indirect link failure - a failure of a link that is not directly connected to the core switch in question - Backbonefast goes into action. This indirect link failure is detected when an inferior BPDU is received. Let's take a look at a three-switch setup where all links are working and STP is running as expected, paying particular attention to the STP states on SW3.
All links are assumed to be running at the same speed. All is well, until SW2 loses its connection to SW1, as shown below - which means that SW2 will start announcing itself as the root switch.
SW3 will now be receiving two separate BPDUs from two separate switches, both claiming to be the root switch. We really don't want to wait that long, and with Backbonefast, we don't have to!
When BackboneFast is configured, this process skips the MaxAge stage. While this does not eliminate delays as efficiently as PortFast and UplinkFast, but the delay is cut from 50 seconds to MaxAge's default value is 20 seconds, but the second Listening and Learning stages still have to run.
RLQ uses a series of requests and responses to detect indirect link outages. The purpose of these RLQ requests is to ensure that the local switch still has connectivity to the root switch. The RLQ request identifies the bridge that is considered the root bridge, and the RLQ response will identify the root bridge that can be accessed via that port. If they're one and the same, everything's fine. Upon receiving a RLQ request, a switch will answer immediately under one of two conditions: The receiving switch is indeed the root bridge named in the RLQ request The receiving switch has no connectivity to the root bridge named in the RLQ request, because it considers another switch to be the root bridge The third possibility is that the receiving switch is not the root, but considers the root switch named in the RLQ request to indeed be the root switch.
In that case, the RLQ request is relayed toward the root switch by sending it out the root port. To put BackboneFast into action in our network, we have to know more than the command! We've got to know where to configure it as well.
Since all switches in the network have to be able to send, relay, and respond to RLQ requests, and RLQ is enabled by enabling BackboneFast, every switch in the network should be configured for BackboneFast when using this feature. This feature is enabled globally, and it's simple to configure - and believe it or not, there are no additional timers or options with this command. A true Cisco rarity! The command to verify BackboneFast is just as simple and is shown below. SW1 config spanning-tree backbonefast SW1 show spanning-tree backbonefast BackboneFast is enabled Root Guard You know that the root switch is the switch with the lowest BID, and that a secondary root is also elected - that's the switch with the next-lowest BID.
You also know that you can use the spanning-tree vlan root command to make sure that a given switch becomes the root or the secondary root. SW1 config spanning-tree vlan 23 root? For clarity's sake, the full BID is not shown - just the switch priority. Nothing wrong here, everything's fine The problem here is that SW4 is going to become the root switch, and SW1 is going to become the secondary root.
Depending on the design of your network, this change in root switches can have a negative effect on traffic flow. There's also a delay involved while the switches converge on the new STP topology.
Worse yet, there's always the possibility that R4 isn't even under your administrative control - it belongs to another network! STP has no default behavior to prevent this from happening; the spanning-tree vlan root command helps you determine which switches become the root and secondary root, but does nothing to disqualify a switch from becoming the root.
To prevent SW4 from becoming the root in this network, Root Guard must be configured. Root Guard is configured at the port level, and disqualifies any switch that is downstream from that port from becoming the root or secondary root.
Root Guard will actually block that superior BPDU, discard it, and put the port into root-inconsistent state. Configuring Root Guard is simple: There is no interface reset or reload necessary, but note that Root Guard- enabled ports act as designated ports until a superior BPDU is received, of course. Here's the console message we receive as a result on R3: Additionally, there's a spanning-tree command that will show you a list of ports that have been put into root-inconsistent state, but it's not as obvious as some of the other show spanning-tree commands we've seen: SW3 show spanning-tree?
This is the resulting topology: Now, you'd think that would be enough of a warning, right? But there is a chance - just a chance - that someone is going to manage to connect a switch to a port running Portfast, which in turn creates the possibility of a switching loop.
BPDU Guard protects against this possibility. If any BPDU, superior or inferior, comes in on a port that's running BPDU Guard, the port will be shut down and placed into error disabled state, shown on the switch as err-disabled. SW1 config-if spanning-tree bpduguard?
SW1 config spanning-tree portfast bpduguard default Note that this command is a variation of the portfast command. You can use BPDU Filtering, but you have to be careful how you configure it - this feature works differently when it's configured globally as opposed to configuring it on a per-interface level. SW1 config spanning portfast bpdufilter? SW1 show spanning-tree summary totals Switch is in rapid-pvst mode Root bridge for: Designated root has priority , address e.
Particularly with fiber optic, there are situations where a physical layer issue disables data transfer in one direction, but not the other. If a UDLD frame is received in return, that indicates a bidirectional link, and all is well. If a UDLD frame is not received in return, the link is considered unidirectional.
It's really like a Layer 2 ping. If the UDLD "echo" is seen, there's bidirectional communication; if the "echo" is not seen, there isn't! UDLD has two modes of operation, normal and aggressive.
When a unidirectional link is detected in normal mode, UDLD generates a syslog message but does not shut the port down. In aggressive mode, the port will be put into error disabled state "err- disabled" after eight UDLD messages receive no echo from the remote switch.
Why is it called "aggressive"? Because the UDLD messages will go out at a rate of one per second when a potential unidirectional link is found. UDLD can be enabled globally or on a per-port level. To enable UDLD globally, run the udld enable command. In this case, "globally" means that UDLD will run on all fiber optic interfaces. For aggressive mode, run udld aggressive.
There is no udld normal command. SW2 config udld? For example, in the previous two-switch examples, UDLD would have to be configured on both switches, either on the switch ports or globally. Now, you may be thinking the same thing I did when I first read about aggressive mode If aggressive mode shuts a port down after failing to receive an echo to eight consecutive UDLD frames, won't the port always shut down when you first configure UDLD?
When UDLD's aggressive mode is first configured on the local switch, the port will start sending UDLD frames, but will not shut down the port when it doesn't hear back from a remote switch within 8 seconds. The remote switch will first have to answer back with a UDLD frame, which makes the local switch aware of the remote switch.
Then, if the remote frame stops sending back an echo frame, the local switch will shut the port down. Duplex Mismatches And Switching Loops A duplex mismatch between two trunking switches isn't quite a unidirectional link, but it can indeed lead to a switching loop.
You're not often going to change switch duplex settings, especially on trunk ports, but if you change one switch port's duplex setting, change that of any trunking partner! We all know what happens then! One collision does not a switching loop make, but if the full-duplex port sends enough traffic, it effectively drowns out anything that the half-duplex port tries to send.
Depending on the location of the root switch in this network or if one of these switches is the root switch , a switching loop may well occur. Keep your ports in the same duplex mode and you don't have to worry about this! Loop Guard! You can probably guess that the "loop" being guarded against is a switching loop Let's revisit an earlier example to see how the absence of BPDUs can result in a switching loop.
In this network, only one port will be in blocking mode BLK. Ports in blocking mode still receive BPDUs, and right now everything's as we would want it to be.Perhaps we only want Host 2 to receive any broadcast sent by Host 1. It's interesting to note that of the six ports involved in our example, five are in forwarding mode and only one is blocked - but placing that one particular port into blocking mode prevents switching loops from forming. To review: Let's take a look at the same command's output on SW2.
The original root port will become the root port again when it detects that its link to the root switch has come back up.