Switch SG

SWITCH
Implementing Cisco
IP Switched
Networks
Copyright Notices
Americas Headquarters Asia Pacific Headquarters Europe Headquarters

Cisco Systems, Inc. Cisco Systems (USA) Pte. Ltd. Cisco Systems International BV
San Jose, CA Singapore Amsterdam,
The Netherlands
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at
www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To
view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third party trademarks mentioned are the
property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any
other company. (1110R)
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO
WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN
ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY
DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND
FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.
This learning product may contain early release content, and while Cisco believes it to be accurate, it falls subject to the disclaimer
above.
Welcome Students
Students, this letter describes important course evaluation access information!
Welcome to Cisco Systems Learning. Through the Cisco Learning Partner Program, Cisco is
committed to bringing you the highest-quality training in the industry. Cisco learning products are
designed to advance your professional goals and give you the expertise that you need to build
and maintain strategic networks.
Cisco relies on customer feedback to guide business decisions. Therefore, your valuable input will
help shape future Cisco course curricula, products, and training offerings. Please complete a brief
Cisco online course evaluation of your instructor and the course materials in this student kit. On
the final day of class, your instructor will provide you with a URL, directing you to a short post-
course evaluation. If there is no Internet access in the classroom, please complete the evaluation
within the next 48 hours or as soon as you can access the web.
On behalf of Cisco, thank you for choosing Cisco Learning Partners for your Internet technology
training.
Sincerely,
Cisco Systems Learning
© 2014 Cisco Systems, Inc.

Table of Contents
Course Introduction ....................................................................................................................I
Overview ................................................................................................................................ I
Course Goal and Objectives ...................................................................................................... II
Course Flow ...........................................................................................................................III
Your Training Curriculum ....................................................................................................... IV
General Administration ............................................................................................................V
Module 1: Basic Concepts and Network Design......................................................................... 7
Lesson 1: Analyzing Campus Network Structure ............................................................................. 8
Hierarchical Network Design .................................................................................................... 9
Layers in the Hierarchical Model ............................................................................................. 10
Building Cisco Enterprise Campus Architecture ......................................................................... 11
Access Layer ........................................................................................................................ 13
Distribution Layer ................................................................................................................. 14
Core Layer ........................................................................................................................... 15
Is a Core Layer Needed?......................................................................................................... 16
Types of Cisco Switches ......................................................................................................... 18
Routed vs. Switched Campus Architecture ................................................................................ 19
Summary.............................................................................................................................. 20
Lesson 2: Comparing Layer 2 and Multilayer Switches ................................................................... 21
Layer 2 Switch Operation ....................................................................................................... 22
Multilayer Switch Operation ................................................................................................... 24
Frame Rewrite ...................................................................................................................... 26
CAM and TCAM .................................................................................................................. 27
Discovery 1: Investigating the CAM......................................................................................... 28
Distributed Hardware Forwarding ............................................................................................ 34
Cisco Switching Methods ....................................................................................................... 35
Route Caching ...................................................................................................................... 37
Topology-Based Switching ..................................................................................................... 38
Summary.............................................................................................................................. 40
Lesson 3: Using Cisco SDM Templates ........................................................................................ 41
What Are SDM Templates? .................................................................................................... 42
SDM Template Types ............................................................................................................ 43
Changing the SDM Template .................................................................................................. 44
Choosing the Correct Template................................................................................................ 46
Summary.............................................................................................................................. 47
Lesson 4: Implementing LLDP.................................................................................................... 49
LLDP Introduction ................................................................................................................ 50
Enabling LLDP ..................................................................................................................... 51
Discovering Neighbors Using LLDP ........................................................................................ 52
Summary.............................................................................................................................. 54
Lesson 5: Implementing PoE ...................................................................................................... 55
The Need for PoE .................................................................................................................. 56
PoE Components ................................................................................................................... 58
PoE Standards....................................................................................................................... 59
PoE Negotiation .................................................................................................................... 60
Configuring and Verifying PoE ............................................................................................... 61
Summary.............................................................................................................................. 62
© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH i

Lesson 6: Module Summary ....................................................................................................... 63
Lesson 7: Module Self-Check..................................................................................................... 65
Module Self-Check Answers ...................................................................................................... 69
Answer Key ......................................................................................................................... 69
Module 2: Campus Network Architecture ............................................................................... 71
Lesson 1: Implementing VLANs and Trunks................................................................................. 72
Discovery 2: Configuring VLANs and Trunks ........................................................................... 73
The Native VLAN ................................................................................................................. 84
Switchport Mode Interactions.................................................................................................. 85
Deploying VLANs ................................................................................................................ 87
End-to-End vs. Local VLANs ................................................................................................. 89
Voice VLAN Overview.......................................................................................................... 91
Voice VLAN Configuration .................................................................................................... 93
Switch Configuration for Wireless Network Support................................................................... 94
Summary ............................................................................................................................. 95
Lesson 2: Introducing VTP......................................................................................................... 97
The Role of VLAN Trunking Protocol...................................................................................... 98
VTP Modes .......................................................................................................................... 99
Discovery 3: VTP Operation ................................................................................................. 101
VTP Versions ..................................................................................................................... 112
Default VTP Configuration................................................................................................... 114
Overwriting VTP Configuration ............................................................................................ 115
VTP Configuration Recommendation ..................................................................................... 124
Summary ........................................................................................................................... 125
Lesson 3: Implementing DHCP................................................................................................. 127
DHCP Overview ................................................................................................................. 128
Discovery 4: Exploring DHCP .............................................................................................. 129
DHCP Relay....................................................................................................................... 137
DHCP Options.................................................................................................................... 138
Summary ........................................................................................................................... 139
Lesson 4: Implementing DHCP for IPv6 .................................................................................... 141
Stateless Autoconfiguration Overview .................................................................................... 142
DHCPv6 Overview.............................................................................................................. 144
DHCPv6 Operation ............................................................................................................. 145
DHCPv6 Lite Overview ....................................................................................................... 147
Discovery 5: Obtaining IPv6 Address Dynamically .................................................................. 148
DHCPv6 Relay Agent .......................................................................................................... 155
Summary ........................................................................................................................... 156
Lesson 5: Configuring Layer 2 Port Aggregation ......................................................................... 157
The Need for EtherChannel................................................................................................... 158
Etherchannel Mode Interactions............................................................................................. 161
Layer 2 EtherChannel Configuration Guidelines ...................................................................... 163
Discovery 6: EtherChannel Configuration and Load Balancing................................................... 165
Etherchannel Load-Balancing Options.................................................................................... 174
Etherchannel Load-Balancing Operation ................................................................................. 176
EtherChannel Guard ............................................................................................................ 177
Summary ........................................................................................................................... 178
Lesson 6: Module Summary ..................................................................................................... 179
Lesson 7: Module Self-Check................................................................................................... 181
Module Self-Check Answers .................................................................................................... 186
Answer Key ....................................................................................................................... 186
ii Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Module 3: Spanning Tree Implementation ............................................................................189
Lesson 1: Implementing RSTP.................................................................................................. 190
STP Overview..................................................................................................................... 192
STP Standards..................................................................................................................... 193
STP Operation .................................................................................................................... 195
Bridge Protocol Data Unit..................................................................................................... 197
Root Bridge Election............................................................................................................ 198
Root Port Election ............................................................................................................... 200
Designated Port Election....................................................................................................... 202
STP Port States ................................................................................................................... 203
Per-VLAN STP................................................................................................................... 204
Discovery 7: Discovering and Modifying STP Behavior ............................................................ 206
RSTP Port Roles ................................................................................................................. 219
Comparison of RSTP and STP Port States ............................................................................... 221
STP Topology Changes ........................................................................................................ 222
RSTP Topology Changes...................................................................................................... 224
RSTP Link Types ................................................................................................................ 226
Summary............................................................................................................................ 228
Lesson 2: Implementing STP Stability Mechanisms ..................................................................... 229
Cisco STP Toolkit ............................................................................................................... 231
UplinkFast.......................................................................................................................... 232
BackboneFast ..................................................................................................................... 234
PortFast ............................................................................................................................. 236
Securing PortFast Interface with BPDUGuard.......................................................................... 239
Disabling STP with BPDUFilter ............................................................................................ 241
Discovery 8: RootGuard ....................................................................................................... 244
The Problem with Unidirectional Links................................................................................... 254
LoopGuard Overview........................................................................................................... 256
LoopGuard Configuration ..................................................................................................... 258
LoopGuard Verification........................................................................................................ 260
UDLD Overview ................................................................................................................. 261
UDLD Configuration ........................................................................................................... 263
Comparing LoopGuard with UDLD ....................................................................................... 264
UDLD Recommended Practices............................................................................................. 265
STP Stability Mechanisms Recommendations .......................................................................... 266
FlexLinks ........................................................................................................................... 268
Summary............................................................................................................................ 271
Lesson 3: Implementing Multiple Spanning Tree Protocol............................................................. 273
Introducing Multiple Spanning Tree Protocol........................................................................... 274
MST Regions...................................................................................................................... 276
STP Instances with MST ...................................................................................................... 278
Extended System ID for MST................................................................................................ 281
Discovery 9: Configuring MST.............................................................................................. 282
Configuring MST Path Cost .................................................................................................. 289
Configuring MST Port Priority .............................................................................................. 290
MST Protocol Migration....................................................................................................... 291
MST Recommended Practice ................................................................................................ 293
Summary............................................................................................................................ 295
Lesson 5: Module Self-Check ................................................................................................... 299
Answer Key........................................................................................................................ 303
© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH iii
Module 4: Configuring Inter-VLAN Routing ........................................................................ 305
Lesson 1: Implementing Inter-VLAN Routing Using a Router ....................................................... 306
Inter-VLAN Routing Using an External Router Overview ......................................................... 307
Discovery 10: Routing with an External Router........................................................................ 308
External Router: Advantages and Disadvantages ...................................................................... 313
Summary ........................................................................................................................... 315
Lesson 2: Configuring a Switch to Route.................................................................................... 317
Switch Virtual Interfaces Overview........................................................................................ 318
Switch Routed Ports Overview .............................................................................................. 320
Discovery 11: Routing on a Multilayer Switch......................................................................... 321
SVI autostate exclude .......................................................................................................... 327
SVI Configuration Checklist ................................................................................................. 329
Layer 2 vs. Layer 3 EtherChannel .......................................................................................... 331
Layer 3 EtherChannel Configuration ...................................................................................... 332
Summary ........................................................................................................................... 334
Answer Key ....................................................................................................................... 340
Module 5: Implementing High Availability Networks ........................................................... 341
Lesson 1: Configuring Network Time Protocol............................................................................ 342
The Need for Accurate Time ................................................................................................. 343
Configuring System Clock Manually...................................................................................... 344
Network Time Protocol Overview.......................................................................................... 347
NTP Modes ........................................................................................................................ 349
Discovery 12: NTP Configuration.......................................................................................... 351
Securing NTP ..................................................................................................................... 360
NTP Source Address............................................................................................................ 363
NTP Versions ..................................................................................................................... 364
NTP in IPv6 Environment .................................................................................................... 365
SNTP Overview .................................................................................................................. 367
SNTP Configuration ............................................................................................................ 368
Summary ........................................................................................................................... 369
Lesson 2: Implementing SNMP Version 3 .................................................................................. 371
SNMP Overview ................................................................................................................. 372
SNMP Versions .................................................................................................................. 373
SNMP Recommendations ..................................................................................................... 375
SNMP Version 3 Configuration............................................................................................. 376
Verifying SNMP Version 3 Configuration............................................................................... 378
Summary ........................................................................................................................... 381
Lesson 3: Implementing IP SLA ............................................................................................... 383
IP SLA Introduction ............................................................................................................ 384
IP SLA Source and Responder .............................................................................................. 387
Discovery 13: IP SLA Echo Configuration .............................................................................. 388
IP SLA Operation with Responder ......................................................................................... 393
IP SLA Responder Time Stamps............................................................................................ 395
Configuring Authentication for IP SLA .................................................................................. 396
Configuration Example: UDP Jitter........................................................................................ 397
Summary ........................................................................................................................... 398
Lesson 4: Implementing Port Mirroring for Monitoring Support..................................................... 399
What is SPAN? ................................................................................................................... 400
SPAN Terminology ............................................................................................................. 401
Remote SPAN .................................................................................................................... 402
iv Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Local SPAN Configuration ................................................................................................... 403
Verifying Local SPAN Configuration ..................................................................................... 404
Remote SPAN Configuration ................................................................................................ 405
Verifying Remote SPAN Configuration .................................................................................. 407
Summary............................................................................................................................ 409
Lesson 5: Verifying Switch Virtualization................................................................................... 411
The Need for Logical Switching Architectures ......................................................................... 412
What is StackWise? ............................................................................................................. 413
StackWise Benefits .............................................................................................................. 415
Verifying StackWise ............................................................................................................ 416
Redundant Switch Supervisors .............................................................................................. 417
Supervisor Redundancy Modes.............................................................................................. 418
What is VSS?...................................................................................................................... 419
VSS Benefits ...................................................................................................................... 420
Verifying VSS .................................................................................................................... 421
Summary............................................................................................................................ 423
Answer Key........................................................................................................................ 432
Module 6: First Hop Redundancy Implementation ............................................................... 435
Lesson 1: Configuring Layer 3 Redundancy with HSRP................................................................ 436
The Need for First Hop Redundancy....................................................................................... 437
The Idea Behind First Hop Redundancy Process....................................................................... 438
Discovery 14: Configuring and Tuning HSRP.......................................................................... 440
HSRP State Transition.......................................................................................................... 449
HSRP and STP.................................................................................................................... 451
Load Sharing With HSRP ..................................................................................................... 452
The Need For Interface Tracking With HSRP .......................................................................... 455
HSRP Interface Tracking ...................................................................................................... 456
HSRP and Object Tracking ................................................................................................... 459
HSRP Authentication ........................................................................................................... 463
HSRP Timers...................................................................................................................... 465
HSRP Versions ................................................................................................................... 467
Summary............................................................................................................................ 468
Lesson 2: Configuring Layer 3 Redundancy with VRRP ............................................................... 469
About VRRP ...................................................................................................................... 470
Discovery 15: Configure VRRP and Spot the Differences from HSRP ......................................... 472
Tracking and VRRP ............................................................................................................. 478
VRRP Interface Tracking Configuration ................................................................................. 479
Summary............................................................................................................................ 481
Lesson 3: Configuring Layer 3 Redundancy with GLBP ............................................................... 483
Introducing GLBP ............................................................................................................... 484
GLBP vs. HSRP.................................................................................................................. 486
GLBP States ....................................................................................................................... 487
Discovery 16: Configure GLBP ............................................................................................. 488
GLBP Load Balancing Options.............................................................................................. 500
GLBP Authentication ........................................................................................................... 501
GLBP and STP ................................................................................................................... 502
Tracking and GLBP ............................................................................................................. 503
Summary............................................................................................................................ 507
Lesson 4: Configuring First Hop Redundancy for IPv6 ................................................................. 509
IPv6 Native First Hop Redundancy ........................................................................................ 510
© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH v

Why FHRP in IPv6? ............................................................................................................ 511
HSRP for IPv6.................................................................................................................... 512
GLBP for IPv6.................................................................................................................... 513
Summary ........................................................................................................................... 514
Answer Key ....................................................................................................................... 522
Module 7: Campus Network Security .................................................................................... 523
Lesson 1: Implementing Port Security........................................................................................ 524
Overview of Switch Security Issues ....................................................................................... 525
Switch Security Recommended Practices ................................................................................ 527
Unauthorized Access by Rogue Devices ................................................................................. 530
Switch Attack Categories ..................................................................................................... 531
MAC Flooding Attack ......................................................................................................... 533
Introducing Port Security...................................................................................................... 534
Discovery 17: Port Security .................................................................................................. 536
Port Error Conditions ........................................................................................................... 544
Error Disabled Port Automatic Recovery ................................................................................ 546
Port Access Lists ................................................................................................................. 547
Configure Port Access Lists .................................................................................................. 548
Summary ........................................................................................................................... 550
Lesson 2: Implementing Storm Control ...................................................................................... 551
Storm Control..................................................................................................................... 552
Configuring Storm Control On An Interface ............................................................................ 554
Verifying Storm Control Behavior ......................................................................................... 556
Summary ........................................................................................................................... 558
Lesson 3: Implementing Access to External Authentication ........................................................... 559
AAA Framework Overview .................................................................................................. 561
The Benefits of AAA Usage ................................................................................................. 562
Authentication Options ........................................................................................................ 563
RADIUS and TACACS+ Overview ....................................................................................... 565
Enabling AAA and Configuring Local User for Fall-back.......................................................... 569
Configuring RADIUS for Console and VTY Access ................................................................. 570
Configuring TACACS+ for Console and VTY Access .............................................................. 572
Configuring Authorization and Accounting ............................................................................. 574
Limitations of TACACS+ and RADIUS ................................................................................. 575
Identity-Based Networking ................................................................................................... 576
IEEE 802.1x Port-Based Authentication Overview ................................................................... 577
IEEE 802.1x Configuration Checklist ..................................................................................... 579
Summary ........................................................................................................................... 580
Lesson 4: Mitigating Spoofing Attacks....................................................................................... 581
DHCP Spoofing Attacks....................................................................................................... 582
DHCP Snooping ................................................................................................................. 583
DHCP Snooping Configuration ............................................................................................. 584
IP Source Guard.................................................................................................................. 587
IP Source Guard Configuration.............................................................................................. 589
ARP Spoofing .................................................................................................................... 590
Dynamic ARP Inspection ..................................................................................................... 592
DAI Configuration .............................................................................................................. 594
Summary ........................................................................................................................... 596
Lesson 5: Securing VLAN Trunks ............................................................................................. 597
Switch Spoofing.................................................................................................................. 598
vi Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Protecting Against Switch Spoofing ....................................................................................... 599
VLAN Hopping .................................................................................................................. 600
Protecting Against VLAN Hopping ........................................................................................ 601
VLAN Access Lists ............................................................................................................. 603
VACL interaction with ACL and PACL .................................................................................. 604
Configuring VACLs............................................................................................................. 605
Summary............................................................................................................................ 606
Lesson 6: Configuring Private VLANs ....................................................................................... 607
The Need for Private VLANs ................................................................................................ 608
Private VLAN Introduction ................................................................................................... 609
Private VLAN Port Types ..................................................................................................... 610
Private VLAN Configuration................................................................................................. 612
Private VLAN Verification ................................................................................................... 614
Private VLANs Across Multiple Switches ............................................................................... 615
Protected Port Feature .......................................................................................................... 617
Summary............................................................................................................................ 618
Glossary..................................................................................................................................624
© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH vii
viii Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.
Course Introduction
Overview
Implementing Cisco Switched Networks (SWITCH) v2.0 is an instructor-led training course presented by
Cisco training partners to their end customers. This five-day course is designed to help students prepare for
Cisco CCNP R&S® certification. This course is one of the three courses in the CCNP Routing and
Switching curriculum.
Learner Skills and Knowledge
© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 1

Course Goal and Objectives
Upon completing this course, you will be able to meet these objectives:
1 Describe the hierarchical campus structure, basic switch operation, use of SDM templates, PoE, and
LLDP
2 Implement VLANs, trunks, explain VTP, implement DHCP in IPv4 and IPv6 environment, and
configure port aggregation
3 Implement and optimize STP mechanism that best suits your network - PVSTP+, RPVSTP+, or MST
4 Configure routing on a multilayer switch
5 Configure NTP, SNMP, IP SLA, port mirroring, and verify StackWise and VSS operation
6 Implement First Hop redundancy in IPv4 and IPv6 environments
7 Secure campus network according to recommended practices
This training reinforces the instruction by providing students with hands-on labs to ensure they thoroughly
understand how to implement advanced routing within their networks.
2 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Course Flow
The schedule reflects the approximate structure for this course. This structure allows enough time for the
instructor to present the course information and for you to work through the lab activities. The exact timing
of the subject materials and labs depends on the pace of your specific class.

Your Training Curriculum
Cisco provides three levels of general certifications for IT professionals with several different tracks to meet
individual needs. There are many paths to Cisco certification, but only one requirement—passing one or
more exams demonstrating knowledge and skill. For details, go to
http://www.cisco.com/web/learning/certifications.
You are encouraged to join The Cisco Learning Network, a discussion forum open to anyone holding a
valid Cisco Career Certification. It provides a gathering place for Cisco certified professionals to share
questions, suggestions, and information about Cisco Career Certification programs and other certification-
related topics. For more information, visit https://learningnetwork.cisco.com.

General Administration
The instructor will discuss the following administrative issues so that you know exactly what to expect from
the class:
• Sign-in process
• Start and anticipated end times of each class day
• Class break and lunch facilities
• Appropriate attire during class
• Materials you can expect to receive during class
• What to do in the event of an emergency
• Location of the restrooms
• How to send and receive telephone and fax messages
Student Introductions

Module 1: Basic Concepts
and Network Design
Introduction
Your company should have a scalable and flexible network, and you can achieve that by having a
hierarchical, layered design.
Today, switches are not only Layer 2 devices, a lot of them are capable of performing Layer 3 features.
In some Cisco switches, you can reallocate system resources in order for the switch to optimize support for
specific features. This reallocation is done through changing of the SDM template. For example, if you want
to implement IPv6 addressing on an access layer switch, you will need to change the SDM template.
Cisco Discovery Protocol is a great tool to perform network discovery, but it is a Cisco proprietary solution.
LLDP is a standard alternative to Cisco Discovery Protocol.
PoE is a LAN technology that allows you to supply devices, like IP phones and wireless APs, with power
over an Ethernet cable. Supplying the device with power over the same cable as data eliminates the need for
a power adapter, lowers the cost of implementation, provides easier maintenance, and provides greater
installation flexibility than with traditional wiring.
Upon completing this module, you will be able to meet these objectives:
• Describe the components of a well-designed campus network
• Explain the difference between Layer 2 and multilayer switch operation
• Change and verify the SDM template
• Enable LLDP and verify LLDP neighbors
• Describe PoE and verify power consumption on a switch

Lesson 1: Analyzing Campus
Network Structure
Overview
The enterprise campus is the portion of the computing infrastructure that provides access to network
communication services and resources to end-devices that are situated at a particular geographic location. It
might span a single floor, building, or even a large group of buildings that are spread over a wider
geographic area.
Designing a campus network is no different from designing any large, complex system—such as a piece of
software or even something as sophisticated as a space shuttle. The use of a guiding set of fundamental
engineering principles serves to ensure that the campus design provides for the balance of availability,
security, flexibility, and manageability. These are the requirements to meet current and future business and
technological needs.
Upon completing this lesson, you will be able to meet these objectives:
• Explain the need for a hierarchical network design
• List and describe the three layers of the Cisco Enterprise Campus Architecture
• Describe how enterprise campus architecture applies to building scale
• Describe the access layer
• Describe the distribution layer
• Describe core layer
• Explain why and when the core layer is needed
• Describe types of Cisco switches
• Compare Layer 2 switching to Layer 3 switching in the access layer

Hierarchical Network Design
A flat enterprise campus network is where all PCs, servers, and printers are connected to each other using
Layer 2 switches. A flat network does not have subnets. All devices on this subnet will share available
bandwidth and all are members of the same broadcast domain. A broadcast packet uses CPU time on each
device within the broadcast domain. A network of 10 devices on the same segment does not seem crowded,
but if you have hundreds of hosts on the same subnet, your network will not perform well.
You can use a Layer 3 device such as a router or a Layer 3 switch to segment a network. Broadcasts that
originate within a subnet will not propagate beyond the edge of the LAN segment—the Layer 3 device.
How do you know if your network has a good design?

• You can double the network size without major design changes.
• You can add components to the network by only making changes on directly connected devices.
• You already know how to add a new WAN link, floor, building, branch, and so on.

Layers in the Hierarchical Model
Hierarchical models for internetwork design allow you to design internetworks in layers. To understand the
importance of layering, consider the OSI reference model, which is a layered model for understanding and
implementing computer communications. By using layers, the OSI model simplifies the task that is required
for two computers to communicate. The Cisco Enterprise Campus Architecture model also uses layers to
simplify the task that is required for internetworking.
Each layer can be focused on specific functions, thus allowing you to choose the right systems and features
for the layer. This model provides you modular framework that allows flexibility in network design and
facilitates implementation and troubleshooting. The enterprise campus divides networks or their modular
blocks into the access, distribution, and core layers with these features:
• Access layer: The access layer is used to grant user access to network devices. In a network campus,
the access layer generally incorporates switched LAN devices with ports that provide connectivity to
workstations and servers. In the WAN environment, the access layer for teleworkers or remote sites
may provide access to the corporate network across WAN technology.
• Distribution layer: The distribution layer aggregates the wiring closets, using switches to segment
workgroups and isolate network problems in a campus environment. Similarly, the distribution layer
aggregates WAN connections at the edge of the campus and provides policy-based connectivity.
• Core layer (also referred to as the backbone): The core layer is a high-speed backbone, which is
designed to switch packets as fast as possible. Because the core is critical for connectivity, it must
provide a high level of availability and adapt to changes very quickly. It also provides scalability and
fast convergence.

Building Cisco Enterprise Campus Architecture
You can apply the Cisco Enterprise Campus Architecture at the campus scale, or at the building scale, to
allow flexibility in network design and to facilitate ease of implementation and troubleshooting.
When the Cisco Enterprise Campus Architecture is applied to a building, the architecture naturally divides
networks into the building access, building distribution, and building core layers, as follows:
• Building access layer: The building access layer is used to grant user access to network devices. In a
network campus, the building access layer generally incorporates switched LAN devices with ports that
provide connectivity to workstations and servers. In the WAN environment, the building access layer at
remote sites may provide access to the corporate network across WAN technology.
• Building distribution layer: The building distribution layer aggregates the wiring closets and uses
switches to segment workgroups and isolate network problems.
• Building core layer: The building core layer (also known as the campus backbone submodule) is a
high-speed backbone and is designed to switch packets as fast as possible. Because the core is critical
for connectivity, it must provide a high level of availability and adapt to changes very quickly.
The Cisco Enterprise Campus Architecture divides the enterprise network into physical, logical, and
functional areas. These areas allow network designers and engineers to associate specific network
functionality on equipment that is based upon its placement and function in the model.
It is important to note that while the tiers do have specific roles in the design, there are no absolute rules for
how a campus network is physically built. While it is true that many campus networks are constructed using
three physical tiers of switches, this is not a strict requirement. In a smaller campus, the network might have
two tiers of switches in which the core and distribution elements are combined in one physical switch, a
collapsed distribution and core. On the other hand, a network may have four or more physical tiers of
switches because the scale, wiring plant, or physical geography of the network might require that the core be
extended. The important point is this: While the hierarchy of the network often defines the physical

topology of the switches, they are not the same thing. The key principle of the hierarchical design is that
each element in the hierarchy has a specific set of functions and services that it offers and a specific role to
play in the design.

Access Layer
The access layer aggregates end users and provides uplinks to the distribution layer.
The access layer is the place where end devices (PCs, printers, cameras, and the like) attach to the wired
portion of the campus network. It is also the place where devices that extend the network out one more level
are attached—IP phones and wireless APs being the two prime examples of devices that extend the
connectivity out one more layer from the actual campus access switch. The wide variety of possible types of
devices that can connect and the various services and dynamic configuration mechanisms that are necessary
make the access layer one of the most feature-rich parts of the campus network:
• High availability: The access layer is supported by many hardware and software attributes. It offers
access to default gateway redundancy using dual connections from access switches to redundant
distribution layer switches that use an FHRP.
• Convergence: The access layer supports inline PoE for IP telephony and wireless APs, allowing
customers to converge voice onto their data network and providing roaming WLAN access for users.
• Security: The access layer provides services for additional security against unauthorized access to the
network by using tools as such port security, DHCP snooping, DAI, and IP Source Guard.

Distribution Layer
The distribution layer in the campus design has a unique role in which it acts as a services and control
boundary between the access layer and the core. Both the access layer and the core are essentially dedicated
special purpose layers. The access layer is dedicated to meeting the functions of end-device connectivity
and the core layer is dedicated to providing nonstop connectivity across the entire campus network. The
distribution layer, on the other hand, serves multiple purposes.
Availability, fast path recovery, load balancing, and QoS are the important considerations at the distribution
layer. High availability is typically provided through dual paths from the distribution layer to the core, and
from the access layer to the distribution layer. Layer 3 equal-cost load sharing allows both uplinks from the
distribution to the core layer to be utilized.
The distribution layer is the place where routing and packet manipulation are performed and can be a
routing boundary between the access and core layers. The distribution layer represents a redistribution point
between routing domains or the demarcation between static and dynamic routing protocols. The distribution
layer performs tasks such as controlled routing decision making and filtering to implement policy-based
connectivity and QoS. To improve routing protocol performance further, the distribution layer summarizes
routes from the access layer. For some networks, the distribution layer offers a default route to access layer
routers and runs dynamic routing protocols when communicating with core routers.
The distribution layer uses a combination of Layer 2 and multilayer switching to segment workgroups and
isolate network problems, preventing these problems from affecting the core layer. The distribution layer is
commonly used to terminate VLANs from access layer switches. The distribution layer connects network
services to the access layer and implements policies regarding QoS, security, traffic loading, and routing.
The distribution layer provides default gateway redundancy by using an FHRP such as HSRP, GLBP, or
VRRP. FHRPs allow for the failure or removal of one of the distribution nodes without affecting endpoint
connectivity to the default gateway.

Core Layer
The core layer is the backbone for campus connectivity, and is the aggregation point for the other layers and
modules in the Cisco Enterprise Campus Architecture. The core must provide a high level of redundancy
and adapt to changes very quickly.
The campus core is in some ways the simplest yet most critical part of the campus. It provides a very limited
set of services and is designed to be highly available and operate in an always-on mode. In the modern
business world, the core of the network must operate as a nonstop, always available service. The key design
objectives for the campus core are based on providing the appropriate level of redundancy to allow for near-
immediate data-flow recovery in the event of the failure of any component (switch, supervisor, line card, or
fiber). The network design must also permit the occasional, but necessary, hardware and software upgrade
or change to be made without disrupting any network applications. The core of the network should not
implement any complex policy services, nor should it have any directly attached user or server connections.
The core should also have the minimal control plane configuration that is combined with highly available
devices that are configured with the correct amount of physical redundancy to provide for this nonstop
service capability.
The campus core is the backbone that binds together all of the elements of the campus architecture. It is the
part of the network that provides for connectivity between end devices, computing, and data storage services
that are located within the data center—and other areas and services within the network. It serves as the
aggregator for all of the other campus blocks and ties together the campus with the rest of the network.

Is a Core Layer Needed?
In environments where the campus is contained within a single building—or multiple adjacent buildings
with the appropriate amount of fiber—it is possible to collapse the core into distribution switches.
Without a core layer, the distribution layer switches will need to be fully meshed. This design is difficult to
scale, and increases the cabling requirements because each new building distribution switch needs full-mesh
connectivity to all the distribution switches. The routing complexity of a full-mesh design increases as you
add new neighbors.

In the figure, a distribution module in the second building of two interconnected switches requires four
additional links for full-mesh connectivity to the first module. A third distribution module to support the
third building would require eight additional links to support connections to all the distribution switches, or
a total of 12 links. A fourth module supporting the fourth building would require 12 new links for a total of
24 links between the distribution switches.
Having a dedicated core layer allows the campus to accommodate this growth without compromising the
design of the distribution blocks, the data center, and the rest of the network. This is particularly important
as the size of the campus grows either in number of distribution blocks, geographical area, or complexity. In
a larger, more complex campus, the core provides the capacity and scaling capability for the campus as a
whole.
The question of when a separate physical core is necessary depends on multiple factors. The ability of a
distinct core to allow the campus to solve physical design challenges is important. However, it should be
remembered that a key purpose of having a distinct campus core is to provide scalability and to minimize
the risk from (and simplify) moves, adds, and changes in the campus. In general, a network that requires
routine configuration changes to the core devices does not yet have the appropriate degree of design
modularization. As the network increases in size or complexity and changes begin to affect the core devices,
it often points out design reasons for physically separating the core and distribution functions into different
physical devices.

Types of Cisco Switches
Cisco switches deliver high performance, security, and scalability to meet the needs of a small business,
midsize business, enterprises, and service providers.
Cisco offers two types of network switches: fixed configuration and modular switches. With fixed
configuration switches, you cannot swap or add another module, like you can with a modular switch.
In the enterprise access layer you will find fixed configuration switches, like the Cisco Catalyst, 2960-X
Series. It offers a wide range of deployments.
In the enterprise distribution layer, you will find fixed or modular switches. An example of a modular
switch that can be found in the distribution layer is the Cisco Catalyst 3850-X Series. This series of switches
allows you to select different network modules (Ethernet or fiber-optic) and redundant power supply
modules. In small businesses without a distribution layer, the 3850-X can be found in the core layer. In big
business you might find 3850-X in the access layer, that is if you want to have high redundancy and full
Layer 3 functionality at the access layer.
In the enterprise core layer, you will find modular switches like the Cisco Catalyst 6800 Series. With the
6800 switch, virtually every component, from the CPU card to power supplies to switch cards, is
individually installed in a chassis.
If you have a network where there is a lot of traffic you could put Cisco Catalyst 4500-X Series switches
into the distribution layer. By doing this, not only the uplinks, all links can be 10Gbps.
All switches within the 2960-X, 3850-X, 4500-X and 6800-X series are managed. This means you can
configure an IP address on the device. By having a management IP address, you can connect to the device
using SSH or Telnet and change device settings. An unmanaged switch is only appropriate for a home or
small business environment.
These are just few examples of Cisco switches and their placement in the network. For more information go
to http://www.cisco.com/c/en/us/products/switches/index.html.

Routed vs. Switched Campus Architecture
When designing the access layer, you can either have it as only Layer 2, or you can introduce routing. Each
of these implementations has benefits and drawbacks.
The first option is to have only Layer 2 switching (also known as bridging) in the access layer. VLANs get
terminated at the distribution layer and half of the uplinks get blocked due to spanning-tree operation.
The second option is to have Layer 3 switching (also known as routing) to the access layer VLANs. VLANs
get terminated on the access-layer devices. The links between distribution and access layer switches are
routed links—all access and distribution devices would participate in routing.
The Layer-2-only access design is a traditional, cheaper solution. However STP, while getting rid of loops,
blocks half of uplinks. Layer 3 design introduces the challenge of how to separate traffic—for example,
guest traffic should stay separated from internal traffic. Layer 3 design also requires careful planning. A
VLAN on one Layer 3 access device cannot also be on another access layer switch in a different part of
your network. Each VLAN is local. With Layer 2, you can have the same VLAN on multiple access layer
switches; however, that practice is not recommended.

Summary
This topic summarizes the key points that were discussed in this lesson.

Lesson 2: Comparing Layer
2 and Multilayer Switches
Overview
In general, you will have two types of switches: Layer 2 switches and multilayer switches. Layer 2 switches
make decisions based on Layer 2 information. Multilayer switches make decisions based on Layer 2, Layer
3, and Layer 4 information. Multilayer switches forward frames and packets at wire speed by using ASIC
hardware. Specific Layer 2 and Layer 3 components, such as routing tables or ACLs, are cached into
hardware. Routing, switching, ACLs, and QoS tables are stored in a high-speed table memory so that
forwarding decisions and restrictions can be made in high-speed hardware. Switches perform lookups in
these tables for result information, such as to determine whether a packet with a specific destination IP
address is supposed to be dropped according to an ACL. Cisco Catalyst switches deploy these memory
tables using specialized memory architectures, referred to as CAM and TCAM.
• Describe how a Layer 2 switch operates
• Describe basic multilayer switch operation
• Describe what the multilayer switch rewrites during the packet forwarding process
• Describe the purpose of the CAM and TCAM tables
• Describe how to investigate the CAM
• Describe the roles of the control plane and data plane in a multilayer switch
• List and describe switching methods that are used by a Cisco Catalyst switch
• Describe the idea behind route caching
• Describe the idea behind topology-based switching

Layer 2 Switch Operation
Traditionally, LANs were made of Ethernet hubs. In such LANs, all hosts share available bandwidth and the
CSMA/CD scheme determines when a device is allowed to transmit data over the shared LAN. Hub
networks force devices to either listen or send data (working in half-duplex mode). If two hosts send data at
the same time, a collision occurs. All hosts must then back off and wait to talk again. Also, if one host sends
a frame, all connected hosts receive it. If one host generates an error, all connected hosts receive it. You can
look at the Layer 2 switch as a multiport bridge, where each port is its own Ethernet LAN segment.
An Ethernet switch operates at Layer 2 of the OSI model. The switch makes decisions about forwarding
frames based on the destination MAC address found within the frame. Collision domains are limited since
each switch port, together with the end-device, is its own collision domain. Since there is no contention on
the media, all hosts can operate in full duplex mode; they can receive and transmit data at the same time.
Each frame that the switch receives gets checked for errors, and only good frames are regenerated and
transmitted.
To figure out where a frame must be sent, the switch will look up its MAC address table. This information
can be told to the switch or it can learn it automatically. The switch listens to incoming frames and checks
the source MAC addresses. If the address is not in the table already, the MAC address, switch port, and
VLAN get recorded in the forwarding table. The forwarding table is also called the CAM table.
What happens if the destination MAC address of the frame is unknown to the switch? The switch then
forwards the frame through all ports within a VLAN. This is known as unknown unicast flooding.
Broadcast and multicast traffic is destined for multiple destinations, so it gets flooded by default.
In the first example, the switch receives a frame on port 1. The destination MAC address for the frame is
0000.0000.5555. The switch will look up its forwarding table and figure out that MAC address
0000.0000.5555 is recorded on port 5. The switch will forward the frame through port 5.
In the second example, the switch receives a broadcast frame on port 1. The switch will forward the frame
through all ports that are within the same VLAN. The frame was received on port 1, which is in VLAN 1;

therefore, the frame is forwarded through all ports on the switch that belong to VLAN 1 (all ports except
port 3).
When a switch receives a frame, it places the frame into a port ingress queue. A port can have multiple
ingress queues and typically these would have different priorities. Important frames get processed sooner.
When the switch selects a frame from the queue, there are a few questions it needs to answer:
• Where should I forward the frame?
• Should I even forward the frame?
• How should I forward the frame?
Decisions about these three questions get answered as follows:

• Layer 2 forwarding table: MAC addresses in the CAM table are used as indexes. If the MAC address
of an incoming frame is found in the CAM table, the frame gets forwarded through the MAC-binded
port. If the address is not found, the frame is flooded through all ports in the VLAN.
• ACLs: ACLs can identify a frame according to its MAC addresses. The TCAM contains these ACLs. A
single lookup is needed to decide whether the frame should be forwarded.
• QoS: Incoming frames can be classified according to QoS parameters. Traffic can then be prioritized
and rate-limited. QoS decisions are also made by TCAM in a single table lookup.
After CAM and TCAM table lookups are done, the frame is placed into an egress queue on the appropriate
outbound switch port. The appropriate egress queue is determined by QoS, and more important frames get
processed first.

Multilayer Switch Operation
Multilayer switches not only perform Layer 2 switching, but also forward frames based on Layer 3 and 4
information. Multilayer switches not only combine the functions of a switch and a router, but also add a
flow cache component.
After a packet is puled off an ingress queue, the switch inspects its Layer 2 and Layer 3 destination
addresses.

As with a Layer 2 switch, there are questions that need answers:
• Where should I forward the frame?
• Should I even forward the frame?
• How should I forward the frame?
Decisions about these three questions get answers as follows:

• Layer 2 forwarding table: MAC addresses in the CAM table are used as indexes. If the frame
encapsulates a Layer 3 packet that needs to be forwarded, the destination MAC address of the frame is
that of the Layer 3 port on the switch.
• Layer 3 forwarding table: The IP addresses in the FIB table are used as indexes. The best match to the
destination IP address is the Layer 3 next-hop address. The FIB also lists next-hop MAC addresses, the
egress switch port, and the VLAN ID, so there is no need for additional lookup.
• ACLs: The TCAM contains these ACLs. A single lookup is needed to decide whether the frame should
be forwarded or not.
• QoS: Incoming frames can be classified according to QoS parameters. Traffic can than be prioritized
and rate-limited. QoS decisions are also made by the TCAM in a single table lookup.
After CAM and TCAM table lookups are done, the packet is placed into an egress queue on the appropriate
outbound switch port. The appropriate egress queue is determined by QoS, and more important packets get
processed first.

Frame Rewrite
A multilayer switch, like a router, obtains next-hop destinations from the FIB table. Before forwarding the
frame, it needs to rewrite certain parts of the frame.
When the frame arrives on the port, the destination MAC address of the frame belongs to the multilayer
switch. After the switch processes the frame, the next-hop Layer 2 address must be put into the frame in
place of the original destination address. The source MAC address of the frame is replaced with the MAC
address that belongs to the multilayer switch. Also, the TTL gets decreased by one, just like with a router.
The source and destination IP addresses stay the same.
When the frame arrives on the port, the switch does checksum calculation on the frame and IP packet to
ensure that there was no frame or packet corruption during transit. Again, the frame and packet checksums
get recalculated before being sent out of the switch.

CAM and TCAM
Cisco Catalyst switches maintain CAM and TCAM tables. CAM is used in Layer 2 switching and TCAM is
used for Layer 3 switching. Both tables are kept in fast memory so that processing of data is quick.
Multilayer switches forward frames and packets at wire speed by using ASIC hardware. Specific Layer 2
and Layer 3 components, such as learned MAC addresses or ACLs, are cached into the hardware. These
tables are stored in CAM and TCAM.
• CAM table: The CAM table is the primary table that is used to make Layer 2 forwarding decisions.
The table is built by recording the source MAC address and inbound port of all incoming frames. When
a frame arrives at the switch with a destination MAC address of an entry in the CAM table, the frame is
forwarded out through only the port that is associated with that specific MAC address. If there is no
exact match found, the switch floods the packet out of all ports in the VLAN.
• TCAM table: The TCAM table stores ACL, QoS, and other information that is generally associated
with upper-layer processing. Most switches have multiple TCAMs, such as one for inbound ACLs, one
for outbound ACLs, one for QoS, and so on. Multiple TCAMs allow switches to perform different
checks in parallel, thus shortening the packet-processing time. Cisco switches perform CAM and
TCAM lookups in parallel. This is why Cisco switches do not suffer any performance degradation by
enabling QoS or ACL processing.

Discovery 1: Investigating the CAM
Overview
Through this discovery, you will investigate the contents and properties of the CAM table of a switch. You
can display the CAM table to verify the information that the switch has learned. The table will also tell you
out of which port the address was learned, along with the VLAN information.

Topology

Job Aids
Note If you shut down an interface on a real router or switch, the connected device will see it as
"down/down". Due to virtualization specifics, IOL behaviour is slightly different. If you shut
down an interface on a router or switch, the connected device will see it as "up/up". In IOL,
the status of an interface can only be "up/up" or "administratively down/down".
Device information
Device Device IP Device Interface Neighbor Interface on the
Neighbor
PC1 10.1.1.1 Eth0/0 Sw itch1 Eth0/0
Sw itch1 n/a Eth1/1 n/a n/a
Investigating CAM
Step 1 From PC1, generate traffic to all devices in the subnet.
Log on to PC1 and issue a broadcast ping to 10.1.1.255. Configure a repeat count of 10,000 and
a datagram size of 1500.
Pinging the broadcast address of 10.1.1.255 will ping all hosts in the 10.1.1.0/24 subnet. You are
doing this in order for Switch1 to learn all the MAC addresses of connected hosts.
When issuing a broadcast ping, you will need to make sure that you are in privileged mode. IP
broadcast pinging is disallowed from user exec mode.
Note that in the IOL environment, PCs are simulated using routers.
PC1>
PC1> enable
PC1# ping
Protocol [ip]:
Target IP address: 10.1.1.255
Repeat count [5]: 10
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000, 1500-byte ICMP Echos to 10.1.1.255, timeout is 2 seconds:
Reply to request 0 from 10.1.1.3, 1 ms

<... output omitted ...>

Step 2 Access Switch1 and investigate its CAM table.
Use the show mac address-table command.
Notice that you see one MAC address per port for Ethernet 0/1, 0/2, and 0/3. These are the ports
that PCs PC1, PC2, and PC3 connect to, respectively.
Switch1# show mac address-table

Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports

---- ----------- -------- -----
1 aabb.cc00.2000 DYNAMIC Et0/1
Total Mac Addresses for this criterion: 5
So, if PC1 sends a packet to PC2, Switch1 will receive it on Ethernet 0/1. Switch1 will
investigate the frame and see that the destination MAC address is that of PC2. Switch1 will now
perform a lookup and find the MAC address of PC2 mapped to Ethernet 0/2. For the final step,
Switch1 will forward the message.
Step 3 On Switch1, filter out MAC addresses that the switch learned through Ethernet 1/1.
Use the command show mac address-table interface Ethernet 1/1.

Switches that connect to many devices can have very long CAM tables. In those cases, you can
help yourself with filtering.
You can see that Switch1 sees two MAC addresses through port Ethernet 1/1:
Switch1# show mac address-table interface ethernet 1/1

Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports

---- ----------- -------- -----
You can add the address keyword to specify a single MAC address. If you want to show just
MAC addresses that belong to devices in a certain VLAN, add the vlan keyword.
Step 4 How is it possible for Switch1 to see two MAC addresses through port Eth1/1?
Switch1 sees two MAC addresses through Ethernet 1/1 because this port connects to another
switch.
Step 5 Issue show cdp neighbor command on Switch1.
You can verify that Switch1 connects to another switch by investigating its Cisco Discovery
Protocol neighbors. Use the show cdp neighbor command. Cisco Discovery Protocol is used to
share information about directly connected Cisco equipment.

You can see that indeed Switch1 connects to another switch, Switch2:
Switch1# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID

Switch2 Eth 1/1 128 R S Linux Uni Eth 1/1
CAM Aging Time

CAM tables can accommodate a lot of entries for frame forwarding. However, there is not enough space for
every address in a large network. For that reason, addresses that have not been heard from for a period of
time (stale entries) are aged-out. That period of time is also called aging time.
Step 6 Investigate aging time using the show mac address-table aging-time command.
By default, the aging time is 300 seconds:
Switch1# show mac address-table aging-time

Global Aging Time: 300
Vlan Aging Time
---- ----------
The default aging time for ARP table entries is 4 hours. In networks where you have a host that
does not generate a lot of traffic for long periods of time, you can have your CAM table entries
time out every 5 minutes. In these rare cases, you might have to increase the CAM aging time to
bring down the amount of flooding.
CAM table entries cannot be summarized like it is done in IP routing. Having 1000 devices in
the network means 1000 addresses per CAM table per switch. When the CAM table is full, the
switch acts as a hub, in that it forwards all new frames like broadcasts. The solution is to
implement routing into the network to limit MAC flooding.
Step 7 Change CAM aging time on Switch1 to 600 seconds.
The default setting of CAM aging time can be changed using the following command: mac
address-table aging-time seconds. Change the aging time on Switch1 to 600 seconds.
Switch1(config)# mac address-table aging-time 600
Step 8 Now, after you have changed the aging time, verify the change using the command show mac
address-table aging-time:
Switch1# show mac address-table aging-time

Global Aging Time: 600
Vlan Aging Time
---- ----------

Distributed Hardware Forwarding
A network device has three planes of operation: the management plane, the control plane, and the
forwarding plane. Layer 3 switching software employs a distributed architecture in which the control path
and data path are relatively independent. The control path code, such as routing protocols, runs on the route
processor, whereas the Ethernet interface module and the switching fabric forward most of the data packets.
Each interface module includes a microcoded processor that handles all packet forwarding. The main
functions of the control layer between the routing protocol and the firmware data path microcode are as
follows:
• Managing the internal data and control circuits for the packet-forwarding and control functions.
• Extracting the other routing and packet-forwarding-related control information from the Layer 2 and
Layer 3 bridging and routing protocols and the configuration data, and then conveying the information
to the interface module for control of the data path.
• Collecting the data path information, such as traffic statistics, from the interface module to the route
processor.
• Handling certain data packets that are sent from the Ethernet interface modules to the route processor.

Cisco Switching Methods
A Cisco router can use one of three methods to forward packets: process switching, fast switching, and
Cisco Express Forwarding. In Cisco Catalyst switches, route caching is equivalent to fast switching.
Topology-based switching is the Cisco Express Forwarding equivalent in Cisco Catalyst switches.
A Cisco router can use one of three methods to forward packets:

• Process switching: In process switching, the router strips off the Layer 2 header for each incoming
frame, looks up the Layer 3 destination network address in the routing table for each packet, and then
sends the frame with the rewritten Layer 2 header, including a computed CRC to the outgoing interface.
All these operations are done by software that is running on the CPU for each individual frame. Process
switching is the most CPU-intensive method that is available in Cisco routers. It will greatly degrade
performance and is generally used only as a last resort or during troubleshooting.
• Fast switching: After the lookup of the first packet that is destined for a particular IP network, the
router initializes the fast-switching cache that is used by the fast-switching mode. When subsequent
frames arrive, the destination is found in this fast-switching cache. The frame is rewritten with
corresponding link addresses and is sent over the outgoing interface.
• Cisco Express Forwarding: Cisco Express Forwarding is the default switching mode. It is less CPU-
intensive than fast switching and process switching. A router with Cisco Express Forwarding enabled
uses information from tables that are built by the CPU, such as the routing table and the ARP table, to
build hardware-based tables that are known as the FIB and adjacency tables. These tables are then used
to make hardware-based forwarding decisions for all frames in a data flow, even the first. While Cisco
Express Forwarding is the fastest switching mode, there are limitations. Some features are not
compatible with Cisco Express Forwarding. There are also some rare instances in which the functions
of Cisco Express Forwarding can actually degrade performance. A typical case of such degradation is
Cisco Express Forwarding polarization in a topology that is using load-balanced Layer 3 paths.

A Layer 3 switch makes forwarding decisions using one of these two methods, which are platform-
dependent:
• Route caching: Also known as flow-based or demand-based switching, route caching means that a
Layer 3 route cache is built within hardware functions as the switch detects traffic flow into the switch.
This method is functionally equivalent to fast switching in Cisco IOS Software.
• Topology-based switching: Information from the routing table is used to populate the route cache,
regardless of traffic flow. The populated route cache is the FIB, and Cisco Express Forwarding is the
facility that builds the FIB. This method is functionally equivalent to Cisco Express Forwarding in
Cisco IOS Software.

Route Caching
Route caching is fast-switching equivalent in Cisco Catalyst switches.
For route caching to function, the destination MAC address of an incoming frame must be that of a switch
interface with Layer 3 capability. The first packet in a stream is switched in software by the route processor,
because no cache entry exists yet for the new flow. The forwarding decision that is made by the route
processor is then programmed into a cache table (the hardware forwarding table), and all subsequent packets
in the flow are switched in the hardware, commonly refered to as ASIC. Entries are created only in the
hardware-forwarding table as the switch detects new traffic flows, and entries will time out after they have
been unused for a period of time.
Because entries are created only in the hardware cache as flows are detected by the switch, route caching
will always forward at least one packet in a flow using software, which is slow in comparison to hardware-
based forwarding.
Route caching is also known as Netflow LAN switching, flow-based, or demand-based switching, and
"route once, switch many."

Topology-Based Switching
Topology-based switching is the Cisco Express Forwarding equivalent in Cisco Catalyst switches. Layer 3
switching using topology-based switching is faster than route caching.
Cisco Express Forwarding uses information in the routing table to populate a route cache (known as an
FIB), without traffic flows being necessary to initiate the caching process.
Because this hardware FIB exists regardless of traffic flow, assuming that a destination address has a route
in the routing table, all packets that are part of a flow, even the first packet, will be forwarded by the
hardware. Because of this increased performance, topology-based switching is currently the predominant
method of switching, ahead of route caching.
In addition, parallel paths can exist and enable Cisco Express Forwarding to perform load balancing. Per-
destination load balancing allows the Layer 3 switch to use multiple paths to achieve load sharing. Packets
for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are
available. This ensures that packets for a given host pair arrive in order. Per-destination load balancing is
enabled by default when you enable Cisco Express Forwarding, and it is the load-balancing method of
choice for most situations.
Recall, however, that this is also a potential limitation of Cisco Express Forwarding. Because, by default, it
would always select the same path for a given host pair, in a topology with multiple Layer 3 paths between a
given host pair, where packet-based load balancing would normally occur across the multiple paths, Cisco
Express Forwarding will “polarize” the traffic by using only one path for a given host pair, thus effectively
negating the load-balancing benefit of the multiple paths for that particular host pair.
Because per-destination load balancing depends on the statistical distribution of traffic, load sharing
becomes more effective as the number of source-destination pairs increases. Thus, in an environment where
there is a broad distribution of traffic among host pairs, Cisco Express Forwarding polarization is of
minimal concern. However, in an environment where the data flow between a small number of host pairs
creates a disproportionate percentage of the packets traversing the network, Cisco Express Forwarding

polarization can become a serious problem. Cisco Express Forwarding load balancing can be “tuned,” so if
you anticipate a problem with Cisco Express Forwarding polarization, you will want to ensure that such
tuning is performed within the enterprise network.
Layer 3 switching can occur at two different locations on the switch:

• Centralized switching: Switching decisions are made on the route processor by a central forwarding
table, typically controlled by an ASIC.
• Distributed switching: Switching decisions can be made on a port or line-card level, rather than on a
central route processor. Cached tables are distributed and synchronized to various hardware components
so that processing can be distributed throughout the switch chassis.
The figure presents the primary features that differentiate centralized switching from distributed switching.
Because centralized switching limits switch performance, it is generally used when the switch does not
support distributed switching or installed line cards, or when other features that are enabled on the switch
are not compatible with distributed switching. Not all switches support distributed switching.

Summary

Lesson 3: Using Cisco SDM
Templates
Overview
The SDM templates on some switches (such as Cisco Catalyst 2960, 3560, or 3750) manage the Layer 2 and
Layer 3 switching information that is maintained in the TCAM. The Cisco SDM templates are used to
configure system resources in the switch in order to optimize support for specific features. The required
feature set depends on how the switch is used in the network. The Cisco SDM templates can be selected in
order to provide maximum system usage for some functions, or to use the default template in order to
balance resources.
The most common action is to change from the default template to the dual-stack template. IPv6
functionalities are not supported with the default template.
Upon completing this lesson, you will be able to:

• Describe the role of SDM templates
• Describe the typical SDM template types
• Change the SDM template
• Describe precautions to take when changing the SDM templates

What Are SDM Templates?
Access layer switches were not built to be used in routing OSPFv3 or BGP, even though they can be used
for that also. By default, the resources of these switches are allocated to a more common set of tasks. If you
want to use the switch for something that is not in the common set of tasks, some switches have an option to
re-allocate resources.
You can use SDM templates to configure system resources (CAM and TCAM) in the switch to optimize
support for specific features, depending on how the switch is used in the network. You can select a template
to provide maximum system usage for some functions; for example, use the default template to balance
resources, and use access templates to obtain maximum ACL usage. To allocate hardware resources for
different usages, the switch SDM templates prioritize system resources to optimize support for certain
features.
You can verify the SDM template that is in use with the show sdm prefer command.

SDM Template Types
There are multiple SDM templates, and each prioritizes different system resources to optimize support for
certain features.
Available SDM templates depend on the device type and Cisco IOS Software that is used. This example is
taken from a Cisco Catalyst 3750 Switch:
• Default: When you unbox a brand new switch, this will be the template enabled. It provides a mix of
unicast routes, connected, and host routes.
• Routing: As one example, you would enable this template if the device is performing routing in the
distribution or core of the network. The device is able to carry numerous routes, but only for IPv4.
• Access: You would enable this template if you have many VLANs. In turn, this template reduces the
resources that are allocated to routing.
• VLAN: When you enable this template, you allocate most of the table space to Layer 2 unicasts. You
would use this when you have large subnets with many MAC addresses.
• Dual IPv4 and IPv6: You would enable this template if you want to turn on the IPv6 capabilities of the
device. When enabling this template, you have to choose between default, routing, and VLAN.
− Default: More space is reserved for IPv6 routing and security. There is less reserved space for
Layer 2 unicast.
− Routing: More space is reserved for IPv6 routing than IPv4 routing.
− VLAN: Suitable for when you are running a dual-stack environment with lots of VLANs.

Changing the SDM Template
If you have a Cisco Catalyst 3750 or 3560 switch and the ipv6 unicast-routing command is not supported,
you probably need to change the SDM template. By enabling the dual-ipv4-and-ipv6 template, you will
then be able to turn on IPv6 on the device.
The default template does not allocate resources to IPv6 functions:

Switch# show sdm prefer
The current template is "desktop default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 6K

number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 8K
number of directly-connected IPv4 hosts: 6K
number of indirect IPv4 routes: 2K
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 1K
When changing the template to dual-ipv4-and-ipv6, you have to choose between the following suboptions:
default, routing, and vlan.
After the template is changed to dual stack, you can see that now the switch has resources that are allocated
to IPv6:

Switch# show sdm prefer
The current template is "desktop IPv4 and IPv6 default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 2K

number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 3K
number of directly-connected IPv4 hosts: 2K
number of indirect IPv4 routes: 1K
number of IPv6 multicast groups: 1.125k
number of directly-connected IPv6 addresses: 2K
number of indirect IPv6 unicast routes: 1K
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 1K
number of IPv6 qos aces: 0.625k
number of IPv6 security aces: 0.5K

Choosing the Correct Template
Change the SDM template only if you have a good reason to do so. Before changing the template,
investigate if the change is needed or if it is just a workaround for poor design.
To verify how much of the system resources are being used, use the command show platform tcam
utilization. If the TCAM utilization is close to maximum for any of the parameters, check if any of the
other template features can optimize for that parameter: show sdm prefer {access | default | dual-ipv4-
and-ipv6 | routing | vlan}.
Probably the most common reason for chaning the SDM template is to enable IPv6 routing. Using the dual-
stack templates results in less TCAM capacity that is allowed for each resource, so do not use it if you plan
to forward only IPv4 traffic. IPv6 is not supported by default for a reason—IPv6 features require extensive
resource reservation.
Another common reason for changing the SDM template is because you are running out of resources. For
example you have so many access lists that you need to change to the access SDM template. In these kinds
of situations it is important to first investigate whether you can optimize the performance so you do not need
to change the SDM template. It might be that the ACLs that you are using are set up inefficiently—there are
redundant entries, the most common entries are at the end of the list, there are unnecessary entries, and so
on. When you change the SDM template, this will not only reserve resources, but will also release other
resource reservations. So while you are solving the problem with ACLs, you might now start running out of
resources for unicast routing.

Summary
References
More information on configuring SDM templates on Cisco Catalyst 3560 and 3750 Series Switches can be
found at:
• http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/15.0_1_se/config
uration/guide/swsdm.html
More information on configuring SDM templates on Cisco Catalyst 2960 Series Switches can be found at:
• http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/15.0_2_se/configuration/
guide/swsdm.html

Lesson 4: Implementing
LLDP
Overview
Network vendors have realized the need for having a discovery protocol (such as Cisco Discovery
Protocol). Due to a lack of interoperability between these protocols, an effort was made to develop a
standardized protocol in IEEE 802.1AB, or LLDP.
• Define LLDP and compare it to Cisco Discovery Protocol
• Describe how to enable LLDP
• Discover neighbors using LLDP

LLDP Introduction
LLDP is an industry standard alternative to Cisco Discovery Protocol. The commands are very similar
between protocols.
Cisco Discovery Protocol is a device discovery protocol that runs over Layer 2 (the data link layer) on all
Cisco-manufactured devices. The protocol allows network management applications to automatically
discover and learn about other Cisco devices that are connected to the network.
If you need to support other devices and allow for interoperability between other devices, you will need to
implement the IEEE 802.1AB, also known as LLDP. LLDP is a neighbor discovery protocol that is used for
network devices to advertise information about themselves to other devices on the network. This protocol
runs over the data link layer, which allows two systems running different network layer protocols to learn
about each other.
LLDP supports a set of attributes that it uses to discover neighbor devices. These attributes contain type,
length, and value descriptions and are referred to as TLVs. LLDP-supported devices can use TLVs to
receive and send information to their neighbors. This protocol can advertise details such as configuration
information, device capabilities, and device identity.
An advantage of LLDP over Cisco Discovery Protocol is that allows you to do much customization. You
can make it carry a lot of information that is relevant to your network. One drawback of LLDP in
comparison to Cisco Discovery Protocol is that it is not very lightweight.

Enabling LLDP
While Cisco Discovery Protocol is enabled by default on all Cisco devices, LLDP may be either enabled or
disabled by default.
To enable LLDP on a device, use the command lldp run in global configuration mode. To disable it, use no
lldp run.
LLDP is unidirectional, operating only in an advertising mode. LLDP does not solicit information or
monitor state changes between LLDP nodes. LLDP periodically sends advertisements to a multicast
address. Devices supporting LLDP can send information about themselves while they receive and record
information about their neighbors.
On some interfaces, for example on a router link toward a service provider, you do not want LLDP running.
To disable LLDP on a specific interface, go into interface configuration mode and use the command no lldp
enable. You can also set the interface to not receive (no lldp receive) or not transmit (no lldp transmit)
LLDP information.
The show lldp command tells you if LLDP is enabled on the device. Additionally, the output will provide
you with information how often LLDP advertisements are sent, how many seconds the hold time is set for,
and how the interface reinitialization delay is set. The LLDP advertisement time is essentially an LLDP
hello packet, and the default is 30 seconds. The LLDP hold timer tells the device how long it should wait
before declaring the neighbor unavailable. By default, the hold time is set to 120 seconds. So, if the device
does not hear from a neighbor for 120 seconds, it purges the neighbor entry from the LLDP table.

Discovering Neighbors Using LLDP
The format of the LLDP neighbor display is very similar to that of Cisco Discovery Protocol.
The show lldp neighbors command tells you information about neighbors. This information includes:
device ID, local interface type and number, holdtime settings, capabilities (device type), and port ID.
You can investigate the more detailed output of the LLDP neighbors using the show lldp neighbors detail
command. You can also filter the output to a specific neighbor by specifying the interface to which the
neighbor is connected. If the neighbor has a description configured under the interface, it will show up next
to "Port id."

Switch1# show lldp neighbors FastEthernet 0/11 detail
Chassis id: 001e.145e.4984

Port id: LINK TO SWITCH1
Port Description: FastEthernet0/22
System Name: Switch2.cisco.com
System Description:
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.2(44)SE6, RELEASE
SOFTWARE (fc1)
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Mon 09-Mar-12 18:10 by gereddy
Time remaining: 94 seconds

System Capabilities: B,R
Enabled Capabilities: B
Management Addresses:
IP: 10.1.1.12
Auto Negotiation - supported, enabled
Physical media capabilities:
10base-T(HD)
10base-T(FD)
100base-TX(HD)
100base-TX(FD)
Media Attachment Unit type: 16
---------------------------------------------
Total entries displayed: 1
The show lldp traffic command shows you the statistics on exchanged LLDP frames between a device and
its neighbors.
Switch1# show lldp traffic
LLDP traffic statistics:

Total frames out: 42
Total entries aged: 0
Total frames in: 11
Total frames received in error: 0
Total frames discarded: 1
Total TLVs unrecognized: 0

Summary
References
More information about LLDP and a comparison with Cisco Discovery Protocol can be found at:
• http://www.cisco.com/en/US/technologies/tk652/tk701/technologies_white_paper0900aecd804cd46d.ht
ml

Lesson 5: Implementing PoE
Overview
IP devices are becoming more common. Soon, billions of devices will be connected to the Internet. Not all
of these devices will be connected using a wireless connection. If there is a need for high-speed
connectivity, reliability of power supply, or the devices have rather high consumption, devices need to get
power through wires. This is where PoE becomes important. PoE, also referred to as inline power, supplies
power through the same cable as data.

• Describe the need for PoE
• Describe the components of a PoE system
• Describe how PoE works
• Describe how IEEE and Cisco PoE standards negotiate the power levels required by the powered device
• Configure and verify PoE

The Need for PoE
A Cisco IP phone must have power in order to operate. This power can come from two types of sources: an
external AC adapter or PoE switch. PoE is a system that transfers electrical power, together with data, to
remote devices over standard data cables in an Ethernet network.
An external AC adapter plugs into a normal AC wall outlet and provides DC to the IP phone or AP.
Although power is easily available in an office environment, using one AC/DC socket per IP phone may be
considered a waste of physical resources. Because the phone has a cable connection to the Ethernet switch, a
logical solution is to use this cable to provide power as well as connectivity.
This setting, called PoE, implies that the power comes through the Ethernet cable. The source of this power
may be the switch itself. If the switch is able to provide power to client devices, the switch is said to be
PoE-able.
If the switch itself cannot provide power, it is often possible to install an intermediate device between the
switch and the IP phone. This device will receive power from a power outlet, and will connect to the switch
with another cable. It connects to the port to which the phone will be connected. A third cable runs from this
intermediate device to the phone, providing power along with data transmission to and from the switch. This
device is called a power injector.

To decrease the cost and complexity of the installation, powering the devices directly from the switch is
often seen as the best solution. In this case, the same power supply is provided to an IP phone through the
same UTP cable that is used for data connectivity. The power source is the Cisco Catalyst switch. You do
not need an additional power source.
You can manage and monitor PoE. To follow best practices, you should also connect a UPS so that it
continues to receive and offer power even if the regular source fails. IP phones are then available even
through power failure.

PoE Components
When implementing PoE, you will use three types of components: power-sourcing devices, powered
devices, and Ethernet cables.
PSE can be switches, routers with switch modules and power injectors. Power injectors are also called "mid-
spans." These are typically a compromise for implementations where you do not have PoE switches but you
want to take advantage of PoE benefits without purchasing new switches.
Typical powered devices are wireless APs, IP phones, and IP surveillance cameras. There are numerous
other PoE-able powered devices, such as thin clients, sensors, wall clocks, and so on. Even switches can be
powered through PoE.
With the standard Category 5 cable, the distance between the PSE and powered device is at maximum 100
meters, or 328 feet.

PoE Standards
Three common PoE methods exist: Cisco inline power, the IEEE 802.3af standard, and the IEEE 802.3at
standard. Cisco inline power is prestandard because the IEEE 802.3 standards did not include specifications
for PoE.
• Cisco Inline Power: This method was developed by Cisco. It was developed before the 802.3af
standard. Cisco Inline Power was released in 2000.
• IEEE 802.3af: This standard provides interoperability between different vendors. Up to 15.4 W of DC
power is available for each powered device. The 802.3af standard was ratified in 2003.
• IEEE 802.3at - This standard is an improvement over the 802.3af standard, and can provide powered
devices with up to 25.5 W of power. This number can be increased to 50 W and more with
implementations that are outside the standard. This standard is also known as "PoE+" or "PoE Plus."
The 802.3at standard was ratified in 2009.
One of the main differences is that the standard implementations use a power-detection mechanism that
detects whether the connected device needs power.

PoE Negotiation
The PoE switch keeps power on a disabled port down. When you connect, for example, a Cisco IP phone to
a port, the switch must automatically detect that this device needs power. The switch must first provide
power to the device; only then it can establish the data link.
With 802.3af and 802.3at, the switch tries to detect the powered device by supplying a small voltage across
the Ethernet cable. The switch then measures the resistance. If the measured resistance is 25K ohm, a
powered device is present. The powered device can provide the switch with a power class information.
Based on that information, the switch can allocate the powered device with the appropriate maximum
power.
IEEE 802.3at power classes are numbered from 0 to 4. The default class of 0 is used if either the switch or
the powered device does not support power class discovery.
Note Cisco Inline Power has a different method of negotiating power than both of the IEEE
standards. The switch sends out a 340-kHz test tone on the Ethernet cable. A tone is
transmitted instead of DC power because the switch must first detect the device before
supplying it with power. With Cisco Inline Power, the most appropriate power level is
determined by exchange of Cisco Discovery Protocol information. The switch discovers the
type of device (for example, a Cisco IP phone) and the power requirements of the device.

Configuring and Verifying PoE
PoE configuration is not complicated. Each switch automatically detects and negotiates the power that is
supplied to the powered device. This behavior can be modified so that the port can never detect or offer
inline power.
You can turn on PoE support at the port level. The power inline auto command is sufficient to enable PoE
and autodetection of power requirements. A device not needing any PoE can still be connected to that port;
power is supplied only if the device requires it. The amount of power that is supplied will be automatically
detected. You still have to plan for the overall power that is consumed by all the devices that are connected
to the PoE switch.
PoE is disabled with the power inline never command. Shutting down the port also stops the power supply.
The show power inline command displays the configuration and statistics about the power that is drawn by
connected powered devices and the capacity of the power supply.
When you are implementing PoE for wireless APs and IP phones, be careful of the switch power budget.
The power budget is the total amount of power that a switch can offer to end devices. In the example, 420
W total is available and the switch has 327.6 W power remaining.

Summary

Lesson 6: Module Summary
Overview
This topic summarizes the key points that were discussed in this module.

Lesson 7: Module Self-
Check

Use the questions here to review what you learned in this module. The correct answers and solutions are
found in the Module Self-Check Answer Key.
1. An end-user PC should be connected to which hierarchical layer? (Source: Analyzing Campus Network
Structure)
A. core
B. distribution
C. access
D. transport
2. Connect the campus network structure elements with their properties. (Source: Analyzing Campus
Network Structure)
provides reliability through redundancy and fast
A. core layer
convergence
offers routing and implements policies (filtering,
B. distribution
security, QoS)
layer
supports convergence for voice, wireless, and data
C. access layer
3. Which two statements apply to topology-based switching? (Choose two.) (Source: Lesson 2 Comparing
Layer 2 and Multilayer Switches)
A. It is functionally equivalent to Cisco Express Forwarding.
B. It is the preferred switching mode in Cisco multilayer switches.
C. It is also known as route caching.
D. It is slower than fast switching.
4. A multilayer switch receives a frame that is destined to another part of the network. Which two
statements about the frame rewrite process are true? (Choose two.) (Source: Lesson 2 Comparing Layer
2 and Multilayer Switches)
A. When the frame arrives on the port, the destination MAC address of the frame belongs to the final
destination device.
B. After the switch processes the frame, it increases TTL by one.
C. The switch obtains the next-hop destination from the FIB table.
D. The switch can recalculate the checksum multiple times.
5. Which two statements are true about SDM templates? (Choose two.) (Source: Using Cisco SDM
Templates)
A. They are available on all Cisco devices.
B. They are used to allocate system resources.
C. Changing the SDM template will not disturb switch operation.
D. You can verify the SDM template that is in use with the show sdm prefer command.

6. Connect the SDM template types with their descriptions. (Source: Using Cisco SDM Templates)
When you unbox a brand new switch, this will be the
A. dual IPv4
template that is enabled.
and IPv6
You would enable this template if you want to turn on the
B. access
IPv6 capabilities of the device.
You would enable this template if you have many VLANs.
C. routing
You would enable this template if the device is performing
D. default routing in the distribution layer or core of the network.
7. Which two statements apply to LLDP? (Choose two.) (Source: Implementing LLDP)
A. It is a proprietary Cisco product.
B. It runs on the data link layer.
C. It is not enabled by default on Cisco devices.
D. To verify neighbors, you would use the show cdp neighbors command.
8. Which two statements are true about the IEEE 802.3at standard? (Choose two.) (Source: Implementing
PoE)
A. It can provide your powered devices with more than 15 W of power.
B. It is not backward compatible with 802.3af.
C. It is an improvement over the 802.3af standard.
D. It is a method that was developed by Cisco.
9. Which two statements are true about the PoE negotiation process? (Choose two.) (Source:
Implementing PoE)
A. The PoE switch keeps the power on a disabled port up, just in case a device that needs PoE will be
connected.
B. With 802.3af and 802.3at, the switch tries to detect the powered device by supplying a small voltage
across the Ethernet cable.
C. IEEE 802.3af power classes are numbered from 0 to 4.
D. Cisco Inline Power has the same method of negotiating power as both of the IEEE standards.

Module Self-Check Answers
Answer Key
1 C
2
A. core layer — provides reliability through redundancy and fast convergence
B. distribution layer — offers routing and implements policies (filtering, security, QoS)
C. access layer — supports convergence for voice, wireless, and data
3 A, B
4 C, D
5 B, D
6
A. default — When you unbox a brand new switch, this will be the template that is enabled.
B. dual IPv4 and IPv6 — You would enable this template if you want to turn on the IPv6 capabilities
of the device.
C. access — You would enable this template if you have many VLANs.
D. routing — You would enable this template if the device is performing routing in the distribution
layer or core of the network.
7 B, C
8 A, C
9 B, C

Module 2: Campus Network
Architecture
Introduction
Knowing the function of VLANs and trunks and how to configure them is the core knowledge needed for
building a switched network. VLANs can span across the whole network or they can be configured to
remain local. VLANs play a critical role in deployment of Voice and Wireless networks. Even though you
are not a specialist at one of those two fields it is important to understand basics since both, Voice and
Wireless, often rely on a basic switched network.
When you create VLANs, their names and descriptions are stored in a VLAN database. There is
mechanisms called VTP (VLAN Trunking Protocol) that dynamically distributes this information between
switches. However, even if you do not plan to use it in your network, you should be aware of it, since it can
cause havoc in some circumstances.
Configuring IPv4 IP address on every device in the network can be a burdensome task. DHCP greatly
reduces that administrative overhead and offers some additional features. DHCP can be used even to assign
a specific IP to a device. This can be useful for servers in your network. There are also DHCP options. This
is additional information that can be pushed down to DHCP clients. Probably the most common example is
DHCP option 150 that is used to tell IP phones the IP address of a TFTP server.
IPv6 has a number of dynamic address allocation mechanisms: stateless autoconfiguration, DHCPv6, and
DHCPv6 Lite.
EtherChannel can be used to bundle physical links in one virtual link, thus increasing throughput. There are
multiple ways traffic can be distributed over the physical within the EtherChannel.
• Configure VLANs and trunks
• Describe the issues that VTP brings
• Implement DHCP
• Implement DHCPv6
• Configure Layer 2 EtherChannel

VLANs and Trunks
Overview
Within the switched internetwork, VLANs provide segmentation and organizational flexibility. You can
design a VLAN structure that lets you group stations that are segmented logically by functions, project
teams, and applications, without regard to the physical location of the users. VLANs allow you to
implement access and security policies to particular groups of users.
The voice VLAN feature enables access ports to carry IP voice traffic from an IP phone. Because the sound
quality of an IP phone call can deteriorate if the data is unevenly sent, the switch supports QoS.
• Configure and verify VLANs
• Configure and verify trunks
• Explain switchport mode interactions
• Identify the basic differences between End-to-End and Local VLANs
• Describe the benefits and drawbacks of local VLANs versus end-to-end VLANs
• Describe voice VLANs
• Configure voice VLANs
• Describe what needs to be configured on switches in order to prepare for wireless network
implementation

Discovery 2: Configuring VLANs and Trunks
Overview
Through this discovery you will configure and verify VLANs and trunks.
A VLAN is a group of end stations with a common set of requirements, independent of their physical
location. A VLAN has the same attributes as a physical LAN, except that it lets you group end stations even
when they are not physically located on the same LAN segment. A VLAN also lets you group ports on a
switch so that you can limit unicast, multicast, and broadcast traffic flooding. Flooded traffic that originates
from a particular VLAN floods only to the ports belonging to that VLAN

Topology

Job Aids
IP Addressing
Device Device IP Device Interface Device Neighbor Interface On The
Neighbor
PC1 192.168.1.100 Eth0/0 SW1 Eth0/1
PC2 192.168.1.101 Eth0/0 SW1 Eth0/2
PC3 192.168.1.110 Eth0/0 SW2 Eth0/1
PC4 192.168.20.110 Eth0/0 SW2 Eth0/2
VLAN Setup
Configuring VLANs and Trunks

Step 1 Ping from PC1 to PC2. Your ping should be successful.
SW1's ports that connect to PC1 and PC2 are in the same VLAN (VLAN1). Also PC1 and PC2
have IPs in the same subnet (192.168.1.0/24).
Devices in the same subnet are a part of the same broadcast domain, therefore PC1 and PC2 are
able to ping each other.

PC1# ping 192.168.1.101
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Because of the ARP process, a ping or two might be unsuccessful at the beginning. After the
switch learns where PCs are connected to, the subsequent pings will be successful.
Step 2 Ping from PC3 to PC4. Your ping should be unsuccessful.
SW2's ports that connect to PC3 and PC4 are in different VLANs (VLAN1 and VLAN20). Also
PC3 and PC4 have IPs in different subnets (192.168.1.0/24 and 192.168.20.0/24).
Devices in different subnets are not a part of the same broadcast domain, therefore PC3 and PC4
are not able to ping each other.
PC3# ping 192.168.20.110

.....
Success rate is 0 percent (0/5)
Step 3 So what would you need to do in order for ping from PC3 to PC4 to be successful?
You would need to configure a Layer 3 device to route between VLANs - VLAN1 and VLAN20
in this example.

VLAN Overview
A VLAN is a logical broadcast domain that can span multiple physical LAN segments. Within the switched
internetwork, VLANs provide segmentation and organizational flexibility. You can design a VLAN
structure that lets you group stations that are segmented logically by functions, project teams, and
applications without regard to the physical location of the users. Ports in the same VLAN share broadcasts.
Ports in different VLANs do not share broadcasts. Containing broadcasts within a VLAN improves the
overall performance of the network.
Each VLAN that you configure on the switch implements address learning, forwarding, and filtering
decisions and loop-avoidance mechanisms, just as though the VLAN were a separate physical bridge. The
Cisco Catalyst switch implements VLANs by restricting traffic forwarding to destination ports that are in
the same VLAN as the originating ports. When a frame arrives on a switch port, the switch must retransmit
the frame only to the ports that belong to the same VLAN. In essence, a VLAN that is operating on a switch
limits transmission of unicast, multicast, and broadcast traffic.
A VLAN can exist on a single switch or span multiple switches. VLANs can include stations in a single
building or multiple-building infrastructures. The process of forwarding network traffic from one VLAN to
another VLAN using a router is called inter-VLAN routing.
Step 4 On SW1, create VLAN 20 and name it "IT".
Use command vlan name from global configuration mode to create a VLAN. Then use name
vlan-name command to name VLAN 20.
Enter these two commands on SW1:
SW1(config)# vlan 20
SW1(config-vlan)# name IT

After a VLAN is created, it is not stored in the running configuration, but rather in the VLAN
database-vlan.dat. You can enter a single VID, a series of VIDs that are separated by commas, or
a range of VIDs that are separated by hyphens. If you do not configure a name for the VLAN, it
will automatically be assigned a name of the form VLAN ###, where ### is the VLAN number
with leading zeros.
To delete a VLAN from the switch configuration, you need to use the no vlan vlan-name
command.
Static and Dynamic VLAN Configuration

To configure a port to belong to a certain VLAN, you have two options:
• Static VLAN configuration
• Dynamic VLAN configuration
With static VLAN configuration switch ports are assigned to a specific VLAN. End-devices become
members in a VLAN based on physical port to which they are connected to. The end device is not even
aware that a VLAN exists. Each port that is assigned to a VLAN receives a PVID.
With dynamic VLAN configuration membership is based on the MAC address of the end-device. When a
device is connected to a witch port the switch must query a database to figure out what VLAN needs to be
configured. With dynamic VLANs you need to assign user's MAC address to VLAN in the database of a
VMPS. With dynamic VLANs users can connect to any port on the switch and they will be automatically
assigned into the VLAN they belong to.
Cisco Catalyst switches have a factory default configuration in which various default VLANs are pre-
configured to support various media and protocol types. VLANs 1002-1005 are reserved for legacy
functions like Token Ring and FDDI switching. The default Ethernet VLAN, VLAN to which all switch's
ports belong by default, is VLAN 1.
With static VLAN configuration you first need to create a VLAN on the switch, if it does not yet exist.
VLANs are identified by the VLAN number that runs 1 through 4094.
Step 5 On SW1 configure port Ethernet 0/2 to be an access port and assign it to VLAN 20.
SW1(config)# interface ethernet 0/2

SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 20
The switchport mode access command explicitly tells the port to be assigned only a single
VLAN, providing connectivity to an end user. When you assign a switch port to a VLAN using
this method, it is known as a static access port.
To configure a bundle of interfaces to a VLAN, use the interface range command. Use the vlan
vlan_number command to set static access membership.
Step 6 On PC2 change Ethernet 0/0 IP of 192.168.1.101/24 to a VLAN20 IP of 192.168.20.101/24.
PC2(config)# interface ethernet 0/0

PC2(config-if)# ip address 192.168.20.101 255.255.255.0
You need to change the IP of PC2 so it is in the subnet that is assigned for VLAN 20.
Step 7 On SW1 verify membership of port Ethernet 0/2.

Use the show vlan command to display information on all configured VLANs. The command
displays configured VLANs, their names, and the ports on the switch that are assigned to each
VLAN.
SW1# show vlan
VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------
1 default active Et0/0, Et0/1, Et0/3, Et1/0
Et1/2, Et1/3, Et2/0, Et2/1
Et2/2, Et2/3, Et3/0, Et3/1
Et3/2, Et3/3, Et4/0, Et4/1
Et4/2, Et4/3, Et5/0, Et5/1
Et5/2, Et5/3
20 IT active Et0/2
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1 enet 100001 1500 - - - - - 0 0
20 enet 100020 1500 - - - - - 0 0
1002 fddi 101002 1500 - - - - - 0 0
1003 tr 101003 1500 - - - - - 0 0
1004 fdnet 101004 1500 - - - ieee - 0 0
1005 trnet 101005 1500 - - - ibm - 0 0
Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------
In the show vlan output you can see that VLAN 20, named "IT", that you've created. Also notice
that Ethernet 0/2 is assigned to VLAN 20, as you configured it.
Use the show vlan id vlan_number or the show vlan name vlan-name command to display
information about a particular VLAN.
If you do not see a port listed in the output, this is probably because it is not configured as an
access port.
Step 8 Ping from PC1 to PC3. The ping should be successful.

PC1# ping 192.168.1.110
..!!!
First few pings might fail because of the ARP process.

PC1 and PC3 belong to the same VLAN. The configuration on the two ports that connect
switches SW1 and SW2 is default—both ports belong to VLAN1. So PCs 1 and 3 belong to the
same LAN-Layer 2 network.
Step 9 Ping from PC2 to PC4. The ping should not be successful.
The ping should not be successful since the link between SW1 and SW2 is an access link and
carries only data for VLAN1.
PC2# ping 192.168.20.110
.....

Trunks Overview
A port normally carries only the traffic for the single VLAN. For a VLAN to span across multiple switches,
a trunk is required to connect two switches. A trunk can carry traffic for multiple VLANs.
A trunk is a point-to-point link between one or more Ethernet switch interfaces and another networking
device, such as a router or a switch. Ethernet trunks carry the traffic of multiple VLANs over a single link
and allow you to extend the VLANs across an entire network. A trunk does not belong to a specific VLAN;
rather, it is a conduit for VLANs between switches and routers.
A special protocol is used to carry multiple VLANs over a single link between two devices. There are two
trunking technologies: ISL and IEEE 802.1Q. ISL is a Cisco proprietary implementation. It is not widely
used anymore. The 802.1Q technology is the IEEE standard VLAN trunking protocol. This protocol inserts
a 4-byte tag into the original Ethernet header, and then recalculates and updates the FCS in the original
frame and transmits the frame over the trunk link. A trunk could also be used between a network device and
server or other device that is equipped with an appropriate 802.1Q-capable NIC.
Ethernet trunk interfaces support various trunking modes. You can configure an interface as trunking or
nontrunking, or you can have it negotiate trunking with the neighboring interface.
By default, all configured VLANs are carried over a trunk interface on a Cisco catalyst switch. On an
802.1Q trunk port, there is one native VLAN, which is untagged (by default, VLAN 1). All other VLANs
are tagged with a VID.
When Ethernet frames are placed on a trunk, they need additional information about the VLANs that they
belong to. This task is accomplished by using the 802.1Q encapsulation header. IEEE 802.1Q uses an
internal tagging mechanism that inserts a 4-byte tag field into the original Ethernet frame between the
Source Address and Type or Length fields. Because 802.1Q alters the frame, the trunking device
recomputes the FCS on the modified frame. It is the responsibility of the Ethernet switch to look at the 4-
byte tag field and determine where to deliver the frame.
Step 10 Configure ports that connect SW1 and SW2, as trunks. Use the dotq encapsulation. Allow only
VLANs 1 and 20 to traverse the trunk link.

Trunk configuration on SW1:
SW1(config)# interface Ethernet 1/1
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport trunk allowed vlan 1,20
SW1(config-if)# switchport mode trunk
Trunk configuration on SW2:

SW2(config-if)# switchport trunk allowed vlan 1,20
If you do not explicitly allow VLANs to traverse the trunk, all traffic will be allowed to cross the
link. This includes broadcasts for all VLANs, using unnecessary bandwidth.
The 802.1Q Tag field has these components:

• EtherType: Uses ethertype 0x8100 to indicate that this is an 802.1Q frame.
• PRI: 3 bits; carries the priority information for the frame.
• Token Ring Encapsulation Flag: Indicates the canonical interpretation of the frame if
it is passed from Ethernet to Token Ring. This value is always set to zero for Ethernet
switches.
• VID: VLAN association of the frame. By default, all normal and extended-range
VLANs are supported. The VLAN database can only store VLANs 1-1005. These are
called Normal-range VLANs. Extended-range VLANs are those that utilize extra bits
within the VLAN ID field. On some platforms extended-range VLANs are not enabled
by default.
Step 11 Verify that Ethernet 1/1 on SW1 is now trunking:
SW1# show interfaces trunk
Port Mode Encapsulation Status Native vlan

Et1/1 on 802.1q trunking 1
Port Vlans allowed on trunk

Et1/1 1,20
Port Vlans allowed and active in management domain

Et1/1 1,20
Port Vlans in spanning tree forwarding state and not pruned

Et1/1 1,20
Also notice that only VLANs 1 and 20 are allowed on the trunk.
Step 12 Issue a ping from PC2 to PC4. The ping should be successful.
You have configured the link between SW1 and SW2 to carry data for both, VLAN1 and
VLAN20.

PC2# ping 192.168.20.110
..!!!

The Native VLAN
The IEEE 802.1Q protocol allows operation between equipment from different vendors. All frames, except
native VLAN, are equipped with a tag when traversing the link.
When you are configuring an 802.1Q trunk, a matching native VLAN must be defined on each end of the
trunk link. A trunk link is inherently associated with tagging each frame with a VID. The purpose of the
native VLAN is to allow frames that are not tagged with a VID to traverse the trunk link.
A frequent configuration error is to have different native VLANs. The native VLAN that is configured on
each end of an 802.1Q trunk must be the same. If one end is configured for native VLAN1 and the other for
native VLAN2, a frame that is sent in VLAN1 on one side will be received on VLAN2 on the other.
VLAN1 and VLAN2 have been segmented and merged. There is no reason this should be required, and
connectivity issues will occur in the network. If there is a native VLAN mismatch on either side of an
802.1Q link, Layer 2 loops may occur because VLAN1 STP BPDUs are sent to the IEEE STP MAC address
(0180.c200.0000) untagged.
Cisco switches use Cisco Discovery Protocol to warn of a native VLAN mismatch. On select versions of
Cisco IOS Software, Cisco Discovery Protocol may not be transmitted or will be automatically turned off if
VLAN1 is disabled on the trunk.
By default, the native VLAN will be VLAN1. For the purpose of security, the native VLAN on a trunk
should be set to a specific VID that is not used for normal operations elsewhere on the network.
Switch(config-if)# switchport trunk native vlan vlan-id
Cisco ISL does not have a concept of native VLAN. Traffic for all VLANs is tagged by encapsulating each
frame.

Switchport Mode Interactions
Cisco switch ports can run DTP, which can automatically negotiate a trunk link. This Cisco proprietary
protocol can determine an operational trunking mode and protocol on a switch port when it is connected to
another device that is also capable of dynamic trunk negotiation.
The default DTP mode is dependent on the Cisco IOS Software version and on the platform. To determine
the current DTP mode, issue the command show interface interface slot/number:
SW1# show interface ethernet 0/3 switchport
Name: Et0/3
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Operational Dot1q Ethertype: 0x8100
In this example, the operational mode on the local port is static access and the administrative mode is
dynamic access. This means the port on the device that Ethernet 0/3 connects to has one of these
adminstrative modes
A general best practice is to set the interface to trunk or access and nonegotiate when a trunk link is
required. On links where trunking is not intended, DTP should be turned off.
You can configure DTP mode to turn off the protocol or to instruct it to negotiate a trunk link only under
certain conditions, as described in the table.

Mode Function
dynamic auto Creates the trunk, based on the DTP request from the neighboring sw itch.
dynamic desirable Communicates to the neighboring sw itch via DTP that the interface is attempting to become
a trunk if the neighboring sw itch interface is able to become a trunk.
trunk Automatically enables trunking regardless of the state of the neighboring sw itch and
regardless of any DTP requests sent from the neighboring sw itch.
access Trunking not allow ed on this port regardless of the state of the neighboring sw itch interface
and regardless of any DTP requests sent from the neighboring sw itch.
nonegotiate Prevents the interface from generating DTP frames. This command can be used only w hen
the interface sw itch port mode is access or trunk. You must manually configure the
neighboring interface as a trunk interface to establish a trunk link.
The switchport nonegotiate interface command specifies that DTP negotiation packets are not sent. The
switch does not engage in DTP negotiation on this interface. This command is valid only when the interface
switchport mode is access or trunk (configured by using the switchport mode access or the switchport
mode trunk interface configuration command). This command returns an error if you attempt to execute it
in dynamic (auto or desirable) mode. Use the no form of this command to return to the default setting.
When you configure a port with the switchport nonegotiate command, the port trunks only if the other end
of the link is specifically set to trunk. The switchport nonegotiate command does not form a trunk link
with ports in either dynamic desirable or dynamic auto mode.

Deploying VLANs
You can design an enterprise campus network with one of two models: end-to-end VLANs or local VLANs.
Each model has its own advantages and disadvantages.
The term end-to-end VLAN refers to a single VLAN that is associated with switch ports that are widely
dispersed throughout an enterprise network on multiple switches. A Layer 2 switched campus network
carries traffic for this VLAN throughout the network.

An end-to-end VLAN model has these characteristics:
• Each VLAN is dispersed geographically throughout the network.
• Users are grouped into each VLAN regardless of physical location.
• As a user moves throughout a campus, the VLAN membership of that user remains the same, regardless
of the physical switch this user attaches to.
• Users are typically associated with a given VLAN for network management reasons. This is why they
are kept in the same VLAN, and therefore in the same group, as they move through the campus.
• All devices on a given VLAN typically have addresses on the same IP subnet.
The Cisco Enterprise Campus Architecture is based on the local VLAN model. In this VLAN model, all
users of a set of geographically common switches are grouped into a single VLAN, regardless of the
organizational function of those users. Local VLANs are generally confined to a wiring closet. If users
move from one location to another in the campus, their connection is changes to the new VLAN at the new
physical location.
In the local VLAN model, Layer 2 switching is used at the access level, and routing is used at the
distribution and core levels to allow users to maintain access to the resources they need.
Here are some local VLAN characteristics and user guidelines:

• You should create local VLANs with physical boundaries in mind rather than the job functions of the
users on the end devices.
• Traffic for the local VLAN is Layer 2-switched between the access and distribution levels.
• Traffic from a local VLAN is routed at the distribution and core levels to reach destinations on other
networks.
• A network that consists entirely of local VLANs can benefit from increased convergence times that are
offered via routing protocols, instead of STP for Layer 2 networks.

End-to-End vs. Local VLANs
In the past, network designers have attempted to implement the 80-20 rule when designing networks. The
rule was based on the observation that, in general, 80 percent of the traffic on a network segment was passed
between local devices, and only 20 percent of the traffic was destined for remote network segments.
Therefore, end-to-end VLANs were typically used. Designers now consolidate servers in central locations
on the network and provide access to external resources such as the Internet through one or two paths on the
network because the bulk of traffic now traverses a number of segments. Therefore, the paradigm now is
closer to a 20-80 proportion, in which the greater flow of traffic leaves the local segment, so local VLANs
have become more efficient.
Because a VLAN represents a Layer 3 segment, each end-to-end VLAN allows a single Layer 3 segment to
be dispersed geographically throughout the network. These could be some of the reasons for implementing
this design:
• Grouping users: Users can be grouped on a common IP segment, even though they are geographically
dispersed.
• Security: A VLAN may contain resources that should not be accessible to all users on the network, or
there may be a reason to confine certain traffic to a particular VLAN.
• Applying QoS: Traffic from a given VLAN can be given a higher or lower access priority to network
resources.
• Routing avoidance: If much of the VLAN user traffic is destined for devices on that same VLAN and
routing to those devices is not desirable, users can access resources on their VLAN without their traffic
being routed off the VLAN, even though the traffic may traverse multiple switches.
• Special-purpose VLAN: Sometimes a VLAN is provisioned to carry a single type of traffic that must
be dispersed throughout the campus (for example, multicast, voice, or visitor VLANs).

• Poor design: For no clear purpose, users are placed in VLANs that span the campus or even span
WANs.
Here are some items that you should consider when implementing end-to-end VLANs:
• Switch ports are provisioned for each user and are associated with a given VLAN. Because users on an
end-to-end VLAN may be anywhere in the network, all switches must be aware of that VLAN. This
means that all switches carrying traffic for end-to-end VLANs are required to have those specific
VLANs defined in the VLAN database of each switch.
• Flooded traffic for the VLAN is, by default, passed to every switch even if it does not currently have
any active ports in the particular end-to-end VLAN.
• Troubleshooting devices on a campus with end-to-end VLANs can be challenging because the traffic
for a single VLAN can traverse multiple switches in a large area of the campus.
The concept of end-to-end VLANs was very attractive when IP address configuration was a manually
administered and burdensome process; therefore, anything that reduced this burden as users moved between
networks was an improvement. However, given the ubiquity of DHCP, the process of configuring an IP
address at each desktop is no longer a significant issue. As a result, there are few benefits to extending a
VLAN throughout an enterprise.
Local VLANs are part of the enterprise campus architecture design, in which VLANs that are used at the
access layer should extend no farther than their associated distribution switch. Traffic is routed from the
local VLAN as it is passed from the distribution layer into the core. This design can mitigate Layer 2
troubleshooting issues that occur when a single VLAN traverses the switches throughout an enterprise
campus network. Implementing the enterprise campus architecture design using local VLANs provides
these benefits:
• Deterministic traffic flow: The simple layout provides a predictable Layer 2 and Layer 3 traffic path.
In the event of a failure that was not mitigated by the redundancy features, the simplicity of the model
facilitates expedient problem isolation and resolution within the switch block.
• Active redundant paths: When implementing PVST or MST, you can use all links to make use of the
redundant paths.
• High availability: Redundant paths exist at all infrastructure levels. Local VLAN traffic on access
switches can be passed to the building distribution switches across an alternative Layer 2 path in the
event of primary path failure. Router redundancy protocols can provide failover should the default
gateway for the access VLAN fail. When both the STP instance and VLAN are confined to a specific
access and distribution block, then Layer 2 and Layer 3 redundancy measures and protocols can be
configured to failover in a coordinated manner.
• Finite failure domain: If VLANs are local to a switch block, and the number of devices on each
VLAN is kept small, failures at Layer 2 are confined to a small subset of users.
• Scalable design: Following the enterprise campus architecture design, you can easily incorporate new
access switches, and add new submodules when necessary.

Voice VLAN Overview
Some Cisco Catalyst switches offer a unique feature called voice VLAN, which lets you overlay a voice
topology onto a data network. You can segment phones into separate logical networks, even though the data
and voice infrastructure are physically the same.
The voice VLAN feature places the phones into their own VLANs without any end-user intervention. These
VLAN assignments can be seamlessly maintained, even if the phone is moved to a new location.
The user simply plugs the phone into the switch, and the switch will provide the phone with the necessary
VLAN information. By placing phones into their own VLANs, network administrators gain the advantages
of network segmentation and control. Furthermore, network administrators can preserve their existing IP
topology for the data end stations. IP phones can be easily assigned to different IP subnets using standards-
based DHCP operation.
With the phones in their own IP subnets and VLANs, network administrators can more easily identify and
troubleshoot network problems. In addition, network administrators can create and enforce QoS or security
policies.

With the voice VLAN feature, Cisco enables network administrators to gain all the advantages of physical
infrastructure convergence while maintaining separate logical topologies for voice and data terminals. This
ability offers the most effective way to manage a multiservice network.
Multiservice switches support a new parameter for IP telephony support that makes the access port a multi-
VLAN access port. The new parameter is called a voice or auxiliary VLAN. Every Ethernet 10/100/1000
port in the switch is associated with two VLANs:
• A native VLAN for data service that is identified by the PVID
• A voice VLAN that is identified by the VVID
− During the initial Cisco Discovery Protocol exchange with the access switch, the IP
phone is configured with a VVID.
− The IP phone is also supplied with a QoS configuration using Cisco Discovery Protocol.
Data packets between the multiservice access switch and the PC or workstation are on the native VLAN. All
packets going out on the native VLAN of an IEEE 802.1Q port are sent untagged by the access switch. The
PC or workstation connected to the IP phone usually sends untagged packets.
The IP phone tags voice packets based on the Cisco Discovery Protocol information from the access switch.
The multi-VLAN access ports are not trunk ports, even though the hardware is set to the dot1q trunk. The
hardware setting is used to carry more than two VLANs, but the port is still considered an access port that is
able to carry one native VLAN and the voice VLAN. The switchport host command can be applied to a
multi-VLAN access port on the access switch.

Voice VLAN Configuration
In the example above, interface Fa0/1 is configured to set data devices in data VLAN 10 and VoIP devices
in voice VLAN 110.
When running the show vlan command, both the voice and the data VLAN are seen as applied to the
interface Fa0/1.
Switch# show vlan

---- -------------------------------- --------- -----------------
1 default active Fa0/6,Fa0/7,Fa0/8,
Fa0/9,Fa0/10
10 VLAN0010 active Fa0/1
110 VLAN0110 active Fa0/1
You can verify the switch port mode and the voice VLAN by using the show interface interface
slot/number switchport command.

Switch Configuration for Wireless Network
Support
Cisco offers two WLAN implementations:
• The standalone WLAN solution is based on standalone APs.
• The controller-based WLAN solution is based on controller-based APs and WLCs (Wireless LAN
Controllers).
In the autonomous (or standalone) solution, each AP operates independently and acts as a transition point
between the wireless media and the 802.3 media. The data traffic between two clients flows via the Layer 2
switch when on the same subnet from a different AP infrastructure. As the AP converts the IEEE 802.11
frame into an 802.3 frame, the wireless client MAC address is transferred to the 802.3 header and appears as
the source for the switch. The destination, also a wireless client, appears as the destination MAC address.
For the switch, the APs are relatively transparent.
In a controller-based solution, management, control, deployment, and security functions are moved to a
central point - the wireless controller. Controllers are combined with lightweight access points that perform
only the real-time wireless operation. Controllers can be standalone devices, integrated into a switch, or
wireless LAN controller can be virtualized.
Both, standalone and lightweight access points connect to a switch. It is very common that the switch is
PoE-able and thus APs get power and data through the Ethernet cable. This makes the wireless network
more scalable and easier to manage.
To implement a wireless network, access points and switches need to be configured. Access points can be
configured directly (autonomous access points) or through a controller (lightweight access points). Either
way, configuring access points is a domain of the WLAN specialist. You need to configure VLANs and
trunks on switches in order to support WLAN solution.

Summary

Lesson 2: Introducing VTP
Overview
VTP is a Cisco proprietary protocol that manages VLANs. When you configure a new VLAN on one VTP
server, the VLAN is distributed through all switches in the domain.
If used with care, VTP can reduce the need to configure the same VLAN everywhere. If you are not aware
of all caveats, it can cause havoc on your network.
• Explain the basic idea behind the VLAN Trunking Protocol
• Describe VTP modes
• Describe VTP operation
• Describe VTP versions
• Describe default VTP configuration on Cisco Catalyst switches
• Describe the dangers of VTP
• Configure transparent VTP mode

The Role of VLAN Trunking Protocol
VTP is a Layer 2 protocol that maintains VLAN configuration consistency by managing the additions,
deletions, and name changes of VLANs across networks.
VTP domain is one switch or several interconnected switches sharing the same VTP environment. You can
configure a switch to be in only one VTP domain.
By default, a Cisco Catalyst switch is in the no-management-domain state or "<null>" until it receives and
advertisement for a domain over a trunk link or until you configure a management domain. Configurations
that are made on a single VTP server are propagated across trunk links to all of the connected switches in
the network. Configurations will be exchanged if VTP domain and VTP passwords match.
VTP is a Cisco proprietary protocol.

VTP Modes
VTP operates in one of three modes: server, transparent, or client. On some switches VTP can also be
completely disabled.
The characteristics of the three VTP modes are as follows:

• Server: The default VTP mode is server mode, but VLANs are not propagated over the network until a
management domain name is specified or learned. When you make a change to the VLAN
configuration on a VTP server, the change is propagated to all switches in the VTP domain. VTP
messages are transmitted out of all the trunk connections.
• Transparent: When you make a change to the VLAN configuration in VTP transparent mode, the
change affects only the local switch. The change does not propagate to other switches in the VTP
domain. VTP transparent mode does forward VTP advertisements that it receives within the domain.
• Client: A VTP client behaves like a VTP server and transmits and receives VTP updates on its trunks,
but you cannot create, change, or delete VLANs on a VTP client. VLANs are configured on another
switch in the domain that is in server mode.
In the Server, Transparent, and Client modes, VTP advertisements are received and transmitted as soon as
the switch enters the management domain state. In the VTP Off mode, switches behave the same as in VTP
transparent mode with the exception that VTP advertisements are not forwarded. Off mode is not available
in all releases.
Cisco Internetwork Operating System VTP servers and clients save VLANs to the vlan.dat file in flash
memory, causing them to retain the VLAN table and revision number. Switches that are in VTP transparent
mode display the VLAN and VTP configurations in the show running-config command output because this
information is stored in the configuration text file. If you perform erase startup-config on a VTP
transparent switch you will delete its VLANs.

Note The erase startup-config command does not affect the vlan.dat file on switches in VTP
Client and Server modes. Delete the vlan.dat file and reload the switch to clear the VTP and
VLAN information. See documentation for your specific switch model to determine how to
delete the vlan.dat file
Discovery 3: VTP Operation
Overview
This discovery will teach you about the VTP operation.
Topology
Job Aids
Device Information
Device Interface Neighbor Interface On The Neighbor
Sw itch1 Ethernet 0/1 Sw itch2 Ethernet 0/1
Sw itch2 Ethernet 0/2 Sw itch3 Ethernet 0/2
VTP Operation
This is the VTP setup on the three switches in this lab:
Step 1 Issue show vtp status command on Switch1.
Switch1 is configured as a VTP client.

There are only five VLANs present on the switch. These five VLANs are on the switch by
default: VLAN1 and 1002-1005.
The VTP revision is 0. Revision 0 means that no changes were made to the VLAN database on
this switch so far. Every time that you make a change to the VLAN database (add, remove,
modification) the revision will increase by one.
Switch1 is in VTP domain "CCNP".
Switch1# show vtp status
VTP Version capable : 1 to 3
VTP version running : 1
VTP Domain Name :CCNP
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : aabb.cc00.5600
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Feature VLAN:
--------------
VTP Operating Mode : Client
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
Configuration Revision : 0
MD5 digest : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
0x56 0x9D 0x4A 0x3E 0xA5 0x69 0x35 0xBC
Switch2 is configured as VTP server.

Like on Switch1 only default VLANs are present, VTP revision is 0, and the VTP domain is set
to "CCNP".
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
--------------
VTP Operating Mode : Server
0x56 0x9D 0x4A 0x3E 0xA5 0x69 0x35 0xBC
Switch3 is configured for VTP transparent mode.

Like on Switch1 and Switch2 only default VLANs are present, VTP revision is 0, and the VTP
domain is set to "CCNP".
Feature VLAN:
--------------
VTP Operating Mode : Transparent
0x56 0x9D 0x4A 0x3E 0xA5 0x69 0x35 0xBC
Step 4 Create VLAN 10 on Switch2.
Switch2 is VTP server mode. You should be allowed to add VLAN 10 to the Switch2 database.
Switch2# configure terminal

Switch2(config)# vlan 10
Note
Note that if you try to add a VLAN on a VTP client you will not be allowed. For example, if you tried to
add VLAN 5 to Switch1 you would get the following message:
VTP VLAN configuration not allowed when device is in CLIENT mode.
Step 5 Verify VLAN database and VTP status on Switch2.
Use commands show vlan and show vtp status.

Switch2 now has VLAN 10 in the database:
Switch2# show vlan

---- -------------------------------- --------- -------------------------------
Et1/2, Et1/3, Et2/0, Et2/1
Et2/2, Et2/3, Et3/0, Et3/1
Et3/2, Et3/3, Et4/0, Et4/1
Et4/2, Et4/3, Et5/0, Et5/1
Et5/2, Et5/3
10 VLAN0010 active
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1 enet 100001 1500 - - - - - 0 0
10 enet 100010 1500 - - - - - 0 0
1002 fddi 101002 1500 - - - - - 0 0
1003 tr 101003 1500 - - - - - 0 0
1004 fdnet 101004 1500 - - - ieee - 0 0
1005 trnet 101005 1500 - - - ibm - 0 0

------- --------- ----------------- ------------------------------------------
The revision number increased by one on Switch2:

VTP Domain Name :
Feature VLAN:
--------------
MD5 digest : 0xB1 0xBE 0x72 0x49 0x96 0x6D 0x99 0xA4
0xB4 0xDC 0x94 0x56 0xD4 0xC2 0x6A 0xBB
But the real question is now, did changes in Switch2's database propagate to Switch1 and
Switch2?
Step 6 Verify changes in VLAN database and VTP status on Switch1.

Because Switch1 is a VTP client, VLAN 10 got replicated from Switch2:
Switch1# show vlan

---- -------------------------------- --------- -------------------------------
Et1/1, Et1/2, Et1/3, Et2/0
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
10 VLAN0010 active
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1 enet 100001 1500 - - - - - 0 0
10 enet 100010 1500 - - - - - 0 0
20 enet 100020 1500 - - - - - 0 0
1002 fddi 101002 1500 - - - - - 0 0
1003 tr 101003 1500 - - - - srb 0 0
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1004 fdnet 101004 1500 - - - ieee - 0 0
1005 trnet 101005 1500 - - - ibm - 0 0

------- --------- ----------------- ------------------------------------------
The revision number on Switch1 is now the same as on Switch2. This indicates they have an
identical VLAN database.

VTP Domain Name : CCNP
Feature VLAN:
--------------
MD5 digest : 0xDF 0x2B 0x3B 0x5D 0x0E 0x8E 0x10 0x17
0x6D 0xDD 0xE2 0x45 0x7F 0x91 0x95 0x9E
Step 7 Verify changes in VLAN database and VTP status on Switch3.
Switch3 is in VTP transparent mode. Switch in transparent mode does never synchronize
database to that of the VTP server. In essence enabling VTP transparent mode disables VTP.
Notice that there is no VLAN 10 on Switch3.
Switch3# show vlan

---- -------------------------------- --------- -------------------------------
Et1/1, Et1/2, Et1/3, Et2/0
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1 enet 100001 1500 - - - - - 0 0
1002 fddi 101002 1500 - - - - - 0 0
1003 tr 101003 1500 - - - - - 0 0
1004 fdnet 101004 1500 - - - ieee - 0 0
1005 trnet 101005 1500 - - - ibm - 0 0

------- --------- ----------------- ------------------------------------------
The revision number on a VTP transparent switch will always be at 0:

Feature VLAN:
--------------
VTP Operating Mode : Transparent
MD5 digest : 0xC8 0x7E 0xBB 0x23 0xCB 0x0D 0xFA 0xCE
0xDB 0xC1 0x0F 0x96 0xF6 0xCA 0x8B 0xAA
VTP Advertisements
VTP advertisements are flooded throughout the management domain. VTP advertisements are sent every 5
minutes or whenever there is a change in VLAN configurations. Advertisements are transmitted (untagged)
over the native VLAN (VLAN 1 by default) using a multicast frame. A configuration revision number is
included in each VTP advertisement. A higher configuration revision number indicates that the VLAN
information being advertised is more current than the stored information.
One of the most critical components of VTP is the configuration revision number. Each time a VTP server
modifies its VLAN information, the VTP server increments the configuration revision number by one. The
server then sends out a VTP advertisement with the new configuration revision number. If the configuration
revision number being advertised is higher than the number stored on the other switches in the VTP domain,
the switches overwrite their VLAN configurations with the new information that is being advertised.
The configuration revision number in VTP transparent mode is always zero.
Note In the overwrite process, if the VTP server deleted all of the VLANs and had the higher
revision number, the other devices in the VTP domain would also delete their VLANs.
A device that receives VTP advertisements must check various parameters before incorporating the received
VLAN information. First, the management domain name and password in the advertisement must match
those values that are configured on the local switch. Next, if the configuration revision number indicates
that the message was created after the configuration currently in use, the switch incorporates the advertised
VLAN information.
On many Cisco Catalyst switches, you can change the VTP domain to another name and then change it back
to reset the configuration revision number, or alternatively, change the mode to transparent and then back to
the previous setting.
Step 8 Create VLAN 20 on Switch3.
Step 9 Investigate VLAN databases on all three switches. Is VLAN 20 present on all three?
Use the show vlan command.
Switch1# show vlan

---- -------------------------------- --------- -------------------------------
Et1/1, Et1/2, Et1/3, Et2/0
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
10 VLAN0010 active
Switch2# show vlan

---- -------------------------------- --------- -------------------------------
Et1/2, Et1/3, Et2/0, Et2/1
Et2/2, Et2/3, Et3/0, Et3/1
Et3/2, Et3/3, Et4/0, Et4/1
Et4/2, Et4/3, Et5/0, Et5/1
Et5/2, Et5/3
10 VLAN0010 active
Switch3# show vlan

---- -------------------------------- --------- -------------------------------
Et1/1, Et1/2, Et1/3, Et2/0
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
20 VLAN0020 active
While a switch is in VTP transparent mode, it can create and delete VLANs that are local only to
itself. These VLAN changes are not propagated to any other switch.
In this example, VLAN 20 is only present in the VLAN database of Switch3 - the VTP
transparent switch, on which you created the VLAN.
VTP Versions
Three different VTP versions exist: 1, 2, and 3.
The default VTP version that is enabled on a Cisco switch is version 1. You can change the switch to run
VTP version 2, but the two versions are not compatible. You need to configure the same VTP version on
every switch in the domain.
If you want to enable version 2 in your domain the only thing you need to do is to enable it on the VTP
server and the change will propagate throughout the network.
VTP version 2 offers the following features that version 1 does not:
• Version-dependent transparent mode - In VTP version 1, a VTP transparent network device inspects
VTP messages for the domain name and version, and forwards a message only if the version and
domain name match. Because only one domain is supported in the supervisor engine software, VTP
version 2 forwards VTP messages in transparent mode, without checking the version.
• Consistency check - In VTP version 2, VLAN consistency checks, such as VLAN names and values,
are performed. However, this is only done when you enter information through the CLI or SNMP.
Consistency checks are not performed when new information is obtained from a VTP message or when
information is read from NVRAM. If the digest on a received VTP message is correct, its information is
accepted without consistency checks.
• Token ring support - VTP version 2 supports Token Ring LAN switching and VLANs.
• Unrecognize Type-Length-Value support - VTP version 2 switches propagate received configuration
change messages out other trunk links, even if they are not able to understand the message. Instead of
dropping the unrecognized VTP message, version 2 still propagates the information and keeps a copy in
NVRAM.
VTP version 3 brings:

• Extended VLAN support: VTP can be used to propagate also VLANs with numbers 1017-4094
(1006-1017 and 4095-2096 are reserved).
• Domain name is not automatically learned: With VTPv2, a factory default switch that receives a
VTP message will adapt the new VTP domain name. Since this is a very dangerous behavior, VTPv3
forces manual configuration.
• Better security: VTP domain password is secured during transmission and in the switch's database.
• Better database propagation. Only the primary server is allowed to update other devices and only one
server per VTP domain is allowed to have this role.
• MST support: VTPv3 adds support for propagation of Multiple-Spanning Tree instances.
Note VTPv3 is not compatible with VTPv1. VTPv3 is compatible with VTPv2 as long as you are
not using it to propagate private or extended VLANs.
Note VTP Version 3 right now has very limited device/software support.
VTP version is changed using the following global configuration command:

vtp version 1 | 2 | 3
To verify VTP version in use on a switch use the show vtp status command:
VTP Domain Name :
Default VTP Configuration
Default VTP configuration values depend on the switch model and the software version.
When creating VLANs, you must decide whether to use VTP in your network. With VTP, you can make
configuration changes on one or more switches, and those changes are automatically communicated to all
other switches in the same VTP domain.
The VTP domain name can be specified or learned. By default, the domain name is <Null>. You can set a
password for the VTP management domain. However, if you do not assign the same password for each
switch in the domain, VTP will not function properly. MD5 hashing is used for VTP passwords.
Note The domain name cannot be reset to <Null> except if the database is deleted. The domain
name can only be re-assigned.
Note The domain name and password are case sensitive.
Overwriting VTP Configuration
The configuration revision number is used when determining if a switch should keep its existing VLAN
database or overwrite it with the VTP update sent by another switch in the same domain with the same
password. Therefore, when a switch is added to a network, it is important that it does not inject spurious
information into the domain.
Example shows a network running VTP. SW1 is VTP server, other two switches are VTP clients. VTP
version 1 is used on all devices.
All devices have the same VTP domain "CCNP" configured and are synchronized to VTP revision 12. Thus
they all have the same user-created VLANs in their databases: 10, 20, 30, and 40.
SW1# show vtp status
Device ID : aabb.cc00.5a00
Feature VLAN:
--------------
MD5 digest : 0x11 0x31 0x4F 0x6A 0x96 0x0D 0xB6 0xB9
0xAE 0xF4 0xD4 0x85 0x4D 0x58 0xC8 0x4D
SW1# show vlan

---- -------------------------------- --------- -------------------------------
Et2/2, Et2/3, Et3/0, Et3/1
Et3/2, Et3/3, Et4/0, Et4/1
Et4/2, Et4/3, Et5/0, Et5/1
Et5/2, Et5/3
10 VLAN0010 active
20 VLAN0020 active Et1/2
40 VLAN0040 active
<... ouput omitted ...>

Feature VLAN:
--------------
SW2# show vlan

---- -------------------------------- --------- -------------------------------
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
20 VLAN0020 active
30 VLAN0030 active
40 VLAN0040 active

Feature VLAN:
--------------
SW3# show vlan

---- -------------------------------- --------- -------------------------------
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
30 VLAN0030 active
<... output omitted...>
Switch SW2 failed. You pull out an old switch out of the closet and plug it in place of SW2.
You configure port that connects to SW1 as trunk, create VLAN 10 and assign the port that connects to
PC2A to VLAN 10:
Replacement(config)# interface Ethernet 0/1
Replacement(config-if)# switchport trunk encapsulation dot1q
Replacement(config-if)# switchport mode trunk
Replacement(config-if)# exit
Replacement(config)# vlan 10
Replacement(config-vlan)# exit
Replacement(config)# interface Ethernet 1/1
Replacement(config-if)# switchport mode access
Replacement(config-if)# switchport access vlan 10
However, you forget to erase the configuration and VLAN database.

The replacement switch has the same VTP domain name configured as other two switches. VTP revision
number on the replacement switch is 29-higher than the revision on other two switches:
Replacement# show vtp status
Feature VLAN:
--------------
MD5 digest : 0x29 0xF2 0x1F 0xA5 0x41 0x44 0x04 0xAC
0x08 0x3B 0x9A 0x2C 0x73 0x8A 0xA2 0xBD
The replacement switch does not have VLANs 20, 30, and 40 in its database.
Replacement# show vlan

---- -------------------------------- --------- -------------------------------
Et2/0, Et2/1, Et2/2, Et2/3
Et3/0, Et3/1, Et3/2, Et3/3
Et4/0, Et4/1, Et4/2, Et4/3
Et5/0, Et5/1, Et5/2, Et5/3
11 VLAN0011 active
22 VLAN0022 active
33 VLAN0033 active
44 VLAN0044 active
Since SW2 has higher revision number, SW1 and SW3 will sync to the latest revision.
The consequence is that VLANs 20, 30, and 40 no longer exist on SW1 and SW2. This leaves the clients
that are connected to ports belonging to non-existing VLANs without connectivity
Feature VLAN:
--------------
SW1# show vlan

---- -------------------------------- --------- -------------------------------
Et2/2, Et2/3, Et3/0, Et3/1
Et3/2, Et3/3, Et4/0, Et4/1
Et4/2, Et4/3, Et5/0, Et5/1
Et5/2, Et5/3
10 VLAN0010 active
11 VLAN0011 active
22 VLAN0022 active
33 VLAN0033 active
44 VLAN0044 active

Feature VLAN:
--------------
SW3# show vlan

---- -------------------------------- --------- -------------------------------
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
11 VLAN0011 active
22 VLAN0022 active
33 VLAN0033 active
44 VLAN0044 active
You must balance the ease of VTP administration against the inherent risk of a large STP domain and the
potential instability and risks of STP. The greatest risk is an STP loop through the entire campus. If you
choose to use VTP, there are two things to which you must pay close attention:
• Remember the configuration revision and how to reset it each time that you insert a new switch in your
network so that you do not bring down the entire network.
• Avoid as much as possible to have a VLAN that spans the entire network.
The VTP revision number is stored in NVRAM and is not reset if you erase switch configuration and reload
it. To reset VTP revision number to zero you have two options:
• Change the switch's VTP domain to a nonexistent VTP domain and then change the domain back to the
original name.
• Change the switch's VTP mode to transparent and then back to previous VTP mode.
You should be aware that also a VTP client with a high revision number can cause havoc in your network!
VTP client as a general rule just listens to VTP advertisements from VTP servers and it does not do it's own
advertisements. However when you first connect a VTP client to a network it will send a summary
advertisement from its own stored database. If the VTP client gets an inferior advertisement from the VTP
server it will assume it has better, more current, information. VTP client will now send out advertisements
with greater revision number, VTP server and all directly connected VTP clients will accept these as more
up-to-date.
VTP Configuration Recommendation
You can use a VTP client/server mode to automatically propagate VLAN definitions across the switched
network. This mode is often used in a new network to facilitate the implementation of new VLANs.
However, as the network grows larger, this benefit can turn into a liability
If a VLAN is deleted by accident on one server, it is deleted throughout the network. If a switch that already
has a VLAN database defined is inserted into the network, it can hijack the VLAN database by deleting
added VLANs. For this reason, the recommended practice is to configure all switches to transparent VTP
mode and manually add VLANs as needed.
Com m and Description
vtp password password The 16-byte secret value that is used in MD5 digest
calculation to be sent in VTP advertisements and to
validate received VTP advertisements. The passw ord can
be an ASCII string from 1 to 32 characters and is case-
sensitive. This step is optional, but it ensures that dynamic
update w ill not occur before the VTP mode and domain are
properly configured.
vtp domain domain_name Sets the VTP domain name. Enter an ASCII string from 1
to 32 characters to identify the VTP administrative domain
for the sw itch. The domain name is case-sensitive.
vtp mode transparent Places the sw itch in transparent mode. It cannot affect
VLAN configurations on other devices in the netw ork. The
sw itch receives VTP advertisements and forw ards them on
all trunk ports except the one on w hich the advertisement
w as received.
Summary
DHCP
Overview
DHCP is a network protocol that enables network administrators to manage and automate IP configuration
assignment. Without DHCP, administrators must manually assign and configure IP addresses, subnet
masks, default gateways, etc., which can, in larger environments, become an excessive administrative
problem, especially if devices are moved from one internal network to another.
In an enterprise environment a DHCP server is usually a dedicated device whereas in smaller deployments
or some Branch offices it can be configured on a Cisco Catalyst switch or a Cisco router.
• Explain the idea behind DHCP
• Configure a DHCP server
• Configure manual DHCP bindings
• Configure a DHCP relay
• Configure DHCP options
DHCP Overview
DHCP provides configuration parameters to Internet hosts. It consists of two components: a protocol for
delivering host-specific configuration parameters from a DHCP server to a host, and a mechanism for
allocating network addresses to hosts. It is built on the client/server model where designated DHCP servers
allocate network addresses and deliver IP configuration parameters to dynamically configured hosts. By
default, Cisco multilayer switches that are running Cisco Internetwork Operating System Software include
DHCP server and relay agent software.
Distribution multilayer switches often act as Layer 3 gateways for clients that are connecting to the various
VLANs of access switches. Therefore, the DHCP service can be provided directly by the distribution
switches. Alternatively, DHCP services can be concentrated in an external, dedicated DHCP server. In that
case, distribution switches must redirect the incoming clients DHCP requests to the external DHCP server.
Discovery 4: Exploring DHCP
Overview
In this discovery you will learn how to configure a DHCP service on a switch. You will also configure a
manual binding for one of the DHCP clients.
Topology
Job Aids
Device Information
Device Interface IP Address
DSW1 VLAN 1 10.0.1.1/24
DSW1 VLAN 10 10.0.10.1/24
Exploring DHCP
Step 1 Access DSW1. Configure a DHCP server for VLAN 10 devices.
Only after the switch has a Layer 3 address, which is preconfigured in this example, you can
configure a DHCP server on the switch. The switch acting as a DHCP server, will intercept
broadcast packets from client machines within a VLAN.
DSW1(config)# ip dhcp excluded-address 10.0.10.1
DSW1(config)# ip dhcp pool VLAN10POOL
DSW1(config-dhcp)# network 10.0.10.0 255.255.255.0
DSW1(config-dhcp)# default-router 10.0.10.1
DSW1(config-dhcp)# lease 2
Command Description
ip dhcp excluded-address start-ip If there are addresses within the IP subnet
end-ip that should not be offered to DHCP clients,
this command will make sure that the
specified addresses are not offered. In the
example 10.0.10.1 was excluded from the DHCP
pool since this is the IP address of the
Layer 3 interface on DSW1.
ip dhcp pool pool-name The pool-name parameter defines a DHCP pool.
Using this command, you enter the DHCP
configuration mode.
network ip-address subnet-mask Specifies the address range through IP
subnet and subnet mask. The network command
will bind the DHCP server to matching Layer
3 interface. In the example DHCP server
"VLAN10POOL" is binded to "VLAN 10"
interface. Broadcast and network IPs are not
offered to clients. You can assign multiple
subnets per pool.
default-router ip-address [ip-address2] Sets the default router address that will be
[ip-address3] ... offered to clients. In the example this is
the IP address of the Layer 3 interface on
the switch.
lease {infinite | {days [hours [minutes]]}} Sets IP address lease duration. By default
IP address is leased to a client for 1 day.
In the example it is set to 2 days.
Step 2 On DSW1 verify the configured DHCP pool using the show ip dhcp pool command.
DSW1# show ip dhcp pool
Pool VLAN10POOL :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 0
Excluded addresses : 1
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased/Excluded/Total
10.0.10.1 10.0.10.1 - 10.0.10.254 0 / 1 / 254
Notice that no addresses are leased to the clients right now.

Excluded IP address are not part of the show ip dhcp pool output.
Step 3 Enable DHCP packet debugging on DSW1.
DSW1# debug ip dhcp server packet

DHCP server packet debugging is on.
Step 4 Configure PC1 interface Ethernet 0/0 to acquire an IP address via DHCP and observe CLI output
on DSW1.
The port on SW1 to which PC1 is connected to is already assigned to VLAN 10, so PC1 will get
an IP from VLAN 10 subnet.

PC1(config-if)# ip address dhcp
PC1(config-if)# no shutdown
As soon as you enable the interface on PC1 it will send a broadcast, requesting an IP.
DSW1#
*Oct 3 11:21:52.364: %SYS-5-CONFIG_I: Configured from console by console
DSW1#
*Oct 3 11:23:09.256: DHCPD: Reload workspace interface Vlan10 tableid 0.
*Oct 3 11:23:09.256: DHCPD: tableid for 10.0.10.1 on Vlan10 is 0
*Oct 3 11:23:09.256: DHCPD: client's VPN is .
*Oct 3 11:23:09.256: DHCPD: using received relay info.
*Oct 3 11:23:09.256: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d
61.6162.622e.6363.3030.2e34.3830.302d.4574.302f.30 on interface Vlan10.
*Oct 3 11:23:09.256: DHCPD: using received relay info.
DSW1#
*Oct 3 11:23:11.264: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d61.616
2.622e.6363.3030.2e34.3830.302d.4574.302f.30 (10.0.10.2).
*Oct 3 11:23:11.264: DHCPD: no option 125
*Oct 3 11:23:11.264: DHCPD: broadcasting BOOTREPLY to client aabb.cc00.4800.
*Oct 3 11:23:11.265: DHCPD: Reload workspace interface Vlan10 tableid 0.
*Oct 3 11:23:11.265: DHCPD: tableid for 10.0.10.1 on Vlan10 is 0
*Oct 3 11:23:11.265: DHCPD: client's VPN is .
*Oct 3 11:23:11.265: DHCPD: DHCPREQUEST received from client 0063.6973.636f.2d6
1.6162.622e.6363.3030.2e34.3830.302d.4574.302f.30.
DSW1#
*Oct 3 11:23:11.265: DHCPD: Sending DHCPACK to client 0063.6973.636f.2d61.6162.
622e.6363.3030.2e34.3830.302d.4574.302f.30 (10.0.10.2).
*Oct 3 11:23:11.265: DHCPD: no option 125
*Oct 3 11:23:11.265: DHCPD: broadcasting BOOTREPLY to client aabb.cc00.4800.
DSW1#
The debug shows you the whole DHCP negotiation process.
DHCP Negotiation
In the DHCP process, the client sends a DHCPDISCOVER broadcast message to locate a Cisco IOS DHCP
server. A DHCP server offers configuration parameters to the client in a DHCPOFFER unicast message.
Typical configuration parameters are an IP address, a domain name, and a lease for the IP address.
A DHCP client may receive offers from multiple DHCP servers and can accept any one of the offers;
however, the client usually accepts the first offer that it receives. Additionally, the offer from the DHCP
server is not a guarantee that the IP address will be allocated to the client; however, the server usually
reserves the address until the client has had a chance to formally request the address.
The client returns a formal request for the offered IP address to the DHCP server in a DHCPREQUEST
broadcast message. The DHCP server confirms that the IP address has been allocated to the client by
returning a DHCPACK unicast message to the client.
In addition to these four messages you can also see these DHCP messages with debug output:
• DHCPDECLINE - Message sent from the client to the server that the address is already in use.
• DHCPNAK - The server sends a refusal to the client for request for configuration.
• DHCPRELEASE - Client tells a server that it is giving up a lease.
• DHCPINFORM - A client already has an IP address but is requesting other configuration parameters
that the DHCP server is configured to deliver such as DNS address.
Step 5 Configure PC2 and PC3 to obtain IP address through DHCP.

Step 6 On DSW1 investigate the DHCP binding table.
DSW1# show ip dhcp binding

Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.0.10.2 0063.6973.636f.2d61. Oct 05 2013 03:23 AM Automatic
6162.622e.6363.3030.
2e34.3830.302d.4574.
302f.30
6162.622e.6363.3030.
2e34.6130.302d.4574.
302f.30
6162.622e.6363.3030.
2e34.3930.302d.4574.
302f.30
Notice that the DHCP server leased three IP addresses.

You could also verify that the three clients acquired IP addresses by issuing the show ip
interface brief command on each client.
Note
There are times when a manually assigned IP address is preferred. For example, it is beneficial for your
servers to have an IP address that does not change.
Since you are using DHCP and with that assigning all IP addresses from a central point, it would be nice if
you could also assign a specific address to a specific device. And you can do that with DHCP as well.
Step 7 Find out PC3's client identifier.
When a Cisco router sends a DHCP Discover message, it will include a client identifier to
uniquely identify the device. You can use this value to configure a static binding.
DSW1# show ip dhcp binding 10.0.10.4

IP address Client-ID/ Lease expiration Type
Hardware address/
User name
6162.622e.6363.3030.
2e30.3630.302d.4574.
302f.30
If you do not like this long client identifier, you can also assign PC3 to use the MAC address as
the client identifier. You can do so by using the ip address dhcp client-id ethernet 0/0
command.
Step 8 On DSW1 clear IP DHCP binding table.
If you already have a binding for a client and you want to manually set its IP address you have to
clear the DHCP binding table.
DSW1(config)# clear ip dhcp binding 10.0.10.4
You could also delete all automatic address bindings. Because you will manually set only the
PC3's IP address, you only need to delete PC3's current IP address from the binding table.
Step 9 On DSW1 assign IP address of 10.0.10.200 to PC3.
You might have examples where it is needed for a client to have the same IP address all the time
because of some application requirements.
DSW1(config)# ip dhcp pool CLIENT3

DSW1(dhcp-config)# host 10.0.10.200 255.255.255.0
DSW1(dhcp-config)# client-identifier
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3630.302d.4574.302f.30
To configure a manual binding you first need to create a host pool, then specify the IP address of
the client and client identifier. Only a client with the specified client identifier will be assigned
this IP address.
At this moment Client 3 will not acquire the specified IP address. Client 3 will only request an IP
address after its lease expires or if it requests a renewal.
Note
Some devices, usually running Linux, do not send client identifiers with DHCP messages. In these cases
you can bind an IP address to a device using client's MAC address. Instead of using the client-identifier
number command use the hardware-address MAC-address command.
Step 10 Force PC3 to request a new lease from the DHCP server.

PC3(config-if)# shutdown
*Oct 3 18:25:17.680: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned
DHCP address 10.0.10.200, mask 255.255.255.0, hostname PC3
You are notified that the client acquired address 10.0.10.200 - the IP address which it was bound
to by using the client-identifier identifier command.
DHCP Relay
The DHCP service does not have to reside directly on the multilayer switch. Many networks use a
centralized DHCP server. In this case, the multilayer switch can redirect DHCP requests to the corporate
DHCP server.
In this configuration, several elements are involved:

• The multilayer switch must have a Layer 3 IP address that will receive the client DHCP request. This
address may be a router port or an SVI.
• An ip helper-address command must be configured on the multilayer switch Layer 3 interface.
When the switch receives a DHCP request in the form of a broadcast message from a client, the switch
forwards this request, as a unicast message, to the IP address that is specified in the ip helper-address
command. With this feature, the switch relays the dialog between the DHCP client and the DHCP server.
DHCP Options
Advanced configuration parameters and other control information are carried in tagged data items, also
known as DHCP options.
You can use DHCP options to "expand" the basic DHCP commands. For example lease command is one of
the basic commands that is used to set the duration of lease validity. With DHCP options you can modify
the behavior of leasing out IP addresses. For example you can change the lease renewal time using the
dhcp-renewall-time option.
Using options, you can also provide clients with additional information that cannot be passed down to the
clients through basic configuration.
Some common examples are:

• Option 43: vendor-encapsulated options, that enables vendors to have their own list of options on the
server. For example, you can use it to tell a lightweight Acces Point where the WLC is.
• Option 69: SMTP server, if you want to specify available SMTP servers to the client.
• Option 70: POP3 server, if you want to specify available POP3 servers to the client.
• Option 150: TFTP server, that enables your phones to access a list of TFTP servers.
For more information on DHCP options, visit:
http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/6.1.1/user/guide/UserApB.html#wp100423
8.
Summary
DHCP for IPv6
Overview
IPv6 defines both a stateful and stateless address autoconfiguration mechanism. The stateless mechanism
allows a host to generate its own addresses using a combination of locally available information and
information advertised by routers.
In IPv6 world there are two types of DHCPv6 - stateless and stateful. Stateful DHCPv6 is similar to
DHCPv4. Stateless DHCPv6 is used to supply additional parameters to clients that already have an IPv6
address. In addition to DHCPv6 IPv6 also has stateless autoconfiguration. This is a mechanism where a
client does not acquire an IPv6 address from a DHCP server, but from a next-hop Layer 3 device.
• Describe stateless autoconfiguration
• Describe DHCPv6
• Describe DHCPv6 operation
• Describe DHCPv6 Lite
• Configure stateless autoconfiguration
• Configure stateful DHCPv6
• Configure stateless DHCPv6
• Configure DHCPv6 relay agent
Stateless Autoconfiguration Overview
Stateless autoconfiguration allows serverless basic configuration of nodes. It requires no manual
configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless
mechanism allows a host to generate its own addresses using a combination of locally available information
and information that is advertised by routers.
Stateless autoconfiguration or SLAAC uses the information in the router advertisement messages to
configure the node. The prefix included in the router advertisement is used as the /64 prefix for the node
address. The other 64 bits are obtained by the dynamically created interface identifier, which, in case of
Ethernet, is the modified EUI-64 format. EUI-64 is split into two equal parts and "FFFE" is inserted
between them. In addition, the seventh bit from the left is flipped (i.e. if its 1 then it is turned into 0, and
vice versa).
Router advertisements are sent periodically. Instead of waiting for the next router advertisement to get the
information to configure its interfaces, a node sends a router solicitation message asking the routers on the
network to reply immediately with a router advertisement so that the node can immediately autoconfigure.
All the routers respond with a normal router advertisement message with the all-nodes multicast address as
the destination address.
On network initialization a node can obtain:
• IPv6 prefix(es)
• Default router address(es)
• Hop limit
• MTU
• Validity lifetime
DNS server address will be provided per RFC 6106, but it is not widely implemented yet.
The full Stateless autoconfiguration procedure looks like this:

• Client generates a link local address.
• Client does a DAD on the generated link local address.
• Client join all host-multicast group (FF02::01) and sends a Router Solicitation .
• Client creates global address. IPv6 addresses are usually based on NIC MAC address. Client creates a
global IPv6 address within each advertised /64 IPv6 prefix. There are provisions to prevent multiple
hosts on a LAN from configuring the same address.
• Client does a DAD on generated IPv6 address.
• Client sets a Default Router.
DHCPv6 Overview
DHCPv6 is an updated version of DHCP for use with IPv6. It supports the addressing model of IPv6.
DHCPv6 is a separate protocol from DHCP. DHCPv6 can only be used to obtain IPv6 addresses, and
DHCP can only be used to obtain IPv4 addresses. It is possible to run DHCP and DHCPv6 in parallel.
DHCPv6 gives you more control than stateless autoconfiguration. But you can also use the two methods
concurrently.
You can use DHCPv6 for automatic domain registration of hosts using DDNS.
Acquiring data for a client in DHCPv6 is like the process in IPv4 but with a few exceptions. The client can
sometimes detect the presence of routers on the link using neighbor discovery messages. If at least one
router is found the client examines the router advertisements to determine if DHCP should be used. If the
router advertisements allow the use of DHCP on that link or if no router is found, the client starts a DHCP
solicit phase to find a DHCP server.
When the client sends a solicit message, it sends the message to the all-DHCP-agents multicast address with
link-local scope. Agents include both servers and relays.
Some servers can be configured to give global addresses using policies. For example, "do not give to
printer".
DHCPv6 is described in RFC 3736.
DHCPv6 Operation
The operation of DHCPv6 is similar to that of DHCP for IPv4, but DHCPv6 is a completely different
protocol.
This is the DHCPv6 negotiation process:

1 The client sends a SOLICIT message to find a DHCPv6 server. This message is a mulitcast, not a
broadcast as in DHCPv4. A DHCPv6 client builds a list of potential servers by sending a solicit
message and collecting advertise message replies from servers. These messages are ranked based on
preference value, and servers may add a preference option to their advertise messages explicitly stating
their preference value. If the client needs to acquire prefixes from servers, only servers that have
advertised prefixes are considered.
2 DHCPv6 servers will respond with an ADVERTISE message. The DHCPv6 server can provide those
configuration parameters that do not require the server to maintain any dynamic state for individual
clients, such as DNS server addresses and domain search list options.
3 Client chooses one of the servers and sends a REQUEST message to it, asking to confirm the addresses
and other parameters that were advertised in the previous step. All the configuration parameters for
clients are independently configured into DHCPv6 configuration pools, which are stored in NVRAM.
4 The final message is a CONFIRM, where the server finalizes the process.
Like with DHCPv4, a DHCPv6 client renews its lease after a period of time by sending a RENEW message.
In addition to the four-way exchange, DHCPv6 can also use a shortened negotiation - two-way exchange.
The DHCPv6 client can obtain configuration parameters from a server either through a rapid two-message
exchange (SOLICIT, REPLY) or through a normal four-message exchange (SOLICIT, ADVERTISE,
REQUEST, REPLY). By default, the four-message exchange is used. When the rapid-commit option is
enabled by both client and server, the two-message exchange is used.
In some environments, such as those in which high mobility occurs and the network attachment point
changes frequently, it is beneficial to rapidly configure clients. And, in these environments it is possible to
more quickly configure clients because the protections offered by the normal (and longer) 4-message
exchange may not be needed. The 4-message exchange allows for redundancy (multiple DHCP servers)
without wasting addresses, as addresses are only provisionally assigned to a client until the client chooses
and requests one of the provisionally assigned addresses. The 2-message exchange may therefore be used
when only one server is present or when addresses are plentiful and having multiple servers commit
addresses for a client is not a problem.
Rapid-commit for DHCPv6 is defined in RFC 4039.
A binding table entry is automatically created whenever a prefix is delegated to a client from the
configuration pool. The binding table entry is updated when the client renews, rebinds, or confirms the
prefix delegation. It is deleted when the client releases all the prefixes in the binding voluntarily, the valid
lifetimes of all prefixes have expired, or administrators enable the clear ipv6 dhcp binding command.
DHCPv6 Lite Overview
DHCPv6 can run in stateless mode. This mode is also known as DHCPv6 Lite.
In stateless mode DHCPv6 does not assign addresses to clients. It only provides configuration information,
such as NTP servers, domain names, DNS servers, etc. If stateless DHCPv6 is used, clients must obtain
routable IPv6 addresses through some other means, such as stateless autoconfiguration.
DHCPv6 Lite is not supported on all platforms.
You can run stateless DHCPv6 in combination with stateful DHCPv6.
Stateless DHCPv6 is described in RFC 3736.
Discovery 5: Obtaining IPv6 Address Dynamically
Overview
In this discovery you will learn how to configure stateless autoconfiguration, DHCPv6, and DHCPv6 Lite.
Topology
Job Aids
IPv6 Addressing
Device Interface IPv6 Address
DSW1 VLAN 10 2001:DB8:A::1/64
DSW1 VLAN 20 2001:DB8:14::1/64
DSW1 VLAN 30 2001:DB8:1e::1/64
PC1 Ethernet 0/0 Via stateless autoconfiguration.
PC2 Ethernet 0/0 Via DHCPv6.
PC3 Ethernet 0/0 Via stateless autoconfiguration.
Obtaining IPv6 Address Dynamically

Step 1 On DSW1 configure interface VLAN10 with IP address 2001:db8:a::1/64.
DSW1(config)# interface vlan 10

DSW1(config-if)# ipv6 address 2001:db8:a::1/64
DSW1(config-if)# no shutdown
In order for clients to receive an IP address through stateless autoconfiguration the only
configuration needed on the Layer 3 switch or router is a configured IPv6 address.
Unlike with IPv4, most devices support more than one IPv6 address.
Step 2 Configure PC1 to acquire IPv6 address via stateless autoconfiguration.

PC1(config-if)# ipv6 address autoconfig
In this example PC1 is simulated using a router. To configure a router's interface to acquire IPv6
address through stateless autoconfiguration you need to use the ipv6 address autoconfig
command.
For example Windows 7 and Windows 8 PCs have IPv6 stack by default configured to obtain
IPv6 automatically. Client will first try to acquire address through stateless autoconfiguration. If
the client cannot get IPv6 address through stateless autoconfiguration it will try to get it through
DHCPv6.
Step 3 Verify that PC1 acquired IPv6 address through stateless autoconfiguration.
PC1# show ipv6 interface ethernet 0/0

Ethernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:6000
No Virtual link-local address(es):
Stateless address autoconfig enabled
Global unicast address(es):
2001:DB8:A:0:A8BB:CCFF:FE00:6000, subnet is 2001:DB8:A::/64 [EUI/CAL/PRE]
valid lifetime 2591996 preferred lifetime 604796
Notice that client has two IPv6 addresses. Link local IPv6 address, the one that starts with
"FE80", is self-generated by the client. Global address, the one that starts with "2001". Global
address is combined from a subnet prefix and EUI-64 Interface ID. The client received client
subnet prefix from the Layer 3 switch and self-generated the interface ID. You can see that
interface ID is the same for link local and global address.
The default lifetime is 2592000 seconds (30 days) and a preferred lifetime of 604800 seconds (7
days). After valid lifetime expires node's address is invalid. Until preferred lifetime expires, the
node will consider the current router as preferred.
Step 4 On DSW1 configure an DHCPv6 pool for VLAN 20.
DSW1(config)# ipv6 dhcp pool DHCPV6POOL20

DSW1(config-dhcpv6)# address prefix 2001:db8:14::/64
DSW1(config-dhcpv6)# dns-server 2001:db8:c1::53
DSW1(config-dhcpv6)# domain-name cisco.com
Like with IPv4 you can configure a DHCP server to allocate IPs to devices. The network
command from IPv4 gets replaced with address prefix command.
Step 5 On DSW1 associate the DHCPv6 pool for VLAN 20, with interface VLAN 20.

DSW1(config)# ipv6 address 2001:db8:14::1/64
DSW1(config-if)# ipv6 dhcp server DHCPV6POOL20
Unlike with DHCP in IPv4 environment, with DHCPv6 you need to associate an interface with
the DHCP pool. It does not get done automatically.
NOTE: DHCP pool name is case sensitive.
Note
There is no excluded-addresses command with DHCPv6 on Cisco IOS devices. However it is important to
understand that DHCPv6 server does not actually give out IP addresses like DHCPv4. The server in IPv6
world only gives out prefixes. For example if the server gives out a /64 prefix, the other 64 bits get auto-
generated by the client. Those other 64 bits are generated using interface's MAC address, thus the chance of
having of duplicate address is next to impossible. And if for some reason there is a duplicate address, IPv6
has a duplicate address detection mechanism.
DHCPv6 on Cisco IOS does not have manual binding mechanism like DHCPv4 does.
Step 6 Configure PC2 to acquire IPv6 address from the DHCPv6 server.

PC2(config-if)# ipv6 address dhcp
PC2(config-if)# ipv6 enable
PC2 is simulated using a router. To configure a router's interface via DHCPv6, use ipv6 address
dhcp command.
You need to add the ipv6 enable command to start the process of EUI-64 interface ID
generation.
Step 7 Verify that PC2's Ethernet 0/0 has iIPv6 addresses configured.
PC2# show ipv6 dhcp interface ethernet 0/0

Ethernet0/0 is in client mode
Prefix State is IDLE
Address State is OPEN
Renew for address will be sent in 11:37:37
List of known servers:
Reachable via address: FE80::A8BB:CCFF:FE80:5E00
DUID: 00030001AABBCC005E00
Preference: 0
Configuration parameters:
IA NA: IA ID 0x00020001, T1 43200, T2 69120
Address: 2001:DB8:14:0:B06C:F6FC:FD69:90E3/128
preferred lifetime 86400, valid lifetime 172800
expires at Oct 11 2013 12:36 AM (171458 seconds)
DNS server: 2001:DB8:C1::53
Domain name: cisco.com
Information refresh time: 0
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled
Notice that PC2 also acquired DNS and domain name information from the DHCPv6 server.
If you would issue show ipv6 interface ethernet 0/0 on PC2 you would also see that Ethernet
0/0 has a link-local and a global IPv6 address.
Step 8 Verify that PC3 has acquired IPv6 address via stateless autoconfiguration.
PC3# show ipv6 interface ethernet 0/0

Ethernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:6200
No Virtual link-local address(es):
Stateless address autoconfig enabled
Global unicast address(es):
2001:DB8:1E:0:A8BB:CCFF:FE00:6200, subnet is 2001:DB8:1E::/64 [EUI/CAL/PRE]
valid lifetime 2591888 preferred lifetime 604688
The idea of stateless autoconfiguration is that you won't need any configuring on the client in
order for it to acquire an IP address. In this example PC3 was preconfigured to get IPv6 address
via stateless autoconfiguration.
However stateless autoconfiguration is very basic IP-assignment mechanism in comparison to
DHCP. Using DHCP you can pass-down to the clients much more information that you can with
stateless autoconfiguration.
You can use stateless autoconfiguration in combination with DHCPv6. In that case basic
addressing is provided via stateless autoconfguration. Other options are provided via DHCPv6.
Step 9 Configure DHCPv6 Lite pool on DSW1 for VLAN 30.
DSW1(config)# ipv6 dhcp pool DHCPV6POOL30

DSW1(config-dhcpv6)# dns-server 2001:db8:c1::53
DSW1(config-dhcpv6)# domain-name cisco.com
The only difference between a "full" DHCPv6 and a "lite" DHCPv6 pool is in the address
prefix command. With DHCPv6 Lite you do not need to enter that command since basic IPv6
addressing gets handled through stateless autoconfiguration.
In this example we are interested to pass additional information to PC3 - domain name and DNS
server address.
Step 10 On DSW1 associate the DHCPv6 pool for VLAN 30, with interface VLAN 30.

DSW1(config-if)# ipv6 dhcp server DHCPV6POOL30
DSW1(config-if)# ipv6 nd other-config-flag
Like with a regular DHCPv6 pool, you need to associate it with an interface. What is different
with DHCP Lite is the ipv6 nd other-config-flag command. This command let's clients know
that after they get their IPv6 address via stateless autoconfiguration, additional information is
waiting for them on the DHCP server.
Step 11 Verify that PC3 now has received domain name and DNS server information through DHCP.
PC3# show ipv6 dhcp interface ethernet 0/0

Ethernet0/0 is in client mode
Prefix State is IDLE (0)
Information refresh timer expires in 23:47:27
Address State is IDLE
List of known servers:
Reachable via address: FE80::A8BB:CCFF:FE80:5E00
DUID: 00030001AABBCC005E00
Preference: 0
Configuration parameters:
Information refresh time: 0
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled
Notice that while domain name and DNS server information is there, you do not see a global
IPv6 address in the output. This is because PC3 acquired the IPv6 global address via stateless
autoconfiguration and not DHCPv6.s
NOTE: If you do not see desired results, try first disabling and than enabling interface
Ethernet0/0 on PC3.
Step 12 On DSW1 verify configured DHCPv6 pools.
DSW1# show ipv6 dhcp pool

DHCPv6 pool: DHCPV6POOL20
Address allocation prefix: 2001:DB8:14::/64 valid 172800 preferred 86400 (1 in
use, 0 conflicts)
Active clients: 1
DHCPv6 pool: DHCPV6POOL30
Active clients: 0
There are two DHCPv6 pools configured on DSW1. "DHCPV6POOL20" is a DHCPv6 pool
configured for VLAN 20. "DHCPV6POOL30" is a DHCP Lite pool configured for VLAN 30.
The number of active clients for VLAN30 will not go beyond 0. This is because the "active
client" counts only leased-out IPv6 addresses. So a client is not a device to which domain-name
or DNS information was passed to.
Notice that there is no information about IPv6 addresses related to stateless autoconfiguration.
DSW1 does not keep track of IP addresses that were assigned through stateless
autoconfiguration.
Step 13 On DSW1 verify DHCPv6 bindings.
DSW1# show ipv6 dhcp binding

Client: FE80::A8BB:CCFF:FE00:9F00 (Vlan20)
DUID: 00030001AABBCC009F00
IA NA: IA ID 0x00020001, T1 43200, T2 69120
Address: 2001:DB8:14:0:75B1:AF8F:97BB:DE0D
preferred lifetime 86400, valid lifetime 172800
expires at Oct 11 2013 04:21 AM (172282 seconds)
So the only DHCPv6 binding is with PC2.
DHCPv6 Relay Agent
Like DHCP in IPv4 environment, you can configure a DHCP relay in IPv6.
A DHCPv6 relay agent is used to relay messages between the client and the server. The DHCPv6 relay
agent operation is transparent to the client. A DHCPv6 client locates a DHCPv6 server using a reserved,
link-scoped multicast address. For direct communication between the DHCPv6 client and the DHCPv6
server, both of them must be attached to the same link. However, in some situations where ease of
management, economy, or scalability is a concern, it is desirable to allow a DHCPv6 client to send a
message to a DHCPv6 server that is not connected to the same link.
To configure a device to act as a DHCP relay use the ipv6 dhcp relay destination IPv6_next_hop_address
source_interface. If you use a global IPv6 address as the next hop address, you do not need to specify the
source interface. If you use a link-local address as the next-hop IPv6 address you will need to specify source
interface. This is because all link-local addresses start with the same prefix and unless you specify the
source or exit interface the device will not know where to send DHCP packets.
Summary
Lesson 5: Configuring Layer
2 Port Aggregation
Overview
In networks where resources may be located far from where users might need them, some links between
switches or between switches and servers become heavily solicited. The speed of these links can be
increased, but only to a certain point. EtherChannel is a technology that allows you to circumvent this issue
by creating logical links that are made up of several physical links.
• Describe the need for EtherChannel technology
• Describe port aggregation negotiation protocols
• Describe configuration steps for bundling interfaces into a Layer 2 EtherChannel
• Configure EtherChannel
• Change EtherChannel Load-Balancing behavior
• Describe how EtherChannel load-balancing works
• Describe the role of EtherChannel guard
The Need for EtherChannel
Any-to-any communications of intranet applications such as video to the desktop, interactive messaging,
VoIP, and collaborative whiteboard use are increasing the need for scalable bandwidth within the core and
at the edge of campus networks. At the same time, mission-critical applications call for resilient network
designs. With the wide deployment of faster switched Ethernet links in the campus, users need to either
aggregate their existing resources or upgrade the speed in their uplinks and core to scale performance across
the network backbone.
In the preceding figure, traffic coming from several VLANs at 100-Mb/s aggregate on the access switches at
the bottom and need to be sent to distribution switches in the middle. Obviously, bandwidth larger than 100
Mb/s must be available on the link between two switches to accommodate the traffic load coming from all
the VLANs. A first solution is to use a faster port speed, such as 1 or 10 Gb/s. As the speed increases on the
VLANs links, this solution finds its limitation where the fastest possible port is no longer fast enough to
aggregate the traffic coming from all VLANs. A second solution is to multiply the numbers of physical
links between both switches to increase the overall speed of the switch-to-switch communication. A
downside of this method is that there must be a strict consistency in each physical link configuration. A
second issue is that Spanning Tree may block one of the links.
EtherChannel is a technology that was originally developed by Cisco as a LAN switch-to-switch technique
of grouping several Fast or Gigabit Ethernet ports into one logical channel. This technology has many
benefits:
• It relies on the existing switch ports: there is no need to upgrade the switch-to-switch link to a faster and
more expensive connection.
• Most of the configuration tasks can be done on the EtherChannel interface instead of on each individual
port, thus ensuring configuration consistency throughout the switch-to-switch links.
• Load balancing is possible between the links that are part of the same EtherChannel. Depending on the
hardware platform, you can implement one or several methods, such as source-MAC to destination-
MAC or source-IP to destination-IP load balancing across the physical links.
Keep in mind that the logic of EtherChannel is to increase the speed between switches. This concept was
extended as the EtherChannel technology became more popular, and some hardware non-switch devices
support link aggregation into an EtherChannel link. In any case, EtherChannel creates a one-to-one
relationship. You can create an EtherChannel link between two switches or between an EtherChannel-
enabled server and a switch, but you cannot send traffic to two different switches through the same
EtherChannel link. One EtherChannel link always connects two devices only. The individual EtherChannel
group member port configuration must be consistent on both devices. For example, if the physical ports of
one side are configured as trunks, the physical ports of the other side must also be configured as trunks.
Each EtherChannel has a logical port channel interface. A configuration that is applied to the port channel
interface affects all physical interfaces that are assigned to that interface. (Such commands can be STP
commands or commands to configure a Layer 2 EtherChannel as a trunk or an access port.)
You can use the EtherChannel technology to bundle ports of the same type. On a Layer 2 switch,
EtherChannel is used to aggregate access ports or trunks. Keep in mind that EtherChannel creates an
aggregation that is seen as one logical link. When several EtherChannel bundles exist between two switches,
Spanning Tree may block one of the bundles to prevent redundant links. When Spanning Tree blocks one of
the redundant links, it blocks one EtherChannel, thus blocking all the ports belonging to this EtherChannel
link. Where there is only one EtherChannel link, all physical links in the EtherChannel are active because
Spanning Tree sees only one (logical) link. If one link in EtherChannel goes down, the bandwidth of the
EtherChannel will be automatically updated and thus the STP cost will change as well.
On Layer 3 switches, you can convert switched ports to routed ports. You can also create EtherChannel
links on Layer 3 links.
Etherchannel Mode Interactions
Etherchannel can be established using one of three mechanisms: LACP, PAgP, and static persistence.
LACP is part of an IEEE specification (802.3ad) that allows several physical ports to be bundled together to
form a single logical channel. LACP allows a switch to negotiate an automatic bundle by sending LACP
packets to the peer. Because LACP is an IEEE standard, you can use it to facilitate EtherChannels in mixed-
switch environments. LACP checks for configuration consistency and manages link additions and failures
between two switches. It ensures that when EtherChannel is created and all ports have the same type of
configuration-speed, duplex setting, and VLAN information. Any port modification after the creation of the
channel will also change all the other channel ports.
LACP packets are exchanged between switches over EtherChannel-capable ports. Port capabilities are
learned and compared with local switch capabilities. LACP assigns roles to EtherChannel's ports. Switch
with the lowest system priority is allowed to make decisions about what ports actively participate in
EtherChannel. Ports become active according to their port priority. A lower number means higher priority.
Commonly up to 16 links can be assigned to an Etherchannel, but only 8 can be active at a time. Non-active
links are placed into a standby state and are enabled if one of the active links goes down.
The maximum number of active links in an Etherchannel varies between switches.
These are the LACP modes of operation:

• Active: enable LACP unconditionally
• Passive: enable LACP only if a LACP device is detected
PAgP provides the same negotiation benefits as LACP. PAgP is a Cisco proprietary protocol and it will only
work on Cisco devices. PAgP packets are exchanged between switches over EtherChannel-capable ports.
Neighbors are identified and capabilities are learned and compared with local switch capabilities. Ports that
have the same capabilities are bundled together into an Etherchannel. PAgP forms an EtherChannel only on
ports that are configured for identical VLANs or trunking. PAgP will automatically modify parameters of
the EtherChannel if one of the ports in the bundle is modified. For example, if configured speed, duplex, or
VLAN of a port in a bundle is changed, PAgP reconfigures that parameter for all ports in the bundle. PAgP
and LACP are not compatible.
These are the PAgP modes of operation:

• Desirable: enable PAgP unconditionally
• Auto: enable PAgP only if a PAgP device is detected
Negotiation with either LACP or PAgP introduces overhead and delay in initialization. As an alternative
you can statically bundle links into an Etherchannel. This method introduces no delays but can cause
problems if not properly configured on both ends.
Layer 2 EtherChannel Configuration Guidelines
Before implementing EtherChannel in a network, you should plan the steps necessary to make it successful.
The first step is to identify the ports that you will use for the EtherChannel on both switches. This task helps
identify any issues with previous configurations on the ports and ensures that the proper connections are
available.
Each interface should have the appropriate protocol identified (PAgP or LACP), have a channel group
number to associate all the given interfaces with a port group, and be configured whether negotiation should
occur.
After the connections are established, make sure that both sides of the EtherChannel have formed and are
providing aggregated bandwidth.
Follow these guidelines and restrictions when configuring EtherChannel interfaces:

• EtherChannel support: All Ethernet interfaces on all modules support EtherChannel, with no
requirement that interfaces be physically contiguous or on the same module.
• Speed and duplex: Configure all interfaces in an EtherChannel to operate at the same speed and in the
same duplex mode. Also, if one interface in the bundle is shut down, it is treated as a link failure, and
traffic will traverse other links in the bundle.
• VLAN match: All interfaces in the EtherChannel bundle must be assigned to the same VLAN or be
configured as a trunk.
• Range of VLANs: An EtherChannel supports the same allowed range of VLANs on all the interfaces in
a trunking Layer 2 EtherChannel.
If the allowed range of VLANs is not the same, the interfaces do not form an EtherChannel, even when
set to auto or desirable mode. For Layer 2 EtherChannels, either assign all interfaces in the
EtherChannel to the same VLAN or configure them as trunks.
• STP path cost: Interfaces with different STP port path costs can form an EtherChannel as long they are
otherwise compatibly configured. Setting different STP port path costs does not, by itself, make
interfaces incompatible for the formation of an EtherChannel.
• Port channel versus interface configuration: After you configure an EtherChannel, any configuration
that you apply to the port-channel interface affects the EtherChannel. Any configuration that you apply
to the physical interfaces affects only the specific interface that you configured.
Discovery 6: EtherChannel Configuration and
Load Balancing
Overview
In this discovery you will learn how to configure EtherChannel and change it's load balancing behavior.
Topology
Job Aids
Device Information
Device IP Address Interface Neighbor Interface On The
Neighbor
PC1 172.16.1.101/24 Ethernet 0/0 Sw itch1 Ethernet 0/1
Sw itch1 no IP address Ethernet 1/1 Sw itch2 Ethernet 0/2
Sw itch1 no IP address Ethernet 1/2 Sw itch2 Ethernet 0/3
EtherChannel Configuration And Load Balancing

You will only configure Etherchannel on Switch1. Switch2 has EtherChannel preconfigured.
Step 1 On Switch1 configure the two ports, that connect to Switch2, to use channel group 1 and LACP
active mode.
Switch1# configure terminal

Switch1(config)# interface range Ethernet 1/1-2
Switch1(config-if-range)# channel-group 1 mode active
Creating a port-channel interface Port-channel 1
You have bundled the two interfaces into channel group 1. By choosing the "active" keyword
you've indirectly chosen to use LACP as the negotiation protocol. Since Switch2 has it's ports
bundled and activated for LACP "passive" mode, Etherchannel should come right up.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to

up
Notice that by assigning the two ports to a port channel, you have created a Port Channel 1
interface.
If you issue the show ip interface brief command, Port Channel 1 will be listed as just another
interface at the very bottom of the list.
Step 2 Enter Interface configuration mode for the newly created port channel interface and configure it
to trunk using dot1Q.
Switch1(config)# interface port-channel 1
Switch1(config-if)# switchport trunk encapsulation dot1q
Switch1(config-if)# switchport mode trunk
Configuration applied to port channel will also reflect on physical interfaces that are bundled
into that port channel. You can investigate the running configuration and see that Etherchannel
1/1 and Etherchannel 1/2 both have had the trunking configuration applied.
Step 3 On Switch1 enter the show etherchannel summary command.
Switch1# show etherchannel summary

Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met

u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1

Number of aggregators: 1
Group Port-channel Protocol Ports

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) LACP Et1/1(P) Et1/2(P)
Group 1 port-channel is a layer 2 Etherchannel, that is in use (SU flag). The negotiation protocol
in use is LACP, and the ports bundled (notice the "P" flag) are Ethernet 1/1 and Ethernet 1/2.
If there was a port down or not connected it would be denoted with an "I" flag-independent.
Step 4 Enter the show etherchannel load-balance to verify which information Etherchannel uses to
load balance traffic.
Switch1# show etherchannel load-balance

EtherChannel Load-Balancing Configuration:
src-dst-ip
EtherChannel Load-Balancing Addresses Used Per-Protocol:

Non-IP: Source XOR Destination MAC address
IPv4: Source XOR Destination IP address
Notice that the default configuration for load balancing is "src-dst-ip". This means the source and
destination IP address are used for hash input.
Step 5 For testing how much traffic goes over each link, clear interface counters on Switch1 using the
clear counters command.
Switch1# clear counters
Clear "show interface" counters on all interfaces [confirm] [Enter]
By clearing the counters you are set up to test how much of traffic goes over each link.
Step 6 Perform an extended ping from PC1 to PC3.
PC1# ping
Protocol [ip]: [Enter]
Timeout in seconds [2]: [Enter]
Extended commands [n]: [Enter]
Sweep range of sizes [n]: [Enter]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
In the next step you will check over which interface all the traffic went.
Step 7 Verify counters on Switch1 for both interfaces.
Switch1# show interface ethernet 1/1 | i packets output

10094 packets output, 15146494 bytes, 0 underruns
Notice that most of the traffic went over the Ethernet 1/1 interface.
But what about if you ping from PC2 to PC3. Will traffic go over the other interface in
Etherchannel bundle?
Step 8 Clear interface counters on Switch1 using the clear counters command.

Step 9 Perform an extended ping from PC2 to PC3
PC2# ping
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Step 10 Verify counters on Switch1 for both interfaces

So with the ping from PC1 to PC3 traffic went over Ethernet 1/1. With ping from PC2 to PC3
traffic went over Ethernet 1/2. This is for the default load balancing method that takes
destination and source IP address for calculating the hash.
Step 11 Change the load balancing behavior on Switch1 from "src-dst-ip" to "dst-ip".
Switch1(config)# port-channel load-balance dst-ip
How will traffic get distributed over the two links now?
Step 12 Verify that load-balancing behavior has changed.
Switch1# show etherchannel load-balance

EtherChannel Load-Balancing Configuration:
dst-ip
EtherChannel Load-Balancing Addresses Used Per-Protocol:

Non-IP: Source XOR Destination MAC address
But what if you change the load balancing to destination IP address? How will traffic get
distributed over the two links?

PC1# ping
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The majority of the traffic went over the Ethernet 1/2 port.

PC2# ping
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Now that you have changed the load balancing to destination IP the behavior has changed. Since
the only input information for calculation of the hash is destination IP address, it does not matter
whether you ping PC3 from PC1 or PC2. In both cases the hash function will be the same and
traffic will go over the same link-in this example Ethernet1/2.
Etherchannel Load-Balancing Options
Etherchannel does load balancing of traffic across links in the bundle. However traffic is not necessarily
distributed equally between all the links.
Frames are forwarded over an Etherchannel link that is based on results of a hashing algorithm. Options that
switch can use to calculate this hash depends from platform to platform.
A common set of options are:

• destination IP address
• destination MAC address
• a combination of source and destination IP addresses
• a combination of source and destination MAC addresses
• source IP address
• source MAC address
• source port number
• destination port number
• source and destination port number
You can verify load-balancing options available on the device by using the port-channel load-balance ?
global configuration command.
Hash algorithm calculates a binary pattern that selects a link within the Etherchannel bundle to forward the
frame.
Default configuration can differ from switch to switch, but very commonly the default option is the "src-dst-
ip". It is not possible to have different load-balancing methods for different Etherchannels on one switch. If
the load-balancing method is changed, it is applicable for all Etherchannels.
Etherchannel Load-Balancing Operation
If only one address or port number is hashed, a switch looks at one or more low-order bits of the hash value.
The switch then uses those bits as index values to decide over which links in the bundle to send the frames.
If two or more addresses or ports numbers are hashed, a switch performs an XOR operation.
A four-link bundle uses a hash of the last 2 bits. A bundle of 8 links uses a hash of the last 3 bits.
The example show results of an XOR on a two-link bundle, using the source and destination addresses.
A conversation between two devices is sent through the same EtherChannel link, because the two endpoint
addresses stay the same. Only when a device talks to several other devices changes are that traffic gets
distributed evenly over the links in the bundle.
When one pair of hosts has a much greater volume of traffic than the other pair, one link will be much more
utilized than others. To fix the imbalance, consider using some other load-balancing mechanisms such as
source and destination port number that will redistribute traffic much differently.
If most of the traffic is IP, it makes sense to load balance according to IP addresses or port numbers.
Let's say you load-balance traffic per IP addresses. What happens with non-IP traffic? In that case, the
switch will load-balance frames according to MAC addresses.
To achieve the optimal traffic distribution, always bundle an even number of links. For example, if you use
four links, the algorithm will take at the last two bits. Two bits mean four indexes - 00, 01, 10, and 11. Each
link in the bundle will get assigned one of these indexes. If you bundle only three links, the algorithm will
still need to use two bits to make decisions. One of the three links in the bundle will be utilized more than
other two. With four links, the algorithm will strive to load-balance traffic in 1:1:1:1 ratio. With three links
algorithm will strive to load-balance traffic in 2:1:1 ratio.
You cannot control the port that a particular flow uses. You can only influence the load balance with a
frame distribution method that results in the greatest variety.
EtherChannel Guard
The EtherChannel Guard feature is used to detect EtherChannel misconfigurations between the switch and a
connected device.
An example of a Etherchannel misconfiguration is when the channel parameters do not match on both sides
of the EtherChannel.
The EtherChannel Guard feature can be enabled by using the spanning-tree etherchannel guard
misconfig global configuration command.
However EtherChannel Guard is enabled by default. To verify if it is configured use the show spanning-
tree summary command.
Summary
Overview
Check
1. Which statement identifies network benefits provided by VLANs? (Source: Implementing VLANs and
Trunks)
A. VLANs allow you to group stations without regard to the physical location of the users.
B. VLANs help to isolate problem employees.
C. VLANs reduce the impact of network problems.
D. VLANs can transmit frames to all ports in all VLANs.
2. Match each command to its explanation. (Source: Implementing VLANs and Trunks)
Configures the port to be
A. Switch(config-if)# switchport voice assigned only a single VLAN.
vlan vlan_id
Configures the port to be

B. Switch(config-if)# switchport mode
assigned to multiple VLANs.
access
Configures a VLAN to be added
C. Switch(config-if)# switchport access to trunk port.
vlan vlan_id
Configures a native VLAN for

D. Switch(config-if)# switchport trunk
native vlan vlan_id the trunk.
Configures a port to be a part of

E. Switch(config-if)# switchport trunk voice VLAN.
allowed vlan add vlan_id
Configures a port to be a part of

F. Switch(config-if)# switchport mode
data VLAN.
trunk
3. How can you reset VTP revision number on a switch? (Choose two.) (Source: Introducing VTP)
A. Set the switch to transparent mode and then to server mode.
B. Set the switch to client mode and then to server mode.
C. Change the VTP domain name to a nonexistent VTP domain and then back to the original name.
D. Reload the switch.
4. Which statement about Transparent VTP mode is true? (Source: Introducing VTP)
A. Creates, modifies, and deletes VLANs on all switches in VTP domain.
B. Creates, modifies, and deletes local VLANs only.
C. Does not forward advertisements to other switches in VTP domain.
D. Synchronize VLAN configurations from other switches in VTP domain.
5. Place the four steps of DHCP negotiation in the correct order. (Source: Implementing DHCP)
DHCP discover message
A. Third
DHCP offer message
B. Second
DHCP request message
C. Fourth
DHCP acknowledgment message
D. First
6. Based on what you can bind an IP address to a device? (Choose two.) (Source: Implementing DHCP)
A. client-identifier
B. IPv6 address
C. Serial number
D. MAC address
E. network-identifier
7. Which of these messages are sent out by the DHCPv6 server? (Choose two.) (Source: Implementing
DHCP for IPv6)
A. SOLICIT message
B. ADVERTISE message
C. REQUEST message
D. CONFIRM message
E. RENEW message
8. Which command would you use to configure DHCPv6 relay on SW1 for VLAN 22? (Source:
Implementing DHCP for IPv6)
A. SW1(config-if)# ipv6 dhcp relay destination FE80::A8BB:CCFF:FE00:A920 ethernet 1/2

B. SW1(config-if)# ipv6 dhcp relay destination FE80::A8BB:CCFF:FE00:A920 ethernet 1/1
C. SW1(config-if)# ipv6 dhcp relay destination FE80::A8BB:CCFF:FE00:A920 ethernet 0/0
D. It is not possible if you don't have global IPv6 address on the DHCP server.
9. What is the correct command for configuring load balancing on an EtherChannel link? (Source:
Configuring Layer 2 Port Aggregation)
A. Switch(config)# channel-group number load-balance method
B. Switch(config-if)# channel-group number load-balance method
C. Switch(config-if)# port-channel number load-balance method
D. Switch(config)# port-channel load-balance method
10. Which of the following EtherChannel modes does not send or receive any negotiation frames? (Source:
Configuring Layer 2 Port Aggregation)
A. passive
B. active
C. on
D. desirable
E. auto
Answer Key
1 C
2
A. Switch(config-if)# switchport mode access — Configures the port to be assigned only a single
VLAN.
B. Switch(config-if)# switchport mode trunk — Configures the port to be assigned to multiple
VLANs.
C. Switch(config-if)# switchport trunk allowed vlan add vlan_id — Configures a VLAN to be
added to trunk port.
D. Switch(config-if)# switchport trunk native vlan vlan_id — Configures a native VLAN for the
trunk.
E. Switch(config-if)# switchport voice vlan vlan_id — Configures a port to be a part of voice
VLAN.
F. Switch(config-if)# switchport access vlan vlan_id — Configures a port to be a part of data VLAN.
3 A, C
4 B
5
A. First — DHCP discover message
B. Second — DHCP offer message
C. Third — DHCP request message
D. Fourth — DHCP acknowledgment message
6 A, D
7 B, D
8 B
9 D
10 C
Module 3: Spanning Tree
Implementation
Introduction
Spanning-tree protocol enables you to use redundant topologies, while avoiding Layer 2 loops. By default
Cisco switches use PVSTP+ (Per VLAN Spanning-tree Protocol Plus). However, whenever possible you
should use either Rapid version of PVST+ or MST (Multiple Spanning-tree) protocol.
STP also knows a number of mechanisms. Some are implemented to speed up performance (UplinkFast,
BackboneFast, PortFast), others are configured to increase stability (BPDUGuard, BPDUFilter, RootGuard,
LoopGuard). There are also other mechanisms that are not directly related to STP, but can be used to either
complement STP operation (UDLD (Unidirectional Link Detection) or to replace it (FlexLinks).
• Implement RSTP
• Describe how and where to configure the following mechanisms: PortFast, UplinkFast, BackboneFast,
BPDUGuard, BPDUFilter, RootGuard, LoopGuard, UDLD, and FlexLinks
• Configure Multiple Spanning-tree protocol
RSTP
Overview
Redundant topology can eliminate the possibility of a single point of failure causing a loss of function for
the entire network As it has benefits, redundant topology also causes problems, such as loops. Spanning
Tree Protocol provides network link redundancy while eliminating caused problems.
A limitation of the traditional STP is the convergence delay after a topology change, so use of Rapid STP is
recommended.
• Explain the need for Spanning Tree Protocol
• List different standards of STP
• Describe basic STP operation
• Describe Bridge Protocol Data Units
• Explain the Root Bridge Election
• Explain the Root Port Election
• Explain Designated Port Election
• List and Explain RSTP Port States
• Explain the concept of Per-VLAN STP
• Examine the difference between STP and RSTP
• Explain STP Manipulation
• List and Explain RSTP Port Roles
• Compare RSTP and STP Port States
• Explain how STP handles Topology Changes
• Explain how RSTP handles Topology Changes
• Describe RSTP Link Types
STP Overview
Redundant topology can eliminate the possibility of a single point of failure causing a loss of function for
the entire switched network.
On the other hand, redundant topology can cause some problems:

• Broadcast storms: Each switch on a redundant network floods broadcast frames endlessly. Switches
flood broadcast frames to all ports except the port on which the frame was received. These frames then
travel around the loop in all directions.
• Multiple frame transmission: Multiple copies of the same unicast frames may be delivered to
destination station, which can cause problems with the receiving protocol. Many protocols expect to
receive only a single copy of each transmission. Multiple copies of the same frame can cause
unrecoverable errors.
• MAC database instability: This results from copies of the same frame being received on different
ports of the switch. MAC address table maps the source MAC address on a packet received to the
interface it was received on. If a loop occurs, then the same source MAC address could be seen on
multiple interfaces causing instability. Data forwarding can be impaired when the switch consumes the
resources that are coping with instability in the MAC address table.
To solve all of these problems, you need a loop-avoidance mechanism. The Spanning Tree Protocol was
developed to address these issues.
STP allows physical path redundancy while preventing the undesirable effects of active loops in the
network.
STP forces certain ports into a standby state so that they do not listen, forward or flood data frames. There is
only one active path to each network segment.
If there is a problem with connectivity to any of the segments, STP re-establishes connectivity by
automatically activating a previously inactive path. BPDUs are messages that STP uses to determine current
topology information. By default they are sent out every 2 seconds on all switch ports.
STP Standards
• STP itself is the original IEEE 802.1D version that provides a loop-free topology in a network with
redundant links. STP was created for bridged network, so it supports only a single LAN or one VLAN.
• CST assumes one spanning-tree instance for the entire network. Unlike 802.1D, it supports more than
one VLAN.
• PVST and PVST+ are Cisco proprietary protocols that provide a separate spanning-tree instance for
each VLAN configured in the network PVST protocol is obsolete.
• MST maps multiple VLANs into the same spanning-tree instance. MST was defined based on the
Cisco's pre-standard, MST. Cisco switches now uses the standard implementation.
• RSTP is standard, described in IEEE 802.1w. It is an evolution of STP that provides faster convergence
of STP.
• PVRST+ is a Cisco implementation of RSTP that is based on Per-VLAN Spanning Tree Plus.
Spanning Tree varieties that use more than one instance of STP have higher CPU and memory
requirements. The CPU and memory requirements are also higher when spanning-tree protocols with faster
convergence are used as the algorithm needs to make calculations more frequently.
When you do not use rapid version of spanning-tree (CST, PVST, or PVST+), the convergence time is slow.
Note There is also a Cisco proprietary implementation of 802.1s, that is pre-standard.
STP Operation
Spanning Tree Protocol provides loop resolution by managing the physical path to the given network
segment, by performing three steps:
1 Elects one root bridge: Only one bridge can act as the root bridge. Root bridge is the reference point,
all data flows in the network are from the perspective of this switch. All ports on a root bridge are
forwarding traffic.
2 Selects the root port on the non-root bridge: One port on each non-root bridge is the root port. It is
the port with the lowest-cost path from the non-root bridge to the root bridge. By default, STP path cost
is calculated from the bandwidth of the link. You can also set STP path cost manually.
3 Selects the designated port on each segment: There is one designated port on each segment. It is
selected on the bridge with the lowest-cost path to the root bridge.
Ports that are neither root or designated, must be nondesignated. Nondesignated ports are normally in the
blocking state to break the loop topology.
There are four port roles in STP:
Port role Description
Root port This port exists on nonroot bridges and is the sw itch port w ith the best path to the root bridge. Only
one root port is allow ed per bridge.
Designated port This port exists on root and nonroot bridges. For root bridge, all sw itch ports are designated ports.
For nonroot bridges, a designated port is the sw itch port that w ill receive and forw ard frames tow ard
the root bridge as needed. Only one designated port is allow ed per segment. If multiple sw itches
exist on the same segment, an election process determines the designated sw itch, and the
corresponding sw itch port begins forw arding frames for the segment.
Nondesignated The nondesignated port is a sw itch port that is not forw arding (blocking) data frames.
port
Disabled port The disabled port is a sw itch port that is shut dow n.
Bridge Protocol Data Unit
BPDUs are used for root bridge election and for loop identification. By default BPDUs are sent out every 2
seconds.
Switch sends out BPDU on a port. The source address is the MAC address of that port and the destination
address is the STP multicast address 01-80-c2-00-00-00.
BPDU frame consists of the following fields:

• Protocol ID: Identifies the Spanning Tree Protocol.
• Version: Identifies the current version of the protocol.
• Message Type: Identifies the type of BPDU—Configuration or TCN BPDU.
• Flags: Used in response to a TCN BPDU.
• Root Bridge ID: Identifies the Bridge ID of the root bridge.
• Root Path Cost: Identifies the cost from the transmitting switch to the root.
• Sender Bridge ID: Identifies the Bridge ID of the transmitting switch.
• Port ID: Identifies the transmitting port.
• Message Age: Indicates the age of the current BPDU.
• Max Age: Indicates the timeout value.
• Hello Time: Identifies the time interval between generation of Configuration BPDUs by the root.
• Forward Delay: Defines the time a switch port must wait in the listening and learning state.
Root Bridge Election
To prevent loops in a network, you need a reference point-root bridge. Root bridge is the logical center of
the spanning tree topology. All paths that are not needed to reach the root bridge from anywhere in the
network are placed in STP blocking mode.
Root Bridge is chosen with an election. Each switch has a unique bridge ID that consists of:
• Bridge priority: A value between 0 and 65,535. The default is 32,768.
• MAC Address.
The root bridge is selected based on the lowest bridge ID. If all switches in the network have the same
priority, the switch with the lowest MAC address becomes the root bridge.
In the beginning each switch assumes that it is the root bridge. Each switch sends BPDU to its neighbours,
presenting its Bridge ID. At the same time it receives the BPDUs from all the neighbors. Each time a switch
receives a BPDU it checks it's Bridge ID against it's own. If the received BID is better than its own, then the
switch knows it is not the root bridge. Otherwise it keeps it's assumption of being the root bridge.
Eventually the election converges and all switches agree that one of them is the root bridge.
Root bridge election is an ongoing process. So if a new switch appears with a better Bridge ID, it will be
elected as the new root bridge.
Note The term root bridge comes from the days of when spanning-tree protocol was developed.
Even though you do not have bridges in your network, this term is still used. The root bridge
of your topology might be better called the root switch.
The switch with the lowest priority will be the root bridge. In the example, since all three switches have the
same priority, the root bridge is elected based on the lowest MAC address.
Root Port Election
After the root bridge is elected, each non-root bridge must figure out where it is in relation to the root
bridge. Root port is the port with the best path to the root bridge.
To determine root ports on non-root bridges, cost value is used. The path cost is the cumulative cost of all
links to the root bridge. Root port indicates the lowest cost to the root bridge.
In the example, SW1 has two paths to the root bridge. Which port will be elected the root port? The path
cost through Ethernet 0/1 is cumulative. The cost of link SW1-SW2 is 100 and the cost between SW3 and
SW2 is 100 - one of these links will be blocked by the STP. So the cost to get to the root bridge through
Ethernet 0/1 is 200. SW1's path through Ethernet 0/0 has cost of 100. Since the path through Ethernet 0/0
has a lower cost, Ethernet 0/0 will be elected the root port.
STP cost is calculated from the bandwidth of the link. It can be manually changed by the administrator.
However, this is not a very common practice.
The table shows common cost values of the link. The higher the bandwidth of a link, the lower the cost of
transporting data across it.
Link Cost
10 Gb/s 1
1 Gb/s 4
100 Mb/s 19
10 Mb/s 100
When two ports have the same cost, arbitration can be done using the advertised port ID (from the
neighboring switch). Port ID is a combination of a port priority, which is 128 by default, and a port number.
For example the port Ethernet0/1 will have the port ID 128.1, the port Ethernet0/3 will have port ID 128.3,
and so on. The lowest port ID is always chosen when port ID is the determining factor.
In the example, SW3 has three paths to the root bridge. Through Ethernet 0/3, the cumulative cost is 200—
links SW3-SW1 and SW1-SW2. Through Ethernet 0/1 and Ethernet 0/2 the cost is the same—100. Since
lower cost is better, one of these two ports will be elected the root port. Since Ethernet 0/1 receives a lower
port ID from SW2 (128.2) than Ethernet 0/2 receives (128.4), Ethernet0/1 will be elected the root port.
Note Bandwidth of the Etherchannel is calculated as the sum of all the links that are bundled into
Etherchannel. The cost of Etherchannel link is calculated based on the summed bandwidth.
Designated Port Election
Root bridge and root ports on non-root bridges have been elected. To prevent the loops, STP has to identify
which port on the segment will forward the traffic.
Only one of the links on a segment should forward traffic to and from that segment. The designated port, the
one forwarding the traffic, is also chosen based on the lowest cost to the root bridge.
On the root bridge, all ports are designated.
You can have two paths with equal cost to the root bridge. STP uses the following criteria for best path
determination and consequently for determination of designated and nondesignated port on the segment:
1 Lowest root bridge ID.
2 Lowest root path cost to root bridge.
3 Lowest sender bridge ID.
4 Lowest sender port ID.
In the example, SW2 is the root bridge, so it has all ports designated. To prevent loops, blocking port for the
SW1-SW3 segment has to be determined. Since SW3 and SW1 have the same path cost to the root bridge,
100, the lower bridge ID breaks the tie. SW1 has lower bridge ID than SW3, so the designated port for the
segment is Ethernet 0/1 on SW1.
Only one port on a segment should forward traffic. All ports, that are not root or designated ports, are
nondesignated ports. Nondesignated ports go to the blocking state in order to prevent a loop.
In the example, root ports are determined on non-root bridges. We have just determined, which ports are
designated. All the other ports are nondesignated. The only two interfaces that are not root or designated
ports are Ethernet 0/2 and Ethernet 0/3 on SW3. Both are nondesignated (blocking).
STP Port States
To participate in the spanning-tree process, a switch port must go through several states. A port will start in
disabled state and then, after administrator enables it, move through various states until it reaches
forwarding state. That is, if it is allowed to be forwarding. If not, it will be moved into blocking state.
• Blocking: In this state, the port ensures that no bridging loops occur. Port in this state cannot receive or
transmit data, but it receives BPDUs, so the switch can hear from it's neighbours switches and
determine the location, and root ID, of the root switch and port roles of each switch. Port in this state is
a nondesignated port, therefore it does not participate in active topology.
• Listening: Port is moved from blocking to listening state, if there is a possibility to be selected as the
root or designated port. The port in this state still cannot send or receive data frames. But it is allowed to
send and receive BPDUs, so it is participating in active topology.
• Learning: After a period of time-Forward Delay in listening state, the port is moved to Learning state.
The port still sends and receives BPDUs, in addition it can learn and add new MAC address to it's table.
Port in this state can not send any data frames.
• Forwarding: After another period of time-Forward Delay in Learning state, the port is moved to
Forwarding state. It is considered as part of the active topology. It sends and receives frames and also
sends and receives BPDUs.
• Disabled: In this state, port is administratively shut down. It does not participate in spanning tree and it
does not forward frames.
Per-VLAN STP
Per-VLAN STP is a Cisco implementation of STP that provides a separate spanning-tree instance for each
configured VLAN in the network.
Unlike CST, Per-VLAN STP runs one spanning-tree instance for each VLAN. This allows you to load
balance traffic over redundant links, when they are assigned in to a different VLAN.
In the example PVST+ is configured. Switch A is configured the root for VLAN1 and Switch B is
configured the root for VLAN2. The uplink on the left forwards traffic for VLAN 1 and VLAN 1 traffic is
blocked on the right uplink. It's reverse for VLAN 2 traffic. The uplink on the right forwards traffic for
VLAN 2 and VLAN 2 traffic is blocked on the left uplink.
If you would implement CST, there would be only one root bridge and one link would forward traffic for
both VLANs, the other link would be blocked for all VLANs
Note PVSTP+ is usually the default STP on Cisco's switches.
Spanning-tree operation requires that each switch has a unique BID. To carry VID information, the
extended system ID is accommodated. The original 16-bit bridge priority field is split into two fields,
resulting in following components in the BID:
• Bridge priority: A 4-bit field, used to carry bridge priority. The default priority is 32,768, which is the
midrange value. The priority is conveyed in discrete values in increments of 4096.
• Extended system ID: A 12-bit field carrying the VLAN ID.
• MAC address: A 6-byte field with the MAC address of the switch.
By virtue of the MAC address, a BID is always unique. If no priority has been configured, every switch will
have the same default priority, and the election of the root for each VLAN is based on the MAC address.
Because this method is random, it is advisable to assign a lower priority to the switch that should serve as
the root bridge.
Discovery 7: Discovering and Modifying STP
Behavior
Overview
In this discovery, you will learn how to manually configure a root bridge and the path for spanning-tree.
You will also observe the difference between the STP and RSTP convergence time.
Topology
All switches are in VLAN 1.
There are two loops in this topology; SW1-SW2-SW3 and SW2-SW3. While wiring the network in such a
way provides redundancy, Layer 2 loops will occur if STP does not block redundant links.
Job Aids
There are no Job Aids for this lab.
Spanning-Tree Protocol
Step 1 Discover which switch is the root bridge.
Issue show spanning-tree command on all three switches.

SW3# show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address aabb.cc00.4500
Cost 100
Port 4 (Ethernet0/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

VLAN0001
Cost 100

VLAN0001
This bridge is the root

SW1 is the root bridge. All three switches have the same priority, so the one with the lowest
MAC address is elected as the root bridge.
Step 2 Investigate port roles on all three switches.
Again use show spanning-tree command.

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0 Desg FWD 100 128.1 Shr

------------------- ---- --- --------- -------- --------------------------------
Et0/2 Root FWD 100 128.3 Shr

------------------- ---- --- --------- -------- --------------------------------
Et0/1 Altn BLK 100 128.2 Shr
Since SW1 is the root bridge, it has both connected ports in designated (forwarding) state.
Because SW2 and SW3 are not the root bridge, one port must be elected root on each of these
two switches. This is the port with the lowest cost to the root bridge. As SW2 has lower bridge
ID than SW3, all ports on SW2 are set to designated. Other ports on SW3 are nondesignated.
NOTE: Cisco's PVSTP+ uses term "alternate" for nondesignated port.
Changing STP Priority
You do not want the network to choose the root bridge by itself. If all switches have default STP priorities,
the switch with the lowest MAC address will become the root bridge. The oldest switch will have the lowest
MAC address, since the lower MAC addresses were factory-assigned first. To manually set the root bridge
you can change switch's priority.
In the example topology, you do not want access layer switch SW3 becoming the root bridge. If SW3 was
the root bridge, the link between distribution layer switches would get blocked. The traffic between SW1
and SW2 would then need to go through SW3, which is not optimal. You want distribution or core switches
to become the root bridge.
When changing the priority, you must set the correct values. The priority can be a value between 0 and
65,535 in increments of 4096. The default value is 32,768. With Per-VLAN spanning-tree, Extended
System ID is used for calculating Bridge Priority. The Priority reduces from 16 to 4 bits, as 12 bits represent
the VLAN ID. With 4-bit priority, there are 16 total combinations. The increment starts at 4096 and
increments another 15 times, until the value is 65,535. This means, you cannot change the priority from
32,768 to 32,789, but you have to add a multiple of 4096, so for example the next possible priority value
would be 36864.
The better solution is to use spanning-tree vlan vlan-id root {primary|secondary} command. This
command is actually a macro that lowers the switch's priority number in order for it to become the root
bridge.
To configure the switch to become the root bridge for a specified VLAN, use the primary keyword. Use
secondary keyword to configure a secondary root bridge. If the primary root bridge fails, you do not want
the slowest, oldest access-layer switch becoming the root bridge!
If the current root priority is more than 24576, the local switch sets its priority to 24576. If the root bridge
has priority lower than 24576, than the local switch sets its priority to 4096 less than the one of the current
root bridge. Configuring the secondary root bridge sets priority of 28672. There is no way for the switch to
figure out what is the second best priority in the network. So setting the secondary priority to 28672 is just a
best guess.
If you issue show running-configuration command, you will see switch's priority as a number - not the
primary or secondary keyword.
Note If the priority of the root bridge is set to 0, configuring another switch with root primary
command will yield no results. The command will fail since it cannot make local switch
priority for 4096 lower than that of the root bridge!
You can display status of the root bridge using show spanning-tree root command.
Step 3 Make SW2 the root bridge for VLAN 1.
SW2(config)# spanning-tree vlan 1 root primary
Step 4 Verify that SW2 is now the root bridge for VLAN 1.
VLAN0001

Aging Time 15 sec

------------------- ---- --- --------- -------- --------------------------------
Step 5 Observe changed port roles on SW1 and SW3.
Since SW2 is the root bridge, all of it's port will be in designated - forwarding. SW1 and SW3
have changed port roles according to the change of the root bridge.

------------------- ---- --- --------- -------- --------------------------------

------------------- ---- --- --------- -------- --------------------------------
Port roles after configuring SW2 as the root bridge.
STP Path Manipulation
For port role determination cost value is used. If all ports have the same cost, sender's port ID breaks the tie.
To control active port selection you can change the cost of the interface or sender's interface port ID.
You can modify port cost using spanning-tree vlan vlan-list cost cost-value command. The cost value can
be between 1 and 65,535.
Port ID consist of port priority and port number. As port number is fixed, because it is based only on its
hardware location, you can change port ID by configuring port priority.
You can modify port priority using spanning-tree vlan vlan-list port-priority port-priority command. The
value of port priority can be between 0 and 255, the default is 128. A lower port priority means more
preferred path to the root bridge.
In the given example Ethernet 0/1 and Ethernet 0/2 have the same interface STP cost. Ethernet 0/1 is
forwarding because it's sender's port ID (128.2) is lower than that of Ethernet 0/2 (128.4). One way that you
could make SW3's Ethernet 0/2 forwarding is to lower the port cost on Ethernet 0/2. Another way to make
SW3's Ethernet 0/2 forwarding is to lower the sender's port priority. In this case this is Ethernet 0/3 on SW2.
Step 6 Make Ethernet 0/2 on SW3 the root port, by changing its cost.
Right now Ethernet 0/1 is the root port on SW because of the lower port priority. Ethernet 0/2
has port priority of 128.3 and Ethernet 0/1 has port priority of 128.2. Since you will change the
cost, port priority will not be observed. STP checks port priority only when costs are equal.

SW3(config-if)# spanning-tree vlan 1 cost 16
Step 7 Again investigate STP port roles on SW1 and SW3.
Use show spanning-tree command.
Because interface Ethernet 0/2 now has lower cost, it is assigned as root port. STP reconsiders a
new path, so new port roles are assigned on SW1 and SW3. Since SW2 is the root bridge, it will
have all port designated - forwarding.

------------------- ---- --- --------- -------- --------------------------------

------------------- ---- --- --------- -------- --------------------------------
Port roles after manually configuring root port on SW3.
Step 8 Turn on the STP topology events debugging on SW3.
You have done this in order to observe STP convergence, that is how much time does STP need
to establish a new path after a link failure, in real time.
SW3# debug spanning-tree events
Step 9 Shut down the forwarding uplink on SW3—Ethernet 0/2.
Observe how much it takes STP to notice the failure and make the redundant link forwarding.
SW3(config-if)# shutdown
*Nov 8 07:52:45.237: STP: VLAN0001 new root port Et0/1, cost 100
*Nov 8 07:52:45.237: STP: VLAN0001 Et0/1 -> listening
*Nov 8 07:52:45.237: STP[1]: Generating TC trap for port Ethernet0/2
SW3(config-if)#
*Nov 8 07:52:47.243: %LINK-5-CHANGED: Interface Ethernet0/2, changed state to
administratively down
SW3(config-if)#
*Nov 8 07:52:47.243: STP: VLAN0001 sent Topology Change Notice on Et0/1
*Nov 8 07:52:48.245: %LINEPROTO-5-UPDOWN: Line protocol on Interfac
Ethernet0/2, changed state to down
SW3(config-if)#
*Nov 8 07:53:00.243: STP: VLAN0001 Et0/1 -> learning
SW3(config-if)#
*Nov 8 07:53:04.160: STP: VLAN0001 sent Topology Change Notice on Et0/1
*Nov 8 07:53:04.160: STP: VLAN0001 Et0/3 -> blocking
SW3(config-if)#
*Nov 8 07:53:15.247: STP: VLAN0001 Et0/1 -> forwarding
STP Timers
STP uses three different timers to ensure proper loop-free convergence.
The transition between port states takes from 30 to 50 seconds, depends on the topology change.
You can adjust STP timers. You can tune hello time between 1 and 10 seconds, forward delay between 4
and 30 seconds and maximum age between 6 and 40 seconds. However, the timer values should never be
changed without consideration. When changing the timers, you should apply changes only on the root
bridge. Root bridge will then propagate the timer values to other switches.
Note Normally you do not change the STP timers, you would instead use RSTP.
You can manually configure timers using spanning-tree [vlan vlan-id] {hello-time | forward-time | max-
age} seconds command. To verify configured STP timers, issue show spanning-tree vlan vlan-id
command.
Step 10 Turn the interface Ethernet 0/2 on SW3 back on.
You have done that in order to observe how topology changes after failed interface comes back
up.
SW3(config-if)# no shutdown
Step 11 Observe how STP port roles get redefined after failed interface comes back up.

------------------- ---- --- --------- -------- --------------------------------

------------------- ---- --- --------- -------- --------------------------------
Port roles are again the same as they were before shutting down the interface. The port roles on
SW2 have not changed, since it is the root bridge and all ports are designated.
NOTE: After you bring Ethernet 0/2 on SW3 back up it will take around 30 seconds for STP to
make ports either forwarding or blocking.
Step 12 Enable Rapid STP on all switches.
SW1(config)# spanning-tree mode rapid-pvst
If all switches in the network, except one, are running Rapid STP, the interfaces that lead to
legacy STP switches will automatically fall-back to non-rapid STP. In case of Cisco's switches,
they will fall-back to PVST+. You can check, that all of the switched have RSTP configured by
observing the convergence time.
Step 13 Verify that the RSTP is enabled on all three switches.
VLAN0001
Spanning tree enabled protocol rstp
VLAN0001
VLAN0001
Step 14 Shut down the interface Ethernet 0/2 on SW3.
If you want to observe the port states recalculation, you have to trigger a topology change. One
of the options is to shut down the interface.
How much time it will take spanning tree to converge now that you enabled the rapid version?
SW3(config-if)# shutdown
Step 15 Observe the convergence time of RSTP.
*Nov 8 08:17:33.415: RSTP(1): transmitting a proposal on Et0/3

*Nov 8 08:17:33.510: RSTP(1): updt roles, root port Et0/2 going down
*Nov 8 08:17:33.510: RSTP(1): Et0/1 is now root port
*Nov 8 08:17:33.510: RSTP(1): syncing port Et0/3
*Nov 8 08:17:33.514: RSTP(1): transmitting a proposal on Et0/3
*Nov 8 08:17:33.519: RSTP(1): updt roles, received superior bpdu on Et0/3
*Nov 8 08:17:33.519: RSTP(1): Et0/3 is now alternate
The convergence time of RSTP is much shorter than of STP. The entire convergence happens at
the speed of BPDU transmission. That can be less than one second.
RSTP Port Roles
The port role defines the ultimate purpose of a switch port and the way it handles data frames. With RSTP,
port roles are slightly different than with STP.
RSTP defines the following port roles.

• Root: The root port is the switch port on every nonroot bridge that is the chosen path to the root bridge.
There can be only one root port on every switch. The root port is considered as part of active topology.
It forwards, sends, and receives BPDUs (data messages).
• Designated: Each switch has at least one switch port as the designated port for the segment. In active
topology, the switch with the designated port receives frames on the segment that are destined for the
root bridge. There can be only one designated port per segment.
• Alternate: The alternate port is a switch port that offers an alternate path toward the root bridge. It
assumes a discarding state in an active topology. Alternate port makes a transition to a designated port if
the current designated path fails.
• Disabled: A disabled port has no role within the operation of spanning tree.
• Backup: The backup port is an additional switch port on the designated switch with a redundant link to
the shared segment for which the switch is designated. The backup port has the discarding state in
active topology.
There is a difference between STP and RSTP port roles. Instead of STP nondesignated port role, there are
now alternate and backup port.
Additional port roles allow RSTP to define a standby switch port before a failure or topology change. The
alternate port moves to the forwarding state if there is a failure on the designated port for the segment.
Note You will probably not see Backup port role in practice. It is used only when switches are
connected to a shared segment. To build shared segments, you need hubs and these are
obsolete.
Comparison of RSTP and STP Port States
The RSTP port states correspond to the three basic operations of a switch port: discarding, learning, and
forwarding. There is no listening state as it was with STP. Listening and Blocking STP states are replaced
with discarding state.
In a stable topology, RSTP ensures that every root port and designated port transit to forwarding, while all
alternate ports and backup ports are always in the discarding state.
The characteristics of RSTP port states:
Port state Description
Discarding This state is seen in both a stable active topology and during topology synchronization and
changes. The discarding state prevents the forw arding of data frames, thus “breaking” the continuity
of a Layer 2 loop.
Learning This state is seen in both a stable active topology and during topology synchronization and
changes. The learning state accepts data frames to populate the MAC table to limit flooding of
unknow n unicast frames.
Forw arding This state is seen only in stable active topologies. The forw arding sw itch ports determine the
topology. Follow ing a topology change, or during synchronization, the forw arding of data frames
occurs only after a proposal and agreement process.
A port will accept and process BPDU frames in all port states.
STP Topology Changes
When a switch moves a port into the Forwarding state or into Blocking state, we can talk about STP
topology changes.
Switch announces a topology change by sending TCN BPDU out from the root port. This BPDU does not
contain data about the change, but it only informs other switches in the network, that the change has
occurred.
When the root bridge receives the TCN BPDU, it first sends an acknowledgement BPDU (TCA) to the
switch that it received the TCN from. Root bridge then signals the topology change to other switches in the
network, by changing Topology Change Flag in its BPDU (TC). Switches then shorten their bridge table
aging times to the Forward Delay time.
There are three types of topology change:
• A direct topology change can be detected on an interface. In the figure, SW4 has detected a link failure
on one of the interfaces. It then sends out a TCN message on the root port to reach the root bridge.
SW1, the root bridge, then announces the topology change to other switches in the network. All
switches shorten their bridging table aging time to the Forward Delay. That way they get new
associations of port and MAC address after 15 seconds, not after 300 seconds, which is the default
bridging table aging time. The convergence time in that case is two times the Forward Delay period, so
30 seconds.
• With an indirect topology change, the link status stays up. Something, for example another device
such as firewall, on the link has failed or is filtering traffic and no data is received on each side of the
link. Because there is no link failure, no TCN messages are sent. The topology change is detected as
there are no BPDUs from the root bridge. With indirect link failure, the topology does not change
immediately but the STP converges again, thanks to timer mechanisms. The convergence time in that
case is longer than with direct topology change, around 50 seconds.
• Insignificant topology change would occur if, for example, PC connected to SW4 was turned off.
Event causes SW4 to send out TCNs. However, since none of the switches had to change port states to
reach the root bridge no actual topology change occurred. The only consequence of shutting down the
PC is that all switches will age-out entries from CAM table sooner than normal. This can become a
problem if you have a lot of PCs. A lot of PCs going up and down can cause a lot of TCN exchanges.
To avoid that you can enable PortFast on end-user ports. If a PortFast-enabled port goes up or down a
TCN is not generated.
RSTP Topology Changes
For RSTP, a topology change is only when a nonedge port transitions to the Forwarding state. This means a
loss of connectivity is not considered as a topology change any more, contrary to STP.
Switch announces a topology change by sending BPDUs with TC bit set, out from all the nonedge
designated ports. This way all the neighbors are informed about the topology change, so they can correct
their bridging tables.
In the figure, SW4 sends BPDUs out of all its ports after it detects a link failure. SW2 then sends the BPDU
to all its neighbors, except the one that received the BPDU from SW4, and so on.
When a switch receives a BPDU with TC bit set from a neighbor it clear the MAC addresses learned on all
its ports, except the one that receivs the topology change. The switch also BPDUs with TC bit set on all
designated ports and root port.
RSTP no longer uses the specific TCN BPDU, unless legacy bridge needs to be notified.
With RSTP, the TC propagation is now a one step process. In fact, the initiator of the topology change
floods this information throughout the network, as opposed to 802.1D where only the root did. This
mechanism is much faster than the 802.1D equivalent. There is no need to wait for the root bridge to be
notified and then maintain the topology change state for the whole network for <max age plus forward
delay> seconds. In just a few seconds, or a small multiple of hello-times, most of the entries in the CAM
tables of the entire network (VLAN) flush. This approach results in potentially more temporary flooding,
but on the other hand it clears potential stale information that prevents rapid connectivity restitution.
Why does RSTP not consider link failure a topology change? Loss of connectivity does not provide new
paths in topology. If a switch loses the link to downstream switch, the downstream switch either has an
alternate path to the root bridge or it does not. If the down stream switch has no alternate patch, no action
will be taken to improve convergence. If the downstream switch has an alternate path, the downstream
switch will unblock it and consequently generate its own BPDUs with TC bit set.
Like with STP, PortFast-enabled ports do not create topology changes. This reduces the amount of topology
change messages flooding. PortFast-enabled ports do not have associated MAC addresses flushed if a
topology change message is received.
RSTP Link Types
Link type provides a categorization for each port participating in RSTP.
The link type can predetermine the active role that the port plays as it stands by for immediate transition to a
forwarding state. These parameters are different for edge ports and nonedge ports. Nonedge ports are
categorized into two link types.
Link Type Description
Point-to-point Port operating in full-duplex mode. It is assumed that the port is

connected to a single sw itch device at the other end of the link.
Shared Port operating in half-duplex mode. It is assumed that the port is

connected to shared media w here multiple sw itches might exist.
Link type is automatically determined but can be overwritten with an explicit port configuration.
Edge port is a switch port that is never intended to be connected to another switch device. Edge ports,
equivalent of point-to-point link, are candidates for rapid transition to a forwarding state. Before the link
type parameter can be considered for expedient port transition, RSTP must determine the port role.
Root ports: Do not use the link type parameter. Root ports are able to make a rapid transition to the
forwarding state as soon as the port is in the sync state.
Alternative and backup ports: In most cases do not use the link type parameter
Designated ports: Make the most use of the link type parameter. Rapid transition to the forwarding state for
the designated port occurs only if the link type parameter indicates a point-to-point link.
You can verify the port type by issuing the show spanning-tree command:
Switch# show spanning tree

------------------- ---- --- --------- -------- --------------------------------
Et0/1 Desg FWD 100 128.2 P2p
Et0/2 Desg FWD 100 128.2 Edge
Note Edge port has only a single host that is connected to it. If edge port ever receives BPDU, it
immediately loses the edge port status.
Summary
Lesson 2: Implementing STP
Stability Mechanisms
Overview
STP is a very mature protocol, benefiting from years of development and production deployment. However,
STP makes assumptions about the quality of the network, and the protocol can fail. Those failures are
generally high-profile failures because of the extent to which they impact the network. STP is designed to
never open a loop, even temporarily, during its operation. However, like any protocol, it is based on some
assumptions that might not be valid in the network. To help STP converge faster and for the protocol
behavior to match your network infrastructure, several features are available to filter the way that BPDUs
are sent or received, and to alter the way the network should react in case of an unexpected network
topology change.
• List and briefly explain Cisco STP Toolkit
• Describe UplinkFast
• Configure BackboneFast
• Decribe how to configure PortFast
• Describe how to configure BPDUGuard
• Describe how to configure BPDUFilter
• Describe how to configure RootGuard
• Describe the problem with unidirectional links
• Describe LoopGuard
• Configure LoopGuard
• Verify LoopGuard configuration
• Describe how UDLD detects an unidirectional link and what action does it take
• Configure UDLD
• Compare UDLD to LoopGuard
• Describe the recommended practice for the UDLD implementation
• Describe the recommended practice for the implementation of STP stability mechanisms
• Describe how to configure FlexLinks
Cisco STP Toolkit
The Cisco Spanning Tree Protocol Toolkit provides tools to better manage STP.
PortFast, UplinkFast, and BackboneFast improve convergence times of non-rapid STP protocol. Other tools
provide stability and protect the network from STP failures if used properly.
UplinkFast and BackboneFast are mechanisms that can only be enabled with non-raipd STP. Both of these
two mechanisms are integrated into Rapid STP versions. Therefore you do not need to enable them.
UplinkFast
If forwarding uplink fails, it will take 30-50 seconds for the other uplink to take over. UplinkFast is a Cisco
proprietary solution that greatly reduces convergence time.
The UplinkFast feature is based on the definition of an uplink group. On a given switch, the uplink group
consists of the root port and all the ports that provide an alternate connection to the root bridge. If the root
port fails, which means if the primary uplink fails, a port with next lowest cost from the uplink group is
selected to immediately replace it.
To accelerate the recovery time, the access layer switch will start announcing all MAC addresses as source
addresses in dummy multicast frames that are sent upstream through the new forwarding port. The total time
to recover the primary link failure will be normally less than a second.
In the figure, if ASW's Ethernet 0/1 (root port) fails Ethernet 0/2 will become active immediately if ASW
has UplinkFast enabled.
UplinkFast only works when the switch has blocked ports. The feature is typically designed for an access
switch that has redundant blocked uplinks. When you enable UplinkFast, it is enabled for the entire switch
and cannot be enabled for individual VLANs.
UplinkFast is a Cisco proprietary feature.
To enable UplinkFast, use the following command:

ASW(config)# spanning-tree uplinkfast
By default UplinkFast is disabled.

Only enable UplinkFast on access layer switches with redundant uplinks. If you enable a transit switch for
UplinkFast, you risk an occurrence of an STP loop. A transit switch is a switch that connects to both the
root bridge and another switch. In the figure DSW1 is an example of a transit switch if DSW3 is the root
bridge. The only acceptable use of UplinkFast in the example is on ASW.
To verify the current status of STP UplinkFast use the following command:
ASW# show spanning-tree uplinkfast
UplinkFast is enabled
Station update rate set to 150 packets/sec.
UplinkFast statistics
-----------------------
Number of transitions via uplinkFast (all VLANs) : 2
Number of proxy multicast addresses transmitted (all VLANs) : 0
Name Interface List

-------------------- ------------------------------------
VLAN0001 Et0/1(fwd), Et0/2
With Rapid STP UplinkFast mechanism is already integrated into the protocol in a standards-based way.
BackboneFast
In the network backbone, core or distribution layer, BackboneFast can be used to fasten convergence times
of non-rapid STP. When an indirect link failure occurs, BackboneFast checks whether an alternative path
exists to the root bridge. Indirect failure is when a link that is not directly connected to a switch fails.
DSW3 is the root bridge and DSW2 is the one blocking DSW3's alternate path to DSW1. When DSW1's
root port fails, DSW1 declares itself the root bridge and starts sending BPDUs to all switches it's connected
to - in this case only DSW2. These BPDUs are inferior. When a switch receives an inferior BPDU on a
blocked port, it runs a procedure to validate that it still has an active path to the currently known root bridge.
Normally a switch must wait for the Max_Age timer to expire before responding to the inferior BPDUs.
However BackboneFast searches for an alternative path:
• If the inferior BPDU arrives on a port that is blocked, the switch assumes that the root port and all other
blocked ports are an alternative path.
• If the inferior BPDU arrives on a port that is root, the switch assumes all blocked are an alternative path.
If no ports are blocked then the switch assumes that it lost connectivity with the root bridge and
considers itself as the root bridge.
In the example, inferior BPDU is received on a blocked port. DSW2 assumes that root port (connects to
DSW4) is an alternative path to the root bridge.
After the switch identifies potential alternative ports, it starts sending RLQ. By sending these queries, it
finds out if upstream switches have a path to the root bridge.
When a switch, which is either the root bridge or has a connection to the root bridge, receives an RLQ
Query, the switch sends back a RLQ Reply. Otherwise RLQ Query gets forwarded until it gets to a switch
that is the root bridge or has a connection to the root bridge.
If exchange of RLQ messages results in validation that root bridge (DSW3) is still accessible, than switch
(DSW2) starts sending existing root bridge information to the bridge that lost connectivity through it's root
port (DSW1). In case that this validation would fail, then DSW2 can start the root bridge election process.
In either of these cases, if validation is successful or not, Max_Age time is shortened.
To configure BackboneFast, use the following command:

DSW1(config)# spanning-tree backbonefast
By default BackboneFast is disabled.

You need to configure BackboneFast on all switches in the network, because it relies to use RLQ messages
to inform other switches of STP stability.
To verify the current BackboneFast state issue the following command:
DSW1# show spanning-tree backbonefast
BackboneFast is enabled
BackboneFast was implemented into Rapid STP. RSTP implementation differs a bit from BackboneFast.
Where BackboneFast relies on RLQ messages to validate the current root bridge, RSTP relies on cached
information.
PortFast
An end-user PC connects to access-layer switches. When the PC is turned on, STP will have to go through
all the states - blocking, listening, learning, and eventually forwarding. With the default STP timers this
transition will take about 30 seconds. 15 seconds for listening to learning and 15 seconds from learning to
forwarding. PC won't be able to transmit or receive data before the switch transitions the port to forwarding
state. How can this affect the user PC? PC might run into trouble with acquiring of DHCP addresses in first
try - thus it will take quite some time for the PC to become operational.
When you enable PortFast, port will transition immediately from blocking to forwarding.
An additional benefit of using PortFast is that TCN BPDUs are not sent when a switch port in PortFast
mode goes up or down. In a large network, PCs might go up and down, and that can mean a lot of TCNs if
your access ports are not configured with PortFast.
By default PortFast is disabled on all switch ports. There are two ways you can configure PortFast—per-
port and globally. If you configure PortFast globally that is a conditional configuration—all ports that are
configured as access will automatically become PortFast-enabled. If you configure PortFast globally, then
ports that are PortFast enabled will immediately transition to forwarding. That is unless they receive a
BPDU. In that case that port will go into blocking mode. If you configure PortFast per-port, then in some
implementations, that can be an unconditional configuration. Port will be PortFast-enabled even if it
receives BPDUs.
To configure PortFast on port-per-port basis, use the following interface configuration command:
ASW(config-if)# spanning-tree portfast
To configure PortFast for all ports on the switch, use the following global configuration command:
ASW(config)# spanning-tree portfast default
Note Never use the PortFast feature on switch ports that connect to other switches, hubs, or
routers. These connections can cause physical loops, and spanning tree must go through
the full initialization procedure in these situations. A spanning tree loop can bring your
network down. If you turn on PortFast for a port that is part of a physical loop, there can be a
window of time when packets are continuously forwarded (and can even multiply) in such a
way that the network cannot recover.
You can also enable PortFast on trunk ports. This is useful if you have a trunk enabled for a host such as a
server that needs multiple VLANs. To enable a port for PortFast on an interface that connects to such
server, use the following interface configuration command:
ASW(config-if)# spanning-tree portfast trunk
To display the current status of PortFast, use the following command:
ASW# show spanning-tree interface ethernet 0/0 portfast
VLAN0001 enabled
You must only configure PortFast on interfaces that connect to end-devices such as PCs and servers.
Otherwise, you risk creating a loop and bringing down your network.
With RSTP PortFast is enabled with the same commands. However these single-host ports are called Edge
ports. But why would you want to enable PortFast in RSTP since convergence times are much shorter? If
you have numerous end-devices in your network and, they are going up-and-down all the time that can
mean many STP recalculations. Defining the Edge ports reduces the number of STP recalculations.
Securing PortFast Interface with BPDUGuard
Even though PortFast is enabled, the interface will listen for BPDUs. If BPDU is received, then port will be
moved into a blocking state. However, a loop can only be detected in a finite amount of time—some time is
needed to move a port into a blocked state.
BPDUGuard protects the integrity of ports that are PortFast-enabled. If any BPDU is received on a PortFast-
enabled port, that port is put into error-disabled state. That means the port is shut down and must be
manually re-enabled or automatically recovered through the error-disabled timeout function.
This is an example CLI notification that you would get if a switch was connected to a port that has
BPDUGuard enabled:
%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Et0/0 with BPDU Guard enabled.
Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Et0/0, putting Et0/0 in err-disable
state
You should always enable BPDUGuard on all PortFast-enabled ports! This will prevent adding a switch to a
switchport that is dedicated to an end-device.
BPDUGuard does not prevent all loop occurrences. A hub or some unmanaged switches do not send
BPDUs, therefore, BPDUGuard will not be able to detect them. If a hub or a switch connects to two
locations in a network, you might end up with a loop in your network.
By default BPDUGuard is disabled on all switch ports. Like with PortFast, there are two ways to configure
BPDUGuard-globally and per-port.
To configure BPDUGuard on a port, use the following interface configuration command:
ASW(config-if)# spanning-tree bpduguard enable
To configure BPDUGuard by default on all switchports that are PortFast-enabled use the following global
configuration command:
ASW(config)# spanning-tree portfast bpduguard default
So global configuration is conditional-if the port is not PortFast-enabled, BPDU guard will not be activated!
To verify if BPDUGuard is enabled use the following command:
ASW# show spanning-tree summary totals
Disabling STP with BPDUFilter
BPDUs are sent on all ports, even if they are PortFast-enabled. You should always run STP to prevent
loops. But there are special cases where you need to prevent from BPDUs being sent out. You can achieve
that by using BPDUFilter.
Configuring BPDUFilter so that all configuration BPDUs received on a port are dropped can be useful for
service provider environments, where a service provider provides Layer 2 Ethernet access for customers.
Ideally, the service provider does not want to share any spanning-tree information with customers, because
such sharing might jeopardize the stability of the service provider's internal spanning-tree topology. By
configuring PortFast and BPDUFilter on each customer access port, the service provider will not send any
configuration BPDUs to customers and will ignore any configuration BPDUs sent from customers.
This kind of configuration sometimes appears in companies where there are multiple administrators. A
similar situation occurs as with service provider described example. This is a bad implementation practice.
BPDUFilter behaves differently if applied globally or on per-port basis.
When enabled globally, BPDUFilter has these attributes:

• It affects all operational PortFast ports on switches that do not have BPDUFilter configured on the
individual ports.
• If BPDUs are detected, the port loses its PortFast status, BPDUFilter is disabled, and the STP sends and
receives BPDUs on the port as it would with any other STP port on the switch.
• Upon startup, the port transmits 10 BPDUs. If this port receives any BPDUs during that time, PortFast
and PortFast BPDUFilter are disabled.
When enabled on an individual port, BPDUFilter has these attributes:

• It ignores all BPDUs received.
• It sends no BPDUs.
Note An explicit configuration of PortFast BPDUFilter on a port that is not connected to a host
station can result in bridging loops. The port ignores any incoming BPDUs and changes to
the forwarding state. This does not occur when PortFast BPDUFilter is enabled globally.
To configure BPDUFilter on a specific port, use the following interface configuration command:
Switch(config-if)# spanning-tree bpdufilter enable
To configure BPDUFilter on all switchports that are PortFast-enabled use the following global configuration
command:
Switch(config)# spanning-tree portfast bpdufilter default
To verify global BPDUFilter configuration, use the following command:

Switch# show spanning-tree summary totals
Switch is in rapid-pvst mode
Root bridge for: none
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is enabled
Loopguard Default is disabled
To verify BPDUFilter configuration on a specific port, use the following command:

Switch# show spanning-tree interface ethernet 0/0 detail
Port 1 (Ethernet0/0) of VLAN0001 is designated forwarding
Port path cost 100, Port priority 128, Port Identifier 128.1.
Designated root has priority 28673, address aabb.cc00.0300
Designated bridge has priority 32769, address aabb.cc00.0200
Designated port id is 128.1, designated path cost 100
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is shared by default
Bpdu filter is enabled
Loop guard is enabled on the port
BPDU: sent 6732, received 0
Note If you configure BPDUGuard and BPDUFilter on a switch, only BPDUFilter will be active!
BPDUFIlter is an older mechanism than BPDUGuard. Never implement BPDUGuard and
BPDUFilter on the same interface!
Discovery 8: RootGuard
Overview
In this discovery, you will learn the role of RootGuard and how to configure it.
Topology
Topology in this lab has three switches. ASW is acting as an access layer switch. Other two switches are
core layer switches. The whole network is in VLAN 1.
Job Aids
RootGuard
Step 1 Validate that DSW1 is the root bridge for VLAN 1. Investigate which links are being blocked by
STP.
DSW1# show spanning-tree
VLAN0001

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
Et0/1 Desg FWD 10 128.2 Shr Peer(STP)
Currently DSW1 is the root bridge for VLAN1. It's BID is 28673 (priority 28672 + VLAN 1).
Since it is the root, interfaces that connect to DSW2 and ASW are forwarding traffic.
VLAN0001
Cost 10

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
DSW2 has a BID of 32769 (priority 32768 + VLAN 1). Interfaces connecting to DSW1 and
ASW are both in forwarding state.
ASW# show spanning-tree
VLAN0001
Cost 100

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
<... output omitted ....>
ASW has a BID of 32769 (priority 32768 + VLAN 1). Interface connecting to DSW1 is
forwarding. Interface connecting to DSW2 is in blocking state.
Step 2 Make ASW the root bridge for VLAN 1.
DSW1 is the root bridge for VLAN 1 with priority of 28672. You can, for example, assign ASW
an STP priority of 20480 and it will become the root bridge. The lower Bridge ID wins root
bridge election.
ASW(config)# spanning-tree vlan 1 priority 20480
Step 3 Verify that ASW is the root bridge for VLAN 1. Investigate which ports are now blocked by
STP.
VLAN0001

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
ASW is indeed the root bridge and has all ports forwarding.
VLAN0001
Cost 100

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
Et0/1 Desg FWD 10 128.2 Shr Peer(STP)
DSW1 has both ports forwarding.
VLAN0001
Cost 100

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
DSW2 has link towards ASW forwarding and port towards DSW1 blocked.
The Need for RootGuard
In the figure, switches DSW1 and DSW2 are the core of the network. DSW1 is the root bridge for VLAN 1.
ASW is an access layer switch. The link between DSW2 and ASW is blocking on the switch ASW side.
If Bridge ID of ASW is lowered, then ASW will become the root bridge. How can STP Bridge ID get
lowered? Maybe you changed it manually. Or ASW failed, you needed a quick replacement and you forgot
to erase a backup that you pulled out of a lab setup. Either way, the result is ASW being the root bridge.
Since ASW is the root bridge the link between DSW1 and DSW2 is not passing traffic. That link is blocked
on DSW2 side. This is clearly unwanted behavior since all traffic between these two switches must now go
through ASW - an access layer switch.
RootGuard limits the switch ports out of which the root bridge may be negotiated. If a RootGuard-enabled
port receives BPDUs that are superior to those being sent by the current root bridge, then that port will be
moved to a root-inconsistent state, which is effectively equal to an STP listening state.
Step 4 On ASW change STP priority for VLAN 1 back to the default value.
ASW(config)# no spanning-tree vlan 1 priority
Step 5 Verify that ASW is back at being non-root bridge for VLAN 1. Ethernet 0/2 should be back
being blocked by STP.
VLAN0001
Cost 100

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
The network has now the original, desired topology where DSW1 is the root bridge and ASW
has one of the two uplinks blocked.
Where Should RootGuard be Configured?
Step 6 Secure STP with RootGuard.
DSW1(config)# interface ethernet 0/0

DSW1(config-if)# spanning-tree guard root
*Nov 7 14:46:52.497: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on
port Ethernet0/0.
Ethernet 0/0 on DSW1 connects to ASW. You do not want ASW to become the Root Bridge, so
configure Ethernet 0/0 with RootGuard.

DSW2(config-if)# spanning-tree guard root
*Nov 7 14:48:52.497: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on
port Ethernet0/0.
Ethernet 0/0 on DSW2 connects to ASW. You do not want ASW to become the root bridge, so
configure Ethernet 0/0 with RootGuard.
To verify if RootGuard is configured under individual port use the show running-config
interface interface slot/number command.
Step 7 Try to make ASW the root bridge for VLAN 1 again.
ASW(config)# spanning-tree vlan 1 priority 20480
Step 8 Observe CLI of DSW1 and DSW2.
DSW1(config-if)#
*Nov 8 07:48:54.875: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port
Ethernet0/0 on VLAN0001.
DSW2(config-if)#
*Nov 8 07:48:54.875: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port
DSW1 and DSW2 are informing you that they detected a switch sending superior BPDU through
ports that are configured with RootGuard.
Step 9 Verify that DSW1 is still the root bridge, even though ASW has a better bridge ID.
VLAN0001

Aging Time 300 sec

------------------- ---- --- --------- -------- --------------------------------
Et0/0 Desg BKN*100 128.1 Shr *ROOT_Inc
DSW1 is still the root bridge. However, when DSW1 received a superior BPDU on RootGuard-
enabled port, it got marked as Root Inconsistent. No data traffic will be able to go across this
port - it is effectively an equal of STP listening state.
If you would issue show spanning-tree command on DSW2 you would see similar results - link
towards ASW would be root inconsistent.
If you issue show spanning-tree on ASW, you can see that ASW also thinks it is the root
bridge. This is because DSW1 and DSW2 can only ignore BPDUs from ASW, they cannot "tell"
ASW that it has no business being the root bridge!
Step 10 Use show spanning-tree inconsistentports on DSW2 verify which ports are root inconsistent.
DSW2# show spanning-tree inconsistentports
Name Interface Inconsistency

-------------------- ------------------------ ------------------
VLAN0001 Ethernet0/0 Root Inconsistent
Number of inconsistent ports (segments) in the system : 1
Port Ethernet 0/0, the one that connects to ASW is root inconsistent.
If you use show spanning-tree inconsistentports on DSW1 you will see similar output.
Recovery From Root Inconsistent State
In the example as soon as you configure ASW with a higher (worse) priority that DSW1, RootGuard will
unblock ports on DSW1 and DSW2:
*Nov 8 08:26:37.491: %SPANTREE-2-ROOTGUARD_UNBLOCK: Root guard unblocking port
The Problem with Unidirectional Links
With bidirectional links traffic flows in both directions. If for some reason one direction traffic flow fails,
that results into a unidirectional link. Unidirectional link can result into a Layer 2 loop.
So what would happen if transmit circuitry in gigabit interface converter or SPF (small form-factor
pluggable transceiver) module failed?
In the example, SW1 has a port, which is connected to SW2 and blocked by STP. Because SW1 is no longer
receiving BPDUs from SW2, SW1 will proceed to unblock the port.
Final result will be that all ports in the topology are forwarding. The result is a Layer 2 loop.
LoopGuard Overview
The STP LoopGuard feature provides additional protection against Layer 2 loops.
A Layer 2 loop is created when an STP blocking port in a redundant topology erroneously transitions to the
forwarding state. This usually happens because one of the ports of a physically redundant topology (not
necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on
continuous reception or transmission of BPDUs based on the port role. The designated port transmits
BPDUs, and the non-designated port receives BPDUs.
When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives
that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes
designated and moves to a forwarding state. This situation creates a loop.
The LoopGuard feature makes additional checks. If BPDUs are not received on a non-designated port, and
LoopGuard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the
listening / learning / forwarding state. Without the LoopGuard feature, the port assumes the designated port
role. The port moves to the STP forwarding state and creates a loop.
When the LoopGuard blocks an inconsistent port, this message is logged:
%SPANTREE-2-LOOPGUARD_BLOCK: LoopGuard blocking port FastEthernet0/24 o VLAN0050.
Once the BPDU is received on a port in a loop-inconsistent STP state, the port transitions into another STP
state. According to the received BPDU, this means that the recovery is automatic and intervention is not
necessary. After recovery, this message is logged:
%SPANTREE-2-LOOPGUARD_UNBLOCK: LoopGuard unblocking port FastEthernet0/24 VLAN0050.
In the example switch A is the root. Switch C does not receive BPDUs from switch B due to unidirectional
link failure on the link between switch B and switch C. Without LoopGuard, the STP blocking port on
switch C transitions to the STP listening state when the Max_Age timer expires, and then it transitions to the
forwarding state in two times the forward_delay time. This situation creates a loop. With LoopGuard
enabled, the blocking port on switch C transitions into STP loop-inconsistent state when the Max_Age timer
expires. A port in STP loop-inconsistent state does not pass user traffic, so a loop is not created. The loop-
inconsistent state is effectively equal to blocking state.
LoopGuard Configuration
The LoopGuard feature is enabled on a per-port basis. However, as long as it blocks the port on the STP
level, LoopGuard blocks inconsistent ports on a per-VLAN basis (because of per-VLAN STP). That is, if
BPDUs are not received on the trunk port for only one particular VLAN, only that VLAN is blocked
(moved to loop-inconsistent STP state). For the same reason, if enabled on an EtherChannel interface, the
entire channel is blocked for a particular VLAN, not just one link (because EtherChannel is regarded as one
logical port from the STP point of view).
On which ports should the LoopGuard be enabled? The most obvious answer is on the blocking ports.
However, this is not totally correct. LoopGuard must be enabled on the non-designated ports (more
precisely, on root and alternate ports) for all possible combinations of active topologies. As long as the loop
guard is not a per-VLAN feature, the same (trunk) port might be designated for one VLAN and non-
designated for the other. The possible failover scenarios should also be taken into account.
By default, LoopGuard is disabled. You can configure LoopGuard globally or on a port-per-port basis.
If you enable LoopGuard globally, then effectively, it is enabled on all point-to-point links. The point-to-
point link is detected by the duplex status of the link. If duplex is full, the link is considered point-to-point.
It is still possible to configure, or override, global settings on a per-port basis.
The RootGuard is mutually exclusive with the LoopGuard. The RootGuard is used on designated ports, and
it does not allow the port to become non-designated. The LoopGuard works on non-designated ports and
does not allow the port to become designated through the expiration of Max_Age. The RootGuard cannot be
enabled on the same port as the LoopGuard. When the LoopGuard is configured on the port, it disables the
RootGuard configured on the same port.
LoopGuard Verification
UDLD Overview
UDLD is a Cisco proprietary protocol that detects unidirectional links and prevents from Layer 2 loops from
occurring.
UDLD is a Layer 2 protocol that works with the Layer 1 mechanisms to determine the physical status of a
link. If one fiber strand in a pair is disconnected, autonegotiation will not allow the link to become active or
stay up. If both fiber strands are operant from a Layer 1 perspective, UDLD determines if traffic is flowing
bidirectionally between the correct neighbors.
The switch periodically transmits UDLD packets on an interface with UDLD enabled. If the packets are not
echoed back within a specific time frame, the link is flagged as unidirectional and the interface is error-
disabled. Devices on both ends of the link must support UDLD for the protocol to successfully identify and
disable unidirectional links.
Both UDLD peers discover each other by exchanging special frames that are sent to well-known MAC
address 01:00:0C:CC:CC:CC.
Although the UDLD protocol falls outside of STP, UDLD has numerous benefits that make it essential in a
Layer 2 network. The function of UDLD is to prevent one-way communication between adjacent devices.
In an EtherChannel bundle, UDLD will error-disabled only the physical link that has failed.
UDLD messages are sent at regular intervals. This timer can be modified. The default setting varies between
platforms. Typical value is 15 seconds.
UDLD is a Cisco proprietary protocol that is also defined in RFC 5171.
After UDLD detects unidirectional link it can take two courses of action - depending on configured mode.
• Normal mode - When unidirectional link is detected the port is allowed to continue its operation.
UDLD just marks the port as having an undetermined state. A Syslog message is generated.
• Aggressive mode - When a unidirectional link is detected the switch tries to re-establish the link. It
sends one message a second, for 8 seconds. If none of these messages is sent back, the port is placed in
error-disabled state.
UDLD Configuration
You configure UDLD on per-port basis. However you can enable UDLD for all fiber-optic ports globally.
For normal mode, use the enable keyword. For aggressive mode specify the aggressive keyword.
Default status for the UDLD on a global and an interface basis:
Feature Default Status
UDLD global enable state Globally disabled.
UDLD per-interface enable state for fiber-optic Enabled on all Ethernet fiber-optic interfaces.
media
UDLD per-interface enable state for tw isted-pair Disabled on all Ethernet 10 or 100 and 1000BASE-TX interfaces.
(copper) media
To display the UDLD status for the specified interface or for all interfaces, use the show udld [interface
slot/number] privileged EXEC command.
Use udld reset command to reset all the interfaces that were shut down by UDLD. You can achieve the
same thing by first shutting down the interface and then bringing it back up.
Comparing LoopGuard with UDLD
LoopGuard and UDLD functionality overlap, partly in the sense that both protect against STP failures that
are caused by unidirectional links. However, these two features differ in functionality and how they
approach the problem.
UDLD provides no protection against STP failures that are caused by software and that result in the
designated switch not sending BPDUs. However, this type of failure is less common than problems caused
by a hardware failure.
On an EtherChannel bundle, UDLD will disable individual failed links. The channel itself remains
functional if other links are available. LoopGuard will put the entire channel into a loop-inconsistent state if
any physical link in the bundle fails.
LoopGuard does not work on shared links or on a link that has been unidirectional since its initial setup.
Enabling both UDLD and LoopGuard provides the highest level of protection.
UDLD Recommended Practices
UDLD supports both fiberoptic and copper Ethernet cables that are connected to LAN ports.
A recommended practice is to enable UDLD aggressive mode in all environments where fiber-optic
interconnections are used.
You should enable UDLD in global mode so that you do not have to enable it on every individual fiber-
optic interface.
STP Stability Mechanisms Recommendations
Spanning tree should be used, and its topology should be controlled by root bridge manual designation.
Once the tree is created, use the Cisco Spanning Tree Protocol Toolkit to enhance the overall mechanism
performances and to reduce the time that is lost during topology changes.
The Cisco Rapid Spanning Tree Protocol implementation is far superior to 802.1D STP and even to PVST+
from a convergence perspective. It greatly improves the restoration times for any VLAN that requires a
topology convergence due to linkup, and it also greatly improves the convergence time over BackboneFast
for any indirect link failures and UplinkFast for any uplink failures.
These are recommended practices for using STP stability mechanisms:

• PortFast: Apply to all end-user ports. To secure PortFast-enabled ports, always combine PortFast with
BPDUGuard.
• RootGuard: Apply to all ports where root is never expected.
• LoopGuard: Apply to all ports that are or can become non-designated.
Depending on the security requirements of an organization, the port security feature can be used to restrict
the ingress traffic of a port by limiting the MAC addresses that are allowed to send traffic into the port.
The use of RootGuard and LoopGuard is mutually exclusive.
Note Examples where you will need to implement BPDUFilters are very rare. Under no
circumstances use BPDUFilter and BPDUGuard on the same interface.
Note If a network includes other vendor switches, you should isolate the different STP domains
with Layer 3 routing to avoid STP compatibility issues.
FlexLinks
FlexLink is a Layer 2 availability feature that gives convergence of 50-100ms. Flex links are Cisco
proprietary. Configuration automatically disables STP on affected ports.
FlexLinks are a pair of a Layer 2 interfaces, where one interface is configured to act as a backup to the
other. FlexLinks are typically configured in service-provider or enterprise networks where customers do not
want to run STP. FlexLinks provide link-level redundancy that is an alternative to STP. STP is
automatically disabled on FlexLinks interfaces.
To configure the FlexLinks feature, you configure one Layer 2 interface as the standby link for the link that
you want to be primary. With FlexLinks configured for a pair of interfaces, only one of the interfaces is in
the linkup state and is forwarding traffic. If the primary link shuts down, the standby link starts forwarding
traffic. When the inactive link comes back up, it goes into standby mode.
In the example, ports FastEthernet 0/1 and FastEthernet 0/2 on switch A are connected to uplink switches B
and C. Because they are configured as Flex Links, only one of the interfaces is forwarding traffic and the
other one is in standby mode. If FastEthernet 0/1 is the active link, it begins forwarding traffic between port
Ethernet 0/1 and switch B; the link between FastEthernet 0/2 (the backup link) and switch C is not
forwarding traffic. If port FastEthernet 0/1 goes down, port FastEtherent 0/2 comes up and starts forwarding
traffic to switch C. When port Ethernet0/1 comes back up, it goes into standby mode and does not forward
traffic; port FastEthernet 0/2 continues to forward traffic.
Note Example shows a simple configuration of an access layer switch. However you can
configure FlexLink even on much more complex switch networks. You will have to take
special care to avoid creating a loop in topology. None of the converged state can have a
topology loop. Configuring Flex link outside access layer switches can be very complex.
Note After primary link comes back up, it will not take over forwarding of traffic. Preemption is not
enabled for FlexLink by default - it needs to be configured.
If a primary (forwarding) link goes down, a trap notifies the network management stations. If the standby
link goes down, a trap notifies the users.
When a primary link fails, the feature takes these actions:

• Detects the failure.
• Moves any dynamic unicast MAC addresses that are learned on the primary link to the standby link.
• Moves the standby link to a forwarding state.
• Transmits dummy multicast packets over the new active interface. The dummy multicast packet format
is:
− Destination: 01:00:0c:cd:cd:cd
− Source: MAC address of the hosts or ports on the newly active Flex Link port.
In figure, ports FastEthernet 0/1 and FastEthernet 0/2 on switch A are connected to switches B and D
through a Flex Link pair. FastEthernet 0/1 is forwarding traffic, and FastEthernet 0/2 is in the blocking state.
Traffic from the PC to the server is forwarded from FastEthernet 0/1 to FastEthernet 0/3. The MAC address
of the PC has been learned on port 3 of switch C. Traffic from the server to the PC is forwarded from port 3
to port 1.
If FastEthernet 0/1 shuts down, FastEthernet 0/2 starts forwarding traffic. If there is no traffic from the PC
to the server after failover to FastEthernet 0/2, switch C does not learn the MAC address of the PC on
FastEthernet 0/4, and because of that, switch C keeps forwarding traffic from the server to the PC out of
FastEthernet 0/3. There is traffic loss from the server to the PC because FastEthernet 0/1 is down. To
alleviate this problem, the feature sends out a dummy multicast packet with the source MAC address of the
PC over FastEthernet 0/2. Switch C learns the PC MAC address on FastEthernet 0/4 and start forwarding
traffic from the server to the PC out of FastEthernet 0/4. One dummy multicast packet is sent out for every
MAC address.
Follow these guidelines to configure FlexLinks:

• You can configure only one FlexLink backup link for any active link, and it must be a different
interface from the active one.
• An interface can belong to only one FlexLink pair. An interface can be a backup link for only one active
link. An active link cannot belong to another FlexLink pair.
• Neither of the links can be a port that belongs to an EtherChannel. However, you can configure two port
channels (EtherChannel logical interfaces) as FlexLinks, and you can configure a port channel and a
physical interface as FlexLinks, with either the port channel or the physical interface as the active link.
• A backup link does not have to be the same type (Fast Ethernet, Gigabit Ethernet, or port channel) as
the active link. However, you should configure both FlexLinks with similar characteristics so that there
are no loops or changes in behavior if the standby link begins to forward traffic.
• STP is disabled on FlexLink ports. A FlexLink port does not participate in STP, even if the VLANs that
are present on the port are configured for STP. When STP is not enabled, be sure that there are no loops
in the configured topology.
It is a pair of Layer 2 interfaces, either switch ports or port channels, that are configured to act as a backup
to another Layer 2 interface. The feature provides an alternative solution to the STP, and it allows users to
turn off STP and still provide basic link redundancy. An active/standby link pair is defined on a common
access switch.
Flex Links is configured at the interface level with the command:
switchport backup interface interface slot/number
To verify FlexLink configuration use show interface switchport backup command.
Summary
Multiple Spanning Tree
Protocol
Overview
The 802.1Q and PVST+ represent two extremes of STP operation. 802.1Q has only a single instance for all
VLANs in the network. If your network is running 1000 VLANs, only one instance runs for all 1000
VLANs. With PVST+ one instance is used for each active VLAN in the network. If your network has 1000
VLANs, there will be 1000 independent instances of STP running.
MST is a concept of mapping one or more VLANs to a single STP instance.
• Describe when and why to use MST
• Identify the role of MST regions
• Describe MST Instances
• Describe the Extended System ID for MST
• Configure MST
• Verify MST
• Configure MST Path Cost
• Configure MST Port Priority
• Describe recommended practices when migrating a network to MST
• Describe the MST recommended practices
Introducing Multiple Spanning Tree Protocol
The main purpose of MST is to reduce the total number of spanning-tree instances to match the physical
topology of the network. Reducing the total number of spanning-tree instances will reduce the CPU loading
of a switch. The number of instances of spanning tree is reduced to the number of links (that is, active paths)
that are available.
In the example PVST+ was implemented. There could be up to 4094 instances of spanning tree, each with
its own BPDU conversations, root bridge election, and path selections.
Imagine an example where the goal would be to achieve load distribution with VLANs 1 through 500 using
one path and VLANs 501 through 1000 using the other path. Instead of creating 1000 PVST+ instances, you
can use MST with only two instances of spanning tree. The two ranges of VLANs are mapped to two MST
instances, respectively. Rather than maintaining 1000 spanning trees, each switch needs to maintain only
two.
Implemented in this fashion, MST converges faster than PVST+ and is backward-compatible with 802.1D
STP, 802.1w RSTP, and the Cisco PVST+ architecture. Implementation of MST is not required if the Cisco
Enterprise Campus Architecture is being employed, because the number of active VLAN instances, and
hence the STP instances, would be small and very stable due to the design.
MST allows you to build multiple spanning trees over trunks by grouping VLANs and associating them
with spanning-tree instances. Each instance can have a topology independent of other spanning-tree
instances. This architecture provides multiple active forwarding paths for data traffic and enables load
balancing.
Network fault tolerance is improved over CST because a failure in one instance (forwarding path) does not
necessarily affect other instances. This VLAN-to-MST grouping must be consistent across all bridges
within an MST region. Interconnected bridges that have the same MST configuration are referred to as a
MST region.
In large networks, you can more easily administer the network and use redundant paths by locating different
VLAN and spanning-tree assignments in different parts of the network. A spanning-tree instance can exist
only on bridges that have compatible VLAN instance assignments.
You must configure a set of bridges with the same MST configuration information, which allows them to
participate in a specific set of spanning-tree instances. Bridges with different MST configurations or legacy
bridges running 802.1D are considered separate MST regions.
Note MST is defined in the IEEE 802.1s standard. Before the standardized MST there was Cisco
multiple spanning tree protocol implementation or MISTP.
MST Regions
MST differs from the other spanning-tree implementations in combining some but not necessarily all
VLANs into logical spanning-tree instances. This difference raises the problem of determining which
VLAN is supposed to be associated with which instance. VLAN-to-instance association is communicated
by tagging the BPDUs so that the receiving device can identify the instances and the VLANs to which they
apply.
To provide this logical assignment of VLANs to spanning trees, each switch that is running MST in the
network has a single MST configuration consisting of three attributes:
• An alphanumeric configuration name (32 bytes).
• A configuration revision number (2 bytes).
• A 4096-element table that associates each of the potential 4096 VLANs supported on the chassis with a
given instance.
To be part of a common MST region, a group of switches must share the same configuration attributes. It is
the responsibility of the network administrator to propagate the configuration properly throughout the
region. Currently, this step is possible only with the CLI or through the SNMP. Other methods can be
implemented in the future because the IEEE specification does not explicitly mention how to accomplish
this task.
To ensure a consistent VLAN-to-instance mapping, it is necessary for the protocol to be able to identify the
boundaries of the regions exactly. For that purpose, the characteristics of the region are included in BPDUs.
The exact VLAN-to-instance mapping is not propagated in the BPDU because the switches need to know
only whether they are in the same region as a neighbor.
Therefore, only a digest of the VLAN-to-instance mapping table is sent, along with the revision number and
the name. After a switch receives a BPDU, it extracts the digest (a numerical value that is derived from the
VLAN-to-instance mapping table through a mathematical function) and compares it with its own computed
digest. If the digests differ, the mapping must be different, so the port on which the BPDU was received is at
the boundary of a region.
In generic terms, a port is at the boundary of a region if the designated bridge on its segment is in a different
region or if it receives legacy 802.1D BPDUs.
Configuration revision number gives you a method of tracking changes that are made to the MST region. It
does not automatically increase each time that you make changes to the MST configuration. Each time that
you make a change you should increase the revision number by one.
STP Instances with MST
MST protocol does not send BPDUs for every active STP instance separately. A special instance—instance
0, is designed to carry all STP-related information. BPDUs carry all the usual STP information, as well as
configuration name, revision number, and hash value that is calculated over VLAN-to-instance mappings
tables. If hash values do not match, then there is an MST misconfiguration between the two switches.
MST supports a number of instances. Instance 0 is the IST.

Figure shows how different MSTIs exist within a single MST region. MSTI1 and MSTI2 are mapped to
different VLANs. Their topologies converge differently because root bridges are configured differently.
Within the MST region there are three independent STP instances: MSTI0 (IST), MSTI1 and MSTI2.
In the figure on the left, all six VLAN instances belong to MSTI0. This is the default behavior. Then half of
VLAN instances (11, 22, and 33) were mapped to MSTI1, and the other half (44, 55, and 66) were mapped
to MSTI2. If different root bridges are configured for MSTI1 and MSTI2, their topologies will converge
differently. By having different layer two topologies between MST instances, links are more evenly utilized.
Within a topology where multiple variations of STP are used, CST Topology considers MST region as a
single black-box. CST maintains a loop-free topology with the links that connect the regions to each other
and to switches that are not running MST.
Within the MST region, internal spanning tree instance maintains a loop free topology. IST presents the
whole MST region as a single virtual bridge to the outside STP. BPDUs between the MST's STP instance
and the CST's STP instance are exchanged over the native VLAN - as if a single CST was used.
MST is compatible with other flavours of STP. In the figure on the left a there are three switches running
within a MST region and two switches that are not running MST. The figure on the right shows how the IST
provides a loop-free path within a MST region. IST instance makes the whole region look like one single
bridge that interacts with BPDU's with the switches outside the MST region.
The MSTIs are simple RSTP instances that only exist inside a region. These instances run the RSTP
automatically by default, without any extra configuration work. Unlike the IST, MSTIs never interact with
the outside of the region. Remember that MST only runs one spanning tree outside of the region, so except
for the IST instance, regular instances inside of the region have no outside counterpart. Additionally, MSTIs
do not send BPDUs outside a region, only the IST does.
By default all VLANs are mapped to the IST instance. This represents the case of classic IEEE RSTP with
all VLANs sharing the same spanning-tree. You must explicitly map them to other instances.
Recommended practice is to map VLANs instances other than MSTI0. Leave MSTI0 for mapping VLANs
that connect to switches that are not running MST. Every MSTI assign its own priorities to the switches and
use its own link costs to come up with a private logical topology, separate from the IST. MST does not send
MST's information in separate BPDUs. MSTI information is carried in the IST's BPDU! This information is
carried in so-called M-Record fields - one for every active MSTI.
Extended System ID for MST
As with PVST, the 12-bit Extended System ID field is used in MST. In MST, this field carries the MST
instance number.
Discovery 9: Configuring MST
Overview
In this discovery, you will learn how to configure multiple spanning tree protocol.
Figure on the left represents STP configuration at the beginning of this lab. All three switches are
configured with PVST+ and four user-created VLANs: 2, 3, 4, and 5. SW1 is configured as the root bridge
for VLANs 2 and 3. SW2 is configured as the root bridge for VLANs 4 and 5. This configuration distributes
forwarding of traffic between the SW3-SW1 and SW3-SW2 uplinks.
Figure on the right shows the STP configuration that you will perform in this lab. VLANs 2 and 3 are
mapped into MST instance 1. VLANs 4 and 5 are mapped into MST instance 2.
Topology
Job Aids
Device Information
Device Interface Neighbor Neighbor Interface
SW1 Eth0/0 SW2 Eth0/2
Configuring MST
Step 1 Investigate spanning tree instances on SW3.
SW3# show spanning-tree summary

Switch is in pvst mode
Root bridge for: none
Name Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001 1 0 19 0 20
VLAN0002 1 0 2 0 3
VLAN0003 1 0 2 0 3
VLAN0004 1 0 2 0 3
VLAN0005 1 0 2 0 3
---------------------- -------- --------- -------- ---------- ----------
5 vlans 5 0 27 0 32
An STP instance is created for each VLAN with PVST+. In this lab, 5 VLANs translate into 5
STP instances.
If you investigate SW1 and SW2, you will discover that both have the same number of running
STP instances as SW3.
Step 2 Configure all three switches to be a part of the same MST region - "CCNP", and have the same
revision - "1".
SW1(config)# spanning-tree mst configuration

SW1(config-mst)# name CCNP
SW1(config-mst)# revision 1
SW2config)# spanning-tree mst configuration

Now all three switches belong to the same MST region.
Step 3 On all three switches, map VLANs 2 and 3 to MST instance 1. Map VLANs 4 and 5 to MST
instance 2.

SW1(config-mst)# instance 1 vlan 2,3
SW1(config-mst)# end


At this point, MST is configured with three instances. VLANs 2, 3 belong to instance 1. VLANs
4 and 5 belong to instance 2. All other VLANs between 1 and 4094, that are not in instances 1 or
2, belong to instance 0.
Using end or exit command will apply configuration. If you want to abort change use abort
keyword.
Step 4 Configure SW1 as primary root bridge for MST instance 1 and secondary root for instance 2.
SW1(config)# spanning-tree mst 1 root primary

SW1(config)# spanning-tree mst 2 root secondary
In this example, you have changed the MST switch priority using spanning-tree mst instance-id
root {primary|secondary}. This command is actually a macro that sets the switch's MST
priority, which is a number. If you issue a show running-config you will see switch priority as a
number—not the primary or secondary keyword.
Alternatively you can change the switch's bridge priority directly, by using the spanning-tree
mst instance-id priority priority command.
Step 5 Configure SW2 as secondary root bridge for MST instance 1 and primary root for instance 2.
SW2(config)# spanning-tree mst 1 root secondary

SW2(config)# spanning-tree mst 2 root primary
Step 6 Change STP mode to MST on all three switches.
SW1(config)# spanning-tree mode mst
Changing STP mode to MST before doing the actual VLAN-to-instance mappings is not
advisable. Every change in the mapping will result in recalculation of the STP tree.
A switch cannot run MST and PVST+ at the same time. If you issue show spanning-tree on
either of the three switches you will notice that "mstp" is now the enabled protocol.
Step 7 Again, investigate spanning tree instances on SW3.
SW3# show spanning-tree summary

Switch is in mst mode (IEEE Standard)
Name Blocking Listening Learning Forwarding STP Active

---------------------- -------- --------- -------- ---------- ----------
MST0 0 0 0 24 24
MST1 0 0 0 4 4
MST2 0 0 0 4 4
---------------------- -------- --------- -------- ---------- ----------
3 msts 0 0 0 32 32
MST runs three instances; the default MSTI0 and the two you configured—MSTI1 and MSTI2.
Step 8 Investigate MST configuration on SW3.

SW3(config-mst)# show current
Current MST configuration
Name [CCNP]
Revision 1 Instances configured 3
Instance Vlans mapped

-------- ---------------------------------------------------------------------
0 1,6-4094
1 2-3
2 4-5
-------------------------------------------------------------------------------
VLANs 2 and 3 are mapped to MSTI1 . VLANs 4 and 5 are mapped to MSTI2 . All other
VLANs are mapped to MSTI0 or IST.
To verify currently applied MST configuration use show current under MST configuration
mode. To verify pending MST configuration use show pending under MST configuration mode.
When you type exit or end, pending configuration will become current. Thus show current and
show pending will produce the same outputs.
Step 9 Verify MST message digest on all three switches.
SW1# show spanning-tree mst configuration digest

Name [CCNP]
Digest 0x47CAC1CE872FFD89640049F4CC87BCB2
Pre-std Digest 0x6E07725683888804D99F3D3BE25CA594

Name [CCNP]

Name [CCNP]
Since MST configuration is identical on all three switches in a region, the digest matches. A
mismatch in digest would indicate that the VLAN lists do not match between switches. Note that
digest may be different in your case. It only matters that the digest is the same on all three
switches.
The "Pre-std Digest" refers to Cisco's legacy pre-standard implementation of MST. Cisco
developed a proprietary version of MST before MST was released called MISTP, which has
similar principles as MST.
Step 10 On SW3 verify MSTI1 and MSTI2 mappings and Layer2 convergence.
SW3# show spanning-tree mst 1
##### MST1 vlans mapped: 2-3

<... output omitted ..>
Et0/2 Altn BLK 2000000 128.3 Shr
Et0/3 Root FWD 2000000 128.4 Shr
SW3# show spanning-tree mst 2
##### MST2 vlans mapped: 4-5

Et0/2 Root FWD 2000000 128.3 Shr
Et0/3 Altn BLK 2000000 128.4 Shr
MST instances 1 and 2 have two distinct Layer 2 topologies. Instance 1 uses uplink towards
SW1 as the active link and blocks uplink towards SW2. Instance 2 uses uplink towards SW2 as
the active link and blocks uplink towards SW1.
You can use show spanning-tree mst 1 to verify that SW1 is the root bridge for instance 1.
Also, you can use show spanning-tree mst 2 on SW2 to verify that SW2 is the root bridge for
instance 2.
Configuring MST Path Cost
Path cost functions the same as with other STPs, except with MST port costs are configured per instance.
MST, like any other STP, uses the sequence of four criteria to choose the best path:
1 Lowest bridge ID.
2 Lowest root path cost.
You can assign lower-cost values to interfaces that you want selected first and higher-cost values that you
want selected last. If all interfaces have the same cost value, the MST puts the interface with the lowest
sender port ID in the forwarding state and blocks the other interfaces.
To change STP cost of an interface enter interface configuration mode for that interface and use command
spanning-tree mst instance cost cost. For instance you can specify a single instance, a range of instances
that are separated by a hyphen, or a series of instances that are separated by a comma. The range is 0 to
4094. For cost, the range is 1 to 200000000; the default value is usually derived from the media speed of the
interface.
To verify MST path cost settings use show spanning-tree mst interface interface-id or show spanning-
tree mst instance-id. However, information is displayed only for ports that are in a link-up operative state.
Otherwise, you can use the show running-config command to confirm the configuration.
Configuring MST Port Priority
Port priority functions the same as with other STPs, except with MST port priorities are configured per
instance.
MST, like any other STP, uses the sequence of four criteria to choose the best path:
1 Lowest bridge ID.
2 Lowest root path cost.
You can assign higher sender's priority values (lower numerical values) to interfaces that you want selected
first and lower sender's priority values (higher numerical values) that you want selected last. If all sender's
interfaces have the same priority value, the MST puts the interface with the lowest sender port ID in the
forwarding state and blocks the other interfaces.
To change interface's STP port priority, enter interface configuration mode and use spanning-tree mst
instance port-priority priority command.
For instance, you can specify a single instance, a range of instances that are separated by a hyphen, or a
series of instances that are separated by a comma. The range is 0 to 4094. For priority, the range is 0 to 240
in increments of 16. The default is 128. The lower the number, the higher the priority. To return the
interface to its default setting, use the no spanning-tree mst instance port-priority interface configuration
command.
To verify port priority setting use show spanning-tree mst interface interface or show spanning-tree mst
instance. However, information is displayed only for ports that are in a link-up operative state. Otherwise,
you can use the show running-config command to confirm the configuration.
MST Protocol Migration
The first step in the migration to 802.1s is to properly identify point-to-point and edge ports. Ensure all
switch-to-switch links, on which a rapid transition is desired, are full-duplex. Edge ports are defined through
the PortFast feature. Carefully decide how many instances are needed in the switched network, and keep in
mind that an instance translates to a logical topology. Decide what VLANs to map onto those instances, and
carefully select a root and a back-up root for each instance. Choose a configuration name and a revision
number that will be common to all switches in the network. Cisco recommends that you place as many
switches as possible into a single region; it is not advantageous to segment a network into separate regions.
Avoid mapping any VLANs onto instance 0. Migrate the core first. Change the STP type to MST, and work
your way down to the access switches. MST can interact with legacy bridges running PVST+ on a per-port
basis, so it is not a problem to mix both types of bridges if interactions are clearly understood. Always try to
keep the root of the CST and IST inside the region. If you interact with a PVST+ bridge through a trunk,
ensure that the MST bridge is the root for all VLANs allowed on that trunk.
When you enable MST, it also enables RSTP. The spanning tree UplinkFast and BackboneFast features are
PVST+ features, and are disabled when you enable MST because those features are built within RSTP, and
MST relies on RSTP. Within the migration, you can remove those commands in IOS.
The configuration of the features such as the PortFast, BPDUGuard, BPDUFfilter, RootGuard, and
LoopGuard are also applicable in MST mode. The usage of these features is the same as in PVST+ mode. If
you have already enabled these features in the PVST+ mode, it remains active after the migration to MST
mode.
Note Do not use LoopGuard in combination with BPDUGuard. If BPDUGuard and BPDUFilter are
enabled at the same time, only BPDUFilter is active.
MST Recommended Practice
There are some issues that you can run across because MST instances do not map one-to-one with VLANs.
With PVST+ not allowing a VLAN on trunk link would also disable STP on that link. With MST every
instance is running on every link in the region. If you disallow a VLAN on a trunk link, you might end up
with connectivity issues.
Figure 1 shows a network where VLANs are manually pruned on trunks. Since pruning is not consistent
with MST configuration, VLAN10's traffic is blocked between Switch1 and Switch2.
You would have the same problem if you would configure one of the two links as access. For example, one
link as access VLAN 10 and the other link as access VLAN 20, as figure 2 shows. These 2 access VLANs
use the same STP instance!
It is recommended that you do not run MST on access-ports and that you do not manually prune VLANs
from trunks.
Figure shows Switch1 and Switch2 connected with access ports each located in different VLANs. VLAN 10
and VLAN 20 are mapped to different instances. VLAN 10 is mapped to instance 0 and VLAN 20 is
mapped to instance 1.
With this configuration no VLAN 10 traffic will be able to pass between the switches! How is that possible
with no apparent loop?
This issue is explained by the fact that MST information is conveyed with only one BPDU (IST BPDU),
regardless of the number of internal instances. Individual instances do not send individual BPDUs. When
Switch1 and Switch2 Exchange STP information for VLAN 20, the switches send an IST BPDU for
instance 1 because that is where VLAN 20 is mapped. However, because it is an IST BPDU, this BPDU
also contains information for instance 0. This means that the IST instance is active on all ports inside an
MST region, whether these ports carry VLANs mapped to the IST instance or not.
Switch2 receives two BPDUs for instance 0 from Switch1 (one on each port). Switch2 then needs to block
one of the two ports in order to prevent a loop.
The solution is to avoid mapping VLANs to the IST instance or to convert links to trunks and allow all
VLANs to pass through.
Summary
Overview
Check
1. Which command enables rapid spanning-tree on a switch? (Source: Implementing RSTP)

A. spanning-tree mode rapid-pvst
B. no spanning-tree mode pvst
C. spanning tree mode rstp
D. rapid spanning-tree enable
2. When a switch running RSTP receives an 802.1D BPDU, what happens? (Source: Implementing RSTP)
A. The switch disables RSTP.
B. The switch begins to use 802.1D rules on that port.
C. BPDU is discarded.
D. 802.1D BPDU is translated into 802.1w BPDU and processed.
3. Which of the following is a STP port state but not a RSTP port state? (Source: Implementing RSTP)
A. Forwarding
B. Learning
C. Listening
D. Discarding
4. Why is it important to protect the placement of the root bridge? (Source: Implementing STP Stability
Mechanisms)
A. To prevent Layer 2 loops.
B. To keep Layer 2 topology predictable in such a way that traffic flows are always efficient.
C. To prevent from two switches to become root bridges.
D. To prevent Layer 3 loops.
5. Can PortFast be configured on a trunk link? (Source: Implementing STP Stability Mechanisms)
A. No, PortFast is disabled by the command switchport mode trunk.
B. Yes, enabling PortFast globally applies PortFast to all ports, including trunks.
C. Yes, it can be configured on a port-to-port basis and with caution, because loops may occur.
D. No, the portfast keyword is available only with the switchport mode access command.
6. Which two statements are true of LoopGuard? (Choose two) (Source: Implementing STP Stability
Mechanisms)
A. It allows a blocked port in a physically redundant topology to stop receiving BPDUs.
B. It provides additional protection against Layer 2 STP loops.
C. It moves ports into the STP loop-inconsistent state, if BPDUs are not received on a nondesignated
port.
D. It enables the blocking port to move to the forwarding state.
7. Which standard describes Multiple Spanning Tree protocol? (Source: Implementing STP Stability
Mechanisms)
A. 802.1s
B. 802.1D
C. 802.1w
D. 802.1Q
8. Which two features apply to MST? (Choose two) (Source: Implementing Multiple Spanning Tree
Protocol)
A. It groups a set of instances to a single VLAN.
B. It can group a set of VLANs to a single spanning-tree instance.
C. A failure in one instance can cause a failure in another instance.
D. The total number of spanning-tree instances should match the number of redundant switch paths.
9. How are VLANs mapped to instances by default with MST? (Source: Implementing Multiple Spanning
Tree Protocol)
A. All VLANs are mapped to MST Instance 0.
B. All VLANs are mapped to MST Instance 1.
C. Each VLAN is mapped to it's own instance.
D. All VLANs are un-mapped.
Answer Key
1 A
2 B
3 C
4 B
5 C
6 B, C
7 A
8 B, D
9 A
Module 4: Configuring Inter-
VLAN Routing
Introduction
To transport packets between VLANs you will need a Layer 3 device. This can be either a router or a switch
with Layer 3 capabilities.
Inter-VLAN routing can be performed by an external router that uses a separate link for each VLAN. Since
the number of physical connections on a switch is limited this is not a scalable solution. A better solution is
to have a single trunk link, between the router and the switch, carrying data for all VLANs. This setup is
commonly called "router on a stick" or "one-armed router".
A convenient solution is to have a device that combines switching and routing functions into one device - a
multilayer switch. In that case no external router is needed.
Upon completing this module, you will be able to:

• Configure external router for inter-VLAN routing
• Configure routing on a multilayer switch
Inter-VLAN Routing Using a
Router
Overview
A switch with multiple VLANs requires a means of passing Layer 3 traffic between those different VLANs.
One of the possibilities is the use of an external router, that can perform inter-VLAN routing.
Router can use different physical connections for each VLAN, or each VLAN can be accessed through a
single trunk link. The later configuration is commonly referred as a "router on a stick" or a "one-armed
router".
• Explain what is Inter-VLAN routing using an external router
• Configure Inter-VLAN routing using an external router
• Verify router-on-a-stick configuration and operation
• Describe the advantages and disadvantages of configuring Inter-VLAN routing using an external router
Inter-VLAN Routing Using an External Router
Overview
A VLAN defines a broadcast domain. At Layer 3, broadcast domains are defined by IP subnets. For this
reason, there is normally a one-to-one mapping of VLANs to IP subnets.
If a switch supports multiple VLANs but has no Layer 3 capability to route packets between those VLANs,
the switch must be connected to an external device with Layer 3 capability. That device is normally a router,
although it could be a multilayer switch. The most efficient way to perform this setup is to provide a single
trunk link between the Layer 2 switch and the router. The trunk link carries the traffic of multiple VLANs.
The traffic between VLANs is routed by the Layer 3 device—the router.
The figure shows a configuration where the router is connected to a core switch using a single 802.1Q trunk
link. This configuration is commonly referred to as “router on a stick.” The router can receive packets on
one VLAN and forward them to another VLAN. In the example, PC1 can send packets to PC2, which is in
different VLAN.
To support 802.1Q trunking, you must subdivide the physical router interface into multiple, logical,
addressable interfaces, one per VLAN. The resulting logical interfaces are called subinterfaces.
Discovery 10: Routing with an External Router
Overview
In this discovery, you will learn how to configure Inter-VLAN Routing, using an external router also known
as "router on a stick".
Topology
PC1 is in VLAN10, PC2 is in VLAN20. R1 and the link between R1 and SW1 need to be configured in
order for PC1 to have connectivity to PC2.
Job Aids
Client Configuration
Device Interface Neighbor IP Address
PC1 Eth0/0 SW1 10.0.10.100
PC2 Eth0/0 SW1 10.0.20.100
Routing with an External Router

Step 1 On R1's Ethernet0/0, configure a subinterface for routing of VLAN 10 traffic.
The router that provides inter-VLAN routing must be configured with subinterfaces. There must
be one subinterface for each VLAN.
R1(config)# interface ethernet 0/0.10

R1(config-subif)# encapsulation dot1q 10
R1(config-subif)# ip address 10.0.10.1 255.255.255.0
Trunk on a router is configured using subinterfaces. Each subinterface on the physical link of the
router must have the same trunk encapsulation protocol. That protocol must match the
encapsulation type that is configured on the switch side of the link. Normally, 802.1Q
encapsulation is used.
To configure 802.1Q encapsulation on a subinterface, use the encapsulation dot1q vlan-id
subinterface command.
The subinterface number does not have to match the encapsulation VLAN number. However, it
is a good practice to do so because it makes it easier to manage the configuration.
The IP address on the subinterface is used as the default gateway IP address for clients in that
VLAN.
Step 2 On R1's Ethernet0/0 configure a subinterface for routing of VLAN 20 traffic.

R1(config-subif)# encapsulation dot1q 20
Step 3 On R1's Ethernet0/0 configure a subinterface for routing of all untagged traffic.
Configure a subinterface for native VLAN. By default this is VLAN 1.
R1(config-subif)# encapsulation dot1q 1 native
NOTE: The other option to configure routing of untagged traffic is to configure a physical
interface with the native VLAN IP address. The disadvantage of that configuration is, that when
you do not want the untagged traffic to be routed, you shut down the physical interface, but that
also shuts down all the subinterfaces on that interface.
Step 4 On R1, verify that all the configured subinterfaces are up.
R1# show ip interface brief

Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES NVRAM up up
Ethernet0/0.1 10.0.1.1 YES manual up up
Ethernet0/1 unassigned YES NVRAM administratively down down
Step 5 Configure SW1's Ethernet 0/0 as a trunk port. Allow only VLAN 1, 10, and 20 traffic.
The link between SW1 and R1 must be configured as a trunk, to carry traffic from all the
configured VLANs. Trunk has already been configured on R1. Now, you have to configure it on
SW1 as well.
It is recommended practice that you configure a static trunk link and only allow traffic from
VLANs that are in use.
SW1(config)# interface ethernet 0/0

SW1(config-if)# switchport trunk allowed vlan 1,10,20
Step 6 On SW1, verify that the SW1-R1 link is carrying traffic for user-VLANs 10 and 20, and the
native VLAN.
Issue the show interface interface switchport command and verify, that the SW1's interface that
is connected to R1 has VLANs 10 and 20 allowed.
SW1# show interfaces ethernet0/0 switchport
Name: Et0/0
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: 1,10,20
Pruning VLANs Enabled: 2-1001
Also notice that the configured (default) native VLAN is VLAN 1.
Router on a Stick Traffic Flow
Traffic flow from PC1 to PC2 is as follows:

1 The traffic from PC1 enters the switch on VLAN 10.
2 Crosses trunk to router, arriving on subinterface Ethernet 0/0.10 (VLAN 10).
3 Router determines that route to PC2 is through subinterface Ethernet 0/0.20 (VLAN 20).
4 Crosses trunk to switch, arriving on VLAN20.
5 Switched to PC2.
Step 7 Use traceroute to verify the traffic flow between PC1 and PC2.
PC1# traceroute 10.0.20.100

Tracing the route to 10.0.20.100
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.10.1 0 msec 0 msec 1 msec
2 10.0.20.100 0 msec 1 msec *
External Router: Advantages and Disadvantages
The advantages of external router usage:

• An external router works with any switch, since Layer 3 services are not required on the switch. Many
switches do not contain Layer 3 forwarding capability, especially switches that are used at the access
layer of a hierarchical network. If you are using local VLANs, none of the switches at the access layer
will have Layer 3 forwarding ability. Depending on the network design, it is possible that there are no
switches in the network with Layer 3 forwarding capability.
• The implementation is simple. Only one switch port and one router interface require configuration. If
the switch allows all VLANs to cross the trunk (the default), you need to use only a few commands to
configure the switch.
• The router provides communication between VLANs. If the network design includes only Layer 2
switches, the design and also the process for troubleshooting traffic flow become very simple because
there is only one place in the network where VLANs interconnect.
The disadvantages of external router usage:

• The router is a single point of failure.
• A single traffic path may become congested. With a “router on a stick” model, the trunk link is limited
by the speed of the router interface being shared across all trunked VLANs. Depending on the size of
the network, the amount of inter-VLAN traffic, and the speed of the router interface, congestion could
result from this design.
• Latency may be introduced as frames leave and reenter the switch chassis multiple times, and the router
makes software-based routing decisions. Any time that traffic must flow between devices, latency is
introduced. Additionally, routers make routing decisions in software, which always incurs a greater
latency penalty than switching with hardware.
Since the usage of external router has physical limitations such as link congestions, latency and speed, it is
not recommended to use it in large deployments. You normally implement an external router in small
networks or branch offices of small-to-medium business, as there is no need to upgrade to a high-
performing, more expensive device that is a multilayer switch.
Summary
Lesson 2: Configuring a
Switch to Route
Overview
In order to configure Inter-VLAN routing you need a Layer 3 device. Some switch models have Layer 3
capabilities and can be used to route between VLANs.
Layer 3 switch is a widely used term to describe a switch that can perform either static or dynamic routing.
The term multilayer switch is used to describe a switch that operates at Layers 2-7 of the OSI model. For a
multilayer switch to perform routing it has to have a route processor.
By default every switch port on most Cisco switches is a Layer 2 interface. If you need an interface to
operate at Layer 3, you need to configure it. After you turn a switch port into a routed port, it behaves like a
port on a router. At that point you can configure multilayer switch to perform static or dynamic routing.
The amount of routing features that can be configured on a switch is differs between device models.

• Describe Switch Virtual Interface
• Describe the role of a routed port on a switch
• Configure SVI on a switch
• Configure routed port on a switch
• Configure a routing protocol on a multilayer switch
• Configure Switch Virtual Interface with autostate exclude
• List and describe the steps of configuring SVI on a multilayer switch
• Compare Layer 2 and Layer 3 EtherChannel
• Configure Layer 3 EtherChannel
Switch Virtual Interfaces Overview
An SVI is a virtual interface that is configured within a multilayer switch. You can create an SVI for any
VLAN that exists on the switch. Only one SVI can be associated with one VLAN. An SVI can be
configured to operate at Layer 2 or Layer 3.
SVI is “virtual” in that that there is no physical port that is dedicated to the interface, yet it can perform the
same functions for the VLAN as a router interface would, and can be configured in much the same way as a
router interface (IP address, inbound or outbound access control lists, and so on). The SVI for the VLAN
provides Layer 3 processing for packets to and from all switch ports that are associated with that VLAN.
You configure an SVI for a VLAN for several reasons:

• To provide a gateway for a VLAN so that traffic can be routed into, or out of that VLAN .
• To provide VLAN bridging, if it is required for nonroutable protocols.
• To provide Layer 3 IP connectivity to the switch.
• To support routing protocol and bridging configurations.
By default, a SVI is created for the default VLAN (VLAN1) to permit remote switch administration.
Additional SVIs must be explicitly created. You create SVIs the first time that you enter the VLAN
interface configuration mode for a particular VLAN SVI. For example, when you enter the command
interface vlan vlan_number. The VLAN number that you use should correspond to the VLAN tag that is
associated with data frames on an 802.1Q encapsulated trunk or with the VID that is configured for an
access port. For instance, if you are creating an SVI as a gateway for VLAN 10, name the SVI interface
vlan 10. Configure and assign an IP address to each VLAN SVI that is to route traffic from and onto a
VLAN.
Note A BVI is a Layer 3 virtual interface that acts like a normal SVI to route packets. This is a
legacy method where Layer 2 is bridged across Layer 3 interfaces. Bridging creates a single
instance of spanning tree in multiple VLANs. It complicates spanning tree and behaviour of
other protocols. In turn, this makes troubleshooting difficult. Bridging across routed domains
is not recommended in today's networks.
Switch Routed Ports Overview
A routed switch port is a physical switch port on a multilayer switch that is configured to perform Layer 3
packet processing. You configure a routed switch port by removing the Layer 2 switching capability of the
switch port. Unlike the access port or the SVI, a routed port is not associated with a particular VLAN. Also,
since Layer 2 functionality has been removed, Layer 2 protocols such as STP and VTP do not function on a
routed interface. However, protocols like LACP, which can be used to build either Layer 2 or Layer 3
EtherChannel bundles, would still function at Layer 3.
A routed port behaves like a regular router interface, except that it does not support VLAN subinterfaces.
Routed switch ports can be configured using most of the commands that are applied to a physical router
interface, including the assignment of an IP address and the configuration of Layer 3 routing protocols.
Similarly to SVI, a routed switch port provides Layer 3 packet processing. SVIs generally provide Layer 3
services for devices that are connected to any ports of the switch where the VLAN that is associated with
the SVI is configured and is active. Routed switch ports can provide a Layer 3 path into the switch for a
number of devices on a specific subnet, all of which are accessible from a single physical switch port. A
routed switchport can connect to a firewall or router that has no knowledge of the VLAN structure. This
firewall or router, provides access to and from external networks over WAN or the Internet.
Discovery 11: Routing on a Multilayer Switch
Overview
In this discovery you will learn how to configure SVIs, routed ports, and routing on a multilayer switch.
Topology
SW1's ports are configured to have PC1 in VLAN10 and PC2 in VLAN20. The link between SW1 and
DSW1 is configured as a trunk link. PCs 1 and 2 are configured with IP addresses. R1 is configured with IP
addresses and EIGRP.
There is no connectivity between PC1 and PC2. You will configure DSW1 to route between PC1 and PC2.
You will configure DSW1's uplink to exchange routes with R1.
Job Aids
IP Addressing
PC1 Ethernet 0/0 10.0.10.100/24
PC2 Ethernet 0/0 10.0.20.100/24
DSW1 VLAN 10 10.0.10.1/24
DSW1 VLAN 20 10.0.20.1/24
DSW1 Ethernet 0/2 10.0.99.1/24
R1 Ethernet 0/1 10.0.99.2/24
R1 Ethernet 0/0 209.165.201.2/30
Server on the Internet N/A 209.165.201.1
Routing on a Multilayer Switch

Step 1 On DSW1 create VLANs 10 and 20.
DSW1(config)# vlan 10
DSW1(config-vlan)# vlan 20
If a VLAN that is to be routed by an SVI interface does not already exist on the multilayer
switch, you must create it.
In this example VLANs 10 and 20 were already pre-configured on DSW1 and you could have
verified that with show vlan command. However, these VLANs will not be present on a new
device and if you forget to configure them, switch will not be able to perform inter-VLAN
routing.
Step 2 On DSW1 enable IPv4 routing.
DSW1(config)# ip routing
Multilayer switches might or might not have IP routing enabled by default. In order for the
switch to route between SVIs, you will need to enable IPv4 routing.
NOTE: In this lab IP routing was already enabled, but this is something you easily forget to turn
on.
Step 3 On DSW1 configure SVI for VLAN10 with IP address 10.0.10.1/24.
PC1 is in VLAN 10 and already configured with default gateway of 10.0.10.1-an IP address that
you will now configure on DSW1.
DSW1(config-if)# ip address 10.0.10.1 255.255.255.0
You need to create an SVI interface for each VLAN that is to be routed within the multilayer
switch.
SVI needs to be enabled using the no shutdown command. Otherwise it will stay in
"administratively shutdown" state.
Step 4 On DSW1 configure SVI for VLAN20 with IP address 10.0.20.1/24.
PC2 is in VLAN 20 and already configured with default gateway of 10.0.20.1-an IP address that
you will now configure on DSW1.

Step 5 On DSW1 verify IP interface configuration for VLANs 10 and 20.
DSW1# show ip interface brief

Vlan10 10.0.10.1 YES manual up up
Vlan20 10.0.20.1 YES manual up up
In order for SVIs to be fully operational, they need to have the correct IP address configured and
be in "up/up" state.
Step 6 Use traceroute to test connectivity between PC1 to PC2.

1 10.0.10.1 1001 msec 1 msec 0 msec
2 * *
10.0.20.100 1 msec
You should be able to ping from PC1 to PC2. Traffic from PC1 goes through SW1 to DSW1's
SVI for VLAN 10, gets routed to DSW1's SVI for VLAN 20 and then goes through SW1 to
PC2. The reverse path is the same.
Step 7 On DSW1 turn interface that connects to R1 (Ethernet 0/0) into a routed interface. Configure it
with IP 10.0.99.1/24.
The link between DSW1 and R1 should be a Layer 3 link. R1's interface is already configured
with an IP address.

DSW1(config-if)# no switchport
*Nov 28 15:03:55.138: %LINK-3-UPDOWN: Interface Ethernet0/2, changed state to up
*Nov 28 15:03:56.142: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Ethernet0/2, changed state to up
When you enter the no switchport command for an interface, it turns it from Layer 2 to Layer 3
interface.
When you issue the no switchport command, the interface will be shut down and then brought
back up. When you put the interface into Layer 3 mode, you delete all Layer 2 configuration on
the interface.
Step 8 On DSW1 verify routed port IP interface configuration.
DSW1# show ip interface brief

Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset up up
Ethernet0/1 unassigned YES unset up up
Ethernet0/2 10.0.99.1 YES manual up up
DSW1's routed interface has an IP address configured and in "up/up" state. It functions like a
port on a router.
Step 9 On DSW1 configure EIGRP with AS 1. Enable VLAN 10, VLAN 20, and Ethernet 0/2
interfaces for EIGRP.
As soon as a multilayer switch is configured with Layer 3 IP addresses, it starts behaving like a
router in the sense that it has connections to different subnets. Communication between these
subnets is no longer possible through the use of Layer 2 protocols. A major difference between a
multilayer switch and a router is that a multilayer switch does not route by default. To allow
routing behavior, you first need to enable routing with the ip routing command. Once routing is
enabled, you can configure static routes or dynamic routing, or both, just like on a router.
R1 is already configured to exchange routes through EIGRP.
DSW1(config)# router eigrp 1
DSW1(config-router)# network 10.0.0.0
*Nov 28 15:12:22.448: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.99.2
(Ethernet0/2) is up: new adjacency
Issuing the network 10.0.0.0 command will enable all interfaces configured with an IP address
within 10.0.0.0/8 subnet. DSW1's Ethernet 0/2, VLAN 10, and VLAN 20 interfaces will be
enabled for EIGRP.
Notice that DSW1 established an EIGRP adjacency with R1.
Step 10 Verify the routing table on DSW1.
DSW1# show ip route

D*EX 0.0.0.0/0 [170/307200] via 10.0.99.2, 00:07:13, Ethernet0/2
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
Notice that DSW1 acquired a default route from R1 via EIGRP.

If you ping from PC1 to the Internet address of 209.165.201.1, your ping should be successful.
PC1 has it's default gateway set to the IP of DSW1's SVi for VLAN 10 and DSW1 has a default
route that it acquired through EIGRP from R1.
SVI autostate exclude
The SVI interface is brought up when one Layer 2 port in the VLAN has had time to converge (transition
from STP listening-learning state to forwarding state). The default action, when a VLAN has multiple ports,
is that the SVI goes down when all ports in the VLAN go down. This action prevents features such as
routing protocols from using the VLAN interface as if it were fully operational, and minimizes other
problems, such as routing black holes.
You can use the SVI autostate exclude command to configure a port so that it is not included in the SVI
line-state up-and-down calculation. One example is the use of a network analyzer, where the traffic capture
is being made without the device being an active participant in the VLAN that is assigned to the interface.
When enabled on a port, autostate exclude applies to all VLANs that are enabled on that port. You would
therefore need to carefully consider the implications of activating this feature on a trunk link.
Configuring a Layer 2 switch port for autostate exclude requires two steps:
Step Action Notes
1 Switch(config)# interface interface Selects interface for configuration.

slot/number
2 Switch(config-if)# switchport Excludes the access port or trunk in defining the

autostate exclude status of an SVI (up or dow n). This command w ould
commonly be used for ports that are used for
monitoring, for instance, so that a monitoring port
did not cause the SVI to remain in the up state
w hen no other ports are active in the VLAN.
Note In some IOS releases (e.g 12.4T), you can use no autostate VLAN interface command.
This disables the SVI autostate and make SVI interface permanently active.
SVI Configuration Checklist
Before implementing inter-VLAN routing on a multilayer switch, it is important that you plan the steps that
are necessary to make it successful. Planning, which includes logically organizing the necessary steps and
providing checkpoints and verification, can help you reduce the risk of problems during the installation.
The first step is to identify the VLANs that require a Layer 3 gateway within the multilayer switch. It is
possible that not all VLANs will need to reach other VLANs within the enterprise. For example, a company
may have a VLAN in use in an R&D laboratory. The network designer has determined that this VLAN
should not have connectivity with other VLANs in the enterprise or to the Internet. However, the R&D
VLAN is not a local VLAN but spans the switch fabric, due to the presence of an R&D server in the data
center, so you cannot simply prune it from the trunk between the multilayer switch and the R&D lab switch.
One way of ensuring the desired segregation might be to configure such a VLAN without a Layer 3
gateway.
If a VLAN that is to be routed by an SVI interface does not already exist on the multilayer switch, you must
create it. Then you would create an SVI interface for each VLAN to be routed within the multilayer switch.
Assuming that the enterprise uses only IP as a routed protocol, you would then configure each SVI interface
with an appropriate IP address and mask. At that point, you would enable the SVI interface using the no
shutdown interface command.
You can configure an SVI to give VLANs the ability to reach the switch itself. You would do that for the
VLAN that is designated for management. But for most part configuring SVIs is done to provide Layer 3
forwarding services. In that case you must enable the routing function on the multilayer switch. Routing is
usually not enabled by default. You can also configure the multilayer switch to exchange routes via a
dynamic routing protocol—the configuration is done in a similar manner to the one on a router.
Depending on the size of the network and the design that you provide, it may be necessary for the multilayer
switch to exchange dynamic routing protocol updates with one or more other routing devices in the network.
You must determine whether this need exists, and if so, configure an appropriate dynamic routing protocol
on the multilayer switch. The choice of protocol may be specified by the network designer, or the choice
may be left to you.
Finally, after carefully considering the network structure, you may decide to exclude certain switch ports
from contributing to the SVI line-state up-and-down calculation. You would configure any such switch
ports by using the autostate exclude interface configuration command.
Layer 2 vs. Layer 3 EtherChannel
You can use the EtherChannel technology to bundle ports of the same type. On a Layer 2 switch,
EtherChannel is used to aggregate access ports or trunks. In the figure, EtherChannel links are used to
connect to the several switches, and pairs of ports are used to create EtherChannel bundles. Because each
EtherChannel link is detected as one logical connection, both ports of each EtherChannel link can be used at
the same time.
On Layer 3 switches, switched ports can be converted to routed ports. These ports do not perform switching
at Layer 2 anymore, but become Layer 3 ports that are similar to those that are found on router platforms.
EtherChannel links can also be created on Layer 3 links. On the left part of the figure, Layer 3 switches
must connect through an aggregated link. Two physical ports on each side are converted to routed ports and
are then aggregated into a Layer 3 EtherChannel link.
On a multilayer switch, you can configure Layer 2 or Layer 3 EtherChannels, depending on what type of
devices you connect, and depending on their position in the network. Here again, this configuration
supposes that ports on both sides are configured the same way: as switch ports (access or trunk) or as routed
ports. The bottom switch is Layer 2 only—it is probably an access switch. Layer 2 EtherChannel is
configured. At the distribution layer or the core layer, where Layer 3 links are recommended, Layer 3
EtherChannels are configured.
Layer 3 EtherChannel Configuration
The following table shows the steps for configuring and verifying a Layer 3 EtherChannel interface.
Step Action Notes
1. Sw itch(config)# interface port-channel Creates a virtual Layer 2 interface.

1
2. Sw itch(config-if)# no switchport Changes interface to Layer 3 and enables the use of the IP
address command.
3. Sw itch(config-if)# ip address Assigns an IP address to the port channel interface because this
172.32.52.10 255.255.255.0 w ill be a Layer 3 interface.
4. Sw itch(config)# interface range Navigates to the interface that is to be associated w ith the
fastethernet 5/4 - 5 EtherChannel bundle.
This example show s navigation to a range of interfaces w ith the
port channel. Individual interfaces can be used also.
5. Sw itch(config-if-range)# no switchport The independent Layer 2 and Layer 3 functionality of the port
must be removed so that the port can function as part of a
group. This step is very important. On a Layer 3 sw itch,
Sw itch(config-if-range)# interfaces are, by default, in Layer 2 mode. If you set the port
channel-protocol pagp channel interface to a layer and if the physical ports are in
another mode (Layer 3), the EtherChannel w ill not form.
Optionally, can specify the channel protocol.
6. Sw itch(config-if-range)# channel-group Assigns all of the physical interfaces in the range to the
1 mode desirable EtherChannel group.
Example shows a configuration for two switches, using a Layer 3 EtherChannel bundle. The left switch has
created a virtual interface with an IP address, and the physical interfaces are assigned to the matching
channel-group number. The same is true with the right switch. Again, the interfaces do not need to have the
same number as any of the partner switches. For example, Ethernet0/1 does not need to connect to
Ethernet0/1 on the other side of the link. The port channel number does not need to match between the
switches on the opposite side of the link. Notice how the guidelines were followed here:
• Speed and duplex: Configure all interfaces in an EtherChannel to operate at the same speed and in the
same duplex mode.
• Interface mode: Because the port channel interface is a routed port, the no switchport command was
applied to it. The physical interfaces are, by default, switched, which is a mode that is incompatible with
a router port. The no switchport command was applied also to the physical ports, to make their mode
compatible with the EtherChannel interface mode.
Note In some IOS releases you can only statically configure Layer 3 EtherChannel. Using LACP
or PAgP as the negotiation protocol might result in non-functional link.
Example output tells you that EtherChannel 1 is a Layer 3 EtherChannel ("R"-flag). You can see that
Ethernet 0/0 and Ethernet 0/1 are indeed bundled by the "P"-flag next to each of them.
Ports Ethernet 0/0 and Ethernet 0/1 will now behave as one "virtual" physical interface. For example, if you
issue show ip route, routes will be seen as accessible through PortChannel 1 and not Ethernet 0/1 or
Ethernet 0/0.
Summary
Overview
Check
1. Which of the following arrangements can be considered "Router on a Stick"? (Chose one.) (Source:
Implementing Inter-VLAN Routing Using a Router)
A. One switch, two VLANs, one connection to a router.
B. One switch, two VLANs, two connections to a router.
C. Two switches, two VLANs, two connections to a router.
D. All of the above.
2. Which two statements are typical characteristics of VLAN arrangements? (Choose two.) (Source:
Implementing Inter-VLAN Routing Using a Router)
A. A new switch has no VLANs configured.
B. Connectivity between VLANs requires a Layer 3 device.
C. Each VLAN usually uses a separate address space.
D. VLANs cannot span multiple switches.
3. How do you configure a trunk on a router's interface that will have connections to more than one
VLAN? (Source: Implementing Inter-VLAN Routing Using a Router)
A. Using subinterfaces on a physical interface, for each VLAN.
B. Using switchport mode trunk command.
C. You do not need to explicitly configure a trunk on a interface.
4. You have configured a switch to perform Layer 3 routing via an SVI and have assigned that interface to
VLAN 20. To check the status of the SVI, you issue the show interfaces vlan 20 command. You see
from the output display that the interface is in an “up/up” state. Among others, what must be true in an
SVI configuration to bring the VLAN and line protocol up? (Source: Configuring A Switch To Route)
A. The port must be physically connected to another Layer 3 device.
B. At least one port in VLAN 20 must be active.
C. Because this is a virtual interface, the operational status will always be in an “up/up” state.
D. All of the above.
5. While configuring SVIs on a Multilayer switch, when must you use the ip routing command? (Source:
Configuring A Switch To Route)
A. When using an SVI to provide IP connectivity to the switch itself for a given VLAN.
B. When configuring the SVI as part of a Layer 2 EtherChannel bundle.
C. When using an SVI to provide Layer 3 IP forwarding services to its assigned VLAN.
D. Never, because IP routing is enabled by default on a Multilayer switch.
6. In Layer 3 EtherChannel two links were bundled. On each of the two switches, there are two IP
addresses configured. True or false? (Source: Configuring A Switch To Route)
A. True
B. False
Answer Key
1 A
2 B, C
3 A
4 B
5 C
6 B
Module 5: Implementing High
Availability Networks
Introduction
Continuous access to applications, data and content demands a network-wide resilience to increase IP
network availability. High network availability is achieved by applying network-level resiliency, system-
level resiliency, management and monitoring.
Network-level resiliency is achieved by adding redundant devices and connections into the network.
System-level resiliency is achieved by adding redundant modules, such as power supplies, supervisor
engines, and other components, to a modular device. Added redundancy often results in added complexity
of the network. Complexity of the network can be reduced by the implementation of switch virtualization.
Management and monitoring systems alarm the network operators, so they can respond to network and
system outages and place appropriate actions to prevent a network quality of service reduction or downtime.
Different tools and features are available to monitor and manage network devices, network traffic flows and
network consistency with the service level agreements (SLA).

• Configure Network Time Protocol
• Configure Simple Network Management Protocol version 3
• Configure basic IP SLA for the purpose of network monitoring
• Configure local and remote SPAN
• Verify switch virtualization
Lesson 1: Configuring
Network Time Protocol
Overview
Internet Protocol based networks are quickly evolving from the traditional best effort delivery model to a
model where performance and reliability need to be quantified and, in many cases, guaranteed with SLAs.
The need for greater insight into network characteristics has led to significant research efforts being targeted
at defining metrics and measurement capabilities to characterize network behavior. The foundation of many
metric methodologies is the measurement of time.
Keeping consistent time across network devices in your network will assure you that you can properly read
log messages and other information critical to troubleshooting.

• Explain the need for accurate time and possible sources of accurate time
• Manually configure system clock on a Cisco device
• Explain the idea behind NTP
• Describe NTP modes and their roles
• Configure NTP clients and NTP peers
• Secure NTP using authentication and access lists
• Describe how and why would you configure a NTP source interface
• Verify configured NTP version
• Configure NTPv4 in IPv6 environment
• Compare SNTP to NTP
• Configure SNTP
The Need for Accurate Time
The heart of the time service is the system clock. The system clock runs from the moment the system starts
and keeps track of the current date and time. The system clock can be set from a number of sources and, in
turn, can be used to distribute the current time through various mechanisms to other systems.
The system clock keeps track of time internally based on UTC. You can configure information about the
local time zone and daylight savings time so that the time is displayed correctly relative to the local time
zone. The system clock keeps track of whether the time is authoritative or not. If it is not authoritative, the
time is available only for display purposes and cannot be redistributed. Authoritative refers to the
trustworthiness of the source. Nonauthoritative sources do not guarantee accurate time. It is recommended
to set clocks on all network devices to UTC regardless of their location, and then configure the time zone to
display the local time if desired.
Accurate time is needed for public key infrastructure that is based on X.509 certificates since they keep time
of validity - for example a certificate's validity expired on 10th of February 2011, but because of incorrect
time source your devices still consider it valid. Accurate time is also essential for logging events in your
network; for example using Syslog. Only when devices are time-synchronized you can track the problem
from one device to another.
Configuring System Clock Manually
To change system clock manually, you need to use the clock set command from privileged exec mode and
not global configuration mode. The date and time need to be set in UTC and not the local time zone! Local
time zone and, if applicable, daylight saving time needs to be configured.
To configure timezone, use the clock timezone zone hours-offset [minutes-offset] global configuration
command.
Param eter Description
hours-offset Hours difference from UTC.
minutes-offset (Optional) Minutes difference from UTC.
To configure automatic switch to summer time, that is the daylight saving time, use one of the following
formats of the clock summer-time command:
• clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]]
• clock summer-time zone date date month year hh:mm date month year hh:mm [offset]
• clock summer-time zone date month date year hh:mm month date year hh:mm [offset]
Param eter Description
zone Name of the time zone (for example, "PDT") to be displayed

w hen summer time is in effect.
recurring Indicates that summer time should start and end on the
corresponding specified days every year.
date Indicates that summer time should start on the first specific date
that is listed in the command and end on the second specific
date in the command.
week (Optional) Week of the month (1 to 5 or last).
day (Optional) Day of the w eek (Sunday, Monday, and so on).
date Date of the month (1 to 31).
month (Optional) Month (January, February, and so on).
year Year (1993 to 2035).
hh:mm (Optional) Time (military format) in hours and minutes.
offset (Optional) Number of minutes to add during summer time

(default is 60).
By default, summer time is disabled. If the clock summer-time zone recurring command is specified
without parameters, the summer time rules default to United States rules. Default of the offset argument is
60.
A number of Cisco devices contain a battery-powered calendar system that tracks the date and time across
system restarts and power outages. This calendar system is always used to initialize the system clock when
the system is restarted. It can also be considered as an authoritative source of time and redistributed through
NTP if no other source is available. Furthermore, if NTP is running, the calendar can be periodically
updated from NTP, compensating for the inherent drift in the calendar time. When a router with a system
calendar is initialized, the system clock is set based on the time in its internal battery-powered calendar. On
models without a calendar, the system clock is set to a predetermined time constant. Calendar is also called
hardware clock.
You could configure the hardware clock using calendar set hh:mm:ss <1-31> month year.
Note In the absence of NTP or other reliable time source, make sure that whenever you are
manually setting the clock, you update the calendar with it to ensure continuity when the
device restarts.
Note Manually configuring time is neither accurate or scalable. The better way to assure accurate
time is to use a protocol for time synchronization such as NTP.
Network Time Protocol Overview
NTP is designed to synchronize the time on a network of machines. NTP runs over the UDP, using port 123
as both the source and destination, which in turn runs over IP. NTP is used to synchronize timekeeping
among a set of distributed time servers and clients. A set of nodes on a network is identified and configured
with NTP and the nodes form a synchronization subnet, sometimes referred to as an overlay network. While
multiple masters (primary servers) may exist, there is no requirement for an election protocol.
An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic
clock attached to a time server. NTP then distributes this time across the network. An NTP client makes a
transaction with its server over its polling interval (from 64 to 1024 seconds) which dynamically changes
over time depending on the network conditions between the NTP server and the client. The other situation
occurs when the router communicates to a bad NTP server (for example, NTP server with large dispersion);
the router also increases the poll interval. No more than one NTP transaction per minute is needed to
synchronize two machines. It is not possible to adjust the NTP poll interval on a router.
The communications between machines running NTP (associations) are usually statically configured. Each
machine is given the IP address of all machines with which it should form associations. Accurate
timekeeping is made possible by exchanging NTP messages between each pair of machines with an
association. However, in a LAN environment, NTP can be configured to use IP broadcast messages instead.
This alternative reduces configuration complexity because each machine can be configured to send or
receive broadcast messages. However, the accuracy of timekeeping is marginally reduced because the
information flow is one-way only.
NTP uses the concept of a stratum to describe how many NTP hops away a machine is from an authoritative
time source. For example, a stratum 1 time server has a radio or atomic clock that is directly attached to it. It
then sends its time to a stratum 2 time server through NTP, and so on. A machine running NTP
automatically chooses the machine with the lowest stratum number that it is configured to communicate
with using NTP as its time source. This strategy effectively builds a self-organizing tree of NTP speakers.
NTP performs well over the nondeterministic path lengths of packet-switched networks, because it makes
robust estimates of the following three key variables in the relationship between a client and a time server:
• Network delay
• Dispersion of time packet exchanges—A measure of maximum clock error between the two hosts.
• Clock offset—The correction applied to a client's clock to synchronize it.
Clock synchronization at the 10 millisecond level over long distance WANs (124.27 miles [2000 km]), and
at the 1 millisecond level for LANs, is routinely achieved.
NTP avoids synchronizing to a machine whose time may not be accurate in two ways. First of all, NTP
never synchronizes to a machine that is not synchronized itself. Second, NTP compares the time that is
reported by several machines, and will not synchronize to a machine whose time is significantly different
from the others, even if its stratum is lower.
NTP Modes
NTP can operate in four different modes that provide you flexibility to configure time synchronization in
your network.
Server and client modes are usually combined with Cisco network devices. A device that is an NTP client
can act as an NTP server to another device. Client/server mode is the most common Internet configuration.
A client sends a request to the server and expects a reply at some future time. This process could also be
called "poll" operation since the client polls the time and authentication data from the server. A client is
configured in client mode by using the server command and specifying the DNS name or address. The
server requires no prior configuration. In a common client/server model, a client sends an NTP message to
one or more servers and processes the replies as received. The server interchanges addresses and ports,
overwrites certain fields in the message, recalculates the checksum, and returns the message immediately.
Information included in the NTP message allows the client to determine the server time with respect to local
time and adjust the local clock accordingly. In addition, the message includes information to calculate the
expected timekeeping accuracy and reliability, as well as select the best server.
Peer mode is also commonly known as symmetric mode. It is intended for configurations where a group of
low stratum peers operate as mutual backups for each other. Each peer operates with one or more primary
reference sources, such as a radio clock, or a subset of reliable secondary servers. If one of the peers loses
all the reference sources or simply ceases operation, the other peers automatically reconfigure so that time
values can flow from the surviving peers to all the others in the clique. In some contexts this is described as
a push-pull operation, in that the peer either pulls or pushes the time and values depending on the particular
configuration. Symmetric modes are most often used between two or more servers operating as a mutually
redundant group. In these modes, the servers in the group members arrange the synchronization paths for
maximum performance, depending on network jitter and propagation delay. If one or more of the group
members fail, the remaining members automatically reconfigure as required.
Where the requirements in accuracy and reliability are modest, clients can be configured to use broadcast
and/or multicast modes. Normally, these modes are not utilized by servers with dependent clients. The
advantage is that clients do not need to be configured for a specific server, allowing all operating clients to
use the same configuration file. Broadcast mode requires a broadcast server on the same subnet. Since
broadcast messages are not propagated by routers, only broadcast servers on the same subnet are used.
Broadcast mode is intended for configurations involving one or a few servers and a potentially large client
population. A broadcast server is configured using the broadcast command and a local subnet address. A
broadcast client is configured using the broadcast client command, allowing the broadcast client to respond
to broadcast messages that are received on any interface.
Discovery 12: NTP Configuration
Overview
During this discovery you will configure devices in your network to synchronize their clocks via NTP.
Topology
Job Aids
IP Addresses Used For NTP Configuration
NTP
Step 1 Configure R1 to synchronize its clock to public NTP server at 209.165.200.187.
R1(config)# ntp server 209.165.200.187
Before you can configure NTP, you will have to choose an NTP server to synchronize to. Large
organizations have their own stratum 1 servers. However usually you will configure your devices
to synchronize to a public NTP server.
NTP allows you to limit the maximum number of peer and client associations that your device
will serve. This assures that this NTP server is not overwhelmed by too many NTP requests. To
limit the number of NTP associations, use the ntp max-associations number command in global
configuration mode.
When NTP is enabled on a device, that in turn means that NTP is enabled on all interfaces. This
means that all interfaces will serve as NTP servers. You can use the ntp disable interface
configuration command on interfaces that connect to external networks, since you do not want to
provide clock to those. NTP-disabled interfaces will turn off NTP server functionality, but still
allow the interface to act as an NTP client.
To configure a device to be an authoritative NTP server, use the ntp master stratum_number
command in global configuration mode. Configuring only authoritative server in your network is
only recommended if you do not have a reliable external reference clock. When using the ntp
master command, you should choose a high stratum number, such as 10, so time associations
through the inaccurate master clock are ignored if more trustworthy NTP information is made
available. Local router should be also configured as a time source. This way the router will serve
meaningful time to connected devices, even if it loses upstream connectivity. In that case
approximately correct time is better than totally incorrect time.
It is recommended that you configure more than one NTP server for your devices to synchronize
your device to. In that scenario, device will associate itself with one server and mark the other
one as alternate. To specify a preferred NTP server, use the ntp server ip_address prefer
command.
If you use an inbound access list on your Internet interface, you will need to open up NTP
communication for the NTP server selected: access-list acl_number permit udp host
NTP_host_IP eq ntp.
NOTE: The IP address that is used for the NTP server in this step is just an example—it will not
work in real networks.
Step 2 On R1 issue the show ntp status command to investigate if router's clock has synchronized to
the (public) NTP server.
R1# show ntp status

Clock is synchronized, stratum 2, reference is 209.165.200.187
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
ntp uptime is 1500 (1/100 of seconds), resolution is 4000
reference time is D67E670B.0B020C68 (05:22:19.043 PST Mon Jan 13 2014)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 630.22 msec, peer dispersion is 189.47 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000000 s/s
system poll interval is 64, last update was 5 sec ago.
The output will tell you if NTP has successfully synchronized the device's clock. Stratum will be
+1 in comparison to the NTP source. Since the output shows that this device is stratum 2, you
can assume that you are synchronizing to a stratum 1 device.
NTP can be slow to synchronize. It can take up to 5 minutes for a device to synchronize with an
upstream server. NTP poll timer is 64 seconds.
Once a device is synchronized to an NTP source or configured to serve as a master, it will, in
turn, act as an NTP server to any system that requests synchronization.
Step 3 Issue the show ntp associations command to verify devices that R1 is associated with through
NTP.
R1# show ntp associations
address ref clock st when poll reach delay offset disp

*~209.165.200.187 .LOCL. 1 24 64 17 1.000 -0.500 2.820
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
The "*" before the IP address signifies that devices is associated with that server. If you have
multiple NTP servers defined, others will be marked with "+", which signifies alternate options.
Alternate servers are those that will become associated if currently associated NTP server fails.
Step 4 On R1 investigate it's current clock.
R1# show clock

04:56:17.655 PST Tue Jan 14 2014
Notice that R1 has its time zone set to PST. This is an IOL-specific behavior. On real equipment,
time zone will be set to UTC by default. After you configure synchronization, you will also need
to define local time zone and (if applicable) enable summer time.
By default, NTP will only synchronize the software clock. If you want NTP also to synchronize
the hardware clock, you will need to issue ntp update-calendar in global configuration mode.
Note that this command will not work in IOL environment or on devices that do not have a
hardware clock.
Step 5 On R1 configure the time zone that you are currently in, and enable summer time if applicable to
the time zone that you are in.
In this example, time zone is set to EDT and summertime is enabled. "EDT" is just a label. You
can make it whatever you like. The "-5" is the actual offset from UTC.
R1(config)# clock timezone EDT -5

R1(config)# clock summer-time EDT recurring
Step 6 On R1 verify that time zone is now set to the one you are currently in and that summer time is
enabled (if applicable).
R1# show clock detail

08:01:54.470 EDT Tue Jan 14 2014
Time source is NTP
Summer time starts 02:00:00 EDT Sun Mar 9 2014
Summer time ends 02:00:00 EDT Sun Nov 2 2014
In this example R1 is configured with EDT time zone and summer time is enabled.
Step 7 Configure SW1 to synchronize its clock to R1 via NTP and configure it with the same time zone
and summer time configuration as R1.
Only few devices in your network should synchronize to external NTP servers. All other devices
in your networks will synchronize to those few devices.
SW1(config)# ntp server 10.0.0.1

SW1(config)# clock timezone EDT -5
SW1(config)# clock summer-time EDT recurring
Step 8 Verify that SW1's clock is synchronized to R1.
SW1# show ntp status

reference time is D67FD8F2.4624853F (10:40:34.273 EDT Tue Jan 14 2014)
Notice that SW1 is considered stratum 3 device since it synchronizes to a stratum 2 device - R1.
Step 9 Configure SW2 to synchronize its clock to R1 via NTP and configure it with the same time zone
and summer time configuration as R1.
SW2(config)# ntp server 10.0.1.1

SW2(config)# clock timezone EDT -5
SW2(config)# clock summer-time EDT recurring
Step 10 Verify that SW2's clock is synchronized to R1.
SW2# show ntp status

reference time is D67FD974.17CE137F (10:42:44.092 EDT Tue Jan 14 2014)
Notice that SW2 is considered stratum 3 device since it synchronizes to a stratum 2 device - R1.
With a flat structure you will configure all routers to be each-others NTP peers. Each router will
act both as a client and server with every other router. Two or three routers should be configured
to synchronize their time with external time servers. This model is very stable since each device
synchronizes with every other device in the network. The disadvantages are difficulty of
administration, slow convergence time, and poor scalability. If you add a device to the network,
it can take you a good amount of time to identify all other devices and peer them with the new
device. Since all devices in a peer-to-peer relationship have a say in selecting the best time, it
can take a while to agree to what is accurate time.
Do not use the flat model for large networks. You should rather implement NTP in a hierarchical
manner. Every ISP uses this kind of model. Each ISP has multiple stratum-one servers that
synchronize other ISP's devices. The later devices in turn provide time synchronization services
to customer devices. That customer devices (or devices) then provide synchronization to
customer internal system. With a tiered model, there is less administrative overhead and time
convergence in minimized. If you have a large network in your organization, it makes sense to
implement a similar hierarchy of NTP synchronization.
There is also "star" structure where all devices in a network have a relationship with few time
servers in the core. This is the middle ground between having a flat and hierarchical structure.
When designing NTP in campus network it is important to consider broadcast association mode.
The broadcast association mode simplifies the configurations for the LANs, but reduces the
accuracy of the time calculations. Therefore, the trade-off in maintenance costs must be
considered against accuracy in performance measurements.
The high stratum campus network that is shown in the figure is taken from the standard Cisco
Campus network design and contains three components. The campus core consists of two Layer
3 devices labeled CB-1 and CB-2. The server component that is located in the lower section of
the figure has two Layer 3 devices labeled SD-1 and SD-2. The remaining devices in the server
block are Layer 2 devices. In the upper left, there is a standard access block with two Layer 3
distribution devices labeled dl-1 and dl-2. The remaining devices are Layer 2 switches. In this
client access block, the time is distributed using the broadcast option. In the upper right, there is
another standard access block that uses a client/server time distribution configuration.
Step 11 Configure SW1 and SW2 to be NTP peers to each other.
SW1(config)# ntp peer 172.16.0.12
SW2(config)# ntp peer 172.16.0.11
NTP peers will exchange time information with each other. This will prevent single point of
failures.
Step 12 On SW1 and SW2 verify NTP associations.
SW1# show ntp association

*~10.0.0.1 209.165.200.187 2 22 128 377 0.0 0.02 0.0
+~172.16.0.12 10.0.1.1 3 1 128 376 0.0 -1.00 0.0
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
SW2# show ntp association

*~10.0.1.1 209.165.200.187 2 18 128 377 0.0 0.02 0.3
+~172.16.0.11 10.0.0.1 3 0 128 17 0.0 -3.00 1875.0
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
Notice that now SW1 and SW2 both have two sources of NTP information listed. If you look at
the output from SW1, R1 is listed as NTP source to which SW1 is synchronized to. SW2 is listed
as a candidate source and it will be considered if the first source fails.
Securing NTP
NTP can be an easy target in your network. Since device certificates rely on accurate time you should secure
NTP operation. You can secure NTP operation using authentication and access lists.
Cisco devices support only MD5 authentication for NTP. To configure NTP authentication, follow these
steps:
• Define NTP authentication key or keys with ntp authentication-key command. Every number specifies
a unique NTP key.
• Enable NTP authentication using the ntp authenticate command.
• Tell the device which keys are valid for NTP authentication using the ntp trusted-key command. The
only argument to this command is the key that you defined in the first step.
• Specify NTP server that requires authentication using ntp server ip_address key key_number
command. You can similarly authenticate NTP peers, using the ntp server ip_address key key_number
command.
Not all clients need to be configured with NTP authentication. NTP does not authenticate clients—it
authenticates the source. Because of that the device will still respond to unauthenticated requests, so be sure
to use access lists to limit NTP access.
After implementing authentication for NTP, use show ntp status command to verify that clock is still
synchronized. If client has not successfully authenticated the NTP source, then clock will be
unsynchronized.
Once a router or switch is synchronized to an NTP, source it will act as NTP server to any device that
requests synchronization. You should configure access lists on those devices that synchronize their time
with external servers. Why would you want to do that? A lot of NTP synchronization requests from the
Internet might overwhelm your NTP server device. An attacker could use NTP queries to discover the time
servers to which your device is synchronized, and then through an attack such as DNS cache poisoning,
redirect your device to a system under its control. If an attacker modifies time on your devices, that can
confuse any time-based security implementations that you might have in place.
For NTP, the following four restrictions can be configured through access lists:
• peer: Time synchronization requests and control queries are allowed. Device is allowed to synchronize
itself to remote systems that pass the access list.
• serve: Time synchronization requests and control queries are allowed. Device is not allowed to
synchronize itself to remote systems that pass the access list.
• serve-only: Only allows synchronization requests.
• query-only: Only allows control queries.
Let's say you have hierarchical model with two routers configured to provide NTP services to the rest of the
devices in your network. You would configure these two routers with peer and serve-only restrictions. You
would use peer restriction mutually on the two core routers. You would use serve-only restriction on both
core routers to specify which devices in your network are allowed to synchronize their information with
these two routers.
If your device is configured as NTP master, then you must allow access to source IP of 127.127.x.1. This is
because 127.127.x.1 is the internal server that is created by the ntp master command. The value of the third
octet varies between platforms.
After you secure the NTP server with access lists, make sure to check if clients still have their clocks
synchronized via NTP using the show ntp status command. You can verify which IP address was assigned
to the internal server using show ntp associations command.
NTP Source Address
The source of NTP packet will be the same as the interface the packet was sent out on. When implementing
authentication and access lists it is good to have a specific interface set to act as the source interface for
NTP.
It would be wise of you to choose a Loopback interface to use as the NTP source. This is because Loopback
will never be down like physical interfaces.
If you configured Loopback 0 to act as the NTP source for all communication and that interface has, let's
say, IP address of 192.168.12.31. Then you can write up just one access list that will allow or deny based on
one single IP address of 192.168.12.31.
NTP Versions
Currently NTP versions 3 and 4 are used. Some vendors of operating systems customize and deliver their
own versions. Generally, older clients can talk with newer versions.
NTPv4 is an extension of NTP Version 3. NTPv4 supports both IPv4 and IPv6 and is backward-compatible
with NTPv3.
NTPv4 provides the following capabilities:

• NTPv4 supports IPv6, making NTP time synchronization possible over IPv6.
• Security is improved over NTPv3. The NTPv4 protocol provides a whole security framework based on
public key cryptography and standard X509 certificates.
• Using specific multicast groups, NTPv4 can automatically calculate its time-distribution hierarchy
through an entire network. NTPv4 automatically configures the hierarchy of the servers in order to
achieve the best time accuracy for the lowest bandwidth cost. This feature leverages site-local IPv6
multicast addresses.
NTPv3 supports sending and receiving clock updates using IPv4 broadcast messages. Many network
administrators use this feature to distribute time on LANs with minimum client configuration. For example,
Cisco corporate LANs use this feature over IPv4 on local gateways. End-user workstations are configured to
listen to NTP broadcast messages and synchronize their clocks accordingly. In NTPv4 for IPv6, IPv6
multicast messages instead of IPv4 broadcast messages are used to send and receive clock updates.
NTPv3 access group functionality is based on IPv4 numbered access lists. NTPv4 access group
functionality accepts IPv6 named access lists as well as IPv4 numbered access lists.
NTPv4 adds DNS support for IPv6.
NTP in IPv6 Environment
The NTP is a protocol that is designed to time-synchronize a network of machines. NTP runs over UDP,
which in turn runs over IP. NTPv4 is an extension of NTP version 3, which supports both IPv4 and IPv6.
Your software release may not support all the features that are documented in this topic.
Networking devices running NTPv4 can be configured to operate in variety of association modes when
synchronizing time with reference time sources. There are two ways that a networking device can obtain
time information on a network: by polling host servers and by listening to NTPv4 multicasts.
Configuring of polling host servers is done using ntp server ipv6_address version 4 command. Sometimes
this is also called the "client mode".
Configuring of synchronization to a peer is done through ntp peer ipv6_address version 4 command.
Sometimes this is called the "asymmetric active mode".
To configure multicast-based NTPv4 associations, use the ntp multicast ipv6_address command. You also
need to configure the device interface to receive NTPv4 multicast packets. You do that by issuing the ntp
multicast client ipv6_address command in interface configuration mode..
Authentication and access-list configuration with IPv6 is similar to that in IPv4.
After you configure NTP in IPv6 environment, the verification commands are very similar to those in IPv4.
SNTP Overview
SNTP is a simplified, client-only version of NTP. SNTP can only receive the time from NTP servers; it
cannot be used to provide time services to other systems.
SNTP typically provides time within 100 milliseconds of the accurate time, but it does not provide the
complex filtering and statistical mechanisms of NTP.
You can configure SNTP to request and accept packets from configured servers or to accept NTP broadcast
packets from any source. When multiple sources are sending NTP packets, the server with the best stratum
is selected. If multiple servers are at the same stratum, a configured server is preferred over a broadcast
server. If multiple servers pass both tests, the first one to send a time packet is selected. SNTP will choose a
new server only if it stops receiving packets from the currently selected server, or if a better server is
discovered.
SNTP and NTP cannot coexist on the same machine as they use the same port. This means that these two
services cannot be configured on the system at the same time:
Switch(config)# sntp server 209.165.200.187
%SNTP : Cannot configure SNTP as NTP is already running.
%SNTP : Unable to start SNTP process
SNTP support for IPv6 addresses is available only if the image supports IPv6 addressing.
SNTP Configuration
There is little difference basic command-wise between SNTP and NTP for end-devices. Command ntp
server server_ip gets replaced with sntp server server_ip. Command show ntp gets replaced with show
sntp.
To enable SNTP authentication, use the sntp authenticate command. To define an authentication key, use
the sntp authentication-key number md5 key. You can specify one or multiple keys. To mark keys as
trusted for SNTP, use the sntp authentication-key number md5 key command. The last step is to tell the
device to which server should it synchronize it's time. You do that using sntp server server_ip command.
To verify if device has synchronized its time via SNTP use the show sntp command. The output will show
you what is the IP address of the SNTP server or servers it uses, what is the stratum number, SNTP version
number, when was the last synchronization cycle done, and whether time is synchronized or not.
If you need to troubleshoot SNTP server selection, issue the debug sntp select command. Debug will
output messages that are related to both IPv4 and IPv6 servers.
If you need to troubleshoot the SNTP process, use the debug sntp packets [detail] command.
Summary
SNMP Version 3
Overview
Modern communication networks are extremely complex. This is partly due to combination of different
network technologies and techniques that are used to achieve their own specific goals. Trend of transporting
different types of traffic (data, voice, and video) over same IP infrastructure doesn’t help to make your job
as a network administrator an easy one.
In this environment the need for network monitoring is very important, in order to effectively troubleshoot
problems, trend data, and plan for network upgrades.
Simple Network Monitoring Protocol (SNMP) exposes environment and performance parameters of a
network device, allowing a Network Management System (NMS) to collect and process data. All modern
NMS are based on SNMP.
• Describe the role of SNMP
• Compare different SNMP versions
• Explain what are recommended practices for setting up SNMP
• Configure SNMP version 3
• Verify SNMP version 3 configuration
SNMP Overview
SNMP has become the standard for network management. SNMP is a simple, easy to implement protocol
and is thus supported by virtually all vendors.
SNMP defines how management information is exchanged between SNMP managers and SNMP agents.
SNMP uses the UDP transport mechanism to retrieve and send management information, such as MIB
variables.
SNMP manager periodically polls the SNMP agents on managed devices by querying the device for data.
Periodic polling has a disadvantage: there is a delay between an actual event occurrence and the time SNMP
manager polls the data.
SNMP agents on managed devices collect device information and translate it into a compatible SNMP
format according to the MIB. MIBs are collections of definitions of the managed objects. SNMP agents
keep the database of values for definitions written in the MIB.
Agents also generate SNMP traps, asynchronous notifications that are sent from agent to manager. SNMP
traps are event-based and provide almost real-time notification of events.
SNMP is typically used to gather environment and performance data such as device CPU usage, memory
usage, interface traffic, interface error rate, etc. Free and enterprise NMS software bundles provide data
collection, storage, manipulation, and presentation. NMS offers a look into historical data, as well as
anticipated trends. Based on SNMP values NMS triggers alarms to notify network operators. Central view
provides an overview of the entire network to easily identify irregular events, such as increased traffic and
device unavailability due to Denial of Service attack.
Note SNMP allows for read/write access. Configuration of network devices can be applied using
SNMP write access, so SNMP access must be configured with care and security in mind.
SNMP Versions
New functionalities were added to SNMP through time. There are currently three versions of SNMP.
The initial version of SNMP, version 1 introduces 5 message types: Get Request, Get Next Request, Set
Request, Get Response and Trap, but is rarely used nowadays.
SNMP version 2 introduced 2 new message types, Get Bulk Request to poll large amounts of data, and
Inform Request, a type of Trap with expected acknowledgment on receipt. Version 2 added 64-bit counters
to accommodate faster network interfaces.
SNMP version 2 added a complex security model, which was never widely accepted. Instead a community-
based SNMP version 2, known as version 2c, draft standard was introduced and is now, due to its wide
acceptance, considered de facto version 2 standard.
Note Neither SNMPv1 nor SNMPv2c offer security features. Specifically, SNMPv1 and SNMPv2c
can neither authenticate the source of a management message nor provide encryption.
In SNMP version 3 methods to ensure the secure transmission of critical data between manager and agent,
were added. It provides flexibility in defining security policy. You can define secure policy per group, and
optionally limit IP addresses to which it's members can belong to. You have to define encryption and
hashing algorithms and passwords for each user.
SNMP v3 introduces three levels of security:
• noAuthNoPriv: No authentication is required, and no privacy (encryption) is provided,
• authNoPriv: Authentication is based on Hashed Message Authentication Code MD5 or SHA. No
encryption is provided.
• authPriv: In addition to authentication, CBC-DES encryption is used.
SNMP Recommendations
There are some basic guidelines and best practices you should follow when setting up SNMP in you
network.
NMS systems rarely need SNMP write access, so it is good practice to configure SNMP access as read-only.
Separate community / credentials should be configured for systems that require write access.
The Setup SNMP view command can block the user with only access to limited MIB. By default, there is no
SNMP view entry. It works similar to access-list in that if you have any SNMP View on certain MIB trees,
every other tree is implicitly denied.
Access lists should be used to limit SNMP access only to known SNMP managers.
SNMPv3 is recommended whenever possible. It provides authentication, encryption and integrity. Be
aware, that SNMPv1 or SNMPv2c community string was not designed as a security mechanism and is
transmitted in clear text, nevertheless community strings should not be trivial, and should be changed at
regular intervals.
SNMP Version 3 Configuration
When configuring SNMPv3 there are a few of mandatory steps you should implement first to get SNMPv3
work properly.
As shown in the example, you first have to configure standard access list (access-list 99), which will be
further used to limit SNMP access to local device to SNMP managers with addresses in subnet 10.1.1.0/24
(permit 10.1.1.0. 0.0.0.255)
Next you configure the view "OPS" that will be used as both read and write view for the group "groupZ".
You can include or exclude specific OIDs from the view. In the example, OIDs for system uptime, interface
status, and description were added.
Then you configure SNMPv3 security policy. SNMPv3 group is configured with "authPriv" security level
(snmp-server group groupZ v3 priv) and user for that group (snmp-server userZ groupZ) with
passwords for both authentication (auth sha itsasecret) and encryption (priv aes 256 anothersecret).
You can also enable SNMP traps with snmp-server enable traps command. Traps are sent by a local
device, so receiving SNMP manager has to be configured. SNMPv3 traps will be sent to address 10.1.1.50
(snmp-server host 10.1.1.50 traps) using user with authPriv security level (priv). You can also limit
events for which traps are sent. In the example, these are cpu and port security related events (cpu port-
security).
SNMP does not identify object instances, such as network interfaces, by their names, rather their numerical
indexes. Whenever a number of instances changes (for instance, when a new Loopback interface is
configured), index numbers may shuffle. As a consequence NMS may mismatch data from different
interfaces. To prevent index shuffle, snmp-server ifindex persist command should be used. This will
guarantee index persistence over device reboots and minor software upgrades.
snmp-server enable traps [notification-type] Enables SNMP notification types that are available on
your system.
snmp-server group group-name {v1 | v2c | v3 Configures a new SNMP group w ith specified
{auth | noauth | priv}} [context context-name] authentication and optionally w ith specified associated
[read read-view][write write-view][notify notify- SNMP context, read, w rite, notify view and associated
view][access [acl-number | acl-name]] ACL.
snmp-server host {ip-address} [infroms | traps| Specifies the recipient of an SNMP notification operation.
version{1 | 2c | 3 {auth | noauth}}}
snmp-server ifindex persist Enable interface index persistence.
snmp-server user username group-name {v1 | v2c | Configures a new user to an SNMP group.
v3 [encrypted][atuh {md5 | sha} auth-password]}
[access [priv {des | 3des | aes {128 | 192 | 256}}
privpassword]] {acl-number | acl-name}]
snmp-server view view-name oid-tree Creates a view entry.
Verifying SNMP Version 3 Configuration
Verification of administrative and operational state of SNMP is a very important step in the overall process
of setting up SNMPv3 in your network.
The command show snmp provides you with basic information about SNMP configuration. You can see if
the SNMP agent is enabled. You can verify whether the device is configured to send traps, and if so, to
which SNMP managers. The SNMP traffic statistics is also provided.
The command show snmp view gives you information about configured SNMP views. You can verify for
each group which OIDs are included. Also, there is a default read view (v1default) displayed, which is used
if you don’t configure any custom read views.
The command show snmp group gives you information about configured SNMP groups. Most important
parameters are security model and level (SNMPv3 authPriv, displayed as v3 priv in the output).
Information about read and write views for the group is displayed. Also, note that although notify view was
not configured explicitly, it is implicitly defined by a set of allowed SNMP objects for specific trap
destination. This is defined at the moment when you configure trap receiver and tie specific user to it – view
is generated for the group to which user belongs (in this case groupZ), in accordance with allowed SNMP
object for the trap receiver.
Access list which defines who has access to the agent is also displayed.
The command show snmp user gives you information about configured SNMP users. Most important
parameters to notice are user name (userZ) and group name to which user belongs (groupZ). Aside from
that, authentication (SHA) and encryption (AES256) algorithms are displayed, which tells you that the
group that the user belongs to is configured with authPriv security level.
Note You can remotely verify your SNMP configuration with a simple SNMP manager, such as
Net-SNMP snmpwalk. Snmpwalk is a simple command line tool that allows you to perform
SNMP queries. To perform an SNMPv3 query, use the snmpwalk -On -v 3 -u <user>
-l <security level> -a <authentication algorithm> -A <authentication
password> -x <encryption algorithm> -X <encription password> <device
IP address> command. Be aware, that the SNMP access from your device might be
limited by an ACL.
Summary
References
For additional information, refer to these references:
• SNMP introduction: http://www.cisco.com/en/US/tech/tk648/tk362/tk605/tsd_technology_support_sub-
protocol_home.html
• SNMP Object navigator: http://tools.cisco.com/Support/SNMP/do/BrowseOID.do
Lesson 3: Implementing IP
SLA
Overview
The Cisco IOS IP SLA (Service Level Agreement) feature can be used to gather realistic information how
specific types of traffic are being handled when they flow across the network. IP SLA device generates
traffic destined to a far-end device. When far-end device responds, the IP SLA device gathers data about
what happened to the traffic along the way.

• Describe the purpose of IP SLA
• Describe the roles of IP SLA source and responder
• Configure ICMP Echo IP SLA to test availability of a remote device
• Describe the operation of IP SLA with responder
• Explain the role of IP SLA responder time stamps
• Configure authentication for IP SLA
• Configure IP SLA UDP Jitter testing
IP SLA Introduction
The network has become increasingly critical for customers, and any downtime or degradation can
adversely affect revenue. Companies need some form of predictability with IP services. An SLA (service
level agreement) is a contract between the network provider and its customers, or between a network
department and internal corporate customers. It provides a form of guarantee to customers about the level of
user experience.
An SLA specifies connectivity and performance agreements for an end-user service from a service provider.
The SLA will typically outline the minimum level of service and the expected level of service. The
networking department can use the SLAs to verify that the service provider is meeting its own SLAs or to
define service levels for critical business applications. An SLA can also be used as the basis for planning
budgets and justifying network expenditures.
Administrators can ultimately reduce the MTTR by proactively isolating network issues. They can change
the network configuration, based on optimized performance metrics.
Typically, the technical components of an SLA contain a guaranteed level for network availability, network
performance in terms of RTT, and network response in terms of latency, jitter, and packet loss. The
specifics of an SLA vary depending on the applications that an organization is supporting in the network.
A simple example of an IP SLA test is the ICMP Echo test. IP SLA uses ICMP Echo Request and Response
packets to test availability of far-end device. The far-end device can be any device with IP capabilities-
router, switch, PC, server, and so on.
Using IP SLA feature in your network you can take advantage of features like:
• Gather information of VoIP quality.
• Track interfaces to influence behavior of first-hop redundancy protocols (HSRP, VRRP, GLBP).
• When thresholds are breached, schedule further IP SLA tests that will tell you more about your
network.
• When a threshold is breached send an SNMP trap.
There are several common functions for the IP SLA measurements:

• Edge-to-edge network availability monitoring.
• Network performance monitoring and network performance visibility.
• VoIP, video, and VPN monitoring.
• SLA monitoring.
• IP service network health.
• MPLS network monitoring.
• Troubleshooting of network operation.
IP SLA measurement uses various operations and actively generated traffic probes to gather many types of
measurement statistics:
• Network latency and response time.
• Packet loss statistics.
• Network jitter and voice quality scoring.
• End-to-end network connectivity.
Multiple IP SLA operations (measurements) can be running in a network at any given time. Reporting tools
use SNMP to extract the data into a database and then report on it.
IP SLA measurements allow the network manager to verify service guarantees, which increases network
reliability by validating network performance, proactively identifying network issues, and easing the
deployment of new IP services.
Which tests you can perform on IP SLA source is platform-dependent:
Switch(config-ip-sla)# ?
IP SLAs entry configuration commands:
dhcp DHCP Operation
dns DNS Query Operation
exit Exit Operation Configuration
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo Operation
path-echo Path Discovered ICMP Echo Operation
path-jitter Path Discovered ICMP Jitter Operation
tcp-connect TCP Connect Operation
udp-echo UDP Echo Operation
udp-jitter UDP Jitter Operation
IP SLA Source and Responder
The IP SLA source is where all IP SLA measurement probe operations are configured either by the CLI or
through an SNMP tool that supports IP SLA operation. The source is also the Cisco IOS device that sends
probe packets. The destination of the probe may be another Cisco device or another network target such as a
web server or IP host.
Although the destination of the majority of the tests can be any IP device, the measurement accuracy of
some of the tests can be improved with an IP SLA responder. An IP SLA responder is a device that runs
Cisco IOS Software. The responder adds a timestamp to the packets sent so the IP SLA source can take into
account any latency that occurred while the responder is processing the test packets. For this test to work
properly both source's and responder's clock need to be synchronized through NTP.
Discovery 13: IP SLA Echo Configuration
Overview
In this discovery, you will learn how to configure and verify IP SLA.
Topology
HQ is local Layer 3 switch that you will configure as IP SLA source. BR is remote Layer 3 switch that will
respond to the IP SLA pings.
Job Aids
Device Information
HQ Ethernet 0/0 192.168.1.1/24
BR Ethernet 0/0 172.16.1.1/24
BR Loopback 0 172.16.22.254/24
IP SLA Echo Configuration

Step 1 On the HQ switch define IP SLA with number 1.
HQ(config)# ip sla 1
This step defines IP SLA operation number. Operation number is an arbitrarily chosen number
that uniquely identifies an IP SLA test.
Step 2 Configure IP SLA 1 on HQ to perform ICMP echo tests to the BR IP of 172.16.22.254.
HQ(config-ip-sla)# icmp-echo 172.16.22.254
Configuring the test to perform starts with the test-type. In this example the test-type is icmp-
echo. Test-type is followed by a list of parameters. In ICMP echo example the only mandatory
parameter is the destination IP address. In this example the destination IP address is that of
switch BR— 172.16.22.254.
NOTE: With IOS releases prior to 12.2(33) you have to use keyword type before defining the
test type. So this exact example would be: type icmp-echo 172.16.22.254.
Step 3 Schedule IP SLA 1 on HQ to perform ICMP Echo test.
HQ(config)# ip sla schedule 1 life forever start-time now
The ip sla schedule command schedules the IP SLA test. It specifies when test starts, for how
long does it run, and for how long the collected data is kept.
Switch(config)# ip sla schedule operation-number [life {forever | seconds}] [start-time
{hh:MM[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds]
[recurring]
With the life keyword you set how long the IP SLA test will run. If you choose forever the test
will run until you manually remove it. By default IP SLA test will run for 1 hour.
With the start-time keyword you will set when the IP SLA test should start. You can start the
test right away by issuing now keyword, or you can configure a delayed start.
With the ageout keyword you can control how long the collected data is kept.
With the recurring keyword you can schedule a test to run periodically—for example the same
time each day.
NOTE: After an IP SLA test is scheduled to run, you will not be able to modify it.
Step 4 On HQ verify the IP SLA configuration.
HQ# show ip sla configuration

IP SLAs Infrastructure Engine-III
Entry number: 1
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 172.16.22.254/0.0.0.0
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Verifying the IP SLA configuration on HQ you should see IP SLA 1 enabled to perform ICMP
Echo tests from the local device to the IP address of 172.16.22.254. Operation frequency is set to
60 seconds and that test will run forever, and collected entries will never age-out.
Step 5 On the HQ verify IP SLA statistics.
HQ# show ip sla statistics

IPSLAs Latest Operation Statistics
IPSLA operation id: 1

Latest RTT: 1 milliseconds
Latest operation start time: 23:31:26 PST Mon Jan 6 2014
Latest operation return code: OK
Number of successes: 32
Number of failures: 0
Operation time to live: Forever
Using show ip sla statistics you can investigate the results of the test. In this example IP SLA 1
test on HQ was successfully performed 32 times and the test has never failed.
You can add the aggregated keyword to view a more summarized output of the show ip sla
statistics command.
You can add the details keyword to view a more detailed output of the show ip sla statistics
command.
NOTE: The show ip sla application command will show you which operations are supported
on the platform and how many operations are configured and/or active.
IP SLA Operation with Responder
Specific IP SLA measurements, such as ICMP Echo, Telnet or HTTP can be performed against a
destination device running standard network services. However the accuracy of the measurements can be
greatly improved with a use of IP SLA Responder. The IP SLAs responder is a component embedded in the
destination Cisco device that allows the system to anticipate and respond to IP SLAs request packets.
Switches and routers can take tens of milliseconds to process incoming packets due to other high priority
processes. This delay affects the response times because the test-packet reply might be in a queue while
waiting to be processed. In this situation, the response times would not accurately represent true network
delays. IP SLA minimizes these processing delays on the source device as well as on the target device (if
the responder is being used) to determine true round-trip times. IP SLAs test packets use time stamping to
minimize the processing delays.
The network manager configures an IP SLA operation by defining a target device, protocol, and port
number on the IP SLA source. The network manager can also configure reaction conditions. The operation
is scheduled to be run for a period of time to gather statistics. The following sequence of events occurs for
each IP SLA operation that requires a responder on the target:
1 At the start of the control phase, the IP SLA source sends a control message with the configured IP SLA
operation information to IP SLA control port UDP 1967 on the target router. The control message
carries information such as protocol, port number, and duration.
– If MD5 authentication is enabled, MD5 checksum is sent with the control message.
– If the authentication of the message is enabled, the responder verifies it; if the authentication fails,
the responder returns an authentication failure message.
– If the IP SLA measurement operation does not receive a response from a responder, it tries to
retransmit the control message and eventually times out.
2 If the responder processes the control message, it sends an OK message to the source router and listens
on the port that is specified in the control message for a specified duration. If the responder cannot
process the control message, it returns an error. In the figure, UDP port 2020 is used for the IP SLA test
packets.
Note The responder is capable of responding to multiple IP SLA measurement operations that try
to connect to the same port number.
3 If the return code of control message is OK, then the IP SLA operation moves to the probing phase,
where it will send one or more test packets to the responder for response time computations. The return
code is available with the show ip sla statistics command. In the figure, these test messages are sent on
control port 2020.
4 The responder accepts the test packets and responds. Based on the type of operation, the responder may
add an “in” time stamp and an “out” time stamp in the response packet payload to account for CPU time
that is spent in measuring unidirectional packet loss, latency, and jitter to a Cisco device. These time
stamps help the IP SLA source to make accurate assessments on one-way delay and the processing time
in the target routers. The responder disables the user-specified port after it responds to the IP SLA
measurements packet or when a specified time expires.
IP SLA Responder Time Stamps
The figure illustrates the use of IP SLA responder time stamps in round-trip calculations. The IP SLA
source will use four time stamps for the RTT calculation. The IP SLA source sends a test packet at time T1.
The IP SLA responder includes both the receipt time (T2) and transmit time (T3). Because of other high-
priority processes, routers can take tens of milliseconds to process incoming packets. The delay affects the
response times as the reply to test packets might be sitting in a queue while waiting to be processed. This
time stamping is made with a granularity of submilliseconds. At times of high network activity, an ICMP
ping test often shows a long and inaccurate response time, while an IP SLA–based responder shows an
accurate response time. The IP SLA source subtracts T2 from T3 to produce the time spent processing the
test packet in the IP SLA responder. This time is represented by a delta value.
The delta value is then subtracted from the overall RTT. The same principle is applied by the IP SLA source
where the incoming T4 is also taken at the interrupt level to allow for greater accuracy, as compared with
T5 when the packet is processed.
An additional benefit of two time stamps at the IP SLA responder is the ability to track one-way delay,
jitter, and directional packet loss. These statistics are critical, because a great deal of network behavior is
asynchronous. To capture one-way delay measurements, you must configure both the IP SLA source and the
IP SLA responder with the NTP.
Both the source and destination must be synchronized to the same clock source. The IP SLA responder
provides enhanced accuracy for measurements, without the need for dedicated third-party external probe
devices. It also provides additional statistics, which are not otherwise available via standard ICMP-based
measurements.
Configuring Authentication for IP SLA
The key-chains should be configured on the source router as well as on the destination router. Only then
source device will be allowed to interact with the destination router.
Multiple authentication strings can be configured for a key-chain. When multiple strings are configured,
then MD5 alternates between the strings during communication.
Once a key-chain is configured, it has to be tied to Cisco IOS IP SLAs, so that it could use these
authentication strings for authenticating control messages.
Configuration Example: UDP Jitter
The IP SLAs UDP jitter operation was primarily designed to diagnose network suitability for real-time
traffic applications such as VoIP, video over IP, or real-time conferencing.
This topic presents an example of how IP SLA feature can be used. There are many more uses for it, this is
just one of them.
Jitter means inter-packet delay variance. When multiple packets are sent consecutively from source to
destination, for example, 10 ms apart, and the network is behaving ideally, the destination should be
receiving them 10 ms apart. But if there are delays in the network (like queuing, arriving through alternate
routes, and so on) the arrival delay between packets might be greater than or less than 10 ms. Using this
example, a positive jitter value indicates that the packets arrived more than 10 ms apart. If the packets arrive
12 ms apart, then positive jitter is 2 ms; if the packets arrive 8 ms apart, then negative jitter is 2 ms. For
delay-sensitive networks like VoIP, positive jitter values are undesirable, and a jitter value of 0 is ideal.
To configure UDP jitter SLA, simply enter IP SLA configuration mode and define UDP jitter test:
Switch(config-ip-sla)# udp-jitter dest-ip-add dest-udp-port [source-ip src-ip-add]
[source-port src-udp-port] [num-packets num-of-packets] [interval packet-interval]
With UDP jitter IP SLA configuration you can specify IP and destination IP addresses and also specify the
port numbers that are used for the packet stream. By default 10 packets, spaced at 20 milliseconds will be
sent. You can override this behavior by specifying the num-packets and interval keywords.
After defining the basic UDP jitter test, you can specify additional parameters. In provided example these
additional parameters are the frequency of test execution and number of bytes in payload.
Summary
References
For additional information, refer to:
• Configuring IP SLAs UDP Jitter Operations: http://www.cisco.com/en/US/docs/ios-
xml/ios/ipsla/configuration/15-mt/sla_udp_jitter.html
Lesson 4: Implementing Port
Mirroring for Monitoring
Support
Overview
Cisco Switches provide various information, such as resource utilization, traffic counts, error counts, etc.
However certain traffic information can only be acquired by specialized traffic sniffers and analyzers. To
feed the traffic sniffer with traffic flows, you can use SPAN feature.
• Describe what is SPAN
• Describe SPAN terminology
• Describe different versions of SPAN
• Configure SPAN
• Verify local SPAN configuration
• Configure RSPAN
• Verify RSPAN configuration
What is SPAN?
Traffic sniffer can be a valuable tool to monitor and troubleshoot a network. Properly placing a traffic
sniffer to capture a traffic flow but not interrupt it can prove challenging.
When local area networks were based on hubs, connecting a traffic sniffer was simple. When a hub receives
a packet on one port, the hub sends out a copy of that packet on all ports except on the one where the hub
received the packet. Traffic sniffer connected a hub port could thus receive all traffic in the network.
Modern local networks are essentially switched networks. After a switch boots, it starts to build up a Layer
2 forwarding table on the basis of the source MAC address of the different packets that the switch receives.
After this forwarding table is built, the switch forwards traffic that is destined for a MAC address directly to
the corresponding port, thus preventing a traffic sniffer that is connected to another port to receive the
unicast traffic.
The SPAN feature was therefore introduced on switches.
SPAN feature allows you to instruct a switch to send copies of packets seen on one port, to another port on
the same switch.
If you would like to analyze the traffic flowing from PC1 to PC2, you need to specify a source port. You
can either configure interface GigabitEthernet0/1 to capture the ingress traffic or interface
GigabitEthernet0/2 to capture the egress traffic. Second, specify interface GigabitEthernet0/3 as a
destination port. Traffic flowing from PC1 to PC2 will then be copied to that interface and you will be able
to analyze it with a traffic sniffer.
Besides the traffic on ports, you can also monitor the traffic on VLANs.
SPAN Terminology
SPAN features two different port types. Source port is a port that is monitored for traffic analysis. SPAN
can copy ingress, egress or both traffic from a source port. Both Layer 2 and Layer 3 ports can be
configured as SPAN source ports. Traffic is copied to destination (also called monitor) port.
Association of source ports and a destination port is called a SPAN session. In a single session you can
monitor one or multiple source ports. Depending on the switch series you might be able to copy session
traffic to more than one destination port.
Alternatively you can specify a source VLAN, where all ports in the source VLAN become sources of
SPAN traffic. Each SPAN session can have either ports or VLANs as sources, but not both.
Remote SPAN
SPAN feature is limited, as it only allows for local copy on a single switch. Typical switched network
usually consists of multiple switches and it is practical to monitor ports spread all over the switched network
with a single packet sniffer. This is possible with the Remote SPAN.
While local SPAN supports source and destination ports only on one switch, a Remote SPAN supports
source and destination ports on different switches.
RSPAN consists of an:

• RSPAN source session.
• RSPAN VLAN.
• RSPAN destination session.
You separately configure RSPAN source sessions and destination sessions on different switches. Your
monitored traffic is flooded into RSPAN VLAN that is dedicated for the RSPAN session in all participating
switches. RSPAN destination port can then be anywhere in that VLAN.
On some of the platforms a reflector port needs to be specified together with RSPAN VLAN. Reflector
port is a physical interface which acts as a loopback and reflects the traffic that is copied from source ports
to an RSPAN VLAN. No traffic is actually sent out of the interface that is assigned as the reflector port. The
need for a reflector port is caused by hardware design limitation on some platforms. Reflector port can only
be used for one session at a time.
Local SPAN Configuration
When configuring a SPAN, you have to take notice on following facts:

• The destination port cannot be a source port, or vice versa.
• Number of destination ports is platform-dependent, some platform allow for more than one destination
port.
• Destination port is no longer a normal switch port—only monitored traffic passes through that port.
In the example shown in the figure, the objective is to capture all the traffic that is sent or received by the
PC connected to port GigabitEthernet 0/1 on the switch. A packet sniffer is connected to port
GigabitEthernet 0/2. The switch is instructed to copy all the traffic that it sends and receives on port
GigabitEthernet 0/1 to port GigabitEthernet 0/2 by configuring a SPAN session.
The SPAN session is identified by a session number, in our example "1". The first step is then that you
associate SPAN session with source ports or VLANs by use of following command:
monitor session number source interface/vlans
Similarly, you associate destination port with SPAN session number by use of the following command:
monitor session number destination interface/vlans
Verifying Local SPAN Configuration
You can verify the configuration of the SPAN session by using the show monitor command.
As shown in the example above, the show monitor command returns the type of the session, source ports
for each traffic directions, and the destination port. In the example shown in the figure, information about
session number "1" are presented—source ports for both traffic directions is GigabitEthernet 0/1 and
destination port is GigabitEthernet 0/2. The ingress SPAN is disabled on destination port, so only traffic that
leaves the switch is copied to it.
In case you have more than one session configured, information about all session are shown after using the
show monitor command.
Remote SPAN Configuration
There are some differences between the configuration of remote SPAN and the configuration of local
SPAN.
As the ports are now on two different switches, you use a special RSPAN VLAN to transport the traffic
from one switch to the other. You configure this VLAN as any other VLAN but in addition you enter the
remote-span keyword in VLAN configuration mode. You need to define this VLAN on all switches in the
path.
Remote SPAN uses two sessions—source and destination.
Use the following commands to define the port that traffic is captured from and the port that traffic is copied
to:
• monitor session number source interface slot/number
• monitor session number destination remote vlan vlan-number
These two sessions need to be defined on both, local and remote switch.
Session numbers are local to each switch, so they don't need to be the same on every switch.
Verifying Remote SPAN Configuration
As with local SPAN configuration, you can verify RSPAN session configuration by using show monitor
command.
The only difference is, that now on the source switch the session type is identified as "Remote Source
Session", while on the destination switch it is marked as "Remote Destination Session".
In addition to verifying the correct configuration, it is also important that you verify that the VLAN is
configured correctly as RSPAN VLAN on both switches. You can verify this by using show vlan remote-
span command.
Summary
Lesson 5: Verifying Switch
Virtualization
Overview
Redundant topologies often introduce overhead in terms of management, resiliency, and performance. To
reduce the number of logical network devices and simplify Layer 2 and Layer 3 network topology, you can
use two switch virtualization technologies: StackWise and VSS.

• Describe the need and basic idea behind switch stacking and VSS
• Describe StackWise
• Describe the benefits of StackWise
• Verify StackWise
• Explain Supervisor Redundancy
• Describe Supervisor Redundancy Modes
• Describe what is VSS
• Describe VSS benefits
• Verify VSS
The Need for Logical Switching Architectures
The figure shows a typical switch topology on the access and the distribution layer. Two (or more) access
switches are sitting next to each other in the same rack to provide enough access ports for all the network
devices, each one with two redundant connections to each of the distribution switches.
This topology introduces certain overhead in terms of management, resiliency, and performance.
Every switch demands it‘s own configuration and management, even though you can clearly identify only
two different roles – access and distribution. Every access switch needs it‘s own uplink to each of the
distribution switches to satisfy the redundancy requirements, but one of the uplinks has to be blocked by the
spanning tree protocol to prevent a loop, thus cutting the bandwidth in half. Configuring per-VLAN
spanning tree protocol will unequally utilize both uplinks, but with additional management overhead. Hosts
connected to ASW1 can only communicate with hosts in the same VLAN connected to ASW2 via one of
the distribution switches.
What is StackWise?
Cisco StackWise technology provides a method for collectively utilizing the capabilities of a stack of
switches. Configuration and routing information is shared by every switch in the stack, creating a single
switching unit. Switches can be added to and deleted from a working stack without affecting the
performance.
The switches are united into a single logical unit, using special stack interconnect cables that create a
bidirectional closed-loop path. This bidirectional path acts as a switch fabric for all the connected switches.
Network topology and routing information are updated continuously through the stack interconnect. All
stack members have full access to the stack interconnect bandwidth. The stack is managed as a single unit
by a master switch, which is elected from one of the stack member switches. Up to nine separate switches
can be joined.
Each stack of switches has a single IP address and is managed as a single object. This single IP management
applies to activities such as fault detection, VLAN creation and modification, security, and QoS controls.
Each stack has only one configuration file, which is distributed to each member in the stack. This allows
each switch in the stack to share the same network topology, MAC address, and routing information. In
addition, it allows for any member to become the master if the master ever fails.
Note Catalyst 3750-E, 3750-X, and 3850 series switches support StackWise and StackWise Plus.
StackWise Plus is an evolution of StackWise. StackWise Plus supports local switching, so
locally destined packets need not traverse the stack ring. Additionaly it supports spatial
reuse, ability to more efficiently utilize stack interconnect, thus further improving it's
throughput performance. Catalyst 3850 series supports StackWise-480 with improved 480
Gbps stacking. Catalyst 2960-S series supports FlexStack, a StackWise based feature
tailored for Layer 2 switches. FlexStack is limited to 4 stacked switches.
StackWise Benefits
Uniting switches into a stack has multiple benefits.
StackWise is typically used to unite access switches mounted in the same rack. Multiple switches are used
to provide enough access ports. The stack, up to 9 switches, is managed as a single unit, reducing the
number of units you have to manage in your network. Switches can be added to and removed from a
working stack without affecting stack performance. When a new switch is added, the master switch
automatically configures the unit with the currently running IOS image and the configuration of the stack.
You do not have to do anything to bring up the switch before it is ready to operate.
The switches are united into a single logical unit using special stack interconnect cables that create a
bidirectional closed-loop path. This bidirectional path acts as a switch fabric for all the connected switches.
When a break is detected in a cable, the traffic is immediately wrapped back across the remaining path to
continue forwarding.
Multiple switches in a stack can create an EtherChannel connection. Spanning tree protocol can thus be
avoided, doubling the available bandwidth of the existing distribution switches uplinks.
Verifying StackWise
You can verify the status of your stack by using the show switch command with different parameters.
The show switch command without additional parameters returns the shared stack MAC address and lists
all the switches in a stack with their stack number, stack role, MAC address, hardware priority, hardware
version, and current state. Hardware priority is used in stack master election and can be configured.
Hardware version number is associated with the switch model. Different switch models can have the same
hardware version if they support the same system-level features. Hardware version number is not used in the
stack master election.
Each stack switch uses 2 ports to connect to other stack switches to form a bidirectional ring. You can verify
the state of stack port with the show switch stack-ports command.
The show platform stack manager all command offers an in-depth view into StackWise status. It reveals
the stack status, stack ports status, stack manager version, different counters, and so on.
Redundant Switch Supervisors
Cisco Supervisor Engine module is the heart of the Cisco modular switch platforms. The supervisor
provides centralized forwarding information and processing. All software processes of a modular switch are
run on a supervisor.
Platforms such as the Catalyst 4500, 6500 and 6800 series can accept two supervisor modules that are
installed in a single chassis, thus removing a single point of failure. The first supervisor module to
successfully boot becomes the active supervisor for the chassis. The other supervisor remains in a standby
role, waiting for the active supervisor to fail.
All switching functions are provided by the active supervisor. The standby supervisor, however, is allowed
to boot up and initialize only to a certain level. When the active module fails, the standby module can
proceed to initialize any remaining functions and take over the active role.
Supervisor Redundancy Modes
Redundant supervisor modules can be configured in several modes. The redundancy mode affects how the
two supervisors handshake and synchronize information. Additionally, the mode limits the standby
supervisor's state of readiness. The more ready the standby module is allowed to become, the less
initialization and failover time will be required.
You can use the following redundancy modes on Catalyst switches:

• Route processor redundancy (RPR): The redundant supervisor is only partially booted and initialized.
When the active module fails, the standby module must reload every other module in the switch then
initialize all the supervisor functions.
• Route processor redundancy plus (RPR+): The redundant supervisor is booted, allowing the
supervisor and route engine to initialize. No Layer 2 or Layer 3 functions are started. When the active
module fails, the standby module finishes initializing without reloading other switch modules. This
allows switch ports to retain their state.
• Stateful switchover (SSO): The redundant supervisor is fully booted and initialized. Both the startup
and running configuration contents are synchronized between the supervisor modules. Layer 2
information is maintained on both supervisors so that hardware switching can continue during a
failover. The state of the switch interfaces is also maintained on both supervisors so that links don't flap
during a failover.
Nonstop Forwarding
You can enable another redundancy feature along with SSO. NSF is an interactive method that focuses on
quickly rebuilding the RIB table after a supervisor switchover. The RIB is used to generate the FIB table for
CEF, which is downloaded to any switch modules that can perform CEF.
What is VSS?
VSS is a network system virtualization technology that combines a pair of Catalyst 4500 or 6500 series
switches into one virtual switch, increasing the operational efficiency, boosting nonstop communications,
and scaling the system bandwidth capacity. The VSS simplifies network configuration and operation by
reducing the number of Layer 3 routing neighbors and by providing a loop-free Layer 2 topology.
VSS is made up of two Catalyst switches and a VSL between them. VSL is made up of up to eight 10
Gigabit Ethernet connections bundled into an EtherChannel. VSL carries the control plane communication
between the two VSS members, as well as regular data traffic.
Once the VSS is formed, only the control plane of one of the member's is active. Data plane and switch
fabric of both members are active. Both chassis are kept in sync with the interchassis SSO mechanism along
with NSF to provide nonstop communication even in the event of failure of one of the member supervisor
engines or chassis.
VSS Benefits
VSS increases operational efficiency by reducing switch management overhead and simplifying the
network. It provides a single point of management, IP address, and routing instance.
You see a single management point from which you configure and manage the VSS. Neighbors see the VSS
as a single Layer 2 switching or Layer 3 routing node, thus reducing the control protocol traffic. VSS
provides a single VLAN gateway IP address, removing the need for the first-hop redundancy protocol
(HSRP, VRRP, GLBP). MEC allows you to bundle links to 2 physical switches in VSS, creating a loop-free
redundant topology without the need for Spanning Tree Protocol.
Interchassis stateful failover results in no disruption to applications that rely on network state information
(for example, forwarding table info, NetFlow, Network Address Translation, authentication, and
authorization). VSS eliminates Layer 2 / Layer 3 protocol reconvergence if a virtual switch member fails,
resulting in deterministic subsecond virtual switch recovery.
Verifying VSS
You can verify the status of your stack by using the show switch virtual command with different
parameters.
To display configuration and status information for a VSS, use the show switch virtual command. Active
and standby switches will be displayed, together with a virtual switch domain number. You can display
further details, such as priority, by adding the role keyword:
Switch1# show switch virtual role
RRP information for Instance 1
--------------------------------------------------------------------
Valid Flags Peer Preferred Reserved
Count Peer Peer
--------------------------------------------------------------------
TRUE V 1 1 1
Switch Switch Status Priority Role Local Remote

Number Oper(Conf) SID SID
--------------------------------------------------------------------
LOCAL 1 UP 200(200) ACTIVE 0 0
REMOTE 2 UP 100(100) STANDBY 1730 5394
Peer 0 represents the local switch
Flags : V - Valid
In dual-active recovery mode: No
You can display virtual switch link status with the show switch virtual link command. More information,
such as EthetChannel used for VSL, can be obtained by adding port-channel keyword:
Switch1# show switch virtual link port-channel
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, no aggregation due to minimum links not met

m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
d - default port
w - waiting to be aggregated
Group Port-channel Protocol Ports

------+-------------+-----------+-------------------
2 Po2(RU) - Te1/5/4(P) Te1/5/5(P)
3 Po3(RU) - Te2/5/4(P) Te2/5/5(P)
Summary
References
• StackWise and StackWise Plus whitepaper:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5023/prod_white_paper09186a00801b0
96a.html
• StackWise creation and management:
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a008
07811ad.shtml
• FlexStack description and usage:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/white_paper_c11-578928.html
• SSO configuration guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SY/configuration/guide/stateful_s
witchover.html
• VSS configuration guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html
• VSS Q&A:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/prod_qas0900aecd806ed74b.html
Overview
Check
1. Which of the following statements are true? (Chose two.) (Source: Configuring Network Time Protocol)
A. Stratum 1 devices have directly attached radio or atomic clock.
B. Higher stratum number always indicates greater quality and reliability.
C. Stratum number represents the distance from a reference clock.
D. Network devices will always synchronise with NTP server with the highest stratum number.
2. Different NTP restrictions can be configured through ACLs on Cisco devices. Match the restriction
keyword with the restriction it applies. (Source: Configuring Network Time Protocol)
Time synchronization requests and control queries are allowed.

A. peer
Device is allowed to synchronize itself to remote systems that
pass the access list.
Time synchronization requests and control queries are allowed.
B. query-
Device is not allowed to synchronize itself to remote systems
only that pass the access list.
Only allows synchronization requests.
C. serve
Only allows control queries.
D. serve-
only
3. Match SNMP versions with their descriptions. (Source: Implementing SNMP Version 3)
Initial version, rarely used nowadays.
A. SNMPv1
Added a complex security model, but was never widely
B. SNMPv2
accepted.
Community based de-facto standard, widely used, but
C. SNMPv3 provides no security features besides a community string.
Supports authentication and encryption. Should be used
D. SNMPv2c
whenever possible.
4. Which of the following SNMP statements are true? (Chose two.) (Source: Implementing SNMP Version
3)
A. Given the SNMP write access, a device can be remotely reconfigured via SNMP.
B. Network Management Systems (NMS) include their own SNMP agent.
C. snmp-server ifindex persist command exposes interface counters over SNMP.
D. SNMP traps are sent from the SNMP agent to the SNMP manager and are event based.
5. Which of the following SNMP recommendations is not valid? (Source: Implementing SNMP Version 3)
A. Always use MD5 authentication when SNMPv3 is not available and you are forced to use
SNMPv2c.
B. Restrict access to read-only.
C. Setup SNMP views to restrict manager to only access needed set of MIBs.
D. Configure ACLs to restrict SNMP access only by known managers.
6. Which statement about IP SLA Responder is true? (Source: Implementing IP SLA)

A. The responder can respond to multiple IP SLA measurement operations that try to connect to the
same port number.
B. IP SLA operation with responder has two phases: control and management.
C. IP SLA source and responder communicate over TCP.
D. All IP SLA tests will only work if IP SLA responder is used.
7. Which of the following IP SLA statements are true? (Chose two.) (Source: Implementing IP SLA)
A. IP SLA guarantees the service level of a network link
B. Results of the IP SLA tests can be polled from device using SNMP.
C. IP SLA Responder can improve the accuracy of the test by subtracting the time spent to process a
packet on the destination device.
D. Under no condition IP SLA measurement can take into account processing delay of an IP SLA test.
8. Match switch virtualization terms with their descriptions. (Source: Verifying Switch Virtualization)
Joins up to 9 individual switches in a single logical
A. StackWise
switching unit.
Network system virtualization technology that pools
B. Virtual switch
two multichasis switches into one virtual switch.
link (VSL)
Connects switches to create a bidirectional closed-loop
C. Virtual
path.
Switching
System (VSS)
Carries regular data traffic in addition to the control

D. StackWise
plane communication between the two virtual switch
interconnect
members. It consists of multiple 10 GigabitEthernet
cable
connections bundled in an EtherChannel.
9. Which of the following is not a technology used to join Cisco switches in a stack? (Source: Verifying
Switch Virtualization)
A. StackWise
B. StackWise Plus
C. StackWise-480
D. StackPower
E. FlexStack
10. What is Switched Port Analyzer (SPAN)? (Source: Implementing Port Mirroring for Monitoring
Support)
A. SPAN performs analysis of the management traffic flowing through the switch.
B. SPAN is a packet sniffing feature.
C. SPAN allows a switch to send copies of packets seen on one port, to another port on the same switch.
D. SPAN logs the traffic. Logs can later be exported in a traffic analyser to be analysed.
11. Which of the following RSPAN statements are true? (Chose two.) (Source: Implementing Port
Mirroring for Monitoring Support)
A. RSPAN requires a dedicated RSPAN VLAN.
B. RSPAN supports source and destination ports on different switches.
C. RSPAN sessions work across WAN.
D. A reflector port forwards all traffic to connected device.
Answer Key
1 A, C
2
A. peer — Time synchronization requests and control queries are allowed. Device is allowed to
B. serve — Time synchronization requests and control queries are allowed. Device is not allowed to
C. serve-only — Only allows synchronization requests.
D. query-only — Only allows control queries.
3
A. SNMPv1 — Initial version, rarely used nowadays.
B. SNMPv2 — Added a complex security model, but was never widely accepted.
C. SNMPv2c — Community based de-facto standard, widely used, but provides no security features
besides a community string.
D. SNMPv3 — Supports authentication and encryption. Should be used whenever possible.
4 A, D
5 A
6 A
7 B, C
8
A. StackWise — Joins up to 9 individual switches in a single logical switching unit.
B. Virtual Switching System (VSS) — Network system virtualization technology that pools two
multichasis switches into one virtual switch.
C. StackWise interconnect cable — Connects switches to create a bidirectional closed-loop path.
D. Virtual switch link (VSL) — Carries regular data traffic in addition to the control plane
communication between the two virtual switch members. It consists of multiple 10 GigabitEthernet
connections bundled in an EtherChannel.
9 D
10 C
11 A, B
Module 6: First Hop
Redundancy Implementation
Introduction
A First Hop Redundancy Protocol (FHRP) is a networking protocol that is designed to protect the default
gateway by allowing two or more routers or Layer 3 switches to provide backup for that address. If one
first-hop device fails, the backup router will take over the address, by default within a few seconds.
HSRP, VRRP, and GLBP are three first-hop redundancy protocols. All three protocols have versions that
support first-hop redundancy not only in IPv4 environments, but also IPv6. However not all platforms and
their IOS versions support all of these three protocols for both IPv4 and IPv6.

• Configure and verify HSRP.
• Configure and verify VRRP.
• Configure and verify GLBP.
• Configure and verify GLBP and HSRP in IPv6 environment.
3 Redundancy with HSRP
Overview
A network with high availability provides alternative means by which all infrastructure paths and key
servers can be accessed at all times. The HSRP is one of the features that can be configured to provide
default gateway redundancy to network hosts. HSRP optimization provides immediate or link-specific
failover as well as a recovery mechanism.

• Describe the need for first hop redundancy protocols
• Describe the principle of first hop redundancy
• Configure basic HSRP
• Describe HSRP state transitions
• Align HSRP with STP topology
• Explain load sharing with HSRP
• Describe what options HSRP has for tracking
• Configure HSRP interface tracking
• Configure object tracking in combination with HSRP
• Configure HSRP authentication
• Tune HSRP timers
• Describe differences between HSRP versions 1 and 2
The Need for First Hop Redundancy
Take a look at the figure. Both Router A and Router B are connected to the 10.1.10.0/24 network and are
advertising it with the routing protocol. All the packets that are destined to the 10.1.10.0/24 network are
routed to router A. Should router A become unavailable, the routing protocol will dynamically converge,
and packets will be routed to router B. Redundancy is thus achieved with dynamic routing protocol.
Workstations in the 10.1.10.0/24 subnet, however, like most workstations, servers, printers, and other
network hosts, does not support dynamic routing protocols. Whenever a network host wants to
communicate with a host that is located in a different subnet, packets must be relayed through a Layer 3
device (router or Layer 3 switch). Packets that are destined to another subnet are sent to a Layer 3 device by
either Proxy ARP or default gateway setting.
With the Proxy ARP technique, Layer 3 device offers its own MAC address in response to an ARP query to
a MAC address that exists outside the source subnet, thus accepting all subsequent packets destined to that
address, routing them to another subnet. Proxy ARP technique has no fallback mechanisms and introduction
of multiple routers that use this technique in the same subnet will cause issues such as MAC flapping.
Network hosts are configured with a single default gateway IP address. All packets destined to another
subnet are sent to the default gateway IP address, which does not change when network topology changes
occur. If the router whose IP address serves as the default gateway to the network hosts fails, a network host
will be unable to send packets to another subnet, effectively disconnecting it from the rest of the network.
Even if a redundant router exists that could serve as a default gateway for that subnet, there is no dynamic
method by which these devices can determine the address of a new default gateway.
The Idea Behind First Hop Redundancy Process
With the first hop router redundancy, a set of routers or Layer 3 switches work together to present the
illusion of a single virtual router to the hosts on the LAN. By sharing an IP address and a MAC (Layer 2)
address, two or more routers can act as a single “virtual” router.
The IP address of the virtual router is configured as the default gateway for the workstations on a specific IP
subnet. When frames are to be sent from the workstation to the default gateway, the workstation uses ARP
to resolve the MAC address that is associated with the IP address of the default gateway. The ARP
resolution will return the MAC address of the virtual router. Frames that are sent to the MAC address of the
virtual router can then be physically processed by an active router that is part of that virtual router group.
A protocol is used to identify two or more routers as devices that are responsible for processing the frames
that are sent to the MAC or IP address of a single virtual router. Host devices send traffic to the address of
the virtual router, which is then picked up and routed by an active physical router. The physical router that
forwards this traffic is transparent to the network hosts.
The redundancy protocol provides the mechanism for determining which router should take the active role
in forwarding traffic and determining when that role must be taken over by a standby router. The transition
from one forwarding router to another is transparent to the network hosts.
When the forwarding router or a link to it fails:

• The standby router stops seeing hello messages from the forwarding router.
• The standby router assumes the role of the forwarding router.
• As the new forwarding router assumes both the IP and MAC addresses of the virtual router, the end
stations see no disruption in service.
Examples of first hop redundancy protocols are HSRP, VRRP, and GLBP. HSRP and GLBP are Cisco
proprietary protocols. VRRP is an industry standard protocol.
Discovery 14: Configuring and Tuning HSRP
Overview
HSRP is a Cisco proprietary protocol that was developed to allow several multilayer switches or routers to
appear as a single gateway IP address.
In this discovery you will learn how to configure HSRP.
Note In this discovery, HSRP, which is an example of FHRP, can be configured on Layer 3
switches and routers. In this discovery, HSRP is configured on routers since IOL does not
support the HSRP feature on switches.
Topology
Job Aids
IP Addressing
Configuring and Tuning HSRP

Step 1 Configure R1's Ethernet 0/1 (LAN-facing interface) with 192.168.1.3/24 IP address and HSRP
standby IP of 192.168.1.1.
The IP of 192.168.1.1 is HSRP´s virtual IP address that is also configured as the default gateway
IP address on PC1 and PC2.
R1(config)# interface ethernet 0/1

R1(config-if)# ip address 192.168.1.3 255.255.255.0
R1(config-if)# standby 1 ip 192.168.1.1
Step 2 Configure R2's Ethernet 0/1 (LAN-facing interface) with 192.168.1.2/24 IP address and HSRP
standby IP of 192.168.1.1.
Both R1 and R2 must have the same HSRP standby IP address configured.
R2(config-if)# standby 1 ip 192.168.1.1
An HSRP group is a set of HSRP devices emulating a virtual router. You have assigned both
routers a common HSRP group—group 1. If you had left out the group number, it would be set
to default group 0. With HSRP version 1, a group number can be any integer between 0 and 255.
If you are configuring HSRP on a multilayer switch, it is a good practice to configure HSRP
group number equal to the VLAN number. HSRP group numbers are locally significant. For
example, HSRP group 1 on interface VLAN 22 is independent from HSRP group 1 on interface
VLAN 33.
One of the two routers will be elected as "active" and the other will be elected as "standby". If
you had more routers in your HSRP group, they would be in the "listen" state. Roles are elected
based on the exchange of HSRP hello messages. When the active router fails, the other HSRP
routers stop seeing hello messages from the active router. The standby router then assumes the
role of the active router. If other routers are participating in the group, they then contend to be
the new standby router. Should both the active and standby router fail, all other routers in the
group contend for the active and standby router roles. As the new active router assumes both the
IP and the MAC addresses of the virtual router, the end stations see no disruption in the service.
The end stations continue to send packets to the virtual router MAC address, and the new active
router forwards the packets towards their destination.
HSRP active and standby routers send hello messages to multicast address 224.0.0.2 UDP port
1985.
The ICMP protocol allows a router to redirect an end station to send packets for a particular
destination to another router on the same subnet. That is, if the first router knows that the other
router has a better path to that particular destination. As was the case for default gateways, if the
router to which an end station has been redirected for a particular destination fails, then the end
station's packets to that destination were not delivered. In standard HSRP, this is exactly what
happens. For this reason, we recommend disabling ICMP redirects if HSRP is turned on.
Step 3 On R1 verify the ARP table.
R1# show ip arp

Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 - 0000.0c07.ac01 ARPA Ethernet0/1
Internet 192.168.1.2 - aabb.cc01.ba10 ARPA Ethernet0/1
Internet 192.168.1.3 50 aabb.cc01.bb10 ARPA Ethernet0/1
Internet 192.168.2.1 - aabb.cc01.ba00 ARPA Ethernet0/0
Internet 192.168.2.2 51 aabb.cc01.bc00 ARPA Ethernet0/0
The IP address and the corresponding MAC address of the virtual router are maintained in the
ARP table of the active router in an HSRP group.
The HSRP MAC address is in the following format: 0000.0c07.acXX, where XX is the HSRP
group number. Clients utilize this MAC address to forward data.
Forwarding Through Active Router
All the routers in an HSRP group have specific roles and interact in specific ways.
The virtual router is simply an IP and MAC address pair that end devices have configured as their default
gateway. The active router will process all packets and frames that are sent to the virtual router address. The
virtual router processes no physical frames.
Within an HSRP group, one router is elected to be the active router. The active router responds to traffic for
the virtual router. If an end station sends a packet to the virtual router MAC address, the active router
receives and processes that packet. If an end station sends an ARP request with the virtual router IP address,
the active router replies with the virtual router MAC address. In this example, R1 assumes the active role
and forwards all frames that are addressed to the well-known MAC address of 0000.0c07.acXX, where XX
is the HSRP group identifier.
Step 4 Configure R2's HSRP group 1 with priority of 110.

R2(config-if)# standby 1 priority 110
HSRP priority is a parameter that enables you to choose the active router between HSRP-enabled
devices in a group. Priority is a value between 0 and 255. The default value is 100. The device
with the highest priority will become active.
If HSRP group priorities are the same, the device with the highest IP address will become active.
In this example that is R1.
Setting priority is wise for deterministic reasons. You want to know, not guess, how your
network will behave under normal conditions. Knowing that R2 is the active gateway for VLAN
1 clients, enables you to write up good documentation.
However, now that you have changed R2's priority to 110, it will not automatically become the
active router as preemption is not enabled by default. Preemption is the ability of a HSRP-
enabled device to trigger the re-election process.
Step 5 Configure R1's and R2's Ethernet 0/1 HSRP group 1 interfaces with preemption.

R1(config-if)# standby 1 preempt

R2(config-if)# standby 1 preempt
Notice that after you enable preemption R1 will change it's state to "standby" and R2 will change
it's state to "active".
Step 6 On R1 and R2, verify HSRP status.
R1# show standby

Ethernet0/1 - Group 1
State is Standby
10 state changes, last state change 00:14:15
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.152 secs
Preemption enabled
Active router is 192.168.1.2, priority 110 (expires in 9.744 sec)
Standby router is local
Priority 100 (default 100)
Group name is "hsrp-Et0/1-1" (default)
R2# show standby brief

P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Et0/1 1 110 P Active local 192.168.1.3 192.168.1.1
R1 is the standby router and R2 is the active router. The output of show standby can be
condensed using the brief keyword.
Step 7 Enable continuous ping from PC1 to server at 192.168.2.44.
PC1# ping 192.168.4.22 repeat 10000000

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Right now traffic flows from PC1 through ASW1, ASW2, R2, R3, to the server, and back. This
is because R2 is the active router.
Step 8 To simulate R2's failure, shut down it's Ethernet 0/1 interface.
A few attempts might get lost on your continuous ping from PC1 to the server, but the switch-
over from R2 to R1 should be quick and seamless for PC1.

R2(config-if)# shutdown
Step 9 On R1 and R2, investigate the HSRP status.

|
Et0/1 1 100 P Active local unknown 192.168.1.1

|
Et0/1 1 110 P Init unknown unknown 192.168.1.1
R1 has taken over as the active router and R2 is stuck in the "Init" state. The "Init" state indicates
that R1 and R2 are not recognizing each other as HSRP peers. This is logical since they have lost
direct connectivity over LAN interfaces.
Step 10 On R2, bring up the Ethernet 0/1 interface.

R2(config-if)# no shutdown
Will R2 become the active or the standby router?
Step 11 Investigate the HSRP status on R1 and R2.
|
Et0/1 1 100 P Standby 192.168.1.2 local 192.168.1.1

|
Et0/1 1 100 Active local 192.168.1.3 192.168.1.1
After R2 is available again, it almost instantly becomes the active router. R1 is on standby again.
This is only because preemption is enabled. Thus, when an HSRP-enabled device with higher
priority comes online, it will become the active device.
With preemption disabled, which is the default behavior, R2 would not regain active status after
coming back online.
If you would perform a traceroute from PC1 to the server, you would see that R2 answers with
its "real" interface address (192.168.1.2), not the virtual HSRP address (192.168.1.1). This is
really helpful if you want to verify through which first-hop device is traffic going.
HSRP State Transition
When a router exists in one of these states, it performs the actions required by that state. Not all HSRP
routers in the group will transition through all states. In a HSRP group with three or more routers, a router
that is not the standby or active router will remain in the listen state.
All routers begin in the initial state. This is the starting state and it indicates that HSRP is not running. This
state is entered via configuration change, such as when HSRP is disabled on an interface, or when an HSRP-
enabled interface is first brought up, for instance when the no shutdown command is issued.
The purpose of the listen state is to determine if there are any active or standby routers already present in
the group. In the speak state, the routers are actively participating in the election of the active router,
standby router or both.
Each router uses three timers for the HSRP hello messages. When a timer expires, the router transitions to a
new HSRP state.
In the example in the figure, Router A starts. As it is the first router in the subnet that is configured for
standby group 1, it transits through the listen and speak states, and then becomes the active router. Router B
starts after router A. While Router B is in the listen state, Router A is already assuming the standby and then
the active role. As there is an active router already present, Router B assumes the standby role.
When two routers participate in an election process, a priority can be configured to determine which router
should become active. Without specific priority configuration, each router has a default priority of 100, and
the router with the highest IP address is elected as the active router.
Regardless of other router priorities or IP addresses, an active router will stay active by default. A new
election will occur only if the active router is removed. When the standby router is removed, a new election
is made to replace the standby router. You can change this default behavior with the preempt option.
HSRP and STP
STP is running between the Layer 3 and Layer 2 switches. In a redundant spanning-tree topology, some
links are blocked. The spanning-tree topology has no awareness of the HSRP configuration. There is no
automatic relationship between the HSRP active router election process and the spanning-tree root bridge
election process.
Take a look at the figure. VLAN traffic destined for the core is sent to SW1, as it is a STP root bridge and
the other links are blocked by the STP. However, SW2 is an active HSRP gateway, so traffic needs to be
forwarded to SW2 before being routed to the core network. Traffic path is thus suboptimal, with traffic
passing more devices than needed.
It is a good practice, to configure the same Layer 3 switch to be both the spanning-tree root and the HSRP
active router for a single VLAN. This approach ensures that the Layer 2 forwarding path leads directly to
the Layer 3 device that is the HSRP active gateway, thus achieving maximum efficiency.
Load Sharing With HSRP
HSRP does not support load sharing as part of the protocol specification. However, load sharing can be
achieved through configuration of MHSRP.
In the figure, two HSRP-enabled Layer 2 switches participate in two separate VLANs, using IEEE 802.1Q
trunks. By leaving the default HSRP priority values, a single Layer 2 switch will likely become an active
gateway for both VLANs, effectively utilizing only one uplink towards the core of the network.
In order to utilize both paths towards the core network, you can configure HSRP with MHSRP. Group 10 is
configured for VLAN 10. Group 20 is configured for VLAN 20. For group 10, Switch1 is configured with
higher priority to become the active gateway and Switch2 becomes the standby gateway. For group 20,
Switch2 is configured with higher priority to become the active gateway and Switch1 becomes the standby
router. Now both uplinks towards the core are utilized, one with VLAN 10 and one with VLAN 20 traffic.
Note MHSRP load sharing can also be configured in a flat network, that is when all end-devices
belong to the same VLAN. Two or more HSRP groups with different virtual IPs can be
configured per single interface, serving different clients in a single VLAN.
Switch1 has two HSRP groups configured for two VLANs and corresponding STP root configuration.
Switch1 is the active router for HSRP group 10 and the standby router for group 20.
Switch2 has two HSRP groups configured for two VLANs and corresponding STP root configuration.
Switch2 is the active router for HSRP group 20 and standby router for group 10.
The Need For Interface Tracking With HSRP
HSRP has the ability to track interfaces or objects and decrement priority if interface or object fails.
When the conditions that are defined by the object are fulfilled, the router priority remains the same. As
soon as the verification that is defined by the object fails, the router priority is decremented. The amount of
decrease can be configured. Default value is 10.
HSRP Interface Tracking
HSRP has a built-in mechanism for detecting link failures and starting the HSRP re-election process.
R1 and R2 are configured with HSRP. R2 is configured to be the active default gateway and R1 will take
over if R2 or R2's HSRP-enabled interface fails.
What happens if the R2's uplink fails? The uplink interface is not an HSRP-enabled interface, so it's failure
does not affect HSRP. R2 is still the active default gateway. All the traffic from PC1 to the server now has
to go through R2, then gets routed to R1, and forward to the server, resulting in an inefficient traffic path.
HSRP provides a solution to the presented problem—HSRP interface tracking. Interface tracking allows
you to specify another interface on the router for the HSRP process to monitor in order to alter the HSRP
priority for a given group. If the specified interface's line protocol goes down, the HSRP priority of this
router is reduced, allowing another HSRP router with higher priority to become active. Preemption must be
enabled.
Let's look at the same scenario as before. R2's uplink interface fails, but this time HSRP, by virtue of HSRP
interface tracking, detects this failure and R2's HSRP priority is decreased by 20. With preemption enabled,
R1 will then take over as the active HSRP peer, as it has a higher priority.
Traffic path is now optimal. Traffic from PC1 to the server goes directly through R1.
HSRP Tracking Configuration Arguments
Variable Description
group-number (Optional) Indicates the group number on the interface to w hich the tracking applies. The default
number is 0.
type Indicates the interface type (combined w ith the interface number) that w ill be tracked.
number Indicates the interface number (combined w ith the interface type) that w ill be tracked.
interface-priority (Optional) Indicates the amount by w hich the hot standby priority for the router is decremented
w hen the interface becomes disabled. The priority of the router is incremented by this amount
w hen the interface becomes available. The default value is 10.
To disable interface tracking, enter the no standby group track command.

The command to configure HSRP tracking on a multilayer switch is the same as on the external router,
except that the interface type can be identified as a switch virtual interface (vlan followed by the vlan
number that is assigned to that interface) or by a physical interface.
The internal routing device uses the same command as the external routing device to disable interface
tracking.
You can apply multiple tracking statements to an interface. This may be useful if, for example, the currently
active HSRP interface will relinquish its status only upon the failure of two (or more) tracked interfaces.
Use the show track track_number command to verify the state of the tracked interface.
You can use the show standby command to verify that tracking is configured.
HSRP and Object Tracking
R1 and R2 are configured with HSRP. R2 is configured to be the active default gateway and R1 will take
over if R2 or R2's HSRP-enabled interface fails. HSRP-native interface tracking mechanism can concede
elections if R1's or R2's uplink interface fails, provided we also configured preemption.
Let's look at the switch between R3 and R2. What happens if switch's R3-facing interface fails? In this case,
if R2 has a statically configured default route pointing upwards, it will not figure out that there was a change
in topology. Dynamic routing protocol will bypass the failure but at a cost of suboptimal traffic path. In both
cases, HSRP on R2 will not detect a change and R2 will still be the active router.
By utilizing HSRP-native interface tracking you can monitor the state of R2-SW1 link and trigger the re-
election process of the HSRP active router. But how can you tell R2 to trigger the election process if R3-
SW1 link is down? Here is where HSRP's ability to utilize object tracking and react to changes comes in
action.
R3 can only be reached from R2 if the link is operational. You can define an IP SLA reachability test on R2
and then create an object to track this IP SLA test. Tell the HSRP process to track the created object. When
R2 looses connectivity to R3's SW1-facing interface, HSRP priority of R2 will be decreased by a specified
amount. With preemption configured, R2 will lose its active status to R1. R1 will then be the active default
gateway for PC1.
Configure an IP SLA test that will track reachability of R3's SW1-facing interface first. Specify the
frequency of test execution. Do not forget that the test does not start unless scheduled.
After the IP SLA test is up and running, configure HSRP to track the IP SLA and decrement the priority if
the test fails. Default decrease is 10. You can specify any value between 0 and 255.
Verify tracking with the show standby command.
Tracked objects are defined in global configuration with the keyword track, followed by an object number.
You can track up to 500 objects.
Tracked objects offer a vast group of possibilities. A few options that are commonly available are:
• An interface: This performs a similar function like the HSRP interface tracking mechanism, but with
advanced features. This tracking object can not only verify the interface status (line protocol), but also
whether IP routing is enabled, whether an IP address is configured on the interface, and whether the
interface state is up before reporting to the tracking client that the interface is up.
• IP route: A tracked IP-route object is considered up and reachable when a routing-table entry exists for
the route and the route is accessible. To provide a common interface to tracking clients, route metric
values are normalized to the range of 0 to 255, where 0 is connected and 255 is inaccessible. You can
track route reachability, or even metric values, to determine best-paths values to the target network. The
tracking process uses a per-protocol configurable resolution value to convert the real metric to the
scaled metric. The metric value that is communicated to clients is always such that a lower metric value
is better than a higher metric value.
• IP SLA: This special case allows you to track advanced parameters such as IP reachability, delay, or
jitter.
• A list of objects: You can track several objects and interrelate their results to determine if one or
several of them should trigger the “success” or “fail” condition.
HSRP Authentication
HSRP authentication prevents rogue Layer 3 devices on the network from joining the HSRP group.
A rogue device may claim the active role and can prevent the hosts from communicating with the rest of the
network, creating a DoS attack. A rogue router could also forward all traffic and capture traffic from the
hosts, achieving a man-in-the-middle attack.
HSRP provides two types of authentication—plain-text and MD5.
To configure plain-text authentication use the following interface configuration command on HSRP peers:
Switch(config-if)# standby group authentication string
With plain-text authentication, a message that matches the key configured on a HSRP peer is accepted. A
maximum length of a key string is 8 characters. Clear text messages can easily be intercepted, so avoid
plain-text authentication if MD5-type authentication is available.
To configure MD5 authentication use the following interface configuration command on HSRP peers:
Switch(config-if)# standby group authentication md5 key-string [0 | 7] string
Using MD5 key, a hash is computed on a portion of each HSRP message. Hash is sent along with the HSRP
message. When a peer receives the message and a hash, it will perform hashing on the received message. If
the received hash and the newly-computed hash match, the message is accepted. It is very difficult to
reverse the hash value itself and hash keys itself are never exchanged. MD5 authentication is preferred.
By default, the key string is given as plain-text. After you enter the key-string, it will get encrypted and
stored into the running configuration. You can copy and paste an encrypted key string value into this
command by preceding the string with the 7 keyword. However, keep in mind this type of encryption is
weak.
Alternatively, you can define MD5 strings as keys on a key chain. This is a more flexible method since you
can define multiple keys with different validity times.
To configure MD5 authentication using key-chains use the following command sequence:
Switch(config)# key chain chain-name
Switch(config-keychain)# key key-number
Switch(config-keychain-key)# key-string [0 | 7] string
Switch(config-keychain-key)# exit
Switch(config)# interface interface slot/number
Switch(config-if)# standby group authentication md5 key-chain chain-name
HSRP Timers
A hello message contains the priority of the router, the hello time, and holdtime parameter values. The hello
timer parameter value indicates the interval between the hello messages that the router sends. The holdtime
parameter value indicates how long the current hello message is considered valid. The standby timer
includes an msec parameter to allow for subsecond failovers. Lowering the hello timer results in increased
traffic for hello messages and should be used cautiously.
If an active router sends a hello message, the receiving routers consider the hello message to be valid for
one hold time period. The hold time value should be at least three times the value of the hello time. The hold
time value must be greater than the value of the hello time.
You can adjust the HSRP timers to tune the performance of HSRP on distribution devices, thereby
increasing their resilience and reliability in routing packets off the local VLAN.
By default, HSRP hello time is 3 seconds and the hold time is 10 seconds, which means that the failover
time could be as much as 10 seconds for clients to start communicating with the new default gateway. In
some cases, this interval may be excessive for application support. The hello time and the hold time
parameters are configurable. To configure the time between the hello messages and the time before other
group routers declare the active or standby router to be nonfunctioning, enter this command in the interface
configuration mode:
Switch(config-if)# standby group-number timers [msec] hellotime [msec] holdtime
The hello interval is specified in seconds unless the msec keyword is used. This is an integer from 1 through
255. The default is 3 seconds. The dead interval, also specified in seconds, is a time before the active or
standby router is declared to be down. This is an integer from 1 through 255, unless the msec keyword is
used. The default is 10 seconds.
The hello and the dead timer intervals must be identical for all the devices within the HSRP group.
To reinstate the default standby-timer values, enter the no standby group timers command.
Ideally, to achieve fast convergence, these timers should be configured to be as low as possible. Within
milliseconds after the active router fails, the standby router can detect the failure, expire the holdtime
interval, and assume the active role.
Note Decreasing the HSRP timers will allow you to detect a first hop failure faster. However,
shorter HSRP timers mean more HSRP hello packets, which in turn means more overhead
traffic.
Nevertheless, timer configuration should also take into account other parameters relevant to the network
convergence. For example, both HSRP routers may be running a dynamic routing protocol. The routing
protocol probably has no awareness of the HSRP configuration, and sees both routers as individual hops
toward other subnets. If HSRP failover occurs before the dynamic routing protocol converges, suboptimal
routing information may still exist. In a worst-case scenario, the dynamic routing protocol continues seeing
the failed router as the best next hop to other networks, and packets are lost. When configuring HSRP
timers, make sure that they harmoniously match the other timers that can influence which path is chosen to
carry packets in your network.
Preemption is an important feature of HSRP that allows the primary router to resume the active role when
it comes back online after a failure or a maintenance event. Preemption is a desired behavior as it forces a
predictable routing path for the VLAN traffic during normal operations. It also ensures that the Layer 3
forwarding path for a VLAN parallels the Layer 2 STP forwarding path whenever possible.
When a preempting device is rebooted, HSRP preemption communication should not begin until the
distribution switch has established full connectivity to the rest of the network. This situation allows the
routing protocol convergence to occur more quickly, after the preferred router is in an active state.
To accomplish this, measure the system boot time and set the HSRP preemption delay to a value that is
about 50 percent greater than device's boot time. This value ensures that the primary distribution switch
establishes full connectivity to the network before the HSRP communication occurs.
HSRP Versions
There are two HSRP versions available on most Cisco routers and Layer 3 switches: HSRPv1 and HSRPv2.
Version 1 is a default version on Cisco IOS devices. HSRPv2 is supported in Cisco IOS Release 12.2(46)SE
and later. HSRPv2 allows group numbers up to 4095, thus allowing you to use VLAN number as the group
number.
HSRP version 2 must be enabled on an interface before HSRP IPv6 can be configured.
HSRP version 2 will not interoperate with HSRP version 1. All devices in an HSRP group must have the
same version configured, otherwise, the hello messages are not understood. An interface cannot operate
both version 1 and version 2 as they are mutually exclusive.
The MAC address of the virtual router and the multicast address for the hello messages is different with
version 2. HSRPv2 uses the new IP multicast address 224.0.0.102 to send the hello packets instead of the
multicast address of 224.0.0.2, which is used by version 1. This new address allows Cisco Group Multicast
Protocol processing to be enabled at the same time as HSRP.
HSRPv2 has a different packet format. It includes a 6-byte identifier field that is used to uniquely identify
the sender of the message by its interface MAC address, making troubleshooting easier.
Summary
References
• HSRP Features and Functionality: http://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-
protocol-hsrp/9234-hsrpguidetoc.html
3 Redundancy with VRRP
Overview
The VRRP is a first hop redundancy protocol and serves as a standard-based alternative to Cisco-proprietary
HSRP.

• Describe the idea behind VRRP
• Configure and verify VRRP
• Describe the differences between HSRP and VRRP
• Describe tracking options with VRRP
• Configure VRRP interface object tracking
About VRRP
VRRP is an open standard alternative to HSRP.
VRRP is very similar to HSRP, both in operation and configuration. The VRRP Master is analogous to the
HSRP active gateway, while the VRRP Backup is analogous to the HSRP standby gateway. A VRRP group
has one Master device and one or multiple Backup devices. A device with the highest priority is the elected
Master. Priority can be a number between 0 and 255. Priority value 0 has a special meaning—it indicates,
that the current Master has stopped participating in VRRP. This setting is used to trigger Backup devices to
quickly transition to Master without having to wait for the current Master to time out.
VRRP differs from HSRP in that it allows you to use an address of one of the physical VRRP group
members as a virtual IP address. In this case, the device with the used physical address is a VRRP Master
whenever it is available.
The Master is the only device that sends advertisements (analogous to HSRP hellos). Advertisements are
sent to the 224.0.0.18 multicast address, protocol number 112. The default advertisement interval is 1
second. The default hold time is 3 seconds. HSRP, in comparison, has the default hello timer set to 3
seconds and the hold timer to 10 seconds.
Although the VRRP protocol as per RFC 3768 does not support millisecond timers, Cisco devices allow
you to configure millisecond timers. You need to manually configure the millisecond timer values on both
the Master and the Backup devices. Use the millisecond timers only where absolutely necessary and with
careful consideration and testing. Millisecond values work only under favorable circumstances, and you
must be aware that the use of the millisecond timer values restricts VRRP operation to Cisco devices only.
Note When using millisecond values, the Master advertisement value that is displayed by the
show vrrp command output on the Backup routers is always 1 second, even though the
actual value may differ.
In the example, Layer 3 switches A, B, and C are configured as VRRP virtual routers and are members of
the same VRRP group. Since Switch A has the highest priority, it is elected as the Master for this VRRP
group—end-user devices will use it as their default gateway. Layer 3 switches B and C function as virtual
router Backups. If the Master fails, the device with the highest configured priority will become the Master
and provide uninterrupted service for the LAN hosts. When Switch A recovers and the preemption is
enabled, Switch A becomes the Master again. Contrary to HSRP, preemption is enabled by default with
VRRP.
Like with HSRP, load sharing is also available with VRRP. Multiple virtual router groups can be
configured. For instance, you could configure clients 3 and 4 to use a different default gateway as clients 1
and 2. Then you would configure the three Layer 3 switches with another VRRP group and designate
Switch B to be the Master VRRP device for the second group.
Discovery 15: Configure VRRP and Spot the
Differences from HSRP
Overview
In this discovery, you will learn how to configure VRRP and the differences between VRRP and HSRP.
Topology
Job Aids
IP Addressing
Configure VRRP and Spot the Differences from HSRP

Step 1 Configure R1's Ethernet 0/1 with IP address 192.168.1.3 and VRRP virtual IP address
192.168.1.1.

R1(config-if)# vrrp 1 ip 192.168.1.1
Like HSRP, VRRP uses the concept of virtual IP address to provide the end-user devices with
redundant first-hop connectivity. The virtual IP address is configured using the vrrp
group_number ip virtual_ip interface configuration command.
You can use one of the "real" IP addresses from physical routers as the virtual IP address. In this
example you could for instance use 192.168.1.3 as the virtual IP address.
Step 2 Configure R2's Ethernet 0/1 with IP address of 192.168.1.2 and VRRP virtual IP address of
192.168.1.1.
R2(config-if)# vrrp 1 ip 192.168.1.1
With HSRP, you could leave out the group number when performing the configuration and it
will default to group 0. With VRRP there is no such default. You need to specify a group number
which can be anything between 1 and 255.
Step 3 Configure R2's Ethernet 0/1 with VRRP priority of 110.
R2(config-if)# vrrp 1 priority 110
In the routers' CLIs, notice that one of the devices transitioned to Master state and the other to
Backup state.
Higher priority is configured on a device that should be the Master of the VRRP group. In this
example you configured R2 with priority of 110. R1 is left with default priority of 100.
However, if you use one of the router's IP addresses as the virtual IP address, priorities are
ignored for the purpose of electing the Master. The router that has the IP address that matches
the virtual IP address will become the Master.
VRRP has preemption enabled by default. HSRP has preemption disabled by default.
Step 4 On VRRP-enabled devices, verify the VRRP status.
R1# show vrrp

State is Backup
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Master Router is 192.168.1.2, priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec (expires in 3.049 sec)
In the output of R1, you can see the MAC address of the virtual router. The MAC address has
the following form: 0000.5e00.01XX, where XX is the two-digit hexadecimal group number.
R2# show vrrp brief

Interface Grp Pri Time Own Pre State Master addr Group addr
Et0/1 1 110 3570 Y Master 192.168.1.2 192.168.1.1
To verify VRRP status, use show vrrp. If you append the brief keyword, you will get a more
condensed view.
VRRP and Authentication
The VRRP standard used to specify plain text and MD5 authentication, which was later revoked. However,
Cisco IOS devices still support authentication mechanisms.
According to RFC 5798, operational experience and further analysis determined that VRRP authentication
did not provide sufficient security to overcome the vulnerability of misconfigured secrets, causing multiple
Masters to be elected. Due to the nature of the VRRP protocol, even if VRRP messages are
cryptographically protected, it does not prevent hostile nodes from behaving as if they are the VRRP
Master, creating multiple Masters. Authentication of VRRP messages could have prevented a hostile node
from causing all properly functioning routers from going into Backup state. However, having multiple
Masters can cause as much disruption as no routers, which authentication cannot prevent. Also, even if a
hostile node could not disrupt VRRP, it can disrupt ARP and create the same effect as having all routers go
in Backup state.
Independent of any authentication type, VRRP includes a mechanism (setting TTL = 255, checking on
receipt) that protects against VRRP packets being injected from another remote network. This limits most
vulnerabilities to local attacks.
With Cisco IOS devices, the default VRRP authentication is plain text. MD5 authentication can be
configured by specifying a key string or, like with HSRP, reference a key-chain.
Step 5 Configure MD5 authentication for VRRP on R1's Ethernet 0/1 interface.

R1(config-if)# vrrp 1 authentication md5 key-string MyVRRP
In the CLI output of R1, notice the "bad authentication" message. R1 is currently configured
with the MD5 authentication while R2 has no VRRP authentication configured. As a
consequence, routers do not consider each other as members of the same group. If you verify
VRRP status on both devices, you will see that both consider themselves the Master for VRRP
group 1.
%VRRP-4-BADAUTHTYPE: Bad authentication from 192.168.1.2, group 1, type 0,

expected 254.
Step 6 Configure MD5 authentication for VRRP on R2's Ethernet 0/1 interface.

R2(config-if)# vrrp 1 authentication md5 key-string MyVRRP
Notice that now that you have configured matching MD5 VRRP authentications, you got a
message in CLI of R1 saying that it is transitioning to Backup.
%VRRP-6-STATECHANGE: Et0/1 Grp 1 state Master -> Backup
Tracking and VRRP
Without configured tracking, the VRRP Master will only lose its status if a VRRP enabled interface fails or
the VRRP router itself fails.
While VRRP does not have a native interface tracking mechanism, it does have the ability to track objects.
Object tracking is an independent process that manages creating, monitoring, and removing tracked objects,
such as the state of the line protocol of an interface. Clients such as HSRP or VRRP register their interest
with specific tracked objects and act when the state of an object changes. Each tracked object is identified
by a unique number that is specified on the tracking CLI. Client processes such as VRRP use this number to
track a specific object. The tracking process periodically polls the tracked objects and notes any change of
value. The changes in the tracked object are communicated to interested client processes, either immediately
or after a specified delay. The object values are reported as either up or down. The priority of a device can
change dynamically if it has been configured for object tracking and the object that is being tracked goes
down.
Examples of objects that can be tracked are the line protocol state of an interface or the reachability of an IP
route. If the specified object goes down, the VRRP priority is reduced. The VRRP router with the higher
priority can now become the virtual router Master if it has the preemption enabled.
Objects that can be tracked depend on the IOS version and platform that you are using. Some common
objects are interfaces, IP SLA, and IP routes.
VRRP Interface Tracking Configuration
In the example topology, R2 is currently the VRRP Master, and R1 is Backup.

If R2's uplink fails, it will not lose its master status. PC1 will not lose connectivity to the server, provided
that routing is properly configured. However the path between PC1 and server will be suboptimal. Traffic
from PC1 will first go to R2 as default gateway, only to be rerouted to R1 and only then to the server.
With HSRP, the solution to this problem was the implementation of HSRP interface tracking or
implementation of object tracking. With VRRP, only the later is possible, as it does not have a native
interface tracking mechanism.
In the example, tracked object 1 is created that observes line protocol status of R2's Ethernet 0/0. VRRP
group 1 is told to track that object and decrease router's VRRP priority by 20 should the uplink fail. As with
HSRP, the default priority decrement is 10.
Summary
References
• Configuring VRRP: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/12-
4/fhp-12-4-book/fhp-vrrp.html
3 Redundancy with GLBP
Overview
GLBP, similarly to HSRP and VRRP, provides automatic router backup for IP hosts configured with a
single default gateway on the LAN. Multiple first-hop routers on the LAN are combined to offer a single
virtual first-hop IP address while sharing the IP packet forwarding load. Other routers on the LAN may act
as redundant GLBP routers that will become active if any of the existing forwarding routers fail. So the
major difference between HSRP/VRRP and GLBP, is that with the latter all GLBP routers forward traffic
by default.

• Describe basic idea behind GLBP
• Compare GLBP to HSRP
• Describe the possible states of GLBP virtual gateway and virtual forwarder
• Configure and verify GLBP
• List and describe GLBP load balancing options
• Secure GLBP using authentication
• Describe GLBP behavior in VLANs with running STP
• Describe the system of weights and decrements in GLBP
Introducing GLBP
GLBP shares some concepts with VRRP and HSRP, but the terminology is different, and its behavior is
more dynamic and robust.
Although HSRP and VRRP provide gateway resiliency with redundant members of the FHRP group, the
redundant member upstream bandwidth is not used while the device is not active. Only the active router
within the group forwards the traffic for the virtual MAC. You can accomplish load sharing with HSRP by
manually specifying multiple groups and assigning multiple default gateways. That, however, introduces
overhead in the form of additional configuration as well as supporting services, such as DHCP.
Additionally, due to manual assignment of the default gateway to the end hosts, load sharing is rarely
equally balanced among all participating gateways.
GLBP is a Cisco proprietary solution that allows for automatic selection and simultaneous use of multiple
available gateways in addition to automatic failover between those gateways. Multiple routers share the load
of packets that, from a client's perspective, are sent to a single default gateway address.
With GLBP, you can fully utilize resources without the administrative burden of configuring multiple
groups and managing multiple default gateway configurations, as is required with HSRP and VRRP. You
do not need to configure a specific gateway address on an individual host. All hosts can use the same default
gateway.
GLBP divides a function that is performed by the HSRP and VRRP routers into two roles—that of a
gateway and that of a forwarder.
GLBP AVG: Members of a GLBP group elect one gateway to be the AVG for that group. Other group
members provide a backup for the AVG when the AVG becomes unavailable—these will be in standby
state.
The AVG assigns a virtual MAC address to each member of the GLBP group. The AVG listens to the ARP
requests for the default gateway IP and replies with a MAC address of one of the GLBP group members,
thus load sharing traffic among all the group members.
GLBP AVF: Each gateway assumes responsibility for forwarding packets that are sent to the virtual MAC
address that is assigned to that gateway by the AVG. These gateways are known as AVFs. There can be up
to four forwarders within a GLBP group. All other devices will be secondary forwarders—serving as
backup if the current AVF fails. Forwarders that are forwarding traffic for a specific virtual MAC are in the
active state and are called AVFs. Forwarders that are serving as backups are in the listen state.
GLBP vs. HSRP
HSRP and GLBP are Cisco proprietary protocols. VRRP is an industry-standard protocol.
With HSRP, one virtual router is active and one is serving as a backup in standby mode and not forwarding
traffic. GLBP has two different roles, gateway and forwarder, each with it's own states. Virtual gateway
shares it's states with HSRP - there is one active and one standby virtual gateway, all other gateways are in
the listen state. Per GLBP group there can be up to 4 active forwarders (1 per virtual MAC), all others are in
the listen state.
GLBP members communicate with each other through hello messages that are sent by default every 3
seconds to the multicast address 224.0.0.102, UDP port 3222 (source and destination).
The routers participating in GLBP, monitor each other's presence in order to assume the role of AVG if it
fails. Monitoring is done by exchanging hello messages. These are, like with HSRP, by default sent every 3
seconds. If hello messages are not received from a GLBP peer within a "hold time", that peer is presumed to
have failed. The default hold time is 10 seconds. The GLBP timers can be adjusted with the glbp group
timers [msec] hellotime [msec] holdtime command. Timer values are given in seconds unless preceded by
the msec keyword. Timer values only need to be configured on the AVG. AVG will then propagate settings
to all other GLBP-enabled devices within the group. You should always make the hold time at least three
times longer then the hello time. This will give some tolerance to the delayed or the missed hellos.
GLBP, using concepts of virtual gateway and virtual forwarder, separates the functions of protocol and
traffic forwarding. Each AVF has a MAC address that is assigned to it by the AVG. With HSRP there is
only one MAC address per each HSRP group.
GLBP does not have a native interface tracking mechanism like HSRP. Like VRRP, you can only configure
object tracking. Since interface tracking is one of the options within object tracking, native interface
tracking is not really missed!
Both GLBP and HSRP support two types of authentication: plain-text and MD5. Out of the two, MD5 is
recommended to secure GLBP group from unauthorized devices joining.
GLBP States
GLBP states of Virtual Gateway and Virtual Forwarder are slightly different.
Possible Virtual Gateway states:

• Disabled: Virtual IP address has not been configured or learned, but there is some GLBP configuration.
• Initial: Virtual IP address has been configured or learned, however configuration is not complete.
Interface must be operational on Layer 3 and configured to route IP.
• Listen: Virtual gateway is receiving hello packets. It is ready to change to speak state if the active or
standby virtual gateway becomes unavailable.
• Speak: Virtual gateway is trying to become the active or standby virtual gateway.
• Standby: This gateway is next in line to be the active virtual gateway.
• Active: This gateway is the AVG, and is responsible for responding to ARP requests for the virtual IP
address.
Possible Virtual Forwarder states:

• Disabled: Virtual MAC address has not been assigned or learned. Disabled virtual forwarder will be
deleted shortly. This state is transitory only.
• Initial: Virtual MAC address is known but configuration of virtual forwarder is not complete. Interface
must be operational on Layer 3 and configured to route IP.
• Listen: This virtual forwarder is receiving hello packets and is ready to change to the active state if the
active virtual forwarder becomes unavailable.
• Active: This gateway is the AVF, and is responsible for forwarding packets sent to the virtual
forwarder's MAC address.
Discovery 16: Configure GLBP
Overview
In this discovery you will learn how GLBP works, how to configure, and verify it.
Topology
Job Aids
IP Addressing
Configuring Layer 3 Redundancy with GLBP

Step 1 Configure R1's Ethernet 0/1 with IP address of 192.168.1.3 and GLBP virtual IP address of
192.168.1.1.

R1(config-if)# glbp 1 ip 192.168.1.1
The basic configuration of GLBP is very similar to those of HSRP and VRRP. To configure a
GLBP group, use glbp group_number ip virtual_ip_address command, where the GLBP group
is a number between 0 and 1023.
Step 2 Configure R2's Ethernet 0/1 with IP address of 192.168.1.2 and GLBP virtual IP address of
192.168.1.1.

R2(config-if)# glbp 1 ip 192.168.1.1
With GLBP you do not actually need to specify the virtual IP address on non-AVG routers. You
can leave it empty and the device will learn the virtual IP address from the AVG.
PC1, PC2, and PC3 are already configured to use the 192.168.1.1 IP address as their default
gateway. At this point you should have a functional first-hop redundancy already working.
However, there is much more that you can do with GLBP in order to fine-tune its behavior.
Step 3 Configure R1's Ethernet 0/1 with GLBP priority of 110 and enable preemption for both GLBP
routers.

R1(config-if)# glbp 1 priority 110
R1(config-if)# glbp 1 preempt

R2(config-if)# glbp 1 preempt
GLBP priority is a number between 1 and 255. The default value is 100. The GLBP-enabled
device with the highest priority value is elected the AVG. If priorities of all routers are tied, then
the device with the highest IP address becomes the AVG.
Like with HSRP, but unlike with VRRP, GLBP has preemption disabled by default. So, by
default, another router cannot take over an active role until the current active router fails. You
need to explicitly enable this feature.
Step 4 On R1 verify status of GLBP.
R1# show glbp
State is Active
1 state change, last state change 00:15:11
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption enabled, min delay 0 sec
Active is local
Standby is 192.168.1.2, priority 100 (expires in 9.184 sec)
Priority 110 (configured)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
aabb.cc00.3510 (192.168.1.3) local
aabb.cc00.3610 (192.168.1.2)
There are 2 forwarders (1 active)
Forwarder 1
State is Active
MAC address is 0007.b400.0101 (default)
Owner ID is aabb.cc00.0910
Redirection enabled
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is aabb.cc00.0a10
Redirection enabled, 599.200 sec remaining (maximum 600 sec)
Time to live: 14399.200 sec (maximum 14400 sec)
Active is 192.168.1.2 (primary), weighting 100 (expires in 11.072 sec)
The first part of the output refers to the status of the VG. You can see that GLBP group 1 is
configured under R1's Ethernet 0/1. You can see that R1 has the role of the AVG for group 1.
The virtual router IP address is 192.168.1.1 and preemption is enabled. R1 sees a standby router
at 192.168.1.2 (on R2). In case that R1 fails, R2 will assume the role of AVG of the GLBP
group. The priority of virtual router on R1 is 110.
The rest of the output shows the status of virtual forwarders. In this example, there are two
forwarders (1 and 2), that the AVG (R1) assigns virtual MAC addresses to them.
Step 5 On R2 verify the status of GLBP.
R2# show glbp
State is Standby
Virtual IP address is 192.168.1.1 (learnt)
Redirect time 600 sec, forwarder timeout 14400 sec
Active is 192.168.1.3, priority 110 (expires in 9.312 sec)
Standby is local
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
aabb.cc00.3510 (192.168.1.3)
aabb.cc00.3610 (192.168.1.2) local
There are 2 forwarders (1 active)
Forwarder 1
State is Listen
MAC address is 0007.b400.0101 (learnt)
Owner ID is aabb.cc00.0910
Time to live: 14398.560 sec (maximum 14400 sec)
Active is 192.168.1.3 (primary), weighting 100 (expires in 9.376 sec)
Forwarder 2
State is Active
MAC address is 0007.b400.0102 (default)
Owner ID is aabb.cc00.0a10
Active is local, weighting 100
The virtual MAC addresses of GLBP are in the form of 0007.b4XX.XXYY. XXXX is a 16-bit
value that represents six zero bits, followed by a 10-bit GLBP group number. YY is an 8-bit
value and it represents the virtual forwarder number. The AVG assigned forwarder 1 virtual
MAC address of 0007.b400.0101 and forwarder 2 virtual MAC address of 0007.b400.0102.
Notice that R2's virtual router is in active state for forwarder 2. This means it is actively
forwarding traffic for clients that send traffic to the MAC address of forwarder 2. R2 is in listen
state for forwarder 1. This means that R1's virtual router is the one forwarding traffic from
clients that send traffic to the MAC address of forwarder 1. R2 with its forwarder 1 listen state, is
serving as backup.
Step 6 From PC1, trace the path that packets take to the server at 192.168.4.22 and then verify PC1's
ARP table.

1 192.168.1.3 1 msec 1 msec 0 msec
2 192.168.2.2 2 msec 1 msec 0 msec
3 192.168.4.22 0 msec 0 msec *
PC1# show arp
Internet 192.168.1.1 5 0007.b400.0101 ARPA Ethernet0/0
Internet 192.168.1.100 - aabb.cc00.0200 ARPA Ethernet0/0
You can see from the output that PC1 has it's default gateway configured to 192.168.1.1 and that
the MAC address it associates with this IP is that of the device that is active for VF1. Since R1 is
the AVF 1, PC1's traffic goes through R1.
ARP table.

1 192.168.1.2 0 msec 0 msec 1 msec
2 192.168.3.2 0 msec 0 msec 0 msec
3 192.168.4.22 0 msec 1 msec *
PC2# show arp
ARP table.

1 192.168.1.3 1005 msec 0 msec 0 msec
2 192.168.2.2 0 msec 1 msec 0 msec
3 192.168.4.22 1 msec 1 msec *
PC3# show arp
GLBP Operation Explained
After GLBP group is established all PCs will send ARP requests. ARP request is a broadcast.
The AVG, in this instance a role assigned to R1, responds to ARP requests by using configured load-
balancing method. By default, load balancing method is round-robin. Thus, PC1 received ARP
0007.b400.0101, PC2 received ARP 0007.b400.0102, and PC3 received ARP 0007.b400.0101. MAC
address 0007.b400.0101 is a virtual MAC address of the AVF 1 and 0007.b400.0102 is a virtual MAC
address of the AVF 2.
So, even though all PCs have the same configured default gateway, devices will send data to different first-
hops. PC1 and PC3 will send data to the AVF 1—in this case R1. PC2 will send data to AVF 2—in this case
R2.
Step 9 On R1, shut down Ethernet 0/0 and Ethernet 0/1.
R1(config)# interface range ethernet 0/0, ethernet 0/1

R1(config-if-range)# shutdown
By doing this, you simulated a failure of R1. R1 was up until now AVG and AVF 1. What
happens now?
Step 10 On R2, investigate GLBP status.
R2# show glbp brief

Interface Grp Fwd Pri State Address Active router Standby router
Et0/1 1 - 100 Active 192.168.1.1 local unknown
Et0/1 1 1 - Active 0007.b400.0101 local -
Et0/1 1 2 - Active 0007.b400.0102 local -
Notice that R2 is now the AVG for group 1. Since R2 is the only functional GLBP-enabled
device of group 1, it is also elected to be AVF 1 and AVF 2. R2 will now forward traffic for all
clients—PC1, PC2, and PC3.
Although the virtual router at this moment has two different virtual MAC addresses to support
function for two AVFs, it does not make sense to keep them both for a longer time period. AVG
maintains two different timers for this purpose. The redirect, timer is used to determine when the
AVG will stop using the old virtual MAC address in ARP replies. The AVF that uses old virtual
MAC continues to act as a gateway for any client that tries to use it. When the timeout timer
expires, the old MAC of the virtual router and the virtual forwarder are flushed from all GLBP
peers. AVG assumes that old AVF will not return to service, so the resource (virtual MAC
address) is reclaimed. Clients using an old MAC address must refresh the entry to obtain a new
virtual MAC address. By default, the redirect timer is 10 minutes and the timeout timer is 4
hours.
GLBP Load Balancing Options
The AVG within the GLBP group is the one that ensures that traffic will be load-balanced between the end-
devices and their first hop. AVG hands out virtual MAC addresses to clients in a deterministic fashion. Each
virtual MAC address belongs to one AVF and is assigned to AVF by the AVG. Up to four MAC addresses,
that is four AVFs, can be used in a GLBP group.
GLBP supports these operational modes for load balancing traffic across multiple default routers that are
servicing the same default gateway IP address:
• Weighted load-balancing algorithm: The amount of load that is directed to a router is dependent upon
the weighting value that is advertised by that router.
• Host-dependent load-balancing algorithm: A host is guaranteed the use of the same virtual MAC
address as long as that virtual MAC address is participating in the GLBP group.
• Round-robin load-balancing algorithm: As clients send ARP requests to resolve the MAC address of
the default gateway, the reply to each client contains the MAC address of the next possible router in a
round-robin fashion. The MAC addresses of all routers take turns being included in address resolution
replies for the default gateway IP address.
GLBP automatically manages the virtual MAC address assignment, determines who handles the forwarding,
and ensures that each station has a forwarding path in the event of failures to gateways or tracked interfaces.
If failures occur, the load-balancing ratio is adjusted among the remaining AVFs so that resources are used
in the most efficient way.
GLBP Authentication
MD5 authentication provides greater security than the alternative plain text authentication scheme and
protects against spoofing software. MD5 authentication allows each GLBP group member to use a secret
key to generate a keyed MD5 hash that is part of the outgoing packet. A keyed hash of an incoming packet
is generated and if the hash within the incoming packet does not match the generated hash the packet is
ignored.
The key for the MD5 hash can either be given directly in the configuration using a key string, or supplied
indirectly through a key chain. The key string cannot exceed 100 characters in length.
GLBP packets will be rejected in any of the following cases:

• The authentication schemes differ on the router and in the incoming packet.
• MD5 digests differ on the router and in the incoming packet.
• Text authentication strings differ on the router and in the incoming packet.
When configuring GLBP MD5 authentication using a key string use the glbp group-number authentication
md5 key-string [ 0 | 7 ] key interface configuration command. No prefix to the key argument, or specifying
0, means that the key is not encrypted. Specifying 7 means that the key is encrypted. The key-string
authentication key will automatically be encrypted if the service password-encryption global configuration
command is enabled.
GLBP and STP
With some switching topologies, the operation of STP results in inefficient traffic paths. In such cases
implementation of HSRP might be preferred over GLBP as it is easier to understand, while GLBP provides
no advantages.
Topologies with layer 2 loops—such as the one on the figure, where distribution Layer 3 switches are
interconnected—run STP, which blocks some of the access-distribution links. The end hosts now only have
a direct connection with SW1. With GLBP configured, SW1 serves as a AVF for some of the end hosts,
routing traffic towards the core, while the other half of the traffic is forwarded to SW2, which serves as the
other AVF. While distribution-core links are now load balanced, half of the traffic is taking a suboptimal
route, passing through both SW1 and SW2, before being routed to the core.
In environments with STP and multiple VLANs, GLBP's load sharing might not be of value, and the
configuration of a multi group HSRP aligned with STP topology may be preferred.
Tracking and GLBP
Changing weight affects the AVF election and the load balancing algorithm. Both values can be
manipulated with object tracking.
In the example, GLBP gateway S1 is the AVG of GLBP group. This means S1 is the one that assigns MAC
addresses to AVFs of the group and it is also the one that answers to ARP replies of clients. Both gateways,
S1 and S2, are AVFs. S1 is an active forwarder 1 and S2 is an active forwarder 2. All PCs are configured
with the same virtual IP address for it's default gateway. The AVG will assign virtual MAC addresses to the
PCs through ARP replies. About half of PCs will have virtual MAC address of AVF1 (these PCs will have
traffic forwarded through S1) and the other half will have virtual MAC address of AVF2 (these PCs will
have traffic forwarded through S2).
GLBP uses a weighting scheme to determine the forwarding capacity of each router in the GLBP group.
The weighting that is assigned to a router in the GLBP group can be used to determine whether it will
forward packets and, if so, the proportion of hosts in the LAN for which it will forward packets. Thresholds
can be set to disable forwarding when the weighting for a GLBP group falls below a certain value, and
when it rises above another threshold, forwarding is automatically re-enabled.
The GLBP group weighting can be automatically adjusted by tracking the state of an interface within the
router. If a tracked interface goes down, the GLBP group weighting is reduced by a specified value.
Different interfaces can be tracked to decrement the GLBP weighting by varying amounts.
By default, the GLBP virtual forwarder preemptive scheme is enabled with a delay of 30 seconds. A backup
virtual forwarder can become the AVF if the current AVF weighting falls below the low weighting
threshold for 30 seconds. You can disable the GLBP forwarder preemptive scheme using the no glbp
forwarder preempt command or change the delay using the glbp forwarder preempt delay minimum
command.
So, let's look at S1 for a moment. It has configured weighting of 110. If S1's Gi0/1 fails, it's weighting will
be lowered by 50 - to 60. At this point S1 is still the AVF1 since it's weight did not go under the lower
threshold of 20. If Gi0/2 also fails, weight of GLBP groups gets decreased to 10. Now S1's GLBP group has
weight under configured lower threshold and S1 loses its AVF1 role. S2 is now active for forwarders 1 and
2! All PCs will now use S2 to forward traffic.
When either of S1's uplinks comes back up, the weight of S1's virtual router gets incremented by 50. Since
weight went from 10 to 60, it breached configured high threshold of 50. This means S1 is eligible to become
AVF1 again!
Without interface traffic, should both S1's uplinks fail, S1 would still be AVF1 and all PCs with default
gateway MAC address of AVF1 would forward traffic through S1. With routing configured on the LAN
segment traffic would than be rerouted to S2, resulting in suboptimal path.
How does the weight value influence the traffic flows through S1 or S2? If load-balancing for the GLBP
group is configured as weighted, traffic distribution should look like this:
No. of active uplinks on S1 No. of active uplinks on S2 Traffic through S1
2 2 50% (110:110)
2 1 65% (110:60)
2 0 100% (S2 not eligible to forw ard)
1 2 35% (60:110)
1 1 50% (110:110)
0 0 0% (none eligible for forw arding)
Traffic percentage calculations in the table are approximations, based on assumption that all end devices
produce same amount of traffic. The more end devices in a GLBP group, the closer real traffic patterns get
to those numbers.
If load balancing is configured as round-robin, then, as long as both S1 and S2 are eligible to forward,
traffic will be about 50:50 between both first hops.
Note Configuring of tracking through "weighting" does not have an effect on the election of AVG.
S1, in this example, will be the AVG as long it has connectivity to S2. Since the only role of
AVG is to assign MAC addresses to AVFs and clients, uplink failures do not affect AVG's
performance.
To configure tracking, you will first need to configure a tracked object. The available tracking options
depend on the platform and the software version you are using. Some common examples are interface
status, IP SLA, and IP route.
The second part of configuration is to configure the weight of virtual router and it's lower and upper
thresholds.
The third part of configuration is to tell GLBP to track the object that you have configured. You can specify
a decrement value by which weight will get reduced. The default decrement is 10.
Summary
References
• GLBP configuration guide: http://www.cisco.com/c/en/us/td/docs/ios-
xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhp-glbp.html
Lesson 4: Configuring First
Hop Redundancy for IPv6
Overview
IPv6 natively provides first hop redundancy through it's router advertisement mechanism. However, this
mechanism might not be the best choice in all scenarios, so you will learn why and when the usage of first
hop redundancy protocols is a preferred solution. You will learn how the protocols you know from the IPv4
world (HSRP, VRRP, GLBP) behave and are configured in an IPv6 network.

• Describe how IPv6 native mechanism provides first hop redundancy
• Explain why and when FHRP implementation is needed in IPv6 environment
• Configure HSRP in IPv6 environment
• Configure GLBP in IPv6 environment
IPv6 Native First Hop Redundancy
IPv6 natively provides first hop redundancy through it's router advertisement mechanism.
IPv6 provides a new ICMP type 134 packet, which is known as Router Advertisement. Router
Advertisement messages are periodically advertised by all routers in a LAN. With Router Advertisement
messages, routers advertise their presence, but also provide connection settings to the hosts. Host will
forward traffic to the gateway, who's Router Advertisement message receives first.
If default gateway fails, a disruption in connectivity occurs. Eventually, the client will acknowledge the
failure and start forwarding traffic to the other router that is sending the Router Advertisements. However,
the downtime in such case can be up to 40 seconds.
Note Router Advertisement is part of the Neighbor Discovery Protocol suite.
Why FHRP in IPv6?
Since IPv6 has a native first hop redundancy solution, are first hop redundancy protocols still needed?
Relying on Router Advertisements is slow. Router Advertisement includes a lifetime that is measured in
whole seconds, which means that the shortest lifetime which can be advertised is one second. Achieving a
subsecond failover is thus not possible.
Other technologies, such as DHCPv6, might be used to provide connectivity settings to LAN hosts, partially
or completely ignoring Router Advertisement messages.
FHRP usage offers more features and control than IPv6 Router Advertisement messages – for example
preemption, timers, tracking.
Note HSRP, GLBP, and VRRP have support for IPv6, but not in all Cisco IOS versions. VRRP for
IPv6 is less frequently supported on Cisco devices.
HSRP for IPv6
HSRP version 2 must be enabled on an interface before HSRP IPv6 can be configured.
HSRP configuration in IPv6 environment does not require a specified IPv6 address (global or link-local).
With the autoconfig keyword a link-local address is generated from the link-local prefix, and a modified
EUI-64 format interface identifier is generated from the relevant HSRP virtual MAC address. A link-local
address is an IPv6 unicast address that can be automatically configured on any interface using the link-local
prefix FE80::/10 and the interface identifier in the modified EUI-64 format. Link-local addresses are used
in the stateless autoconfiguration process. Nodes on a local link can use link-local addresses to
communicate—the nodes do not need site-local or globally unique addresses to communicate.
The HSRP global IPv6 address feature allows users to configure multiple nonlink local addresses as virtual
addresses, and it allows for the storage and management of multiple global IPv6 virtual addresses in
addition to the existing primary link-local address. If an IPv6 address is used, it must include an IPv6 prefix
length. If a link-local address is used, it must not have a prefix.
An HSRP IPv6 group has a virtual MAC address that is derived from the HSRP group number and a virtual
IPv6 link-local address that is, by default, derived from the HSRP virtual MAC address. Periodic Router
Advertisements are sent for the HSRP virtual IPv6 link-local address when the HSRP group is active.
GLBP for IPv6
The configuration of GLBP for IPv6 environment is very similar to that in IPv4. The only major difference
is that when enabling GLBP you can either specify an IPv6 address or autoconfigure it using the autoconfig
keyword.
GLBP for IPv6 supports all features that are supported in GLBP for IPv4—timer tuning, gateway priority,
authentication, tracking, and so on.
Summary
References
• HSRP: Global IPv6 Address: http://www.cisco.com/c/en/us/td/docs/ios-
xml/ios/ipapp_fhrp/configuration/15-sy/fhp-15-sy-book/ip6-fhrp-hsrp-global.html
Overview
Check
1. Which command enables HSRP on a Cisco IOS device? (Source: Configuring Layer 3 Redundancy
With HSRP)
A. standby virtual ip 10.1.1.1
B. standby ip 10.1.1.1 group 1
C. hsrp 1 ip 10.1.1.1
D. standby 1 ip 10.1.1.1
2. Which HSRP group uses the MAC address 0000.0c07.ac01? (Source: Configuring Layer 3 Redundancy
With HSRP)
A. group 0
B. group 7
C. group 11
D. group 1
3. If you have four routers enabled for the same HSRP group, how many of them will be in "standby"
state? (Source: Configuring Layer 3 Redundancy With HSRP)
A. 0
B. 1
C. 2
D. all, except the active router.
4. Which VRRP group uses the MAC address 0000.5e00.01ff? (Source: Configuring Layer 3 Redundancy
With VRRP)
A. group 0
B. group 1
C. group 255
D. group 94
5. What is the primary difference between VRRP and HSRP? (Source: Configuring Layer 3 Redundancy
With VRRP)
A. HSRP is a standard protocol, while VRRP is Cisco proprietary.
B. VRRP is a standard protocol, while HSRP is Cisco proprietary.
C. HSRP is configured at the global level, while VRRP is configured at the interface level.
D. VRRP offers Layer 2 first-hop redundancy, while HSRP offers Layer 3 first-hop redundancy.
6. Which IP address should a client PC use as its default gateway if you have the following configuration
on a multilayer switch? (Source: Configuring Layer 3 Redundancy With VRRP)
interface ethernet 0/1
no switchport
ip address 192.168.199.3 255.255.255.0
vrrp 1 ip address 192.168.199.2
A. 192.168.199.1
B. 192.168.199.2
C. 192.168.199.3
D. any of the above three IP addresses
7. By default, which MAC address will be sent to the next client that is asking for the GLBP virtual
gateway? (Source: Configuring Layer 3 Redundancy With GLBP)
A. 0007.a400.0102
B. next virtual MAC in sequence
C. virtual MAC of the least-utilized router
D. virtual MAC address of HSRP
8. At maximum, how many active virtual forwarders can be there within a GLBP group? (Source:
Configuring Layer 3 Redundancy With GLBP)
A. 1
B. 2
C. 4
D. 8
9. Which description best suits the GLBP "Standby" virtual gateway state? (Source: Configuring Layer 3
Redundancy With GLBP)
A. Virtual IP address has not been configured or learned, but there is some GLBP configuration.
B. Virtual IP address has been configured or learned, however configuration is not complete. Interface
must be operational on Layer 3 and configured to route IP.
C. Virtual gateway is receiving hello packets. It is ready to change to “Speak” state if the active or
standby virtual gateway becomes unavailable.
D. Virtual gateway is trying to become the active or standby virtual gateway.
E. This gateway is next in line to be the active virtual gateway.
10. What is the function of the following interface configuration command: standby 1 ipv6 autoconfig?
(Source: Configuring First Hop Redundancy for IPv6)
A. Let's the IOS choose the best fit for IPv6 FHRP. IOS will choose either HSRP or GLBP.
B. Configures virtual IPv6 address for GLBP group 1.
C. Configures virtual IPv6 address for HSRP group 1.
D. Configures virtual IPv6 address for VRRP group 1.
11. You are configuring HSRP for IPv6 group 1. Which of the following commands can you use to set the
priority of virtual router to 110? (Source: Configuring First Hop Redundancy for IPv6)
A. Router(config-if)# standby 1 priority 110
B. Router(config-if)# standby 1 ipv6 priority 110
C. Router(config-if)# standby ipv6 1 priority 110
D. Router(config)# standby 1 priority 110
12. Which HSRP versions support IPv6? (Source: Configuring First Hop Redundancy for IPv6)
A. version 1
B. version 1 and 2
C. version 2
D. version 3
Answer Key
1 D
2 D
3 B
4 C
5 B
6 B
7 B
8 C
9 E
10 C
11 A
12 C
Module 7: Campus Network
Security
Introduction
While much attention focuses on security attacks from outside the walls of an organization and at the upper
OSI layers, campus access devices and Layer 2 communication are largely unconsidered in most security
discussions. It is important that only authorized devices and users are able to access ports on your access
layer switches. In this lesson you will not only learn about port security configuration but also about more
centralized solution that is AAA framework.
Equipment malfunction and malicious attacks can bring down your network. In this lesson you will learn
how storm control mechanisms, DHCP snooping, IP source guard, dynamic ARP inspection, and VLAN
access lists can aid in your efforts of having a secure and stable network.
Lastly you will learn about Private VLANs. These will help you to segment traffic within a single VLAN.
• Configure port security and automatic recovery from error conditions
• Implement storm control
• Configure AAA (local, RADIUS, TACACS+)
• Configure DHCP snooping, IP source guard, and dynamic ARP inspection
• Describe how switch can be attacked over poorly configured trunk links and how to properly protect
those links
• Perform basic private VLAN configuration
Lesson 1: Implementing Port
Security
Overview
Layer 2 security implementation is often forgotten. However, you should take the basic security measures to
guard against a host of attacks that can be launched at a switch and its ports. Two of the common security
measures are implementing port security and port access lists.
• Establish the importance of switch access security
• Describe recommended practices for securing a switch
• Describe how a rogue device gains unauthorized access to a network
• Describe categories of switch attack types and list mitigation options
• Describe what is MAC flooding and how you can protect against such attacks
• Describe how port security is used to block input from devices based on Layer 2 restrictions
• Configure and verify simple port security
• Configure and verify port security using sticky MAC addresses
• Describe what can cause for a port to become error-disabled
• Describe how to recover a port from "error-disabled" state
• Introduce the Port Access Lists
• Configure the Port Access Lists
Overview of Switch Security Issues
Much industry attention focuses on security attacks from outside the walls of an organization and at the
upper OSI layers. Network security often focuses on edge routing devices and the filtering of packets that
are based on Layer 3 and Layer 4 headers, ports, stateful packet inspection, and so on. This includes all the
issues that are related to Layer 3 and above, as traffic makes its way into the campus network from the
Internet. Campus access devices and Layer 2 communication are largely unconsidered in most security
discussions.
The default state of networking equipment highlights this focus on external protection and internal open
communication. Firewalls, placed at the organizational borders, arrive in a secure operational mode and
allow no communication until they are configured to do so. Routers and switches that are internal to an
organization and that are designed to accommodate communication, delivering needful campus traffic, have
a default operational mode that forwards all traffic unless they are configured otherwise. Their function as
devices that facilitate communication often results in minimal security configuration, and they become
targets for malicious attacks. If an attack is launched at Layer 2 on an internal campus device, the rest of the
network can be quickly compromised, often without detection.
Many security features are available for switches and routers, but they must be enabled to be effective. As
with Layer 3, where security had to be tightened on devices within the campus as malicious activity that
compromised this layer increased, now security measures must be taken to guard against malicious activity
at Layer 2. A new security focus centers on attacks that are launched by maliciously using normal Layer 2
switch operations. Security features exist to protect switches and Layer 2 operations. However, as with
ACLs for upper-layer security, a policy must be established, and appropriate features must be configured to
protect against potential malicious acts while maintaining daily network operations.
Several reasons exist for strong protection of the enterprise campus infrastructure, including security
functions in each individual element of the enterprise campus:
• Relying on the security that has been established at the enterprise edge fails as soon as security there is
compromised. Having several layers of security increases the protection of the enterprise campus, where
usually the most strategic assets reside.
• If the enterprise allows visitors into its buildings, an attacker can potentially gain physical access to
devices in the enterprise campus. Relying on physical security is not enough.
• Very often external access does not stop at the enterprise edge. Applications require at least an indirect
access to the enterprise campus resources, which means that strong security is necessary.
Switch Security Recommended Practices
Whenever possible, consider and implement these switch security suggestions:

• Configure secure passwords:
− The enable password command employs weak encryption. Use enable secret whenever possible.
− Use the service password-encryption global configuration command to encrypt all passwords that
cannot be encrypted using strong authentication. Even though this is weak, easily broken
encryption, it can prevent casual passers-by from seeing clear text passwords.
− Having external AAA servers means that you do not need to manage and maintain user credentials
on individual devices. Use external AAA authentication.
• Use system banners:
− After users successfully access a device, they need to be made aware of access policies of your
organization. The goal is to warn unauthorized users that their activities could be grounds for
persecution.
− Use banner login command to configure text that is displayed to authenticated user.
• Secure console access:
− Even though switches are usually locked away, it is still considered good practice to configure
authentication on any console. It is usually the case that vty and console lines use the same
password.
• Secure vty access:
− Always secure all vty lines on a device.
− Configure access lists to limit source IP addresses of potential administrative users who try to
access the device remotely.
− access-list 1 permit 10.0.0.234
access-list 1 permit 10.0.0.235
line vty 0 15
access-class 10 in
• Secure web interface:
− If you are not using web interface to manage a switch, disable it's web interface using no ip http
server command.
− If you do decide to use switch's web interface, use HTTPS (if its supported). With standard HTTP,
traffic is not encrypted. To enable HTTPS use ip http secure server global configuration
command.
− If you do decide to use switch's web interface, use access list to limit source addresses that can
access the HTTPS interface.
− ip http secure server
access-list 1 permit 10.100.50.0 0.0.0.255
ip http access-class 1
− HTTP is disabled by default on later IOS versions.
Whenever possible, consider and implement these switch security suggestions:

• Use SSH, not Telnet:
− Telnet is easy to use but not secure. All text that is sent through a Telnet session is in clear text! It is
easy to eavesdrop on Telnet sessions and overhear usernames and passwords.
− SSH uses strong encryption to secure session data. You should use the highest SSH version
available on device available.
• Secure SNMP access:
− If you do not need the write access through SNMP, disable it. This will prevent unauthorized users
to make changes to configuration.
• Secure STP operation:
− You should always enable BPDU Guard feature on access switch ports. This way if unexpected
BPDU is received, port is automatically shut down!
− Do not ever configure BPDU Guard and BPDU Filter on the same port. In this case only BPDU
Filter will take effect. BPDU Filter ignores BPDUs and if you enable it on access ports this can be a
great opportunity for a Layer 2 loop to occur.
• Secure CDP:
− As a rule, all Cisco devices have CDP enabled on all ports by default. CDP by itself is very useful
to discover network topology. However, you should disable CDP on ports that connect to outside
networks. This will prevent advertising unnecessary information about your switch to listening
attackers. CDP advertisements are sent in clear text and you cannot configure authentication.
• Secure unused switch ports:
− All unused switch ports should be shut down to prevent unauthorized users from connecting to your
network.
− All user ports should be configured with switchport mode access command. If user ports are
configured to DTP's dynamic or auto mode, malicious user might connect and attempt to negotiate
trunking mode on a port.
− Put all unused ports into an isolated or bogus VLAN. If a malicious user succeeds to access to a
port, he will only have access to a VLAN that is isolated from the rest of the network.
Unauthorized Access by Rogue Devices
Rogue access comes in several forms. For example, because unauthorized rogue access points are
inexpensive and readily available, employees sometimes plug them into existing LANs and build ad hoc
wireless networks without IT department knowledge or consent. These rogue access points can be a serious
breach of network security because they can be plugged into a network port behind the corporate firewall.
Because employees generally do not enable any security settings on the rogue access point, it is easy for
unauthorized users to use the access point to intercept network traffic and hijack client sessions.
Malicious rogue access points, although much less common than employee-installed rogue access points,
are also a security concern. These rogue access points create an unsecured wireless LAN connection that
puts the entire wired network at risk. Malicious rogues present an even greater risk and challenge because
they are intentionally hidden from physical and network view.
To mitigate STP manipulation, use the root guard and the BPDU guard enhancement commands to
enforce the placement of the root bridge in the network and to enforce the STP domain borders. The root
guard feature is designed to provide a way to enforce the root bridge placement in the network. The STP
BPDU guard is designed to allow network designers to keep the active network topology predictable.
Although BPDU guard may seem unnecessary, given that the administrator can set the bridge priority to
zero, there is still no guarantee that it will be elected as the root bridge, because there might be a bridge with
priority zero and a lower bridge ID. BPDU guard is best deployed toward user-facing ports to prevent rogue
switch-network extensions by an attacker.
Switch Attack Categories
A device that is connected to the campus network typically launches Layer 2 malicious attacks. The attacks
may originate from a physical rogue device that has been placed on the network for malicious purposes. The
attack may also come from an external intrusion that takes control of, and launches attacks from, a trusted
device. In either case, the network sees all traffic as originating from a legitimate connected device.
Attacks that are launched against switches and at Layer 2 can be grouped as follows:
• MAC layer attacks
• VLAN attacks
• Spoofi attacks
• Attacks on switch devices
Significant attacks in these categories are discussed in more detail in subsequent sections of the course.
Each attack method is accompanied by a standard measure for mitigating the security compromise.
The table describes attack methods and the steps to mitigation.
Switch Security Concerns and Mitigation Steps
Attack Method Description Steps to Mitigation
MAC Layer Attacks
MAC address flooding Frames w ith unique, invalid source MAC Port security.
addresses flood the sw itch, exhausting CAM table MAC address VLAN access
space, disallow ing new entries from valid hosts. maps.
Traffic to valid hosts is then flooded out all ports.
VLAN Attacks
VLAN hopping By altering the VLAN ID on packets that are Tighten up trunk configurations
encapsulated for trunking, an attacking device can and the negotiation state of
send packets on various VLANs, bypassing Layer unused ports.
3 security measures.
Shut dow n unused ports.
Place unused ports in a common
VLAN.
Attacks betw een devices on Devices may need protection from one another, Implement PVLANs.
a common VLAN even though they are on a common VLAN. This is
especially true on service-provider segments that
support devices from multiple customers.
Spoofing Attacks
DHCP starvation and DHCP An attacking device can exhaust the address Use DHCP snooping.
spoofing space available to the DHCP servers for a time
period or establish itself as a DHCP server in man-
in-the-middle attacks.
Spanning-tree compromises Attacking device spoofs the root bridge in the STP Proactively configure the primary
topology. If successful, the netw ork attacker can and backup root devices.
see various frames. Enable RootGuard.
MAC spoofing Attacking device spoofs the MAC address of a Use DHCP snooping, port
valid host currently in the CAM table. Sw itch then security.
forw ards to the attacking device any frames that
are destined for the valid host.
Address Resolution Protocol Attacking device crafts ARP replies intended for Use DAI.
(ARP) spoofing valid hosts. The MAC address of the attacking DHCP snooping, port security.
device then becomes the destination address that
is found in the Layer 2 frames that w ere sent by the
valid netw ork device.
Sw itch Device Attacks
Cisco Discovery Protocol Information sent through Cisco Discovery Protocol Disable Cisco Discovery Protocol
manipulation is transmitted in clear text and unauthenticated, on all ports w here it is not
allow ing it to be captured and to divulge netw ork intentionally used.
topology information.
Secure Shell (SSH) Protocol Telnet packets can be read in clear text. SSH is an Use SSH version 2.
and Telnet attacks option but has security issues in version 1. Use Telnet w ith vty ACLs.
MAC Flooding Attack
A common Layer 2 or switch attack is MAC flooding, which results in an overflow of the CAM table of a
switch. The overflow causes the flooding of regular data frames out all switch ports. This attack can be
launched for the malicious purpose of collecting a broad sample of traffic or as a DoS attack.
The CAM tables of a switch are limited in size and therefore can contain only a limited number of entries at
any one time. A network intruder can maliciously flood a switch with many frames from a range of invalid
source MAC addresses. If enough new entries are made before old ones expire, new valid entries will not be
accepted. Then, when traffic arrives at the switch for a legitimate device that is located on one of the switch
ports that was not able to create a CAM table entry, the switch must flood the frames to that address out all
ports. This has two adverse effects:
• The switch traffic forwarding is inefficient and voluminous.
• An intruding device can be connected to any switch port and can capture traffic that is not normally
detected on that port.
If the attack is launched before the beginning of the day, the CAM table would be full when most of devices
are powered on. Then frames from those legitimate devices are unable to create CAM table entries as they
power on. If this represents many network devices, the number of MAC addresses that are flooded with
traffic will be high, and any switch port will carry flooded frames from many devices.
If the initial flood of invalid CAM table entries is a one-time event, the switch will eventually age out older,
invalid CAM table entries, allowing new, legitimate devices to create entries. Traffic flooding will cease
and may never be detected, even though the intruder may have captured a significant amount of data from
the network.
To mitigate MAC flooding attacks, you should configure port security to define the number of MAC
addresses that are allowed on a given port. Port security can also specify which MAC address is allowed on
a given port.
Introducing Port Security
Port security is used to block input from devices based on Layer 2 restrictions.
Port security restricts a switch port to a specific set or number of MAC addresses. Those addresses can be
learned dynamically or configured statically. The port will then provide access to frames from only those
addresses. If, however, the number of addresses is limited to four but no specific MAC addresses are
configured, the port will allow any four MAC addresses to be learned dynamically, and port access will be
limited to those four dynamically learned addresses.
A port security feature called "sticky learning," available on some switch platforms, combines the features
of dynamically learned and statically configured addresses. When this feature is configured on an interface,
the interface converts dynamically learned addresses to "sticky secure" addresses. This adds them to the
running configuration as if they were configured with the switchport port-security mac-address
command.
Port Security Process
Step Action Notes
1. Configure port security. Configure port security to allow only desired number
of connections on the port. Configure an entry for
each of these allow ed MAC addresses. This
configuration, in effect, populates the MAC address
table w ith new entries for that port and allow s no
additional entries to be learned dynamically.
2. Allow ed frames are processed. When frames arrive on the sw itch port, their source
MAC address is checked against the MAC address
table. If the frame source MAC address matches an
entry in the table for that port, the frames are
forw arded to the sw itch to be processed like any
other frames on the sw itch.
3. New addresses are not allow ed to create new MAC When frames w ith a nonallow ed MAC address arrive
address table entries. on the port, the sw itch determines that the address
is not in the current MAC address table and does
not create a dynamic entry for that new MAC
address, because the number of allow ed addresses
has been limited.
4. Sw itch takes action in response to nonallow ed The sw itch w ill disallow access to the port and take
frames. one of these configuration-dependent actions: (a)
the entire sw itch port can be disabled; (b) access
can be denied for that MAC address only and a log
error can be generated; (c) access can be denied for
that MAC address but w ithout generating a log
message.
Discovery 17: Port Security
Overview
Port security can restrict port's input by limiting and identifying MAC addresses that are allowed to access
the port.
In this discovery, you will learn how to configure port security.
Topology
Job Aids
Device Addressing
Port Security
Step 1 On SW configure Ethernet 0/1 to only allow one MAC address and that MAC address should be
"aaaa.aaaa.aaaa".
SW(config)# interface ethernet 0/1

SW(config-if)# switchport port-security mac-address aaaa.aaaa.aaaa
SW(config-if)# switchport port-security maximum 1
Maximum number of allowed MAC addresses is set to 1 by default, so the last line of
configuration is not really needed, however, you would need to allow two MAC addresses per
port if a daisy-chained VoIP phone and computer are connected to this port.
Port security can also be configured per-VLAN.
Step 2 On SW's Ethernet 0/1 enable port security.
SW(config-if)# switchport port-security
This is the configuration that enables port security. What you did in the previous step was a
configuration of port security parameters.
Soon after you enable port security the following messages should appear in SW's CLI:
*Mar 6 12:47:42.882: %PM-4-ERR_DISABLE: psecure-violation error detected on Et0/1,
putting Et0/1 in err-disable state
*Mar 6 12:47:42.882: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation
occurred, caused by MAC address aabb.cc00.1000 on port Ethernet0/1.
You are being notified that port Ethernet 0/1 was put into an "error-disabled" state, because a
device with MAC address that is not "aaaa.aaaa.aaaa" is trying to communicate through switch
SW. PC1, connected to Ethernet 0/1 on SW, does not have a MAC address of "aaaa.aaaa.aaaa".
Port will transition to error-disabled state only if a violation occurs and the port is configured
with port security "shutdown" mode. This is the default violation mode.
NOTE: PC's MAC addresses may differ.
Step 3 From PC1 ping SRV's IP address 192.168.0.163. Your attempt should not be successful.
PC1# ping 192.168.0.163

.....
Not only PC1's MAC address is not allowed by port security, the port PC1 is connected to has
been error-disabled by port security, so even if a device with legitimate MAC address
"aaaaa.aaaa.aaaaa" would now be connected to that port, it would still be forbidden to
communicate.
Step 4 On SW verify port security status on Ethernet 0/1.
SW# show port-security interface ethernet 0/1

Port Security : Enabled
Port Status : Secure-shutdown
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 1
Configured MAC Addresses : 1
Sticky MAC Addresses : 0
Last Source Address:Vlan : aabb.cc00.1000:1
Security Violation Count : 1
Notice that Ehternet 0/1 on SW has port security enabled and that the port status is "Secure-
shutdown". This port status signifies that port is in error-disabled state.
Maximum MAC addresses is set to 1 and there is one configured MAC address
("aaaa.aaaa.aaaa").
The MAC address that is listed next to "Last Source Address:Vlan" is that of the PC1 - the
device that caused port security violation in this example.
Whenever a port security violation occurs the violation count will increase by 1. Since port was
moved into error-disabled state, error count is equal to 1 and it will no increase unless you bring
the port back up without removing the violator (PC1).
Step 5 On SW's Ethernet 0/1 interface change port security violation mode to "restrict" and enable the
interface.

SW(config-if)# switch port-security violation restrict
SW(config-if)# shutdown
SW(config-if)# no shutdown
To get error-disabled port back to operational state you need to shut it down and then bring it
back up.
In the CLI of SW you should soon notice the following error message:
*Mar 6 12:57:43.019: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation
occurred, caused by MAC address aabb.cc00.1000 on port Ethernet0/1.
You are being notify that there is a security violation on Ethernet 0/1 and it also tells you the
offending MAC address. Notice that port was not shut down.
PC1# ping 192.168.0.163

.....
So what is the difference between "shutdown" and "restrict" violation modes? With the later
interface is not being shutdown when a violation occurs. All traffic from devices with allowed
MAC addresses gets through - in this example that would be device with MAC "aaaa.aaaa.aaaa",
if it existed. Traffic from other devices gets dropped - in this example PC1.
Step 7 Again, verify port security status on SW's Ethernet 0/1 interface.

Port Status : Secure-up
Violation Mode : Restrict
Aging Time : 0 mins
Output is pretty similar a previous one, but now the violation mode is "restrict" and port status is
noted as secure and operational, rather than error-disabled. You should also notice that violation
count has increased quite a bit. This is because the port was not shutdown and all subsequent
communication events of PC1 result in violation counter increase.
Step 8 On SW's Ethernet 0/1 interface change port security violation mode to "protect".

SW(config-if)# switchport port-security violation protect
You should notice that violation notifications in the CLI of SW stopped.
PC1# ping 192.168.0.163

.....
Step 10 For the third time, verify port security status on SW's Ethernet 0/1 interface.

Violation Mode : Protect
Aging Time : 0 mins
Port security violation is now set to "protect" and port is secured and operational.
What are the differences between "restrict" and "protect" violation modes? None from the
allowed traffic perspective. Device with MAC addresses "aaaa.aaaa.aaaa" would still be allowed
to communicate through Ethernet 0/1 if it existed while PC1 is still not allowed to communicate.
However, with "protect" mode enabled there are no more notifications about port security
violations. And likewise, with "protect" mode the security violation counter will not increase.
Issue the show port-security interface ethernet 0/1 command. The counter has not increased.
You, as the network administrator are encouraged to use the "restrict" mode. You should use the
port violation messages to identify persistent violators and remove the root cause, not only
prevent it.
Manually configuring every allowed MAC address is a time consuming task. Is there a more
dynamic way to configure switch ports with port security?
Step 11 On SW configure Ethernet0/2 interface with "sticky" MAC address port security.
SW(config-if)# switchport port-security mac-address sticky
SW(config-if)# switchport port-security
In this example Ethernet 0/2 was configured with "sticky" MAC address and port security was
enabled on the port.
With sticky addresses switch port will learn MAC addresses dynamically. It will learn as many
MAC addresses as allowed by maximum MAC addresses configuration, set to one by default. In
this example Ethernet 0/2 interdace on SW will learn MAC address of PC2.
Step 12 From PC2 ping SRV's IP address 192.168.0.163. Your attempt should be successful.
PC2# ping 192.168.0.163

!!!!!
Step 13 On SW verify port security status of Ethernet 0/2 interface.

Violation Mode : Shutdown
Aging Time : 0 mins
Port Ethernet0/2 is in secure and operational state. Violation mode is "shutdown" and MAC
address learned is that of PC2. Violation counter is 0, because there was no port security
violation.
NOTE: MAC address of PC2 might be different in your example.
Step 14 On SW verify the running configuration of Ethernet0/2 interface.
SW# show run interface ethernet 0/2
Building configuration...
Current configuration : 197 bytes

!
interface Ethernet0/2
switchport mode access
switchport port-security
switchport port-security mac-address sticky
switchport port-security mac-address sticky aabb.cc00.1400
duplex auto
end
MAC address of PC2 was automatically learned by SW.

If you save the current running configuration, the learned sticky MAC addresses will be kept in
the startup configuration.
Sticky addresses are a balance between security and administrative overhead. Instead of
manually specifying MAC addresses on every switch interface to which end-devices connect to,
you can allow switch to learn addresses automatically and then save them. This is a suitable
approach only if you are absolutely positive that at the time of configuration only the allowed
end-user devices connect to the port.
Port Error Conditions
When a port is enabled, but switch detects an error situation on the port, it puts the port into an "error-
disabled" state and shuts it down. When a port is in "error-disabled" state no traffic is sent or received on
that port.
The "error-disabled" state lets the administrator know when there is a port problem and it eliminates the
possibility of this port causing other ports on the module to fail.
Port security violation is only one of the reasons why port might be in the "error-disabled" state. There are
several other reasons:
• Spanning-tree BPDU guard violation: When you have portfast configured in combination with BPDU
guard, the port will switch to the "error-disabled" state, if the BPDU is received on the port.
• EtherChannel misconfiguration: All parameters have to be the same for all ports on both sides of the
bundle, otherwise the port will switch into the "error-disabled" state.
• Duplex mismatch: Duplex mode has to be the same on both sides of the link, otherwise the ports
switch into the "error-disabled" state.
• UDLD condition: UDLD assures that the link is bidirectional at all times, so when it detects an
unidirectional link it places the port into the "error-disabled" state.
• Spanning-tree root guard: If a root guard-enabled port receives a superior BPDU from those sent by
the current root bridge, the port is moved into the "error-disabled" state.
• Link flapping: When link state is "flapping" between the up and down states, the port is placed into the
"error-disabled" state.
• Other reasons such as late-collision detection, Layer 2 Tunneling Protocol guard, DHCP snooping
rate-limit, incorrect GBIC, ARP inspection.
Error-disable detection is enabled for all of these causes by default. You can configure only desired causes
to trigger port being disabled. Use the following command to specify the causes:
Switch(config)# errdisable detect cause [all | cause name]
Error Disabled Port Automatic Recovery
An error-disabled port will become operational after you shut it down and than bring back up. To reduce the
administrative overhead, an error-disabled port can be automatically re-enabled, after the problem causing
the "error-disabled" state is fixed.
This can be achieved by the errdisable recovery command, which automatically re-enables the port after a
specified period of time. If the problem, that caused the port to change into "error-disabled" state is not
resolved, the port will stay in "error-disabled" state.
SW(config)# errdisable recovery cause cause
SW(config)# errdisable recovery interval seconds
The default time interval is 300 seconds, the minimum is 30 seconds.

You can verify where you have autorecovery enabled by using the command show errdisable recovery.
By default, autorecovery feature is disabled.
Port Access Lists
Standard access lists (ACL) are applied to traffic passing through the Layer 3 interface, for instance a SVI
used to route from one VLAN to another VLAN on a Layer 3 switch. The PACL feature provides the ability
to perform access control on a specific Layer 2 port.
A Layer 2 port is a physical LAN or trunk port that belongs to a VLAN. Port ACLs are applied only on the
ingress traffic. The port ACL feature is supported only in hardware (port ACLs are not applied to any
packets routed in software). The PACL feature does not affect Layer 2 control packets, such as CDP, VTP,
DTP, STP, received on the port.
There are two types of PACL:

• IP access list filters IPv4 and IPv6 packets on a Layer 2 port.
• MAC access list filters packets that are of an unsupported type (not IP, ARP or MPLS) based on the
fields of the Ethernet frame. A MAC access list is not applied to IP, MPLS, or ARP messages. You can
define only named MAC access lists.
PACLs interaction with other types of ACLs depends on the configured mode:
• In prefer port mode PACL takes effects and overrides the effect of other ACLs. This mode is the only
mode that is allowed when applying PACL on a trunk.
• In merge mode PACLs, VACLs and standard ACLs are merged in the ingress direction. This is the
default mode.
PACLs can be configured on an EtherChannel interface, but not on its port members.
Configure Port Access Lists
IP and MAC ACLs can be applied to Layer 2 physical interfaces. Standard (numbered, named) and
Extended (numbered, named) IP ACLs, and Extended Named MAC ACLs are supported.
Configure an extended named MAC ACL and apply it on a Layer 2 interface:

SW(config)# mac access-list extended acl-name
SW(config-ext-macl)# permit host [source-mac | any] [destination-mac | any]
SW(config-ext-macl)# interface interface slot/number
SW(config-if)# mac access-group acl-name in
Configure a standard or extended IP ACL and apply it on a Layer 2 interface:

SW(config)# ip access-list acl-type acl-name
SW(config-ext-nacl)# permit protocol [source-address | any] [destination-address |
any]
SW(config-ext-nacl)# interface interface slot/number
SW(config-if)# ip access-group acl-name in
Note The CLI syntax for creating a PACL is identical to the syntax for creating a Cisco IOS ACL.
An instance of an ACL that is mapped to a Layer 2 port is called a PACL. An instance of an
ACL that is mapped to a Layer 3 interface is called a Cisco IOS ACL. The same ACL can be
mapped to both a Layer 2 port and a Layer 3 interface.
To configure the access mode on a Layer 2 interface, perform this task:

SW(config)# interface interface slot/number
SW(config-if)# access-group mode [prefer port | merge]
Please note that access mode command is not supported on all platforms.
Summary
References
• Errdisable Port State Recovery: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-
tree-protocol/69980-errdisable-recovery.html
• Configuring Port ACLs: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-
2SY/configuration/guide/sy_swcg/port_acls.html
Storm Control
Overview
Network or host misconfigurations, host malfunctions or intentional denial of service attacks may flood the
network with traffic storms. Cisco IOS switches provide the Storm Control feature to limit the impact of
traffic storms and, in neccesarry, take appropriate actions.

• Describe what a traffic storm is and how to control it
• Configure Storm Control
• Verify Storm Control behavior
Storm Control
A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network
performance. Storm control feature prevents LAN ports from being disrupted by a broadcast, multicast, or
unicast traffic storm on physical interfaces and is used to protect against or isolate broadcast storms caused
by STP misconfigurations, unicast storms created by malfunctioning hosts or denial of service attacks.
Traffic storm control (also called traffic suppression) monitors incoming traffic levels over a 1-second
traffic storm control interval. During the interval it compares the traffic level with the traffic storm threshold
level that you configure. The traffic storm control level is either an absolute number of bits or packets per
second or a percentage of the total available bandwidth of the port. Two thresholds can be configured. When
traffic exceeds the rising threshold level, storm control blocks the port. Once the traffic falls under the
falling threshold, storm control removes the block. Configuration of a falling threshold is optional.
Each T slot on the figure represents a 1 second interval. In T0, ingress traffic stays below rising threshold.
In T1 traffic breaches the rising threshold, consequently the port is blocked in the next interval, T2. In T2
traffic falls below the rising threshold, but it is still above the falling thresholds, so the port block is kept in
T3. Finally, traffic falls under falling threshold in T3 and port block is removed in T4.
Note Storm control algorithms may differ. On some of the Cisco devices port is blocked as soon
as the threshold is breached and is kept blocked until the end of the 1 second interval.
Optionally, an interface can be shut down if threshold level is breached or SNMP trap sent.
Storm control is configured per interface for each traffic type (unicast, multicast, broadcast) separately.
Note Depending on the Catalyst switch series multicast traffic may be considered a part of
broadcast traffic. Consult with the documentation for each Catalyst series.
Configuring Storm Control On An Interface
Storm control configuration is done per interface for each type of traffic separately. Storm control is
typically configured on access ports, to limit the effect of traffic storm on access level, before it enters the
network.
You have to configure a rising threshold. Falling threshold is optional. Both thresholds can be configured
either in percents of the total interface bandwidth, bits per second or packets per second:
SW(config)# interface interface slot/int
SW(config-if)# storm-control [broadcast | multicast | unicast] level {rising-percent |
bps rising-bps | pps rising-pps} [falling-percent | falling-bps | falling-pps]
Networks differ from one another, so do the traffic patterns. To configure an effective threshold level,
interface traffic monitoring over a longer period is advised to establish a baseline. Monitoring of Storm
Control events, either with remote syslog server or SNMP Trap receiver, will allow you to effectively adjust
the thresholds when needed.
Storm control can be configured on the port channel interface of an EtherChannel. Do not configure it on
ports that are members of an EtherChannel.
Note Configured percentage thresholds are only approximation, actual enforced level might differ.
On some platforms, setting percentage thresholds under 0.33 percent may suppress all
traffic.
Additional actions can be taken by storm control upon traffic breach, such as putting the interface in error-
disable or sending an SNMP trap:
SW(config)# interface interface slot/int
SW(config-if)# storm-control action {shutdown | trap}
Verifying Storm Control Behavior
You can verify Storm Control behavior by investigating each port's filter state and current level of traffic
compared to configured thresholds.
The show storm-control command without the additional parameter display the broadcast filter state. In
this case, rising threshold is set to 50% of interface bandwidth, falling threshold to 30%, while current
broadcast traffic reaches 1.33%. Filter is thus in forwarding state:
SW# show storm-control
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Gi0/1 Forwarding 50.00% 30.00% 1.33%
Additional multicast keyword displays multicast filter, which has it's rising threshold set to 30.000 packets
per second and falling threshold set to 20.000 packets per second.
SW# show storm-control multicast
--------- ------------- ----------- ----------- ----------
Gi0/1 Forwarding 30k pps 20k pps 0 pps
The unicast filter is set to 30 Megabits per second. Falling threshold is not configured and is thus equal to
rising threshold. Current unicast traffic exceeds the threshold with 37 Megabits per second. As the threshold
was already breached in the previous 1 second interval, filter is set to Blocking:
SW# show storm-control unicast
--------- ------------- ----------- ----------- ----------
Gi0/1 Blocking 30m bps 30m bps 37m bps
Note To verify the Storm Control configuration, you can generate broadcast, multicast or unicast
traffic with traffic generators, such as iperf.
Summary
References
• Configuring Storm Control on Catalyst 3560 Series:
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/15-
0_2_se/configuration/guide/scg3560/swtrafc.html#wp1063295
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/15-
02SG/configuration/guide/config/bcastsup.html
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-
0SY/configuration/guide/15_0_sy_swcg/traffic_storm_control.html
Access to External
Authentication
Overview
AAA services are part of an architectural framework that enables configuration of these functions in a
uniform yet flexible way. First, you want to identify users before they access the network—authentication.
Your next step is to determine what are users capable of doing and what restrictions apply to them—
authorization. Finally, you want to keep the information about user activities for future auditing, billing or
reporting purposes—accounting.
The aim of the lesson is to explain what each of the AAA component is, to compare possible authentication
options you can implement on the Cisco IOS and to show how centralized implementation of AAA services
using TACACS+ or RADIUS server contributes to better scalability, manageability and control. Second
part of the lesson focuses on the configuration of authentication using centralized server and a local
database, describes limitations of TACACS+ and RADIUS and gives implementation cases for the two.
Upon completing this lesson, you will be able to configure AAA on a Cisco IOS device. You will be able to
meet the following objectives:
• Describe what is AAA and its components
• Describe the benefits of implementing AAA
• Describe the purpose of authentication and list authentication options
• Describe RADIUS and TACACS+, and highlight their differences
• Enable AAA and create a local backup user account
• Configure RADIUS for console and vty access
• Configure TACACS+ for console and vty access
• Configure authentication, authorization and accounting.
• Describe limitations and use cases for RADIUS and TACACS+
• Identity Based Networking
• Describe IEEE 802.1x Port-Based Authentication
• Configure IEEE 802.1x on a Cisco IOS device
AAA Framework Overview
AAA represents architectural framework through which the network access control policy is enforced on the
networking device. The acronym AAA stands for authentication, authorization and accounting - three main
functions of the model configurable in a consistent manner.
Authentication – Authentication is the process of identifying a user prior to being allowed access to a
protected resource. User presents valid credentials which are then compared with the information in the user
database. Additionally, authentication component may offer other services depending on the security
protocol selected (e.g. additional challenge and response, messaging support, encryption).
Authorization – After the user gains access to the network, authorization is performed. Authorization
allows you to control the level of access users have. For example, via authorization you can define which
priviledge EXEC commands are available to the user, or you may control remote access allowing user to
use protocols such as PPP or SLIP. User capabilities are defined by a set of attribute-value pairs which are
associated with the user or users’s group. These pairs may be stored locally on the device, or on the
centralized TACACS+/RADIUS server.
When user tries to perform some specific function (e.g. configure an IP address on an interface), AAA
engine on the device queries the authorization server for that specific attribute and user. Based on the reply
from the server (i.e. value of the user’s attribute in question), user is allowed or not allowed to perform that
specific function.
Accounting – Accounting is performed after authentication. Accounting enables you to collect information
about the user activity and resource consumption. It allows you to log user logins, commands executed by
the user, session durations, bytes transferred, etc. Network device sends this information in a form of
attribute-value pairs to the accounting server. User activity information from all devices in your network is
thus located in one central place. This information can then be used used for billing, auditing and reporting
purposes.
Authentication can be valid without the authorization and accounting. Authorization and accounting,
however, it cannot be performed without the authentication.
The Benefits of AAA Usage
Implementation of the AAA model brings the following advantages:

• Increased flexibility and control of access configuration – Although Cisco IOS offers possibilities to
configure local usernames and passwords, line passwords and enable secrets without the use of AAA,
these methods do not offer satisfactory level of flexibility and control. AAA offers additional
authorization flexibility on a per-command or per-interface level, which is unavailable with local
credentials.
• Scalability – Storing usernames and passwords in a local database on device may be appropriate
solution for a small network with a small number of users. As the network grows, managing large
number of users on multiple devices becomes highly impractical, error-prone, with a lot of
administrative burden. Outdated credentials or lack of credentials lead to a usage of a single username
by a number of network administrators, loosing ability to track activities back to a single user. AAA
model is the only solution that scales well.
• Standardized authentication methods – Implementation of AAA framework supports RADIUS
protocol which is an industry open standard. This ensures interoperability and allows flexibility as you
can mix and match different vendors. For example, you can have your network built with Cisco
equipment, and have an AAA server from another vendor or you can even build your own custom AAA
server based on RADIUS.
• Multiple backup systems – You may specify multiple servers when configuring authentication option
on the method list combining them in a server group. In case of a server failure, AAA engine on the
device will continue to query the next server from the server group.
Authentication Options
Before the user is given an access to a network or device resource, you want to verify the user's identity.
The process is called authentication.
Generally speaking authentication can be based on something that user knows (username and password),
something that user has (digital certificate issued by certification authority) or something that user is
(biometrical scanners which can identify him by his fingerprint or eye retina).
Whichever method is used, the information provided by the user is compared with the information stored in
the authentication database and if a match exists, user is granted access to the network. Authentication
database may be stored either locally on a network device or on a centralized server.
AAA model on Cisco IOS allows you to configure both local and remote authentication. Configuration is
done with the aaa authentication command. First, you need to specify a service type the authentication
configuration will be applied for. A service type might be login for CLI login authentication (be it console,
telnet, SSH, etc.), ppp for PPP connections and so on.
Second, you need to specify a method list. You can specify a default method list with the default keyword.
Default method list applies to any interface, line or service if a more specific named method list is not
defined. It is typically used in smaller/medium environments, where there is a single shared AAA
infrastructure. Additionally named method lists can be specified. When defined, named method list must be
explicitly applied to an interface, line or service. It overrides default method list. You define named method
lists according to your needs.
Last you need to specify a single or a list of authentication methods. Multiple authentication methods are
available, such as local for local database authentication or group to configure groups of remote RADIUS
or TACACS+ servers. When multiple authentication methods are configured, additional methods of
authentication are used only if the previous method returns an error, not if it fails. To specify that the
authentication should succeed even if all methods return an error, specify none as the final method in the
command line. Usage of none authentication method is discouraged in production environments as it allows
access without successful authentication.
RADIUS and TACACS+ Overview
RADIUS and TACACS+ are AAA protocols.
Both use client-server model. User or machine sends a request (1 in the figure) to a client. Client is also
called NAS or RAS. Typically NAS is a router, switch, firewall or access point. Client than communicates
(2, 3) with a server exchanging RADIUS or TACACS+ messages. If authentication is successful, user is
granted (4) an access to a protected resource (5), such as a device CLI, network, etc. Cisco implements the
AAA server functionality in Cisco Secure Access Control Server and ISE.
RADIUS is fully open standard protocol developed by Livingston Enterprises. It is described in RFCs 2865
(authentication and authorization) and 2866 (accounting). RADIUS uses UDP port 1812 for the
authentication and authorization, and thus combining authentication and authorization into one service. For
the accounting service RADIUS uses UDP port 1813. Communication between NAS and RADIUS server
is not completely secure – only password portion of the RADIUS packet header is encrypted.
TACACS+ is Cisco proprietary protocol not compatible with the older versions such as TACACS or
XTACACS, which are now deprecated. It allows for greater modularity, by total separation of all three
AAA functions. TACACS+ uses TCP port 49, thus reliability is ensured by the transport protocol itself.
Entire TACACS+ packet is encrypted, so communication between NAS and the TACACS+ server is
completely secure.
Authentication process between NAS and RADIUS server starts when client sends login request in the form
of Access-Request packet. This packet contains username, encrypted password, NAS IP address and NAS
port number.
When server receives the query it first compares the shared secret key sent in the request packet with the
value configured on the server. When shared secrets are not identical server silently drops the packet. This
ensures that only authorized clients are able to communicate with the server. If shared secrets are identical,
packet is further processed comparing username and password inside the packet with those found in the
database.
If a match is found server returns Access-Accept packet with list of attributes to be used with this session in
the form of AV pairs (e.g. IP address, ACL for NAS, etc.). If, on the other hand, a match is not found,
RADIUS server returns Access-Reject packet. It is important to notice that authentication and authorization
phases are combined in a single Access-Request packet.
During authentication and authorization phase optional Access-Challenge message may be requested by the
RADIUS server with the purpose of collecting additional data (e.g. PIN, token card, etc.), thus further
verifying client's identity.
Accounting phase is realized separately after authentication and authorization phases, using Accounting-
Request and Accounting-Response messages.
Communication between NAS and TACACS+ server starts with establishing a TCP connection.
NAS contacts TACACS+ server to obtain a username prompt, which is then displayed to the user.
Username entered by the user is forwarded to the server. Server prompts the user again, this time for
password. Password is sent to the server where it is validated against the database (local or remote).
If a match is found, server will send ACCEPT message to the client and authorization phase may begin (if
configured on the NAS). If, on the other hand, a match is not found, server will respond with the REJECT
message and any further access will be denied.
Enabling AAA and Configuring Local User for
Fall-back
To enable AAA, you need to configure the aaa new-model command in global configuration. Until this
command is enabled, all other AAA commands are hidden.
You may use different authentication options. You can use external authentication servers such as RADIUS
or TACACS+ or you may specify a local database. In any case it is a good practice to configure a local
username, to serve as as a backup, should external servers fail.
Switch(config)# username username secret password
Note The aaa new-model command immediately applies local authentication to all lines and
interfaces (except console line line con 0). To avoid being locked out of the router, you
should define a local username and password before starting the AAA configuration.
To use the local database for authentication, you must specify the local keyword in the aaa authentication
command.
To use the local database only as a backup option, you need to tell the device to use the local database only
if all other authentication methods are unavailable. In order to do so, you must specify the local keyword at
the very end of the authentication methods list in the aaa authentication command.
Configuring RADIUS for Console and VTY Access
RADIUS AAA configuration starts with the configuration of a RADIUS server:

Switch(config)# radius server configuration-name
Switch(config-radius-server)# address ipv4 hostname [auth-port integer] [acct-port
integer]
Switch(config-radius-server)# key string
You need to specify the hostname or the IP address of the server. Optionally you can specify a custom port
number for the UDP communication, if your RADIUS server is listening on nondefault ports. Port numbers
for authentication and accounting differ. key string specifies the authentication and encryption key used
between access device and RADIUS server. This value must match on both devices.
Next, add the RADIUS server to a server group. You can add multiple RADIUS servers to a group, as long
as they were previously defined using the radius server command.
Switch(config)# aaa group server radius group-name
Switch(config-sg-radius)# server name configuration-name
For example, to configure RADIUS server with the IP address 172.16.1.1 using key cisco456 as a part of
the group Mygroup2:
Switch(config)# radius server myRadius
Switch(config-radius-server)# address ipv4 172.16.1.1
Switch(config-radius-server)# key cisco456
Switch(config)# aaa group server radius Mygroup2
Switch(config-sg-radius)# server name myRadius
To configure a login authentication using a named method list radius_list, server group Mygroup2 as
primary authentication option and local user database as a backup, use the following command:
Switch(config)# aaa authentication login radius_list group Mygroup2 local
Now apply this method list to the vty0 line (named method lists, contrary to default list, must be applied):
Switch(config)# line vty 0
Switch(config-line)# login authentication radius_list
Configuring TACACS+ for Console and VTY
Access
TACACS+ AAA configuration is nearly identical to RADIUS configuration. First, you need to configure
the TACACS+ server.
Switch(config)# tacacs server configuration-name
Switch(config-server-tacacs)# address ipv4 hostname
Switch(config-server-tacacs)# port integer
Switch(config-server-tacacs)# key string
You need to specify the hostname or the IP address of the server. Optionally you can specify a custom port
number for the TCP communication, if your TACACS+ server is listening on a nondefault port. key string
specifies the encryption key to be used for encrypting all traffic between access device and TACACS+
server. This value must match on both devices.
Next, add the TACACS+ server to a server group. You can add multiple TACACS+ servers to a group, as
long as they were previously defined using the tacacs server command.
Switch(config)# aaa group server tacacs+ group-name
Switch(config-sg-tacacs+)# server name configuration-name
For example, to configure TACACS+ server with the IP address 192.168.1.1 using shared secret key
cisco123 as a part of the server group Mygroup1:
Switch(config)# tacacs server myTacacs
Switch(config-server-tacacs)# address ipv4 192.168.1.1
Switch(config-server-tacacs)# key cisco123
Switch(config)# aaa group server tacacs+ Mygroup1
Switch(config-sg-tacacs+)# server name myTacacs
To configure a default login authentication and exec authorization with the server group Mygroup1 as a
primary authentication option and local user database as a backup, use the following commands:
Switch(config)# aaa authentication login default group Mygroup1 local
Switch(config)# aaa authorization exec default group Mygroup1 local
The default method list is automatically applied to all interfaces except those that have a named method list
explicitly defined.
Configuring Authorization and Accounting
Once the AAA has been enabled on a Cisco IOS device and aaa authentication has been configured, you
can optionally configure dependent AAA functions, aaa authorization and aaa accounting.
To configure authorization:
1. Define method list for authorization service with the aaa authorization command. As a minimum,
when configuring AAA services, you must always configure authentication. Authorization component
is not valid without previously configured authentication.
2. Apply authorization method list to a corresponding interface or line with authorization command. This
does not apply if authorization component is not configured in step 1.
To configure accounting:
1. Define method list for accounting service with the aaa accounting command. Accounting may not
stand alone as a component, it is not valid without previously configured authentication.
2. Apply accounting method list to a corresponding interface or line using accounting command. This
does not apply if accounting component is not configured in step 1.
Limitations of TACACS+ and RADIUS
RADIUS is not suitable to be used in the following situations:

Multiprotocol access environments – RADIUS does not support protocols such as ARA, NBFCP, NASI
and X.25 PAD connections.
Device-to-device situations – RADIUS does not offer two-way authentication. It works strictly in a client-
server mode where authentication may only be started from the client side and where server always
authenticates the client. If you have two devices that need to mutually authenticate each other, RADIUS is
not an appropriate solution.
Networks using multiple services – RADIUS generally binds a user to a single service model. Access-
Request RADIUS packet contains information about a type of session you want to use. There are two
session types that may be initiated – character mode (used for the Telnet service) and PPP mode (used for
the PPP protocol). In character mode your session will typically terminate on a device for the administrative
purposes (i.e. to access CLI). In PPP mode your session will terminate on a NAS, but your goal is to access
network resources behind the NAS. Single RADIUS server can’t bind a user simultaneously to character
and PPP mode.
TACACS+ is not suitable to be used in the following situations:
Multivendor environment – TACACS+ is a Cisco proprietary protocol developed as a completely new
version of the older TACACS protocol. Some vendors may not support it although Cisco has published
TACACS+ specification in a form of a draft RFC.
When speed of response from the AAA services is of concern – TACACS+ uses TCP as a transport
protocol mechanism. TCP is a connection-oriented protocol which means connection between two
endpoints has to be established before the data can start to flow. This mechanism consumes precious time
and TACACS+ might not be the best option if you need fast response from the AAA services.
Identity-Based Networking
Identity-Based Networking is a concept that unites several authentication, access control, and user policy
components with the aim to provide users with the network services that they are entitled to.
Traditional LAN security depends on physical security of the network ports. In order to gain access to the
accounting VLAN, a user has to walk into accounting department and plug the device in an ethernet port.
With user mobility as one of the core requirements of modern enterprise networks, this dependency is no
longer practical, and does not provide sufficient security.
Identity-based networking allows you to verify users once they connect to a switch port. Identity-based
networking authenticates users and places them in the right VLAN based on their identity. Should any users
fail to pass the authentication process, their access can be rejected, or they might be simply put in a guest
VLAN.
The IEEE 802.1x standard allows you to implement the identity-based networking in your LAN for both
physical and wireless connections.
IEEE 802.1x Port-Based Authentication Overview
The IEEE 802.1x standard defines a client-server based access control and authentication protocol that
prevents unauthorized clients from connecting to a LAN through switch ports unless they are properly
authenticated. The authentication server authenticates each client connected to a switch port before any
services offered by the switch or the LAN behind it are made available.
Until the client is authenticated, 802.1x access control allows only EAPOL, Cisco Discovery Protocol, and
STP traffic passing through the port to which the client is connected. After authentication is successful,
normal traffic can pass through the port.
Client is usually a workstation with 802.1x compliant client software. It is already included in all modern
operating systems. Client requests access to the LAN and switch services and responds to the requests from
the Authenticator. Client is also called supplicant in 802.1x terminology.
Authenticator, usually an edge switch or wireless access point, controls the physical access to the network
based on the authentication status of the client. The switch acts as an intermediary (proxy) between the
client and the authentication server, requesting identity information from the client, verifying that
information with the authentication server, and relaying a response to the client. Authenticator includes a
RADIUS client, which is responsible for encapsulation and decapsulation of EAP frames and interaction
with the authentication server.
Authentication server performs the actual authentication of the client. Authentication server validates the
identity of the client and notifies the authenticator whether or not the client is authorized to access LAN and
switch services. Since authenticator acts as a proxy, authentication service is transparent to the client.
Currently, RADIUS server with EAP extensions is the only supported authentication server.
Both switch and the client can initiate authentication. Switch initiates authentication when the link state
changes from down to up or periodically as long as the port remains up and unauthenticated. The switch
sends an EAP-request/identity frame to the client to request its identity. Upon receipt of the frame, the client
responds with an EAP-response/identity frame.
However, if EAP-request/identity is sent while the client is in the bootup phase, the client does not receive
it. Client can than initiate authentication by sending an EAPOL-start frame, which prompts the switch to
request the client's identity.
When the client supplies its identity, the switch begins its role as the intermediary, passing EAP frames
between the client and the authentication server until authentication succeeds or fails. When a client is
successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to
flow normally.
When a client logs off, it sends an EAPOL-logoff message, causing the switch port to change back to the
unauthorized state. Additionally, if the link state of a port changes from up to down, the port returns to the
unauthorized state.
IEEE 802.1x Configuration Checklist
802.1x authentication demands an enabled AAA and a configured RADIUS server:

Switch(config)# aaa new-model
Switch(config)# radius server host 172.16.1.1 key cisco456
Switch(config)# aaa group server radius Mygroup3
Switch(config-sg-radius)# server 172.16.1.1
Create a default 802.1X authentication method list:

Switch(config)# aaa authentication dot1x default group Mygroup3
Enable 802.1X authentication on the switch:

Switch(config)# dot1x system-auth-control
Enable 802.1X authentication on the FastEthernet0/8 interface:

Switch(config)# interface FastEthernet0/8
Switch(config-if)# dot1x port-control auto
Note You will not be able to issue dot1x commands on the interface if it is not set to
switchport mode access.
Summary
References
• AAA Overview: http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html
• TACACS+ and RADIUS Comparison: http://www.cisco.com/c/en/us/support/docs/security-
vpn/remote-authentication-dial-user-service-radius/13838-10.html
• Configuring RADIUS: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_rad/configuration/15-
mt/sec-usr-rad-15-mt-book/sec-cfg-radius.html
• Configuring TACACS: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_tacacs/configuration/15-
mt/sec-cfg-tacacs.html
• Configuring IEEE 802.1x Port-Based Authentication:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/15.0_1_se/config
uration/guide/sw8021x.html
Lesson 4: Mitigating
Spoofing Attacks
Overview
By spoofing, or pretending to be another machine, the attacker can redirect part or all the traffic coming
from, or going to, a predefined target. After the attack, all traffic from the device under attack flows through
the computer of the attacker and then to its destination.
Spoofing attack can affect devices that are connected to your Layer 2 network by sending false information
to devices that are connected to the same broadcast domain. Spoofing attacks can also intercept traffic that
is intended for other hosts in the same domain.
There are several mechanisms that can mitigate DHCP, MAC, and ARP spoofing threats, such as DHCP
snooping, IP Source Guard, and Dynamic ARP Inspection.

• Describe how can a rogue DHCP server harm your network
• Describe DHCP Snooping
• Configure and verify DHCP Snooping
• Describe what is IP Source Guard and why do you need it
• Configure IP Source Guard
• Explain ARP spoofing
• Describe how dynamic ARP inspection works
• Configure Dynamic ARP Inspection
DHCP Spoofing Attacks
DHCP server provides the basic information for the clients operation, such as IP address, subnet mask,
default gateway, etc. One of the ways that an attacker can gain access to network traffic is to bring a rogue
DHCP server in the same subnet as DHCP clients.
The DHCP spoofing device replies to client's DHCP requests. The legitimate server may also reply to
DHCP requests, but if the spoofing device is on the same segment as the client, its reply to the client may
arrive first, so legitimate server's reply is discarded by the client.
DHCP reply from the intruder offers an IP address and supporting information that designates the intruder
as the default gateway or DNS server. In the case of a gateway, the clients will then forward packets to the
attacking device, which will in turn send them to the desired destination. This is referred to as a man-in-the-
middle attack, and it may go entirely undetected as the intruder intercepts the data flow through the network.
DHCP Spoofing Attack Sequence

Sequence of Events Description
1. Attacker hosts a rogue DHCP server off a sw itch port to the same subnet as the clients.
2. Client broadcasts a request for DHCP configuration information.
3. The rogue DHCP server responds before the legitimate DHCP server, assigning attacker-
defined IP configuration information.
4. Host packets are redirected to the attacker’s address as it emulates a default gatew ay for
the erroneous IP address that is provided to the client via DHCP.
DHCP Snooping
DHCP snooping is a Cisco security feature, that protects against rogue and malicious DHCP servers. It
determines which switch ports can respond to DHCP requests.
DHCP snooping is a per-port security mechanism that is used to determine which switch port can respond to
DHCP requests. Ports are identified as trusted and untrusted. Trusted ports can source all DHCP messages,
whereas untrusted ports can source requests only. DHCP snooping allows only authorized DHCP servers to
respond to DHCP requests and to distribute network information to clients.
• Trusted ports host a DHCP server or can be an uplink toward the DHCP server.
• Untrusted ports are those that are not explicitly configured as trusted. From a DHCP snooping
perspective, untrusted access ports should not send any DHCP server responses, such as DHCPOFFER,
DHCPACK, or DHCPNAK. If a rogue device on an untrusted port attempts to send a DHCP response
packet into the network, the port is shut down. This feature can be coupled with DHCP option 82, in
which switch information, such as the port ID of the DHCP request, can be inserted into the DHCP
request packet.
DHCP Snooping Configuration
To mitigate the chances of DHCP spoofing, these procedures are recommended:

1 Enable DHCP snooping globally.
2 Enable DHCP snooping on selected VLANs.
3 Configure trusted interfaces, since untrusted is default.
4 Configure rate-limit of DHCP requests on untrusted ports.
5 Configure information option using DHCP option 82.
In the following example, DHCP snooping is globally enabled on SW and only PC's VLAN 10 has DHCP
snooping enabled. By default all ports are untrusted. Interface Ethernet0/0, port to trusted DHCP server, has
been configured as trusted port.
If you want to provide more information about the actual client that generated the DHCP request, configure
DHCP option 82 with the ip dhcp snooping information option command. This adds the switch port
identifier into the DHCP request.
To verify DHCP snooping, use the show ip dhcp snooping command. The output shows only trusted ports
or the ports with configured rate limit. In the example, DHCP snooping is enabled for VLAN 10 and only
Ethernet0/0 is specified as trusted.
SW# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled

circuit-id default format: vlan-mod-port
remote-id: 0024.f9c6.1a80 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow option Rate limit (pps)

----------------------- ------- ------------ ----------------
Ethernet0/0 yes yes unlimited
Custom circuit-ids:
To display all the known DHCP bindings that have been learned on a switch, use show ip dhcp snooping
binding command. In the example above, there are two PCs connected to the switch, so there is a binding
for each of them in the table:
SW# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- ----------
----------
00:24:13:47:AF:C2 192.168.1.4 85858 dhcp-snooping 10 Ethernet0/1
00:24:13:47:7D:B1 192.168.1.5 85859 dhcp-snooping 10 Ethernet0/2
Total number of bindings: 2
DHCP Snooping Commands
Step Com m ents
ip dhcp snooping Enables DHCP snooping globally. By

default, the feature is not enabled.
ip dhcp snooping information option Enables DHCP option 82. This is optional
for the forw arded DHCP request packet to
contain information on the sw itch port
w here it originated. The option is enabled
by default.
ip dhcp snooping vlan vlan-id [vlan-id] Identifies VLANs that w ill be subject to
DHCP snooping.
ip dhcp snooping trust Configures trusted port. Use the no

keyw ord to revert to untrusted. Use this
command in the interface configuration
mode.
ip dhcp snooping limit rate rate Configures the number of DHCP p/s that an
interface can receive. This ensures that
DHCP traffic w ill not overw helm the DHCP
servers. Normally, the rate limit applies to
untrusted interfaces. Use this command in
the interface configuration mode.
show ip dhcp snooping Verifies the configuration.
IP Source Guard
A host is assigned an IP address which it uses for all the traffic. A rogue PC can use a hijacked IP from the
neighbor or a random one, which is known as spoofed IP address. Such IP address spoofing is difficult to
mitigate, especially when it is used inside a subnet, the IP belongs to. IP Source Guard is a security feature,
that protects against IP address spoofing.
IP Source Guard dynamically maintains per-port VLAN ACLs based on IP-to-MAC-to-switch-port

bindings and is typically deployed on untrusted switch ports in the access layer.
At the beginning all IP traffic on the port is blocked, except for DHCP packets that are captured by the
DHCP snooping process. When a client receives a valid IP address from the DHCP server or when a static
IP source binding is configured by the user, a per-port and VLAN access control list (PVACL) is installed
on the port.
This process restricts the client IP traffic to those source IP addresses that is configured in the binding. Any
IP traffic with a source IP address other than that in the IP source binding will be filtered out. This filtering
limits the ability of a host to attack the network by claiming the IP address of a neighbor host.
Note If IP Source Guard is enabled on a trunk port with a large number of VLANs that have DHCP
snooping enabled, you might run out of ACL hardware resources, and some packets might
be switched in software.
IP source Guard supports only Layer 2 ports, including both access and trunk. For each untrusted port, there
are two possible levels of IP traffic security filterings:
• Source IP address filter: IP traffic is filtered based on its source IP address. Only IP traffic with a
source IP address that matches the IP source binding entry is permitted.
An IP source address filter is changed when a new IP source entry binding is created or deleted on the
port. The PVACL will be recalculated and reapplied in the hardware to reflect the IP source binding
change. By default, if the IP filter is enabled without any IP source binding on the port, a default
PVACL that denies all IP traffic is installed on the port. Similarly, when the IP filter is disabled, any IP
source filter PVACL will be removed from the interface.
• Source IP and MAC address filter: IP traffic is filtered based on its source IP address in addition to its
MAC address; only IP traffic with source IP and MAC addresses that match the IP source binding entry
are permitted.
IP Source Guard Configuration
IP Source Guard has to be enabled on a port. DHCP snooping is required to learn valid IP address and MAC
address pairs.
To enable IP Source Guard on the port use the ip verify source command.
In the example, both access ports, Ethernet0/1 and Ethernet0/2, are configured with IP Source Guard.
To verify the IP Source Guard configuration, use show ip verify source command. In the example, switch
access ports are configured with IP Source Guard, so both, Ethernet0/1 and Ethernet0/2 are listed in the
output. Each interface has one valid DHCP binding.
SW# show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- ----------------- ----
Et0/1 ip active 192.168.1.4 10
Et0/2 ip active 192.168.1.5 10
ARP Spoofing
Normally the host sends an ARP broadcast to determine the MAC address of a host with a particular IP
addresses. The device with this IP address replies with its MAC address, and the originating host caches the
ARP response.
By spoofing an ARP reply from a legitimate device, the attacking device appears as the destination host
seen by the senders. The attacker sends gratuitous ARP packet to the host, with the MAC address of the
attacker and the IP address of the particular host.
Note To support features such as Proxy ARP, source IP and MAC addresses in the ARP payload
may differ from the addresses in the IP and Ethernet header. Consequently IP Source Guard
does not protect against ARP spoofing attacks, as the attacker uses it's legitimate IP
address in the IP header and spoofed IP address in the ARP payload.
The ARP reply from the attacker causes the sender to store the MAC address of the attacking system in its
ARP cache. All packets that are destined for those IP addresses will be forwarded through the attacker
system. ARP poisoning leads to various man-in-the-middle attacks, posing a security threat in the network.
ARP Spoofing Attack
Step or Sequence Description
Num ber
1. PCA sends an ARP request for MAC address of R1.
2. R1 replies w ith its MAC and IP address. It also updates its ARP cache.
3. PCA binds MAC address of R1 to R1's IP address in its ARP cache.
4. Attacker sends it's ARP reply to PCA, binding it's MAC address to the IP of R1.
5. PCA updates ARP cache w ith MAC address of attacker bound to IP address of R1.
6. Attacker sends it's ARP reply to R1, binding it's MAC address to the IP of PCA.
7. R1 updates ARP cache w ith MAC address of attacker bound to IP address of PCA.
8. Packets are diverted through attacker.
Dynamic ARP Inspection
To prevent ARP spoofing or poisoning, a switch must ensure that only valid ARP requests and responses
are relayed.
In a typical attack, malicious user can send unsolicited ARP replies to other hosts on the subnet with the
MAC Address of the attacker and the IP address of the default gateway.
Dynamic ARP inspection helps prevent such attacks by not relaying invalid or gratuitous ARP replies out to
other ports in the same VLAN. Dynamic ARP inspection intercepts all ARP requests and all replies on the
untrusted ports. Each intercepted packet is verified for valid IP-to-MAC binding. ARP replies coming from
invalid devices are either dropped or logged by the switch for auditing so that ARP poisoning attacks are
prevented. You can also use DAI to rate-limit the ARP packets and then error-disable the interface if the
rate is exceeded.
DAI determines the validity of an ARP packet based on a valid MAC-address-to-IP-address bindings
database that is built by DHCP snooping. In addition, to handle hosts that use statically configured IP
addresses, DAI can validate ARP packets against user-configured ARP ACLs.
To ensure that only valid ARP requests and responses are relayed, DAI performs these tasks:
• Forwards ARP packets that are received on a trusted interface without any checks.
• Intercepts all ARP packets on untrusted ports.
• Verifies that each intercepted packet has a valid IP-to-MAC address binding before forwarding packets
that can update the local ARP cache.
• Drops, logs, or drops and logs ARP packets with invalid IP-to-MAC address bindings.
Configure all access switch ports as untrusted and all switch ports that are connected to other switches as
trusted. In this case, all ARP packets that are entering the network would be from an upstream distribution
or core switch, bypassing the security check and requiring no further validation.
DAI Configuration
It is generally advisable to configure all access switch ports as untrusted and to configure all uplink ports
that are connected to other switches as trusted.
To mitigate the chances of ARP spoofing, these procedures are recommended:

1 Implement protection against DHCP spoofing:
− Enable DHCP snooping globally.
− Enable DHCP snooping on selected VLANs.
2 Enable DAI:
− Enable ARP inspection on selected VLANs.
3 Configure trusted interfaces for DHCP snooping and ARP inspection (untrusted is default).
In the example above, SW has globally enabled DHCP snooping. DHCP snooping and ARP inspection are
enabled for PC's VLAN, VLAN10. Uplink, interface Ethernet0/0, is configured as trusted for DHCP
snooping and ARP inspection.
DAI Commands
ip arp inspection vlan vlan-id [,vlan-id] Enables DAI on a VLAN or range of VLANs
ip arp inspection trust Enables DAI on an interface and sets the interface as a trusted
interface
ip arp inspection validate Configures DAI to drop ARP packets w hen the IP addresses are
{[src-mac] [dst-mac] [ip]} invalid, or w hen the MAC addresses in the body of the ARP packets
do not match the addresses that are specified in the Ethernet header
Summary
Lesson 5: Securing VLAN
Trunks
Overview
Trunk links are formed between switches that you administer, and are therefore often considered secure.
Unfortunately, trunks are exposed to some attacks that can be used to gain access to a trunk itself or some of
the VLANs carried by a trunk. In this lesson you will expose some of the possible attacks and learn how to
prevent them.

• Describe the switch spoofing attack
• Protect your network against switch spoofing
• Describe the VLAN hopping attack
• Protect your network against the VLAN hopping attack
• Describe the need for VLAN Access Lists
• Describe how VLAN Access Lists interact with Standard and Port Access Lists
• Configure the VLAN Access Lists
Switch Spoofing
Typically two switches are connected with a common trunk link, which carries traffic from multiple
VLANs. A trunk link can be either manually configured on both sides of a link, or automatically negotiated
using the DTP. While use of DTP simplifies switch administration, it may lead to configuration errors and
switch port exposure.
Depending on the IOS version switch ports default to either dynamic desirable or dynamic auto DTP mode.
Default setting is convenient - when a switch is connected to a dynamic port, a trunk is formed after a DTP
negotiation. When a workstation is connected, it does not speak DTP, so switch port is turned into an access
port with a single access VLAN.
An attacker, however, might exploit the DTP and negotiate a trunk with the switch port. His PC will present
itself as a switch and attacker will gain access to any VLAN, that is permitted on this trunk, by default all
VLANs.
Protecting Against Switch Spoofing
Protection against switch spoofing is simple - every switch port must have a configured behavior.
DTP dynamic auto and dynamic desirable modes should be avoided. All ports should be configured either
as trunk or access ports, depending on the predicted usage:
SW(config-if)# switchport mode access
SW(config-if)# switchport access vlan vlan-id
Ports, that are not used should be administratively shut down, to prevent any unauthorized access:
SW(config-if)# shutdown
Depending on a network topology, trunk access might be limited, by allowing only certain VLANs on a
trunk port:
SW(config-if)# switchport trunk allowed vlan vlan-list
VLAN Hopping
An attacker connected to one of the access ports can send frames with spoofed 802.1Q tags, to send frames
to a different VLAN. The attack is called VLAN hopping or more specificly double tagging, and only
works under very specific conditions.
The attacker is connected to an access port of Switch A. All traffic between a workstation and an access port
would normally be untagged, but the attacker prepends it's payload with two 802.1Q tags, the outer one with
the VLAN the access port belongs to (VLAN 10 in the figure) and the inner one with the VLAN the attacker
wants to hop into (VLAN 20 in the figure).
Note Normally, a switch would not expect to receive tagged frames on an access port and would
discard the tagged frames. Modern switches, however, support technologies such as QoS
with CoS bits present in the 802.1Q header, or Q-in-Q tunneling, so they are accepting
tagged frames on access ports.
Frames are accepted by a switch if the outer VLAN tag matches the VLAN in which the access port is put
into. Tag (VLAN 10) is removed, and the payload, together with the inner tag (VLAN 20) is forwarded.
Frame is forwarded to a trunk. In order for the attack to succeed, trunk's native VLAN must match the
attacker's access port VLAN (10 in the figure). Only then is the frame sent over a trunk without the
additional VLAN tag prepended.
Switch B receives a frame, which now only has one tag in the header, so it considers frame being a part of a
VLAN, the attacker wants to hop in (VLAN 20). Switch B forwards the frame to the destination
workstation, which is located in VLAN 20. Attacker has thus successfully hopped from VLAN 10 to VLAN
20.
Protecting Against VLAN Hopping
VLAN hopping attacks are not easy to pull out, as they require specific native VLAN settings on a trunk.
They also have limited usability as VLAN hopping only works in one direction, thus preventing attacker to
establish TCP session. Nevertheless, protection against VLAN hopping attacks is simple, so you should
apply it whenever possible.
VLAN hopping attacks rely on a specific trunk configuration, therefore securing the trunk will close that
attack surface.
Attacker's access port VLAN must match the native VLAN of a trunk for attack to succed, so setting native
VLAN on all trunks to an unused value will close that attack vector:
SW(config-if)# switchport trunk native vlan vlan-id
Alternative is to prune the native VLAN on both ends of a trunk:

SW(config-if)# switchport trunk native vlan vlan-id
SW(config-if)# switchport trunk allowed vlan remove vlan-id
Note Maintenance protocols, such as Cisco Discovery Protocol and DTP are normally carried
over the native VLAN. Native VLAN pruning will not affect them, they will still communicate
on a prunned native VLAN.
Last option is to tag all frames, including native VLAN frames. This is done with the global configuration
command:
SW(config)# vlan dot1q tag native
VLAN Access Lists
VACLs can provide access control for all packets that are bridged within a VLAN or that are routed into or
out of a VLAN or a WAN interface for VACL capture. Unlike Cisco IOS Access Control Lists that are
applied on routed packets only, VACLs apply to all packets and can be applied to any VLAN or WAN
interface.
You can configure VACLs for IP and MAC-layer traffic. VACLs applied to WAN interfaces support only
IP traffic for VACL capture.
VLAN access maps can be applied to VLANs for VACL capture. Each VLAN access map can consist of
one or more map sequences; each sequence has a match clause and an action clause. The match clause
specifies IP or MAC ACLs for traffic filtering and the action clause specifies the action to be taken when a
match occurs. When a flow matches a permit ACL entry, the associated action is taken and the flow is not
checked against the remaining sequences. When a flow matches a deny ACL entry, it will be checked
against the next ACL in the same sequence or the next sequence. If a flow does not match any ACL entry
and at least one ACL is configured for that packet type, the packet is denied.
As with PACL, there are two types of VACL:

• IP access list filters IPv4 and IPv6 packets on a Layer 2 port.
• MAC access list filters packets that are of an unsupported type (not IP!) based on the fields of the
Ethernet datagram. A MAC access list is not applied to IP messages. You can define only named MAC
access lists.
Note VACLs have an implicit deny at the end of the map; a packet is denied if it does not match
any ACL entry, and at least one ACL is configured for the packet type.
VACL interaction with ACL and PACL
For an incoming packet on a physical port, the PACL is applied first. If the packet is permitted by the
PACL, the VACL on the ingress VLAN is applied next. If the packet is Layer 3 forwarded and is permitted
by the VACL, it is filtered by the Cisco IOS Access Control Lists on the same VLAN. The same process
happens in reverse in the egress direction. However, there is currently no hardware support for output
PACLs .
The PACLs override both the VACLs and Cisco IOS ACLs when the port is configured in prefer port mode.
The one exception to this rule is when the packets are forwarded in the software by the route processor. The
route processor applies the ingress Cisco IOS ACL regardless of the PACL mode. Two examples where the
packets are forwarded in the software are as follows:
• Packets that are egress bridged (due to logging or features such as NAT).
• Packets with IP options.
Configuring VACLs
VLAN ACLs are configured through the VLAN access maps and than applied to a VLAN.
Two types of ACLs can be configured as VACL, MAC access lists and IP access lists. There is an implicit
deny at the end of each list:
SW(config)# mac access-list extended acl-name
SW(config-ext-macl)# permit hos t [source-mac | any] [destination-mac | any]
SW(config)# ip access-list acl-type acl-name
SW(config-ext-nacl)# permit protocol [source-address | any] [destination-address |
any]
Configured ACLs are then used as a matching ACL inside a VLAN access map. When the traffic is matched
against a configured ACL, action is taken. The action clause in a VACL can be forward, drop, capture, or
redirect. Traffic can also be logged. There is an implicit drop at the end of the map:
SW(config)# vlan access-map map-name
SW(config-access-map)# match [mac | ip] address acl-name
SW(config-access-map)# action [drop | forward] [log]
VLAN access map can be applied to one or multiple VLANs, but only one VLAN access map can be
applied to each VLAN.
SW(config)# vlan filter map-name vlan-list [vlan-list | all]
Note You cannot apply a VACL to a secondary private VLAN. VACLs applied to primary private
VLANs also apply to secondary private VLANs.
Summary
References
• Double-Encapsulated 802.1Q VLAN attack:
www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#w
p39211
• VLAN ACLs: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-
2SY/configuration/guide/sy_swcg/vlan_acls.html
Lesson 6: Configuring
Private VLANs
Overview
There are cases when Layer 2 communication inside a single VLAN needs to be limited. A PVLAN
partitions the Layer 2 broadcast domain of a VLAN into subdomains, thus isolating the ports on the switch
from each other, while keeping them in the same subnet.

• Describe the need for Private VLANs.
• Describe the Private VLAN feature.
• Describe the Private VLAN port types.
• Configure Private VLANs.
• Verify Private VLAN configuration.
• Describe Private VLANs across multiple switches.
• Describe Protected Port feature.
The Need for Private VLANs
You are tasked to build a LAN for an upcoming conference held in your campus.
Hundreds of conference participants are expected, each of them requiring a wired Internet and conference
video server access. Participant's ports should be isolated and communication between the participants
forbidden.
VLAN is a broadcast domain. Inside a VLAN every device is allowed to communicate with every other
device on a data link layer, exposing local network devices to various security attacks (the figure on the
left). However, putting each user in his own VLAN (the figure on the right) would demand a separate
subnet for every user. In a typical network that resolves in hundreds of subnets, expand network routing
complexity, introduce configuration and management overhead, complicate DHCP operations, etc.
Is it possible to maintain a port isolation provided by the multi VLAN topology, yet keep the simplicity and
performance of a single broadcast domain?
Private VLAN Introduction
A PVLAN partitions the Layer 2 broadcast domain of a VLAN into subdomains, thus isolating the ports on
the switch from each other, while keeping them in the same subnet.
Private VLANs are essentially VLANs inside a VLAN. Different VLANs are not allowed to communicate
directly; a Layer 3 devices is needed to route packets between different VLANs. PVLANs follow the same
concept - a Layer 3 device is needed to route packets between different PVLANs. However, there is a
difference between VLANs and PVLANs. VLAN typically corresponds to an IP subnet. When VLAN is
partitioned into PVLANs, devices in different PVLANs still belong to the same IP subnet. They are,
however, unable to communicate with each other on Layer 2; all traffic has to be routed through a Layer 3
device, where additional security techniques, such as ACLs, can be applied.
PVLANs are an elegant solution when you need to keep multiple devices in the same IP subnet, yet provide
port isolation on Layer 2.
Private VLAN Port Types
A private VLAN domain has one primary VLAN. Each port in a private VLAN domain is a member of the
primary VLAN; the primary VLAN is the entire private VLAN domain.
Secondary VLANs are subdomains that provide isolation between ports within the same private VLAN
domain. There are two types of secundary VLANs: isolated VLANs and community VLANs. Isolated
VLANs contain isolated ports. Community VLANs contain community ports.
There are three types of PVLAN ports:

• Promiscuous - Promiscuous port belongs to the primary VLAN and can communicate with all mapped
ports in the primary VLAN, including community and isolated ports. A port, that provides uplink
connection to a router is configured as a promiscuous port, as all hosts need to communicate with the
router. There can be multiple promiscuous ports in a primary VLAN.
• Isolated - Isolated port is a host port that belongs to an isolated secondary VLAN. Isolated port has
complete isolation from other ports, except with associated promiscuous ports. You can have more than
one isolated port in a specified isolated VLAN. Each port is completely isolated from all other ports in
the isolated VLAN.
• Community - Community port is a host port that belongs to a community secondary VLAN.
Community ports communicate with other ports in the same community VLAN and with associated
promiscuous ports. They are isolated from all ports in other Community VLANs and all isolated ports.
In the figure, we have a VLAN 100, which serves as a primary VLAN, containing all switch ports. Router
facing switch port is configured as a promiscuous port, as it provides router connection for all other ports in
VLAN 100.
PC 1 and PC 2 are connected to isolated ports, which are part of the isolated secondary VLAN 101. PC 1
and PC 2 can communicate with the router, but they can not communicate with each other or any other PC,
even though they are in a common secondary VLAN.
PC 3 and PC 4 are connected to community ports, which are part of the community VLAN 102. PC 3 and
PC 4 can communicate with the router, and between each other. They are not able to communicate with PC
1 and PC 2 or any other host that might be in an isolated VLAN or any other community VLAN.
Private VLAN Configuration
To configure Private VLANs, primary and secondary VLANs must be configured first.
VTP must be set to transparent mode or off, before the PVLAN configuration is possible:
SW(config)# vtp mode transparent
Configure primary VLAN. You can use any vlan-id available:

SW(config)# vlan vlan-id
SW(config-vlan)# private-vlan primary
Configure secondary VLANs. Again, you can use any vlan-id available. Secondary VLANs can be either
isolated or community:
SW(config-vlan)# private-vlan isolated
SW(config-vlan)# private-vlan community
All secondary VLANs are subdomains of a primary VLAN, so you need to associate them with the primary
VLAN:
SW(config)# vlan primary-vlan-id
SW(config-vlan)# private-vlan association secondary-vlan-id {, secondary-vlan-id}
Once the primary and secondary VLANs are configured, you need to assign the ports to a proper VLAN.
Promiscuous ports are assigned to a single primary VLAN. Each promiscuous port can have several
secondary VLANs, or no secondary VLANs, associated to that port. You can associate a secondary VLAN
to more than one promiscuous port, as long as the promiscuous port and secondary VLANs are within the
same primary VLAN:
SW(config-if)# switchport mode private-vlan promiscuous
SW(config-if)# switchport private-vlan mapping primary-vlan-id add secondary-vlan-id
{, secondary-vlan-id}
Configure a range of host ports to become a part of secondary VLAN. If a secondary VLAN is isolated, all
ports will be isolated. If a secondary VLAN is community, all ports will be community. A host port can
only be a part of one secondary VLAN:
SW(config)# interface range interface-range
SW(config-if-range)# switchport mode private-vlan host
SW(config-if-range)# switchport private-vlan host-association primary-vlan-id
secondary-vlan-id
Private VLAN Verification
Private VLAN verification commands are mostly a subset of VLAN and interface verification commands.
Verify Private VLAN configuration, primary and secondary VLANs configured and port membership:
Private VLANs Across Multiple Switches
Private VLANs can span multiple switches. Different trunk port types can be used, depending on the type
and ability of a device on the other side of a trunk.
Standard trunk port carries the primary VLAN and secondary VLANs to a neighboring switch. The trunk
port relates to the PVLAN as any other VLAN. To maintain the security of your private VLANs and to
avoid other use of the VLANs configured as PVLANs, the configuration of PVLANs must match on all
intermediate devices, including devices that have no private VLAN ports.
Note As VTP does not support PVLANs, you must manually configure PVLANs on all switches in
the Layer 2 network.
Isolated PVLAN trunk port is used when connecting a PVLAN-enabled switch with a switch with no
PVLAN support, such as Catalyst 2950. Normal VLAN traffic is treated the same as on a standard trunk
port. Traffic tagged with VLAN which is configured as isolated, however, is treated the same as the traffic
from an isolated port—it is isolated from other isolated and community ports. Switch with isolated trunk
port can thus isolate between the traffic from the isolated trunk and directly connected hosts, but not
between hosts connected to the non-PVLAN switch.
Promiscuous PVLAN trunk port is used in a situation where a PVLAN promiscuous host port would
normally be used, but where it is necessary to carry multiple normal VLANs or PVLAN domains. An
upstream router without PVLAN support can be connected to a promiscuous trunk port. Traffic that is sent
out through a promiscuous trunk port is received by a router on a subinterface, just like any other VLAN
traffic.
Note Isolated and Promiscuous PVLAN trunk ports are only supported on modular switch
platforms such as Catalyst 4500 and 6500 series.
Protected Port Feature
Private VLAN feature is not available on all switches, for instance Catalyst 2950 does not support it.
Protected port feature provides a similar functionality on a wider range of Catalyst switches.
Protected port, also known as the PVLAN edge, is a feature that (unlike Private VLANs) has only local
significance to the switch. Protected ports do not forward any traffic to protected ports on the same switch.
This means that all traffic passing between protected ports—unicast, broadcast, and multicast—must be
forwarded through a Layer 3 device. Protected ports can forward any type of traffic to nonprotected ports,
and they forward as usual to all ports on other switches.
Configuration of a protected port is simple:
SW(config-if)# switchport protected
Note Protected ports are typically applied on access switches, which are than connected to a
distribution switch's isolated PVLAN trunk port.
Summary
References
• Configuring Isolated Private VLANs on Catalyst Switches:
http://www.cisco.com/c/en/us/support/docs/lan-switching/private-vlans-pvlans-promiscuous-isolated-
community/40781-194.html
• Configuring Private VLANs: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-
2/54sg/configuration/guide/config/pvlans.html
Check
1. Which feature that is supported on Cisco switches restricts a switch port to a specific set or number of
MAC addresses? (Source: Implementing Port Security)
A. DHCP snooping
B. PVLAN
C. Port Security
D. VACL
2. At which layer should port security be implemented? (Source: Implementing Port Security)
A. Access layer
B. Distribution layer
C. Core layer
D. All of the above
3. What is the aim of the “sticky” option when used with port security? (Source: Implementing Port
Security)
A. A learned MAC address must stick to one single port.
B. A dynamically learned MAC address is considered like a statically learned MAC address.
C. For a given MAC address with the sticky option, the port security feature applies to whichever port
the MAC address connects to.
D. A router on a stick can bypass the port security feature and use one MAC address per subinterface.
4. Storm Control feature controls which type of traffic? (Source: Implementing Storm Control)
A. Unicast
B. Broadcast
C. Multicast
D. All of the above
5. Which command enables 802.1X globally on a switch? (Source: Implementing Access to External
Authentication)
A. dot1x enable
B. dot1x port-contol auto
C. aaa dot1x enable
D. dot1x system-auth-control
6. What is the role of the switch in a AAA architecture? (Source: Implementing Access to External
Authentication)
A. authentication server
B. supplicant
C. authenticator
D. RADIUS entry point
7. The users in a department are using a variety of host platforms, some old and some new. All of them
have been approved with a user ID in a RADIUS server database. Which one of these features should be
used to restrict access to the switch ports in the building? (Source: Implementing Access to External
Authentication)
A. AAA authentication
B. AAA authorization
C. 802.1x
D. Port security
8. With DHCP snooping, which port is configured "trusted"? (Source: Mitigating Spoofing Attacks)
A. The port to the known DHCP server is always trusted.
B. The port to the DHCP client is always trusted.
C. With DHCP snooping you do not configure trusted ports.
D. Any port to the client and to the server can become trusted as soon as a DHCP transaction is secured.
9. Which two of the following does a switch use to detect spoofed addresses when IP Source Guard is
enabled? (Choose two.) (Source: Mitigating Spoofing Attacks)
A. ARP entries
B. DHCP database
C. DHCP snooping database
D. Static IP source binding entries
E. Reverse path-forwarding entries
10. By default Cisco IOS switch ports are put in one of two DTP port modes. Which two? (Choose two.)
(Source: Securing VLAN Trunks)
A. Access
B. Dynamic Desirable
C. Dynamic Auto
D. Trunk
E. Non negotiate
11. Which statements about VLAN hopping are correct? (Choose two.) (Source: Securing VLAN Trunks)
A. Catalyst switch discards VLAN tagged packets ingressing an access port.
B. Catalyst switch accepts VLAN tagged packets ingressing an access port if VLAN tag matches the
VLAN of the access port.
C. VLAN hopping attack with double tagging is only possible when attacker's access port is in the same
VLAN as the native VLAN of a trunk port.
D. VLAN hopping attack with double tagging is bidirectional - traffic can hop from attackers VLAN to
the target VLAN and vice versa.
E. Native VLAN pruning disables maintenance protocols, such as CDP and DTP.
622 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.© 2014 Cisco Systems, Inc.
12. Put the ACLs in order of operation for an incoming, routed packet. (Source: Securing VLAN Trunks)
1
A. Egress VLAN ACL
2
B. Egress SVI Standard ACL
3
C. Ingress Port ACL
4
D. Ingress SVI Standard ACL
5
E. Ingress VLAN ACL
Not applied
F. Egress Port ACL
13. There are two types of secondary private VLANs. Which two? (Choose two.) (Source: Configuring
Private VLANs)
A. Promiscuous
B. Primary
C. Transparent
D. Isolated
E. Community
14. Which statement about PVLAN promiscuous mode are correct? (Choose two.) (Source: Configuring
Private VLANs)
A. Promiscuous port can be mapped to a single primary VLAN.
B. Promiscuous port can be mapped to multiple primary VLANs.
C. Promiscuous port can always communicate with all ports in the same primary VLAN.
D. Promiscuous port can only communicate with the ports in secondary VLANs it is mapped to.
15. Match each port type to its definition. (Source: Configuring Private VLANs)
Cannot communicate with protected ports on the
A. Standard trunk port same switch.
Connects PVLAN enabled Switch with an
B. Isolated port
upstream Router with no PVLAN support.
Connects two devices with PVLANs configured.
C. Community port
Has complete isolation from other ports, except
D. Protected ports
with associated promiscuous ports.
Can communicate with associated promiscuous
E. Promiscuous PVLAN
ports.
trunk port
© 2014 Cisco Systems, Inc.© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 623
Glossary
broadcast domain
Set of all devices that receive broadcast frames originating from any device within the set. Broadcast
domains typically are bounded by routers because routers do not forward broadcast frames.
MAC address
Standardized data link layer address that is required for every port or device that connects to a LAN. Other
devices in the network use these addresses to locate specific ports in the network and to create and update
routing tables and data structures. MAC addresses are 6 bytes long and are controlled by the IEEE. Also
known as a hardware address, MAC layer address, and physical address.
VLAN
virtual LAN. Group of devices on one or more LANs that are configured (using management software) so
that they can communicate as if they were attached to the same wire, when in fact they are located on a
number of different LAN segments. Because VLANs are based on logical instead of physical connections,
they are extremely flexible.
624 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.© 2014 Cisco Systems, Inc.

Switch SG

Uploaded by

Copyright:

Switch SG

Uploaded by

Document Information

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Switch SG

Uploaded by

Copyright:

SWITCH

Americas Headquarters Asia Pacific Headquarters Europe Headquarters

© 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH i

ii Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

iv Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH v

vi Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Learner Skills and Knowledge

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 1

2 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 3

4 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 5

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 7

8 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

How do you know if your network has a good design?

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 9

10 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 11

12 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 13

14 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 15

16 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 17

18 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 19

20 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 21

22 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Decisions about these three questions get answered as follows:

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 23

24 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Decisions about these three questions get answers as follows:

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 25

26 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 27

28 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 29

PC1 10.1.1.1 Eth0/0 Sw itch1 Eth0/0

PC2 10.1.1.2 Eth0/0 Sw itch1 Eth0/1

PC3 10.1.1.3 Eth0/0 Sw itch1 Eth0/2

Sw itch1 n/a Eth1/1 n/a n/a

Reply to request 0 from 10.1.1.3, 1 ms

30 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

Use the show mac address-table command.

Switch1# show mac address-table

Vlan Mac Address Type Ports

Use the command show mac address-table interface Ethernet 1/1.

Switch1# show mac address-table interface ethernet 1/1

Vlan Mac Address Type Ports

Step 5 Issue show cdp neighbor command on Switch1.

© 2014 Cisco Systems, Inc. Implementing Cisco IP Switched Networks SWITCH 31

Device ID Local Intrfce Holdtme Capability Platform Port ID

CAM Aging Time

By default, the aging time is 300 seconds:

Switch1# show mac address-table aging-time

Step 7 Change CAM aging time on Switch1 to 600 seconds.

Switch1# show mac address-table aging-time

32 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

34 Implementing Cisco IP Switched Networks SWITCH © 2014 Cisco Systems, Inc.

A Cisco router can use one of three methods to forward packets: