Cisco CCNP Switching Study Guide: V1.21 - Aaron Balchunas

CCNP Switching Study Guide v1.
21 – Aaron Balchunas 1
___________________________________________
Cisco CCNP Switching Study Guide

V1.21 © 2007
________________________________________________
Aaron Balchunas
aaron@routeralley.com
http://www.routeralley.com
________________________________________________
Foreword:
This study guide is intended to provide those pursuing the CCNP

certification with a framework of what concepts need to be studied. This is
not a comprehensive document containing all the secrets of the CCNP
Switching exam, nor is it a “braindump” of questions and answers.
This document is freely given, and can be freely distributed. However, the
contents of this document cannot be altered, without my written consent.
Nor can this document be sold or published without my expressed consent.
I sincerely hope that this document provides some assistance and clarity in
your studies.
________________________________________________
***
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
CCNP Switching Study Guide v1.21 – Aaron Balchunas 2
Table of Contents
Part I – General Switching Concepts
Section 1 Ethernet Standards
Section 2 Hubs vs. Switches vs. Routers
Section 3 Switching Models
Section 4 Switching Tables
Part II – Switch Configuration

Section 5 Basic Switch Management
Section 6 Switch Port Configuration
Part III – Switching Protocols and Functions

Section 7 VLANs and VTP
Section 8 EtherChannel
Section 9 Spanning-Tree Protocol
Section 10 Multilayer Switching
Section 11 SPAN
Part IV– Advanced Switch Services

Section 12 Redundancy and Load Balancing
Section 13 Multicast
Section 14 Introduction to Quality of Service
Section 15 DiffServ QoS
Section 16 Congestion Avoidance (WRED)
Part V – Switch Security

Section 17 AAA
Section 18 Switch Port and VLAN Security
***
________________________________________________
Part I
General Switching Concepts
________________________________________________
***
Section 1
- Ethernet -
What is Ethernet?
Ethernet has become the standard technology used in LAN networking. Over
time, the Ethernet standard has evolved to satisfy bandwidth requirements,
resulting in various IEEE “categories” of Ethernet:
• 802.3 - Ethernet (10 Mbps)
• 802.3u - Fast Ethernet (100 Mbps)
• 802.3z or 802.3ab - Gigabit Ethernet (1000 Mbps)
Various subsets of these Ethernet categories exist, operating at various speeds,
distances, and cable types:
Standard Cable Type Speed Max. Distance
10base2 Coaxial (thinnet) 10 Mbps 185 meters
10base5 Coaxial (thicknet) 10 Mbps 500 meters
10baseT Twisted-pair 10 Mbps 100 meters
100baseT Twisted-pair 100 Mbps 100 meters
1000baseSX Fiber (multi-mode) 1 Gbps >500 meters
1000baseLX Fiber (single-mode) 1 Gbps > 3 km
Half-Duplex vs. Full-Duplex

Ethernet devices can operate either at half-duplex, or full-duplex. At half
duplex, devices can either transmit or receive data, but not simultaneously.
Full-duplex allows devices to both transmit and receive at the same time.
Devices connected to a hub can only operate at half-duplex, whereas devices
connected to a switch can operate at full-duplex.
Half-duplex Ethernet uses Carrier Sense Multiple Access with Collision
Detect (CSMA/CD) to control media access. Devices monitor the physical
link, and will only transmit a frame if the link is idle. If two devices send a
packet simultaneously, a collision will occur. When a collision is detected, both
NICs will wait a random amount of time before resending their respective
packets. Full-duplex Ethernet does not use CSMA/CD.
Port speed and duplex can be either manually configured or auto-negotiated
with a hub or switch. However, a duplex mismatch will occur if one side is
configured manually, and the other configured for auto-negotiation.
***
Ethernet (10 Mbps)
The first incarnation of Ethernet operated at 10 Mbps, over thinnet

(10base2), thicknet (10base5), or twisted pair (10baseT) mediums.
Ethernet’s specifications were outlined in the IEEE 802.3 standard.
Even though the term “Ethernet” is widely used to describe any form of
Ethernet technology, technically the term refers to the 10 Mbps category.
The most common implementation of Ethernet is over Category 5 twisted-
pair cable, with a maximum distance of 100 meters.
Full Duplex Ethernet allows devices to both send and receive

simultaneously, doubling the bandwidth to 20 Mbps per port. Only devices
connected to a switch can operate at Full Duplex.
Fast Ethernet
Fast Ethernet, or IEEE 802.3u, operates at 100 Mbps, utilizing Category 5

twisted-pair (100base-TX) or fiber cabling (100base-FX).
Full Duplex Fast Ethernet allows devices connected to a switch to both send
and receive simultaneously, doubling the bandwidth to 200 Mbps per port.
Many switches (and hubs) support both Ethernet and Fast Ethernet, and are
commonly referred to as 10/100 switches. These switches will auto-
negotiate both port speed and duplex.
As mentioned earlier, it is also possible to statically configure this

information. Both the device and switch must be configured for auto-
negotiation (or both configured with the same static settings), otherwise a
duplex mismatch error will occur.
***
Gigabit Ethernet
Gigabit Ethernet operates at 1000 Mbps, and can be utilized over Category
5e twisted-pair (1000baseT) or fiber cabling (1000baseSX or 1000baseLX).
Gigabit Ethernet over copper is defined in the IEEE 802.3ab standard.
Full Duplex Gigabit Ethernet allows devices connected to a switch to both
send and receive simultaneously, doubling the bandwidth to 2000 Mbps.
Newer switches can support Ethernet, Fast Ethernet, and Gigabit Ethernet
simultaneously, and are often referred to as 10/100/1000 switches. Again,
switches and devices can auto-negotiate both speed and duplex.
10 Gigabit Ethernet has also been developed, defined in the IEEE 802.3ae
standard, and currently can operate only over fiber cabling.
Twisted-Pair Cabling
Twisted-pair cable usually contains 2 or 4 pairs of wire, which are twisted
around each other to reduce crosstalk. Crosstalk is a form of
electromagnetic interference (EMI) or “noise” that reduces the strength and
quality of a signal. It is caused when the signal from one wire “bleeds” or
interferes with another wire’s signal.
Twisted-pair cabling can be either shielded or unshielded. Shielded twisted-
pair is more resistant to from external EMI. Florescent light ballasts,
microwaves, and radio transmitters can all create EMI.
There are various categories of twisted-pair cable, identified by the number
of “twists per inch.”
• Category 3 (three twists per inch)
• Category 5 (five twists per inch)
• Category 5e (five twists per inch, pairs are twisted around each
other)
Category 5 (and 5e) twisted-pair cabling usually contains four pairs of wire
(eight wires total), and each wire is assigned a color:
• White Orange • White Blue
• Orange • Blue
• White Green • White Brown
• Green • Brown
***
Types of Twisted-Pair Cables

Various types of twisted-pair cables can be used. A straight-through cable
is used in the following circumstances:
• From a host to a hub (or switch)
• From a router to a hub (or switch)
The pins (wires) on each end of a straight-through cable must be identical.
The most common straight-through standard is wired as follows:
1 White Orange ------------------------ White Orange 1
2 Orange ------------------------ Orange 2
3 White Green ------------------------ White Green 3
4 Blue ------------------------ Blue 4
5 White Blue ------------------------ White Blue 5
6 Green ------------------------ Green 6
7 White Brown ------------------------ White Brown 7
8 Brown ------------------------ Brown 8
A cross-over cable is used in the following circumstances:
• From a host to a host
• From a hub to a hub
• From a switch to a switch
• From a hub to a switch
• From a router to a router
To make a crossover cable, we must swap pins 1 and 3, and pins 2 and 6 on
one end of the cable. The most common crossover standard is as follows:
1 White Orange ------------------------ White Green 3

2 Orange ------------------------ Green 6
3 White Green ------------------------ White Orange 1
4 Blue ------------------------ Blue 4
5 White Blue ------------------------ White Blue 5
6 Green ------------------------ Orange 2
7 White Brown ------------------------ White Brown 7
8 Brown ------------------------ Brown 8
Remember, when connecting anything into a hub or switch, except for
another hub or switch, we use a straight-through cable. When connecting
“like” devices, we use a crossover cable.
***
Types of Twisted-Pair Cables (continued)
Finally, a roll-over cable is used to connect a PC into a Cisco router’s

console or auxiliary port.
The pins are completely reversed on one end to make a rollover cable:
1 White Orange ------------------------ Brown 8

2 Orange ------------------------ White Brown 7
3 White Green ------------------------ Green 6
4 Blue ------------------------ White Blue 5
5 White Blue ------------------------ Blue 4
6 Green ------------------------ White Green 3
7 White Brown ------------------------ Orange 2
8 Brown ------------------------ White Orange 1
***
Section 2
- Hubs vs. Switches vs. Routers -
“Layered” Communication
The OSI model represents seven “layers” that define how network
communication should occur.
As data “travels” from the user application down the layers of the OSI
model, each of the lower layers adds a header (and sometimes trailer)
containing information specific to that layer. These “headers” are called
Protocol Data Units (PDUs), and the process of adding these headers is
called encapsulation.
Depending on what layer we are looking at, the data’s PDU is identified
with different terms:
Layer PDU Name
Application Data
Presentation Data
Session Data
Transport Segments
Network Packets
Data-link Frames
Physical Bits
When we identify the layer that certain devices operate at, we are actually
identifying what “header” or “PDU” that device looks at. For example, we
usually identify switches as Layer 2 devices, because switches look for
MAC address information stored in the Data-Link header of a frame.
Similarly, we identify routers as Layer 3 devices, because routers look for
logical (usually IP) addressing information in the Network header of a
packet.
However, switches can also operate at higher layers of the OSI model, as
described on subsequent pages in this guide.
***
Layer 1 Hubs
Hubs are Layer 1 devices that physically connect network devices together
for communication.
Hubs do not look at the Data-Link header, and thus cannot make intelligent
forwarding decisions based on MAC address. Thus, hubs will always
forward every frame, including unicasts, out every port, excluding the port
that frame originated from.
Ethernet hubs operate at half-duplex. At half duplex, devices can either
transmit or receive data, but not simultaneously.
Half-duplex Ethernet uses Carrier Sense Multiple Access with Collision
Detect (CSMA/CD) to control media access. Devices monitor the physical
link, and will only transmit a frame if the link is idle. If two devices send a
packet simultaneously, a collision will occur. When a collision is detected,
both NICs will wait a random amount of time before resending their
respective packets.
All ports on a hub belong to the same collision domain. If devices
connected to a hub send a frame simultaneously, a collision will occur.
Hubs belong to only one broadcast domain. A hub will forward both
broadcasts and multicasts out every port, except for the port the broadcast or
multicast originated from. Only Layer 3 devices, such as routers, can be
break up broadcast domains.
***
Layer 2 Switching
Layer-2 switches build MAC address tables that allow them to make
intelligent forwarding decisions on frames. The MAC address table
maintains a list of MAC addresses and the switch port those MACs are
associated with. Layer 2 switches are also referred to as multi-port
transparent bridges.
When a Layer-2 switch is first powered on, it will flood every frame,
including unicasts, out every port (excluding the port the frame originated
from).
Switches will build their MAC address tables by looking at the source MAC
address on each frame.
Consider the above diagram. We’ll assume that Computer A is attached to

interface fa0/10, and Computer B is attached to interface fa0/11. When
Computer A sends a frame to Computer B, the switch will add Computer
A’s MAC address to its table, associating it with port fa0/10.
However, the switch will not learn Computer B’s MAC address until
Computer B sends a frame to Computer A, or to another device connected to
the switch.
A switch is always in a perpetual state of learning. However, as the MAC
address table becomes populated, the flooding of frames will decrease,
allowing the switch to make more intelligent forwarding decisions.
These forwarding decisions are made at wire speed, due to specialized
hardware circuits called ASICs (Application-Specific Integrated Circuits).
***
Layer 2 Switching (continued)

Unlike hubs, switches can operate in Full Duplex, and thus each individual
port on a switch belongs to its own collision domain. Thus, switches create
more collision domains, which results in fewer collisions.
However, both hubs and switches belong to only ONE broadcast domain.
Thus, Layer-2 switches will forward a broadcast or multicast out every port,
excluding the port the broadcast or multicast originated from.
Only Layer-3 devices can break apart broadcast domains. Because of this,
Layer-2 switches are not well suited for large, scalable networks. Layer-2
switches make forwarding decisions solely based on Data-Link layer MAC
addresses, and thus have no way of differentiating between one network and
another.
Imagine the problems that this poses. If we only had data-link layer (or
hardware) addressing, all devices would technically be on the same network.
Modern network systems like the Internet could not exist, as there would be
no way to separate my network from your network.
Furthermore, imagine that the entire Internet was a purely switched, data-
link layer environment. Switches, as a rule, forward broadcasts out all ports.
Conservatively estimating that there are a billion devices on the Internet,
with each device sending out a broadcast on average every 10 seconds, the
broadcast storms that would result would be devastating. The Internet would
simply collapse.
Switches are also susceptible to switching loops, which can cause
destructive broadcast storms. Switches utilize the Spanning Tree Protocol
(STP) to maintain a loop-free environment.
Remember, there are three things that switches do that hubs do not:
• Address Learning
• Intelligent forwarding and filtering
• Loop Avoidance
***
Layer 2 Switching Methods

Switches support three “methods” of forwarding frames. Each provides a
different level of latency and reliability. Latency is otherwise known as
delay. Less latency indicates quicker forwarding.
The Cut-Through (Real Time) method reads only the header of a frame to
determine its destination address. This method transfers frames at “wire
speed,” and has the least latency of any of the three methods. No error
checking is attempted when using the cut-through method.
The FragmentFree (Modified Cut-Through) method reads only the first
64 bytes of a frame, which is minimize size of an Ethernet packet. Most
collisions or corruption occurs in the first 64 bytes of a frame. This is the
default mode for a Catalyst 1900 family switch.
The Store-and-Forward method reads the entire frame, and performs a
Cycle Redundancy Check (CRC) to ensure complete reliability. However,
this additional error-checking causes store-and-forward to have the highest
latency of any of the switching methods.
***
Layer 3 Routing
Layer 3 Routing is the process of sending a packet of information from one
network to another network. Thus, routes are usually based on the
destination network, and not the destination host (host routes can exist, but
are used only in rare circumstances). A Layer 3 router looks at the Network
layer header of packets for this logical addressing information.
To route, routers build routing tables that contain the following:
• The destination network and subnet mask
• The “next hop” router to get to the destination network
• Routing metrics and Administrative Distance
The routing table is concerned with two types of protocols:
• A routed protocol is a layer 3 protocol that applies logical addresses
to devices and routes data between networks. Examples would be IP
and IPX.
• A routing protocol dynamically builds the network, topology, and
next hop information in routing tables. Examples would be RIP,
IGRP, OSPF, etc.
Each port on a Layer 3 router belongs to its own collision domain. Thus,
routers are like switches, in that they create more collision domains, which
results in fewer collisions.
However, unlike Layer 2 switches, Layer 3 routers also break up broadcast
domains. As a rule, routers will never forward broadcasts from one network
to another network. Routers, by default, will not forward multicasts either,
unless they are configured to participate in a multicast tree.
Layer 3 routers must examine the Network layer header of each packet
before that data can be “routed.” Thus, each packet consumes CPU cycles as
it passes through the router, resulting in latency. Layer 3 routers do not have
ASICs to allow routing to occur at “wire speed."
Thus, routing is always slower than switching.
***
Collision vs. Broadcast Domain Example
In the above example, there are THREE broadcast domains, and EIGHT
separate collision domains.
• Each port coming off a router creates a separate broadcast AND
collision domain.
• Each port of a switch creates a separate collision domain.
• Hubs belong to only one collision domain, and switches and hubs both
only belong to one broadcast domain.
***
Layer 3 Switching
Layer 3 switches group ports together into separate Virtual LANs
(VLANs). Each VLAN belongs to a separate broadcast domain, and usually
to a separate IP subnet. Broadcasts from one VLAN will never be forwarded
to another VLAN.
Layer 3 switches look at both the Data-link and Network layer headers, for
MAC address and IP address information respectively. Thus, Layer 3
switches can make intelligent forwarding decisions based on both hardware
and logical addresses. Layer 3 switches use routing modules to allow routing
to occur between logical networks. This is called interVLAN routing.
Layer 3 switches keep track of IP address traffic flows. Consider the
following diagram:
Si
Layer 3
Switch
Computer A Computer B
VLAN1 VLAN2
If Computer A sends a packet to Computer B, the Layer 3 switch will add

Computer A’s MAC address to its MAC address table, just like a Layer 2
switch would.
Because Computer A and Computer B are on different VLANs, the Layer 3
switch must route the packet. However, the Layer 3 switch will also cache a
shortcut of this IP flow. Because of this caching, the next time Computer A
sends a packet to Computer B, the packet can be switched instead of routed.
Please note: VLANs are not a Layer 3 function. Layer 2 switches also
support VLANs; however, Layer 2 switches cannot route between VLANs.
This is explained in detail in another guide.
Remember that a Layer 2 switch’s ASICs allow frames to be forwarded at
wire speed. Layer 3 switches allow packets to be forwarded at wire speed
too. Thus, Layer 3 switches have far less latency than Layer 3 routers.
***
Layer 4 Switching
Layer 4 switches, like Layer 3 switches, will examine both the Data-link and
Network layer headers, for MAC address and IP address information
respectively. Thus, Layer 4 switches will also make intelligent forwarding
decisions based on both hardware and logical addresses.
However, Layer 4 switches also examine the Transport layer header of a
segment for TCP and UDP port number information. Thus, Layer 4 switches
not only cache IP address traffic flows, but also Layer 4 application flows.
Si
Layer 4
Switch
Client Webserver
VLAN1 VLAN2
Consider the above example. If the Client requests data from the Webserver,
the Layer 4 switch will add the Client’s MAC address to the MAC table.
The Layer 4 switch will also cache the IP traffic flow between the Client and
the Webserver, allowing subsequent information to be switched instead of
routed, to reduce latency.
The Layer 4 switch will further cache the Application traffic flow, based on
TCP or UDP port number, between the Client and Webserver. In this case,
The Client will be accessing TCP port 80 on the Webserver.
Caching application traffic flows allow administrators to apply QoS
(Quality of Service) to specific applications. In the above example, we
could provide a higher level of service (i.e. more bandwidth) to HTTP than
any other application flow.
Layer 4 switches require more memory than Layer 2 or 3 switches to keep
track of application traffic flows.
***
Multilayer Switching
Multilayer switching is a generic term that describes devices that support
Layer 2, Layer 3, and Layer 4 switching.
Thus, multilayer switches have the following characteristics:
• Build MAC address tables associating MACs with switch ports
• Cache IP (or logical) address traffic flows
• Cache TCP or UDP (application) traffic flows
• Apply QoS to traffic flows
A key characteristic of Multilayer switches is the ability to “switch” Layer 2
frames, Layer 3 packets, and Layer 4 segments at wire speed. This ability is
provided by hardware ASICs, and ensures less latency than Layer 3 routers.
***
Section 3
- Switching Models -
Network Traffic Models
When designing scalable, efficient networks, it is critical to consider how
traffic “flows” through the network, rather than simply concentrating on the
type of traffic. A traffic flow is a map of the path data takes to get from a
source to a destination, and the type of data being transmitted.
Originally, proper network design followed the 80/20 rule, which dictates
that 80 percent of the traffic remains on the local network, and only 20
percent should be routed to another network. This allowed a majority of the
traffic to be switched instead of routed, and thus latency was reduced.
Servers and resources were thus placed close to the users that required them.
However, the architecture of networks has been changing. Instead of placing
“workgroup” servers in every local network, many organizations have
centralized their resources. Internet web servers, email servers, and IP
telephony are examples of this trend. Thus, a majority of traffic must be
“routed” to a centralized network. This concept is identified as the 20/80
rule.
Because routing introduces more latency than switching, the 20/80 rule has
dictated a need for a faster Layer 3 technology, namely Layer 3 switching.
***
The Cisco Hierarchical Network Model

Cisco developed a hierarchical model to serve as a guideline to proper
network design. This model is separated into three layers:
Si Si
Si Si
• Access Layer – The Access Layer is where the end user connects into
the network. Access Layer switches generally have a high number of
low-cost ports per switch, and VLANs are usually configured at this
Layer. In a distributed environment (80/20 rule), servers and other
such resources are kept close to users in the Access Layer.
• Distribution Layer – The Distribution Layer provides end users with
access to the Core (backbone) Layer. Security (using access-lists) and
QoS are usually configured at the Distribution Layer.
• Core Layer – The Core Layer is the “backbone” of the network. The
Core Layer is concerned with switching data quickly and efficiently
between all other “layers” or “sections” of the network. In a
centralized environment (20/80 rule), servers and other such
resources are placed in their own “dedicated” Access Layer, and the
Core Layer must switch traffic from all other Access Layers to this
Server Block.
***
Example of the Cisco Hierarchical Network Model
Servers Internet
Internet Border
Router
Server Farm Distribution Distribution

Block Si MultiLayer Switch MultiLayer Switch Si Enterprise
Edge Block
Core MultiLayer Core MultiLayer

Switch Si Core Block Si Switch
Distribution Distribution
MultiLayer Switch Si Si MultiLayer Switch
Access Workgroup Access Workgroup Access Workgroup Access Workgroup

Switch Switch Switch Switch
“User” Switch Block “User” Switch Block
Cisco likes to break down network hierarchies into separate “blocks.” Notice
that the Core Block, which connects all other blocks, has redundant links to
all distribution layer switches.
The Switch Block contains the Distribution and Access Layer switches that
service end users. The Server Farm Block contains all network resources
that end users need access to. The Enterprise Edge Block connects this
Autonomous System to the Internet.
The above is an example of a Dual Core design, where there is a clearly
defined Core layer separated from the Distribution Layer. Network designs
that do not require a separately defined Core layer can instead combine the
functions of the Core and Distribution layers, in a Collapsed Core design.
***
Cisco Switching Products

Cisco offers a wide variety of Catalyst switches that fit within each Layer of
the Cisco Hierarchical network model:
Access Layer Switches:

Model Max. Port Density Max. Backplane
Catalyst 2950 48 “10/100” ports 13.6 Gpbs

Catalyst 3550 (SMI) 48 “10/100” ports or 24 Gpbs
12 “10/100/1000” ports
Catalyst 4000/4500 240 “10/100/1000” ports 64 Gpbs
with Supervisor Engine
III or IV
Distribution and Core Layer Switches:

Model Max. Port Density Max. Backplane
Catalyst 3550 (EMI) 48 “10/100” ports or 24 Gpbs

12 “10/100/1000” ports
Catalyst 6500 Over 500 “10/100/1000” 256 Gpbs
ports
There are no hard rules that dictate that you must use a certain model of
switch in a specific layer. The above tables are only guidelines. For example,
if a network supports a large number of users in the Access Layer, it might
be beneficial to use a Catalyst 6500 to support those users.
A Supervisor Engine provides the software (usually the Cisco IOS) and
processor to allow Cisco Catalyst switches to operate. The Supervisor
Engine is the mechanism that allows multilayer switching to occur.
The Cisco Catalyst 3550 has two specific software “images,” SMI
(Standard MultiLayer Image) and EMI (Enhanced MultiLayer Image).
The EMI software provides support for Layer 3 routing protocols, such as
OSPF and EIGRP.
***
Section 4
- Switching Tables -
The Layer 2 Switching “Process”
Layer 2 switches contain queues where frames are stored after they are
received and before they are sent.
When a Layer 2 switch receives a frame on a port, it places that frame in one
of the port’s ingress queues. When the switch decides which port that frame
should sent out of, it places the frame in that port’s egress queue. If the
destination MAC address in the frame is not in the MAC address table, the
frame is placed in the egress queue of all ports and is flooded throughout the
network.
Each port can be configured with multiple ingress or egress queues. Using
Quality of Service (QoS), each queue can be assigned a different priority.
Thus, we can give a higher preference to more critical traffic, such as video
conferencing, by placing that traffic in a high priority queue.
Before a Layer 2 switch can take a frame from one port’s ingress queue to
another port’s egress queue, it must consult two tables:
• Content Addressable Memory (CAM), which is Cisco’s term for the
MAC address table. It can also be referred to as the Layer 2
Forwarding Table.
• Ternary Content Addressable Memory (TCAM), which contains
access lists that can filter frames by MAC address, and QoS access-
lists to prioritize traffic. In multi-layer switches, the TCAM also
contains access lists to filter frames based on IP address or TCP/UDP
port.
Both the CAM and TCAM are stored in RAM, so that information lookup is
quick. Throughout the rest of this guide, the MAC address table will be
referred to as the CAM.
***
Content Addressable Memory (CAM)

As stated before, Cisco refers to a Catalyst switch’s MAC address table as
Content Addressable Memory (CAM).
Remember that switches only place the source MAC address of a frame in
the CAM. Additionally, the CAM stores which port and VLAN the frame
was received from.
By default, dynamically learned MAC addresses are stored for 300 seconds
in the CAM. After 300 seconds, if no activity is received from that MAC
address, its entry is removed from the CAM. MAC address entries can also
be statically entered into the CAM.
The following is a sample output of the CAM, using the command:
Switch# show mac address-table dynamic
Destination Address Address Type VLAN Destination Port

------------------- ------------ ---- --------------------
0000.001e.2a52 Dynamic 1 FA1/1
0000.001e.345e Dynamic 1 FA1/1
0000.001e.bb3a Dynamic 1 FA1/1
0000.001e.eba3 Dynamic 1 FA1/2
0000.001e.face Dynamic 1 FA1/3
0000.001e.3519 Dynamic 1 FA1/4
0000.001e.2dc1 Dynamic 1 FA1/5
0000.001e.8465 Dynamic 1 FA1/5
0000.001e.1532 Dynamic 1 FA1/5
0000.001e.8ab2 Dynamic 1 FA1/6
0000.001e.15b1 Dynamic 1 FA1/6
0000.005a.1b01 Dynamic 1 FA1/6
0000.005a.4214 Dynamic 1 FA1/7
0000.005a.5129 Dynamic 1 FA1/8
0000.00cc.bbe2 Dynamic 1 FA1/9
0000.00cc.2291 Dynamic 1 FA1/10
Don’t be confused that the columns are labeled “destination” address and
“destination” port. The MAC address is always learned from the source
MAC. However, once the address is learned, that address is used as a
possible “destination” address for any new frames the switch receives.
***
Configuring the CAM

To change the aging timer for dynamically learned MAC addresses in the
CAM from its default of 300 seconds to 360 seconds:
Switch(config)# mac address-table aging-time 360
To statically add to the CAM a MAC address of 0011.2233.4455, which

resides on Port FA0/0 on VLAN 1:
Switch(config)# mac address-table static 0011.2233.4455 vlan 1 interface fa0/0
Please note, in earlier versions of the Cisco IOS (prior to 12.1), the
command syntax for the above commands contained an additional hyphen
between “mac” and “address”:
Switch(config)# mac-address-table aging-time 360
Switch(config)# mac-address-table static 0011.2233.4455 vlan 1 interface fa0/0
To view all dynamic MAC entries in the CAM:

Switch# show mac address-table dynamic
To view a specific dynamic address in the CAM:

Switch# show mac address-table dynamic address 1234.5678.90ab
To view the number of MAC addresses per VLAN:

Switch# show mac address-table count
To clear the entire dynamic contents of the CAM:

Switch# clear mac address-table dynamic
To clear a single entry of the CAM:

Switch# clear mac address-table dynamic 1234.5678.90ab
***
Ternary Content Addressable Memory (TCAM)

The TCAM integrates access lists into its table, allowing filtering to occur
on the fly. On multi-layer switches, the TCAM can filter not only MAC
addresses, but also IP addresses and TCP/UDP ports. Additionally, QoS
access lists can be integrated into the TCAM to prioritize traffic.
The TCAM consists of two components:
• Feature Manager (FM) – Integrates access lists into the TCAM
• Switching Database Manager (SDM) – Maintains TCAM partitions
Multiple TCAMs can exist on a single router. For example, there are
TCAMs for inbound traffic, outbound traffic, and for QoS information.
The TCAM table is more complex than the CAM. The CAM is a flat table
containing only MAC address, VLAN, and port information. Entries in the
TCAM table contain three parameters:
• Values – consists of the addresses or ports that must be matched
• Masks – dictates how much of the address to match
• Result – what action to take when a match occurs
For example, if we created the following access list:
access-list 150 permit tcp 172.16.0.0 0.0.255.255 host 172.17.1.1 eq 23
access-list 150 deny tcp 172.16.0.0 0.0.255.255 host 172.17.1.1 eq 80
The Feature Manager (FM) will automatically integrate the access-lists into
the TCAM. Configuring the TCAM consists solely of creating the necessary
access-lists.
The values are the source of 172.16.0.0, and the destination of 172.17.1.1.
The masks in this case are 0.0.255.255 for the 172.16.0.0 source network,
dictating that the last two octets can be anything. A mask of 0.0.0.0 is given
to the destination host 172.17.1.1, indicating it must be an exact match.
The result in this case is either permit or deny. However, other results are
possible when using QoS access-lists, which is more concerned with
prioritizing traffic than filtering it.
***
________________________________________________
Part II
Switch Configuration
________________________________________________
***
Section 5
- Basic Switch Management -
Catalyst Operating Systems
Catalyst switches, depending on the model, support one of two possible
operating systems:
• Catalyst OS (CatOS)
• IOS
The CatOS is an antiquated interface based on “set” commands. Retired
Catalyst models such as the 40xx and 50xx series supported the CatOS
interface.
Modern Catalyst switches support the Cisco IOS, enhanced with switching-
specific commands. Catalyst models that support the Cisco IOS include:
• 29xx series
• 35xx series
• 37xx series
• 45xx series
• 49xx series
• 65xx series
The Cisco IOS interface on Catalyst switches is nearly identical to that of the
router IOS (with the exception of the switching-specific commands). The
IOS is covered in great detail in other guides on this site, specifically:
• Router Components
• Introduction to the Cisco IOS
• Advanced IOS Functions
Some basic IOS concepts will be reviewed in this guide. For more
comprehensive information, please consult the above guides.
***
Using Lines to Configure the IOS

Three methods (or lines) exist to configure Cisco IOS devices (including
Catalyst switches):
• Console ports
• Auxiliary ports
• VTY (telnet) ports
Nearly every modern Cisco router or switch includes a console port,
sometimes labeled on the device simply as con. The console port is generally
a RJ-45 connector, and requires a rollover cable to connect to. The opposite
side of the rollover cable connects to a PC’s serial port using a serial
terminal adapter.
From the PC, software such as HyperTerminal is required to make a
connection from the local serial port to the router console port. The
following settings are necessary for a successful connection:
• Bits per second - 9600 baud
• Data bits - 8
• Parity - None
• Stop bits - 1
• Flow Control - Hardware
Some Cisco devices include an auxiliary port, in addition to the console
port. The auxiliary port can function similarly to a console port, and can be
accessed using a rollover cable. Additionally, auxiliary ports support modem
commands, thus providing dial-in access to Cisco devices.
Telnet, and now SSH, are the most common methods of remote access to
routers and switches. The standard edition of the IOS supports up to 5
simultaneous VTY connections. Enterprise editions of the IOS support up
to 255 VTY connections.
There are two requirements before a Catalyst switch will accept a VTY
connection:
• An IP address must be configured on the Management VLAN
(by default, this is VLAN 1)
• At least one VTY port must be configured with a password
***
IOS Modes on Cisco Catalyst Switches

The Cisco IOS is comprised of several modes, each of which contains a set
of commands specific to the function of that mode.
By default, the first mode you enter when logging into a Cisco device is
User EXEC mode. User mode appends a “>” after the device hostname:
Switch>
No configuration can be changed or viewed from User mode. Only basic

status information can be viewed from this mode.
Privileged EXEC mode allows all configuration files, settings, and status
information to be viewed. Privileged mode appends a “#” after the device
hostname:
Switch#
To enter Privileged mode, type enable from User mode:

Switch> enable
Switch#
To return back to User mode from Privileged mode, type disable:

Switch# disable
Switch>
Very little configuration can be changed directly from Privileged mode.

Instead, to actually configure the Cisco device, one must enter Global
Configuration mode:
Switch(config)#
To enter Global Configuration mode, type configure terminal from

Privileged Mode:
Switch# configure terminal
Switch(config)#
To return back to Privileged mode, type exit:

Switch(config)# exit
Switch#
***
IOS Modes on Cisco Catalyst Switches (continued)

As its name implies, Global Configuration mode allows parameters that
globally affect the device to be changed. Additionally, Global Configuration
mode is sectioned into several sub-modes dedicated for specific functions.
Among the most common sub-modes are the following:
• Interface Configuration mode - Switch(config-if)#
• Line Configuration mode - Switch(config-line)#
Recall the difference between interfaces and lines. Interfaces connect

routers and switches to each other. In other words, traffic is actually routed
or switched across interfaces. Examples of interfaces include Serial, ATM,
Ethernet, Fast Ethernet, and Token Ring.
To configure an interface, one must specify both the type of interface, and
the interface number (which always begins at “0”). Thus, to configure the
first Ethernet interface on a router:
Switch(config)# interface ethernet 0
Switch(config-if)#
Lines identify ports that allow us to connect into, and then configure, Cisco
devices. Examples would include console ports, auxiliary ports, and VTY
(or telnet) ports.
Just like interfaces, to configure a line, one must specify both the type of
line, and the line number (again, always begins at “0”). Thus, to configure
the first console line on a switch:
Switch(config)# line console 0
Switch(config-line)#
Multiple telnet lines can be configured simultaneously. To configure the first

sixteen telnet (or VTY) lines on a switch:
Switch(config)# line vty 0 15
Switch(config-line)#
Notice that Catalyst switches natively support up to 16 VTY connections. A

Cisco router running the standard IOS supports up to 5 VTY connections.
Remember that the numbering for both interfaces and lines begins with “0.”
***
Enable Passwords
The enable password protects a switch’s Privileged mode. This password
can be set or changed from Global Configuration mode:
Switch(config)# enable password MYPASSWORD
Switch(config)# enable secret MYPASSWORD2
The enable password command sets an unencrypted password intended for

legacy systems that do not support encryption. It is no longer widely used.
The enable secret command sets an MD5-hashed password, and thus is far
more secure. The enable password and enable secret passwords cannot be
identical. The switch will not accept identical passwords for these two
commands.
Line Passwords and Configuration

Passwords can additionally be configured on switch lines, such as telnet
(vty), console, and auxiliary ports. To change the password for a console
port and all telnet ports:
Switch(config)# line console 0 Switch(config)# line vty 0 15
Switch(config-line)# login Switch(config-line)# login
Switch(config-line)# password cisco1234 Switch(config-line)# password cisco1234
Switch(config-line)# exec-timeout 0 0 Switch(config-line)# exec-timeout 0 0

Switch(config-line)# logging synchronous Switch(config-line)# logging synchronous
The exec-timeout 0 0 command is optional, and disables the automatic

timeout of your connection. The two zeroes represent the timeout value in
minutes and seconds, respectively. Thus, to set a timeout for 2 minutes and
30 seconds:
Switch(config-line)# exec-timeout 2 30
The logging synchronous command is also optional, and prevents system

messages from interrupting your command prompt.
By default, line passwords are stored in clear-text in configuration files. To
ensure these passwords are encrypted in all configuration files:
Switch(config)# service password–encryption
***
Catalyst Configuration Files

Like Cisco routers, Catalyst switches employ a startup-config file (stored in
NVRAM) and a running-config (stored in RAM). The startup-config is the
saved configuration used when a router boots, and the running-config is the
currently active configuration.
Any configuration change made to an IOS device is made to the running-
config. Because the running-config file is stored in RAM, the contents of
this file will be lost during a power-cycle. To save the contents of the
running-config to the startup-config file:
Switch# copy run start
Catalyst switches additionally employ the following configuration and

diagnostic files, all stored in Flash memory:
• vlan.dat
• system_env_vars
• crashinfo
The vlan.dat file contains a list all created VLANs, and includes any VTP
specific information. The vlan.dat file does not contain information on
interface-to-VLAN assignments (which is stored in the startup-config).
The system_env_vars file contains environmental information specific to
the Catalyst switch, including serial/model numbers and MAC addresses.
The crashinfo file contains memory-dump information about previous
switch failures.
To delete all files in flash:
Switch# erase flash:
To delete a specific file in flash:

Switch# erase flash:FILENAME
To delete a specific file in flash:

Switch# format flash:
To upload an IOS image file from a TFTP server to flash:

Switch# copy tftp: flash:FILENAME
***
Configuring Telnet Access on Catalyst Switches

Recall the two requirements to configure a Catalyst switch for VTY access:
• An IP address must be configured on the Management VLAN (by
default, this is VLAN 1)
• At least one VTY port must be configured with a password.
Configuring passwords on VTY lines was covered previously:
Switch(config)# line vty 0 15
Switch(config-line)# login
Switch(config-line)# password cisco1234
To assign an IP address to the Management VLAN:

Switch(config)# interface vlan 1
Switch(config-if)# ip address 192.168.123.151 255.255.255.0
Switch(config-if)# no shut
***
Section 6
- Switch Port Configuration -
Switch Port Configuration
To enter interface configuration mode for interface Fast Ethernet 0/10:
Switch(config)# interface fa0/10
Multiple individual ports can be configured simultaneously:

Switch(config)# interface range fa0/10 , fa0/12 , fa0/14
The above command selects ports fa0/10, fa0/12, and fa0/14. Please note the
space on either side of the commas.
A contiguous range of interfaces can be specified:
Switch(config)# interface range fa0/10 - 15
The above command selects ports fa0/10 through fa0/15. Please note the
space on either side of the dash.
Macros can be created for groups of ports that are configured often:
Switch(config)# define interface-range MACRONAME fa0/10 – 15
Switch(config)# interface range macro MACRONAME
The first command creates a macro, or “group,” of interfaces called

MACRONAME. The second command actually selects those interfaces for
configuration.
For documentation purposes, we can apply descriptions on interfaces:
Switch(config-if)# description DESCRIPTIONTEXT
To view the status of an interface (example, Fast Ethernet 0/10):

Switch# show interface fa0/10
This will also display duplex, speed, and packet errors on this particular
interface.
To view the errdisable state (explained shortly) of an interface:
Switch# show interface status err-disabled
***
Switch Port Configuration – Speed and Duplex

To specify the port speed of an interface:
Switch(config-if)# speed 10
Switch(config-if)# speed auto
To specify the duplex of an interface:

Switch(config-if)# duplex half
Switch(config-if)# duplex full
Switch(config-if)# duplex auto
Port Error Conditions

Catalyst switches can detect error conditions on a port, and if necessary
automatically disable that port. When a port is disabled due to an error, the
port is considered to be in errdisable state.
The following events can put a port into errdisable state:
• bpduguard – when a port configured for STP Portfast and BPDU
Guard receives a BDPU
• dtp-flap – when trunking encapsulation (ISL or 802.1Q) is “flapping”
• link-flap – when a port is flapping between an “up” or “down” state
• pagp-flap – when EtherChannel ports become inconsistently
configured
• rootguard – when a non-designated port receives a BDPU from a
root bridge
• udld – when data appears to be only sent in one direction
To enable all possible error conditions:
Switch(config)# errdisable detect cause all
To enable a specific error condition:

Switch(config)# errdisable detect cause link-flap
***
Port Error Conditions (continued)

To take a port out of errdisable state:

Switch(config-if)# shut
To allow switch ports to automatically recover from an errdisable state:

Switch(config)# errdisable recovery cause all
Switch(config)# errdisable recovery interval 250
The last line specifies the duration a port will remain in errdisable before
recovering. The default is 300 seconds.
***
________________________________________________
Part III
Switching Protocols and Functions
________________________________________________
***
Section 7
- VLANs and VTP -
Review of Collision vs. Broadcast Domains
In a previous guide, we learned that a “collision domain” is a segment where
a collision can occur, and that a Layer 2 switch running in Full Duplex
breaks up collision domains. Thus, Layer 2 switches create more collision
domains, which results in fewer collisions.
We also learned that Layer 2 switches do not break up broadcast domains,
and thus belong to only one broadcast domain. Layer 2 switches will
forward a broadcast or multicast out every port, excluding the port the
broadcast or multicast originated from.
Only Layer-3 devices can break apart broadcast domains. Because of this,
Layer-2 switches are not well suited for large, scalable networks. Layer-2
switches make forwarding decisions solely based on Data-Link layer MAC
addresses, and thus have no way of differentiating between one network and
another.
Virtual LANs (VLANs)

Virtual LANs (or VLANs) separate a Layer 2 switch into multiple
broadcast domains. Each VLAN is its own individual broadcast domain (i.e.
IP subnet).
Individual ports or groups of ports can be assigned to a specific VLAN.
Only ports belonging to the same VLAN can freely communicate; ports
assigned to separate VLANs require a router to communicate. Broadcasts
from one VLAN will never be sent out ports belonging to another VLAN.
Please note: a Layer 2 switch that supports VLANs is not necessarily a
Layer 3 switch. A Layer 3 switch, in addition to supporting VLANs, must
also be capable of routing, and caching IP traffic flows. Layer 3 switches
allow IP packets to be switched as opposed to routed, which reduces
latency.
***
VLAN Example
Consider the following example:
Four computers are connected to a Layer 2 switch that supports VLANs.

Computers A and B belong to VLAN 1, and Computers C and D belong to
VLAN 2.
Because Computers A and B belong to the same VLAN, they belong to the
same IP subnet and broadcast domain. They will be able to communicate
without the need of a router.
Computers C and D likewise belong to the same VLAN and IP subnet. They
also can communicate without a router.
However, Computers A and B will not be able to communicate with
Computers C and D, as they belong to separate VLANs, and thus separate IP
subnets. Broadcasts from VLAN 1 will never go out ports configured for
VLAN 2. A router will be necessary for both VLANs to communicate.
Most Catalyst multi-layer switches have integrated or modular routing
processors. Otherwise, an external router is required for inter-VLAN
communication.
By default with Cisco Catalysts, all ports on every switch belong to VLAN
1. VLAN 1 is also considered the management VLAN (by default).
***
Advantages of VLANs
VLANs provide the following advantages:
Broadcast Control – In a pure Layer 2 environment, broadcasts are
received by every host on the switched network. In contrast, each VLAN
belongs to its own broadcast domain (or IP subnet); thus broadcast traffic
from one VLAN will never reach another VLAN.
Security – VLANs allow administrators to “logically” separate users and
departments.
Flexibility and Scalability – VLANs remove the physical boundaries of a
network. Users and devices can be added or moved anywhere on the
physical network, and yet remain assigned to the same VLAN. Thus, access
to resources will never be interrupted.
VLAN Membership
VLAN membership can be configured one of two ways:
Statically – Individual (or groups of) switch-ports must be manually
assigned to a VLAN. Any device connecting to that switch-port(s) becomes
a member of that VLAN.
Dynamically – Devices are automatically assigned into a VLAN based on
its MAC address. Cisco developed a dynamic VLAN product called the
VLAN Membership Policy Server (VMPS). In more sophisticated
systems, a user’s network account can be used to determine VLAN
membership.
Catalyst switches that participate in a VTP domain (explained shortly)
support up to 1005 VLANs.
Catalyst switches configured in VTP transparent mode support up to 4094
VLANs.
***
Static VLAN Configuration

The first step in configuring VLANs is to create the VLAN:
Switch(config)# vlan 100
Switch(config-vlan)# name MY_VLAN
The first command creates VLAN 100, and places you in VLAN
configuration mode. The second command assigns the name MY_VLAN to
this VLAN.
The list of VLANs is stored in Flash in a database file named vlan.dat.
However, information concerning which ports are assigned to a specific
VLAN is not stored in this file; it is stored in the startup-config file instead.
Next, we must assign an interface (or range of interfaces) to this VLAN. The
following commands will assign interface fa0/10 into our newly created
MY_VLAN.
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 100
The first command places us in interface configuration mode. The second

command indicates that this is an access port, as opposed to a trunk port
(explained in detail shortly). The third command assigns this access port to
VLAN 100.
To view the list of VLANs, including which ports are assigned to each
VLAN:
Switch# show vlan
***
VLAN Port “Types”

There are two types of ports supported on a VLAN-enabled switch, access
ports and trunk ports.
An access port belongs to only one VLAN. Host devices, such as computers
and printers, plug into access ports. A host automatically becomes a member
of its access port’s VLAN. This is done transparently, and the host is usually
unaware of the VLAN infrastructure. By default, all switch ports are access
ports.
VLANs can span multiple switches. There are two methods of connecting
these VLANs together. The first requires creating “uplink” access ports
between all switches, for each VLAN. Obviously, in large switching and
VLAN environments, this quickly becomes unfeasible.
A better alternative is to use trunk ports. Trunk ports do not belong to a
single VLAN. Any or all VLANs can traverse trunk links to reach other
switches. Only Fast or Gigabit Ethernet ports can be used as trunk links.
The following diagram illustrates the advantage of using trunk ports, as
opposed to uplinking access ports:
VLAN A, B, C
VLAN C
VLAN A
VLAN B
VLAN A, B, C
VLAN C
VLAN A
VLAN B
***
VLAN Frame-Tagging
When utilizing trunk links, switches need a mechanism to identify which
VLAN a particular frame belongs to. Frame tagging places a VLAN ID in
each frame, identifying which VLAN the frame belongs to.
Tagging occurs only when a frame is sent out a trunk port. Consider the
following example:
If Computer 1 sends a frame to Computer 2, no frame tagging will occur.

The frame never leaves the Switch 1, stays within its own VLAN, and will
simply be switched to Computer 2.
If Computer 1 sends a frame to Computer 3, which is in a separate VLAN,
frame tagging will still not occur. Again, the frame never leaves the switch,
but because Computer 3 is in a different VLAN, the frame must be routed.
If Computer 1 sends a frame to Computer 5, the frame must be tagged
before it is sent out the trunk port. It is stamped with its VLAN ID (in this
case, VLAN A), and when Switch 2 receives the frame, it will only forward
it out ports belonging to VLAN A (fa0/0, and fa0/1). If Switch 2 has
Computer 5’s MAC address in its CAM table, it will only send it out the
appropriate port (fa0/0).
Cisco switches support two frame-tagging protocols, Inter-Switch Link
(ISL) and IEEE 802.1Q.
***
Inter-Switch Link (ISL)

ISL is Cisco’s proprietary frame-tagging protocol, and supports Ethernet,
Token Ring, FDDI, and ATM frames.
ISL encapsulates a frame with an additional header (26 bytes) and trailer (4
bytes), increasing the size of an Ethernet frame up to 30 bytes. The header
contains the 10 byte VLAN ID.
Because ISL increases the size of a frame, non-ISL devices (i.e. non-Cisco
devices) will actually drop ISL-tagged frames. Many devices are configured
with a maximum acceptable size for Ethernet frames (usually 1514 or 1518
bytes). ISL frames can be as large as 1544 bytes, and thus are considered to
be “giants” or corrupt.
ISL has deprecated in use over time. Newer Catalyst models may not
support ISL tagging.
IEEE 802.1Q
IEEE 802.1Q, otherwise known as DOT1Q, is the standardized frame-
tagging protocol supported by most switch manufacturers, including Cisco.
Thus, switches from multiple vendors can be “trunked” together.
Instead of adding an additional header and trailer, 802.1Q actually embeds a
4-byte VLAN ID into the Layer 2 frame header. This still increases the size
of a frame from its usual 1514 bytes to 1518 bytes, but most modern VLAN-
enabled switches support 802.1Q and the slight increase in size.
Manual vs. Dynamic Trunking

ISL or 802.1Q tagging can either be manually configured on Catalyst trunk
ports, or dynamically decided using Cisco’s proprietary Dynamic Trunking
Protocol (DTP).
***
Configuring Trunk Links

To manually configure a trunk port, either for ISL or 802.1Q tagging:
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk encapsulation isl
Switch(config-if)# switchport trunk encapsulation dot1q
The first line in each set of commands places you in interface configuration
mode. The second line manually sets this switchport as a trunk port. The
third line manually sets the tagging protocol the trunk link will use. Always
remember, both sides of the trunk line must be configured with the same
tagging protocol.
The Catalyst switch can negotiate the tagging protocol:
Switch(config-if)# switchport trunk encapsulation negotiate
Whichever tagging protocol is supported on both switches will be used. If

both switches support both ISL and 802.1Q, ISL will be selected (no
surprise).
By default, trunk ports allow all 4,094 VLANs to traverse the trunk link.
However, a list of “allowed” VLANs can be configured on each trunk port:
Switch(config-if)# switchport trunk allowed vlan add 2-50
Switch(config-if)# switchport trunk allowed vlan remove 50-100
Switch(config-if)# switchport trunk allowed vlan all
Switch(config-if)# switchport trunk allowed vlan except 2-100
Certain VLANs are reserved and cannot be removed from a trunk link,
including VLAN 1 and VLANs 1002-1005.
***
Native VLANs
A native VLAN can also be configured on trunk ports:
Switch(config-if)# switchport trunk native vlan 100
Native VLANs are usually configured when plugging Cisco Voice over IP
(VoIP) phones into a Catalyst Switch (which is beyond the scope of this
section). Only 802.1Q supports Native VLANs, ISL does not.
Native VLANs are also useful if a trunk port fails. For example, if an end
user connects a computer into a trunk port, the trunking status will fail and
the interface will essentially become an access port. The user’s computer
will then be “joined” to the Native VLAN.
Native VLANs provide another benefit. A trunk port will accept “untagged”
frames and place them in the Native VLAN. Consider the following
example:
Assume that both 802.1Q switches have trunk links configured to the non-
802.1Q switch, and that the trunk ports are configured in Native VLAN 100.
Not only will the 802.1Q switches be able to communicate with each other,
the non-802.1Q switch will be “placed” in Native VLAN 100, and be able to
communicate with any device in VLAN 100 on any switch.
(Please note, that the author of this study guide finds the “benefit” of the
above example of Native VLANs to be……dubious at best, and confusing
as hell at worst. Native VLANs find their true purpose when a Cisco VoIP
phone is plugged into a trunk link, or when a trunk link fails).
By default, the Native VLAN is VLAN 1.
***
Dynamic Trunking Protocol (DTP) Configuration

Not only can the frame tagging protocol of a trunk port be auto-negotiated,
but whether a port actually becomes a trunk can be negotiated dynamically
as well using the Dynamic Trunking Protocol (DTP).
To manually set a port to be a trunk:
To allow a port to “dynamically” decide whether to become a trunk, there

are two options:
Switch(config-if)# switchport mode dynamic desirable
Switch(config-if)# switchport mode dynamic auto
If both ports are manually set to trunk¸ a trunk link will be created.
If one port is set to dynamic desirable, and the other port is set to manual
trunk, dynamic desirable, or dynamic auto, a trunk link will be created.
If one port is set to dynamic auto, and the other port is set to manual trunk
or dynamic desirable, a trunk link will be created.
If both ports are set to dynamic auto, the link will never become a trunk,
because both ports are waiting for the other to “initialize” the trunk.
Trunk ports send out DTP frames every 30 seconds to indicate their
configured “mode.”
In general, it is best to manually specific the trunk link, and disable DTP
using the switchport nonegotiate command:

Switch(config-if)# switchport nonegotiate
***
Troubleshooting Trunks
When troubleshooting a misbehaving trunk link, ensure that the following is
configured identically on both sides of the trunk:
• Mode (both sides must be set to “trunk” or dynamically negotiated)
• Frame-tagging protocol (ISL, 802.1Q, or dynamically negotiated)
• Native VLAN
• VTP Domain
• Allowed VLANs
If the above parameters are not set identically on both sides, the trunk link
will never become active.
Troubleshooting Commands
To show a list of all active VLANs:
Switch# show vlan
To view only VLAN 3:

Switch# show vlan id 3
To view whether a port is an access or trunk port (such as fa0/5):

Switch# show interface fa0/5 switchport
To view the status of a trunking port (such as fa0/10):

Switch# show interface fa0/10 trunk
To view information on DTP:

Switch# show dtp
***
VLAN Trunking Protocol (VTP)

In large switching environments, it can become difficult to maintain a
consistent VLAN database across all switches on the network. VLAN
Trunking Protocol (VTP) allows the VLAN database to be easily managed
throughout the network.
Switches configured with VTP are joined to a VTP domain. Only switches
belonging to the same domain will share VLAN information, and a switch
can only belong to a single domain. When an update is made to the VLAN
database, this information is propagated to all switches via VTP
advertisements.
By default, VTP updates are sent out every 300 seconds, or anytime a
change to the database occurs. VTP updates are sent across VLAN 1, and
are only sent out trunk ports.
VTP “Modes”
VTP-enabled switches can operate in one of three modes:
Server – Only VTP servers can create, modify or delete entries in the
VLAN database. Servers advertise their VLAN database to all other
switches on the network. This is the default mode for Cisco Catalyst
switches. Servers can only advertise VLANs 1 - 1005.
Client – VTP clients cannot make modifications to the VLAN database, and
will receive all of their VLAN information from VTP servers. A client will
also forward an update from a server to other clients.
Transparent – VTP transparent switches will not advertise or accept any
VLAN database information from other switches (even a server). Changes
can be made only to the transparent switch’s local VLAN database.
However, transparent VTP switches will forward VTP information from
servers to clients, and thus acts as a “pass-through.”
Note: if you are installing a new switch, make sure that you configure it as a
VTP client before plugging it into the network. By default, a Cisco Catalyst
switch will be in server mode, and will advertise a blank VLAN database
to all other switches. Configuring it as a client, or lowering its VTP revision
number to 1, first allows it to “learn” the current VLAN database.
***
Configuring VTP
To configure a switch’s VTP domain:
Switch(config)# vtp domain MYDOMAIN
To configure a switch’s VTP “mode”:

Switch(config)# vtp mode server
Switch(config)# vtp mode client
Switch(config)# vtp mode transparent
To prevent a malicious user from using a VTP server to delete all VLAN
information, the VTP domain can be password protected:
Switch(config)# vtp password PASSWORD
All switches participating in the VTP domain must be configured with the
same password.
There are two versions of VTP. VTP version 2 supports additional
functionality, including error checking and support for Token Ring. VTP
version 2 also allows transparent switches to always forward update
information from servers to clients, even if the transparent switch is in a
separate domain. By default, a Catalyst switch uses VTP version 1. To
configure the VTP version:
Switch(config)# vtp version 2
To view status information about VTP, including version, domain and mode:
Switch# show vtp status
Message and error counters can also be viewed:

Switch# show vtp counters
***
VTP Pruning
VTP pruning is a process of preventing unnecessary VLAN broadcast or
multicast traffic.
In the following example, VTP pruning would prevent VLAN “C”
broadcasts from being sent to Switch 2. Pruning would further prevent
VLAN “A” and “B” broadcasts from being sent to Switch 3.
With VTP pruning, traffic is only sent out the necessary VLAN trunk ports
where those VLANs exist.
VTP pruning is disabled by default on Catalyst IOS switches. To enable
VTP pruning:
Switch(config)# vtp pruning
On trunk ports, it is possible to specify which VLANs are pruning eligible:

Switch(config-if)# switchport trunk pruning vlan add 2-50
Switch(config-if)# switchport trunk pruning vlan remove 50-100

Switch(config-if)# switchport trunk pruning vlan all
Switch(config-if)# switchport trunk pruning vlan except 2-100
***
Section 8
- EtherChannel -
Port Aggregation
When a switched network spans multiple switches, some method of
“linking” those switches must be used. A single Fast Ethernet or Gigabit
Ethernet port can be used to uplink between switches, but this introduces a
bottleneck to the flow of traffic. For example, when using a 24-port Catalyst
switch, imagine having to pipe the traffic of 23 ports over a single port to
reach another switch!
Unfortunately, we cannot simply connect two or more ports from one switch
to another switch, as this introduces a switching loop to the network. The
result would be an almost instantaneous broadcast storm.
Port Aggregation allows us to tie multiple ports together into a single
“logical” interface. Cisco’s implementation of port aggregation is called
EtherChannel. The switch treats an EtherChannel as a single interface, thus
eliminating the possibility of a switching loop.
Not only does port aggregation increase the bandwidth of a link, but it also
provides redundancy. If a single port fails, traffic will be redirected to the
other port(s).
A maximum of 8 Fast Ethernet or 8 Gigabit Ethernet ports can be “grouped”
together when forming an EtherChannel. Thus, when running in full duplex,
a Fast EtherChannel (FEC) has a maximum bandwidth of 1600 Mbps. A
Gigabit EtherChannel (GEC) has a maximum bandwidth of 16 Gbps.
A maximum of 64 EtherChannels can be configured on a single Catalyst
3550XL switch. A Catalyst 6500 switch supports up to 128 EtherChannels.
***
EtherChannel Requirements
EtherChannels can be formed with either access or trunk ports.
An EtherChannel comprised of access ports provides increased bandwidth
and redundancy to a host device, such as a server. The host device must
support a port aggregation protocol, such as LACP.
EtherChannels comprised of trunk ports provide increased bandwidth and
redundancy to other switches.
All interfaces in an EtherChannel must be configured identically. Specific
settings that must be identical include:
• Speed settings
• Duplex settings
• STP settings
• VLAN membership (for access ports)
• Native VLAN (for trunk ports)
• Allowed VLANs (for trunk ports)
• Trunking Encapsulation (ISL or 802.1Q, for trunk ports)
When configuring an EtherChannel “trunk” to another switch, the above
configuration should be identical on both switches.
EtherChannels will not form if either dynamic VLANs or port security are
enabled on the participating EtherChannel interfaces.
***
EtherChannel Load-Balancing
Data sent across an EtherChannel is not load-balanced equally between all
interfaces. EtherChannel utilizes a load-balancing algorithm, which can be
based on several forms of criteria, including:
• Source IP Address (src-ip)
• Destination IP Address (dst-ip)
• Both Source and Destination IP (src-dst-ip)
• Source MAC address (src-mac)
• Destination MAC address (dst-mac)
• Both Source and Destination MAC (src-dst-mac)
• Source TCP/UDP port number (src-port)
• Destination TCP/UDP port number (dst-port)
• Both Source and Destination port number (src-dst-port)
On a Catalyst 3550XL, the default load-balancing method for Layer 2
switching is src-mac. For Layer 3 switching, it’s src-dst-ip.
EtherChannel Load-Balancing Configuration

To configure what load-balancing method to utilize:
Switch(config)# port-channel load-balance TYPE
For example, to switch the load-balancing method to source TCP/UDP port

number:
Switch(config)# port-channel load-balance src-port
To view the currently configured load-balancing method, including the

current load on each link:
Switch# show etherchannel port-channel
***
EtherChannel Load-Balancing Example

Consider the following example, where ports fa0/10 and fa0/18 are
configured as a single EtherChannel on both switches:
Switch A
Fa0/10 Fa0/18
Fa0/10 Fa0/18
Switch B
Assume that the EtherChannel load-balancing method we are using is src-ip.

We can “represent” the two links in our EtherChannel in one bit. A bit can
either be off (“0”) or on (“1”). The first interface in our EtherChannel will
become Link 0; the second will become Link 1.
Consider the following source IP addresses and their binary equivalents:
10.1.1.1 – 00001010.00000001.00000001.00000001
10.1.1.2 – 00001010.00000001.00000001.00000010
Because we only have two channels in our link, we only need to look at one
bit in these source IP addresses – the last bit. The first address ends with a
“1” bit, and thus would be sent down Link 1. The second address ends with a
“0” bit, and thus would be sent down Link 0. Simple, right?
This method of load-balancing can lead to one link being overburdened, in
the odd circumstance that there are a disproportionate number of even or odd
addresses.
In general, EtherChannels should be formed with an even number of
interfaces, to provide the best chance for equal load-balancing. Four
interfaces can be represented with two bits; eight interfaces with three bits.
Odd numbers of interfaces CAN be used in EtherChannel. However, one of
the links will be severely overburdened compared to other links.
***
EtherChannel Load-Balancing Example (continued)

Consider again the following example:
Switch A
Fa0/10 Fa0/18
Fa0/10 Fa0/18
Switch B
This time, assume that the EtherChannel load-balancing method we are

using is src-dst-ip. The load-balancing algorithm will use both the source
and destination IP when choosing a link. Again, the first interface in our
EtherChannel will become Link 0; the second will become Link 1.
Consider the following source and destination IP addresses and their binary
equivalents:
192.168.1.10 – 11000000.10101000.00000001.00001010
192.168.1.25 – 11000000.10101000.00000001.00011001
The Catalyst switch performs an exclusive OR (XOR) to determine the
appropriate link. Again, looking at the last bit of each address:
Source 0 1 0 1
Destination 0 0 1 1
Result 0 1 1 0
Based on the XOR operation, the result can either be “off” (“0”) or “on”
(“1”). This determines the link the switch will use. In our above example of
source/destination IP address, the XOR operation would result in a “1”, and
thus we would use Link 1.
***
EtherChannel Protocols
EtherChannel can either be configured manually, or can be dynamically
negotiated via one of two protocols:
• PAgP (Port Aggregation Protocol) – Cisco’s proprietary
aggregating protocol.
• LACP (Link Aggregation Control Protocol) – The IEEE
standardized aggregation protocol, otherwise known as 802.3ad.
Both PAgP and LACP exchange packets between switches in order to form
the EtherChannel. However, when the EtherChannel is manually configured
(i.e., set to on), no update packets are exchanged.
Thus, an EtherChannel will not be formed if one switch has a manually
configured EtherChannel, and the other switch is configured with a dynamic
protocol (PAgP or LACP).
Furthermore, PAgP and/or LACP configuration must be removed from a
switch’s interfaces before a manual EtherChannel can be formed.
EtherChannel Manual Configuration

To manually “force” an EtherChannel on two ports:
Switch(config)# interface range fa0/10 - 11
Switch(config-if)# channel-group 1 mode on
The other switch must also have the EtherChannel manually configured as
on. Remember that speed, duplex, VLAN, and STP information must be the
same on every port in the EtherChannel.
The channel-group number identifies this particular EtherChannel. The
channel-group number does not need to be configured identically on both
switches. Remember, a maximum of 64 EtherChannels are allowed on a
Catalyst 3550XL switch.
***
EtherChannel PAgP Configuration

To configure PAgP negotiation on two ports, there are two options:
Switch(config)# interface range fa0/10 – 11
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group 1 mode desirable
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group 1 mode auto
Obviously, the other switch must also be configured with channel-protocol

pagp. The channel-group number identifies this particular EtherChannel
The PAgP channel-group “mode” can be configured to either desirable or
auto. A switch configured as desirable will actively request to form an
EtherChannel. When set to auto, the switch will passively wait for another
switch to make the request.
When set to desirable, the switch will form an EtherChannel with another
switch configured as either desirable or auto.
When set to auto, the switch will form an EtherChannel only with another
switch configured as desirable. If both switches are set to auto, no
EtherChannel will be formed.
Regardless if set to desirable or auto, a Catalyst switch configured with
PAgP will not form an EtherChannel with a switch that has a manually
configured EtherChannel.
Again, remember that speed, duplex, VLAN, and STP information must be
the same on every port in the EtherChannel.
***
EtherChannel LACP Configuration

To configure LACP negotiation on two ports, there are also two options:
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group 1 mode active
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group 1 mode passive
The other switch must also be configured with channel-protocol lacp.

The LACP channel-group “mode” can be configured to either active or
passive. A switch configured as active will actively request to form an
EtherChannel. When set to passive, the switch will passively wait for
another switch to make the request.
When set to active, the switch will form an EtherChannel with another
switch configured as either active or passive.
When set to passive, the switch will form an EtherChannel only with
another switch configured as active. If both switches are set to passive, no
EtherChannel will be formed.
LACP provides an additional configuration option, a numerical priority that
allows LACP to determine which ports can become active in the
EtherChannel. This priority can either be set globally:
Switch(config)# lacp system-priority PRIORITY
Or on interfaces:
Switch(config-if)# lacp port-priority PRIORITY
A low value indicates a high priority. The ports with the lowest values
(highest priorities) become active in the EtherChannel.
***
Troubleshooting EtherChannel
To view the current status of all configured EtherChannels:
Switch# show etherchannel summary
To view the current EtherChannel protocol and mode:

Switch# show etherchannel port-channel
***
Section 9
- Spanning-Tree Protocol -
Switching “Loops”
By default, a switch will forward a broadcast or multicast out all ports,
excluding the port the broadcast/multicast was sent from.
When a “loop” is introduced into the network, a highly destructive
broadcast storm can develop within seconds. Broadcast storms occur when
broadcasts are endlessly switched through the loop, choking off all other
traffic.
Consider the following “looped” environment:
Switch 1
Switch 2 Switch 3
Switch 4 Switch 5
If the computer connected to Switch 4 sends out a broadcast, the switch will
forward the broadcast out all ports, including the ports connecting to Switch
2 and Switch 5. Those switches, likewise, will forward that broadcast out all
ports, including to their neighboring switches.
The broadcast will loop around the switches infinitely. Only powering off
the switch or removing all cabling can stop the storm.
***
Spanning Tree Protocol (STP)

Switches (and bridges) needed a mechanism to prevent loops from forming,
and thus Spanning Tree Protocol (STP, or IEEE 802.1D) was developed.
STP is enabled by default on all VLANs on Catalyst switches.
STP-enabled switches communicate to form a topology of the entire
switching network, and then shutting down (or “blocking”) a port if a loop
exists. The “blocked” port can be reactivated if another link on the switching
network goes down, thus preserving fault-tolerance. Once all switches agree
on the topology database, the switches are considered “converged.”
STP switches send BPDU’s (Bridge Protocol Data Units) to each other to
form their topology databases. Switches also send a specific Topology
Change (TCN) BPDU out all root ports if a change occurs in the topology.
BPDU’s are sent out all ports every two seconds, are forwarded to a specific
MAC multicast address: 0180.c200.0000.
STP “Types”
Various flavors of STP exist, including:
• Common Spanning Tree (CST) – A single STP process is used for
all VLANs
• Per-VLAN Spanning Tree (PVST) – Cisco proprietary version of
STP, that uses a separate STP process for each VLAN
• Per-VLAN Spanning Tree Plus (PVST+) – Enhanced version of
PVST that allows CST-enabled switches and PVST-enabled switches
to interoperate. This is default on newer Catalyst switches.
The STP “Process”

To maintain a loop-free environment, STP performs the following functions:
• A Root Bridge is elected
• Root Ports are identified
• Designated Ports are identified
• If a loop exists, a port is placed in Blocking state. If the loop is
removed the blocked port is activated again.
***
Electing an STP Root Bridge

The first step in the STP process is electing a Root Bridge, which serves as
the centralized “point” of the STP topology. Good design practice dictates
that the Root Bridge be placed closest to the center of the STP topology.
The Root Bridge is determined by a switch’s priority. The default priority is
32,768, and the lowest priority wins. In case of a tie in priority, the switch
with the lowest MAC address will be elected root bridge. The combination
of a switch’s priority and MAC address make up that switch’s Bridge ID.
Remember that the lowest priority determines the Root Bridge. Switches 2,
3, and 5 have the default priority set. Switches 1 and 4 each have a priority
of 100 configured. However, Switch 1 will become the root bridge, as it has
the lowest MAC address.
Switches exchange BPDU’s to perform the election process. By default, all
switches “believe” they are the Root Bridge, until a switch with a lower
Bridge ID is discovered.
Root Bridge elections are a continuous process. If a new switch with a lower
Bridge ID is added to the topology, it will be elected as the new Root
Bridge.
***
Identifying Root Ports

The second step in the STP process is identifying Root Ports, or the ports on
all switches that have the lowest path cost to get to the Root Switch. Each
switch has only one Root Port.
Path Cost is a cumulative cost based on the bandwidth of the links. The
higher the bandwidth, the lower the Path Cost:
Bandwidth Cost
4 Mbps 250
10 Mbps 100
16 Mbps 62
100 Mbps 19
1 Gbps 4
Assume the links between all switches are 10Mbps Ethernet, with a Path
Cost of 100. Each switch will identify the port with the least cumulative Path
Cost to get to the Root Bridge.
For Switch 4, the port leading “up” to Switch 2 has a Path Cost of 200, and
becomes the Root Port. The port to Switch 5 has a higher Path Cost of 300.
***
Identifying Designated Ports

The third and final step in the STP process is to identify Designated Ports,
or all non-Root Ports that have the lowest Path Cost. Each “segment”
requires a single Designated Port leading to the Root Bridge.
Ports on the Root Bridge are never placed in a blocking state, and thus are
always Designated Ports.
The segments between Switches 2 and 4, and between Switches 3 and 5,
already contained a Root Port. Each segment requires a Designated Port, and
thus the ports on Switch 2 and Switch 3 become Designated Ports.
The segment between Switch 4 and Switch 5 does not contain a Root Port. A
segment can only have one Designated Port, and thus one of the ports must
be placed in a blocking state.
Normally, Path Cost is used to determine which port is blocked. However,
the ports connecting Switches 4 and 5 have the same Path Cost to reach the
Root Bridge (300). Whichever switch has the lowest Bridge ID is awarded
the Designated Port. Whichever switch has the highest Bridge ID has its
port placed in a blocking state. In this example, Switch 4 has the lowest
priority, and thus Switch 5’s port goes into a blocking state.
***
Port ID
In certain circumstances, there will be a tie in both Path Cost and Bridge ID.
Switch 1
Root Bridge
Fa0/10 Fa0/11
Switch 2
If the bandwidth of both links are equal, then both of Switch 2’s interfaces
have an equal path cost to the Root Bridge. Which interface will become the
Root Port? The next “tiebreaker” should be the lowest Bridge ID, but that
obviously cannot be used in this circumstance (unless Switch 2 is
experiencing a schizophrenic identity crisis ☺).
Instead, Port ID will be used as the tiebreaker. An interface’s Port ID
consists of two “parts,” a 6 bit port priority value plus the MAC address for
that port. Whichever interface has the lowest Port ID will become the Root
Port.
By default, the port priority of an interface is 128. By lowering this value,
we can ensure a specific interface becomes the Root Port:
Switch(config)# int fa0/10

Switch(config-if)# spanning-tree port-priority 50
Remember, that port priority is the last tiebreaker STP will consider. STP
decides Root and Designated Ports based on the following criteria, and in
this order:
• Lowest Path Cost to the Root Bridge
• Lowest Bridge ID
• Lowest Port ID
***
Extended System IDs

Normally, a switch’s Bridge ID is a 64-bit value that consists of a 16-bit
Bridge Priority value, and a 48-bit MAC address.
However, it is possible to include a VLAN ID, called an extended System
ID, into a Bridge ID. Instead of adding bits to the existing Bridge ID, 12 bits
of the Bridge Priority value are used for this System ID, which identifies the
VLAN this STP process represents.
Because we have stolen 12 bits from our Bridge Priority field, we have
reduced the “range” of priorities we can use. Normally, our Bridge Priority
can range from 0 (or “off”) to 65,535, with a default of 32,768. With
extended System ID enabled, our range would be 4,096 – 65,535.
To enable the extended System ID:
Switch(config)# spanning-tree extend system-id
This accomplishes two things:

• First, it increases the amount of supported VLANs on the switch from
1005 to 4094.
• It includes the VLAN ID as part of the Bridge ID.
Thus, when this command is enabled, our 64-bit Bridge ID will consist of:
• 4-bit Priority Value
• 12-bit System ID value (VLAN ID)
• 48-bit MAC address
***
Per-VLAN Spanning Tree (PVST) Example

Remember that PVST+ is the default implementation of STP on Catalyst
switches. Thus, each VLAN on the switch is allotted its own STP process.
Switch 1
Switch 2 Switch 3
Switch 4
With Common Spanning Tree (CST), all VLANS would belong to the same
STP process. Thus, if one Switch 4’s ports entered a “blocking” state to
eliminate the loop, all VLANs would be blocked out that port. For efficiency
purposes, this may not be ideal.
In the above examples, the benefit of PVST becomes apparent. STP runs a
separate process for each VLAN, allowing a port to enter a blocking state
only for that specific VLAN. Thus, it is possible to “load balance” VLANs,
to allow traffic to flow more efficiently.
***
STP Port States

Switch Ports participating in STP can be in one of five “port states”:
Blocking – Default state of an STP port when a switch is powered on, and
when a port is shut down to eliminate a loop. Ports in a “blocking” state do
not forward frames or learn MAC addresses. It will still listen for BPDUs
from other switches, to learn about topology changes to the switching
network.
Listening – A port will progress from Blocking to Listening only if the port
is NOT being shut down to eliminate a loop. The port will listen for BPDU’s
to participate in the election of a Root Bridge, Root Ports, and Designated
Ports. Ports in a “listening” state still do not forward frames or learn MAC
addresses.
Learning – After a brief period of time, called a Forward Delay, a port in a
“listening” state will be elected either a Root Port or Designated Port, and
placed in a “learning” state. Ports in a “learning” state listen for BPDUs, and
also begin to learn MAC addresses. However, “learning” ports still do not
forward frames
Forwarding – After another Forward Delay, a port in “learning” mode will
be placed in “forwarding” mode. Ports in a forwarding state can send and
receive all data frames, and continue to build its MAC address table. All
designated, root, and non-uplink ports will eventually enter a “forwarding”
state.
Disabled – A port in “disabled” state has been administratively shut down,
and does not participate in STP or forward frames at all.
On average, a port in a “blocking” state will take 30 to 50 seconds to reach a
“forwarding” state.
To view the current “state” of a port (such fa0/0):
Switch# show spanning-tree interface fa0/0
***
STP Timers
STP utilizes three timers to ensure all switches remain synchronized, and to
allow enough time for the Spanning Tree process to ensure a loop-free
environment.
Hello Timer – Default is 2 seconds. Indicates how often BPDU’s are sent
by switches.
Forward Delay – Default is 15 seconds. Indicates a “delay” period in both
the “listening” and “learning” states of a port, for a total of 30 seconds. This
delay ensures STP has ample time to detect and eliminate loops.
Max Age – Default is 20 seconds. If a switch fails to receive BPDU’s from
a neighboring switch for the Max Age period, it will remove that switch’s
information from the STP topology database.
All timer values can be adjusted, and should only be adjusted on the Root
Bridge. The Root Bridge will propagate the changed settings to all other
switches participating in STP.
When a change to the network topology occurs, switches send out TCN
(Topology Change) BPDUs. When a switch receives a TCN BPDU, it will
temporarily change its MAC address Aging Timer from 300 seconds to 15
seconds, so that any erroneous MAC addresses can be flushed out of the
CAM.
To adjust the three STP timers for VLAN 10:
Switch(config)# spanning-tree vlan 10 hello-time 10
Switch(config)# spanning-tree vlan 10 forward-time 20
Switch(config)# spanning-tree vlan 10 max-age 40
The timers are measured in seconds. The above examples represent the
maximum value each timer can be configured to.
Remember that STP is configured on a VLAN by VLAN basis on Catalyst
Switches.
***
Basic STP Configuration

To disable STP for a specific VLAN:
Switch(config)# no spanning-tree vlan 10
To adjust the Bridge Priority of a switch from its default of 32,768, to

increase its chances of being elected Root Bridge of a VLAN:
Switch(config)# spanning-tree vlan 10 priority 150
To change a port’s Path Cost from its defaults:

Switch(config-if)# spanning-tree cost COST
To force a switch to become the Root Bridge:

Switch(config)# spanning-tree vlan 10 root primary diameter 7
The root primary parameter in the above command automatically lowers the
switch’s priority to 24,768. If another switch on the network has a lower
priority than 24,768, the above command will lower the Priority by 4096
less than that switch.
We can have a Secondary Root Bridge for redundancy. To force a switch
to become a Secondary Root Bridge:
Switch(config)# spanning-tree vlan 10 root secondary diameter 7
The diameter parameter in the preceding commands indicates the number of

switches traffic will be sent across, with 7 being the maximum value we can
apply to a diameter. This does not mean our switching network can only
have seven switches; instead, it indicates our switching network can only
extend seven switches (or levels) “deep.”
The above root commands also adjust the Hello, Forward Delay, and Max
Age timers. This is the recommended way to adjust timers, instead of
manually altering each, as the hello timers are tuned specifically to the
diameter of the switching network.
***
STP PortFast
PortFast allows switch ports that connect a host device (such as a PC), to
bypass the normal progression of STP “states.” Because no possibility of a
loop exists on a port connecting a host device, the port can move from a
“blocking” state to a “forwarding” state immediately, eliminating the
normal 30 to 50 second delay.
To configure PortFast on an interface:
Switch(config-if)# spanning-tree portfast
PortFast should not be enabled on switch ports connecting to another

hub/switch, as it may result in a loop. PortFast does not disable STP on a
port, it merely speeds up the convergence.
STP UplinkFast
Switches can have multiple uplinks to other “upstream” switches. If the
multiple links are not placed in an EtherChannel, then at least one of the
ports is placed into a “blocking” state to eliminate the loop.
If a directly-connected interface goes down, STP needs to perform a
recalculation to bring the other interface out of a “blocking” state. As stated
earlier, this calculation can take from 30 to 50 seconds.
UplinkFast allows the port in a “blocking” state to be held in standby-mode,
and activated immediately if the “forwarding” interface fails. If multiple
ports are in a “blocking” state, whichever port has the lowest Root Path Cost
will become unblocked.
UplinkFast is configured globally for all VLANs on the switch:
Switch(config)# spanning-tree uplinkfast
The Root Bridge cannot have UplinkFast enabled, as the “standby” ports are
calculated using the best Path Cost to the Root Bridge.
***
STP BackboneFast
While UplinkFast allows faster convergence if a directly connected interface
fails, BackboneFast provides the same benefit is an indirectly connected
interface fails.
For example, if the Root Bridge fails, another switch will be elected the
Root. A switch learning about the new Root Bridge must wait its Max Age
timer to flush out the old information, before it will accept the updated info.
By default, the Max Age timer is 20 seconds.
BackboneFast allows a switch to bypass the Max Age timer if it detects an
indirect failure on the network. It will update itself with the new Root info
immediately.
BackboneFast is configured globally, and should be implemented on all
switches in the network when used:
Switch(config)# spanning-tree backbonefast
STP Troubleshooting Commands

To view STP parameters for all VLANS:
Switch# show spanning-tree
To view STP parameters for a specific VLAN:

Switch# show spanning-tree vlan 10
To view Root information, including Bridge ID and Path Costs:

Switch# show spanning-tree root
To view ports participating in STP, and their current states:

Switch# show spanning-tree brief
Switch# show spanning-tree summary
***
Protecting STP
STP is vulnerable to attack for two reasons:
• STP builds its topology information by accepting a neighboring
switch’s BPDU’s
• The Root Bridge is always determined by the lowest Bridge ID
(Priority + MAC address)
Switches with a low priority can be maliciously placed on the network, and
elected the Root Bridge. This can lead to a highly undesirable topology
design.
Two mechanisms exist to protect the STP topology, Root Guard and BPDU
Guard. Both mechanisms are configured on an individual port basis, and are
disabled by default.
Root Guard prevents an unauthorized switch from advertising itself as a
Root Bridge.
Switch(config-if)# spanning-tree guard root
The above command prevents this switch from accepting a “new” Root
Bridge off of this interface. If a Root Bridge advertises itself to this port, the
port will enter a root-inconsistent state, and will enter a pseudo “blocking”
state.
BPDU Guard is used on interfaces that also have PortFast enabled.
Normally, a PortFast-enabled interface is connecting a host device, such as a
computer or printer, and should never receive BPDU’s.
If another switch is accidentally or maliciously plugged into a PortFast
interface, BPDU Guard will place the interface into an errdisable state
(explained in an earlier section). More accurately, if an interface configured
for BPDU Guard receives a BPDU, then the errdisable state will occur.
Switch(config-if)# spanning-tree bpduguard enable
***
Unidirectional Link Detection (UDLD)

Most communication in a switching network is bi-directional. STP requires
that switches send BPDU’s bi-directionally to build the topology database. If
a malfunctioning switch port only allows traffic one way, and the switch still
sees that port as “up,” a loop can form without the switch realizing it.
Unidirectional Link Detection (UDLD) periodically tests ports to ensure
bi-directional communication is maintained. UDLD sends out “ID” frames
on a port, and waits for the remote switch to respond with its own ID frame.
If the remote switch does not respond, UDLD assumes the interface has
malfunctioned and become unidirectional.
By default, UDLD sends out ID frames every 15 seconds, and must be
enabled on both sides of a link. UDLD can run in two modes:
• Normal Mode – If a unidirectional link is detected, the port is not
shut down, but merely flagged as being in an undetermined state
• Aggressive Mode – If a unidirectional link is detected, the port is
placed in an errdisable state
UDLD can be enabled globally (but only for Fiber ports on the switch):
Switch(config)# udld enable message time 20
Switch(config)# udld aggressive message time 20
The enable parameter sets UDLD into normal mode, and the aggressive
parameter is for aggressive mode (obviously). The message time parameter
modifies how often ID frames are sent out.
UDLD can be configured on individual interfaces:
Switch(config-if)# udld enable
Switch(config-if)# udld aggressive
Switch(config-if)# udld disable
To view UDLD status on ports, or re-enable UDLD errdisabled ports:

Switch# show udld
Switch# udld reset
***
Rapid Spanning Tree Protocol (RSTP)

To further alleviate the 30 to 50 second convergence delays with STP,
enhancements were made to the original IEEE 802.1D standard. The result
was 802.1w, or Rapid Spanning Tree Protocol (RSTP).
RSTP is similar in many respects to STP. A Root Bridge is elected, based on
the lowest Bridge ID. Root Ports and Designated Ports are also determined.
RSTP defines five port “types”:
• Root Ports – Switch port on each switch that has the best Path Cost to
the Root Bridge (same as STP).
• Alternate Ports – A “backup” Root Port, that has a less desirable
Path Cost.
• Designated Ports – All non-Root ports that represent the best Path
Cost for each network segment (same as STP). Designated ports are
also called Point-to-Point ports, as they connect switches together
• Backup Port – A “backup” Designated Port, that has a less desirable
Path Cost
• Edge Port – A port connecting a host device. Any port configured
with PortFast becomes an Edge Port.
RSTP also uses BPDU’s, and is backwards-compatible with STP. However,
when RSTP switches interact with STP switches, RSTP must play by STP’s
rules, and thus loses its advantages.
RSTP’s main benefit is speedier convergence. Switches no longer require
artificial timers to ensure a loop-free environment, but instead perform a
handshake synchronization to ensure a consistent topology table throughout
the network. One switch “handshakes” with another, and once they both
agree on the topology, they “handshake” with their neighbors.
The result is convergence that completes in a few seconds, as opposed to 30
to 50 seconds.
***
Implementations of RSTP
Two separate standards of RSTP (over multiple VLANS) have been
developed:
• Rapid Per-VLAN Spanning Tree Protocol (RPVST+) – Cisco’s
proprietary implementation (no surprise)
• Multiple Spanning Tree (MST) – The IEEE 802.1s standard
Multiple Spanning Tree (MST)

Earlier in this section, we discussed two types of STP:
• Common Spanning Tree (CST) – All VLANs utilize one STP
process
• Per-VLAN Spanning Tree (PVST) – Each VLAN is allotted its own
STP process
PVST allows for more efficient traffic flow throughout the switching
network. However, because each VLAN must run its own separate STP
process, the burden on the switch’s processor can be extreme.
Multiple Spanning Tree (MST) allows “groups” of VLANs to be allotted
their own STP process. Each STP process is called an instance. MST
separates the STP topology into regions that must contain identical
parameters, including:
• Configuration Name (similar to a VTP domain)
• Revision Number
• VLAN to Instance Mappings
Each region runs its own Internal Spanning Tree (IST) to eliminate loops
within that region.
MST is fully compatible with all other implementations of STP.
***
MST Configuration
MST must first be enabled on a switch:
Switch(config)# spanning-tree mode mst
Most other MST configuration is completed in “MST Configuration” mode:

Switch(config)# spanning-tree mst configuration
To configure the switch’s MST Configuration Name:

Switch(config-mst)# name NAME
To configure the switch’s Revision Number (must be the same on all

switches):
Switch(config-mst)# revision VERSION
To map VLANs to a specific MST instance:

Switch(config-mst)# instance 1 vlan 1-100
A maximum of 16 instances are allowed (0 – 15). By default, all VLANs

belong to instance 0.
To view the changes to the configuration:
Switch(config-mst)# show pending
All other configuration of MST is identical to standard STP, with two

exceptions. The parameter “mst” must be used, and all settings are applied
to instances instead of VLANs.
Switch(config)# spanning-tree mst hello-time 10

Switch(config)# spanning-tree mst forward-time 15
Switch(config)# spanning-tree mst max-age 19
Switch(config)# spanning-tree mst 1 root primary
Switch(config)# spanning-tree mst 1 priority 32000
***
Section 10
- MultiLayer Switching -
Routing Between VLANs
VLANs separate a Layer 2 switch into multiple broadcast domains. Each
VLAN is its own individual broadcast domain (i.e. IP subnet). Only ports
belonging to the same VLAN can freely communicate; ports assigned to
separate VLANS require a router to communicate.
Routing between VLANs can be accomplished one of three ways:
• Using an external router that has a link to each VLAN:
• Using an external router that has a single link into the switch, over
which all VLANs can be routed. The router must understand either
802.1Q or ISL trunking encapsulations, and the switch port must be
configured as a trunk. This method is known as router on a stick:
• Using a Multilayer switch with a built-in routing processor:
***
Configuring Router on a Stick
Consider the above example. To allow the router to “route” between

VLANs, we must configure three things:
• Interface fa0/10 on the switch must be configured as a trunk port
• Interfaces fa0/14 and fa0/15 must be assigned to their respective
VLANs
• Interface fa0/1 on the router must be split into separate subinterfaces
for each VLAN. These subinterfaces must support the frame-tagging
protocol used by the switch’s trunk port.
Configuration on the switch would be as follows:
Switch(config)# interface fa0/10 Switch(config)# interface fa0/14
Switch(config-if)# switchport mode trunk Switch(config-if)# switchport access vlan 101
Switch(config-if)# switchport trunk encapsulation dot1q Switch(config)# interface fa0/15
Switch(config-if)# switchport access vlan 102
Configuration on the router would be as follows:

Router(config)# interface fa0/1
Router(config-if)# no shut Router(config)# interface fa0/1.102
Router(config-subif)# encapsulation dot1q 102
Router(config)# interface fa0/1.101 Router(config-subif)# ip address 10.1.1.1 255.255.0.0
Router(config-subif)# encapsulation dot1q 101
Router(config-subif)# ip address 172.16.1.1 255.255.0.0
We then point devices in each VLAN to their specific subinterface on the

router. For example, Computer A’s default gateway would be 172.16.1.1,
and Computer B’s would be 10.1.1.1.
Thus, the router can perform all inter-VLAN communication for the switch.
***
Multilayer Switch Port “Types”

Multilayer switches support both Layer 2 (switching) and Layer 3 (routing)
functions. Thus, three port “types” can exist on Multilayer switches:
• Switchports – Layer 2 ports on which MAC addresses are learned
• Layer 3 Ports – Essentially “routing” ports on multi-layer switches
• Switched Virtual Interfaces (SVI) – A VLAN virtual “interface”
where an IP address can be assigned to the entire VLAN
A port’s “type” can be changed. By default, on Catalyst 2950’s and 3550’s,
all ports are switchports.
To configure a port as a switchport:
Switch(config-if)# switchport
To configure a port as a Layer 3 (routing) port, and assign an IP address:

Switch(config-if)# no switchport
To assign an IP address to an SVI (virtual VLAN interface):

To view the port “type” of a particular port (fa0/10):

Switch# show int fa0/10 switchport
***
MultiLayer Switching Methods

An earlier section discussed how basic multilayer switching works.
Multilayer switches contain both a switching and routing engine. A packet
must first be “routed,” allowing the switching engine to cache the IP traffic
flow. After this cache is created, subsequent packets destined for that flow
can be “switched” as opposed to “routed,” reducing latency.
This concept is often referred to as route once, switch many. Cisco refers to
this type of Multilayer switching as NetFlow switching or route cache
switching.
As is their habit, Cisco replaced NetFlow multilayer switching with a more
advanced method called Cisco Express Forwarding (CEF). CEF is
enabled by default on all Catalyst multi-layer switches (at least, those that
support CEF). CEF cannot even be disabled on the Catalyst 3550, 4500 and
6500.
CEF contains two basic components:
• Layer 3 Engine – Builds the routing table and then “routes” data
• Layer 3 Forwarding Engine – “Switches” data based on the FIB.
The Layer 3 Engine builds its routing table using either static routes, or
routes dynamically learned through a routing protocol (such as RIP or
OSPF).
The routing table is then reorganized into a more efficient table called the
Forward Information Base (FIB). The most specific routes are placed at
the top of the FIB. The Layer 3 Forwarding Engine utilizes the FIB to then
“switch” data in hardware, as opposed to “routing” it through the Layer 3
Engine’s routing table.
The FIB contains the following information:
• Destination networks
• Destination masks
• Next-hop addresses
• The MAC addresses of each next hop (called the Adjacency Table)
To view the CEF FIB table:

Switch# show ip cef
***
Multilayer Switching vs. Router on a Stick

Earlier in this section, we learned how to configure “router on a stick” to
route between VLANs. Unfortunately, there are some disadvantages to
router on a stick:
• There may be insufficient bandwidth for each VLAN, as all routed
traffic will need to share the same router interface
• There will be an increased load on the router processor, to support the
ISL or DOT1Q encapsulation taking place
A more efficient (though usually more expensive) alternative is to use a
multilayer switch.
Configuration is simple. First, we must create the VLANs we want:

Switch(config-vlan)# name VLAN101
Switch(config-vlan)# name VLAN102
Then we must globally enable routing on our multilayer switch:

Switch(config)# ip routing
Next, we must assign an IP address to each VLAN:


These IP addresses will serve as the default gateways for the clients on each
VLAN. By adding an IP address to a VLAN, those networks will be added
to the routing table, allowing routing to occur.
***
Fallback Bridging
The Catalyst 3550 only supports IP when using CEF multilayer switching. If
other protocols (IPX, Appletalk, SNA) need to be “routed” between VLANs,
fallback bridging can be used.
To configure fallback bridging, a bridge group must first be created. Then
specific VLANs can be assigned to that bridge group. A maximum of 31
bridge groups can be created.
Switch(config)# bridge-group 1 protocol vlan-bridge
Switch(config-if)# bridge-group 1
Switch(config-if)# bridge-group 1
The first command creates the bridge group. The next command place
VLANs 100 and 101 in bridge group 1. If protocols other than IP utilize
these VLANs, they will be transparently bridged across the VLANs.
To view information about all configured bridge groups:

Switch# show bridge group
***
Section 11
- SPAN -
Monitoring Traffic
Various technologies and packet sniffers exist to monitor traffic on a
network. Catalyst switches support a feature called Switched Port Analyzer
(SPAN) to simplify this process.
SPAN works by copying or mirroring the traffic from one or more source
ports, to a destination port. Because the traffic is only copied, SPAN will
never affect any of the traffic on the source port(s). A packet sniffer or
similar device can be connected to this “destination” port, capturing traffic
without interfering with the actual data.
A SPAN source can consist of:
• One or more access switchports (Local SPAN)
• One or more routed interface
• An EtherChannel
• A trunk port
• An entire VLAN (VSPAN)
SPAN can mirror data coming inbound or outbound on a source interface,
or both.
A SPAN destination can consist of only a single switchport or routed
interface. Once an interface is identified as a SPAN destination, it is
dedicated to that purpose. No user traffic will be sent down that link. If you
configure a SPAN destination as a trunk port, it will be able to capture all
VLAN tagged data.
A SPAN destination cannot be an EtherChannel.
Under some circumstances, the traffic from the SPAN source can exceed the
capacity of the destination interface. For example, if the SPAN source was
an entire VLAN, this could very easily exceed the bandwidth capabilities of
a single Fast Ethernet interface. In this instance, packets in the destination
queue will be dropped to ease the congestion. Always remember, that the
source port(s)/VLAN are never affected.
***
Configuring SPAN
The first step in configuring SPAN is to identify a source:
Switch(config)# monitor session 1 source interface fa0/10 rx
Switch(config)# monitor session 1 source interface fa0/11 tx
Switch(config)# monitor session 1 source vlan 100 both
The first command creates a monitor session, and assigns it a number of 1.

When we specify a destination interface, we must use the same session
number. The rest of the command identifies a source interface of fa0/10, and
monitors all received (rx) traffic.
The second command adds a second interface to our monitor session 1, this
time specifying transmitted (tx) traffic.
The third command adds a vlan to our monitor session 1, and specifies both
incoming and outgoing traffic.
If monitoring a source trunk port, we can specify which specific VLANs we
wish to SPAN to mirror:
Switch(config)# monitor session 1 filter vlan 1-5
Next, we must identify our destination port:

Switch(config)# monitor session 1 destination interface fa0/15
The above command associates destination interface fa0/15 to monitor

session 1.
To stop this monitoring session:

Switch(config)# no monitor session 1
To view the status of SPAN sessions:

Switch(config)# show monitor
***
Remote SPAN (RSPAN)
Consider the above example. The previous page described how to configure
SPAN if both the source and destination ports were on the same switch.
However, it is also possible to utilize SPAN if the source and destination are
on different switches, using Remote SPAN (RSPAN).
Each switch in the chain must support RSPAN, and the information is sent
across a configured RSPAN VLAN.
Configuration on Switch 1 would be:
Switch(config-vlan)# remote-span
Switch(config)# monitor session 1 source interface fa0/10
Switch(config)# monitor session 1 destination vlan 123


Switch(config)# monitor session 1 source vlan 123

Switch(config)# monitor session 1 destination interface fa0/12
On all three switches, we must create the RSPAN VLAN, and apply the
remote-span parameter to it.
On Switch 1, we configure our SPAN source as normal, but point to the

RSPAN VLAN as our destination. On Switch 3, we configure our SPAN
destination as normal, but point to the RSPAN VLAN as our source.
***
________________________________________________
Part IV
Advanced Switch Services
________________________________________________
***
Section 12
- Redundancy and Load Balancing -
Importance of Redundancy
Users utilize a single “gateway” to reach the Internet. In this example, the
gateway is a multilayer switch; however, it could just have easily been a
Layer 3 router. Throughout the rest of this section, the terms “router” and
“multilayer switch” will be used interchangeably.
The gateway represents a single point of failure on this network. If that
gateway fails, users no longer can access the Internet (or any other resource
beyond the gateway). This lack of redundancy may be unacceptable on
mission-critical networks.
A method to allow multiple “gateways” became necessary:
However, the solution needed to be transparent to the end user (or host
device).
***
Hot Standby Router Protocol (HSRP)

Cisco developed a proprietary protocol called Hot Standby Router
Protocol (HSRP) that allows multiple routers or multilayer switches to
masquerade as a single gateway. This is accomplished by assigning a virtual
IP address to all routers participating in HSRP.
All routers are assigned to a single HSRP group (numbered 0-255). Routers
are then elected to specific roles:
• Active Router – the router currently serving as the gateway
• Standby Router – backup router to the Active Router
• Listening Router – all other routers participating in HSRP
Only one Active and one Standby router are allowed per HSRP group.
HSRP routers regularly send Hello packets (by default, every 3 seconds) to
ensure all routers are functioning. If the current Active Router fails, the
Standby Router is made active, and a new Standby is elected.
The “role” of an HSRP router is dictated by its “priority.” Whichever router
has the highest (a higher value is better) priority becomes the Active Router;
the second highest priority becomes the Standby Router. If all priorities are
equal, whichever router has the highest IP Address on its HSRP interface
becomes active.
In the above example, Switch 2 would become the Active HSRP router, as it
has the highest priority. Switch 1 would become the Standby router.
***
HSRP “States”
A router or multilayer switch configured for HSRP will progress through
several “states” before settling into a role:
• Disabled – the interfaces is not configured for HSRP, or is
administratively shut down
• Init – this is the “starting” state when an interface is first brought up
• Learn – the router is waiting to hear hellos from the Active Router, to
learn the configured Virtual Address
• Listen – the router is aware of the Virtual IP address, but was not
elected the Active or Standby Router.
• Speak – the router is currently participating in an Active Router
election, and is sending Hello packets.
• Standby – the router is acting as a “backup” to the Active Router.
Monitors and sends hellos to the Active Router
• Active – the router is currently accepting and forwarding user traffic,
using the Virtual IP address. The Active Router actively exchanges
hellos with the Standby Router
By default, HSRP Hello packets are sent every 3 seconds.

Routers in a listening state will only listen for and not periodically send
hello packets. While the HSRP is fully converged, only the Active and
Standby Routers will send hellos.
When an election occurs, routers will enter a speaking state, and will send
hellos to complete the election process. Thus, the three “states” where hellos
are sent are speak, standby, and active.
***
HSRP Configuration
All HSRP configuration is completed on the interface that will be
“accepting” traffic.
To configure the priority of a router:
Switch(config-if)# standby 1 priority 150
The standby 1 command specifies what HSRP group that interface belongs
to. The priority 150 parameter changes the actual priority value. Remember
that a higher value wins, and that the default priority is 100.
However, if a new router is added to the HSRP group, and it has the best
priority, it will not automatically assume the role of the Active router. In
fact, the first router to be powered on will become the Active router, even if
it has the lowest priority!
To force the highest-priority switch to assume the role of Active router:
Switch(config-if)# standby 1 preempt delay 10
The standby 1 preempt command allows this switch to force itself as the
Active router, if it has the highest priority. The delay 10 parameter tells the
router to wait 10 seconds before becoming Active.
HSRP routers send out Hello packets to verify each other’s status:
Switch(config-if)# standby 1 timers 4 12
The standby 1 timers command allows us to configure the two timers. The
first setting 4 sets the Hello timer to 4 seconds. The second setting 12 sets
the holddown timer to 12 seconds.
Remember, by default, Hello packets are sent every 3 seconds. Only the
Standby router listens to Hello packets from the Active router. If the Standby
router doesn’t hear any Hellos from the Active router for the holddown
period, then it will assume the Active router is down.
In general, the holddown timer should be three times the Hello timer. HSRP
Hello packets are sent to the multicast address 224.0.0.2 over UDP port
1985.
***
HSRP Configuration (continued)

Each router in the HSRP group retains the address configured on its
respective interface. However, the HSRP group is assigned a virtual IP
address, that client computer “point” to as their default gateway.
To configure the virtual HSRP IP address:
Switch(config-if)# standby 1 ip 192.168.1.5
Multiple virtual HSRP IP addresses can be used:

Switch(config-if)# standby 1 ip 192.168.1.5
Switch(config-if)# standby 1 ip 192.168.1.6 secondary
The HSRP group is also assigned a virtual MAC address. By default, a

reserved MAC address is used:
0000.0c07.acxx
…where xx is the HSRP group number in Hexadecimal. For example, if the
Group Number was 8, the result would be:
0000.0c07.ac08
The HSRP virtual MAC address can be changed:
Switch(config-if)# standby 1 mac-address 0001.0023.0456
Authentication can be configured for HSRP. All HSRP routers in the group
must be configured with the same clear-text string:
Switch(config-if)# standby 1 authentication CISCO
***
HSRP Tracking
In the above example, Switch 2 becomes the Active Router, and Switch 1
becomes the Standby router. Both Switch 1 and Switch 2 send out Hello
packets with updates on their status.
On Switch 2, if port Fa0/12 goes down, the switch is still able to send Hello
packets to Switch 1 via Fa0/10. Thus, Switch 1 will never realize that no
traffic is leaving Switch 2, as the switch still appears to be “Active.”
To combat this, HSRP can “track” interfaces. If the “tracked” interface fails,
the router’s (or multilayer switch’s) priority is decreased by a specific value.
For example, on Switch 2 we would configure:
Switch(config-if)# standby 1 track fa0/12 50
The above command sets tracking for the fa0/12 interface, and will decrease
the priority of the switch by 50 if the interface fails. The hope is that the
priority is decreased enough to allow another router to be promoted to
Active.
Tracking of interfaces does not work unless the other router is configured to
“preempt” the Active Router.
Switch(config-if)# standby 1 preempt
Otherwise, Switch 1 would never take over, even if Switch 2’s priority was
decreased to 1.
***
Practical HSRP Example
Switch 1: Switch 2:
Switch(config)# int fa0/10 Switch(config)# int fa0/10
Switch(config-if)# no switchport Switch(config-if)# no switchport
Switch(config-if)# ip address 192.168.1.5 255.255.255.0 Switch(config-if)# ip address 192.168.1.6 255.255.255.0
Switch(config-if)# standby 1 priority 50 Switch(config-if)# standby 1 priority 75
Switch(config-if)# standby 1 preempt Switch(config-if)# standby 1 preempt
Switch(config-if)# standby 1 ip 192.168.1.1 Switch(config-if)# standby 1 ip 192.168.1.1
Switch(config-if)# standby 1 authentication CISCO Switch(config-if)# standby 1 authentication CISCO
Switch(config-if)# standby 1 track fa0/12 50
The no switchport command turns interface fa0/10 into a Layer 3 (routing)

port.
Both switches are assigned unique IP addresses to their interfaces. However,
both are given a single HSRP virtual IP address. This virtual address is
what client computers will use as their default gateway.
Because of its higher priority, Switch 2 will become the Active Router. Its
priority will decrement by 50 if interface fa0/12 should fail. Because Switch
1 is configured with the preempt command, it will take over the Active
Router duties if this should happen.
To view the status of a configured HSRP group:
Switch# show standby
***
Virtual Router Redundancy Protocol (VRRP)

While HSRP is a Cisco proprietary protocol, Virtual Router Redundancy
Protocol (VRRP) is a standardized “fault tolerance” protocol. It is nearly
identical to HSRP, with some notable exceptions:
• The “active” router is called the Master Router
• All other routers are Backup Routers
• By default, the virtual MAC address is 0000.5e00.01xx, where xx is
the hexadecimal group number
• Hello’s are sent, by default, every 1 second.
• VRRP Hellos are sent to multicast address 224.0.0.18.
• VRRP will preempt by default
• VRRP cannot track interfaces
Configuration of VRRP is also very similar to HSRP:
Switch(config-if)# vrrp 1 priority 75
Switch(config-if)# vrrp 1 authentication CISCO
Switch(config-if)# vrrp 1 ip 192.168.1.1
By default, the VRRP priority is 100.

Again, preemption is enabled by default. It can be disabled:
Switch(config-if)# no vrrp 1 preempt
Or re-enabled again:
Switch(config-if)# vrrp 1 preempt
To view VRRP status:

Switch# show vrrp brief all
***
HSRP’s and VRRP’s “Pseudo” Load-Balancing

While HSRP and VRRP do provide redundant gateways for fault tolerance,
they do not provide load-balancing between those gateways.
Cisco “pretends” that load balancing can be configured. Theoretically, two
separate HSRP or VRRP “groups” can be configured on each router. There
would thus be two virtual IP addresses for each group. Each router would be
the Active router for one group, and the Standby router for the other group.
Then, half of the clients can be pointed to one virtual address, and the other
half to the other address.
That’s simple and dynamic, right? Nothing like having to manually
configure half of your clients to use one gateway address, and half of them
to use the other. Or set up two separate DHCP scopes….
<unnecessary obscene commentary edited out>
Gateway Load Balancing Protocol (GLBP)

<back to reality>
To overcome the…. shortcomings in HSRP and VRRP, Cisco developed the
oh-so proprietary Gateway Load Balancing Protocol (GLBP). Routers or
multilayer switches are added to a GLBP group, but unlike HSRP/VRRP, all
routers are Active. Thus, both redundancy and load-balancing are achieved.
And there was much rejoicing.
As with HSRP and VRRP, GLBP routers are placed in a “group” (1-255).
Routers are assigned a priority (default is 100), and the router with the
highest priority becomes the Active Virtual Gateway (AVG). If priorities
are equal, which router has the highest IP on its interface will become the
AVG.
***
GLBP Example
Routers (or multilayer switches) in the GLBP group are assigned a virtual IP
address. Clients point to this virtual address as their default gateway.
Remember that for IP communication to occur, a device needs to broadcast
an ARP request to determine the MAC address for that virtual IP. Whichever
router was elected the AVG (highest priority) listens for those ARP requests.
In addition to the AVG, up to three other routers can become Active Virtual
Forwarders (AVF’s). The AVG assigns each AVF (including itself) a
virtual MAC address (for a maximum total of 4 virtual MAC addresses).
When a client performs an ARP request, the AVG will provide the client
with one of the virtual MAC addresses. In this way, load balancing can
occur.
GLBP is not limited to four routers. Any routers that are not AVF’s become
Secondary Virtual Forwarders (SVF’s), which wait in standby until an
AVF fails.
What determines whether a router becomes an AVF or SVF? Each router is
assigned a weight, and the default weight is 100. Weight can either be
statically configured, or dynamically decided. When dynamically decided, a
router’s weight will drop if a tracked interface fails.
***
GLBP Load-Balancing
GLBP supports three load balancing methods:
• Round Robin – Traffic is distributed equally between all routers. The
first request is sent to Router 1, the second to Router 2, etc. This is the
default load balancing mechanism.
• Weighted – Routers that have a higher weight will be utilized more
frequently.
• Host-Dependent – Once a client performs an ARP request, that client
always utilizes the same gateway
Configuring GLBP
To set a GLBP router’s priority to 150:
Switch(config-if)# glbp 1 priority 150
To allow a router with a higher priority to preempt the current AVG

(preemption is not enabled by default):
Switch(config-if)# glbp 1 preempt
To track an interface, so that a router’s weight can be reduced if the interface

fails:
Switch(config)# track 10 interface fa0/12
Switch(config-if)# glbp 1 weighting track 10 decrement 50
The first command creates a track object 10, which is tracking interface
fa0/12. The second command assigns that track object to glbp group 1, and
will decrease this router’s weight by 50 if interface fa0/12 fails. Another
router cannot become AVF unless it is configured to preempt.
We can also specify the Virtual IP, and the load-balancing method:
Switch(config-if)# glbp 1 ip 192.168.1.2
Switch(config-if)# glbp 1 load-balancing weighted
***
Server Load Balancing (SLB)

HSRP, VRRP, and GLBP provide “gateway” redundancy for clients. Cisco
routers and switches also support a basic “clustering” service.
Server Load Balancing (SLB) allows a router to apply a virtual IP address
to a group of servers. All of the servers should be configured identically
(with the exception of their IP addresses), and provide the same function.
Having multiple servers allows for both redundancy and load-balancing.
Clients point to a single virtual IP address to access the server farm. The
client is unaware of which server it is truly connecting to. If one of the
servers fails, the server farm can stay operational. Individual servers can be
brought down for repair or maintenance, and the server farm can stay
functional
The following diagram demonstrates SLB:
We’ll assume the servers are Web servers. To access the Web resource,
users will connect to the Virtual IP address 192.168.1.10. The multilayer
switch intercepts this packet, and redirects it to one of the physical servers
inside the server farm. In essence, the multilayer switch is functioning as a
Virtual Server.
***
SLB Load Balancing Methods

Two load balancing methods exist for SLB:
• Weighted Round Robin – Traffic is forwarded to the physical
servers in a round robin fashion. However, servers with a higher
weight are assigned more traffic. This is the default method.
• Weighted Least Connections – Traffic is assigned to the server with
the least amount of current connections
Configuring SLB
Two separate elements need to be configured with SLB, the Server Farm,
and the Virtual Server.
To configure the Server Farm:
Switch(config)# ip slb serverfarm MYFARM
Switch(config-slb-sfarm)# predictor leastconns
Switch(config-slb-sfarm)# real 192.168.1.20

Switch(config-slb-real)# weight 150
Switch(config-slb-real)# inservice
Switch(config-slb-sfarm)# real 192.168.1.21

Switch(config-slb-real)# weight 100
Switch(config-slb-real)# inservice
The ip slb serverfarm command sets the server farm name, and places you in
SLB Server Farm configuration mode.
The predictor command sets the load-balancing method.
The real command identifies the IP address of a physical server in the farm,
and places you in SLB Real Server configuration mode.
The weight command assigns the load-balancing weight to that server.
The inservice command activates the real server. To deactivate: no inservice
***
Configuring SLB (continued)

To configure the Virtual Server:
Switch(config)# ip slb vserver VSERVERNAME
Switch(config-slb-vserver)# serverfarm MYFARM
Switch(config-slb-vserver)# virtual 192.168.1.10
Switch(config-slb-vserver)# client 192.168.0.0 0.0.255.255
Switch(config-slb-vserver)# inservice
The ip slb vserver command sets the Virtual Server name, and places you in
SLB Virtual Server configuration mode.
The serverfarm command associates the server farm to this Virtual Server.
The virtual command assigns the virtual IP address for the server farm.
The client command allows you to specify which clients can access the
server farm. It utilizes a wildcard mask like an access-list. In the above
example, client 192.168.0.0 0.0.255.255 would allow all clients in the
192.168.x.x Class B network.
The inservice activates the Virtual Server. To deactivate: no inservice.
To troubleshoot SLB:
Switch# show ip slb serverfarms
Switch# show ip slb vserver
Switch# show ip slb real
***
Section 13
- Multicast -
Types of “packets”
Three types of packets can exist on an IPv4 network:
Unicast – A packet sent from one host to only one other host. A hub will
forward a unicast out all ports. If a switch has a table entry for the unicast’s
MAC address, it will forward it out only the appropriate port.
Broadcast – A packet sent from one host to all hosts on the IP subnet. Both
hubs and switches will forward a broadcast out all ports. By definition, a
router will not forward a broadcast from one segment to another.
Multicast – A packet sent from one host to a specific group of hosts.
Switches, by default, will forward a multicast out all ports. A router, by
default, will not forward a multicast from one segment to another.
Multicast Concepts
Remember, a multicast is a packet sent from one computer to a group of
hosts. A host must join a multicast group in order to accept a multicast.
Joining a multicast group can be accomplished statically or dynamically.
Multicast traffic is generally sent from a multicast server, to multicast
clients. Very rarely is a multicast packet sent back from a client to the
server.
Multicasts are utilized in a wide range of applications, most notably voice or
video systems that have one source “serving” out data to a very specific
group of clients.
The key to configuring multicast is to ensure only the hosts that require the
multicast traffic actually receive it.
***
Multicast Addressing
IPv4 addresses are separated into several “classes.”
Class A: 1.1.1.1 – 127.255.255.255
Class B: 128.0.0.0 – 191.255.255.255
Class C: 192.0.0.0 – 223.255.255.255
Class D: 224.0.0.0 – 239.255.255.255
Class D addresses have been reserved for multicast. Within the Class D
address space, several ranges have been reserved for specific purposes:
• 224.0.0.0 – 224.0.0.255 – Reserved for routing and other network
protocols, such as OSPF, RIP, VRRP, etc.
• 224.0.1.0 – 238.255.255.255 – Reserved for “public” use, can be used
publicly on the Internet. Many addresses in this range have been
reserved for specific applications
• 239.0.0.0 – 239.255.255.255 – Reserved for “private” use, and cannot
be routed on the Internet.
The following outlines several of the most common multicast addresses
reserved for routing protocols:
• 224.0.0.1 – all hosts on this subnet
• 224.0.0.2 – all routers on this subnet
• 224.0.0.5 – all OSPF routers
• 224.0.0.6 – all OSPF Designated routers
• 224.0.0.9 – all RIPv2 routers
• 224.0.0.10 – all IGRP routers
• 224.0.0.12 – DHCP traffic
• 224.0.0.13 – all PIM routers
• 224.0.0.19-21 – ISIS routers
• 224.0.0.22 – IGMP traffic
• 224.0.1.39 – Cisco RP Announce
• 224.0.1.40 – Cisco RP Discovery
***
Multicast MAC Addresses

Unfortunately, there is no ARP equivalent protocol for multicast addressing.
Instead, a reserved range of MAC addresses were created for multicast IPs.
All multicast MAC addresses begin with:
0100.5e
Recall that the first six digits of a MAC address identify the vendor code,
and the last 6 digits identify the specific host address. To complete the MAC
address, the last 23 bits of the multicast IP address are used.
For example, consider the following multicast IP address and its binary
equivalent:
224.65.130.195 = 11100000.01000001.10000010.11000011
Remember that a MAC address is 48 bits long, and that a multicast MAC
must begin with 0100.5e. In binary, that looks like:
00000001.00000000.01011110.0
Add the last 23 bits of the multicast IP address to the MAC, and we get:
00000001.00000000.01011110.01000001.10000010.11000011
That should be exactly 48 bits long. Converting that to Hex format, our full
MAC address would be:
0100.5e41.82c3
How did I convert this to Hex? Remember that hexadecimal is Base 16
mathematics. Thus, to represent a single hexadecimal digit in binary, we
would need 4 bits (24 = 16). So, we can break down the above binary MAC
address into groups of four bits:
Binary 0000 0001 0000 0000 0101 1110 0100 0001 1000 0010 1100 0011
Decimal 0 1 0 0 5 14 4 1 8 2 12 3
Hex 0 1 0 0 5 e 4 1 8 2 c 3
Hence the MAC address of 0100.5e41.82c3.
***
Multicast MAC Addresses (continued)

Ready for some more math, you binary fiends?
Calculate what the multicast MAC address would be for the following IP
addresses:
225.2.100.15 = 11100001.00000010.01100100.00001111
231.130.100.15 = 11100111.10000010.01100100.00001111
Remember that all multicast MACs begin with:
0100.5e = 00000001.00000000.01011110.0
So, add the last 23 digits of each of the above IP addresses to the MAC
address, and we get:
225.2.100.15 = 00000001.00000000.01011110.00000010.01100100.00001111
231.130.100.15 = 00000001.00000000.01011110.00000010.01100100.00001111
In Hex, that would be:

225.2.100.15 = 0100.5e02.640f
231.130.100.15 = 0100.5e02.640f
Wait a second…. That’s the exact same multicast MAC address, right?
Double-checking our math, we see that it’s perfect.
Believe it or not, each multicast MAC address can match 32 multicast IP
addresses, because we’re only taking the last 23 bits of our IP address.
We already know that all multicast IP addresses MUST begin 1110. Looking
at the 225.2.100.15 address in binary:
11100001.00000010.01100100.00001111
That leaves 5 bits in between our starting 1110, and the last 23 bits of our IP.
Those 5 bits could be anything, and the multicast MAC address would be the
same. Because 25 = 32, there are 32 multicast IP’s per multicast MAC.
According to the powers that be, the likelihood of two multicast systems
utilizing the same multicast MAC is rare. The worst outcome would be that
hosts joined to either multicast system would receive multicasts from both.
***
Multicasts and Routing

A router, by default, will drop multicast traffic, unless a Multicast routing
protocol is utilized. Multicast routing protocols ensure that data sent from a
multicast source are received by (and only by) its corresponding multicast
clients.
Several multicast routing protocols exist, including:
• Protocol Independent Multicast (PIM)
• Multicast OSPF (MOSPF)
• Distance Vector Multicast Routing Protocol (DVMRP)
• Core-Based Trees (CBT)
Multicast routing must be enabled globally on a Cisco router or switch,
before it can be used:
Switch(config)# ip multicast-routing
Multicast Path Forwarding

Normally, routers build routing tables that contain destination addresses,
and route packets towards that destination. With multicast, routers are
concerned with routing packets away from the multicast source. This
concept is called Reverse Path Forwarding (RPF).
Multicast routing protocols build tables that contain several elements:
• The multicast source, and its associated multicast address (labeled as
“S,G”, or “Source,Group”)
• Upstream interfaces that point towards the source
• Downstream interfaces that point away from the source towards
multicast hosts.
***
Multicast Path Forwarding Example
A router interface will not be designated as a downstream interface unless

multicast hosts actually exist downstream. In the above example, no
multicast hosts exist downstream of Router 5.
In fact, because no multicast hosts exist downstream of Router 1 towards
Router 2, no multicast traffic for this multicast group will be forwarded
down that path. Thus, Router 1’s interface connecting to Router 2 will not
become a downstream port.
This pruning allows for efficient use of bandwidth. No unnecessary traffic is
sent down a particular link. This “map” of which segments contain multicast
hosts is called the multicast tree. The multicast tree is dynamically updated
as hosts join or leave the multicast group (otherwise known as pruning the
branches).
By designating upstream and downstream interfaces, the multicast tree
remains loop-free. No multicast traffic should ever be sent back upstream
towards the multicast source.
***
Internet Group Management Protocol (IGMP)

Remember, multicast works by having a source send data to a specific set of
clients that belong to the same multicast group. The multicast group is
configured (or assigned) a specific multicast address.
The multicast clients need a mechanism to join multicast groups. Internet
Group Management Protocol (IGMP) allows clients to send “requests” to
multicast-enabled routers to join a multicast group.
IGMP only handles group membership. To actually route multicast data to a
client, a multicast routing protocol is required, such as PIM or DVMRP.
Three versions of IGMP exist, IGMPv1, IGMPv2, and IGMPv3.
IGMPv1 routers send out a “query” every 60 seconds to determine if any
hosts need access to a multicast server. This query is sent out to the
224.0.0.1 address (i.e., all hosts on the subnet). Interested hosts must reply
with a Membership Report stating what multicast group they wish to join.
Unfortunately, IGMPv1 does not allow hosts to dynamically “leave” a
group. Instead, if no Membership Reports are received after 3 times the
query interval, the router will flush the hosts out of its IGMP table.
IGMPv2 adds additional functionality. Queries can be sent out either as
General Queries (224.0.0.1) or Group-Specific Queries (only sent to
specific group members). Additionally, hosts can send a Leave Group
message to IGMPv2 routers, to immediately be flushed out of the IGMP
table. Thus, IGMPv2 allows the multicast tree to by updated more
efficiently.
All versions of IGMP elect one router to be the Designated Querier for that
subnet. The router with the lowest IP address becomes Designated.
IGMPv1 is not compatible with IGMPv2. If any IGMPv1 routers exist on
the network, all routers must operate in IGMPv1 mode.
Cisco IOS version 11.1 and later support IGMPv2 by default.
IGMPv3 enhances v2 by supporting source-based filtering of multicast
groups. Essentially, when a host responds to an IGMP query with a
Membership Report, it can specifically identify which sources within a
multicast group to join (or even not join).
***
IGMP Example
In the above example, assume the router is using IGMPv2. Interface fa0/1
points towards the multicast source, and thus becomes the upstream
interface.
Initially, the router will sent out Group Specific Queries out all non-
upstream interfaces. Any multicast hosts will respond with a Membership
Report stating what multicast group they wish to join.
Interfaces fa0/2 and fa0/3 will become downstream interfaces, as they
contain multicast hosts. No multicast traffic will be sent out fa0/4.
If all multicast hosts leave the multicast group off of interface fa0/2, it will
be removed from the multicast tree. If a multicast host is ever added off of
interface fa0/4, it will become a downstream interface.
***
IGMP Configuration
No configuration is required to enable IGMP, except to enable IP multicast
routing (ip multicast-routing). We can change the version of IGMP running
on a particular interface (by default, it is Version 2):
Switch(config-if)# ip igmp version 1
To view which multicast groups the router is aware of:

Switch# show ip igmp groups
We can join a router interface to a specific multicast group (forcing the

router to respond to ICMP requests to this multicast group):
Switch(config-if)# ip igmp join-group 226.1.5.10
WE can also simply force a router interface to always forward the traffic of a
specific multicast group out an interface:
Switch(config-if)# ip igmp static-group 226.1.5.10
We can also restrict which multicast groups a host, off of a particular

interface, can join:
Switch(config)# access-list 10 permit 226.1.5.10
Switch(config-if)# ip igmp access-group 10
***
Protocol Independent Multicast (PIM)

While IGMP concerns itself with allowing multicast hosts to join multicast
groups, Protocol Independent Multicast (PIM) is a multicast routing
protocol that is concerned about getting the multicast data to its destination
(or, more accurately, taking the data away from the multicast source).
PIM is also responsible for creating the multicast tree, and “pruning” the tree
so that no traffic is sent unnecessarily down a link.
PIM can operate in three separate modes:
• PIM Dense Mode (PIM-DM)
• PIM Sparse Mode (PIM-SM)
• PIM Sparse-Dense Mode (PIM-SM-DM, Cisco proprietary)
The key difference between PIM Dense and Sparse Mode is how the
multicast tree is created. With PIM Dense Mode, all networks are flooded
with the multicast traffic from the source. Afterwards, networks that don’t
need the multicast are pruned off of the tree. The network that contains the
multicast source becomes the “root” of the multicast network.
With PIM Sparse Mode, no “flooding” occurs. Only networks that contain
“requesting” multicast hosts are added to the multicast tree. A centralized
PM router, called the Rendezvous Point (RP), is elected to be the “root”
router of the multicast tree. PIM routers operating in Sparse Mode build their
tree towards the RP, instead of towards the multicast source. The RP allows
multiple multicast “sources” to utilize the same multicast tree.
PIM Sparse-Dense Mode allows either Sparse or Dense Mode to be used,
depending on the multicast group. Any group that points to an RP utilizes
Sparse Mode. PIM Sparse-Dense Mode is Cisco proprietary.
Consider these key points:
• Dense Mode should be used when a large number of multicast hosts
exist across the internetwork. The “flooding” process allows for a
quick creation of the multicast tree, at the expense of wasting
bandwidth.
• Sparse Mode should be used when only a limited number of
multicast hosts exist. Because hosts must explicitly join before that
network segment is added to the multicast tree, bandwidth is utilized
more efficiently.
***
PIM Dense Mode Example
Multicast
Source
Router 1
Router 2 Router 3 Router 4
Router 6 Router 7
Router 5
Multicast Hosts No Multicast Multicast Hosts

No Multicast Hosts
Hosts
Consider the above example. When PIM routers operate in Dense Mode, all
segments of the multicast tree are flooded initially. Eventually, “branches”
that do not require the multicast traffic are pruned off:
Multicast
Source
Router 1
Router 2 Router 3 Router 4
Router 6 Router 7
Router 5
Multicast Hosts No Multicast Multicast Hosts

No Multicast Hosts
Hosts
***
PIM Sparse Mode Example
When PIM routers operate in Sparse Mode, multicast traffic is not initially
flooded throughout the entire multicast tree. Instead, a Rendezvous Point
(RP) is elected or designated, and all multicast sources and clients must
explicitly register with the RP. This provides a centralized method of
directing the multicast traffic of multiple multicast sources:
***
Configuring Manual PIMv1

Two versions of PIM exist (PIMv1 and PIMv2), though both are very
similar. PIM must be enabled on each participating interface in the multicast
tree.
To enable PIM and specify its mode on an interface:
Switch(config-if)# ip pim dense-mode
Switch(config-if)# ip pim sparse-mode
Switch(config-if)# ip pim sparse-dense-mode
When utilizing PIM-SM, we must configure a Rendezvous Point (RP). RP’s

can be identified manually, or dynamically chosen using a process called
auto-RP (Cisco-proprietary).
To manually specify an RP on a router:
Switch(config)# ip pim rp-address 192.168.1.1
The above command must be configured on every router in the multicast

tree, including the RP itself.
To restrict the RP to a specific set of multicast groups:
Switch(config)# ip pim rp-address 192.168.1.1 10
The first two commands create an access-list 10 specifying the multicast

groups this RP will support. The third command identifies the RP, and
applies access-list 10 to the RP.
***
Configuring Dynamic PIMv1

When using Cisco’s auto-RP, one router is designated as a Mapping Agent.
To configure a router as a mapping agent:
Switch(config)# ip pim send-rp-discovery scope 10
The 10 parameter in the above command is a TTL (Time to Live) setting,

indicating that this router will serve as a mapping agent for up to 10 hops
away.
Mapping agents listen for candidate RP’s over multicast address 224.0.1.39
(Cisco RP Announce). To configure a router as a candidate RP:
Switch(config)# ip pim send-rp-announce fa0/10 scope 4 group-list 10

groups this RP will support. The third command identifies this router as a
candidate RP for the multicast groups specified in group-list 10. This RP’s
address will be based on the IP address configured on fa0/10. The scope 4
parameter indicates the maximum number of hops this router will advertise
itself for.
The above commands essentially create a “mapping” of specific RP’s to
specific multicast groups. Once a mapping agent learns of these mappings
from candidate RPs, it sends the information to all PIM routers over
multicast address 224.0.1.40 (Cisco RP Discovery).
***
Configuring Dynamic PIMv2

Configuring PIMv2 is very similar to PIMv1, except that PIMv2 is a
standards-based protocol. Also, there are terminology differences. Instead of
mapping agents, PIMv2 uses Bootstrap Routers (BSR), which performs the
same function.
To configure a router as a BSR:
Switch(config)# ip pim bsr-candidate fa0/10
To configure candidate RP’s in PIMv2:

Switch(config)# ip pim rp-candidate fa0/10 4 group-list 10

groups this RP will support. The third command identifies this router as a
candidate RP for the multicast groups specified in group-list 10. This RP’s
address will be based on the IP address configured on fa0/10. The 4
parameter indicates the maximum number of hops this router will advertise
itself for.
With PIMv2, we can create border routers to prevent PIM advertisements
(from the BSR or Candidate RPs) from passing a specific point.
To configure a router as a PIM border router:
Switch(config)# ip pim border
***
Multicasts and Layer 2 Switches

Up to this point, we’ve discussed how multicasts interact with routers or
multilayer switches.
By default, a Layer 2 switch will forward a multicast out all ports, excluding
the port it received the multicast on. To eliminate the need of “flooding”
multicast traffic, two mechanisms have been developed for Layer 2
switches:
• IGMP snooping
• CGMP
IGMP snooping allows a Layer 2 switch to “learn” the multicast MAC
address of multicast groups. It does this by eavesdropping on IGMP
Membership Reports sent from multicast hosts to PIM routers. The Layer 2
switch then adds a multicast MAC entry in the CAM for the specific port
that needs the multicast traffic.
IGMP snooping is enabled by default on the Catalyst 2950 and 3550. If
disabled, it can be enabled with the following command:
Switch(config)# ip igmp snooping
If a Layer 2 switch does not support IGMP snooping, Cisco Group

Membership Protocol (CGMP) can be used. Three guesses as to whether
this is Cisco-proprietary or not.
Instead of the Layer 2 switch “snooping” the IGMP Membership Reports,
CGMP allows the PIM router to actually inform the Layer 2 switch of the
multicast MAC address, and the MAC of the host joining the group. The
Layer 2 switch can then add this information to the CAM.
CGMP must be configured on the PIM router (or multilayer switch). It is
disabled by default on all PIM routers. To enable CGMP:
Switch(config-if)# ip cgmp
No configuration needs to occur on the Layer 2 switch.
***
Troubleshooting Multicasting
To view IGMP groups and current members:
Switch# show ip igmp groups
To view the IGMP snooping status:

Switch# show ip igmp snooping
To view PIM “neighbors”:

Switch# show ip pim neighbor
To view PIM RPs:

Switch# show ip pim rp
To view PIM RP-to-Group mappings:

Switch# show ip pim rp mapping
To view the status of PIMv1 Auto-RP:

Switch# show ip pim autorp
To view PIMv2 BSRs:

Switch# show ip pim bsr-router
We can also debug multicasting protocols:

Switch# debug ip igmp
Switch# debug ip pim
***
Viewing the Multicast Table

Just like unicast routing protocols (such as OSPF, RIP), multicast routing
protocols build a routing table.
Again, these tables contain several elements:
• The multicast source, and its associated multicast address (labeled as
“S,G”, or “Source,Group”)
• Upstream interfaces that point towards the source
• Downstream interfaces that point away from the source towards
multicast hosts.
To view the multicast routing table:
Switch# show ip mroute
If using PIM in Dense Mode, the output would be similar to the following:
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(10.1.1.1/24, 239.5.222.1), uptime 1:11:11, expires 0:04:29, flags: C

Incoming interface: Serial0, RPF neighbor 10.5.11.1
Outgoing interface list:
Ethernet0, Forward/Sparse, 2:52:11/0:01:12
Remember that a multicast source with its associated multicast address is

labeled as (S,G). Thus, in the above example, 10.1.1.1/24 is the multicast
source, while 239.5.222.1 is the multicast address/group that the source
belongs to.
The Incoming interface indicates the upstream interface. The RPF neighbor
is the next hop router “upstream” towards the source. The outgoing
interface(s) indicate downstream interfaces.
Notice that the S – Sparse flag is not set. That’s because PIM is running in
Dense Mode.
***
Viewing the Multicast Table (continued)

Remember, to view the multicast routing table:
Switch# show ip mroute
If using PIM in Sparse Mode, the output would be similar to the following:
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 224.59.222.10), uptime 2:11:05, RP is 10.1.1.10, flags: SC

Incoming interface: Serial0, RPF neighbor 10.3.35.1,
Outgoing interface list:
Ethernet0, Forward/Sparse, 4:41:22/0:05:21
Notice that the (S,G) pairing is labeled as (*, 224.59.222.10). In Sparse

Mode, we can have multiple sources share the same multicast tree.
The Rendezvous Point (RP) is 10.1.1.10. The flags are set to SC, indicating
this router is running in Sparse Mode.
Just like with Dense Mode, the Incoming interface indicates the upstream
interface, and the outgoing interface(s) indicate downstream interfaces.
However, the RPF neighbor is the next hop router “upstream” towards the
RP now, and not the source.
***
Section 14
- Introduction to QoS -
Obstacles to Network Communication
Various types of “traffic” can exist on a network, including voice, video, and
“data” (such as email, file sharing, web traffic, etc.).
Some forms of traffic, especially voice and video, require “guaranteed” or
“regulated” service. Such traffic is more susceptible to the obstacles of
network communication, which include:
Bandwidth – Nothing interferes with network communication more than a
simple lack of sufficient physical speed. Thus, increasing bandwidth is often
considered the best method of improving network communication.
Bandwidth is generally measured in bits-per-second (bps), and can either
be a fixed rate speed (as Ethernet usually is), or a variable rate speed (as
Frame-Relay is). Various mechanisms, such as compression, can be used to
pseudo-increase the bandwidth capacity of a link.
Delay – Defines the latency that occurs when traffic is sent from one device
to another device. Delay can occur at several points on a network, all of
which will be covered shortly.
Jitter – Describes the fragmentation that occurs when traffic arrives at
irregular times (in other words, with a varying amount of delay), or in the
wrong order. Voice communication is especially susceptible to jitter issues.
Data Loss – Defines the inconsistency or failure that occurs when traffic is
dropped due to congestion. Packets are most often dropped when queues
become full, and tail drop takes effect.
All of these factors – bandwidth, delay, jitter, and data loss – adversely
affect network communication. While increasing bandwidth may alleviate
many issues, various Quality of Service (QoS) tools have been developed to
control the affects of these factors, when additional bandwidth may not be
available. These QoS mechanisms provide specific applications with
guaranteed, consistent service.
***
Types of Delay
As stated earlier, delay can occur at all points on a network. Thus, various
types of delay have been defined:
• Serialization Delay – refers to the time necessary to encode bits of
data on a physical interface. Calculating serialization delay can be
accomplished using a simple formula:
________# of bits________
bits per second (bps)
Thus, the serialization delay to encode 128,000 bits on a 64,000 bps

link would be 2 seconds.
• Propagation Delay – refers to the time necessary for a single bit to
travel end-to-end on a physical wire. For the incredibly anal geeks, the
“rough” formula to estimate propagation delay:
____Length of the Physical Wire (in meters)___
2.1 x 108 meters/second
• Forwarding Delay – refers to the time between the ingress (input)

and egress (output) queues. Forwarding delay is affected by
routing/switching methods, and the speed of the underlying CPU. For
example, a router with a very large routing table but a very slow CPU
will have long forwarding delays.
• Queuing Delay – refers to the time spent in an egress queue, waiting
for previously-queued packets to be sent first. Queues that are too
small will become congested, and start dropping new packets (tail
drop – which forces a higher-layer protocol such as TCP to resend
data). Queues that are too large will queue too many packets, causing
long queuing delays
• Network (Provider) Delay – refers to the time spent in a provider’s
“cloud,” which could consist of a large number of routers/switches.
Network delay can be very difficult to quantify, as it is often
impossible to determine the structure of the cloud.
• Shaping Delay – refers to the delay initiated by shaping mechanisms
(usually used by Frame Relay), intended to slow down traffic to
prevent dropped packet due to congestion.
***
QoS Methodologies
Three separate QoS “philosophies” exist, each with a different method (or
non-method) of providing quality of service:
• Best-Effort – Traffic is routed on a first come, first served basis.
Best-Effort is not truly QoS, but simply the default behavior of routers
and switches.
• Integrated Services (IntServ) – “End-to-end” QoS, meaning that a
dedicated (or guaranteed) communication path is provided (or
“reserved”) from the sending host to the receiving host. This quickly
becomes impractical on large networks with a variety of applications
needing QoS. There is only so much bandwidth that can be reserved.
• Differentiated Services (DiffServ) – Organizes traffic into separate
Classes of Service (CoS). Each router (or hop) is configured with
“instructions” on how to handle traffic, based on the CoS criteria.
The CCNP exams concentrate mostly on DiffServ QoS.
QoS Tools
Various tools have been developed to enforce QoS. Most of these tools are
used in conjunction with each other for a complete QoS policy.
• Classification and Marking – classification differentiates services by
looking at packet headers. Marking uses either the IP Precedence or
DSCP field of a packet to specify the level of QoS required for a
specific service/application.
• Queuing - used to allocate bandwidth and priority to specific traffic
types (per the above classification and marking).
• Queue Congestion Avoidance – used to regulate queue usage so that
total queue saturation does not occur.
• Traffic Shaping and Policing – used to regulate (or enforce) traffic
flow rates, to prevent link saturation.
Each of the above tools is covered in great detail in separate guide.
***
Section 15
- DiffServ QoS -
Classifying Traffic
Differentiated QoS relies on the “classification” of traffic. The header of an
IP packet contains a one byte (8 bit) field for Type of Service (ToS). The
value of this ToS field indicates the level of QoS needed for the IP packet.
The ToS field is used by two “implementations” of QoS:
• IP Precedence - which uses only 3 bits of the ToS field to classify
traffic
• Differentiated Service Code Point (DSCP) – which uses 6 bits of
the ToS field to classify traffic. When using DSCP, the ToS field is
often referred to as the Differentiated Services (DS) field.
IP Precedence
IP Precedence utilizes three bits of the ToS header to identify the “priority”
of a packet. The IP Precedence of a packet can be set using access lists, class
maps, route maps, or various QoS “traffic shaping” mechanisms. The higher
the value, the better “service” that is provided.
Eight different IP Precedence values exist:
Type Decimal Binary Description
Routine 0 000 “Best effort” routing

Priority 1 001 Higher QoS than Routing
Immediate 2 010 Higher QoS than Priority
Flash 3 011 Higher QoS than Immediate
Flash-Override 4 100 Higher QoS than Flash
Critical 5 101 Highest QoS for non router traffic
Internet 6 110 Reserved for routing protocols
Network Control 7 111 Reserved for control traffic
By default, all traffic has an IP Precedence of 000 (Routine), and is
forwarded on a best-effort basis. Normal network traffic should not be set to
110 (Internet) or 111 (Network Control), as it could interfere with the
operation of the routers.
***
Differentiated Service Code Point (DSCP)

DSCP utilizes six bits of the ToS header to identify the “priority” of a
packet. The first three bits identify the Class of the packet, and the last three
bits identify the Drop Precedence of the packet.
Class Name Binary Class Selector Drop Precedence
Default 000 000 0

AF11 001 010 Low
AF12 001 100 1 Medium
AF13 001 110 High
AF21 010 010 Low
AF22 010 100 2 Medium
AF23 010 110 High
AF31 011 010 Low
AF32 011 100 3 Medium
AF33 011 110 High
AF41 100 010 Low
AF42 100 100 4 Medium
AF43 100 110 High
EF 101 110 5
Confused? It’s simpler than it looks.
DSCP has 6 separate “classes” for traffic (0-5). Class “0” is default, and
indicates best-effort routing. Class “5” is the highest form of DSCP QoS.
Higher valued Class Selectors are provided with better QoS.
Within each Class Selector, traffic is also assigned a Drop Precedence.
Packets with a higher Drop Precedence are more likely to be dropped during
congestion than packets with a lower Drop Precedence (within the same
Class Selector).
The Class Name provides a simple way of identifying the DSCP value. AF
is short for Assured Forwarding, and is the type of service applied to
Classes 1 – 4. If a packet is marked AF23, then we know its Class is 2 (the
“2” in 23) and its Drop Precedence is High (the “3” in 23).
Packets marked as Class 0 (Default) or Class 5 (Expedited Forwarding or
EF) do not have a Drop Precedence.
***
Identifying Traffic for QoS

The first step to configuration QoS on Catalyst switches is to enable QoS:
Switch(config)# mls qos
Next, we must identify the traffic we wish to apply QoS to, in a class map:
Switch(config)# access-list 10 permit 192.168.1.0 0.0.0.255
Switch(config)# class-map match-any MYCLASS

Switch(config-cmap)# match access-group 10
Switch(config-cmap)# match ip precedence 2
Switch(config-cmap)# match ip dscp af21
Switch(config-cmap)# match protocol ftp
Switch(config-cmap)# match protocol napster
Switch(config-cmap)# match protocol kazaa2
The first command creates the class-map named MYCLASS. The match-any
parameter indicates that the packet can match any of the criteria within the
class-map. We could also have specified match-all, which would have
required that the packet match all the criteria within the class-map.
After creating the class map, we are placed into Class Map Configuration
Mode. Here, we use match statements to specify the criteria our packet must
match.
We can match by access-list: match access-group 10
We can match by IP precedence: match ip precedence 2
We can match by DSCP value: match ip dscp af21
We can even match by application using Cisco’s Network-Based
Application Recognition (NBAR):
match protocol ftp
match protocol napster
match protocol kazaa2
NBAR keeps track of TCP/UDP traffic flows. The list of supported
applications for NBAR grows regularly.
***
Creating the QoS Policy

Identifying traffic for QoS is only the first step. Next, we must create a
“policy” that applies QoS values to traffic.
Switch(config)# policy-map MYPOLICY
Switch(config-pmap)# class MYCLASS
Switch(config-pmap)# set ip dscp af32
Switch(config-pmap)# set ip precedence 5
The first command creates the policy-map named MYPOLICY. The second
command associates the class-map we created earlier to this policy.
Finally, we can specify either the DSCP value or IP Precedence we wish to
apply to this traffic.
Applying the QoS Policy to an Interface

Once the QoS class map and policy are created, the last step is to apply the
policy to an interface. An interface can have up to two QoS policies, one
inbound and one outbound.
Switch(config-if)# service-policy input MYPOLICY
Thus, any traffic matching the criteria of class map MYCLASS, coming
inbound on interface fa0/10, will have the QoS information in the policy
MYPOLICY applied.
By default, routers and switches are configured not to trust the QoS
information received on an interface. This is useful for routers on the “edge”
of your network, preventing erroneous or malicious QoS-enabled packets
from congesting router queues. To enable your router/switch to trust either
DSCP or IP Precedence values:
Switch(config-if)# mls qos trust dscp
Switch(config-if)# mls qos trust ip-precedence
To not trust any received QoS information:

Switch(config-if)# no mls qos trust
“Not trusting” QoS information will not drop those packets! It simply
ignores the IP Precedence or DSCP information inside the packet header.
***
Troubleshooting QoS
To view the QoS settings on an interface:
Switch# show mls qos interface fa0/10
To view the queuing information for an interface:

Switch# show mls qos interface fa0/10 queuing
To view QoS mapping configurations:

Switch# show mls qos maps
***
Section 16
- Congestion Avoidance (WRED) -
Queue Congestion
Queues are susceptible to congestion. If a port’s queue buffer fills to
capacity, packets will be dropped. QoS provides switches and routers with a
mechanism to drop lower priority traffic before higher priority traffic.
By default, ports will perform tail drop if congestion occurs. Tail drop
works on a first come, first served basis. If a standard queue fills to capacity,
any new packets are indiscriminately dropped, regardless of QoS.
Weighted Random Early Detection

A more efficient of congestion control was developed called Weighted
Random Early Detection (WRED). WRED prevents the queue from ever
filling to capacity, by randomly dropping packets already queued using TCP’s
congestion control mechanism.
To confuse things further, there are two methods to configuring WRED. The
first method involves tuning WRED to drop packets with a lower IP
Precedence (or DSCP value) more frequently than higher priority packets. This
is accomplished by configuring minimum and maximum packet “thresholds”
for each IP Precedence or DSCP value. We’ll call this basic WRED
configuration.
The minimum threshold indicates the minimum number of packets that must
be in the queue before packets of that Precedence or DSCP value will be
randomly dropped. Whereas the maximum threshold indicates the number of
queued packets before all new packets of that Precedence or DSCP value are
dropped. Essentially, when the maximum threshold is reached, WRED mimics
the tail drop method of congestion control.
The second method involves tuning WRED maximum and minimum thresholds
on a per-queue basis, rather than to specific IP Precedence or DSCP values. In
this instance, the min and max thresholds are based on percentages, instead of a
specific number of packets. We’ll call this advanced WRED configuration,
and is only supported on higher model Catalyst switches.
WRED only affects standard queues. Traffic from strict priority queues is never
dropped by WRED.
***
Configuring Basic WRED

Precedence Minimum Maximum
Threshold Threshold
0 10 25
1 12 25
2 14 25
3 16 25
If our WRED configuration matched the above table, packets with a precedence
of “0” would be randomly dropped once 10 packets were queued. Packets with
a precedence of “2” would similarly be dropped once 14 packets were queued.
The maximum queue size is 25, thus all new packets of any precedence would
be dropped once 25 packets were queued.
Configuration of basic WRED occurs on an interface. To configure WRED
when using IP Precedence:
Switch(config-if)# random-detect
Switch(config-if)# random-detect precedence 0 10 25
The first random-detect command enables WRED. The subsequent random-

detect commands apply a minimum and maximum threshold to each IP
precedence level.
To configure WRED when using DSCP:
Switch(config-if)# random-detect
Switch(config-if)# random-detect dscp-based af11 14 25
To view the WRED status and configuration on all interfaces:

Switch# show queuing random-detect
***
Configuring Advanced WRED

On higher-end Catalyst models, WRED can be handled on a per-queue basis,
and is configured in conjunction with a feature called Weighted Round
Robin (WRR).
Recall that switches prioritize outbound (egress) traffic in a process called
scheduling. Switch ports have standard and strict priority egress queues. If a
Catalyst switch has two standard egress queues, the first standard queue
(Queue 1) is treated as a low-priority queue, and the second standard queue
(Queue 2) is treated as a higher priority queue. The strict priority queue is
the highest priority of all, and will never have packets randomly dropped by
WRED.
Standard egress queues can be assigned weights, which dictate the
proportion of traffic sent across each queue.
On Catalyst Switches:
Switch(config-if)# wrr-queue bandwidth 127 255
The above command would be used if a particular port has two standard
egress queues (remember, the number of queues depends on the Catalyst
model). The two numbers are the weights for Queue 1 and Queue 2,
respectively. The weight is a number between 1 and 255, and serves as a
ratio for sending traffic.
In the above example, Queue 2 would be allowed to transmit twice as much
traffic as Queue 1 every “cycle” (255 is roughly twice that of 127). This
way, the higher-priority traffic should always be serviced first, and more
often.
Next, we can enable WRED on a particular queue. Is WRED enabled by
default? Cisco’s documentation on this is inconsistent. To enable WRED on
queue 1:
Switch(config-if)# wrr-queue random-detect 1
To disable WRED and revert to tail-drop congestion control:

Switch(config-if)# no wrr-queue random-detect 1
***
Configuring Advanced WRED (continued)

Next, we can tune the WRED minimum and maximum thresholds. Again,
this is accomplished per standard queue, and based on a percentage of
capacity of the queue.
Recall that each switch port has a specific set of queues (for example,
1p2q2t). The 2t indicates that we can have two WRED thresholds per
standard queue. Confused?
Switch(config-if)# wrr-queue random-detect min-threshold 1 5 10
Switch(config-if)# wrr-queue random-detect max-threshold 1 40 100
The first command sets two separate min-thresholds for Queue 1,

specifically 5 percent and 10 percent.
The second command sets two separate max-thresholds for Queue 1,
specifically 40 percent and 100 percent.
Why two separate minimum and maximum thresholds per queue? Because
we can map packets of a specific IP Precedence to a specific threshold of a
specific queue.
*evil grin*
Switch(config-if)# wrr-queue cos-map 1 1 0 1
Switch(config-if)# wrr-queue cos-map 1 2 2 3
The first command creates a map, associating queue 1, threshold 1 with

Precedence values of 0 and 1.
The second command creates a map, associating queue 1, threshold 2 with
Precedence values of 2 and 3.
Simple, right? All traffic marked with Precedence 0 or 1 will have a
minimum threshold of 5 percent, and a maximum threshold of 40 percent
(per our earlier commands). All traffic marked with Precedence 2 or 3 will
have a minimum threshold of 10 percent, and a maximum threshold of 100
percent.
The above wrr-queue commands are actually the default settings on Catalyst
switches.
***
Troubleshooting QoS
To view the QoS settings on an interface:
Switch# show mls qos interface fa0/10
To view the queuing information for an interface:

Switch# show mls qos interface fa0/10 queuing
To view QoS mapping configurations:

Switch# show mls qos maps
***
________________________________________________
Part V
Switch Security
________________________________________________
***
Section 17
- AAA -
AAA
Securing access to Cisco routers and switches is a critical concern. Often,
access is secured using enable and vty/console passwords, configured locally
on the device.
For large networks with many devices, this can become unmanageable,
especially when passwords need to be changed. A centralized form of access
security is required.
AAA is a security system based on Authentication, Authorization, and
Accounting.
Authentication is used to grant or deny access based on a user account and
password. Authorization determines what level of access that user has on
the Router/router when authenticated. Accounting can keep track of who
logged into what device, and for how long.
AAA must be enabled globally on a router/Router. By default, it is disabled.
Router(config)# aaa new-model
Privilege Levels
IOS devices have a total of 16 privilege levels, numbered 0 through 15.
User Exec mode is privilege level 1. Privileged Exec mode is privilege
level 15.
We can create a custom Privilege level, including the commands users are
allowed to input at that mode:
Router(config)# privilege exec all level 3 show interface
Router(config)# privilege exec all level 3 show ip route
Router(config)# privilege exec all level 3 show reload
To then enter that privilege level from User Mode:

Router> enable 3
***
Configuring Authentication
Authentication can be handled several different ways. We can use a
username and password configured locally on the router/Router:
Router(config)# username MYNAME password MYPASSWORD
Or we can point to a centralized RADIUS or TACACS+ server, which can

host the username/password database for all devices on the network:
Router(config)# radius-server host 172.16.10.150
Router(config)# radius-server key MYKEY
Router(config)# tacacs-server host 172.16.10.151 key MYKEY
Router(config)# tacacs-server key MYKEY
The above commands point to a host server. A measure of security is

maintained by using a shared key that must be configured both on the router
and the RADIUS/TACACS+ server.
We can also create groups of RADIUS or TACACS+ servers to point to:
Router(config)# aaa group server radius MYGROUP
Router(config-sg-radius)# server 172.16.10.150
There are several key differences between RADIUS and TACACS+ servers:
• RADIUS is an industry standard protocol, while TACACS+ is Cisco
proprietary
• RADIUS utilizes UDP, while TACACS+ utilizes TCP
• RADIUS encrypts only the password during the authentication
process, while TACACS+ encrypts the entire packet
There is one additional key difference: TACACS+ allows for the
authorization of a user, in addition to the authentication of a user. Thus,
TACACS+ allows us to control what commands a particular user can input.
RADIUS provides only authentication services.
***
Configuring Login Authentication

On the previous page, we directed our router to a specific RADIUS or
TACACS server. Next, we must specify which methods of authentication we
want our router to consider when a user logs in. We can actually configure
the router to use multiple forms of authentication (up to four):
Router(config)# aaa authentication login default radius tacacs+ local
The above command creates an authentication profile for router login named
default, directing the router to use the RADIUS server(s), TACACS+
server(s), and local forms of authentication, in that order.
Thus, the RADIUS server(s) will always be used, unless they fail. Then the
TACACS+ server will be used and then finally local authentication. This
provides fault-tolerance and automatic failover.
You should always include local at the end of this command. Otherwise, if
all RADIUS and TACACS+ servers are down, you won’t be able to log into
the router.
Multiple authentication profiles can be created. Each must have a unique
profile name. Obviously, default is the default profile name. If we wanted a
separate profile named ONLYLOCAL:
Router(config)# aaa authentication login ONLYLOCAL local
The last step in configuring authentication is to apply the profile to a “line,”

such as the console or telnet ports.
Router(config)# line vty 0 15
Router(config-line)# login authentication default
Notice we referenced the authentication profile’s name of default.
***
Configuring PPP Authentication

The previous page illustrates the use of AAA Authentication to control user
login to routers and switches. Additionally, we can use AAA to authenticate
both ends of a PPP connection.
Point-to-Point Protocol (PPP) is a standardized WAN encapsulation protocol
that can be used on a wide variety of WAN technologies, including:
• Serial dedicated point-to-point lines
• Asynchronous dial-up (essentially dialup)
• ISDN
To specify the authentication methods for PPP:
Router(config)# aaa authentication ppp MYPROFILE radius local
Notice the new keyword of ppp, as opposed to login. Once we have

specified the desired authentication methods, we must apply this profile to
the appropriate interface:
Router(config)# interface serial 0
Router(config-if)# encapsulation ppp
Router(config-if)# ppp authentication pap MYPROFILE
Or:
Router(config)# interface serial 0
Router(config-if)# encapsulation ppp
Router(config-if)# ppp authentication chap MYPROFILE
Notice that the top example uses PAP (Password Authentication Protocol),
while the bottom example uses CHAP Challenge Handshake Authentication
Protocol. PAP sends the password in clear text, whereas CHAP encrypts the
password with an MD5 hash. Thus, CHAP is far more secure.
***
Configuring Authorization
Authorization allows us to dictate what rights a user has to the router once
they have logged in:
Router(config)# aaa authorization commands default radius
Router(config)# aaa authorization config-commands default radius
Router(config)# aaa authorization exec default radius
Router(config)# aaa authorization network default radius
Router(config)# aaa authorization reverse-access default radius
The Router will consult the RADIUS server to “authorize” access to specific
privilege modes (or in the case of TACACS+, even specific commands). A
user trying to access Global Configuration mode must be authorized to do so
on the RADIUS server.
Explanations of the above “sections” we can authorize:
• commands – access to any Router command at any mode
• config-commands – access to any Router configuration command
• exec – access to privileged mode
• network – access to network-related commands
• reverse-access – ability to reverse telnet from the Router
We can then apply this authorization to a line:
Router(config-line)# authorization default
***
Configuring Accounting
We can configure accounting to log access to routers and switches:
Router(config)# aaa accounting system default stop-only
Router(config)# aaa accounting exec default start-stop
Router(config)# aaa accounting commands 3 default start-stop
Router(config)# aaa accounting commands 15 default start-stop
We can configure accounting on three separate functions:

• System – records system-level events, such as reloads
• Exec – records user authentication events, including duration of the
session
• Commands (1-15) – records every command typed in at that privilege
level. In our above example, we’re logging our custom Privilege
Level 3
We can then specify when these functions should be recorded:
• Start-stop – recorded when the event starts and stop
• Stop-only – recorded only when the event stops
Finally, we must apply this to a line:
Router(config-line)# accounting default
Troubleshooting AAA
To debug the various functions of AAA:
Router# debug aaa authentication
Router# debug aaa authorization
Router# debug aaa accounting
Router# debug radius
Router# debug tacacs
***
Section 18
- Switch Port and VLAN Security -
Switch Port Security
Port Security adds an additional layer of security to the switching network.
Generally, the MAC address of a host does not change. If we are certain that
a specific host will always remain plugged into a specific port, we can filter
all MAC addresses but that host’s address. We can either statically set this
MAC address, of have the switch dynamically learn it from traffic.
To enable Port Security:
Switch(config-if)# switchport port-security
By default, Port Security will allow only one MAC on a port. We can adjust
the maximum number of MACs, up to 1024:
Switch(config-if)# switchport port-security maximum 2
If we want to statically specify the allowed MAC address(es) on a port:

Switch(config-if)# switchport port-security mac-address 0001.1111.2222
Switch(config-if)# switchport port-security mac-address 0001.3333.5555
Only those MACs will be able to send traffic through this port. If we had
specified a maximum of 10 MAC address for this port, and manually
specified only two, the remaining 8 MACs would be dynamically learned.
Finally we must tell the switch how to react if an unauthorized MAC address
tries to send traffic through this port:
Switch(config-if)# switchport port-security violation shutdown
Switch(config-if)# switchport port-security violation restrict
Switch(config-if)# switchport port-security violation protect
• Shutdown – the port is placed in an errdisable state (default)

• Restrict – the port stays online, dropping only the unauthorized traffic
and logging the violations
• Protect – same as restrict, but without logging
Port security cannot be enabled on trunk ports, dynamic access ports,
Etherchannel ports, or a SPAN destination port.
***
VLAN Access Lists

Normally, access lists are used to filter traffic between networks (or
VLANs). VLAN Access Lists allow us to filter traffic within a VLAN, with
granular precision.
For example, we can block all traffic from a single host (or group of hosts)
from reaching any other hosts, within the same VLAN:
Switch(config)# ip access-list extended BLOCKTHISIP
Switch(config-ext-nacl)# permit ip host 10.1.5.10 10.1.0.0 0.0.255.255
Switch(config)# vlan access-map MYVLANACL 5

Switch(config-access-map)# match ip address BLOCKTHISIP
Switch(config-access-map)# action drop
Switch(config-access-map)# vlan access-map MYVLANACL 10
Switch(config-access-map)# action forward
Switch(config)# vlan filter MYVLANACL vlan-list 102
The first line creates an extended named access-list called BLOCKTHISIP.

This contains a single entry, permiting host 10.1.5.10 to reach any other
device on the 10.1.0.0 network.
Wait a second, didn’t we want to block this address? In this instance, we are
not using the access list to BLOCK traffic, but merely IDENTIFY this
traffic. Thus, think of permit being more like true, and deny more like false.
The next line creates a vlan access-map (or, VLAN access list) named
MYVLANACL. Then, we match the IP address(es) listed in the
BLOCKTHISIP access list, and apply an action of drop.
Our final vlan access-map entry contains only an action to forward. Since no
specific IP or access list was mentioned, this indicates all traffic. Thus, the
final result of the above configuration would be to block all traffic from
10.1.5.10 to another device on the VLAN, while allowing all other traffic.
Notice after every access-map statement there is a sequence number (in our
example, 5 and 10). This details the order in which these rules should be
followed.
***

Cisco CCNP Switching Study Guide: V1.21 - Aaron Balchunas

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

Cisco CCNP Switching Study Guide: V1.21 - Aaron Balchunas

Uploaded by

Copyright:

Available Formats

CCNP Switching Study Guide v1.

Cisco CCNP Switching Study Guide

This study guide is intended to provide those pursuing the CCNP

Part II – Switch Configuration

Part III – Switching Protocols and Functions

Part IV– Advanced Switch Services

Part V – Switch Security

Half-Duplex vs. Full-Duplex

Ethernet (10 Mbps)

The first incarnation of Ethernet operated at 10 Mbps, over thinnet

Full Duplex Ethernet allows devices to both send and receive

Fast Ethernet, or IEEE 802.3u, operates at 100 Mbps, utilizing Category 5

As mentioned earlier, it is also possible to statically configure this

Types of Twisted-Pair Cables

1 White Orange ------------------------ White Green 3

Types of Twisted-Pair Cables (continued)

Finally, a roll-over cable is used to connect a PC into a Cisco router’s

1 White Orange ------------------------ Brown 8

Layer PDU Name

Consider the above diagram. We’ll assume that Computer A is attached to

Layer 2 Switching (continued)

Layer 2 Switching Methods

Collision vs. Broadcast Domain Example

If Computer A sends a packet to Computer B, the Layer 3 switch will add

The Cisco Hierarchical Network Model

Example of the Cisco Hierarchical Network Model

Server Farm Distribution Distribution

Core MultiLayer Core MultiLayer

Access Workgroup Access Workgroup Access Workgroup Access Workgroup

“User” Switch Block “User” Switch Block

Cisco Switching Products

Access Layer Switches:

Catalyst 2950 48 “10/100” ports 13.6 Gpbs

Distribution and Core Layer Switches:

Catalyst 3550 (EMI) 48 “10/100” ports or 24 Gpbs

Content Addressable Memory (CAM)

Destination Address Address Type VLAN Destination Port

Configuring the CAM

To statically add to the CAM a MAC address of 0011.2233.4455, which

To view all dynamic MAC entries in the CAM:

To view a specific dynamic address in the CAM:

To view the number of MAC addresses per VLAN:

To clear the entire dynamic contents of the CAM:

To clear a single entry of the CAM:

Ternary Content Addressable Memory (TCAM)

Using Lines to Configure the IOS

IOS Modes on Cisco Catalyst Switches

No configuration can be changed or viewed from User mode. Only basic

To enter Privileged mode, type enable from User mode:

To return back to User mode from Privileged mode, type disable:

Very little configuration can be changed directly from Privileged mode.

To enter Global Configuration mode, type configure terminal from

To return back to Privileged mode, type exit:

IOS Modes on Cisco Catalyst Switches (continued)

Recall the difference between interfaces and lines. Interfaces connect

Multiple telnet lines can be configured simultaneously. To configure the first

Notice that Catalyst switches natively support up to 16 VTY connections. A

The enable password command sets an unencrypted password intended for

Line Passwords and Configuration

Switch(config-line)# exec-timeout 0 0 Switch(config-line)# exec-timeout 0 0

The exec-timeout 0 0 command is optional, and disables the automatic

The logging synchronous command is also optional, and prevents system