The Ultimate CCNA Study Package - ICND 2

Chris Bryant, CCIE #12933 http://www.thebryantadvantage.com Back To Index

More LAN Switching

Overview
Spanning Tree Protocol Root Bridge, Root Ports, and Designated Ports STP Timers STP Port States Portfast VLANs Trunking Access And Trunk Port Comparison VTP "Router On A Stick" RSTP PVST Etherchannels "Hot Spots And Gotchas"

NOTE: Before reading this chapter, you MUST read and understand the topics in the CCENT Study Guide switching chapter. Spanning Tree Protocol

In almost every switching network, there will be path redundancy that is, there will be more than one way to get to a given destination. We always want redundancy, but that redundancy can cause problems at Layer 2. If all the paths in the following diagram were available at all times, switching loops would form.

Don't get me wrong, we love redundant paths! Each of those switches has three different ways to get to every other switch in the network. The key is that we can't have all of those paths available simultaneously, or we're going to end up with switching loops. That's where STP comes in! The Spanning Tree Protocol (STP) , defined by IEEE 802.1d, prevents switching loops from occurring by placing ports along the most desirable path into forwarding mode, while ports along less-desirable paths are placed into blocking mode.OnceSTP converges, everyport on these paths is in either forwarding or blocking mode, makingonly one pathavailable between any two destinations,and a switching loop cannot occur. Note: You're going to hear about routing loops later in your studies, if you haven't already. STP has nothing to do with routing loops. STP is strictly a Layer 2 protocol and is used to prevent switching loops. If a problem arises with the available path, STP will run the spanning-tree algorithm to recalculate the available paths and determine the best path. Ports along the new best path will be brought out of blocking mode and into forwarding mode, while ports along less-desirable paths are placed into blocking mode. Again, only one path will be available. For example, let's say that STP has decided that the best path from SW1 to SW3 is the most direct path. (This is not always the case, as you'll see later.) Logically, SW1 sees only one way to get to SW3.

If something happens that makes that path unavailable, STP will recalculate its available paths. When that recalculation ends, STP will begin to bring the appropriate ports out of blocking mode and into forwarding mode.

The Root Bridge Election STP must first determine a root bridge for every Virtual LAN (VLAN). When people are born, they act like they are the center of the universe. In a similar fashion, when a switch is first powered on, it believes it is the root bridge for every single VLAN on your network. Since your network has multiple switches, and they all believe they are the root bridge for every VLAN, there must be an election process to determine the true root bridge for each VLAN. The election process is carried out by the exchange of BPDUs (Bridge Protocol Data Units). Switches are continually sending BPDUs; hubs, repeaters, routers, servers, and other network

devices do not send BPDUs.

The BPDU contains the following data: The root bridges Bridge ID (BID). The BID is a combination of the bridges priority and MAC address. At the beginning of the election process, every switch thinks it is the root, so this will at first be the sending routers BID. The bridge with the lowest BID will be the root bridge. The default priority value is 32768 for all switches; therefore, since the lowest BID wins, the switch with the lowest MAC address will become the root bridge unless the priority is changed. I'll demonstrate this later in the section, but I do want to mention now that the easiest way to guarantee that a certain switch becomes the root bridge is to lower its priority. In the BID, the priority comes first and is followed by the MAC address, so lowering the priority is sufficient to make a certain switch the root bridge. Cost To Reach Root From This Bridge: STP considers the path to have the lowest cost to be the best path. Every port is assigned a cost relative to its speed; the higher the speed, the lower the port cost. BID Of The BPDUs Sender: This simply identifies which switch sent the BPDU. When a switch receives a BPDU, the switch compares the root bridge BID contained in the BPDU against its own BID.

If the incoming root bridge BID is lower than that of the switch receiving it, the switch starts announcing that device as the root bridge.

If the incoming BID is higher than that of the receiver, the receiver continues to announce itself as the root. This process continues until every switch has agreed on the root bridge. (This may sound confusing, but we'll go through an illustrated example in just a moment.)

Once STP has converged - that is, all switches agree on the root bridge - every port on the switched network will be in either blocking or forwarding mode. There are intermediate states that you should be aware of, though. Here's the order of STP port states as a port goes from blocking to forwarding. BLOCKING: Frames are not forwarded, but BPDUs are accepted. LISTENING: Frames are not forwarded, and the MAC address table is not yet being built. LEARNING: Frames are not forwarded. MAC addresses are being learned and the MAC address table is being built. FORWARDING: Frames are forwarded, MAC addresses are still learned. Note that even though we have a "learning" state, there are two states where the port is learning MAC addresses - learning and forwarding. There is a fifth STP state, disabled, and it's just what it sounds like. The port is actually disabled, and disabled ports cannot accept BPDUs. We're going to take two looks at STP in action, the first with two switches and the second with three switches. In the first example, there are two separate crossover cables connecting the switches. It's important to note that once STP has converged, one port - and only one port - will be in blocking mode, with the other three in forwarding mode.

I haven't configured anything on these switches beyond a hostname and the usual lab commands, so what VLANs, if any,

will be running on these switches? SW1#show vlan brief VLAN Name Status Ports ---- -------------------------------- --------------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup Right! All ports belong to VLAN 1 by default. Except there's one odd thing here... notice that the ports used to connect the switches, Fa0/11 and Fa0/12, don't show up in show vlan brief? That's because they're trunk ports, the kind of port we have to have in order to connectto another switchvia that port. We'll talk much more about trunking later in this section, and you can always see what ports are trunking with the show interface trunk command. SW1#show interface trunk Port Mode Status Native vlan Fa0/11 desirable trunking 1 Fa0/12 desirable trunking 1 Port Vlans allowed on trunk Fa0/11 1-4094 Fa0/12 1-4094 Port Vlans management domain Fa0/11 1 Fa0/12 1 allowed and active in Encapsulation 802.1q 802.1q

Port Vlans in spanning tree forwarding

state and not pruned Fa0/11 1 Fa0/12 none We will examine that command's output in greater detail later in this section, but for now I wanted you to know why those ports were not showing up in show vlan brief. Don't panic, just run show interface trunk! Now back to our network....

To see each switch's STP values for VLAN 1, we'll run show spanning-tree vlan 1.First, we'll take a look at SW1's output for that command. SW1#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000b.be2c.5180 Cost 19 Port 11 (FastEthernet0/11) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e2.25c0 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- ------------------------------Fa0/11 Root FWD 19 128.11 P2p Fa0/12 Altn BLK 19 128.12

P2p The Root ID is the BID information for the root bridge; the Bridge ID is the BID information for the local switch. Since the addresses are different for the Root and Bridge ID, this switch is definitely not the root switch. The BID of any switch is the priority followed by the MAC address, so let's compare the two values:

Root ID BID: 32769:00-0b-be-2c-51-80 Bridge ID BID: 32769:00-0f-90-e2-25-c0

The device with the lowest BID will be elected root. Since both devices have the exact same priority, the switch with the lowest MAC address is named the root switch, and that's exactly what happened here. On SW1, Fa0/11 is in FWD status, short for forwarding. Note that this port is marked Root, meaning that this port will be used by SW1 to reach the root switch. Fa0/11 is SW1's root port for VLAN 1. Fa0/12 is in BLK status, short for blocking.How did the switch decide to put Fa0/11 into forwarding mode while 0/12 goes into blocking? The switch first looked at the path cost, but that's the same for both ports - 19.The tiebreaker is the port priority, found under the prio.nbr field. Fa0/11's port priority is lower, so it's chosen as the root port. Let's mark that on our exhibit and then move on to SW2.

Here's the output of show spanning-tree vlan 1 on SW2. SW2#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000b.be2c.5180

 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 000b.be2c.5180 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- ------------------------------Fa0/11 Desg FWD 19 128.11 P2p Fa0/12 Desg FWD 19 128.12 P2p We have two really big hints that SW2 is the root switch for VLAN 1. The first is really, really big - the phrase "This bridge is the root"! The next isn't quite as obvious, but it's a good one to keep in mind for exam day. Both Fa0/11 and Fa0/12 are in FWD status. They're both in forwarding mode! A root bridge will always have all of its ports in Forwarding mode. This does help speed up convergence if and when STP recalculates. The root bridge doesn't need its port(s) brought out of blocking mode, because they're already in forwarding mode. Blocking the single port on SW1 in this topology is enough to prevent switching loops. Here's how our switched network looks now:

It's a common misconception that the Fa0/12 port on both switches would be blocked in this situation. Remember that a root switch will have all its ports in forwarding mode.

Now we'll take a look at a three-switch example. In the following network, there are three switches, fully meshed. WhenVLAN 10 comes online, all three switches will believe they are the root bridge for VLAN 10.

For clarity's sake, each switch's MAC address is the switch's letter repeated 12 times. The switch priorities have been left at their defaults, resulting in the BIDs shown below. MAC Address Default Priority Bridge ID (BID) Switch A aaaa.aaaa.aaaa 32768 32768:aaaa.aaaa.aaaa Switch B bbbb.bbbb.bbbb 32768 32768:bbbb.bbbb.bbbb Switch C cccc.cccc.cccc 32768 32768:cccc.cccc.cccc Assuming that all three switches just came online, they all think they're the root switch. To take a closer look at how this situation gets resolved, we'll take a look at each switch's individual behavior during the root bridge election.

Switch A receives BPDUs from Switch B and Switch C, each

claiming they are the root bridge. Switch A examines their BIDs, and sees that its own BID of 32768:aaaa.aaaa.aaaa is lower than either of the BIDsit is receiving. Switch A will continue to advertise itself as the root bridge.

Switch B receives BPDUs from Switch A and Switch C, each claiming they are the root bridge. Switch B examines the BIDs from these switches. SwitchB sees it has a lower bid than Switch C, but a higher bid than Switch A. Switch B recognizes Switch A should be the root bridge due to its lower BID. Switch B will now send BPDUs naming Switch A as the root bridge.

Switch C receives BPDUs from Switch A and Switch B. Switch C will see that it has a higher BIDthan both of the other switches, but that A's is the lowest BID ofall. Switch C will now recognize Switch A as the root bridge and will send BPDUs naming Switch A as the root bridge. At this point, both ports on SW A will be placed into Forwarding mode, since it's the root switch.

Next, the root ports on each non-root bridge must be selected. Each non-root bridge has two different ports that it can reach the root bridge through, but the cost is lowerfor the port that is closer to the root bridge (we're assuming all port speeds are the same). Those ports will now be selected as the root port on their respective switches - the switch port with the lowest cost to the root bridge is that switch'sroot port.

Hey, we're almost done! Now either Switch B or Switch C must be elected the designated bridge of their common segment. The switch that advertises the lowest cost to the root bridge will be the designated bridge, and that switch's port on the shared segment will be the designated port (DP). In this network, SW B and SW C will advertise the same cost to each other over the shared segment. In that case, the switch with the lowest BID will be the designated bridge, and we know that's SW B. SW B's Fa0/2 port will be put into forwarding mode and named the DP for that segment; SW C's Fa0/2 port will be put into blocking mode and will be that segment's non-designated port (NDP). The DP is always in forwarding mode and the NDP will always be in blocking mode. Additionally, all forwarding ports on the root switch are considered DPs. A root switch will not have root ports - it doesn't have a port to reach the root, it is the root!

At this point, only the root switch actually originates BPDUs. The other switches receive them, read them, update the port costs, and then forward them - but nonroot switches do not originate BPDUs. The switching network is nowina state of convergence - all switches are in agreement on the various STP port states, and all ports are in either Forwarding or Blocking mode. In earlier examples, the speed of both links between switches was the same. What if they were different, as shown in the following example?

In our earlier two-switch example, fast0/11 was chosen as the root port on SW1. The port cost was the same (19), so the port priority was the tiebreaker. In this scenario, the speeds of the links are not the same. The faster the port setting, the lower the port cost, so now fast0/12 would be chosen as the RP on SW1. Here are some common port speeds and their associated STP port costs:

10 MBPS: 100 100 MBPS: 19 1 GBPS (also expressed as 1000 MBPS): 4 10 GBPS: 2

You must keep those costs in mind when examining a network diagram to determine the flow of traffic, because it's our nature to think the physically shortest path is the fastest path - but STP does not see things that way. Consider:

At first glance, you'd think that SW B would select Fa0/1 as its root port. Would it? The BPDU actually carries the Root Path Cost, and this cost increments as the BPDU is forwarded throughout the network. A port's Path Cost is locally significant only and is unknown by downstream switches. The root bridge will transmit a BPDU with the Root Path Cost set to zero. When a neighboring switch receives this BDPU, that switch adds the cost of the port the BPDU was received on to the incoming Root Path Cost.Root Path Cost increments asBPDUs are received, not sent.That new root path cost value will be reflected in the BDPU that switch then sends out. Let's look at the network again, with the port costs listed. As mentioned earlier, 100 MBPS ports have a port cost of 19, and 1000 MBPS ports have a port cost of 4. For clarity's sake, I've removed the speeds from the diagram.

Two very important points regarding port cost:

The root switch originates the BPDU with a cost of zero The root port cost increments as BPDUs are received

When SW A sends a BPDU directly to SW B, the root path cost is zero. That will increment to 19 as it's received by SW B. When SW A sends a BPDU to SW C, the root path cost is zero. That will increment to 4 as it's received by SW C. That BPDU is then forwarded to SW B, which then adds 4 to that cost as it's received on Fa0/2. That results in an overall root path cost of 8, which will result in SW B naming Fa 0/2 as the root port.

The moral of the story: The physically shortest path is not always the logically shortest path. Watch for that any time you see different link speeds in a network diagram! The STP Timers Once these elections have taken place, the root bridge will begin sending a Hello BPDU out all its ports every two seconds. This Hello BPDU serves as the heartbeat of STP, since as long as the non-root bridges receive it, they know the path to the root is unchanged and stable. Once that heartbeat disappears, its an indication of a failure somewhere along the path. STP will run the spanning-tree algorithm to determine the best available path, and ports will be brought out of blocking mode as needed to build this path. The Hello BPDUs carry values for three timers that are used by all bridges in identifying situations when the STP algorithm needs to be run again:

Hello Time: Time between Hello BPDUs. Default: 2 seconds. Max Age: The bridge should wait this amount of time after not hearing a Hello BPDU before attempting to change the STP topology. Default: 20 seconds. Forward Delay: The amount of time a port should stay in the listening and learning stages as it changes from blocking to forwarding mode. Default: 15 seconds.

Think carefully before changing these timers, and should you choose to do so, you must do so on the root bridge. The non-root switches will allow you to change the timers on them, but the changes will not be advertised to the other switches! Change any and all of these timers with the spanning-tree vlan command, specifying the timers as shown below.
SW1(config)#spanning-tree vlan 1 ? forward-time Set the forward delay for the spanning tree hello-time Set the hello interval for the spanning tree max-age Set the max age interval for the spanning tree priority Set the bridge priority for the spanning tree root Configure switch as root <cr>

The STP Interface States When a port goes from blocking state to forwarding state, it does not do so instantly. If it did, loops could result. STP has interfaces go through two intermediate states between blocking and forwarding --listening and learning. A port coming out of blocking state first goes into listening state. The port is

listening for Hello BPDUs from other possible root switches. The port will listen for the value of the Forward Delay timer, 15 seconds by default. The port will then go into learning state. This state has the port learn the new location of MAC addresses, but will not allow forwarding of them, since there is a good possibility other switches are currently converging and loops could develop if MAC addresses were learned from other switches during convergence. Learning state also lasts the duration of the ForwardDelay timer. To review the order and timers involved:

Port comes out of blocking state, goes into listening state for 15 seconds Port transitions from listening to learning, stays in learning state for 15 seconds Port transitions from learning to blocking

The one STP state we didn't mention here is disabled. Some non-Cisco documentation does not consider this an official STP state, but since the CCNA is a Cisco exam, we certainly should! Ports in disabled mode are not learning MAC addresses, and they're not accepting or sending BPDUs - they're not doing anything! So What Happens If I Turn STP Off? A lot of bad things. The most obvious is that you're going to have switching loops form very quickly, which in turn will lead to broadcast storms. A broadcast storm occurs when one broadcast is answered with multiple broadcasts, which in turn generate even more broadcasts. It's a really ugly situation, and there really is no good reason to turn STP off.

Portfast Consider the amount of time a port ordinarily takes to go from blocking to forwarding when it stops receiving Hello BPDUs: Port stays in blocking mode for 20 seconds before beginning the transition to listening (as defined by the MaxAge value) Port stays in listening mode for 15 seconds before beginning the transition to learning (as defined by the Forward Delay value) Port stays in learning mode for 15 seconds before transitioning to forwarding mode (also as defined by Forward Delay) That's 50 seconds, or what seems like 50 hours in networking terms. :) The listening and learning stages are there for a reason, the primary one being loop prevention during convergence. In certain circumstances, we can avoid these delays with Portfast. Portfast allows a port to bypass the listening and learning stages of this process, but is only appropriate to use on switch ports that connect directly to an end-user device, such as a PC. Using portfast on a port leading to another networking device can lead to switching loops. That threat is so serious that Cisco even warns you about it on the router when you configure Portfast.
SW2(config)#int fast 0/6 SW2(config-if)#spanning portfast %Warning: portfast should only be enabled on ports connected to a singlehost. Connecting hubs, concentrators, switches, bridges, etc... to thisinterface when portfast is enabled, can cause temporary bridging loops.Use with CAUTION %Portfast has been configured on FastEthernet0/6 but will only

have effect when the interface is in a non-trunking mode.

That's a pretty serious warning! I love the mention of "temporary bridging loops", though. All pain is temporary, but that doesn't make it feel good at the time! Portfast can be a real help in the right circumstances....

... and a real hazard in the wrong circumstances.

Make sure you know which is which! Virtual LANs (VLANs) We went over basic VLAN concepts in theBasic Switching section, and I'm going to repeat that information here since it relates closely to the information following this section - namely, trunking and VLAN Trunking Protocol (VTP). There is some new material in the following that's pertinent to the CCNA exam, so read carefully - this is not just the same VLAN information from earlier in the course. Let's review a switch's default behavior regarding broadcasts and then go into more detail about why this is so important. The default behavior of a switch is to forward a broadcast out every single port on the switch except the one it came in on. All hosts that receive a broadcast sent bya host are considered to be on the same physical LAN as the sender.

Looks pretty innocent, right? We actually have two potential issues with this situation. First, in a production network, you'll have many other hosts connected to

that switch - and every single one of those hosts is going to get a copy of any broadcast sent by any other host connected to that switch. That's a lot of broadcasts, and it's a big waste of bandwidth. The next problem is that broadcasts tend to result in the recipients generating broadcasts of their own. Pretty soon, the switch is so busy handling all of the broadcasts that it can't carry out its other functions, and the network comes to a standstill. This continual generation of new broadcasts is called a broadcast storm, and this is one storm that can sink your switch for good. A broadcast storm can overwhelm a switch's memory and CPU capabilities, rendering the switch virtually useless. Between the waste of bandwidth and switch resources and the possibility ofa broadcast storm, we're very interested in limiting broadcasts. Before we take a look at how Virtual LANs can help us limit broadcasts, I want to reiterate that broadcasts are not evil, and they can't be eliminated. The more you learn about networking, the more you realize that broadcasts are actually quite helpful and have some very important roles in our network. What we want to do is limit broadcasts, particularly the sending of broadcasts to hosts that do not need them. To illustrate how Virtual LANs can help limit broadcast propagation, we'll assign an IP address to each one of our hosts and then take a look at the default Cisco switch settings for VLANs. The circle(s) will continue to illustrate the broadcast domain(s). The numbers on the switch indicate the switch port that's connected to that host.

To test connectivity, we'll send pings from 172.34.34.4 to the other three hosts. Note that I'm using Cisco routers for our hosts, so these pings will look different than any you've run from PCs.
Host4#ping 172.34.34.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.34.34.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms Host4#ping 172.34.34.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.34.34.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

Host4#ping 172.34.34.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.34.34.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

Everything looks good! Now that we know that Host 4 can ping the other hosts, let's take a look at the switch. I occasionally have a student tell me that their network doesn't use VLANs, but a Cisco switch is set up for and is using VLANs by default. The key command for viewing and verifying VLAN configuration is show vlan brief.
SW1#show vlan brief VLAN Name Status ---- -------------------------------- --------1 default active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active Ports ------------------------------Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10

Note that VLAN1 has the name "default". That's exactly what VLAN 1 is - the default VLAN for every host connected to this switch. Under "ports", you can see that 10 ports are in this VLAN. By default, a copy of every broadcast sent by any host in a given VLAN will be sent to every other host in that VLAN. (The default VLAN is also called the native VLAN.) If a host is connected to every one of those ports, and any of the hosts sends a broadcast, a copy of that broadcast will be sent to every other host connected to that switch. That's a real waste of switch resources and bandwidth! Let's say that we want only Host 2 to receive any broadcast sent by Host 4, and vice versa. We can accomplish this by placing those two hosts into their own VLAN. That's done at the port level with the switchport access vlan command, followed by the VLAN number the port's being placed into. You must make the port an access port before you can place it into a VLAN.
SW1(config-if)#interface fast 0/2 SW1(config-if)#switchport access vlan 24 % Access VLAN does not exist. Creating vlan 24 SW1(config-if)#interface fast 0/4 SW1(config-if)#switchport access vlan 24

If you try to put a port into a VLAN that hasn't been created yet, the switch creates it for you and even tells you so. Pretty good deal! Now Hosts 2 and 4 are in VLAN 24, and Hosts1 and 3 arestill in VLAN 1. We'll verify that after the illustration with show vlan brief.

SW1#show vlan brief VLAN Name Status ---- -------------------------------- --------1 default active 24VLAN0024 active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active Ports ------------------------------Fa0/1, Fa0/3, Fa0/5, Fa0/6 Fa0/7, Fa0/8, Fa0/9,Fa0/10 Fa0/2, Fa0/4

That simple configuration really helps to reduce broadcasts! When all four hosts were in the same VLAN and one host sent a broadcast, the switch would make sure that all three of the other hosts received a copy. Now when a member of any given VLAN sends a broadcast, only members of that same VLAN will receiveit - and right now, that means only one other host will receive it! When we create VLANs, we're creating multiple, smaller broadcast domains, and that really helps to limit the scope of those broadcasts. In networking, thought, there's almost alwaysa tradeoff. If Host 4 sends a broadcast, Hosts 1 and 3 will not receive it because they're in another VLAN. Does that hold true for other kinds of traffic - like pings, for instance? To find out, let's send a ping from Host 4 to the other three hosts. When they were all in the same VLAN, the pings were all returned. What about now?
Host4#ping 172.34.34.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.34.34.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Host4#ping 172.34.34.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.34.34.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms Host4#ping 172.34.34.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.34.34.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

When you ping a remote host and get five periods back, that means the local host has no IP connectivity to the specified destination . Host 4 can still ping Host 2, since they're in the same VLAN, but Host 4 can no longer ping the other two hosts since they are not in that VLAN. It's vital to remember that no traffic - pings or data packets - can be sent from one VLAN to another without the intervention of a Layer 3 device, most likely a router. Notice I said "most likely". We really have two options here:

Using a technique called "router on a stick" Using a Layer 3 switch for that switch

We're going to look at "router on a stick" in much greater detail later in this section, but I'd like to talk about L3 switches for just a moment before we move on. You're not going to be asked questions about L3 switches in your CCNA exam, but as a CCNA you should certainly know they exist. An L3 switch is a switch that can actually run routing protocols as well. You can switch on some ports and configure other ports as routing ports! Once you get your CCNA, you really should learn more about L3 switches. In the previous example, if that switch were an L3 switch, we could simply configure some routing ports on that switch and the VLANs could send data to each other without a router getting involved. But for the CCNA exam, a switch runs at L2, and that's it. I'll show you more than you'd ever want to know about "router on a stick" later in this section! VLANs have uses beyond limiting broadcasts. One common usage is to use VLANs to group users by their job function or department. Let's say you have three hosts each in your Accounting and Security departments, and two in Maintenance. Without VLANs, they're in one big group, sharing the same address space. (For clarity, I've left out the cabling. Straightthrough cables, that is!)

With VLANs, we can logically segment the switch into three logical groups. (Physically segmenting the switch is not recommended, it's a little rough on the hardware.)

This also helps to limit access to network resources on a per-VLAN basis - after all, you know our end users can get a bit territorial! If someone in the Accounting department said they had a new server that contained data that should be available only to Accounting personnel, you could just put the port leading to the server into VLAN 30. The ability to place hosts in their own VLAN is also considereda security feature. If someone came to you and told you they have a new department that needs to be totally segregated from the rest of the network, putting those hosts in their own VLAN will do the job. So VLANs are a security feature, but I wouldn't throw away my firewalls just yet. VLANs and the MAC Address Table In the first Switching section in this course, you learned - everyone repeat after me the switch examines the source MAC address of incoming frames before looking at anything else. That's how the switch builds its MAC table. Now that you know about VLANs, I wanted to mention that the switch actually keeps a separate switching table for each VLAN. This command can really come in handy with troubleshooting on occasion. In this example, I've put port fast0/2 into VLAN 17 and then run the show mac-address-table dynamic vlan 17 command.
SW1#show mac-address-table dynamic vlan 17 Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ---- ----------- -------- ---- 17 0010.7b39.c5e9 DYNAMIC Fa0/2 Total Mac Addresses for this criterion: 1

Trunking Trunking is the process of allowing VLAN traffic to flow over physically connected switches. In order for a switch receiving a frame to know the destination VLAN of that frame, a tag is placed on the frame indicating the destination VLAN by the transmitting switch ("frame tagging"). In the following network, we have two hosts in VLAN 10, and they're connected to separate, trunking switches. A frame would be tagged "VLAN 10" before being sent across the trunk. When the receiving switch processes that incoming frame, the switch knows that frame should be distributed only to members of VLAN 10. This allows members in the same VLAN to communicate when they are physically connected to different switches, which is a common need since VLANs can and

usually do span multiple switches.

The trunk consists of two trunking ports and a crossover cable. The PCs are connected to access ports with a straightthrough cable. We do need the help of a trunking protocol to build this trunk. Not all switches support both of these protocols, but for your CCNA exam, it's an excellent idea to know them both and the differences between them. The Inter-Switch Protocol (ISL) is the Cisco-proprietary trunking protocol.Obviously, it can only be used between two Cisco switches. The entire frame is encapsulated before transmission across the trunk. IEEE 802.1Q, generally known as "dot1q", is the industry standardtrunking protocol. If a non-Cisco switch is involved in the trunk, this is the trunking protocol to use. Dot1q does not encapsulate the entire frame. Instead, a 4-byte header is added to the Ethernet header, indicating the VLAN to which the frame is intended. The key difference between the two is the way they handle - or do not handle - the native vlan. By default, the native vlan is VLAN 1. The native vlan is the default vlan. When dot1q is ready to transmit a frame destined for the native vlan over the trunk, the protocol will not put that 4-byte header onto the frame. Instead, the frame is transmitted as-is. This helps to cut down even more on overhead. When the receiving frame sees there is no header on the frame, it assumes the frame is intended for the native vlan, and it is forwarded accordingly. Dot1q allows for a different VLAN to be selected as the native VLAN.

ISL does not recognize the concept of the native vlan. Every single frame transmitted over an ISL trunk will be encapsulated. That means a lot of additional overhead as compared to dot1q. To sum it up: ISL is the Cisco-proprietary trunking protocol. ISL encapsulates every frame

before it crosses the trunk, and doesn't recognize the native VLAN concept. Dot1q is the industry standard, places only a 4-byte header onto a frame, and won't even do that if the frame is destined for the native VLAN. Access Ports, Trunk Ports, And Trunk Port Settings A Cisco switch port is going to be either an access port or a trunk port; it cannot be both. As we saw earlier, an access port belongs to one and only one VLAN. Once you configure a port as an access port, that port cannot trunk. Trunk ports carry traffic for multiple VLANs. The default behavior of a trunk port is that it is a member of all VLANs, but you will not see this indicated by show vlan brief. Here's the output of that command on our switch where fast0/11 and 0/12 are trunking:
SW1#show vlan br VLAN Name Status ---- -------------------------------- --------1 default active 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup Ports --------------------------Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10

Notice that 0/11 and 0/12 are missing from the port list. They're seen with the show interface trunk command.
SW1#show interface trunk Port Mode Encapsulation Status Native vlan Fa0/11 desirable 802.1q trunking 1 Fa0/12 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa0/11 1-4094 Fa0/12 1-4094 Port Vlans allowed and active in management domain Fa0/11 1 Fa0/12 1 Port Vlans in spanning tree forwarding state and not pruned Fa0/11 1 Fa0/12 none

Let's use IOS Help to look at our trunking options. We have quite a few, but they're not all visible in one place.
SW1(config-if)#switchport mode access Set trunking mode to dynamic Set trunking mode to trunk Set trunking mode to ? ACCESS unconditionally dynamically negotiate access or trunk mode TRUNK unconditionally

The top choice refers to access ports, and we saw that in action earlier. When you configure a port as an access port, this is in effect setting the trunking mode to OFF unconditionally. The dynamic option will dynamically negotiate trunk mode, while the trunk option unconditionally turns trunking on for this port. dynamic has a few options we need to know as well.
SW1(config-if)#switchport mode dynamic ?

 auto Set trunking mode dynamic negotiation parameter to AUTO desirable Set trunking mode dynamic negotiation parameter to DESIRABLE

We have dynamic auto and dynamic desirable, and these options are generally referred to simply as "auto" and "desirable". There's one more "hidden" trunk port setting:
SW1(config-if)#switchport nonegotiate

Therefore, according to IOS Help, we actually have five options for trunk ports:

on off auto desirable nonegotiate

On means that the switchport is unconditionally trunking, whether the other end of the trunk likes it or not.

Off means that the port will not trunk with the remote partner under any circumstances. This mode is the result of making a port an access port.

Desirable means that the port will actively attempt to trunk. If the remote port is in on, desirable, or auto mode, a trunk will result.

Auto means the port will trunk, but the other side must initiate trunking. If the remote port is desirable or on mode, a trunk will result. If both sides are in auto trunking mode, no trunk will result.

Finally, nonegotiate means that the local port will go into permanent trunking mode, but Dynamic Trunking Protocol (DTP) frames are not sent across the trunk. Now that we've got our switches trunking, we need to let them exchange VLAN information. It's important for our switches to know about all VLANs in the network, not just the VLANs configured on the switch. Here's why:

SW2doesn't have any ports in VLAN 10, but it still has to know about that VLAN. If one PC in VLAN 10 sends data to the other, those frames are going to be tagged for

VLAN 10. With this topology, the frames have to go throughSW2. If SW2 doesn't know about VLAN 10, it'll have no way to send them to the correct destination! To give our switches a common view of the VLANs in use, we use the Ciscoproprietary protocol VTP - the VLAN Trunking Protocol. VLAN Trunking Protocol (VTP) VTP allows switches to advertise VLAN information between other members of the same VTP domain. VTP allows a consistent view of the switched network across all switches. When a VLAN is created on one switch in a VTP server, all other VTP devices in the domain are notified of that VLANs existence. VTP servers will know about every VLAN -- even VLANs that have no members on that switch. This information is shared between VTP devices in the form of summary advertisements.A VTP Server will send one of these advertisements every five minutes, and immediately upon a change in its VTP database. There are three separate VTP modes. Be sure you are very clear on all three before taking the CCNA exam. In server mode, VLANs can be created, modified, and deleted. When these actions are taken, the changes are advertised to all switches in the VTP domain. VTP Servers can originate, forward, and process VTP summary ads.VTP Servers keep VLAN configuration information upon reboot by storing that information in nonvolatile RAM (NVRAM). In client mode, the switch cannot modify, create, or delete VLANs. VTP clients cannot retain VLAN configuration information upon reboot.VTPclients keep this information in their running configuration, but not in NVRAM.If a VTP client is reloaded, it mustobtain this information from a VTP server when it comes back up.VTP clients can accept and process summary advertisements. The third VTP mode is a specialty VTP mode, transparent mode. You don't see it very often, but you still see it on occasion. Take special note of the differences between transparent mode and the other two VTP modes. Switches in transparent modeforward the VTP advertisements received from other switches, but they do not process the information contained in those ads.VLANs can be created, deleted, and modified on a transparent server, but those changes are not advertised to the other switches in the VTP domain - they are locally significant only. Transparent VTP switches keep their VLAN information in NVRAM, just as VTP Servers do. Setting the VTP mode of a Cisco switch is done with the vtp mode command.
SW1(config)#vtp mode ? client Set the device to client mode. server Set the device to server mode. transparent Set the device to transparent mode.

There are two VTP basics we have to be aware of for VLAN information to be correctly exchanged. 1. The VTP domain name must match. This is case-sensitive. "CISCO" and "cisco" are two different domains.The VTP domain is set with the vtp domain command. When you see the domain name changed from NULL to a new name, NULL indicates that there was no previous domain name.
SW1(config)#vtp domain CCNA

Changing VTP domain name from NULL to CCNA

2. To distribute information about a newly-created VLAN, the switch upon which that VLAN is created must be in Server mode. You can't have a VTP domain with only VTP clients. This is what happens when you try to create a VLAN ona switch configured as a VTP client:
SW1(config)#vtp mode client Setting device to VTP CLIENT mode. SW1(config)#vlan 20 VTP VLAN configuration not allowed when device is in CLIENT mode.

The switch is kind enough to remind you that you cannot create, modify, or delete VLANs on a VTP client. I doubt the exam will remind you, so remember that! The one major VTP command to view the number of VLANs, the local switch's operating mode, the VTP domain name, the configuration revision number, and more is show vtp status.
SW1#show vtp status VTP Version : 2 Configuration Revision : 2 Maximum VLANs supported locally : 64 Number of existing VLANs : 7 VTP Operating Mode : Server VTP Domain Name : CCNA VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x00 0xE9 0x2B 0x8D 0x0B 0xF9 0x37 0x57 Configuration last modified by 74.92.187.151 at 3-1-93 09:14:26 Local updater ID is 74.92.187.151 on interface Vl1 (first interface found)

And what's the configuration revision number? Glad you asked, because if you don't know, you could have a little trouble on your exam - and a lot of trouble in your realworld network. VTP Configuration RevisionNumbers Most VTP deployments are going to have two or more VTP servers, so when one VTP server sends a summary advertisement, how does the receiving VTP server know if that ad has the latest and greatest information?

Every VTP summary advertisement has a configuration revision number that is

incremented by one when it updates its own VTP database. That same number is placed into the outgoing VTP summary advertisement. If the receiving switch's own VTP configuration revision number is lower than that of the incoming advertisement, the incoming ad'sinformation isconsidered to be more recentand is accepted.

If thereceiving switch'srevision number ishigher than that of the incoming advertisement, the incoming advertisement is considered out-of-date and is therefore ignored.

If you want to authenticate VTP updates, you can do so with the vtp password command. This password is case-sensitive and needs to be set on every VTP switch in the domain.
SW1(config)#vtp password CCNA Setting device VLAN database password to CCNA

Although this is referred to as secure VTPand VTP Secure mode, there'svery littleabout it that's secure - the command show vtp password displays the password, and this password can't be encrypted with service password-encryption.
SW1#show vtp password VTP Password: CCNA SW1(config)#service password-encryption SW1#show vtp password VTP Password: CCNA

VTP Pruning Trunk ports belong to all VLANs, which leads to an issue involving broadcasts and multicasts. 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! In the following example, VTP allows both switches to know about VLANs 2 - 19, even though neither switch has ports in all those VLANs. Since a trunk port belongs to every VLAN, they both forward broadcasts and multicasts for all those VLANs. Both switches are transmitting and receiving broadcasts and multicasts that they do not need, since the only VLANs they have in common are VLANs 10 and 11.

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. The command vtp pruning enables pruning for all VLANs in the VTP domain. All VLANs from 2 - 1001 are eligible to be pruned. The reserved VLANs you see in show vlan brief - VLANs 1 and 1002 - 1005 - cannot be pruned. You cannot enable pruning on a VTP client.
SW1(config)#vtp pruning Cannot modify pruning unless in VTP server mode SW1(config)#vtp mode server Setting device to VTP SERVER mode SW1(config)#vtp pruning Pruning switched on

As a result of VTP pruning, only broadcasts and multicasts for the VLANs actually needed by the remote switch will be sent across the trunk. In this case, each switch will now send broadcast and multicasts across the trunk only if they're intended for VLANs 10 and 11.

Verify VTP pruning has been enabled with show vtp status.
SW1#show vtp status VTP Version : 2 Configuration Revision : 1 Maximum VLANs supported locally : 64 Number of existing VLANs : 5 VTP Operating Mode : Server VTP Domain Name : VTP Pruning Mode : Enabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled

"Router On A Stick" We have two options for configuring interVLAN communication:

Using an L3 switch Configuring "router on a stick" (ROAS)

L3 switches are becoming more and more prevalent in today's networks, and as a CCNA you should know that an L3 switch doesn't require an outside device to allow

interVLAN communication. You're very likely to see ROAS configs on your CCNA exam, though, and let's face it - we can't just tear out a client's L2 switch and replace it with an L3 switch just because we want to! We'll first go through an ROAS configuration with the following network, and then we'll take a detailed look at troubleshooting. Oncethis configis up and running, you can leave it alone for months or years, but there are quite a few details that we need towatch to get it up and running! Here's the network:

Right away, we've got a few important details to take note of:

As expected, the switch ports connected to the hosts are access ports. The switch port connected to the router must be trunking, and the trunking protocol (ISL or dot1q) must be the same as that used by the router. The router must use a Fast Ethernet port for ROAS. A regular Ethernet port will not suffice. (Gigabit Ethernet, or 1000 MBPS Ethernet, is great, too, but you probably won't have a spare Gig Ethernet port to spare.)

Let's verify those VLAN memberships:

SW1#show vlan brief VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------1 default active Fa0/3, Fa0/5, Fa0/6, Fa0/7 Fa0/8, Fa0/9, Fa0/10, Fa0/11 Fa0/12, Fa0/13, Fa0/14, Fa0/15 Fa0/16, Fa0/17, Gi0/2 2 VLAN0002 active Fa0/2 4 VLAN0004 active Fa0/4

Looks good. Since port Fa0/1 is trunking, we will not see it in that output; instead, we'll run show interface trunk.
SW1#show interface trunk Port Mode Encapsulation Status Native vlan Fa0/1 on isl trunking 1

That port is up and trunking with ISL encapsulation. Let's move up to the router and begin the configuration. The next important detail is that the Fast Ethernet port on the router will be using subinterfaces, and we'll use two commands on each subinterface:

the encapsulation command, matching the encap type set on the connecting switch's trunk port an appropriate IP address for the VLAN indicated by the encapsulation command

Sounds complicated, but it's not. However, you have to use the encapsulation command first. If you try to apply an IP address onto the subinterface first, here's

the message you get.

R1(config)#int fast 0/0.2 R1(config-subif)#ip address 172.12.2.1 255.255.255.0 % Configuring IP routing on a LAN subinterface is only allowed if that subinterface is already configured as part of an IEEE 802.10, IEEE 802.1Q, or ISL vLAN.

So let's do just that, and then apply the IP address.

R1(config-subif)#encapsulation isl 2 R1(config-subif)#ip address 172.12.2.1 255.255.255.0

Let's use IOS Help to look at the options we had for the encapsulation command, and just why I have that number "2" in bold.
R1(config)#int fast 0/0.2 R1(config-subif)#encapsulation ? dot1Q IEEE 802.1Q Virtual LAN isl Inter Switch Link - Virtual LAN encapsulation R1(config-subif)#encapsulation isl ? <1-1000> Virtual LAN Identifier. R1(config-subif)#encapsulation isl 2 R1(config-subif)#ip address 172.12.2.1 255.255.255.0

The IP address must come from the address space of the VLAN we indicate with the encapsulation command. This interface will be part of VLAN 2, so we had to put an IP address from the 172.12.2.0 /24 subnet. Where did I get that IP range? Check the IP address of the host that's already in VLAN 2.

That's probably the most common error in a ROAS configuration. Make sure you have the right VLAN ID associated with the appropriate IP address on the router subinterfaces! Now let's configure a subinterface to be part of VLAN 4. That subinterface will need an IP address from the 172.12.4.0 /24 subnet.
R1(config-subif)#int fast 0/0.4 R1(config-subif)#encap isl 4 R1(config-subif)#ip address 172.12.4.1 255.255.255.0

When you're done, don't forget to open the physical interface!

R1(config-subif)#int fast 0/0 R1(config-if)#no shut R1(config-if)#^Z R1#wr Building configuration... [OK] R1# *Nov 27 04:35:52.171: %SYS-5-CONFIG_I: Configured from console by console *Nov 27 04:35:53.675: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up *Nov 27 04:35:54.871: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

I'll run show interface fast 0/0.2 to see what we can see!
R1#show interface fast 0/0.2 FastEthernet0/0.2 is up, line protocol is up Hardware is AmdFE, address is 000a.4164.31c1 (bia 000a.4164.31c1) Internet address is 172.12.2.1/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ISL Virtual LAN, Color 2. ARP type: ARPA, ARP Timeout 04:00:00 Last clearing of "show interface" counters never

The encapsulation type is listed along with the VLAN number - that's behind the interesting term "Color". We'll verify fast 0/0.4 as well.
R1#show interface fast 0/0.4 FastEthernet0/0.4 is up, line protocol is up Hardware is AmdFE, address is 000a.4164.31c1 (bia 000a.4164.31c1) Internet address is 172.12.4.1/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ISL Virtual LAN, Color 4. ARP type: ARPA, ARP Timeout 04:00:00 Last clearing of "show interface" counters never

At this point, the default gateway on the hosts must be set to the appropriate subinterface IP address on the router. If you have an IP address assigned to the switch - remember, we canapply an IP address to the switch's VLAN1 interface to make remote management possible - do not use that IP address. Always use the appropriate IP address from the router's subinterfaces as the default gateway for each host. For our host in VLAN 2, that address is the router subinterface's IP address in the VLAN 2 address space, and for the VLAN 4 host it's the subinterface's IP address in VLAN 4.

And of course, the final test - do we now have interVLAN communication? From Host 4, let's ping the following three addresses:

Host 4's own default gateway, 172.12.4.1 Host 2's default gateway, 172.12.2.1 Host 2, 172.12.2.2

Host4#ping 172.12.4.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.4.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms Host4#ping 172.12.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Host4#ping 172.12.2.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

All three are successful! Let's ping the following three destinations from Host 2:

Host 2's own default gateway, 172.12.2.1 Host 4's default gateway, 172.12.4.1 Host 4, 172.12.4.4

Host2#ping 172.12.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Host2#ping 172.12.4.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.4.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Host2#ping 172.12.4.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Success! If you have connectivity issues from one host to another after configuring ROAS, you should follow that order - always ping your local host's default gateway first. If you can't ping that, there's no way you can ping the other two! ROAS does work beautifully, but as you now know, there are quite a few details to attend to. I'll list those here and then we'll look at some common misconfigurations. The Router: The port must be a Fast Ethernet port. An Ethernet port won't do the job. You can create Ethernet subinterfaces, but the encapsulation command will not be recognized.
R3(config)#interface e0.12 R3(config-subif)#encapsulation ? % Unrecognized command

Subinterfaces must be configured on the FE port. The trunking protocol configured on the router's subinterfaces must match that of the trunk port connected to that router. The IP address configured on a subinterface must be part of the subnet used by the VLAN indicated in the encapsulation command. For example, the following config required an IP address from VLAN 2's address space since the encapsulation command is configured with a VLAN ID tag of 2.
R1(config)#int fast 0/0.2 R1(config-subif)#encapsulation ? dot1Q IEEE 802.1Q Virtual LAN isl Inter Switch Link - Virtual LAN encapsulation R1(config-subif)#encapsulation isl ? <1-1000> Virtual LAN Identifier. R1(config-subif)#ip address 172.12.2.1 255.255.255.0

The Switch: The switch port connected to the router must be trunking. The trunking protocol in use (ISL or dot1q) must match the one in use on the router's subinterfaces. Naturally, the ports leading to the hosts must be access ports. The Hosts: Each host should have its default gateway set to the IP address on the router subinterface that is part of that VLAN's address space. ROASFSC (Frequently Screwed-up Configurations) I think you'll agree with me that the ROAS config is very straightforward, but it is commonly misconfigured. Since there's not much to configure in the first place, the misconfiguration is pretty easy to spot! Since we perform most of the ROAS config on the router, we tend to concentrate on the router config when we have a problem. What we have to keep in mind with ROAS troubleshooting is that the problem might not be on the router - it might be on the hosts, or even the switch! Frequent ROASMisconfig #1: Wrong Default Gateway Settings

If you spotted that right away, nice work! The default gateway settings on the hosts are backwards. The default gateway address must always be in the same subnet as the host's IP address. Frequent ROASMisconfig #2: Router IP Addresses & VLAN IDs Do Not Match Up

R1 Config:
interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.2 encapsulation isl 2 ip address 172.12.4.1 255.255.255.0 no ip redirects no snmp trap link-status ! interface FastEthernet0/0.4 encapsulation isl 4 ip address 172.12.2.1 255.255.255.0 no ip redirects no snmp trap link-status

This is one of the two most common ROAS configs. An IP address from VLAN 2's subnet has been applied to the subinterface with the VLAN 4 ID, and vice versa. With that config, neither host will even be able to ping its own default gateway.
Host4#ping 172.12.4.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.4.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Host2#ping 172.12.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.2.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

ROAS troubleshooting can be a little tricky without a structured approach, so I suggest the approach I've always used:

Always check the default gateway settings on the hosts first. Make sure the port leading to the router is trunking. On the router, make sure the IP address assigned to each subinterface is from the subnet assigned to the VLAN that's assigned to that subinterface.

Follow those three tips and you'llconfigure and troubleshoot ROAS successfully every time!

Rapid Spanning Tree Protocol So you understand STP, and you've got all those STP features down - and now here's another kind of STP! Specifically, it's RSTP, or Rapid Spanning Tree Protocol. RSTP is defined by IEEE 802.1w, and is considered an extension of IEEE

802.1d, the formal name of STP. Where does the "rapid" part come in? Isn't STP rapid enough? Well ... not really. The 30-second delay caused by the listening and learning states during STP convergence was once considered an acceptable delay. Then again, a floppy disk used to be considered all the storage space anyone would ever need, and that theory didn't exactly stand the test of time! Root bridges are still elected with RSTP, but the port roles themselves are different between STP and RSTP.Let's take a look at the RSTP port roles in the following three-switch network, where SW1 is the root. We'll use the same switched network we used in the STP discussion, with one exception - there's a hub on SW3. And you just know it's gotta be there for a reason! And just to complicate things, we've got two physical connections from SW3 to the hub. (Actually, I put it there to illustrate an RSTP port state.)

RSTP uses the root port in the same fashion that STP does. All nonroot ports will select a root port, and this port is the one reflecting the lowest root path cost. Assuming all links in this network are running at the same speed, SW2 and SW3 will both select the port directly connected to SW1 as their root ports. As with STP, there will be no root port on a root bridge.

An RSTP designated port is the port with the best root path cost. Just as with STP, the ports on the root port will be DPs. We'll assume R3 has the DP for the segment connected to SW2.

At this point, you're probably wondering what the real differences between STP and RSTP are! Here's one - RSTP'sequivalent to an STP blocked port is an alternate port. In this segment, SW2's port leading to SW3 is an alternate port.

In this network, SW3 has two separate ports on the same physical segment. One portwill be thedesignated port for that segment, and the other port will become the backup port. This port gives a redundant path to that segment. The only time you'll see a backup port is when a switch has two connections to the same segment. You don't see this terribly often, but you do see it!

The "rapid" in RSTP comes in with the new port states. The STP port states disabled, blocking, and listening are combined into the RSTP port state discarding, which is the initial RSTP port state. RSTP ports transition from the discarding state to the learning state, where incoming frames are still discarded. However, the MAC addresses are now being learned by the switch. Finally, an RSTP port will transition to the forwarding state, which is the same as the STP forwarding state. Let's compare the transition states:

STP: disabled > blocking > listening > learning > forwarding RSTP: discarding > learning > forwarding There are other port types unique to RSTP. You know what a root port is, but RSTP also has edge ports and point-to-point ports. An edge port is just what it sounds like - a port on the edge of the network. In this case, it's a switch port that is connected to a single host, most likely an end user's PC. An edge port will operate just like an STP port that is running Portfast.

A point-to-point port is any port that is connected to another switch and is running in full-duplex mode. Edge Ports And RSTP Topology Changes Edge ports play a role in when RSTP considers a topology change to have taken place. Rather, I should say that they don't play a role, because RSTP considers a topology change to have taken place when a port moves into Forwarding mode unless that port is an edge port. When an edge port moves into Forwarding mode, RSTP doesn't consider that a topology change, since only a single host will be connected to that particular port. Another major difference between STP and RSTP is the way BPDUs are handled. With STP, only the root bridge is sending BPDUs every two seconds; the nonroot bridges simply forward, or relay, that BPDU when they receive it. RSTP-enabled switches generate a BPDU every two seconds, regardless of whether they have received a BPDU from the root switch or not. (The default value of hello time, the interval at which switches send BPDUs, is two seconds in both STP and RSTP.) This change not only allows all switches in the network to have a role in detecting link failures, but discovery of link failures is faster. Why? Because every switch expects to see a BPDU from its neighbor every two seconds, and if three BPDUs are missed, the link is considered down. The switch then immediately ages out all information concerning that port. This cuts the error detection process from 20 seconds in STP to 6 seconds in RSTP. Let's compareSTPand RSTPand their link failure detection times. When a switch running STP misses a BPDU, the MaxAge timer begins. This timer dictates how long the switch will retain the last BPDU before timing it out and beginning the STP recalculation process. By default, MaxAge is 20 seconds. When a switch running RSTP misses three BPDUs, it will immediately are out the superior BPDU's information and begin the STP recalculation process. Since the default hello-time is 2 seconds for both STP and RSTP, it takes an RSTP-enabled switch only 6 seconds overall to determine that a link to a neighbor has failed. That's where the "rapid" part comes in! Per-VLAN Spanning Tree Per-VLAN Spanning Tree Plus (PVST+) is just what it sounds like - every VLAN has its own instance of STP running. PVST+allows per-VLAN load balancing and is also

Cisco-proprietary. The "+" has been left off this acronym for so long that it's generally just referred to as "PVST" today. PVST is actually the version of STP that we've been running during the entire switching section of the course - Cisco Catalyst switches run PVST by default. You'll see many of the benefits of PVST in future studies, but just to mention one - we can load-balance on a per-VLAN basis by default. Let's take a quick look as to when that might come in handy using a two-switch example.

We know that we'll have one root bridge selected; we'll assume it's the one on the right. We also know that the non-root bridge will select one root port, and the other port leading to the root bridge will go into blocking mode. If we have 50 VLANs in this network, traffic for all 50 VLANs will go over one of the two available links while the other remains totally idle.

That's not an efficient use of available resources! With PVST, we can fine-tune the port costs on a per-VLAN basis to enable one port to be selected as the root port for half of the VLANs, and the other port to be selected as the root port for the other half. That's per-VLAN load balancing!

We've got another option for better utilization of multiple trunk links - an Etherchannel. Etherchannels An Etherchannel is the logical bundling of two to eight parallel Ethernet trunks. This bundling of trunks is also referred to as aggregation. This provides greater throughput, and is another effective way to avoid the 50-second wait between blocking and forwarding states in case of a link failure. Spanning-Tree Protocol (STP)considers an Etherchannel to be one link. If one of the physical links making up the logical Etherchannel should fail, there is no STP reconfiguration, since STP doesnt know the physical link went down. STP sees only the Etherchannel, and a single link failure will not bring an Etherchannel down. In this example, we have two switches connected by three separate crossover cables.

We'll verify the connections with show interface trunk and then run show spanningtree vlan 1.
SW1#show interface trunk Port Fa0/10 Fa0/11 Fa0/12 Mode desirable desirable desirable Encapsulation 802.1q 802.1q 802.1q Status trunking trunking trunking Native vlan 1 1 1

SW1#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000b.be2c.5180 Cost 19 Port 10 (FastEthernet0/10) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e2.25c0 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15 Role ---Root Altn Altn Sts --FWD BLK BLK Cost --------19 19 19 Prio.Nbr -------128.10 128.11 128.12 Type -----------------------P2p P2p P2p

Interface ---------------Fa0/10 Fa0/11 Fa0/12

We know this is not the root switch, because...

there's no "thisbridge is the root" message there is a root port, which is forwarding

So right now, we have three physical connections between the two switches, and only one of them is actually in use. That's a waste of bandwidth! Additionally, if the root port goes down, we're in for a delay while one of the other two ports comes out of blocking mode and through listening and learning mode on the way to forwarding. Both of these issues can be addressed by configuring an Etherchannel. By combining the three physical ports into a single logical link, not only is the bandwidth of the three links combined, but the failure of a single link will not force STP to recalculate the spanning tree. Ports are placed into an Etherchannel with the channel-group command. Natually, the channel group must be the same on all interfaces that will be part of that particular Etherchannel. Here's the configuration, and this is a great chance to practice our interface range command! (Nothing wrong with configuring each port individually, but this command saves time - on the job and in the exam room!)
SW1(config)#interface range fast 0/10 - 12 SW1(config-if-range)#channel-group 1 mode on Creating a port-channel interface Port-channel 1 00:33:57: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up 00:33:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changedstate to up SW2(config)#int range fast 0/10 - 12 SW2(config-if-range)#channel-group 1 mode on Creating a port-channel interface Port-channel 1

00:47:36: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up 00:47:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changedstate to up

After configuring an Etherchannel on each router with the interface-level command channel-group, the output of commands show interface trunk and show spanning vlan 1verifiesthat STP now sees the three physical links as one logical link -- the virtual interface port-channel 1 ("Po1"). Note that the Etherchannel's cost is 9, instead of 19. This lower cost reflects the increased bandwidth of the Etherchannel as compared to a single physical connection.
SW1#show interface trunk Port Mode Encapsulation Status Native vlan Po1 desirable 802.1q trunking 1 SW1#show spanning vlan 1 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- --------------------------Po1 Root FWD 9 128.65 P2p

Before configuring the Etherchannel, closing fast0/10 would have resulted in an STP recalculation and a temporary loss of connectivity between the switches. Now that the channels are bundled, I'll close that port and immediately run show spanning vlan 1.
SW1(config)#int fast 0/10 SW1(config-if)#shut SW1#show spanning vlan 1 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- ------------------------Po1 Root FWD 12 128.65 P2p

The cost is now higher since there are only two physical channels bundled instead of three, but the truly important point is that STP does not consider the Etherchannel to be down and there's no loss of connectivity between our switches. "Hot Spots And Gotchas" Yeah, I know it's a big chapter. But you gotta read it before you read this summary! ;) And with a chapter this big, this is just that - a summary! STP The Spanning Tree Protocol is a Layer 2 switching loop prevention protocol. BPDUs are the heartbeat of STP, and are originated by root switches and forwarded by all other switches. No host device or router is going to send a BPDU. The root bridge is the one with the lowest BID, and that BID is a combination of the priority and the switch's MAC address. In Per-VLAN Spanning Tree (PVST), each VLAN will have its own root switch. Of course, if you leave things at the default, every VLAN will have the same root switch. The STP port states: disabled, blocking, listening, learning, forwarding. A port begins learning MAC addresses in learning mode, and continues to do so once it's migrated to forwarding mode.

Root switches will have the phrase "this switch is the root" in its show spanning-tree vlan output. If you don't see that phrase, the information under Root ID indicates which switch is the root. STP convergence has occured when the switched network is "quiet" - that is, all ports are either blocking or forwarding, with none in the intermediate states of listening and learning. To view the MAC address table on a per-VLAN basis, run the show mac-addresstable vlan command followed by the VLAN number. To see the dynamic entries only, run show mac-address-table dynamic vlan command. An excellent troubleshooting command! The root switch will have no blocked ports, and all ports will be Designated Ports (DP). Non-root switches select their root port (RP) on the basis of path cost through each potential root port. The port with the lowest overall path cost will be the root port.

VLANs VLANs are used to create multiple, smaller broadcast domains. This helps to limit the scope of the broadcasts. By default, all switch ports belong to the default VLAN, VLAN 1. VLAN 1 cannot be deleted. The default VLAN is also called the native VLAN. The native vlan can be changed with the switchport trunk native vlan command. VLANs allow the restriction of access to network resources on a per-user or a perdepartment basis. As you'll see in a later section, access lists are great for this as well - it just depends on your network topology and your exact needs. When moving a switch from one switched network to another, make sure to erase the VLAN database on that switch before putting it into the new network. As a bonus for reading this section, here's how you do it:
SW1#delete vlan.dat Delete filename [vlan.dat]? Delete flash:vlan.dat? [confirm] SW1#

Just hit ENTER to accept those prompts - if you type in "y" or "yes" to that second question, the switch thinks you're trying to delete a file called "y" or "yes"!

Trunking The trunking port modes are desirable, on, off, nonegotiate, and auto.

Desirable - port is actively attempting to trunk with remote port Auto - port will trunk if the other port initiates the process On - port has sent Dynamic Trunking Protocol frames to remote port and is unconditionally ready to trunk Nonegotiate - port has NOT sent DTP frames, and is unconditionally ready to trunk Off - port is an access port and cannot trunk

Even though trunk ports belong to all VLANs by default, they will not appear in the

output of show vlan brief. Instead, run show interface trunk - that will display the trunking ports, their modes, and the trunking protocols in use. Access ports vs. Trunk ports Access ports:

belong to one and only one VLAN connect a host device to the switch uses a straightthrough cable for that connection literally cannot trunk

Trunk ports:

By default, belongs to all VLANs Connects another switch to the local switch (or a router, in the case of routeron-a-stick) Can use ISL or dot1q as the trunking port Uses a crossover cable for the trunk

VTP VTP's purpose is to allow switches to exchange VLAN information. A VTP domain must have at least one VTP Server. VTP Servers allow the deletion, creation, and modification of VLANs. These changes are advertised throughout the VTP domain. VTP Clients cannot delete, create, or modify VLANs. VTP Transparent switches can delete, create, and modify VLANs; however, these changes are locally significant only and are not advertised. For switches to exchange information via VTP, they must be in the same VTP domain. The VTP domain name is case-sensitive. You can set a VTP password,officially called "secure mode". That password will be contained in the VTP advertisements, and must match on all switches in the VTP domain. VTP Clients will both process and forward VTP summary advertisements. Only the VTP Server can originate these ads. VTP Transparent switches will forward these advertisements, but will not process them. VTP Clients can only save their VLAN information to the running configuration; they cannot save this information in NVRAM. The Client will have to get that information from a VTP Server upon a reload of the Client. Both VTP Server and Transparent switches save their VLAN information to NVRAM. VTP devices keep a configuration revision number, and if a VTP ad comes in with a revision number lower than the receiving switch's number, that update is ignored. If a VTP ad comes in with a revision number higher than the receiving switch's number, that update is accepted and the information in it is used to overwrite the receiving switch's VLAN database.

Router-On-A-Stick The hosts must have their default gateway set to the router subinterface IP address that is part of their VLAN's address space. The switch port leading to the router must be trunking. ROAS is one of the two ways to allow interVLAN communication. A Layer 3 switch is the other. L3 switch configuration is not part of the CCNA or CCENT exam. The fastethernet interface requires subinterfaces, one for each VLAN. There will be no IP address on the physical interface. Each subinterface must be configured with the encapsulation command reflecting the VLAN ID of that subinterface and an IP address. Back To Index
Copyright 2011 The Bryant Advantage. All Rights Reserved.