Bryant BCMSN Study Guide

careercert.blogspot.
com
The Bryant Advantage BCMSN Study Guide

Chris Bryant, CCIE #12933 www.thebryantadvantage.com Back To Index
Basic Switch Operation & Configuration

Overview
Ethernet Types Basic Switch Operation How The Switch Builds Its MAC Table Basic Switch Configuration Breaking Down Cisco IOS Filenames The Interface Range And Description Commands The Errdisable Recovery Command
Before we get to the switch in this chapter, we're going to spend a few minutes going over some Ethernet types and limitations. You know from your CCNA studies how CSMA/CD works, but we don't just have Ethernet anymore... we've got Ethernet, Long Range Ethernet, Fast Ethernet, Gig Ethernet, and more! So even if you're comfortable with your Ethernet knowledge, spend a few minutes here going over these basics and then we'll get back to the switch -- I promise! Ethernet Good old "basic" Ethernet is based on IEEE 802.3, and offers a bandwidth of 10 MB to end users. The more users there are on an Ethernet segment, the higher the chance of collisions, which render signals sent by the hosts to an unusable state. When the hosts are connected to their own individual switch ports, they will each get a dedicated 10 MB and the chance of collisions is eliminated. Each port on a switch is its own collision domain. Ethernet uses UTP cabling (Unshielded Twisted Pair), and this cable type has a length limit of 100 meters. Referring to the Cisco three-layer networking model, Ethernet is generally going to be found at the access layer, connecting end users to the network. Fast Ethernet Fast Ethernet is defined in IEEE 802.3u, and operates at 100 MB. FE can use UTP or fiber-optic wiring. When full-duplex FE is in operation, the effective bandwidth is 200 MBPS, since FE ports can send and receive at the same time.
careercert.blogspot.com
You'll see "10/100" ports on many switches. This means that the port will work with an Ethernet or Fast Ethernet connection, and the port speed can be negotiated between the switch and the connected device. To allow this negotiation, both end devices should be set for "auto", short for autonegotiation. And as you know, if you're connecting a server, router, or workstation to a switch, you'll need a straight-through cable. Fast Ethernet ports can also be used to create a Fast EtherChannel. An Etherchannel, or EC, is a logical bundling of physical connections between switches. A Fast EC can bundle up to eight physical connections, resulting in throughput of up to 1600 MBPS! As with Ethernet, Fast Ethernet connections can connect end users to the access-layer switches. FE ports can also be used to form a trunk between the access and distribution-layer switches, but hopefully we've got some Gigabit Ethernet ports to handle that. Gigabit Ethernet The next logical step is Gigabit Ethernet, often referred to as "Gig Ethernet". Gig Ethernet will support speeds up to 1000 MBPS, or 1 Gigabit Per Second (GBPS). The cabling you use with your Gig Ethernet ports is going to vary widely. The necessary cable is determined by the Gigabit Ethernet standard in use on your particular switch. Some of the more common cable types to use with Gigabit Ethernet are Shielded Twisted-Pair (STP), Multimode Fiber (MMF) cable with either a 50- or 62.5 micron core, and Single-Mode Fiber (SMF) with an 8-, 9-, or 50-micron core. I told you there were quite a few cables that support Gig Ethernet! Make sure to check your switch's documentation before you start buying cables! 10 Gigabit Ethernet Often referred to in documentation as 10GbE. 10Gig Ethernet will only work on fiber-optic and in full-duplex mode. (That's the only way all that speed can be used!) Long Range Ethernet No, LRE isn't faster than 10 Gig Ethernet! LRE can use preexisting wiring to provide Ethernet service to a building that might not otherwise have it. The preexisting wiring is usually going to be the phone wires. The available speed is dependent on the cable length - the longer the wire, the less bandwidth that's available. A Quick Cable Review To connect your PC to the console port of a switch, you must have a rollover cable. Check your PC in advance to make sure you don't need an adapter for the rollover cable. Many laptops no longer have a DB9 port. To connect a router, PC, or server to a switch, you'll need a straightthrough cable. If the router has an AUI port, you'll also need a transceiver for the router. The transceiver connects to the router and the cable connects to the transceiver.
To connect two switches, you'll need a crossover cable. What's A "Geebic"? A GBIC, pronounced "geebic", is a module that fits into a Gig Ethernet port. These modules are hot-swappable for easier migration to a new media type. Basic Switch Operation As a CCNA and CCNP candidate, you should be more than familiar with the basic operation of a switch, how the MAC address table is built, and basic switch configuration. Just in case you're a little rusty, we're going to review that information here, and add a few commands you might not be as familiar with. A switch uses Layer 2 addresses, more commonly referred to as MAC addresses, to forward or filter frames as needed. When a switch is first powered on, its MAC address table is empty. While a MAC table can be populated with static MAC entries, it's more efficient to have the switch learn the addresses dynamically. The switch does this by examining the source MAC address before deciding how to get the frame to the destination MAC address. When a switch examines the source MAC of a frame, the switch checks its MAC table to see if there's an entry for that address. If not, the switch adds that address to its MAC table along with the port used to reach that address. The switch will then check its MAC table for the destination MAC. There are four possibilities for that destination MAC: The destination MAC is a unicast and there is no entry for the address in the MAC table. This frame will be flooded - it will be sent out every switch port except the one it came in on.
The destination MAC is a unicast and there is an entry for the address in the MAC table. In this case, the frame will be sent out only the port leading to the host with the proper destination MAC.
The destination MAC is a unicast, and there is an entry for the address in the MAC table, AND the source and destination address are found off the same port. This frame will be filtered - it will not be forwarded at all by the switch.
The destination MAC is a broadcast or multicast, in which case the frame will be sent out every port except the one it was received upon.
Let's look at these possibilities using the following network.
If the switch's MAC table is empty and Host A sends a frame to Host B, the switch will end up forwarding a copy of the frame out every port except 0/1. The switch will also make an entry in its MAC table for Host A as a result of examining the frame's source MAC address.
When Host B replies, the switch will first examine the source MAC address and will then make an entry it its table for Host B. The switch will see that it already has an entry for Host A, so the switch will unicast the frame out port 0/1.
Once the switch has entries for all three hosts, the switch will realize that Host A and Host C are found off the same port. If either of those hosts sends a frame to the other, the switch will filter the frame.
The official terminology for the MAC table is the CAM table, or Content Addressable Memory table. Depending on who you talk to, you'll hear this table called... the MAC address table the CAM table the bridging table ... but they're all the same thing. This command has quite a few options, all shown below thanks to IOS Help.
SW2#show mac-address-table ? address address keyword aging-time aging-time keyword
count count keyword dynamic dynamic entry type interface interface keyword multicast multicast info for selected wildcard notification MAC notification parameters and history table static static entry type vlan VLAN keyword | Output modifiers <cr> SW2#show mac-address-table dynamic Mac Address Table ------------------------------------------Vlan Mac Address Type Ports -------- -------- ----------1 000e.d7f5.a04b DYNAMIC Fa0/11 Total Mac Addresses for this criterion: 1
Basic Switch Configuration Commands As a CCNA, you already know that the command to name a switch is hostname. This command is run in global configuration mode, and like all global commands, this command takes effect immediately.
SW2(config)#hostname SWITCH_2 SWITCH_2(config)#
Sooner or later, you're going to need remote access to your network's switches. You can assign an IP address to the switch's management interface (by default, the vlan 1 interface) with the interface vlan command.
SWITCH_2(config)#interface vlan 1 SWITCH_2(config-if)#ip address 20.1.1.1 255.255.255.0
To allow Telnet access to any Cisco device, a vty password has to be set. You must also either set an enable password or enable secret, or use the command privilege level 15 to put a telnetting user straight into privileged exec mode. A console password can also be set just as you would on a router, and the service password-encryption command can be used to encrypt these commands as well.
SWITCH_2(config)#line vty 0 15 SWITCH_2(config-line)#password CCNP SWITCH_2(config-line)#login
SWITCH_2(config-line)#line console 0 SWITCH_2(config-line)#password CCIE SWITCH_2(config-line)#login SWITCH_2(config)#enable password CCNA
All these passwords appear in clear text, until the service passwordencryption command is run.
line con 0 exec-timeout 0 0 password CCIE login line vty 0 4
password CCNP login line vty 5 15 password CCNP login SWITCH_2(config)#service password-encryption line con 0 exec-timeout 0 0 password 7 096F6D203C login line vty 0 4 password 7 08026F6039 login line vty 5 15 password 7 08026F6039 login
There's one more Telnet option you may not have considered or known about, but with the need for security today, it's one you should strongly consider. Telnet connections take place over channels that are basically non-secure, but using Secure Shell instead will allow a user to connect to the switch over a secure channel and using strong authentication. To configure a switch to allow only Secure Shell connections:
line vty 0 15 transport input ssh
This is *not* all there is to SSH; quite the opposite. Configuring a network for SSH is out of the scope of the BCMSN exam, but you can visit www.cisco.com/univercd to learn more about configuring SSH with your particular IOS versions. Copying Switch Configuration Files Believe me - you're going to move files on a Cisco switch sooner or later, probably sooner! You may want to back up the starting configuration, update an IOS, or copy the running configuration over the startup configuration - and the key word is "copy". The copy command can be used to move files to and from any valid location, but the command does take a little getting used to. Let's use IOS Help to take a more detailed look at this simple command.
SWITCH_2#copy ? /erase /noverify bs: flash: ftp: null: nvram: rcp: running-config startup-config system: tftp: xmodem: ymodem: Erase destination file system. Disable automatic image verification after copy Copy from bs: file system Copy from flash: file system Copy from ftp: file system Copy from null: file system Copy from nvram: file system Copy from rcp: file system Copy from current system configuration Copy from startup configuration Copy from system: file system Copy from tftp: file system Copy from xmodem: file system Copy from ymodem: file system
Note that all the descriptions contain the word "from". The first location you specify in the copy command is the current location of the file, while the second location is where you want to file copied to.
SWITCH_2#copy startup-config ? flash: Copy to flash: file system ftp: Copy to ftp: file system null: Copy to null: file system nvram: Copy to nvram: file system rcp: Copy to rcp: file system running-config Update (merge with) current system configuration startup-config Copy to startup configuration system: Copy to system: file system tftp: Copy to tftp: file system
The copy command can be a pain if you're updating IOS images or saving them to a TFTP server, due to the sheer length of an IOS image filename. Just be careful, remember the syntax of the copy command, and you'll be fine. Speaking of which, ever wonder what a Cisco filename means? Look at the IOS image filename on the switch we've been using in this chapter: c2950-i6q4l2-mz.121-19.EA1.bin Believe it or not, that mix of numbers and letters actually means something. There is a standard for IOS filenames, so as we decipher this filename, remember that you can use this method to do so with any IOS filename. c2950 - This one's easy, since we're working on a Catalyst 2950 switch. i6q4l2 - This part describes the switch's feature set. The i at the beginning of this feature set description indicates a switch running an IP feature set. mz - The m indicates that the image is running in RAM; the z indicates a zip-compressed image. 121-19.EA1 - The 121 indicates the major IOS release version, 12.1. The 19 is the maintenance release. The E indicates an Early Deployment of features. A indicates the interim build level, in this case the first one ("A"). The 1 indicates the first build of that level, and finally the .bin indicates that the image file is a binary executable. Choosing A Range Of Ports If you'd like to configure a group of ports with a given command rather than one at a time, use the interface range command. The speed and duplex commands are also shown in the following example. Make sure to get some practice with this command - it'll make your life a lot easier on Cisco exams and when working on production networks.
SW2(config)#interface range fast 0/1 - 11 SW2(config-if-range)#speed 10 SW2(config-if-range)#duplex half
This may not seem like the world's most important command, but believe me - whether you're asked to configure a feature on 12 ports during the exam or 24 ports in a production network, you're going to be really glad you know this command! Describing A Port's Purpose
It's a great idea to take a few seconds to describe what a port is being used for, and you can do this with the description command. In the following example, we're using the interface range command in combination with the description command to make a notation in the configuration that these ports are trunking with SW1. Note that the description appears under each port named in the range.
SW2(config)#interface range fast 0/11 - 12 SW2(config-if-range)#description ports trunking with SW1 interface FastEthernet0/11 description ports trunking with SW1 no ip address ! interface FastEthernet0/12 description ports trunking with SW1 no ip address
Autorecovery From An Err-Disabled State A switch port will be placed into error-disabled state, referred to on the switch as err-disabled, under certain circumstances such as a violation of port security. By default, a port in err-disabled state has to be manually reopened. (The port LED will go out as well; as you'd suspect, a green LED indicates an active port.) You may have a situation where you want the port to re-enable itself after a certain period of time, and this can be configured with the errdisable recovery interval command. Before doing so, though, you must define the causes from which the port can recover automatically. We'll use the "all" option here to allow the port to autorecover from any err-disabled state.
SW2(config)#errdisable recovery cause all SW2(config)#errdisable recovery interval ? <30-86400> timer-interval(sec) SW2(config)#errdisable recovery interval 300
As with any command involving time, you should first check the unit of time this particular command uses. Some Cisco commands use seconds, some use minutes, some use hours. If you want a five-minute interval before the port re-enables, you need to enter 300, not 5.
Copyright 2007 The Bryant Advantage. All Rights Reserved.

Chris Bryant, CCIE #12933 http://www.thebryantadvantage.com Back To Index
Virtual LANs (VLANs)

Overview
Why We Create VLANs Static VLANs Dynamic VLANs Trunking ISL and IEEE 802.1q Troubleshooting Trunks The Native VLAN Dynamic Trunking Protocol (DTP) Trunking Modes VLAN Database Mode VLAN Design Guidelines End-To-End And Local VLANs
The solid foundation of LAN switching knowledge you built during your CCNA studies is going to serve you well on BCMSN exam day! In this chapter, we're going to revisit some basic VLAN concepts and expand on them in order to prepare you for total success on your exam and on your job. And if your LAN switching knowledgebase isn't quite what you'd like, or is a little rusty, don't worry - you'll be back up to speed in no time. Before we review VLAN basics, let's have a quick refresher on why we configure them in the first place.
The most common reason for creating VLANs is to prevent the excess traffic caused by a switch's default behavior when it receives a broadcast. One of the first switching concepts you learned was that a switch that receives a broadcast will forward it out every other port on the switch except the one that it was originally received on. Here, we have five PCs connected to their own switch port. One PC is sending a broadcast, and by default all other devices in the diagram will receive it. This network segment is one large broadcast domain. To lessen the number of broadcasts being flooded throughout the network, we can either introduce a Layer 3 device or configure VLANs. There are only five PCs in this diagram - what if there were 48? We'd have a broadcast being sent to 47 hosts every time a broadcast was received by the switch. Odds are that all those hosts don't need that particular packet, and on top of that we're losing valuable bandwidth to unnecessary broadcasts. We can use Virtual LANs (VLANs) to restrict broadcasts by creating logical groups of hosts. The physical location of the hosts does not matter, because these are virtual local area networks. When a switch receives a broadcast packet from a host in one particular VLAN, that switch will forward that broadcast only via ports that are in the same VLAN. By creating VLANs, you create multiple broadcast domains while also lowering the number of multicasts sent throughout the network. (A switch's default behavior regarding broadcasts is the same for multicasts.) Cisco's best practice is to have one VLAN per IP subnet, and this is a best practice that works very well in the real world. The VLAN membership of a host depends on one of two factors: With static VLANs, it's dependent on the port the host is connected
to With dynamic VLANs, it's dependent on the host's MAC address We'll first look at static VLANs.
Here, VLANs have been created, and only the devices that are in the same VLAN as the sending host will receive the broadcast. There's always a catch, though, right? The issue here is that not only will broadcasts not be forwarded between VLANs, but no traffic will be forwarded between VLANs! This may be exactly what we wanted, but we're going to have to introduce an OSI Model Layer Three device to perform routing between the two VLANs. We could introduce a router to our network, or if we're lucky enough, the switch we're working on is a Layer 3 Switch. This is a switch that can run routing protocols as well as handle switching. We'll look at one such switch in a later chapter. Occasionally, I'll run into someone who tells me "we don't use VLANs." If you're using a Cisco switch, your model is probably using VLANs whether you know it or not! Let's run show vlan brief on a 2950 switch that has just come out of the box.
SW2#show vlan br 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 active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active
We're already using VLANs, even though we haven't configured one. By default, all Cisco switch ports are placed into VLAN 1. The default VLAN is also known as the native VLAN. The five VLANs shown here - 1, 1002, 1003, 1004, and 1005 - cannot be deleted.
SW2(config)#no vlan 1002 Default VLAN 1002 may not be deleted.
There's one more reason that may lead you to create VLANs. If you have a network segment with hosts whose very existence should not be known by the rest of the network, just put these hosts into their own VLAN. Unless you then make them known to the rest of the network via routeron-a-stick or a Layer 3 switch, these hosts will not be known or reachable by hosts in other VLANs. In the following example, all hosts are on the 172.12.123.0 /27 subnet, with their host number as the final octet. Every host can ping every other host. For now. :) Each host is connected to the switch port that matches its host number. These hosts are on the same subnet to illustrate inter-VLAN connectivity issues. It's standard practice as well as Cisco's recommendation that each VLAN have its own separate IP subnet.
The problem right now is that every host will receive every broadcast packet sent out by every other host, since all switch ports are placed into VLAN 1 by default. Perhaps we only want Host 2 to receive any broadcast sent by Host 1. We can make this happen by placing them into another VLAN.
We'll use VLAN 12 in this case. By placing switch ports 0/1 and 0/2 into VLAN 12, hosts that are not in that VLAN will not have broadcast packets originated in that VLAN forwarded to them by the switch.
SW1(config)#int fast 0/1 SW1(config-if)#switchport mode access SW1(config-if)#switchport access vlan 12 % Access VLAN does not exist. Creating vlan 12
SW1(config-if)#int fast 0/2 SW1(config-if)#switchport mode access SW1(config-if)#switchport access vlan 12
One of the many things I love about Cisco switches and routers is that if you have forgotten to do something, the Cisco device is generally going to remind you or in this case actually do it for you. (You'll see an exception to this later in this very section.) I placed port fast0/1 into a VLAN that did not yet exist, so the switch created it for me! It's easy to put a port into a static VLAN, but there are two commands needed to place a port into one. By default, these ports are running in dynamic desirable trunking mode, meaning that the port is actively attempting to form a trunk with a remote switch. The problem is that a trunk port belongs to all VLANs by default, and we want to put this port into a single VLAN only. To do so, we run the switchport mode access command to make the port an access port, and access ports belong to one and only one VLAN. After doing that, we placed the port into VLAN 12 with the switchport access vlan 12 command. After configuring VLANs, always run show vlan brief to make sure the ports have been placed into the desired VLANs. The output shows that ports 0/1 and 0/2 have been placed into VLAN 12.
Host 1 can still ping Host 2, but to ping the other hosts (or send any traffic to those hosts!), a routing process has to be run either on a remote router with router-on-a-stick or on this switch if it's an L3 switch. Even though Host 3 and Host 4 are on the same IP subnet as Host 1, they're in different VLANs and therefore cannot ping each other.
HOST1#ping 172.12.123.2 Sending 5, 100-byte ICMP Echos to 172.12.123.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
HOST1#ping 172.12.123.3 Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
..... Success rate is 0 percent (0/5)
HOST1#ping 172.12.123.4 Sending 5, 100-byte ICMP Echos to 172.12.123.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
In your CCNA studies, you were shown only this particular type of VLAN where ports have to be manually placed into a VLAN. This VLAN configuration type is referred to as a "Static VLAN". What if Hosts 1 and 2 still couldn't ping each other, even though they're obviously in the same subnet and the same VLAN? There are two places you should look that might not occur to you right away. First, check speed and duplex settings on the switch ports. Second, check the MAC table on the switch and make sure the hosts in question have an entry in the table to begin with. Nothing is perfect, not even a Cisco switch, and every once in a very great while the switch may not have learned a MAC address that it should know. Throughout this chapter, I've used show vlan brief to check VLAN membership. Here's what the full show vlan command displays:
All the information you need for basic and intermediate VLAN troubleshooting is contained in show vlan brief, so I prefer to use that version of the command. You know that all ports are placed into VLAN 1 by default, and all ports in the above configuration except 0/1 and 0/2 are indeed in VLAN 1. In the more detailed field at the bottom of the show vlan output, note that the default VLAN type set for VLANs 1 and 12 is "enet", short for ethernet. (The other VLANs are designed for use with FDDI and Token Ring, and you can see the defaults follow that designation.) The only other default seen here is the MTU size of 1500. Notice that all the VLAN-related configuration has been placed on the switch - we haven't touched the hosts. With static VLANs, the host
devices will assume the VLAN membership of the port they're connected to. The hosts don't even know about the VLANs. By the way, if you just want to see the ports that belong to a specific VLAN, run the command show vlan id followed by the VLAN number. This command shows you the ports that belong to that VLAN, the status of those ports, the MTU of the VLAN, and more.
SW1#show vlan id ? WORD ISL VLAN IDs 1-1005 SW1#show vlan id 5 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------5 VLAN0005 active Fa0/5, Fa0/11, Fa0/12 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ - ------- ---- -------- ------ -----5 net 100005 1500 - 0 0 Remote SPAN VLAN ---------------Disabled Primary Secondary Type Ports ------- --------- ----------------- -----------------------------------------SW1#
If we have "static VLANs", it follows that there is such a thing as a "dynamic VLAN". The configuration of dynamic VLANs is far out of the scope of the BCMSN exam, but as a CCNP you need to know the basics of VMPS - a VLAN Membership Policy Server. When you move a user from one port to another using static VLANs, you have to change the configuration of the switch to reflect these changes. Using VMPS results in these changes being performed dynamically, because the port's VLAN membership is decided by the source MAC address of the device connected to that port. (Yet another reason that the first value a switch looks at on an incoming frame is the source MAC address.) VMPS uses a TFTP server to help in this dynamic port assignment scheme. A database on the TFTP server that maps source MAC addresses to VLANs is downloaded to the VMPS server, and that downloading occurs every time you power cycle the VMPS server. VMPS uses UDP to listen to client requests. An interesting default of VMPS is that when a port receives a dynamic VLAN assignment, PortFast is automatically enabled for that port! There's no problem with PortFast being turned off on that port if you feel it necessary, but keep in mind that PortFast will run on a dynamic VLAN port by default. What if we had to move Host 1's connection to the switch to port 0/6? With static VLANs, we'd have to connect to the switch, configure the port as an access port, and then place the port into VLAN 12. With VMPS, the only thing we'd have to do is reconnect the cable to port 0/6, and the VMPS would dynamically place that port into VLAN 12.
When dynamic VLANs are in use, the port number isn't important - the MAC address of the host connected to the port is the deciding factor regarding VLAN membership. I urge you to do additional reading regarding VMPS. It's a widely used switching service, and it's a good idea to know the basics. Use your favorite search engine for the term configuring vmps and you'll quickly find some great official Cisco documentation on this topic. Some things to watch out for when configuring VMPS: The VMPS server has to be configured before configuring the ports as dynamic. Again, PortFast is enabled by default when a port receives a dynamic VLAN assignment. If a port is configured with port security, that feature must be turned off before configuring a port as dynamic. Trunking ports cannot be made dynamic ports, since by definition trunking ports must belong to all VLANs. Trunking must be disabled to make a port a dynamic port. To review, the VLAN membership of a host is decided by one of two factors. With static VLANs, the host's VLAN membership is the VLAN to which its switch port has been assigned. With dynamic VLANs, it is dependent upon its MAC address. As for the relation between VLANs and subnets, it's Cisco's recommendation that there be every VLAN be a separate subnet.
Odds are that your network is going to have VLAN members that physically reside on different switches, as shown here:
g ni knurT NALV
We've got hosts in two different VLANs physically connected to two different switches, and only one physical connection between the two switches. You know that an access port can only be a member of one VLAN, so the switch ports that are connected must be trunk ports in order to allow a trunk to form between the two switches. A trunk is a point-to-point connection between two physically connected switches that allows traffic to flow between the switches, regardless of the VLAN the traffic is destined for. By default, a trunk port is a member of all VLANs, so traffic for any and all VLANs can travel across this trunk. That includes broadcast traffic! The default mode of a switch port does differ between models, so always check your documentation. On Cisco 2950 switches, every single port is in dynamic desirable mode by default, meaning that every port is actively attempting to trunk. On these switches, the only action needed from us is to physically connect them with a crossover cable. In just a few seconds, the port light turns green and the trunk is up and running. The command show interface trunk will verify trunking.
From left to right, you can see the ports that are trunking, the mode the ports are in (desirable and dynamic desirable are the same thing), the encapsulation type (2950s support only 802.1q), the port status is trunking, and the default or "native" VLAN is VLAN 1. You can also see the VLAN traffic that is allowed to go across the trunk. Just as important is where you will not see trunk ports listed. When we took our first look at the show vlan brief command earlier in this section, there was something a little odd...
SW2#show vlan br 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 active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active
There are 10 ports shown, but this is a 12-port switch. Note that ports 0/11 and 0/12 do not appear in the output of show vlan brief, and if you ran the full show vlan command, they wouldn't show up there, either! The ports didn't just disappear, thankfully - ports that are trunking will not appear in the output of show vlan or show vlan brief. Always run both show vlan and show interface trunk to see what mode each and every one of your switch ports is using. How does the receiving switch know what VLAN the frame belongs to? The frames are tagged by the transmitting switch with a VLAN ID, reflecting the number of the VLAN whose member ports should receive this frame. When the frame arrives at the remote switch, that switch will examine this ID and then forward the frame appropriately. You may have had a CCNA flashback when I mentioned "dot1q"! There were quite a few differences between the trunking protocols ISL and dot1q, so let's review those before we examine a third trunking protocol that you didn't learn during your CCNA studies. For a trunk to form successfully, the ports must agree on the speed, the duplex setting, and the encapsulation type. Many Cisco switches offer the choice of ISL and IEEE 802.1q - and I can practically guarantee your BCMSN exam just might discuss these encap types! Let's take a detailed
look at each right now.
ISL is Cisco-proprietary, making it unsuitable for a multivendor environment. That's one drawback, but there are others. ISL will place both a header and trailer onto the frame, encapsulating it. This increases the overhead on the trunk line. You know that the default VLAN is also known as the "native VLAN", and another drawback to ISL is that ISL does not use the concept of the native VLAN. This means that every single frame transmitted across the trunk will be encapsulated. The 26-byte header that is added to the frame by ISL contains the VLAN ID; the 4-byte trailer contains a Cyclic Redundancy Check (CRC) value. The CRC is a frame validity scheme that checks the frame's integrity. In turn, this encapsulation leads to another potential issue. ISL encapsulation adds 30 bytes total to the size of the frame, potentially making them too large for the switch to handle. (The maximum size for an Ethernet frame is 1518 bytes. Frames larger than that are called giants.) For that reason, if one trunking switch is using ISL and its remote partner is not, the remote partner will consider the ISL-encapsulated frames as giants. In contrast, dot1q does not encapsulate frames. A 4-byte header is added to the frame, resulting in less overhead than ISL and resulting in a maximum frame size of 1522 bytes. If the frame is destined for hosts residing in the native VLAN, even that small header isn't added. Since the dot1q header is only 4 bytes in size, and isn't even placed on every frame, using dot1q lessens the chance of oversized frames. When the remote port receives an untagged frame, the switch knows that these untagged frames are destined for the native VLAN. Other dot1q facts you should be familiar with: Dot1q actually embeds the tagging information into the frame itself. You'll occasionally hear this referred to as internal tagging. Dot1q is the "open standard" or "industry standard" trunking protocol and is suitable for a multivendor environment. Dot1q does not change the destination MAC address in any way. Believe it or not, ISL and dot1q actually have something in common! They're both considered point-to-point protocols, since by definition a trunk only has two endpoints, and that's it - just like ISDN. Also notice that there's a 4-byte addition in both ISL and dot1q - make sure to have them straight: ISL: 4-byte trailer (with CRC value) dot1q: 4-byte header inserted into the frame
PTD dna ,)"q1tod"( q1.208 EEEI,)LSI( locotorP kniL hctiwS-retnI
Troubleshooting Trunks I've created a lot of trunks over the years, and I've bumped into quite a few "gotchas" that you might not think to look at in a production network. For trunks to work properly, the port speed and port duplex setting should be the same on the two trunking ports. ISL switches don't care about the native VLAN setting, because they don't use the native VLAN to begin with. Giants are frames that are larger than 1518 bytes, and these can occur on ISL since they add 30 bytes to the frame. Some Catalyst switches have Cisco-proprietary hardware that allows them to handle the larger frames. Check the documentation for your switch to see if this is the case for your model. Dot1q does add 4 bytes to the frame, but thanks to IEEE 802.3ac, the maximum frame length can be extended to 1522 bytes. (The opposite of a giant is a runt. While giants are too large to be successfully transmitted, runts are frames less than 64 bytes in size.) Both switches must be in the same VTP domain - watch those domain names, they're case-sensitive. If you're working on a multilayer switch (also called a "Layer 3 switch"), make sure the port you want to trunk is a Layer 2 port by configuring the interface-level command switchport on it. You can configure a 10, 100, or 1000 MBPS interface as a trunk. Changing the native VLAN on one switch does not dynamically change the native VLAN on a remote trunking partner.
Most Cisco switches used to support both ISL and dot1q, but that is no longer the case. For example, the popular 2950 switches don't support ISL. Make sure to check Cisco's online documentation site at www.cisco.com/univercd for a particular switch model if you must have one particular trunking protocol. How Do Access Ports Handle Encapsulation And Tagging? Easy -- they don't. Since access ports belong to one and only one VLAN, there's no need to encapsulate or tag them with VLAN ID information.
Changing The Native VLAN By default, the native VLAN is VLAN 1. The native VLAN is the VLAN the port will belong to when it is not trunking, regardless of whether it once was a trunk port. The native vlan can be changed with the switchport trunk native vlan command, but you should be prepared for an error message very quickly after configuring it on one side of the trunk. We'll change the native vlan
setting on fast 0/11 on one side of an existing trunk and see what happens.
SW1(config-if)#switchport trunk native vlan 12 1d21h: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 1 on FastEthernet0/11 VLAN12. 1d21h: %SPANTREE-2-BLOCK_PVID_PEER: Blocking FastEthernet0/11 on VLAN0001. Inconsistent peer vlan. 1d21h: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet0/11 on VLAN0012. Inconsistent local vlan. 1d21h: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/11 (12), with SW2 FastEthernet0/11 (1). SW1#show int fast 0/11 trunk Port Fa0/11 Mode desirable Encapsulation 802.1q Status trunking Native vlan 12
The trunk itself doesn't come down, but those error messages will continue until you have configured the native vlan on the remote switch port to be the same as that on the local port it's trunking with. Remember, ISL doesn't use the native VLAN concept and dot1q does not place the 4-byte header on frames destined for the native VLAN - when a port running dot1q receives an untagged frame, that frame belongs to the native VLAN. Changing the native VLAN on one switch in a trunk does not automatically change it for the other switch! Manually Configuring Trunking Protocols To manually configure a trunk port to run ISL or dot1q, use the switchport trunk encapsulation command.
Rack1SW1(config-if)#switchport trunk encapsulation ? dot1q Interface uses only 802.1q trunking encapsulation when trunking isl Interface uses only ISL trunking encapsulation when trunking negotiate Device will negotiate trunking encapsulation with peer on interface
Notice that there's a third option, negotiate. The trunk ports will then negotiate between ISL and dot1q, and naturally it must be a protocol that both ports support. If the negotiating ports support both protocols, ISL will be selected. By the way, if you use IOS Help to display your switch's encapsulation choices, and there aren't any, that's a pretty good sign that your switch supports only dot1q!
SW1(config)#interface fast 0/11 SW1(config-if)#switchport trunk encapsulation ? % Unrecognized command
You learned about ISL and dot1q in your CCNA studies, but there's a third trunking protocol involved as well. The Cisco-proprietary Dynamic Trunking Protocol actively attempts to negotiate a trunk line with the remote switch. This sounds great, but there is a cost in overhead - DTP frames are transmitted every 30 seconds.
If you decide to configure a port as a non-negotiable trunk port, there's no need for the port to send DTP frames. Also, if there's a device on the other end of the line that can't trunk at all - a firewall, for example - there's no need to send DTP frames. DTP can be turned off at the interface level with the switchport nonegotiate command, but as you see below, you cannot turn DTP off until the port is no longer in dynamic desirable trunking mode
SW2(config)#int fast 0/8 SW2(config-if)#switchport nonegotiate Command rejected: Conflict between 'nonegotiate' and 'dynamic' status. SW2(config-if)#switchport mode ? access Set trunking mode to ACCESS unconditionally dynamic Set trunking mode to dynamically negotiate access or trunk mode trunk Set trunking mode to TRUNK unconditionally SW2(config-if)#switchport mode trunk SW2(config-if)#switchport nonegotiate
.
You can verify DTP operation (or non-operation) with show dtp.
SW1#show dtp Global DTP information Sending DTP Hello packets every 30 seconds Dynamic Trunk timeout is 300 seconds 4 interfaces using DTP
There is a show dtp interface command as well, but it's extremely verbose. It will show you which interfaces are running DTP, which the basic show dtp command will not do. While we've got those trunking modes in front of us, let's examine exactly what's going on with each one. Trunk mode means just that - this port is in unconditional trunk mode and cannot be an access port. Since this port cannot negotiate, it's standard procedure to place the remote port in trunk mode. Turning off DTP when you place a port in trunk mode is a great idea, because there's no use in sending negotiation frames every 30 seconds if no negotiation is necessary! Dynamic desirable is the default setting for most Cisco switch ports today. If the local switch port is running dynamic desirable and the remote switch port is running in trunk, dynamic desirable, or dynamic auto, a trunk will form. This is because a port in dynamic desirable mode is sending and responding to DTP frames. If you connect two 2950s with a crossover cable, a trunk will form in less than 10 seconds with no additional configuration needed. Dynamic auto is the "oddball" trunking mode. A port configured as dynamic auto (often called simply "auto") will not actively negotiate a trunk, but will accept negotiation begun by the remote switch. As long as the remote trunk port is configured as dynamic desirable or trunk, a trunk line will form. It's important to note that this setting does not have to match between two potential trunk ports. One port could be in dynamic desirable and the
other in trunk mode, and the trunk would come up. Is there a chance that two ports that are both in one of these three modes will not successfully form a trunk? Yes - if they're both in dynamic auto mode. You can expand the show interface trunk command we examined earlier in this section to view the trunking mode of a particular interface. We can see that port 0/11 is running in dynamic desirable mode.
We can change the mode with the switchport mode command. By changing the port to trunk mode, the mode is "on".
SW2(config)#int fast 0/11 SW2(config-if)#switchport mode trunk
SW2#show interface fast 0/11 trunk Port Fa0/11 Port Fa0/11 Port Fa0/11 Port Fa0/11 Mode on Encapsulation Status 802.1q trunking Native vlan 1
Vlans allowed on trunk 1-4094 Vlans allowed and active in management domain 1 Vlans in spanning tree forwarding state and not pruned 1
When we looked at the options for switchport mode, did you notice that there is no "off" setting?
SW2(config-if)#switchport mode ? access Set trunking mode to ACCESS unconditionally dynamic Set trunking mode to dynamically negotiate access or trunk mode trunk Set trunking mode to TRUNK unconditionally
When a port is configured as an access port, that unconditionally turns trunking off. switchport mode access is the command that turns trunking off. Here's the show interface trunk command displaying the information for the port leading to HOST 1 after configuring the port as an access port.
SW1#show interface fast 0/1 trunk Port Fa0/1 Port Fa0/1 Mode off Encapsulation 802.1q Status not-trunking Native vlan 1
Vlans allowed on trunk 12
Port Fa0/1 Port Fa0/1
Vlans allowed and active in management domain 12 Vlans in spanning tree forwarding state and not pruned 12
Through the various show commands we've used in this section, you might have noticed that trunk ports allow traffic for VLANs 1 - 4094 to cross the trunk line. This is the default, but it can be changed with the switchport trunk allowed vlan command. The various options with this command do take a little getting used to, so let's take a closer look at them.
SW1(config-if)#switchport trunk allowed vlan ? WORD VLAN IDs of the allowed VLANs when this port is in trunking mode add add VLANs to the current list all all VLANs except all VLANs except the following none no VLANs remove remove VLANs from the current list
except - Follow this command with the VLANs whose traffic will not be allowed across the trunk. We'll configure interface fast 0/11 and 0/12 to not trunk for VLAN 1000 and look at the results with show interface trunk.
SW1(config)#interface fast 0/11 SW1(config-if)#switchport trunk allowed vlan except 1000 SW1(config-if)#interface fast 0/12 SW1(config-if)#switchport trunk allowed vlan except 1000 SW1#show interface trunk Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Mode desirable desirable Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 1 1
Vlans allowed on trunk 1-999,1001-4094 1-999,1001-4094 Vlans allowed and active in management domain 1,12 1,12 Vlans in spanning tree forwarding state and not pruned 1,12 12
VLAN 1000 is not allowed to trunk through interfaces fast 0/11 and fast 0/12. To allow VLAN 1000 to trunk through these interfaces again, we'll use the add option of this command. (To remove additional VLANs, we would use remove.)
SW1(config)#int fast 0/11 SW1(config-if)#switchport trunk allowed vlan add 1000 SW1(config-if)#int fast 0/12 SW1(config-if)#switchport trunk allowed vlan add 1000 SW1#show interface trunk Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Mode desirable desirable Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 1 1
Vlans allowed on trunk 1-4094 1-4094
Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12
Vlans allowed and active in management domain 1,12 1,12 Vlans in spanning tree forwarding state and not pruned 1,12 12
VLAN 1000 is again allowed to trunk through these two interfaces. The more drastic choices are all and none. To disable trunking for all VLANs, the none option would be used. To enable trunking for all VLANs again, we'll use the all option.
SW1(config)#int fast 0/11 SW1(config-if)#switchport trunk allowed vlan none SW1(config-if)#int fast 0/12 SW1(config-if)#switchport trunk allowed vlan none SW1#show interface trunk Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Mode desirable desirable Encapsulation Status 802.1q trunking 802.1q trunking Native vlan 1 1
Vlans allowed on trunk none none Vlans allowed and active in management domain none none Vlans in spanning tree forwarding state and not pruned none none
SW1(config)#int fast 0/11 SW1(config-if)#switchport trunk allowed vlan all SW1(config-if)#int fast 0/12 SW1(config-if)#switchport trunk allowed vlan all
SW1#show interface trunk Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Mode desirable desirable Encapsulation Status 802.1q trunking 802.1q trunking Native vlan 1 1
Vlans allowed on trunk 1-4094 1-4094 Vlans allowed and active in management domain 1,12 1,12 Vlans in spanning tree forwarding state and not pruned none none
Naming VLANs You can give your VLAN a more intuitive name with the name command.
SW1(config)#vlan 10
SW1(config-vlan)#name ENGINEERING
Running show vlan brief verifies that the VLAN has been named...
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, Fa0/13, Fa0/14 Fa0/15, Fa0/16, Fa0/17, Fa0/18 Fa0/19, Fa0/20, Fa0/21, Fa0/22 Fa0/23, Fa0/24 10 ENGINEERING active
... but if you want to further configure the VLAN, you must do so by number, not by name.
SW1(config)#vlan ENGINEERING Command rejected: Bad VLAN list - character #1 is a non-numeric character ('E').
SW1(config)#vlan 10 SW1(config-vlan)#
VLAN Database Mode You'll notice that all of the configurations in this study guide use the CLI commands to configure VLANs. There is a second way to do so, and that's using VLAN database mode. I personally don't like using this mode, because it's very easy to save your changes incorrectly - which of course means that your changes aren't saved! It's always a good idea to know how to do something more than one way in Ciscoland, though, so let's take a look at this mode. You enter this mode by typing vlan database at the command prompt.
SW1#vlan database SW1(vlan)#
The prompt changed appropriately, so let's create VLAN 30.

SW1(vlan)#vlan 30 VLAN 30 added: Name: VLAN0030
No problem! Let's exit this mode the way we always do, by using ctrl-z, and then verify the creation of the VLAN. To save some room, I'll show all VLANs except VLAN 1.
SW1(vlan)#^Z SW1#show vlan brief VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------10 ENGINEERING 1002 fddi-default 1003 token-ring-default 1004 fddinet-default 1005 trnet-default active active active active active
Do you see a VLAN 30 there? I sure don't. And no matter how many
times you do what we just did, you'll never see VLAN 30 - because vlan database mode requires you to type APPLY to apply your changes, or to type EXIT to leave this mode and save changes. I'll do both here, and notice that when you exit by typing EXIT, the APPLY is, well, applied!
SW1(vlan)#vlan 30 VLAN 30 added: Name: VLAN0030 SW1(vlan)#apply APPLY completed. SW1(vlan)#exit APPLY completed. Exiting.... SW1#show vlan br VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------10 ENGINEERING 30 VLAN0030 1002 fddi-default 1003 token-ring-default 1004 fddinet-default 1005 trnet-default active active active active active active
Cisco switches were actually giving a message a few years ago anytime you used the vlan database command that this mode was being phased out. I imagine they got tired of helpdesk calls from people who didn't know about the EXIT and APPLY. (Did you notice that when we left this mode with ctrl-z, the switch didn't tell us the changes were not being applied?) Cisco seems to have changed their minds about getting rid of this mode, and while you probably won't see it on your BCMSN 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 knowledge to your network's needs. In my BSCI Study Guide's discussion of Cisco's Three-Layer Hierarchical Networking Model, I mention that it's important to let the Distribution layer handle the "little things" in order to allow the core switches to do what they do best - switch! 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. Watch the details here, as one is following the 80/20 rule and the other is following the 20/80 rule. End-to-End and Local VLANs
With end-to-end VLANs, the name is the recipe as end-to-end VLANs will span the entire network. 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 can come in handy as a security tool and/or when the hosts have similar resource requirements - for example, if you had certain hosts across the network that needed access to a particular network resource, but you didn't even want your other hosts to know of the existence of that resource. However, I can tell you that this VLAN type is a real pain in the butt to configure. :) End-to-end VLANs should be designed with the 80/20 rule in mind, where 80 percent of the local traffic stays within the local area and the other 20 percent will traverse the network core en route to a remote destination. 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. The following network diagram is simplified, but even this network would be difficult to configure with end-to-end VLANs if the hosts need connectivity to the Internet and/or corporate servers located across a WAN. With Internet access becoming more of a requirement than a luxury for today's end users, 80/20 traffic patterns aren't seen as often as they once were.
Local VLANs are designed with the 20/80 rule in mind. Local VLANs
assume that 20 percent of traffic is local in scope, while the other 80 percent will traverse the network core. While physical location is unimportant in end-to-end VLANs, users are grouped by location in Local VLANs. More and more networks are using centralized data depositories, such as server farms - and even in the simplified network diagram above, the end user must go across a WAN to reach the server farm, another reason that 80/20 traffic patterns aren't seen as often as they were in the past.

VLAN Trunking Protocol (VTP)

Overview
The Need For VTP Configuring VTP VTP Modes VTP Advertisement Process Preventing VTP Synchronization Issues VTP Advertisement Types VTP Features VTP Versions The VLAN.DAT File VTP Secure Mode
As a CCNP candidate, you know that when it comes to Cisco technologies, there's always something new to learn! You learned about the VLAN Trunking Protocol (VTP) in your CCNA studies, but now We're going to review a bit and then build on your knowledge of both of these important switching technologies.
Why Do We Need VTP? VLAN Trunking Protocol (VTP) allows each switch in a network to have an overall view of the active VLANs. VTP also allows network administrators to restrict the switches upon which VLANs can be created, deleted, or modified. 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 can create VLAN 10 on SW1, and SW2 really doesn't need to know about this new VLAN.
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.
SW2 doesn't have any hosts in VLAN 10, but for VLAN 10 traffic to successfully travel from SW1 to SW3 and vice versa, SW2 has to know about VLAN 10's existence. SW2 could be configured manually with VLAN 10, but that's going to get very old very fast. 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! 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.)
There's nothing next to "VTP Domain Name", so a VTP domain has not yet been configured. We'll now change that by placing this switch into a domain called CCNP. Watch this command - it is case sensitive.
After configuring the VTP domain "CCNP" on SW2, SW1 is also placed into that domain. 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. VTP Modes In the previous show vtp status readouts, the VTP Operating Mode is set to Server. The more familiar term for VTP Operating Mode is simply VTP Mode, and Server is the default. It's through the usage of VTP modes that we can place limits on which switches can delete and create VLANs.
It's not unusual for edge switches such as SW1 and SW3 to be available to more people that they should be. If SW2 is the only switch that's physically secure, SW2 should be the only VTP Server. Let's review the VTP Modes and then configure SW1 and SW3 appropriately. In Server mode, a VTP switch can be used to create, modify, and delete VLANs. This means that a VTP deployment has to have at least one Server, or VLAN creation will not be possible. This is the default setting for Cisco switches. Switches running in Client mode cannot be used to create, modify, or delete VLANs. Clients do listen for VTP advertisements and act accordingly when VTP advertisements notify the Client of VLAN changes. VTP Transparent mode actually means that the switch isn't participating in VTP. (Bear with me here.) Transparent VTP switches don't synchronize their VTP databases with other VTP speakers; they don't even advertise their own VLAN information! Therefore, any VLANs created on a
Transparent VTP switch will not be advertised to other VTP speakers in the domain, making them locally significant only. I'm not saying that Transparent mode is evil, or even bad; I am saying that you have to be careful when implementing Transparent mode into your network. There are two versions of VTP, V1 and V2, and the main difference between the two versions affects how a VTP Transparent switch handles an incoming VTP advertisement. 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. To ensure that no one can create VLANs on SW1 and SW3, we'll configure both of them as VTP Clients. SW1's configuration and the resulting output of show vtp status is shown below.
Attempting to create a VLAN on a VTP client results in the following message:
This often leads to a situation where only the VTP Clients will have ports that belong to a given VLAN, but the VLAN still has to be created on the VTP Server. VLANs can be created and deleted in Transparent mode, but those changes aren't advertised to other switches in the VTP domain. Also, switches do not advertise their VTP mode. Which Switches Should Be Servers, Which Should Be Clients? 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 absolutely 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 VTP Advertisement Process VTP Advertisements are multicasts, but they are not sent out every port on the switch. 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. The hosts in VLAN 10 in the following exhibit would not receive VTP advertisements.
Along with the VTP domain name, VTP advertisements carry a configuration revision number that enables VTP switches to make sure they have the latest VLAN information. 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? SW1 received a VTP advertisement from SW2. 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. This indicates to SW1 that the information contained in this VTP advertisement is more recent than its own VLAN information, so the advertisement is accepted. If SW1's revision number had been higher than that in the VTP advertisement from SW2, the advertisement would have been ignored.
In this example, SW2 is the root and is sending out an advertisement with revision number 300. The three switches are running VLANs 10, 20, 30, 40, and 50, and everything's just fine. The VTP domain is CCNP.
Now, a switch that was at another client site is brought to this client and installed in the CCNP domain. The problem is that the VTP revision number on the newly installed switch is 500, and this switch only knows about the default VLAN, VLAN 1.
The 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. The problem is that the new advertisements don't list VLANs 10, 20, 30, 40, or 50, so connectivity for those VLANs is lost. I've seen this happen with switches that were brought it to swap out with a downed 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:
1. 2.
Change the VTP domain name to a nonexistent domain, then change it back to the original name. Change the VTP mode to Transparent, then change it back to
Server. 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. (Reloading the switch won't do the job, because the revision number is kept in NVRAM, and the contents of Non-Volatile RAM are kept on a reload.) It's a good practice to perform this reset with VTP Clients as well as Servers. 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. ;) To see the number of advertisements that have been sent and received, run show vtp counters.
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. Keep in mind that Cisco switches only accept VTP advertisements from other switches in the same VTP domain. Summary Advertisements are transmitted by VTP servers every 5 minutes, or upon a change in the VLAN database. Information included in the summary advertisement: VTP domain name and version Configuration revision number MD5 hash code Timestamp Number of subset advertisements that will follow this ad Subset Advertisements are transmitted by VTP servers upon a VLAN configuration change. Subset ads give specific information regarding the VLAN that's been changed, including: Whether the VLAN was created, deleted, activated, or suspended The new name of the VLAN The new Maximum Transmission Unit (MTU) VLAN Type (Ethernet, Token Ring, FDDI)
Client Advertisement Requests are just that - a request for VLAN information from the client. Why would a client request this information? Most likely because the VLAN database has been corrupted or deleted. The VTP Server will respond to this request with a series of Summary and Subset advertisements.
Configuring VTP Features 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.
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 or not! 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.
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. 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.
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:
If the three hosts shown in VLAN 7 are the only hosts in that VLAN, there's no reason for VLAN 7 broadcasts to reach the middle and bottom two switches. 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".
SW2#show interface trunk Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Mode desirable desirable Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 1 1
Vlans allowed on trunk 1-4094 1-4094 Vlans allowed and active in management domain 1,10,20,30,40 1,10,20,30,40
Port Fa0/11 Fa0/12
Vlans in spanning tree forwarding state and not pruned 1,10,20,30 none
In this example, VLAN 40 is allowed and active, but it's been pruned. That's fine if you don't have hosts on both sides of the trunk in VLAN 40, but I have seen this happen in a production network where there were hosts on both sides of the trunk in a certain VLAN, and that VLAN had been pruned. It's a rarity, but now you know to look out for it!
VTP Versions By now, you've probably noticed that the first field in the readout of show vtp status is the VTP version. The first version of VTP was VTP Version 1, and that is the default of some older Cisco switches. The next version was Version 2, and that's the default on many newer models, including the 2950. As RIPv2 has advantages over RIPv1, VTP v2 has several advantages over VTPv1. Version 2 supports Token Ring VLANs and Token Ring switching, where Version 1 does not. When changes are made to VLANs or the VTP configuration at the command-line interface (CLI), Version 2 will perform a consistency check. So what's being checked? VLAN names and numbers. This helps to prevent incorrect / inaccurate names from being propagated throughout the network. A switch running VTPv2 and Transparent mode will forward VTP advertisements received from VTP Servers in that same domain. As with RIP, VTP versions don't work well together. Cisco switches run in Version 1 by default, although most newer switches are V2-capable. If you have a V2-capable switch such as a 2950 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.
The VLAN.DAT File Those of you with switches in your home labs have probably run into this situation. You run a write erase on your routers, reload them, and since NVRAM is now empty, you're prompted to go into setup mode. All IP addressing, routing protocols, static routes - everything's gone. So now you do the same to your switches. You run write erase, reload, and you're prompted to go into setup mode. Funny thing, though - the VLAN information is still there! Below, we see a switch that had its NVRAM erased and was then reloaded. There is no startup configuration, but the VLAN information that was on the switch is still there!
How did the VLAN information survive the write erase? The startup configuration is gone, but the VLAN database still contains information about VLANs created before the write erase. That's because the write erase command erases the contents of NVRAM, the VLAN information is kept in a file called vlan.dat - and that file is kept in Flash.
If you want to truly initialize a switch, the vlan.dat file has to go. Deleting it can be a little tricky if you do it too quickly, though.
When a router or switch presents you with a question such as "Delete filename?", your first instinct may be to type "y" or "n". Don't do that here. If you type "y" or "yes", the switch will attempt to delete a file named "y" or "yes". Just hit the enter key for both questions to accept the defaults in the brackets. Then when you reload the router, you'll be prompted with the system configuration question you see in this example. Make sure to answer "n" to that question. Remember - when you do this, the prior VLAN information is gone from the switch. VTP "Secure Mode" By setting a VTP password, you place the entire VTP domain into Secure Mode. Every switch in the domain must have a matching password.
SW1(config)#vtp domain CCNP Changing VTP domain name from NULL to CCNP SW1(config)#vtp password CCIE Setting device VLAN database password to CCIE
VTP Secure Mode isn't all that secure, though - here's how you discover the password:
SW1#show vtp password VTP Password: CCIE
Pretty secure, eh? :) Let's try to encrypt that password -SW1(config)#service password-encryption SW1#show vtp password VTP Password: CCIE
That's something to keep in mind! VTP Configuration Tips I've configured VTP many times, and while the following two tips aren't Cisco gospel, they've worked well for me. 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.

Spanning Tree Protocol Basics

Overview
Basics Of LAN Switching BPDUs The Root Bridge Election Root Port Selection And Cost Default Root Port Costs STP Port States STP Timers Making A Nonroot Switch The Root Bridge Where Should The Root Bridge Be Located? Topology Change Notification BPDU Operation Load Sharing With The port-priority Command The Extended System ID Feature
If you paid particular attention to Spanning-Tree Protocol (STP, defined in IEEE 802.1d) in your CCNA studies, you've got a big advantage when it comes to the BCMSN exam. If you're a little rusty on why and how to run STP, fear not! We're going to review the basics of how switches work with STP to prevent switching loops, and then build on those fundamentals by introducing you to more advanced STP features. The advanced STP features you'll learn about in this section aren't just for the exam! Many of them are commonly used in production networks, so you need to know this material for the exam and for real-world success. Before we get to those features, though, let's review the basic operation of a switch and of STP. LAN Switching Basics Switches use their MAC address table to switch frames, but when a switch is first added to a network, it has no entries in this table. The switch will dynamically build its MAC table by examining the source MAC
address of incoming frames. (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 host has an entry in the switch's MAC table. Such a frame would be forwarded only out the appropriate port. 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. Actually, there are times where we don't want there to be only one path from source to destination. 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. The Spanning Tree Protocol (STP) helps to prevent switching loops from forming, but what if STP didn't exist? 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? If Host A sends a frame to Host C, all three switches would receive the frame on their port 0/1. Since none of the switches would have an entry for Host A in their MAC tables, each switch would make an entry for that host, listing it as reachable via port 0/1. 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. That includes port 0/2 on all three switches. Just this quickly, without STP, we have a switching loop. Each switch will see the frames that the other two switches just forwarded out their port 0/2. The problem is that the source MAC address is still the address of Host A, but now the switches will each be receiving frames with that source MAC address on port 0/2! Since all the switches had port 0/1 as the port for Host A, they'll now change that MAC address table listing to port 0/2 - and again flood the frame. The frames are just going to keep going in circles, and that's why we call it a switching loop! Switching loops aren't just bad because frames can't reach their intended destination. They also put a strain on the router's CPU, and can actually lock the switch up if the loops become prevalent enough. Luckily for us, switching loops just don't occur that often, because STP does a great job of preventing switching loops before they can occur - and STP all begins with the exchange of Bridge Protocol Data Units (BPDUs). The Role Of BPDUs BPDUs are transmitted every two seconds to the well-known multicast MAC address 01-80-c2-00-00-00. (It might not have been well-known to you before, but it is now!) We've actually got two different BPDU types: Topology Change Notification (TCN) Configuration We'll talk about TCNs later in this section, but for now it's enough to know that the name is the recipe - a switch sends a TCN when there is a change in the network topology. Configuration BPDUs are used for the actual STP calculations. Once a root bridge is elected, only that root bridge will originate Configuration BPDUs; the non-root bridges will forward copies of that BPDU. BPDUs also carry out the election to decide which switch will be the Root Bridge. The Root Bridge is the "boss" of the switching network - this is the switch that decides what the STP values and timers will be. Each switch will have a Bridge ID Priority value, more commonly referred to as a BID.
This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-3344-55-66, the BID would be 32768:11-22-33-44-55-66. 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. Switches are a lot like people - when they first arrive, they announce that they are the center of the universe! Unlike some people, the switches will soon get over it. BPDUs will be exchanged until one switch is elected Root Bridge, and it's the switch with the lowest BID that will end up being the Root Bridge. To review, let's 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 32768, and the MAC address of each switch is the switch's letter 12 times. All three switches are coming online at the same time, so each one of them believes that they are the Root Bridge. (When a switch first comes online, it assumes it's the root, so its ports will go to the Listening stage - allowing it to hear BPDUs from other switches.)
SW A has a BID of 32768:aa-aa-aa-aa-aa-aa. That switch will receive BPDUs from both SW B and SW C, both containing their BIDs. SW A will see that the BIDs it's getting from both of those switches are higher than its own, so SW A will continue to send BPDUs announcing itself as the Root Bridge.
SW B has a BID of 32768:bb-bb-bb-bb-bb-bb. SW B will receive the BIDs as shown, and since SW A is sending a lower BID than SW B's, SW B will
recognize that SW A is the true Root Bridge, and will start announcing SW A as the root.
SW C is in the same situation. SW C will receive the BIDs as shown, and since SW A is sending a lower BID than SW C's, SW C will recognize that SW A is the Root Bridge and will start announcing SW A as the root. Even though these switches have quickly agreed that SW A is the root, this election really never ends. If a new switch comes online and advertises a BID that is lower than SW A's. that switch would then become the root bridge. In the following example, SW D has come online and has a BID lower than the current Root Bridge, SW A. SW D will advertise this BID via a BDPU to SW B, and SW B will realize that SW D should be the new root bridge. SW B will then announce this to the other switches, and soon SW D is indeed the root bridge. Since BPDUs are sent every two seconds, SW D will be seen as the new root bridge very quickly.
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.
SW1#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000f.90e1.c240 This bridge is the root Hello Time 2 sec Max Age 20 sec Bridge ID
Forward Delay 15 sec
Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e1.c240 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15 Role Sts Cost Prio.Nbr Type ---- --- --------- -------- ----------------------------Desg FWD 19 Desg FWD 19 128.11 128.12 P2p P2p
Interface -----------------Fa0/11 Fa0/12
There are several points of interest in SW1's output: There are two indicators that this is the root bridge. The MAC address in both the Root ID and Bridge ID fields is the same, and the more obvious indicator is the phrase this bridge is the root. Both trunk ports on the root bridge are in Forwarding mode. (If you don't quite remember the STP port stages, Forwarding mode means that frames can actually be forwarded via this port.) Let's take a look at the same command's output on SW2.
SW2#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000f.90e1.c240 Cost 19 Port 11 (FastEthernet0/11) Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e2.1300 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15 Role Sts Cost Prio.Nbr Type ---- --- --------- -------- ----------------------------Root FWD 19 Altn BLK 19 128.11 128.12 P2p P2p
Interface -----------------Fa0/11 Fa0/12
Note that the Root ID and Bridge ID fields are different. The Bridge ID field is the MAC address of the local switch, and the Root ID is the MAC address of the root bridge. Also note that one of the ports, fast 0/12, is in Blocking (BLK) mode. STP works by putting certain ports into Blocking mode, which in turn prevents switching loops from forming. 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. Hang in there! 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 as BPDUs are received, not sent. That new root path cost value will be reflected in the BDPU 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 is, and doesn't particularly care. No switch downstream of SW3 will know of any Path Costs on SW2 or SW3 - the downstream switches will only see the cumulative cost, the Root Path Cost. Let's go back to our two-switch example...
...the incoming Root Path Cost should be the same for both ports on SW2, since the two links are the same speed. Let's run show spanning-tree vlan 1 again to see what the deciding factor was.
SW2#show spanning-tree vlan 1 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------
Fa0/11 Fa0/12
Root Altn
FWD BLK
19 19
128.11 128.12
P2p P2p
The costs are indeed the same, 19 for each port. (That's the default cost for a 100 MBPS port. Remember, the port cost is determined by the speed of the port.) SW2 is receiving BPDUs from SW1 on both ports 0/11 and 0/12, and one of those ports has to be chosen as the Root Port by SW2. Here's the process of choosing a Root Port, and how these steps factored into SW2's decision-making process. 1. Choose the port receiving the superior BPDU. By "superior BPDU", we mean the one with the lowest BID. The BPDUs are coming from the same switch - SW1 - so this is a tie. 2. Choose the port with the lowest Root Path Cost to the root bridge. That's a tie here, too. 3. Choose the port receiving the BPDU with the lowest Sender BID. Since the same switch is sending both BPDUs, that's a tie here as well. 4. Choose the lowest Port ID. That was the tiebreaker here. Using our three-router network, we can easily identify the root ports on both SW B and SW C. Both ports on SW A will be in forwarding mode, since this is the root bridge.
STP isn't quite done, though. A designated port needs to be chosen for the segment connecting SW B and SW C. 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. Remember the network segment we looked at earlier in this section where we had three switches with the capability to forward frames onto a segment? If only one of the switches is allowed to forward frames, the possibility of a switching loop is reduced considerably. That's why we have DPs. There's a chance that both switches in this example would have the same Root Path Cost. In that case, the port belonging to the switch with the lowest BID will become the Designated Port. Additionally, all ports on the root bridge are considered Designated Ports. Assuming that SW B has a priority of 32768:bb-bb-bb-bb-bb-bb and SW C has a priority of 32768:cc-cc-cc-cc-cc-cc, port 0/2 on SW B would become a Designated Port, and port 0/1 on SW C would be placed into blocking mode. Out 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.
How Root Path Costs Are Determined The default STP Path Costs are determined by the speed of the port. These path costs have changed from their original values, so you'll be shown both here. The costs we'll see on the switches in this section are the revised costs. 10 MBPS Port: Originally 100, still 100 100 MBPS Port: Originally 10, now 19 1 GBPS Port: Originally 1, now 4 10 GBPS Port: Originally 1, now 2 If you change a port cost, the Spanning-Tree Algorithm (STA) runs and STP port states may change as a result - but then, that's probably why you're changing port costs! These costs were revised as port speed capabilities increased. Originally, 1 GBPS and 10 GBPS ports had the same port cost, which shouldn't be the case and no longer is. Whether in the real world or in the exam room, you've got to know how to determine what ports will be root ports and which will be non-designated (blocked) ports. You have to be careful not to jump to the conclusion that the physically shortest path is the logically shortest path.
If you're asked which port on SW3 will be the root port, it's easy to look at the physical topology and decide that it's fast 0/3 - after all, that port is a physically straight shot to the root. 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. SW3 - SW1 Root Path Cost: 100 (One 10 MBPS link) SW3 - SW2 - SW 1 Root Path Cost: 38 (Two 100 MBPS links) Whether it's in the exam room or a production network, make sure to check the port speeds before assuming that the physically shortest path is the optimal path. (RIP makes that mistake - don't you make it!) 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 or perhaps avoid results you don't want! In the following example, SW2 shows a Path Cost of 19 for both ports 0/11 and 0/12.
We'll now change the port cost of 0/12 to 9 for all VLANs...
SW2(config)#int fast 0/12 SW2(config-if)#spanning-tree cost 9
... and the results are seen immediately. Note that 0/11 was placed into blocking mode and 0/12 is in Listening mode, soon to be Forwarding mode.
Let's take this one step further. Right now on this switch, we have VLANs 1, 20, and 100. What if we wanted to lower port 0/11's cost to 5 for VLAN 100 only, but leave it at the default of 19 for the other VLANs? We can do this by specifying the VLAN in the cost command.
SW2(config)#int fast 0/11 SW2(config-if)#spanning-tree vlan 100 cost 5
The cost is lowered for this port in VLAN 100....
... but for VLAN 20, the cost remains the same.
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. The STP Port States
We've discussed the Forwarding and Blocking states briefly, but you should remember from your CCNA studies that there are some intermediate STP states. A port doesn't go from Blocking to Forwarding immediately, and for good reason - this is another switching loop prevention mechanism. Let's talk about each STP port state. Disabled isn't generally thought of as an STP port state; you're not going to look into the STP table of a VLAN and see "DIS" next to a port. 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?" Listening for BPDUs - and this port can now send BPDUs as well. The port still can't forward or receive data frames, and 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. Finally, a port enters forwarding mode. This allows a port to forward and receive data frames, send and receive BPDUs, and place MAC addresses in its MAC table. To see the STP mode of a given interface, use the show spanning-tree interface command.
SW1#show spanning-tree interface fast 0/11 Vlan Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- ---------VLAN0001 Desg FWD 19 128.11 P2p
STP Timers You may remember these timers from your CCNA studies as well, and you should also remember that these timers should not be changed lightly. 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. Don't believe me? :) We'll prove that very shortly. Right now, let's review the STP timer basics. Hello Time defines how often the Root Bridge will originate Configuration BPDUs. 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. 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. If a switch's blocked port does not receive a BPDU for the MaxAge duration, that port will come out of Blocking mode and go into Listening mode as part of its transition to Forwarding mode. 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 ? 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> SW1(config)#spanning-tree vlan 1 hello-time 5 SW1(config)#spanning-tree vlan 1 max-age 30 SW1(config)#spanning-tree vlan 1 forward-time 20 SW1#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000f.90e1.c240 This bridge is the root Hello Time 5 sec Max Age 30 sec Bridge ID
Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e1.c240 Hello Time 5 sec Max Age 30 sec Forward Delay 20 sec Aging Time 300 Role Sts Cost Prio.Nbr Type ---- --- --------- -------- ----------------------------Desg FWD 19 Desg FWD 19 128.11 128.12 P2p P2p
Interface -----------------Fa0/11 Fa0/12
Again, these values have to be changed on the root switch in order for the change to be accepted by the rest of the network. In the following example, we'll change the STP timers on a nonroot switch and then run show spanning-tree.
SW2#show spanning vlan 10 VLAN0010 Spanning tree enabled protocol ieee Root ID Priority 32778 Address 000f.90e1.c240 Cost 19 Port 11 (FastEthernet0/11) Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 32778 (priority 32768 sys-id-ext 10) Address 000f.90e2.1300 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15
SW2 is not the root switch for VLAN 10 (or any other VLANs at this point). We'll change the STP timers on this switch.
SW2(config)#spanning-tree vlan 10 forward-time 30 SW2(config)#spanning-tree vlan 10 hello-time 5 SW2(config)#spanning-tree vlan 10 max-age 40 SW2#show spanning-tree vlan 10 VLAN0010 Spanning tree enabled protocol ieee Root ID Priority 32778 Address 000f.90e1.c240 Cost 19 Port 11 (FastEthernet0/11) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32778 (priority 32768 sys-id-ext 10) Address 000f.90e2.1300 Hello Time 5 sec Max Age 40 sec Forward Delay 30 sec Aging Time 300
The "Bridge ID" timers have changed, but the Root ID STP timers didn't. The timers listed next to Root ID are the STP timers in effect on the network. The nonroot switch will allow you to change the STP timers, but these new settings will not be used by any router, including the local switch itself, 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 to keep the same timers if the root goes down and the secondary then becomes the root. You'll occasionally see STP documentation that mentions lessening BPDU traffic by altering the STP timers, or perhaps changing the timers in a situation where STP regularly recalculates. While this is technically true, my personal real-world recommendation is to fix the problem causing the STP recalculation, not trying to work around it by changing STP timers. You might have noticed some other options with the spanning-tree vlan command:
SW1(config)#spanning-tree vlan 1 ? forward-time Set the forward delay for the spanning tree hello-time Set the hello interval for the spanning tree max-age Set the max age interval for the spanning tree priority Set the bridge priority for the spanning tree root Configure switch as root <cr>
If STP is left totally alone, a single switch is going to be the root bridge for every single VLAN in your network. Worse, that single switch is going to be selected because it has a lower MAC address than every other switch, which isn't exactly the criteria you want to use to select a single root bridge. The time will definitely come when you want to determine a particular switch to be the root bridge for your VLANs, or when you will want to spread the root bridge workload. For instance, if you have 50 VLANs and five switches, you may want each switch to act as the root bridge for 10 VLANs each. You can make this happen with the spanning-tree vlan root command. In our previous two-switch example, SW 1 is the root bridge of VLAN 1. We can create 3 more VLANs, and SW 1 will always be the root bridge for
every VLAN. Why? Because its BID will always be lower than SW 2. I've created three new VLANs, as seen in the output of show vlan brief. The edited output of show spanning-tree vlan shows that SW 1 is the root bridge for all these new VLANs.
SW1#show vlan br 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 10 VLAN0010 active 20 VLAN0020 active 30 VLAN0030 active SW1#show spanning-tree vlan 10 VLAN0010 Spanning tree enabled protocol ieee Root ID Priority 32778 Address 000f.90e1.c240 This bridge is the root SW1#show spanning-tree vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 32788 Address 000f.90e1.c240 This bridge is the root SW1#show spanning-tree vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 32788 Address 000f.90e1.c240 This bridge is the root
Let's say we'd like SW 2 to act as the root bridge for VLANs 20 and 30 while leaving SW 1 as the root for VLANs 1 and 10. To make this happen, we'll go to SW 2 and use the spanning-tree vlan root primary command.
SW2(config)#spanning-tree vlan 20 root primary SW2(config)#spanning-tree vlan 30 root primary SW2#show spanning vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 24596 Address 000f.90e2.1300 This bridge is the root SW2#show spanning vlan 30 VLAN0030 Spanning tree enabled protocol ieee Root ID Priority 24606 Address 000f.90e2.1300 This bridge is the root
SW 2 is now the root bridge for both VLAN 20 and 30. Notice that the priority value has changed from the default.
This command has another option you should be aware of:

SW2(config)#spanning-tree vlan 30 root ? primary Configure this switch as primary root for this spanning tree secondary Configure switch as secondary root
You can also configure a switch to be the secondary, or standby, root bridge. 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. We'll use the root primary command to make SW3 the root of VLAN 20. Which switch would become the root if SW3 went down?
SW3(config)#spanning vlan 20 root primary SW3#show spanning vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 24596 Address 0011.9375.de00 This bridge is the root Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 24596 (priority 24576 sys-id-ext 20) Address 0011.9375.de00 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15
SW2#show spanning vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 32788 Address 0011.9375.de00 Cost 19 Port 24 (FastEthernet0/22) Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 32788 (priority 32768 sys-id-ext 20) Address 0018.19c7.2700 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300
SW1#show spanning vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 32788 Address 0011.9375.de00 Cost 38 Port 15 (FastEthernet0/13) Hello Time 2 sec Max Age 20 sec Bridge ID Priority Address Hello Time
32788 (priority 32768 sys-id-ext 20) 0019.557d.8880 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
SW2 and SW1 have the same default priority, so the switch with the lowest MAC address will be the secondary root - and that's SW2. But what if we want SW1 to become the root if SW3 goes down? We use the root secondary command on SW1!
SW1(config)#spanning vlan 20 root secondary SW1#show spanning vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 24596 Address 0011.9375.de00 Cost 38 Port 15 (FastEthernet0/13) Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 28692 (priority 28672 sys-id-ext 20) Address 0019.557d.8880 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300
SW1 now has a priority of 28672, which will make SW1 the root if SW3 goes down. A priority value of 28672 is an excellent tipoff that the root secondary command has been used on a switch. The config itself shows this command as well:
spanning-tree mode pvst spanning-tree extend system-id spanning-tree vlan 20 priority 28672
Take note of those two default settings - "mode pvst" and "extend systemid". We'll talk about the Extended System ID feature later in this section, and the PVST default mode is discussed in the Advanced STP section. 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,576, the switch sets its priority to 24576 in order to become the root. You saw that in the previous example. If the current root bridge's priority is less than 24,576, the switch subtracts 4096 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 4096.
SW2(config)#spanning-tree vlan 10 priority ?
<0-61440>
bridge priority in increments of 4096
Where Should The Root Bridge Be Located? I'm sure you remember the Cisco Three-Layer Hierarchical Model, which lists the three layers of a switching network - Core, Distribution, and Access. 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 accesslayer 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. Topology Change Notifications (TCNs) Configuration BPDUs are originated only by the root bridge, but a TCN BPDU will be generated by any switch in the network when one of two things happen: A port goes into Forwarding mode A port goes from Forwarding or Learning mode into Blocking mode While the TCN BPDU is important, it doesn't give the other switches a lot
of detail. The TCN doesn't say exactly what happened, just that something happened. (Kind of like Lassie used to do.)
As the TCN works its way toward the root bridge, each switch that receives the TCN will send an acknowledgement and forward the TCN.
When the root bridge receives the TCN, the root will also respond with an acknowledgement, but this ack will take the form of a Configuration BPDU with the Topology Change bit set.
This indicates to all receiving switches that the default aging time for their MAC tables should be changed from the default of 5 minutes to whatever the Forward Delay value is - by default, that's 15 seconds. (Another reason to be careful, if not downright hesitant, to start adjusting STP timers.) A natural question is "How long will the aging time for the MAC table stay at the Forward Delay value?" Here's the quick formula for the answer: (Forward Delay) + (Max Age) Assuming the default settings, that's a total of 35 seconds... and yet another reason to consider leaving the STP timers at their defaults!
TCNs And The Portfast Exception Cisco switching veterans just know that Portfast has to get involved here somewhere! 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! Load Sharing With The port-priority Command We can actually change a port's priority for some VLANs and leave it at the default for other VLANs in order to perform load balancing over a trunk. Let's take a look at the default behavior of a trunk between to 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. SW1 is the root for all ten VLANs. 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!
SW1#show spanning vlan 11 VLAN0011 Spanning tree enabled protocol ieee Root ID Priority 32779 Address 000e.d7f5.a040 This bridge is the root Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 32779 (priority 32768 sys-id-ext 11) Address 000e.d7f5.a040 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Role ---Desg Desg Sts --FWD FWD Cost --------19 19 Prio.Nbr -------128.11 128.12 Type ---------------------------P2p P2p
Interface ---------------Fa0/11 Fa0/12
SW2#show spanning vlan 11 VLAN0011 Spanning tree enabled protocol ieee Root ID Priority 32779 Address 000e.d7f5.a040 Cost 19 Port 11 (FastEthernet0/11) Hello Time 2 sec Max Age 20 sec
Bridge ID
Priority 32779 (priority 32768 sys-id-ext 11) Address 000f.90e2.14c0 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Role ---Root Altn Sts --FWD BLK Cost --------19 19 Prio.Nbr -------128.11 128.12 Type -------------------------P2p P2p
Interface ---------------Fa0/11 Fa0/12
I'm not going to run this command for all of the other VLANs in this example, but right now the trunk line between 0/11 on both switches is carrying the entire load for all VLANs. What if we wanted to use the trunk connecting 0/12 on both switches to carry the data for VLANs 15-20, while the trunk connecting 0/11 carries the rest? By lowering the port priority on 0/12 on one of the switches, we can accomplish this. Here, we'll change the port priority on SW1's fast 0/12 port. 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!
SW1(config)#int fast 0/12 SW1(config-if)#spanning-tree vlan ? WORD vlan range, example: 1,3-5,7,9-11 SW1(config-if)#spanning-tree vlan 15-20 ? cost Change an interface's per VLAN spanning tree path cos port-priority Change an interface's spanning tree port priority SW1(config-if)#spanning-tree vlan 15-20 port-priority ? <0-240> port priority in increments of 16 SW1(config-if)#spanning-tree vlan 15-20 port-priority 16
We didn't change the root switch in any way, so SW1 still shows as the root, and both trunk ports will still be in forwarding mode. Note the change to 0/12's priority.
SW1#show spanning vlan 15 VLAN0015 Spanning tree enabled protocol ieee Root ID Priority 32783 Address 000e.d7f5.a040 This bridge is the root Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 32783 (priority 32768 sys-id-ext 15) Address 000e.d7f5.a040 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Role ---Desg Desg Sts --FWD FWD Cost Prio.Nbr Type --------- -------- -----------------------19 128.11 P2p 19 16.12 P2p
Interface ---------------Fa0/11 Fa0/12
The true impact of the command is seen on SW2, where 0/12 is now in Forwarding mode for VLAN 15, and 0/11 is in Blocking mode.
SW2#show spanning vlan 15 VLAN0015 Spanning tree enabled protocol ieee
Root ID
Priority Address Cost Port Hello Time
32783 000e.d7f5.a040 19 12 (FastEthernet0/12) 2 sec Max Age 20 sec
Bridge ID
Priority 32783 (priority 32768 sys-id-ext 15) Address 000f.90e2.14c0 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300
Interface Role Sts Cost Prio.Nbr Type ------------------- --- --------- -------- ------------------------Fa0/11 Altn BLK 19 128.11 P2p Fa0/12 Root FWD 19 128.12 P2p
Let's check VLAN 11 on SW2 - is fast 0/11 still in Forwarding mode for that VLAN?
SW2#show spanning vlan 11 VLAN0011 Spanning tree enabled protocol ieee Root ID Priority 32779 Address 000e.d7f5.a040 Cost 19 Port 11 (FastEthernet0/11) Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 32779 (priority 32768 sys-id-ext 11) Address 000f.90e2.14c0 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Role ---Root Altn Sts --FWD BLK Cost --------19 19 Prio.Nbr -------128.11 128.12 Type -------------------P2p P2p
Interface ---------------Fa0/11 Fa0/12
Yes, it is! VLANs 11 - 15 will use the trunk between the switches' fast 0/11 ports, and VLANs 15-20 will use the trunk between the switches' fast 0/12 ports. I'll grant you that in most instances, you'll configure an Etherchannel here rather than using port priority to load balance over the trunk lines. However, 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! And in this situation, if 0/12 should go down for some reason....
SW2(config)#int fast 0/12 SW2(config-if)#shutdown
... VLANs 15 - 20 would begin using the 0/11 trunk.

SW2#show spanning vlan 15 VLAN0015 Spanning tree enabled protocol ieee Root ID Priority 32783 Address 000e.d7f5.a040 Cost 19 Port 11 (FastEthernet0/11) Hello Time 2 sec Max Age 20 sec Bridge ID Priority Address
32783 (priority 32768 sys-id-ext 15) 000f.90e2.14c0
Hello Time 2 sec Aging Time 300
Max Age 20 sec
Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- ----------------------------Fa0/11 Root FWD 19 128.11 P2p
Get The VLAN Information You Need! 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?
SW1#show interface fast 0/2 switchport Name: Fa0/2 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: down Administrative Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Protected: false Appliance trust: none
From top to bottom, you can see whether the switchport is enabled, what the trunking mode is ("administrative mode"), what trunking encapsulation is in use, whether trunking's being negotiated or not, what the native VLAN is, and so forth. This is an excellent VLAN and trunking troubleshooting command. And the problem? I left the interface shut down. :) output looks like when the interface is open.
SW1#show interface fast 0/2 switchport Name: Fa0/2 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: none
Here's what the
Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Protected: false Appliance trust: none
The reason I'm pointing that out is that with the basic show interface command, you'll see the phrase "administratively down" - and you know from your CCNA studies that this phrase really means "you forgot to open the interface."
SW1#show interface fast 0/2 FastEthernet0/2 is administratively down, line protocol is down (disabled)
When you run show interface switchport, you're not going to see "administratively down", but just "down" - which may lead you to look for a more complex solution. It certainly did that to me once! Just remember to always check the interface's open/shut status first, no matter what the router or switch is telling you. : ) Here's what the output looks like when a trunk port is specified. Note that you can also see what VLANs are allowed across the trunk and which VLANs are being pruned.
SW1#show interface fast 0/11 switchport Name: Fa0/11 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Protected: false Appliance trust: none
The Extended System ID Feature Earlier in this section, we took a look at part of a switch's configuration and saw this line:
spanning-tree extend system-id
Defined in IEEE 802.1t, the Extended System ID feature greatly extends the number of STP instances that can be supported by the switch, which in turn allows the switch to support up to 4096 VLANs. The extended VLANs will be numbered 1025 - 4096. You can't use this feature on all Cisco switches, though. It is enabled by default on 2950 and 3550 switches with an IOS version of 12.1(8)EA or later. 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:
SW1#show spanning vlan 20 VLAN0020 Spanning tree enabled protocol ieee Root ID Priority 24596 Address 0011.9375.de00 Cost 38 Port 15 (FastEthernet0/13) Hello Time 2 sec Max Age 20 sec Bridge ID
Priority 32788 (priority 32768 sys-id-ext 20) Address 0019.557d.8880 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300
The BID priority is the default priority of 32768 plus the System ID Extension value (sys-id-ext). The sys-id-ext value just happens to be the VLAN number, so the BID priority is 32768 + 20, which equals 32788. Some switches running CatOS can support this feature; with those switches, it's called STP MAC Address Reduction. Disabled by default, it can be enabled with the set spantree macreduction command. (set commands are run on CatOS switches only - IOS-based switches use the CLI commands you see throughout this book.)

Advanced Spanning Tree

Overview
Portfast Uplinkfast Backbonefast Root Guard BPDU Guard UDLD Loop Guard BPDU Skew Detection Rapid Spanning Tree Protocol PVST And PVST+ CTP and MST Etherchannels
We'll now build on the fundamental switching skills you have and take those skills to the next level. You're going to be introduced to quite a few Spanning Tree and switching features that you may never have seen before, and the challenge is that their names and purposes are similar. Make sure you have the information in this section down cold before you take the BCMSN exam. Portfast You should remember this one from your CCNA studies! 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.
A Cisco router will give you a warning when you configure Portfast:
SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree portfast %Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION %Portfast has been configured on FastEthernet0/5 but will only have effect when the interface is in a non-trunking mode. SW1(config-if)#
Do not configure Portfast on a port leading to a switch, router, or other networking device. It's just that simple! 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. An excellent real-world usage of Portfast is to allow users to get their IP addresses from a DHCP server. 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:
SW2(config)#spanning portfast default %Warning: this command enables portfast by default on all interfaces. 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. And remember, a Portfastenabled port will not send TCP BPDUs when the port goes into Blocking mode. Uplinkfast When a port goes through the transition from blocking to forwarding, you're looking at a 50-second delay before that port can actually begin forwarding frames. Configuring a port with Portfast is one way to get around that, but again, you can only use it when a single host device is found off the port. What if the device connected to a port is another switch?
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 50-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 50-second delay, that certainly seems immediate! Uplinkfast cannot be configured on a root switch. When Uplinkfast is enabled, it's enabled globally and for all VLANs residing on the switch. You can't run Uplinkfast on some ports or on a per-VLAN basis - it's all or nothing. The original root port will become the root port again when it detects that its link to the root switch has come back up. This does not take place immediately. The switch uses the following formula to determine how long to wait before transitioning the original root port back to the forwarding state: ( 2 x FwdDelay) + 5 seconds Uplinkfast will take immediate action to ensure that a switch cannot become the root switch -- actually, two immediate actions! First, the switch priority will be set to 49,152, which means that if
all other switches are still at their default priority, they'd all have to go down before this switch can possibly become the root switch. Additionally, the STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches. And you just know there's got to be at least one option with this command, right? Let's run IOS Help and see.
SW2(config)#spanning-tree uplinkfast ? max-update-rate Rate at which station address updates are sent
When there is a direct link failure, dummy multicast frames are sent to the MAC destination address 01-00-0c-cd-cd-cd. The max-update-rate value determines how many of these frames will be sent in a 100-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. Now, you may be asking, "What is an inferior BPDU?" Glad you asked! 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.
SW1 has been elected the root bridge, and sends BPDUs every two seconds to SW2 and SW3 telling them this. In turn, SW2 takes the BPDU it's receiving from SW1 and relays it to SW3. 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.
SW3 looks at the priority of the BPDU coming in from SW2, and compares it to the BDPUs it's getting from SW1. SW3 quickly realizes the BPDU from SW2 is an inferior BPDU, and simply ignores it. Once SW3's MaxAge timer on the port leading to SW2 hits zero, that port will transition to the listening state and will start relaying the information contained in the superior BPDU, the BPDU coming in from SW1.
The key phrase here is "once SW3's MaxAge timer on the port leading to SW2 hits zero". 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 30. (MaxAge's default value is 20 seconds, but the 15-second Listening and Learning stages still have to run.) BackboneFast uses the Root Link Query (RLQ) protocol. RLQ uses a series of requests and responses to detect indirect link outages. RLQ requests are transmitted via the ports that would normally be receiving BPDUs. 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#show spanning-tree backbonefast BackboneFast is disabled SW1#conf t Enter configuration commands, one per line. SW1(config)#spanning-tree backbonefast SW1#show spanning-tree backbonefast BackboneFast is enabled
End with CNTL/Z.
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 ? primary Configure this switch as primary root for this spanning tree secondary Configure switch as secondary root
We've used that command to name the root and secondary root switches in the following network. For clarity's sake, the full BID is not shown - just the switch priority.
Nothing wrong here, everything's fine... until another switch is added to the mix.
The problem here is that SW4 is going to become the root switch, and SW1 is going to become the secondary root. If SW4 is allowed to become the root bridge, here's what the new STP topology will look like.
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. To prevent SW4 from becoming the root or secondary root, SW3's port that will receive BPDUs from SW4 should be configured with Root Guard. When the BPDU comes in from SW4, SW3 will recognize this as a superior BPDU, one that would result in a new root switch being elected. Root Guard will actually block that superior BPDU, discard it, and put the port into root-inconsistent state. When those superior BPDUs stop coming, SW3 will allow that port to transition normally through the STP port states. Configuring Root Guard is simple:
SW3(config)#int fast 0/24 SW3(config-if)#spanning guard root SW3(config-if)# 00:10:35: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/24.
SW4 now comes online and sends a superior BPDU for VLAN 23 to SW3, which receives the BPDU on port 0/24 - the port running Root Guard. Here's the console message we receive as a result on R3:
00:26:46: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/24 on VLAN0023.
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 ? active Report on active interfaces only backbonefast Show spanning tree backbonefast status blockedports Show blocked ports bridge Status and configuration of this bridge detail Detailed information inconsistentports Show inconsistent ports interface Spanning Tree interface status and configuration pathcost Show Spanning pathcost options root Status and configuration of the root bridge summary Summary of port states uplinkfast Show spanning tree uplinkfast status vlan VLAN Switch Spanning Trees | Output modifiers <cr> SW1#show spanning-tree inconsistentports Name Interface Inconsistency -------------------- ---------------------- ------------------
Those of you who do not like to type can just enter "inc" for that last word! This is the resulting topology:
BPDU Guard Remember that warning that we got from the router when configuring PortFast?
SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree portfast %Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION %Portfast has been configured on FastEthernet0/5 but will only have effect when the interface is in a non-trunking mode.
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. That could lead to two major problems, the first being the formation of a switching loop. Remember, the reason we have listening and learning modes is to help prevent switching loops. The possibility of switching loops actually pales next to the other possibility - there could be a new root bridge elected and it could be a switch that isn't even in your network!
BPDU Guard protects against this disastrous possibility. If any BPDU 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. To configure BPDU Guard on a specific port only:
SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree bpduguard % Incomplete command. SW1(config-if)#spanning-tree bpduguard ? disable Disable BPDU guard for this interface enable Enable BPDU guard for this interface SW1(config-if)#spanning-tree bpduguard enable
To configure BPDU Guard on all ports on the switch:

SW1(config)#spanning-tree portfast bpduguard default
Naturally, BPDU Guard can only be configured on ports already running Portfast. The same goes for the next feature, BPDU Filtering. PortFast BPDU Filtering What if you don't want the port to be put into err-disabled state when it receives a BPDU? 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. Globally enabling BPDU Filtering will have a PortFast-enabled port stop running PortFast when the port receives a BPDU. Enabling BPDU Filtering on a specific port or ports, rather than enabling it globally, will result in received BPDUs being quietly ignored. Those incoming BPDUs will be dropped, and the port will not send any BPDUs in return. To enable BPDU Filtering globally on all Portfast-enabled ports:
SW1(config)#spanning portfast bpdufilter ? default Enable bdpu filter by default on all portfast ports SW1(config)#spanning portfast bpdufilter default
To enable BPDU Filtering on a specific port:

SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree bpdufilter enable
To verify global configuration of BPDU Filtering (and quite a few other features!):
SW1#show spanning-tree summary totals Switch is in rapid-pvst mode Root bridge for: none Extended system ID is enabled Portfast Default is disabled PortFast BPDU Guard Default is disabled Portfast BPDU Filter Default is enabled Loopguard Default is disabled EtherChannel misconfig guard is enabled UplinkFast is disabled BackboneFast is disabled Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------13 vlans 39 0 0 24 63
To verify configuration of BPDU Filtering on a specific port:

SW2#show spanning-tree interface fast0/5 detail Port 5 (FastEthernet0/5) of VLAN0001 is forwarding Port path cost 19, Port priority 128, Port Identifier 128.5. Designated root has priority 32769, address 000e.381f.ee80 Designated bridge has priority 32769, address 000e.381f.ee80 Designated port id is 128.5, designated path cost 0 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 1 The port is in the portfast mode Link type is point-to-point by default Bpdu filter is enabled by default BPDU: sent 6837, received 0
Unidirectional Link Detection (UDLD) Most problems involving the physical link will make data transfer in either direction impossible. Particularly with fiber optic, there are situations where a physical layer issue disables data transfer in one direction, but not the other.
UDLD detects these unidirectional links by transmitting a UDLD frame across the link. 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 ("errdisabled") 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 ? aggressive Enable UDLD protocol in aggressive mode on fiber ports except configured enable Enable UDLD protocol on fiber ports except where locally configured message Set UDLD message parameters SW2(config)#udld enable where locally
Here are your options for running UDLD at the interface level:
SW1(config)#int fast 0/11 SW1(config-if)#udld ? port Enable UDLD protocol on this interface SW1(config-if)#udld port ? aggressive Enable UDLD protocol in aggressive mode on this interface <cr>
Another important detail regarding UDLD is that to have it run effectively, you've got to have it configured on both involved ports. 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? Personally, I type very quickly, but even I can't enter the UDLD command on one switch and then connect to the remote switch and enable UDLD there within eight seconds! 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! Believe it or not, the switching loop potential is caused by CSMA/CD! The full-duplex port will not perform CSMA/CD, but the half-duplex port will. The problem comes in when the half-duplex port listens to the segment, hears nothing, and sends frames as it normally would under CSMA/CD rules...
... and then the full-duplex port sends frames without listening to the segment. We all know what happens then!
Under CSMA/CD rules, the half-duplex port will then invoke its random timer and then listen to the segment again before attempting to send frames - and that includes BPDUs. 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 We've had BPDU Guard, Root Guard, and now... Loop Guard! You can probably guess that the "loop" being guarded against is a switching loop... but how does Loop Guard prevent switching loops? 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. SW3 is receiving a BPDU directly from the root as well as a forwarded BPDU from the secondary root. But what happens if a physical issue causes the link between SW2 and SW3 to become a unidirectional link, where SW3 can send BPDUs to SW2 but SW2 cannot send them to SW3?
If SW2 cannot transmit to SW3, the BPDUs will obviously not reach SW3. SW3 will wait for the duration of the MaxAge timer - by default, 20 seconds - and will then begin to transition the port facing SW2 from blocking to forwarding mode. With all six ports in Forwarding mode, we've got ourselves a switching loop. Loop Guard does not allow a port to go from blocking to forwarding in this situation. With Loop Guard enabled, the port will go from blocking to loopinconsistent, which is basically still blocking mode, and a switching loop will not form.
Once the unidirectional link issue is cleared up and SW3 begins to receive BPDUs again, the port will come out of loop-inconsistent state and will be treated as an STP port would normally be. Loop Guard is disabled on all ports by default, and is enabled at the port level:
SW2(config-if)#int fast 0/5 SW2(config-if)#spanning-tree guard loop
You can also enable Loop Guard on a global basis:

SW1(config)#spanning-tree loopguard default
BPDU Skew Detection You may look at that feature's name and think, "What is a BPDU Skew, and why do I want to detect it?" What we're actually attempting to detect are BPDUs that aren't being relayed as quickly as they should be. After the root bridge election, the root bridge transmits BPDUs, and the non-root switches relay that BPDU down the STP tree. This should happen quickly all around, since the root bridge will be sending a BPDU every two seconds by default ("hello time"), and the switches should relay the BDPUs fast enough so every switch is seeing a BPDU every two seconds. That's in a perfect world, though, and there are plenty of imperfect networks out there! You may have a busy switch that can't spare the CPU to relay the BPDU quickly, or a BPDU may just simply be lost along the way down the STP tree. That two-second hello time value doesn't give the switches much leeway, but we don't want the STP topology recalculated unnecessarily either. BPDU Skew Detection is strictly a notification feature. Skew Detection will not take action to prevent STP recalculation when BPDUs are not being relayed quickly enough by the switches, but it will send a syslog message informing the network administrator of the problem. The amount of time between when the BPDU should have arrived and when it did arrive is referred to as "skew time" or "BPDU latency". A busy CPU could quickly find itself overwhelmed if it had to send a syslog message for every BPDU delivery that's skewed. The syslog messages will be limited to one every 60 seconds, unless the "skew time"
is at a critical level. In that case, the syslog message will be sent immediately with no one-per-minute limit. And what is "critical", according to BPDU Skew Detection? Any value greater than 1/2 of the MaxAge value, making the critical skew time level 10 seconds or greater.
Rapid Spanning Tree Protocol So you understand STP, and you've got all these 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 802.1d. The 30-second delay caused by the listening and learning states 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. Note that SW3 has multiple connections to the ethernet segment.
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. There will be no root port on a root bridge.
An RSTP designated port is the port with the best root path cost. The ports on the root switch will obviously have the lowest root path cost for that network segment, and will be the DP for that segment. We'll assume R3 has the DP for the segment connected to SW2.
RSTP's answer to a 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 port has already been selected as the designated port for that segment, and the other port will become the backup port. This port gives a redundant path to that segment, but doesn't guarantee that the root switch will still be accessible.
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. When a topology change is discovered by a switch running RSTP, that switch sends BPDUs with the Topology Change (TC) bit set. While the concept of a Portfast-enabled port and an Edge port in RSTP are the same - both go immediately to the Forwarding state and should be connected only to a single host - there is a major difference in their behavior when a BPDU is received on such a port. An RSTP Edge Port will simply be considered a "normal" spanning tree port after receiving a BPDU. 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 compare the two protocols and 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. The BPDU format is the same for STP and RSTP, but RSTP uses all flag bits available in the BPDU for various purposes including state negotiation between neighbors, but STP uses only the Topology Change (TC) and Topology Change Ack (TCA) flags. The details of this negotiation are out of the scope of the BCMSN exam, but can easily be found on the Internet by searching for "RSTP" in your favorite search engine. The RSTP BPDU is also of a totally different type (Type 2, Version 2), which allows an RSTP-enabled switch to detect older switches. Switching features we looked at earlier in this section - Uplinkfast, Portfast, and Backbonefast are built-in to RSTP. Per-VLAN Spanning Tree Versions (PVST and PVST+) The ultimate "the name is the recipe" protocol, the Cisco-proprietary PVST, well, runs a separate instance of STP for each VLAN! The Good: PVST does allow for much better fine-tuning of spanning-tree performance than does regular old STP. The Bad: Running PVST does mean extra work for your CPU and memory. The Ugly: PVST is Cisco-proprietary, so it must run over the Ciscoproprietary trunking protocol - ISL. The requirement for PVST to run ISL becomes a major issue in a network like this:
PVST doesn't play well at all with CST, so Cisco came up with PVST+. PVST+ is described by Cisco's website as having the same functionality as PVST, with the + version using dot1q rather than ISL. PVST+ is Ciscoproprietary as well. PVST+ can serve as an intermediary between groups of PVST switches and switches running CST; otherwise, the groups wouldn't be able to
communicate. Using PVST+ along with CST and PVST can be a little difficult to fine-tune at first, but this combination is running in many a network right now - and working fine!
Rapid Per-VLAN Spanning Tree Plus (RPVST +) And PVST+ Now there's a mouthful! Cisco being Cisco, you just know they have to have their own version of STP! Per-VLAN Spanning Tree Plus (PVST+) is just what it sounds like every VLAN has its own instance of STP running. PVST+ allows perVLAN load balancing and is also Cisco-proprietary. If you configure a switch running PVST+ to use RSTP, you end up with RPVST+ - Rapid Per-VLAN Spanning Tree Plus. The good news is that the command is very simple, and we'll use IOS Help to look at some other options:
SW1(config)#spanning-tree mode ? mst Multiple spanning tree mode pvst Per-Vlan spanning tree mode rapid-pvst Per-Vlan rapid spanning tree mode SW1(config)#spanning-tree mode rapid-pvst
The bad news is that doing so will restart all STP processes, which in turn results in a temporary data flow interruption. If you choose to make this change, it's a good idea to do so when end users aren't around. We'll revisit an old friend, show spanning-tree, to verify that RPVST+ is running on VLAN 1:
SW1#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol rstp Root ID Priority 32769 Address 000e.381f.ee80 Cost 4 Port 25 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Later in the output of that same command, note that ports leading to switches have "P2P Peer (STP)" as the type.
Fa0/18 Fa0/19 Altn BLK 19 Desg FWD 19 128.18 128.19 P2p Peer(STP) P2p Peer(STP)
CST And MST When our friend IEEE 802.1Q ("dot1q") is the trunking protocol, Common Spanning Tree is in use. With dot1q, all VLANs are using a single instance of STP.
Defined by IEEE 802.1s, Multiple Spanning Tree gets its name from a scheme that allows multiple VLANs to be mapped to a single instance of STP, rather than having an instance for every VLAN in the network. MST serves as a middle ground between STP and PVST. CST uses a single instance of STP, PVST has an instance for every VLAN, and MST allows you to reduce the number of STP instances without knocking it all the way back to one. MST was designed with enterprise networks in mind, so while it can be very useful in the right environment, it's not for every network. The configuration of MST involves logically dividing the switches into regions, and the switches in any given region must agree of the following:
1. 2. 3.
The MST configuration name The MST instance-to-VLAN Mapping table The MST configuration revision number
If any of these three values are not agreed upon by two given switches, they are in different regions. Switches send MST BPDUs that contain the configuration name, revision number, and a digest value derived from the mapping table. MST configurations can become quite complex and a great deal of planning is recommended before implementing it. No matter the size of the network, however, keep the central point in mind - the purpose of MST is to map multiple VLANs to a lesser number of STP instances. A good way to get a mental picture of the interoperability of MST and CST is that CST will cover the entire network, and MST is a "subset" of the network. CST is going to maintain a loop-free network only with the links connecting the MST network subnets, and it's MST's job to keep a loopfree topology in the MST region. CST doesn't know what's going on inside the region, and it doesn't want to know.
The "IST" in each region stands for Internal Spanning Tree, and it's the IST instance that is responsible for keeping communications in the MST Region loop-free. Up to 16 MST instances (MSTIs) can exist in a region, numbered 0 through 15. MSTI 0 is reserved for the IST instance, and only the IST is going to send MST BPDUs.
Occasionally the first ten MST instances are referred to as "00" "09". These are not hex values - they're regular old decimals. Here's the good part -- there's no such thing as "VTP For MST". Each and every switch in your MST deployment must be configured manually. (No, I'm not kidding!) When you create VLAN mappings in MST, you've got to configure every switch in your network with those mappings they're not advertised. A good place to start is to enable MST on the switch:
SW2(config)# spanning-tree mode mst
The name and revision number must now be set.

SW2(config)# spanning-tree mode mst configuration SW2(config-mst)# name REGION1 SW2(config-mst)# revision 1
To map VLANs to a particular MST instance:

SW2(config-mst)# instance 1 10,13, 14-20
Note that I could use commas to separate individual VLANs or use a hyphen to indicate a range of them. When mapping VLANs, remember that by default all VLANs will be mapped to the IST. Why Does Anyone Run STP Instead Of PVST? Like the TCP vs. UDP argument from your CCNA studies, this seems like a bit of a no-brainer. STP: 100 VLANs results in one STP process PVST: 100 VLANs results in 100 STP processes, allowing for greater flexibility with trunk usage (per-VLAN load balancing, for example) However, this goes back to something you must keep in mind when you're learning about all of these great features - everything we do on a Cisco switch has a cost in resources. The more STP processes a switch runs, the bigger the hit against the switch's memory and CPU. This is a decision you have to make in accordance with the switch's available resource and the workload PVST will put on your switch. Since Cisco Catalyst switches run PVST by default, that's a good indicator that PVST is the way to go. Just keep the resource hit in mind as your network grows - and the number of VLANs in that network with it! Etherchannels Etherchannels aren't just important for your BCMSN studies, they're a vital part of many of today's networks. Knowing how to configure and troubleshoot them is a vital skill that any CCNP must have. Etherchannels are part of the CCNA curriculum, but many CCNA books either leave Etherchannels out entirely or mention them briefly. You may
not have even seen an Etherchannel question on your CCNA exam, so we're going to begin this section with a review of what an Etherchannel is and why we would configure one. After that review, we'll begin an indepth examination of how Etherchannels work, and I'll show you some real-world examples of common Etherchannel configuration errors to help you master this skill for the BCMSN exam and for the real world. What Is An Etherchannel? 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 50second 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, there are three trunks between two switches.
If port 0/19 goes down, port 0/20 will begin the process of going from blocking to learning. In the meantime, communication between the two switches is lost. This temporary lack of a forwarding port can be avoided with an Etherchannel. By combining the three physical ports into a single logical
PTS taht set art sulli
e g dir b toor- non eht no 01 n al v gn inn ap s wohs

:sknil et ara pes eerht sees
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. Etherchannels use the Exclusive OR (XOR) algorithm to determine which channel in the EC to use to transmit data to the remote switch. After configuring an Etherchannel on each switch with the interface-level command channel-group, the output of commands show interface trunk and show spanning vlan 10 show STP now sees the three physical links as one logical link.
If one of the three physical links goes down, STP will not recalculate. While some bandwidth is obviously lost, the logical link itself stays up. Data that is traveling over the downed physical link will be rerouted to another physical link in a matter of milliseconds - it will happen so fast that you won't even hear about it from your end users! Negotiating An Etherchannel There are two protocols that can be used to negotiate an etherchannel. The industry standard is the Link Aggregation Control Protocol (LACP), and the Cisco-proprietary option is the Port Aggregation Protocol (PAgP). PAgP packets are sent between Cisco switches via ports that have the capacity to be placed into an etherchannel. First, the PAgP packets will check the capabilities of the remote ports against those of the local switch ports. The remote ports are checked for two important values: The remote port group number must match the number configured on the local switch The device ID of all remote ports must be the same - after all, if the remote ports are on separate switches, that would defeat the purpose of configuring an etherchannel!
PAgP also has the capability of changing a characteristic of the etherchannel as a whole if one of the ports in the etherchannel is changed. If you change the speed of one of the ports in an etherchannel, PAgP will allow the etherchannel to dynamically adapt to this change. The industry standard bundling protocol defined in 802.3ad, LACP assigns a priority value to each port that has etherchannel capability. You can actually assign up to 16 ports to belong to an LACP-negotiated etherchannel, but only the eight ports with the lowest port priority will be bundled. The other ports will be bundled only if one or more of the bundled ports fails. PAgP and LACP use different terminology to express the same modes. PAgP has a dynamic mode and auto mode. A port in dynamic mode will initiate bundling with a remote switch, while a port in auto mode waits for the remote switch to do so. LACP uses active and passive modes, where active ports initiate bundling and passive ports wait for the remote switch to do so. There's a third option, on, which means that there is no negotiation at all. Personally, this is the one I use in real-world networks, but it's a real good idea to know all about PAgP and LACP. Configuring Etherchannels To select a particular negotiation protocol, use the channel-protocol command.
SW1(config-if)#channel-protocol ? lacp Prepare interface for LACP protocol pagp Prepare interface for PAgP protocol
The channel-group command is used to place a port into an etherchannel.

SW1(config-if)#channel-group 1 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected
You can see the different terminology LACP and PAgP use for the same results - "active" and "desirable" for the local port to initiate the EC, "auto" and "passive" if the remote port is going to initiate the EC. To enable the etherchannel with no negotiation, use the on option. For an EC to form, LACP must have at least one of the two ports on each physical link set for "active"; if both ports are set to "passive", no EC will be built. The same can be said for PAgP and the settings "auto" and "desirable" - if both ports are set to auto, the link won't join the EC. To verify both PAgP and LACP neighbors, you can use the show pagp neighbor and show lacp neighbor commands. To illustrate, I've created an EC using channel-group 1 and the desirable option, meaning that PAgP is enabled unconditionally. The number you see below in each command is the channel group number. You can see that PAgP is running on ports 0/23 and 0/24, and that LACP is not running at all on that EC.
SW1#show pagp 1 neighbor Flags: S - Device is sending Slow hello. C - Device is in Consistent state. A - Device is in Auto mode. P - Device learns on physical port. Channel group 1 neighbors Partner Partner Partner Port Name Device ID Port Fa0/23 SW2 000e.381f.ee80 Fa0/23 Fa0/24 SW2 000e.381f.ee80 Fa0/24 SW1#show lacp 1 neighbor Channel group 1 is not participating in LACP
Partner Group Age Flags Cap. 13s SC 10001 11s SC 10001
The ECs we've created up to this point are pure Layer 2 ECs. We can verify this with the command show etherchannel brief.
SW1#show etherchannel brief Channel-group listing: ---------------------Group: 1 ---------Group state = L2 Ports: 2 Maxports = 8 Port-channels: 1 Max Port-channels = 1 Protocol: PAgP
You may be wondering what other kind of EC we might see here! In certain situations, you may want to apply an IP address to the EC itself, which results in a Layer 3 Etherchannel. We're on an L3 switch right now, which gives us the ability to create an L3 EC. The use and configuration of an L3 EC is beyond the scope of the BCMSN exam, but let's take a quick look at this config and view its impact on the show etherchannel brief command. With an L2 EC, we bundled the ports by configuring each port with the channel-group command, which automatically created the port-channel interface. When configuring an L3 interface, you must create the portchannel interface first, then put the ports into the EC with the port-channel command. IP routing must be enabled on the L3 switch, and all involved ports must be configured as routed ports with the switchport command.
SW1(config)#int port-channel 1 SW1(config-if)#no switchport SW1(config-if)#ip address 172.12.1.1 255.255.255.0 SW1(config-if)#int fast 0/23 SW1(config-if)#channel-group 1 mode desirable SW1(config-if)#no switchport
SW1(config-if)#int fast 0/24 SW1(config-if)#no switchport SW1(config-if)#channel-group 1 mode desirable
And now when we run show etherchannel brief...

SW1#show etherchannel brief Channel-group listing: ---------------------Group: 1 ---------Group state = L3
Ports: 2 Maxports = 8 Port-channels: 1 Max Port-channels = 1 Protocol: -
... the L3 EC is verified by the line "Group state = L3". Troubleshooting EtherChannels Once you get an EC up and running, it generally stays that way - unless a port setting changes. From personal experience, here are a few things to watch out for: Changing the VLAN assignment mode to dynamic. Ports configured for dynamic VLAN assignment from a VMPS cannot remain or become part of an EC. The allowed range of VLANs for the EC must match that of the ports. Here's a reenactment of an EC issue I ran into once. The configuration of the channel-group looked just fine...
interface FastEthernet0/11 switchport trunk allowed vlan 10,20 no ip address channel-group 1 mode on ! interface FastEthernet0/12 switchport trunk allowed vlan 100,200 no ip address channel-group 1 mode on
.. but notice that the allowed VLANs on these two ports is different. That will prevent an EC from working correctly. Here's the error message that occurs in a scenario like this:
02:46:10: %EC-5-CANNOT_BUNDLE2: Fa0/12 is not compatible with Fa0/11 and will be suspended (vlan mask is different)
Interestingly enough, port fast0/12 is not going to go into err-disabled mode; instead, you see this:
SW1#show int fast 0/12 FastEthernet0/12 is up, line protocol is down (notconnect)
When I remove the original command, I get the EC error message again, but once I change port 0/12's config to match 0/11's, the EC forms.
SW1(config)#int fast 0/12 SW1(config-if)#no switchport trunk allowed vlan 100,200 02:51:15: %EC-5-CANNOT_BUNDLE2: will be suspended (vlan mask is 02:51:15: %EC-5-CANNOT_BUNDLE2: will be suspended (vlan mask is Fa0/12 is not compatible with Fa0/11 and different) Fa0/12 is not compatible with Fa0/11 and different)chport
SW1(config-if)#switchport trunk allowed vlan 10,20 02:51:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/12, changed state to up
show interface trunk and show interface port-channel1 verify that the trunk and the EC are both up.
SW1#show int trunk
Port Po1 Port Po1 Port Po1
Mode desirable
Encapsulation 802.1q
Status trunking
Native vlan 1
Vlans allowed on trunk 10,20 Vlans allowed and active in management domain none
Port Vlans in spanning tree forwarding state and not pruned Po1 none SW1#show int port-channel1 Port-channel1 is up, line protocol is up (connected)
Changing a port attribute. Ports need to be running the same speed, duplex, native VLAN, and just about any other value you can think of! If you change a port setting and the EC comes down, you know what to do change the port setting back!
Verifying And Troubleshooting Etherchannels To take a quick look at the ECs running on a switch, run show etherchannel summary. In the following example, we can see that the EC serving as Port-Channel 1 is a Layer 2 EC as indicated by the code "S", and is in use as indicated by the code "U". You can also see the ports in the channel.
SW1#show etherchannel summary Flags: D - down P - in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 u - unsuitable for bundling U - in use f - failed to allocate aggregator d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+-----------------------1 Po1(SU) Fa0/11(Pd) Fa0/12(P)
If it's real detail you want, use show etherchannel x detail.

SW1#show etherchannel 1 detail Group state = L2 Ports: 2 Maxports = 8 Port-channels: 1 Max Port-channels = 1 Protocol: Ports in the group: ------------------Port: Fa0/11 -----------Port state Channel group Port-channel Port index = = = = Up Mstr In-Bndl 1 Mode = On/FEC Po1 GC = 0 Load = 0x00
Gcchange = Pseudo port-channel = Po1 Protocol = -
Age of the port in the current state: 00d:00h:26m:49s
Port: Fa0/12 -----------Port state Channel group Port-channel Port index = = = = Up Mstr In-Bndl 1 Mode = On/FEC Po1 GC = 0 Load = 0x00
Gcchange = Pseudo port-channel = Po1 Protocol = -
Age of the port in the current state: 00d:00h:21m:29s Port-channels in the group: ---------------------Port-channel: Po1 -----------Age of the Port-channel = 00d:00h:26m:52s Logical slot/port = 1/0 Number of ports = 2 GC = 0x00000000 HotStandBy port = null Port state = Port-channel Ag-Inuse Protocol = Ports in the Port-channel: Index Load Port EC state No of bits ------+------+------+------------------+----------0 00 Fa0/11 On/FEC 0 0 00 Fa0/12 On/FEC 0 Time since last port bundled: 00d:00h:21m:32s Time since last port Un-bundled: 00d:00h:21m:32s SW1# Fa0/12 Fa0/12
Copyright 2007 by The Bryant Advantage. All Rights Reserved.

Securing The Switches & Tunneling

Passwords Introduction To AAA Authentication Authorization Accounting Port Security Dot1x Port-Based Authentication SPAN Basics Local SPAN Remote SPAN SPAN Limitations VLAN Access Control Lists Dot1q Tunneling Ethernet over MultiProtocol Label Switching Transparent LAN Service Private VLANs DHCP Snooping Dynamic ARP Inspection IP Source Guard MAC Address Flooding
When it comes to security, you really can't do enough to protect your network devices. However, some networks are protected from the outside in, but not the inside out. What security do you have in place to
stop intruders who are physically inside your building? Could they delete every VLAN in your network? Could they bring your network down? Or would they be stopped before I got started? The first methods of security I'm going to talk about in this chapter aren't fancy, they aren't exciting, and they don't cost an arm and a leg. But the basic security features are the ones to start with. I don't care which layer of the Cisco three-layer model a switch fits into, and what block of the Enterprise Composite Network Model the switch falls into, I use a four-step process when suggesting a security model to a client: 1. Physical security - lock those servers, routers, and switches up! This is the most basic form of network security, and it's also the most ignored. 2. Passwords - set 'em, change 'em on occasion (and that occasion should not be the Millennium) 3. Different privilege levels - not every user needs the same level of access to potentially destructive commands. 4. Grant remote access only to those who absolutely, positively need it. Physical security is just that. Get the routers and switches locked up! Steps two and three go hand in hand, and much of what follows may be familiar to you. Don't skip this part, though, because we're going to tie in privilege levels when it comes to telnet access. You know how to configure the basic passwords on a switch:
SW2(config)#enable password ccna SW2(config)#enable secret ccnp SW2(config)#line con 0 SW2(config-line)#login % Login disabled on line 0, until 'password' is set SW2(config-line)#password ccie SW2(config)#line vty 0 15 SW2(config-line)#password cisco SW2(config-line)#login
Here's a quick refresher on some basic Cisco password rules and messages.... All passwords appear in the configuration in clear text by default except the enable secret. The command service password-encryption will encrypt the remaining passwords. The login message shown when the login command is used in the above example simply means that a password needs to be set to enable this feature. As long as you enter both the login and password commands, it does not matter in what order you enter them. Cisco switches have more VTY lines than routers. Routers allow up to five simultaneous Telnet sessions, and obviously switches allow more! The default behavior is the same, however. Any user who telnets in to the
switch will be placed into user exec mode, and will then be prompted for the proper enable mode password. If neither the enable secret nor the enable password has been set, the user will not be able to enter enable mode! To place users coming into the switch via telnet straight into enable mode, use the command privilege level 15 under the VTY lines.
SW2(config-line)#privilege level 15
Note below how the configuration appears on the switch when it comes to the VTY lines. If you want a command to be applied to all 16 lines, you don't have to use "line vty 0 4" and then "line vty 5 15" - just run the command line vty 0 15.
line vty 0 4 privilege level 15 password cisco login line vty 5 15 privilege level 15 password cisco login
The possible issue here is that any user who telnets in will be placed into enable mode. We might not want that. Consider a situation where a tech support person has to telnet into a router. Maybe they know what they're doing, and with all due respect, maybe they don't. Do you want this person making changes to the router without you knowing about it? It may be better to assign privilege level 15 to yourself while assigning the default value of 0 to others. I also don't like having one password for all telnet users. I prefer a scheme where each individual user has their own password. Creating a local database of users and privilege levels allows us to do this, and it's a simple procedure. As a matter of fact, you already did this at least once during your CCNA studies. All you have to do is create a username / password database the same way you create one for PPP authentication.
SW2(config)#username CBRYANT privilege 15 password CCIE SW2(config)#username WMCDANIEL password CCNP SW2(config)#username BMULLIGAN password CCNA
SW2(config)#line vty 0 15 SW2(config-line)#login local
The username / password command allows the assignment of privilege levels. If none is specified, level 0 is the default. With the above configuration, the first user would be placed into privileged exec mode when connecting via telnet, while the other two users would be required to enter the enable password before they could enter that mode. The login local command is required to have the switch look to a local database for authentication information. If a user doesn't know their username/password combination, they can't telnet into this switch. You may have heard or read the acronym AAA in Cisco switch
documentation. This stands for Authentication, Authorization, and Accounting - and you didn't know it, but you're already working with AAA. Well, "A", anyway! The passwords we've set here are part of Authentication, and this local database of passwords is just one method of authenticating users. We can also use RADIUS servers (Remote Authentication Dial-In User Service, a UDP service) or TACACS+ servers (Terminal Access Controller Access Control System, a TCP service). Both RADIUS and TACACS+ offer a lot of options. We're going to look at a basic switch config that could get us started with either. First, we've got to enable AAA on the switch. (This is not required if only the local database will be used.)
SW2(config)#aaa new-model
Here's the basic command for RADIUS, and all the options. Note that RADIUS is a UDP service.
SW2(config)#radius-server host ? Hostname or A.B.C.D IP address of RADIUS server SW2(config)#radius-server host 172.1.1.1 ? acct-port UDP port for RADIUS accounting server (default is 1813) alias 1-8 aliases for this server (max. 8) auth-port UDP port for RADIUS authentication server (default is 1812) key per-server encryption key (overrides default) non-standard Parse attributes that violate the RADIUS standard retransmit Specify the number of retries to active server (overrides default) timeout Time to wait for this RADIUS server to reply (overrides default) <cr> SW2(config)#radius-server host 172.1.1.1
The authentication process itself can and should be encrypted, as you see in the above output next to the key command. Here's the basic command for TACACS+. There's no mention of it here, but TACACS+ is a TCP service.
SW2(config)#tacacs-server ? administration Start tacacs+ deamon handling administrative messages attempts Number of login attempts via TACACS directed-request Allow user to specify tacacs server to use with dns-alias-lookup Enable IP Domain Name System Alias lookup for TACACS servers host Specify a TACACS server key Set TACACS+ encryption key. packet Modify TACACS+ packet options timeout Time to wait for a TACACS server to reply
Whether you define one or both, the methods of authentication must then be listed. They will be listed with one command, and in the order in which they appear in the command.
W2(config)#aaa authentication login ? WORD Named authentication list. default The default authentication list. W2(config)#aaa authentication login default ? enable Use enable password for authentication. group Use Server-group line Use line password for authentication. local Use local username authentication.
local-case none
Use case-sensitive local username authentication. NO authentication.
W2(config)#aaa authentication login default local ? enable Use enable password for authentication. group Use Server-group line Use line password for authentication. none NO authentication. <cr> W2(config)#aaa authentication login default local group ? WORD Server-group name radius Use list of all Radius hosts. tacacs+ Use list of all Tacacs+ hosts. W2(config)#aaa authentication login default local group radius ? enable Use enable password for authentication. group Use Server-group line Use line password for authentication. none NO authentication. <cr> W2(config)#aaa authentication login default local group radius
This command would check the local database first, then the RADIUS server(s). Finally, this list will be applied to the appropriate VTY lines. IMPORTANT: Make sure to stay connected to the switch while it's tested. Don't log out, then find out you can't log back in.
SW2(config-line)#login authentication ? WORD Use an authentication list with this name. default Use the default authentication list. SW2(config-line)#login authentication default
Using RADIUS and / or TACACS+ gives you a tremendous amount of control over who does and does not connect to your switch, but don't overlook the basic password database and privilege level assignments. And encrypt those passwords! Authorization The second A is Authorization, and we've already configured a little of that as well. Assigning the right to perform given tasks is Authorization, and when we granted one of our Telnet users privilege level 15, we authorized that user to pretty much do what they want to do. While RADIUS is limited in the different levels of authorization, TACACS+ can be configured to force the user to be authenticated for any of the tasks seen here in IOS Help.
SW2(config)#aaa authorization ? auth-proxy For Authentication Proxy Services commands For exec (shell) commands. config-commands For configuration mode commands. configuration For downloading configurations from AAA server exec For starting an exec (shell). network For network services. (PPP, SLIP, ARAP) reverse-access For reverse access connections
If we choose commands here, the user will have to be given permission to use any switch command at all privilege levels. config-commands refers
to the use of configuration commands, and reverse-access refers to the user's ability or inability to run Reverse Telnet on the switch. Authorization is then applied to the appropriate lines much like authentication was.
SW2(config-line)#authorization ? arap For Appletalk Remote Access Protocol commands For exec (shell) commands exec For starting an exec (shell) reverse-access For reverse telnet connections
Accounting For some of us, this is the best part of AAA - Accounting. As in, "holding people accountable for what they do!" Accounting will use a RADIUS or TACACS+ server to track user activity. As with the previous AAA services, a method list must be defined:
SW2(config)#aaa accounting ? commands For exec (shell) commands. connection For outbound connections. (telnet, rlogin) exec For starting an exec (shell). nested When starting PPP from EXEC, generate NETWORK records before EXEC-STOP record. network For network services. (PPP, SLIP, ARAP) send Send records to accounting server. suppress Do not generate accounting records for a specific type of user. system For System events. update Enable accounting update records.
I know it's tempting to try to track everything that anyone's doing on any of your network devices. Believe me, I know it's tempting. But as with anything else Cisco, everything we do has a cost. Don't overwhelm your network trying to keep up with what everybody's doing. With the proper physical security and privilege levels. you won't have to run a great deal of accounting! The method list is applied as shown below.
SW2(config)#line vty 0 15 SW2(config-line)#accounting ? arap For Appletalk Remote Access Protocol commands For exec (shell) commands connection For connection accounting exec For starting an exec (shell)
One thing I want you to get used to now - the options for both services are not going to be the same from one IOS version to another. These options probably change from one router or switch to another more than any other options in the IOS, in my experience. Just a real-world word of warning! Port Security Here's another basic security feature that's regularly overlooked, but is very powerful. Port security uses a host's MAC address as a password, and if a device with a different MAC address sends frames to the switch on that port, the port will take action - by default, it will shut down. The switchport port-security command enables this feature, and then we've got a few options to consider...
SW2(config)#int fast 0/5 SW2(config-if)#switchport port-security Command rejected: Fa0/5 is not an access port. SW2(config-if)#switchport mode access SW2(config-if)#switchport access vlan 10
.... but before we enable this feature, the port has to be made an access port. Port security can't be enabled on ports that can possibly form a trunk. Now, let's get back to those options.
SW2(config-if)#switchport port-security ? aging Port-security aging commands mac-address Secure mac address maximum Max secure addresses violation Security violation mode <cr>
The first option to consider is the maximum value. This is the maximum number of secure MAC addresses allowed on the port. This number can vary - I've seen Cisco switches that would allow up to 1024, but this 2950 will only allow 132. These addresses can be configured statically with the mac-address option, or they can be learned dynamically.
SW2(config-if)#switchport port-security maximum ? <1-132> Maximum addresses SW2(config-if)#switchport port-security mac-address ? H.H.H 48 bit mac address
Finally, we need to decide the action the port should take in case of a violation. The default is shutdown, and it's just what it sounds like - the port is placed into error-disabled state and manual intervention is needed to reopen the port. An SNMP trap message is also generated. (You can also use the errdisable recovery command to specify how long the port should remain in that state before the switch itself resets the port.)
SW2(config-if)#switchport port-security violation ? protect Security violation protect mode restrict Security violation restrict mode shutdown Security violation shutdown mode
Protect mode simply drops the offending frames, while restrict mode drops the offending frames and will generate both an SNMP trap notification and syslog message regarding the violation. Let's take a look at the console messages you'll see when running port security in its default mode, shutdown. I configured a port on this switch with port security, one secure MAC address, and made sure it didn't match the host that would be sending frames on that port. Sure enough, within seconds all of this happened:
SW1(config-if)# 05:06:04: %PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/7, puttingFa0/7 in err-disable state 05:06:04: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 000f.f773.ed20 on port FastEthernet0/7. 05:06:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/7, changed state to down 05:06:06: %LINK-3-UPDOWN: Interface FastEthernet0/7, changed state to down
show interface verifies that this interface is in error-disabled state.

SW1#show int fast 0/7 FastEthernet0/7 is down, line protocol is down (err-disabled)
That port must now manually be reopened - of course, after resolving the security issue that brought it down in the first place! There is a little "gotcha" with port security that you need to be aware of. You can specify the number of secure MAC addresses, and you can specify secure MAC addresses as well. What if you allow for more secure MAC address than you actually configure manually, as shown below?
SW1(config-if)#switchport SW1(config-if)#switchport SW1(config-if)#switchport SW1(config-if)#switchport port-security port-security maximum 3 port-security mac-address aaaa.aaaa.aaaa port-security mac-address cccc.cccc.cccc
In this situation, the remaining secure MAC address will be dynamically learned - so if a rogue host with the MAC address dddd.dddd.dddd connected to that port right now, port security would allow it. Be careful! To verify your port security configuration, run show port-security interface.
SW1#show port-security interface fast 0/2 Port Security : Enabled Port Status : Secure-up Violation Mode : Shutdown Aging Time : 0 mins Aging Type : Absolute SecureStatic Address Aging : Disabled Maximum MAC Addresses : 3 Total MAC Addresses : 2 Configured MAC Addresses : 2 Sticky MAC Addresses : 0 Last Source Address:Vlan : 0000.0000.0000:0 Security Violation Count : 0
The violation mode here is the default, shutdown. In this scenario, the port will be shut down if the number of secure MAC addresses is reached and a host whose MAC address is not among those secure addresses connects to this port. Note that "aging time" is set to zero - that actually means that secure MAC addresses on this port will never age out, not that they have zero minutes before aging out. You can change this value with the switchport portsecurity aging command. This particular switch accepts the value set in minutes; many older models want this entered in seconds. Always use IOS Help to double-check a command's metric!
SW1(config-if)#switchport port-security aging time ? <1-1440> Aging time in minutes. Enter a value between 1 and 1440
The aging type value determines whether a secure MAC address will absolutely expire after a certain amount of time, or whether aging should be based on inactivity ... as IOS Help shows us!
SW1(config-if)#switchport port-security aging type ? absolute Absolute aging (default) inactivity Aging based on inactivity time period
Port security is a great feature, but you can't run it on all ports. There are a few port types that you can't configure with port security:
trunk ports ports placed in an Etherchannel destination SPAN port 802.1x ports Dot1x Port-Based Authentication Port security is good, but we can take it a step further with dot1x portbased authentication. The name refers to IEEE 802.1x, the standard upon which this feature is based. Unusually enough, the Cisco authentication server must be RADIUS - you can't use TACACS or TACACS+. One major difference between dot1x port-based authentication and port security is that both the host and switch port must be configured for 802.1x EAPOL (Extensible Authentication Protocol over LANs). That's a major departure from many of the switch features we've studied to date, since most other switch features don't require anything of the host. Usually the PC isn't aware of what the switch is doing, and doesn't need to know. Not this time!
Until the user is authenticated, only the following protocols can travel through the port: EAPOL STP CDP By default, once the user authenticates, all traffic can be received and transmitted through this port. To configure dot1x, AAA must first be enabled. As with previous configurations, a method list must be created. And again, as with previous configurations, you should use line as the last choice, just in case something happens regarding your login with the other methods.
SW2(config)#aaa new-model SW2(config)#aaa authentication dot1x ? WORD Named authentication list. default The default authentication list. SW2(config)#aaa authentication dot1x default ? enable Use enable password for authentication. group Use Server-group line Use line password for authentication. local Use local username authentication. local-case Use case-sensitive local username authentication. none NO authentication.
To enable dot1x on the switch:

SW2(config)#dot1x ? system-auth-control Enable or Disable SysAuthControl
Dot1x must be configured globally, but every switch port that's going to run dot1x authentication must be configured as well.
SW2(config-if)#dot1x port-control ? auto PortState will be set to AUTO force-authorized PortState set to Authorized force-unauthorized PortState will be set to UnAuthorized
Force-authorized, the default, does just what it sounds like - it forces the port to authorize any host attempting to use the port, but authentication is not required. Basically, there is no authentication on this port type. A port in force-unauthorized state literally has the port unable to authorize any client - even clients who could otherwise successfully authenticate! The auto setting enables dot1x on the port, which will begin the process as unauthorized. Only the necessary EAPOL frames will be sent and received while the port's unauthorized. Once the authentication is complete, normal transmission and receiving can begin. Not surprisingly, this is the most common setting.
SPAN Operation And Configuration We've secured the ports, but there will also come a time when we want to connect a network analyzer to a switch port. A common situation is illustrated below, where we want to analyze traffic sourced from the three PCs. To properly analyze the traffic, the network analyzer needs a copy of every frame the hosts are sending - but how are we going to get it there?
SPAN allows the switch to mirror the traffic from the source port(s) to the destination port to which the network analyzer is attached. (In some Cisco documentation, the destination port is referred to as the monitor port.) SPAN works very well, and the basic operation is simple. Studying SPAN
for exams and network usage can seem complicated at first, though, because there are several different versions of SPAN. The versions are much the same, though; the real difference comes in when you define the source ports. It's the location of the source ports that determines the SPAN version that needs to run on the switch. In the above example, we're running Local SPAN, since the destination and source ports are all on the same switch. If the source was a VLAN rather than a collection of physical ports, VLAN-based SPAN (VSPAN) would be in effect. The command monitor session starts a SPAN session, along with allowing the configuration of the source and destination. The sessions are totally separate operations, but the number of simultaneous sessions you can run differs from one switch platform to another. Cat 3550s and 2950s support only two, but more powerful switches can run as many as 64 sessions at once.
SW2(config)#monitor session ? <1-2> SPAN session number SW2(config)#monitor session 1 ? destination SPAN destination interface or VLAN source SPAN source interface, VLAN SW2(config)#monitor session 1 source ? interface SPAN source interface remote SPAN source Remote SW2(config)#monitor session 1 source interface ? FastEthernet FastEthernet IEEE 802.3 Port-channel Ethernet Channel of interfaces SW2(config)#monitor session 1 source interface fast 0/1 - 5 , Specify another range of interfaces Specify a range of interfaces both Monitor received and transmitted traffic rx Monitor received traffic only tx Monitor transmitted traffic only <cr>
Here, ports fast 0/1 - 0/5 have been configured as the source. By default, traffic being received and transmitted will be mirrored, but this can be changed to received traffic only and transmitted traffic only as shown above. Using the same session number, the traffic will be mirrored to the destination port 0/10. Verify the SPAN configuration with show monitor.
SW2(config)#monitor session 1 destination interface fast 0/10 SW2#show monitor Session 1 --------Type : Local Session Source Ports : Both : Fa0/1-2 Destination Ports : Fa0/10 Encapsulation : Native Ingress: Disabled
SPAN works fine if the source and destination ports are on the same switch, but realistically, that's not always going to happen. What if the traffic to be monitored is on one switch, but the only vacant port available
is on another switch?
Remote SPAN (RSPAN) is the solution. Both switches will need to be configured for RSPAN, since the switch connected to the PCs will need to send mirrored frames across the trunk. A separate VLAN will be created that will carry only the mirrored frames. RSPAN configuration is simple, but there are some factors you need to consider when configuring RSPAN: If there were intermediate switches between the two shown in the above example, they would all need to be RSPAN-capable. VTP treats the RSPAN VLAN like any other VLAN. It will be propagated throughout the VTP domain if configured on a VTP server. Otherwise, it's got to be manually configured on every switch along the intermediate path. VTP Pruning will also prune the RSPAN VLAN under the same circumstances that it would prune a "normal" VLAN. MAC address learning is disabled for the RSPAN VLAN. The source and destination must be defined on both the switch with the source port and the switch connected to the network analyzer, but the commands are not the same on each. After all that, the configuration is simple! Create the VLAN first, and identify it as the RSPAN VLAN with the remote-span command.
SW2(config)#vlan 30 SW2(config-vlan)#remote-span
SW2 is the source switch, and the traffic from ports 0/1 - 0/5 will be monitored and frames mirrored to SW1 via RSPAN VLAN 30.
SW2(config)#monitor session 1 source interface fast 0/1 - 5 SW2(config)#monitor session 1 destination remote ?
vlan
Remote SPAN destination RSPAN VLAN
SW2(config)#monitor session 1 destination remote vlan 30 % Incomplete command. SW2(config)#monitor session 1 destination remote vlan 30 ? reflector-port Remote SPAN reflector port
As you see, naming the RSPAN VLAN here doesn't finish the job. We now have to define the reflector port, the port that will be copying the SPAN traffic onto the VLAN.
SW2(config)#monitor session 1 desti remote vlan 30 reflector-port fast 0/12
SW1 will receive the mirrored traffic and will send it to a network analyzer on port 0/10.
SW1(config)#monitor session 1 source remote vlan 30 SW1(config)#monitor session 1 destination interface fast 0/10
Run show monitor to verify the configuration.

SW1#show monitor Session 1 --------Type : Remote Destination Session Source RSPAN VLAN: 30 Destination Ports : Fa0/10 Encapsulation : Native Ingress: Disabled
SPAN Limitations As I mentioned, SPAN is easy to configure, but it does have a few limitations on what ports can be made source or destination ports: Source port notes: A source port can be monitored in multiple, simultaneous SPAN sessions. A source port can be part of an Etherchannel. A source port cannot be configured as a destination port. A source port can be any port type - Ethernet, FastEthernet, etc. Destination port notes: A destination port can be any port type. A destination port can participate in only one SPAN session. A destination port cannot be a source port. A destination port cannot be part of an Etherchannel. A destination port doesn't participate in STP, CDP, VTP, PaGP, LACP, or DTP. Trunk ports can be configured as source and/or destination SPAN ports; the default behavior will result in the monitoring of all active VLANs on the trunk. I strongly recommend that you find the SPAN documentation for your
switch models before configuring them. SPAN operation is simple, but the command options do change. Finally, you may see the term "ESPAN" in some SPAN documentation. This is Enhanced SPAN, and some of Cisco's documentation mentions that this term has been used so often to describe different additions that the term has lost meaning. You'll still see it occasionally, but it doesn't refer to any specific addition or change to SPAN.
Filtering Intra-VLAN Traffic At this point in your Cisco studies, you're very familiar with access lists and their many, many, many uses! Access lists do have their limitations, though. While an ACL can filter traffic traveling between VLANs, it can't do anything about traffic from one host in a VLAN to another host in the same VLAN. Why not? It relates to how ACLs are applied on a multilayer switch. You know that the CAM (Content Addressable Memory) table holds the MAC addresses that the switch has learned, but the TCAM - Ternary Content Addressable Memory - cuts down on the number of lookups required to compare a packet against an ACL. This filtering of packets by the switch hardware speeds up the process, but this limits ACL capability. An ACL can be used to filter inter-VLAN traffic, but not intra-VLAN traffic. To filter traffic between hosts in the same VLAN, we've got to use a VLAN Access List (VACL).
Even though a VACL will do the actual filtering, an ACL has to be written as well. The ACL will be used to as the match criterion within the VACL. For example, let's say we have the subnet 172.10.10.0 /24's addresses configured on hosts in VLAN 100. The hosts 172.10.10.1 - 3 are not to be allowed to communicate with any other hosts on the VLAN, including each
other. An ACL will be written to identify these hosts.

SW2(config)#ip access-list extended NO_123_CONTACT SW2(config-ext-nacl)#permit ip 171.10.10.0 0.0.0.3 172.10.10.0 0.0.0.255
Notice that even though the three source addresses named in the ACL are the ones that will not be allowed to communicate with other hosts in the VLAN, the ACL statement is permit, not deny. The deny part is coming! Now the VLAN access-map will be written, with any traffic matching the ACL to be dropped and all other traffic to be forwarded. Note that the second access-map clause has no match clause, meaning that any traffic that isn't affect by clause 10 will be forwarded. That is the VACL equivalent of ending an ACL with "permit any". If you configure a VACL without a final "action forward" clause as shown below, all traffic that does not match a specific clause in the VACL will be dropped.
SW2(config)# vlan access-map NO_123 10 SW2(config-access-map)# match ip address NO_123_CONTACT SW2(config-access-map)# action drop SW2(config-access-map)# vlan access-map NO_123 20 SW2(config-access-map)# action forward
Finally, we've got to apply the VACL. We're not applying it to a specific interface - instead, apply the VACL in global configuration mode. The VLAN to be filtered is specified at the end of the command with the vlanlist option.
SW2(config)# vlan filter NO_123 vlan-list 100
Some additional notes and tips regarding VACLs: Bridged traffic, as well as non-IP and non-IPX traffic, should be filtered with VACLs VACLs run from top to bottom, and run until a match occurs VACLs have an implicit deny at the end. The VACL equivalent of "permit all" is an "action forward" clause with no match criterion, as shown in the previous example. If traffic is not expressly forwarded, it's implicitly dropped! Only one VACL can be applied to a VLAN The sequence numbers allow you to go back and add lines without rewriting the entire VACL. They are still active while being edited. A routing ACL can be applied to a SVI to filter inbound and/or outbound traffic just as you would apply one to a physical interface, but VACLs are not applied in that way - they're applied in global configuration mode. On L3 switches, you may run into a situation where there's a VACL configured, and a "normal" ACL affecting incoming traffic is applied to a
routed port that belongs to that same VLAN. In this case, packets entering that VLAN will be matched against the VACL first; if the traffic is allowed to proceed, it will then be matched against the inbound ACL on that port. A Possible Side Effect Of Performing ACL Processing In Hardware At the beginning of the VACL section, I mentioned that ACL processing in multilayer switches is performed in hardware. There will still be some traffic that is sent to the CPU for software processing, and that forwarding rate is much lower than the rate for the traffic forwarded by the switch hardware. If the hardware hits its storage limit for ACL configs, resulting in even more packets begin sent to the CPU, the switch performance can degrade. (I've seen that, and it's ugly. Avoid it.) Cisco's website lists two other factors that may result in too many packets being sent to the CPU, and they may surprise you: Excessive logging Use of ICMP Unreachable messages Use the log option with care. Logging must be performed by the switch software, not the hardware.
Tunneling With IEEE 802.1Q You know all about dot1q trunking by now, and you're probably sick of hearing about it! Well, this is a little different - we're going to perform some dot1q tunneling. Dot1q tunneling allows a service provider to transport frames from different customers over the same tunnel - even if they're using the same VLAN numbers. This technique also keeps customer VLAN traffic segregated from the service provider's own VLAN traffic. In the following example, frames will have an original tag of VLAN 100, which will be changed to VLAN 50 for transport over the service provider network. The VLAN number will be 100 again before the process is over, though! The dot1q tunneling steps are numbered and explained beneath the diagram.
1 -- The PC transmits a frame, which has no VLAN ID at this point. 2 -- The customer switch tags the frame with VLAN ID 100 and transports it across a dot1q trunk. So far, the normal behavior for dot1q trunking. 3 -- The service provider switch receives the frame on a tunnel port. The switch has been preconfigured to take this customer's VLAN traffic and treat it as the provider's VLAN 50. This is accomplished by placing a second VLAN tag onto the frame, this one with the service provider VLAN ID. This is why dot1q tunneling is often referred to as "q-in-q trunking". 4 -- The remote service provider switch receives this frame, and removes the tag put onto the frame by the first service provider switch. 5 -- When the remote customer switch receives the frame, the original VLAN 100 tag is the only tag that switch will see. This entire process is transparent to the customer switches. You can see where this would allow the service provider to service separate customers whose VLANs overlap. Consider this exhibit:
If Customer A and Customer B are using the same VLAN numbers, the service provider can use dot1q tunneling to resolve any potential issues. Both A and B can use VLAN 40 with no problem, because the service provider will assign the customers different VLANs for transport across the service provider network. Once the other edge service provider switch removes the new VLAN tag, the frames will be sent to the appropriate customer switches with the original VLAN 40 tag. The configuration is very simple, and needs to be configured only on the service provider switch ports that are receiving traffic from and sending traffic to the customer switches.
MLS_1(config)#int fast 0/12 MLS_1(config-if)#switchport access vlan 100 MLS_1(config-if)#switchport mode dot1qtunnel MLS_1(config-if)#vlan dot1q tag native
Note that the VLAN identified in the switchport access vlan command is the VLAN number that the customer is using. This is a great technology, but there's a limitation. (You knew that part was coming.) The service provider switches will accept CDP frames from the customer switches, but will not send them through the tunnel to the remote customer site. Worse, STP and VTP frames will not be accepted at all, giving the customer a partial (and inaccurate) picture of its network. To tunnel STP, VTP, and CDP frames across the services provider network, a Layer 2 Protocol Tunnel must be built. The following commands will be needed on all service provider edge switches. (I've used IOS Help to show you the various options.)
MLS_1(config-if)#l2protocol-tunnel ? cdp Cisco Discovery Protocol drop-threshold Set drop threshold for protocol packets point-to-point point-to-point L2 Protocol shutdown-threshold Set shutdown threshold for protocol packets stp Spanning Tree Protocol vtp Vlan Trunking Protocol <cr>
MLS_1(config-if)#l2protocol-tunnel drop-threshold ? <1-4096> Packets/sec rate beyond which protocol packets will be dropped cdp Cisco Discovery Protocol point-to-point point-to-point L2 Protocol stp Spanning Tree Protocol vtp Vlan Trunking Protocol MLS_1(config-if)#l2protocol-tunnel drop-threshold cdp ? <1-4096> Packets/sec rate beyond which protocol packets will be dropped MLS_1(config-if)#l2protocol-tunnel drop-threshold cdp 2000 ? <cr> MLS_1(config-if)#l2protocol-tunnel drop-threshold cdp 2000 MLS_1(config-if)#l2protocol-tunnel shutdown-threshold ? <1-4096> Packets/sec rate beyond which interface is put to err-disable cdp Cisco Discovery Protocol point-to-point point-to-point L2 Protocol stp Spanning Tree Protocol vtp Vlan Trunking Protocol MLS_1(config-if)#l2protocol-tunnel shutdown-threshold vtp ? <1-4096> Packets/sec rate beyond which interface is put to err-disable MLS_1(config-if)#l2protocol-tunnel shutdown-threshold vtp 4096
To avoid having their network overwhelmed with a customer's control frame traffic, the service provider can actually have frames dropped after a certain threshold of frames is reached with the drop-threshold option, and even have the port placed into err-disabled state at a certain threshold with the shutdown-threshold command. There's another method the service provider can use in this situation, Ethernet over Multiprotocol Label Switching (EoMPLS). To do so, the service provider's got to have an MPLS core to begin with, and don't worry - that configuration is very much out of the realm of the BCMSN exam. It's a good idea to know the basics of EoMPLS, though. With EoMPLS, the service provider cloud consists of two router types. The Edge Label Switch Routers (ELSR) are found at the edge of the cloud, and these routers place a MPLS tag, or label, onto incoming traffic that meets predefined criteria. Inside the cloud, Label Switch Routers (LSR) will route the traffic looking only at the MPLS label. Once the remote ELSR receives the packet, the MPLS label is removed and the data can be forwarded normally. The original VLAN value is kept intact. There's another service provider solution that's becoming more and more popular, and as a CCNP, you should know about it (if you don't already!) Transparent LAN Service is basically a LAN interconnection technology that hides the connecting WAN from the end users - that's the "transparent" part! In the following illustration, the end users are all in VLAN 100 - but it's a Virtual LAN that spans a WAN.
One drawback to TLS is that broadcasts will be treated as a broadcast on any VLAN - they'll be sent to every host in the VLAN. There's a major benefit involved if you're the client here, though, in that the service provider is responsible for all equipment and protocols used to connect your LANs. Private VLANs This may well be the ultimate in filtering VLAN traffic! Hosts can be placed into a secondary VLAN, which is going to have one of two results: The host will be able to communicate with other hosts in the secondary VLAN and with the primary VLAN, but not with hosts in other secondary VLANs - this is a community private VLAN The host can communicate with the primary VLAN, but with no other hosts, including other hosts in its own secondary VLAN -- this is an isolated private VLAN In the following example, the router is located off a switch port that has been configured as a private VLAN port. There are options here as well: The device connected to the private VLAN port can communicate with any device connected to any primary or secondary VLAN - this is promiscuous mode. This is the recommended mode for ports connected to gateway devices, such as the router seen below. The host connected to the port is on either type of private VLAN (isolated or community), and can communicate with devices found off other promiscuous ports. If the host is configured as part of a community private VLAN, the host can also communicate with other hosts in that private VLAN.
Host A has been placed into an isolated private VLAN, and will be able to communicate only with the router. The remaining hosts will be able to communicate with each other and with the router. Configuring private VLANs is not a one-step config at all - there's quite a bit to do. First, the private VLAN itself has to be configured:
MLS(config-vlan)#private-vlan ? association Configure association between private VLANs community Configure the VLAN as a community private VLAN isolated Configure the VLAN as an isolated private VLAN primary Configure the VLAN as a primary private VLAN twoway-community Configure the VLAN as a two way community private VLAN MLS(config-vlan)#private-vlan community Private VLANs can only be configured when VTP is in transparent mode MLS(config-vlan)#exit MLS(config)#vtp mode transparent Setting device to VTP TRANSPARENT mode. MLS(config)#vlan 20 MLS(config-vlan)#private-vlan community
Now here's a little detail quite a few books and documents leave out - a switch must be in VTP Transparent mode to have private VLANs. This differs from earlier IOS versions. I'd be really surprised if you saw anything to do with this on the exam, but you should know about it if you're even thinking about deploying private VLANs in the real world. Now the primary VLAN must be configured as the "associate" of the private VLAN. We'll assume VLAN 30 for that role.
MLS(config-vlan)#private-vlan association ? WORD VLAN IDs of the private VLANs to be configured add Add a VLAN to private VLAN list remove Remove a VLAN from private VLAN list MLS(config-vlan)#private-vlan association 30
The ports will now be placed into the private VLAN:
MLS(config-if)# switchport mode private-vlan 20 host
If this were the port connected to the router in the above diagram, we'd need the promiscuous option configured instead of host. Private VLANs are a little difficult to pick up at first, so hang in there. I personally like to use other forms of network security or "cloaking" to hide hosts when the time comes, but Private VLANs are out there and it's a good idea to know the basics. DHCP Snooping It may be hard to believe, but something as innocent as DHCP can be used for network attacks. The potential for trouble starts when a host sends out a DHCPDiscovery packet, it listens for DHCPOffer packets and as we know, the host will accept the first Offer it gets!
Part of that DHCPOffer is the address to which the host should set its default gateway. In this network, there's no problem, because there's only one DHCP Server. The host will receive the DHCPOffer and set its default gateway accordingly. What if a DHCP server that does not belong on our network - a rogue DHCP server - is placed on that subnet?
Now we've got a real problem, because that host is going to use the information in the first DHCPOffer packet it receives - and if the host uses the Offer from the rogue DHCP server, the host will actually set its default gateway to the rogue server's IP address! The rogue server could also have the host set its DNS server address to the rogue server's address as well. This opens the host and the network to several nasty kinds of attacks. DHCP Snooping allows the switch to serve as a firewall between hosts and untrusted DHCP servers. DHCP Snooping classifies interfaces on the switch into one of two categories - trusted and untrusted. DHCP messages received on trusted interfaces will be allowed to pass through the switch. Not only will DHCP messages received on untrusted interfaces be dropped by the switch, the interface itself will be placed into err-disabled state.
Now, you're probably asking "How does the switch determine which ports are trusted and which ports are untrusted?" By default, the switch considers all ports untrusted - which means we better remember to configure the switch to trust some ports when we enable DHCP Snooping! First, we need to enable DHCP Snooping on the entire switch:
SW1(config)#ip dhcp snooping
You must then identify the VLANs that will be using DHCP Snooping. Let's use IOS Help to look at the other options available.
SW1(config)#ip database information verify vlan <cr> dhcp DHCP DHCP DHCP DHCP snooping snooping Snooping snooping Snooping ? database agent information verify vlan
SW1(config)#ip dhcp snooping vlan ? WORD DHCP Snooping vlan fist number or vlan range, example: 1,3-5,7,9-11
Note that you can use commas and dashes to define a range of VLANs for DHCP Snooping. We'll create three VLANs on this switch and then enable DHCP Snooping only for VLAN 4.
SW1(config)#int fast 0/2 SW1(config-if)#switchport mode access SW1(config-if)#switchport access vlan 2 % Access VLAN does not exist. Creating vlan 2
SW1(config-if)#int fast 0/3 SW1(config-if)#switchport mode access SW1(config-if)#switchport access vlan 3 % Access VLAN does not exist. Creating vlan 3
SW1(config-if)#int fast 0/4 SW1(config-if)#switchport mode access SW1(config-if)#switchport access vlan 4 % Access VLAN does not exist. Creating vlan 4 SW1(config)#ip dhcp snooping vlan 4
Assuming we have a trusted DHCP server off port 0/10, we would then trust that port with the following command:
SW1(config-if)#ip dhcp snooping trust
From your previous studies, you're familiar with the DHCP Relay Agent Information option. Usually referred to as Option 82 (we still don't know what happened to the first 81 options), this option can be disabled or enabled with the following command:
SW1(config)#ip dhcp snooping information option
DHCP Snooping is verified with the show ip dhcp snooping command.

SW1#show ip dhcp snooping Switch DHCP snooping is enabled DHCP snooping is configured on following VLANs: 4 Insertion of option 82 is enabled circuit-id format: vlan-mod-port remote-id format: MAC Option 82 on untrusted port is not allowed Verification of hwaddr field is enabled Interface Trusted Rate limit (pps) --------------------------------------------FastEthernet0/10 yes unlimited
The key information here, from top to bottom: DHCP Snooping is enabled on the switch VLAN 4 is the only VLAN using DHCP Snooping Option 82 is enabled, but not allowed on untrusted ports The only trusted port is fast 0/10 Note the "rate limit" for the untrusted port is set to "unlimited". That rate limit refers to the number of DHCP packets the interface can accept in one second (packets per second).
Dynamic ARP Inspection Just as we must protect against rogue DHCP servers, we have to be wary of rogue ARP users as well. From your CCNA studies, you know all about Address Resolution Protocol and how it operates. A rogue device can overhear part of the ARP process in action and make itself look like a legitimate part of the network. This happens through ARP Cache Poisoning. (This is also known as ARP Spoofing - be aware of both names for your exam.) ARP Cache Poisoning starts innocently enough - in this case, through the basic ARP process on a switch.
Host A is sending an ARP Request, requesting the host with the IP address 172.12.12.2 to respond with its MAC Address. Host B will receive the request, but before responding, Host B will make an entry in its local ARP cache mapping the IP address 172.12.12.1 to the MAC address aa-aa-aa-aa-aa-aa. Once Host A receives that ARP Reply, both hosts will have a MAC address - IP address mapping for the remote host.
The problem comes in if a rogue host responds to the original ARP Request with its own MAC address.
Now Host A will make an entry in its ARP cache mapping the IP address 172.12.12.2 to cc-cc-cc-cc-cc-cc. Meanwhile, the rogue host will acquire Host B's true MAC address via ARP, which leads to this process:
1.
2.
When Host A transmits data to the IP address 172.12.12.2 with a MAC address of cc-cc-cc-cc-cc-cc, the data is actually being received by the rogue host. The rogue host will read the data and then possibly forward it to Host B, so neither Host A nor Host B immediately notices anything wrong.
The rogue host has effectively placed itself into the middle of the communication, leading to the term man in the middle for this kind of network attack. When the rogue host does the same for an ARP Request being sent from Host B to Host A, all communications between Host A and Host B will actually be going through the rogue host. Enabling Dynamic ARP Inspection (DAI) prevents this behavior by building a database of trusted MAC-IP address mappings. This database is the same database that is built by the DHCP Snooping process, and static ARP configurations can be used by DAI as well. DAI uses the concept of trusted and untrusted ports, just as DHCP Snooping does. However, untrusted ports in DAI do not automatically drop ARP Requests and Replies. Once the IP-MAC address database is built, every single ARP Request and ARP Reply received on an untrusted interface is examined. If the ARP message has an approved MAC-IP address mapping, the message is forwarded appropriately; if not, the ARP message is dropped. If the interface has been configured as trusted, DAI allows the ARP message to pass through without checking the database of trusted mappings. DAI is performed as ARP messages are received, not transmitted. Since DAI uses entries in the DHCP Snooping database to do its job, DHCP Snooping must be enabled before beginning to configure DAI. After that, the first step in configuring DAI is to name the VLAN(s) that will be using DAI.
SW1(config)#ip arp inspection ? filter Specify ARP acl to be applied log-buffer Log Buffer Configuration validate Validate addresses vlan Enable/Disable ARP Inspection on vlans SW1(config)#ip arp inspection vlan ? WORD vlan range, example: 1,3-5,7,9-11 SW1(config)#ip arp inspection vlan 4
Just as with DHCP Snooping, you can specify a range of VLANs with hyphens and commas. Also just as with DHCP Snooping, all ports are considered untrusted until we tell the switch to trust them, and we do that with the ip arp inspection trust interface-level command.
SW1(config)#int fast 0/4 SW1(config-if)#ip arp inspection trust
You may have noticed a validate option in the ip arp inspection command above. You can use the validate option to go beyond DAI's default inspection. Let's use IOS Help to take a look at our choices:
SW1(config)#ip arp inspection validate ? dst-mac Validate destination MAC address ip Validate IP addresses src-mac Validate source MAC address
You can actually specify validation of more than one of those addresses. Here's what happens with each: "src-mac" compares the source MAC address in the Ethernet header and the MAC address of the source of the ARP message. "dst-mac" compares the destination MAC address in the Ethernet header and the MAC destination address of the ARP message. "ip" compares the IP address of the sender of the ARP Request against the destination address of the ARP Reply. We'll use the "ip" option and then verify the configuration with show ip arp inspection.
SW1(config)#ip arp inspection validate ip SW1#show ip arp inspection Source Mac Validation : Disabled Destination Mac Validation : Disabled IP Address Validation : Enabled Vlan ---4 Vlan ---4 Vlan ---4 Vlan ---4 Vlan ---Vlan ---4 Configuration ------------Enabled ACL Logging ----------Deny Forwarded --------0 DHCP Permits -----------0 Operation --------Active DHCP Logging -----------Deny Dropped ------0 ACL Permits ----------0 DHCP Drops ---------0 ACL Drops --------0 ACL Match --------Static ACL ----------
Source MAC Failures ------------------0 Invalid Protocol Data --------------------Invalid Protocol Data --------------------0
Dest MAC Failures ----------------Dest MAC Failures ----------------0
IP Validation Failures ---------------------IP Validation Failures ---------------------0
That show command results in a great deal of output, but as you apply DAI in your network, you should run this command regularly to spot potential rogue hosts on your network. A large number of validation failures is one indicator of such a rogue! If you run DAI in your network, most likely you'll run it on all of your switches. Cisco's recommended trusted/untrusted port configuration is to have all ports connected to hosts run as untrusted and all ports connected
to switches as trusted. Since DAI runs only on ingress ports, this configuration scheme ensures that every ARP packet is checked once, but no more than that. There is no problem with running DAI on trunk ports or ports bundled into an Etherchannel.
IP Source Guard We can use IP Source Guard to prevent a host on the network from using another host's IP address. IP Source Guard works in tandem with DHCP Snooping, and uses the DHCP Snooping database to carry out this operation. As with DAI, DHCP Snooping must be enabled before enabling IP Source Guard. When the host first comes online and connects to an untrusted port on the switch, the only traffic that can reach that host are DHCP packets. When the client successfully acquires an IP address from the DHCP Server, the switch makes a note of this IP address assignment.
The switch will then dynamically create an ACL that will only allow traffic with the corresponding source IP address to be processed by the switch.
If the host pretends to be another host on that subnet, or to spoof that host's IP address -- 172.12.12.100, for example -- the switch will simply filter that traffic because the source IP address will not match the database's entry for that port.
MAC Address Flooding Attacks Since ARP, IP addresses, and DHCP all have potential security issues, we can't leave MAC addresses out - because network attackers sure won't do so! A MAC Address Flooding attack is an attempt by a network intruder to overwhelm the switch memory reserved for maintenance of the MAC address table. The intruder generates a large number of frames with different source MAC addresses - all of them invalid. As the switch's MAC address table capabilities are exhausted, valid entries cannot be made and this results in those valid frames being broadcast instead of unicast. This has three side effects, all unpleasant: As mentioned, the MAC address table fills to capacity, preventing legitimate entries from being made. The large number of unnecessary broadcasts quickly consumes bandwidth as well as overall switch resources The intruder can easily intercept packets with a packet sniffer, since the unnecessarily broadcasted packets will be sent out every port on the switch - including the port the intruder is using. You can combat MAC Address Flooding with two of the features we addresses earlier in this section - port-based authentication and port security. By making sure our host devices are indeed who we think they are, we reduce the potential for an intruder to unleash a MAC Address Flooding attack on our network. The key isn't to fight the intruder once they're in our network - the key is to keep them out in the first place.
VLAN Hopping We've seen how intruders can use seemingly innocent ARP and DHCP processes can be used to harm our network, so it shouldn't come as any surprise that Dot1q tagging can be used against us as well! One form of VLAN Hopping is double tagging, so named because the intruder will transmit frames that are "double tagged" with two separate VLAN IDs. As you'll see in our example, certain circumstances must exist for a double tagging attack to be successful: The intruder's host device must be attached to an access port. The VLAN used by that access port must be the native VLAN. The term "native VLAN" tips us off to the third requirement - dot1q must be the trunking protocol in use, since ISL doesn't use the native VLAN.
When the rogue host transmits a frame, that frame will have two tags. One will indicate native VLAN membership, and the second will be the number of the VLAN under attack. In this example, we'll assume that to be VLAN 100.
The trunk receiving this double-tagged frame will see the tag for VLAN 25, and since that's the native VLAN, that tag will be removed and then transmitted across the trunk - but the tag for VLAN 100 is still there!
When the switch on the other side of the trunk gets that frame, it sees the tag for VLAN 100 and forwards the frame to ports in that VLAN. The rogue now has successfully fooled the switches and has hopped from one
VLAN to another. VLAN Hopping seems innocent enough, but it's quite the opposite. VLAN Hopping has been used for network attacks ranging from Trojan horse virus propagation to stealing bank account numbers and passwords. That's why you often see the native VLAN of a network such as the one above set to a VLAN that no host on the network is a member of - that stops this version of VLAN Hopping right in its tracks.
Notice that I said "this version". Switch spoofing is another variation of VLAN Hopping that is even worse than double tagging, because this version allows the rogue to pretend to be a member of *all* VLANs in your network. Many Cisco switch ports now run in dynamic desirable mode by default, which means that a port is sending out Dynamic Trunking Protocol frames in an aggressive effort to form a trunk. A potential problem exists, since the switch doesn't really know what kind of device is receiving the DTP frames.
This leads many well-intentioned network admins to place such a port into Auto mode, which means that port will still trunk but it's not actively seeking to do so. That in turn leads to another major potential problem, because a rogue host connected to a port in Auto trunking mode can pretend it's a switch and send DTP frames of its own - leading to a trunk formed between the switch and the rogue host!
When that trunk forms, the rogue host will have access to all VLANs after all, this is now a trunk! Luckily, there's a quick defense for this attack. Every port on your switch that does not lead to another known switch should be placed into access mode. That disables the port's ability to create a trunk, and in turn disables the rogue host's ability to spoof being a switch!

Multilayer Switching And Fault Tolerance

Overview
What Is Multilayer Switching? Route Caching Cisco Express Forwarding Inter-VLAN Routing Switched Virtual Interfaces (SVIs) Fallback Bridging ICMP Router Discovery Protocol (IRDP) HSRP Basics HSRP MAC Address Changing HSRP Changing The Active Router HSRP Load Balancing HSRP Interface Tracking Virtual Router Redundancy Protocol (VRRP) Gateway Load Balancing Protocol (GLBP) Server Load Balancing (SLB)
When you're learning basic routing and switching theory in your CCNA studies, the two processes are taught as separate operations that happen on two separate physical devices. While they are separate operations, devices that can perform both routing and switching are more and more popular today. These devices are Layer 3 switches, or multilayer switches. Redundancy is key in today's networks, and Cisco routers and L3 switches offer no fewer than four different schemes for gateway redundancy. We'll examine each in detail, because success on your exam as well as today's production networks depends upon your knowledge of these protocols and schemes.
What Is Multilayer Switching? Multilayer switches are devices that switch and route packets in the switch hardware itself. A good phrase to describe a multilayer switch is "pure performance" - these switches can perform packet switching up to ten times as fast as a pure L3 router. When it comes to Cisco Catalyst switches, this hardware switching is performed by a router processor (or L3 engine). This processor must download routing information to the hardware itself. To make this hardware-based packet processing happen, Cat switches will run either the older....um, I mean "legacy" Multilayer Switching (MLS), or the newer Cisco Express Forwarding (CEF). Application-Specific Integrated Circuits (ASICs) will perform the L2 rewriting operation of these packets. You know from your CCNA studies that while the IP source and destination address of a packet will not change during its travels through the network, the L2 source and addresses may and probably will. With multilayer switching, it's the ASICs that perform this L2 address overwriting. Multilayer Switching Methods The first multilayer switching (MLS) method is route caching. This method may be more familiar to you as NetFlow switching. Route caching devices have both a routing processor and a switching engine. The routing processor routes a flow's first packet, the switching engine snoops in on that packet and the destination, and the switching engine takes over and forwards the rest of the packets in that flow. Now, what exactly does a "flow" consist of? A flow is a unidirectional stream of packets from a source to a destination, and packets on the same flow will share the same protocol. That is, if a source is sending both WWW and TFTP packets to the same destination, there are actually two flows of traffic. The MLS cache entries support such unidirectional flows. There's always room for improvement from the first implementation of anything, though, and that improvement is Cisco Express Forwarding. Cisco Express Forwarding (CEF) is a highly popular method of multilayer switching. Primarily designed for backbone switches, this topology-based switching method requires special hardware, so it's not available on all L3 switches. CEF can't be configured on 2950 switches, but you will see it on 3550s and several other higher-numbered series. CEF is highly scalable, and is also easier on a switch's CPU than route caching. CEF has two major components - the Forwarding Information Base and the Adjacency Table. CEF-enabled devices the same routing information that a router would, but it's not found in a typical routing table. CEF-enabled switches keep a Forwarding Information Base (FIB) that contains the usual routing information - the destination networks, their masks, the next-hop IP
addresses, etc - and CEF will use the FIB to make L3 prefix-based decisions. The FIB's contents will mirror that of the IP routing table - actually, the FIB is really just the IP routing table in another format. You can view the FIB with the show ip cef command.
SW2#show ip cef Prefix 0.0.0.0/32 224.0.0.0/4 224.0.0.0/24 255.255.255.255/32 Next Hop receive drop receive receive Interface
Not exactly the routing table we've come to know and love! However, running CEF doesn't prevent us from configuring access-lists, QoS, or other "regular" traffic filtering features that routers use every day. The routing information in the FIB is updated dynamically as change notifications are received from the L3 engine. Since the FIB is prepopulated with the information from the routing table, the MLS can find the routing information quickly. The FIB takes care of the L3 routing information, but what of the L2 information we need? That's found in the Adjacency Table (AT). As adjacent hosts are discovered via ARP, that next-hop L2 information is kept in this table for CEF switching. Once the appropriate L3 and L2 next-hop addresses have been found, the MLS is just about ready to forward the packet. The MLS will make the same changes to the packet as a router normally would, and that includes changing the L2 destination MAC address - that's going to be changed to the next-hop destination, as I'm sure you remember from your CCNA studies. The L3 destination will remain the same. (The L2 source address will change as well, to the MAC address on the MLS switch interface that transmits the packet.) Enabling CEF is about as simple as it gets. CEF is on by default on any and all CEF-enabled switches, and you can't turn it off. Remember, CEF is hardware-based, not software-based, so it's not a situation where running "no cef" on a switch will disable CEF. There's no such command! A multilayer switch must have IP routing enabled for CEF to run, however. Trying to view the FIB of a switch with IP routing not enabled results in this console readout...
SW2#show ip cef %IPv4 CEF not running
... and then after enabling IP routing.

SW2(config)#ip routing SW2#show ip cef Prefix 0.0.0.0/32 224.0.0.0/4 224.0.0.0/24 255.255.255.255/32
Next Hop receive drop receive receive
Interface
As with several advanced L3 switching capabilities, not every L3 switch
can run CEF. For instance, the 2900XL and 3500XL do not support CEF. Keep in mind that switches that do support CEF do so by default, and CEF can't be turned off on those switches! CEF does support per-packet and per-destination load balancing, but again does not do so on all multilayer switches. Be sure to check your switch's capabilities before purchasing. The Control Plane And The Data Plane These are both logical planes found in CEF multilayer switching, and I know you won't be surprised to find they are also referred to by several different names. These all refer to the control plane: "CEF control plane" "control plane" "Layer 3 engine" or "Layer 3 forwarding engine" The control plane's job is to first build the ARP and IP routing tables, which makes the FIB and AT creation possible. In turn, the data plane is also called by several different names: "data plane" "hardware engine" "ASIC" The control plane builds the tables necessary for L3 switching, but it's the data plane that does the actual work! It's the data plane that places data in the L3 switch's memory while the FIB and AT tables are consulted, and then performs any necessary encapsulation before forwarding the data to the next hop. Exceptions To The Rule (Of L3 Switching, That Is) Exception packets are packets that cannot be hardware switched, which leaves us only one option - software switching! Comparing hardware switching to software switching is much like comparing the hare to the tortoise - but these tortoises are not going to win a race. Here are just a few of the packet types that must be software switched: Packets with IP header options Packets that will be fragmented before transmission (because they're exceeding the MTU) 802.3 Ethernet packets Note that packets with TCP header options are still switched in hardware; it's the IP header options that cause trouble! Is "Fast Switching" Really That Fast? With so many switching options available today, it's hard to keep up with which option is fastest, then next-fastest, and so on. According to Cisco's website, here's the order;
1. Distributed CEF (DCEF). The name is the recipe - the CEF workload is distributed over multiple CPUs. 2. CEF 3. Fast Switching 4. Process Switching
Inter-VLAN Routing Since you learned in your CCNA studies that switching only happens on switches and routing only happens on routers, you also learned that a router has to get involved for inter-VLAN communication. Configuring router-on-a-stick is one way to get inter-VLAN communication going, and it requires only a single physical connection from the router to the switch. (The port on the router needs to be a FastEthernet port, remember.) Having configured router-on-a-stick many times, I can tell you that it works beautifully, but it does have its drawbacks. Depending on how many VLANs are involved in this configuration, they may not get all the bandwidth they need. Router-on-a-stick does put an extra load on the router's processor as well, so you have to be careful as to which router in your network you select for this job. The biggest concern I have personally with ROAS is that the router becomes a single point of failure. If that FastEthernet port goes down, that's the end of your inter-VLAN traffic. Bringing an external router into the picture is one method of configuring inter-VLAN traffic, but we also have the option of using a switch with an internal route processor or Route Switch Module (RSM). For example, a Catalyst 5000 switch's RSM takes the place of an external router - no router-on-a-stick needed! Multilayer switches allow us to create a logical interface that represents the VLAN. Remember that the L2 switches you've worked with have an "interface VLAN1" by default? That's actually a switched virtual interface (SVI). An SVI exists for VLAN 1 by default, but that's the only VLAN that has a "pre-created" SVI. On an MLS, such a logical interface can be configured for any VLAN.
MLS(config)#interface vlan 10 MLS(config-if)#ip address 10.1.1.1 255.255.255.0
Let's put SVIs to work with a basic interVLAN routing configuration.
To allow these two hosts to communicate, you know that we've got to have an L3 device - and now we have a different kind of L3 device than you've used before. This L3 switch will allow interVLAN communication without involving a router. Before we begin configuring, we'll send pings between the two hosts. (In this example, I'm using routers for hosts, but there are no routes of any kind on them.)
HOST_1#ping 30.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) HOST_3#ping 20.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
As expected, neither host can ping the other. Let's fix that! To get started, we'll put the port leading to Host 1 into VLAN 11, and the port leading to Host 3 in VLAN 33.
SW1(config)#int fast 0/1 SW1(config-if)#switchport mode access SW1(config-if)#switchport access vlan 11
We're going to create two SVIs on the switch, one representing VLAN 11 and the other representing VLAN 33. Note that both SVIs show as up/up immediately after creation. Some Cisco and non-Cisco documentation mentions that you should open the SVIs after creating them, but that's not necessarily the case in the real world. Couldn't hurt, though. :)
SW1(config)#int vlan11 01:30:04: %LINK-3-UPDOWN: Interface Vlan11, changed state to up 01:30:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan11, changed state to up SW1(config-if)#ip address 20.1.1.11 255.255.255.0
SW1(config-if)#int vlan33 01:30:11: %LINK-3-UPDOWN: Interface Vlan33, changed state to up 01:30:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan33, changed state to up SW1(config-if)#ip address 30.1.1.11 255.255.255.0
Verify the SVIs with show interface vlan. I'll only show the top three rows
of output for each SVI.

SW1#show int vlan11 Vlan11 is up, line protocol is up Hardware is EtherSVI, address is 0012.7f02.4b41 (bia 0012.7f02.4b41) Internet address is 20.1.1.11/24 SW1#show int vlan33 Vlan33 is up, line protocol is up Hardware is EtherSVI, address is 0012.7f02.4b42 (bia 0012.7f02.4b42) Internet address is 30.1.1.11/24
Now let's check that routing table...

SW1# show ip route Default gateway is not set Host Gateway ICMP redirect cache is empty Last Use Total Uses Interface
Hmm, that's not good. We don't have one! There's a simple reason, though - on L3 switches, we need to enable IP routing, because it's off by default! Step One In L3 Switching Troubleshooting: Make Sure IP Routing Is On!
SW1(config)#ip routing SW1(config)#^Z SW1#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 20.0.0.0/24 is subnetted, 1 subnets 20.1.1.0 is directly connected, Vlan11 30.0.0.0/24 is subnetted, 1 subnets C 30.1.1.0 is directly connected, Vlan33 C
Now that looks like the routing table we've come to know and love! In this particular case, there's no need to configuring a routing protocol. You recall from your CCNA studies that when router-on-a-stick is configured, the IP address assigned to the router's subinterfaces should be the default gateway setting on the hosts. When SVIs are in use, the default gateway set on the hosts should be the IP address assigned to the SVI that represents that host's VLAN. After setting this default gateway on the hosts, the hosts can now successfully communicate. Since we're using routers for hosts, we'll use the ip route command to set the default gateway.
HOST_1(config)#ip route 0.0.0.0 0.0.0.0 20.1.1.11 HOST_3(config)#ip route 0.0.0.0 0.0.0.0 30.1.1.11
Can the hosts now communicate, even though they're in different VLANs?
HOST_1#ping 30.1.1.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms HOST_3#ping 20.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Ports on multilayer switches can also be configured as routing ports, and have IP addresses assigned directly to them. If we add a router to our network as shown below, that's what we'll need to do.
Remember, the ports on a multilayer switch will all be running in L2 mode by default. To configure a port as a routing port, use the no switchport command, followed by the appropriate IP address. Note that in the following configuration, the line protocol on the switch port goes down and comes back up in just a few seconds.
SW1(config)#interface fast 0/5 SW1(config-if)#no switchport 02:19:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down 02:19:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to up SW1(config-if)#ip address 210.1.1.11 255.255.255.0
We verify the IP address assignment with show int fast 0/5.

SW1#show int fast 0/5 FastEthernet0/5 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0012.7f02.4b43 (bia 0012.7f02.4b43) Internet address is 210.1.1.5/24
The switch can now ping 210.1.1.1, the downstream router.

SW1#ping 210.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms Now let's take this just one step further - what if we wanted the hosts in the VLANs to be able to communicate with the router? They can ping 210.1.1.11, the switch's interface in that subnet, but not 210.1.1.1, the router's interface. HOST_1#ping 210.1.1.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
The router has no path to either 20.1.1.0 /24 or 30.1.1.0/24, so there's no way for the pings to get back to Host 1 or Host 3.
ROUTER_TO_INTERNET#show ip route < code table removed for clarity > Gateway of last resort is not set C 210.1.1.0/24 is directly connected, FastEthernet0/0
To remedy that, we'll now configure a dynamic routing protocol between the L3 switch and the router. We'll use EIGRP in this case.
SW1(config)#router eigrp 100 SW1(config-router)#no auto-summary SW1(config-router)#network 210.1.1.0 0.0.0.255 SW1(config-router)#network 20.1.1.0 0.0.0.255 SW1(config-router)#network 30.1.1.0 0.0.0.255 ROUTER_TO_INTERNET(config)#router eigrp 100 ROUTER_TO_INTERNET(config-router)#no auto-summary ROUTER_TO_INTERNET(config-router)#network 210.1.1.0 0.0.0.255
The router now has the VLAN subnets in its routing table...
ROUTER_TO_INTERNET#show ip route < code table removed for clarity >
Gateway of last resort is not set 20.0.0.0/24 is subnetted, 1 subnets 20.1.1.0 [90/28416] via 210.1.1.11, 00:01:01, FastEthernet0/0 210.1.1.0/24 is directly connected, FastEthernet0/0 30.0.0.0/24 is subnetted, 1 subnets 30.1.1.0 [90/28416] via 210.1.1.11, 00:01:01, FastEthernet0/0
D C D
... and the hosts now have two-way IP connectivity with the router's 210.1.1.1 interface.
HOST_1#ping 210.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms HOST_3#ping 210.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
It never hurts to make sure the pings can go the other way, too!
ROUTER_TO_INTERNET#ping 20.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
ROUTER_TO_INTERNET#ping 30.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
As you've seen, the choice of using SVIs and/or routed ports depends on what devices are on the other end of the connection. You've also seen that even a relatively simply network topology can require the use of both! As always, there are some simple but important details to keep in mind when configuring SVIs. You need to create the VLAN before the SVI, and that VLAN must be active at the time of SVI creation Theoretically, you need to open the SVI with no shut just as you would open a physical interface after configuring an IP address Remember that the VLAN and SVI work together, but they're not the same thing. Creating a VLAN doesn't create an SVI, and creating an SVI doesn't create a VLAN. Fallback Bridging Odds are that you'll never need to configure fallback bridging, but it falls under the category of "it couldn't hurt to know it". CEF has a limitation in that IPX, SNA, LAT, and AppleTalk are either not supported by CEF or, in the case of SNA and LAT, are nonroutable protocols. If you're running any of these on an CEF-enabled switch, you'll need fallback bridging to get this traffic from one VLAN to another. Fallback bridging involves the creation of bridge groups, and the SVIs will have to be added to these bridge groups. To create a bridge group:
MLS(config)# bridge-group 1
To join a SVI to a bridge group:

MLS(config)#interface vlan 10 MLS(config-if)#bridge-group 1
Router Redundancy Techniques In networking, we'll take as much redundancy as we can get. If a router goes down, we've obviously got real problems. Hosts are relying on that router as a gateway to send packets to remote networks. For true network redundancy, we need two things: A secondary router to handle the load when the primary goes down A protocol to get the networks using that secondary protocol as soon as possible That second point is so important that Cisco currently offers four separate
protocols to expedite the cutover to the secondary router. These methods have much the same end result, but how they get there is another story. It's a story you can expect to be asked about quite a bit on your exam, so let's get to work and hit the details of these four redundancy strategies. ICMP Router Discovery Protocol Defined in RFC 1256, IRDP is commonly used by Windows DHCP clients and several Unix variations, but you do see it in Cisco routers as well. IRDP is an extension of ICMP - after all, it is the ICMP Router Discovery Protocol! IRDP routers will generate Router Advertisement packets that will be heard by hosts on that segment. If a host hears from more than one IRDP router, it will choose one as its primary and will start using the other router if the primary goes down. In the following example, the PCs will choose either 172.12.1.1 or 172.12.1.2 as their default gateway.
IRDP is the only router redundancy protocol that does not involve a virtual router of some kind - when hosts transmit data, they will be using the IP and MAC address of a real, physical router as the default gateway, not the IP and MAC address of a virtual router. Hosts may also generate Router Solicitation messages, usually at startup, asking IRDP routers to send Router Advertisement packets. To enable IRDP on a router's interface, just use the ip irdp command.
MLS(config)# interface serial0 MLS(config-if)# ip irdp
Hot Standby Routing Protocol Defined in RFC 2281, HSRP is a Cisco-proprietary protocol in which routers are put into an HSRP router group. Along with dynamic routing protocols and STP, HSRP is considered a high-availability network service, since all three have an almost immediate cutover to a secondary path when the primary path is unavailable. One of the routers will be selected as the primary, and that primary will handle the routing while the other routers are in standby, ready to handle
the load if the primary router becomes unavailable. In this fashion, HSRP ensures a high network uptime, since it routes IP traffic without relying on a single router. The hosts using HSRP as a gateway don't know the actual IP or MAC addresses of the routers in the group. They're communicating with a pseudorouter, a "virtual router" created by the HSRP configuration. This virtual router will have a virtual MAC and IP address as well. The standby routers aren't just going to be sitting there, though! By configuring multiple HSRP groups on a single interface, HSRP load balancing can be achieved. Before we get to the more advanced HSRP configuration, we better get a basic one started! We'll be using a two-router topology here, and keep in mind that one or both of these routers could be multilayer switches as well. For ease of reading, I'm going to refer to them only as routers.
R2 and R3 will both be configured to be in standby group 5. The virtual router will have an IP address of 172.12.23.10 /24. All hosts in VLAN 100 should use this address as their default gateway.
R2(config)#interface ethernet0 R2(config-if)#standby 5 ip 172.12.23.10 R3(config)#interface ethernet0 R3(config-if)#standby 5 ip 172.12.23.10
The show command for HSRP is show standby, and it's the first command you should run while configuring and troubleshooting HSRP. Let's run it on both routers and compare results.
R2#show standby Ethernet0 - Group 5 Local state is Standby, priority 100 Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.776 Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 9.568 Standby router is local 1 state changes, last state change 00:00:22 R3#show standby Ethernet0 - Group 5 Local state is Active, priority 100 Hellotime 3 sec, holdtime 10 sec Next hello sent in 2.592 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.2 expires in 8.020 Virtual mac address is 0000.0c07.ac05 2 state changes, last state change 00:02:08
R3 is in Active state, while R2 is in Standby. The hosts are using the 172.12.123.10 address as their gateway, but R3 is actually handling the workload. R2 will take over if R3 becomes unavailable. An IP address was assigned to the virtual router, but not a MAC address. However, there is a MAC address under the show standby output on R3, the active router. How did the HSRP process arrive at a MAC of 00-000c-07-ac-05? Well, most of the work is already done before the configuration is even begun. The MAC address 00-00-0c-07-ac-xx is HSRP's well-known virtual MAC address, and xx is the group number in hexadecimal. That's a good skill to have for the exam, so make sure you're comfortable with hex conversions. In this example, the group number is 5, which is expressed as 05 with a two-bit hex character. If the group number had been 17, we'd see 11 at the end of the MAC address - one unit of 16, one unit of 1. The output of the show standby command also tells us that the HSRP speakers are sending Hellos every 3 seconds, with a 10-second holdtime. These values can be changed with the standby command, but HSRP speakers in the same group should have the same timers. You can even tie down the hello time to the millisecond, but it's doubtful you'll ever need to do that.
R3(config-if)#standby 5 timers ? <1-254> Hello interval in seconds msec Specify hello interval in milliseconds R3(config-if)#standby 5 timers 4 ? <5-255> Hold time in seconds R3(config-if)#standby 5 timers 4 12
Another key value in the show standby command is the priority. The default is 100, as shown in both of the above show standby outputs. The router with the highest priority will be the primary HSRP router, with the router with the highest IP address on an HSRP-enabled interface becoming the primary if there is a tie on priority. We'll raise the default priority on R2 and see the results.
R2(config)#interface ethernet0 R2(config-if)#standby 5 priority 150 R2#show standby Ethernet0 - Group 5 Local state is Standby, priority 150
Hellotime 4 sec, holdtime 12 sec Next hello sent in 0.896 Virtual IP address is 172.12.23.10 configured Active router is 172.12.23.3, priority 100 expires in 8.072 Standby router is local 1 state changes, last state change 00:14:24
R2 now has a higher priority, but R3 is still the active router. R2 will not take over as the HSRP primary until R3 goes down - OR the preempt option is configured on R2.
R2(config-if)#standby 5 priority 150 preempt 1d11h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Standby -> Active R2#show standby Ethernet0 - Group 5 Local state is Active, priority 150, may preempt Hellotime 4 sec, holdtime 12 sec Next hello sent in 1.844 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.3 expires in 10.204 Virtual mac address is 0000.0c07.ac05 2 state changes, last state change 00:00:13
In just a few seconds, a message appears that the local state has changed from standby to active. Show standby confirms that R2, the local router, is now the active router - the primary. R3 is now the standby. So if anyone tells you that you have to take a router down to change the Active router, they're wrong - you just have to use the preempt option on the standby priority command. What you do not have to do is configure the preempt command if you want the standby to take over as the active router if the current active router goes down. That's the default behavior of HSRP. The preempt command is strictly intended to allow a router to take over as the active router without the current active router going down. On rare occasions, you may have to change the MAC address assigned to the virtual router. This is done with the standby mac-address command. Just make sure you're not duplicating a MAC address that's already on your network!
R2(config-if)#standby 5 mac-address 0000.1111.2222
1d12h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Active -> Learn R2#show standby Ethernet0 - Group 5 Local state is Active, priority 150, may preempt Hellotime 4 sec, holdtime 12 sec Next hello sent in 3.476 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.3 expires in 10.204 Virtual mac address is 0000.1111.2222 configured 4 state changes, last state change 00:00:00 1d12h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Listen -> Active
The MAC address will take a few seconds to change, and the HSRP routers will go into Learn state for that time period.
A real-world HSRP troubleshooting note: If you see constant state changes with your HSRP configuration, do what you should always do when troubleshooting - check the physical layer first. We can do some load balancing with HSRP, but it's not quite the load balancing you've learned about with some dynamic protocols. Let's say we have six hosts and two separate HSRP devices. For HSRP load balancing, there will be two HSRP groups created for the one VLAN. R2 will be the primary for Group 1 and R3 will be the primary for Group 2. (In production networks, you'll need to check the documentation for your software, because not all hardware platforms support multiple groups.) R2 is the Active for Group 1, which has a Virtual IP address of 172.12.23.11 /24. R3 is the Active for Group 2, which has a Virtual IP address of 172.12.23.12 /24. The key to load balancing with HSRP is to configure half of the hosts to use .11 as their gateway, and the remaining hosts should use .12.
This is not true "load balancing", and if the hosts using .11 as their gateway are sending much more traffic than the hosts using .12, HSRP has no dynamic method of adapting. HSRP was really designed for redundancy, not load balancing, but there's no use in letting the standby router just sit there! Some other HSRP notes: HSRP updates can be authenticated by using the standby command with the authentication option.
R2(config-if)#standby 5 ? authentication Authentication ip Enable HSRP and set the virtual IP address mac-address Virtual MAC address name Redundancy name string preempt Overthrow lower priority designated routers priority Priority level timers Hello and hold timers track Priority tracking
If you're configuring HSRP on a multilayer switch, you can configure HSRP on routed ports, SVIs, and Layer 3 port-channels (an Etherchannel with an IP address). HSRP requires the Enhanced Multilayer Software Image (EMI) to run on an L3 switch. Gig Ethernet switches will have that image, but Fast Ethernet switches will have either the EMI or Standard Multilayer Image (SMI). Check your documentation. The SMI can be upgraded to the EMI. Not for free, though! HSRP can run on Ethernet, Token Ring, and FDDI LANs. Some HSRP documentation states that Token Ring interfaces can support a maximum of three HSRP groups. You saw several HSRP states in this example, but not all of them. Here they are, presented in order and with a quick description. Disabled - Some HSRP documentation lists this as a state, others do not. I don't consider it one, but Cisco may. Disabled means that the interface isn't running HSRP yet. Initial (Init) -- The router goes into this state when an HSRP-enabled interface first comes up. HSRP is not yet running on a router in Initial state. Learn -- At this point, the router has a lot to learn! A router in this state has not yet heard from the active router, does not yet know which router is the active router, and it doesn't know the IP address of that router, either. Other than that, it's pretty bright. ;) Listen -- The router now knows the virtual IP address, but is not the primary or the standby router. It's listening for hello packets from those routers. Speak -- The router is now sending Hello messages and is active in the election of the primary and standby routers. Standby -- The router is now a candidate to become the active router, and sends Hello messages. Active -- The router is now forwarding packets sent to the group's virtual IP address. Note that an HSRP router doesn't send Hellos until it reaches the Speak state. It will continue to send Hellos in the Standby and Active states as well. There's also no problem with configuring an interface to participate in multiple HSRP groups on most Cisco routers. Some 2500, 3000, and 4000 routers do not have this capability. Always verify with show standby, and note that this command indicates that there's a problem with one of the virtual IP addresses!
R1#show standby FastEthernet0/0 - Group 1 State is Listen Virtual IP address is 172.12.23.10 Active virtual MAC address is unknown
Local virtual MAC address is 0000.0c07.ac01 (v1 default) Hello time 3 sec, hold time 10 sec Preemption disabled Active router is unknown Standby router is unknown Priority 100 (default 100) IP redundancy name is "hsrp-Fa0/0-1" (default) FastEthernet0/0 - Group 5 State is Init (virtual IP in wrong subnet) Virtual IP address is 172.12.34.10 (wrong subnet for this interface) Active virtual MAC address is unknown Local virtual MAC address is 0000.0c07.ac05 (v1 default) Hello time 3 sec, hold time 10 sec Preemption disabled Active router is unknown Standby router is unknown Priority 100 (default 100) IP redundancy name is "hsrp-Fa0/0-5" (default)
HSRP Interface Tracking Using interface tracking can be a little tricky at first, but it's a feature that can really come in handy. Basically, this feature enables the HSRP process to monitor an additional interface; the status of this interface will dynamically change the HSRP priority for a specified group. When that interface's line protocol shows as "down", the HSRP priority of the router is reduced. This can lead to another HSRP router on the network becoming the active router - but that other router must be configured with the preempt option. In the following network, R2 is the primary due to its priority of 105. R3 has the default priority of 100. R2 will therefore be handling all the traffic sent to the virtual router's IP address of 172.12.23.10. That's fine, but there is a potential single point of failure. If R2's Serial0 interface fails, the hosts will be unable to reach the server farm. HSRP can be configured to drop R2's priority if the line protocol of R2's Serial0 interface goes down, making R3 the primary router. (The default decrement in the priority when the tracked interface goes down is 10.)
R2(config)#interface ethernet0 R2(config-if)#standby 1 priority 105 preempt R2(config-if)#standby 1 ip 172.12.23.10 R2(config-if)#standby 1 track serial0 R3(config)#interface ethernet0 R3(config-if)#standby 1 priority 100 preempt R3(config-if)#standby 1 ip 172.12.23.10 R2#show standby Ethernet0 - Group 1 Local state is Active, priority 105, may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 1.424 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.3 expires in 9.600 Virtual mac address is 0000.0c07.ac01 2 state changes, last state change 00:01:38 Priority tracking 1 interface, 1 up: Interface Decrement State Serial0 10 Up
R3#show standby Ethernet0 - Group 1 Local state is Standby, priority 100, may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.624 Virtual IP address is 172.12.23.10 configured Active router is 172.12.23.2, priority 105 expires in 9.452 Standby router is local 1 state changes, last state change 00:01:33
The show standby output on R2 shows the tracked interface, the default decrement of 10, and that the line protocol of the tracked interface is currently up. We'll test the configuration by shutting the interface down manually.
R2(config-if)#int s0 R2(config-if)#shutdown
1d14h: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Active -> Speak 1d14h: %LINK-5-CHANGED: administratively down Interface Serial0, changed state to
1d14h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
R2#show standby Ethernet0 - Group 1 Local state is Standby, priority 95 (confgd 105), may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.446 Virtual IP address is 172.12.23.10 configured Active router is 172.12.23.3, priority 100 expires in 9.148 Standby router is local 4 state changes, last state change 00:00:02 Priority tracking 1 interface, 0 up: Interface Decrement State Serial0 10 Down (administratively down)
Not only does the HSRP tracking work to perfection - R2 is now the standby and R3 the primary - but the show standby command even shows us that the line protocol is administratively down, rather than just "down". Running show standby on R3 verifies that R3 now sees itself as the Active router.
R3#show standby Ethernet0 - Group 1 Local state is Active, priority 100, may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.706 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.2 expires in 8.816 Virtual mac address is 0000.0c07.ac01 2 state changes, last state change 00:02:34
We'll now reopen the Serial0 interface on R2. Since we also put the preempt option on that router's HSRP configuration, R2 should take over as the Active router.
R2(config)#int s0 R2(config-if)#no shut 1d14h: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Standby -> Active 1d14h: %LINK-3-UPDOWN: Interface Serial0, changed state to up 1d14h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up
R2#show standby Ethernet0 - Group 1 Local state is Active, priority 105, may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.852 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.3 expires in 9.276 Virtual mac address is 0000.0c07.ac01 5 state changes, last state change 00:00:16 Priority tracking 1 interface, 1 up: Interface Decrement State Serial0 10 Up
Just that quickly, R2 is again the Active router. If you're running HSRP interface tracking, it's a very good idea to configure the preempt option on
all routers in the HSRP group. The #1 problem with an HSRP Interface Tracking configuration that is not working properly is a priority / decrement value problem. As I mentioned earlier, the default decrement is 10, and that's fine with the example we just worked through. If R2 had a priority of 120, the decrement of 10 would not be enough to make R3 the Active router. You can change the default decrement at the end of the standby interface command. The following configuration would result in a priority value decrement of 25 when the tracked interface goes down.
R1(config)#int ethernet0 R1(config-if)#standby 5 track s0/0? <1-255> Decrement value <cr> R1(config-if)#standby 5 track s0/0 25
That does not change the decrement value for all interfaces - just the one we're tracking with that particular statement, serial0. If we configure a second interface for tracking and do not supply a decrement value, that interface will have a decrement value of 10.
FastEthernet0/0 - Group 5 State is Init (virtual IP in wrong subnet) Virtual IP address is 172.12.34.10 (wrong subnet for this interface) Active virtual MAC address is unknown Local virtual MAC address is 0000.0c07.ac05 (v1 default) Hello time 3 sec, hold time 10 sec Preemption disabled Active router is unknown Standby router is unknown Priority 65 (default 100) Track interface Serial0/0 state Down decrement 25 Track interface Serial0/1 state Down decrement 10
Note that this interface's priority is now 65 in Group 5! At the bottom of that output, we see that it's using the default of 100, then has 25 decremented from that because serial0/0 is down, and then another 10 decremented because serial0/1 is down.
Troubleshooting HSRP We've discussed several troubleshooting steps throughout the HSRP section, but the show standby command can indicate other HSRP issues as well. I've deliberately misconfigured HSRP on this router to illustrate a few.
R1#show standby FastEthernet0/0 - Group 1 State is Active 2 state changes, last state change 01:08:58 Virtual IP address is 172.12.23.10 Active virtual MAC address is 0000.0c07.ac01 Local virtual MAC address is 0000.0c07.ac01 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 2.872 secs Preemption disabled Active router is local Standby router is unknown Priority 100 (default 100)
IP redundancy name is "hsrp-Fa0/0-1" (default) FastEthernet0/0 - Group 5 State is Init (virtual IP in wrong subnet) Virtual IP address is 172.12.34.10 (wrong subnet for this interface) Active virtual MAC address is unknown Local virtual MAC address is 0000.0c07.ac05 (v1 default) Hello time 3 sec, hold time 10 sec Preemption disabled Active router is unknown Standby router is unknown Priority 75 (default 100) Track interface Serial0/0 state Down decrement 25 IP redundancy name is "hsrp-Fa0/0-5" (default)
We've got all sorts of problems here! In the Group 5 readout, we see a message that the subnet is incorrect; naturally, both the active and standby routers are going to be unknown. In the Group 1 readout, the Active router is local but the Standby is unknown. This is most likely a misconfiguration on our part as well, but along with checking the HSRP config, always remember "Troubleshooting starts at the Physical layer!" One Physical layer issue with HSRP I've run into in both practice labs and production networks is an unusual number of state transitions. You can spot this and most other HSRP issues with debug standby.
R1#debug standby *Apr 9 20:15:10.542: HSRP: Fa0/0 API MAC address update *Apr 9 20:15:10.546: HSRP: Fa0/0 API Software interface coming up *Apr 9 20:15:10.550: HSRP: Fa0/0 API Add active HSRP addresses to ARP table *Apr 9 20:15:10.554: HSRP: Fa0/0 API Add active HSRP addresses to ARP table R1# *Apr 9 20:15:11.648: %SYS-5-CONFIG_I: Configured from console by console *Apr 9 20:15:12.541: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up R1# *Apr 9 20:15:12.541: HSRP: API Hardware state change *Apr 9 20:15:12.541: HSRP: Fa0/0 API Software interface coming up *Apr 9 20:15:12.545: HSRP: Fa0/0 API Add active HSRP addresses to ARP table *Apr 9 20:15:13.483: HSRP: Fa0/0 Interface up *Apr 9 20:15:13.483: HSRP: Fa0/0 Starting minimum interface delay (1 secs) *Apr 9 20:15:13.543: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up R1# *Apr 9 20:15:14.485: HSRP: Fa0/0 Interface min delay expired *Apr 9 20:15:14.485: HSRP: Fa0/0 Grp 1 Init: a/HSRP enabled *Apr 9 20:15:14.485: HSRP: Fa0/0 Grp 1 Init -> Listen *Apr 9 20:15:14.485: HSRP: Fa0/0 Grp 1 Redundancy "hsrp-Fa0/0-1" state Init ->Backup
This is an extremely verbose command, and a very helpful one. If you have the opportunity to run HSRP in a lab environment, run this one often during your configuration to see the different states and values being passed around the network. (Never practice debugs at work or in any production environment.) If you see HSRP states regularly transitioning, particularly between Speak and Standby, check your cabling - you'd be surprised how often that happens, especially in labs. Virtual Router Redundancy Protocol
Defined in RFC 2338, VRRP is the open-standard equivalent of the Ciscoproprietary HSRP. VRRP works very much like HSRP, and is suited to a multivendor environment. The operation of the two is so similar that you basically learned VRRP while going through the HSRP section! There are a few minor differences, a few of which are: VRRP's equivalent to HSRP's Active router is the Master router. (Some VRRP documentation refers to this router as the IP Address Owner.) This is the router that has the virtual router's IP address as a real IP address on the interface it will receive packets on. The physical routers in a VRRP Group combine to form a Virtual Router. VRRP Advertisements are multicast to 224.0.0.18. VRRP's equivalent to HSRP's Standby router state is the Backup state. The MAC address of VRRP virtual routers is 00-00-5e-00-01-xx, and you guessed it - the xx is the group number in hexadecimal. "preempt" is a default setting for VRRP routers. As of IOS Version 12.3(2)T, VRRP now has an Object Tracking feature. Similar to HSRP's Interface Tracking feature, a WAN interface can be tracked and a router's VRRP priority dropped when that interface goes down. Gateway Load Balancing Protocol (GLBP) HSRP and its open-standard relation VRRP have some great features, but accurate load balancing is not among them. While both allow a form of load sharing, it's not truly load balancing. I'm sure you can tell that the primary purpose of the Gateway Load Balancing Protocol (GLPB) is just that - load balancing! It's also suitable for use only on Cisco routers, because GLBP is Cisco-proprietary. As with HSRP and VRRP, GLBP routers will be placed into a router group. However, GLBP allows every router in the group to handle some of the load in a round-robin format, rather than having a primary router handle all of it while the standby routers remain idle. With GLBP, the hosts think they're sending all of their data to a single gateway, but actually multiple gateways are in use at one time. GLBP also allows standard configuration of the hosts, who will all have their gateway address set to the virtual router's address - none of this "some hosts point to gateway A, some hosts point to gateway B" business we had with HSRP load balancing. The key to GLBP is that when a host sends an ARP request for the MAC of the virtual router, one of the physical routers will answer. The host will then have the IP address of the virtual router and the MAC address of a physical router in the group. In the following illustrations, the three hosts send an ARP request for the MAC of the virtual router.
The Active Virtual Gateway (AVG) will be the router with the highest GLBP priority, and this router will send back ARP responses containing virtual MAC addresses. The virtual MAC addresses are assigned by the AVG as well. The three hosts will have the same Layer 3 address for their gateway, but a different L2 address, accomplishing the desired load balancing while allowing standard configuration on the hosts. (If the routers all have the same GLBP priority, the router with the highest IP address will become the AVG.) In the following illustration, R3 is the AVG and has assigned a virtual MAC of 22-22-22-22-22-22 to R2, 33-33-33-33-33-33 to itself, and 44-44-44-4444-44 to R4. The routers receiving and forwarding traffic received on this virtual MAC address are Active Virtual Forwarders (AVFs).
If the AVG fails, the router that's serving as the standby AVG will take over. If any of the AVFs fails, another router will handle the load destined
for a MAC on the downed router. GLBP routers use Hellos to detect whether other routers in their group are available or not. GLBP's load balancing also offers the opportunity to fine-tune it to your network's needs. GLBP offers three different forms of MAC address assignment, the default being round-robin. With round-robin assignments, a host that sends an ARP request will receive a response containing the next virtual MAC address in line. If a host or hosts need the same MAC gateway address every time it sends an ARP request, host-dependent load balancing is the way to go. Weighted MAC assignments affect the percentage of traffic that will be sent to a given AVF. The higher the assigned weight, the more often that particular router's virtual MAC will be sent to a requesting host. GLBP is enabled just as VRRP and HSRP are - by assigning an IP address to the virtual router. The following command will assign the address 172.1.1.10 to group 5.
MLS(config-if)# glbp 5 ip 172.1.1.10
To change the interface priority, use the glbp priority command. To allow the local router to preempt the current AVG, use the glbp preempt command.
MLS(config-if)# glbp 5 priority 150 MLS(config-if)# glbp 5 preempt
Server Load Balancing We've talked at length about how Cisco routers and multilayer switches can work to provide router redundancy - but there's another helpful service, Server Load Balancing, that does the same for servers. While HSRP, VRRP, and CLBP all represent multiple physical routers to hosts as a single virtual router, SLB represents multiple physical servers to hosts as a single virtual server. In the following illustration, three physical servers have been placed into the SRB group ServFarm. They're represented to the hosts as the virtual server 210.1.1.14.
The hosts will seek to communicate with the server at 210.1.1.14, not knowing that they're actually communicating with the routers in ServFarm. This allows quick cutover if one of the physical servers goes down, and also serves to hide the actual IP addresses of the servers in ServFarm. The basic operations of SLB involves creating the server farm, followed by creating the virtual server. We'll first add 210.1.1.11 to the server farm:
MLS(config)# ip slb serverfarm ServFarm MLS(config-slb-sfarm)# real 210.1.1.11 MLS(config-slb-real)# inservice
The first command creates the server farm, with the real command specifying the IP address of the real server. The inservice command is required by SLB to consider the server as ready to handle the server farm's workload. The real and inservice commands should be repeated for each server in the server farm. To create the virtual server:
MLS(config)# ip slb vserver VIRTUAL_SERVER MLS(config-slb-vserver)# serverfarm ServFarm MLS(config-slb-vserver)# virtual 210.1.1.14 MLS(config-slb-vserver)# inservice
From the top down, the vserver was named VIRTUAL_SERVER, which represents the server farm ServFarm. The virtual server is assigned the IP address 210.1.1.14, and connections are allowed once the inservice command is applied. You may also want to control which of your network hosts can connect to
the virtual server. If hosts or subnets are named with the client command, those will be the only clients that can connect to the virtual server. Note that this command uses wildcard masks. The following configuration would allow only the hosts on the subnet 210.1.1.0 /24 to connect to the virtual server.
MLS(config-slb-vserver)# client 210.1.1.0 0.0.0.255

IP Telephony & Voice VLANs

Overview
Cisco IP Phone Basics Voice VLANs Voice And Switch QoS DiffServ At Layer 2 DiffServ At Layer 3 Trust Or No Trust? The Basics Of AVVID Power Over Ethernet
If you don't have much (or any) experience with Voice Over IP (VoIP) yet, you're okay for now - you'll be able to understand this chapter with no problem. I say "for now" because all of us need to know some basic VoIP. Voice and security are the two fastest-growing sectors of our business. They're not going to slow down anytime soon, either. Once you're done with your CCNP, I urge you to look into a Cisco voice certification. There are plenty of good vendor-independent VoIP books on the market as well. Most Cisco IP phones will have three ports. One will be connected to a Catalyst switch, another to the phone ASIC, and another will be an access port that will connect to a PC, as shown here:
As is always the case with voice or video traffic, the key here is getting the voice traffic to its destination as quickly as possible in order to avoid jitter and unintelligible voice streams. ("jitter" occurs when there's a delay in transmitting voice or video traffic, perhaps due to improper queueing.) With Cisco IP Phones, there is no special configuration needed on the PC - as far as the PC's concerned, it is attached directly to the switch. The PC is unaware that it's actually connected to an IP Phone. The link between the switch and the IP Phone can be configured as a trunk or an access link. Configuring this link as a trunk gives us the advantage of creating a voice VLAN that will carry nothing but voice traffic while allowing the highest Quality of Service possible, giving the delaysensitive voice traffic priority over "regular" data handled by the switch. Configuring the link as an access link results in voice and data traffic being carried in the same VLAN, which can lead to delivery problems with the voice traffic. The problem isn't that the voice traffic will not get to the switch - it simply may take too long. Voice traffic is much more delaysensitive than data traffic.
The phrase "delay-sensitive" is vague, so let's consider this: The human ear will only accept 140 - 150 milliseconds of delay before it notices a problem with voice delivery. That's how long we have to get the voice traffic from source to destination before the voice quality is compromised. Voice VLANs When it comes to the link between the switch and the IP Phone, we've got four choices: Configure the link as an access link Configure the link as a trunk link and use 802.1p Configure the link as a trunk link and do not tag voice traffic Configure the link as a trunk link and specify a Voice VLAN If we configure the link as an access link, the voice and data traffic is transmitted in the same VLAN. It's recommended you make the port a trunk whenever possible. This will allow you to create a Voice VLAN, which will be separate from the regular data VLAN on the same line. The creation of Voice VLANs also makes it much easier to give the delay-sensitive voice traffic priority over "regular" data flows. The command to create a voice VLAN is a simple one - it's the choices that take a little getting used to. The "PVID" shown in these options is the Port VLAN ID, which identifies the data VLAN.
SW2(config-if)#switchport voice vlan ?
<1-4094> dot1p none untagged
Vlan for voice traffic Priority tagged on PVID Don't tell telephone about voice vlan Untagged on PVID
Let's look at these options from top to bottom. The <1 - 4094> option creates a voice VLAN and will create a dot1q trunk between the switch and the IP Phone. As with data VLANs, if the Voice VLAN has not been previously created, the switch will create it for you.
SW2(config-if)#switchport voice vlan 12 % Voice VLAN does not exist. Creating vlan 12
The dot1p option has two effects: The IP Phone grants voice traffic high priority Voice traffic is sent through the default voice native VLAN, VLAN 0 Note the console message when the dot1p option is enabled:
SW2(config-if)#switchport voice vlan dot1p % Voice VLAN does not exist. Creating vlan 0
The none option sets the port back to the default. Finally, the untagged option results in voice packets being put into the native VLAN.
SW2(config-if)#switchport voice vlan untagged
As always, there are just a few details you should be aware of when configuring : When Voice VLAN is configured on a port, Portfast is automatically enabled -- but if you remove the Voice VLAN, Portfast is NOT automatically disabled. Cisco recommends that QoS be enabled on the switch and the switch port connected to the IP phone be set to trust incoming CoS values. The commands to perform these tasks are mls qos and the interface-level command mls qos trust cos, respectively. You can configure voice VLANs on ports running port security or 802.1x authentication. It is recommended that port security be set to allow more than one secure MAC address. CDP must be running on the port leading to the IP phone. CDP should be globally enabled on all switch ports, but take a few seconds to make sure with show cdp neighbor. Voice VLAN is supported only on L2 access ports. Particularly when implementing video conferencing, make sure your total overall traffic doesn't exceed 75% of the overall available bandwidth. That includes video, voice, and data! Cisco also recommends that voice and video combined not exceed 33% of a link's bandwidth. This allows for network control traffic to flow through the network and helps to prevent jitter as well.
A voice VLAN's dependency on CDP can result in problems. Believe it or not, there is such a thing as CDP Spoofing, and that can result in an issue with anonymous access to Voice VLANs. Basically, CDP Spoofing allows the attacker to pretend to be the IP Phone! This issue is out of the scope of the BCMSN exam, but if you've got voice VLANs in your network or are even thinking about using them, you should run a search on "cdp spoofing voice vlan" and start reading!
Voice And Switch QoS I mentioned jitter earlier, but we've got three main enemies when it comes to successful voice transmission: jitter delay packet loss To successfully combat these problems, we have to make a decision on what QoS scheme to implement - and this is one situation where making no decision actually is making a decision! Best-effort delivery is the QoS you have when you have no explicit QoS configuration - the packets are simply forwarded in the order in which they came into the router. Best-effort works fine for UDP, but not for voice traffic. The Integrated Services Model, or IntServ, is far superior to best-effort. I grant you that's a poor excuse for a compliment! IntServ uses the Resource Reservation Protocol (RSVP) to do its job, and that reservation involves creating a high-priority path in advance of the voice traffic's arrival. The device that wants to transmit the traffic does not do so until a reserved path exists from source to destination. The creation of this path is sometimes referred to as Guaranteed Rate Service (GRS), or simply Guaranteed Service. The obvious issue with IntServ is that it's not a scalable solution - as your network handles more and more voice traffic, you're going to have more and more reserved bandwidth, which can in turn "choke out" other traffic. That issue is addressed with the Differentiated Services Model, or DiffServ. Where IntServ reserves an entire path in advance for the entire voice packet flow to use, DiffServ does not reserve bandwidth for the flow; instead, DiffServ makes its QoS decisions on a per-router basis as the flow traverses the network. If DiffServ sounds like the best choice, that's because it is - and it's so popular that this is the model we'll spend the most time with today. (Besides, it's pretty easy to configure the best-effort model - just don't do anything!) The DiffServ Model At Layer Two As mentioned earlier, DiffServ takes a DifferentView (sorry, couldn't resist) of end-to-end transmission than that taken by IntServ. The DiffServ
model allows each network device along the way to make a separate decision on how best to forward the packet toward its intended destination, rather than having all forwarding decisions made in advance. This process is Per-Hop Behavior (PHB).
The core tasks of Diffserv QoS are marking and classification. (They are two separate operations, but they work very closely together, as you'll see.) Marking is the process of tagging data with a value, and classification is taking the appropriate approach to queueing and transmitting that data according to that value. It's best practice to mark traffic as close to the source as possible to ensure the traffic receives the proper QoS as it travels across the network. This generally means you'll be marking traffic at the Access layer of the Cisco switching model, since that's where our end users can be found. At Layer 2, tagging occurs only when frames are forwarded from one switch to another. We can't tag frames that are being forwarded by a single switch from one port to another.
You know that the physical link between two switches is a trunk, and you know that the VLAN ID is tagged on the frame before it goes across the trunk. You might not know that another value - a Code of Service (CoS) value - can also be placed on that frame. Where the VLAN ID indicates the VLAN whose hosts should receive the frame, the CoS is used by the switch to make decisions on what QoS, if any, the frame should receive. It certainly won't surprise you to find that our trunking protocols, ISL and IEEE 802.1Q ("dot1q") handle CoS differently. Hey, with all the differences between these two that you've already mastered, this is easy!
The ISL tag includes a 4-bit User field; the last three bits of that field indicate the CoS value. I know I don't have to tell you this, but three binary bits give us a range of decimal values of 0 - 7. The dot1q tag has a User field as well, but this field is built a little differently. Dot1q's User field has three 802.1p priority bits that make up the CoS value, and again that gives us a decimal range of 0 - 7. Of course, there's an exception to the rule! Remember how dot1q handles frames destined for the native VLAN? There is no tag placed on those frames -- so how can there be a CoS value when there's no tag?
The receiving switch can be configured with a CoS to apply to any incoming untagged frames. Naturally, that switch knows that untagged frames are destined for the native VLAN. The DiffServ Model At Layer Three Way back in your Introduction To Networking studies, you became familiar with the UDP, TCP, and IP headers. One of the IP header fields is Type Of Service (ToS), and that ToS value is the basis for DiffServ's approach to marking traffic at Layer Three. The IP ToS byte consists of... an IP Precedence value, generally referred to as IP Prec (3 bits) a Type Of Service value (4 bits) a zero (1 bit) DiffServ uses this 8-bit field as well, but refers to this as the Differentiated Services (DS) field. The DS byte consists of.... a Differentiated Service Code Point value (DSCP,6 bits,RFC 2474) an Explicit Congestion Notification value (ECN, 2 bits, RFC 2481) The 6-bit DSCP value is itself divided into two parts: a Class Selector value, 3 bits a Drop Precedence value, 3 bits These two 3-bit values also have a possible range of 0 - 7 overall (000 111 in binary). Here's a quick description of the Class Selector values and their meanings: Class 7 (111) - Network Control, and the name is the recipe - this value is reserved for network control traffic (STP, routing protocol traffic, etc.) Class 6 (110) - Internetwork Control, same purpose as Network
Control. Class 5 (101) - Expedited Forwarding (EF, RFC 2598) - Reserved for voice traffic and other time-critical data. Traffic in this class is practically guaranteed not to be dropped. Classes 1 - 4 (001 - 100) - Assured Forwarding (AF, RFC 2597) These classes allow us to define QoS for traffic that is not as timecritical as that in Class 5, but that should not be left to best-effort forwarding, which is.... Class 0 (000) - Best-effort forwarding. This is the default. We've got four different classes in Assured Forwarding, and RFC 2597 defines three Drop Precedence values for each of those classes: High - 3 Medium - 2 Low - 1 The given combination of any class and DP value is expressed as follows: AF (Class Number)(Drop Precedence) That is, AF Class 2 with a DP of "high" would be expressed as "AF23".
To Trust Or Not To Trust, That Is The Question Just as you and I have to make a decision on whether to trust something that's told to us, a switch has to make a decision on whether to trust an incoming QoS value.
Once that decision is made, one of two things will happen. If the incoming value is trusted, that value is used for QoS. If the incoming value is not trusted, the receiving switch can assign a preconfigured value. It's a pretty safe bet that if the frame is coming from a switch inside your network, the incoming value should be trusted. It's also better to be safe than sorry, so if the frame is coming from a switch outside your administrative control, it should not be trusted. The point at which one of your switches no longer trusts incoming frames is the trust boundary.
We've also got to decide where to draw the line with a trust boundary when PCs and IP Phones are involved. Let's walk through a basic configuration with an IP Phone attached to the switch. Here's a quick reminder of the physical topology:
The first command we'll use isn't required, but it's a great command for those admins who work on the switch in the future:
SW2(config)#int fast 0/5 SW2(config-if)#description ? LINE Up to 240 characters describing this interface SW2(config-if)#description IP Phone Port
It never hurts to indicate which port the phone is attached to. Now to the required commands! Before we perform any QoS on this switch, we have to enable it - QoS is disabled globally by default.
SW2(config)#mls qos QoS: ensure flow-control on all interfaces are OFF for proper operation.
We can trust values on two different levels. First, we can trust the value unconditionally, whether that be CoS, IP Prec, or DSCP. Here, we'll unconditionally trust the incoming CoS value.
SW2(config-if)#mls qos trust ? cos Classify by packet COS device trusted device class dscp Classify by packet DSCP ip-precedence Classify by packet IP precedence <cr> SW2(config-if)#mls qos trust cos
We can also make this trust conditional, and trust the value only if the device on the other end of this line is a Cisco IP phone. IOS Help shows us that the only option for this command is a Cisco IP phone!
SW2(config-if)#mls qos trust device ? cisco-phone Cisco IP Phone
SW2(config-if)#mls qos trust device cisco-phone
If you configure that command and show mls qos interface indicates the port is not trusted, most likely there is no IP Phone connected to that port. Trust me, I've been there. :)
SW2#show mls qos interface fast 0/5 FastEthernet0/5 trust state: not trusted trust mode: trust cos COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map Trust device: cisco-phone
There's another interesting QoS command we need to consider:

SW2(config-if)#switchport priority extend ? cos Override 802.1p priority of devices on appliance trust Trust 802.1p priorities of devices on appliance
If an IP Phone is the only device on the end of the link, what "appliance" are we talking about? Why are we discussing extending the trust? To what point are we extending the trust? Let's take another look at our diagram:
Remember, we've got a PC involved here as well. The IP Phone will generate the voice packets sent to the switch, but the PC will be generating data packets. We need to indicate whether QoS values on data received by the phone from the PC should be trusted or overwritten. In other words, should the trust boundary extend to the PC? The best practice is to not trust the QoS values sent by the PC. Some applications have been known to set QoS values giving that application's data a higher priority than other data. (Can you believe such a thing?) That's one reason the default behavior is to not trust the CoS value from the PC, and to set that value to zero.
To overwrite the CoS value sent by the PC and set it to a value we choose, use the switchport priority extend cos command.
SW2(config-if)#switchport priority extend cos ?
<0-7>
Priority for devices on appliance
SW2(config-if)#switchport priority extend cos 2
Frames received from the PC are now trusted and will have their priority set to 2. If we had chosen to trust those same frames and allow their CoS to remain unchanged after transmission from the PC, we would use the switchport priority extend trust command.
SW2(config-if)#switchport priority extend ? cos Override 802.1p priority of devices on appliance trust Trust 802.1p priorities of devices on appliance SW2(config-if)#switchport priority extend trust
The word "boundary" doesn't appear in the command, but this command has the effect of extending the trust boundary beyond the phone to the PC.
Other QoS Methods To Improve VOIP Speed & Quality We've talked at length about using a priority queue for voice traffic, but there are some other techniques we can use as well. As with any other QoS, the classification and marking of traffic should be performed as close to the traffic source as possible. Access-layer switches should always perform this task, not only to keep the extra workload off the core switches but to ensure the end-to-end QoS you wanted to configure is the QoS you're getting. Another method of improving VOIP quality is to configure RTP Header Compression. This compression takes the IP/UDP/RTP header from its usual 40 bytes down to 2 - 4 bytes.
RTP header compression is configured with the interface-level ip rtp header-compression command, with one option you should know about passive. If the passive option is configured, outgoing packets are subject to RTP compression only if incoming packets are arriving compressed.
An Introduction To AVVID Cisco's Architecture for Voice, Video, and Integrated Data (AVVID) is a comprehensive network architecture approach which integrates Voice and Video into an existing Data network. (But you knew that from the name, right?) A PDF available on Cisco's website lists these five AVVID components as primary concerns: High Availability Quality of Service Security Enterprise Mobility Scalability Basically, AVVID is designed to take an organization's existing infrastructures and combine them into one large infrastructure. Cisco's theory holds that doing so will reduce overall costs while preparing the infrastructure to run the latest and greatest Cisco technologies. Storage Networking is becoming more and more important every day, and is also an important part of an AVVID design. To show you how wide-ranging AVVID is, a single AVVID infrastructure is designed to hold all of the following hardware: Cisco routers Cat switches IP phones
Voice trunking Cisco Call Manager analog and digital gateways to the PSTN voice modules AVVID design is not in the scope of the BCMSN exam, but this is a Cisco service that's just going to continue to get larger as more organizations introduce voice and video to their infrastructures. There's an excellent white paper on the Net that can help you get started with AVVID - just search for "designing a Cisco AVVID infrastructure" and you'll find a document called "Migrating Toward Convergence". It's highly recommended reading! "Power Over Ethernet" I don't anticipate you'll see much of POE on your exam, if at all, but it is a handy way to power the phone if there's just no plug available! With POE, the electricity necessary to power the IP Phone is actually transferred from the switch to the phone over the UTP cable that already connects the two devices!
Not every switch is capable of running POE. Check your particular switch's documentation for POE capabilities and details. The IEEE standard for POE is 802.3af. There is also a proposed standard for High-Power POE, 802.3at. To read more than you'd ever want to know about POE, visit http://www.poweroverethernet.com. By default, ports on POE-capable switches do attempt to find a device needing power on the other end of the link. We've got a couple of options for POE as well:
SW4(config)#int fast 1/0/1 SW4(config-if)#power inline ? auto Automatically detect and power inline devices consumption Configure the inline device consumption never Never apply inline power static High priority inline power interface
The auto setting is the default. The consumption option allows you to set the level of power sent to the device:
SW4(config-if)#power inline consumption ? <4000-15400> milli-watts SW4(config-if)#power inline consumption
And naturally, the never option disables POE on that port. POE options and capabilities differ from one device to the next, so check your switch's documentation *carefully* before using POE.

Wireless
Overview
Wireless Basics Wireless Standards, Ranges, and Frequencies IrDA 1.1 Wireless Antenna Types and Usage CSMA/CA The Cisco Compatible Extensions Program The Lightweight Access Point Protocol The Aironet System Tray Utility
Wireless Basics Hard to believe there was once a time when a laptop or PC had to be connected to an outlet to access the Internet, isn't it? Wireless is becoming a larger and larger part of everyday life, to the point where people expect to be able to access the Net or connect to their network while eating lunch. A common wireless topology is an Infrastructure Wireless Local Area Network (WLAN) , also called a Basic Service Set (BSS), where a Wireless Access Point (WAP) is used to allow multiple devices to intercommunicate. The area of coverage the WAP provides is called a cell, and as any of us who have used wireless networks know, that cell can shrink and grow without warning! Hosts successfully connecting to the WAP in a BSS are said to have formed an association with the WAP. Forming this association usually requires the host to present required authentication and/or the correct Service Set Identifier (SSID). The SSID is the public name of the wireless network. A SSID is simply a string of text. SSIDs are case-sensitive and can be up to 32 characters in length.
Cisco uses the term AP instead of WAP in much of their documentation; just be prepared to see this term expressed either way on your exam and in network documentation. I'll call it an AP for the rest of this section. A BSS operates much like a hub-and-spoke network in that all communication must go through the hub, which in this case is the AP. APs can also be arranged in such a way that a mobile user, or roaming user, will (theoretically) always be in the provider's coverage area. Those of us who are roaming users understand the "theoretical" part! Speaking as a roaming user, did you ever wonder how your wireless card decides to quit using its current AP and start using the next one in line? Well, keep wondering. :) Seriously, wireless vendors keep us guessing on this one, since they all use different standards on when that cutover needs to be performed. What we do know is that there are two different methods the client can use to find the next AP - active scanning and passive scanning. With active scanning, the client sends Probe Request frames and then waits to hear Probe Responses. If multiple Probe Responses are heard, the client chooses the most appropriate WAP to use in accordance with vendor standards. Passive scanning is just what it sounds like - the client listens for beacon frames from APs. No Probe Request frames are sent. WLAN Authentication (And Lack of Same) Of course, you don't want just any wireless client connecting to your WLAN! The 802.11 WLAN standards have two different authentication schemes - open system and shared key. They're both pretty much what they sound like. Open system is basically one station asking the receiving station "Hey, do you recognize me?" Hopefully, shared key is the authentication system you're more familiar with, since open system is a little too open! Shared key uses Wired Equivalent Privacy (WEP) to provide a higher level of security than open system. There's just one little problem with WEP. Okay, a big problem. It can be
broken in seconds by software that's readily available on the Web. Another problem is the key itself. It's not just a shared key, it's a static key, and when any key or password remains the same for a long time, the chances of it being successfully hacked increase substantially. These two factors make WEP unacceptable for our network's security. Luckily, we've got options... A Giant LEAP Forward The Extensible Authentication Protocol (EAP) was actually developed originally for PPP authentication, but has been successfully adapted for use in wireless networks. RFC 3748 defines EAP. Cisco's proprietary version of EAP is LEAP, the Lightweight Extensible Authentication Protocol. LEAP has several advantages over WEP: There is two-way authentication between the AP and the client The AP uses a RADIUS server to authenticate the client The keys are dynamic, not static, so a different key is generated upon every authentication Recognizing the weaknesses inherent in WEP, the Wi-Fi Alliance (their home page is http://wi-fi.org) saw the need for stronger security features in the wireless world. Their answer was Wi-Fi Protected Access (WPA), a higher standard for wireless security. Basically, WPA was adopted by many wireless equipment vendors while the IEEE was working on a higher standard as well, 802.11i - but it wasn't adopted by every vendor. As a result, WPA is considered to work universally with wireless NICs, but not with all early APs. When the IEEE issued 802.11i, the Wi-Fi Alliance improved the original WPA standards, and came up with WPA2. As you might expect, not all older wireless cards will work with WPA2. To put it lightly, both WPA and WPA2 are major improvements over WEP. Many wireless devices, particularly those designed for home use, offer WEP as the default protection - so don't just click on all the defaults when you're setting up a home wireless network! The WPA or WPA2 password will be longer as well - they're actually referred to as passphrases. Sadly, many users will prefer WEP simply because the password is shorter. APs are not required to create a wireless network. In an ad hoc WLAN ("wireless LAN"), the wireless devices communicate with no AP involved. The official name for an ad hoc WLAN is an Independent Basic Service Set (IBSS). In the real world, you'll almost always here them call ad hoc networks, but it couldn't hurt to keep the official name in mind for your exam.
Wireless Networking Standards, Ranges, and Frequencies Along with the explosion of wireless is a rapidly-expanding range of wireless standards. Some of these standards play well together, others do not. Let's take a look at the wireless standards you'll need to know to pass the Network+ exam and to work with wireless in today's networks. The standards listed here are all part of the 802.11x standards developed by the IEEE. 802.11a has a typical data rate of 25 MBPS, but can reach speeds of 54 MBPS. Indoor range is 100 feet. Operating frequency is 5 GHz. 802.11b has a typical data rate of 6.5 MBPS, but can reach speeds of 11 MBPS. Indoor range is 100 feet. Operating frequency is 2.4 GHz. 802.11g has a typical data rate of 25 MBPS, a peak data rate of 54 MBPS, and an indoor range of 100 feet. Operating frequency is 2.4 GHz. 802.11b and 802.11g are compatible to the point where many wireless routers and cards that use these standards are referred to as "802.11b/g", or just "b/g". You can have trouble with 802.11g from an unexpected source - popcorn! Well, not directly, but microwave ovens also share the 2.4 GHz band, and the presence of a microwave in an office can actually cause connectivity issues. (And you thought they were just annoying when people burn popcorn in the office microwave!) Solid objects such as walls and other buildings can disturb the signal in any bandwidth. 802.11n has a typical data rate of 200 MBPS, a peak data rate of 540 MBPS, and an indoor range of 160 feet. Operating frequency is either 2.4 GHz or 5 GHz. Infrared Data Association (IrDA) The IrDA is another body that defines specifications, but the IrDA is concerned with standards for transmitting data over infrared light. IrDA 1.0 only allowed for a range of 1 meter and transmitted data at approximately 115 KBPS. The transmission speed was greatly improved
with IrDA 1.1, which has a theoretical maximum speed of 4 MBPS. The two standards are compatible. Keep in mind that neither IrDA standard has anything to do with radio frequencies - only infrared light streams. The IrDA notes that to reach that 4 MBPS speed, the hardware must be 1.1 compliant, and even that might not be enough - the software may have to be modified as well. Which doesn't sound like fun. Antenna Types A Yagi antenna (technically, the full name is "Yagi-Uda antenna") sends its signal in a single direction, which means it must be aligned correctly and kept that way. Yagi antennas are sometimes called directional antennas, since they send their signal in a particular direction.
In contrast, an Omni ("omnidirectional") antenna sends a signal in all directions on a particular plane. Since this is networking, we can't just call these antennae by one name! Yagis are also known as point-to-point and directional antenna; Omni antennas are also known as omnidirectional and point-to-multipoint antenna. Both Yagi and Omni antennas have their place in wireless networks. The unidirectional signal a Yagi antenna sends makes it particularly helpful in bridging the distance between APs. The multidirectional signal sent by Omni antennas help connect hosts to APs, including roaming laptop users.
CSMA/CA From your CCNA studies, you know all about how a "Wired LAN" avoids collisions. Through the use of IEEE 802.3, CSMA/CD (Carrier Sense Multiple Access with Collision Detection), only one host can transmit at a time - and even if multiple hosts transmit data onto a shared segment at once, jam signals and random timers help to minimize the damage. With "Wireless LANs", life isn't so simple. Wireless LANs can't listen and send at the same time - they're half-duplex - so traditional collision detection techniques cannot work. Instead, wireless LANs will use IEEE standard 802.11, CSMA/CA, (Carrier Sense Multiple Access with Collision Avoidance).
Let's walk through an example of Wireless LAN access, and you'll see where the "avoidance" part of CSMA/CA comes in. The foundation of CSMA/CA is the Distributed Coordination Function (DCF). The key rule of DCF is that when a station wants to send data, the station must wait for the Distributed Interframe Space (DIFS) time interval to expire before doing so. In our example, Host A finds the wireless channel to be idle, waits for the DIFS timer to expire, and then sends frames.
Host B and Host C now want to send frames, but they find the channel to be busy with Host A's data.
The potential issue here is that Host B and Host C will simultaneously realize Host A is no longer transmitting, so they will then both transmit, which will lead to a collision. To help avoid (there's the magic word!) this, DCF requires stations finding the busy channel to also invoke a random timer before checking to see if the channel is still busy. In DCF-speak, this random amount of time is the Backoff Time. The formula for computing Backoff Time is beyond the scope of the BCMSN exam, but the computation does involve a random number, and that random value helps avoid collisions. The Cisco Compatible Extensions Program When you're looking to start or add to your wireless network, you may just wonder.... "How The $&!(*% Can I Figure Out Which Equipment Supports Which Features?" A valid question! :) Thankfully, Cisco's got a great tool to help you out - the Cisco Compatible Extension (CCX) website. Cisco certification isn't just for you and I -
Cisco also certifies wireless devices that are guaranteed to run a desired wireless feature. The website name is a little long to put here, and it may well change, so I recommend you simply enter "cisco compatible extension" into your favorite search engine - you'll find the site quickly. Don't just enter "CCX" in there - you'll get the Chicago Climate Exchange. I'm sure they're great at what they do, but don't trust them to verify wireless capabilities! The Lightweight Access Point Protocol (LWAPP) As wireless networks grow in popularity, they grow in size and complexity as well. It's imperative that each AP in your network enforce a consistent policy when it comes to security and Quality of Service - but sometimes this just doesn't happen. As our wireless networks get larger and larger, we really need some kind of central authority to ensure that a consistent access policy is successfully implemented. By no small coincidence, Cisco has developed such an authority as part of their Cisco Unified Wireless Network - the WLAN Controller, which communicates with Lightweight Access Points (LAP). This communication takes place via LWAPP, the LightWeight Access Point Protocol.
The WLAN Controller is basically the quarterback of the WLAN, with the LAPs serving as the other players. The WLAN Controller will be configured with security procedures, Quality of Service (QoS) policies, mobile user policies, and more. The WLAN Controller than informs the LAPs of these policies and procedures, ensuring that each LAP is consistently enforcing the same set of wireless network access rules and regulations. Many CIsco Aironet access points can operate autonomously or as an LAP. Here are a few of those models: 1230 AG Series 1240 AG Series 1130 AG Series Some other Aironet models have circumstances under which they cannot operate as LAPs - make sure to do your research before purchasing!
The Aironet System Tray Utility We're all familiar with the generic icon on a laptop or PC that shows us how strong (or weak) our wireless signal is. The Aironet System Tray Utility (ASTU) gives us that information and a lot more. Instead of just indicating how strong the wireless signal is, the icon will change color to indicate signal strength and other important information. Problem is, the colors aren't exactly intuitive, so we better know what they mean! Here's a list of ASTU icon colors and their meanings. Red - This does not mean that you don't have a connection to an access point! It means that you do have connectivity to an AP, and you are authenticated via EAP if necessary, but that the signal strength is low. Yellow - Again, you are connected to an AP and are authenticated if necessary, but signal strength is fair. Green - Connection to AP is present, EAP authentication is in place if necessary, and signal strength is very good. Light Gray - Connection to AP is present, but you are *not* EAPauthenticated. Dark Gray - No connection to AP is present. White - Client adapter is disabled. If you're connecting to an ad hoc network, just substitute "remote client" for "AP" in the above list. The key is to know that red, green, and yellow are referring to signal strength, light gray indicates a lack of EAP authentication, dark gray means there is no connection to an AP or remote client, and white means the adapter is disabled.

Network Design And Models

Overview
Cisco's Three-Layer Hierarchical Model The Core Layer The Distribution Layer The Access Layer The Enterprise Composite Network Model The Server Farm Block The Network Management Block The Enterprise Edge & Service Provider Edge Block
In this section, you're going to be reintroduced to a networking model you first saw in your CCNA studies. No, it's not the OSI model or the TCP/IP model - it's the Cisco Three-Layer Hierarchical Model. About all you had to do for the CCNA was memorize the three layers and the order they were found in that model, but the stakes are raised here in your CCNP studies. You need to know what each layer does, and what each layer should not be doing. This is vital information for your realworld network career as well, so let's get started with a review of the Cisco three-layer model, and then we'll take a look at each layer's tasks. Most of the considerations at each layer are common sense, but we'll go over them anyway!
The Cisco Three-Layer Hierarchical Model
The Core Layer The term core switches refers to any switches found here, the core layer. Switches at the core layer allow switches at the distribution layer to communicate, and this is more than a full-time job. It's vital to keep any extra workload off the core switches, and allow them to do what they need to do - switch! The core layer is the backbone of your entire network, so we're interested in high-speed data transfer and very low latency. That's it! The core layer is the backbone of our network, so we've got to optimize data transport. Today's core switches are generally multilayer switches - switches that can handle both the routing and switching of data. The throughput of core switches must be high, so examine your particular network's requirements and switch documentation thoroughly before making a decision on purchasing core switches. We want our core switches to handle switching, and let distribution-layer switches handle routing. Core layer switches are usually the most powerful in your network, capable of higher throughput than any other switches in the network. Remember, everything we do on a Cisco router or switch has a cost in CPU or memory, so we're going to leave most frame manipulation and filtering to other layers. The exception is Cisco QoS, or Quality of Service. Advanced QoS is generally performed at the core layer. We'll go into much more detail regarding QoS in another section, but for now, know that QoS is basically high-speed queuing where special consideration can be given to certain data in certain queues. Leave ACLs and other filters for other parts of the network. We always want redundancy, but you want a lot of redundancy in your core layer. This is the nerve center of your entire network, so fault tolerance needs to be as high as you can possibly get it. Root bridges should also be located in the core layer whenever possible.
The Distribution Layer The demands on switches at this layer are high. The access-layer switches are all going to have their uplinks connecting to these switches, so not only do the distribution-layer switches have to have high-speed ports and links, they've got to have quite a few to connect to both the access and core switches. That's one reason you'll find powerful multilayer switches at this layer - switches that work at both L2 and L3. Distribution-layer switches must be able to handle redundancy for all links as well. Examine your network topology closely and check vendor documentation before making purchasing decisions on distribution-layer switches. The distribution layer is also where routing should take place when utilizing multilayer switches, since the access layer is busy with end users and we want the core layer to be concerned only with switching, not routing. While QoS is often found operating at the core layer, you'll find it in the distribution layer as well. The distribution layer also serves as the boundary for broadcasts and multicasts, thanks to the L3 devices found here. (Recall from your CCNA studies that Layer 3 devices do not forward broadcasts or multicasts.) The Access Layer End users communicate with the network at this layer. VLAN membership is handled at this layer, as well as traffic filtering and basic QoS. Redundancy is important at this layer as well - hey, when isn't redundancy important? - so redundant uplinks are vital. The uplinks should also be scalable to allow for future network growth. You also want your access layer switches to have as many ports as possible, and again, plan for future growth. A 12-port switch may be fine one week, but a month from now you might just wish you had bought a 24-port switch. A good rule of thumb for access switches is "low cost, high switchport-to-user ratio". Don't assume that today's sufficient port density will be just as sufficient tomorrow! You can perform MAC address filtering at the access layer, although hopefully there are easier ways for you to perform the filtering you need. (MAC filtering is a real pain to configure.) Collision domains are also formed at the access layer.
The Enterprise Composite Network Model This model is much larger than the Cisco three-layer model, as you'll see in just a moment. I want to remind you that networking models are guidelines, and should be used as such. This is particularly true of the Enterprise Composite Network Model, which is one popular model used to design campus networks. A campus network is basically a series of LANs that are interconnected by a backbone. Before we look at this model, there's some terminology you should be
familiar with. Switch blocks are units of access-layer and distribution-layer devices. These layers contain both the traditional L2 switches (found at the access layer) and multilayer switches, which have both L2 and L3 capabilities (found at the distribution layer). Devices in a switch block work together to bring network access to a unit of the network, such as a single building on a college campus or in a business park. Core blocks consist of the high-powered core switches, and these core blocks allow the switch blocks to communicate. This is a tremendous responsibility, and it's the major reason that I'll keep mentioning that we want the access and distribution layers to handle as many of the "extra" services in our network whenever possible. We want the core switches to be left alone as much as possible so they can concentrate on what they do best - switch. The design of such a network is going to depend on quite a few factors the number of LANs involved, the physical layout of the building or buildings involved being just two of them - so again, remember that these models are guidelines. Helpful guidelines, though! The Enterprise Composite Network Model uses the term block to describe the three layers of switches we just described. The core block is the collection of core switches, which is the backbone mentioned earlier. The access and distribution layer switches are referred to as the switch blocks. Overall, there are three main parts of this model: The Enterprise Campus The Enterprise Edge The Service Provider Edge The Enterprise Campus consists of the following modules: Campus Infrastructure module Server Farm module Network Management module Enterprise Edge (yes, again) In turn, the Campus Infrastructure module consists of these modules: Building Access module (Access-layer devices) Building Distribution module (Distribution-layer devices) Campus Backbone (Interconnects multiple Distribution modules) Let's take a look at a typical campus network and see how these block types all tie in. How The Switch Blocks And Core Blocks Work Together
The smaller switches in the switch block represent the access-layer switches, and these are the switches that connect end users to the network. The distribution-layer switches are also in the switch block, and these are the switches that connect the access switches to the core. All four of the distribution layer switches shown have connections to both switches in the core block, giving us the desired redundancy. The core block serves as the campus backbone, allowing switches in the LAN 1 Switch Block to communicate with switches in the LAN 2 Switch Block. The core design shown here is often referred to as dual core, referring to the redundant fashion in which the switch blocks are connected to the core block. The point at which the switch block ends and the core block begins is very clear. A smaller network may not need switches to serve only as core switches, or frankly, may not be able to afford such a setup. Smaller networks can use a collapsed core, where certain switches will perform both as distribution and core switches.
In a collapsed core, there is no dedicated core switch. The four switches at the bottom of the diagram are serving as both core and distribution layer switches. Note that each of the access switches have redundant uplinks to both distribution / core switches in their switch block.
The Server Farm Block As much as we'd like to get rid of them sometimes, we're not going to have much of a network without servers! In a campus network, the server farm block will be a separate switch block, complete with access and distribution layer switches. The combination of access, distribution, and core layers shown here is sometimes referred to as the Campus Infrastructure.
Again, the distribution switches have redundant connections to the core switches. So far we have a relatively small campus network, but you can already get a good idea of the sheer workload the core switches will be under. The Network Management Block Network management tools are no longer a luxury - in today's networks, they're a necessity. AAA servers, syslog servers, network monitoring tools, and intruder detection tools are found in almost every campus network today. All of these devices can be placed in a switch block of their own, the network management block.
Now our core switches have even more to contend with - but we're not quite done yet. We've got our end users located in the first switch blocks, we've got our server farm connected to the rest of the network, we've got our all-important network management and security block set up... what else do we need? Oh yeah.... internet connectivity! (And WAN access!) Two blocks team up to bring our end users those services - the Enterprise Edge Block and the Service Provider Edge Block.
Internet and WAN connectivity for a campus network is a two-block job one block we have control over, the other we do not. The Enterprise Edge Block is indeed the edge of the campus network, and this block of the routers and switches needed to give the needed WAN connectivity to the rest of the campus network. While the Service Provider Edge Block is considered part of the campus network model, we have no control over the actual structure of this block. And frankly, we don't really care! The key here is that this block borders the Enterprise Edge Block, and is the final piece of the Internet connectivity puzzle for our campus network. Take a look at all the lines leading to those core switches. Now you know why we want to dedicate as much of these switches' capabilities to pure switching - we're going to need it!

Bonus Section: Queueing And Compression

Overview
First In, First Out (FIFO) Flow-Based Weighted Fair Queueing (WFQ) Class-Based Weighted Fair Queueing (CBWFQ) CBWFQ, Packet Drop, And TCP Global Synchronization Random Early Detect & Weighted Random Early Detect Low Latency Queueing (LLQ) Priority Queueing (PQ) Custom Queueing (CQ) Queueing Summary Choosing A Queueing Strategy Header And Payload Compression
We covered CoS and IP Telephony QoS in another section, but there's a chance that you'll see some more general QoS questions on your BCMSN exam. With that in mind, here's a bonus chapter on QoS! In today's networks, there's a huge battle for bandwidth. You've got voice traffic, video traffic, multicasts, broadcasts, unicasts.... and they're all fighting to get to the head of the line for transmission! The router's got to make a decision as to which traffic should be treated with priority, which traffic should be treated normally, and which traffic should be dumped if congestion occurs. Cisco routers offer several options for this queueing procedure, and it won't surprise you to know that you need to know quite a few of them to become a CCNP! Beyond certification, it's truly important to know what's going on with a network's queues - and the only way to learn queueing is to dive right in, so let's get started! Here's a (very) basic overview of the queuing dilemma facing a router:
Three different kinds of traffic, and they all want to be transmitted first by the router. Of course, we could break this down further by specifying the sender and receiver - "if Host A sends data to Host B, send that first". Developing a successful queuing strategy takes time and planning, because not all this data can go first. First In, First Out FIFO is just what it sounds like - there is no priority traffic, no traffic classes, no queueing decision for the router to make. This is the default for all Cisco router interfaces, with the exception of Serial interfaces running at less than E1 (2.048 MBPS) speed. FIFO is fine for many networks, and if you have no problem with network congestion, FIFO may be all you need. If you've got traffic that's especially time-sensitive such as voice and video, FIFO is not your best choice. Flow-Based Weighted Fair Queueing What's so "fair" about Weighted Fair Queueing (WFQ)? WFQ prevents one particular stream of network traffic, or flow, from using most or all of the available bandwidth while forcing other streams of traffic to sit and wait. These flows are defined by WFQ and require no access list configuration. Flow-based WFQ is the default queueing scheme for Serial interfaces running at E1 speed or below. Flow-Based WFQ takes these packet flows and classifies them into conversations. WFQ gives priority to the interactive, low-bandwidth conversations, and then splits the remaining bandwidth fairly between the non-interactive, high-bandwidth conversations. In the following exhibit, a Telnet flow reaches the router at the same time as two FTP flows. Telnet is low-volume, so the Telnet transmission will be forwarded first. The two remaining file transfers will then be assigned a comparable amount of bandwidth. The packets in the two file transfers will be interleaved - that is, some packets for Flow 1 will be sent, then some for Flow 2, and so on. The key here is that one file transfer flow will not have priority over the other.
Enabling flow-based WFQ is simple enough. We don't even have to configure it on the following Serial interface, since WFQ is enabled by default on all serial interfaces running at or below E1 speed, but let's walk through the steps:
R1(config)#int serial0 R1(config-if)#fair-queue ? <1-4096> Congestive Discard Threshold <cr>
The Congestive Discard Threshold dictates the number of packets that can be held in a single queue. The default is 64. Let's change it to 200.
R1(config)#int serial0 R1(config-if)#fair-queue ? <1-4096> Congestive Discard Threshold <cr> R1(config-if)#fair-queue 200
To verify your queuing configuration, run show queue followed by the interface type and number.
R1#show queue serial0 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/200/0 (size/max total/threshold/drops) Conversations 0/0/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 1158 kilobits/sec IOS Help shows other WFQ Options: R1(config-if)#fair-queue 200 ? <16-4096> Number Dynamic Conversation Queues <cr>
The Dynamic Conversation Queues are used for normal, best-effort conversations. We'll change that to 200 as well.
R1(config-if)#fair-queue 200 200 Number of dynamic queues must be a power of 2 (16, 32, 64, 128, 256, 512, 1024)
Then again, maybe we won't. Let's change it to 256 instead and use IOS Help to show any other options.
R1(config-if)#fair-queue 200 256 ? <0-1000> Number Reservable Conversation Queues
The final WFQ option is the number of Reservable Conversation Queues. The default here is zero. These queues are used for specialized queueing and Quality of Service features like the Resource Reservation Protocol (RSVP). We'll set this to 100.
R1(config-if)#fair-queue 200 256 100
show queue verifies that all three of these values have been successfully set, as does show queueing fair.
R1#show queue serial 0 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair Output queue: 0/1000/200/0 (size/max total/threshold/drops) Conversations 0/0/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 1158 kilobits/sec
What Prevents WFQ From Running? Earlier in this section, I mentioned that serial interfaces running at E1 speed or lower will run WFQ by default. However, if any of the following features are running on the interface, WFQ will not be the default. Tunnels, Bridges, Virtual Interfaces Dialer interfaces, LAPB, X.25 Class-Based Weighted Fair Queuing The first reaction to WFQ is usually something like this: "That sounds great, but shouldn't the network administrator be deciding which flows should be transmitted first, rather than the router?" Good question! There's an advanced form of WFQ, Class-Based Weighted Fair Queuing (CBWFQ) that allows manual configuration of queuing - and CBWFQ does involve access list configuration. Since the name is the recipe, the first step in configuring CBWFQ is to create the classes themselves. If you've already passed your BCRAN exam, this will all look familiar to you. If not, no problem at all, we'll take a step-by-step approach to CBWFQ. We'll first define two classes, one that will be applied to TCP traffic sourced from 172.10.10.0 /24, and another applied to FTP traffic from 172.20.20.0 /24. The first step is to write two separate ACLs, with one matching the first source and another matching the second. Don't write one ACL matching both.
R1(config)#access-list 100 permit tcp 172.10.10.0 0.0.0.255 any R1(config)#access-list 110 permit tcp 172.20.20.0 0.0.0.255 any eq ftp
Now two class maps will be written, each calling one of the above ACLs.
R1(config)#class-map 17210100 R1(config-cmap)#match access-group 100 R1(config)#class-map 17220200 R1(config-cmap)#match access-group 110
By the way, we've got quite a few options for the match statement in a class map, and up to 64 classes can be created:
R1(config-cmap)#match ? access-group Access group any Any packets class-map Class map cos IEEE 802.1Q/ISL class of service/user priority values destination-address Destination address input-interface Select an input interface to match ip IP specific values mpls Multi Protocol Label Switching specific values not Negate this match result protocol Protocol qos-group Qos-group source-address Source address
At this point, we've created two class maps that aren't really doing anything except matching the access list. The actual values applied to the traffic are contained in our next step, the policy map.
R1(config)#policy-map CBWFQ R1(config-pmap)#class 17210100 R1(config-pmap-c)#? QoS policy-map class configuration commands: bandwidth Bandwidth exit Exit from QoS class action configuration mode no Negate or set default values of a command priority Strict Scheduling Priority for this Class queue-limit Queue Max Threshold for Tail Drop random-detect Enable Random Early Detection as drop policy service-policy Configure QoS Service Policy shape Traffic Shaping <cr> police Police
The values we'll set for both classes are the bandwidth and queue-limit values. For traffic matching class 17210100, we'll assign bandwidth of 400 and a queue limit of 50 packets; for traffic matching class 17220200, we'll assign bandwidth of 200 and a queue limit of 25 packets. The bandwidth assigned to a class is the value CBWFQ uses to assign weight. The more bandwidth assigned to a class, the lower the weight The lower the weight, the higher the priority for transmission
R1(config)#policy-map CBWFQ R1(config-pmap)#class 17210100 R1(config-pmap-c)#bandwidth 400 R1(config-pmap-c)#queue-limit 50
R1(config-pmap-c)#class 17220200 R1(config-pmap-c)#bandwidth 200 R1(config-pmap-c)#queue-limit 25
If no queue limit is configured, the default of 64 is used. Finally, we need to apply this policy map to the interface! As with ACLs, a Cisco router interface can have one policy map affecting incoming traffic and another affecting outgoing traffic. We'll apply this to traffic leaving Serial0.
R1(config)#int s0 R1(config-if)#service ? history Keep history of QoS metrics input Assign policy-map to the input of an interface output Assign policy-map to the output of an interface R1(config-if)#service output CBWFQ Must remove fair-queue configuration first.
Here's a classic "gotcha" - to apply a policy map, you've got to disable WFQ first. The router will be kind enough to tell you that. The exam probably won't be that nice. :) Remove WFQ with the no fair-queue command, then we can apply the policy map.
R1(config-if)#no fair-queue R1(config-if)#service output CBWFQ
To view the contents of a policy map, run show policy-map.
R1#show policy-map CBWFQ Policy Map CBWFQ Class 17210100 Bandwidth 400 (kbps) Max Threshold 50 (packets) Class 17220200 Bandwidth 200 (kbps) Max Threshold 25 (packets)
CBWFQ configuration does have its limits. By default, you can't assign over 75% of an interface's bandwidth via CBWFQ, because 25% is reserved for network control and routing traffic. To illustrate, I've rewritten the previous policy map to double the requested bandwidth settings. When I try to apply this policy map to the serial interface, I get an interesting message:
R1#show policy-map Policy Map CBWFQ Class 17210100 Bandwidth 800 (kbps) Max Threshold 50 (packets) Class 17220200 Bandwidth 400 (kbps) Max Threshold 25 (packets) R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interfac serial0 R1(config-if)#service output CBWFQ Serial0 class 17220200 requested bandwidth 400 (kbps) Available only 358 (kbps)
Why is 358 Kbps all that's available? Start with the bandwidth of a serial interface, 1544 kbps. Only 75% of that bandwidth can be assigned through CBWFQ, and 1544 x .75 = 1158. We can assign only 1158 kbps of a T1 interface's bandwidth in the policy map. We have already assigned 800 kbps to class 17210100, leaving only 358 kbps for other classes. Keep this 75% rule in mind - it's a very common error with CBWFQ configurations. Don't jump to the conclusion that bandwidth 64 is the proper command to use when you've got a 64 kbps link and you want to enable voice traffic to use all of it. Always go with a minimum of 75% of available bandwidth, and don't forget all the other services that will need bandwidth as well! If you really need to change this reserved percentage - and you should have a very good reason before doing so - use the max-reservedbandwidth command on the interface. The following configuration changes the reservable bandwidth to 85%.
R1(config-if)#max-reserved-bandwidth ? <1-100> Max. reservable bandwidth as % of interface bandwidth <cr> R1(config-if)#max-reserved-bandwidth 85
The "reservable bandwidth" referenced in this command isn't just the bandwidth assigned in CBWFQ. It also includes bandwidth allocated for the following: Low Latency Queuing (LLQ) IP Real Time Protocol (RTP) Priority Frame Relay IP RTP Priority Frame Relay PVC Interface Priority Queuing Resource Reservation Protocol (RSVP)
CBWFQ And Packet Drop Earlier in this section, we used the queue-limit command to dictate how many packets a queue could hold before packets would have to be dropped. Below is part of that configuration, and for this particular class the queue is limited to holding 50 packets.
R1(config)#policy-map CBWFQ R1(config-pmap)#class 17210100 R1(config-pmap-c)#bandwidth 400 R1(config-pmap-c)#queue-limit 50
If the queue is full, what happens? No matter how efficient your queuing strategy, sooner or later, the router is going to drop some packets. The default method of packet drop with CBWFQ is tail drop, and it's just what it sounds like - packets being dropped from the tail end of the queue.
Tail drop may be the default, but there are two major issues with it. First, this isn't a very discriminating way to drop traffic. What if this were voice traffic that needed to go to the head of the line? Tail drop offers no mechanism to look at a packet and decide that a packet already in the queue should be dropped to make room for it. The other issue with tail drop is TCP global synchronization. This is a result of TCP's behavior when packets are lost. Packets dropped due to tail drop result in the TCP senders reducing their transmission rate. As the transmission slows, the congestion is reduced. All TCP senders will gradually increase their transmission speed as a result of the reduced congestion - which results in congestion occurring all over again. The result of TCP global synchronization? When the TCP sender simultaneously slow their transmission, that results in underutilization of the bandwidth. When the TCP senders all increase their transmission rate at the same time, the bandwidth is oversubscribed, packets are dropped and must be retransmitted, and the entire process begins all over again. Basically, the senders are either sending too little or too much traffic at any given time. To avoid the TCP Global Synchronization problems, Random Early Detection (RED) or Weighted Random Early Detection (WRED) can be used in place of Tail Drop. RED will proactively drop packets before the queue gets full, but the decision of which packets will be dropped is still
random. WRED uses either a packet's IP Precedence or Differentiated Services Code Point (DSCP) to decide which packets should be dropped. WRED gives the best service it can to packets in a priority queue. If the priority queue becomes full, WRED will drop packets from other queues before dropping any from the priority queue. The random-detect command is used to enable WRED. You know it can't be just that simple, right? You must keep in mind that when WRED is configured as part of a class in a policy map, WRED must not be running on the same interface that the policy is going to be applied to.
R1(config)#policy-map CBWFQ_WRED R1(config-pmap)#class 17210100 R1(config-pmap-c)#bandwidth 400 R1(config-pmap-c)#random-detect R1(config-pmap-c)#random-detect ? dscp parameters for each dscp value dscp-based Enable dscp-based WRED as drop policy exponential-weighting-constant weight for mean queue depth calculation prec-based Enable precedence-based WRED as drop policy precedence parameters for each precedence value <cr>
Both RED and WRED are useful only when the traffic in question is TCPbased. Low Latency Queueing CBWFQ is definitely a step in the right direction, but what we're looking for is a guarantee (or something close to it) that data adversely affected by delays is given the highest priority possible. Low Latency Queuing (LLQ) is an "add-on" to CBWFQ that creates such a strict priority queue for such traffic, primarily voice traffic, allowing us to avoid the jitter that comes with voice traffic that is not given the needed priority queuing. (Cisco recommends that you use an LLQ priority queue only to transport Voice Over IP traffic.) Since we're mentioning "priority" so often here, it shouldn't surprise you to learn that the command to enable LLQ is priority. Before we configure LLQ, there are a couple of commands and services we've mentioned that don't play well with LLQ: WRED and LLQ can't work together. Why? Because WRED is effective only with TCP-based traffic, and the voice traffic that will use LLQ's priority queue is UDP-based. The random-detect and priority commands can't be used in the same class. By its very nature, LLQ doesn't have strict queue limits, so the queue-limit and priority commands are mutually exclusive. Finally, the bandwidth and priority commands are also mutually exclusive. In the following example, we'll create an LLQ policy that will place any UDP traffic sourced from 210.1.1.0 /24 and destined for 220.1.1.0 /24 into the priority queue - IF the UDP port falls in the 17000-18000 or 2000021000 range. The priority queue will be set to a maximum bandwidth of 45 kbps. The class class-default defines what happens to traffic that doesn't match any other classes, and we'll use that class to apply fair
queuing to unmatched traffic.

R2#show access-list Extended IP access list 155 permit udp 210.1.1.0 0.0.0.255 220.1.1.0 0.0.0.255 range 17000 18000 permit udp 210.1.1.0 0.0.0.255 220.1.1.0 0.0.0.255 range 20000 21000 R2(config)#class-map VOICE_TRAFFIC_PRIORITY R2(config-cmap)#match access-group 155
R2(config)#policy-map VOICE R2(config-pmap)#class VOICE_TRAFFIC_PRIORITY R2(config-pmap-c)#priority 45 R2(config-pmap-c)#class class-default R2(config-pmap-c)#fair-queue
R2(config-pmap-c)#interface serial0 R2(config-if)#service-policy output VOICE
Priority Queuing (PQ) The "next level" of queuing is Priority Queuing (PQ), where four predefined queues exist: High, Medium, Normal, and Low. Traffic is placed into one of these four queues through the use of access lists and priority lists. The High queue is also called the strict priority queue, making HQ and LLQ the queueing solutions to use when a priority queue is needed.
These four queues are predefined, as are their limits: High-Priority Queue: 20 Packets Medium-Priority Queue: 40 Packets Normal-Priority Queue: 60 Packets Low-Priority Queue: 80 Packets It won't surprise you to learn that these limits can be changed. Before we configure PQ and change these limits, there's one very important concept that you must keep in mind when developing a PQ strategy. PQ is not round-robin; when there are packets in the High queue, they're going to be sent before any packets in the lower queues. If too many traffic types are configured to go into the High and Medium queues, packets in the Normal and Low queues may never be sent! This is sometimes referred to as traffic starvation or packet starvation. (I personally think it's more like queue starvation, but the last thing we need is a third name for it.)
The moral of the story: When you're configuring PQ, be very discriminating about how much traffic you place into the upper queues. Configuring PQ is simple. The queues already exist, but we need to define what traffic should go into which queue. We can use the incoming interface or the protocol to decide this, and we can also change the size of the queue with this command.
R3(config)#priority-list 1 ? default Set priority queue for unspecified datagrams interface Establish priorities for packets from a named interface protocol priority queueing by protocol queue-limit Set queue limits for priority queues
If we choose to use protocol to place packets into the priority queues, access lists can be used to further define queuing.
R3(config)#priority-list 1 protocol ? aarp AppleTalk ARP appletalk AppleTalk arp IP ARP bridge Bridging cdp Cisco Discovery Protocol compressedtcp Compressed TCP decnet DECnet decnet_node DECnet Node decnet_router-l1 DECnet Router L1 decnet_router-l2 DECnet Router L2 ip IP ipx Novell IPX llc2 llc2 pad PAD links snapshot Snapshot routing support R3(config)#priority-list 1 protocol ip ? high medium normal low R3(config)#priority-list 1 protocol ip high ? fragments Prioritize fragmented IP packets gt Prioritize packets greater than a specified size list To specify an access list lt Prioritize packets less than a specified size tcp Prioritize TCP packets 'to' or 'from' the specified port udp Prioritize UDP packets 'to' or 'from' the specified port <cr>
Let's say we want IP traffic sourced at 20.1.1.0 /24 and destined for 30.3.3.0 /27 to be placed into the High queue. We'd need to write an ACL defining that traffic and call that ACL from the priority-list command.
R3(config)#access-list 174 permit ip 20.1.1.0 0.0.0.255 30.3.3.0 0.0.0.31 R3(config)#priority-list 1 protocol ip high list 174
To place all TCP DNS traffic into the Medium queue, use the protocol option with the priority-list command. We'll use IOS Help to show us the options after the queue name.
R3(config)#priority-list 1 protocol ip medium tcp 53 R3(config)#priority-list 1 protocol ip medium ? fragments Prioritize fragmented IP packets gt Prioritize packets greater than a specified siz list To specify an access list lt Prioritize packets less than a specified size
tcp udp <cr>
Prioritize TCP packets 'to' or 'from' the speci Prioritize UDP packets 'to' or 'from' the speci
R3(config)#priority-list 1 protocol ip medium tcp ? <0-65535> Port number bgp Border Gateway Protocol (179) chargen Character generator (19) cmd Remote commands (rcmd, 514) daytime Daytime (13) discard Discard (9) < output of command edited here > R3(config)#priority-list 1 protocol ip medium tcp 53
As you can see, the router will list many of the more common TCP ports. To place packets coming in on the Ethernet0 interface into the Normal queue, use the interface option with the priority-list command.
R3(config)#priority-list 1 interface ethernet0 normal
Finally, the default queue sizes can be changed with the queue-limit command. This is an odd little command in that if you just want to change one queue's packet limit, you still have to list the values for all four queues - and all four values must be entered in the order of high, medium, normal, and low. In the following example, we'll double the capacity of the Normal queue while retaining all other default queue sizes.
R3(config)#priority-list 1 queue-limit ? <0-32767> High limit R3(config)#priority-list 1 queue-limit 20 ? <0-32767> Medium limit R3(config)#priority-list 1 queue-limit 20 40 ? <0-32767> Normal limit R3(config)#priority-list 1 queue-limit 20 40 120 ? <0-32767> Lower limit R3(config)#priority-list 1 queue-limit 20 40 120 80 ? <cr> R3(config)#priority-list 1 queue-limit 20 40 120 80
Priority queuing is applied to the interface with the priority-group command.

R3(config)#int serial0 R3(config-if)#priority-group 1
show queueing verifies that PQ is now in effect on this interface.

R3#show queueing inter serial0 Interface Serial0 queueing strategy: priority Output queue utilization (queue/count) high/0 medium/0 normal/0 low/0
Show queueing priority displays the priority lists that have been created, along with the changes to each queue's defaults. Note that the queue limit is only shown under Arguments ("Args") if it's been changed. Also, ACLs and port numbers in use are shown on the right.
R3#show queueing priority Current DLCI priority queue configuration: Current priority queue configuration: List 1 1 1 1 1 Queue high high medium normal normal Args protocol ip protocol ip protocol ip interface Ethernet0 limit 120
list 174 tcp port domain
Custom Queueing (CQ) Custom Queueing (CQ) takes PQ one step further - CQ actually allows you to define how many bytes will be forwarded from every queue when it's that queue's turn to transmit. CQ doesn't have the same queues that PQ has, though. CQ has 17 queues, with queues 1 - 16 being configurable. Queue Zero carries network control traffic and cannot be configured to carry additional traffic. By default, the packet limit for each configurable queue is 20 packets and each will send 1500 bytes when it's that queue's turn to transmit.
The phrase "network control traffic" in regards to Queue Zero covers a lot of traffic. Traffic that uses Queue Zero includes Hello packets for EIGRP, OSPF, IGRP, ISIS Syslog messages STP keepalives CQ uses a round-robin system to send traffic. When it's a queue's turn to send, that queue will transmit until it's empty or until the configured byte limit is reached. By configuring a byte-limit, CQ allows you to allocate the desired bandwidth for any and all traffic types. Configuring CQ is basically a three-step process: Define the size of the queues Define what packets should go in each queue Define the custom queue list by applying the list to the appropriate interface Defining The Custom Queue Size To change the capacity of any queue from the default of 20 packets, use the queue-list x queue x limit command. The following configuration changes Queue 1's queue limit to 100 packets.
R3(config)#queue-list 1 queue 1 limit ? <0-32767> number of queue entries
R3(config)#queue-list 1 queue 1 limit 100
Defining The Packets To Be Placed In Each Custom Queue Traffic can be placed into a given queue according to its protocol or incoming interface. If the protocol option is used, an ACL can be used to further define the traffic. In the following example, traffic sourced from network 100.1.1.0 /25 and destined for 200.2.2.0 /28 will be placed into Queue 2.
R3(config)#access-list 0.0.0.15 124 permit ip 100.1.1.0 0.0.0.127 200.2.2.0
R3(config)#queue-list 1 protocol ip ? <0-16> queue number R3(config)#queue-list 1 protocol ip 2 ? fragments Prioritize fragmented IP packets gt Classify packets greater than a specified size list To specify an access list lt Classify packets less than a specified size tcp Prioritize TCP packets 'to' or 'from' the specified port udp Prioritize UDP packets 'to' or 'from' the specified port <cr> R3(config)#queue-list 1 protocol ip 2 list 124
To queue traffic according to the incoming interface, use the interface option with the queue-list command. All traffic arriving on ethernet0 will be placed into Queue 4.
R3(config)#queue-list 1 interface ethernet0 4
To change the amount of bytes a queue will transmit when the round-robin format allows it to, use the byte-count option. Here, we'll double the default for Queue 3.
R3(config)#queue-list 1 queue 3 byte-count 3000
A default queue can also be created as a "catch-all" for traffic that isn't matched by earlier arguments. Since this example has used queues 1 - 4, Queue 5 will be used as the default queue.
R3(config)#queue-list 1 default 5
There's one more common queue-list configuration you should know about. All traffic using a specific port number can be assigned to a specific queue. The configuration isn't the most intuitive I've seen, so let's go through a queue-list command that places all WWW traffic into queue 2. We'll start by looking at all the options for the queue-list command.
R1(config)#queue-list 1 ? default Set custom queue for interface Establish priorities lowest-custom Set lowest number of protocol priority queueing by queue Configure parameters stun Establish priorities unspecified datagrams for packets from a named interface queue to be treated as custom protocol for a particular queue for stun packets
We'll use the protocol option and look at the options there.
R1(config)#queue-list 1 protocol ? aarp AppleTalk ARP appletalk AppleTalk
arp bridge cdp compressedtcp decnet decnet_node decnet_router-l1 decnet_router-l2 ip ipx llc2 pad snapshot
IP ARP Bridging Cisco Discovery Protocol Compressed TCP DECnet DECnet Node DECnet Router L1 DECnet Router L2 IP Novell IPX llc2 PAD links Snapshot routing support
The next step is where the confusion tends to come in. After ip, the next value is the queue number itself. The next value is the protocol type.
R1(config)#queue-list 1 protocol ip ? <0-16> queue number R1(config)#queue-list 1 protocol ip 3 ? fragments Prioritize fragmented IP packets gt Classify packets greater than a specified size list To specify an access list lt Classify packets less than a specified size tcp Prioritize TCP packets 'to' or 'from' the specified port udp Prioritize UDP packets 'to' or 'from' the specified port <cr>
Finally, the port number is configured, which ends the command. I won't show all the port numbers that IOS Help will display, but it's a good idea for test day to know your common port numbers. And I don't mean just the BCRAN test - I mean any Cisco test. You should know them by heart anyway, but five minutes review before any exam wouldn't hurt. :)
R1(config)#queue-list 1 protocol ip 3 tcp ? <0-65535> Port number bgp Border Gateway Protocol (179) chargen Character generator (19) cmd Remote commands (rcmd, 514) R1(config)#queue-list 1 protocol ip 3 tcp 80
Defining The Custom Queue List By Applying It To The Appropriate Interface To apply the custom queue to an interface, use the custom-queue-list command. To verify the configuration, run show queueing custom and show queueing interface serial0. Note that the latter command shows all 17 queues, including the control queue Queue Zero.
R3(config)#interface serial0 R3(config-if)#custom-queue-list 1 R3#show queueing custom Current custom queue configuration: List 1 1 1 1 1 Queue 5 2 4 1 3 Args default protocol ip interface Ethernet0 limit 100 byte-count 3000
list 124
R3#show queueing interface serial0 Interface Serial0 queueing strategy: custom
Output queue utilization (queue/count) 0/0 1/0 2/0 3/0 4/0 5/0 6/0 7/0 8/0 9/0 10/0 11/0 12/0 13/0 14/0 15/0 16/0
Queueing Summary I know from experience that keeping all of these queueing strategies straight is tough when you first start studying them. I strongly advise you to get some hands-on experience configuring queueing, and here's a chapter summary to help you keep them straight. This summary is NOT a substitute for studying the entire chapter! Weighted Fair Queueing (Flow-Based) No predefined limit on the number of queues Assigns weights to traffic flows Low-bandwidth, interactive transmissions are given priority over high-bandwidth transmissions The default queueing strategy for physical interfaces running at or less than E1 speed, AND that aren't running LAPB, SDLC, Tunnels, Loopbacks, Dialer Profiles, Bridges, Virtual Interfaces, or X.25. Priority Queueing Four predefined queues High priority queue traffic is always sent first, sometimes at the expense of lower queues whose traffic may receive inadequate attention Not the default under any circumstances, must be manually configured A maximum of 64 classes can be defined Custom Queueing 17 overall predefined queues; Queue Zero is used for network control traffic and cannot be configured to carry other traffic, leaving 16 configurable queues Uses a round-robin transmission approach A maximum of 64 classes can be defined Not the default under any circumstances, must be manually configured Deciding On A Queueing Strategy The key to a successful queueing rollout is planning. Much like network design, there's no "one size fits all" solution for queueing. This is where your analytical skills come in. You're familiar with the phrase "measure twice, cut once"? You want to measure your queueing strategy at least twice before applying it on your network! This decision often comes down to whether you've got voice traffic on your network. If you do, Priority Queueing is probably your best choice. PQ offers a queue (the High queue) that will always offer the highest priority to traffic - but you must be careful and not choke out traffic in the lower queues at the expense of priority traffic. If there's no delay-sensitive traffic such as voice or video, Custom
Queueing works well, since CQ allows you to configure the size of each queue as well as allocating the maximum amount of bandwidth each queue is allowed to use. In comparison to PW and CQ, Weighted Fair Queueing requires no access-list configuration to determine priority traffic, because there isn't any priority traffic. Both low-volume, interactive traffic as well as highervolume traffic such as file transfers gets a fair amount of bandwidth.
Link, Header, And Payload Compression Techniques There are two basic compression types we're going to look at in this section. First, there's link compression, which compresses the header and payload of a data stream, and is protocol-independent. The second is TCP/IP header compression, and the name is definitely the recipe. When it comes to link compression, we can choose from Predictor or Stacker (STAC). The actual operation of these compression algorithms is out of the scope of this exam, but in short, the Predictor algorithm uses a compression dictionary to predict the next set of characters in a given data stream. Predictor is easier on a router's CPU than other compression techniques, but uses more memory. In contrast, Stacker is much harder on the CPU than Predictor, but uses less memory. There's a third compression algorithm worth mentioning. Defined in RFC 2118, the Microsoft Point-To-Point Compression makes it possible for a Cisco router to send and receive compressed data to and from a MS client. To use any of these compression techniques, use the compress interfacelevel command followed by the compression you want to use. Your options depend on the interface's encapsulation type. On a Serial interface using HDLC encapsulation, stacker is the only option.
R1(config)#int s0 R1(config-if)#encapsulation hdlc R1(config-if)#compress ? stac stac compression algorithm
Using PPP encapsulation on the same interface triples our options.

R1(config)#int s0 R1(config-if)#encap ppp R1(config-if)#compress ? mppc MPPC compression type predictor predictor compression type stac stac compression algorithm <cr>
Keep in mind that the endpoints of a connection using link compression must agree on the method being used. Defined in RFC 1144, TCP/IP Header Compression does just what it says - it compresses the TCP/IP header. Just as obviously, it's protocoldependent. This particular RFC is very detailed, but it's worth reading, particularly the first few paragraphs where it's noted that TCP/IP HC is truly designed for low-speed serial links.
TCP/IP HC is supported on serial interfaces running HDLC, PPP, or Frame Relay. Configuring TCP/IP HC is simple, but it's got one interesting option, shown below with IOS Help.
R1(config-if)#ip tcp header-compression ? passive Compress only for destinations which send compressed headers <cr>
If the passive option is configured, the only way the local interface will compress TCP/IP headers before transmission is if compressed headers are already being received from the destination. Finally, if your network requires the headers to remain intact and not compressed, the payload itself can be compressed while leaving the header alone. Frame Relay allows this through the use of the Frame Relay Forum.9, referred to on the router as FRF.9. This can be enabled on a per-VC basis at the very end of the frame map command. The following configuration would compress the payload of frames sent to 172.12.1.1, but the header would remain intact.
R1(config-if)#frame FRF9 data-stream packet-by-packet map ip 172.12.1.1 110 broad payload-compression ? FRF9 encapsulation cisco proprietary encapsulation cisco proprietary encapsulation
R1(config-if)#frame map ip 172.12.1.1 110 broad payload-compression frf9 ? stac Stac compression algorithm R1(config-if)#frame map ip 172.12.1.1 110 broad payload-compression frf9 stac
Choosing Between TCP/IP HC And Payload Compression The main deciding factor here is the speed of the link. If the serial link is slow - and I mean running at 32 kbps or less - TCP/IP HC is the best solution of the two. TCP/IP HC was designed especially for such slow links. By contrast, if the link is running above 32 kbps and less than T1 speed, Layer 2 payload compression is the most effective choice. What you don't want to do is run them both. The phrase "unpredictable results" best describes what happens if you do. Troubleshooting that is a lot more trouble than it's ever going to be worth. Choose L2 compression or TCP/IP HC in accordance with the link speed, and leave it at that.
:SPMV gnirugifnoc nehw rof tuo hctaw ot sgniht emoS .stseuqer tneilc ot netsil ot PDU sesu SPMV .revres SPMV eht el c y c r e w o p u o y e mit yr e v e s r u c c o g ni d a ol n w o d t a ht d n a ,r e v r es SPMV eht ot dedaoln wod si sNALV ot sesserdda CAM ecruos spam taht revres PTFT eht no esabatad A .emehcs tnemngissa t r o p ci m a n y d si ht ni pl e h ot r e vr e s P T F T a s e s u S P M V .)revreS yciloP pihsrebmeM NALV( SPMV a yb demrofrep si s i h T . s s er d d a C A M ri e ht hti w e c n a dr o c c a ni N A L V a ot d e n gi s s a era sNALV cimanyd ni stsoh dna ,tnemngissa citats s'trop e ht m o r f pi h sr e b m e m N A L V ri e ht tir e h ni s N A L V cit at s ni st s o H
VLANs:
.cimanyd sa strop eht gnirugifnoc erofeb derugifnoc eb ot sah revres SPMV ehT
.t n e m n gi s s a N AL V ci m a n y d a seviecer trop a nehw tluafed yb delbane si tsaFtroP
BCMSN Exam Details You Must Know!
Voice VLANs Quality Of Service Networking Models And Designs STP Basics Switch Security And Tunneling Multilayer Switching Basic Switch Configuration STP Advanced Skills VTP VLANs & Trunking
BCMSN Exam Details You Must Know!

Chris Bryant, CCIE #12933
Overview
www.thebryantadvantage.com
It takes two commands to configure a port to belong to a single VLAN:

switchport mode access Switchport access vlan x (makes the port an access port) (places the port into VLAN x)
If two hosts cant ping and theyre in the same VLAN, there are two settings you should check right away. First, check those speed and duplex settings on the switch ports. Second, check that MAC table and make sure the hosts in question have an entry in the table to begin with.
ISL is Cisco-proprietary and encapsulates every frame before sending it across the trunk. ISL doesnt recognize the native VLAN concept. ISL encapsulation adds 30 bytes total to the size of the frame, potentially making them too large for the switch to handle. (The maximum size for an Ethernet frame is 1518 bytes, and such frames are called giants. Frames less than 64 bytes are called runts.) Dot1q does not encapsulate frames. A 4-byte header is added to the frame, resulting in less overhead than ISL. If the frame is destined for hosts residing in the native VLAN, that header isn't added. For trunks to work properly, the port speed and port duplex setting should be the same on the two trunking ports. Dot1q does add 4 bytes, but thanks to IEEE 802.3ac, the maximum frame length can be extended to 1522 bytes. To change the native VLAN:
SW1(config-if)#switchport trunk native vlan 12
The Cisco-proprietary Dynamic Trunking Protocol actively attempts to negotiate a trunk line with the remote switch. This sounds great, but there is a cost in overhead - DTP frames are transmitted every 30 seconds. To turn DTP off:
SW2(config)#int fast 0/8 SW2(config-if)#switchport nonegotiate
SW2(config-if)#switchport mode trunk SW2(config-if)#switchport nonegotiate
Is there a chance that two ports that are both in one of the three trunking
.tr o p ci m a n y d a tr o p a e k a m ot d el b a s i d eb tsum gniknurT .sNALV lla ot gnoleb tsum yeht noitinifed y b e c ni s , str o p ci m a n y d e d a m e b t o n n a c str o p g ni k n u r T
.cimanyd sa trop a gnirugifnoc erofeb ffo denrut eb tsum erutaef taht ,ytiruces trop htiw derugifnoc si trop a fI
.sutats 'cimanyd' dna 'etaitogenon' neewteb tcilfnoC :detcejer dnammoC
modes will not successfully form a trunk? Yes - if they're both in dynamic auto mode. End-to-end VLANs should be designed with the 80/20 rule in mind, where 80 percent of the local traffic stays within the local area and the other 20 percent will traverse the network core en route to a remote destination.
Place a switch into a VTP domain with the global command vtp domain. In Server mode, a VTP switch can be used to create, modify, and delete VLANs. This means that a VTP deployment has to have at least one Server, or VLAN creation will not be possible. This is the default setting for Cisco switches. Switches running in Client mode cannot be used to create, modify, or delete VLANs. Clients do listen for VTP advertisements and act accordingly when VTP advertisements notify the Client of VLAN changes. Transparent VTP switches don't synchronize their VTP databases with other VTP speakers; they don't even advertise their own VLAN information! Therefore, any VLANs created on a Transparent VTP switch will not be advertised to other VTP speakers in the domain, making them locally significant only. VTP advertisements carry a configuration revision number that enables VTP switches to make sure they have the latest VLAN information. When you introduce a new switch into a VTP domain, you have to make sure that its revision number is zero.
Theory holds that there are two ways to reset a switch's revision number to zero:
1. 2.
. s N A L V l a c oL n i n oit a c ol y b d e p u o r g era sresu ,sNALV dne-ot-dne ni tnatropminu si noitacol lacisyhp elih W .eroc kro wten eht esrevart lliw tnecrep 08 rehto eht elih w ,epocs ni lacol si ciffart fo tnecrep 02 taht emussa sNALV l a c o L . d n i m ni el ur 0 8 / 0 2 e ht hti w d e n gi s e d e r a s N A L V l a c oL
VTP: Change the VTP domain name to a nonexistent domain, then change it back to the original name. Change the VTP mode to Transparent, then change it back to Server.
Reloading the switch won't do the job, because the revision number is kept in NVRAM, and the contents of Non-Volatile RAM are kept on a reload. Summary Advertisements are transmitted by VTP servers every 5 minutes, or upon a change in the VLAN database. Subset Advertisements are transmitted by VTP servers upon a VLAN configuration change. 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. All it takes is the global configuration command vtp pruning. Real-world troubleshooting tip: 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! As RIPv2 has advantages over RIPv1, VTP v2 has several advantages over VTPv1. VTPv2 supports Token Ring switching, Token Ring VLANs, and runs a consistency check. VTPv1 does none of these.
Cisco switches run in Version 1 by default, although most newer switches are V2-capable. If you have a V2-capable switch such as a 2950 in a VTP domain with switches running V1, just make sure the newer switch is running V1. The version can be changed with the vtp version command.
Spanning Tree Basics Switches use their MAC address table to switch frames, but when a switch is first added to a network, it has no entries in its table. The switch will dynamically build its MAC table by examining the source MAC address of incoming frames.
BPDUs are transmitted by a switch every two seconds to the multicast MAC address 01-80-c2-00-00-00. We've actually got two different BPDU types: Topology Change Notification (TCN) Configuration As you'd expect from their name, TCN BPDUs carry updates to the
network topology. Configuration BPDUs are used for the actual STP calculations.
The Root Bridge is the "boss" of the switching network - this is the switch that decides what the STP values and timers will be.
This BID is a combination of a default priority value and the switch's MAC address, with the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-3344-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default, the MAC address is the deciding factor.
Each potential root port has a root port cost, the total cost of all links along the path to the root bridge. The BPDU actually carries the root port cost, and this cost increments as the BPDU is forwarded throughout the network.
The default STP Path Costs are determined by the speed of the port. These path costs have changed from their original values, so you'll be shown both here. 10 MBPS Port: Originally 100, still 100 100 MBPS Port: Originally 10, now 19 1 GBPS Port: Originally 1, now 4 10 GBPS Port: Originally 1, now 2
You have to be careful not to jump to the conclusion that the physically shortest path is the logically shortest path.
Hello Time is the interval between BPDUs, two seconds by default.
Forward Delay is the length of both the listening and learning STP stages, with a default value of 15 seconds.
Maximum Age, referred to by the switch as MaxAge, is the amount of time a switch will retain a 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 secondary switch as well.
There are two commands that will make a non-root bridge the root bridge for the specified VLAN. If you use the root primary command, the priority will automatically be lowered sufficiently for the local switch to become the root. If you use the vlan priority command, you must make sure the priority is low enough for the local switch to become the root.
SW2(config)#spanning-tree vlan 20 root primary SW2(config)#spanning-tree vlan 10 priority <x> Ideally, the root bridge should be a core switch, which allows for the highest optimization of STP.
Advanced Spanning Tree 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.
What if the device connected to a port is another switch? We can't use PortFast to shorten the delay since these are switches, not host devices. What we can use is Uplinkfast.
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. Uplinkfast cannot be configured on a root switch. When Uplinkfast is enabled, it's enabled globally and for all VLANs residing on the switch. You can't run Uplinkfast on some ports or on a per-VLAN basis - it's all or nothing.
Uplinkfast will take immediate action to ensure that the switch cannot become the root switch. First, the switch priority will be set to 49,152, which means that if all other switches are still at their default priority,
they'd all have to go down before this switch can possibly become the root switch. Additionally, the STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches.
The Cisco-proprietary feature BackboneFast can be used to help recover from indirect link failures. BackboneFast uses the Root Link Query (RLQ) protocol.
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. This is done with the following command:
SW2(config)#spanning-tree backbonefast
Root Guard is configured at the port level, and basically disqualifies any switch that is downstream from that port from becoming the root or secondary root. Configuring Root Guard is simple:
SW3(config)#int fast 0/3 SW3(config-if)#spanning-tree guard root
If any BPDU 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.
UDLD detects unidirectional links by transmitting a UDLD frame across the link. 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.
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.
Loop Guard prevents a port from going from blocking to forwarding mode due to a unidirectional link. Once the unidirectional link issue is cleared up, the port will come out of loop-inconsistent state and will be treated as
an STP port would normally be.
BDPU Skew Detection is strictly a notification feature. Skew Detection will not take action to prevent STP recalculation when BDPUs are not being relayed quickly enough by the switches, but it will send a syslog message informing the network administrator of the problem.
Comparison of STP / RSTP post states: STP: disabled > blocking > listening > learning > forwarding RSTP: discarding > learning > forwarding
When a switch running RSTP misses three BPDUs, it will immediately 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 switch will then age out any information regarding the failed switch.
When our old friend IEEE 802.1Q ("dot1q") is the trunking protocol, Common Spanning Tree is in use. With dot1q, all VLANs are using a single instance of STP.
Per-VLAN Spanning Tree (PVST) is just what it sounds like - every VLAN has its own instance of STP running.
Defined by IEEE 802.1s, Multiple Spanning Tree gets its name from a scheme that allows multiple VLANs to be mapped to a single instance of STP, rather than having an instance for every VLAN in the network.
The switches in any MST region must agree of the following: 1. The MST configuration name 2. The MST instance-to-VLAN Mapping table 3. The MST configuration revision number If any of these three values are not agreed upon by two given switches, they are in different regions.
Each and every switch in your MST deployment must be configured
manually.

Note that I could use commas to separate individual VLANs or use a hyphen to indicate a range of them.
Networking Models The core layer is the backbone of your entire network, so we're interested in high-speed data transfer and very low latency - that's it!
Today's core switches are generally multilayer switches - switches that can handle both the routing and switching of data.
Advanced QoS is generally performed at the core layer.
Not only do the distribution-layer switches have to have high-speed ports and links, they've got to have quite a few to connect to both the access and core switches. That's one reason you'll find powerful multilayer switches at this layer - switches that work at both L2 and L3.
End users communicate with the network at the Access layer. VLAN membership is handled at this layer, as well as traffic filtering and basic QoS. Collision domains are also formed at the access layer.
A good rule of thumb for access switches is "low cost, high switchport-touser ratio". Don't assume that today's sufficient port density will be just as sufficient tomorrow!
Switch blocks are units of access-layer and distribution-layer devices.
Core blocks consist of the high-powered core switches, and these core blocks allow the switch blocks to communicate.
Dual core is a network design where the switch blocks have redundant connections to the core block. The point at which the switch block ends and the core block begins is very clear.
In a collapsed core, there is no dedicated core switch. The distribution and core switches are the same.
AAA servers, syslog servers, network monitoring tools, and intruder detection tools are found in almost every campus network today. All of these devices can be placed in a switch block of their own, the network management block.
The Enterprise Edge Block works with the Service Provider Edge Block to bring WAN and Internet access to end users.
Ethernet And Basic Switch Configuration Good old "basic" Ethernet is based on IEEE 802.3, and offers a bandwidth of 10 MB to end users. Ethernet uses UTP cabling (Unshielded Twisted Pair), and this cable type has a length limit of 100 meters.
Fast Ethernet is defined in IEEE 802.3u, and operates at 100 MB. FE can use UTP or fiber-optic wiring. When full-duplex FE is in operation, the effective bandwidth is 200 MBPS, since FE ports can send and receive at the same time.
The cabling you use with your Gig Ethernet ports is going to vary widely. Some of the more common cable types to use with Gigabit Ethernet are Shielded Twisted-Pair (STP), Multimode Fiber (MMF) cable with either a 50- or 62.5 micron core, and Single-Mode Fiber (SMF) with an 8-, 9-, or 50-micron core.
Often referred to in documentation as 10GbE, 10Gig Ethernet will only work on fiber-optic and in full-duplex mode.
To connect your PC to the console port of a switch, you must have a rollover cable. To connect a router, PC, or server to a switch, you'll need a straight-through cable. To connect two switches, you'll need a crossover
cable.
You can assign an IP address to the switch's management interface (by default, the vlan 1 interface).
Telnet connections take place over channels that are basically nonsecure, but using Secure Shell instead will allow a user to connect to the switch over a secure channel and using strong authentication.
To configure a switch to allow only Secure Shell connections:

To configure port autorecovery from err-disabled state, define the causes of this state that should be recovered from without manual intervention, then enter the duration of the ports err-disabled state in seconds with the following commands:
SW2(config)#errdisable recovery cause all SW2(config)#errdisable recovery interval 300
Etherchannels 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.
There are two protocols that can be used to negotiate an etherchannel. The industry standard is the Link Aggregation Control Protocol (LACP), and the Cisco-proprietary option is the Port Aggregation Protocol (PAgP).
PAgP and LACP use different terminology to express the same modes. PAgP has a dynamic mode and auto mode. LACP uses active and passive modes, where active ports initiate bundling and passive ports wait for the remote switch to do so.
To select a particular negotiation protocol, use the channel-protocol command.

SW1(config-if)#channel-protocol ? lacp Prepare interface for LACP protocol pagp Prepare interface for PAgP protocol
The channel-group command is used to place a port into an etherchannel.

SW1(config-if)#channel-group 1 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected
Ports bundled in an Etherchannel need to be running the same speed, duplex, native VLAN, and just about any other value you can think of! If you change a port setting and the EC comes down, you know what to do change the port setting back!
QOS The three basic reasons for configuring QoS are delays in packet delivery, unacceptable levels of packet loss, and jitter in voice and video traffic. Of course, these three basic reasons have about 10,000 basic causes! ;)
Best-effort is just what it sounds like - routers and switches making their "best effort" to deliver data. This is considered QoS, but it's kind of a "default QoS". Best effort is strictly "first in, first out" (FIFO).
Integrated Services is much like the High-Occupancy Vehicle lanes found in many larger cities. If your car has three or more people in it, you're considered a "priority vehicle" and you can drive in a special lane with much less congestion than regular lanes. Integrated Services will create this lane in advance for "priority traffic", and when that traffic comes along, the path already exists.
Integrated Services uses the Resource Reservation Protocol (RSVP) to create these paths. RSVP guarantees a quality rate of service, since this "priority path" is created in advance. With Differentiated Services (DiffServ), there are no advance path reservations and there's no RSVP. The QoS policies are written on the routers and switches, and they take action dynamically as needed. Since each router and switch can have a different QoS policy, DiffServ takes effect on a per-hop basis rather than the per-flow basis of Integrated
Services. A packet can be considered "high priority" by one router and "normal priority" by the next.
Layer 2 switches have a Class Of Service field that can be used to tag a frame with a value indicating its priority. The limitation is that a switch can't perform CoS while switching a frame from one port to another port on the same switch. If the source port and destination port are on the same switch, QoS is limited to best-effort delivery. CoS can tag a frame that is about to go across a trunk.
Classification is performed when a switch examines the kind of traffic in question and comparing it against any given criterion, such as an ACL.
The point in your network at which you choose not to trust incoming QoS values is the trust boundary. The process of changing an incoming QoS value with another value is marking.
Placing the traffic into the appropriate egress queue, or outgoing queue, is what scheduling is all about.
Tail Drop is aptly named, because that's what happens when the queue fills up. The frames at the head of the queue will be transmitted, but frames coming in and hitting the end of the line are dropped, because there's no place to put them.
Random Early Detection (RED) does exactly what the name says - it detects high congestion early, and randomly drops packets in response. This will inform a TCP sender to slow down. The packets that are dropped are truly random, so while congestion is avoided, RED isn't a terribly intelligent method of avoiding congestion.
WRED will use the CoS values on a switch and the IP Precedence values on a router to intelligently drop frames or packets. Thresholds are set for values, and when that threshold is met, frames with that matching value will be dropped from the queue.
Both RED and WRED are most effective when the traffic is TCP-based, since both of these QoS strategies take advantage of TCPs retransmission abilities.
Enabling QoS on a switch is easy enough:

SW2(config)#mls qos
Basic steps to creating and applying a QoS policy: 1. Use an ACL to define the traffic to be affected by the policy. 2. Write a class-map that calls the ACL. 3. Write a policy-map that calls the class-map and names the action to be taken again the matching traffic. 4. Apply the policy-map with the service-policy command.
Traffic should generally be classified and marked at the Access layer. Low Latency Queuing (LLQ) is an excellent choice for core switches. The name says it all - low latency! Weighted Fair Queuing gives priority to low-volume traffic, and highvolume traffic shares the remaining bandwidth.
Multilayer Switching Multilayer switches are devices that switch and route packets in the switch hardware itself.
The first multilayer switching (MLS) method is route caching. This method may be more familiar to you as NetFlow switching. The routing processor routes a flow's first packet, the switching engine snoops in on that packet and the destination, and the switching engine takes over and forwards the rest of the packets in that flow.
A flow is a unidirectional stream of packets from a source to a destination.
Cisco Express Forwarding (CEF) is a highly popular method of multilayer switching. Primarily designed for backbone switches, this topology-based switching method requires special hardware, so it's not available on all L3 switches.
CEF-enabled switches keep a Forwarding Information Base (FIB) that contains the usual routing information - the destination networks, their masks, the next-hop IP addresses, etc - and CEF will use the FIB to make L3 prefix-based decisions. The FIB's contents will mirror that of the IP routing table.
The FIB takes care of the L3 routing information, but what of the L2 information we need? That's found in the Adjacency Table (AT).
On an MLS, a logical interface representing a VLAN is configured like this:

You need to create the VLAN before the SVI, and that VLAN must be active at the time of SVI creation Hosts in that SVIs VLAN should use this address as their gateway. Remember that the VLAN and SVI work together, but they're not the same thing. Creating a VLAN doesn't create an SVI, and creating an SVI doesn't create a VLAN.
The ports on multilayer switches are going to be running in L2 mode by default, so to assign an IP address and route on such a port, it must be configured as an L3 port with the no switchport command.
MLS(config)#interface fast 0/1 MLS(config-if)# no switchport MLS(config-if)# ip address 172.1.1.1 255.255.255.0
To put a port back into switching mode, use the switchport command.
MLS(config)# interface fast 0/1 MLS(config-if)# switchport
CEF has a limitation in that IPX, SNA, LAT, and AppleTalk are either not supported by CEF or, in the case of SNA and LAT, are nonroutable protocols. If you're running any of these on an CEF-enabled switch, you'll need fallback bridging to get this traffic from one VLAN to another.
Defined in RFC 1256, IRDP is commonly used by Windows DHCP clients and several Unix variations, but you do see it in Cisco routers as well.
IRDP is an extension of ICMP - after all, it is the ICMP Router Discovery Protocol!
Defined in RFC 2281, HSRP is a Cisco-proprietary protocol in which routers are put into an HSRP router group. One of the routers will be selected as the primary, and that primary will handle the routing while the other routers are in standby, ready to handle the load if the primary router becomes unavailable. The MAC address 00-00-0c-07-ac-xx is reserved for HSRP, and xx is the group number in hexadecimal. On rare occasions, you may have to change the MAC address assigned to the virtual router. This is done with the standby mac-address command.
The following configuration configures an HSRP router for interface tracking. The routers HSRP priority will drop by 10 (the default decrement) if the line protocol on Serial0 goes down.
R2(config)#interface ethernet0 R2(config-if)#standby 1 priority 105 preempt R2(config-if)#standby 1 ip 172.12.23.10 R2(config-if)#standby 1 track serial0
Defined in RFC 2338, VRRP is the open-standard equivalent of HSRP. VRRP works very much like HSRP, and is suited to a multivendor environment.
As with HSRP and VRRP, GLBP routers will be placed into a router group. However, GLBP allows every router in the group to handle some of the load, rather than having a primary router handle all of it while the standby routers remain idle.
The Active Virtual Gateway (AVG) in the group will send requesting hosts ARP responses containing virtual MAC addresses. The virtual MAC addresses are assigned by the AVG as well, to the AVFs Active Virtual Forwarders.
To add a servers IP address to a server farm:

To create the virtual server for the server farm:

Switch Security & Tunneling You may have heard or read the acronym AAA in Cisco switch documentation. This stands for Authentication, Authorization, and Accounting. A local database of passwords is just one method of authenticating users. We can also use RADIUS servers (Remote Authentication Dial-In User Service, a UDP service) or TACACS+ servers (Terminal Access Controller Access Control System, a TCP service). To enable AAA on a switch:
SW2(config)#aaa new-model
The second A is Authorization. Assigning the right to perform given tasks is Authorization.
Port security uses a hosts MAC address for authentication.

The number of secure MAC addresses defined here includes static and dynamically learned addresses.
One major difference between dot1x port-based authentication and port security is that both the host and switch port must be configured for 802.1x EAPOL (Extensible Authentication Protocol over LANs). Until the user is authenticated, only the following protocols can travel through the port: EAPOL Spanning-Tree Protocol Cisco Discovery Protocol
By default, once the user authenticates, all traffic can be received and transmitted through this port. To configure dot1x, AAA must first be enabled.
SPAN allows the switch to mirror the traffic from the source port(s) to the destination port, the destination port being the port to which the network analyzer is attached. Local SPAN occurs the destination and source ports are all on the same switch. If the source was a VLAN rather than a collection of physical ports, VLAN-based SPAN (VSPAN) would be in effect. RSPAN (Remote SPAN) is configured when source and destination ports are found on different switches. The command monitor session will start a SPAN session, along with allowing the configuration of the source and destination. SPAN Source port notes: A source port can be monitored in multiple SPAN sessions. A source port can be part of an Etherchannel. A source port cannot then be configured as a destination port. A source port can be any port type - Ethernet, FastEthernet, etc. SPAN Destination port notes: A destination port can be any port type. A destination port can participate in only one SPAN session. A destination port cannot be a source port. A destination port cannot be part of an Etherchannel. A destination port doesn't participate in STP, CDP, VTP, PaGP, LACP, or DTP.
To filter traffic between hosts in the same VLAN, we've got to use a VLAN Access List (VACL). A sample configuration follows:
SW2(config)#ip access-list extended NO_123_CONTACT SW2(config-ext-nacl)#permit ip 171.10.10.0 0.0.0.3 172.10.10.0 0.0.0.255 SW2(config)# vlan access-map NO_123 10 SW2(config-access-map)# match ip address NO_123_CONTACT SW2(config-access-map)# action drop SW2(config-access-map)# vlan access-map NO_123 20 SW2(config-access-map)# action forward SW2(config)# vlan filter NO_123 vlan-list 100
Dot1q tunneling allows a service provider to transport frames from different customers over the same tunnel - even if they're using the same VLAN numbers. This technique also keeps customer VLAN traffic segregated from the service provider's own VLAN traffic. The configuration is very simple, and needs to be configured only on the service provider switch ports that are receiving traffic from and sending traffic to the customer switches.
The service provider switches will accept CDP frames from the customer switches, but will not send them through the tunnel to the remote customer site. Worse, STP and VTP frames will not be accepted at all, giving the customer a partial (and inaccurate) picture of its network. To tunnel STP, VTP, and CDP frames across the services provider network, a Layer 2 Protocol Tunnel must be built.
Voice VLANs As is always the case with voice or video traffic, the key here is getting the voice traffic to its destination as quickly as possible in order to avoid jitter and unintelligible voice streams. The human ear will only accept 140 - 150 milliseconds of delay before it notices a problem with voice delivery. That means we've got that amount of time to get the voice traffic from Point A to Point B. 802.1p is a priority tagging scheme that grants voice traffic a high priority. All voice traffic will go through the native voice VLAN, VLAN 0. 802.1q will carry traffic in a VLAN configured especially for the voice traffic. This traffic will have a CoS value of 2.
Some Voice VLAN commands and their options:

MLS(config)# mls qos (globally enables QoS on the switch) (port leading to IP phone) (trust incoming CoS values)
MLS(config)# interface fast 0/5 MLS(config-if)# mls qos trust cos
MLS(config-if)# switchport voice vlan ( x / dot1p / none / untagged)
To configure the phone to accept the CoS values coming from the PC:
MLS(config)# interface fast 0/5 (port leading to IP phone)
MLS(config-if)# switchport priority extend trust
To configure the phone not to trust the incoming CoS value:

MLS(config-if)# switchport priority extend cos 0
We can also make this trust conditional, and trust the value only if the device on the other end of this line is a Cisco IP phone.
SW2(config-if)#mls qos trust device ? cisco-phone Cisco IP Phone SW2(config-if)#mls qos trust device cisco-phone
If you configure that command and show mls qos interface indicates the port is not trusted, most likely there is no IP Phone connected to that port. Trust me, I've been there. :)
SW2#show mls qos interface fast 0/5 FastEthernet0/5 trust state: not trusted trust mode: trust cos COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map Trust device: cisco-phone Copyright 2007 The Bryant Advantage. All Rights Reserved.
lamicedaxeh eht ni ecalp otni llaf srettel eht erehw wonk uoy taht woN
sse ccuS maxE ro F snoi sre vno C r uoY eci tcarP
).ts ac da orb 2 reyaL a si ffff.ffff.ffff fo sserdda CAM a taht rebmemeR( .f htiw 51 ,yllanif dna ,e htiw 41 ,d htiw 31 ,c htiw 21 lamiced eht ;b htiw 11 lamiced eht ;a rettel eht htiw xeh ni detneserper si 01 lamiced ehT .srettel htiw os od eW ?51 ro ,41 ,31 ,21 ,11 ,01 fo eulav a tneserper ylbissop ew nac woh ,neetxis fo stinu sesu xeh ecniS 9 8 2 982 lar e mun xeh ehT 5 1 0 51 lar e mun xeh ehT 1 fO stinU 61 fO stinU 652 fO stinU .)61 x 61( 652 fo stinu owt dna ,neetxis fo stinu thgie ,eno fo stinu enin si xeh ni 982 rebmun ehT .neetxis fo tinu eno dna eno fo stinu evif gnivah sa daer si xeh ni 51 rebmun ehT .61 fo stinu era ereh stinu eht tpecxe ,yaw emas eht hcum daer era srebmun xeH 9 8 2 982 lamiced ehT 5 1 0 51 lamiced ehT 1 fO stinU 01 fO stinU 001 fO stinU !hguone elpmiS .derdnuh eno fo stinu owt dna ,net fo stinu thgie ,eno fo stinu enin si 982 rebmun ehT .net fo tinu eno dna eno fo stinu evif si 51 rebmun eht ,si tahT .evah ew derdnuh eno dna ,net ,eno fo stinu ynam woh setacidni rebmun eht ,tfel ot thgir morf rebmun lamiced a daer uoy fi ,yaw siht ti fo kniht ot pots ylerar ew hguohtlA .net fo stinu htiw flesti snrecnoc ,lamiced ,yad yreve esu ew metsys gnirebmun ehT
. gno r W
?thgir ,b rettel eht htiw 11 lamiced eht gnitneserper htiw devlovni alumrof detacilpmoc ylbidercni emos eb tsum ereht ,lla retfa detadimitni eb yam yeht ,esroW .rebmun a tneserper ylbissop nac tebahpla eht fo rettel a woh ot sa desufnoc netfo era gnirebmun lamicedaxeh ot sremocweN .gnirebmun lamicedaxeh sevlovni taht dna ,hguoht ,maxe ocsiC ruoy no daeh ylgu sti raer thgim taht noisrevnoc rehtona serehT .MSLV dna gnittenbus gnivlovni soiranecs decnavda erom sa llew sa ,yranib- ot-lamiced dna lamiced-ot-yranib sa hcus ,snoisrevnoc cisab sedulcni sihT .htam yranib retsam tsum ,EICC eht ot ANCC eht morf ,setadidnac noitacifitrec ocsiC
Performing Hexadecimal Conversions

How To Perform Hexadecimal Conversions
Chris Bryant, CCIE #12933 Back To Index www.thebryantadvantage.com
on evah lluoy ,ta devirra saw rewsna hcae woh yltcaxe wonk dna ,snoitseuq eseht htiw ecitcarp uoy ecnO .slliks noisrevnoc lamicedaxeh ruoy ecitcarp uoy pleh lliw taht snoitseuq ecitcarp 02 nettirw evah I
491 = 2 + 291 2 eulaV 1 lamiceD fo stinU
21 61 fo stinU
0 652 fo stinU
2c reb muN lamicedaxeH
.491 erugif lamiced eht su sevig sihT .2 fo stinu owt dna ,61 fo stinu 21 evah ew snaem sihT .21 rebmun lamiced eht stneserper c rettel eht taht wonk won eW ?2c erugif xeh eht tuoba tahW 423 = 4 + 46 + 652 eulaV lamiceD 4 4 1 fo 61 stinU fo stinU 1 652 fo stinU 441 reb muN lamicedaxeH
.423 erugif lamiced eht su sevig sihT .4 fo stinu ruof dna ,61 fo stinu ruof ,652 fo tinu eno evah eW ?tnelaviuqe lamiced eht si tahw ,441 rebmun xeh eht neviG .relpmis neve era snoisrevnoc lamiced- ot-xeH 241 2 eulaV 1 lamicedaxeH fo stinU 4 61 fo stinU 223 1 rebmuN lamiceD 652 fo stinU
.2 fo stinu 2 dna ,23 fo stinu ruof ,652 fo tinu eno 241 erugif xeh eht si 223 lamiced eht fo tnelaviuqe xeh ehT .eno fo stinu owt ro ,2 sevael taht ;66 ni 61 fo stinu ruof era erehT .66 sevael taht ;652 fo tinu eno si erehT .melborp on si xeh ot 223 lamiced eht gnitrevnoC b1 )11( B eulaV 1 lamicedaxeH fo stinU 1 61 fo stinU 72 0 rebmuN lamiceD 652 fo stinU
.s nois rev noC lamicedaxeH lamiceD mrofreP oT thgiR oT tfeL morF kroW
.eno fo stinu 11 ,neetxis fo tinu eno b1 htiw xeh ni detneserper si sihT .eno fo stinu 11 sevael taht ;lamiced siht ni 61 fo tinu eno si ereht taht ees nac uoY ?xeh ot 72 lamiced eht trevnoc uoy dluow woH .ecitcarp uoy fi xeh ot lamiced dna lamiced ot xeh gnitrevnoc elbuort elttil evah lluoy ,dlrow gnirebmun
10111001 :xeh ot gnirts yranib gniwollof eht trevnoC .91 10111010 :xeh ot gnirts yranib gniwollof eht trevnoC .81 11110011 :xeh ot gnirts yranib gniwollof eht trevnoC .71 11001100 :xeh ot gnirts yranib gniwollof eht trevnoC .61 47 :yranib ot rebmun xeh gniwollof eht trevnoC .51 c3 :yranib ot rebmun xeh gniwollof eht trevnoC .41 9a :yranib ot rebmun xeh gniwollof eht trevnoC .31 21 :yranib ot rebmun xeh gniwollof eht trevnoC .21 24 :yranib ot rebmun xeh gniwollof eht trevnoC .11 5 43 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .01 30 91 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .9 9 14 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .8 4 87 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .7 31 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .6 4 e3 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .5 b 41 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .4 9 a2 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .3 1f :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .2
c1 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .1
33921# EIC C ,tn ayrB sirhC ,sseccus ruoy oT ! k c u l f o t s eB .smaxe ocsiC ruoy no snoisrevnoc lamicedaxeh htiw melborp
_ _____________________________________________________
186 = 9 + 061 + 215 .1 f o stinu enin dn a ,61 f o stinu net ,6 52 f o stinu o wt er a erehT
61
652
9 a2 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .3

_________________________________________________
142 = 1 + 042 .1 f o tinu 1 dna 61 f o stinu neetfif er a erehT
61
652
1f :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .2

_________________________________________________________________________
.82 = 21 + 61 .1 fo stinu evlewt dna 61 fo tinu eno si erehT

1 61
652
c1 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .1

_________________________________________________________________________
61
652
:trahc siht esu lliw srebmun lamicedaxeh gnivlovni snoisrevnoC )! tsacdaorb 2 reyaL a si ffff.ffff.ffff taht rebmemer dnA( .51 = F ,41 = E ,31 = D ,21 = C ,11 = B ,01 = A :gnirebmun lamicedaxeh ni srettel fo gninaem eht weiver s'tel ,deveihca erew yeht woh dna srewsna eht hguorht og ew erofeB
10101011 :xeh ot gnirts yranib gni wollof eht trevnoC.02
a f
9 1
_________________________________________________
.re b mun eht gnisse rpxe n eh w se ore z gni da el yna ev ah ot y rass ecen t on s'tI ." d" si re wsn a ehT
61
652
xeh
el gnis fo
hti w
"31 "
reb mun ?31
eht
. meht
neetri h T
.eruS
l a mice d
eht
61
652
.oN
?31 l amice d eht ni 61 f o stinu yn a ereht erA
61
652
.oN
?31 lamic ed eht ni 652 f o stinu yn a er eht erA
tfel m orf tr ah c em as eht hti w k ro w ,xeh ot l amice d gnitrevn oc n ehW
31 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .6

_ _____________________________________________________
699 = 4 + 422 + 867 .1 f o stinu ru of dn a ,61 f o stinu neetru of ,652 f o stinu eerht er a erehT
61
652
4 e3 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .5
_ _____________________________________________________
133 = 11 + 46 + 652 .1 fo stinu 11 dn a ,61 f o stinu ru of ,652 f o tinu en o si erehT
61
652
b 41 :lamiced ot rebmun lamicedaxeh gniwollof eht trevnoC .4
?retc arahc sser pxe ni 1 fo ew w oh yn a re b me meR e reht e rA
stinu
.thgir ot
a htiw , meht f o xis , seY
?111 la mi ced eht ni 61 f o stinu yn a e reht erA
61
652
.111 fo rednia mer a sev ael sih T , meht f o nev es , seY
?3091 la mic ed eht ni 6 52 f o stinu yn a ereht erA
30 91 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .9

_ _____________________________________________________
61
652
r eb mun
xeh
e ht
dna
,re dni ame r
eht
fo
61
652
a hti w ,m eht f o net ,s eY
61
652
,en o ,se Y
914 :lamicedaxeh ot rebmun lamiced gniwollof eht trevnoC .8

_________________________________________________
."013 " re bmun xeh eht si tluse r l anif eh T
61
652
.stols gninia mer eht ni "0" a ec alp nac ew ,re dni am er on si ereht ecniS .61 ni 61 fo tinu en o s' ereht ,ylsu oi vbO
61 = 867 - 487
61
652
tcart bu s dn a ,t ols 652 eht ni "3 " a ecal P fo eerht ,seY ?487 lamice d eht ni 652
7 1
.2971 gnilat ot
3 0
.re wsna eht si "3 a1" er ac se kat en o fo stinu eerhT
.eerht f o re dni amer
.361 f o r ednia mer a htiw
.487 mo rf 867 .867 fo l at ot a rof , meht fo stinu yna ereht e rA
"21"
r ebmun
x eh
ehT
.l a mice d
ot
r eb mun
x eh
eht
t revn oc
,tsriF
21 :yranib ot rebmun xeh gniwollof eht trevnoC .21

_______________________________________________________
01000010 :rewsna tcerroc ehT
0
1
:yr ani b otni 66 l amice d eht trevn oc ot w oh gni wohs tr ah c ruo s'er eH .yr ani b otni la mic ed t aht tre vn oc ot t og e v'e w w oN
.l amice d ruo evah ew ,66 = 2 + 46 ecniS x eh ni "24 " .1 f o stinu o wt dn a 61 fo stinu ru of ev ah ew sn aem w onk eW .la mic ed ot r eb mun x eh eht trevn oc ,tsriF

_________________________________________________
61
652
."951" rebmun xeh eht su evig enin fo stinu eniN 5

1 61 .9 f o re dni am er a hti w ,meht f o evif ,se Y ?98 ni 61 f o stinu yn a ereht erA
1
652
61
652
re dni ame r a hti w , en o , eruS
?543 ni 652 fo stinu yna er eht erA

_________________________________________________
61
652
si "f67" re wsna l anif eht ,1 f o stinu 51 tnes erp er ot "f " rettel eht gnisu yB
61
652
128 64 32 16 8 4 66 0 1 0 0 0 0 7 7 1
1
.98 fo .d eveihca .51 f o re dni amer
2 1 6 6
:yranib otni 611 lamiced eht trevnoC .)4 + 211( 611 lamiced eht ni gnitluser ,1 fo stinu ruof dna 61 fo stinu neves evah eW .lamiced ot rebmun xeh eht trevnoc ,tsriF

128 64 32 16 8 4 0 0 1 1 1 1 2 0
0 1
:yranib otni 06 lamiced eht trevnoC .)21 + 84( 06 fo latot a su gnivig ,)21 = c( 1 fo stinu 21 dna 61 fo stinu eerht evah eW .lamiced ot rebmun xeh eht trevnoc ,tsriF
c3 :yranib ot rebmun xeh gniwollof eht trevnoC .41

_______________________________________________________

128 64 32 16 8 4 1 0 1 0 1 0 2 0
1 1
:yr ani b ot 961 la mic ed eht trevn oc w oN 961 = 9 + 06 1 ni 01 sl auqe "a " .1 f o stinu enin dn a 61 f o stinu 01 ev ah e w ,x eh ecni S .l amice d ot r eb mun xeh eht trevn oc ,tsriF
9a :yranib ot rebmun xeh gniwollof eht trevnoC .31

_______________________________________________________

128 64 32 16 8 4 0 0 0 1 0 0 2 1
0 1
:11 n oits euQ ni desu e w tr ahc e m as eht esU .yr ani b otni l amice d t aht trevn oc ot w oN .81 si siht ,l amice d ni ;en o f o stinu o wt dna neetxis f o tinu eno set aci dni
60
169
18
128 64 32 16 8 4 0 1 1 1 0 1
2 0
0 1
The correct answer: 01110100
116
_______________________________________________________
Now convert the decimal 207 to hex. Are there any units of 256 in the decimal 207? No. Are there any units of 16 in the decimal 207? Yes, twelve of them, for a total of 192 and a remainder of 15. Twelve is represented in hex with the letter "c". Fifteen units of one are expressed with the letter "f", giving us a hex number of "cf".
1 61 652
Now convert the decimal 93 to hex. There are no units of 256, obviously. How many units of 16 are there? Five, for a total of 80 and a remainder of 13. We express the number 13 in hex with the letter "d". The final result is the hex number "5d".
1 61 652
As always, convert the binary string to decimal first:
10111001 :xeh ot gnirts yranib gniwollof eht trevnoC .91
11001100 :xeh ot gnirts yranib gniwollof eht trevnoC .61 11110011 :xeh ot gnirts yranib gniwollof eht trevnoC .71 10111010 :xeh ot gnirts yranib gniwollof eht trevnoC .81
:l amice d ot gnirts y ranib eht trevn oc ll 'e w ,tsriF
To finish answering the question, convert the decimal 51 to hex. Are there any units of 256 in the decimal 51? No. Are there any units of 16 in the decimal 51? Yes, three, for a total of 48 and a remainder of three. Three units of one gives us the hex number "33".
:l amice d ot gnirts y ranib eht trevn oc ll 'e w ,tsriF
la mic eD
39
128 64 32 16 8 4 2 0 1 0 1 1 1 0
1 1
la mic eD
7 02
128 64 32 16 8 4 2 1 1 0 0 1 1 1
1 1
la mic eD
:l amice d ot gnirts yr ani b eht trevn oc ,tsriF
15
f d
128 64 32 16 8 4 2 0 0 1 1 0 0 1
1 1
61
652
Now convert the decimal 157 to hex. There are no units of 256. How many units of 16 are there in the decimal 157? Nine, for a total of 144 and a remainder of 13. You know to express the number 13 in hex with the letter "d", resulting in a hex number of "9d". 256 16 1
9 d
First, convert the binary string to decimal:
Now convert the decimal 213 to hex. No units of 256, but how many of 16? Thirteen of them, with a total of 208 and a remainder of 5. Again, the number 13 in hex is represented with the letter "d", and the five units of one give us the hex number "d5".
10101011 :xeh ot gnirts yranib gniwollof eht trevnoC .02
3 12
128 64 32 16 8 4 2 1 1 0 1 0 1 0
1 Decimal 1
7 51
5
128 64 32 16 8 4 2 1 0 0 1 1 1 0
1 Decimal 1
1 61 652
.selur gniwollof eht yb ediba ot eerga uoy ,sbal etomer ym ot gnitcennoc yB
.se it ila geL ob m uj ob m u m la usU ehT toN eryehT .ylluferaC seluR gniwolloF ehT daeR esaelP
.ecived siht fo noitarugifnoc eht egnahc ot deen on si erehT .htiw etacinummoc ot tenleT gnisu eb yllautca lliw uoy retuor eht staht ;revres ssecca eht si retuor dnoces ehT ).noitces pleH baL emoH eht kcehc dna etisbew ym tisiv ,hctiws yaler emarf a fo noitarugifnoc eht ees ot ekil duoy fI( .derugifnocerp si hctiws yaler emarf ruoY .bal ecitcarp a ni duolc yaler emarf a evah ot elbissop ti sekam hcihw ,hctiws yaler emarf a sa gnitca retuor a si tsrif ehT .ereh nwohs ton era taht dop ruoy ni sretuor ocsiC lanoitidda owt era erehT .koobkrow bal siht ni esu lluoy ygolopot krowten eht ta kool a ekat stel ,dnim ni taht htiW .noitca ni yroeht eht ees ot lativ sti tub ,yroeht eht nrael ot daer ot tog evuoY .meht esu ot si seigolonhcet ocsiC tuoba nrael ot yaw tseb ehT .seiduts ocsiC erutuf ruoy rof noitadnuof dilos a uoy evig dna ,maxe NSMCB eht ssap ot deen lluoy slliks eht lla retsam uoy pleh lliw koob siht ,slatneR kcaR PNCC / ANCC ym htiw noitanibmoc ni desU !koobkroW baL NSMCB egatnavdA tnayrB ehT ot emocleW
! e mocl e W
The Bryant Advantage BCMSN Lab Workbook
Multilayer Switch Commands Switch Security General Switch Commands SPAN HSRP STP VLAN, VTP, And Trunking Connecting And Navigating To Your Pod Chris Bryant, CCIE #12933
One Final Bonus Command
BCMSN Lab Workbook

Back To Index www.thebryantadvantage.com
Overview
.detacitnehtua eb ton lliw uoy dna ecaps llun a dnes lliw siht ;rehtie gniretne fo dne eht ta rab ecaps eht tih ton oD .2 . dro w s sa p a neht , e manr esu a r of detp m or p e b lliw u oY .1 :ni gniggol rof spit wef A
Password:
.sx eht fo ecalp ni sserdda PI eht htiw ,x.x.x.x tenlet epyt ro ,tenlet tfosorciM otni og ot tenlet epyt nac uoy ,tpmorp :C ruoy morF .tpmorp :C ruoy ot tuo gniog yb tenleT esu ,gnitacitnehtua elbuort evah dna lanimreTrepyH esu uoy fI .tenleT htiw elbuort evah snoisrev emos nees evI tub ,ekil uoy fi lanimreTrepyH esu nac uoY .revres ssecca ruoy ot tcennoc ot noisrev tenleT yna esu nac uoY .snoitav reser kcar ruoy ekam uoy nehw uoy ot deliame eb lliw noitamrofni noitcennoc ruoY .revres ssecca ruoy ot tenleT ot deen lluoy ,tsriF !ysae si sehctiws 0592 dna sretuor ocsiC fo dop ruoy htiw detrats gnitteG
doP ruo Y oT gni tcen noC
!u oy knahT .enif si esac rewol ro esac reppU .skram noitatouq eht tuohtiw ,ancc ro ocsic sdrowssap eht esu TSUM uoy ,revewoH .sdrowssap tenlet dna ,drowssap elosnoc ,drowssap elbane ,terces elbane ruoy ecitcarp ot emoclew naht erom era uoY .3 .hctiws ro retuor yna fo retsiger noitarugifnoc eht egnahc ton oD .2 .erutuf eht ni sdop eht gnitner morf detibihorp eb osla lliw uoY .nevig eb ton lliw dnufer a dna ,noisses ruoy dne yam os gnioD .yaw yna ni revres ssecca eht fo noitarugifnoc eht egnahc ton oD .1
C:\>telnet 100.100.100.100
OR:
Password:
Username:
User Access Verification
Microsoft Telnet> open 100.100.100.100 (put the IP address you were sent in email in place of the 100.100.100.100)
Escape Character is 'CTRL+]'
Welcome to Microsoft Telnet Client
Username: User Access Verification C:\> telnet
.2WS dna ,1WS ,3R ,2R rof ssecorp eht taepeR .revres ssecca eht ta kcab thgir eruoy nehT .x tih dna syek esoht esaeler neht ,)!eno taht wonk lla ew( eteled-tla-lrtc retne duoy yaw emas eht 6-tfihs-lrtc tih uoY .ti tuoba gnikniht tuohtiw ti gniod eb lluoy gnol erofeb tub ,tsrif ta drawkwa elttil a si ekortsyek sihT >X < >6 TFIHS LRTC< :si ti ereH .revres ssecca eht morf kcab og ot gnisu eb lluoy taht ekortsyek gib eht nrael ot deen uoy ,woN .1R rof tpmorp eht ees neht lluoY .niaga yek retnE eht tih ,nepO drow eht ees uoy nehW :etoN
R1# THE_BRYANT_ADVANTAGE_16x#r1 Trying R1 (100.1.1.1, 2001)... Open
:tp m or p eht t a 1R epyT
.owt ro etunim a uoy ekat ylno lliw ti tub ,ssecorp gnol a ekil sdaer sihT .revres ssecca ruoy morf ecived hcae ot tcennoc ot gniog eruoy ,deraelc era senil eht taht woN .ti tpecca ot yek retne ruoy tih tsuj ,eciohc ]mrifnoc[ eht ees uoy nehW
THE_BRYANT_ADVANTAGE_16x# line 05 line 01 line 04 line 03 line 02 THE_BRYANT_ADVANTAGE_16x#clear [confirm] [OK] THE_BRYANT_ADVANTAGE_16x#clear [confirm] [OK] THE_BRYANT_ADVANTAGE_16x#clear [confirm] [OK] THE_BRYANT_ADVANTAGE_16x#clear [confirm] [OK] THE_BRYANT_ADVANTAGE_16x#clear [confirm] [OK] THE_BRYANT_ADVANTAGE_15x# Password: User Access Verification
.secived rehto eht ot gnidael senil eht raelc ,tsriF .ecived hcae ssecca ot woh sereH .revres ssecca siht ot detcennoc lla era sehctiws ocsiC owt dna sretuor eerht ruoY
:revr es ssec ca eht n o ed o m cexe degelivirp otni tup eb lluoy ,drowssap dna emanresu ruoy gniretne retfA .stcudorp tfosorciM tsom ot ni gniggol nehw od uoy sa ,sksiretsa ees ton lliw uoY .tluafed ocsiC a stahT .drowssap dna emanresu ruoy retne uoy nehw EVOM TON LLIW rosruc ehT .3
R1# < Use above keystroke to go back to access server > THE_BRYANT_ADVANTAGE_16x#r2 Trying R2 (100.1.1.1, 2002)... Open R2# < Use above keystroke to go back to access server > THE_BRYANT_ADVANTAGE_16x#r3 Trying R3 (100.1.1.1, 2003)... Open R3# < Use above keystroke to go back to access server > THE_BRYANT_ADVANTAGE_16x#sw1 Trying SW1 (100.1.1.1, 2004)... Open sw1# < Use above keystroke to go back to access server > THE_BRYANT_ADVANTAGE_16x#sw2 Trying SW2 (100.1.1.1, 2005)... Open sw2# < Use above keystroke to go back to access server >
THE_BRYANT_ADVANTAGE_16x#
THE_BRYANT_ADVANTAGE_16x#1 [Resuming connection 1 to r1 ... ] R1# THE_BRYANT_ADVANTAGE_16x#2 [Resuming connection 2 to r2 ... ] R2# THE_BRYANT_ADVANTAGE_16x#3 [Resuming connection 3 to r3 ... ]
R3# THE_BRYANT_ADVANTAGE_16x#4 [Resuming connection 4 to sw1 ... ] sw1# THE_BRYANT_ADVANTAGE_16x#5 [Resuming connection 5 to sw2 ... ] sw2# THE_BRYANT_ADVANTAGE_16x#
no emit ruoy fo erom gnidneps eb ll'uoy ,maxe gnihctiws a si siht ecniS !ti ot si ereht lla stahT .tpmorp elbane eht ot uoy teg lliw tahT .egassem noitcennoc gnimuser eht ees uoy retfa niaga retne tih ot tegrof tnoD
.w ole b nw ohs s a ,r evres ssecc a eht no ereh e es uoy srebmun eht epyt tsuj ;niaga ecived eht fo eman eritne eht epyt tnoD 2 WS :5 1 WS :4 3R :3 2R :2 1R :1 :ecived hcae ot teg ot srebmun eseht epyt tsuj ,revres ssecca eht tA .ecived hcae ot kcab og ot noitcennoc eht fo rebmun eht ylno esu lliw uoy ,snoitcennoc esoht detaerc evuoy taht woN .ti tuoba gnikniht neve tuohtiw ekortsyek taht gnisu eb lluoy ,gnol erofeB .rehtona ot retuor eno morf teg ot revres ssecca eht ot kcab gnimoc syawla eruoy ,rebmemeR
.liame noitamrifnoc noitavreser ruoy ni dedulcni eb lliw srebmun enohp NDSI .meht esu ot emoclew er'uoy tub ,koob bal siht ni desu ton er'yeht esuaceb nwohs ton era snoitcennoc esehT .3R dna 1R neewteb noitcennoc laires tcerid a s'ereht dna ,rotalumis NDSI na ot detcennoc osla era 2R dna 1R .21/0 dna 11/0 tsaf aiv 1WS ot dna 3/0 tsaf aiv 3R ot detcennoc si 2WS .21/0 dna 11/0 tsaf aiv 2WS ot dna 2/0 tsaf aiv 2R ot detcennoc si 1WS .0tenrehtE aiv 2WS ot dna 0laireS aiv duolc yaler emarf eht ot detcennoc si 3R .0tenrehtE aiv 1WS ot dna 0laireS aiv duolc yaler emarf eht ot detcennoc si 2R .0laireS aiv duolc yaler emarf eht ot detcennoc si 1R .bal PRSH eht ni sretuor eht esu lliw uoy ,revewoH !sehctiws eht
Create the VTP domain CCNP on SW1. Run show vtp status on SW1 and SW2 to verify.
Port Fa0/11 Fa0/12 SW1#show interface trunk
Verify the trunk between SW1 and SW2 with show interface trunk.
SW1(config)#vtp domain CCNP Changing VTP domain name from NULL to CCNP
VLANs, VTP, and Trunks
Mode desirable desirable
Encapsulation 802.1q 802.1q
Status trunking trunking
Native vlan 1 1
SW1#show vtp status VTP Version Configuration Revision Maximum VLANs supported locally Number of existing VLANs VTP Operating Mode VTP Domain Name SW2#show vtp status VTP Version Configuration Revision Maximum VLANs supported locally Number of existing VLANs VTP Operating Mode VTP Domain Name
: : : : : :
2 0 64 5 Server CCNP
: : : : : :
2 0 64 5 Server CCNP
On SW2, change the trunking mode on fast 0/11 and fast 0/12 to dynamic auto, then to unconditional trunking. Note that the trunk doesn't come down.
SW2(config)#int fast 0/11 SW2(config-if)#switchport mode ? access Set trunking mode to ACCESS unconditionally dynamic Set trunking mode to dynamically negotiate access or trunk mode trunk Set trunking mode to TRUNK unconditionally SW2(config-if)#switchport mode dynamic auto SW2(config-if)#switchport mode trunk SW2(config)#int fast 0/12 SW2(config-if)#switchport mode trunk
Both switches will be VTP servers, so create VLAN 32 on either one. Run show vlan brief to verify.
SW2(config)#vlan 32 SW2#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 32 VLAN0032 active
Change the native VLAN to VLAN 32 with the switchport trunk native vlan 32 command. You'll need to configure this on fast 0/11 and fast 0/12 on both switches. Be prepared for the trunk to come down during the process.
SW1(config)#int fast 0/11 SW1(config-if)#switchport trunk native vlan 32 SW1(config-if)#int fast 0/12 SW1(config-if)#switchport trunk native vlan 32 SW2(config)#int fast 0/11 SW2(config-if)#switchport trunk native vlan 32 SW2(config-if)#int fast 0/12 SW2(config-if)#switchport trunk native vlan 32
Run show interface trunk on both switches to ensure that the trunk is up and that the native VLAN was successfully changes. (This is going to sound strange, but get into the habit of checking both switches with show interface trunk. Every once in a while, you'll get a response to this command on one switch that doesn't match up to the other switch's
response.)
SW2#show interface trunk Port Fa0/11 Fa0/12 Mode on desirable Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 32 32
SW1#show int trunk Port Fa0/11 Fa0/12 Mode desirable desirable Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 32 32
On SW1, disable Dynamic Trunking Protocol (DTP) on both fast 0/11 and 0/12.
SW1(config)#int fast 0/11 SW1(config-if)#switchport nonegotiate Command rejected: Conflict between 'nonegotiate' and 'dynamic' status SW1(config-if)#switchport mode trunk SW1(config-if)#switchport nonegotiate SW1(config-if)#int fast 0/12 SW1(config-if)#switchport mode trunk SW1(config-if)#switchport nonegotiate
As you quickly noticed, you can't turn DTP off when the port is in any dynamic state. Making the port an unconditional trunk port with switchport mode trunk allowed us to turn DTP off. Prevent traffic for VLAN 1000 from being sent over fast 0/11 and 0/12 on SW1 and SW2 with the switchport trunk allowed vlan command. Verify with show interface trunk.
SW1(config)#int fast 0/11 SW1(config-if)#switchport trunk allowed vlan except 1000 SW1(config-if)#int fast 0/12 SW1(config-if)#switchport trunk allowed vlan except 1000 SW1#show interface trunk Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12 Mode on on Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 32 32
Vlans allowed on trunk 1-999,1001-4094 1-999,1001-4094
Add the VLANs right back with the same command. Verify again with show interface trunk.
SW1(config)#int fast 0/11 SW1(config-if)#switchport trunk allowed vlan add 1000 SW1(config-if)#int fast 0/12 SW1(config-if)#switchport trunk allowed vlan add 1000
Feel free to experiment with this command - add, remove, and the other options. The more you use it, the better you'll be with it on the exam. Run show vtp status on both switches and note the configuration revision number.
SW1#show vtp status
VTP Version Configuration Revision SW2#show vtp status VTP Version Configuration Revision
: 2 : 1
: 2 : 1
On SW2, delete VLAN 32. Run show vlan brief on SW2 to verify, then show vtp status to note the configuration revision number.
SW2#show vtp status VTP Version Configuration Revision : 2 : 2
The revision number moved up to 2, as expected. Run both commands on SW1 as well.
SW1#show vtp status VTP Version Configuration Revision : 2 : 2
Since we just deleted our native VLAN, it would be a good idea to set that value back to VLAN 1! On SW1, use the switchport native vlan command to do so. Be prepared to see an error message such as the one seen below.
SW1(config)#int fast 0/11 SW1(config-if)#switchport trunk native vlan 1 SW1(config)#int fast 0/12 SW1(config-if)#switchport trunk native vlan 1 05:32:33: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/11 (1), with SW2 FastEthernet0/11 (32). 05:32:33: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/12 (1), with SW2 FastEthernet0/12 (32).
The numbers in the parens can be very helpful if you don't spot the problem right away. The first paren is the native VLAN according to the local switch port, and the second paren is the native VLAN according to the remote switch port. On SW2, use the no switchport trunk native vlan 32 command on both trunk ports. Run show interface trunk to verify the trunk is up and running.
SW2(config)#int fast 0/12 SW2(config-if)#no switchport trunk native vlan 32 SW2(config-if)#int fast 0/11 SW2(config-if)#no switchport trunk native vlan 32 SW2#show int trunk Port Fa0/11 Fa0/12 Mode on on Encapsulation 802.1q 802.1q Status Native vlan trunking 1 trunking 1
The trunk is up and the native VLAN has reverted back to VLAN 1. Put SW2 into VTP Client mode and try to create a VLAN on it.
SW2(config)#vtp mode client Setting device to VTP CLIENT mode. SW2(config)#vlan 50 VTP VLAN configuration not allowed when device is in CLIENT mode.
Just one more reminder about that little fact. :) Put the switch back into server mode.
SW2(config)#vtp mode server Setting device to VTP SERVER mode
On SW2, enable vtp pruning. Then check on R1 and see if pruning shows as enabled on that switch as well.
SW2(config)#vtp pruning Pruning switched on SW1#show vtp status VTP Version Configuration Revision Maximum VLANs supported locally Number of existing VLANs VTP Operating Mode VTP Domain Name VTP Pruning Mode
: : : : : : :
2 4 64 6 Server CCNP Enabled
To finish this section, let's get some practice in with the interface range command. I can't stress this enough - this command can save you a lot of time on Cisco exams as well as when working on production networks. I urge you to get some practice in with this command and be comfortable with it. Configure ports 0/8 - 10 on both switches with the interface range command. Enable portfast on all three ports, set the speed to 100 MBPS, and the duplex to full.
SW1(config)#interface range fast 0/8 - 10 SW1(config-if-range)#spanning portfast SW1(config-if-range)#speed 100 SW1(config-if-range)#duplex full SW2(config)#interface range fast 0/8 - 10 SW2(config-if-range)#spanning portfast SW2(config-if-range)#speed 100 SW2(config-if-range)#duplex full
Spanning Tree Protocol Keep in mind that the MAC addresses you see in this lab are NOT necessarily going to be the ones you see during your time on my racks, and they won't be the same ones you have in your home lab. When we're going back and forth between root bridges in this exercise, they won't necessarily be the same ones that are the root bridges when you run the labs. Run show spanning-tree vlan 1 on both switches and identify the root.
SW1#show spanning vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000e.d7f5.a040 This bridge is the root Hello Time 2 sec Max Age 20 sec
On the nonroot bridge, run show spanning vlan 1 and note the port costs .
SW2#show spanning vlan 1 Interface ---------------Fa0/11 Fa0/12 Role ---Root Altn Sts Cost Prio.Nbr Type --- --------- -------- -----FWD 19 128.11 P2p BLK 19 128.12 P2p
We'll now change the root port cost of fast 0/12 with the spanning cost command. Change this cost to 15, then run show spanning vlan 1 again.
SW2(config)#int fast 0/12 SW2(config-if)#spanning-tree cost 15 SW2#show spanning vlan 1 Interface ---------------Fa0/11 Fa0/12 Role Sts Cost Prio.Nbr Type ---- --- --------- -------- -----Root BLK 19 128.11 P2p Altn LIS 15 128.12 P2p
The root port selection has changed because fast 0/12's port cost is now less than 0/11. Fast 0/11 goes into blocking mode and 0/12 will go through the STP port states until it reaches the Forwarding state. Change the STP timers on the root bridge.
SW1(config)#spanning vlan 1 hello 5 SW1(config)#spanning vlan 1 forward-time 12 SW1(config)#spanning vlan 1 max-age 15
On SW2, run show spanning vlan 1. Note that the timers changed under Root ID, but not Bridge ID. The local switch's settings are under Bridge ID, but it's the timer values announced by the Root Bridge that are the ones being used.
SW2#show spanning vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000e.d7f5.a040 Cost 15 Port 12 (FastEthernet0/12) Hello Time 5 sec Max Age 15 sec Bridge ID
Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e2.14c0 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300
Make the nonroot bridge the root bridge for VLAN 1 with spanning-tree vlan 1 root primary. Run show spanning vlan 1 to verify.
SW2(config)#spanning-tree vlan 1 root primary SW2#show spanning vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 24577 Address 000f.90e2.14c0 This bridge is the root
Make the new nonroot bridge the root bridge again with the spanning-tree vlan 1 priority command. Set the priority to 10000.
SW1(config)#spanning-tree % Bridge Priority must be % Allowed values are: 0 4096 8192 12288 32768 36864 40960 45056 vlan 1 priority 10000 in increments of 4096. 16384 20480 24576 28672 49152 53248 57344 61440
In that case, make it 8192. ;) Verify with show spanning vlan 1.

SW1(config)#spanning-tree vlan 1 priority 8192 SW1#show spanning vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 8193 Address 000e.d7f5.a040 This bridge is the root
Place port 0/5 on SW1 into Portfast. By now, you know what you'll see! BUT... there's another Portfast option that we'll look at when we come to the end of this lab workbook.
SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree portfast %Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION %Portfast has been configured on FastEthernet0/5 but will only have effect when the interface is in a non-trunking mode.
Enable Uplinkfast on each switch. Do the same for Backbonefast. Remember, in production networks (and the exam), Uplinkfast is best suited for wiring-closet switches, and Backbonefast should be configured on all switches in the network.
SW1(config)#spanning uplinkfast SW2(config)#spanning uplinkfast SW1(config)#spanning backbonefast SW2(config)#spanning backbonefast
Assume that a third switch will be added to SW2's fast 0/7 port, and this switch must not become the root bridge. Configure Root Guard on this port to meet that requirement.
On SW1, fast 0/5 has already been configured with Portfast. Just to make sure a switch doesn't get connected to that port, configure BPDU Guard on fast 0/5. This port will now shut down if a BPDU is received on it.
SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree bpduguard % Incomplete command.
SW1(config-if)#spanning-tree bpduguard ? disable Disable BPDU guard for this interface enable Enable BPDU guard for this interface SW1(config-if)#spanning-tree bpduguard enable
Enable aggressive UDLD globally on both switches.

SW1(config)#udld aggressive SW2(config)#udld aggressive
On both switches, run show spanning-tree summary. This command doesn't get mentioned often, but once you've got some STP features running, it's a good command to know. You can see that SW2 isn't the root bridge for any VLAN, and you can also see what features are and are not enabled on this switch.
SW2#show spanning-tree summary Switch is in pvst mode Root bridge for: none EtherChannel misconfig guard is enabled Extended system ID is enabled Portfast Default is disabled PortFast BPDU Guard Default is disabled Portfast BPDU Filter Default is disabled Loopguard Default is disabled UplinkFast is enabled BackboneFast is enabled Pathcost method used is short Name VLAN0001 VLAN0080 2 vlans Blocking Listening Learning Forwarding STP Active 1 0 0 1 2 1 0 0 1 2 2 0 0 2 4
Since Loop Guard isn't configured on this switch, let's do so on port 0/1.
SW2(config)#interface fast 0/1 SW2(config-if)#spanning-tree guard loop
Run show spanning summary again and you'll see "Loopguard" is enabled, and the word "default" is gone. When you see default next to a value in this command, you know that it's running at the default.
General Switch Commands On R2, configure the switch to autorecover from all port err-disabled conditions with the errdisable recovery cause command. Before selecting "all" as the option, use IOS Help to look at the other options. As you can see, there are a lot of different ways for a port to go into err-disabled state! Set the duration of the err-disabled state to 300 seconds.
SW2(config)#errdisable recovery cause all SW2(config)#errdisable recovery cause all SW2(config)#errdisable recovery interval ? <30-86400> timer-interval(sec) SW2(config)#errdisable recovery interval 300
Create an Etherchannel over ports fast 0/11 and 0/12 on each switch.
Use PAgP auto mode on SW1 and PAgP desirable on the SW2. Be prepared for quite a few "line protocol down" and "line protocol up" messages while you're building the EC.
SW1(config)#int fast 0/11 SW1(config-if)#channel-group 1 mode auto Creating a port-channel interface Port-channel 1 SW1(config-if)#int fast 0/12 SW1(config-if)#channel-group 1 mode auto SW2(config)#int fast 0/11 SW2(config-if)#channel-group 1 mode desirable Creating a port-channel interface Port-channel 1 SW2(config-if)#int fast 0/12 SW2(config-if)#channel-group 1 mode desirable
Verify the EC with show interface trunk. If you don't see anything, check each physical port with show interface fast 0/x and see if the port was placed into err-disabled state during the EC configuration. If so, simply open the interface manually.
SW2#show interface trunk Port Po1 Mode on Encapsulation Status 802.1q trunking Native vlan 1
For further verification, run show interface port-channel 1. Note the defaults for the speed and duplex. (It's out of the scope of the BCMSN exam, but when an EC is configured on a multilayer switch, it can be made a Layer 3 EC and have an IP address assigned.)
SW2#show interface port-channel 1 Port-channel1 is up, line protocol is up (connected) Hardware is EtherChannel, address is 000f.90e2.14cb (bia 000f.90e2.14cb) MTU 1500 bytes, BW 200000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 100Mb/s
Hot Standby Routing Protocol The following lab can be run on routers or switches, and in my racks we're going to run HSRP on R2 and R3. R2's Serial0 interface line protocol must be up as well, so you'll need to bring the Frame Relay interfaces up on R1, R2, and R3. The Frame Relay switch in my labs is preconfigured, so you'll only need to apply the following commands on the routers: R1:
interface serial0 ip address 172.12.123.1 255.255.255.0 encap frame no frame inverse frame map ip 172.12.123.2 122 broadcast
frame map ip 172.12.123.3 123 broadcast
R2:
interface serial0 ip address 172.12.123.2 255.255.255.0 encap frame no frame inverse frame map ip 172.12.123.1 221 broadcast frame map ip 172.12.123.3 221
R3:
interface serial0 ip address 172.12.123.3 255.255.255.0 encap frame no frame inverse frame map ip 172.12.123.1 321 broadcast frame map ip 172.12.123.2 321
Don't forget to open the interfaces! All interfaces should be able to ping each other. The important thing is that R2's Serial0 line protocol is up. R2 and R3 are also connected via an Ethernet segment. Configure 172.12.23.2 /24 on R2's e0 interface and 172.12.23.3 /24 on R3's e0 interface. Both ports should be in the same VLAN and pings should be successful between the two routers over that interface. Configure R2 and R3 to use 172.12.23.10 as the IP address of the virtual router. On R2, run show standby to view the HSRP details. If the router isn't in Active or Standby state yet, give it half a minute and run it again.
R2(config)#int e0 R2(config-if)#standby 1 ip 172.12.23.10 R3(config)#int e0 R3(config-if)#standby 1 ip 172.12.23.10 R2#show standby Ethernet0 - Group 1 Local state is Standby, priority 100 Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.170 Virtual IP address is 172.12.23.10 configured Active router is 172.12.23.3, priority 100 expires in 7.452 Standby router is local 1 state changes, last state change 00:01:07 IP redundancy name is "hsrp-Et0-1" (default)
R2 is the standby, R3 the Active router. Configure R2 as the Active by
setting its priority to 105. Verify with show standby.

R2(config)#int e0 R2(config-if)#standby 1 priority 105 R2#show standby Ethernet0 - Group 1 Local state is Standby, priority 105 Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.832 Virtual IP address is 172.12.23.10 configured Active router is 172.12.23.3, priority 100 expires in 8.340 Standby router is local 1 state changes, last state change 00:02:40 IP redundancy name is "hsrp-Et0-1" (default)
R2's priority is now higher than R3's, but it's not the Active router. For R2 to become the Active while the current Active router is still online, the preempt option must be configured. Depending on the IOS version, the preempt will either be set at the end of the priority command, or on a line of its own.
R2(config)#int e0 R2(config-if)#standby 1 preempt 07:55:25: Active %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Standby ->
We see a message that the local router has gone from Standby to Active, but always verify. Trust, but verify - and we do that with show standby.
R2#show standby Ethernet0 - Group 1 Local state is Active, priority 105, may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 2.394 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.3, priority 100 expires in 7.428 Virtual mac address is 0000.0c07.ac01 2 state changes, last state change 00:00:56 IP redundancy name is "hsrp-Et0-1" (default)
R2 is now the Active router. Change the MAC address of the virtual router to aa-aa-aa-aa-aa-aa with the standby mac-address command. Verify with show standby.
R2(config)#int e0 R2(config-if)#standby 1 mac-address aaaa.aaaa.aaaa 07:57:57: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Active -> Learn 07:58:09: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Listen -> Active R2#show standby Ethernet0 - Group 1 Local state is Active, priority 105, may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.800 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.3, priority 100 expires in 9.068 Virtual mac address is aaaa.aaaa.aaaa configured 4 state changes, last state change 00:00:10 IP redundancy name is "hsrp-Et0-1" (default)
Notice the word "configured" next to the MAC address in show standby.
That indicates that this particular MAC address was statically configured. We'll now configure HSRP interface tracking. If the line protocol on R2's Serial0 goes down, we want R3 to become the Active router, since its serial line will still be up. R2's priority is 105, and R3's is 100. Since the default priority decrement with interface tracking is 10, we'll leave the default in place. If we wanted to change the decrement, that value is placed at the end of the standby track command.
R2(config-if)#standby 1 track serial0 R2(config-if)#standby 1 track serial0 ? <1-255> Priority decrement <cr> R2(config-if)#standby 1 track serial0
To test the configuration, R2's Serial0 interface will be shut down. After shutting that port down, run show standby to see the results.
R2(config-if)#int s0 R2(config-if)#shut R2#show standby Ethernet0 - Group 1 Local state is Active, priority 95 (confgd 105), may preempt Hellotime 3 sec, holdtime 10 sec Next hello sent in 2.506 Virtual IP address is 172.12.23.10 configured Active router is local Standby router is 172.12.23.3, priority 100 expires in 7.736 Virtual mac address is aaaa.aaaa.aaaa configured 4 state changes, last state change 00:06:36 IP redundancy name is "hsrp-Et0-1" (default) Priority tracking 1 interface, 0 up: Interface Decrement State Serial0 10 Down (administratively down)
The priority did go down, and the priority tracking even shows how the line went down! But this router is still the Active router, even though its priority decremented to 95. Why? Because R3 needs the HSRP preempt option configured on it as well. A router can't take over from an Active router that's up unless the preempt option is configured.
R3(config)#int e0 R3(config-if)#standby 1 preempt R3(config-if)# 08:06:22: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Standby -> Active
Within seconds, R3 becomes the Active router, verifying interface tracking. What happens when R2's Serial0 line protocol comes back up? Open it and see!
R2(config)#int s0 R2(config-if)#no shut 08:08:18: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Active 08:08:18: %SYS-5-CONFIG_I: Configured from console by console Standby ->
08:08:19: %LINK-3-UPDOWN: Interface Serial0, changed state to up
08:08:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up
Just that quickly, R2 becomes the Active router again, since its priority incremented by 10 when the line protocol came up. Watch that preempt option! ;)
Switch Security Enable AAA, and assume a RADIUS server at 172.1.1.1. Assume A TACACS server at 172.2.2.2 as well. (RADIUS and TACACS configuration is out of the scope of the BCMSN exam, but it doesn't hurt to know the basic command. Use IOS Help at the end of both host commands to view the options.)
SW1(config)#aaa new-model SW1(config)#radius-server host 172.1.1.1 SW1(config)#tacacs-server host 172.2.2.2 Create a local username / password database. SW1(config)#username BRYANT password CCIE SW1(config)#username SOPRANO password CCNP SW1(config)#username WALNUTS password CCNA
Configure an AAA authentication method list that will use the RADIUS server first, then the TACACS+ server, then the local database.
SW1(config)#aaa authentication login default ? enable Use enable password for authentication. group Use Server-group line Use line password for authentication. local Use local username authentication. local-case Use case-sensitive local username authentication. none NO authentication SW1(config)#aaa authentication login default group radius tacacs local
Configure port security on SW2, port 0/5. The port should allow two secure MAC addresses. Change the default port security mode from shutdown to protect.
SW2(config)#int fast 0/5 SW2(config-if)#switchport port-security Command rejected: Fa0/5 is not an access port. SW2(config-if)#switchport mode access SW2(config-if)#switchport port-security SW2(config-if)#switchport port-security ? aging Port-security aging commands mac-address Secure mac address maximum Max secure addresses violation Security violation mode <cr> SW2(config-if)#switchport port-security maximum 2 SW2(config-if)#switchport port-security violation protect
On SW1, configure 0/7 for dot1x authentication. The first step is to enable AAA. While we're at it, configure a default method list for authentication that will use the tacacs server and then any local database. Enable IEEE
802.1x with the dot1x system-auth-control command.

SW1(config)#aaa new-model SW1(config)#aaa authentication dot1x default tacacs SW1(config)#dot1x system-auth-control
Make fast 0/7 an access port and configure the configuration for Auto mode.
SW1(config-if)#int fast 0/7 SW1(config-if)#sw mode access SW1(config-if)#dot1x port-control auto
Note: If you attempt to configure dot1x port authentication on a potential trunk port, you'll get the following error:
SW1(config-if)#dot1x port-control auto Command rejected: Dynamic mode enabled on one or more ports. Dot1x is supported only on Ethernet interfaces configured Routed or Private-vlan Host Mode.
in
Access,
SPAN Configure Local SPAN session 1 on SW1. Ports fast 0/1 - 5 will be the source ports, and port 0/6 will be the destination port.
SW1(config)#monitor session 1 source interface fast 0/1 - 5 SW1(config)#monitor session 1 destination int fast 0/6
Verify with show monitor. (Remember - it's not show span!)

SW1#show monitor Session 1 --------Type : Local Session Source Ports : Both : Fa0/1-5 Destination Ports : Fa0/6 Encapsulation : Native Ingress: Disabled
Remove this session with no monitor session 1.

SW1(config)#no monitor session 1
We'll now configure a Remote SPAN (RSPAN) session. Create VLAN 45 as the special VLAN that will carry the mirrored traffic.
The source port for this configuration will be fast 0/7 and the destination will be fast 0/7 on SW2.
SW1(config)#monitor session 1 source interface fast 0/7 SW1(config)#monitor session 1 destination remote vlan 45 reflector-port fast 0/12
SW2 will receive the traffic and send it to a network analyzer on fast 0/7.
Run show monitor to verify the configuration.

SW2#show monitor Session 1 --------Type : Remote Destination Session Source RSPAN VLAN: 45 Destination Ports : Fa0/7 Encapsulation : Native Ingress: Disabled
Multilayer Switching Commands R2 and R3 are both connected to the multilayer switch in your pod. R2 is on port fast0/2, R3 on port fast 0/3. Assign the Ethernet0 interfaces on R2 and R3 the IP addresses shown in the diagram below. The routers will serve as hosts for this lab. The hosts will not be able to send pings to each other at this point.
R2#ping 30.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R3#ping 20.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
To get started, we'll put the port leading to Host 2 into VLAN 22, and the port leading to Host 3 in VLAN 33.
We're going to create two SVIs on the switch, one representing VLAN 22 and the other representing VLAN 33. Note that both SVIs show as up/up immediately after creation. Some Cisco and non-Cisco documentation mentions that you should open the SVIs after creating them, but that's not necessarily the case in the real world. Couldn't hurt, though. :)
SW1(config)#int vlan22
01:30:04: %LINK-3-UPDOWN: Interface Vlan22, changed state to up 01:30:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan22, changed state to up SW1(config-if)#ip address 20.1.1.11 255.255.255.0
SW1(config-if)#int vlan33 01:30:11: %LINK-3-UPDOWN: Interface Vlan33, changed state to up 01:30:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan33, changed state to up SW1(config-if)#ip address 30.1.1.11 255.255.255.0
Verify the SVIs with show interface vlan. I'll only show the top three rows of output for each SVI.
SW1#show int vlan11 Vlan11 is up, line protocol is up Hardware is EtherSVI, address is 0012.7f02.4b41 (bia 0012.7f02.4b41) Internet address is 20.1.1.11/24 SW1#show int vlan33 Vlan33 is up, line protocol is up Hardware is EtherSVI, address is 0012.7f02.4b42 (bia 0012.7f02.4b42) Internet address is 30.1.1.11/24
Now let's check that routing table...

SW1# show ip route Default gateway is not set Host Gateway ICMP redirect cache is empty Last Use Total Uses Interface
Hmm, that's not good. We don't have one! There's a simple reason, though - on L3 switches, we need to enable IP routing, because it's off by default!
SW1(config)#ip routing SW1(config)#^Z SW1#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 20.0.0.0/24 20.1.1.0 30.0.0.0/24 30.1.1.0 is is is is subnetted, 1 subnets directly connected, Vlan11 subnetted, 1 subnets directly connected, Vlan33
C C
Now that looks like the routing table we've come to know and love! In this particular case, there's no need to configuring a routing protocol. You recall from your CCNA studies that when router-on-a-stick is configured, the IP address assigned to the router's subinterfaces should be the default gateway setting on the hosts. When SVIs are in use, the default gateway set on the hosts should be the IP address assigned to the SVI that represents that host's VLAN. After setting this default gateway on the hosts, the hosts can now successfully
communicate. Since we're using routers for hosts, we'll use the ip route command to set the default gateway.
R2(config)#ip route 0.0.0.0 0.0.0.0 20.1.1.11 R3(config)#ip route 0.0.0.0 0.0.0.0 30.1.1.11
Can the hosts now communicate, even though they're in different VLANs? Yes, they can!
R2#ping 30.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R3#ping 20.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Ports on multilayer switches can also be configured as routing ports, and have IP addresses assigned directly to them. R4 is connected to the multilayer switch off port 0/4. Configure the IP address shown in the diagram on R4's Ethernet0 interface before proceeding.
The ports on a multilayer switch will all be running in L2 mode by default. To configure a port as a routing port, use the no switchport command, followed by the appropriate IP address. Note that in the following configuration, the line protocol on the switch port goes down and comes back up in just a few seconds.
SW1(config)#interface fast 0/4 SW1(config-if)#no switchport 02:19:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/4, changed state to down 02:19:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/4, changed state to up
SW1(config-if)#ip address 210.1.1.11 255.255.255.0
We verify the IP address assignment with show int fast 0/4.

SW1#show int fast 0/4 FastEthernet0/4 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0012.7f02.4b43 (bia 0012.7f02.4b43) Internet address is 210.1.1.5/24
The switch can now ping 210.1.1.1, the downstream router.

SW1#ping 210.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms Now we'll configure the switch to allow the hosts to ping R4. (They can ping 210.1.1.11, the switch's interface in that subnet, but not 210.1.1.1, the router's interface.)
The router has no path to either 20.1.1.0 /24 or 30.1.1.0/24, so there's no way for the pings to get back to Host 1 or Host 3.
R4#show ip route < code table removed for clarity > Gateway of last resort is not set C 210.1.1.0/24 is directly connected, FastEthernet0/0
To remedy that, we'll now configure a dynamic routing protocol between the L3 switch and the router. We'll use EIGRP in this case.
SW1(config)#router eigrp 100 SW1(config-router)#no auto-summary SW1(config-router)#network 210.1.1.0 0.0.0.255 SW1(config-router)#network 20.1.1.0 0.0.0.255 SW1(config-router)#network 30.1.1.0 0.0.0.255 R4(config)#router eigrp 100 R4(config-router)#no auto-summary R4(config-router)#network 210.1.1.0 0.0.0.255
The router now has the VLAN subnets in its routing table...
R4#show ip route < code table removed for clarity >
Gateway of last resort is not set 20.0.0.0/24 is subnetted, 1 subnets 20.1.1.0 [90/28416] via 210.1.1.11, 00:01:01, FastEthernet0/0 210.1.1.0/24 is directly connected, FastEthernet0/0 30.0.0.0/24 is subnetted, 1 subnets 30.1.1.0 [90/28416] via 210.1.1.11, 00:01:01, FastEthernet0/0
D C D
... and the hosts now have two-way IP connectivity with the router's 210.1.1.1 interface.
R2#ping 210.1.1.1 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms R3#ping 210.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
It never hurts to make sure the pings can go the other way, too!
R4#ping 20.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R4#ping 30.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
And finally.....
SW2(config)#spanning portfast default %Warning: this command enables portfast by default on all interfaces. You should now disable portfast explicitly on switched ports leading to hubs, switches and bridges as they may create temporary bridging loops.
The above command will make Portfast the default setting for all ports. I didn't want you to configure it early because it wouldn't have worked nicely with a lot of the commands you ran during and after the STP section, but it's a good command to know for the exam and the real world. To your Cisco success, Chris Bryant CCIE #12933
BCMSN Exam Command Reference

Command Reference
Overview
VLANs VTP Basic Spanning Tree Advanced Spanning Tree Basic Switch Operations Multicasting Quality of Service Multilayer Switching & Router Redundancy Switch Security & Tunneling Voice VLANs
VLANs show interface trunk shows port trunk modes, encapsulation, whether the interface is actually trunking, and the native vlan for each interface.
SW1#show interface trunk Port Fa0/11 Fa0/12 Mode desirable desirable Encapsulation Status 802.1q trunking 802.1q trunking Native vlan 1 1
Port Vlans allowed on trunk Fa0/11 1-999,1001-4094 Fa0/12 1-999,1001-4094 Port Vlans allowed and active in management domain Fa0/11 1,12 Fa0/12 1,12 Port Vlans in spanning tree forwarding state and not pruned Fa0/11 1,12 Fa0/12 12
show vlan is the full command to see information regarding all VLANs on the switch, including some reserved ones you probably aren't using.
show vlan brief gives you the information you need to troubleshoot any VLAN-related issue, but limits the information shown on the reserved VLANs.
switchport nonegotiate turns DTP frames off, but the port must be hardcoded for trunking to do so.
SW2(config)#int fast 0/8 SW2(config-if)#switchport nonegotiate Command rejected: Conflict between 'nonegotiate' and 'dynamic' status. SW2(config-if)#switchport mode ? access Set trunking mode to ACCESS unconditionally dynamic Set trunking mode to dynamically negotiate access or trunk mode trunk Set trunking mode to TRUNK unconditionally SW2(config-if)#switchport mode trunk SW2(config-if)#switchport nonegotiate
switchport mode access and switchport access vlan x work together to place a port into a VLAN. The first command prevents the port from becoming a trunk port, and the second command is a static vlan assignment.
switchport trunk allowed vlan is used to disallow or allow VLANs from
sending traffic across the trunk, as shown with the below IOS Help readout.
SW1(config-if)#switchport trunk allowed vlan ? WORD VLAN IDs of the allowed VLANs when this port is in trunking mode add add VLANs to the current list all all VLANs except all VLANs except the following none no VLANs remove remove VLANs from the current list
SW1(config)#interface fast 0/11 SW1(config-if)#switchport trunk allowed vlan except 1000 SW1(config-if)#interface fast 0/12 SW1(config-if)#switchport trunk allowed vlan except 1000
switchport trunk encapsulation is used to define whether ISL or dot1q will be used on the trunk.
Rack1SW1(config-if)#switchport trunk encapsulation ? dot1q Interface uses only 802.1q trunking encapsulation when trunking isl Interface uses only ISL trunking encapsulation when trunking negotiate Device will negotiate trunking encapsulation with peer on interface
switchport trunk native vlan x is used to change the native VLAN of the trunk. This should be agreed upon by both endpoints. Be prepared to see an error message while you're changing this, as shown below.
SW1(config-if)#switchport trunk native vlan 12 1d21h: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 1on FastEthernet0/11 VLAN12. 1d21h: %SPANTREE-2-BLOCK_PVID_PEER: Blocking FastEthernet0/11 on VLAN0001. Inconsistent peer vlan. 1d21h: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet0/11 on VLAN0012. Inconsistent local vlan.
VTP show vtp counters displays the number of different VTP advertisements send and received by the switch.
show vtp status displays just about anything you need to know about your VTP domain, including domain name and revision number.
vlan x is used to create a VLAN. SW2(config)# vlan 25 SW2(config-vlan)#
vtp domain is used to define the VTP domain.
vtp mode is used to define the switch as a VTP Server, Client, or as running in Transparent mode.
To configure VTP in secure mode, set a password on all devices in the VTP domain with vtp password. Verify with show vtp password.
p 2 P 2 1. 8 2 1 9 1 D WF g seD 2 1/ 0 a F p 2 P 1 1. 8 2 1 9 1 D WF g seD 1 1/ 0 a F ---------- ----------- ----- ------ -------- --------- --- ---- ----- ----------e p y T r b N. o ir P tsoC stS eloR ecafretnI 0 0 3 e m i T g ni g A c e s 0 2 y a l e D dr a wr o F c e s 0 3 e g A x a M c e s 5 e m i T o l l e H 0 4 2 c. 1 e 0 9.f 0 0 0 s s er d d A ) 1 t x e- di- s y s 8 6 7 2 3 ytir o ir p( 9 6 7 2 3 yt ir o ir P DI e g d ir B
c e s 0 2 y a l e D d r a w r o F c e s 0 3 e g A x a M c e s 5 e m i T oll e H
Enable VTP pruning with vtp pruning, and check the VTP version with vtp version.
show spanning tree interface x will display the STP settings for an individual port.
SW2(config)#spanning-tree vlan 20 root primary SW2(config)#spanning-tree vlan 30 root primary
spanning-tree vlan x can be used to make a nonroot the root bridge with either the root primary or priority options.
t o o r e ht s i e g d ir b si h T 0 4 2 c. 1 e 0 9.f 0 0 0 s s er d d A 9 6 7 2 3 yt ir o ir P DI t o o R e e ei l o c ot o r p d e l b a n e e e rt g n i n n a p S 1 00 0N ALV 1 nalv eert-gninnaps wohs#1WS
show spanning-tree vlan x shows the STP setting for the entire VLAN.
Interface Role Sts Cost ---------------- ---- --- --------- -------Fa0/11 Root FWD 19 Fa0/12 Altn BLK 19 SW2#show spanning-tree vlan 1
Basic Spanning Tree
Prio.Nbr Type -------------------------------128.11 P2p 128.12 P2p
SW2(config)#spanning-tree vlan 30 root ? primary Configure this switch as primary root for this spanning tree secondary Configure switch as secondary root SW2(config)#spanning-tree vlan 10 priority ? <0-61440> bridge priority in increments of 4096
spanning-tree vlan x is also used to change the STP timers, but this must be done on the root bridge to be effective.
SW1(config)#spanning-tree vlan 1 hello-time 5 SW1(config)#spanning-tree vlan 1 max-age 30 SW1(config)#spanning-tree vlan 1 forward-time 20
Advanced Spanning Tree Portfast can be enabled on the interface level or globally with the spanning-tree portfast and spanning portfast default commands.
SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree portfast %Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION %Portfast has been configured on FastEthernet0/5 but will only have effect when the interface is in a non-trunking mode. SW1(config-if)# SW2(config)#spanning portfast default %Warning: this command enables portfast by default on all interfaces. You should now disable portfast explicitly on switched ports leading to hubs, switches and bridges as they may create temporary bridging loops.
Below, you'll see how to enable the STP features Uplinkfast, Backbonefast, Root Guard, BPDU Guard, Loop Guard, and UDLD. Several important options are also shown. You must know these commands and exactly what they do.
SW2(config)#spanning-tree uplinkfast
SW2(config)#spanning-tree backbonefast
SW1(config)#int fast 0/5 SW1(config-if)#spanning-tree bpduguard % Incomplete command. SW1(config-if)#spanning-tree bpduguard ? disable Disable BPDU guard for this interface
enable Enable BPDU guard for this interface SW1(config-if)#spanning-tree bpduguard enable
SW2(config)#udld ? aggressive Enable UDLD protocol in aggressive mode on fiber ports except where locally configured enable Enable UDLD protocol on fiber ports except where locally configured message Set UDLD message parameters SW2(config)#udld enable
SW2(config-if)#int fast 0/5 SW2(config-if)#spanning-tree guard loop
To enable Multiple Spanning Tree:

SW2(config)# spanning-tree mode mst
The name and revision number must now be set.

SW2(config)# spanning-tree mode mst configuration SW2(config-mst)# name REGION1 SW2(config-mst)# revision 1

Basic Switch Operation show mac-address-table displays the CAM table contents. This command has about 10 options -- the dynamic option is very helpful.
SW2#show mac-address-table dynamic Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ---- ------------------ ----1 000e.d7f5.a04b DYNAMIC Fa0/11 Total Mac Addresses for this criterion: 1
Create an SVI on an L3 switch:

Configure the switch's VTY lines to accept Secure Shell connections:
Use the interface-range command to configure a number of interfaces with one command. Use speed and duplex to adjust those settings for an interface, and use description to, well, describe what the ports are doing!
SW2(config)#interface range fast 0/1 - 11 SW2(config-if-range)#speed 10 SW2(config-if-range)#duplex half SW2(config)#interface range fast 0/11 - 12 SW2(config-if-range)#description ports trunking with SW1 SW2(config)#errdisable recovery cause all SW2(config)#errdisable recovery interval ? <30-86400> timer-interval(sec) SW2(config)#errdisable recovery interval 300 SW1(config-if)#channel-group 1 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected
Multicasting Enable multicasting with ip multicast-routing. Statically configure the RP location with ip pim rp-address. Enable Sparse Mode on the interfaces with ip pim sparse. Verify with show ip pim neighbor.
R1(config)#ip multicast-routing R1(config)#ip pim rp-address 172.12.123.1 R1(config)#int s0 R1(config-if)#ip pim sparse R2(config)#ip multicast-routing R2(config)#ip pim rp-address 172.12.123.1 R2(config)#int s0 R2(config-if)#ip pim sparse R3(config)#ip multicast-routing R3(config)#ip pim rp-address 172.12.123.1 R3(config)#int s0 R3(config-if)#ip pim sparse R1#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface 172.12.123.3 Serial0 172.12.123.2 Serial0
Uptime Expires Ver Mode 00:11:08 00:01:37 v2 (DR) 00:11:37 00:01:38 v2
How to limit the multicast groups a router can serve as the RP for:
R1(config)#access-list 14 permit 224.0.1.40
R1(config)#ip pim rp-address 172.12.123.1 ? <1-99> Access-list reference for group <1300-1999> Access-list reference for group (expanded range) WORD IP Named Standard Access list override Overrides Auto RP messages <cr> R1(config)#ip pim rp-address 172.12.123.1 14
Configure routers as PIM RPs with send-rp-announce, and as PIM Mapping Agents with send-rp-discovery.
R3(config)#ip pim send-rp-announce serial0 scope 5 R1(config)#ip pim send-rp-discovery serial 0 scope 5
Bootstrapping Commands: To configure R1 as a C-BSR:

R1(config)# ip pim bsr-candidate
To configure R2 and R3 as C-RPs:

R2(config)# ip pim rp-candidate
IGMP and CGMP: Verify IGMP snooping with show ip igmp snooping.
SW1#show ip igmp snooping Global IGMP Snooping configuration: ----------------------------------IGMP snooping : Enabled IGMPv3 snooping (minimal) : Enabled Report suppression : Enabled TCN solicit query : Disabled TCN flood query count : 2 Vlan 1: -------IGMP snooping : Enabled Immediate leave : Disabled Multicast router learning mode : pim-dvmrp Source only learning age timer : 10 CGMP interoperability mode : IGMP_ONLY
Enable CGMP on a router and switch as shown below. router interface must be PIM-enabled first.
R1(config)#int e0 R1(config-if)#ip cgmp WARNING: CGMP requires PIM enabled on interface R1(config-if)#ip pim sparse R1(config-if)#ip cgmp
Note that the
SW1(config)#int fast 0/5 SW1(config-if)#ip cgmp
Quality Of Service To enable QoS:

SW2(config)#mls qos
To configure an interface to trust the incoming CoS:

MLS(config-if)# mls qos trust cos
To change your mind and take the trust off:

SW2(config-if)# no mls qos trust
To create COS-DSCP and IP PREC-DSCP maps:

SW2(config)# mls qos map cos-dscp SW2(config)#mls qos map ip-prec-dscp
A mutation map is created as follows:

SW2(config) mls qos dscp-mutation
The mutation map needs to be applied to the proper interface:

SW2(config-if)mls qos dscp-mutation MAP_NAME
To create a QoS policy, write an ACL to identify the traffic and use a class-map to refer to the ACL:
SW1(config)#access-list 105 permit tcp any any eq 80 SW1(config)#class-map WEBTRAFFIC SW1(config-cmap)#match access-group 105
QoS policies are configured with the policy-map command, and each clause of the policy will contain an action to be taken to traffic matching that clause.
SW1(config)#policy-map LIMIT_WEBTRAFFIC_BANDWIDTH SW1(config-pmap)#class WEBTRAFFIC SW1(config-pmap-c)#police 5000000 exceed-action drop SW1(config-pmap-c)#exit
Finally, apply the policy to an interface with the service-policy command.

SW1(config)# service-policy LIMIT_WEBTRAFFIC_BANDWIDTH in
Multilayer Switching
To create a Switched Virtual Interface:

To configure a multilayer switch port as a routed port:

MLS(config)#interface fast 0/1 MLS(config-if)# no switchport MLS(config-if)# ip address 172.1.1.1 255.255.255.0
To configure a multilayer switch port as a switching port:

MLS(config)# interface fast 0/1 MLS(config-if)# switchport
To create a bridge group:

MLS(config)# bridge-group 1
To join a VLAN to a bridge group:

MLS(config)#interface vlan 10 MLS(config-if)#bridge-group 1
To enable IRDP:
MLS(config)# interface serial0 MLS(config-if)# ip irdp
To configure basic HSRP:

R2(config)#interface ethernet0 R2(config-if)#standby 5 ip 172.12.23.10 R3(config)#interface ethernet0 R3(config-if)#standby 5 ip 172.12.23.10 R2#show standby
Ethernet0 - Group 5 Local state is Standby, priority 100 Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.776 Virtual IP address is 172.12.23.10 configured Active router is 172.12.23.3, priority 100 expires in 9.568 Standby router is local 1 state changes, last state change 00:00:22
To change HSRP timers:

R3(config-if)#standby 5 timers 4 12
To change HSRP priority and allow a router to take over from an online Active router:
R2(config-if)#standby 5 priority 150 preempt
To change the HSRP virtual router MAC address:

To configure HSRP interface tracking:

R2(config-if)#standby 1 track serial0
To configure GLBP:
MLS(config-if)# glbp 5 ip 172.1.1.10
To change the interface priority, use the glbp priority command. To allow the local router to preempt the current AVG, use the glbp preempt command.
MLS(config-if)# glbp 5 priority 150 MLS(config-if)# glbp 5 preempt
To configure members of the server farm "ServFarm"

To create the SRB virtual server:

To allow only specified hosts to connect to the virtual server:

MLS(config-slb-vserver)# client 210.1.1.0 0.0.0.255
Switch Security / Tunnel Commands
To enable AAA and specify a RADIUS or TACACS server:

SW2(config)#aaa new-model SW2(config)#radius-server host ? Hostname or A.B.C.D IP address of RADIUS server SW2(config)#tacacs-server ? host Specify a TACACS server
To define a default method list for AAA authentication:

SW2(config)#aaa authentication login default local group radius
To configure port security:

To specify secure MAC addresses:

SW2(config-if)#switchport port-security mac-address ? H.H.H 48 bit mac address
To set the port security mode:

SW2(config-if)#switchport port-security violation ? protect Security violation protect mode restrict Security violation restrict mode
shutdown Security violation shutdown mode
To enable Dot1x on the switch:

SW2(config)#dot1x system-auth-control system-auth-control Enable or Disable SysAuthControl
Dot1x must be configured globally, but every switch port that's going to run dot1x authentication must be configured as well.
SW2(config-if)#dot1x port-control ? auto PortState will be set to AUTO force-authorized PortState set to Authorized force-unauthorized PortState will be set to UnAuthorized
To configure and verify a local SPAN session:

SW2(config)#monitor session 1 source interface fast 0/1 - 5 SW2(config)#monitor session 1 destination interface fast 0/10 SW2#show monitor Session 1 --------Type : Local Session Source Ports : Both : Fa0/1-2 Destination Ports : Fa0/10 Encapsulation : Native Ingress: Disabled
To verify a remote SPAN session, create the VLAN that will carry the mirrored traffic:
Configure the source ports and destination as shown on the source switch:
SW2(config)#monitor session 1 source interface fast 0/1 - 5 SW2(config)#monitor session 1 desti remote vlan 30 reflector-port fast 0/12
Configure the source VLAN and destination port on the destination switch:
To create a VLAN ACL, first write an ACL specifying the traffic to be affected.
SW2(config)#ip access-list extended NO_123_CONTACT SW2(config-ext-nacl)#permit ip 171.10.10.0 0.0.0.3 172.10.10.0 0.0.0.255
Follow that with the VLAN access-map:

SW2(config)# vlan access-map NO_123 10 SW2(config-access-map)# match ip address NO_123_CONTACT SW2(config-access-map)# action drop SW2(config-access-map)# vlan access-map NO_123 20 SW2(config-access-map)# action forward
Finally, we've got to apply the VACL. We're not applying it to a specific interface - instead, apply the VACL in global configuration mode.
SW2(config)# vlan filter NO_123 vlan-list 100
For dot1q tunneling, the following configuration would be needed on the service provider switch ports that will receive traffic from the customer:
By default, CDP, STP, and VTP will not be sent through the dot1q tunnel. To send those frames to the remote network, create an L2 protocol tunnel. This command has quite a few options, so I've shown as many as possible below.
MLS_1(config-if)#l2protocol-tunnel ? cdp Cisco Discovery Protocol drop-threshold Set drop threshold for protocol packets point-to-point point-to-point L2 Protocol shutdown-threshold Set shutdown threshold for protocol packets stp Spanning Tree Protocol vtp Vlan Trunking Protocol <cr> MLS_1(config-if)#l2protocol-tunnel drop-threshold ? <1-4096> Packets/sec rate beyond which protocol packets will be dropped cdp Cisco Discovery Protocol point-to-point point-to-point L2 Protocol stp Spanning Tree Protocol vtp Vlan Trunking Protocol MLS_1(config-if)#l2protocol-tunnel drop-threshold cdp ? <1-4096> Packets/sec rate beyond which protocol packets will be dropped MLS_1(config-if)#l2protocol-tunnel drop-threshold cdp 2000 ? <cr> MLS_1(config-if)#l2protocol-tunnel drop-threshold cdp 2000
MLS_1(config-if)#l2protocol-tunnel shutdown-threshold ? <1-4096> Packets/sec rate beyond which interface is put to err-disable cdp Cisco Discovery Protocol point-to-point point-to-point L2 Protocol stp Spanning Tree Protocol vtp Vlan Trunking Protocol MLS_1(config-if)#l2protocol-tunnel shutdown-threshold vtp ? <1-4096> Packets/sec rate beyond which interface is put to err-disable MLS_1(config-if)#l2protocol-tunnel shutdown-threshold vtp 4096
Creating a private VLAN:

MLS(config-vlan)#private-vlan community Private VLANs can only be configured when VTP is in transparent mode MLS(config-vlan)#exit MLS(config)#vtp mode transparent Setting device to VTP TRANSPARENT mode. MLS(config)#vlan 20 MLS(config-vlan)#private-vlan community MLS(config-vlan)#private-vlan association ? WORD VLAN IDs of the private VLANs to be configured add Add a VLAN to private VLAN list remove Remove a VLAN from private VLAN list MLS(config-vlan)#private-vlan association 30
The ports will now be placed into the private VLAN:

MLS(config-if)# switchport mode private-vlan 20 host
Voice VLANs
The basic Voice VLAN configuration is as follows:

MLS(config)# mls qos (globally enables QoS on the switch) (port leading to IP phone) (trust incoming CoS values)
MLS(config)# interface fast 0/5 MLS(config-if)# mls qos trust cos
MLS(config-if)# switchport voice vlan ( x / dot1p / none / untagged)
To configure the phone to accept the CoS values coming from the PC:
MLS(config-if)# switchport priority extend trust
To configure the phone not to trust the incoming CoS value:

MLS(config-if)# switchport priority extend cos 0
To configure the switch to trust incoming CoS values if they're sent by a Cisco IP phone:
MLS(config-if)# mls qos trust cos MLS(config-if)# mls qos trust device cisco-phone
ohw relaed eht ot kcab ylbissop ro yabe no bal ruoy lles nac uoY .ekam ot eciohc a evah neht uoy ,PNCC ro ANCC ruoy detelpmoc evuoy nehW .detrats teg ot deen uoy esle gnihtyreve dna ,sreviecsnart ,selbac ruoy uoy lles llyehT .stik PNCC dna ANCC edam-erp evah ohw yabe no srelaed fo snezod era ereht dna ,ycnaf ylbidercni gnihtyna deen tnod uoY .bal ocsiC nwo ruoy rehtegot tup ot erofeb reve naht repaehc s'tI
.eulav elaser elttil evah s margorp eseht ,yabe no nees evI tahw morF .002$ - 051$ kcab uoy tes lliw margorp rotalumis A .tne mpiuqe ocsiC .sv srotalu mis fo tsoc eht ta kool steL .kniht uoy naht repaehc stI .nac uoy ,seY .tnempiuqe nwo ym droffa tnac I :ydaerla uoy raeh I .tnempiuqe ocsiC laer no krow e mos ni tup ot deen uoY .hguone ton tsuj si ylevisulcxe meht no gnikrow ,yaw gnol a e moc evah smargorp rotalumis elihW !skoob gnidaer tsuj dnoyeb og ot evah uoY .meht rof deraperp ylreporp eruoy erus ekam ot si snoitseuq rotalumis tuoba yteixna ruoy revo teg ot od nac uoy gniht tseb ehT
ecna m rofreP rooP st ne verP ecn a mrofreP re porP .1

!ecaf ruoy no nirg a dna dnah ruoy ni edarg gnissap a htiw moor gnitset taht fo tuo gniklaw ot yaw ruoy no eb lluoy dna ,spets eseht wolloF .maxe PNCC ro ANCC ruoy gnilian dna snoitseuq rotalumis deda erd eht gnireuqnoc drawot spets elpmis evif era erehT .egdelwonk htiw dereuqnoc eb nac yteixna siht ,raef dna yteixna tsom hti w sa tuB .ereht tuo ees I yteixna eht fo tol a rof elbisnopser si tcaf tahT .snoitseuq rotalu mis eht ssi m uoy fi maxe ocsiC a ssap ot ,tluciffid ton fi ,elbissop mi sti taht si modsiw lanoitnevnoc ehT .meht r of eraperp ot woh dna ,deksa eb lliw tahw ,ekil era snoitseuq rotalumis tahw tuoba teN eht no eton a tsop etadidnac PNCC ro ANCC a ees tnod I taht yb seog yad a ton ,taht lla neviG .taht rof stniop emos teg od uoy ,thgir meht fo owt teg uoy dna sgniht eerht od ot deksa era uoy fi ,si taht ;snoitseuq rotalumis ksat-elpitlu m ni nevig si tiderc laitrap taht detats osla sah ocsiC .snoitseuq eciohc elpitlum lacipyt eht naht thgiew erom nevig era snoitseuq eseht taht drocer eht rof detats sah ocsiC .tnatropmi si noitseuq fo epyt siht ,ylniatreC .rotalumis retuor a no demrofrep eb tsum taht sksat fo seires ro ksat a htiw detneserp si etadidnac eht ,noitseuq fo dnik siht nI .noitseuq rotalu mis dedaerd eht eb ot sah ti ,srekat-tset gno ma yteixna sesuac taht noitseuq maxe ocsiC fo epyt eno sereht fI
Five Tips For Success On Cisco Simulator Questions

Chris Bryant, CCIE #12933 www.thebryantadvantage.com
Simulator Question Success

Back To Index
yeht syas ohw enoyna taht knalb tniop uoy llet nac I dna ,baL EICC eht dessap dna delkcat evI .dneirf tseb sreenigne ocsiC eht si pleH SOI
.e lb al ia va g nie b t i no d n e p e d t n od t u b , e l b i s s o p n e h w r o t a l u m i s e h t n i p l e H S O I e s U . 4
.ylluferac lairotut eht hguorht og maxe eht trats yllautca uoy ERO FEB deen uoy noita mrofni eht rof kool ot erehw wonk uoy erus ekam tsuJ .snoitseuq eseht htiw uoy kcirt ot gniyrt ton socsiC .perp maxe ruoy fo trap lairotut eht hguorht gniog redisnoc tsu m uoy tub ,moor gnitset eht otni klaw uoy nehw detrats teg ot suoixna eruoy wonk I .lairotut eht ni noitseuq rotalu mis a fo hguorhtklaw hguoroht a sereht dna ,os gniod yb e mit yna esol ton od uoY . maxe eht no gninnigeb eht ta lairotut eht ekat ot erus ekaM .uoy fo tnorf ni ereht thgir si deen uoy noita mrofni eht lla dna ,drawrofthgiarts era smaxe ocsiC no snoitseuq rotalumis ehT .tcerrocni si sihT .noitseuq eht rewsna ot noitamrofni hguone ton sereht syas ohw etadidnac a morf liame na teg ro tsop a ees yllanoisacco I
.u oy f o tnorf n i th gir si deen uo y no ita mr ofni eh t llA .3

.selcatsbo ton ,seitinutroppo sa snoitseuq eseht no kooL .PNCC ro ANCC eurt a era uoy taht ocsiC ot evorp ot ecnahc a si sihT .tnod uoy ro ti od ot woh wonk rehtie uoY :snoitseuq rotalu mis htiw elur elpmis a sereht tub ,snoitseuq eciohc elpitlu m a htiw ykcul teg thgi m gniod eryeht tahw wonk tnod ohw elpoeP .gniod eruoy tahw wonk uoy EVORP ot ecnahc a sa meht nopu kooL .snoitseuq rotalumis ot hcaorppa latne m ruoy egnahC )?NALV a etaerc ot woh wonk tndid ohw ANCC a erih uoy dluoW( .taht od ot woh wonk dluohs ANCC a taht eerga lluoy ylniatreC .locotorp gnituor a ro NALV a gnirugifnoc fo senil eht gnola gnihte mos deksa eb duoy kniht dluow I ,smaxe ANCC eht roF . maxe eht fo level eht evoba gnihtyna deksa eb ot gniog ton eruoY .x aleR .erugifnoc ot deksa eb ot gniog eryeht sksat tahw tuoba deirrow era ohw setadidnac morf era cipot siht no teg I sliame eht fo tsoM .nwonknu eht fo raef eht si ereh melborp ehT ?thgir ,elpmis sdnuoS
.xa leR .2
.ylisae snoitseuq rotalu mis eht evlos lluoy ,siht od uoy nehW .sehctiws dna sretuor laer no gnihctiws dna gnituor nrael sreenigne ocsiC taerG .srotalumis nehctik ton ,snehctik laer ni kooc ot nrael sfehc taerG ?srotalumis fo skcats ees uoy od ro ,sehctiws dna sretuor ocsiC laer ees uoy od ,retnec krowten a otni klaw uoy nehW .sretuor ocsiC no gnikrow rof etutitsbus on si erehT .ti gniyub ton ,bal eht gnisael yllacisab eruoY . y d u t s r o l e v e l t x e n r u o y r o f t n e m p i u qe emos dda dna ti peek nac uoy ro ,ecalp tsrif eht ni morf ti thguob uoy
.yad maxe no suoirotciv egreme uoy pleh lliw dna ,snoitseuq tnatropmi eseht lian uoy pleh lliw seuqinhcet evif eseht gnisU .meht rewsna ot evah uoy emit tsrif eht ylralucitrap ,suovren elttil a uoy ekam n ac smaxe ocsiC no snoitseuq rotalu mis eht taht wonk I
!yrt a ti eviG .llew sa spleh yllaer ti em dlot evah setadidnac tnerruc dna ,re ddal noitacifitrec ocsiC eht pu yaw ym no em depleh yllaer ti gniretne erofeb rewsna ym tuo gnitirw dnuof I .ti retne uoy retfa rotalu mis eht no noitarugifnoc ruoy evomer tonnac uoy taht ton stI .rotalumis eht otni ti gniretne erofeb rehto eht ro yaw eno rewsna ruoy tuo etirw ot uoy rof tnatropmi yrev sti ,taht dias gnivaH .sretnec gnitset ni elbaliava si dapetoN rehtehw no stroper tnereffid draeh evI
.tsrif rewsna ruoy tuo etirw ,elbaliava tnsi dapetoN fI .rotalumis eh t o tn i t i g nire tne erof eb da peto N n i r e ws na ruo y tuo e pyT .5
.yad maxe no meht no dneped tnod ,niaga tub ,seno tnatropmi eht wonK .sdnam moc wohs rof seog emas ehT .elbaliava ton sti fi desirprus eb tnod tuB .os gniod rof stniop esol uoy ekil ton sti ;ti esu ot yrt ylniatrec nac uoY . maxe ruoy ni elbaliava gnieb ti no dneped tnod ,revewoH teg uoy ecnahc yreve ti esu dna ,yduts PNCC dna ANCC ruoy ni pleH SOI htiw railimaf yrev eb dluohs uoY .oot ,stnemnorivne bal ni esu ot taerg stI .pleH SOI esu lla eW .uoy ot gniyl si sdna mmoc elbaliava eht lla rebmemer
33921# EI CC tn ayrB sirhC ,sse ccuS ruo Y oT

Bryant BCMSN Study Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bryant BCMSN Study Guide

Uploaded by

Copyright:

Available Formats

careercert.blogspot.

The Bryant Advantage BCMSN Study Guide

Basic Switch Operation & Configuration

Let's look at these possibilities using the following network.

SWITCH_2(config-line)#line console 0 SWITCH_2(config-line)#password CCIE SWITCH_2(config-line)#login SWITCH_2(config)#enable password CCNA

Copyright 2007 The Bryant Advantage. All Rights Reserved.

The Bryant Advantage BCMSN Study Guide

Virtual LANs (VLANs)

SW1(config-if)#int fast 0/2 SW1(config-if)#switchport mode access SW1(config-if)#switchport access vlan 12

HOST1#ping 172.12.123.3 Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:

..... Success rate is 0 percent (0/5)

look at each right now.

PTD dna ,)"q1tod"( q1.208 EEEI,)LSI( locotorP kniL hctiwS-retnI

Vlans allowed on trunk 12

Port Fa0/1 Port Fa0/1

Vlans allowed on trunk 1-4094 1-4094

Port Fa0/11 Fa0/12 Port Fa0/11 Fa0/12

The prompt changed appropriately, so let's create VLAN 30.

Copyright 2007 The Bryant Advantage. All Rights Reserved.

The Bryant Advantage BCMSN Study Guide

VLAN Trunking Protocol (VTP)

Attempting to create a VLAN on a VTP client results in the following message:

The VTP mode is changed with the vtp mode command.

Port Fa0/11 Fa0/12

SW1#show vtp password VTP Password: CCIE

Copyright 2007 The Bryant Advantage. All Rights Reserved.

The Bryant Advantage BCMSN Study Guide

Spanning Tree Protocol Basics

Now this is redundancy! We've got three separate switches connecting

Forward Delay 15 sec

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

Forward Delay 15 sec

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

The cost is lowered for this port in VLAN 100....

Forward Delay 20 sec

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

Forward Delay 15 sec

This command has another option you should be aware of:

Forward Delay 15 sec

Forward Delay 15 sec

Forward Delay 15 sec

Aging Time 300

Forward Delay 15 sec

bridge priority in increments of 4096

Forward Delay 15 sec

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

Forward Delay 15 sec

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

Forward Delay 15 sec

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

Priority Address Cost Port Hello Time

32783 000e.d7f5.a040 19 12 (FastEthernet0/12) 2 sec Max Age 20 sec

Forward Delay 15 sec

Forward Delay 15 sec

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

... VLANs 15 - 20 would begin using the 0/11 trunk.

Forward Delay 15 sec

32783 (priority 32768 sys-id-ext 15) 000f.90e2.14c0

Hello Time 2 sec Aging Time 300

Max Age 20 sec

Forward Delay 15 sec

Here's what the