CCIE Routing And Switching V5.0 Official Cert Guide, Volume 1, 5/e & V5 Guide.Volume.1.5th.Edition

User Manual:

Open the PDF directly: View PDF .
Page Count: 957 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Contents
Introduction
Part I: LAN Switching
Part II: IP Networking
- Chapter 4 IP Addressing
- Chapter 5 IP Services
Part III: IP IGP Routing
Part IV: Final Preparation
- Chapter 12 Final Preparation
Part V: Appendixes
- Appendix A: Answers to the “Do I Know This Already?” Quizzes
- Appendix B: CCIE Exam Updates
Index
- A
- B
- C
- D
- E
- F
- G
- H
- I
- J-K
- L
- M
- N
- O
- P
- Q
- R
- S
- T
- U
- V
- W
- X-Y-Z
CD-Only
Glossary
- A
- B
- C
- D
- E
- F
- G
- H
- I
- K
- L
- M
- N
- O
- P
- Q
- R
- S
- T
- U
- V

ptg13046388

Cisco Press

800 East 96th Street

Indianapolis, IN 46240

CCIE Routing and

Switching v5.0 Official

Cert Guide, Volume 1

Fifth Edition

Narbik Kocharians, CCIE No. 12410

Peter Palúch, CCIE No. 23527

ptg13046388

CCIE Routing and Switching v5.0 Official Cert Guide,

Volume 1, Fifth Edition

Narbik Kocharians, CCIE No. 12410

Peter Palúch, CCIE No. 23527

Published by:

Cisco Press

800 East 96th Street

Indianapolis, IN 46240 USA

electronic or mechanical, including photocopying, recording, or by any information storage and retrieval

system, without written permission from the publisher, except for the inclusion of brief quotations in a

review.

Printed in the United States of America

First Printing August 2014

Library of Congress Control Number: 2014944345

ISBN-13: 978-1-58714-396-0

ISBN-10: 1-58714-396-8

Warning and Disclaimer

This book is designed to provide information about Cisco CCIE Routing and Switching Written Exam,

No. 400-101. Every effort has been made to make this book as complete and as accurate as possible, but

no warranty or fitness is implied.

The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc. shall

have neither liability nor responsibility to any person or entity with respect to any loss or damages arising

from the information contained in this book or from the use of the discs or programs that may accom-

pany it.

The opinions expressed in this book belong to the authors and are not necessarily those of Cisco

Systems, Inc.

ptg13046388

Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have been appropri-

ately capitalized. Cisco Press or Cisco Systems, Inc., cannot attest to the accuracy of this information.

Use of a term in this book should not be regarded as affecting the validity of any trademark or service

mark.

Special Sales

For information about buying this title in bulk quantities, or for special sales opportunities (which may

include electronic versions; custom cover designs; and content particular to your business, training

goals, marketing focus, or branding interests), please contact our corporate sales department at

corpsales@pearsoned.com or (800) 382-3419.

For government sales inquiries, please contact governmentsales@pearsoned.com .

For questions about sales outside the U.S., please contact international@pearsoned.com .

Feedback Information

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book

is crafted with care and precision, undergoing rigorous development that involves the unique expertise of

members from the professional technical community.

Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we

could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us

through email at feedback@ciscopress.com . Please make sure to include the book title and ISBN in your

message.

We greatly appreciate your assistance.

Publisher: Paul Boger

Associate Publisher: Dave Dusthimer

Business Operation Manager, Cisco Press:

Jan Cornelssen

Executive Editor: Brett Bartow

Managing Editor: Sandra Schroeder

Senior Development Editor:

Christopher Cleveland

Senior Project Editor: Tonya Simpson

Copy Editor: John Edwards

Technical Editors: Paul Negron, Sean Wilkins

Editorial Assistant: Vanessa Evans

Cover Designer: Mark Shirar

Composition : Tricia Bronkella

Indexer: Tim Wright

Proofreader: Chuck Hutchinson

ptg13046388

iv CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

About the Authors

Narbik Kocharians , CCIE No. 12410 (Routing and Switching, Security, SP), is a Triple

CCIE with more than 32 years of experience in the IT industry. He has designed,

implemented, and supported numerous enterprise networks. Narbik is the president of

Micronics Training Inc. ( www.micronicstraining.com ), where he teaches CCIE R&S and

SP boot camps.

Peter Palúch , CCIE No. 23527 (Routing and Switching), is an assistant professor, Cisco

Networking Academy instructor, and instructor trainer at the Faculty of Management

Science and Informatics, University of Zilina, Slovakia. Peter has cooperated in various

educational activities in Slovakia and abroad, focusing on networking and Linux-based

network server systems. He is also active at the Cisco Support Community, holding the

Cisco Designated VIP award in LAN & WAN Routing and Switching areas since the

award program inception in 2011. Upon invitation by Cisco in 2012, Peter joined two Job

Task Analysis groups that assisted defining the upcoming CCIE R&S and CCNP R&S cer-

tification exam topics. Peter holds an M.Sc. degree in Applied Informatics and a doctoral

degree in the area of VoIP quality degradation factors. Together with his students, Peter

has started the project of implementing the EIGRP routing protocol into the Quagga

open-source routing software suite, and has been driving the effort since its inception in

2013.

ptg13046388

About the Technical Reviewers

Paul Negron , CCIE No. 14856, CCSI No. 22752, has been affiliated with networking

technologies for 17 years and has been involved with the design of core network ser-

vices for a number of service providers, such as Comcast, Qwest, British Telecom, and

Savvis to name a few. He currently instructs all the CCNP Service Provider–level courses,

including Advanced BGP, MPLS, and the QoS course. Paul has six years of experience

with satellite communications as well as ten years of experience with Cisco platforms.

Sean Wilkins is an accomplished networking consultant for SR-W Consulting

( www.sr-wconsulting.com ) and has been in the field of IT since the mid 1990s, working

with companies such as Cisco, Lucent, Verizon, and AT&T as well as several other private

companies. Sean currently holds certifications with Cisco (CCNP/CCDP), Microsoft

(MCSE), and CompTIA (A+ and Network+). He also has a Master of Science in informa-

tion technology with a focus in network architecture and design, a Master of Science

in organizational management, a Master’s Certificate in network security, a Bachelor of

Science in computer networking, and Associates of Applied Science in computer infor-

mation systems. In addition to working as a consultant, Sean spends most of his time as a

technical writer and editor for various companies; check out this work at his author web-

site: www.infodispersion.com .

ptg13046388

vi CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Dedications

From Narbik Kocharians:

I would like to dedicate this book to my wife, Janet, for her love, encouragement, and

continuous support, and to my dad for his words of wisdom.

From Peter Palúch:

To my family, students, colleagues, and friends.

ptg13046388

vii

Acknowledgments

From Narbik Kocharians:

First, I would like to thank God for giving me the opportunity and ability to write, teach,

and do what I truly enjoy doing. Also, I would like to thank my family, especially my

wife of 29 years, Janet, for her constant encouragement and help. She does such an amaz-

ing job of interacting with students and handling all the logistics of organizing classes as

I focus on teaching. I also would like to thank my children, Chris, Patrick, Alexandra, and

my little one, Daniel, for their patience.

A special thanks goes to Mr. Brett Bartow for his patience and our constant changing

of the deadlines. It goes without saying that the technical editors and reviewers did a

phenomenal job; thank you very much. Finally, I would like to thank all my students who

inspire me every day, and you, for reading this book.

From Peter Palúch:

The opportunity to cooperate on the new edition of this book has been an honor and

privilege beyond words for me. Wendell Odom, who has so gracefully and generously

passed the torch to us, was the key person in introducing me to the Cisco Press repre-

sentatives as a possible author, and I will be forever indebted to him for all the trust he

has blessed us with. I have strived very much to live up to the unparalelled high level of

content all previous authors have maintained throughout all editions of this book, and I

would like to sincerely thank all of them for authoring such a great book that has signifi-

cantly helped me achieve my certification in the first place.

My next immense thank you goes to Brett Bartow, the executive editor for this book.

Brett’s inviting and forthcoming attitude throughout the time of editing the book, com-

pounded with his patience and understanding for my ever-moving (and constantly missed)

deadlines, is second to none. He has done all in his power to help us, the authors, without

compromising the quality of the work.

I would not have been able to complete my work on this volume without the endless sup-

port of my family. They have encouraged me, supported me, and gone out of their way to

accommodate my needs. Words are not enough to express my gratitude.

Psalm 127, whose musical setting in works of Monteverdi, Handel, or Vivaldi I have

come to admire, begins with words “Unless the Lord build the house, they labor in vain

who build.” Indeed, if it was not first and foremost the Lord’s blessing and help through-

out, this work would not have been finished successfully. To my Lord and Savior, Jesus

Christ—thank you!

ptg13046388

viii CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Contents at a Glance

Introduction xxiv

Part I LAN Switching

Chapter 1 Ethernet Basics 3

Chapter 2 Virtual LANs and VLAN Trunking 47

Chapter 3 Spanning Tree Protocol 103

Part II IP Networking

Chapter 4 IP Addressing 183

Chapter 5 IP Services 227

Part III IP IGP Routing

Chapter 6 IP Forwarding (Routing) 267

Chapter 7 RIPv2 and RIPng 313

Chapter 8 EIGRP 347

Chapter 9 OSPF 453

Chapter 10 IS-IS 563

Chapter 11 IGP Route Redistribution, Route Summarization, Default Routing, and

Troubleshooting 633

Part IV Final Preparation

Chapter 12 Final Preparation 701

Part V Appendixes

Appendix A Answers to the “Do I Know This Already?” Quizzes 707

Appendix B CCIE Exam Updates 713

Index 714

CD-Only

Appendix C Decimal to Binary Conversion Table

Appendix D IP Addressing Practice

Appendix E Key Tables for CCIE Study

Appendix F Solutions for Key Tables for CCIE Study

Appendix G Study Planner

Glossary

ptg13046388

Contents

Introduction xxiv

Part I LAN Switching

Chapter 1 Ethernet Basics 3

“Do I Know This Already?” Quiz 3

Foundation Topics 8

Ethernet Layer 1: Wiring, Speed, and Duplex 8

RJ-45 Pinouts and Category 5 Wiring 8

Autonegotiation, Speed, and Duplex 9

CSMA/CD 10

Collision Domains and Switch Buffering 10

Basic Switch Port Configuration 11

Ethernet Layer 2: Framing and Addressing 14

Types of Ethernet Addresses 16

Ethernet Address Formats 17

Protocol Types and the 802.3 Length Field 18

Switching and Bridging Logic 19

SPAN, RSPAN, and ERSPAN 22

Core Concepts of SPAN, RSPAN, and ERSPAN 23

Restrictions and Conditions 24

Basic SPAN Configuration 26

Complex SPAN Configuration 26

RSPAN Configuration 26

ERSPAN Configuration 27

Virtual Switch System 28

Virtual Switching System 29

VSS Active and VSS Standby Switch 30

Virtual Switch Link 30

Multichassis EtherChannel (MEC) 31

Basic VSS Configuration 31

VSS Verification Procedures 35

IOS-XE 38

Foundation Summary 41

ptg13046388

x CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Memory Builders 44

Fill In Key Tables from Memory 44

Definitions 44

Further Reading

For a good reference for more information on the actual FLPs used by autonegotia-

tion, refer to the Fast Ethernet web page of the University of New Hampshire Research

Computing Center’s InterOperability Laboratory, at www.iol.unh.edu/services/testing/fe/

training/ .

For information about configuring SPAN and RSPAN, and for a full set of restrictions

(specific to the 3560 and 3750), see www.ciscosystems.com/en/US/docs/switches/lan/

catalyst3560/software/release/12.2_50_se/configuration/guide/swspan.html .

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ VLANs

■ VLAN Trunking

■ VLAN Trunking Protocol (VTP)

■ PPP over Ethernet (PPPoE)

ptg13046388

This chapter continues with the coverage of some of the most fundamental and impor-

tant LAN topics with coverage of VLANs and VLAN trunking. As usual, for those of

you current in your knowledge of the topics in this chapter, review the items next to the

Key Topic icons spread throughout the chapter, plus the “Foundation Summary” and

“Memory Builders” sections at the end of the chapter.

“Do I Know This Already?” Quiz

Table 2-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 2-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in This Section Score

Virtual LANs 1–2

VLAN Trunking Protocol 3–5

VLAN Trunking: ISL and 802.1Q 6–9

Configuring PPPoE 10

Total Score

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. Assume that VLAN 28 does not yet exist on Switch1. Which of the following com-

mands, issued in the global configuration mode (reached with the configure terminal

command) or any of its submodes would cause the VLAN to be created?

a. vlan 28

b. vlan 28 name fred

c. switchport vlan 28

d. switchport access vlan 28

e. switchport access 28

CHAPTER 2

Virtual LANs and VLAN Trunking

ptg13046388

48 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

2. Which of the following are advantages of using Private VLANs?

a. Better LAN security

b. IP subnet conservation

c. Better consistency in VLAN configuration details

d. Reducing the impact of broadcasts on end-user devices

e. Reducing the unnecessary flow of frames to switches that do not have any ports

in the VLAN to which the frame belongs

3. Which of the following VLANs can be pruned by VTP on an 802.1Q trunk?

a. 1–1023

b. 1–1001

c. 2–1001

d. 1–1005

e. 2–1005

4. An existing switched network has ten switches, with Switch1 and Switch2 being the

only VTPv2 servers in the network. The other switches are all VTPv2 clients and

have successfully learned about the VLANs from the VTPv2 servers. The only con-

figured VTP parameter on all switches is the VTP domain name (Larry). The VTP

revision number is 201. What happens when a new, already-running VTPv2 client

switch, named Switch11, with domain name Larry and revision number 301, con-

nects through a trunk to any of the other ten switches?

a. No VLAN information changes; Switch11 ignores the VTP updates sent from

the two existing VTP servers until the revision number reaches 302.

b. The original ten switches replace their old VLAN configuration with the con-

figuration in Switch11.

c. Switch11 replaces its own VLAN configuration with the configuration sent to it

by one of the original VTP servers.

d. Switch11 merges its existing VLAN database with the database learned from the

VTP servers, because Switch11 had a higher revision number.

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 49

5. An existing switched network has ten switches, with Switch1 and Switch2 being

the only VTPv3 servers in the network, and Switch1 being the primary server. The

other switches are all VTPv3 clients, and have successfully learned about the VLANs

from the VTP server. The only configured VTP parameter is the VTP domain name

(Larry). The VTP revision number is 201. What happens when an already-running

VTPv3 server switch, named Switch11, with domain name Larry and revision number

301, connects through a trunk to any of the other ten switches?

a. No VLAN information changes; all VTP updates between the original VTP

domain and the new switch are ignored.

b. The original ten switches replace their old VLAN configuration with the con-

figuration in Switch11.

c. Switch11 replaces its old VLAN configuration with the configuration sent to it

by one of the original VTP servers.

d. Switch11 merges its existing VLAN database with the database learned from the

VTP servers, because Switch11 had a higher revision number.

e. None of the other answers is correct.

6. Assume that two brand-new Cisco switches were removed from their cardboard

boxes. PC1 was attached to one switch, PC2 was attached to the other, and the two

switches were connected with a cross-over cable. The switch connection dynamically

formed an 802.1Q trunk. When PC1 sends a frame to PC2, how many additional

bytes of header are added to the frame before it passes over the trunk?

a. 0

b. 4

c. 8

d. 2 6

7. Assume that two brand-new Cisco Catalyst 3560 switches were connected with a

cross-over cable. Before the cable was attached, one switch interface was config-

ured with the switchport trunk encapsulation dot1q , switchport mode trunk , and

switchport nonegotiate subcommands. Which of the following must be configured

on the other switch before trunking will work between the switches?

a. switchport trunk encapsulation dot1q

b. switchport mode trunk

c. switchport nonegotiate

d. No configuration is required.

ptg13046388

50 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

8. When configuring trunking on a Cisco router Fa0/1 interface, under which configu-

ration modes could the IP address associated with the native VLAN (VLAN 1 in this

case) be configured?

a. Interface Fa0/1 configuration mode

b. Interface Fa0/1.1 configuration mode

c. Interface Fa0/1.2 configuration mode

d. None of the other answers is correct.

9. Which of the following about 802.1Q are false?

a. Encapsulates the entire frame inside an 802.1Q header and trailer

b. Has a concept of a native VLAN

c. Allows VTP to operate only on extended-range VLANs

d. Is chosen over ISL by DTP

10. Which command enables PPPoE client functionality on the outside Ethernet inter-

face on a Cisco router?

a. pppoe enable

b. pppoe-client enable

c. pppoe-client dialer-pool-number

d. pppoe-client dialer-number

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 51

Foundation Topics

Virtual LANs

In an Ethernet LAN, a set of devices that receive a broadcast sent by any one of the

devices in the same set is called a broadcast domain . On switches that have no con-

cept of virtual LANs (VLAN), a switch simply forwards all broadcasts out all interfaces,

except the interface on which it received the frame. As a result, all the interfaces on an

individual switch are in the same broadcast domain. Also, if the switch connects to other

switches and hubs, the interfaces on those switches and hubs are also in the same broad-

cast domain.

A VLAN is simply an administratively defined subset of switch ports that are in the same

broadcast domain. Ports can be grouped into different VLANs on a single switch, and on

multiple interconnected switches as well. By creating multiple VLANs, the switches cre-

ate multiple, yet contained, broadcast domains. By doing so, a broadcast sent by a device

in one VLAN is forwarded to the other devices in that same VLAN; however, the broad-

cast is not forwarded to devices in the other VLANs.

With VLANs and IP, best practices dictate a one-to-one relationship between VLANs

and IP subnets. Simply put, the devices in a single VLAN are typically also in the same

single IP subnet. Alternately, it is possible to put multiple subnets in one VLAN, and use

secondary IP addresses on routers to route between the VLANs and subnets. Ultimately,

the CCIE written exams tend to focus more on the best use of technologies, so this book

will assume that one subnet sits on one VLAN, unless otherwise stated.

Layer 2 switches forward frames between devices in the same VLAN, but they do not

forward frames between two devices in different VLANs. To forward data between

two VLANs, a multilayer switch (MLS) or router is needed. Chapter 6 , “IP Forwarding

(Routing),” covers the details of MLS.

VLAN Configuration

On Cisco IOS–based switches, a VLAN is primarily identified by its numerical ID, which

is the only mandatory argument when creating, modifying, or deleting a VLAN. A VLAN

can be assigned a verbal name for better orientation, but only a very few places in the

CLI allow substituting the VLAN name for its ID. Also, a VLAN has an operational state:

It can either be active , which is the default state, or it can be suspended . A suspended

VLAN is hibernated—while it exists, it does not operate. Access ports in a suspended

VLAN are unable to communicate and drop all frames, similar to ports put into a nonex-

istent VLAN. Putting a suspended VLAN back into the active state also reinstates normal

communication on all ports in that VLAN.

Key

Topic

ptg13046388

52 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Configuring VLANs in a network of Cisco switches requires just a few simple steps:

Step 1. Create the VLAN itself, optionally configuring its name and state.

Step 2. Associate the correct ports with that VLAN.

The challenge relates to how some background tasks differ depending on how the Cisco

VLAN Trunking Protocol (VTP) is configured, and whether normal-range or extended-

range VLANs are being used. We will discuss VTP and VLAN ranges in more detail later

in this chapter.

Using VLAN Database Mode to Create VLANs

To begin, consider Example 2-1 , which shows some of the basic mechanics of VLAN

creation in VLAN database configuration mode . While this configuration mode is

considered obsolete on recent switches and might not be supported at all, it might still

be used on older Catalyst platforms and on ISR and ISR G2 routers with switching mod-

ules installed. VLAN database configuration mode allows the creation of VLANs, basic

administrative settings for each VLAN, and verification of VTP configuration informa-

tion. Only normal-range (VLANs 1–1005) VLANs can be configured in this mode, and

the VLAN configuration is stored in a Flash file called vlan.dat. In general, the VLAN

database configuration mode should be avoided if possible, and hopefully you will not

need to use it anymore; however, there are still switches and even relatively recent routers

deployed in networks that do not support the newer way of configuring VLANs in global

configuration mode.

Example 2-1 demonstrates VLAN database configuration mode, showing the configura-

tion on Switch3 from Figure 2-1 . The example shows VLANs 21 and 22 being created.

PC1

Fa0/0 Gi0/1

VLAN 21

Subnet 10.1.21.x/24

VLAN 22

Subnet 10.1.22.x/24

Fa0/2

Fa0/7

Fa0/12 Fa0/24

Fa0/3

Fa0/1

Fa0/5

SW1

R1 R2

SW3

SW2

SW4

Figure 2-1 Simple Access and Distribution

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 53

Example 2-1 VLAN Creation in VLAN Database Mode – Switch3

! Below, note that Fa0/12 and Fa0/24 are missing from the list, because they have

! dynamically become trunks, supporting multiple VLANs.

Switch3# show vlan brief

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4

Fa0/5, Fa0/6, Fa0/7, Fa0/8

Fa0/9, Fa0/10, Fa0/11, Fa0/13

Fa0/14, Fa0/15, Fa0/16, Fa0/17

Fa0/18, Fa0/19, Fa0/20, Fa0/21

Fa0/22, Fa0/23

! Below, "unsup" means that this 2950 switch does not support FDDI and TR

1002 fddi-default act/unsup

1003 token-ring-default act/unsup

1004 fddinet-default act/unsup

1005 trnet-default act/unsup

! Below, vlan database moves user to VLAN database configuration mode.

! The vlan 21 command defines the VLAN, as seen in the next command output

! ( show current ), VLAN 21 is not in the "current" VLAN list.

Switch3# vlan database

Switch3(vlan)# vlan 21

VLAN 21 added:

Name: VLAN0021

! The show current command lists the VLANs available to the IOS when the switch

! is in VTP Server mode. The command lists the VLANs in numeric order, with

! VLAN 21 missing.

Switch3(vlan)# show current

VLAN ISL Id: 1

Name: default

Media Type: Ethernet

VLAN 802.10 Id: 100001

State: Operational

MTU: 1500

Backup CRF Mode: Disabled

Remote SPAN VLAN: No

Key

Topic

ptg13046388

54 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! Lines omitted for brevity

! Next, note that show proposed lists VLAN 21. The vlan 21 command

! creates the definition, but it must be "applied" before it is "current".

Switch3(vlan)# show proposed

VLAN ISL Id: 1

Name: default

Media Type: Ethernet

VLAN 802.10 Id: 100001

State: Operational

MTU: 1500

Backup CRF Mode: Disabled

Remote SPAN VLAN: No

VLAN ISL Id: 21

Name: VLAN0021

Media Type: Ethernet

VLAN 802.10 Id: 100021

State: Operational

MTU: 1500

Backup CRF Mode: Disabled

Remote SPAN VLAN: No

! Lines omitted for brevity

! Next, you could apply to complete the addition of VLAN 21,

! abort to not make the changes and exit VLAN database mode, or

! reset to not make the changes but stay in VLAN database mode.

Switch3(vlan)# ?

VLAN database editing buffer manipulation commands:

abort Exit mode without applying the changes

apply Apply current changes and bump revision number

exit Apply changes, bump revision number, and exit mode

no Negate a command or set its defaults

reset Abandon current changes and reread current database

show Show database information

vlan Add, delete, or modify values associated with a single VLAN

vtp Perform VTP administrative functions.

! The apply

command was used, making the addition of VLAN 21 complete.

Switch3(vlan)# apply

APPLY completed.

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 55

! A show current now would list VLAN 21.

Switch3(vlan)# vlan 22 name ccie-vlan-22

VLAN 22 added:

Name: ccie-vlan-22

! Above and below, some variations on commands are shown, along with the

! creation of VLAN 22, with name ccie-vlan-22 .

! Below, the vlan 22 option is used on show current and show proposed

! detailing the fact that the apply has not been done yet.

Switch3(vlan)# show current 22

VLAN 22 does not exist in current database

Switch3(vlan)# show proposed 22

VLAN ISL Id: 22

! Lines omitted for brevity

! Finally, the user exits VLAN database mode using CTRL-Z, which does

! not inherently apply the change. CTRL-Z actually executes an abort .

Switch3(vlan)# ^Z

Using Configuration Mode to Put Interfaces into VLANs

To put a VLAN to use, the VLAN must be created, and then switch ports must be

assigned to the VLAN. Example 2-2 shows how to associate the interfaces with the cor-

rect VLANs, once again on Switch3.

Note At the end of Example 2-1, VLAN 22 had not been successfully created. The

assumption for Example 2-2, however, is that VLAN 22 has been successfully created.

Example 2-2 Assigning Interfaces to VLANs – Switch3

! First, the switchport mode access command configures respective interfaces for

! static access mode, and the switchport access vlan command assigns them into

! respective VLANs.

Switch3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

Switch3(config)# int fa 0/3

Switch3(config-if)# switchport mode access

Switch3(config-if)# switchport access vlan 22

Key

Topic

ptg13046388

56 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Switch3(config-if)# int fa 0/7

Switch3(config-if)# switchport mode access

Switch3(config-if)# switchport access vlan 21

Switch3(config-if)# ^Z

! Below, show vlan brief lists these same two interfaces as now being in

! VLANs 21 and 22, respectively.

Switch3# show vlan brief

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/4, Fa0/5

Fa0/6, Fa0/8, Fa0/9, Fa0/10

Fa0/11, Fa0/13, Fa0/14, Fa0/15

Fa0/16, Fa0/17, Fa0/18, Fa0/19

Fa0/20, Fa0/21, Fa0/22, Fa0/23

21 VLAN0021 active Fa0/7

22 ccie-vlan-22 active Fa0/3

! Lines omitted for brevity

! While the VLAN configuration is not shown in the running-config at this point,

! the switchport access command that assigns the VLAN for the interface is in the

! configuration, as seen with the show run int fa 0/3 command.

Switch3# show run int fa 0/3

interface FastEthernet0/3

switchport access vlan 22

switchport mode access

Using Configuration Mode to Create VLANs

At this point, the two new VLANs (21 and 22) have been created on Switch3, and the

two interfaces are now in the correct VLANs. However, all recent Cisco IOS–based

switches support a different way to create VLANs, using configuration mode, as shown

in Example 2-3 . This is the preferred mode for configuring VLANs whenever supported,

and is the only mode that can be used to configure extended-range and Private VLANs.

All VLAN settings are performed in the vlan vlan-id mode accessed from global con-

figuration level. Configuration changes apply only after exiting the vlan mode; this is one

of the few IOS CLI contexts in which changes are not applied immediately after entering

individual commands.

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 57

Example 2-3 Creating VLANs in Configuration Mode – Switch3

! First, VLAN 31 did not exist when the switchport access vlan 31 command was

! issued. As a result, the switch both created the VLAN and put interface fa0/8

! into that VLAN. Then, the vlan 32 global command was used to create a

! VLAN from configuration mode, and the name subcommand was used to assign a

! non-default name.

Switch3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

Switch3(config)# int fa 0/8

Switch3(config-if)# switchport mode access

Switch3(config-if)# switchport access vlan 31

% Access VLAN does not exist. Creating vlan 31

Switch3(config-if)# exit

Switch3(config)# vlan 32

Switch3(config-vlan)# name ccie-vlan-32

Switch3(config-vlan)# ^Z

Switch3# show vlan brief

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/4, Fa0/5

Fa0/6, Fa0/9, Fa0/10, Fa0/11

Fa0/13, Fa0/14, Fa0/15, Fa0/16

Fa0/17, Fa0/18, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Fa0/23

21 VLAN0021 active Fa0/7

22 ccie-vlan-22 active Fa0/3

31 VLAN0031 active Fa0/8

32 ccie-vlan-32 active

! Portions omitted for brevity

Example 2-3 shows how the switchport access vlan subcommand creates the VLAN, as

needed, and assigns the interface to that VLAN. Note that in Example 2-3 , the show vlan

brief output lists Fa0/8 as being in VLAN 31. Because no ports have been assigned to

VLAN 32 as of yet, the final line in Example 2-3 simply does not list any interfaces.

Modifying the Operational State of VLANs

The state of a VLAN—active or suspended—can be manipulated both in vlan database

and in configuration mode. A VLAN can be suspended in two ways: globally in the

entire VTP domain and locally on a single switch without influencing its state through

Key

Topic

ptg13046388

58 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

VTP on other switches. The state suspend command, valid both in vlan database and in

configuration mode, is used to globally suspend a VLAN. Suspending a VLAN locally,

also called “locally shutting down the VLAN,” is accomplished using the shutdown com-

mand, and is supported only in the configuration mode in the VLAN context. Do not

confuse the shutdown command in the VLAN context with the same command avail-

able under interface Vlan mode, which has a different and unrelated meaning (shutting

down an SVI without further impairing the operation of the corresponding VLAN itself).

Global and local VLAN states can be configured independently, but for a VLAN to be

operational on a switch, it must be both globally and locally activated. Manipulating

the operational state of VLANs and the use of corresponding commands are shown in

greater detail in Example 2-4 .

Example 2-4 Modifying the Operational State of VLANs

! First, put the VLAN 21 to global suspended state in vlan database mode. The state

! will be propagated by VTP to all switches in the VTP domain if VTP is used.

Switch3# vlan database

Switch3(vlan)# vlan 21 state ?

active VLAN Active State

suspend VLAN Suspended State

Switch3(vlan)# vlan 21 state suspend

VLAN 31 modified:

State SUSPENDED

Switch3(vlan)# exit

APPLY completed.

Exiting....

! VLAN 21 will now be listed as suspended

Switch3# show vlan brief

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/4, Fa0/5

Fa0/6, Fa0/9, Fa0/10, Fa0/11

Fa0/13, Fa0/14, Fa0/15, Fa0/16

Fa0/17, Fa0/18, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Fa0/23

21 VLAN0021 suspended Fa0/7

! Portions omitted for brevity

! Now use the configuration mode to reactivate the VLAN

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 59

Switch3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

Switch3(config)# vlan 21

Switch3(config-vlan)# state active

Switch3(config-vlan)# exit

Switch3(config)# do show vlan brief

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/4, Fa0/5

Fa0/6, Fa0/9, Fa0/10, Fa0/11

Fa0/13, Fa0/14, Fa0/15, Fa0/16

Fa0/17, Fa0/18, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Fa0/23

21 VLAN0021 active Fa0/7

! Portions omitted for brevity

! To locally suspend a VLAN, enter its configuration context and issue

! the shutdown command, then exit. Alternatively, you may also use the

! shutdown vlan global level configuration command that has exactly

! the same effect. In the VLAN listing, the VLAN 21 will be reported as

! active in the VTP domain on other switches, yet locally shutdown.

! It is also possible to both use the state suspend to suspend the VLAN

! via VTP globally, and shutdown to also have it locally shut down.

Switch3(config)# vlan 21

Switch3(config-vlan)# shutdown

Switch3(config-vlan)# exit

Switch3(config)# do show vlan brief

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/4, Fa0/5

Fa0/6, Fa0/9, Fa0/10, Fa0/11

Fa0/13, Fa0/14, Fa0/15, Fa0/16

Fa0/17, Fa0/18, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Fa0/23

21 VLAN0021 act/lshut Fa0/7

! Portions omitted for brevity

! To reactivate the locally shut VLAN, enter the no shutdown command in vlan 21

! context, or more straightforward, enter the no shutdown vlan 21 command

Switch3(config)# no shutdown vlan 21

Switch3(config)# do show vlan brief

ptg13046388

60 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/4, Fa0/5

Fa0/6, Fa0/9, Fa0/10, Fa0/11

Fa0/13, Fa0/14, Fa0/15, Fa0/16

Fa0/17, Fa0/18, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Fa0/23

21 VLAN0021 active Fa0/7

! Portions omitted for brevity

The VLAN creation process is simple but laborious in a large network. If many VLANs

exist, and they exist on multiple switches, instead of manually configuring the VLANs on

each switch, you can use VTP to distribute the VLAN configuration of a VLAN to the

rest of the switches. VTP will be discussed later in the chapter.

Private VLANs

Engineers can design VLANs with many goals in mind. In many cases today, devices

end up in the same VLAN just based on the physical locations of the wiring drops.

Security is another motivating factor in VLAN design: Devices in different VLANs do

not overhear each other’s broadcasts and possibly other communication. Additionally, the

separation of hosts into different VLANs and subnets requires an intervening router or

multilayer switch between the subnets, and these types of devices typically provide more

robust security features.

Regardless of the design motivations behind grouping devices into VLANs, good design

practices typically call for the use of a single IP subnet per VLAN. In some cases, how-

ever, the need to increase security by separating devices into many small VLANs con-

flicts with the design goal of conserving the use of the available IP subnets. The Cisco

Private VLAN feature described in RFC 5517 addresses this issue. Private VLANs allow

a switch to separate ports as if they were on different VLANs, while consuming only a

single subnet.

A common place to implement Private VLANs is in the multitenant offerings of a service

provider (SP). The SP can install a single router and a single switch. Then, the SP attaches

devices from multiple customers to the switch. Private VLANs then allow the SP to use

only a single subnet for the entire building, separating different customers’ switch ports

so that they cannot communicate directly, while supporting all customers with a single

router and switch.

Conceptually, a Private VLAN is a mechanism that partitions a given VLAN into an

arbitrary number of nonoverlapping sub-VLANs, or secondary VLANs . This partition-

ing is invisible to the outside world that continues to see only the original VLAN, in this

context called the primary VLAN . An important consequence of this private partition-

ing is that from outside, the primary VLAN continues to use the same VLAN ID and IP

subnet as the original VLAN. Internally, all secondary VLANs will share this common IP

subnet, although each of them has a different, unique VLAN ID that is associated with

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 61

the primary VLAN. Hence, a Private VLAN can be described as a cluster of one or more

secondary VLANs, represented to the outside by a single primary VLAN, not unlike a

BGP confederation, where multiple internal sub-ASes are represented to external peers as

a single AS. Consider the topology in Figure 2-2 for an overview.

Community

VLAN 101

Community

VLAN 102

Isolated

VLAN 199

Primary VLAN 100

192.168.100.0/24

Community

VLAN 103

Promiscuous

Port Trunk

192.168.100.254/24 SW1 SW2

Figure 2-2 Switched Network Utilizing Private VLANs

Let us first consider the behavior of Private VLANs on a single switch. We will later dis-

cuss how the Private VLAN functionality extends to multiple switches over trunks.

Secondary VLANs can be of two types: community VLANs and isolated VLANs. Ports

assigned to the same community VLAN can communicate with each other directly, but

they are not allowed to communicate with ports in any other VLAN. This behavior is

similar to ordinary VLANs. A single primary VLAN can be associated with multiple

community VLANs, each of them representing a group of devices that can talk directly

to each other but that are separated from any other similar groups.

On the other hand, ports assigned to an isolated VLAN can neither communicate with

each other nor with ports in any other VLAN. A single primary VLAN can be associated

with at most one isolated VLAN, as having multiple isolated VLANs under a single pri-

mary VLAN would make no sense.

A single primary VLAN can be associated with zero or more community VLANs and

with at most one isolated VLAN. A secondary VLAN, either a community or an isolated

VLAN, must be associated with exactly one primary VLAN.

As an example, consider a block of flats that needs to be fully networked, with you being

the person responsible for configuring the networking equipment. A simple approach

would be to connect all flats to a switch and assign all ports to a single VLAN, say,

VLAN 100 utilizing the IP subnet 192.168.100.0/24. All stations in this VLAN share this

IP space and can communicate with each other directly, and use a gateway IP address

from the same subnet, for example, 192.168.100.254, to reach other networks. However,

ptg13046388

62 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

this network has an obvious security issue—users in individual flats are not controlled

and cannot be trusted. A single misbehaving or infected computer in one flat can wreak

havoc throughout the entire VLAN. Therefore, it is natural to require that individual flats

be isolated from each other but still continue to use the former VLAN 100, the same IP

subnet, and the same default gateway. This can be accomplished by creating a new sec-

ondary isolated VLAN, for example, VLAN 199, associating it with the original VLAN

100 (thereby making the VLAN 100 a primary VLAN) and assigning all access ports

toward flats to the isolated VLAN 199. As a result, individual flats will be isolated from

each other, yet they will continue to use the same IP address space and default gateway.

The outside world will not see any difference.

Life is seldom that simple, though. Selected users can start coming to you after a while

and request direct visibility with other selected users because they want to mutually

share files, stream a video, or play network games. There can be many similar groups of

users that want to have mutual visibility, yet remain isolated from all other users. As an

example, consider that three separate groups of users requesting mutual connectivity

have formed in the block. Obviously, these groups form three communities, with mem-

bers of each single community requesting full visibility with each other, yet keeping the

separation between communities and from users that do not belong to any particular

community.

A comfortable way of solving this task is by creating three secondary community

VLANs, one for each community, and assigning each member of a single community to

the same community VLAN. In this example, the first group can be assigned to com-

munity VLAN 101, the second group can be assigned to community VLAN 102, and the

remaining group can be put into community VLAN 103. These secondary community

VLANs 101–103 will be associated with the primary VLAN 100, again sharing its IP

address space and default gateway. All other flats will remain in isolated VLAN 199 and

will keep their total isolation.

Depending on what secondary VLAN type a switch port is assigned to, we call these

ports either community ports or isolated ports . In the preceding example, switch ports

configured with VLANs 101–103 would be called community ports, while switch ports

configured with VLAN 199 would be called isolated ports. Note that none of the ports

mentioned so far is assigned to the primary VLAN 100. Both community and isolated

ports behave as normal access ports—they technically belong to a single VLAN and they

do not tag frames.

According to communication rules described so far, hosts in a particular community

VLAN can only talk to other hosts in the same community VLAN and no one else; hosts

in a particular isolated VLAN can talk to no one at all. There is, so far, no possibility of

communicating with the world outside the given Private VLAN, nor a way of accessing

common shared resources, such as network printers, storage, or servers. Clearly, the use-

fulness of such VLANs would be questionable at best. Therefore, there must be a way of

defining a special port that is allowed to communicate with any member of any second-

ary VLAN under a particular primary VLAN. A device attached to such a port—a router,

server, NAS, printer, and so on—would then be accessible by any host in any secondary

VLAN under a particular primary VLAN, regardless of the type of the secondary VLAN.

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 63

In Private VLAN terminology, such ports are called promiscuous ports. A promiscu-

ous port is not associated with any particular secondary VLAN. Instead, it is associated

with the corresponding primary VLAN itself. A device connected to a promiscuous port

can communicate with devices in all secondary VLANs associated with this primary

VLAN and vice versa. A device in a secondary VLAN that is associated with a particular

primary VLAN can communicate with any promiscuous port in that primary VLAN. If

there are multiple promiscuous ports in the primary VLAN, they can also communicate

with each other. Promiscuous ports also behave as access ports in the sense they do not

use tagging.

In the preceding example, if the default gateway 192.168.100.254 is an external router,

it would be connected to a promiscuous port on the switch that implements the Private

VLAN. This setup would allow hosts in VLANs 101–103 and 199 to communicate with

other networks through this router.

If Private VLANs are in use, the rules of communication on a single switch can be sum-

marized as follows:

■ A port in a particular community VLAN (that is, a community port) can communi-

cate with all other ports in the same community VLAN and with all promiscuous

ports in the corresponding primary VLAN.

■ A port in a particular isolated VLAN (that is, an isolated port) can communicate

with all promiscuous ports in the corresponding primary VLAN.

■ A port in a particular primary VLAN (that is, a promiscuous port) can communicate

with all other promiscuous ports in the same primary VLAN and with all ports in all

secondary VLANs associated with this primary VLAN.

Extending the operation of Private VLANs over a set of switches is fairly simple. The

basic goal is to increase the span of Private VLANs while keeping their defined behavior

and containment. A port in a particular community VLAN shall be able to communicate

with other ports in the same community VLAN and with all promiscuous ports in the

corresponding primary VLAN on any switch. Similarly, a port in a particular isolated

VLAN shall be able to communicate with all promiscuous ports in the corresponding

primary VLAN on any switch. A promiscuous port in a particular primary VLAN shall

be able to communicate with all other promiscuous ports in that primary VLAN and with

all ports in all associated secondary VLANs on all switches. Because these requirements

implicitly assume that a frame received on a port in a primary or secondary VLAN can

be forwarded through trunk ports to other switches, yet another communication rule is

hereby established: A frame received on a promiscuous, community, or isolated port can

always be forwarded through a trunk port.

Obviously, if all primary/secondary VLANs, their IDs, types, and associations are config-

ured identically on all switches (provided they support the Private VLAN feature), each

switch will give frames the same consistent treatment as soon as their membership in a

particular VLAN is established. As frames between switches are carried by trunk ports,

it is important to see how the tagging of frames received on a Private VLAN port is per-

formed.

Key

Topic

ptg13046388

64 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

If a frame is received on a community or isolated port and is forwarded through a trunk,

the switch will tag the frame using the VLAN ID of the corresponding secondary

VLAN. The receiving switch will then forward the received frame further according to

the type of the secondary VLAN.

If a frame is received on a promiscuous port and is forwarded through a trunk, the switch

will tag the frame using the VLAN ID of the corresponding primary VLAN. The receiv-

ing switch will then forward the frame further as a frame coming from a promiscuous

port.

To summarize the communication and tagging rules in Private VLANs:

■ A port in a particular community VLAN (that is, a community port) can communi-

cate with all other ports in the same community VLAN, with all promiscuous ports

in the corresponding primary VLAN, and with all trunks.

■ A port in a particular isolated VLAN (that is, an isolated port) can communicate

with all promiscuous ports in the corresponding primary VLAN, and with all trunks.

■ A port in a particular primary VLAN (that is, a promiscuous port) can communicate

with all other promiscuous ports in the same primary VLAN, with all ports in all sec-

ondary VLANs associated with this primary VLAN, and with all trunks.

■ A frame received on a community or isolated port will be tagged with the ID of the

corresponding secondary VLAN when forwarded out a trunk.

■ A frame received on a promiscuous port will be tagged with the ID of the corre-

sponding primary VLAN when forwarded out a trunk.

■ A frame received on a trunk tagged with a community or isolated VLAN ID will be

forwarded as if it was received on a local community or isolated port in the corre-

sponding secondary VLAN.

■ A frame received on a trunk tagged with a primary VLAN ID will be forwarded as if

it was received on a local promiscuous port in the corresponding primary VLAN.

■ Community VLANs can be seen as VLANs carrying “upstream” traffic from a host

to other hosts of the same community VLAN and to promiscuous ports in the

corresponding primary VLAN. Isolated VLANs can be seen as VLANs carrying

“upstream” traffic from hosts to promiscuous ports in the corresponding primary

VLAN. A Primary VLAN can be seen as a VLAN carrying “downstream” traffic

from promiscuous ports to other promiscuous ports and hosts in all associated sec-

ondary VLANs.

Table 2-2 summarizes the communication rules between various ports.

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 65

Table 2-2 Private VLAN Communications Between Ports

Description of Who Can Talk to Whom Primary

VLAN Ports

Community

VLAN Ports

Isolated

VLAN Ports

Talk to ports in primary VLAN

(promiscuous ports)

Yes Yes Yes

Talk to ports in the same secondary VLAN

(host ports)

N/A 2 Ye s N o

Talk to ports in another secondary VLAN N/A

2 N o N o

Talk to trunks Yes Yes Yes

1 Community and isolated VLANs are secondary VLANs.

2 Promiscuous ports, by definition in the primary VLAN, can talk to all other ports.

There are two common misconceptions regarding the Private VLAN operation on trunks.

The first misconception relates to the tagging. It is often incorrectly believed that Private

VLANs use double tagging on trunks. This belief is supported by the apparent nesting of

secondary VLANs inside their associated primary VLAN. In reality, secondary VLANs

do not exist “inside” their primary VLAN; rather, they are only associated with it. This

association merely indicates that a frame received in a secondary VLAN can be for-

warded out promiscuous ports in the associated primary VLAN and vice versa.

The second misconception is related to trunk port types. We have so far described

normal trunks ( switchport mode trunk ) that can be used both for ordinary and Private

VLANs. There are, however, two special types of trunk ports with respect to Private

VLANs. These special trunk port types are called Promiscuous PVLAN Trunk and

Isolated PVLAN Trunk ports. Both these types shall not be used in ordinary Private

VLAN deployments between switches supporting Private VLANs; rather, their usage

is limited to a set of special scenarios. To understand better, consider Figure 2-3 , which

contains a slightly modified topology, with VLAN 100 being the primary VLAN, VLANs

101 and 102 being community VLANs, and VLAN 199 being an isolated VLAN. In

addition, there is VLAN 999, which spans the router and both switches and serves the

purpose of a management VLAN. The SW1 switch is assumed to support Private VLANs

while SW2 does not support them.

The first special trunk type is the Promiscuous PVLAN Trunk . Whenever a frame from

a secondary VLAN is going to be sent out such a trunk, its VLAN tag will be rewritten

with the appropriate primary VLAN ID. This rewriting is necessary when a trunk car-

rying a set of VLANs including Private VLANs is to be connected to an external device

that does not support Private VLANs, yet which shall be reachable from the Private

VLANs as if connected to a promiscuous port. If, for example, a router-on-stick like R1

in Figure 2-3 is used to route between several VLANs including a primary VLAN, the

external router does not understand that multiple secondary VLANs actually map to a

single primary VLAN. The Promiscuous PVLAN Trunk port will translate all secondary

VLAN IDs into the corresponding primary VLAN ID so that the external router always

sees only the primary VLAN.

Key

Topic

ptg13046388

66 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The second special type of a trunk is the Isolated PVLAN Trunk . This trunk type trans-

lates a primary VLAN ID into the ID of the isolated VLAN that is associated with the

primary VLAN. This is used to extend the isolated VLAN over a trunk carrying multiple

VLANs to a switch that does not support Private VLANs but is capable of isolating its

own ports. To illustrate, entry-level Catalyst switches do not support Private VLANs

but they support so-called protected ports (this feature is sometimes called the Private

VLAN Edge). On these switches, a protected port can be configured using the switch-

port protected command. Protected ports configured with this command are prohibited

from ever communicating with each other—in essence, they act just like isolated ports. If

a frame is received on a promiscuous port in the primary PVLAN and is about to be sent

out the Isolated PVLAN Trunk port, its VLAN tag currently carrying the primary VLAN

ID will be rewritten to the isolated VLAN ID. If the neighboring switch has its protected

ports assigned to the isolated VLAN (although the VLAN is not configured as isolated

on that switch because it does not support Private VLANs), it will be able to forward

the frame to the appropriate host. In Figure 2-3 , the Isolated PVLAN Trunk is used to

extend the isolated PVLAN 199 from SW1 to SW2 that does not support PVLANs, yet

is capable of locally isolating its ports in VLAN 199. SW2 will not allow these ports to

communicate together while allowing them to communicate with the trunk toward SW1.

SW1 will make sure that a frame received on another isolated port in VLAN 199 will not

be forwarded out the isolated PVLAN trunk toward SW2, and that a frame tagged with

VLAN 199 coming through the isolated PVLAN trunk from SW2 will not be forwarded

out any other isolated port in the same secondary VLAN. This way, the isolated second-

ary VLAN is extended to SW2 without losing any of its isolated properties. Should, how-

ever, R1 or any other device on a promiscuous port send a packet to a station on SW2,

this packet would ordinarily be tagged with primary VLAN 100. On the isolated PVLAN

Community

VLAN 101

Community

VLAN 102

Isolated

VLAN 199

Primary VLAN 100

192.168.100.0/24

Promiscuous

PVLAN Trunk

VLAN 100: Primary VLAN “Users”

VLAN 999: Management VLAN

Isolated

PVLAN Trunk

R1 SW1 SW2

Figure 2-3 Switched Topology Utilizing Special Trunk Types

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 67

trunk on SW1, however, the tag 100 will be rewritten to 199 and forwarded to SW2,

allowing the R1 on the promiscuous trunk to communicate with stations on SW2.

So, in essence, the special nature of these trunks lies in the tag rewriting they perform:

■ A Promiscuous PVLAN Trunk port rewrites the secondary VLAN ID into the pri mary

PVLAN ID upon sending a frame. When a frame is received, no tag manipulation is

performed. Also, no tag manipulation is performed for frames in ordinary VLANs.

■ An Isolated PVLAN Trunk port rewrites the primary VLAN ID into the isolated sec-

ondary VLAN ID upon sending a frame. When a frame is received, no tag manipu-

lation is performed. Also, no tag manipulation is performed for frames in ordinary

VLANs.

Special Private VLAN Trunk types are supported only on selected higher-level Catalyst

switches.

Example 2-5 shows the configuration of a switch with Private VLANs. Configuration of

ordinary trunks is not shown, as there is nothing specific regarding it.

Example 2-5 Configuring Private VLANs

! If not running VTPv3, a switch must be put into VTP Transparent mode before

! configuring Private VLANs

AccessSw(config)# vtp mode transparent

Setting device to VTP Transparent mode for VLANS.

! One isolated secondary VLAN and three community secondary VLANs will now be

! created. Afterwards, they will be associated with the primary VLAN 100.

AccessSw(config)# vlan 199

AccessSw(config-vlan)# name Isolated

AccessSw(config-vlan)# private-vlan isolated

AccessSw(config-vlan)# vlan 101

AccessSw(config-vlan)# name Community1

AccessSw(config-vlan)# private-vlan community

AccessSw(config-vlan)# vlan 102

AccessSw(config-vlan)# name Community2

AccessSw(config-vlan)# private-vlan community

AccessSw(config-vlan)# vlan 103

AccessSw(config-vlan)# name Community3

AccessSw(config-vlan)# private-vlan community

AccessSw(config-vlan)# vlan 100

AccessSw(config-vlan)# name Primary1

AccessSw(config-vlan)# private-vlan primary

AccessSw(config-vlan)# private-vlan association 101-103,199

AccessSw(config-vlan)# exit

Key

Topic

Key

Topic

ptg13046388

68 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! The show vlan private-vlan command is useful to verify the types and associations

! of private VLANs and their member ports. At this moment, there are no ports

! assigned to these VLANs yet.

AccessSw(config)# do show vlan private-vlan

Primary Secondary Type Ports

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

100 101 community

100 102 community

100 103 community

100 199 isolated

! Now, ports will be assigned to these VLANs:

! Fa0/1 - 3: Secondary community VLAN 101

! Fa0/4 - 5: Secondary community VLAN 102

! Fa0/6 - 8: Secondary community VLAN 103

! Fa0/9 - 12: Secondary isolated VLAN 199

! Fa0/13: Promiscuous port in primary VLAN 100

! For brevity purposes, only the configuration of Fa0/1 - 3 will be shown, as all

! other ports in secondary VLANs, isolated or community, are configured similarly

! Afterwards, show vlan private-vlan is issued to verify the port assignment.

! As Fa0/13 is a promiscuous port, it will be shown in all associated secondary

! VLANs

AccessSw(config)# interface range fa0/1 - 3

AccessSw(config-if-range)# switchport mode private-vlan host

AccessSw(config-if-range)# switchport private-vlan host-association 100 101

AccessSw(config-if-range)# interface fa0/13

AccessSw(config-if)# switchport mode private-vlan promiscuous

AccessSw(config-if)# switchport private-vlan mapping 100 101-103,199

AccessSw(config-if)# do show vlan private-vlan

Primary Secondary Type Ports

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

100 101 community Fa0/1, Fa0/2, Fa0/3, Fa0/13

100 102 community Fa0/4, Fa0/5, Fa0/13

100 103 community Fa0/6, Fa0/7, Fa0/8, Fa0/13

100 199 isolated Fa0/9, Fa0/10, Fa0/11, Fa0/12, Fa0/13

! If a SVI is used as a gateway for devices associated with the primary VLAN 100,

! it must also be configured as promiscuous

AccessSw(config-if)# interface Vlan100

AccessSw(config-if)# private-vlan mapping 101-103,199

AccessSw(config-if)# ip address 192.168.100.254 255.255.255.0

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 69

VLAN Trunking: ISL and 802.1Q

VLAN trunking allows switches, routers, and even PCs with the appropriate network

interface cards (NIC) and/or software drivers to send traffic for multiple VLANs across a

single link. To know to which VLAN a frame belongs, the sending switch, router, or PC

adds a header to the original Ethernet frame, with that header having a field in which to

place the VLAN ID of the associated VLAN. This section describes the protocol details

for the two trunking protocols, followed by the details of how to configure trunking.

ISL and 802.1Q Concepts

If two devices are to perform trunking, they must agree to use either Inter-Switch Link

(ISL) or 802.1Q, because there are several differences between the two, as summarized in

Table 2-3 .

Table 2-3 Comparing ISL and 802.1Q

Feature ISL 802.1Q

VLANs supported Normal and extended range

1 Normal and extended range

Protocol defined by Cisco IEEE

Encapsulates original frame or

inserts tag

Encapsulates Inserts tag

Has a concept of native VLAN No Yes

1 ISL originally supported only normal-range VLANs, but was later improved to support extended-range

VLANs as well.

ISL and 802.1Q differ in how they add a header to the Ethernet frame before sending it

over a trunk. ISL adds a new 26-byte header, plus a new trailer (to allow for the new FCS

value), encapsulating the entire original frame. This encapsulating header uses the source

address (listed as SA in Figure 2-4 ) of the device doing the trunking, instead of the source

MAC of the original frame. ISL uses a multicast destination address (listed as DA in

Figure 2-4 ) of either 0100.0C00.0000 or 0300.0C00.0000. Overall, though, an ISL frame is

technically a SNAP-encapsulated frame.

802.1Q inserts a 4-byte header, called a tag, into the original frame (right after the Source

Address field). The original frame’s addresses are left intact. Normally, an Ethernet con-

troller would expect to find either an Ethernet Type field or 802.3 Length field right after

the Source Address field. With an 802.1Q tag, the first 2 bytes after the Address fields

hold a registered Ethernet type value of 0x8100, which implies that the frame includes

an 802.1Q header. Because 802.1Q does not actually encapsulate the original frame, it is

often called frame tagging . Figure 2-4 shows the contents of the headers used by both

ISL and 802.1Q.

Key

Topic

ptg13046388

70 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Finally, the last row from Table 2-3 refers to the native VLAN . On trunks, 802.1Q does

not tag frames sent inside the native VLAN, and assigns all received untagged frames to

the native VLAN. The native VLAN feature allows a switch to attempt to use 802.1Q

trunking on an interface, but if the other device does not support trunking, the traffic

for that one native VLAN can still be sent over the link. By default, the native VLAN is

VLAN 1, which is also the default access VLAN. It is absolutely necessary that the native

VLANs on both ends of a trunk link match; otherwise a native VLAN mismatch occurs,

causing the two VLANs to effectively merge. To detect and possibly avoid any ill effects

of a native VLAN mismatch, Cisco switches implement a proprietary extension to PVST+

and Rapid PVST+ that allows them to detect and block the mismatched native VLANs

on the trunk. This extension is described in more detail in Chapter 3 , “Spanning Tree

Protocol.” Also, Cisco Discovery Protocol (CDP) will detect and report a native VLAN

mismatch. As a best practice, on each trunk, its native VLAN should be changed from

VLAN 1 to a different VLAN, and this VLAN should not be used for any other purpose

except being configured as a native VLAN. This prevents users from attempting a VLAN

hopping attack by sending double-tagged frames that would be detagged on trunks if the

top tag matches the trunk’s native VLAN.

Detailed information about the ISL and 802.1Q tagging as implemented by Cisco can be

found at Cisco.com published as a technote document called “Inter-Switch Link and IEEE

802.1Q Frame Format,” Document ID: 17056.

ISL Header

26 bytes

CRC

4 bytes

Encapsulated Ethernet Frame

VLAN

DA Type User SA LEN AAAA03 HSA VLAN BPDU INDEX RES

BPDU

Dest Src Len/Etype Data FCS

Dest Src Etype Tag Len/Etype Data FCS

Priority VLAN-ID

Original

Frame

Tagged

Frame

Figure 2-4 ISL and 802.1Q Frame Marking Methods

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 71

ISL and 802.1Q Configuration

Cisco switches use the Dynamic Trunk Protocol (DTP) to dynamically learn whether the

device on the other end of the cable wants to perform trunking and, if so, which trunk-

ing protocol to use. It is meant both to ease the initial deployment of a switched network

and to minimize configuration errors that result from mismatched port configuration on

an interconnection between two switches.

DTP learns whether to trunk based on the DTP mode defined for an interface. The indi-

vidual DTP modes are

■ dynamic auto: The port will negotiate the mode automatically; however, it prefers to

be an access port.

■ dynamic desirable: The port will negotiate the mode automatically; however, it pre-

fers to be a trunk port.

Out of these modes, dynamic desirable has a higher priority—if both ports are dynamic

but one is configured as auto and the other as desirable, the resulting operating mode

will be trunk. DTP also negotiates the type of encapsulation on the trunk should either

of the two devices support both ISL and 802.1Q. If both devices support both trunk

types, they will choose ISL. Should the DTP negotiation fail, any port in dynamic mode,

either desirable or auto, will be operating as an access port. An upcoming section, “Trunk

Configuration Compatibility,” covers the different DTP modes and their combinations in

closer detail.

Different types of Cisco switches have different default DTP modes. For example, earlier

Catalyst 2950 and 3550 models default to dynamic desirable mode. Later Catalyst mod-

els, such as 2960, 3560 or 3750, default to dynamic auto mode. Authoritative information

pertaining to the particular switch platform and IOS version can be found in the appropri-

ate Command Reference.

While DTP and VTP are independent protocols, DTP carries the VTP domain name in

its messages. Switches will successfully negotiate the link operating mode only if the

VTP domain name on both switches is the same, or one switch has no VTP domain name

configured yet (that is, it uses a NULL domain name). The reason behind tying the DTP

negotiation to the VTP domain name is that in different VTP domains, there might be dif-

ferent sets of VLANs, and identically numbered VLANs might be used for different pur-

poses (that is why the network was split into several VTP domains in the first place—to

keep the VLAN databases separate and independent). As a result, switches should not try

to bring up the link as a trunk, as extending VLANs from one VTP domain to another can

have undesired consequences.

With the DTP mode set to desirable, switches can simply be connected, and they should

dynamically form a trunk. You can, however, configure trunking details and verify the

results with show commands. Table 2-4 lists some of the key Catalyst IOS commands

related to trunking.

ptg13046388

72 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 2-4 VLAN Trunking–Related Commands

Command Function

switchport | no switchport Toggle defining whether to treat the interface as a switch

interface ( switchport ) or as a routed interface ( no switchport )

switchport mode ... Sets DTP negotiation parameters

switchport trunk ... Sets trunking parameters if the interface is trunking

switchport access ... Sets nontrunking-related parameters if the interface is not

trunking

show interfaces trunk Summary of trunk-related information

show interfaces type

number trunk

Lists trunking details for a particular interface

show interfaces type

number switchport

Lists both trunking and nontrunking details for a particular

interface

Figure 2-5 lists several details regarding Switch1’s trunking configuration and status, as

shown in Example 2-6 . R1 is not configured to trunk, so Switch1 will fail to negotiate

trunking. Switch2 is a Catalyst 3550, which supports both ISL and 802.1Q, so they will

negotiate trunking and use ISL. Switch3 and Switch4 are Catalyst 2950s, which support

only 802.1Q; as a result, Switch1 negotiates trunking, but picks 802.1Q as the trunking

protocol. While both Catalyst 3550 and 2950 are End-of-Life at the time of writing, their

default port settings of dynamic desirable serve a useful example of how simply intercon-

necting them results in links dynamically becoming trunks. With recent Catalyst models,

such as 2960, 3560, 3750, or 3850 Series, the default setting is dynamic auto , so the

same topology in Figure 2-5 equipped with any of these platforms would negotiate all

connected ports to operate in access mode.

Gi0/1

Not Configured

to Trunk

Defaults to DTP Desirable

Supports ISL or .1Q

Defaults to DTP Desirable

Does Not Support ISL (2950)

Defaults to DTP Desirable

Does Not Support ISL (2950)

Fa0/12 Fa0/24

Fa0/1

SW1 SW2

SW4SW3

Figure 2-5 Trunking Configuration Reference for Example 2-6

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 73

Example 2-6 Trunking Configuration and show Command Example – Switch1

! The administrative mode of dynamic desirable (trunking) and negotiate (trunking

! encapsulation) means that Switch1 attempted to negotiate to trunk, but the

! operational mode of static access means that trunking negotiation failed.

! The reference to "operational trunking encapsulation" of native means that

! no tagging occurs.

Switch1# show int fa 0/1 switchport

Name: Fa0/1

Switchport: Enabled

Administrative Mode: dynamic desirable

Operational Mode: static access

Administrative Trunking Encapsulation: negotiate

Operational Trunking Encapsulation: native

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Protected: false

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Voice VLAN: none (Inactive)

Appliance trust: none

! Next, the show int gig 0/1 trunk command shows the configured mode

! (desirable), and the current status (n-isl), meaning negotiated ISL. Note

! that the trunk supports the extended VLAN range as well.

Switch1# show int gig 0/1 trunk

Port Mode Encapsulation Status Native vlan

Gi0/1 desirable n-isl trunking 1

Port Vlans allowed on trunk

Gi0/1 1-4094

Port Vlans allowed and active in management domain

Gi0/1 1,21-22

ptg13046388

74 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Port Vlans in spanning tree forwarding state and not pruned

Gi0/1 1,21-22

! Next, Switch1 lists all three trunks - the segments connecting to the other

! three switches - along with the type of encapsulation.

Switch1# show int trunk

Port Mode Encapsulation Status Native vlan

Fa0/12 desirable n-802.1q trunking 1

Fa0/24 desirable n-802.1q trunking 1

Gi0/1 desirable n-isl trunking 1

Port Vlans allowed on trunk

Fa0/12 1-4094

Fa0/24 1-4094

Gi0/1 1-4094

Port Vlans allowed and active in management domain

Fa0/12 1,21-22

Fa0/24 1,21-22

Gi0/1 1,21-22

Port Vlans in spanning tree forwarding state and not pruned

Fa0/12 1,21-22

Fa0/24 1,21-22

Gi0/1 1,21-22

The possibility to configure the port to negotiate its operating mode dynamically also

explains why there can be both switchport access and switchport trunk commands

present on a single interface. Though confusing at first sight, these commands merely

define how a port would behave if it was operating either as an access or a trunk port.

Commands related to a currently unused operating mode of a port might be present but

they are ignored.

As shown in Example 2-7 , on newer Catalyst platforms, the show dtp commands display

the operating state of DTP globally and on individual ports.

Example 2-7 show dtp Command Output on SW1

SW1# show dtp

Global DTP information

Sending DTP Hello packets every 30 seconds

Dynamic Trunk timeout is 300 seconds

12 interfaces using DTP

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 75

! The TOS/TAS/TNS stand for Trunk Operating/Administrative/Negotiation Status

! The TOT/TAT/TNT stand for Trunk Operating/Administrative/Negotiation Type

! In the following output, Fa0/12 is configured as dynamic desirable

SW1# show dtp interface fa0/12

DTP information for FastEthernet0/12:

TOS/TAS/TNS: TRUNK/DESIRABLE/TRUNK

TOT/TAT/TNT: ISL/NEGOTIATE/ISL

Neighbor address 1: 00179446B30E

Neighbor address 2: 000000000000

Hello timer expiration (sec/state): 19/RUNNING

Access timer expiration (sec/state): 289/RUNNING

Negotiation timer expiration (sec/state): never/STOPPED

Multidrop timer expiration (sec/state): never/STOPPED

FSM state: S6:TRUNK

# times multi & trunk 0

Enabled: yes

In STP: no

Statistics

----------

3 packets received (3 good)

0 packets dropped

0 nonegotiate, 0 bad version, 0 domain mismatches,

0 bad TLVs, 0 bad TAS, 0 bad TAT, 0 bad TOT, 0 other

6 packets output (6 good)

3 native, 3 software encap isl, 0 isl hardware native

0 output errors

0 trunk timeouts

2 link ups, last link up on Mon Mar 01 1993, 00:14:09

2 link downs, last link down on Mon Mar 01 1993, 00:14:02

Note Without any configuration, the default port settings on recent Catalyst switch

series such as 2960, 3560, 3750, 3650, and 3850 are as follows: mode set to dynamic auto,

native VLAN set to 1, access VLAN set to 1, trunk encapsulation set to auto (if both ISL

and dot1q supported) or dot1q, all VLANs allowed, and VLANs 2–1001 eligible for prun-

ing. On older 2950 and 3550 models, the default mode was dynamic desirable.

ptg13046388

76 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Allowed, Active, and Pruned VLANs

Although a trunk can support VLANs 1–4094, several mechanisms reduce the actual

number of VLANs whose traffic flows over the trunk. First, VLANs can be administra-

tively forbidden from existing over the trunk using the switchport trunk allowed inter-

face subcommand. Also, any allowed VLANs must be configured on the switch before

they are considered active on the trunk. Finally, VTP can prune VLANs from the trunk,

with the switch simply ceasing to forward frames from that VLAN over the trunk.

The show interface trunk command lists the VLANs that fall into each category, as

shown in the last command in Example 2-6 . The categories are summarized as follows:

■ Allowed VLANs: Each trunk allows all VLANs by default. However, VLANs can

be removed or added to the list of allowed VLANs by using the switchport trunk

allowed command.

■ Allowed and active: To be active, a VLAN must be in the allowed list for the trunk

(based on trunk configuration), the VLAN must exist in the VLAN configuration on

the switch, and it must be in the active state (not suspended or locally shutdown).

With PVST+, an STP instance is actively running on this trunk for the VLANs in this

list.

■ Active and not pruned: This list is a subset of the “allowed and active” list, with

any VTP-pruned VLANs and VLANs for which PVST+ considers the port Blocking

removed.

Trunk Configuration Compatibility

In most production networks, switch trunks are configured using the same standard

throughout the network. For example, rather than allow DTP to negotiate trunking, many

engineers configure trunk interfaces to always trunk ( switchport mode trunk ) and dis-

able DTP on ports that should not trunk. IOS includes several commands that impact

whether a particular segment becomes a trunk. Because many enterprises use a typical

standard, it is easy to forget the nuances of how the related commands work. This section

covers those small details.

Two IOS configuration commands impact if and when two switches form a trunk. The

switchport mode and switchport nonegotiate interface subcommands define whether

DTP even attempts to negotiate a trunk, and what rules it uses when the attempt is made.

Additionally, the settings on the switch ports on either side of the segment dictate wheth-

er a trunk forms or not.

Table 2-5 summarizes the trunk configuration options. The first column suggests the con-

figuration on one switch, with the last column listing the configuration options on the

other switch that would result in a working trunk between the two switches.

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 77

Table 2-5 Trunking Configuration Options That Lead to a Working Trunk

Configuration

Command on

One Side

Short Name Meaning To Trunk,

Other Side

Must Be

switchport mode

trunk

Trunk Always trunks on this end; sends

DTP to help other side choose to

trunk

On, desirable,

auto

switchport mode

trunk ; switchport

nonegotiate

Nonegotiate Always trunks on this end; does

not send nor process DTP messages

(good when other switch is a non-

Cisco switch)

switchport mode

dynamic desirable

Desirable Sends DTP messages indicating

dynamic mode with preferred

trunking, and trunks if negotiation

succeeds

On, desirable,

auto

switchport mode

dynamic auto

Auto Sends DTP messages indicating

dynamic mode with preferred access,

and trunks if negotiation succeeds

On, desirable

switchport mode

access

Access Never trunks; can send a single DTP

message when entering the access

mode to help other side reach same

conclusion, ceases to send and

process DTP messages afterward

(Never trunks)

switchport mode

access ; switchport

nonegotiate

Access (with

nonegotiate)

Never trunks; does not send or

process DTP messages

(Never trunks)

1 When the switchport nonegotiate command is not listed in the first column, the default (DTP negotia-

tion is active) is assumed.

Note If an interface trunks, the type of trunking (ISL or 802.1Q) is controlled by the

setting on the switchport trunk encapsulation command if the switch supports multiple

trunk encapsulations. This command includes an option for dynamically negotiating the

type (using DTP) or configuring one of the two types.

Also, for DTP negotiation to succeed, both switches must either be configured with the

same VTP domain name, or at least one switch must have its VTP domain name unconfig-

ured (that is, NULL).

Configuring Trunking on Routers

VLAN trunking can be used on routers and hosts as well as on switches. However, rout-

ers do not support DTP, so you must manually configure them to support trunking.

Additionally, you must manually configure a switch on the other end of the segment to

trunk, because the router does not participate in DTP.

Key

Topic

ptg13046388

78 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The majority of router trunking configurations use subinterfaces, with each subinter-

face being associated with one VLAN. The subinterface number does not have to match

the VLAN ID; rather, the encapsulation command sits under each subinterface, with

the associated VLAN ID being part of the encapsulation command. Use subinterface

numbers starting with 1; the subinterface number 0 is the physical interface itself (for

example, interface Fa0/0.0 is the Fa0/0 itself). Also, because good design calls for one

IP subnet per VLAN, if the router wants to forward IP packets between the VLANs, the

router needs to have an IP address associated with each trunking subinterface.

You can configure 802.1Q native VLANs under a subinterface or under the physical inter-

face on a router. If they are configured under a subinterface, you use the encapsulation

dot1q vlan-id native subcommand, with the inclusion of the native keyword meaning

that frames exiting this subinterface should not be tagged, and incoming untagged frames

shall be processed by this subinterface. As with other router trunking configurations,

the associated IP address would be configured on that same subinterface. Alternately, if

not configured on a subinterface, the router assumes that the native VLAN is associated

with the physical interface. In this case, the encapsulation command is not needed nor

supported under the physical interface; the associated IP address, however, would need

to be configured under the physical interface. Configuring an (understandably distinct) IP

address on both physical interface and a subinterface under the same physical interface

using encapsulation dot1q vlan-id native , thereby technically resulting in two differ-

ent interfaces for the native VLAN, is not supported. All incoming untagged frames will

be processed by the subinterface configuration only. A notable exception to this rule

can be seen on ISR G1 routers equipped with 10-Mbps Ethernet built-in interfaces. On

these router platforms, settings for the native VLAN shall be configured on the physical

Ethernet interface directly. While the router will accept the configuration of a subinter-

face with the encapsulation dot1q vlan-id native command, incoming untagged frames

will be processed by the configuration of the physical interface. This exception applies

only to ISR platforms with 10-Mbps Ethernet interfaces, and is not present on platforms

with Fast Ethernet or faster interfaces.

If the router supports native VLAN configuration on a subinterface, it is recommended to

use subinterfaces instead of putting the native VLAN configuration on a physical port.

Aside from keeping the configuration more consistent (all configuration being placed

on subinterfaces), this configuration allows the router to correctly process frames that,

despite being originated in the native VLAN, carry an 802.1Q tag. Tagging such frames

is done when using the CoS field inside an 802.1Q tag. If the native VLAN configuration

was done on a physical interface, the router would not be able to recognize that a frame

carrying an 802.1Q tag with a nonzero VLAN ID is really a CoS-marked frame in the

native VLAN. When using subinterfaces, the encapsulation dot1q vlan-id native com-

mand allows the router to recognize that both untagged frames and CoS-marked frames

tagged with the particular vlan-id should be processed as frames in the native VLAN.

Example 2-8 shows an example configuration for Router1 in Figure 2-1 , both for ISL and

802.1Q. In this case, Router1 needs to forward packets between the subnets on VLANs

21 and 22. The first part of the example shows ISL configuration, with no native VLANs,

and therefore only a subinterface being used for each VLAN. The second part of the

example shows an alternative 802.1Q configuration, using the option of placing the native

VLAN (VLAN 21) configuration on the physical interface.

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 79

Example 2-8 Trunking Configuration on Router1

! Note the subinterface on the Fa0/0 interface, with the encapsulation

! command noting the type of trunking, as well as the VLAN number. The subinterface

! number does not have to match the VLAN ID. Also note the IP addresses for

! each interface, allowing Router1 to route between VLANs.

! The encapsulation command must be entered on a subinterface before entering any

! other IP-related commands, such as configuring an IP address.

Router1(config)# interface fa0/0

Router1(config-if)# no shutdown

Router1(config-if)# interface fa0/0.1

Router1(config-subif)# encapsulation isl 21

Router1(config-subif)# ip address 10.1.21.1 255.255.255.0

Router1(config-subif)# interface fa0/0.2

Router1(config-subif)# encapsulation isl 22

Router1(config-subif)# ip address 10.1.22.1 255.255.255.0

! Next, an alternative 802.1Q configuration is shown. Note that this configuration

! places the IP address for VLAN 21 on the physical interface; the router simply

! associates the physical interface with the native VLAN. Alternatively,

! a subinterface could be used, with the encapsulation dot1q 21 native command

! specifying that the router should treat this VLAN as the native VLAN.

Router1(config)# interface fa0/0

Router1(config-if)# ip address 10.1.21.1 255.255.255.0

Router1(config-if)# no shutdown

Router1(config-if)# interface fa0/0.2

Router1(config-subif)# encapsulation dot1q 22

Router1(config-subif)# ip address 10.1.22.1 255.255.255.0

Note also that the router does not have an explicitly defined allowed VLAN list on an

interface. However, the allowed VLAN list is implied based on the configured VLANs.

For example, in this example, when using ISL, Router1 allows VLANs 21 and 22, while

when using 802.1Q, it allows the native VLAN and VLAN 22.

802.1Q-in-Q Tunneling

Traditionally, VLANs have not extended beyond the WAN boundary. VLANs in one cam-

pus extend to a WAN edge router, but VLAN protocols are not used on the WAN.

Today, several emerging alternatives exist for the passage of VLAN traffic across a WAN,

including 802.1Q-in-Q, its standardized version 802.1ad called Provider Bridges, another

standard 802.1ah called Provider Backbone Bridges, Layer2 Tunneling Protocol (L2TPv3),

Key

Topic

ptg13046388

80 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Ethernet over MPLS (EoMPLS), and VLAN Private LAN Services (VPLS). While these

topics are more applicable to the CCIE Service Provider certification, you should at least

know the concept of 802.1 Q-in-Q tunneling.

Also known as Q-in-Q on Catalyst switches, 802.1Q-in-Q allows an SP to preserve

802.1Q VLAN tags across a WAN service. By doing so, VLANs actually span multiple

geographically dispersed sites. Figure 2-6 shows the basic idea.

SP:

Customer1: VLAN 5

Customer2: VLAN 6

VLANs 100-199

VLANs 100-500

VLAN

ID 100 Data

VLAN

ID 6

Eth.

Header

VLAN

ID 100 Data

VLAN

ID 5

Eth.

Header

VLAN

ID 100 Data

Eth.

Header

VLAN

ID 100 Data

Eth.

Header

VLAN

ID 100 Data

Eth.

Header

VLAN

ID 100 Data

Eth.

Header

C1-SW2

C2-SW2

C1-SW1

C2-SW1

SP-SW2SP-SW1

Figure 2-6 Q-in-Q: Basic Operation

The ingress SP switch takes the 802.1Q frame, and then tags each frame entering the

interface with an additional 802.1Q header, called the S-tag (the original customer tags

are called C-tags and are not modified nor processed). In this case, all of Customer1’s

frames are tagged as VLAN 5 as they pass over the WAN; Customer2’s frames are tagged

with VLAN 6. After removing the S-tag at egress, the customer switch sees the original

802.1Q frame with the C-tag intact, and can interpret the VLAN ID correctly. The receiv-

ing SP switch (SP-SW2 in this case) can keep the various customers’ traffic separate based

on the additional VLAN S-tags.

Notice that if the trunk between SP-SW1 and SP-SW2 used VLAN 5 as the native

VLAN, frames coming from Customer1 would not have an S-tag added on this trunk.

As a result, they would be received by SP-SW2 tagged only with the C-tag, and would

be processed in the VLAN indicated in the C-tag instead of VLAN 5. This could result

in Customer1’s traffic leaking out to another customer, or to be otherwise misforwarded

or blackholed. To prevent this, SP’s switches are usually configured with vlan dot1q tag

native command to essentially deactivate the concept of native VLAN, and to tag all

frames on trunks regardless of the native VLAN setting.

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 81

Using Q-in-Q, an SP can offer VLAN services, even when the customers use overlapping

VLAN IDs. Customers get more flexibility for network design options, particularly with

metro Ethernet services. Plus, CDP and VTP traffic can be configured to pass transpar-

ently over the Q-in-Q service.

On Catalyst switches, the Q-in-Q is supported on 3550 and higher platforms. Example

2-9 shows the configuration, which is relatively straightforward.

Example 2-9 Q-in-Q Configuration Example on a Catalyst 3560

! It is assumed that C1-SW1 and C1-SW2 have their ports towards SP-SW1 configured

! as ordinary 802.1Q trunks. On SP-SW1, the vlan dot1q tag native is used to

! force tagging on all VLANs including native VLAN on trunks. Also, because

! a customer's C-tagged frame may already contain 1500 bytes in its payload, this

! payload including the C-tag is considered a new payload in the S-tagged frame,

! and thus may grow up to 1504 bytes. Therefore, the MTU of the resulting frames

! is increased to 1504 bytes using the system mtu commands. Their use must also

! be carefully matched by neighboring devices.

SP-SW1(config)# vlan dot1q tag native

SP-SW1(config)# system mtu 1504 ! Applies to 100Mbps interfaces

SP-SW1(config)# system mtu jumbo 1504 ! Applies to 1Gbps and 10Gbps interfaces

SP-SW1(config)# vlan 5

SP-SW1(config-vlan)# name Customer1

SP-SW1(config-vlan)# exit

SP-SW1(config)# vlan 6

SP-SW1(config-vlan)# name Customer2

SP-SW1(config-vlan)# exit

! The Fa0/24 interface connects to SP-SW2. This interface is configured as an

! ordinary trunk port

SP-SW1(config)# interface FastEthernet0/24

SP-SW1(config-if)# switchport trunk encapsulation dot1q

SP-SW1(config-if)# switchport mode trunk

! The Fa0/1 interface connects to C1-SW1. Here, apart from 802.1Q-in-Q tunneling,

! the switch is also configured to tunnel selected Layer2 management protocols.

! To assign all Customer1's traffic to SP's VLAN 5, switchport access vlan 5 is

! used.

SP-SW1(config)# interface FastEthernet0/1

SP-SW1(config-if)# switchport mode dot1q-tunnel

SP-SW1(config-if)# switchport access vlan 5

Key

Topic

ptg13046388

82 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

SP-SW1(config-if)# l2protocol-tunnel cdp

SP-SW1(config-if)# l2protocol-tunnel lldp

SP-SW1(config-if)# l2protocol-tunnel stp

SP-SW1(config-if)# l2protocol-tunnel vtp

! The Fa0/2 interface connects to C2-SW1. This is the basic 802.1Q-in-Q tunneling

! configuration without any Layer2 management protocol tunneling

SP-SW1(config)# interface FastEthernet0/2

SP-SW1(config-if)# switchport mode dot1q-tunnel

SP-SW1(config-if)# switchport access vlan 6

! The show interfaces Fa0/1 switchport shows that the interface is operating

! in QinQ tunneling mode. The show vlan (not shown here for brevity) would display

! the Fa0/1 in the Customer1 VLAN just like an ordinary access port.

SP-SW1# show interfaces fa0/1 switchport

Name: Fa0/1

Switchport: Enabled

Administrative Mode: tunnel

Operational Mode: tunnel

Administrative Trunking Encapsulation: negotiate

Operational Trunking Encapsulation: native

Negotiation of Trunking: Off

Access Mode VLAN: 5 (Customer1)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk associations: none

Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Protected: false

Unknown unicast blocked: disabled

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 83

Unknown multicast blocked: disabled

Appliance trust: none

SP-SW1#

VLAN Trunking Protocol

VTP advertises VLAN configuration information to neighboring switches so that the

VLAN configuration can be made on one switch, with all the other switches in the

domain learning the VLAN information dynamically. VTP advertises the VLAN ID,

VLAN name, and VLAN type and state for each VLAN. However, VTP does not adver-

tise any information about which ports (interfaces) should be in each VLAN, so the con-

figuration to associate a switch interface with a particular VLAN (using the switchport

access vlan command) must still be configured on each individual switch.

The VTP protocol exists in three versions. VTPv1 and VTPv2 are widely supported

across the CatOS and IOS-based switching platforms. VTPv3 support on IOS-based

switches is, at the time of writing, relatively new. On entry-level Catalyst switches,

VTPv3 is supported starting with IOS Release 12.2(52)SE.

VTPv1 is the default VTP version supported and active on enterprise IOS-based switches.

It supports disseminating of normal-range VLANs only.

VTPv2 enhancements include the following:

■ Support for Token Ring Concentrator Relay Function and Bridge Relay Function

(TrCRF and TrBRF) type VLANs: These VLANs were used to segment a Token

Ring network into multiple logical rings and interconnecting bridges. There is no use

for them in Ethernet-based networks.

■ Support for unknown Type-Length-Value (TLV) records: VTP messages can con-

tain additional information elements stored as TLV records. A switch running VTPv1

would drop all unrecognized TLVs from received messages, not propagating them

farther to neighboring switches. VTPv2-enabled switches keep all TLVs in propa-

gated messages even if they are not recognized.

■ Optimized VLAN database consistency checking: In VTPv1, VLAN database

consistency checks are performed whenever the VLAN database is modified, either

through CLI, SNMP, or VTP. In VTPv2, these consistency checks are skipped if the

change was caused by a received VTP message, as the message itself was originated

as a result of a CLI or SNMP action that must already have been sanitized. This is

really just an implementation optimization.

There is ongoing confusion regarding the VTP transparent mode. The IOS documenta-

tion for earlier Catalyst series appeared to suggest that VTPv1 switches in transparent

mode forward VTP messages only if their version and domain match the settings on the

transparent switch, while VTPv2 transparent switches allegedly forward VTP messages

regardless of their domain and version. Documentation to recent Catalyst switches is less

ptg13046388

84 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

clear, but it states that both VTPv1 and VTPv2 transparent switches check the domain

and only forward the message if its domain matches the domain configured on the trans-

parent switch.

In reality, experiments performed on multiple Catalyst switch types that supported both

VTPv1 and VTPv2 show that, regardless of the activated VTP version, a transparent

switch whose VTP domain was NULL (that is, unconfigured) forwarded all VTP messages

happily. A transparent switch with a configured domain forwarded VTP messages only if

their domain matched.

VTPv3 differs from VTPv2 in the following aspects:

■ The server role has been modified: There are two server types in VTPv3: primary

and secondary. A primary server is allowed to modify VTP domain contents, and

there can be at most one primary server per VTP domain at any time. A secondary

server (often called just a server) is not allowed to modify VTP domain contents, but

it can be promoted to the role of primary server, retaking the role from the existing

primary server if it exists. Ownership of the primary server role is a runtime state

that is not stored in the configuration; instead, it is requested in the privileged EXEC

mode if necessary. This modification significantly reduces the probability of unin-

tended modification of the VLAN database, as it is not possible to modify the data-

base contents without the concerted effort of making a switch the primary server.

■ VTPv3 password storage and usage has been improved: The VTP password can be

stored in an encrypted form that cannot be displayed back as plaintext. While this

encrypted string can be carried over to a different switch to make it a valid member

of the domain, the promotion of a secondary server into the primary server role will

require entering the password in its plaintext form.

■ VTPv3 is capable of distributing information about the full range of VLANs

including Private VLANs: With VTPv3, it is not necessary to use Transparent mode

when using extended-range VLANs and Private VLANs. Pruning, however, still

applies only to normal-range VLANs, even in VTPv3.

■ VTPv3 supports the off mode in which the switch does not participate in VTPv3

operations and drops all received VTP messages: It is also possible to deactivate

VTP on a per-trunk basis.

■ VTPv3 is a generalized mechanism for distributing contents of an arbitrary

database, and is not limited to synchronizing VLAN information over a set of

switches: As an example, VTPv3 is also capable of distributing and synchronizing

the MST region configuration among all switches in a VTP domain.

Each Cisco switch uses one of four VTP modes, as outlined in Table 2-6 .

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 85

Table 2-6 VTP Modes and Features

Function Server

Mode

Client

Mode

Transparent

Mode

O f f

Mode*

Originates VTP advertisements Yes Yes No No

Processes received advertisements to update

its VLAN configuration

Ye s Ye s N o N o

Forwards received VTP advertisements Yes Yes Yes No

Saves VLAN configuration in NVRAM or

vlan.dat

Yes Yes Yes Yes

Can create, modify, or delete VLANs using

configuration commands

Yes No Yes Yes

* The Off mode is supported only with VTPv3.

VTPv1 and VTPv2 use four types of messages:

■ Summary Advertisement: This message is originated by VTP Server and Client

switches every 5 minutes and, in addition, after each modification to the VLAN

database. This message carries information about VTP domain name, revision num-

ber, identity of the last updater, time stamp of the last update, MD5 sum computed

over the contents of the VLAN database and the VTP password (if configured), and

the number of Subset Advertisement messages that optionally follow this Summary

Advertisement. Summary Advertisement messages do not carry VLAN database

contents.

■ Subset Advertisement: This message is originated by VTP Server and Client switch-

es after modifying the VLAN database. Subset Advertisements carry full contents of

the VLAN database. One Subset Advertisement can hold multiple VLAN database

entries. However, multiple Subset Advertisements might be required if the VLAN

database is large.

■ Advertisement Request: This message is originated by VTP Server and Client

switches to request their neighbors send the complete VLAN database or a part of

it. Advertisement requests are sent when a VTP Client switch is restarted, when a

switch enters the Client mode, or when a Server or Client switch receives a Summary

Advertisement with a higher revision number than its own.

■ Join: This message is originated by each VTP Server and Client switch periodically

every 6 seconds if VTP Pruning is active. Join messages contain a bit field that, for

each VLAN in the normal range, indicates whether it is active or unused (that is,

pruned).

At press time, the details about VTPv3 message types were not made public.

Key

Topic

Key

Topic

ptg13046388

86 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Note In any VTP version, VTP messages are transmitted and accepted only on trunk

ports. Access ports neither send nor accept VTP messages. For two switches to communi-

cate in VTP, they must first be interconnected through a working trunk link.

VTP Process and Revision Numbers

Let us first have a look at the VTPv1 and VTPv2 update process. Differences in VTPv3

will be explained later.

In VTPv1 and VTPv2, the update process begins when a switch administrator, from a

VTP server switch, adds, deletes, or updates the configuration for a VLAN. When the

new configuration occurs, the VTP server increments the old VTP revision number by

1 and advertises the entire VLAN configuration database along with the new revision

number.

The VTP revision number concept allows switches to know when VLAN database chang-

es have occurred. Upon receiving a VTP update, if the revision number in a received VTP

update is larger than a switch’s current revision number, it believes that there is a new ver-

sion of the VLAN database. Figure 2-7 shows an example in which the old VTP revision

number was 3; the server adds a new VLAN (incrementing the revision number to 4), and

then propagates the VTP database to the other switches.

1 Add New VLAN

2 Rev 3 Rev 4

5 Sync New VLAN Info

4 Rev 3 Rev 4

VTP

Client

VTP

client

VTP

Server

3 Send VTP Advertisement

4 Rev 3 Rev 4

3 Send VTP Advertisement

5 Sync New VLAN Info

Figure 2-7 VTP Revision Number Basic Operation

Cisco switches default to use VTP server mode, but they do not start sending VTP

updates until the switch has been configured with a VTP domain name. At that point,

the server begins to send its VTP updates, with an updated database and revision number

each time its VLAN configuration changes. However, the VTP clients in Figure 2-7 actu-

ally do not have to have the VTP domain name configured. If not configured yet, the cli-

ent will assume that it should use the VTP domain name in the first received VTP update.

However, the client does need one small bit of configuration, namely, the VTP mode, as

configured with the vtp mode global configuration command. As a side note, switches

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 87

must of course be interconnected with trunk links, as VTP messages are exchanged only

over trunks.

VTP clients and servers alike will accept VTP updates from other VTP server and client

switches. For better availability, a switched network using VTP needs at least two VTP

server switches. Under normal operations, a VLAN change could be made on one server

switch, and the other VTP server (plus all the clients) would learn about the changes to

the VLAN database. Once learned, both VTP servers and clients store the VLAN con-

figuration in their respective vlan.dat files in flash memory; they do not store the VLAN

configuration in NVRAM.

With multiple VTP servers installed in a LAN, it is possible to accidentally overwrite the

VTP configuration in the network. If trunks fail and then changes are made on more than

one VTP server, the VTP configuration databases could differ, with different configura-

tion revision numbers. When the formerly separated parts of the LAN reconnect using

trunks, the VTP database with a higher revision number is propagated throughout the

VTP domain, replacing some switches’ VTP databases. Note also that because VTP cli-

ents can actually originate VTP updates, under the right circumstances, a VTP client can

update the VTP database on another VTP client or server. In summary, for a newly con-

nected VTP server or client to change another switch’s VTP database, the following must

be true:

■ The new link connecting the new switch is trunking.

■ The new switch has the same VTP domain name as the other switches.

■ The new switch’s revision number is higher than that of the existing switches.

■ The new switch must have the same password, if configured on the existing

switches.

To protect a VTP domain from being joined by unauthorized switches, use VTP pass-

words. VTP Summary Advertisements carry an MD5 hash computed over the VLAN

database contents and the VTP password if configured. After receiving an update to

the VLAN database in the form of a Summary Advertisement and at least one Subset

Advertisement, the receiving switch computes its own MD5 hash over the contents of

the VLAN database reconstituted from these messages and its own VTP password, and

compares it to the MD5 hash value indicated in the Summary Advertisement. For these

MD5 hash values to match, the sending and receiving switch must be using the same

VTP password and the messages must be genuine (that is, not changed or tampered

with during transit). Contrary to the popular belief, the MD5 hash present in Summary

Advertisements is not computed from the VTP password alone. Also, the MD5 hash—

being present only in Summary Advertisements—is not used to protect VTP messages

themselves. Some installations simply use VTP transparent or off mode on all switches,

which prevents switches from ever listening to other switches’ VTP updates and errone-

ously modifying their VLAN configuration databases.

ptg13046388

88 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

VTPv3 addresses the problem of inadvertent (or intentional) rewrite of a VLAN database

by introducing the concept of a primary server . A primary server is the only switch

in a VTPv3 domain whose VLAN database can be propagated throughout the domain.

VTPv3 servers and clients will share their VLAN database only if they agree both on the

domain name and on the identity of a primary server (given by its base MAC address).

Also, a primary server is the only switch that allows an administrator to perform modifi-

cations to the VLAN database.

Other VTPv3 switches configured as servers are called secondary servers . Unlike

VTPv1/VTPv2 servers, secondary servers in VTPv3 do not permit an administrator to

modify the VLAN database; rather, they are only eligible to be promoted to the role of

a primary server, taking over this role from the existing primary server if present. Clients

in VTPv3 neither allow an administrator to modify the VLAN database nor are eligible

to be promoted to the primary server role. Both secondary servers and clients store a

copy of the primary server’s VLAN database and will share it with their neighboring serv-

ers and clients that agree on the identity of the primary server. This means that even in

VTPv3, a secondary server or a client switch with a higher revision number can overwrite

a neighbor’s VLAN database, but for this to occur, these switches must first match on the

domain name, primary server’s identity, and VTP password.

The state of two or more server or client switches in a VTPv3 domain having different

opinions about the identity of a primary server is called a conflict . Conflicting switches

do not synchronize their VLAN databases even if all other VTP parameters match. This

concept of a conflict is at the core of VTPv3’s improved resiliency against inadvertent

VLAN database overwrites. Because changes to the VLAN database can only be per-

formed on a primary server, switches that agree on the primary server’s identity also

immediately share the primary server’s database. If a switch is disconnected from the

network, unless it is the primary server itself, its VLAN database can be modified only if

that switch is promoted to a primary server while disconnected. After this switch is con-

nected back to the network, its idea of the primary server’s identity does not match its

neighbors’ knowledge about the primary server; that is, a conflict exists. Therefore, even

if its revision number is higher, its VLAN database will not be accepted by its neighbors.

This way, the possibility of inadvertent VLAN database overwrites is greatly reduced,

though not completely avoided.

There can be at most one primary server in a VTPv3 domain. Only switches configured

as VTPv3 servers can be promoted to the role of a primary server, and the promotion is

always performed in the privileged EXEC mode by invoking the vtp primary command.

The state of a primary server is therefore a volatile runtime state that cannot be perma-

nently stored in the configuration. After a primary server is reloaded, it comes back only

as a secondary server again. A switch newly promoted to the role of a primary server

using the vtp primary command will flood its VLAN database to its neighbors, and they

will install and flood it further even if the new primary server’s revision number is lower.

This way, the new primary server’s database is asserted over the VTP domain.

With VTPv3, it is no longer possible to reset the configuration revision number to 0 by

setting the switch to the transparent mode and back. The revision number will be reset to

0 only by modifying the VTP domain name or by configuring a VTP password.

Key

Topic

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 89

If a VTPv3 switch detects an older switch running VTPv1 or VTPv2 on its port, it will

revert to VTPv2 operation on that port, forcing the older switch to operate in VTPv2

mode. Cooperation between VTPv3 and VTPv1-only switches is not supported.

VTP Configuration

VTP sends updates out all active trunk interfaces (ISL or 802.1Q) by default. However,

with all default settings from Cisco, switches are in server mode, with no VTP domain

name configured, and they do not send any VTP updates. Before any switches can learn

VLAN information from another switch, a working trunk must interconnect them, and

at least one switch must have a bare-minimum VTP server configuration—specifically, a

domain name.

Example 2-10 shows Switch3 configuring a VTP domain name to become a VTP server

and advertise the VLANs it has configured. The example also lists several key VTP

show commands. (Note that the example begins with VLANs 21 and 22 configured on

Switch3, and all default settings for VTP on all four switches. Also keep in mind that the

output of various show commands can differ from this example depending on your IOS

version and VTP version supported/activated.)

Example 2-10 VTP Configuration and show Command Example

! First, Switch3 is configured with a VTP domain ID of CCIE-domain.

Switch3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

Switch3(config)# vtp domain CCIE-domain

Changing VTP domain name from NULL to CCIE-domain

! Next, on Switch1, the VTP status shows the same revision as Switch3, and it

! learned the VTP domain name CCIE-domain. Note that Switch1 has no VTP-related

! configuration, so it is a VTP server; it learned the VTP domain name from

! Switch3.

Switch1# show vtp status

VTP Version capable : 1 to 3

VTP version running : 1

VTP Domain Name : CCIE-domain

VTP Pruning Mode : Disabled

VTP Traps Generation : Disabled

Device ID : 0023.ea41.ca00

Configuration last modified by 10.1.1.3 at 9-9-13 13:31:46

Local updater ID is 10.1.1.1 on interface Vl1 (lowest numbered VLAN interface

found)

ptg13046388

90 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Feature VLAN:

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

VTP Operating Mode : Server

Maximum VLANs supported locally : 1005

Number of existing VLANs : 7

Configuration Revision : 2

MD5 digest : 0x0E 0x07 0x9D 0x9A 0x27 0x10 0x6C 0x0B

0x0E 0x35 0x98 0x1E 0x2F 0xEE 0x88 0x88

! The show vlan brief command lists the VLANs learned from Switch3.

Switch1# show vlan brief

VLAN Name Status Ports

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

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4

Fa0/5, Fa0/6, Fa0/7, Fa0/10

Fa0/11, Fa0/13, Fa0/14, Fa0/15

Fa0/16, Fa0/17, Fa0/18, Fa0/19

Fa0/20, Fa0/21, Fa0/22, Fa0/23

Gi0/2

21 VLAN0021 active

22 ccie-vlan-22 active

1002 fddi-default act/unsup

1003 token-ring-default act/unsup

1004 fddinet-default act/unsup

1005 trnet-default act/unsup

Example 2-11 shows examples of a few VTP configuration options. Table 2-7 provides a

list of the most used options, along with explanations.

Table 2-7 VTP Global Configuration Options

Option Meaning

domain Sets the name of the VTP domain. Received VTP messages are ignored if the

domain name indicated in these messages does not match the receiving switch’s

domain name. A switch can be a member of a single domain only.

password Sets the password to prevent unauthorized switches from joining the domain.

The password is taken into account when generating the MD5 hash of the VLAN

database. Received VTP updates are ignored if the passwords on the sending

and receiving switch do not match. If VTPv3 is used, the password can also

be specified as hidden , meaning that the password will never be displayed in

plaintext in the show vtp password output. The secret keyword is used when

entering the password in an already encrypted form.

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 91

Option Meaning

mode Sets server, client, or transparent mode on the switch. If VTPv3 is supported, it

is also possible to set the off mode, effectively disabling VTP on the switch.

version Sets VTP version. Configuring the version 1 or 2 on a server switch applies to all

switches in the domain. VTPv3 has to be configured manually on each switch.

Prior to activating version 3, the switch must use a non-NULL domain name.

pruning Enables VTP pruning, which prevents flooding on a per-VLAN basis to switches

that do not have any ports configured as members of that VLAN. Regardless of

the VTP version, the pruning applies only to normal-range VLANs.

interface Specifies the interface whose IP address is used to identify this switch as an

updater in VTP updates. By default, a configured IP address from the lowest

numbered VLAN SVI interface will be used.

Example 2-11 shows the use of VTPv3. Differences in running VTPv3 are most visible

in the need of designating a selected switch as the primary server using the vtp primary

command before changes to the VLAN database can be performed on it, and in the way

VTP passwords are used. While not shown in the following example, VTPv3 can also be

deactivated either globally on the switch using the vtp mode off command, or on a per-

interface basis using the simple no vtp command (the status of VTP on individual inter-

faces can be conveniently verified using the show vtp interface command). It is worth

noting that after changing the VTP mode from off to any other mode, all existing VLANs

except those hardwired into IOS (1, 1002–1005) will be deleted.

Example 2-11 Use of VTPv3 Example

! To use VTPv3, each switch has to be configured individually for version 3 opera-

! tion. It is assumed that all four switches have been converted to VTPv3. Switches

! 1 and 2 are configured as VTP servers, switches 3 and 4 are configured as VTP

! clients. Only the Switch3 configuration is shown here for brevity purposes.

Switch3(config)# vtp version 3

Switch3(config)#

Sep 9 15:49:34.493: %SW_VLAN-6-OLD_CONFIG_FILE_READ: Old version 2 VLAN configura-

tion file detected and read OK. Version 3

files will be written in the future.

Switch3(config)# vtp mode client

Setting device to VTP Client mode for VLANS.

! An attempt to create a new VLAN on Switch1 will fail, as the Switch1 has not yet

! been promoted to the role of primary server. The example also shows how to

! promote it, and subsequently create the VLAN without further obstacles. The "No

ptg13046388

92 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! conflicting VTP3 devices found." statement means that all switches in the VTP

! domain agree on the identity of the current primary server and thus share its

! VLAN database.

Switch1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

Switch1(config)# vlan 23

VTP VLAN configuration not allowed when device is not the primary server for vlan

database.

Switch1(config)# do vtp primary

This system is becoming primary server for feature vlan

No conflicting VTP3 devices found.

Do you want to continue? [confirm]

Switch1(config)#

Sep 9 17:06:59.332: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0023.ea41.ca00 has become

the primary server for the VLAN VTP feature

Switch1(config)# vlan 23

Switch1(config-vlan)# name ccie-vlan-23

Switch1(config-vlan)# exit

! On Switch3, the show vtp status shows:

Switch3(config)# do show vtp status

VTP Version capable : 1 to 3

VTP version running : 3

VTP Domain Name : CCIE-domain

VTP Pruning Mode : Disabled

VTP Traps Generation : Disabled

Device ID : 0023.ea93.8e80

Feature VLAN:

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

VTP Operating Mode : Client

Number of existing VLANs : 8

Number of existing extended VLANs : 0

Maximum VLANs supported locally : 255

Configuration Revision : 2

Primary ID : 0023.ea41.ca00

Primary Description : Switch1

MD5 digest : 0x2A 0x42 0xC5 0x50 0x4B 0x9C 0xB6 0xDE

0x17 0x8E 0xE0 0xB6 0x2E 0x67 0xA4 0x9C

Feature MST:

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

VTP Operating Mode : Transparent

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 93

Feature UNKNOWN:

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

VTP Operating Mode : Transparent

! Trying to promote the Switch3 to the role of primary server would fail, as it is

! configured to operate as a client:

Switch3(config)# do vtp primary

System can become primary server for Vlan feature only when configured as a server

! The password handling in VTPv3 has been improved. The password can be configured

! as being hidden, in which case it will never be displayed again in plaintext:

Switch1(config)# vtp password S3cr3tP4ssw0rd hidden

Setting device VTP password

Switch1(config)# do show vtp password

VTP Password: 8C70EFBABDD6EC0300A57BE402409C48

! This string can be used to populate the password setting on other switches

! without ever knowing the plaintext form, e.g.:

Switch2(config)# vtp password 8C70EFBABDD6EC0300A57BE402409C48 secret

Setting device VTP password

! After the password is configured in the secret form (or originally configured in

! the plain form and marked hidden), any attempt to promote a switch to the primary

! server role will require entering the password in the plaintext form into the

! CLI. Without knowing the plaintext form of the password, it is not possible to

! designate a switch as a primary server:

Switch2(config)# do vtp primary

This system is becoming primary server for feature vlan

Enter VTP Password: <entering 8C70EFBABDD6EC0300A57BE402409C48>

Password mismatch

Switch2(config)# do vtp primary

This system is becoming primary server for feature vlan

Enter VTP Password: <entering S3cr3tP4ssw0rd>

No conflicting VTP3 devices found.

Do you want to continue? [confirm]

Switch2(config)#

Sep 9 17:10:42.215: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0017.9446.b300 has become

the primary server for the VLAN VTP feature

ptg13046388

94 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Normal-Range and Extended-Range VLANs

Because of historical reasons, some VLAN numbers are considered to be normal , where-

as some others are considered to be extended . Normal-range VLANs are VLANs 1–1005,

and can be advertised through VTP versions 1 and 2. These VLANs can be configured

both in VLAN database mode and in global configuration mode, with the details being

stored in the vlan.dat file in Flash.

Extended-range VLANs range from 1006–4094, inclusive. However, if using VTPv1 or

VTPv2, these additional VLANs cannot be configured in VLAN database mode, nor

stored in the vlan.dat file, nor advertised through VTP. In fact, to configure them, the

switch must be in VTP transparent mode. (Also, you should take care to avoid using

VLANs 1006–1024 for compatibility with CatOS-based switches.) VTPv3 removes these

limitations: Both normal- and extended-range VLANs can be advertised by VTPv3. Also,

with VTPv3, information about all VLANs is again stored in the vlan.dat file in Flash.

Both ISL and 802.1Q support extended-range VLANs today. Originally, ISL began life

only supporting normal-range VLANs, using only 10 of the 15 bits reserved in the ISL

header to identify the VLAN ID. The later-defined 802.1Q used a 12-bit VLAN ID field,

thereby allowing support of the extended range. Following that, Cisco changed ISL to

use 12 of its reserved 15 bits in the VLAN ID field, thereby supporting the extended

range.

Table 2-8 summarizes VLAN numbers and provides some additional notes.

Table 2-8 Valid VLAN Numbers, Normal and Extended

VLAN

Number

Normal or

Extended?

Can Be Advertised

and Pruned by VTP

Versions 1 and 2?

Comments

0 Reserved — Not available for use

1 Normal No On Cisco switches, the default VLAN

for all access ports; cannot be deleted or

changed

2–1001 Normal Yes —

1002–1005 Normal No Defined specifically for use with FDDI

and TR translational bridging

1006–4094 Extended No —

4095 Reserved No Not available for use

Storing VLAN Configuration

Catalyst IOS stores VLAN and VTP configuration in one of two places—either in a Flash

file called vlan.dat or in the running configuration. (Remember that the term “Catalyst

Key

Topic

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 95

IOS” refers to a switch that uses IOS, not the Catalyst OS, which is often called CatOS.)

IOS chooses the storage location in part based on the VTP version and mode, and in part

based on whether the VLANs are normal-range VLANs or extended-range VLANs. Table

2-9 describes what happens based on what configuration mode is used to configure

the VLANs, the VTP mode, and the VLAN range. (Note that VTPv1/VTPv2 clients also

store the VLAN configuration in vlan.dat, and they do not understand extended-range

VLANs.)

Table 2-9 VLAN Configuration and Storage for VTPv1 and VTPv2

Function When in VTP Server Mode When in VTP

Transparent Mode

Normal-range VLANs can be

configured from

Both VLAN database and

configuration modes

Both VLAN database and

configuration modes

Extended-range VLANs can be

configured from

Nowhere—cannot be

configured

Configuration mode only

VTP and normal-range VLAN

configuration commands are

stored in

vlan.dat in Flash Both vlan.dat in Flash and

running configuration

Extended-range VLAN

configuration commands are

stored in

Nowhere—extended range

not allowed in VTP server

mode

Running configuration

only

1 When a switch reloads, if the VTP mode or domain name in the vlan.dat file and the startup config file

differs, the switch uses only the vlan.dat file’s contents for VLAN configuration.

Note The configuration characteristics referenced in Table 2-9 do not include the inter-

face configuration command switchport access vlan; they include the commands that cre-

ate a VLAN (vlan command) and VTP configuration commands.

For VTPv3, the situation is greatly simplified: Regardless of the mode (server, client,

transparent, or off), both normal- and extended-range VLANs are stored in the vlan.dat

file. If transparent or off mode is selected, VLANs are also present in the running-config.

Of particular interest for those of you stronger with CatOS configuration skills is that

when you erase the startup-config file and reload the Cisco IOS switch, you do not actu-

ally erase the normal-range VLAN and VTP configuration information. To erase the

VLAN and VTP configuration, you must use the delete flash:vlan.dat EXEC command.

Also note that if multiple switches are in VTP server mode, if you delete vlan.dat on one

switch and then reload it, as soon as the switch comes back up and brings up a trunk, it

learns the old VLAN database through a VTP update from the other VTP server.

Key

Topic

ptg13046388

96 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Configuring PPPoE

Although it might seem out of place in this chapter on VLANs and VLAN trunk-

ing, Point-to-Point Protocol over Ethernet (PPPoE) fits best here. Somewhat similar to

VLANs that virtualize Ethernet switched infrastructure into multiple isolated multiaccess

switched environments, PPPoE virtualizes Ethernet into multiple point-to-point sessions

between client hosts and an access concentrator, turning the broadcast Ethernet into a

point-to-multipoint environment. PPP itself is a great Layer2 protocol for point-to-point

links, with capabilities very well suited to a service provider’s needs, such as per-user

authentication (and resulting billing), negotiation of allowed higher protocols carried

over the PPP link including their settings (such as endpoint IP addresses), negotiation of

compression, link bundling (also called multilink), and so on. PPPoE described in RFC

2516 was originally conceived as a method for carrying PPP-based sessions over Ethernet

access networks often used in service provider networks, with the PPPoE software client

running on a PC equipped with an ordinary Ethernet card. With the advent of Digital

Subscriber Line (DSL) technology, the use of PPPoE with DSL allowed for a simple

deployment. Client PCs continued to run PPPoE software clients, while a DSL modem

connected to a common LAN with the client PCs simply took the Ethernet frames con-

taining PPP datagrams and transmitted them inside a series of ATM cells over the DSL

interface, essentially bridging them over the ATM-based DSL network to the Broadband

Remote Access Server (BRAS). In the opposite direction, the modem received Ethernet

frames encapsulated in series of ATM cells, reconstructed them and forwarded them onto

the LAN. As the features of routers improved, the PPPoE client functionality moved from

PCs to the router connected to the DSL network itself.

The PPPoE client feature permits a Cisco IOS router, rather than an endpoint host, to

serve as the client in a network. This permits entire LANs to connect to the Internet over

a single PPPoE connection terminated at the single router.

In a DSL environment, PPP interface IP addresses are derived from an upstream DHCP

server using IP Configuration Protocol (IPCP), a subprotocol of PPP. Therefore, IP

address negotiation must be enabled on the router’s dialer interface. This is done using

the ip address negotiated command in the dialer interface configuration.

Because PPPoE introduces an 8-byte overhead (2 bytes for the PPP header and 6 bytes

for PPPoE), the MTU for PPPoE is usually decreased to 1492 bytes so that the entire

encapsulated frame fits within the 1500-byte Ethernet frame. Additionally, for TCP ses-

sions, the negotiated Maximum Segment Size is clamped down to 1452 bytes, allowing

for 40 bytes in TCP and IP headers and 8 bytes in the PPPoE, totaling 1500 bytes that

must fit into an ordinary Ethernet frame. A maximum transmission unit (MTU) mismatch

can prevent a PPPoE connection from coming up or from properly carrying large data-

grams. Checking the MTU setting is a good first step when troubleshooting PPPoE con-

nections.

Those familiar with ISDN BRI configuration will recognize the dialer interface configura-

tion and related commands in Example 2-11 . The key difference between ISDN BRI con-

figuration and PPPoE is the pppoe-client dial-pool-number command.

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 97

Configuring an Ethernet edge router for PPPoE Client mode is the focus of this section.

This task requires configuring the Ethernet interface (physical or subinterface) and a cor-

responding dialer interface.

Figure 2-8 shows the topology. Example 2-12 shows the configuration steps. The first step

is to configure the outside Ethernet interface as a PPPoE client and assign it to a dialer

interface. The second step is to configure the corresponding dialer interface. Additional

steps, including Network Address Translation (NAT) configuration, are also shown.

Workstations

EdgeRouter

DSL

Access

Multiplexer

LAN

Fa0/0

ATM

Network

DSL

CPE

Access

Concentrator

Fa0/1

Figure 2-8 PPPoE Topology for Example 2-12

Example 2-12 Configuring PPPoE on EdgeRouter

EdgeRouter# conf t

EdgeRouter(config)# interface fa0/0

EdgeRouter(config-if)# no shutdown

EdgeRouter(config-if)# ip address 192.168.100.1 255.255.255.0

EdgeRouter(config-if)# ip nat inside

EdgeRouter(config)# interface fa0/1

EdgeRouter(config-if)# no shutdown

EdgeRouter(config-if)# pppoe-client dial-pool-number 1

EdgeRouter(config-if)# exit

EdgeRouter(config)# interface dialer1

EdgeRouter(config-if)# mtu 1492

EdgeRouter(config-if)# ip tcp adjust-mss 1452

EdgeRouter(config-if)# encapsulation ppp

EdgeRouter(config-if)# ip address negotiated

EdgeRouter(config-if)# ppp chap hostname Username@ISP

EdgeRouter(config-if)# ppp chap password Password4ISP

EdgeRouter(config-if)# ip nat outside

ptg13046388

98 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

EdgeRouter(config-if)# dialer pool 1

EdgeRouter(config-if)# exit

EdgeRouter(config)# ip nat inside source list 1 interface dialer1 overload

EdgeRouter(config)# access-list 1 permit 192.168.100.0 0.0.0.255

EdgeRouter(config)# ip route 0.0.0.0 0.0.0.0 dialer1

You can verify PPPoE connectivity using the show pppoe session command. Cisco IOS

includes debug functionality for PPPoE through the debug pppoe [ data | errors | events |

packets ] command.

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 99

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter as well as review items noted with a Key Topic icon.

Table 2-10 lists some of the most popular IOS commands related to the topics in this

chapter. (The command syntax was retaken from the Catalyst 3560 Multilayer Switch

Command Reference, 15.0(2)SE . Note that some switch platforms might have differences

in the command syntax.)

Table 2-10 Catalyst IOS Commands Related to Chapter 2

Command Description

show mac address-table [ aging-time |

count | dynamic | static ] [ address hw-addr ]

[ interface interface-id ] [ vlan vlan-id ]

Displays the MAC address table; the security

option displays information about the

restricted or static settings

show interfaces [ interface-id ] switchport |

trunk ]

Displays detailed information about an

interface operating as an access port or a

trunk

show vlan [ brief | id vlan-id | internal usage |

name vlan-name | private-vlan | summary ]

EXEC command that lists information about

the VLAN

show vtp status Lists VTP configuration and status

information

switchport mode { access | dot1q-tunnel |

dynamic { auto | desirable } | private-vlan

{ host | promiscuous } | trunk }

Configuration command setting nontrunking

( access , private-vlan ), tunneling ( dot1q-

tunnel ) trunking ( trunk ), and dynamic

trunking ( auto and desirable ) parameters

switchport nonegotiate Interface subcommand that disables DTP

messages; interface must not be configured

as a dynamic port

switchport trunk { allowed vlan vlan-list }

| { encapsulation { dot1q | isl | negotiate }} |

{ native vlan vlan-id } | { pruning vlan vlan-list }

Interface subcommand used to set

parameters used when the port is trunking

switchport access vlan vlan-id Interface subcommand that statically

configures the interface as a member of that

one VLAN

ptg13046388

100 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 2-11 lists the commands related to VLAN creation—both the VLAN database

mode configuration commands (reached with the vlan database privileged mode com-

mand) and the normal configuration mode commands.

Note Some command parameters might not be listed in Table 2-11.

Table 2-11 VLAN Database and Configuration Mode Command List and Comparison

VLAN Database Configuration

vtp { domain domain-name | password

password | pruning | v2-mode | { server |

client | transparent }}

vtp { domain domain-name | file filename

| interface name | mode { client | server |

transparent | off } | password password [

hidden | secret ] | pruning | version number }

vlan vlan-id [ name vlan-name ] [ state { active

| suspend }]

vlan vlan-id

show { current | proposed | difference } No equivalent

apply | abort | reset No equivalent

Table 2-12 Cisco IOS PPPoE Client Commands

Command Description

pppoe-client dial-pool-number

number

Configures the outside Ethernet interface on a router

for PPPoE operation and assigns the PPPoE client

into a dialer pool to be used later by a dialer interface

debug pppoe [ data | errors | events

| packets ]

Enables debugging for PPPoE troubleshooting

ptg13046388

Chapter 2: Virtual LANs and VLAN Trunking 101

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Fill In Key Tables from Memory

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD to check your answers.

Definitions

Next, take a few moments to write down the definitions for the following terms:

VLAN, broadcast domain, DTP, VTP pruning, 802.1Q, ISL, native VLAN, encapsula-

tion, Private VLAN, promiscuous port, community VLAN, isolated VLAN, promis-

cuous port, community port, isolated port, 802.1Q-in-Q, Layer 2 protocol tunneling,

PPPoE, DSL.

Refer to the glossary to check your answers.

Further Reading

The topics in this chapter tend to be covered in slightly more detail in CCNP Switching

exam preparation books. For more details on these topics, refer to the Cisco Press CCNP

preparation books found at www.ciscopress.com/ccnp .

Cisco LAN Switching , by Kennedy Clark and Kevin Hamilton, is an excellent reference

for LAN-related topics in general, and certainly very useful for CCIE written and lab

exam preparation.

DTP protocol details are not covered in official Cisco documentation; however,

DTP has been filed as U.S. Patent No. 6,445,715, which is publicly available at

www.google.com/?tbm=pts .

ptg13046388

Blueprint topics covered in this chap ter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ Spanning Tree Protocol

■ 802.1D STP

■ 802.1w RSTP

■ 802.1s MST

■ Loop Guard

■ Root Guard

■ EtherChannel Misconfiguration Guard

■ BPDU Guard and BPDU Filter

■ UDLD

■ Bridge Assurance

■ EtherChannel

■ Troubleshooting Complex Layer 2 Issues

ptg13046388

Spanning Tree Protocol (STP) is probably one of the most widely known protocols cov-

ered on the CCIE Routing and Switching written exam. STP has been around for a long

time, is used in most every campus network today, and is covered extensively on the

CCNP SWITCH exam. This chapter covers a broad range of topics related to STP.

“Do I Know This Already?” Quiz

Table 3-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 3-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in This

Section

S c o r e

802.1D Spanning Tree Protocol and Improvements 1–8

Protecting and Optimizing Spanning Tree 9

Configuring and Troubleshooting EtherChannels 10

Troubleshooting Complex Layer 2 Issues 11

Total Score

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. Assume that a nonroot 802.1D switch has ceased to receive Hello BPDUs. Which

STP setting determines how long a nonroot switch waits before trying to choose a

new Root Port?

a. Hello timer setting on the Root

b. MaxAge timer setting on the Root

c. ForwardDelay timer setting on the Root

d. Hello timer setting on the nonroot switch

e. MaxAge timer setting on the nonroot switch

f. ForwardDelay timer setting on the nonroot switch

CHAPTER 3

Spanning Tree Protocol

ptg13046388

104 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

2. Assume that a nonroot 802.1D switch receives a Hello BPDU with the TCN flag set.

Which STP setting determines how long the nonroot switch waits before timing out

inactive CAM entries?

a. Hello timer setting on the Root

b. MaxAge timer setting on the Root

c. ForwardDelay timer setting on the Root

d. Hello timer setting on the nonroot switch

e. MaxAge timer setting on the nonroot switch

f. ForwardDelay timer setting on the nonroot switch

3. Assume that a nonroot Switch1 (SW1) is Discarding on an 802.1Q trunk connected

to Switch2 (SW2). Both switches are in the same MST region. SW1 ceases to receive

Hellos from SW2. What timers have an impact on how long Switch1 takes to both

become the Designated Port on that link and reach the Forwarding state?

a. Hello timer setting on the Root

b. MaxAge timer setting on the Root

c. ForwardDelay timer on the Root

d. Hello timer setting on SW1

e. MaxAge timer setting on SW1

f. ForwardDelay timer on SW1

4. Which of the following statements are true regarding support of multiple spanning

trees over an 802.1Q trunk?

a. Only one common spanning tree can be supported.

b. Cisco PVST+ supports multiple spanning trees if the switches are Cisco switches.

c. 802.1Q supports multiple spanning trees when using IEEE 802.1s MST.

d. Two PVST+ domains can pass over a region of non-Cisco switches using 802.1Q

trunks by encapsulating non-native VLAN Hellos inside the native VLAN

H e l l o s .

5. When a switch notices a failure, and the failure requires STP convergence, it notifies

the Root by sending a TCN BPDU. Which of the following best describes why the

notification is needed?

a. To speed STP convergence by having the Root converge quickly.

b. To allow the Root to keep accurate count of the number of topology changes.

c. To trigger the process that causes all switches to use a short timer to help flush

the CAM.

d. There is no need for TCN today; it is a holdover from DEC’s STP specification.

ptg13046388

Chapter 3: Spanning Tree Protocol 105

6. Two switches have four parallel Ethernet segments, none of which forms into an

EtherChannel. Assuming that 802.1D is in use, what is the maximum number of the

eight ports (four on each switch) that stabilize into a Forwarding state?

a. 1

b. 3

c. 4

d. 5

e. 7

7. IEEE 802.1w does not use the exact same port states as does 802.1D. Which of the

following are valid 802.1w port states?

a. Blocking

b. Listening

c. Learning

d. Forwarding

e. Disabled

f. Discarding

8. What STP tools or protocols supply a “MaxAge optimization,” allowing a switch to

bypass the wait for MaxAge to expire when its Root Port stops receiving Hellos?

a. Loop Guard

b. UDLD

c. BPDU Guard

d. Bridge Assurance

e. IEEE 802.1w

9. A trunk between switches lost its physical transmit path in one direction only.

Which of the following features protect against the STP problems caused by such an

event?

a. Loop Guard

b. UDLD

c. D i s p u t e

d. PortFast

ptg13046388

106 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

10. A switch has four Ethernet segments toward its neighbor, with the intention of

using them in an EtherChannel. Some settings on the physical ports on this switch

might be different and yet these ports will be allowed to be bundled in a single

EtherChannel. Which settings do not have to match?

a. DTP negotiation settings (auto/desirable/on)

b. Allowed VLAN list

c. STP per-VLAN port cost on the ports on a single switch

d. If 802.1Q, native VLAN

11. A computer’s NIC is hardcoded to 1000 Mbps and full-duplex, and it is connected

to a switch whose Fast Ethernet interface is set to autonegotiate speed and duplex.

What speed and duplex will the switch use if the autonegotiation on the computer’s

NIC is deactivated as a result of hardcoding the speed and duplex?

a. 100 Mbps and full-duplex

b. 100 Mbps and half-duplex

c. 1000 Mbps and full-duplex

d. 1000 Mbps and half-duplex

e. The link will be inactive.

ptg13046388

Chapter 3: Spanning Tree Protocol 107

Foundation Topics

802.1D Spanning Tree Protocol and Improvements

Although many CCIE candidates already know STP well, the details are easily forgotten.

For example, you can install a campus LAN, possibly turn on a few STP optimizations

and security features out of habit, and have a working LAN using STP—without ever

really contemplating how STP does what it does. And in a network that makes good use

of Layer 3 switching, each STP instance might span only three to four switches, making

the STP issues much more manageable—but more forgettable in terms of helping you

remember things you need to know for the exam. This chapter reviews the details of

IEEE 802.1D STP, and then goes on to related topics—802.1w RSTP, multiple spanning

trees, STP optimizations, and STP security features. STP terminology refers to bridges

in many places; in the following sections, the words bridge and switch will be used

interchangeably with respect to STP. While the upcoming sections about various STP

versions might appear lengthy and reiterate on many known facts, be sure to read them

very carefully in their entirety. It is always tiresome to read an in-depth discussion about

a protocol as notorious as STP—but as we know, it’s details that matter, especially for a

CCIE. This chapter tries to put several details about STP straight, cleaning up numerous

misconceptions that have crept in the common understanding of STP over the years of its

existence.

Before diving into STP internals, it is worthwhile to comment on a possible naming con-

fusion regarding various STP versions. The first IEEE-standardized STP, also often called

the “legacy” STP, was originally described in 802.1D. Its improvements were subsequently

published in so-called amendments: The Rapid STP (RSTP) was standardized in amend-

ment 802.1w, while Multiple STP (MSTP) was covered in amendment 802.1s. Since then,

the amendments have been integrated into existing standards. The latest 802.1D-2004

standard no longer includes the legacy STP at all (which is considered obsolete), and

instead, it covers the RSTP originally found in 802.1w. The 802.1s MSTP is integrated into

802.1Q-2005 and later revisions. With current standards, therefore, RSTP is covered in

802.1D while MSTP is covered in 802.1Q, and legacy STP has been dropped. Still, many

people are used to the old naming, with 802.1D referring to STP, 802.1w referring to

RSTP, and 802.1s referring to MSTP.

STP uses messaging between switches to stabilize the network into a logical loop-free

topology. To do so, STP causes some interfaces (popularly called ports when discussing

STP) to simply not forward or receive traffic—in other words, the ports are in a Blocking

state. The remaining ports, in an STP Forwarding state, together provide a loop-free path

to every Ethernet segment in the network.

STP protocol messages are called Bridge Protocol Data Units (BPDU), the basic structure

for which is shown in Figure 3-1 .

ptg13046388

108 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Configuration BPDU

BPDU Field Length in Octets

Protocol Identifier 2

Protocol Version 1

BPDU Type 1

Flags 1

Root Bridge ID 8

Root Path Cost 4

Sending Bridge ID 8

Sending Port ID 2

Message Age 2

Max Age 2

Hello Time 2

Forward Delay 2

Topology Change Notification BPDU

BPDU Field Length in Octets

Protocol Identifier 2

Protocol Version 1

BPDU Type 1

Figure 3-1 Format of STP Bridge Protocol Data Units

For STP, the Protocol Identifier value is set to 0x0000 and the Protocol Version is also set

to 0x00. The BPDU Type field identifies two kinds of STP BPDUs: Configuration BPDUs

(type 0x00) and Topology Change Notification BPDUs (type 0x80). The Flags field uses

2 bits out of 8 to handle topology change events: the Topology Change Acknowledgment

flag and the Topology Change flag. Following the Flags, there is a series of fields identify-

ing the root bridge, distance of the BPDU’s sender from the root bridge, the sender bridge’s

own identifier, and the identifier of the port on the sender bridge that forwarded this

BPDU. The MessageAge field is an estimation of the BPDU’s age since it was originated by

the root bridge. At the root bridge, it is set to 0. Any other switch will increment this value,

usually by 1, before forwarding the BPDU further. The remaining lifetime of a BPDU after

being received by a switch is MaxAge-MessageAge. Finally, the remaining fields carry the

values of STP timers: MaxAge, HelloTime, ForwardDelay. These timer values always reflect

the timer settings on the root switch. Timers configured on a nonroot switch are not used

and would become effective only if the switch itself became the root switch.

Bridges and ports are identified by their IDs in BPDUs. Without discussing the exact for-

mat at this point, an object in STP that is called “identifier,” or ID, always has a configu-

rable part called the priority , and a fixed part that cannot be modified by management.

Both bridges and ports have IDs with configurable priorities.

STP operation is based on the ability to compare any two arbitrary Configuration BPDUs

and determine which one of them is better, or superior . The other BPDU is called infe-

rior . To determine which BPDU out of a pair of BPDUs is superior, they are compared in

the following sequence of values, looking for the first occurrence of a lower value:

■ Root Bridge ID (RBID)

■ Root Path Cost (RPC)

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 109

■ Sender Bridge ID (SBID)

■ Sender Port ID (SPID)

■ Receiver Port ID (RPID; not included in the BPDU, evaluated locally)

First, the RBID value in both BPDUs is compared. If one of the BPDUs contains a

lower RBID value, this BPDU is declared superior and the comparison process stops.

Otherwise, both BPDUs carry the same RBID value and the RPC is compared. Again, if

one of the BPDUs carries a lower RPC value, this BPDU is declared superior. In case both

BPDUs carry an identical RPC value, the comparison process moves to the SBID. Should

the SBID value be also found identical, the SPID will be compared. If even the SPID

values in both BPDUs are the same, RPIDs of ports that received the same BPDU are

compared. This very last step is very uncommon and would be seen in situations where

a single BPDU was received by multiple ports of a single switch, possibly because of

multiple connections to a hub or a non-STP switch being placed somewhere in between.

In any case, precisely this capability of selecting a single superior BPDU out of a set of

BPDUs is at the core of STP’s capability to choose exactly one root bridge per a switched

environment, exactly one Root Port on a nonroot bridge, and exactly one Designated

Port for each connected network segment, as each of these roles is derived from the con-

cept of a superior BPDU. Only Configuration BPDUs are compared; Topology Change

Notification BPDUs do not convey information used to build a loop-free topology and

are not compared. Therefore, whenever a comparison of BPDUs is discussed, it is implied

that the BPDUs in question are Configuration BPDUs.

Additionally, an important fact to remember is that each port in STP stores (that is,

remembers) the superior BPDU it has either sent or received. As you will see later, Root

Ports and Blocking ports store the received BPDU sent by the “upstream” designated

switch (because that BPDU is superior to the one that would be sent out from this port),

while Designated Ports store their own sent BPDU (because that one is superior to any

received BPDU). Essentially, each port stores the Designated Port’s BPDU—whether it is

the port itself that is Designated or it is a neighbor’s port. Should a port store a received

BPDU, it must be received again within a time interval of MaxAge-MessageAge seconds;

otherwise it will expire after this period. This expiry is always driven by the timers in the

BPDU, that is, according to timers of the root switch.

In the following sections, Configuration BPDUs will also be called simply Hello BPDUs

or Hellos, as their origination is driven by the Hello timer.

Choosing Which Ports Forward: Choosing Root Ports and Designated

Ports

To determine which ports forward and block, STP follows a three-step process, as listed in

Table 3-2 . Following the table, each of the three steps is explained in more detail.

Key

Topic

ptg13046388

110 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 3-2 Three Major 802.1D STP Process Steps

Major Step Description

Elect the root switch The switch with the lowest bridge ID; the standard bridge ID is

2-byte priority followed by a MAC address unique to that switch.

Determine each switch’s

Root Port

The one port on each nonroot switch that receives the superior

resulting BPDU from among all received BPDUs on all its ports.

Determine the

Designated Port for

each segment

When multiple switches connect to the same segment, this is the

switch that forwards the superior BPDU from among all forwarded

BPDUs onto that segment.

Electing a Root Switch

Only one switch can be the root of the spanning tree; to select the root, the switches

hold an election . Each switch begins its STP logic by creating and sending an STP Hello

bridge protocol data unit (BPDU) message, claiming itself to be the root switch. If a

switch hears a superior Hello to its own Hello—namely, a Hello with a lower bridge

ID—it stops claiming to be root by ceasing to originate and send Hellos. Instead, the

switch starts forwarding the superior Hellos received from the superior candidate.

Eventually, all switches except the switch with the lowest bridge ID cease to originate

Hellos; that one switch wins the election and becomes the root switch.

The original IEEE 802.1D bridge ID held two fields:

■ The 2-byte Priority field, which was designed to be configured on the various

switches to affect the results of the STP election process.

■ A 6-byte MAC Address field, which was included as a tiebreaker, because each

switch’s bridge ID includes a MAC address value that should be unique to each

switch. As a result, some switch must win the root election.

The format of the original 802.1D bridge ID has been redefined in amendment 802.1t and

since then integrated into 802.1D-2004. Figure 3-2 shows the original and new format of

the bridge IDs.

Priority

(0 – 65,535)

System ID

(MAC Address)

System ID Extension

(Typically Holds VLAN ID)

Priority

Multiple

of 4096

6 Bytes

System ID

(MAC Address)

2 Bytes

12 Bits4 Bits

Original Format

Bridge ID

System ID

Extension

(MAC Address

Reduction)

6 Bytes

Figure 3-2 IEEE 802.1D STP Bridge ID Formats

Key

Topic

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 111

The format was changed mainly because of the advent of multiple spanning trees as sup-

ported by Per VLAN Spanning Tree Plus (PVST+) and IEEE 802.1s Multiple Spanning

Trees (MST). With the old-style bridge ID format, a switch’s bridge ID for each STP

instance (possibly one per VLAN) was identical if the switch used a single MAC address

when building the bridge ID. Because VLANs cause a single physical switch to behave as

multiple logical switches, having multiple STP instances with the same bridge ID was in

violation of the 802.1D that required a distinct bridge ID for each switch. Vendors such as

Cisco used a different MAC address for each VLAN when creating the old-style bridge

IDs. This provided a different bridge ID per VLAN, but it consumed a large number of

reserved MAC addresses in each switch.

The System ID Extension, originally described in IEEE 802.1t, allows a network to use

multiple instances of STP, even one per VLAN, but without the need to consume a

separate MAC address on each switch for each STP instance. The System ID Extension

field allows the VLAN ID to be placed into what was formerly the last 12 bits of the

Priority field. A switch can use a single MAC address to build bridge IDs and, with the

VLAN number in the System ID Extension field, still have a unique bridge ID in each

VLAN. The use of the System ID Extension field is also called MAC address reduction ,

because of the need for many fewer reserved MAC addresses on each switch. The use

of the System ID Extension on a switch is indicated by the presence of the spanning-

tree extend system-id command in global configuration mode. Older switches equipped

with a larger reserve of MAC addresses allow this command to be removed, reverting

to the old-style bridge IDs. Recent switches, however, do not allow this command to be

removed even though it is displayed in the running config, and always use the System ID

Extension.

Determining the Root Port

After the root switch is elected, the rest of the switches now need to determine their

Root Port (RP) . The process proceeds as described in the following list:

1. The root switch creates and sends a Hello every Hello timer (2 seconds by default).

This Hello contains the RBID and SBID fields set to the ID of the root, RPC set to 0,

and SPID set to the identifier of the egress port.

2. Each nonroot switch receiving a BPDU on a particular port adds that port’s cost to

the RPC value in the received BPDU, yielding a resulting BPDU. Subsequently, the

switch declares the port receiving the superior resulting BPDU as its Root Port.

3. Hellos received on the Root Port of a nonroot switch are forwarded through its

remaining designated ports after updating the RPC, SBID, SPID, and MessageAge

fields accordingly. Hellos received on other ports of a nonroot switch are processed

but they are not forwarded.

4. Switches do not forward Hellos out Root Ports and ports that stabilize into a

Blocking state. Hellos forwarded out these ports would be inferior (and therefore

uninteresting) to Hellos originated by some neighboring switch’s Designated Port on

those segments.

Key

Topic

ptg13046388

112 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The result of this process is that each nonroot switch chooses exactly one port as its

Root Port, as there is always only a single received Hello that is superior over all other

received Hellos. According to the sequence of compared fields in received Hellos when

selecting a superior BPDU, a Root Port always provides the least-cost path toward the

switch with the lowest Bridge ID (that is, the root switch). If there are multiple equal-cost

paths, additional tiebreakers (SBID, SPID, RPID) will allow the receiving switch to always

choose exactly one path in a deterministic fashion: first, port toward the neighbor with

the lowest Bridge ID; then, if there are multiple links toward that neighbor, port con-

nected to the neighbor’s port with the lowest Port ID; and finally, if the same BPDU is

received on multiple ports at once, the receiving port with the lowest Port ID.

In this sense, the STP operation is quite similar to the operation of the Routing

Information Protocol (RIP), the simplest distance-vector routing protocol. Just like RIP,

STP tries to find the least-cost path toward a particular destination, in this case, the root

bridge, and has additional criteria to select a single path if there are multiple least-cost

paths available. Hellos can be likened to RIP Update messages with RBID identifying the

destination , RPC expressing the next hop’s metric to the destination, SBID being the

next-hop identifier , and SPID identifying the next hop’s interface . Each time a Hello is

received, the receiving switch can be thought to reevaluate its choice of a Root Port and

updates the choice if necessary, just like a RIP router receives updates every 30 seconds

and reevaluates its choice of least-cost paths to individual destinations. In fact, STP can

be seen as a special case of a timer-driven distance-vector routing protocol, selecting

exactly one path to exactly one particular destination, the root bridge. This makes STP

similar to, though of course not entirely analogous to, RIP.

A switch must examine the RPC value in each Hello, plus the switch’s STP port costs, to

determine its least-cost path to reach the root. To do so, the switch adds the cost listed in

the Hello message to the switch’s port cost of the port on which the Hello was received.

For example, Figure 3-3 shows the loop network design and details several STP cost cal-

culations.

Fa0/4

Cost 19

Cost 1

Cost 19

Cost out fa0/1 = 0 +

100 = 100; cost out

fa0/4 = 38 + 19 = 57!

Fa0/1

Cost 100

Root Hello Cost 0

Loop Design – All Port Costs 19 Unless Shown

Adding my incoming cost

setting fields for forwarder’s

bridge ID, port priority, and

port number.

Hello Cost 38

Hello Cost 19

Hello Cost 0

SW1

SW3

SW2

SW4

Figure 3-3 Calculating STP Costs to Determine RPs

ptg13046388

Chapter 3: Spanning Tree Protocol 113

In Figure 3-3 , SW1 happened to become root, and is originating Hellos of cost 0. SW3

receives two Hellos, one with cost 0 and one with cost 38. However, SW3 must then cal-

culate its cost to reach the root, which is the advertised cost (0 and 38, respectively) plus

SW3’s port costs (100 and 19, respectively). As a result, although SW3 has a direct link

to SW1, the calculated cost is lower out interface Fa0/4 (cost 57) than it is out interface

Fa0/1 (cost 100), so SW3 chooses its Fa0/4 interface as its RP.

Note Many people think of STP costs as being associated with a segment; however, the

cost is actually associated with interfaces. Good design practices dictate using the same

STP cost on each end of a point-to-point Ethernet segment, but the values can be different.

While the costs shown in Figure 3-3 might seem a bit contrived, the same result would

happen with default port costs if the link from SW1 to SW3 were Fast Ethernet (default

cost 19), and the other links were Gigabit Ethernet (default cost 4). Table 3-3 lists the

default port costs according to various revisions of the IEEE 802.1D standard. Before

802.1D-1998, IEEE did not specify any recommended STP port cost values for differ-

ent link speeds in their standard. Speeds shown in Table 3-3 were chosen by Cisco and

used in its STP implementations of that time. The 802.1D-1998 revision of the standard

provided a table of recommended values, but as the speeds of Ethernet links continued to

increase dramatically, IEEE revised these recommended values again in its 802.1D-2004

revision of the standard. On recent Catalyst switches, the default costs correspond to the

802.1D-1998 version of the standard if PVST or Rapid PVST is used, and to the 802.1D-

2004 version if MSTP is used. With PVST and Rapid PVST, the 802.1D-2004 costs can be

activated using the spanning-tree pathcost method long global configuration command.

By default, spanning-tree pathcost method short is configured, causing the switch to

use the older revision of the costs.

Table 3-3 Default Port Costs

Port speed Pre-802.1D-1998

Cost

802.1D-1998

Cost

802.1D-2004

Cost

10 Mbps 100 100 2000000

100 Mbps 10 19 200000

1 Gbps 1 4 20000

10 Gbps 1 2 2000

Determining the Designated Port

A converged STP topology results in only one switch forwarding Hellos onto each LAN

segment. The switch that forwards Hellos onto a LAN segment is called the designated

switch for that segment, and the port that it uses to forward frames onto that segment is

Key

Topic

ptg13046388

114 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

called the Designated Port (DP) . All remaining ports on a switch that have been deter-

mined as neither Root nor Designated will be moved to Blocking state. In the following

text, they will be labeled as Non-Designated ports.

To win the right to be the DP, a switch must send superior Hellos onto the segment. For

example, consider the segment between SW3 and SW4 in Figure 3-3 before the DP has

been determined on that segment. SW3 would get Hellos directly from SW1, compute

its cost to the root over that path, and then forward the Hello out its Fa0/4 interface to

SW4, with RPC set to 100. Similarly, SW4 will forward a Hello with RPC of 38, as shown

in Figure 3-3 . SW4’s port on this segment becomes the DP, as it sends superior Hellos

because of their lower RPC value. Even after SW3 selects its Fa0/4 as the Root Port (as it

receives superior resulting BPDUs from among all ports on SW3), any Hellos sent from

SW3’s Fa0/4 port would indicate the RPC of 57, still being inferior to SW4’s Hellos.

Only the DP forwards Hellos onto a LAN segment. In the same example, SW4 keeps

sending the Hellos with an RPC of 38 out the port, but SW3 stops sending its inferior

Hellos. There would be no harm if SW3 continued to send its inferior BPDUs out its

Fa0/1 and Fa0/4 ports, but because STP always cares only for superior BPDUs, this would

be a waste of effort. Therefore, neither Root Ports nor ports in the Blocking state send

BPDUs.

The tiebreakers during DP selection are the same as before: first, the switch with the

least-cost path to the root identified by the lowest Bridge ID; then the neighboring switch

with the lowest Bridge ID; and finally the port on the neighbor with the lowest Bridge ID

with the lowest Port ID.

To sum up the rules:

■ The root switch is the switch that has the lowest Bridge ID in the topology.

■ On each nonroot switch, a Root Port is the port receiving the best (that is, superior)

resulting BPDUs from all received BPDUs on all ports. The adjective “resulting”

refers to the addition of the port’s cost to the BPDU’s RPC value before comparing

the received BPDUs.

■ On each connected segment, a Designated Port is the port sending the best (that is,

superior) BPDUs on the segment. No modifications to the BPDUs are performed;

BPDUs are compared immediately.

■ All ports that are neither Root Ports nor Designated Ports are superfluous in an

active topology and will be put into the Blocking state.

■ Configuration BPDUs are sent out only from Designated Ports. Root and Non-

Designated ports do not emit Configuration BPDUs because they would be inferior

to BPDUs of a Designated Port on this segment and hence ignored.

Key

Topic

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 115

■ Each port stores the best (that is, superior) BPDU it has received or sent itself.

Designated Ports store the BPDU they send; Root and Blocking ports store the best

BPDU they receive. The stored BPDU determines the role of the port and is used for

comparisons.

■ Received superior stored BPDUs will expire in MaxAge-MessageAge seconds if not

received within this time period.

Converging to a New STP Topology

Although STP is very illustratively described in the three steps discussed earlier, this

approach also gives an impression that after the three steps are completed, STP effec-

tively goes dormant until a topology change occurs. Such impression would be incorrect,

though. In reality, STP never stops working. With each received BPDU, a switch reevalu-

ates its own choice of the root switch, Root Port, and Designated/Non-Designated Ports,

effectively performing all three steps all over again. In a stable topology, received BPDUs

do not change, and therefore, processing them yields the same results again and again.

This is similar to the operation of the RIP that also never stops running—it’s just that in

a stable network which has converged, processing periodic received updates produces

the same set of best paths, which gives off an impression that the protocol has done its

job and has stopped. In reality, both STP and RIP continue running indefinitely, only in a

stable and converged topology, each run produces the same results.

Of course, a topology in which STP runs can change over time, and STP has to react

appropriately. In precise terms, for STP, a topology change is an event that occurs when

■ A Topology Change Notification BPDU is received by a Designated Port of a switch

■ A port moves to the Forwarding state and the switch has at least one Designated

Port (meaning that it is not a standalone switch with just a Root Port connected to an

upstream switch and no other connected ports)

■ A port moves from Learning or Forwarding to Blocking

■ A switch becomes the root switch

When a change to the topology occurs, the elementary reaction of switches that detect

the topology change is to start originating BPDUs with appropriately updated contents,

propagating the information to their neighbors. These neighbors will process the updated

BPDUs, reevaluating their choice of the root switch, Root Port, and Designated/Non-

Designated Ports with each received BPDU as usual, and forwarding the BPDU farther

according to usual STP rules.

For an example, consider Figure 3-4 , which shows the same loop network as in Figure

3-3 . In this case, however, the link from SW1 to SW2 has just failed.

Key

Topic

ptg13046388

116 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Loop Design – All Port Costs 19 Unless Shown

Fa0/4

Cost 19

Disabled

Fa0/3

Fa0/2

Fa0/4

Disabled

Cost 1

SW1’s bridge ID is better.

So I’m sending the

superior Hello on this

segment. I am now DP!

Fa0/1

Cost 100

MAC 0200.1111.1111

Root My RP failed. I am

receiving no other Hellos.

I must be the root now!

Hello Root =

Sw2 Cost 0

Hello Root =

Sw2 Cost 19

Hello Root =

Sw1 Cost 0

Hello Root =

Sw1 Cost 100

SW1

SW3

SW2

SW4

Figure 3-4 Reacting to the Loss of Link Between SW1 and SW2

The following list describes some of the key steps from Figure 3-4 :

1. SW2’s Root Port goes down. On SW2, the loss of a Root Port causes it to reelect its

Root Port by choosing the port receiving superior resulting BPDUs. However, as the

only remaining port is Fa0/4 connected to SW4, and SW4 did not send any BPDUs

to SW2 from its Root Port Fa0/2, SW2 has no received BPDUs to choose from, and

it will start considering itself a root switch, flooding its own Hellos through all its

connected ports.

2. SW4 notices that the latest Hellos indicate a new root switch. However, these Hellos

from SW2 received on SW4’s Fa0/2 port, its current Root Port, are inferior to the

BPDU stored on that port. When the link between SW1 and SW2 still worked,

BPDUs arriving at SW4’s Fa0/4 contained the SW1’s Bridge ID as the RBID. After the

link between SW1 and SW2 went down and SW2 started considering itself as the

root bridge, its BPDUs arriving at SW4’s Fa0/2 port contained SW2’s Bridge ID as

the RBID. However, SW2 has a higher Bridge ID than SW1; otherwise, it would be

the root switch right away. Therefore, BPDUs claiming that SW2 is the root bridge

are inferior to the BPDU stored on SW4’s Fa0/2 that claims SW1 is the root bridge,

and as a result, they are ignored until the BPDU stored on SW4’s Fa0/2 expires. This

expiry will take MaxAge-MessageAge, or 20−1=19 seconds. Until then, SW4 does

not forward any BPDUs to SW3.

3. During the time SW4 receives inferior BPDUs from SW2 on its Fa0/2 port, it does

not forward any BPDUs to SW3. As a result, SW3 ceases to receive BPDUs on

its Fa0/4 port, which is its current Root Port. The BPDU stored on SW3’s Fa0/4

port expires in MaxAge-MessageAge, or 20–2=18 seconds. After it expires, Fa0/4

becomes a Designated Port and moves to the Listening state. SW3 then searches for

a new Root Port by looking for the superior received resulting BPDU, ultimately

choosing Fa0/1 as its new port. Afterward, it will forward SW1’s Hello out its Fa0/4

port after updating the necessary fields.

ptg13046388

Chapter 3: Spanning Tree Protocol 117

4. In the meantime, SW4 might have the BPDU expired from its Fa0/2, started accept-

ing BPDUs from SW2, declared the Fa0/2 as its Root Port toward SW2, and started

relaying the Hellos from SW2 to SW3. Even if that was the case, SW3 would treat

these Hellos from SW4 as inferior because Hellos sent out from SW3’s Fa0/4 claim

that the root switch is SW1 having a lower Bridge ID than SW2. After SW4 receives

the relayed Hello from SW3, it will learn about a better root switch than SW2,

namely, SW1, and will choose its Fa0/3 as the Root Port. Afterward, it will forward

the Hello out its Fa0/2 port.

5. After SW2 receives the forwarded Hello from SW4, it will also learn about SW1

being a better root switch than itself. Therefore, SW2 will stop considering itself as a

root switch and will instead declare its Fa0/4 port as the Root Port, finally converg-

ing on the new loop-free topology.

Topology Change Notification and Updating the CAM

Simply updating the active topology by processing new BPDUs is not sufficient. When

STP reconverges on a new active topology, some Content Addressable Memory (CAM)

entries might be invalid (CAM is the Cisco term for what is more generically called

the MAC address table, switching table, or bridging table on a switch). For example,

before the link failure shown in Figure 3-4 , SW3’s CAM might have had an entry for

0200.1111.1111 (Router1’s MAC address) pointing out Fa0/4 to SW4. Remember, at the

beginning of the scenario described in Figure 3-4 , SW3 was Blocking on its Fa0/1 inter-

face back to SW1. When the link between SW1 and SW2 failed, SW3 would need to

change its CAM entry for 0200.1111.111 to point out port Fa0/1.

STP is not a protocol that tries to find shortest paths toward individual MAC addresses,

so it cannot be expected to fill the CAM tables with new correct entries. All STP can do

is to instruct switches to age out unused entries prematurely, assuming that the unused

entries are exactly those that need updating. Even if good entries are flushed from CAM

tables, this does not impair basic connectivity—switches will flood frames to unknown

destinations rather than dropping them.

To update the CAMs, two things need to occur:

■ All switches need to be notified to time out their apparently unused CAM entries.

■ Each switch needs to use a short timer, equivalent to the Forward Delay timer

(default 15 seconds), to time out the CAM entries.

A topology change can start as a highly localized event—a port becoming Forwarding

or transitioning from Learning or Forwarding to Blocking on a particular single switch.

The information about this change must nevertheless be propagated to all switches in the

topology. Therefore, a switch that detects a topology change must notify the root switch,

and the root switch in turn can notify all switches in the topology. (Recall that it is the

root switch’s Hello that is propagated throughout the network to all switches; a nonroot

switch has no way of sending its own Configuration BPDU to all remaining switches in

a topology because that BPDU would be inferior, and thus ignored, by possibly many

switches.) To do so, a switch detecting a topology change notifies the root switch using

ptg13046388

118 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

a Topology Change Notification (TCN) BPDU. The TCN goes up the tree to the root.

After that, the root notifies all the rest of the switches. The process is illustrated in Figure

3-5 and runs as follows:

TCN

BPDU

TCA

Conf.

BPDU

TCN

BPDU

TCA

Conf.

BPDU

Figure 3-5 Propagating Information About Topology Change

1. A topology change event occurs on a port of a switch.

2. After detecting the event, the switch sends a TCN BPDU out its Root Port; it repeats

this message every Hello time until it is acknowledged.

3. The next designated switch receiving that TCN BPDU sends back an acknowledg-

ment through its next forwarded Hello BPDU by marking the Topology Change

Acknowledgment (TCA) bit in the Flags field of the Hello.

4. The designated switch on the segment in the second step repeats the first two steps,

sending a TCN BPDU out its Root Port, and awaits acknowledgment from the desig-

nated switch on that segment.

5. After the TCN arrives at the root switch, it also acknowledges its arrival through

sending a BPDU with the Topology Change Acknowledgment bit set through the

port through which the TCN BPDU came in. At this point, the root switch has been

informed about a topology change that occurred somewhere in the network.

6. For the next MaxAge+ForwardDelay seconds, the root switch will originate BPDUs

with the Topology Change (TC) bit set, instructing all switches to shorten the aging

time for CAM entries to ForwardDelay seconds.

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 119

By each successive switch repeating Steps 2 and 3, eventually the root receives a TCN

BPDU. After it is received, the root sets the Topology Change (TC) flag on the next sev-

eral Hellos (during the next MaxAge+ForwardDelay seconds), which are forwarded to all

switches in the network, notifying them that a change has occurred. A switch receiving

a Hello BPDU with the TC flag set uses the short (ForwardDelay time derived from the

value in the received BPDU, set by the root switch) timer to time out unused entries in

the CAM.

Transitioning from Blocking to Forwarding

When STP reconverges to a new, stable topology, some ports that were Blocking might

have been designated as DP or RP, so these ports need to be in a Forwarding state.

However, the transition from Blocking to Forwarding state cannot be made immediately

without the risk of causing loops.

To transition to Forwarding state but also prevent temporary loops, a switch first puts a

formerly Blocking port into Listening state, and then into Learning state, with each state

lasting for the length of time defined by the ForwardDelay timer (by default, 15 seconds).

Table 3-4 summarizes the key points about all the 802.1D STP port states.

Table 3-4 IEEE 802.1D Spanning Tree Interface States

State Forwards Data

Frames?

Learns Source MACs

of Received Frames?

Transitory or Stable

State?

Blocking No No Stable

Listening No No Transitory

Learning No Yes Transitory

Forwarding Yes Yes Stable

Disabled No No Stable

In summary, when STP logic senses a change in the topology, it converges, possibly pick-

ing different ports as RP, DP, or neither. Any switch changing its RPs or DPs sends a TCN

BPDU to the root at this point. For the ports newly designated as RP or DP, 802.1D STP

first uses the Listening and Learning states before reaching the Forwarding state. (The

transition from Forwarding to Blocking can be made immediately.)

Per-VLAN Spanning Tree and STP over Trunks

If only one instance of STP was used for a switched network with redundant links but

with multiple VLANs, several ports would be in a Blocking state, unused under stable

conditions. The redundant links would essentially be used for backup purposes.

Key

Topic

ptg13046388

120 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The Cisco Per VLAN Spanning Tree Plus (PVST+) feature creates an STP instance for

each VLAN. By tuning STP configuration per VLAN, each STP instance can use a dif-

ferent root switch and have different interfaces block. As a result, the traffic load can be

balanced across the available links. For example, in the common building design with

distribution and access links in Figure 3-6 , focus on the left side of the figure. In this

case, the access layer switches block on different ports on VLANs 1 and 2, with different

root switches. Support for PVST+ implies the capability of trunk ports to be selectively

blocked or forwarding for individual VLANs.

Root

VLAN1

ISL

.1Q .1Q

FWD

VLAN1

FWD

VLAN2

Root

VLAN2

FWD

VLAN2

FWD

VLAN1

.1Q .1Q

3560

2960

3560

2960

Figure 3-6 Operation of PVST+ for Better Load Balancing

With different root switches and with default port costs, the access layer switches end up

sending VLAN1 traffic over one uplink and VLAN2 traffic over another uplink.

Using 802.1Q VLANs with IEEE 802.1D STP requires some extra thought as to how it

works. Non-Cisco switches that follow exclusively the IEEE standard support only a so-

called Common Spanning Tree (CST) . Here, only one instance of STP runs in the net-

work (not even being tied to a specific VLAN because basic STP does not know anything

about VLANs), and that one STP topology is used for all VLANs, hence being called as

“common.” Although using only one STP instance reduces the STP messaging overhead,

it does not allow load balancing by using multiple STP instances, as was shown with

PVST+ in Figure 3-6 .

When building networks using a mix of Cisco and non-Cisco switches, along with 802.1Q

trunking, you can still take advantage of multiple STP instances in the Cisco portion

of the network, but we need to look closer at the rules that govern the interoperation

between the 802.1D STP and PVST+, and the cooperation of PVST+ regions intercon-

nected by CST regions.

Cisco PVST+ running on trunks uses a VLAN 1 STP instance to communicate with non-

Cisco switches and their STP. VLAN 1’s STP instance in PVST+ regions interoperates and

merges with the STP in CST regions. As a result, the entire switched network computes

a single loop-free topology. In CST regions, the active loop-free topology is binding for

all VLANs; inside PVST+ regions, the active loop-free topology applies to VLAN 1 only.

Other VLANs inside PVST+ regions have their own PVST+ instances.

PVST+ instances for VLANs other that VLAN 1 in PVST+ regions treat CST regions

simply as loop-free shared segments. This is done by encapsulating the PVST+ BPDUs on

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 121

trunks differently than ordinary BPDUs: Their destination MAC address is set to the mul-

ticast address 0100.0CCC.CCCD (ordinary STP BPDUs are destined to 0180.C200.0000),

they are tagged with the corresponding VLAN (ordinary STP BPDUs are untagged), and

by using SNAP encapsulation (ordinary STP BPDUs use LLC encapsulation without

SNAP). In addition, each PVST+ BPDU has a special TLV record placed at its end that

carries the VLAN number in which the PVST+ BPDU was originated. We will call this

TLV the Port VLAN ID TLV, or a PVID TLV. This TLV is analyzed by PVST+ switches

and compared to the VLAN in which the BPDU is received to detect native VLAN mis-

matches. As a result, PVST+ BPDUs are tunneled across CST regions, with CST switches

flooding them as ordinary multicasts without processing them. To non-VLAN 1 PVST+

instances, the entire switched network appears as PVST+ regions interconnected by

shared segments. By tunneling PVST+ BPDUs across CST regions, PVST+ STP instances

for VLANs 2–4094 in individual PVST+ regions cooperate together to form a single

spanning tree for each corresponding VLAN inside all PVST+ regions, with CST regions

merely serving the purpose of loop-free shared segments connecting the PVST+ regions

together.

VLAN 1 on PVST+ trunks is actually handled specially: Both standard STP BPDUs and

PVST+ BPDUs are sent for VLAN 1. However, only the STP BPDU is used both by CST

and PVST+ switches in VLAN 1 to compute the spanning tree. PVST+ BPDU for VLAN

1 is used to detect native VLAN mismatches and is otherwise ignored upon arrival.

To summarize the sending and processing of PVST+ and ordinary IEEE BPDUs on ports,

when sending BPDUs, access ports send only IEEE BPDUs relevant to their access

VLAN. Trunk ports always send a set of BPDUs:

■ IEEE-formatted BPDUs for VLAN1, always untagged.

■ PVST+ BPDUs (also called SSTP BPDUs in Cisco documents) for all existing and

allowed VLANs including VLAN1, tagged accordingly to the native VLAN of the

trunk; that is, BPDUs for the native VLAN won’t be tagged and all others will. Each

of these PVST+ BPDUs carries the PVID TLV.

When processing received BPDUs, an access port must receive only IEEE BPDUs; oth-

erwise a Type Inconsistent state is declared. These IEEE BPDUs will be processed by the

STP instance for the access VLAN of the port. On trunk ports, the processing is a little

more complex:

■ IEEE-formatted BPDUs will be immediately processed by the VLAN1 STP instance.

■ PVST+ BPDUs are processed according to this sequence of steps:

1. Assign the BPDU to the appropriate VLAN by looking at its 802.1Q tag. If the

tag is present, the BPDU is assigned to the VLAN indicated by the tag. If the tag

is not present, the BPDU is assigned to the native VLAN.

2. Check the PVID TLV in the BPDU. If the VLAN stored in the PVID TLV does

not match the VLAN to which the BPDU was assigned, drop the BPDU and

declare the PVID_Inconsistent state for the offending pair of VLANs. This is the

native VLAN mismatch check.

Key

Topic

ptg13046388

122 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

3. BPDUs whose PVID TLV VLAN matches the assigned VLAN will be processed

by STP in their appropriate VLANs except BPDUs for VLAN1. Because the

information for VLAN1 is duplicated in the IEEE BPDUs and PVST+ BPDUs

and the IEEE BPDUs always have to be processed, the PVST+ BPDU for VLAN1

served only the purpose of protection against native VLAN mismatch in

VLAN1, and can be dropped afterward.

Figure 3-7 shows a network in which three CST regions of non-Cisco switches connect to

two regions of Cisco PVST+ supporting switches.

ISL

Non-native VLAN STP

BPDUs trunked, sent to

0100.0CCC.CCCD

PVST+ Region

.1Q .1Q

.1Q

STP only in

VLAN 1

Common

Spanning Tree

CST Region 1

CST Region 2

.1Q

ISL

PVST+ Region

.1Q .1Q

Non-native VLAN STP

BPDUs trunked, sent to

0100.0CCC.CCCD

Non-Cisco

Non-Cisco Non-Cisco

Non-Cisco

Non-Cisco Non-Cisco

3560 3560

2960 2960

3560 3560

2960 2960

CST Region 3

Figure 3-7 Combining Standard IEEE 802.1Q and CST with PVST+

The topology in Figure 3-7 consists of three CST and two PVST+ regions. CST regions

use ordinary STP with no per-VLAN semantics. PVST+ regions run STP independently

in each VLAN, and on PVST+ boundaries, they use the VLAN 1 STP instance to interact

and interoperate with CST regions.

ptg13046388

Chapter 3: Spanning Tree Protocol 123

As CST and PVST+ VLAN 1 STP instances will interact and cooperate with each other,

the result of this interaction is a tree that spans through the entire network. In CST

regions, the loop-free topology will be shared by all VLANs; in PVST+ regions, the loop-

free topology will be applied to VLAN 1 only. Assuming that the topmost switch in CST

Region 2 is the root switch and all links have the same STP cost, the resulting loop-free

topology in CST regions and in VLAN 1 in PVST+ regions is shown in Figure 3-8 .

ISL

PVST+ Region

.1Q

CST Region 1

CST Region 2

CST Region 3

.1Q

ISL

PVST+ Region

.1Q

Non-Cisco

Non-Cisco Non-Cisco

Non-Cisco

Non-Cisco Non-Cisco

3560 3560

2960 2960

3560 3560

2960 2960

Figure 3-8 Resulting Spanning Tree in CST Regions and in VLAN 1 in PVST+ Regions

In simple terms, the result of CST and VLAN 1 STP interaction can be easily visualized

simply by considering all switches to run a single STP instance and computing the span-

ning tree, ignoring all VLANs for the moment, then taking into consideration that in CST

regions, this spanning tree will be shared by all VLANs, while in PVST+ regions, only

VLAN 1 will be affected. Also, any CST region that interconnects two or more PVST+

regions is internally loop free and either continuous (as in CST Region 2; this region pro-

vides a transit connectivity between PVST+ regions) or partitioned (as in CST Region 3;

this region does not provide transit connectivity to PVST+ regions).

ptg13046388

124 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

This observation about CST regions being internally loop free is important to understand

the operation of remaining non-VLAN 1 STP instances in PVST+ regions. After loops

have been eliminated from CST regions, the resulting network as seen by PVST+ STP

instances can be seen in Figure 3-9 .

ISL

Non-native VLAN STP

BPDUs trunked, sent to

0100.0CCC.CCCD

PVST+ Region

.1Q .1Q

ISL

PVST+ Region

.1Q .1Q

3560 3560

2960 2960

3560 3560

2960 2960

Figure 3-9 Network as Perceived by Non-VLAN 1 PVST+ STP Instances

As PVST+ BPDUs are effectively tunneled across CST regions, the CST regions simply

appear as shared segments to non-VLAN 1 PVST+ STP instances. These shared segments

are internally loop free and either interconnect PVST+ regions, in which case PVST+ will

take care of eliminating any remaining possible loops between PVST+ regions, or do not

even provide transit connectivity. PVST+ BPDUs will be flooded across the CST region

without being processed. When forwarded PVST+ BPDUs reach the first Cisco PVST+

switch in the other PVST+ region, the switch, listening for multicasts to 0100.0CCC.

CCCD, reads and interprets the BPDU.

Note Along with 802.1s Multiple Spanning Tree Protocol (MSTP), 802.1Q allows 802.1Q

trunks for supporting multiple STP instances. MST is covered later in this chapter.

STP Configuration and Analysis

Example 3-1 , based on Figure 3-10 , shows some of the basic STP configuration and show

commands. Take care to note that many of the upcoming commands allow the parameters

to be set for all VLANs by omitting the VLAN parameter, or set per VLAN by includ-

ing a VLAN parameter. Example 3-1 begins with SW1 coincidentally becoming the root

switch. After that, SW2 is configured to become root, and SW3 changes its Root Port as

a result of a configured port cost in VLAN 1.

ptg13046388

Chapter 3: Spanning Tree Protocol 125

Fa0/4 Fa0/3

Fa0/4

Fa0/2

Fa0/3

Fa0/2 Fa0/1

Fa0/1

Fa0/2

Fa0/4

Fa0/1

Fa0/3

Core Design

SW1

SW3

SW2

SW4

Figure 3-10 Network Used with Example 3-1

Example 3-1 STP Basic Configuration and show Commands

! First, note the Root ID column lists the root's bridge ID as two parts,

! first the priority, followed by the MAC address of the root. The root cost of

! 0 implies that SW1 (where the command is executed) is the root.

SW1# sh spanning-tree root

Root Hello Max Fwd

Vlan Root ID Cost Time Age Dly Root Port

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

VLAN0001 32769 000a.b7dc.b780 0 2 20 15

VLAN0011 32779 000a.b7dc.b780 0 2 20 15

VLAN0012 32780 000a.b7dc.b780 0 2 20 15

VLAN0021 32789 000a.b7dc.b780 0 2 20 15

VLAN0022 32790 000a.b7dc.b780 0 2 20 15

! The next command confirms that SW1 believes that it is the root of VLAN 1.

SW1# sh spanning-tree vlan 1 root detail

Root ID Priority 32769

Address 000a.b7dc.b780

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

! Next, SW2 is configured with a lower (better) priority than SW1,

! so it becomes the root. Note that because SW2 is defaulting to use

! the System ID Extension, the actual priority must be configured as a

! multiple of 4096.

Key

Topic

ptg13046388

126 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

SW2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW2(config)# spanning-tree vlan 1 priority ?

<0-61440> bridge priority in increments of 4096

SW2(config)# spanning-tree vlan 1 priority 28672

SW2(config)# ^Z

SW2# sh spanning-tree vlan 1 root detail

VLAN0001

Root ID Priority 28673

Address 0011.92b0.f500

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

! The System ID Extension field of the bridge ID is implied next. The output

! does not separate the 4-bit Priority field from the System ID field. The output

! actually shows the first 2 bytes of the bridge ID, in decimal. For VLAN1,

! the priority is 28,673, which is the configured 28,672 plus the VLAN ID,

! because the VLAN ID value is used in the System ID field in order to implement

! the MAC address reduction feature. The other VLANs have a base priority

! of 32768, plus the VLAN ID - for example, VLAN11 has priority 32779,

! (priority 32,768 plus VLAN 11), VLAN12 has 32780, and so on.

SW2# sh spanning-tree root priority

VLAN0001 28673

VLAN0011 32779

VLAN0012 32780

VLAN0021 32789

VLAN0022 32790

! Below, SW3 shows a Root Port of Fa0/2, with cost 19. SW3 gets Hellos

! directly from the root (SW2) with cost 0, and adds its default cost (19).

! This next command also details the breakdown of the priority and system ID.

SW3# sh spanning-tree vlan 1

VLAN0001

Spanning tree enabled protocol ieee

Root ID Priority 28673

Address 0011.92b0.f500

Cost 19

Port 2 (FastEthernet0/2)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

ptg13046388

Chapter 3: Spanning Tree Protocol 127

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

Address 000e.837b.3100

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

Interface Role Sts Cost Prio.Nbr Type

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

Fa0/1 Altn BLK 19 128.1 P2p

Fa0/2 Root FWD 19 128.2 P2p

Fa0/4 Desg FWD 19 128.4 P2p

Fa0/13 Desg FWD 100 128.13 Shr

! Above, the port state of BLK and FWD for each port is shown, as well as the

! Root Port and the Designated Ports.

! Below, Switch3's VLAN 1 port cost is changed on its Root Port (Fa0/2),

! causing SW3 to reconverge, and pick a new RP.

SW3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW3(config)# int fa 0/2

SW3(config-if)# spanning-tree vlan 1 cost 100

SW3(config-if)# ^Z

! The next command was done immediately after changing the port cost on

! SW3. Note the state listed as "LIS," meaning Listening. STP has already

! chosen Fa0/1 as the new RP, but it must now transition through Listening

! and Learning states.

SW3# sh spanning-tree vlan 1

VLAN0001

Spanning tree enabled protocol ieee

Root ID Priority 28673

Address 0011.92b0.f500

Cost 38

Port 1 (FastEthernet0/1)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

Address 000e.837b.3100

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 15

ptg13046388

128 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Interface Role Sts Cost Prio.Nbr Type

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

Fa0/1 Root LIS 19 128.1 P2p

Fa0/2 Altn BLK 100 128.2 P2p

Fa0/4 Desg FWD 19 128.4 P2p

Fa0/13 Desg FWD 100 128.13 Shr

The preceding example shows one way to configure the priority to a lower value to

become the root. Optionally, the spanning-tree vlan vlan-id root { primary | secondary }

[ diameter diameter ] command could be used. This command causes the switch to set the

priority lower. The optional diameter parameter causes this command to lower the Hello,

ForwardDelay, and MaxAge timers. (This command does not get placed into the configu-

ration, but rather it acts as a macro, being expanded into the commands to set priority

and the timers.)

Note When using the primary option, the spanning-tree vlan command sets the prior-

ity to 24,576 if the current root has a priority larger than 24,576 or its priority is 24,576

and its MAC address is higher than the current switch’s MAC (that is, if setting the priority

of 24,576 allows the current switch to become the root). Otherwise, this command sets

this switch’s priority to 4096 less than the current root. With the secondary keyword,

this switch’s priority is always set to 28,672. Also note that this logic applies to when the

configuration command is executed; it does not dynamically change the priority if another

switch later advertises a better priority.

Rapid Spanning Tree Protocol

IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) enhances the 802.1D standard with

one goal in mind: improving STP convergence. Updates to the entire protocol operation

are multifold and result in a dramatic increase of its convergence speed—well below 1

second in properly designed networks.

New Port Roles, States and Types, and New Link Types

RSTP has significantly reworked the classification of port and link properties to stream-

line and optimize its operation. Properties of ports include port states , port roles , and

port types . In addition, links interconnecting RSTP switches also have their types .

The number of port states has been reduced from five to three: While 802.1D STP

defines Disabled, Blocking, Listening, Learning, and Forwarding states, 802.1w RSTP

defines only Discarding, Learning, and Forwarding states. Discarding and Forwarding

states are stable states; Learning is a transitory state. This cleanup relates to the fact that a

port can either be in stable state, that is, Forwarding or Discarding, for an unlimited time

in the absence of any topological changes, or can be in a transitory Learning state, going

ptg13046388

Chapter 3: Spanning Tree Protocol 129

from Discarding to Forwarding over a limited time period. Table 3-5 compares the port

states defined by each protocol.

Table 3-5 RSTP and STP Port States

Administrative State STP State (802.1D) RSTP State (802.1w)

Disabled Disabled Discarding

Enabled Blocking Discarding

Enabled Listening Discarding

Enabled Learning Learning

Enabled Forwarding Forwarding

In RSTP, a Discarding state means that the port does not forward data frames, receive

data frames, or learn source MAC addresses, regardless of whether the port was shut

down, failed, or simply does not have a reason to forward frames. Note that even a

Discarding port, similarly to the Blocking state in legacy STP, continues to process

received BPDUs; send BPDUs (depending on its role); and send and receive frames of

inter-switch signaling protocols such as DTP, VTP, CDP, LLDP, PAgP, LACP, or LOOP. The

Discarding is also the default state of a port that has newly come alive (with the excep-

tion of an Edge port whose default state is Forwarding).

RSTP decouples the state of the port from its purpose, or a role , in a topology, and

defines four separate port roles:

■ Root Port (maintains its usual meaning)

■ Designated Port (maintains its usual meaning)

■ Alternate Port (a prospective replacement for the switch’s own Root Port)

■ Backup Port (a prospective replacement for the switch’s own Designated Port into a

shared segment)

This decoupling allows for better definition of what function a port fulfills in a topology

without inferring its role purely from its state. Also, this split underlines the fact that dur-

ing transitory periods, Root and Designated Ports can be put into Discarding or Learning

states, or—as is in the case of the Proposal/Agreement process—these can be skipped.

Table 3-6 lists individual RSTP port roles, how they are determined, and their purpose.

Key

Topic

Key

Topic

ptg13046388

130 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 3-6 RSTP Port Roles

RSTP Role Definition

Root Port Same as 802.1D Root Port.

Designated Port Same as 802.1D Designated Port.

Alternate Port A replacement Root Port. Alternate Ports are ports receiving BPDUs

from other switches but not meeting requirements to become Root or

Designated. Such a port is attached to a neighboring switch and provides

a possible alternate path toward the root. Upon the loss of the current

Root Port, the Alternate Port receiving the best resulting BPDUs will be

rapidly promoted to the role of Root Port and moved to the Forwarding

state.

Backup Port A replacement Designated Port. Backup Ports are ports receiving

BPDUs from the same switch but not meeting requirements to become

Designated. Such a port is attached to the same link as another port on

the same switch, but the other port is Designated for that segment. The

Backup Port is ready to take over if the DP fails; however, this takeover is

not rapid. Rather, it is driven by timers.

The Alternate Port concept offers protection against the loss of a switch’s Root Port,

also called a direct link failure , by keeping track of the Alternate Ports with a path to

the root. If the current Root Port fails, RSTP will simply compare the resulting BPDUs

(BPDUs stored on ports after incrementing the Root Path Cost by the receiving port’s

cost) on Alternate Ports and choose the port with the superior resulting BPDU as the new

Root Port. This port will be immediately declared Root Forwarding. Figure 3-11 illus-

trates this process.

Root Sec. Root

Root

Port

Alternate

Port

Figure 3-11 Use of Alternate Port to Replace Lost Root Port (Direct Link Failure)

The Backup Port role provides protection against losing the Designated Port attached

to a shared link when the switch has another physical port attached to the same shared

LAN. As this is a shared link, there is no rapid convergence. After the Designated Port

fails, all Backup Ports for the same link become Designated Discarding after missing

three BPDUs in a row from the former Designated Port (expiry of Rapid Spanning Tree

[RST] BPDUs will be described in the next section). Out of them, only a single port will

remain Designated Discarding; the others will again revert to Backup Discarding after

receiving the BPDU from the newly elected Designated Port. This new Designated Port

ptg13046388

Chapter 3: Spanning Tree Protocol 131

will gradually move from Discarding through Learning to Forwarding. As Proposals are

not sent on ports connected to shared links, there is no way of safely moving a Backup

Port to Designated rapidly.

The default role for a port that has newly come alive is Designated.

Finally, in RSTP, ports have types : A port can be either an Edge or a Non-Edge port.

This property is already well known thanks to the Cisco PortFast feature. An Edge Port

immediately becomes Designated Forwarding after coming up. It still sends BPDUs but

it expects not to receive any. Should a BPDU be received by an Edge port, this port will

revert to the Non-Edge type and start operating as a common RSTP port. No commands

will be removed from the configuration; only the runtime operational type of the port

will change. The port will again become an Edge port after it goes down and comes up

again, either through disconnect/reconnect or through shutting it down and reactivating.

There is no reliable way of automatically detecting whether a port is an Edge or a Non-

Edge port. The default port type on Cisco Catalyst switches is Non-Edge.

Regarding links, RSTP recognizes two link types :

■ Point-to-point link: A link that connects an RSTP switch to at most one neighboring

RSTP switch.

■ Shared link: A link that connects an RSTP switch to two or more neighboring

switches.

In most modern LAN designs with no hubs or non-STP switches that create a shared

communication environment from RSTP’s viewpoint, all links would be of the point-to-

point type. Most of RSTP’s improvements in its reaction speed are usable only on point-

to-point links. On shared links, RSTP reverts to slow operation driven by timers similar

to STP. There is no reliable way of detecting whether a link is point-to-point or shared.

However, Catalyst switches try to be somewhat smart in this aspect: If a port negotiates

half-duplex operation with its connected neighbor, the switch assumes that the neighbor

is a hub (as hubs are incapable of supporting full-duplex), and it will consider the link

type to be shared. If a port negotiates full-duplex operation, the switch will assume that

the neighbor is a switch running RSTP, and will treat the link as point-to-point. Obviously,

this decision process is just a guess and there are easily presentable situations where this

logic fails (for example, running half-duplex on a point-to-point link between two switch-

es because of some technical difficulties or peculiarities of the link, or having three or

more RSTP switches interconnected by an unmanaged switch together that do not run

STP). There is no one-to-one correspondence between the duplex mode and the link type.

In cases this heuristic fails, the link type can be configured on a per-port basis using the

spanning-tree link-type { point-to-point | shared } command.

Note The default port role and port state are Designated Discarding—this is the combi-

nation of roles and states applied to a port at the moment it becomes live. The default port

type is Non-Edge. The default link type depends on the duplex mode of the port—for

full-duplex, it is point-to-point; for half-duplex, it is shared.

Key

Topic

ptg13046388

132 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Changes to BPDU Format and Handling

In RSTP, there is only a single type of BPDU used both for building a loop-free topology

and for topology change notification purposes. TCN BPDUs are not used by RSTP. For

RSTP, the Protocol Version field is set to 2 (legacy STP uses Version 0; Version 1 was an

STP variant for Remote MAC Bridging according to the 802.1G standard but was never

widely deployed).

The Flags field has been updated. In 802.1D STP BPDUs, only 2 bits out of 8 are used:

TC (Topology Change) and TCA (Topology Change Acknowledgment). RSTP uses the

6 remaining bits as well to encode additional information: Proposal bit, Port Role bits,

Learning bit, Forwarding bit, and Agreement bit. The TCA bit is not used by RSTP. This

change allows implementing the Proposal/Agreement mechanism and also allows a BPDU

to carry information about the originating port’s role and state, forming the basis of

RSTP’s Dispute mechanism, protecting against issues caused by unidirectional links.

In STP, Configuration BPDUs are originated by the root switch only. A nonroot switch

does not originate its own Configuration BPDUs; rather, it waits for a BPDU to arrive on

its Root Port to relay it farther out its own Designated Ports after updating its contents.

This delays an appropriate reaction to a sudden loss of received BPDUs on a port—their

lack only indicates a problem somewhere between the root switch and the current switch.

The switch needs to wait for MaxAge-MessageAge seconds for the BPDU stored on the

Root Port to expire. In RSTP, each switch originates BPDUs on its own, with their con-

tents nevertheless based on the information from the BPDU stored on the switch’s Root

Port. RSTP BPDUs therefore become more similar to a Hello mechanism known from

routing protocols. If a switch ceases to receive RSTP BPDUs on its port, it is certain that

the problem is contained on the link between this switch and its neighbor. This allows

RSTP switches to age out BPDUs much sooner—in a 3x Hello interval. Three missing

Hellos in a row cause a port to age out the stored BPDU. The MessageAge field value no

longer has an influence on BPDU’s expiry. Instead, it serves the role of a hop count. Any

BPDU whose MessageAge is equal to or higher than its MaxAge will be discarded upon

arrival.

RSTP improves handling of inferior BPDUs sent by the designated switch on a segment.

In STP, if a designated switch (that is, a switch having a Designated Port on a segment)

suddenly started sending BPDUs that are inferior to the BPDUs sent earlier, remain-

ing switches on the segment would ignore them until the superior BPDU expired from

their ports, which is after MessageAge-MaxAge seconds (values taken from the superior

BPDU). In RSTP, an inferior BPDU originated by a designated switch on a segment is

accepted right away, immediately replacing previously stored BPDUs on receiving ports

of attached switches. In other words, if a designated switch on a segment suddenly sends

an inferior BPDU, other switches on the segment will immediately accept it as if the

superior stored BPDU expired just when the inferior BPDU arrived, and reevaluate their

own port roles and states on the segment according to usual rules. This behavior allows a

switch to rapidly react to a situation where the neighboring switch experiences a disrup-

tive change in its own connectivity toward the root switch (this is called an indirect link

failure ). Consider the situation in Figure 3-12 .

Key

Topic

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 133

Root Sec. Root

Root

Port

Alternate

Port

Root

Port

Designated

Port

My RP failed. I am

receiving no other Hellos.

I must be the root now!

Link fails.

I am suddenly receiving worse Hellos

from my designated switch. Accepting

them right away. They are inferior to

even my own Hellos on this port.

I am now designated on this segment!

I am receiving Hellos with

superior root BID.

I am no longer root, and

this is my root port.

AccessSw

Figure 3-12 Accepting Inferior BPDUs from Designated Switch (Indirect Link Failure)

To better understand the need for this improvement, it is important to realize that if

an inferior BPDU arrives from the designated switch, the designated switch or its own

upstream switches must have encountered a change for the worse to their connectivity

toward the root switch—the root path cost might have increased, or the Root Bridge

ID itself might have changed to a higher value. If the root path cost has increased, the

neighboring switch might no longer be using the shortest available path toward the root

switch, and possibly, the next shortest path to the root switch might be through the cur-

rent switch. If the Root Bridge ID has increased, the neighboring switch believes that the

root switch has changed, but the true root switch might be different. In both cases, this

inferior information has to be processed immediately to find out whether the neighboring

switch has to be updated about the root switch’s identity or about a better path toward

it. This is accomplished by accepting and processing the inferior BPDU, and running the

usual sequence of steps: reevaluating the role of the switch (whether it should become

the root switch itself), reevaluating the choice of a Root Port, and reevaluating roles of

remaining ports. If the port toward the neighbor becomes Designated (before the change,

it could only have been Root or Alternate), it will start sending BPDUs, thereby updating

the neighbor about the root switch and the available root path cost.

Proposal/Agreement Process in RSTP

Improvements described so far allow a switch or its neighbors to rapidly recover from

a lost connectivity to the root switch. However, a connectivity disruption can also be

caused by adding a new link into the topology that causes one of the switches to reelect

its Root Port and place it on the added link (that is, the added link provides a better path

to the root switch). RSTP uses the Proposal/Agreement process on a point-to-point link

to rapidly put such a link into operation without causing a temporary switching loop or

significant interruptions in the communication.

ptg13046388

134 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

If a newly added point-to-point link causes one of the attached switches to place its Root

Port on this new link, the roles of remaining ports on this switch can move from Root

or Alternate to Designated (the root path cost of this switch can decrease below the

costs of its neighbors). As the neighboring switches might not yet be informed about the

changes on this switch, they might still have some of their ports toward this switch in the

Designated role, too. This would cause a switching loop. Therefore, a loop has to be pre-

vented locally on the switch that is performing its Root Port changeover. In addition, after

the neighboring switches are informed about the potentially decreased root path cost of

this switch, they might also decide to change their Root Ports to point toward this switch,

causing them to face the very same task as the current switch. An addition of a new link

to the topology can therefore have a cascading effect of several switches updating their

Root Ports, and this needs to be handled rapidly and in a loop-free manner.

Preventing a switch from creating a switching loop by rapidly changing and activating

its Root Port can be done by having this switch put all its Non-Edge Designated ports

into Discarding state before the new Root Port is put into Forwarding state. Note that

the Non-Edge Designated ports include those ports that have moved from old Root and

Alternate roles to Designated after a superior resulting BPDU was received on the new

Root Port and the switch reevaluated the roles of all ports.

This procedure alone would allow a switch to rapidly change its Root Port while main-

taining a loop-free topology, but at the same time, it would cause a major disruption in

the communication because the switch is effectively isolated from the network: While

its new Root Port might be made Forwarding, the upstream neighbor’s Designated Port

on the added link is still in the Discarding or Learning state. In addition, all Non-Edge

Designated ports on this switch have been put into the Discarding state as well to prevent

a possible loop. To avoid waiting twice for the ForwardDelay timer, an explicit signaling

scheme between the switches needs to be used, allowing them to confirm that it is safe to

put a Designated Port into the Forwarding state.

This signaling scheme is called Proposal/Agreement . The Proposal signifies the will-

ingness of a port to become Designated Forwarding, while the Agreement stands for

permission to do so immediately. After a new link point-to-point link is added between

two switches, ports on both ends will come up as Designated Discarding, the default role

and state for a Non-Edge port. Any Designated Port in a Discarding or Learning state

sends BPDUs with the Proposal bit set. Both switches will therefore attempt to exchange

BPDUs with the Proposal bit set (or simply a Proposal), assuming that they have the

right to be Designated. However, if one of the ports receiving a Proposal discovers that

the Proposal constitutes the best received resulting BPDU, its role will change from

Designated to Root (the state will remain Discarding yet). Other port roles on that switch

will also be updated accordingly. Furthermore, a switch receiving a Proposal on its Root

Port will immediately put all its Non-Edge Designated ports into a Discarding state. This

operation is called Sync . A switch in Sync state is now isolated from the network, pre-

venting any switching loop from passing through it: Its Root Port is still in the Discarding

state (and even if it was Forwarding, the neighboring Designated Port is still Discarding

or Learning), and its own Designated Ports are intentionally moved to the Discarding

state. Now it is safe to move the new Root Port to the Forwarding state and inform the

upstream switch that it is now allowed to move its Designated Discarding or Learning

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 135

port to the Forwarding state. This is accomplished by a switch sending a BPDU with the

Agreement bit set (or simply an Agreement) through its Root Port after performing the

Sync. Upon receiving an Agreement on its Designated Discarding or Learning port, the

upstream switch will immediately move that port into the Forwarding state, completing

the Proposal/Agreement exchange between two switches.

As a result of the Proposal/Agreement and Sync operation, all Non-Edge Designated

ports on the switch with the new Root Port have been moved to the Discarding state.

Because all Designated Discarding and Designated Learning ports send Proposals,

the Proposal/Agreement exchange has effectively moved from “above” the switch to

“beneath” it (with respect to the root switch being at the “top” of the spanning tree),

constituting the cascading effect of switches pairwise reevaluating their choice of Root

Ports, expressing their willingness to have their Designated Ports made Forwarding rap-

idly (Proposals), and eventually receiving approvals to do so (Agreements). This process is

illustrated in Figure 3-13 , showing a wave-like sending of Proposals, performing Sync and

generating Agreements in turn while pushing the Proposal/Agreement exchange down-

stream.

55 5 5

6666

Proposal

Agreement

Proposal

Agreement

Proposal

Agreement

Proposal

Sync Sync Sync Sync

Sync

Figure 3-13 Proposal/Agreement Mechanism in RSTP

Note Outages in a switched network can be caused by direct link failures (a switch los-

ing its Root Port), indirect link failures (a neighbor losing its Root Port), adding a new root

link, or a root switch changeover. RSTP has reaction mechanisms for each of these events:

Direct link failures are handled by the best Alternate Port becoming a new Root Port, indi-

rect link failures are handled by the concept of accepting inferior BPDUs from designated

switches, adding a new root link is handled by the Proposal/Agreement mechanism, and

the changeover of a root switch is handled by the combination of the mechanisms above.

ptg13046388

136 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Note During the Proposal/Agreement exchange, all Non-Edge Designated ports will be

moved to Discarding state (the Sync operation). If ports toward end hosts are not explic-

itly configured as Edge ports using the spanning-tree portfast port level command or the

spanning-tree portfast default global level command (both have an effect on access ports

only), they will become Discarding during Sync. Because end hosts are incapable of send-

ing RSTP Agreements, these ports will require twice the ForwardDelay interval to become

Forwarding again, and the end hosts will experience major connectivity outages. In RSTP,

it is of crucial importance to configure ports toward end hosts as Edge ports; otherwise

the performance of the network might be perceived as being even worse than with 802.1D

STP.

Topology Change Handling in RSTP

As opposed to STP, which recognizes four distinct events as topology change events,

RSTP simplifies this concept: Only a transition of a Non-Edge port from a non-Forward-

ing state to the Forwarding state is considered a topology change event in RSTP. The rea-

son is that a port that has newly become Forwarding can provide a better path to a set of

MAC addresses than was previously available, and the CAM tables need to be updated.

The loss of a Forwarding port is not a cause for topology change event anymore, as the

set of MAC addresses previously learned on that port is definitely inaccessible unless

some other port in the topology becomes Forwarding (which is handled as a topology

change anyway) and possibly provides an alternate path toward them.

The way of propagating topology change information has also changed. Instead of for-

warding the information about a topology change using TCN BPDUs in a hop-by-hop

fashion to the root switch and causing the root switch to send BPDUs with the TC flag

set, RSTP switches immediately flood BPDUs with TC flag set. More precisely, a switch

that detects a topology change on a port (that is, one of its own Non-Edge ports transi-

tions into the Forwarding state) or learns about a topology change on a port (a BPDU

with the TC flag set is received on its Root or Designated Port) will do the following:

■ Set a so-called tcWhile timer to the value of the Hello time plus one second (older

revisions of RSTP set this value to twice the Hello time) on all remaining Non-Edge

Designated ports and Root Port if any, except the port on which the topology

change was detected or learned.

■ Immediately flush all MAC addresses learned on these ports.

■ Send BPDUs with the TC flag set on these ports every Hello seconds until the

tcWhile timer expires.

This way, information about a topology change is rapidly flooded along the spanning

tree in the form of BPDUs with the TC flag set, and causes switches to immediately flush

their CAM tables for all ports except those ports on which the topology change was

detected or learned, as they point in the direction of the topology change where a set of

MAC addresses might have become reachable through a new or improved path.

Key

Topic

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 137

Edge ports never cause a topology change event, and MAC addresses learned on them

are not flushed during topology change event handling.

Rapid Per-VLAN Spanning Tree Plus (RPVST+)

RPVST+ is a form of running RSTP on a per-VLAN basis, analogous to PVST+. This

provides the subsecond convergence of RSTP with the advantages of PVST+ described

in the previous section. Thus, RPVST+ and RSTP share the same characteristics such as

convergence time, Hello behavior, the election process, port states, and so on. RPVST+

is backwardly compatible with PVST+. Also the rules of interoperation of RPVST+ with

CST regions running RSTP are the same.

Configuring RPVST+ is straightforward. In global configuration mode, issue the

spanning-tree mode rapid-pvst command. Also, it is very important to configure ports

toward end hosts as Edge ports—either on a per-port basis using the spanning-

tree portfast command or globally using the spanning-tree portfast default com-

mand. Both these commands have an effect only on ports operating in access mode.

Additionally, as explained earlier, most RSTP improvements are applicable only on point-

to-point links. If the physical connections between switches are of the point-to-point

nature but operate in half-duplex (abnormal for a correct point-to-point interconnection!),

Cisco switches will treat these links as shared, as also evidenced by the acronym Shr in

the show spanning-tree output. In these rare cases, if the link is truly point-to-point, the

link type can be overridden using the spanning-tree link-type point-to-point interface

level command. Apart from these specific configurations, all other configuration com-

mands are of the same meaning as in PVST+. See the “Further Reading” section, later in

this chapter, for a source of more information on RPVST+.

Note For RSTP and consequently RPVST+ to provide rapid reaction to changes in the net-

work topology, all switches must run RSTP or RPVST+, all inter-switch links must be proper-

ly installed and recognized as point-to-point links, and all ports toward end stations must be

properly identified as edge ports. Failure to meet these three requirements will degrade the

RSTP and RPVST+ performance, voiding its advantages. Ports toward legacy switches will

revert to legacy 802.1D STP or PVST+ operation. On shared links, RSTP and RPVST+ revert

to timers. On non-edge ports, RSTP and RPVST+ rely on the Proposal/Agreement procedure

to provide rapid reaction, and if the neighboring device does not speak RSTP or RPVST+, it

will not be able to send an Agreement in response to a Proposal.

Multiple Spanning Trees: IEEE 802.1s

IEEE 802.1s Multiple Spanning Trees (MST) , sometimes referred to as Multiple STP

(MSTP) , defines a standards-based way to use multiple instances of STP in a network

that uses 802.1Q VLANs. The following are some of the main benefits of 802.1s:

■ Like PVST+, it allows the tuning of STP parameters on a per-instance basis so that

while some port blocks for one set of VLANs, the same port can forward in another

set of VLANs.

Key

Topic

ptg13046388

138 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ As opposed to PVST+, it does not run a separate STP instance for each and every

VLAN because that is largely unnecessary: Usually only a handful of different span-

ning trees is required and configured in a network. Running a separate STP instance

for each VLAN in PVST+ merely results in multiple instances creating exactly the

same spanning tree while consuming multifold system resources. Instead, MST

runs in instances whose existence is not directly related to any particular VLAN.

Instances are created by configuration, and VLANs are subsequently mapped onto

them. Spanning tree created by an MST instance is shared by all VLANs mapped

onto that instance.

■ Use 802.1w RSTP for rapid convergence in each instance, inheriting all its rapid

convergence properties. The following advantages have been retained: general RSTP

rules about BPDU expiry in a 3x Hello interval, acceptances of inferior BPDUs from

designated switches, port roles/states/types, link types, Proposal/Agreement, and

so on.

■ At press time, various Catalyst platforms have a limit on the maximum number of

concurrent STP instances. The 2960, 3560, and 3750 platforms, for example, sup-

port at most 128 STP instances. If more than 128 VLANs are created and active on

ports, some VLANs will not have any STP instance running and will not be protected

against switching loops. If decreasing the number of active VLANs is not an option,

neither PVST+ nor RPVST+ can be used, and MST is the only choice.

■ MST is the only standards-based and interoperable version of STP supporting

VLANs and suitable in multivendor switched environments.

MST Principles of Operation

MST organizes the network into one or more regions. An MST region is a group of

switches that together use MST in a consistent way—they run the same number of MST

instances and map the same sets of VLANs onto these instances, among other things.

For example, in Figure 3-14 , an MST region has been defined, along with connections to

non-MST switches. Focusing on the left side of the figure, inside the MST region, you

really need only two instances of STP—one each for roughly half of the VLANs. With

two instances, the access layer switches will forward on their links to SW1 for one set of

VLANs using one MST instance, and forward on their links to SW2 for the other set of

VLANs using the second MST instance.

One of the key benefits of MST over PVST+ is that it requires only one MST instance for

a group of VLANs. If this MST region had hundreds of VLANs, and used PVST+, hun-

dreds of sets of STP messages would be used. With MST, only one set of STP messages

is needed for each MST instance.

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 139

MST reuses the concept of System ID Extension from IEEE 802.1t to embed the instance

number into the Bridge ID. As the System ID Extension field contains 12 bits, the range

of MST instance numbers is in the range of 0–4095, though at the time of this writ-

ing, different Catalyst platforms supported different ranges: 0–15 on Catalyst 2950, and

0–4094 on Catalyst 2960 and 3560. Furthermore, the MST standard allows for at most

65 active MST instances (instance 0 plus at most 64 user-definable instances). Apart

from being higher than any reasonable network would require, this limit is also moti-

vated by the fact that MST uses a single BPDU to carry information about all instances,

and it must fit into a single Ethernet frame. While a typical Ethernet MTU of 1500B

would allow for approximately 88 MST instances in total, the limit of 64 user-definable

in stances is sufficient for any practical needs and fits well into an ordinary Ethernet

frame. In MST, a port sends BPDUs if it is Designated for at least one MST instance. As

MST uses a single BPDU for all instances, it is possible to see both switches on a point-

to-point link to send BPDUs to each other if each of these switches is Designated in a

different MST instance.

Out of all MST instances, the instance 0 has a special meaning. This instance is also

called the Internal Spanning Tree , or IST, and serves several purposes. First, this instance

always exists even if no other MST instances are created, providing a loop-free environ-

ment to VLANs mapped onto it within a region. Without any additional configuration,

all VLANs are mapped onto the IST. Second, the IST is the only instance that interacts

with STP run on switches outside the MST region. Whatever port role and state are deter-

mined by the interaction of IST on a region boundary with a neighboring switch, this

role and state will be inherited by all existing VLANs on that port, not just by VLANs

Root

Instance1

ISL

.1Q

.1Q .1Q

.1Q

FWD

Instance1

FWD

Instance2

Root

Instance2

FWD

Instance2

FWD

Instance1

Non-MST Region

MST appears as a

single switch to the

outside world

CST

Topology

Non-MST Region

MST Region

Non-Cisco Non-Cisco

3560

Non-Cisco Non-Cisco

3560 3560

2960 2960

Figure 3-14 MST Operations

Key

Topic

Key

Topic

ptg13046388

140 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

mapped onto the IST. This is a part of overall MST operations that makes the region

appear as a single switch to other regions and non-MST switches.

If the network consists of several MST regions, each of them can be visualized as a single

switch. The view of the entire topology consisting of several MST regions can thus be

simplified—instead of a region, imagine a single switch in its place while keeping the

links interconnecting different regions in place. Obviously, the resulting network after this

simplification can still contain loops if the regions are interconnected by redundant links.

MST blocks these loops by building a so-called Common Spanning Tree (CST) . This

CST is simply a result of the interaction of individual ISTs on region boundaries, and con-

stitutes a spanning tree between individual regions, consisting purely of links between

MST regions. Also, if there was a non-MST (either STP or RSTP) part of the network, it

would become an integral part of the CST. This CST has no per-VLAN semantics—it is a

spanning tree interconnecting MST region boundaries and optionally spanning non-MST

regions, shared by all VLANs. CST has two main purposes:

■ It determines loop-free paths between regions. An important consequence is that

loops between regions are blocked on inter-region links and not inside regions,

just like loops between switches would be blocked on the inter-switch links, not

somewhere “inside” those switches. This behavior is consistent with the simplifying

notion that from outside, an MST region can be perceived as just a single switch.

■ CST is the only spanning tree that can be understood and participated in by non-

MST (that is, STP and RSTP) switches, facilitating the interoperation between MST

and its predecessors. In mixed environments with MST and STP/RSTP, STP/RSTP

switches unknowingly participate in CST. Costs in CST reflect only the costs of links

between regions and in non-MST parts of the network. These costs are called exter-

nal costs by MST.

In each MST region, the CST on the region’s boundary merges with the IST inside the

region. The resulting tree consists of a loop-free interconnection between MST regions

“glued together” with loop-free interconnection inside each MST region, and is called the

Common and Internal Spanning Tree , or CIST. This tree is the union of CST between

regions and ISTs inside individual regions, and is a single spanning tree that spans the

entire switched topology. As each MST region has its own IST root, CIST—consisting

of ISTs inside regions and CST between regions—can have multiple root switches as a

result. These switches are recognized as the CIST Root Switch (exactly one for the entire

CIST) and CIST Regional Root Switches (exactly one for the IST inside each region). CIST

Regional Root Switch is simply a different name for an IST root switch inside a particular

region.

The CIST Root Switch is elected by the lowest Bridge ID from all switches that par-

ticipate in CIST, that is, from all MST switches across all regions according to their IST

Bridge IDs (composed of IST priority, instance number 0, and their base MAC address),

and from all STP/RSTP switches, if present, according to the only Bridge IDs they have.

If running a pure MST-based network, the CIST Root Switch will be the switch whose

IST priority is the lowest (numerically), and in the case of a tie, the switch with the low-

est base MAC address. This switch will also become the root of IST inside its own MST

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 141

region; that is, it will also be the CIST Regional Root Switch. As the CIST Root Switch

has the lowest known Bridge ID in the CST, it is automatically the CST Root as well,

although this observation would be important only in cases of mixed MST and non-MST

environments.

In other MST regions that do not contain the CIST Root Switch, only MST switches at

the region boundary (that is, having links to other regions) are allowed to assert them-

selves as IST root switches. This is done by allowing the CIST Regional Root ID to be set

either to the Bridge ID of the switch itself if and only if the switch is also the CIST Root,

or in all other cases, to the Bridge ID of an MST boundary switch that receives BPDUs

from a different region. Remaining internal switches have therefore no way of participat-

ing in IST root elections. From boundary switches, IST root switches are elected first by

their lowest external root path cost to the CIST Root Switch. The external root path cost

is the sum of costs of inter-region links to reach the region with the CIST Root Switch, or

in other words, the CST cost of reaching the region with the CIST Root Switch; costs of

links inside regions are not taken into account. In case of a tie, the lowest IST Bridge ID

of boundary switches is used. Note that these rules significantly depart from the usual

concept of the root switch having the lowest Bridge ID. In MST regions that do not con-

tain the CIST Root Switch, the regional IST root switches might not necessarily be the

ones with the lowest Bridge IDs.

A CIST Regional Root Switch has a particular importance for a region: Its own CIST Root

Port, that is, the Root Port to reach the CIST Root Switch outside the region, is called

the Master port (this is an added port role in MST), and provides connectivity from the

region toward the CIST Root for all MST instances inside the region.

Interoperability Between MST and Other STP Versions

To understand the interoperation between MST and other STP versions, we first need

to have a look at the way MST interoperates with non-MST switches running pure

IEEE 802.1D STP or 802.1w RSTP without any per-VLAN semantics (let us call them

simply non-MST switches). These non-MST switches run a single STP instance for all

VLANs and so all VLANs share the same single spanning tree in the non-MST part of

the network. Whatever role and state a non-MST switch puts a port into, this role and

state are shared by all VLANs on that port. If a non-MST switch is to interoperate with

one or more neighboring MST switches, these MST switches must give the impression

of running a single STP or RSTP to non-MST switches. Also, because STP and RSTP

do not understand nor see into the workings of MST in individual instances inside an

MST region, the entire MST region is a single “black box” to STP and RSTP. It is quite

logical, then, to treat this single “black box” as a single huge switch. This single switch

must speak a single instance of STP or RSTP on its boundary ports toward its non-MST

neighbors, and whatever decisions are made about port roles and states on this boundary,

they must apply to all VLANs. The non-MST switches accomplish this trivially by the

very way they run IEEE STP/RSTP; the MST switches do this by speaking exclusively the

MST instance 0, also called the IST, on boundary ports, formatted into ordinary STP or

RSTP BPDUs, and applying the negotiated port roles and states on boundary ports to all

ptg13046388

142 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

VLANs on those ports. The MST instance 0 has a key role here—it speaks to non-MST

neighbors and it processes BPDUs received from them.

The interoperation between an MST region and an older IEEE STP variant is relatively

straightforward. The non-MST region speaks a single STP/RSTP instance. The MST

region uses the IST to speak on behalf of the entire region to non-MST neighbors on

boundary ports. The resulting boundary port roles and states derived from the interaction

of IEEE STP/RSTP and IST are binding for all VLANs.

Interaction between MSTP and Cisco’s PVST+ is significantly more complex to under-

stand. PVST+ regions by definition run one STP or RSTP instance for each active VLAN.

It might be tempting at first to have each received PVST+ BPDU processed by the

particular MST instance to which the respective VLAN is mapped. This idea is futile,

however. There can be two or more VLANs mapped to the same MST instance that have

completely different root bridges, root path costs, and so on in the PVST+ region. Which

root bridge IDs, root path costs, and other STP attributes shall be taken into account by

this MST instance, then? Clearly, the idea of doing any “smart” mapping between PVST+

and MST instances is not the way to go.

Instead, the idea of interoperation between MST and PVST+ stems from the basic idea

of interoperation between MST and IEEE STP/RSTP. For both MST and PVST+ regions,

a single representative is chosen to speak on behalf of the entire region, and the interac-

tion between these two representatives determines the boundary port roles and states

for all VLANs. Doing this is trickier than it seems, though. While the role and state of an

MST boundary will be unconditionally imposed on all VLANs active on that port (that is

how MST boundary ports work), PVST+ ports have independent roles and states for each

VLAN. If a single representative MST instance is chosen to speak on behalf of an MST

region, its information must be delivered to PVST+ switches in such a way that every

PVST+ instance receives the same information to make an identical, consistent choice.

The word consistent becomes very important—it describes a process where both MST

and PVST+ in all their instances arrive at the same port role and state determination even

though only a single MST instance and a single PVST+ instance directly interact with

each other. The purpose of the PVST Simulation mechanism is to allow for a consistent

interoperation between MST and PVST+ regions.

In the MST-to-PVST+ direction, the MST region again chooses the IST as the represen-

tative, with the goal of speaking IST information to all PVST+ instances using PVST+

BPDUs. To allow the PVST+ region to make an identical, consistent decision based on

IST’s attributes for all known VLANs, all PVST+ instances must receive the same IST

information formatted in PVST+ BPDUs. Therefore, MST boundary ports replicate the

IST’s BPDUs into PVST+ BPDUs for all active VLANs. This way, the MST supplies PVST+

neighbors with consistent information in all VLANs. A PVST+ neighbor receiving these

BPDUs on any single port will therefore make an identical, consistent choice of that

port’s role and state for all VLANs.

In the opposite direction, MST takes the VLAN 1 as the representative of the entire

PVST+ region, and processes the information received in VLAN 1’s BPDUs in IST.

The boundary port’s role and state will be binding for all VLANs active on that port.

However, MST must make sure that the boundary’s port role and state as determined by

ptg13046388

Chapter 3: Spanning Tree Protocol 143

interaction with VLAN 1’s STP instance truly represent the choice that all other PVST+

instances would also make; that is, it must ascertain whether the result of IST’s interaction

with VLAN 1’s STP instance is consistent with the state of STP instances run in other

VLANs.

Let us analyze this in closer detail. The interaction of IST run on an MST boundary port

and VLAN 1 PVST+ can basically result in three possible roles of the port: Designated,

Root, or Non-Designated (whether that is Alternate or Backup is not relevant at this

point).

An MST boundary port will become a Designated Port if the BPDUs it sends out (car-

rying IST data) are superior to incoming VLAN 1 PVST+ BPDUs. A Designated bound-

ary port will unconditionally become Forwarding for all VLANs, not just for VLAN 1.

Therefore, to make sure that the other PVST+ instances make a consistent decision, the

boundary port must verify whether other PVST+ instances would also consider it to be a

Designated Port. This is trivially accomplished by listening to all incoming PVST+ BPDUs

and making sure that each of them is inferior to the boundary port’s own BPDUs. This

forms our first PVST Simulation consistency criterion:

PVST+ BPDUs for all VLANs arriving at a Designated boundary port must be

inferior to its own BPDUs derived from IST.

Conversely, an MST boundary port will become a Root Port toward the CIST root

bridge if the incoming VLAN 1 PVST+ BPDUs are so superior that they not only beat

the boundary port’s own BPDUs but also are the best VLAN 1 PVST+ BPDUs received

on any of the boundary ports. Obviously, this situation implies that the CIST Root is

located in the PVST+ region and it is the root switch for VLAN 1. A root boundary port

will unconditionally become forwarding for all VLANs. Therefore, to make sure that the

other PVST+ instances make a consistent decision, the boundary port must also act like a

Root Port toward root bridges in all remaining VLANs. This in turn implies that the root

bridges for these VLANs must also be located in the PVST+ region and the Root Port

toward them is exactly this particular boundary port. A simple, yet sufficient condition

to make this happen is to verify whether incoming PVST+ BPDUs for VLANs other than

1 are identical or even superior to incoming PVST+ BPDUs for VLAN 1. This forms our

second consistency PVST Simulation criterion:

PVST+ BPDUs for VLANs other than VLAN 1 arriving at a root boundary port

must be identical or superior to PVST+ BPDUs for VLAN 1.

Note that if System ID Extension is used, PVST+ BPDUs for different VLANs cannot be

identical, and in fact, with the same priority on a PVST+ root switch for multiple VLANs,

PVST+ BPDU for VLAN x is inferior to BPDU for VLAN y if x>y . Therefore, to meet

the second consistency criterion, priorities for PVST+ root switches in VLANs other than

VLAN 1 must be lower by at least 4096 from the priority of the PVST+ VLAN 1 root

switch.

In both these cases, if the criterion for a particular port role is not met, the PVST

Simulation process will declare a PVST Simulation inconsistency and will keep the port

in the blocked state until the consistency criterion for the port’s role is met again. Older

switches report the offending port as Root Inconsistent; recent switches use the PVST

Simulation Inconsistent designation instead.

ptg13046388

144 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Finally, an MST boundary port will become a Non-Designated port if the incoming

VLAN 1 PVST+ BPDUs are superior to its own BPDUs but not that superior to make

this port a Root Port. A Non-Designated boundary port will unconditionally become

Blocking for all VLANs. Therefore, to make sure that the other PVST+ instances make a

consistent decision, the boundary port should verify whether also other PVST+ instances

would consider it to be a Non-Designated port. This could be trivially accomplished

by listening to all incoming PVST+ BPDUs and making sure that each of them is supe-

rior to the boundary port’s own BPDU; however, Cisco appears to have implemented

a slight optimization here. If indeed this criterion was met, all PVST+ instances would

consis tently consider this port to be a Non-Designated port and the port would be

blocked according to its Non-Designated role. If, however, this criterion was not met,

that is, at least one non-VLAN1 PVST+ BPDU was inferior to this port’s BPDU, the PVST

Simulation inconsistency would be declared, and the port would be kept blocked. So in

any case, the port will be blocked. Hence, for Non-Designated ports, there are no consis-

tency checks performed because the port is blocked regardless.

If it is necessary to operate a mixed MST and PVST+ network, it is recommended to

make sure that the MST region appears as a root switch to all PVST+ instances by lower-

ing its IST root’s priority below the priorities of all PVST+ switches in all VLANs.

It is noteworthy to mention that if a Cisco MST switch faces a pure 802.1D STP or

802.1w RSTP switch, it will revert to the appropriate STP version on the interconnect-

ing port, that is, STP or RSTP, according to the neighbor type. However, if a Cisco MST

switch is connected to a PVST+ or RPVST+ switch, it will always revert to PVST+. In

other words, Cisco MST interoperates with RPVST+ regions using only PVST+, revert-

ing to PVST+ operation on a region boundary. This is an implementor’s decision made to

simplify the interworking between MST and RPVST+ regions—it requires less state to be

stored and processed, particularly with respect to the Proposal/Agreement mechanism.

Note PVST Simulation consistency criteria require that for an MST Boundary port

toward a PVST+ region to be Forwarding, one of the following conditions must be met:

■ Either the boundary port’s own IST BPDUs are superior to all received PVST+

BPDUs regardless of their VLAN (in this case, the port becomes Designated; “if be

Designated Port for VLAN 1, then be Designated Port for all VLANs”)

■ Or the boundary port’s own IST BPDUs are inferior to received PVST+ BPDUs for

VLAN 1, and they are in turn identical or inferior to received PVST+ BPDUs for other

VLANs (in this case, the port becomes Root Port; “if be Root Port for VLAN 1, then

be Root Port for all VLANs”)

MST Configuration

Configuring MST requires a certain degree of prior planning. First, it is necessary to

decide whether multiple regions shall be used and where their boundaries shall be placed.

Multiple regions allow having independent numbers of MST instances, VLAN-to-instance

ptg13046388

Chapter 3: Spanning Tree Protocol 145

mappings, and individual instance roots in each region. The overall network operation

can become more complex to understand and maintain, though. Each region must be

subsequently assigned its name, configuration revision number, and VLAN-to-instance

mapping table. The name, revision number, and VLAN-to-instance mappings are three

mandatory elements of MST configuration and must match on all switches of a single

region. The name and configuration revision number are carried in MST BPDUs in their

plain form. Instead of transmitting the entire VLAN-to-instance mapping table, an MD5

hash is performed over it and its value is carried in MST BPDUs. The region name, revi-

sion number, and the MD5 hash of the VLAN-to-instance mapping table are compared

upon BPDU arrival and must match for two switches to consider themselves being in the

same region. The hash value can be displayed using the show spanning-tree mst

configuration digest EXEC command. On older switches, the digest keyword might be

hidden but nevertheless accepted if typed in its entirety.

A modification to the MST region configuration (name, revision, mapping of VLANs

onto instances) on a single switch causes the switch to create its own region and trig-

ger a topology change, possibly causing a transient network outage. Upgrading an MST

region to a new configuration will therefore require a maintenance window. As changes

to VLAN-to-instance mappings are most common, it is recommended to premap VLANs

into instances even before the VLANs are created. Creating (or deleting) a VLAN after it

is mapped to an instance will not cause any topology change event with respect to MST.

If it is necessary to operate a mixed MST and PVST+ network, it is recommended to

make sure that the MST region becomes the region containing the CIST Root Switch.

This can be accomplished by lowering the IST root switch’s priority (that is, the priority

of the existing root of instance 0 in the MST region) below the priorities of all PVST+

switches in all VLANs.

Finally, older Cisco switches have implemented a prestandard version of MST that differs

in the BPDU format and some other details. A quick test to verify whether the switch

supports the standard or prestandard MST version is to issue the show spanning-tree mst

configuration digest command. If there is only a single MD5 digest displayed in the out-

put, the switch supports prestandard MST only. If there are two MD5 digests displayed,

the switch supports standard MST and also the prestandard MST for backward compat-

ibility. If a switch implementing standard MST is to be connected to a switch running

prestandard MST, the port toward the prestandard switch must be configured with the

spanning-tree mst pre-standard command; otherwise, permanent switching loops can

ensue or the switch will keep the port blocking until configured with this command.

Configuration of MST can be accomplished by following these steps:

Step 1. Enter MST configuration mode by using the spanning-tree mst configura-

tion command.

Step 2. From MST configuration mode, create an MST region name (up to 32 charac-

ters) by using the name subcommand.

Step 3. From MST configuration mode, define an MST revision number by using the

revision command.

ptg13046388

146 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step 4. From MST configuration mode, map VLANs to an MST STP instance by

using the instance command.

Step 5. From MST configuration mode, after reviewing the MST configuration before

performing the changes using the show current command and after the

changes using the show pending command, you can either apply the changes

using the exit command or cancel the changes using the abort command.

Both commands will exit from the MST configuration mode.

Step 6. Globally enable MST using the spanning-tree mode mst command.

Example 3-2 demonstrates configuring a switch with an MST region.

Example 3-2 MST Configuration and show Commands

! First, the MST region configuration is entered, defining the name of the region

! to be CCIE, the configuration revision to 1, and creating four instances

! with different VLANs mapped onto them. Note that the VLANs do not need to be

! created at all; they can be pre-mapped into MST instances and created later.

! The show current shows the current (empty at the moment) MST configuration,

! the show pending shows the modified but still unapplied configuration.

SW1(config)# spanning-tree mst configuration

SW1(config-mst)# name CCIE

SW1(config-mst)# revision 1

SW1(config-mst)# instance 1 vlan 1-500

SW1(config-mst)# instance 2 vlan 501-1000

SW1(config-mst)# instance 3 vlan 1001-2047

SW1(config-mst)# instance 4 vlan 2048-4094

SW1(config-mst)# show current

Current MST configuration

Name []

Revision 0 Instances configured 1

Instance Vlans mapped

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

0 1-4094

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

SW1(config-mst)# show pending

Pending MST configuration

Name [CCIE]

Revision 1 Instances configured 5

Instance Vlans mapped

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

0 none

1 1-500

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 147

2 501-1000

3 1001-2047

4 2048-4094

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

SW1(config-mst)# exit

SW1(config)# spanning-tree mode mst

! To modify the switch's priority, spanning-tree mst instance priority command

! must be used instead of spanning-tree vlan vlan-id priority . Also, modifying

! a port's cost or priority is accomplished using spanning-tree cost mst and

! spanning-tree port-priority mst commands instead of their counterparts utilizing

! the vlan keyword. They have no effect in MST mode.

SW1(config)# spanning-tree mst 0 priority 0

SW1(config)# spanning-tree mst 1 priority 4096

SW1(config)# spanning-tree mst 2 priority 8192

! If switches in the region support VTPv3 then VTPv3 can be used to synchronize

! the MST region configuration across all switches in the VTP domain. As all

! switches in the VTP domain will share the same MST region configuration, they

! will all become members of the same MST region. Hence, there is a 1:1 relation

! between a VTPv3 domain and the MST region.

SW1(config)# vtp domain CCIE

Changing VTP domain name from NULL to CCIE

*Mar 12 16:12:14.697: %SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to

CCIE.

SW1(config)# vtp version 3

SW1(config)#

*Mar 12 16:12:18.606: %SW_VLAN-6-OLD_CONFIG_FILE_READ: Old version 2 VLAN

configuration file detected and read OK. Version 3

files will be written in the future.

SW1(config)# vtp mode server mst

Setting device to VTP Server mode for MST.

SW1(config)# do vtp primary mst

This system is becoming primary server for feature mst

No conflicting VTP3 devices found.

Do you want to continue? [confirm]

*Mar 12 16:12:46.422: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0023.ea41.ca00 has become

the primary server for the MST VTP feature

SW1(config)#

! From this moment on, the entire spanning-tree mst configuration section will be

! synchronized across the entire VTPv3 domain, and changes to its contents on SW1

ptg13046388

148 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! as the primary server switch will be propagated to all switches in the domain.

! Note that MST region configuration revision is independent of VTPv3 revision

! number and will not be incremented by VTP automatically. VTP uses its own

! revision number which will be incremented.

Protecting and Optimizing STP

This section covers several switch configuration tools that protect STP from different

types of problems or attacks, depending on whether a port is a trunk or an access port.

The previous edition of this book covered Cisco-proprietary extensions to legacy STP—

the UplinkFast and BackboneFast features. These additions have been dropped from the

current exam blueprint, and in addition, their core ideas (tracking Alternate Ports, accept-

ing inferior BPDUs from designated switches) have been leveraged in RSTP and MST,

becoming an integral part of their design.

PortFast Ports

The PortFast is a well-known improvement in legacy STP and PVST+, and is a standard-

ized enhancement in RSTP and MST. Essentially, it defines an Edge port. We will use

both Edge port and PortFast port terms interchangeably. An Edge port becomes for-

warding immediately after coming up, does not generate topology change events, does

not flush MAC addresses from the CAM table as a result of topology change handling,

and is not influenced by the Sync step in the Proposal/Agreement procedure. An Edge

port sends BPDUs but it expects not to receive any BPDUs back. If a BPDU does arrive at

a PortFast port, the operational PortFast status will be disabled on the port until it goes

down and back up.

The use of PortFast on ports toward end hosts is important for several reasons. First and

foremost, it accelerates the port’s transition into the Forwarding state. Apart from saving

twice the ForwardDelay time, it also remediates problems with overly sensitive DHCP

clients on end hosts that report an error if no response from a DHCP server is received

within a couple of seconds. Second, a somewhat less obvious but far more grave rea-

son to use PortFast is that in RSTP and MST, it prevents a port from being put into the

Discarding state during Proposal/Agreement handling. Not taking care to configure Edge

ports in a network running RSTP or MST will result in intermittent connectivity during

topology changes, and while the network itself will reconverge in seconds at most (and

usually much sooner), end hosts will suffer an outage for twice the ForwardDelay time.

PortFast ports can be configured either directly on ports using the spanning-tree

portfast command or on a global level using the spanning-tree portfast default com-

mand. Both of these commands apply only to ports operating in access mode (that is,

static access or dynamic mode that negotiated an access link). This behavior simply fol-

lows the logic that end hosts are usually connected to access ports while links to other

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 149

switches operate as trunks. If PortFast is enabled globally, but some access port is nev-

ertheless connected to another switch, PortFast can be explicitly disabled on that port

using the spanning-tree portfast disable command.

If a trunk port is connected to an end device, such as a router or a server, it can be forced

into PortFast mode using the spanning-tree portfast trunk interface level command. Be

sure, however, to never activate PortFast on ports toward other switches. RSTP and MST

will take care of their rapid handling if the other switch also speaks RSTP or MST.

Root Guard, BPDU Guard, and BPDU Filter: Protecting Access Ports

Network designers probably do not intend for end users to connect a switch to an access

port that is intended for attaching end-user devices. However, it happens—for example,

someone just might need a few more ports in the meeting room down the hall, so he fig-

ures that he could just plug a small, cheap switch into the wall socket.

The STP topology can be changed based on one of these unexpected and undesired

switches being added to the network. For example, this newly added and unexpected

switch might have the lowest Bridge ID and become the root. To prevent such problems,

BPDU Guard and Root Guard can be enabled on these access ports to monitor for incom-

ing BPDUs—BPDUs that should not enter those ports, because they are intended for

single end-user devices. Both features can be used together. Their base operations are as

follows:

■ BPDU Guard: Enabled per port or globally per PortFast-enabled ports; error disables

the port immediately upon receipt of any BPDU.

■ Root Guard: Enabled per port; ignores any received superior BPDUs to prevent this

port from becoming the Root Port. Upon receipt of superior BPDUs, this switch puts

the port in a root-inconsistent blocking state, ceasing forwarding and receiving data

frames until the superior BPDUs cease.

The BPDU Guard can either be activated unconditionally on a per-port basis using the

spanning-tree bpduguard enable interface command or globally using the spanning-

tree portfast bpduguard default command. The global command, however, activates the

BPDU Guard only on ports that operate as PortFast ports (it does not matter how the

port was configured for PortFast operation). Again, in the case where BPDU Guard is

enabled globally but it needs to be deactivated on a particular PortFast port, the

spanning-tree bpduguard disable interface command can be used.

There is often confusion regarding the relation of PortFast and BPDU Guard to each

other. In reality, the only dependence between these mechanisms is concerned with con-

figuring the BPDU Guard on a global level. In this case, it will be automatically activated

on those ports on which PortFast is also active; in other words, the global activation of

BPDU Guard will activate it on all Edge ports. Besides this particular configurational

Key

Topic

ptg13046388

150 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

dependency, PortFast and BPDU Guard are completely independent. On a port, BPDU

Guard can be configured regardless of PortFast. PortFast, either per-port or globally, can

be configured regardless of BPDU Guard.

Regardless of how the BPDU Guard is activated on an interface, when a BPDU is received

on such a port, it will be immediately err-disabled.

Root Guard can be activated only on a per-port basis using the spanning-tree guard root

interface command.

With BPDU Guard, the port does not recover from the err-disabled state unless addi-

tional configuration is added. You can tell the switch to change from the err-disabled

state back to an up state after a certain amount of time. With Root Guard, the port recov-

ers automatically when the undesired superior BPDUs are no longer received for the usual

MaxAge-Message age in STP, or 3x Hello in RSTP (effectively, when they expire).

The BPDU Filter feature is concerned with stopping the transmission, and optionally

the reception as well, of BPDUs on a port. Its behavior differs depending on how it is

activated:

■ If configured globally using spanning-tree portfast bpdufilter default , it applies

only to Edge ports (that is, to ports on which PortFast is active). After these ports

are connected to, they will start sending BPDUs each Hello interval; however, if dur-

ing the next ten Hello intervals, no BPDU is received from the connected device, the

port will stop sending BPDUs itself. As a result, the port will send only 11 BPDUs

(one immediately after the port comes up, and then ten more during the ten Hello

intervals) and then cease sending BPDUs. The port is still prepared to process any

incoming BPDUs. If a BPDU arrives at any time, during the first ten Hello intervals

or anytime after, BPDU Filter will be operationally deactivated on that port, and

the port will start sending and receiving BPDUs according to usual STP rules. BPDU

Filter operation on this port will be reinstated after the port is disconnected and

reconnected. As usual, if the global configuration of BPDU Filter applies to an Edge

port on which you do not want BPDU Filter to be activated, you can exempt the

port using the spanning-tree bpdufilter disable command.

■ If configured locally on a port using the spanning-tree bpdufilter enable com-

mand, BPDU Filter will cause the port to unconditionally stop sending and receiving

BPDUs altogether.

The use of BPDU Filter depends on how it is configured. The global BPDU Filter configu-

ration causes Edge ports to stop sending BPDUs after a certain time, assuming that it is

not useful to send BPDUs to end devices as they do not speak STP. If it is discovered that

such a port is actually connected to a switch by receiving a BPDU, the BPDU Filter will

be deactivated on the port until the port goes down and comes back up (through discon-

nect/reconnect, or through shutting it down and activating it again). This can be consid-

ered an optimization in networks with many access ports toward end devices.

Key

Topic

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 151

BPDU Filter configured directly on a port causes the port to stop sending and processing

received BPDUs. No BPDUs will be sent; received BPDUs will be silently dropped. This

configuration prevents STP from participating with any other switch on the port. Usually,

this feature is used to split a network into separate independent STP domains. Because in

this case, STP does not operate over these ports, it is unable to prevent a switching loop

if the STP domains are redundantly interconnected. It is the responsibility of the adminis-

trator, then, to make sure that there are no physical loops between the STP domains.

Again, there is often confusion regarding the dependence of PortFast and BPDU Filter.

Their true dependence is practically identical to that of BPDU Guard and PortFast. The

only situation where BPDU Filter and PortFast are configurationally dependent is when

BPDU Filter is configured on a global level, because in that case it automatically applies

to all Edge ports (that is, ports with active PortFast). If a port on which BPDU Filter

is active because global configuration (meaning that it must have been an Edge port)

receives a BPDU, it will lose its Edge status, and because the global BPDU Filter configu-

ration applies to Edge ports, BPDU Filter on this port will be deactivated as well. Apart

from this, no other dependency between BPDU Filter and BPDU Guard exists.

It is possible to combine globally configured BPDU Filter with BPDU Guard (the BPDU

Guard can be also configured globally or per-port in this case). Should a port protected

both with global BPDU Filter and BPDU Guard receive a BPDU, it will be automatically

err-disabled.

On the other hand, it does not make sense to combine port-level BPDU Filter with BPDU

Guard. As the port drops all received BPDUs, the BPDU Guard will never see them,

meaning that it will never be able to put the port into an err-disabled state.

Protecting Against Unidirectional Link Issues

Unidirectional links are links for which one of the two transmission paths on the link has

failed, but not both. This can happen as a result of miscabling, cutting one fiber cable,

unplugging one fiber, GBIC problems, or other reasons. Because STP monitors incoming

BPDUs to know when to reconverge the network, adjacent switches on a unidirectional

link could both become Forwarding, causing a loop, as shown in Figure 3-15 .

Figure 3-15 shows the fiber link between SW1 and SW2 with both cables. SW2 starts in

a Blocking state, but as a result of the failure on SW1’s transmit path, SW2 ceases to hear

Hellos from SW1. SW2 then transitions to the Forwarding state, and now all trunks on all

switches are Forwarding. Even with the failure of SW1’s transmit fiber, frames will now

loop counterclockwise in the network.

On Catalyst switches, there are several mechanisms available to detect and avoid issues

caused by unidirectional links. These mechanisms include UDLD, STP Loop Guard,

Bridge Assurance, and the RSTP/MST Dispute mechanism.

Unidirectional Link Detection (UDLD), a Cisco-proprietary Layer 2 messaging protocol,

serves as an echo mechanism between a pair of devices. Using UDLD messages, each

switch advertises its identity and port identifier pair as the message originator, and a list

ptg13046388

152 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

of all neighboring switch/port pairs heard on the same segment. Using this information, a

unidirectional link can be detected by looking for one of the following symptoms:

■ UDLD messages arriving from a neighbor do not contain the exact switch/port pair

matching the receiving switch and its port in the list of detected neighbors. This

suggests that the neighbor either does not hear this switch at all (for example, a cut

fiber) or the neighbor’s port sending these UDLD messages is different from that

neighbor’s port receiving this switch’s own UDLD messages (for example, a Tx fiber

plugged into a different port than the Rx fiber).

FWD

Root

FWD

Non-DP

BLK

One Trunk, Two Fiber Cables

Hello Cost 19

2No more Hellos. I must

be the DP. Let me

transition to forwarding!

SW1

SW3

SW2

Figure 3-15 STP Problems with Unidirectional Links

Key

Topic

Key

Topic

■ UDLD messages arriving from a neighbor contain the same switch/port originator

pair as used by the receiving switch. This suggests a self-looped port.

■ A switch has detected only a single neighbor but that neighbor’s UDLD messages

contain more than one switch/port pair in the list of detected neighbors. This sug-

gests a shared media interconnection with an issue in its capability to provide full

visibility between all connected devices.

If any of these symptoms are detected, UDLD will declare the link as unidirectional and

will err-disable the port.

In addition, a unidirectional link can under circumstances also manifest itself by sudden

loss of all incoming UDLD messages without the port going down. This symptom is not

always a reliable indication of a unidirectional link, though. Assume, for example, two

switches interconnected by a link utilizing a pair of metallic/optical media converters. If

one switch is turned off, the other switch will not experience a link down event; just the

UDLD messages stop arriving. Assuming that the link has become unidirectional would

be presumptuous in this case.

UDLD therefore has two modes of operation with the particular respect to the sudden

loss of arriving UDLD messages. In the normal mode, if UDLD messages cease being

received, a switch will try to reconnect with its neighbors (eight times), but if this attempt

ptg13046388

Chapter 3: Spanning Tree Protocol 153

fails, UDLD takes absolutely no action. In particular, the port that stopped receiving

UDLD messages will remain up. In the aggressive mode, after UDLD messages stop

arriving, a switch will try eight times to reconnect with its neighbors, and if this attempt

fails, UDLD will err-disable the port. The difference between the normal and aggressive

mode therefore lies in the reaction to the sudden loss of incoming UDLD messages, that

is, to an implicit indication of a possible unidirectional link condition. Note that both

normal and aggressive modes will err-disable the port if the unidirectional link is explic-

itly detected by the three symptoms described earlier.

UDLD can be activated either on a global level or on a per-port basis, and needs to be

activated on both interconnected devices. Global UDLD configuration applies only to

fiber ports; per-port UDLD configuration activates it regardless of the underlying media

type. On the global level, UDLD is activated with the udld { enable | aggressive } com-

mand, the enable keyword referring to the normal mode and aggressive referring to the

aggressive mode. On a port, UDLD is activated using the udld port [ aggressive ] com-

mand. If the aggressive keyword is omitted, normal mode is used. Operational status

of UDLD including port information and detected neighbors and their states can be

displayed using show udld and show udld neighbors commands. If UDLD err-disables

a port after detecting a unidirectional link condition, apart from shutting it down and

bringing it back up to reactivate it, a port can also be reset from the privileged EXEC

mode using the udld reset command.

STP Loop Guard is an added logic related to receiving BPDUs on Root and Alternate

Ports on point-to-point links. In the case of a unidirectional link, these ports could move

from Root or Alternate to Designated, thereby creating a switching loop. STP Loop

Guard assumes that after BPDUs were being received on Root and Alternate Ports, it is

not possible in a correctly working network for these ports to suddenly stop receiving

BPDUs without them actually going down. A sudden loss of incoming BPDUs on Root

and Alternate Ports therefore suggests that a unidirectional link condition might have

occurred.

Following this logic, STP Loop Guard prevents Root and Alternate Ports from becoming

Designated as a result of total loss of incoming BPDUs. If BPDUs cease being received on

these ports and their stored BPDUs expire, Loop Guard will put them into a loop-

inconsistent blocking state. They will be brought out of this state automatically after

they start receiving BPDUs again.

Loop Guard can be activated either globally or on a per-port basis, and is a local protec-

tion mechanism (that is, it does not require other switches to be also configured with

Loop Guard to work properly). If activated globally using the spanning-tree loopguard

default command, it automatically protects all Root and Alternate Ports on STP point-to-

point link types on the switch. Global Loop Guard does not protect ports on shared type

links. It can also be configured on a per-port basis using the spanning-tree guard loop

command, in which case it applies even to ports on shared links.

The Bridge Assurance, applicable only with RPVST+ and MST and only on point-to-point

links, is a further extension of the idea used by Loop Guard. Bridge Assurance modi-

fies the rules for sending BPDUs. With Bridge Assurance activated on a port, this port

Key

Topic

Key

Topic

Key

Topic

ptg13046388

154 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

always sends BPDUs each Hello interval, whether it is Root, Designated, Alternate, or

Backup. BPDUs thus essentially become a Hello mechanism between pairs of intercon-

nected switches. A Bridge Assurance–protected port is absolutely required to receive

BPDUs. If no BPDUs are received, the port will be but into a BA-inconsistent block-

ing state until it starts receiving BPDUs again. Apart from unidirectional links, Bridge

Assurance also protects against loops caused by malfunctioning switches that completely

stop participating in RPVST+/MST (entirely ceasing to process and send BPDUs) while

opening all their ports. At the time of this writing, Bridge Assurance was supported on

selected Catalyst 6500 and Nexus 7000 platforms. Configuring it on Catalyst 6500 Series

requires activating it both globally using spanning-tree bridge assurance and on ports

on STP point-to-point link types toward other switches using the spanning-tree portfast

network interface command. The neighboring device must also be configured for Bridge

Assurance.

The Dispute mechanism is yet another and standardized means to detect a unidirectional

link. Its functionality is based on the information encoded in the Flags field of RST and

MST BPDUs, namely, the role and state of the port forwarding the BPDU. The principle

of operation is very simple: If a port receives an inferior BPDU from a port that claims to

be Designated Learning or Forwarding, it will itself move to the Discarding state. Cisco

has also implemented the Dispute mechanism into its RPVST+. The Dispute mechanism

is not available with legacy STP/PVST+, as these STP versions do not encode the port

role and state into BPDUs. The Dispute mechanism is an integral part of RSTP/MST and

requires no configuration.

Configuring and Troubleshooting EtherChannels

EtherChannel, also known as Link Aggregation, is a widely supported and deployed tech-

nology used to bundle several physical Ethernet links interconnecting a pair of devices

into a single logical communication channel with increased total throughput. After an

EtherChannel is established, it is represented to the devices as a single logical interface

(called Port-channel in Cisco parlance), utilizing the bandwidth of all its member links.

This allows for traffic load sharing between the member links, taking advantage of their

combined bandwidth. Also, should a link in an EtherChannel bundle fail, the traffic will

be spread over remaining working links without further influencing the state of the logi-

cal interface. Control plane protocols that see only the logical Port-channel interface and

not its underlying physical members, such as STP, will only notice a change in the inter-

face’s bandwidth parameter (if not configured statically using the bandwidth command).

The reaction to a failure or addition of a member link is therefore significantly more

graceful than a reaction to a loss or reestablishment of a standalone link.

Load Balancing Across Port-Channels

EtherChannel increases the available bandwidth by carrying multiple frames over

multiple links. A single Ethernet frame is always transmitted over a single link in an

EtherChannel bundle. A hashing function performed over selected frames’ address fields

produces a number identifying the physical link in the bundle over which the frame will

Key

Topic

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 155

be forwarded. The sequence of frames having an identical value in a particular address

field (or a set of fields) fed into the hashing function is called a conversation or simply

a flow . This hashing function is deterministic, meaning that all frames in a single flow

produce the same hash value, and are therefore forwarded over the same physical link.

Hence, the increase in the available bandwidth is never experienced by a single flow;

rather, multiple flows have a chance of being distributed over multiple links, achieving

higher aggregated throughput. The fact that a single flow is carried by a single link and

thus does not benefit from a bandwidth increase can be considered a disadvantage; how-

ever, this approach also prevents frames from being reordered. This property is crucial, as

EtherChannel—being a transparent technology—must not introduce impairments that

would not be seen on plain Ethernet.

Load-balancing methods differ depending on the model of switch and software revision.

Generally, load balancing is based on the contents of the Layer 2, 3, and/or 4 headers.

If load balancing is based on only one header field in the frame, that single field is fed

into the hashing function. If more than one header field is used, first, an XOR operation

between the selected fields is used and only the result of this XOR is fed into the hashing

function. The details of hashing functions in use are not public and can vary between dif-

ferent switch platforms.

For the best balancing effect, the header fields on which balancing is based need to vary

among the mix of frames sent over the Port-channel. For example, for a Layer 2 Port-

channel connected to an access layer switch, most of the traffic going from the access

layer switch to the distribution layer switch is probably going from clients to the default

router. So most of the frames have different source MAC addresses but the same destina-

tion MAC address. For packets coming back from a distribution switch toward the access

layer switch, many of the frames might have a source address of that same router, with

differing destination MAC addresses. So, you could balance based on source MAC at the

access layer switch and based on destination MAC at the distribution layer switch—or

balance based on both fields on both switches. The goal is simply to use a balancing

method for which the fields in the frames vary.

The port-channel load-balance type global level command sets the type of load balanc-

ing. The type options include using source and destination MAC, IP addresses, and TCP

and UDP ports—either a single field or both the source and destination. Because this

command is global, it influences the operation of all EtherChannel bundles on a switch.

Devices on opposite ends of an EtherChannel bundle can, and often do, use different

load-balancing algorithms.

The maximum number of active member links in an EtherChannel bundle is eight. This

limit is reasonable, considering that Ethernet variants differ in speed by orders of tens (10

Mbps, 100 Mbps, 1 Gbps, 10 Gbps, 100 Gbps). More than eight links in an EtherChannel

bundle is simply closing in on the next faster Ethernet variant, so it is reasonable to con-

sider using a faster Ethernet variant in such cases instead. On many Catalyst switch plat-

forms, the hashing function therefore produces a 3-bit result in the range of 0–7 whose

values are assigned to the individual member links. With eight physical links in a bundle,

ptg13046388

156 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

each link is assigned exactly one value from this range. If there are fewer physical links,

some of the links will be assigned multiple values from this range, and as a result, some

of the links will carry more traffic than the others. Table 3-7 describes the traffic amount

ratios (P n denotes the n th port in a bundle).

Table 3-7 Load Spread Ratios with Different Port Numbers in EtherChannel

Number of Ports in

the EtherChannel

Load-Balancing Ratios

8 P1:P2:P3:P4:P5:P6:P7:P8 → 1:1:1:1:1:1:1:1

7 P1:P2:P3:P4:P5:P6:P7:P1 → 2:1:1:1:1:1:1

6 P1:P2:P3:P4:P5:P6:P1:P2 → 2:2:1:1:1:1

5 P1:P2:P3:P4:P5:P1:P2:P3 → 2:2:2:1:1

4 P1:P2:P3:P4:P1:P2:P3:P4 → 2:2:2:2

3 P1:P2:P3:P1:P2:P3:P1:P2 → 3:3:2

2 P1:P2:P1:P2:P1:P2:P1:P2 → 4:4

Under ideal conditions, the traffic distribution across member links will be equal only

if the number of links is eight, four, or two. With the eight resulting values from a 3-bit

hash function, each value represents 1/8=12.5% of the traffic. The spread of the traffic by

multiples of 12.5% is quite coarse. The indicated ratios can also be computed by using

DIV and MOD operations: For example, with three links in a bundle, each link will be

assigned 8 DIV 3 = 2 resulting hash values, plus 8 MOD 3 = 2 links will be handling an

additional hash result value, yielding a ratio of (2+1):(2+1):2 = 3:3:2, or 37.5% : 37.5% :

25%.

On other Cisco switch platforms, an 8-bit hash result is used although the EtherChannel

is still limited to a maximum of eight links. Because the hash value allows for 256 pos-

sible results, each value represents a mere 1/256 = 0.390625% of the traffic. The spread of

the traffic across links in a bundle is thus much more fine-grained. With three links, each

of them would be assigned 256 DIV 3 = 85 resulting hash values, plus a 256 MOD 3 = 1

link would be handling an additional hash result value. So the traffic split ratio would be

86:85:85, or approximately 33.6% : 33.2% : 33.2%, much more balanced than 3:2:2.

It is sometimes incorrectly stated that a Port-channel can only operate with two, four,

or eight links. That is incorrect—a Port-channel can operate with any number of links

between one and eight, inclusive. The spreading of total traffic across links can be

uneven, however, if the number of links is not a power of 2, as previously explained.

ptg13046388

Chapter 3: Spanning Tree Protocol 157

Port-Channel Discovery and Configuration

When you are adding multiple ports to a particular Port-channel on a single switch , sev-

eral configuration items must be identical, as follows:

■ Same speed and duplex settings.

■ Same operating mode (trunk, access, dynamic).

■ If not trunking, same access VLAN.

■ If trunking, same trunk type, allowed VLANs, and native VLAN.

■ On a single switch, each port in a Port-channel must have the same STP cost per

VLAN on all links in the Port-channel.

■ No ports can have SPAN configured.

Some of these limitations can change over time—it is recommended to consult the

Configuration Guide for your particular switch platform and IOS version to stay up to

date.

When a new Port-channel is created, an interface Port-channel is automatically added to

the configuration. This interface inherits the configuration of the first physical interface

added to the Port-channel, and the configuration of all other physical interfaces added to

the same Port-channel will be compared to the interface Port-channel configuration. If

they differ, the physical interface will be considered as suspended from the Port-channel,

and it will not become a working member until its configuration is made identical to that

of the Port-channel interface. Configuration changes performed on the interface Port-

channel apply only to nonsuspended member ports; that is, commands applied to the

Port-channel interface are pushed down only to those physical member ports whose con-

figuration matched the interface Port-channel configuration before making the change.

Therefore, reentering the configuration on the Port-channel interface in hopes of unifying

the configuration of all member ports will not have an effect on those ports whose cur-

rent configuration differs from that of the Port-channel interface. It is therefore recom-

mended to adhere to the following guidelines when configuring Port-channels:

■ Do not create the interface Port-channel manually before bundling the physical ports

under it. Let the switch create it and populate its configuration automatically.

■ On the other hand, when removing a Port-channel, make sure to manually remove

the interface Port-channel from the running config so that its configuration does

not cause issues when a Port-channel with the same number is re-created later.

■ Be sure to make the configuration of physical ports identical before adding them to

the same Port-channel.

■ If a physical port’s configuration differs from the interface Port-channel configura-

tion, correct the physical port’s configuration first. Only then proceed to perform

changes to the Port-channel interface configuration.

Key

Topic

Key

Topic

ptg13046388

158 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ A Port-channel interface can either be Layer 2 (switched) or Layer 3 (routed),

depending on whether the physical bundled ports are configured as Layer 2

( switchport ) or Layer 3 ( no switchport ). After a Port-channel has been created with

a particular operating level, it is not possible to change it to the other mode with-

out re-creating it. If it is necessary to change between Layer 2 and Layer 3 levels of

operation, the Port-channel must be removed from configuration and re-created after

the physical ports are reconfigured for the required level of operation. It is possible,

though, to combine the Layer 2 Port-channel on one switch with the Layer 3 Port-

channel on another, although not necessarily a best practice.

■ Whenever resolving an issue with err-disabled ports under a Port-channel interface,

be sure to shut down both the physical interfaces and the interface Port-channel

itself. Only then try to reactivate them. If the problem persists, it is recommended to

remove the Port-channel altogether from the configuration, unbundling the ports as a

result, and re-create the Port-channel.

You can statically configure interfaces to be in a Port-channel by using the channel-

group number mode on interface subcommand. You would simply put the same com-

mand under each of the physical interfaces inside the Port-channel, using the same Port-

channel number. This configuration forces the ports to become members of the same

Port-channel without negotiating with the neighboring switch. This way of creating a

Port-channel is strongly discouraged, though. If one switch considers multiple physical

ports to be bundled under a single Port-channel while the neighboring switch still treats

them as individual or assigns them into several bundles, permanent switching loops can

occur. Also, this static Port-channel configuration is not capable of detecting whether the

bundled ports are all connected to the same neighboring device. Having individual ports

in a single Port-channel connect to different neighboring switches can again lead to per-

manent switching loops. To understand how the switch loop ensues, consider the topol-

ogy shown in Figure 3-16 .

Root

AccessSw

Sec. Root

Root

Port Designated

Port

Designated

Port

Designated

Port

Alternate

Port

Root

Port

Designated

Port

Figure 3-16 Permanent Switching Loop in a Misconfigured EtherChannel

In this topology, the ports on the Secondary Root switch toward AccessSw have already

been bundled in a Port-channel using mode on , and the switch uses them as a single

EtherChannel right away, without negotiating with AccessSw. However, AccessSw is not

yet configured for Port-channel on these ports, and treats them as individual links.

ptg13046388

Chapter 3: Spanning Tree Protocol 159

Because Port-channel interfaces are treated as single ports by STP, only a single BPDU

is sent for the entire Port-channel interface, regardless of how many physical links are

bundled. This BPDU is also subject to the hashing function and forwarded over a single

link in the entire Port-channel bundle. Assuming that the Secondary Root has the sec-

ond-lowest priority in this network and that the BPDUs are forwarded over the left link

toward AccessSw, the corresponding port on AccessSw is Alternate Discarding. However,

the AccessSw port on the right link is not receiving any BPDUs and becomes Designated

Forwarding as a result. Even though such a port sends BPDUs, they will be ignored by

the Secondary Root switch because they are inferior to its own BPDUs. Hence, a perma-

nent switching loop is created. This is also the reason why a switch shuts down all physi-

cal ports when no interface Port-channel is issued—to prevent switching loops when

Port-channel configuration is being removed.

Note that if using RSTP/MST, the Dispute mechanism would detect this problem and put

the Port-channel on the Secondary Root switch to the Discarding state, preventing this

loop. In addition, Cisco has implemented yet another prevention mechanism called STP

EtherChannel Misconfig Guard on its switches. This mechanism makes an assumption

that if multiple ports are correctly bundled into a Port-channel at the neighbor side, all

BPDUs received over links in this Port-channel must have the same source MAC address

in their Ethernet header, as the Port-channel interface inherits the MAC address of one of

its physical member ports. If BPDUs sourced from different MAC addresses are received

on a Port-channel interface, it is an indication that the neighbor is still treating the links

as individual, and the entire Port-channel will be err-disabled. Note that the detection

abilities of the EtherChannel Misconfig Guard are limited. In the topology in Figure 3-16 ,

this mechanism will not help because the Secondary Switch receives just a single BPDU

from AccessSw over the right link, and has no other BPDU to compare the source MAC

address to. The mechanism would be able to detect a problem if, for example, there were

three or more links between Secondary Root and AccessSw, or if the two existing links

were bundled at the AccessSw instead of Secondary Root. The EtherChannel Misconfig

Guard is active by default and can be deactivated using the no spanning-tree etherchan-

nel guard misconfig global configuration command.

It is therefore strongly recommended to use a dynamic negotiation protocol to allow

switches to negotiate the creation of a Port-channel and verify whether the links are eli-

gible for bundling. Those protocols are the Cisco-proprietary Port Aggregation Protocol

(PAgP) and the open IEEE 802.1AX (formerly 802.3ad) Link Aggregation Control

Protocol (LACP) . Both protocols offer relatively similar features though they are mutu-

ally incompatible. On a common Port-channel, both switches must use the same negotia-

tion protocol; different Port-channel interfaces can use different negotiation protocols.

Using LACP is generally preferred because of its open nature and widespread support.

PAgP allows a maximum of eight links in a Port-channel. A switch will refuse to add

more than eight links to a PAgP Port-channel. On current Catalyst switches, PAgP has no

user-configurable parameters apart from the frequency of sending PAgP messages. This

frequency is configurable on a per-port basis using the pagp timer { normal | fast } com-

mand; normal frequency is 30 seconds after the Port-channel is established, and fast is a

Key

Topic

ptg13046388

160 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

1-second frequency. Other available commands related to PAgP have no effect on the for-

warding behavior of the switch, and are kept only for backward compatibility with very

old switches.

With LACP, a maximum of 16 links can be placed into a Port-channel. Out of these links,

at most eight links will be active members of the Port-channel. Remaining links will be

put into a so-called Standby (sometimes also called Hot-Standby) mode. If an active link

fails, one of the Standby links will be used to replace it. A single switch is in charge of

selecting which Standby link will be promoted to the active state—it is the switch with

the lower LACP System ID that consists of a configurable priority and the switch MAC

address (the same concept as in STP). If there are multiple Standby links, the switch in

control will choose the link with the lowest Port ID that again consists of a configurable

priority and the port number. LACP priority of a switch can be globally configured using

the lacp system-priority command, and the priority of a port can be set up using the

lacp port-priority command. Both priorities can be configured in the range of 0–65535.

To dynamically form a Port-channel using PAgP, you still use the channel-group com-

mand, with a mode of auto or desirable . To use LACP to dynamically create a Port-

channel, use a mode of active or passive . Table 3-8 lists and describes the modes and

their meanings.

Table 3-8 PAgP and LACP Configuration Settings and Recommendations

PAgP Setting LACP 802.1AX Setting Action

auto passive Uses PAgP or LACP, but waits on the other

side to send the first PAgP or LACP message

desirable active Uses PAgP or LACP and initiates the

negotiation

Note Using auto (PAgP) or passive (LACP) on both switches prevents a Port-channel

from forming dynamically. Cisco recommends the use of desirable mode (PAgP) or active

mode (LACP) on ports that you intend to be part of a Port-channel on both devices.

As remembering the mode keywords and the protocol they refer to ( desirable / auto for

PAgP; active / passive for LACP) can be awkward, Cisco implemented the helper com-

mand channel-protocol { pagp | lacp } that can be used on physical interfaces to limit

the accepted mode keywords to the stated negotiation protocol. In other words, entering

channel-protocol pagp will allow the subsequent use of desirable or auto modes only;

the active , passive , and on modes will be rejected. Similarly, using channel-protocol lacp

will only permit the subsequent use of active or passive modes; the desirable , auto , and

on modes will be rejected.

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 161

Note A common misunderstanding is that the channel-protocol command can be used in

combination with the on mode to start a particular negotiation protocol. This is incorrect.

The channel-protocol command only causes the CLI to refuse any mode keywords that do

not imply running the chosen negotiation protocol.

When PAgP or LACP negotiate to form a Port-channel, the messages include the

exchange of key information that allows detecting whether all links to be bundled under a

single Port-channel are connected to the same neighbor and whether the neighbor is also

willing to bundle them under a single Port-channel. These values include system IDs of

both interconnected devices, identifiers of physical ports, and aggregation groups these

ports fall under. It is sometimes believed that PAgP and LACP carry detailed information

about individual port settings; that is incorrect. While PAgP and LACP make sure that

the links to be bundled are all connected to the same neighboring switch and that both

switches are willing to bundle them into a common Port-channel, they are neither capable

nor supposed to verify whether ports on opposite sides of bundled links are otherwise

identically configured.

Note PAgP and LACP verify only whether the links to be bundled are consistently con-

nected to the same neighboring device and are to be bundled into the same link aggrega-

tion group. However, neither of these protocols performs checks on whether the ports

on this switch and its neighbor are configured identically with respect to their operating

mode, allowed VLANs, native VLAN, encapsulation, and so on.

When PAgP or LACP completes the process, a new Port-channel interface exists and is

used as if it were a single port for STP purposes, with balancing taking place based on

the global load-balancing method configured on each switch.

Troubleshooting Complex Layer 2 Issues

Troubleshooting is one of the most challenging aspects of CCIE study. The truth is, we

can’t teach you to troubleshoot in the pages of a book; only time and experience bring

strong troubleshooting skills. We can, however, provide you with two things that are

indispensable in learning to troubleshoot effectively and efficiently: process and tools.

The focus of this section is to provide you with a set of Cisco IOS–based tools, beyond

the more common ones that you already know, as well as some guidance on the trouble-

shooting process for Layer 2 issues that you might encounter.

In the CCIE Routing and Switching lab exam, you will encounter an array of trouble-

shooting situations that require you to have mastered fast, efficient, and thorough trou-

bleshooting skills. In the written exam, you’ll need a different set of skills—mainly, the

knowledge of troubleshooting techniques that are specific to Cisco routers and switches,

and the ability to interpret the output of various show commands and possibly debug

output. You can also expect to be given an example along with a problem statement. You

ptg13046388

162 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

will need to quickly narrow the question down to possible solutions and then pinpoint

the final solution. This requires a different set of skills than what the lab exam requires,

but spending time on fundamentals as you prepare for the qualification exam will provide

a good foundation for the lab exam environment.

As in all CCIE exams, you should expect that the easiest or most direct ways to a solu-

tion might be unavailable to you. In troubleshooting, perhaps the easiest way to the

source of most problems is through the show run command or variations on it. Therefore,

we’ll institute a simple “no show run ” rule in this section that will force you to use your

knowledge of more in-depth troubleshooting commands in the Cisco IOS portion of this

section.

In addition, you can expect that the issues you’ll face in this part of the written exam will

need more than one command or step to isolate and resolve.

Layer 2 Troubleshooting Process

From the standpoint of troubleshooting techniques, two basic stack-based approaches

come into play depending on what type of issue you’re facing. The first of these is the

climb-the-stack (or bottom-up) approach, where you begin at Layer 1 and work your

way up until you find the problem. Alternatively, you can start at Layer 7 and work your

way down in a top-down approach; however, in the context of the CCIE Routing and

Switching exams, the climb-the-stack approach generally makes more sense.

Another approach is often referred to as the divide-and-conquer method. With this tech-

nique, you start in the middle of the stack (usually where you see the problem) and work

your way down or up the stack from there until you find the problem. In the interest of

time, which is paramount in an exam environment, the divide-and-conquer approach usu-

ally provides the best results. Because this section deals with Layer 2 issues, it starts at

the bottom and works up.

Some lower-level issues that might affect Layer 2 connectivity include the following:

■ Cabling: Check the physical soundness of the cable as well as the use of a cor-

rectly pinned cable. If the switch does not support Automatic Medium-Dependent

Interface Crossover (Auto-MDIX), the correct choice of either crossover or straight-

through cable must be made. On many Catalyst platforms (not all, though), configur-

ing both speed and duplex statically on a port results in autonegotiation including

Auto-MDIX to be deactivated on that port. That can lead both to duplex mis-

matches and to a link going down if the cable required the port to perform automatic

crossover.

■ Speed or duplex mismatch: Most Cisco devices will correctly sense speed and

duplex when both sides of the link are set to Auto, but a mismatch can cause the line

protocol on the link to stay down.

■ Device physical interface: It is possible for a physical port to break.

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 163

Layer 2 Protocol Troubleshooting and Commands

In addition to the protocol-specific troubleshooting commands that you have learned so

far, this section addresses commands that can help you isolate problems through a solid

understanding of the information they present. We will use a variety of examples of com-

mand output to illustrate the key parameters you should understand.

Troubleshooting Using Cisco Discovery Protocol

Cisco Discovery Protocol (CDP) is a proprietary protocol that is used to help adminis-

trators collect information about neighboring Cisco devices. CDP makes it possible to

gather hardware and protocol information about neighbor devices, which is useful infor-

mation for troubleshooting or network discovery.

CDP messages are generated every 60 seconds as Layer 2 multicast messages on each

of a device’s active interfaces. The information shared in a CDP packet about a device

includes, but is not limited to, the following:

■ Name of the device configured with the hostname command

■ IOS software version

■ Hardware capabilities, such as routing, switching, and/or bridging

■ Hardware platform, such as 2800, 2960, or 1900

■ The Layer 3 address(es) of the device

■ The interface that the CDP update was generated on

■ Duplex setting of the interface that CDP was generated on

■ VTP domain of the device if relevant

■ Native VLAN of the sending port if relevant

CDP enables devices to share basic configuration information without even configuring

any protocol-specific information and is enabled by default on all common interfaces

(CDP might be deactivated on less typical interfaces such as Virtual-Template or multi-

point Frame Relay). CDP is a Data Link Layer utility found in IOS that resides at Layer 2

of the OSI model; as such, CDP is not routable and can only operate over directly con-

nected interfaces. As a general rule, CDP is active by default on devices.

CDP updates are generated every 60 seconds with a hold-down period of 180 seconds

for a missing neighbor. The no cdp run command globally disables CDP, while the no

cdp enable command disables CDP on an interface. Disabling CDP globally and enabling

it on individual interfaces is not possible. We can use the show cdp neighbors command

to list any directly connected Cisco neighboring devices. Additionally, we can use the

detail keyword to display detailed information about the neighbor, including its Layer 3

addressing.

ptg13046388

164 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 3-3 shows the CDP timer, which is how often CDP packets are sent, and the

CDP holdtime, which is the amount of time that the device will hold packets from neigh-

bor devices.

Example 3-3 CDP Timers

Router_2# show cdp

Global CDP information:

Sending CDP packets every 60 seconds

Sending a holdtime value of 180 seconds

Example 3-4 shows how we can use the following commands to set CDP timer and hold-

time values to something other than the defaults.

Example 3-4 Adjusting CDP Timers

Router_2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

Router_2(config)# cdp timer 90

Router_2(config)# cdp holdtime 360

CDP can be disabled with the no cdp run command in global configuration mode.

Because a device stores the CDP information in its runtime memory, you can view it

with a show command. It will only show information about directly connected devices

because CDP packets are not passed through Cisco devices. Example 3-5 shows such

output.

Example 3-5 CDP Verification Commands

Router_2# show cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater

Device ID Local Intrfce Holdtme Capability Platform Port ID

Router3 Ser 1 120 R 2500 Ser 0

Router1 Eth 1 180 R 2500 Eth 0

Switch1 Eth 0 240 S 1900 2

! CDP Neighbor Information includes

! Neighbor's device ID

! Local port type and number

! Holdtime value (in seconds)

! Neighbor's network device capability

! Neighbor's hardware platform

! Neighbor's remote port type and number

! In addition to this we can employ the show cdp entry device-id

! command to show more information about a specified neighbor.

ptg13046388

Chapter 3: Spanning Tree Protocol 165

Router_2# show cdp entry Router1

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

Device ID: Router1

Entry address(es):

IP address: 192.168.1.2

Platform: cisco 2500, Capabilities: Router

Interface: Ethernet1, Port ID (outgoing port): Ethernet0

Holdtime : 180 sec

Version:

Cisco Internetwork Operating System Software

IOS (tm) 2500 Software (2500-JS-L), Version 11.2(15)

RELEASED SOFTWARE (fcl)

Compiled Mon 06-Jul-98 22:22 by tmullins

! The following is a sample output for one neighbor from the show cdp neighbors

! detail command. Additional detail is shown about neighbors, including network

! address, enabled protocols, and software version.

Router_2# show cdp neighbors detail

Device ID: 008024 1EEB00 (milan-sw-1-cat9k)

Entry address(es):

IP address: 1.15.28.10

Platform: CAT5000, Capabilities: Switch

Interface: Ethernet1/0, Port ID (outgoing port): 2/7

Holdtime : 162 sec

Version :

Cisco Catalyst 5000

Duplex Mode: full

Native VLAN: 42

VTP Management Domain: 'Accounting Group'

Troubleshooting Using Link Layer Discovery Protocol

Where Cisco Discovery Protocol (CDP) is a device discovery protocol that runs over

Layer 2 on all Cisco-manufactured devices (routers, bridges, access servers, and switches)

that allows network management applications to automatically discover and learn about

other Cisco devices connected to the network, we have to ask the question, “What hap-

pens if we have to work with non-Cisco equipment?”

ptg13046388

166 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

To support non-Cisco devices and to allow for interoperability between other devices,

IOS also supports the IEEE 802.1AB Link Layer Discovery Protocol (LLDP). LLDP is a

neighbor discovery protocol similar to CDP 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 attri-

butes 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.

The switch supports these basic management TLVs. These are mandatory LLDP TLVs:

■ Port description TLV

■ System name TLV

■ System description TLV

■ System capabilities TLV

■ Management address TLV

Similar to CDP, configuration on a Cisco device can be made in the global or interface

mode.

Example 3-6 shows how to globally enable LLDP and to manipulate its configuration.

Example 3-6 LLDP Configuration and Verification

! This example shows how to enable LLDP. First, LLDP must be

! activated globally. Then, instead of having a single

! enable keyword similar to cdp enable , LLDP has lldp transmit and lldp receive

! commands. By default, they are both set, so a port automatically sends and

! receives LLDP messages. The following example shows the use of the commands.

Switch# configure terminal

Switch(config)# lldp run

Switch(config)# interface fa0/1

Switch(config-if)# lldp transmit

Switch(config-if)# lldp receive

Switch(config-if)# end

! You can configure the frequency of LLDP updates, the amount of time to hold the

! information before discarding it, and the initialization delay time.

ptg13046388

Chapter 3: Spanning Tree Protocol 167

Switch# configure terminal

Switch(config)# lldp holdtime 120

Switch(config)# lldp reinit 2

Switch(config)# lldp timer 30

Switch(config)# end

Troubleshooting Using Basic Interface Statistics

The show interfaces command is a good place to start troubleshooting interface issues.

It will tell you whether the interface has a physical connection and whether it was able to

form a logical connection. The link duplex and bandwidth are shown, along with errors

and collisions. Example 3-7 shows output from this command, with important statistics

highlighted.

Example 3-7 Troubleshooting with the show interface Command

! Shows a physical and logical connection

SW4# show int fa0/21

FastEthernet0/21 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 001b.d4b3.8717 (bia 001b.d4b3.8717)

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keep alive set (10 sec)

! Negotiated or configured speed and duplex

Full-duplex, 100Mb/s, media type is 10/100BaseTX

input flow-control is off, output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:01, output 00:00:08, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

16206564 packets input, 1124307496 bytes, 0 no buffer

Received 14953512 broadcasts (7428112 multicasts)

! CRC errors, runts, frames, collisions or late collisions

! may indicate a duplex mismatch

0 runts, 0 giants, 0 throttles

ptg13046388

168 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 7428112 multicast, 0 pause input

0 input packets with dribble condition detected

2296477 packets output, 228824856 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

If an interface shows as up/up, you know that a physical and logical connection has

been made, and you can move on up the stack in troubleshooting. If it shows as up/

down, you have some Layer 2 troubleshooting to do. An interface status of err-disable

could be caused by many different problems, some of which are discussed in this chap-

ter. Common causes include a security violation or detection of a unidirectional link.

Occasionally, a duplex mismatch will cause this state.

Chapter 1, “Ethernet Basics,” showed examples of a duplex mismatch, but the topic is

important enough to include here. Duplex mismatch might be caused by hard-coding

one side of the link to full duplex but leaving the other side to autonegotiate duplex. A

10/100 interface will default to half duplex if the other side is 10/100 and does not nego-

tiate. It could also be caused by an incorrect manual configuration on both sides of the

link. A duplex mismatch usually does not bring the link down; it just creates suboptimal

performance by causing collisions.

You would suspect a duplex mismatch if you saw collisions on a link that should be capa-

ble of full duplex, because a full-duplex link should by definition never have collisions.

A link that is half duplex on both sides will show some interface errors. But more than

about 1 percent to 2 percent of the total traffic is cause for a second look. Watch for the

following types of errors:

■ Runts: Runts are frames smaller than 64 bytes.

■ CRC errors: The frame’s cyclic redundancy checksum value does not match the one

calculated by the switch or router.

■ Frames: Frame errors have a CRC error and contain a noninteger number of octets.

■ Alignment: Alignment errors have a CRC error and an odd number of octets.

■ Collisions: Look for collisions on a full-duplex interface (meaning that the interface

operated in half-duplex mode at some point in the past), or excessive collisions on a

half-duplex interface.

■ Late collisions on a half-duplex interface: A late collision occurs after the first 64

bytes of a frame.

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 169

Another command to display helpful interface statistics is show controllers , shown in

Example 3-8 . The very long output from this command is another place to find the num-

ber of frames with bad frame checks, CRC errors, collisions, and late collisions. In addi-

tion, it tells you the size breakdown of frames received and transmitted. A preponderance

of one-size frames on an interface that is performing poorly can be a clue to the applica-

tion sending the frames. Another useful source of information is the interface autonegoti-

ation status and the speed/duplex capabilities of it and its neighbor, shown at the bottom

of Example 3-8 .

Example 3-8 Troubleshooting with the show controllers Command

R1# show controllers fastEthernet 0/0

Interface FastEthernet0/0

Hardware is MV96340

HWIDB: 46F92948, INSTANCE: 46F939F0, FASTSEND: 4374CB14, MCI_INDEX: 0

Aggregate MIB Counters

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

Rx Good Bytes: 27658728 Rx Good Frames: 398637

Rx Bad Bytes: 0 Rx Bad Frames: 0

Rx Broadcast Frames: 185810 Rx Multicast Frames: 181353

Tx Good Bytes: 3869662 Tx Good Frames: 36667

Tx Broadcast Frames: 0 Tx Multicast Frames: 5684

Rx+Tx Min-64B Frames: 412313 Rx+Tx 65-127B Frames: 12658

Rx+Tx 128-255B Frames: 0 Rx+Tx 256-511B Frames: 10333

Rx+Tx 512-1023B Frames: 0 Rx+Tx 1024-MaxB Frames: 0

Rx Unrecog MAC Ctrl Frames: 0

Rx Good FC Frames: 0 Rx Bad FC Frames: 0

Rx Undersize Frames: 0 Rx Fragment Frames: 0

Rx Oversize Frames: 0 Rx Jabber Frames: 0

Rx MAC Errors: 0 Rx Bad CRCs: 0

Tx Collisions: 0 Tx Late Collisions: 0

! [output omitted]

AUTONEG_EN

PHY Status (0x01):

AUTONEG_DONE LINK_UP

Auto-Negotiation Advertisement (0x04):

100FD 100HD 10FD 10HD

Link Partner Ability (0x05):

100FD 100HD 10FD 10HD

! output omitted

ptg13046388

170 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Troubleshooting Spanning Tree Protocol

Spanning-tree issues are possible in a network that has not been properly configured.

Previous sections of this chapter discussed ways to secure STP. One common STP prob-

lem is a change in the root bridge. If the root bridge is not deterministically configured,

a change in the root can affect network connectivity. To lessen the chance of this, use

Rapid STP and all the tools necessary to secure the root and user ports. Example 3-1

showed commands to check the root bridge and other STP parameters, including the fol-

lowing:

show spanning-tree [ vlan number ] root [ detail | priority [

system-id ] ]

Keep in mind that when BPDU Guard is enabled, a port is error-disabled if it receives a

BPDU. You can check this with the show interfaces status err-disabled command. In

addition, switching loops can result if the spanning-tree portfast trunk command is

enabled on a trunk port toward another switch, or an interface has a duplex mismatch.

One symptom of a loop is flapping MAC addresses. A port protected by Root Guard

is put in a root-inconsistent state if it tries to become a Root Port: a Root and Alternate

Port with Loop Guard configured is put in a loop-inconsistent state if it stops receiving

BPDUs. You can check this with the show spanning-tree inconsistent ports command.

Whether an interface is error-disabled or put into an inconsistent state, the port is effec-

tively shut down to user traffic.

Cisco STP implementation recognizes many kinds of port inconsistencies. Table 3-9 sum-

marizes them and the reasons causing them.

Table 3-9 Types of STP Inconsistencies and Their Causes

Inconsistency Type Description and Probable Cause of Inconsistency

Type

(*TYPE_Inc)

PVST+ BPDUs are received on a non-802.1Q port. Usually caused

by interconnecting access and trunk ports.

Port VLAN ID

(*PVID_Inc)

PVST+ BPDUs are received in a different VLAN than they were

originated in. Usually caused by native VLAN mismatch on a trunk.

PVST Simulation

(*PVST_Inc)

PVST+ BPDUs received on an MST boundary port do not meet the

PVST Simulation consistency criteria.

Loop

(*LOOP_Inc)

A Root or Alternate Port tried to become Designated after BPDUs

stopped arriving. Seen only on Loop Guard–protected ports.

Root

(*ROOT_Inc)

A port tried to become a Root Port after receiving superior BPDUs.

Seen only on Root Guard-protected ports. Also, on older switches,

this state was displayed in place of the PVST_Inc state if PVST

Simulation Inconsistency was encountered on a port.

Bridge Assurance

(*BA_Inc)

A port stopped receiving BPDUs. Seen only on Bridge Assurance–

protected ports.

Key

Topic

ptg13046388

Chapter 3: Spanning Tree Protocol 171

Troubleshooting Trunking

Trunks that fail to form can result from several causes. With an 802.1Q trunk, a native

VLAN mismatch is usually the first thing troubleshooters look at. You should addition-

ally check the Dynamic Trunking Protocol (DTP) negotiation mode of each side of the

trunk. Table 2-9 in Chapter 2 , “Virtual LANs and VLAN Trunking,” lists the combinations

of DTP configurations that will lead to successful trunking.

A VLAN Trunking Protocol (VTP) domain mismatch has been known to prevent trunk

formation, even in switches that are in VTP Transparent mode, because the VTP domain

name is carried in DTP messages. The switch’s logging output will help you greatly. This

is shown in Example 3-9 , along with some commands that will help you troubleshoot

trunking problems. In Example 3-9 , two switches are configured with 802.1Q native

VLANs 10 and 99, and DTP mode desirable. Both are VTP transparent and have different

VTP domain names. Some output irrelevant to the example is omitted.

Example 3-9 Troubleshooting Trunking

! These errors messages were logged by the switch

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet1/0/21

(10), with sw4 FastEthernet0/21 (99)

%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 99 on

FastEthernet1/0/21 VLAN10

%DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa1/0/21 because

of VTP domain mismatch.

! This command shows that the port is configured to trunk

! (Administrative Mode) but is not performing as a trunk

! (Operational Mode)

SW2# show int fa 1/0/1 switchport

Name: Fa1/0/1

Switchport: Enabled

Administrative Mode: dynamic desirable

Operational Mode: static access

Administrative Trunking Encapsulation: negotiate

Operational Trunking Encapsulation: native

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 10 (NATIVE_10)

Administrative Native VLAN tagging: enabled

! output omitted

! Trunking VLANs Enabled: 3,99

! The port is shown as inconsistent due to native VLAN mismatch

ptg13046388

172 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

SW4# show spanning-tree inconsistentports

Name Interface Inconsistency

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

VLAN0099 FastEthernet0/21 Port VLAN ID Mismatch

Number of inconsistent ports (segments) in the system : 1

! Once the errors are corrected, the interface shows as a trunk

SW4# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Fa0/21 desirable 802.1q trunking 99

! Output omitted

If your trunks are connected and operating, but user connectivity is not working, check

the VLANs allowed on each trunk. Make sure that the allowed VLANs match on each

side of the trunk, and that the users’ VLAN is on the allowed list (assuming that it should

be). Either look at the interface configuration or use the show interfaces trunk and show

interfaces switchport commands shown in Example 3-9 to find that information.

Troubleshooting VTP

If you choose to use anything other than VTP Transparent mode in your network, you

should be aware of the ways to break it. VTP will fail to negotiate a neighbor status if the

following items do not match:

■ VTP version

■ VTP domain

■ VTP password

In addition, recall that VTP runs over trunk links only, so you must have an operational

trunk before expecting VTP to act. To prevent your VLAN database from being altered

when adding a VTPv1 or VTPv2 switch to the VTP domain, follow these steps:

Step 1. Change the VTP mode to Transparent, which will reset the configuration revi-

sion number to 0.

Step 2. Configure the remaining appropriate VTP parameters.

Step 3. Configure trunking.

Step 4. Connect the switch to the network.

VTPv3 prevents a switch, even with a higher revision number, from asserting its database

over other switches if its idea of who is the primary server differs from that of its

neighbors.

The first part of Example 3-10 shows a VTP client with a password that doesn’t match

its neighbor (note the error message). The switch does not show an IP address in the last

ptg13046388

Chapter 3: Spanning Tree Protocol 173

line because it has not been able to negotiate a VTP relationship with its neighbor. In the

second part of the example, the configuration has been corrected. Now the neighbor’s IP

address is listed as the VTP updater.

Example 3-10 Troubleshooting VTP

! Wrong password is configured

SW4# show vtp status

VTP Version : running VTP1 (VTP2 capable)

Configuration Revision : 0

Maximum VLANs supported locally : 1005

Number of existing VLANs : 5

VTP Operating Mode : Client

VTP Domain Name : CCIE

VTP Pruning Mode : Disabled

VTP V2 Mode : Disabled

VTP Traps Generation : Disabled

MD5 digest : 0xA1 0x7C 0xE8 0x7E 0x4C 0xF5 0xE3 0xC8

*** MD5 digest checksum mismatch on trunk: Fa0/23 ***

*** MD5 digest checksum mismatch on trunk: Fa0/24 ***

Configuration last modified by 0.0.0.0 at 7-24-09 03:12:27

! On some IOS versions, a message about MD5 digest failing is not displayed.

! In these cases, using debug sw-vlan vtp events may be helpful - look for output

! similar to this:

*Jul 24 11:01:42.558: VTP LOG RUNTIME: MD5 digest failing

calculated = D7 17 28 01 4E 1D E6 65 67 0A 9D 73 71 EA 5A 5C

transmitted = C2 93 A7 15 E5 0C 0B 9D DD 24 BB ED 18 4C 97 45

! Command output after the misconfiguration was corrected

SW4# show vtp status

VTP Version : running VTP2

Configuration Revision : 5

Maximum VLANs supported locally : 1005

Number of existing VLANs : 9

VTP Operating Mode : Client

VTP Domain Name : CCIE

VTP Pruning Mode : Disabled

VTP V2 Mode : Enabled

VTP Traps Generation : Disabled

MD5 digest : 0xDD 0x6C 0x64 0xF5 0xD2 0xFE 0x9B 0x62

Configuration last modified by 192.168.250.254 at 7-24-09 11:02:43

ptg13046388

174 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Troubleshooting EtherChannels

Table 3-8 listed the LACP and PAgP settings. If your EtherChannel is not coming up,

check these settings. If you are using LACP, at least one side of each link must be set to

active . If you are using PAgP, at least one side of the link must be set to desirable . If you

are not using a channel negotiation protocol, make sure that both sides of the links are

set to on .

Remember that the following rules apply to all ports within an EtherChannel:

■ Speed and duplex must match.

■ Interface type—access, trunk, or routed—must match.

■ Trunk configuration—encapsulation, allowed VLANs, native VLAN, and DTP

mode—must match.

■ If a Layer 2 EtherChannel is not a trunk, all ports must be assigned to the same

VLAN.

■ No port in the EtherChannel can be a Switched Port Analyzer (SPAN) port.

■ On a Layer 3 EtherChannel, the IP address must be on the Port-channel interface,

not a physical interface.

To troubleshoot an EtherChannel problem, check all the parameters in the preceding list.

Example 3-11 shows some commands to verify the logical and physical port configura-

tion for an EtherChannel. QoS configuration must match and must be configured on the

physical ports, not the logical one.

Example 3-11 Troubleshooting EtherChannels

! The show etherchannel summary command gives an overview of the

! channels configured, whether they are Layer 2 or Layer 3, the

! interfaces assigned to each, and the protocol used if any

L3SW4# 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: 3

ptg13046388

Chapter 3: Spanning Tree Protocol 175

Number of aggregators: 3

Group Port-channel Protocol Ports

------+-------------+---------+-------------------------------------------

14 Po14(SU) LACP Fa0/3(P)

24 Po24(RU) - Fa0/7(P) Fa0/8(P) Fa0/9(P) Fa0/10(P)

34 Po34(RU) PAgP Fa0/1(P) Fa0/2(P)

! The show interface etherchannel command lets you verify that the

! interface is configured with the right channel group and

! protocol settings

L3SW3# show int fa0/1 etherchannel

Port state = Up Mstr In-Bndl

Channel group = 34 Mode = On Gcchange = -

Port-channel = Po34 GC = - Pseudo port-channel = Po34

Port index = 0 Load = 0x00 Protocol = PAgP

Age of the port in the current state: 1d:07h:28m:19s

! The show interface portchannel command produces output similar

! to a physical interface. It allows you to verify the ports

! assigned to the channel and the type of QoS used

L3SW3# show int port-channel 23

Port-channel23 is up, line protocol is up (connected)

Hardware is EtherChannel, address is 001f.2721.8643 (bia 001f.2721.8643)

Internet address is 10.1.253.13/30

MTU 1500 bytes, BW 200000 Kbit, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, link type is auto, media type is unknown

input flow-control is off, output flow-control is unsupported

Members in this channel: Fa0/3 Fa0/4

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:02, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Approaches to Resolving Layer 2 Issues

Table 3-10 presents some generalized types of Layer 2 issues and ways of approaching

them, including the relevant Cisco IOS commands.

ptg13046388

176 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 3-10 Layer 2 Troubleshooting Approach and Commands

Problem Approach Helpful IOS Commands

Lack of reachability

to devices in the same

VLAN

Eliminate Layer 1 issues with

show interface commands.

Verify that the VLAN exists

on the switch.

Verify that the interface

is assigned to the correct

VLAN.

Verify that the VLAN is

allowed on the trunk.

show interface

show vlan

show interface switchport

traceroute mac source-mac

destination-mac

show interface trunk

Intermittent reachability

to devices in the same

VLAN

Check for excessive interface

traffic.

Check for unidirectional

links.

Check for spanning-tree

problems such as BPDU

floods or flapping MAC

addresses.

show interface

show spanning-tree

show spanning-tree root

show mac address-table

No connectivity between

switches

Check for interfaces that are

shut down.

Verify that trunk links and

EtherChannels are active.

Verify that BPDU Guard

is not enabled on a trunk

interface.

show interfaces status err-

disabled

show interfaces trunk

show etherchannel summary

show spanning-tree detail

Poor performance across

a link

Check for a duplex

mismatch.

show interface

In summary, when troubleshooting Layer 2 issues, check for interface physical problems

or configuration mismatches. Verify that STP is working as expected. If you are using

VTP, make sure that it is configured properly on each switch. For trunking problems,

check native VLAN and DTP configuration. When troubleshooting port channels, verify

that the interface parameters are the same on both sides.

ptg13046388

Chapter 3: Spanning Tree Protocol 177

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter, as well as review items noted with a Key Topic icon.

Table 3-11 lists the protocols mentioned in this chapter and their respective standards

documents.

Table 3-11 Protocols and Standards for Chapter 3

Name Standards Body

RSTP IEEE 802.1D (formerly 802.1w)

MST IEEE 802.1Q (formerly 802.1s)

STP Formerly IEEE 802.1D

LACP IEEE 802.1AX (formerly 802.3AD)

Dot1Q trunking IEEE 802.1Q

PVST+ Cisco

RPVST+ Cisco

PAgP Cisco

Table 3-12 lists the three key timers that impact STP convergence.

Table 3-12 IEEE 802.1D STP Timers

Timer Default Purpose

Hello 2 sec Interval at which the root sends Configuration BPDUs

Forward Delay 15 sec Time that switch leaves a port in the Listening state and the

Learning state; also used as the short CAM timeout timer

MaxAge 20 sec Time without hearing a Hello before expiring the stored BPDU

Table 3-13 lists some of the key IOS commands related to the topics in this chapter.

The command syntax for switch commands was taken from the Catalyst 3560 Switch

Command Reference, 15.0(2)SE .

ptg13046388

178 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 3-13 Command Reference for Chapter 3

Command Description

spanning-tree mode { mst | pvst |

rapid-pvst }

Global config command that sets the STP mode.

[ no ] spanning-tree vlan vlan-id Enables or disables STP inside a particular VLAN

when using PVST+ or RPVST+ .

spanning-tree vlan vlan-id { forward-

time seconds | hello-time seconds | max-

age seconds | priority priority | { root

{ primary | secondary } [ diameter net-

diameter [ hello-time seconds ]]}}

Global config command to set a variety of STP

parameters when using PVST+ or RPVST+.

spanning-tree [ vlan x | mst x ] cost y Interface subcommand used to set interface

costs, per VLAN. If the vlan or mst keyword

is omitted, applies to all unspecified VLANs or

MST instances.

spanning-tree [ vlan x | mst x ] port-

priority y

Interface subcommand used to set port priority,

per VLAN. If the vlan or mst keyword is

omitted, applies to all unspecified VLANs or

MST instances.

channel-group channel-group-number

mode { auto [ non-silent ] | desirable

[ non-silent ] | on | active | passive }

Interface subcommand that places the interface

into a Port-channel, and sets the negotiation

parameters.

channel-protocol { lacp | pagp } Interface subcommand to define which

protocol to allow to configure for EtherChannel

negotiation.

interface port-channel port - channel-

number

Global command that allows entering the logical

interface representing the Port-channel bundle.

spanning-tree portfast [ trunk ] Interface subcommand that enables PortFast on

the interface.

spanning-tree bpduguard {enable |

disable}

Interface command that enables or disables

BPDU Guard on the interface.

spanning-tree mst instance-id priority

priority

Global command used to set the priority of an

MST instance.

spanning-tree mst configuration Global command that puts the user in MST

configuration mode.

show spanning-tree bridge | root | brief

| summary

EXEC command to show various details about

STP operation.

show interfaces Displays Layer 1 and 2 information about an

interface.

show interfaces trunk Displays the interface trunk configuration.

show etherchannel [summary] Lists EtherChannels configured and their status.

ptg13046388

Chapter 3: Spanning Tree Protocol 179

Command Description

show interfaces switchport Displays the interface trunking and VLAN

configuration.

show vtp status Displays the VTP configuration.

show controllers Displays physical interface characteristics as well

as traffic and error types.

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Fill in Key Tables from Memory

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD to check your answers.

Definitions

Next, take a few moments to write down the definitions for the following terms:

CST, CIST, STP, MST, RSTP, Hello timer, MaxAge timer, ForwardDelay timer,

Blocking state, Forwarding state, Listening state, Learning state, Disabled state,

Alternate role, Discarding state, Backup role, Root Port, Designated Port, superior

BPDU, inferior BPDU, PVST+, RPVST+, PortFast, Root Guard, BPDU Guard, UDLD,

Loop Guard, LACP, PAgP

Refer to the glossary to check your answers.

Further Reading

The topics in this chapter tend to be covered in slightly more detail in CCNP Switching

exam preparation books. For more details on these topics, refer to the Cisco Press CCNP

preparation books found at www.ciscopress.com/ccnp .

Cisco LAN Switching , by Kennedy Clark and Kevin Hamilton, covers STP logic and

operations in detail.

More details about UDLD can be found in RFC 5171 and in U.S. Patent No. 7,480,251.

ptg13046388

180 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Cisco.com has an unusually extensive set of high-quality documents covering selected

topics from this chapter. Instead of posting the URLs that can change over time, fol-

lowing is Table 3-14 of selected documents’ names and Document ID numbers you can

use in the Search function to locate the appropriate document. So, for example, when

looking for “Understanding Spanning Tree Protocol Topology Changes,” type the string

“Document ID 12013” in the Search box on the Cisco website. If “PDF” is indicated

instead of a numerical Document ID, the document has no Document ID and must be

searched for only using its name. Some of the documents cover topics that are outdated

and/or have been dropped from the current exam blueprint but which are nevertheless

worth reading to reinforce your understanding. Most of the indicated documents are a

must-read, though.

Table 3-14 Recommended Further Reading at Cisco.com

Document Name Document ID

Understanding Spanning-Tree Protocol Topology Changes 12013

VLAN Load Balancing Between Trunks Using the Spanning-Tree

Protocol Port Priority

10555

Understanding and Tuning Spanning Tree Protocol Timers 19120

Understanding and Configuring the Cisco UplinkFast Feature 10575

Understanding and Configuring Backbone Fast on Catalyst

Switches

12014

Understanding Rapid Spanning Tree Protocol (802.1w) 24062

Understanding Multiple Spanning Tree Protocol (802.1s) 24248

PVST Simulation on MST Switches 116464

Using PortFast and Other Commands to Fix Workstation Startup

Connectivity Delays

10553

Spanning Tree PortFast BPDU Guard Enhancement 10586

Spanning Tree Protocol Root Guard Enhancement 10588

Spanning-Tree Protocol Enhancements using Loop Guard and

BPDU Skew Detection Features

10596

Understanding and Configuring the Unidirectional Link

Detection Protocol Feature

10591

Spanning Tree from PVST+ to Rapid-PVST Migration

Configuration Example

72836

Configuration Example to Migrate Spanning Tree from PVST+ to

MST

72844

Cisco AVVID Network Infrastructure: Implementing 802.1w and

802.1s in Campus Networks

PDF

ptg13046388

Chapter 3: Spanning Tree Protocol 181

Document Name Document ID

Best Practices for Catalyst 6500/6000 Series and Catalyst

4500/4000 Series Switches Running Cisco IOS Software

24330

Troubleshooting Transparent Bridging Environments 10543

Troubleshooting LAN Switching Environments 12006

Spanning Tree Protocol Problems and Related Design

Considerations

10556

Troubleshooting STP on Catalyst Switches Running Cisco IOS

System Software

28943

Troubleshooting Spanning Tree PVID- and Type-Inconsistencies 24063

Understanding EtherChannel Load Balancing and Redundancy on

Catalyst Switches

12023

Understanding EtherChannel Inconsistency Detection 20625

Catalyst 6500, 4500, and 3750 Series Switches EtherChannel

Load-Balancing

116385

Errdisable Port State Recovery on the Cisco IOS Platforms 69980

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ IP Operation

■ TCP Operation

■ UDP Operation

■ IPv4 Addressing

■ IPv4 Subnetting

■ IPv4 VLSM

■ Route Summarization

■ N A T

■ IPv6 Addressing

■ IPv6 Subnetting

■ Migrating from IPv4 to IPv6

ptg13046388

Complete mastery of IP addressing and subnetting is required for any candidate to have

a reasonable chance at passing both the CCIE written and lab exam. In fact, even the

CCNA exam has fairly rigorous coverage of IP addressing and the related protocols. For

the CCIE exam, understanding these topics is required to answer much deeper questions.

For example, a question might ask for the interpretation of the output of a show ip bgp

command and a configuration snippet to decide what routes would be summarized into

a new prefix. To answer such questions, you must be familiar with the basic concepts and

math behind subnetting .

“Do I Know This Already?” Quiz

Table 4-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 4-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in This Section Score

IP Addressing and Subnetting 1–4

CIDR, Private Addresses, and NAT 5–8

IPv6 Addressing and Tunneling 9–11

Total Score

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. In what subnet does address 192.168.23.197/27 reside?

a. 192.168.23.0

b. 192.168.23.128

c. 192.168.23.160

d. 192.168.23.192

e. 192.168.23.196

CHAPTER 4

IP Addressing

ptg13046388

184 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

2. Router1 has four LAN interfaces, with IP addresses 10.1.1.1/24, 10.1.2.1/24,

10.1.3.1/24, and 10.1.4.1/24. What is the smallest summary route that could be adver-

tised out a WAN link connecting Router1 to the rest of the network, if subnets not

listed here were allowed to be included in the summary?

a. 10.1.2.0/22

b. 10.1.0.0/22

c. 10.1.0.0/21

d. 10.1.0.0/16

3. Router1 has four LAN interfaces, with IP addresses 10.22.14.1/23, 10.22.18.1/23,

10.22.12.1/23, and 10.22.16.1/23. Which one of the answers lists the smallest sum-

mary route(s) that could be advertised by Router1 without also including subnets not

listed in this question?

a. 10.22.12.0/21

b. 10.22.8.0/21

c. 10.22.8.0/21 and 10.22.16.0/21

d. 10.22.12.0/22 and 10.22.16.0/22

4. Which two of the following VLSM subnets, when taken as a pair, overlap?

a. 10.22.21.128/26

b. 10.22.22.128/26

c. 10.22.22.0/27

d. 10.22.20.0/23

e. 10.22.16.0/22

5. Which of the following protocols or tools includes a feature like route summariza-

tion, plus administrative rules for global address assignment, with a goal of reducing

the size of Internet routing tables?

a. Classless interdomain routing

b. Route summarization

c. Supernetting

d. Private IP addressing

ptg13046388

Chapter 4: IP Addressing 185

6. Which of the following terms refer to a NAT feature that allows for significantly

fewer IP addresses in the enterprise network as compared with the required public

registered IP addresses?

a. Static NAT

b. Dynamic NAT

c. Dynamic NAT with overloading

d. P A T

e. VA T

7. Consider an enterprise network using private class A network 10.0.0.0, and using

NAT to translate to IP addresses in registered class C network 205.1.1.0. Host 10.1.1.1

has an open www session to Internet web server 198.133.219.25. Which of the fol-

lowing terms refers to the destination address of a packet, sent by the web server

back to the client, when the packet has not yet made it back to the enterprise’s NAT

router?

a. Inside Local

b. Inside Global

c. Outside Local

d. Outside Global

8. Router1 has its fa0/0 interface, address 10.1.2.3/24, connected to an enterprise net-

work. Router1’s S0/1 interface connects to an ISP, with the interface using a publicly

registered IP address of 171.1.1.1/30. Which of the following commands could be

part of a valid NAT overload configuration, with 171.1.1.1 used as the public IP

address?

a. ip nat inside source list 1 int s0/1 overload

b. ip nat inside source list 1 pool fred overload

c. ip nat inside source list 1 171.1.1.1 overload

d. None of the answers are correct.

9. What feature is built into the IPv6 protocol to facilitate intranet-wide address man-

agement that enables a large number of IP hosts to easily discover the network and

get new and globally unique IPv6 addresses associated with their location?

a. ISATAP

b. Address autoconfiguration

c. Interface Overload

d. None of the answers are correct.

ptg13046388

186 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

10. What IPv6 transition strategy involves configuring devices to be able to run IPv4

and IPv6 simultaneously?

a. ISATAP

b. IPv4-in-IPv6 Tunnels

c. Dual Stack

d. 6to4 Tunnels

11. If you use static configuration, all autoconfiguration features provided by IPv6 will

be disabled.

a. T r u e

b. F a l s e

ptg13046388

Chapter 4: IP Addressing 187

Foundation Topics

IP Operation

IP is a protocol, and a protocol is best described as a series of rules governing how things

work in a certain technologies, the ultimate goal being an operational standardization.

When put into a network communication context, a protocol is the set of rules govern-

ing how packets are transmitted over a network. When you have a protocol, you are sure

that all machines on a network (or in the world, when it comes to the Internet) speak

the “same language” and can integrate into a holistic framework. IP is probably the most

common protocol over the Internet. It is the set of rules governing how packets are trans-

mitted over the Internet.

The IP protocol standardizes the way that machines over the Internet or any IP network

forward or route their packets based on their IP addresses. The most fundamental and

basic operation we observe in IP is the ability to perform routing. The routing of IP

packets and its unique addressing scheme is one of the main functions of the IP protocol.

Routing consists of forwarding IP packets from source to destination machines over a

network, based on their IP addresses. IP is probably the most common and widely used

protocol in existence as a result of its ease and use, but IP on its own is not sufficient

to every task that we might have in networking. It must be noted that the operation of

IP is also governed by the manner in which we deliver what to packets. Yes, the routing

protocol allows the delivery, but without certain additional components, IP will not, for

example, provide reliable packet delivery. To meet this goal of adding features like reliable

transport and acknowledgment, we need to rely on another feature known as Transport

Control Protocol (TCP).

TCP Operation

When TCP couples with IP, you get a traffic controller that manages reliable exchange.

TCP and IP work together to transmit data over the Internet, but at different levels. As we

mentioned previously, IP does not guarantee reliable packet delivery over a network, and

it is TCP that takes charge of making packet exchange reliable.

TCP is the protocol that ensures reliability in a transmission with minimal loss of packets.

Additional duties in the operation of TCP include assuring that packets maintain the right

order, and that any delay is kept to an acceptable level. Also, it is TCP that prevents the

possibility of packet duplication. All this is to ensure that the data received is consistent,

in order, complete, and smooth.

TCP operates in the protocol stack at the transport layer of the Open Systems

Interconnection (OSI) model, which means that during data transmission, TCP works just

before IP. TCP bundles data into TCP packets before sending these to IP, which in turn

encapsulates these into IP packets.

ptg13046388

188 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

An IP packet is a packet of data that carries a data payload and an IP header. Any piece

of data is broken into bits and placed into these packets and transmitted over the net-

work. When the packets reach their destination, they are reassembled into the original

data.

UDP Operation

The previous section discussed the nature of reliable transport that is provided by TCP,

but there are instances in many networks where you either do not need reliable packet

delivery or where you cannot afford to pay the associated costs of reliable delivery.

Reliable packet delivery is slow, and many applications that can be deployed on a mod-

ern network find TCP too slow. A perfect example is voice and video traffic. But a more

general explanation would be that TCP traffic is considered to be connection-oriented,

whereas User Datagram Protocol (UDP) traffic is connectionless. This means that UDP

packets do not contain anywhere near the amount of information as a TCP packet and

thus they are smaller. This small size, coupled with their speed, makes them ideal for

applications that are sensitive to the packet loss or delay such as IP voice or video solu-

tions.

But no matter the transport method, TCP or UDP, your IP packets are delivered and man-

aged in the context of IOS through their unique logical addressing and the ability to par-

tition sections of addresses into usable networks.

IP Addressing and Subnetting

You need a postal address to receive letters; similarly, computers must use an IP address

to be able to send and receive data using the TCP/IP protocols. Just as the postal service

dictates the format and meaning of a postal address to aid the efficient delivery of mail,

the TCP/IP protocol suite imposes some rules about IP address assignment so that rout-

ers can efficiently forward packets between IP hosts. This chapter begins with coverage

of the format and meaning of IP addresses, with required consideration for how they are

grouped to aid the routing process.

IP Addressing and Subnetting Review

First, here’s a quick review of some of the core facts about IPv4 addresses that should be

fairly familiar to you:

■ A 32-bit binary number.

■ Written in “dotted decimal” notation (for example, 1.2.3.4), with each decimal octet

representing 8 bits.

■ Addresses are assigned to network interfaces, so computers or routers with multiple

interfaces have multiple IP addresses.

■ A computer with an IP address assigned to an interface is an IP host .

ptg13046388

Chapter 4: IP Addressing 189

■ A group of IP hosts that are not separated from each other by an IP router are in the

same grouping.

■ These groupings are called networks , subnets , or prefixes , depending on the con-

text.

■ IP hosts separated from another set of IP hosts by a router must be in separate

groupings (network/subnet/prefix).

IP addresses can be analyzed using classful or classless logic, depending on the situa-

tion. Classful logic simply means that the main class A, B, and C rules from RFC 791 are

considered. The next several pages present a classful view of IP addresses, as reviewed in

T a b l e 4 - 2 .

With classful addressing, class A, B, and C networks can be identified as such by their

first several bits (shown in the last column of Table 4-2 ) or by the range of decimal values

for their first octets. Also, each class A, B, or C address has two parts (when not sub-

netted): a network part and a host part . The size of each is implied by the class, and can

be stated explicitly using the default mask for that class of network. For example, mask

255.0.0.0, the default mask for class A networks, has 8 binary 1s and 24 binary 0s, repre-

senting the size of the network and host parts, respectively.

Table 4-2 Classful Network Review

Class of

Address

Size of Network and

Host Parts of the

Addresses

Range of First

Octet Values

Default Mask for

Each Class of

Network

Identifying Bits

at Beginning of

Address

A 8/24 1–126 255.0.0.0 0

B 16/16 128–191 255.255.0.0 10

C 24/8 192–223 255.255.255.0 110

D — 224–239 — 1110

E — 240–255 — 1111

Subnetting a Classful Network Number

With classful addressing, and no subnetting, an entire class A, B, or C network is needed

on each individual instance of a data link. For example, Figure 4-1 shows a sample inter-

network, with dashed-line circles representing the set of hosts that must be in the same

IP network—in this case requiring three networks. Figure 4-1 shows two options for how

IP addresses can be assigned and grouped together for this internetwork topology.

Key

Topic

ptg13046388

190 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

172.31.103.41

E0/0

Client3

Network 172.31.0.0 Network 130.2.0.0

Option 1: Use Classful Networks for Each Group

Option 2: Use Subnets of One Classful Network

Network 8.0.0.0

Subnet 172.31.103.0

255.255.255.0

Subnet 172.31.13.0

255.255.255.0

Subnet 172.31.11.0

255.255.255.0

SW1

R3 R1

Figure 4-1 Sample Internetwork with Two Alternatives for Address Assignment—

Without and With Subnetting

Option 1 uses three classful networks; however, it wastes a lot of IP addresses. For

example, all hosts in class A network 8.0.0.0 must reside on the LAN on the right side of

the figure.

Of course, the much more reasonable alternative is to reserve one classful IP network

number and use subnetting to subdivide that network into at least three subdivisions,

called subnets . Option 2 (bottom of Figure 4-1 ) shows how to subdivide a class A, B, or

C network into subnets.

To create subnets, the IP addresses must have three fields instead of just two—the net-

work, subnet , and host. When using classful logic to interpret IP addresses, the size of

the network part is still defined by classful rules—either 8, 16, or 24 bits based on class.

To create the subnet field, the host field is shortened, as shown in Figure 4-2 .

Network Host Class A

Subnet

24 – x

Network Host Class B

Subnet

16 – x x

HostNetwork Class C

Subnet

8 – x24

Figure 4-2 Formats of IP Addresses when Subnetting

Key

Topic

ptg13046388

Chapter 4: IP Addressing 191

Note The term internetwork refers to a collection of computers and networking hard-

ware; because TCP/IP discussions frequently use the term network to refer to a classful

class A, B, or C IP network, this book uses the term internetwork to refer to an entire net-

work topology, as shown in Figure 4-1.

To determine the size of each field in a subnetted IP address, you can follow the three

easy steps shown in Table 4-3 . Note that Figure 4-1 also showed alternative addressing

for using subnets, with the last column in Table 4-3 showing the size of each field for that

particular example, which used class B network 172.31.0.0, mask 255.255.255.0.

Table 4-3 Finding the Size of the Network, Subnet, and Host Fields in an IP Address

Name of Part of

the Address

Process to Find Its Size Size per Figure 4-1

Example

Network 8, 16, or 24 bits based on class rules 16

Subnet 32 minus network and host bits 8

Host Equal to the number of binary 0s in the mask 8

Comments on Classless Addressing

The terms classless and classful can be applied to three popular topics that are all related

to IP. This chapter explains classful and classless IP addressing, which are relatively simple

concepts. Two other chapters explain the other uses of the terms classless and classful:

Chapter 6 , “IP Forwarding (Routing),” describes classless/classful routing, and Chapter 7 ,

“RIPv2 and RIPng,” covers classless/classful routing protocols.

Classless IP addressing, simply put, means that class A, B, and C rules are ignored. Each

address is viewed as a two-part address, formally called the prefix and the host parts of

the address. The prefix simply states how many of the beginning bits of an IP address

identify or define the group. It is the same idea as using the combined network and sub-

net parts of an address to identify a subnet. All the hosts with identical prefixes are in

effect in the same group, which can be called a subnet or a prefix .

Just as a classful subnet must be listed with the subnet mask to know exactly which

addresses are in the subnet, a prefix must be listed with its prefix length . The prefix

itself is a dotted-decimal number. It is typically followed by a / symbol, after which the

prefix length is listed. The prefix length is a decimal number that denotes the length (in

bits) of the prefix. For example, 172.31.13.0/24 means a prefix of 172.31.13.0 and a prefix

length of 24 bits. Also, the prefix can be implied by a subnet mask, with the number of

1s in the binary version of the mask implying the prefix length.

Classless and classful addressing are mainly just two ways to think about IP address for-

mats. For the exam, make sure to understand both perspectives and the terminology used

by each.

Key

Topic

ptg13046388

192 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Subnetting Math

Knowing how to interpret the meaning of addresses and masks, routes and masks in the

routing table, and addresses and masks in access control lists (ACL) and how to configure

route filtering are all very important topics for the CCIE Routing and Switching written

and lab exams. This section covers the binary math briefly, with coverage of some tricks

to do the math quickly without binary math. Several subsequent chapters cover the con-

figuration details of features that require this math.

Dissecting the Component Parts of an IP Address

First, deducing the size of the three parts (classful view) or two parts (classless view) of

an IP address is important, because it allows you to analyze information about that sub-

net and other subnets. Every internetwork requires some number of subnets, and some

number of hosts per subnet. Analyzing the format of an existing address, based on the

mask or prefix length, enables you to determine whether enough hosts per subnet exist,

or whether enough subnets exist to support the number of hosts. The following list sum-

marizes some of the common math facts about subnetting related to the format of IP

addresses:

■ If a subnet has been defined with y host bits, there are 2 y – 2 valid usable IP

addresses in the subnet, because two numeric values are reserved.

■ One reserved IP address in each subnet is the subnet number itself. This number, by

definition, has binary 0s for all host bits. This number represents the subnet, and is

typically seen in routing tables.

■ The other reserved IP address in the subnet is the subnet broadcast address, which

by definition has binary 1s for all host bits. This number can be used as a destination

IP address to send a packet to all hosts in the subnet.

■ When you are thinking classfully, if the mask implies x subnet bits, then 2 x possible

subnets exist for that classful network, assuming that the same mask is used through-

out the network.

■ Although there are no truly reserved values for the subnet numbers, two (lowest and

highest values) can be discouraged from use in some cases:

■ Zero subnet: The subnet ﬁ eld is all binary 0s; in decimal, each zero subnet is the

exact same dotted-decimal number as the classful network number, potentially

causing confusion.

■ Broadcast subnet: The subnet ﬁ eld is all binary 1s; in decimal, this subnet’s

broadcast address is the same as the network-wide broadcast address, potentially

causing confusion.

In Cisco routers, by default, zero subnets and broadcast subnets work fine. You can dis-

able the use of the zero subnet with the no ip subnet-zero global command. The only

time that using the zero subnet typically causes problems is when classful routing proto-

cols are used.

Key

Topic

ptg13046388

Chapter 4: IP Addressing 193

Finding Subnet Numbers and Valid Range of IP Addresses—Binary

When examining an IP address and mask, the process of finding the subnet number, the

broadcast address, and the range of valid IP addresses is as fundamental to networking

as is addition and subtraction for advanced math. Possibly more so for the CCIE Routing

and Switching lab exam, mastery of the math behind subnetting, which is the same basic

math behind route summarization and filtering, will improve your speed in completing

complex configurations on the exam.

The range of valid IP addresses in a subnet begins with the number that is 1 larger than

the subnet number, and ends with the address that is 1 smaller than the broadcast address

for the subnet. So, to determine the range of valid addresses, just calculate the subnet

number and broadcast address, which can be done as follows:

■ To derive the subnet number: Perform a bitwise Boolean AND between the IP

address and mask.

■ To derive the broadcast address: Change all host bits in the subnet number from 0s

to 1s.

A bitwise Boolean AND means that you place two long binary numbers on top of each

other, and then AND the two bits that line up vertically. (A Boolean AND results in a

binary 1 only if both bits are 1; otherwise, the result is 0.) Table 4-4 shows an easy exam-

ple based on subnet 172.31.103.0/24 from Figure 4-1 .

Table 4-4 Binary Math to Calculate the Subnet Number and Broadcast Address

Address 172.31.103.41 1010 1100 0001 1111 0110 0111 0010 1001

Mask 255.255.255.0 1111 1111 1111 1111 1111 1111 0000 0000

Subnet Number (Result

of AND)

172.31.103.0 1010 1100 0001 1111 0110 0111 0000 0000

Broadcast 172.31.103.255 1010 1100 0001 1111 0110 0111 1111 1111

Probably almost everyone reading this already knew that the decimal subnet number and

broadcast addresses shown in Table 4-4 were correct, even without looking at the binary

math. The important part is to recall the binary process, and practice until you can con-

fidently and consistently find the answer without using any binary math. The only parts

of the math that typically trip people up are the binary-to-decimal and decimal-to-binary

conversions. When working in binary, keep in mind that you will not have a calculator

for the written exam, and that when converting to decimal, you always convert 8 bits

at a time—even if an octet contains some prefix bits and some host bits. ( Appendix C ,

“Decimal-to-Binary Conversion Table,” contains a conversion table for your reference.)

Key

Topic

ptg13046388

194 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Decimal Shortcuts to Find the Subnet Number and Valid Range of IP

Addresses

Many of the IP addressing and routing related problems on the exam come back to the

ability to solve a couple of classic basic problems. One of those problems runs as follows:

Given an IP address and mask (or prefix length), determine the subnet number/prefix,

broadcast address, and range of valid IP addresses.

If you can already solve such problems with only a few seconds’ thought, even with

tricky masks, you can skip this section of the chapter. If you cannot solve such questions

easily and quickly, this section can help you learn some math shortcuts that allow you to

find the answers without needing to use any Boolean math.

Note The next several pages of this chapter describe some algorithms that you can use

to find many important details related to IP addressing, without needing to convert to and

from binary. In my experience, some people simply work better performing the math in

binary until the answers simply start popping into their heads. Others find that the decimal

shortcuts are more effective.

If you use the decimal shortcuts, it is best to practice them until you no longer really use

the exact steps listed in this book; rather, the processes should become second nature. To

that end, CD-only Appendix D, “IP Addressing Practice,” lists several practice problems for

each of the algorithms presented in this chapter.

To solve the “find the subnet/broadcast/range of addresses” type of problem, at least

three of the four octets should have pretty simple math. For example, with a nice, easy

mask like 255.255.255.0, the logic used to find the subnet number and broadcast address

is intuitive to most people. The more challenging cases occur when the mask or prefix

does not divide the host field at a byte boundary. For example, the same IP address

172.31.103.41, with mask 255.255.252.0 (prefix /22), is actually in subnet 172.31.100.0.

Working with the third octet in this example is the hard part, because the mask value for

that octet is not 0 or 255; for the upcoming process, this octet is called the interesting

octet . The following process finds the subnet number, using decimal math, even with a

challenging mask:

Step 1. Find the mask octets of value 255; copy the same octets from the IP address.

Step 2. Find the mask octets of value 0; write down 0s for the same octets.

Step 3. If one octet has not yet been filled in, that octet is the interesting octet. Find

the subnet mask’s value in the interesting octet and subtract it from 256. Call

this number the “magic number.”

Step 4. Find the integer multiple of the magic number that is closest to, but not larger

than, the interesting octet’s value.

ptg13046388

Chapter 4: IP Addressing 195

An example certainly helps, as shown in Table 4-5 , with 172.31.103.41, mask

255.255.252.0. The table separates the address into its four component octets. In this

example, the first, second, and fourth octets of the subnet number are easily found from

Steps 1 and 2 in the process. Because the interesting octet is the third octet, the magic

number is 256 – 252, or 4. The integer multiple of 4, closest to 103 but not exceeding

103, is 100—making 100 the subnet number’s value in the third octet. (Note that you can

use this same process even with an easy mask, and Steps 1 and 2 will give you the com-

plete subnet number.)

Table 4-5 Quick Math to Find the Subnet Number—172.31.103.41, 255.255.252.0

Octet Comments

1 2 3 4

Address 172 31 103 41

Mask 255 255 252 0 Equivalent to /22.

Subnet number results after

Steps 1 and 2

172 31 0 Magic number will be 256 –

252 = 4.

Subnet number after complet-

ing the interesting octet

172 31 100 0 100 is the multiple of 4 closest

to, but not exceeding, 103.

A similar process can be used to determine the subnet broadcast address. This process

assumes that the mask is tricky. The detailed steps are as follows:

Step 1. Start with the subnet number.

Step 2. Decide which octet is interesting, based on which octet of the mask does not

have a 0 or 255.

Step 3. For octets to the left of the interesting octet, copy the subnet number’s values

into the place where you are writing down the broadcast address.

Step 4. For any octets to the right of the interesting octet, write 255 for the broadcast

address.

Step 5. Calculate the magic number: Find the subnet mask’s value in the interesting

octet and subtract it from 256.

Step 6. Take the subnet number’s interesting octet value, add the magic number to it,

and subtract 1. Fill in the broadcast address’s interesting octet with this num-

b e r .

Table 4-6 shows the 172.31.103.41/22 example again, using this process to find the sub-

net broadcast address.

ptg13046388

196 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-6 Quick Math to Find the Broadcast Address—172.31.103.41, 255.255.252.0

Octet Comments

1 2 3 4

Subnet number (per Step 1) 172 31 100 0

Mask (for reference) 255 255 252 0 Equivalent to /22

Results after Steps 1 to 4 172 31 255 Magic number will be 256 – 252 = 4

Subnet number after

completing the empty octet

172 31 103 255 Subnet’s third octet (100), plus magic

number (4), minus 1 is 103

Note If you have read the last few pages to improve your speed at dissecting a subnet

without requiring binary math, it is probably a good time to pull out the CD in the back of

the book. CD-only Appendix D, “IP Addressing Practice,” contains several practice prob-

lems for finding the subnet and broadcast address, as well as for many other math issues

related to IP addressing.

Determining All Subnets of a Network—Binary

Another common question, typically simply a portion of a more challenging question on

the CCIE written exam, relates to finding all subnets of a network. The base underlying

question might be as follows:

Given a particular class A, B, or C network, and a mask/prefix length used on all sub-

nets of that network, what are the actual subnet numbers?

The answers can be found using binary or using a simple decimal algorithm. This section

first shows how to answer the question using binary, using the following steps. Note that

the steps include details that are not really necessary for the math part of the problem;

these steps are mainly helpful for practicing the process.

Step 1. Write the binary version of the classful network number; that value is actually

the zero subnet as well.

Step 2. Draw two vertical lines through the number, one separating the network and

subnet parts of the number, the other separating the subnet and host part.

Step 3. Calculate the number of subnets, including the zero and broadcast subnet,

based on 2 y , where y is the number of subnet bits.

Step 4. Write y −1 copies of the binary network number below the first one, but leave

the subnet field blank.

Step 5. Using the subnet field as a binary counter, write the values, top to bottom, in

which the next value is 1 greater than the previous.

Step 6. Convert the binary numbers, 8 bits at a time, back to decimal.

Key

Topic

ptg13046388

Chapter 4: IP Addressing 197

This process takes advantage of a couple of facts about the binary form of IP subnet

numbers:

■ All subnets of a classful network have the same value in the network portion of the

subnet number.

■ All subnets of any classful network have binary 0s in the host portion of the subnet

number.

Step 4 in the process simply makes you write the network and host parts of each subnet

number, because those values are easily predicted. To find the different subnet numbers,

you then just need to discover all possible different combinations of binary digits in the

subnet field, because that is the only part of the subnet numbers that differs from subnet

to subnet.

For example, consider the same class B network 172.31.0.0, with static length subnet

masking (SLSM) assumed, and a mask of 255.255.224.0. Note that this example uses 3

subnet bits, so there will be 23 subnets. Table 4-7 lists the example.

Table 4-7 Binary Method to Find All Subnets—Steps 1 Through 4

Octet

Subnet 1 2 3 4

Network number/zero subnet 10101100 000 11111 000 00000 00000000

2nd subnet 10101100 000 11111 00000 00000000

3rd subnet 10101100 000 11111 00000 00000000

4th subnet 10101100 000 11111 00000 00000000

5th subnet 10101100 000 11111 00000 00000000

6th subnet 10101100 000 11111 00000 00000000

7th subnet 10101100 000 11111 00000 00000000

8th subnet (2 y = 8); broadcast subnet 10101100 000 11111 00000 00000000

At this point, you have the zero subnet recorded at the top, and you are ready to use the

subnet field (the missing bits in the table) as a counter to find all possible values. Table

4-8 completes the process.

ptg13046388

198 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-8 Binary Method to Find All Subnets—Step 5

Octet

Subnet 1 2 3 4

Network number/zero subnet 10101100 00011111 000 00000 00000000

2nd subnet 10101100 00011111 001 00000 00000000

3rd subnet 10101100 00011111 010 00000 00000000

4th subnet 10101100 00011111 011 00000 00000000

5th subnet 10101100 00011111 100 00000 00000000

6th subnet 10101100 00011111 101 00000 00000000

7th subnet 10101100 00011111 110 00000 00000000

8th subnet (2 y = 8); broadcast subnet 10101100 00011111 111 00000 00000000

The final step to determine all subnets is simply to convert the values back to decimal.

Take care to always convert 8 bits at a time. In this case, you end up with the follow-

ing subnets: 172.31.0.0, 172.31.32.0, 172.31.64.0, 172.31.96.0, 172.31.128.0, 172.31.160.0,

172.31.192.0, and 172.31.224.0.

Determining All Subnets of a Network—Decimal

You might have noticed the trend in the third octet values in the subnets listed in the pre-

vious paragraph. When assuming SLSM, the subnet numbers in decimal do have a regu-

lar increment value, which turns out to be the value of the magic number. For example,

instead of the binary math in the previous section, you could have thought the following:

■ The interesting octet is the third octet.

■ The magic number is 256 – 224 = 32.

■ 172.31.0.0 is the zero subnet, because it is the same number as the network number.

■ The other subnet numbers are increments of the magic number inside the interesting

octet.

If that logic already clicks in your head, you can skip to the next section in this chapter.

If not, the rest of this section outlines a decimal algorithm that takes a little longer pass at

the same general logic. First, the question and the algorithm assume that the same subnet

mask is used on all subnets of this one classful network—a feature sometimes called stat-

ic length subnet masking (SLSM) . In contrast, variable length subnet masking (VLSM)

means that different masks are used in the same classful network. The algorithm assumes

a subnet field of 8 bits or less just to keep the steps uncluttered; for longer subnet fields,

the algorithm can be easily extrapolated.

ptg13046388

Chapter 4: IP Addressing 199

Step 1. Write the classful network number in decimal.

Step 2. For the first (lowest numeric) subnet number, copy the entire network num-

ber. That is the first subnet number, and is also the zero subnet.

Step 3. Decide which octet contains the entire subnet field; call this octet the inter-

esting octet. (Remember, this algorithm assumes 8 subnet bits or less, so the

entire subnet field will be in a single interesting octet.)

Step 4. Calculate the magic number by subtracting the mask’s interesting octet value

from 256.

Step 5. Copy the previous subnet number’s noninteresting octets onto the next line as

the next subnet number; only one octet is missing at this point.

Step 6. Add the magic number to the previous subnet’s interesting octet, and write

that as the next subnet number’s interesting octet, completing the next subnet

number.

Step 7. Repeat Steps 5 and 6 until the new interesting octet is 256. That subnet is not

valid. The previously calculated subnet is the last valid subnet, and also the

broadcast subnet.

For example, consider the same class B network 172.31.0.0, with SLSM assumed, and a

mask of 255.255.224.0. Table 4-9 lists the example.

Table 4-9 Subnet List Chart—172.31.0.0/255.255.224.0

Octet Comments

1 2 3 4

Network number 172 31 0 0 Step 1 from the process.

Mask 255 255 224 0 Magic number is 256 – 224 = 32.

Subnet zero 172 31 0 0 Step 2 from the process.

First subnet 172 31 32 0 Steps 5 and 6; previous interesting octet 0,

plus magic number (32).

Next subnet 172 31 64 0 32 plus magic number is 64.

Next subnet 172 31 96 0 64 plus magic number is 96.

Next subnet 172 31 128 0 96 plus magic number is 128.

Next subnet 172 31 160 0 128 plus magic number is 160.

Next subnet 172 31 192 0 160 plus magic number is 192.

Last subnet (broadcast) 172 31 224 0 The broadcast subnet in this case.

Invalid; easy-to-

recognize stopping point

172 31 256 0 256 is out of range; when writing this one,

note that it is invalid, and that the previous

one is the last valid subnet.

Key

Topic

ptg13046388

200 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

You can use this process repeatedly as needed until the answers start jumping out at you

without the table and step-wise algorithm. For more practice, refer to CD-only Appendix D .

VLSM Subnet Allocation

So far in this chapter, most of the discussion has been about examining existing ad -

dresses and subnets. Before deploying new networks, or new parts of a network, you

must give some thought to the ranges of IP addresses to be allocated. Also, when assign-

ing subnets for different locations, you should assign the subnets with thought for how

routes could then be summarized. This section covers some of the key concepts related

to subnet allocation and summarization. (This section focuses on the concepts behind

summarization; the configuration of route summarization is routing protocol–specific

and thus is covered in the individual chapters covering routing protocols.)

Many organizations purposefully use SLSM to simplify operations. Additionally, many

internetworks also use private IP network 10.0.0.0, with an SLSM prefix length of /24,

and use NAT for connecting to the Internet. Operations and troubleshooting can be a lot

easier when you use SLSM, particularly with a nice, easy prefix like /24.

In some cases, VLSM is required or preferred when allocating addresses. VLSM is typi-

cally chosen when the address space is constrained to some degree. The VLSM subnet

assignment strategy covered here complies with the strategy you might remember from

the Cisco BSCI course or from reading the Cisco Press CCNP Routing certification

books.

Similar to when assigning subnets with SLSM, you should use an easily summarized

block of addresses for a new part of the network. Because VLSM network addresses are

likely constrained to some degree, you should choose the specific subnets wisely. The

general rules for choosing wisely are as follows:

Step 1. Determine the shortest prefix length (in other words, the largest block)

required.

Step 2. Divide the available address block into equal-sized prefixes based on the

shortest prefix from Step 1.

Step 3. Allocate the largest required subnets/prefixes from the beginning of the IP

address block, leaving some equal-sized unallocated address blocks at the end

of the original large address block.

Step 4. Choose an unallocated block that you will further subdivide by repeating

the first three steps, using the shortest required prefix length (largest address

block) for the remaining subnets.

Step 5. When allocating very small address blocks for use on links between routers,

consider using subnets at the end of the address range. This leaves the largest

consecutive blocks available in case future requirements change.

For example, imagine that a network engineer plans a new site installation. He allocates

the 172.31.28.0/23 address block for the new site, expecting to use the block as a single

summarized route. When planning, the engineer then subdivides 172.31.28.0/23 per the

Key

Topic

ptg13046388

Chapter 4: IP Addressing 201

subnet requirements for the new installation, as shown in Figure 4-3 . The figure shows

three iterations through the VLSM subnet assignment process, because the requirements

call for three different subnet sizes. Each iteration divides a remaining block into equal

sizes, based on the prefix requirements of the subnets allocated at that step. Note that the

small /30 prefixes were allocated from the end of the address range, leaving the largest

possible consecutive address range for future growth.

172.31.28.0/23 (172.31.28.0 Through 172.31.29.255)

Requirements:

3 /25’s

2 /27’s

3 /30’s

Allocated

Pass 1: /25 prefixes

Block 172.31.28.0/23

Allocated Allocated Unallocated

172.31.28.0/25

172.31.28.1 –

172.31.28.126

172.31.28.128/25

172.31.28.129 –

172.31.28.254

172.31.29.0/25

172.31.29.1 –

172.31.29.126

172.31.29.128/25

172.31.29.129 –

172.31.29.254

AllocatedPass 2: /27 prefixes

Block 172.31.29.128/25

Allocated Unallocated Unallocated

172.31.29.128/27 172.31.29.160/27 172.31.29.192/27 172.31.29.224/27

Step 3: /30 prefixes

Allocate High End:

172.31.29.252/30,

172.31.29.248/30,

172.31.29.244/30

AllocatedUnallocated

Figure 4-3 Example of VLSM Subnet Allocation Process

Route Summarization Concepts

The ability to recognize and define how to most efficiently summarize existing address

ranges is an important skill on both the written and lab exams. For the written exam, the

question might not be as straightforward as, “What is the most efficient summarization

of the following subnets?” Rather, the math required for such a question might simply be

part of a larger question. Certainly, such math is required for the lab exam. This section

looks at the math behind finding the best summarization; other chapters cover specific

configuration commands.

Good IP address assignment practices should always consider the capabilities for route

summarization. For example, if a division of a company needs 15 subnets, an engineer

needs to allocate those 15 subnets from the unused portions of the address block avail-

able to that internetwork. However, assigning subnets 10.1.101.0/24 through 10.1.115.0/24

would be a poor choice, because those do not easily summarize. Rather, allocate a range

of addresses that can be easily summarized into a single route. For example, subnets

Key

Topic

ptg13046388

202 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

10.1.96.0/24 through 10.1.111.0/24 can be summarized as a single 10.1.96.0/20 route, mak-

ing those routes a better choice.

There are two main ways to think of the word best when you are looking for the “best

summarization”:

■ Inclusive summary routes: A single summarized route that is as small a range of

addresses as possible, while including all routes/subnets shown, and possibly includ-

ing subnets that do not currently exist.

■ Exclusive summary routes: As few as possible summarized routes that include all

to-be-summarized address ranges, but excluding all other routes/subnets.

Note The terms inclusive summary, exclusive summary, and candidate summary are

simply terms I invented for this book and will continue to use later in the chapter.

For example, with the VLSM example in Figure 4-3 , the network engineer purposefully

planned so that an inclusive summary of 172.31.28.0/23 could be used. Even though not

all subnets are yet allocated from that address range, the engineer is likely saving the rest

of that address range for future subnets at that site, so summarizing using an inclusive

summary is reasonable. In other cases, typically when trying to summarize routes in an

internetwork for which summarization was not planned, the summarization must exclude

routes that are not explicitly listed, because those address ranges can actually be used in

another part of the internetwork.

Finding Inclusive Summary Routes—Binary

Finding the best inclusive summary lends itself to a formal binary process, as well as to a

formal decimal process. The binary process runs as follows:

Step 1. Write the binary version of each component subnet, one on top of the other.

Step 2. Inspect the binary values to find how many consecutive bits have the exact

same value in all component subnets. That number of bits is the prefix length.

Step 3. Write a new 32-bit number at the bottom of the list by copying y bits from

the prior number, y being the prefix length. Write binary 0s for the remaining

bits. This is the inclusive summary.

Step 4. Convert the new number to decimal, 8 bits at a time.

Table 4-10 shows an example of this process, using four routes, 172.31.20.0, .21.0, .22.0,

and .23.0, all with prefix /24.

ptg13046388

Chapter 4: IP Addressing 203

Table 4-10 Example of Finding the Best Inclusive Summary—Binary

Octet 1 Octet 2 Octet 3 Octet 4

172.31.20.0/24 10101100 00011111 000101 00 00000000

172.31.21.0/24 10101100 00011111 000101 01 00000000

172.31.22.0/24 10101100 00011111 000101 10 00000000

172.31.23.0/24 10101100 00011111 000101 11 00000000

Prefix length: 22

Inclusive summary 10101100 00011111 000101 00 00000000

The trickiest part is Step 2, in which you have to simply look at the binary values and find

the point at which the bits are no longer equal. You can shorten the process by, in this

case, noticing that all component subnets begin with 172.31, meaning that the first 16

bits will certainly have the same values.

Finding Inclusive Summary Routes—Decimal

To find the same inclusive summary using only decimal math, use the following process.

The process works just fine with variable prefix lengths and nonconsecutive subnets.

Step 1. Count the number of subnets; then, find the smallest value of y , such that 2 y

=> that number of subnets.

Step 2. For the next step, use a prefix length based on the longest prefix length of the

component subnets, minus y .

Step 3. Pretend that the lowest numeric subnet number in the list of component sub-

nets is an IP address. Using the new, smaller prefix from Step 2, calculate the

subnet number in which this pretend address resides.

Step 4. Repeat Step 3 for the largest numeric component subnet number and the same

prefix. If it is the same subnet derived as in Step 3, the resulting subnet is the

best summarized route, using the new prefix.

Step 5. If Steps 3 and 4 do not yield the same resulting subnet, repeat Steps 3 and 4

with another new prefix length of 1 less than the last prefix length.

Table 4-11 shows two examples of the process. The first example has four routes,

172.31.20.0, .21.0, .22.0, and .23.0, all with prefix /24. The second example adds

172.31.24.0 to that same list.

ptg13046388

204 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-11 Example of Finding the Best Summarizations

Step Range of .20.0, .21.0, .22.0,

and .23.0, /24

Same Range, Plus 172.31.24.0

Step 1 22 = 4, y = 2 23 = 8, y = 3

Step 2 24 – 2 = 22 24 – 3 = 21

Step 3 Smallest subnet 172.31.20.0, with

/22, yields 172.31.20.0/22

Smallest subnet 172.31.20.0, with /21,

yields 172.31.16.0/21

Step 4 Largest subnet 172.31.23.0, with

/22, yields 172.31.20.0/22

Largest subnet 172.31.24.0, with /21,

yields 172.31.24.0/21

Step 5 — 21 – 1 = 20; new prefix

Step 3, 2nd time — 172.31.16.0/20

Step 4, 2nd

time

— 172.31.16.0/20; the same as prior step,

so that is the answer

With the first example, Steps 3 and 4 yielded the same answer, which means that the best

inclusive summary had been found. With the second example, a second pass through the

process was required. CD-only Appendix D contains several practice problems to help

you develop speed and make this process second nature.

Finding Exclusive Summary Routes—Binary

A similar process, listed next, can be used to find the exclusive summary. Keep in mind

that the best exclusive summary can be composed of multiple summary routes. Once

again, to keep it simple, the process assumes SLSM.

Step 1. Find the best exclusive summary route; call it a candidate exclusive sum-

mary route.

Step 2. Determine whether the candidate summary includes any address ranges it

should not. To do so, compare the summary’s implied address range with the

implied address ranges of the component subnets.

Step 3. If the candidate summary only includes addresses in the ranges implied by

the component subnets, the candidate summary is part of the best exclusive

summarization of the original component subnets.

Step 4. If instead the candidate summary includes some addresses that match the can-

didate summary routes and some addresses that do not, split the current can-

didate summary in half, into two new candidate summary routes, each with a

prefix 1 longer than before.

Step 5. If the candidate summary only includes addresses outside the ranges implied

by the component subnets, the candidate summary is not part of the best

exclusive summarization, and it should not be split further.

ptg13046388

Chapter 4: IP Addressing 205

Step 6. Repeat Steps 2 through 4 for each of the two possible candidate summary

routes created at Step 4.

For example, take the same five subnets used with the inclusive example—172.31.20.0/24,

.21.0, .22.0, .23.0, and .24.0. The best inclusive summary is 172.31.16.0/20, which implies

an address range of 172.31.16.0 to 172.31.31.255—clearly, it includes more addresses

than the original five subnets. So, repeat the process of splitting the summary in half, and

repeating, until summaries are found that do not include any unnecessary address ranges.

Figure 4-4 shows the idea behind the logic.

172.31.16.0/20: 16.0 Thru 31.255

172.31.16.0/21: 16.0 thru 23.255 172.31.24.0/21: 24.0 thru 31.255

172.31.16.0/22:

16.0 Thru 19.255

172.31.20.0/22:

20.0 Thru 23.255

172.31.24.0/22:

24.0 Thru 27.255

172.31.28.0/22:

28.0 Thru 31.255

Too Inclusive:

Split!

Too Inclusive:

Split!

Too Inclusive:

Split!

Range completely

outside range to

be summarized;

stop splitting.

Range completely

outside range to

be summarized;

stop splitting.

Range is

exclusively from

target range –

keep this as part

of best exclusive

summary!

Too inclusive:

keep splitting!

(Details not

shown.)

Routes to Summarize:

172.31.20.0/24 (20.0 thru 20.255)

172.31.21.0/24 (21.0 thru 21.255)

172.31.22.0/24 (22.0 thru 22.255)

172.31.23.0/24 (23.0 thru 23.255)

172.31.24.0/24 (24.0 thru 24.255)

Figure 4-4 Example of Process to Find Exclusive Summary Routes

The process starts with one candidate summary. If it includes some addresses that need

to be summarized and some addresses it should not summarize, split it in half and try

again with each half. Eventually, the best exclusive summary routes are found, or the

splitting keeps happening until you get back to the original routes. In fact, in this case,

after a few more splits (not shown), the process ends up splitting to 172.31.24.0/24, which

is one of the original routes—meaning that 172.31.24.0/24 cannot be summarized any

further in this example.

CIDR, Private Addresses, and NAT

The sky was falling in the early 1990s in that the commercialization of the Internet was

rapidly depleting the IP version 4 address space. Also, Internet routers’ routing tables

were doubling annually (at least). Without some changes, the incredible growth of the

Internet in the 1990s would have been stifled.

To solve the problems associated with this rapid growth, several short-term solutions

were created, as well as an ultimate long-term solution. The short-term solutions included

classless interdomain routing (CIDR), which helps reduce the size of routing tables by

aggregating routes, and Network Address Translation (NAT), which reduces the number

ptg13046388

206 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

of required public IP addresses used by each organization or company. This section cov-

ers the details of CIDR and NAT, plus a few related features.

Classless Interdomain Routing

CIDR is a convention defined in RFCs 1517 through 1520 that calls for aggregating

routes for multiple classful network numbers into a single routing table entry. The pri-

mary goal of CIDR is to improve the scalability of Internet routers’ routing tables.

Imagine the implications of an Internet router being burdened by carrying a route to

every class A, B, and C network on the planet!

CIDR uses both technical tools and administrative strategies to reduce the size of the

Internet routing tables. Technically, CIDR uses route summarization, but with Internet

scale in mind. For example, CIDR might be used to allow a large ISP to control a range of

IP addresses from 198.0.0.0 to 198.255.255.255, with the improvements to routing shown

in Figure 4-5 .

ISP #1

198.0.0.0 -

198.255.255.0

Route to 198.0.0.0 Mask

255.0.0.0 Points to ISP #1

Route to 198.0.0.0 Mask

255.0.0.0 Points to ISP #1

Route to 198.0.0.0 Mask

255.0.0.0 Points to ISP #1

Customer #1

198.8.3.0/24

Customer #2

198.4.2.0/24

198.4.3.0/24

Customer #3

198.1.0.0

ISP #2

ISP #3

ISP #4

Figure 4-5 Typical Use of CIDR

ISPs 2, 3, and 4 need only one route (198.0.0.0/8) in their routing tables to be able to for-

ward packets to all destinations that begin with 198. Note that this summary actually

summarizes multiple class C networks—a typical feature of CIDR. ISP 1’s routers contain

more detailed routing entries for addresses beginning with 198, based on where they allo-

cate IP addresses for their customers. ISP 1 would reduce its routing tables similarly with

large ranges used by the other ISPs.

CIDR attacks the problem of large routing tables through administrative means as well.

As shown in Figure 4-5 , ISPs are assigned contiguous blocks of addresses to use when

assigning addresses for their customers. Likewise, regional authorities are assigned large

address blocks, so when individual companies ask for registered public IP addresses, they

ask their regional registry to assign them an address block. As a result, addresses assigned

by the regional agency will at least be aggregatable into one large geographic region of

the world. For example, the Latin American and Caribbean Internet Addresses Registry

Key

Topic

ptg13046388

Chapter 4: IP Addressing 207

(LACNIC, www.lacnic.net ) administers the IP address space of the Latin American and

Caribbean region (LAC) on behalf of the Internet community.

In some cases, the term CIDR is used a little more generally than the original intent of

the RFCs. Some texts use the term CIDR synonymously with the term route summariza-

tion. Others use the term CIDR to refer to the process of summarizing multiple classful

networks together. In other cases, when an ISP assigns subsets of a classful network to a

customer who does not need an entire class C network, the ISP is essentially performing

subnetting; once again, this idea sometimes gets categorized as CIDR. But CIDR itself

refers to the administrative assignment of large address blocks, and the related summa-

rized routes, for the purpose of reducing the size of the Internet routing tables.

Note Because CIDR defines how to combine routes for multiple classful networks into

a single route, some people think of this process as being the opposite of subnetting. As a

result, many people refer to CIDR’s summarization results as supernetting.

Private Addressing

One of the issues with Internet growth was the assignment of all possible network num-

bers to a small number of companies or organizations. Private IP addressing helps to

mitigate this problem by allowing computers that will never be directly connected to the

Internet to not use public, Internet-routable addresses. For IP hosts that will purposefully

have no direct Internet connectivity, you can use several reserved network numbers, as

defined in RFC 1918 and listed in Table 4-12 .

Table 4-12 RFC 1918 Private Address Space

Range of IP Addresses Class of Networks Number of Networks

10.0.0.0 to 10.255.255.255 A 1

172.16.0.0 to 172.31.255.255 B 16

192.168.0.0 to 192.168.255.255 C 256

In other words, any organization can use these network numbers. However, no organi-

zation is allowed to advertise these networks using a routing protocol on the Internet.

Furthermore, all Internet routers should be configured to reject these routes.

Network Address Translation

NAT, defined in RFC 1631, enables a host that does not have a valid registered IP address

to communicate with other hosts on the Internet. NAT has gained such widespread accep-

tance that the majority of enterprise IP networks today use private IP addresses for most

Key

Topic

ptg13046388

208 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

hosts on the network and use a small block of public IP addresses, with NAT translating

between the two.

NAT translates, or changes, one or both IP addresses inside a packet as it passes through

a router. (Many firewalls also perform NAT; for the CCIE Routing and Switching exam,

you do not need to know NAT implementation details on firewalls.) In most cases, NAT

changes the (typically private range) addresses used inside an enterprise network into

addresses from the public IP address space. For example, Figure 4-6 shows static NAT

in operation; the enterprise has registered class C network 200.1.1.0/24, and uses private

class A network 10.0.0.0/8 for the hosts inside its network.

10.1.1.1 e0/0

s0/0

10.1.1.2

Internet

170.1.1.1

Server

SA 10.1.1.1 SA 200.1.1.1

Inside Local

10.1.1.1

10.1.1.2

Inside Global

200.1.1.1

200.1.1.2

DA 10.1.1.1 DA 200.1.1.1

Inside Outside

NAT

Figure 4-6 Basic NAT Concept

Beginning with the packets sent from a PC on the left to the server on the right, the pri-

vate IP source address 10.1.1.1 is translated to a public IP address of 200.1.1.1. The client

sends a packet with source address 10.1.1.1, but the NAT router changes the source to

200.1.1.1—a registered public IP address. When the server receives a packet with source

IP address 200.1.1.1, the server thinks it is talking to host 200.1.1.1, so it replies with

a packet sent to destination 200.1.1.1. The NAT router then translates the destination

address (200.1.1.1) back to 10.1.1.1.

Figure 4-6 provides a good backdrop for the introduction of a couple of key terms,

Inside Local and Inside Global . Both terms take the perspective of the owner of the

enterprise network. In Figure 4-6 , address 10.1.1.1 is the Inside Local address, and

200.1.1.1 is the Inside Global address. Both addresses represent the client PC on the

left, which is inside the enterprise network. Address 10.1.1.1 is from the enterprise’s

IP address space, which is only locally routable inside the enterprise—hence the term

Inside Local. Address 200.1.1.1 represents the local host, but the address is from the glob-

ally routable public IP address space—hence the name Inside Global. Table 4-13 lists and

describes the four main NAT address terms.

ptg13046388

Chapter 4: IP Addressing 209

Table 4-13 NAT Terminology

Name Location of Host

Represented by Address

IP Address Space in Which Address

Exists

Inside Local address Inside the enterprise

network

Part of the enterprise IP address space;

typically a private IP address

Inside Global

address

Inside the enterprise

network

Part of the public IP address space

Outside Local

address

In the public Internet;

or, outside the enterprise

network

Part of the enterprise IP address space;

typically a private IP address

Outside Global

address

In the public Internet;

or, outside the enterprise

network

Part of the public IP address space

Static NAT

Static NAT works just like the example in Figure 4-6 , but with the IP addresses statically

mapped to each other through configuration commands. With static NAT

■ A particular Inside Local address always maps to the same Inside Global (public) IP

address.

■ If used, each Outside Local address always maps to the same Outside Global (public)

IP address.

■ Static NAT does not conserve public IP addresses.

Although static NAT does not help with IP address conservation, static NAT does allow

an engineer to make an inside server host available to clients on the Internet, because the

inside server will always use the same public IP address.

Example 4-1 shows a basic static NAT configuration based on Figure 4-6 . Conceptually,

the NAT router has to identify which interfaces are inside (attach to the enterprise’s

IP address space) or outside (attach to the public IP address space). Also, the mapping

between each Inside Local and Inside Global IP address must be made. (Although not

needed for this example, outside addresses can also be statically mapped.)

Example 4-1 Static NAT Configuration

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! E0/0 attaches to the internal Private IP space, so it is configured as an inside

! interface.

interface Ethernet0/0

ip address 10.1.1.3 255.255.255.0

Key

Topic

Key

Topic

ptg13046388

210 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

ip nat inside

! S0/0 is attached to the public Internet, so it is defined as an outside

! interface.

interface Serial0/0

ip address 200.1.1.251 255.255.255.0

ip nat outside

! Next, two inside addresses are mapped, with the first address stating the

! Inside Local address, and the next stating the Inside Global address.

ip nat inside source static 10.1.1.2 200.1.1.2

ip nat inside source static 10.1.1.1 200.1.1.1

! Below, the NAT table lists the permanent static entries from the configuration.

NAT# show ip nat translations

Pro Inside global Inside local Outside local Outside global

--- 200.1.1.1 10.1.1.1 --- --

--- 200.1.1.2 10.1.1.2 --- ---

The router is performing NAT only for inside addresses. As a result, the router processes

packets entering E0/0—packets that could be sent by inside hosts—by examining the

source IP address. Any packets with a source IP address listed in the Inside Local column

of the show ip nat translations command output (10.1.1.1 or 10.1.1.2) will be translated to

source address 200.1.1.1 or 200.1.1.2, respectively, per the NAT table. Likewise, the router

examines the destination IP address of packets entering S0/0, because those packets

would be destined for inside hosts. Any such packets with a destination of 200.1.1.1 or .2

will be translated to 10.1.1.1 or .2, respectively.

In cases with static outside addresses being configured, the router also looks at the desti-

nation IP address of packets sent from the inside to the outside interfaces, and the source

IP address of packets sent from outside interfaces to inside interfaces.

Dynamic NAT Without PAT

Dynamic NAT (without PAT), like static NAT, creates a one-to-one mapping between an

Inside Local and Inside Global address. However, unlike static NAT, it does so by defin-

ing a set or pool of Inside Local and Inside Global addresses, and dynamically mapping

pairs of addresses as needed. For example, Figure 4-7 shows a pool of five Inside Global

IP addresses—200.1.1.1 through 200.1.1.5. NAT has also been configured to translate any

Inside Local addresses whose address starts with 10.1.1.

ptg13046388

Chapter 4: IP Addressing 211

10.1.1.1

10.1.1.2

NAT 170.1.1.1

Server

SA 10.1.1.2 SA 200.1.1.1

Inside Local

10.1.1.2

Inside Global

200.1.1.1

Inside Outside

NAT Table After First Packet

Inside Local Inside Global

NAT Table Before First Packet

Criteria for Hosts to NAT:

10.1.1.0 - 10.1.1.255

NAT Pool:

200.1.1.1

200.1.1.2

200.1.1.3

200.1.1.4

200.1.1.5

Internet

NAT

Figure 4-7 Dynamic NAT

The numbers 1, 2, and 3 in Figure 4-7 refer to the following sequence of events:

1. Host 10.1.1.2 starts by sending its first packet to the server at 170.1.1.1.

2. As the packet enters the NAT router, the router applies some matching logic to

decide whether the packet should have NAT applied. Because the logic has been con-

figured to mean “translate Inside Local addresses that start with 10.1.1,” the router

dynamically adds an entry in the NAT table for 10.1.1.2 as an Inside Local address.

3. The NAT router needs to allocate a corresponding IP address from the pool of valid

Inside Global addresses. It picks the first one available (200.1.1.1 in this case) and

adds it to the NAT table to complete the entry.

With the completion of Step 3, the NAT router can actually translate the source IP

address and forward the packet. Note that as long as the dynamic NAT entry exists in the

NAT table, only host 10.1.1.2 can use Inside Global IP address 200.1.1.1.

Overloading NAT with Port Address Translation

As mentioned earlier, NAT is one of the key features that helped to reduce the speed at

which the IPv4 address space was being depleted. NAT overloading , also known as Port

Address Translation ( PAT) , is the NAT feature that actually provides the significant sav-

ings of IP addresses. The key to understanding how PAT works is to consider the follow-

ing: From a server’s perspective, there is no significant difference between 100 different

TCP connections, each from a different host, and 100 different TCP connections all from

the same host.

Key

Topic

ptg13046388

212 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

PAT works by making large numbers of TCP or UDP flows from many Inside Local hosts

appear to be the same number of large flows from one (or a few) host’s Inside Global

addresses. With PAT, instead of just translating the IP address, NAT also translates the

port numbers as necessary. And because the port number fields are 16 bits in length,

each Inside Global IP address can support over 65,000 concurrent TCP and UDP flows.

For example, in a network with 1000 hosts, a single public IP address used as the only

Inside Global address could handle an average of six concurrent flows from each host to

and from hosts on the Internet.

Dynamic NAT and PAT Configuration

Like static NAT, dynamic NAT configuration begins with identifying the inside and out-

side interfaces. Additionally, the set of Inside Local addresses is configured with the ip

nat inside global command. If you are using a pool of public Inside Global addresses, the

set of addresses is defined by the ip nat pool command. Example 4-2 shows a dynamic

NAT configuration based on the internetwork shown in Figure 4-7 . The example defines

256 Inside Local addresses and two Inside Global addresses.

Example 4-2 Dynamic NAT Configuration

! First, the ip nat pool fred command lists a range of IP addresses. The ip nat

! inside source list 1 pool fred command points to ACL 1 as the list of Inside

! Local addresses, with a cross-reference to the pool name.

interface Ethernet0/0

ip address 10.1.1.3 255.255.255.0

ip nat inside

interface Serial0/0

ip address 200.1.1.251 255.255.255.0

ip nat outside

ip nat pool fred 200.1.1.1 200.1.1.2 netmask 255.255.255.252

ip nat inside source list 1 pool fred

access-list 1 permit 10.1.1.0 0.0.0.255

! Next, the NAT table begins as an empty table, because no dynamic entries had

! been created at that point.

NAT# show ip nat translations

! The NAT statistics show that no hits or misses have occurred. Hits occur when

! NAT looks for a mapping, and finds one. Misses occur when NAT looks for a NAT

! table entry, does not find one, and then needs to dynamically add one.

NAT# show ip nat statistics

Total active translations: 0 (0 static, 0 dynamic; 0 extended)

Key

Topic

ptg13046388

Chapter 4: IP Addressing 213

Outside interfaces:

Serial0/0

Inside interfaces:

Ethernet0/0

Hits: 0 Misses: 0

Expired translations: 0

Dynamic mappings:

-- Inside Source

access-list 1 pool fred refcount 0

pool fred: netmask 255.255.255.252

start 200.1.1.1 end 200.1.1.2

type generic, total addresses 2, allocated 0 (0%), misses 0

! At this point, a Telnet session from 10.1.1.1 to 170.1.1.1 started.

! Below, the 1 "miss" means that the first packet from 10.1.1.2 did not have a

! matching entry in the table, but that packet triggered NAT to add an entry to the

! NAT table. Host 10.1.1.2 has then sent 69 more packets, noted as "hits" because

! there was an entry in the table.

NAT# show ip nat statistics

Total active translations: 1 (0 static, 1 dynamic; 0 extended)

Outside interfaces:

Serial0/0

Inside interfaces:

Ethernet0/0

Hits: 69 Misses: 1

Expired translations: 0

Dynamic mappings:

-- Inside Source

access-list 1 pool fred refcount 1

pool fred: netmask 255.255.255.252

start 200.1.1.1 end 200.1.1.2

type generic, total addresses 2, allocated 1 (50%), misses 0

! The dynamic NAT entry is now displayed in the table.

NAT# show ip nat translations

Pro Inside global Inside local Outside local Outside global

--- 200.1.1.1 10.1.1.2 --- ---

! Below, the configuration uses PAT via the overload parameter. Could have used the

! ip nat inside source list 1 int s0/0 overload command instead, using a single

! IP Inside Global IP address.

NAT(config)# no ip nat inside source list 1 pool fred

NAT(config)# ip nat inside source list 1 pool fred overload

! To test, the dynamic NAT entries were cleared after changing the NAT

! configuration. Before the next command was issued, host 10.1.1.1 had created two

! Telnet connections, and host 10.1.1.2 created 1 more TCP connection.

ptg13046388

214 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

NAT# clear ip nat translations *

NAT# show ip nat translations

Pro Inside global Inside local Outside local Outside global

tcp 200.1.1.1:3212 10.1.1.1:3212 170.1.1.1:23 170.1.1.1:23

tcp 200.1.1.1:3213 10.1.1.1:3213 170.1.1.1:23 170.1.1.1:23

tcp 200.1.1.1:38913 10.1.1.2:38913 170.1.1.1:23 170.1.1.1:23

I P v 6

In the TCP/IP stack, IP is where packet sorting and delivery take place. At this layer, each

incoming or outgoing packet is referred to as a datagram . Each IP datagram bears the

source IP address of the sender and the destination IP address of the intended recipient.

Unlike MAC addresses, IP addresses in a datagram remain the same throughout a packet’s

journey across an internetwork.

As we have discussed before, the operation of IP is central to the TCP/IP stack—all other

TCP/IP protocols use IP—and all data passes through it. IP is a connectionless proto-

col and has some limitations. If IP attempts packet delivery and in the process a packet

is lost, delivered out of sequence, duplicated, or delayed, neither sender nor receiver is

informed. Packet acknowledgment is handled by a higher-layer transport protocol, such

as TCP, which we have discussed previously.

IP is responsible for addressing and routing packets between hosts, and determines

whether fragmentation is necessary. Fragmentation involves breaking a datagram into

smaller pieces for optimized routing. The IP protocol will fragment packets prior to send-

ing them and will also reassemble them when they reach their destination.

The issue with IP in the modern internetwork has more to do with capacity constraints

rather than operational issues. In short, we can best describe the Achilles heel of IP by

pointing out the fact that the Internet has grown so significantly over the decades that

there are not enough IP addresses to go around. We obviously are talking about IPv4

addresses. The version 4 address space, as discussed previously, is composed of ad -

dresses defined by a series of 32 bits broken up into four separate octets through the use

of “dotted decimal” notation. This means that we have a very finite number of addresses

available to use at the onset, and this limitation is further compounded by the fact that

many addresses in this total range have either been “reserved” for special operations or

“wasted” with regard to being inefficiently issued to users.

In short, we need another solution. That solution is the next generation IP that is being

widely adopted across the globe as we speak: IPv6. IP version 6 is considered to be the

best fit for the modern network because of the fact that it supports a substantially larger

address space to begin with. Whereas IPv4 addresses were 32 bits long, an IPv6 address

is 128 bits long. This means that the older IPv4 only supports a maximum of 2

32 IP

addresses, which translates to roughly 4.29 billion total addresses. IPv6, because it uti-

lizes 128 bits, supports a maximum of 2

128 available addresses:

340,282,366,920,938,463,463,374,607,431,768,211,456

ptg13046388

Chapter 4: IP Addressing 215

For those who care to know, that number would be read as 340 undecillion, 282 decil-

lion, 366 nonillion, 920 octillion, 938 septillion, 463 sextillion, 463 quintillion, 374 qua-

drillion, 607 trillion, 431 billion, 768 million, 211 thousand, and 456. For the rest of us,

we can just say it’s a very big number.

IPv6 introduces some new concepts with regard to how we annotate addresses and how

we implement and categorize address assignment.

IPv6 Address Format

IPv6 uses 16-byte hexadecimal number fields separated by colons (:) to represent the

128-bit addressing format that makes the address representation less cumbersome and

error-prone. Here is an example of a valid IPv6 address:

2001:db8:130F:0000:0000:09C0:876A:130B

Additionally, to shorten the IPv6 address and make the address easier to represent, IPv6

uses the following conventions:

■ Leading 0s in the address field are optional and can be compressed.

For example: The following hexadecimal numbers can be represented as shown in a

compressed format:

■ Example 1: 0000 = 0 (compressed form)

■ Example 2: 2001:db8:130F:0000:0000:09C0:876A:130B =

2001:db8:130F:0:0:9C0:876A:130B (compressed form)

■ A pair of colons (::) represents successive fields of 0. However, the pair of colons is

allowed just once in a valid IPv6 address.

■ Example 1: 2001:db8:130F:0:0:9C0:876A:130B = 2001:db8:130F::9C0:876A:130B

(compressed form)

■ Example 2: FF01:0:0:0:0:0:1 = FF01::1 (compressed form)

An address parser can easily identify the number of missing 0s in an IPv6 address by

separating the two parts of the address and filling in the 0s until the 128-bit address is

complete. However, if two pairs of colons are placed in the same address, there is no way

to identify the size of each block of 0s. The use of the :: makes many IPv6 addresses very

small.

Network Prefix

In IPv6, there are references to prefixes that, in IPv4 terms, loosely equate to subnets.

The IPv6 prefix is made up of the leftmost bits and acts as the network identifier. The

IPv6 prefix is represented using the IPv6-prefix or prefix-length format just like an IPv4

address is represented in the classless interdomain routing (CIDR) notation.

ptg13046388

216 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The / prefix-length variable is a decimal value that indicates the number of high-order

contiguous bits of the address that form the prefix, which is the network portion of

the address. For example, 2001:db8:8086:6502::/64 is an acceptable IPv6 prefix. If the

address ends in a double colon, the trailing double colon can be omitted. So the same

address can be written as 2001:db8:8086:6502/64. In either case, the prefix length is writ-

ten as a decimal number 64 and represents the leftmost bits of the IPv6 address. A similar

address in IPv4 would be xxx.xxx.xxx.xxx/16.

IPv6 Address Types

There is a major difference in the IP address requirements between an IPv4 host and an

IPv6 host. An IPv4 host typically uses one IP address, but an IPv6 host can have more

than one IP address.

There are three major types of IPv6 addresses:

■ Unicast: An address for a single interface. A packet that is sent to a unicast address is

delivered to the interface identified by that address.

■ Anycast: An address for a set of interfaces that typically belong to different nodes.

A packet sent to an anycast address is delivered to the closest interface, as defined by

the routing protocols in use and identified by the anycast address.

■ Multicast: An address for a set of interfaces (in a given scope) that typically belong

to different nodes. A packet sent to a multicast address is delivered to all interfaces

identified by the multicast address (in a given scope).

Note that in the context of IPv6, there is no concept of Broadcast.

Address Management and Assignment

There are four ways to configure a host address in IPv6:

■ Static Configuration: Similar to IPv4, the host address, mask, and gateway address

are manually defined.

■ Stateless Address Autoconfiguration (SLAAC): In this case, the host autonomously

configures its own address. Router solicitation messages are sent by booting nodes

to request Router Advertisements (RA) for configuring the interfaces (RFC 2462).

■ Stateful DHCPv6: The host uses Dynamic Host Configuration Protocol (DHCP) to

get its IPv6 address. This addressing management is similar to IPv4 behavior (RFC

3315).

■ Stateless DHCP: The host uses SLAAC and also DHCP to get additional parameters

such as TFTP Server, WINS, and so on.

The configuration choice relies on Router Advertisement (RA) flags sent by the router on

the LAN. The sections that follow take a cursory look at each of these methods.

ptg13046388

Chapter 4: IP Addressing 217

Static Configuration

As in IPv4, the host address can be statically defined. In this case, the IPv6 address,

mask, and gateway address are all manually defined on the host.

Static address configuration is typically used for router interface configuration but is not

likely to be used for hosts in IPv6. Keep in mind that using static configuration means

that all autoconfiguration features provided by IPv6 will be disabled.

Stateless Address Autoconfiguration

Nodes can use IPv6 Stateless Address Autoconfiguration to generate addresses without

the necessity of a DHCP server. IPv6 addresses are formed by combining network pre-

fixes with an interface identifier. On interfaces with embedded Institute of Electrical and

Electronics Engineers (IEEE) identifiers, the interface identifier is typically derived from

the IEEE identifier.

The address autoconfiguration feature is built into the IPv6 protocol to facilitate intranet-

wide address management that enables a large number of IP hosts to easily discover the

network and get new and globally unique IPv6 addresses associated with their location.

The autoconfiguration feature enables plug-and-play Internet deployment of new con-

sumer devices, such as cell phones, wireless devices, home appliances, and so on. As a

result, network devices can connect to the network without manual configuration and

without any servers, such as DHCP servers. We need to take a slightly closer look at the

principles behind this feature.

A router on a local link sends network-type information through RA messages, such as

the prefix of the local link and the default route in its router advertisements. The router

provides this information to all the nodes on the local link.

A host can then build its address by appending a host identifier to the /64 prefix received

from the router. As a result, Ethernet hosts can autoconfigure themselves by appending

their 48-bit link-layer address (MAC address) in an extended universal identifier EUI-64-

bit format to the 64 bits of the local link prefix advertised by the router.

Another hugely beneficial aspect to this approach is the ease with which address renum-

bering can be implemented. In IPv6 networks, the autoconfiguration feature makes

renumbering an existing network simple and relatively easy compared to IPv4. The router

sends the new prefix from the new upstream provider in its router announcements. The

hosts in the network automatically pick the new prefix from the router advertisements

and then use it to create their new addresses. As a result, the transition from provider A

to B becomes manageable for network operators.

Stateful DHCPv6

Many enterprises currently use DHCP to distribute addresses to their hosts. IPv6 can be

deployed with the same DHCP mechanism.

ptg13046388

218 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The process for acquiring configuration data for a client in IPv6 is similar to that in IPv4.

However, DHCPv6 uses multicast for many of its messages. Initially, the client must first

detect the presence of routers on the link using neighbor discovery messages. If a router

is found, the client examines the router advertisements to determine whether DHCP

should be used. If the router advertisements enable the use of DHCP on that link (dis-

abling the Autoconfiguration flag and enabling the Managed flag in RA messages allows

a host to use DHCPv6 to obtain an IPv6 address), the client starts a DHCP solicitation

phase to find a DHCP server.

Using DHCPv6 provides the following benefits:

■ More control than serverless/stateless autoconfiguration.

■ It can be used concurrently with stateless autoconfiguration.

■ It can be used for renumbering.

■ It can be used for automatic domain name registration of hosts using dynamic DNS.

■ It can be used to delegate the IPv6 prefix to leaf customer premises equipment (CPE)

routers.

Stateless DHCP

Stateless DHCPv6 normally combines stateless autoconfiguration for address assignment

with DHCPv6 exchange for all other configuration settings. In this case, DHCPv6 is only

used for the host to acquire additional parameters, such as a TFTP server, a DNS server,

and so on.

A host builds its address by appending a host identifier to the /64 prefix received from

the router and then issues a DHCP solicit message to the DHCP server.

IPv6 Transition Technologies

The success of IPv6 originally was thought to depend on the new applications that run

over it. However, it is becoming very clear that the exhaustion of IPv4 will ultimately end

up being the driver for IPv6 adoption. A key part of any good IPv6 design is its ability to

integrate into and coexist with existing IPv4 networks. IPv4 and IPv6 hosts need to coex-

ist for a substantial length of time during the steady migration from IPv4 to IPv6, and the

development of transition strategies, tools, and mechanisms has been part of the basic

IPv6 design from the start.

There are three IPv6 transition technologies: dual stack, tunneling, and translation.

Dual Stack

Dual stack is the basic strategy to use for large agencies that are adopting IPv6. It involves

configuring devices to be able to run IPv4 and IPv6 simultaneously. IPv4 communication

uses the IPv4 protocol stack, and IPv6 communication uses the IPv6 protocol stack.

ptg13046388

Chapter 4: IP Addressing 219

Applications choose between using IPv4 or IPv6 based on the response to DNS requests.

The application selects the correct address based on the type of IP traffic. Because dual

stack allows hosts to simultaneously reach existing IPv4 content and IPv6 content as it

becomes available, dual stack offers a very flexible adoption strategy. However, because

IPv4 addresses are still required, dual stack is not a long-term solution to address

exhaustion.

Dual stack also avoids the need to translate between protocol stacks. Translation is a valid

adoption mechanism, but it introduces operational complexity and lower performance.

Because a host automatically selects the right transport to use to reach a destination

based on DNS information, there should not be a need to translate between an IPv6 host

and an IPv4 server.

Tunneling

Tunnels encapsulate IPv6 traffic within IPv4 packets, and are primarily used for com-

munication between IPv6 (or dual stack) sites or for connection to remote IPv6 networks

or hosts over an IPv4 backbone. There are many different tunneling techniques, including

6to4, ISATAP, Teredo, 6PE, 6VPE, and mGRE v6 over v4. Tunnels can be manually con-

figured or automatically configured. Most modern operating systems include support for

tunneling in addition to dual stack.

Example 4-3 presents a simple 6to4 tunnel configuration.

Example 4-3 Dynamic 6to4 Tunnel Configuration

On R2

R2(config)# int tunnel 23

R2(config-if)# ipv6 addr 23::2/64

R2(config-if)# tunnel source lo0

R2(config-if)# tunnel destination 3.3.3.3

R2(config-if)# tunnel mode ipv6ip

You should see the following console message stating that the tunnel interface is

UP:

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel23, changed state

to up

On R3

R3(config)# int tunnel 32

R3(config-if)# ipv6 addr 23::3/64

R3(config-if)# tunnel source lo0

R3(config-if)# tunnel destination 2.2.2.2

R3(config-if)# tunnel mode ipv6ip

ptg13046388

220 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

You should see the following console message stating that the tunnel interface is

UP:

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel32, changed state

to up

On R2

R2# Ping 23::3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 23::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms

Translation

Address Family Translation (AFT) is the process of translating addresses from one

address family to another. During the adoption phase, AFT is primarily used to translate

between IPv6 hosts and IPv4 content. AFT can be stateless, where reserved portions

of the IPv6 address space are automatically mapped to IPv4, or it can be stateful, with

addresses from a configured range used to map packets between address families.

Nearly all enterprise deployments of IPv6 use dual stack internally. Dual stack offers a

nondisruptive way to learn about and gain operational experience with a new address

family, which is an important part of successfully managing the transition.

Pilots and trials depend on specific requirements.

ptg13046388

Chapter 4: IP Addressing 221

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter, as well as review items noted with a Key Topic icon.

Table 4-14 lists and briefly explains several variations on NAT.

Table 4-14 Variations on NAT

Name Function

Static NAT Statically correlates the same public IP address for use by the

same local host every time. Does not conserve IP addresses.

Dynamic NAT Pools the available public IP addresses, shared among a group

of local hosts, but with only one local host at a time using a

public IP address. Does not conserve IP addresses.

Dynamic NAT with overload

(PAT)

Like dynamic NAT, but multiple local hosts share a single

public IP address by multiplexing using TCP and UDP port

numbers. Conserves IP addresses.

NAT for overlapping address Can be done with any of the first three types. Translates both

source and destination addresses, instead of just the source

(for packets going from enterprise to the Internet).

Table 4-15 lists the protocols mentioned in this chapter and their respective standards

documents.

Table 4-15 Protocols and Standards for Chapter 4

Name Standardized In

IP RFC 791

Subnetting RFC 950

NAT RFC 1631

Private addressing RFC 1918

CIDR RFCs 1517–1520

DHCPv6 RFC 3315

Internet Protocol version 6 (IPv6) Addressing Architecture RFC 3513

IPv6 Global Unicast Address Format RFC 3587

Key

Topic

Key

Topic

ptg13046388

222 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-16 lists and describes some of the most commonly used IOS commands related

to the topics in this chapter.

Table 4-16 Command Reference for Chapter 4

Command Description

ip address ip-address mask [ secondary ] Interface subcommand to assign an IPv4

address

ip nat { inside | outside } Interface subcommand; identifies inside or

outside part of network

ip nat inside source { list { access-list-

number | access-list-name } | route-map

name } { interface type number | pool

pool-name } [ overload ]

Global command that defines the set of inside

addresses for which NAT will be performed,

and corresponding outside addresses

ip nat inside destination list { access-list-

number | name } pool name

Global command used with destination NAT

ip nat outside source { list { access-list-

number | access-list-name } | route-map

name } pool pool-name [ add-route ]

Global command used with both destination

and dynamic NAT

ip nat pool name start-ip end-ip { netmask

netmask | prefix-length prefix-length }

[ type rotary ]

Global command to create a pool of addresses

for dynamic NAT

show ip nat statistics Lists counters for packets and for NAT

table entries, as well as basic configuration

information

show ip nat translations [ verbose ] Displays the NAT table

clear ip nat translation { * | [ inside global-ip

local-ip ] [ outside local-ip global-ip ]}

Clears all or some of the dynamic entries in

the NAT table, depending on which parameters

are used

debug ip nat Issues log messages describing each packet

whose IP address is translated with NAT

show ip interface [ type number ] [ brief ] Lists information about IPv4 on interfaces

Figure 4-8 shows the IP header format.

1st 3 bytes

of MAC FFFE 2nd 3 bytes

of MAC

Subnet ID

16 bits

64 bits, EUI-64 format

48 bits

Begins with binary 001, meaning

the initial hex digit is 2 or 3

Inverts bit 7 of MAC when

creating the IPv6 address

Interface IDGlobal Routing Prefix

Figure 4-8 I P H e a d e r

ptg13046388

Chapter 4: IP Addressing 223

Table 4-17 lists the terms and meanings of the fields inside the IP header.

Table 4-17 IP Header Fields

Field Meaning

Version Version of the IP protocol. Most networks use IPv4 today, with IPv6

becoming more popular. The header format reflects IPv4.

Header Length Defines the length of the IP header, including optional fields. Because

the length of the IP header must always be a multiple of 4, the IP header

length (IHL) is multiplied by 4 to give the actual number of bytes.

DS Field Differentiated Services Field. This byte was originally called the Type of

Service (ToS) byte, but was redefined by RFC 2474 as the DS Field. It is

used for marking packets for the purpose of applying different quality of

service (QoS) levels to different packets.

Packet Length Identifies the entire length of the IP packet, including the data.

Identification Used by the IP packet fragmentation process. If a single packet is

fragmented into multiple packets, all fragments of the original packet

contain the same identifier so that the original packet can be reassembled.

Flags 3 bits used by the IP packet fragmentation process.

Fragment Offset A number set in a fragment of a larger packet that identifies the fragment’s

location in the larger original packet.

Time to Live

(TTL)

A value used to prevent routing loops. Routers decrement this field by 1

each time the packet is forwarded; when it decrements to 0, the packet is

discarded.

Protocol A field that identifies the contents of the data portion of the IP packet.

For example, protocol 6 implies that a TCP header is the first thing in the

IP packet data field.

Header

Checksum

A value used to store a frame check sequence (FCS) value, whose purpose

is to determine whether any bit errors occurred in the IP header (not the

data) during transmission.

Source IP

Address

The 32-bit IP address of the sender of the packet.

Destination IP

Address

The 32-bit IP address of the intended recipient of the packet.

Optional Header

Fields and

Padding

IP supports additional header fields for future expansion through optional

headers. Also, if these optional headers do not use a multiple of 4 bytes,

padding bytes are added, composed of all binary 0s, so that the header is

a multiple of 4 bytes in length.

Table 4-18 lists some of the more common IP protocol field values.

Key

Topic

ptg13046388

224 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-18 IP Protocol Field Values

Protocol Name Protocol Number

ICMP 1

TCP 6

UDP 17

EIGRP 88

OSPF 89

PIM 103

Figure 4-9 Illustrates an IPv6 header.

Version

Length

765

DiffServ Code Point (DSCP) Flow Ctrl

Unused Standard IPv4

DiffServ Extensions

IP Precedence

43210

Len ID Offset TTL Proto FCS IP SA IP DA Data

IPv4 Packet

To S

Byte

Figure 4-9 IPv6 Header

Table 4-19 lists the terms and meanings for the fields in the header illustration.

Table 4-19 IPv6 Header Fields

Field Meaning

Version 4 bits. IPv6 version number.

Traffic Class 8 bits. Internet traffic priority delivery value.

Flow Label 20 bits. Used for specifying special router handling from the source

to the destination(s) for a sequence of packets.

Payload Length 16 bits. Specifies the length of the data in the packet. When cleared

to 0, the option is a hop-by-hop Jumbo payload.

Next Header 8 bits. Specifies the next encapsulated protocol. The values are

compatible with those specified for the IPv4 protocol field.

Hop Limit 8 bits. For each router that forwards the packet, the hop limit is

decremented by 1. When the hop limit field reaches 0, the packet is

discarded. This replaces the TTL field in the IPv4 header that was

originally intended to be used as a time-based hop limit.

Source Address 16 bytes. The IPv6 address of the sending node.

Destination Address 16 bytes. The IPv6 address of the destination node.

Key

Topic

ptg13046388

Chapter 4: IP Addressing 225

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Fill in Key Tables from Memory

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD to check your answers.

Definitions

Next, take a few moments to write the definitions for the following terms:

subnet, prefix, classless IP addressing, classful IP addressing, CIDR, NAT, IPv4,

subnet broadcast address, subnet number, subnet zero, broadcast subnet, subnet

mask, private addresses, SLSM, VLSM, Inside Local address, Inside Global address,

Outside Local address, Outside Global address, PAT, overloading, quartet, IPv6, 6to4

Tunnel, ISATAP, DHCPv6, AFT

Refer to the glossary to check your answers.

Further Reading

All topics in this chapter are covered in varying depth for the CCNP Routing exam.

For more details on these topics, look for the CCNP routing study guides at

www.ciscopress.com/ccnp .

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the Cisco

CCIE Routing and Switching written exam blueprint. Refer

to the full blueprint in Table I-1 in the Introduction for more

details on the topics covered in each chapter and their con-

text within the blueprint.

■ Hot Standby Router Protocol (HSRP)

■ Gateway Load Balancing Protocol (GLBP)

■ Virtual Router Redundancy Protocol (VRRP)

■ Dynamic Host Configuration Protocol (DHCP)

■ Network Time Protocol (NTP)

■ Web Cache Communication Protocol (WCCP)

■ Network Management

■ Logging and Syslog

■ Troubleshoot Network Services

■ Implement IP Service Level Agreement (IP SLA)

■ Object Tracking

■ Implement NetFlow

■ Implement Router IP Traffic Export (RITE)

■ Implement SNMP

■ Implement Cisco IOS Embedded Event Manager (EEM)

■ Implement Remote Monitoring (RMON)

■ Implement FTP

■ Implement TFTP

■ Implement TFTP Server on Router

■ Implement Secure Copy Protocol (SCP)

■ Implement HTTP and HTTPS

■ Implement Telnet

■ Implement SSH

ptg13046388

IP relies on several protocols to perform a variety of tasks related to the process of rout-

ing packets. This chapter provides a reference for the most popular of these protocols. In

addition, this chapter covers a number of management-related protocols and other blue-

print topics related to IP services.

“Do I Know This Already?” Quiz

Table 5-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 5-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in

This Section

S c o r e

ARP, Proxy ARP, Reverse ARP, BOOTP, and DHCP 1–3

HSRP, VRRP, and GLBP 4–6

Network Time Protocol 7

SNMP 8–9

Web Cache Communication Protocol 10–11

Implement SSH 12

Implement SSH, HTTPS, FTP, SCP, TFTP 13

Implement RMON 14

Implement IP SLA, NetFlow, RITE, EEM 15

Total Score

CHAPTER 5

IP Services

ptg13046388

228 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. Two hosts, named PC1 and PC2, sit on subnet 172.16.1.0/24, along with Router R1.

A web server sits on subnet 172.16.2.0/24, which is connected to another interface of

R1. At some point, both PC1 and PC2 send an ARP request before they successfully

send packets to the web server. With PC1, R1 makes a normal ARP reply, but for

PC2, R1 uses a proxy ARP reply. Which two of the following answers could be true

given the stated behavior in this network?

a. PC2 set the proxy flag in the ARP request.

b. PC2 encapsulated the ARP request inside an IP packet.

c. PC2’s ARP broadcast implied that PC2 was looking for the web server’s MAC

address.

d. PC2 has a subnet mask of 255.255.0.0.

e. R1’s proxy ARP reply contains the web server’s MAC address.

2. Host PC3 is using DHCP to discover its IP address. Only one router attaches to

PC3’s subnet, using its fa0/0 interface, with an ip helper-address 10.5.5.5 com-

mand on that same interface. That same router interface has an ip address 10.4.5.6

255.255.252.0 command configured as well. Which of the following are true about

PC3’s DHCP request?

a. The destination IP address of the DHCP request packet is set to 10.5.5.5 by the

router.

b. The DHCP request packet’s source IP address is unchanged by the router.

c. The DHCP request is encapsulated inside a new IP packet, with source IP

address 10.4.5.6 and destination 10.5.5.5.

d. The DHCP request’s source IP address is changed to 10.4.5.255.

e. The DHCP request’s source IP address is changed to 10.4.7.255.

3. Which of the following statements are true about BOOTP, but not true about

RARP?

a. The client can be assigned a different IP address on different occasions, because

the server can allocate a pool of IP addresses for allocation to a set of clients.

b. The server can be on a different subnet from the client.

c. The client’s MAC address must be configured on the server, with a one-to-one

mapping to the IP address to be assigned to the client with that MAC address.

d. The client can discover its IP address, subnet mask, and default gateway IP

address.

ptg13046388

Chapter 5: IP Services 229

4. R1 is HSRP active for virtual IP address 172.16.1.1, with HSRP priority set to 115. R1

is tracking three separate interfaces. An engineer configures the same HSRP group

on R2, also connected to the same subnet, only using the standby 1 ip 172.16.1.1

command, and no other HSRP-related commands. Which of the following would

cause R2 to take over as HSRP active?

a. R1 experiences failures on tracked interfaces, totaling 16 or more lost points.

b. R1 experiences failures on tracked interfaces, totaling 15 or more lost points.

c. R2 could configure a priority of 116 or greater.

d. R1’s fa0/0 interface fails.

e. R2 would take over immediately.

5. Which Cisco IOS feature does HSRP, GLBP, and VRRP use to determine when an

interface fails for active switching purposes?

a. Each protocol has a built-in method of tracking interfaces.

b. When a physical interface goes down, the redundancy protocol uses this auto-

matically as a basis for switching.

c. Each protocol uses its own hello mechanism for determining which interfaces

are up or down.

d. The Cisco IOS object tracking feature.

6. Which is the correct term for using more than one HSRP group to provide load bal-

ancing for HSRP?

a. LBHSRP

b. LSHSRP

c. RHSRP

d. MHSRP

e. None of these is correct. HSRP does not support load balancing.

7. Which of the following NTP modes in a Cisco router requires a predefinition of the

IP address of an NTP server?

a. Server mode

b. Static client mode

c. Broadcast client mode

d. S y m m e t r i c a c t i v e m o d e

ptg13046388

230 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

8. Which of the following are true about SNMP security?

a. SNMP Version 1 calls for the use of community strings that are passed as clear

text.

b. SNMP Version 2c calls for the use of community strings that are passed as

MD5 message digests generated with private keys.

c. SNMP Version 3 allows for authentication using MD5 message digests gener-

ated with private keys.

d. SNMP Version 3 authentication also requires concurrent use of encryption,

typically done with DES.

9. Which of the following statements are true regarding features of SNMP based on

the SNMP version?

a. SNMP Version 2 added the GetNext protocol message to SNMP.

b. SNMP Version 3 added the Inform protocol message to SNMP.

c. SNMP Version 2 added the Inform protocol message to SNMP.

d. SNMP Version 3 expanded the SNMP Response protocol message so that it

must be used by managers in response to Traps sent by agents.

e. SNMP Version 3 enhanced SNMP Version 2 security features but not other

features.

10. WCCP uses what protocol and port for communication between content engines

and WCCP routers?

a. UDP 2048

b. TCP 2048

c. UDP 4082

d. TCP 4082

11. In a WCCP cluster, which content engine becomes the lead engine after the cluster

stabilizes?

a. The content engine with the lowest IP address.

b. The content engine with the highest IP address.

c. There is no such thing as a lead content engine; the correct term is designated

content engine.

d. All content engines have equal precedence for redundancy and the fastest pos-

sible load sharing.

ptg13046388

Chapter 5: IP Services 231

12. Which configuration commands are required to enable SSH on a router?

a. hostname

b. ip domain-name

c. ip ssh

d. crypto key generate rsa

e. http secure-server

13. Which protocol is the most secure choice, natively, for transferring files from a

router?

a. SSH

b. HTTPS

c. FTP

d. TFTP

e. S C P

14. In RMON, which type of configured option includes rising and falling thresholds,

either relative or absolute, and is monitored by another type of RMON option?

a. Event

b. Alert

c. Notification

d. P o r t

e. P r o b e

15. Which Cisco IOS feature permits end-to-end network performance monitoring with

configuration on devices at each end of the network?

a. Flexible NetFlow

b. IP SLA

c. EEM

d. RITE

ptg13046388

232 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Foundation Topics

ARP, Proxy ARP, Reverse ARP, BOOTP, and DHCP

The heading for this section might seem like a laundry list of a lot of different protocols.

However, these five protocols do have one central theme, namely, that they help a host

learn information so that it can successfully send and receive IP packets. Specifically,

Address Resolution Protocol (ARP) and proxy ARP define methods for a host to learn

another host’s MAC address, whereas the core functions of Reverse ARP (RARP),

Bootstrap Protocol (BOOTP), and DHCP define how a host can discover its own IP

address, plus additional related information.

ARP and Proxy ARP

You would imagine that anyone getting this far in his CCIE study would already have a

solid understanding of the Address Resolution Protocol (ARP, RFC 826). However, proxy

ARP (RFC 1027) is often ignored, in part because of its lack of use today. To see how

they both work, Figure 5-1 shows an example of each, with Fred and Barney both trying

to reach the web server at IP address 10.1.2.200.

ARP Reply

Source = R1-E1-MAC Web Server:

10.1.2.200/24

GW = 10.1.2.1

Interface: E1

MAC: R1-E1-MAC

10.1.1.1/24

Barney: 10.1.1.102

Mask: /8

GW = 10.1.1.1

Fred: 10.1.1.101

Mask: /24

GW = 10.1.1.1

Interface: E2

MAC: R1-E2-MAC

10.1.2.1/24

DHCP Server:

10.1.2.202/24

DNS Server:

10.1.2.203/24

ARP Request

Target = 10.1.1.1

ARP Reply

Source = R1-E1-MAC

Proxy logic

used by R1!

ARP Request

Target = 10.1.2.200

Figure 5-1 Comparing ARP and Proxy ARP

Fred follows a normal ARP process, broadcasting an ARP request, with R1’s E1 IP address

as the target. The ARP message has a Target field of all 0s for the MAC address that

needs to be learned, and a target IP address of the IP address whose MAC address it is

searching, namely, 10.1.1.1 in this case. The ARP reply lists the MAC address associated

with the IP address, in this case, the MAC address of R1’s E1 interface.

ptg13046388

Chapter 5: IP Services 233

Note The ARP message itself does not include an IP header, although it does have des-

tination and source IP addresses in the same relative position as an IP header. The ARP

request lists an IP destination of 255.255.255.255. The ARP Ethernet protocol type is

0x0806, whereas IP packets have an Ethernet protocol type of 0x0800.

Proxy ARP uses the exact same ARP message as ARP, but the ARP request is actually

requesting a MAC address that is not on the local subnet. Because the ARP request is

broadcast on the local subnet, it will not be heard by the target host—so if a router can

route packets to that target host, the router issues a proxy ARP reply on behalf of that

target.

For example, Barney places the web server’s IP address (10.1.2.200) in the Target field,

because Barney thinks that he is on the same subnet as the web server because of

Barney’s mask of 255.0.0.0. The ARP request is a LAN broadcast, so R1, being a well-

behaved router, does not forward the ARP broadcast. However, knowing that the ARP

request will never get to the subnet where 10.1.2.200 resides, R1 saves the day by replying

to the ARP on behalf of the web server. R1 takes the web server’s place in the ARP pro-

cess, hence the name proxy ARP. Also, note that R1’s ARP reply contains R1’s E1 MAC

address, so that Barney will forward frames to R1 when Barney wants to send a packet to

the web server.

Before the advent of DHCP, many networks relied on proxy ARP, configuring hosts to

use the default masks in their respective networks. Regardless of whether the proxy ver-

sion is used, the end result is that the host learns a router’s MAC address to forward pack-

ets to another subnet.

RARP, BOOTP, and DHCP

The ARP and proxy ARP processes both occur after a host knows its IP address and

subnet mask. RARP, BOOTP, and DHCP represent the evolution of protocols defined to

help a host dynamically learn its IP address. All three protocols require the client host to

send a broadcast to begin discovery, and all three rely on a server to hear the request and

supply an IP address to the client. Figure 5-2 shows the basic processes with RARP and

BOOTP.

A RARP request is a host’s attempt to find its own IP address. So RARP uses the same

old ARP message, but the ARP request lists a MAC address target of its own MAC

address and a target IP address of 0.0.0.0. A preconfigured RARP server, which must be

on the same subnet as the client, receives the request and performs a table lookup in its

configuration. If that target MAC address listed in the ARP request is configured on

the RARP server, the RARP server sends an ARP reply, after entering the configured IP

address in the Source IP address field.

ptg13046388

234 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

BOOTP was defined in part to improve IP address assignment features of RARP. BOOTP

uses a completely different set of messages, defined by RFC 951, with the commands

encapsulated inside an IP and UDP header. With the correct router configuration, a

router can forward the BOOTP packets to other subnets—allowing the deployment of a

centrally located BOOTP server. Also, BOOTP supports the assignment of many other

tidbits of information, including the subnet mask, default gateway, DNS addresses, and

its namesake, the IP address of a boot (or image) server. However, BOOTP does not solve

the configuration burden of RARP, still requiring that the server be preconfigured with

the MAC addresses and IP addresses of each client.

DHCP

DHCP represents the next step in the evolution of dynamic IP address assignment.

Building on the format of BOOTP protocols, DHCP focuses on dynamically assigning

a variety of information and provides flexible messaging to allow for future changes,

without requiring predefinition of MAC addresses for each client. DHCP also includes

temporary leasing of IP addresses, enabling address reclamation, pooling of IP addresses,

and, recently, dynamic registration of client Domain Name System (DNS) fully qualified

domain names (FQDN). (See www.ietf.org for more information on FQDN registration.)

DHCP servers typically reside in a centralized location, with remote routers forwarding

the LAN-broadcast DHCP requests to the DHCP server by changing the request’s desti-

nation address to match the DHCP server. This feature is called DHCP relay agent. For

example, in Figure 5-1 , if Fred and Barney were to use DHCP, with the DHCP server at

10.1.2.202, R1 would change Fred’s DHCP request from a destination of 255.255.255.255

to a destination of 10.1.2.202. R1 would also list its own IP address in the message, in the

gateway IP address (giaddr) field, notifying the DHCP server of the IP address to which

Key

Topic

Hannah

IP: ?.?.?.?

MAC: 0200.1111.1111

Hey Everybody! My MAC Address Is

0200.1111.1111. If You Are a RARP

Server, Please Tell Me My IP Address!

1 RARP Broadcast

RARP Reply

MAC

0200.1111.1111 10.1.1.1

0200.1234.5678 10.1.1.2

0200.5432.1111 10.1.1.3

Configuration

RARP

Your IP Address Is

10.1.1.1

RARP Server

Hannah

IP: ?.?.?.?

MAC: 0200.1111.1111

MAC IP

Gateway

0200.1111.1111 10.1.1.1

0200.1234.5678 10.1.1.2

0200.5432.1111 10.1.1.3

10.1.1.200

Hey Everybody! My MAC Address Is

0200.1111.1111. If You Are a BOOTP

Server, Please Tell Me My IP Address!

1BOOTP Broadcast

BOOTP Reply

Configuration

10.1.1.200

BOOTP

Your IP Address Is 10.1.1.1

Your Default Gateway Is 10.1.1.200

…

BOOTP Server

Figure 5-2 RARP and BOOTP—Basic Processes

Key

Topic

ptg13046388

Chapter 5: IP Services 235

the response should be sent. After receiving the next DHCP message from the server,

R1 would change the destination IP address to a LAN broadcast, and forward the packet

onto the client’s LAN. The only configuration requirement on the router is an ip helper-

address 10.1.2.202 interface subcommand on its E1 interface.

Alternatively, R1 could be configured as a DHCP server—a feature that is not often con-

figured on routers in production networks but is certainly fair game for the CCIE written

and lab exams. Configuring DHCP on a router consists of several required steps:

Step 1. Configure a DHCP pool.

Step 2. Configure the router to exclude its own IP address from the DHCP pool.

Step 3. Disable DHCP conflict logging or configure a DHCP database agent.

The DHCP pool includes key items such as the subnet (using the network command

within DHCP pool configuration), default gateway ( default-router ), and the length of

time for which the DHCP lease is valid ( lease ). Other items, including the DNS domain

name and any DHCP options, are also defined within the DHCP pool.

Although not strictly necessary in DHCP configuration, it is certainly a best practice to

configure the router to make its own IP address in the DHCP pool subnet unavailable for

allocation through DHCP. The same is true for any other static IP addresses within the

DHCP pool range, such as those of servers and other routers. Exclude host IP addresses

from the DHCP process using the ip dhcp excluded-address command.

Note The ip dhcp excluded-address command is one of the relatively few Cisco IOS ip

commands that is a global configuration command rather than an interface command.

The Cisco IOS DHCP server also provides a mechanism for logging DHCP address con-

flicts to a central server called a DHCP database agent. IOS requires that you either dis-

able conflict logging by using the no ip dhcp conflict-logging command or configure a

DHCP database agent on a server by using the ip dhcp database command. Example 5-1

shows R1’s configuration for a DHCP relay agent, as well as an alternative for R1 to pro-

vide DNS services for subnet 10.1.1.0/24.

Example 5-1 DHCP Configuration Options—R1, Figure 5-1

! UDP broadcasts coming in E0 will be forwarded as unicasts to 10.1.2.202.

! The source IP will be changed to 10.1.1.255, so that the reply packets will be

! broadcast back out E0.

interface Ethernet1

ip address 10.1.1.1 255.255.255.0

ip helper-address 10.1.2.202

! Below, an alternative configuration, with R1 as the DHCP server. R1 assigns IP

! addresses other than the excluded first 20 IP addresses in the subnet, and

! informs the clients of their IP addresses, mask, DNS, and default router. Leases

ptg13046388

236 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! are for 0 days, 0 hours, and 20 minutes.

ip dhcp excluded-address 10.1.1.0 10.1.1.20

ip dhcp pool subnet1

network 10.1.1.0 255.255.255.0

dns-server 10.1.2.203

default-router 10.1.1.1

lease 0 0 20

Table 5-2 summarizes some of the key comparison points with RARP, BOOTP, and

DHCP.

Table 5-2 Comparing RARP, BOOTP, and DHCP

Feature RARP BOOTP DHCP

Relies on server to allocate IP addresses Yes Yes Yes

Encapsulates messages inside IP and UDP so that they can be

forwarded to a remote server

No Yes Yes

Client can discover its own mask, gateway, DNS, and

download server

No Yes Yes

Dynamic address assignment from a pool of IP addresses,

without requiring knowledge of client MACs

N o N o Ye s

Allows temporary lease of IP address No No Yes

Includes extensions for registering client’s FQDN with a DNS No No Yes

HSRP, VRRP, and GLBP

IP hosts can use several methods of deciding which default router or default gateway to

use—DHCP, BOOTP, ICMP Router Discovery Protocol (IRDP), manual configuration,

or even by running a routing protocol (although having hosts run a routing protocol

is not common today). The most typical methods—using DHCP or manual configura-

tion—result in the host knowing a single IP address of its default gateway. Hot Standby

Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and Gateway

Load Balancing Protocol (GLBP) represent a chronological list of some of the best tools

for overcoming the issues related to a host knowing a single IP address as its path to get

outside the subnet.

Key

Topic

ptg13046388

Chapter 5: IP Services 237

HSRP allows multiple routers to share a virtual IP and MAC address so that the end-user

hosts do not realize when a failure occurs. Some of the key HSRP features are as follows:

■ Virtual IP address and virtual MAC are active on the HSRP Active router.

■ Standby routers listen for Hellos from the Active router, defaulting to a 3-second

hello interval and 10-second dead interval.

■ Highest priority (IOS default 100, range 1–255) determines the Active router, with

preemption disabled by default.

■ Supports tracking, whereby a router’s priority is decreased when a tracked object

(interface or route) fails.

■ Up to 255 HSRP groups per interface, enabling an administrative form of load bal-

ancing.

■ Virtual MAC of 0000.0C07.ACxx, where xx is the hex HSRP group.

■ Virtual IP address must be in the same subnet as the routers’ interfaces on the same

LAN.

■ Virtual IP address must be different from any of the routers’ individual interface IP

addresses.

■ Supports clear-text and MD5 authentication (through a key chain).

Example 5-2 shows a typical HSRP configuration, with two groups configured. Routers

R1 and R2 are attached to the same subnet, 10.1.1.0/24, both with WAN links (S0/0.1)

connecting them to the rest of an enterprise network. Cisco IOS provides the tracking

mechanism shown in Example 5-2 to permit many processes, including HSRP, VRRP, and

GLBP, to track interface states. A tracking object can track based on the line protocol

(shown here) or the IP routing table. The example contains the details and explanation of

the configuration.

Example 5-2 HSRP Configuration

! First, on Router R1, a tracking object must be configured so that

! HSRP can track the interface state.

track 13 interface Serial0/0.1 line-protocol

! Next, on Router R1, two HSRP groups are configured. R1 has a higher priority

! in group 21, with R2 having a higher priority in group 22. R1 is set to preempt

! in group 21, as well as to track interface s0/0.1 for both groups.

interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.0

standby 21 ip 10.1.1.21

continues

standby 21 priority 105

standby 21 preempt

standby 21 track 13

standby 22 ip 10.1.1.22

Key

Topic

Key

Topic

ptg13046388

238 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

standby 22 track 13

! Next, R2 is configured with a higher priority for HSRP group 22, and with

! HSRP tracking enabled in both groups. The tracking "decrement" used by R2,

! when S0/0.1 fails, is set to 9 (instead of the default of 10).

! A tracking object must be configured first, as on R1.

track 23 interface Serial0/0.1 line-protocol

interface FastEthernet0/0

ip address 10.1.1.2 255.255.255.0

standby 21 ip 10.1.1.21

standby 21 track 23

standby 22 ip 10.1.1.22

standby 22 priority 105

standby 22 track 23 decrement 9

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! On R1 below, for group 21, the output shows that R1 is active, with R2

! (10.1.1.2) as standby.

! R1 is tracking s0/0.1, with a default "decrement" of 10, meaning that the

! configured priority of 105 will be decremented by 10 if s0/0.1 fails.

Router1# sh standby fa0/0

FastEthernet0/0 - Group 21

State is Active

2 state changes, last state change 00:00:45

Virtual IP address is 10.1.1.21

Active virtual MAC address is 0000.0c07.ac15

Local virtual MAC address is 0000.0c07.ac15 (v1 default)

Hello time 3 sec, hold time 10 sec

Next hello sent in 2.900 secs

Preemption enabled

Active router is local

Standby router is 10.1.1.2, priority 100 (expires in 7.897 sec)

Priority 105 (configured 105)

Track object 13 state Up decrement 10

IP redundancy name is "hsrp-Fa0/0-21" (default)

! output omitted

! NOT SHOWN—R1 shuts down S0.0.1, lowering its priority in group 21 by 10.

! The debug below shows the reduced priority value. However, R2 does not become

! active, because R2's configuration did not include a standby 21 preempt command.

Router1# debug standby

*Mar 1 00:24:04.122: HSRP: Fa0/0 Grp 21 Hello out 10.1.1.1 Active pri 95 vIP

10.1.1.21

ptg13046388

Chapter 5: IP Services 239

Because HSRP uses only one Active router at a time, any other HSRP routers are idle.

To provide load sharing in an HSRP configuration, the concept of Multiple HSRP, or

MHSRP, was developed. In MHSRP, two or more HSRP groups are configured on each

HSRP LAN interface, where the configured priority determines which router will be

active for each HSRP group.

MHSRP requires that each DHCP client and statically configured host are issued a

default gateway corresponding to one of the HSRP groups and requires that they’re

distributed appropriately. Thus, in an MHSRP configuration with two routers and two

groups, all other things being equal, half of the hosts should have one HSRP group

address as its default gateway, and the other half of the hosts should use the other HSRP

group address. If you now revisit Example 5-2 , you will see that it is an MHSRP configu-

ration.

HSRP is Cisco proprietary, has been out a long time, and is widely popular. VRRP (RFC

3768) provides a standardized protocol to perform almost the exact same function. The

Cisco VRRP implementation has the same goals in mind as HSRP but with these differ-

ences:

■ VRRP uses a multicast virtual MAC address (0000.5E00.01 xx , where xx is the hex

VRRP group number).

■ VRRP uses the IOS object tracking feature, rather than its own internal tracking

mechanism, to track interface states for failover purposes.

■ VRRP defaults to use preemption, but HSRP defaults to not use preemption. Both

can be configured to either use preemption or not.

■ The VRRP term Master means the same thing as the HSRP term Active .

■ In VRRP, the VRRP group IP address is the interface IP address of one of the VRRP

routers.

GLBP is a newer Cisco-proprietary tool that adds load-balancing features in addition

to gateway-redundancy features. Hosts still point to a default gateway IP address, but

GLBP causes different hosts to send their traffic to one of up to four routers in a GLBP

group. To do so, the GLBP Active Virtual Gateway (AVG) assigns each router in the

group a unique virtual MAC address, following the format 0007.B400. xxyy , where xx

is the GLBP group number and yy is a different number for each router (01, 02, 03, or

04). When a client ARPs for the (virtual) IP address of its default gateway, the GLBP AVG

replies with one of the four possible virtual MACs. By replying to ARP requests with dif-

ferent virtual MACs, the hosts in that subnet will in effect balance the traffic across the

routers, rather than send all traffic to the one active router.

Cisco IOS devices with GLBP support permit configuring up to 1024 GLBP groups per

physical interface and up to four hosts per GLBP group.

Key

Topic

Key

Topic

ptg13046388

240 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Network Time Protocol

NTP Version 3 (RFC 1305) allows IP hosts to synchronize their time-of-day clocks with a

common source clock. For example, routers and switches can synchronize their clocks to

make event correlation from an SNMP management station more meaningful, by ensuring

that any events and traps have accurate time stamps.

By design, most routers and switches use NTP client mode , adjusting their clocks based

on the time as known by an NTP server. NTP defines the messages that flow between cli-

ent and server, and the algorithms a client uses to adjust its clock. Routers and switches

can also be configured as NTP servers, as well as using NTP symmetric active mode —a

mode in which the router or switch mutually synchronizes with another NTP host.

NTP servers can reference other NTP servers to obtain a more accurate clock source as

defined by the stratum level of the ultimate source clock. For example, atomic clocks

and Global Positioning System (GPS) satellite transmissions provide a source of stratum 1

(lowest/best possible stratum level). For an enterprise network, the routers and switches

can refer to a low-stratum NTP source on the Internet, or purpose-built rack-mounted

NTP servers, with built-in GPS capabilities, can be deployed.

Example 5-3 shows a sample NTP configuration on four routers, all sharing the same

10.1.1.0/24 Ethernet subnet. Router R1 will be configured as an NTP server. R2 acts as an

NTP static client by virtue of the static configuration referencing R1’s IP address. R3 acts

as an NTP broadcast client by listening for R1’s NTP broadcasts on the Ethernet. Finally,

R4 acts in NTP symmetric active mode, configured with the ntp peer command.

Example 5-3 NTP Configuration

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! First, R1's configuration, the ntp broadcast command under interface fa0/0

! causes NTP to broadcast NTP updates on that interface. The first three of the

! four global NTP commands configure authentication; these commands are identical

! on all the routers.

R1# show running-config

interface FastEthernet0/0

ntp broadcast

ntp authentication-key 1 md5 1514190900 7

ntp authenticate

ntp trusted-key 1

ntp master 7

! Below, the "127.127.7.1" notation implies that this router is the NTP clock

! source. The clock is synchronized, with stratum level 7, as configured on the

! ntp master 7 command above.

R1# show ntp associations

Key

Topic

ptg13046388

Chapter 5: IP Services 241

address ref clock st when poll reach delay offset disp

*~127.127.7.1 127.127.7.1 6 22 64 377 0.0 0.00 0.0

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

R1# show ntp status

Clock is synchronized, stratum 7, reference is 127.127.7.1

nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz, precision is 2**16

reference time is C54483CC.E26EE853 (13:49:00.884 UTC Tue Nov 16 2004)

clock offset is 0.0000 msec, root delay is 0.00 msec

root dispersion is 0.02 msec, peer dispersion is 0.02 msec

! R2 is configured below as an NTP static client. Note that the ntp clock-period

! command is automatically generated as part of the synchronization process, and

! should not be added to the configuration manually.

R2# show run | begin ntp

ntp authentication-key 1 md5 1514190900 7

ntp authenticate

ntp trusted-key 1

ntp clock-period 17208144

ntp server 10.1.1.1

end

! Next, R3 has been configured as an NTP broadcast client. The ntp broadcast client

! command on R3 tells it to listen for the broadcasts from R1. This configuration

! relies on the ntp broadcast subcommand on R1's Fa0/0 interface, as shown at the

! beginning of this example.

R3# show run

interface Ethernet0/0

ntp broadcast client

! R4's configuration is listed, with the ntp peer

! command implying the use of symmetric active mode.

R4# show run | beg ntp

ntp authentication-key 1 md5 0002010300 7

ntp authenticate

ntp trusted-key 1

ntp clock-period 17208233

ntp peer 10.1.1.1

SNMP

This section of the chapter summarizes some of the core Simple Network Management

Protocol (SNMP) concepts and details, particularly with regard to features of differ-

ent SNMP versions. SNMP or, more formally, the Internet Standard Management

Framework , uses a structure in which the device being managed (the SNMP agent)

has information that the management software (the SNMP manager) wants to dis-

play to someone operating the network. Each SNMP agent keeps a database, called

ptg13046388

242 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

a Management Information Base (MIB) , that holds a large variety of data about the

operation of the device on which the agent resides. The manager collects the data by

using SNMP.

SNMP has been defined with four major functional areas to support the core function of

allowing managers to manage agents:

■ Data Definition: The syntax conventions for how to define the data to an agent or

manager. These specifications are called the Structure of Management Information

(SMI) .

■ MIBs: More than 100 Internet standards define different MIBs, each for a different

technology area, with countless vendor-proprietary MIBs as well. The MIB defini-

tions conform to the appropriate SMI version.

■ Protocols: The messages used by agents and managers to exchange management

data.

■ Security and Administration: Definitions for how to secure the exchange of data

between agents and managers.

Interestingly, by separating SNMP into these major functional areas, each part has been

improved and expanded independently over the years. However, it is important to know

a few of the main features added for each official SNMP version, as well as for a pseudo-

version called SNMPv2c, as summarized in Table 5-3 .

Table 5-3 SNMP Version Summaries

SNMP

Version

Description

1 Uses SMIv1, simple authentication with communities, but used MIB-I originally.

2 Uses SMIv2, removed requirement for communities, added GetBulk and Inform

messages, but began with MIB-II originally.

2c Pseudo-release (RFC 1905) that allowed SNMPv1-style communities with

SNMPv2; otherwise, equivalent to SNMPv2.

3 Mostly identical to SNMPv2, but adds significantly better security, although it

supports communities for backward compatibility. Uses MIB-II.

Table 5-3 hits the highlights of the comparison points between the various SNMP ver-

sions. As you might expect, each release builds on the previous one. For example,

SNMPv1 defined community strings for use as simple clear-text passwords. SNMPv2

removed the requirement for community strings—however, backward compatibility for

SNMP communities was defined through an optional RFC (1901). Even SNMPv3, with

much better security, supports communities to allow backward compatibility.

Key

Topic

ptg13046388

Chapter 5: IP Services 243

Note The use of SNMPv1 communities with SNMPv2, based on RFC 1901, has popu-

larly been called SNMP Version 2c, with c referring to “communities,” although it is argu-

ably not a legitimate full version of SNMP.

The next few sections provide a bit more depth about the SNMP protocol, with addi-

tional details about some of the version differences.

SNMP Protocol Messages

The SNMPv1 and SNMPv2 protocol messages (RFC 3416) define how a manager and

agent, or even two managers, can communicate information. For example, a manager

can use three different messages to get MIB variable data from agents, with an SNMP

Response message returned by the agent to the manager supplying the MIB data. SNMP

uses UDP exclusively for transport, using the SNMP Response message to both acknowl-

edge receipt of other protocol messages and supply SNMP information.

Table 5-4 summarizes the key information about each of the SNMP protocol messages,

including the SNMP version in which the message first appeared.

Table 5-4 SNMP Protocol Messages (RFCs 1157 and 1905)

Message Initial

Version

Response

Message

Typically

Sent By

Main Purpose

Get 1 Response Manager A request for a single variable’s value.

GetNext 1 Response Manager A request for the next single MIB leaf

variable in the MIB tree.

GetBulk 2 Response Manager A request for multiple consecutive MIB

variables with one request. Useful for getting

complex structures, for example, an IP

routing table.

Response 1 None Agent Used to respond with the information in Get

and Set requests.

Set 1 Response Manager Sent by a manager to an agent to tell the

agent to set a variable to a particular value.

The agent replies with a Response message.

Trap 1 None Agent Allows agents to send unsolicited

information to an SNMP manager. The

manager does not reply with any SNMP

message.

Inform 2 Response Manager A message used between SNMP managers to

allow MIB data to be exchanged.

Key

Topic

ptg13046388

244 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The three variations of the SNMP Get message, and the SNMP Response message, are

typically used when someone is actively using an SNMP manager. When a user of the

SNMP manager asks for information, the manager sends one of the three types of Get

commands to the agent. The agent replies with an SNMP Response message. The differ-

ent variations of the Get command are useful, particularly when the manager wants to

view large portions of the MIB. An agent’s entire MIB—whose structure can vary from

agent to agent—can be discovered with successive GetNext requests, or with GetBulk

requests, using a process called a MIB walk .

The SNMP Set command allows the manager to change something on the agent. For

example, the user of the management software can specify that a router interface should

be shut down; the management station can then issue a Set command for a MIB variable

on the agent. The agent sets the variable, which tells Cisco IOS Software to shut down

the interface.

SNMP Traps are unsolicited messages sent by the agent to the management station. For

example, when an interface fails, a router’s SNMP agent could send a Trap to the SNMP

manager. The management software could then highlight the failure information on a

screen, email first-level support personnel, page support, and so on. Also of note, there

is no specific message in response to the receipt of a Trap; technically, of the messages

in Table 5-4 , only the Trap and Response messages do not expect to receive any kind of

acknowledging message.

Finally, the Inform message allows two SNMP managers to exchange MIB information

about agents that they both manage.

SNMP MIBs

SNMP Versions 1 and 2 included a standard generic MIB, with initial MIB-I (version 1,

RFC 1156) and MIB-II (version 2, RFC 1213). MIB-II was actually created in between the

release of SNMPv1 and v2, with SNMPv1 supporting MIB-II as well. After the creation

of the MIB-II specification, the IETF SNMP working group changed the strategy for

MIB definition. Instead of the SNMP working group creating standard MIBs, other work-

ing groups, in many different technology areas, were tasked with creating MIB definitions

for their respective technologies. As a result, hundreds of standardized MIBs are defined.

Additionally, vendors create their own vendor-proprietary MIBs.

The Remote Monitoring MIB (RMON, RFC 2819) is a particularly important stan-

dardized MIB outside MIB-II. An SNMP agent that supports the RMON MIB can be

programmed, through SNMP Set commands, to capture packets, calculate statistics,

monitor thresholds for specific MIB variables, report back to the management station

when thresholds are reached, and perform other tasks. With RMON, a network can be

populated with a number of monitoring probes, with SNMP messaging used to gather

the information as needed.

ptg13046388

Chapter 5: IP Services 245

SNMP Security

SNMPv3 added solid security to the existing SNMPv2 and SNMPv2c specifications.

SNMPv3 adds two main branches of security to SNMPv2: authentication and encryp-

tion. SNMPv3 specifies the use of message digest algorithm 5 (MD5) and secure hash

algorithm (SHA) to create a message digest for each SNMPv3 protocol message. Doing

so enables authentication of endpoints and prevents data modification and masquerade

types of attacks. Additionally, SNMPv3 managers and agents can use Digital Encryption

Standard (DES) to encrypt the messages, providing better privacy. (SNMPv3 suggests

future support of Advanced Encryption Standard [AES] as well, but that is not a part of

the original SNMPv3 specifications.) The encryption feature remains separate because of

the U.S. government export restrictions on DES technology.

Example 5-4 shows a typical SNMP configuration with the following goals:

■ Enable SNMP and send traps to 192.168.1.100.

■ Send traps for a variety of events to the SNMP manager.

■ Set optional information to identify the router chassis, contact information, and

location.

■ Set read-write access to the router from the 192.168.1.0/24 subnet (filtered by access

list 33).

Example 5-4 Configuring SNMP

access-list 33 permit 192.168.1.0 0.0.0.255

snmp-server community public RW 33

snmp-server location B1

snmp-server contact routerhelpdesk@mail.local

snmp-server chassis-id 2511_AccessServer_Canadice

snmp-server enable traps snmp

snmp-server enable traps hsrp

snmp-server enable traps config

snmp-server enable traps entity

snmp-server enable traps bgp

snmp-server enable traps rsvp

snmp-server enable traps frame-relay

snmp-server enable traps rtr

snmp-server host 192.168.1.100 public

Syslog

Event logging is nothing new to most CCIE candidates. Routers and switches, among

other devices, maintain event logs that reveal a great deal about the operating conditions

of that device, along with valuable time-stamp information to help troubleshoot problems

or chains of events that take place.

ptg13046388

246 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

By default, Cisco routers and switches do not log events to nonvolatile memory. They can

be configured to do so using the logging buffered command, with an additional argu-

ment to specify the size of the log buffer. Configuring a router, for example, for SNMP

management provides a means of passing critical events from the event log, as they occur,

to a network management station in the form of traps. SNMP is, however, fairly involved

to configure. Furthermore, if it’s not secured properly, SNMP also opens attack vectors to

the device. However, disabling SNMP and watching event logs manually is at best tedious,

and this approach simply does not scale.

Syslog, described in RFC 5424, is a lightweight event-notification protocol that provides

a middle ground between manually monitoring event logs and a full-blown SNMP imple-

mentation. It provides real-time event notification by sending messages that enter the

event log to a Syslog server that you specify. Syslog uses UDP port 514 by default.

Cisco IOS devices configured for Syslog, by default, send all events that enter the event

log to the Syslog server. You can also configure Syslog to send only specific classes of

events to the server.

Syslog is a clear-text protocol that provides event notifications without requiring dif-

ficult, time-intensive configuration or opening attack vectors. In fact, it’s quite simple to

configure basic Syslog operation:

Step 1. Install a Syslog server on a workstation with a fixed IP address.

Step 2. Configure the logging process to send events to the Syslog server’s IP address

using the logging host command.

Step 3. Configure any options, such as which severity levels (0–7) you want to send

to the Syslog server using the logging trap command.

Web Cache Communication Protocol

To ease pressure on congested WAN links in networks with many hosts, Cisco developed

WCCP to coordinate the work of edge routers and content engines (also known as cache

engines). Content engines collect frequently accessed data, usually HTTP traffic, locally,

so that when hosts access the same pages, the content can be delivered from the cache

engine rather than crossing the WAN. WCCP differs from web proxy operation in that

the hosts accessing the content have no knowledge that the content engine is involved in

a given transaction.

WCCP works by allowing edge routers to communicate with content engines to make

each aware of the other’s presence and to permit the router to redirect traffic to the con-

tent engine as appropriate. Figure 5-3 shows how WCCP functions between a router and

a content engine when a user requests a web object using HTTP.

ptg13046388

Chapter 5: IP Services 247

ARP Reply

Source = R1-E1-MAC Web Server:

10.1.2.200/24

GW = 10.1.2.1

Interface: E1

MAC: R1-E1-MAC

10.1.1.1/24

Barney: 10.1.1.102

Mask: /8

GW = 10.1.1.1

Fred: 10.1.1.101

Mask: /24

GW = 10.1.1.1

Interface: E2

MAC: R1-E2-MAC

10.1.2.1/24

DHCP Server:

10.1.2.202/24

DNS Server:

10.1.2.203/24

ARP Request

Target = 10.1.1.1

ARP Reply

Source = R1-E1-MAC

Proxy logic

used by R1!

ARP Request

Target = 10.1.2.200

Figure 5-3 WCCP Operations Between a Router and a Content Engine

The figure shows the following steps, with the main decision point on the content engine

coming at Step 4:

Step 1. The client sends an HTTP Get request with a destination address of the web

server, as normal.

Step 2. The router’s WCCP function notices the HTTP Get request and redirects the

packet to the content engine.

Step 3. The content engine looks at its disk storage cache to discover whether the

requested object is cached.

Step 4A. If the object is cached, the content engine sends an HTTP response, which

includes the object, back to the client.

Step. 4B If the object is not cached, the content engine sends the original HTTP Get

request on to the original server.

Step 5. If Step 4B was taken, the server replies to the client, with no knowledge that

the packet was ever redirected to a content engine.

Using WCCP, which uses UDP port 2048, a router and a content engine, or a pool of

content engines (known as a cluster), become aware of each other. In a cluster of content

engines, the content engines also communicate with each other using WCCP. Up to 32

content engines can communicate with a single router using WCCPv1. If more than one

content engine is present, the one with the lowest IP address is elected as the lead engine.

WCCP also provides a means for content engines within a cluster to become aware of

each other. Content engines request information on the cluster members from the WCCP

router, which replies with a list. This permits the lead content engine to determine how

traffic should be distributed to the cluster.

In WCCPv1, only one router can redirect traffic to a content engine or a cluster of con-

tent engines. In WCCPv2, multiple routers and multiple content engines can be config-

ured as a WCCP service group. This expansion permits much better scalability in content

caching. Furthermore, WCCPv1 supports only HTTP traffic (TCP port 80, specifically).

Key

Topic

Key

Topic

ptg13046388

248 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

WCCPv2 supports several other traffic types and has other benefits compared to

WCCPv1:

■ Supports TCP and UDP traffic other than TCP port 80, including FTP caching, FTP

proxy handling, web caching for ports other than 80, Real Audio, video, and tele-

phony.

■ Permits segmenting caching services provided by a caching cluster to a particular

protocol or protocols, and uses a priority system for deciding which cluster to use

for a particular cached protocol.

■ Supports multicast to simplify configuration.

■ Supports multiple routers (up to 32 per cluster) for redundancy and load distribution.

(All content engines in a cluster must be configured to communicate with all routers

in that cluster.)

■ Provides for MD5 security in WCCP communication using the global configuration

command ip wccp password password .

■ Provides load distribution.

■ Supports transparent error handling.

When you enable WCCP globally on a router, the default version used is WCCPv2.

Because the WCCP version is configured globally for a router, the version number affects

all interfaces. However, multiple services can run on a router at the same time. Routers

and content engines can also simultaneously participate in more than one service group.

These WCCP settings are configured on a per-interface basis.

Configuring WCCP on a router is not difficult because a lot of the configuration in a

caching scenario takes place on the content engines; the routers need only minimal con-

figuration. Example 5-5 shows a WCCPv2 configuration using MD5 authentication and

multicast for WCCP communication.

Example 5-5 WCCP Configuration Example

! First we enable WCCP globally on the router,

! specifying a service (web caching), a multicast address for

! the WCCP communication, and an MD5 password:

ip wccp web-cache group-address 239.128.1.100 password cisco

! Next we configure an interface to redirect WCCP web-cache

! traffic outbound to a content engine:

int fa0/0

ip wccp web-cache redirect out

! Finally, inbound traffic on interface fa0/1 is excluded from redirection:

int fa0/1

ip wccp redirect exclude in

Key

Topic

Key

Topic

ptg13046388

Chapter 5: IP Services 249

Finally, WCCP can make use of access lists to filter traffic only for certain clients (or to

exclude WCCP use for certain clients) using the ip wccp web-cache redirect-list access-

list global command. WCCP can also use ACLs to determine which types of redirected

traffic the router should accept from content engines, using the global command ip wccp

web-cache group-list access-list .

Implementing the Cisco IOS IP Service Level Agreement (IP SLA)

Feature

The Cisco IOS IP SLA feature, formerly known as the Service Assurance Agent (SAA),

and prior to that simply the Response Time Reporter (RTR) feature, is designed to pro-

vide a means of actively probing a network to gather performance information from it.

Whereas most of the tools described in the following sections are designed to monitor

and collect information, IP SLA is based on the concept of generating traffic at a speci-

fied interval, with specifically configured options, and measuring the results. It is built

around a source-responder model, where one device (the source) generates traffic and

either waits for a response from another device (the responder) or another device config-

ured as a responder captures the sender’s traffic and does something with it. This model

provides the ability to analyze actual network performance over time, under very specific

conditions, to measure performance, avert outages, evaluate quality of service (QoS)

performance, identify problems, verify SLAs, and reduce network outages. The IP SLA

feature is extensively documented at www.cisco.com/go/ipsla .

The IP SLA feature allows measuring the following parameters in network performance:

■ Delay (one-way and round-trip)

■ Jitter (directional)

■ Packet loss (directional)

■ Packet sequencing

■ Path (per hop)

■ Connectivity (through the UDP Echo, ICMP Echo, ICMP Path Echo, and TCP

Connect functions)

■ Server or website download time

■ Voice-quality metrics (MOS)

Implementing the IP SLA feature requires these steps:

Step 1. Configure the SLA operation type, including any required options.

Step 2. Configure any desired threshold conditions.

Step 3. Configure the responder(s), if appropriate.

ptg13046388

250 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step 4. Schedule or start the operation and monitor the results for a sufficient period

of time to meet your requirements.

Step 5. Review and interpret the results. You can use the Cisco IOS CLI or an SNMP

manager to do this.

After IP SLA monitors have been configured, they cannot be edited or modified. You

must delete an existing IP SLA monitor to reconfigure any of its options. Also, when you

delete an IP SLA monitor to reconfigure it, the associated schedule for that IP SLA moni-

tor is deleted, too.

IP SLAs can use MD5 authentication. These are configured using the ip sla key-chain

command.

Example 5-6 shows a basic IP SLA configuration with the UDP Echo function. On the

responding router, the only required command is global config ip sla monitor responder .

On the originating router, the configuration shown in the example sets the source router

to send UDP echo packets every 5 seconds for one day to 200.1.200.9 on port 1330.

Example 5-6 IP SLA Basic Configuration

SLAdemo# config term

SLAdemo(config)# ip sla monitor 1

SLAdemo(config-sla-monitor)# type udpEcho dest-ipaddr 200.1.200.9 dest-port 1330

SLAdemo(config-sla-monitor)# frequency 5

SLAdemo(config-sla-monitor)# exit

SLAdemo(config)# ip sla monitor schedule 1 life 86400 start-time now

A number of show commands come in handy in verifying IP SLA performance. On the

source router, the most useful commands are show ip sla monitor statistics and show ip

sla monitor configuration . Here’s a sample of the show ip sla monitor statistics com-

mand for the sending router in the configuration in Example 5-6 :

SLAdemo# show ip sla monitor statistics

Round trip time (RTT) Index 1

Latest RTT: 26 ms

Latest operation start time: 19:42:44.799 EDT Tue Jun 9 2009

Latest operation return code: OK

Number of successes: 228

Number of failures: 0

Operation time to live: 78863 sec

Implementing NetFlow

NetFlow is a software feature set in Cisco IOS that is designed to provide network

administrators information about what is happening in the network, so that those respon-

sible for the network can make appropriate design and configuration changes and moni-

tor for network attacks. NetFlow has been included in Cisco IOS for a long time, and

ptg13046388

Chapter 5: IP Services 251

has evolved through several versions (currently version 9). Cisco has renamed the feature

Cisco Flexible NetFlow. It is more than just a renaming, however. The original NetFlow

implementation included a fixed seven tuples that identified a flow. Flexible NetFlow

allows a user to configure the number of tuples to more specifically target a particular

flow to monitor.

The components of NetFlow are

■ Records: A set of predefined and user-defined key fields (such as source IP address,

destination IP address, source port, and so on) for network monitoring.

■ Flow monitors: Applied to an interface, flow monitors include records, a cache, and

optionally a flow exporter. The flow monitor cache collects information about flows.

■ Flow exporters: These export the cached flow information to outside systems (typi-

cally a server running a NetFlow collector).

■ Flow samplers: Designed to reduce the load on NetFlow-enabled devices, flow sam-

plers allow specifying the sample size of traffic, NetFlow analyzes to a ratio of 1:2

through 1:32768 packets. That is, the number of packets analyzed is configurable

from 1/2 to 1/32768 of the packets flowing across the interface.

Configuring NetFlow in its most basic form uses predefined flow records, configured for

collection by a flow monitor, and at least one flow exporter. Example 5-7 shows a basic

NetFlow configuration for collecting information and statistics on IPv4 traffic using the

predefined IPv4 record, and for configuring some timer settings to show their structure.

An exporter is configured to send the collected information to a server at 192.168.1.110

on UDP port 1333, and with a Differentiated Services Code Point (DSCP) of 8 on the

exported packets. The process consists of three steps: configuring the NetFlow monitor,

applying it to an interface, and configuring an exporter.

Example 5-7 Basic NetFlow Monitor and Exporter Configuration

EastEdge# show run | begin flow

flow exporter ipv4flowexport

destination 192.168.1.110

dscp 8

transport udp 1333

flow monitor ipv4flow

description Monitors all IPv4 traffic

record netflow ipv4 original-input

cache timeout inactive 600

cache timeout active 180

cache entries 5000

statistics packet protocol

ptg13046388

252 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

interface FastEthernet0/0

ip address 192.168.39.9 255.255.255.0

ip flow monitor ipv4flow input

! output omitted

You can verify NetFlow configuration using these commands:

■ show flow record

■ show flow monitor

■ show flow exporter

■ show flow interface

Implementing Router IP Traffic Export

IP Traffic Export, or Router IP Traffic Export (RITE), exports IP packets to a VLAN or

LAN interface for analysis. RITE does this only for traffic received on multiple WAN

or LAN interfaces simultaneously as would typically take place only if the device were

being targeted in a denial of service attack. The primary application for RITE is in intru-

sion detection system (IDS) implementations, where duplicated traffic can indicate

an attack on the network or device. In case of actual attacks where identical traffic is

received simultaneously on multiple ports of a router, it’s useful to have the router send

that traffic to an IDS for alerting and analysis—that’s what RITE does.

When configuring RITE, you enable it and configure it to direct copied packets to the

MAC address of the IDS host or protocol analyzer. You can configure forwarding of

inbound traffic (the default), outbound traffic, or both, and filtering on the number of

packets forwarded. Filtering can be performed with access lists and based on one-in- n

packets.

In Example 5-8 , a router is configured with a RITE profile that’s applied to the fa0/0 inter-

face and exports traffic to a host with the MAC address 0018.0fad.df30. The router is

configured for bidirectional RITE, and to send one in every 20 inbound packets and one

in every 100 outbound packets to this MAC address. The egress interface (toward the IDS

host) is fa0/1. For simplicity, Example 5-8 shows only one ingress interface. Configuration

for other ingress interfaces uses the same steps shown here for the fa0/0 interface.

Example 5-8 Router IP Traffic Export Example

Edge# config term

Edge(config)# ip traffic-export profile export-this

Edge(config-rite)# interface fa0/0

Edge(config-rite)# bidirectional

Edge(config-rite)# mac-address 0018.0fad.df30

Edge(config-rite)# incoming sample one-in-every 20

Edge(config-rite)# outgoing sample one-in-every 100

ptg13046388

Chapter 5: IP Services 253

Edge(config-rite)# exit

Edge(config)# interface fa0/1

Edge(config-if)# ip traffic-export apply export-this

Edge(config-if)# end

Edge#

%RITE-5-ACTIVATE: Activated IP traffic export on interface FastEthernet 0/1.

Implementing Cisco IOS Embedded Event Manager

The Embedded Event Manager is a software component of Cisco IOS that is designed

to make life easier for administrators by tracking and classifying events that take place

on a router and providing notification options for those events. The Cisco motivation

for including EEM was to reduce downtime, thus improving availability, by reducing

the mean time to recover from various system events that previously required a manual

troubleshooting and remediation process.

In some ways, EEM overlaps with RMON functionality, but EEM is considerably more

powerful and flexible. EEM uses event detectors and actions to provide notifications of

those events. Event detectors that EEM supports include the following:

■ Monitoring SNMP objects

■ Screening Syslog messages for a pattern match (using regular expressions)

■ Monitoring counters

■ Timers (absolute time-of-day, countdown, watchdog, and CRON)

■ Screening CLI input for a regular expression match

■ Hardware insertion and removal

■ Routing table changes

■ IP SLA and NetFlow events

■ Generic On-Line Diagnostics (GOLD) events

■ Many others, including redundant switchover events, inbound SNMP messages, and

others

Event actions that EEM provides include the following:

■ Generating prioritized Syslog messages

■ Reloading the router

■ Switching to a secondary processor in a redundant platform

■ Generating SNMP traps

ptg13046388

254 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ Setting or modifying a counter

■ Executing a Cisco IOS command

■ Sending a brief email message

■ Requesting system information when an event occurs

■ Reading or setting the state of a tracked object

EEM policies can be written using either the Cisco IOS CLI or using the Tcl command

interpreter language. For the purposes of the CCIE Routing and Switching qualification

exam, you’re more likely to encounter CLI-related configuration than Tcl, but both are

very well documented at www.cisco.com/go/eem . Example 5-9 is a brief example con-

figuration that shows the CLI configuration of an EEM event that detects and then sends

a notification that a console user has issued the wr command, as well as the associated

console output when the command is issued.

Example 5-9 EEM Configuration Example

R9(config)# event manager applet CLI-cp-run-st

R9(config-applet)# event cli pattern "wr" sync yes

R9(config-applet)# action 1.0 syslog msg "$_cli_msg Command Executed"

R9(config-applet)# set 2.0 _exit_status 1

R9(config-applet)# end

R9# wr

Jun 9 19:23:21.989: %HA_EM-6-LOG: CLI-cp-run-st: write Command Executed

The Cisco IOS EEM has such vast capability that an entire book on the subject is easily

conceivable, but considering the scope of the CCIE Routing and Switching qualifying

exam, these fundamental concepts should provide you with enough working knowledge

to interpret questions you might encounter.

Implementing Remote Monitoring

Remote Monitoring, or RMON, is an event-notification extension of the SNMP capabil-

ity on a Cisco router or switch. RMON enables you to configure thresholds for alerting

based on SNMP objects, so that you can monitor device performance and take appropri-

ate action to any deviations from the normal range of performance indications.

RMON is divided into two classes: alarms and events. An event is a numbered, user-

configured threshold for a particular SNMP object. You configure events to track, for

example, CPU utilization or errors on a particular interface, or anything else you can

do with an SNMP object. You set the rising and falling thresholds for these events, and

then tell RMON which RMON alarm to trigger when those rising or falling thresholds

are crossed. For example, you might want to have the router watch CPU utilization and

trigger an SNMP trap or log an event when the CPU utilization rises faster than, say, 20

percent per minute. Or you might configure it to trigger an alarm when the CPU utiliza-

tion rises to some absolute level, such as 80 percent. Both types of thresholds (relative, or

ptg13046388

Chapter 5: IP Services 255

“delta,” and absolute) are supported. Then, you can configure a different alarm notifica-

tion as the CPU utilization falls, again at some delta or to an absolute level you specify.

The alarm that corresponds to each event is also configurable in terms of what it does

(logs the event or sends a trap). If you configure an RMON alarm to send a trap, you also

need to supply the SNMP community string for the SNMP server.

Event and alarm numbering are locally significant. Alarm numbering provides a pointer to

the corresponding event. That is, the configured events each point to specific alarm num-

bers, which you must also define.

Example 5-10 shows the configuration required to identify two pairs of events, and the

four corresponding alarm notifications. The events being monitored are the interface

error counter on the FastEthernet 0/0 interface (SNMP object ifInErrors.1) and the Serial

0/0 interface (SNMP object ifInErrors.2). In the first case, the RMON event looks for a

delta (relative) rise in interface errors in a 60-second period, and a falling threshold of

five errors per 60 seconds. In the second case, the numbers are different and the thresh-

olds are absolute, but the idea is the same. In each case, the RMON events drive RMON

alarms 1, 2, 3, or 4, depending on which threshold is crossed.

Example 5-10 RMON Configuration Example

rmon event 1 log trap public description Fa0.0RisingErrors owner config

rmon event 2 log trap public description Fa0.0FallingErrors owner config

rmon event 3 log trap public description Se0.0RisingErrors owner config

rmon event 4 log trap public description Se0.0FallingErrors owner config

rmon alarm 11 ifInErrors.1 60 delta rising-threshold 10 1 falling-threshold 5 2

owner config

rmon alarm 20 ifInErrors.2 60 absolute rising-threshold 20 3 falling-threshold 10 4

owner config

To monitor RMON activity and to see the configured alarms and events, use the show

rmon alarm and show rmon event commands. Here’s an example of the console events

that take place when the previously configured events trigger the corresponding alarms:

Jun 9 12:54:14.787: %RMON-5-FALLINGTRAP: Falling trap is generated

because the value of ifInErrors.1 has fallen below the falling-

threshold value 5

Jun 9 12:55:40.732: %RMON-5-FALLINGTRAP: Falling trap is generated

because the value of ifInErrors.2 has fallen below the falling-

threshold value 10

Implementing and Using FTP on a Router

You can use the Cisco IOS FTP client to send or receive files from the CLI. Cisco IOS

does not support configuration as an FTP server, but you can configure a TFTP server

(see the next section of this chapter for details).

ptg13046388

256 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

To transfer files using FTP from the CLI, use the ip ftp command with the appropriate

options. You can specify the username and password to use for an FTP transfer using the

ip ftp username and ip ftp password commands. You can also specify the source inter-

face used for FTP transfers using the ip ftp source-interface command.

To initiate an FTP transfer, use the copy command with the ftp keyword in either the

source or destination argument. For example, to send the startup configuration file on

a router to an FTP server at 10.10.200.1, where it will be stored as r8-startup-config, the

transaction is shown in Example 5-11 .

Example 5-11 Using FTP to Copy a Configuration File

R8# copy startup-config ftp:

Address or name of remote host []? 10.10.200.1

Destination filename [r8-confg]? r8-startup-config

Writing r8-startup-config !

3525 bytes copied in 0.732 secs

FTP can also be used to send an exception dump to an FTP server in the event of a crash.

Example 5-12 shows a router configured to send an exception dump of 65,536 bytes to

172.30.19.63 using the username JoeAdmin and password c1sco.

Example 5-12 Using FTP to Send an Exception Dump

ip ftp username JoeAdmin

ip ftp password c1sco

exception protocol ftp

exception region-size 65536

exception dump 172.30.19.63

Finally, you can set the router for passive-mode FTP connections by configuring the ip

ftp passive command.

Implementing a TFTP Server on a Router

TFTP is commonly used for IOS and configuration file transfers on routers and switches.

Cisco IOS supports configuring a TFTP server on a router, and the process is straight-

forward. It should be noted that TFTP is a tool that allows files to be “pulled” from one

device to another.

To enable TFTP, issue the tftp-server command, which has several arguments. You can

specify the memory region where the file resides (typically flash, but other regions are

supported), the filename, and an access list for controlling which hosts can access the

ptg13046388

Chapter 5: IP Services 257

file. Here’s an example that shows the commands to permit TFTP access to flash:c1700-

advipservicesk9-mz.124-23.bin to hosts that are identified by access list 11. This example

also shows how the alias command-line option can be used to make the file available with

a name other than the one that it has natively in flash, specifically supersecretfile.bin:

tftp-server flash:c1700-advipservicesk9-mz.124-23.bin alias

supersecretfile.bin 11

Implementing Secure Copy Protocol

Secure Copy Protocol (SCP) is a service you can enable on a Cisco IOS router or switch

to provide file copy services. SCP uses Secure Shell (SSH) (TCP port 22) for its transport

protocol. It enables file transfer using the IOS copy command.

SCP requires authentication, authorization, and accounting (AAA) for user authentication

and authorization. Therefore, you must enable AAA before turning on SCP. In particular,

because copy is an exec command, you must configure the aaa authorization command

with the exec option. After you’ve enabled AAA, use the ip scp server enable command

to turn on the SCP server.

Implementing HTTP and HTTPS Access

Cisco IOS routers and switches support web access for administration, through both

HTTP and HTTPS. Enabling HTTP access requires the ip http server global configura-

tion command. HTTP access defaults to TCP port 80. You can change the port used for

HTTP by configuring the ip http port command. You can restrict HTTP access to a rout-

er using the ip http access-class command, which applies an extended access list to con-

nection requests. You can also specify a unique username and password for HTTP access

using the ip http client username and ip http client password commands. If you choose,

you can also configure HTTP access to use a variety of other access-control methods,

including AAA, using ip http authentication [ aaa | local | enable | tacacs ].

You can also configure a Cisco IOS router or switch for Secure Sockets Layer (SSL)

access. By default, HTTPS uses TCP port 443, and the port is configurable in much the

same way as it is with HTTP access. Enabling HTTPS access requires the ip http secure-

server command. When you configure HTTPS access in most IOS Release 12.4 ver-

sions, the router or switch automatically disables HTTP access, if it has been configured.

However, you should disable it manually if the router does not do it for you.

HTTPS router access also gives you the option of specifying the cipher suite of your

choice. This is the combination of encryption methods that the router will enable for

HTTPS access. By default, all methods are enabled, as shown in the sample show

command output of Example 5-13 .

ptg13046388

258 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 5-13 HTTPS Configuration Output on a Router

R8# sh ip http server secure status

HTTP secure server status: Enabled

HTTP secure server port: 443

HTTP secure server ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5

rc4-128-sha

HTTP secure server client authentication: Disabled

HTTP secure server trustpoint:

HTTP secure server active session modules: ALL

R8#

Implementing Telnet Access

Telnet is such a ubiquitous method of access on Cisco IOS routers and switches that it

needs little coverage here. Still, a few basic points are in order.

Telnet requires a few configuration specifics to work. On the vty lines, the login com-

mand (or a variation of it such as login local ) must be configured. If a login command is

not configured, the router or switch will refuse all Telnet connection attempts.

By default, Telnet uses TCP port 23. However, you can configure the vty lines to use

rotary groups, also known as rotaries, to open access on other ports. If you configure

this option, you should use an extended access list to enforce connection on the desired

ports. By default, rotaries support connections on a number of ports. For example, if you

configure rotary 33 on the vty lines, the router will accept Telnet connections on ports

3033, 5033, and 7033. Therefore, filtering undesired ports is prudent. Remember that

applying access lists to vty lines requires the access-class list in command.

Implementing SSH Access

Secure Shell (SSH) is much more secure than Telnet because it uses SSL rather than clear

text. Therefore, today, nearly all Cisco router and switch deployments use SSH rather

than Telnet for secure access. Enabling SSH on a Cisco router is a four-step process. This

is because SSH requires a couple of items to be configured before you can enable SSH

itself, and those prerequisites are not intuitive. The steps in configuring SSH are as fol-

lows:

Step 1. Configure a host name using the hostname command.

Step 2. Configure a domain name using the ip domain-name command.

Step 3. Configure RSA keys using the crypto key generate rsa command.

Step 4. Configure the terminal lines to permit SSH access using the transport input

ssh command.

SSH supports rotaries on vty lines just as Telnet does, so you can use rotaries to specify

the port or ports on which SSH access is permitted on vty lines.

ptg13046388

Chapter 5: IP Services 259

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter, as well as review items noted with a Key Topic icon.

Table 5-5 lists the protocols mentioned in this chapter and their respective standards

documents.

Table 5-5 Protocols and Standards for Chapter 5

Name Standardized In

ARP RFC 826

Proxy ARP RFC 1027

RARP RFC 903

BOOTP RFC 951

DHCP RFC 2131

DHCP FQDN option Internet-Draft

HSRP Cisco proprietary

VRRP RFC 3768

GLBP Cisco proprietary

CDP Cisco proprietary

NTP RFC 1305

Syslog RFC 5424

SNMP Version 1 RFCs 1155, 1156, 1157, 1212, 1213, 1215

SNMP Version 2 RFCs 1902–1907, 3416

SNMP Version 2c RFC 1901

SNMP Version 3 RFCs 2578–2580, 3410–3415

Good Starting Point: RFC 3410

Table 5-6 lists some of the most popular Cisco IOS commands related to the topics in this

chapter.

Key

Topic

ptg13046388

260 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 5-6 Command Reference for Chapter 5

Command Description

ip dhcp pool name Creates DHCP pool.

default-router address

[ address2 ... address8 ]

DHCP pool subcommand to list the gateways.

dns-server address [ address2 ... address8 ] DHCP pool subcommand to list DNS servers.

lease { days [ hours ][ minutes ] | infinite } DHCP pool subcommand to define the lease

length.

network network-number [ mask |

prefix-length ]

DHCP pool subcommand to define IP addresses

that can be assigned.

ip dhcp excluded-address [ low-address

high-address ]

Global command to disallow these addresses

from being assigned.

host address [ mask | prefix-length ] DHCP pool subcommand, used with hardware-

address or client-identifier , to predefine a

single host’s IP address.

hardware-address hardware-address

type

DHCP pool subcommand to define MAC

address; works with the host command.

show ip dhcp binding [ ip-address ] Lists addresses allocated by DHCP.

show ip dhcp server statistics Lists stats for DHCP server operations.

standby [ group-number ] ip [ ip-address

[ secondary ]]

Interface subcommand to enable an HSRP group

and define the virtual IP address.

track object-number interface type-

number { line-protocol | ip routing }

Configures a tracking object that can be used by

HSRP, VRRP, or GLBP to track the status of an

interface.

standby [ group-number ] preempt [ delay

{ minimum delay | reload delay | sync

delay }]

Interface subcommand to enable preemption and

set delay timers.

show track [ object-number [ brief ]

| interface [ brief ] | ip route [ brief ] |

resolution | timers ]

Displays status of tracked objects.

standby [ group-number ] priority

priority

Interface subcommand to set the HSRP group

priority for this router.

standby [ group-number ] timers [ msec ]

hellotime [ msec ] holdtime

Interface subcommand to set HSRP group

timers.

standby [ group-number ] track object-

number

Interface subcommand to enable HSRP to track

defined objects, usually for the purpose of

switching active routers on an event related to

that object.

ptg13046388

Chapter 5: IP Services 261

Command Description

show standby [ type number [ group ]]

[ brief | all ]

Lists HSRP statistics.

ntp peer ip-address [ version number ]

[ key keyid ] [ source interface ] [ prefer ]

Global command to enable symmetric active

mode NTP.

ntp server ip-address [ version number ]

[ key keyid ] [ source interface ] [ prefer ]

Global command to enable static client mode

NTP.

ntp broadcast [ version number ] Interface subcommand on an NTP server to

cause NTP broadcasts on the interface.

ntp broadcast client Interface subcommand on an NTP client to

cause it to listen for NTP broadcasts.

ntp master [ stratum ] Global command to enable NTP server.

show ntp associations Lists associations with other NTP servers and

clients.

show ntp status Displays synchronization status, stratum level,

and other basic information.

logging trap level Sets the severity level for syslog messages;

arguments are 0–7, where 0=emergencies,

1=alerts, 2=critical, 3=errors, 4=warnings,

5=notifications, 6=informational, 7=debugging

(default).

logging host {{ ip-address |

hostname }

| { ipv6 ipv6-address | hostname }}

[ transport { udp [ port port-number ] | tcp

[ port port-number ]}] [ alarm [ severity ]]

Configures the IP or IPv6 address or host name

to which to send syslog messages and permits

setting the transport protocol and port number.

ip wccp { web-cache | service-number }

[ service-list service-access-list ]

[ mode { open | closed }] [ group-address

multicast-address ] [ redirect-list access-

list ] [ group-list access-list ] [ password

[ 0-7 ] password ]

Enables WCCP and configures filtering and

service parameters.

ip wccp { web-cache | service-number }

redirect { in | out }

Interface configuration command to enable

WCCP and configure it for outbound or

inbound service.

show ip wccp Displays WCCP configuration settings and

statistics.

snmp-server enable traps Enables sending of all types of traps available on

the router or switch.

ptg13046388

262 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Description

snmp-server host { hostname |

ip-address } [ vrf vrf-name ] [ traps |

informs ] [ version { 1 | 2c | 3 [ auth | noauth

| priv ]}] community-string [ udp-port

port ] [ notification-type ]

Configures the SNMP server to send traps or

informs to a particular host, along with options

for setting the SNMP version for traps and the

UDP port (default is 162). The notification-type

field specifies the types of traps to send; if no

types are specified, all available categories of

traps will be sent.

snmp-server community string [ view

view-name ] [ ro | rw ] [ access-list-number ]

Sets the read-only or read-write community

string and access list for host filtering for access

to SNMP reads and writes on the router or

switch.

show snmp mib ifmib ifindex

interface-id

Shows the router’s interface ID for a particular

interface. Particularly useful for RMON

configuration.

ip sla monitor operation-index Enters IP SLA monitor configuration mode for

an individual monitor function.

type [ jitter | udp-echo | echo protocol

icmpecho | dns | ftp operation | http

operation | mpls ping ipv4 | pathecho |

pathjitter

| tcpconnect | voip delay

post-dial | udp-jitter | udp-jitter codec ]

Configures the IP SLA monitor type with

options (not shown) including source and

destination IP address and source and

destination port number, plus other relevant

options to the particular type.

ip sla key-chain key-chain-name Configures a key chain for MD5 authentication

of IP SLA operations.

ip sla monitor schedule operation-

number [ life { forever | seconds }] [ start-

time { hh : mm [: ss ] [ month day | day

month ] | pending | now | after hh : mm : ss }]

[ ageout seconds ] [ recurring ]

Configures the schedule for a particular IP SLA

monitor. If the IP SLA monitor is deleted from

the configuration, the schedule is also deleted.

ip sla monitor responder Enables the IP SLA responder function globally.

More specific options for this command can be

configured for specific responder types, ports,

and so on.

show ip sla monitor statistics [ operation ]

detail

Shows the statistics for a specified IP SLA

operation or all configured IP SLA operations.

show ip sla responder Shows currently configured IP SLA responders

and recent activity (source IP address, and so

on).

ip ssh [ timeout seconds | authentication-

retries integer ]

Sets SSH access crypto key.

crypto key generate rsa Generates RSA keys. Required for SSH

configuration.

ptg13046388

Chapter 5: IP Services 263

Command Description

transport input ssh In vty configuration mode, permits SSH

connections.

ip http server Enables HTTP server.

ip http secure-server Enables HTTPS server.

ip traffic-export profile profile-name Enables and enters configuration mode for a

RITE profile.

ip traffic-export apply profile-name Applies a RITE profile to an interface.

event manager applet applet-name [ class

class-options ] [ trap ]

Enters EEM applet configuration mode.

event cli pattern regular-expression

{[ default ] [ enter ] [ questionmark ] [ tab ]}

[ sync { yes | no skip { yes | no }] [ mode

variable ] [ occurs num-occurrences ]

[ period period-value ] [ maxrun

maxruntime-number ]

Configures EEM to match a CLI command

string.

ip flow-top-talkers NetFlow aggregator. Aggregates traffic for

unclassified top talkers.

flow monitor flow-name Enters configuration mode for a NetFlow

monitor.

flow exporter exporter-name Configures a NetFlow exporter and the

destination server to which to send NetFlow

information for a particular flow monitor.

rmon event Configures an RMON event to monitor a

particular SNMP object, along with rising and

falling thresholds.

rmon alarm Configures an alarm action for an RMON event’s

rising or falling threshold.

Copy With FTP option in the source or destination

field, copies a file to or from an FTP server.

tftp-server flash [ partition-number: ]

filename1 [ alias filename2 ] [ access-list-

number ]

Configures a TFTP server on the router to serve

a file, optionally with an alias, and optionally

through an ACL.

aaa new-model Enables AAA on the router.

aaa authentication Configures AAA authentication methods.

aaa authorization Configures AAA authorization methods.

ip scp server enable Enables the SCP server on the router. Requires

AAA authentication and AAA authorization to

be configured.

ptg13046388

264 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Fill In Key Tables from Memory

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD to check your answers.

Definitions

Next, take a few moments to write down the definitions for the following terms:

HSRP, VRRP, GLBP, ARP, RARP, proxy ARP, BOOTP, DHCP, NTP symmetric active

mode, NTP server mode, NTP client mode, NTP, virtual IP address, VRRP Master

router, SNMP agent, SNMP manager, Get, GetNext, GetBulk, MIB-I, MIB-II,

Response, Trap, Set, Inform, SMI, MIB, MIB walk, lead content engine

Refer to the glossary to check your answers.

Further Reading

More information about several of the topics in this chapter can be easily found in a

large number of books and online documentation. The RFCs listed in Table 5-5 of the

“Foundation Summary” section also provide a great deal of background information for

this chapter. Here are a few references for more information about some of the less popu-

lar topics covered in this chapter:

■ Proxy ARP: www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note-

09186a0080094adb.shtml .

■ GLBP: www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_glbp.html .

■ VRRP: www.cisco.com/en/US/docs/ios/12_0st/12_0st18/feature/guide/

st_vrrpx.html .

■ SNMP: Any further reading of SNMP-related RFCs should begin with RFC 3410,

which provides a great overview of the releases and points to the more important of

the vast number of SNMP-related RFCs.

ptg13046388

This page intentionally left blank

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ Cisco Express Forwarding Concepts

■ Routing Protocol Migration

■ Policy-Based Routing

ptg13046388

This chapter begins with coverage of the details of the forwarding plane—the actual for-

warding of IP packets. This process of forwarding IP packets is often called IP routing ,

or simply routing . Also, many people also refer to IP routing as the data plane , meaning

the plane (topic) related to the end-user data.

Chapters 7 through 11 cover the details of the IP control plane . In contrast to the term

data plane , the control plane relates to the communication of control information—in

short, routing protocols like OSPF and BGP. These chapters cover the routing protocols

on the exam, plus an additional chapter on redistribution and route summarization.

“Do I Know This Already?” Quiz

Table 6-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 6-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in This Section Score

IP Forwarding 1–6

Multilayer Switching 7–9

Policy Routing 10–11

Total Score

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. What command is used to enable CEF globally for IPv4 packets?

a. enable cef

b. ip enable cef

c. ip cef

d. cef enable

e. cef enable ip

f. cef ip

CHAPTER 6

IP Forwarding (Routing)

ptg13046388

268 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

2. What command is used to enable CEF globally for IPv6 packets?

a. enable cef6

b. ipv6 enable cef

c. ipv6 cef

d. ip cef (the command automatically enables CEF for IPv4 and IPv6)

3. Can CEF for IPv6 be enabled independently of CEF for IPv4?

a. Ye s

b. N o

4. Which of the following triggers an update to a CEF FIB?

a. Receipt of an ICMPv6 Neighbor Advertisement message with previously

unknown information

b. Receipt of a LAN ARP reply message with previously unknown information

c. Addition of a new route to the IP routing table by EIGRP

d. Addition of a new route to the IP routing table by adding an ip route command

e. The removal of a route from the IP routing table by EIGRP

5. Which of the following triggers an update to a CEF adjacency table?

a. Receipt of a CDP multicast on the PVC connected to Router1

b. Receipt of an ARP response with previously unknown information

c. Receipt of a packet that needs to be routed to another router over a point-to-

point interface

d. Receipt of an ICMPv6 Neighbor Advertisement with previously unknown infor-

m a t i o n

6. Which of the following packet-switching paths is considered to be the slowest?

a. Process Switching

b. Fast Switching

c. Route Cache

d. Cisco Express Forwarding

7. Which of the following commands is used on a Cisco IOS Layer 3 switch to use the

interface as a routed interface instead of a switched interface ?

a. ip routing or ipv6 unicast-routing global command

b. ip routing

or ipv6 unicast - routing interface subcommand

c. ip address interface subcommand

d. switchport mode routed interface subcommand

e. no switchport interface subcommand

ptg13046388

Chapter 6: IP Forwarding (Routing) 269

8. On a Cisco Catalyst 3560 switch, the first line of the output of a show interface

vlan 55 command lists the state as “Vlan 55 is down, line protocol is down.” Which

of the following might be causing that state to occur?

a. VLAN interface has not been no shut yet.

b. The ip routing global command is missing from the configuration.

c. On at least one interface in the VLAN, a cable that was previously plugged in

has been unplugged.

d. VTP mode is set to transparent.

e. The VLAN has not yet been created on this switch, or is not in the active state.

9. On a Cisco Catalyst 3560 switch, the first line of the output of a show interface

vlan 55 command lists the state as “Vlan 55 is up, line protocol is down.” Which of

the following might be causing that state to occur?

a. VLAN interface has not been no shut yet.

b. The ip routing global command is missing from the configuration.

c. There is no switch port on the switch with this VLAN allowed and in the STP

forwarding state.

d. STP has been administratively deactivated for this VLAN.

e. The VLAN has not yet been created on this switch, or is not in the active state.

10. Imagine a route map used for policy routing, in which the route map has a set

default interface serial0/0 command. Serial0/0 is a point-to-point link to another

router. A packet arrives at this router, and the packet matches the policy routing

route-map clause whose only set command is the one just mentioned. Which of the

following general characterizations is true?

a. The packet will be routed out interface s0/0; if s0/0 is down, it will be routed

using the default route from the routing table.

b. The packet will be routed using the default route in the routing table; if there is

no default, the packet will be routed out s0/0.

c. The packet will be routed using the best match of the destination address with

the routing table; if no match is found, the packet will be routed out s0/0.

d. The packet will be routed out interface s0/0; if s0/0 is down, the packet will be

discarded.

ptg13046388

270 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

11. Router1 has an fa0/0 interface and two point-to-point WAN links back to the core

of the network (s0/0 and s0/1, respectively). Router1 accepts routing information

only over s0/0, which Router1 uses as its primary link. When s0/0 fails, Router1 uses

policy routing to forward the traffic out the relatively slower s0/1 link. Which of the

following set commands in Router1’s policy routing route map could have been used

to achieve this function?

a. set ip default next-hop

b. set ip next-hop

c. set default interface

d. set interface

ptg13046388

Chapter 6: IP Forwarding (Routing) 271

Foundation Topics

IP Forwarding

IP forwarding , or IP routing , is the process of receiving an IP packet, making a deci-

sion of where to send the packet next, and then forwarding the packet. The forwarding

process needs to be relatively simple, or at least streamlined, for a router to forward large

volumes of packets. Ignoring the details of several Cisco optimizations to the forwarding

process for a moment, the internal forwarding logic in a router works basically as shown

in Figure 6-1 .

IP Routing Table

GW is

103.3

Compare packet

destination with

routing table

Solid lines

show packet

flow

Update TTL and

Header Checksum

E0/0

103.3 S0/0.3333 13.1

Client 3

Telnet Server –

172.31.11.201

172.31.0.0, /24 Prefixes

Is the TTL > 1?

Is the router itself

the packet’s destination?

Verify header checksum

172.31.103.0/24 Connected E0/0

172.31.13.0/24 Connected S0/0.3333

172.31.11.0/24 172.31.13.1 S0/0.3333

172.31.13.1 DLCI 100

Adjacency Information

Insert into Header

IP PacketIP Packet

IP Packet

Header

Trailer

IP Packet

Eth.

Header

Type = 0x0800

Passed FCS

Eth.

Trailer

IP Packet

Eth.

Header

Eth.

Trailer

R3 R1

Figure 6-1 Forwarding Process at Router3, Destination Telnet Server

The following list summarizes the key steps shown in Figure 6-1 :

1. A router receives the frame and checks the received frame check sequence (FCS); if

errors occurred, the frame is discarded. The router makes no attempt to recover the

lost packet.

2. If no errors occurred, the router checks the Ethernet Type field for the packet type

and extracts the packet. The Data Link header and trailer can now be discarded.

3. Assuming an IPv4 packet, its header checksum is first verified. In case of mismatch,

the packet is discarded. With IPv6 packets, this check is skipped, as IPv6 headers do

not contain a checksum.

Key

Topic

Key

Topic

ptg13046388

272 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

4. If the header checksum passed, the router checks whether the destination IP address

is one of the addresses configured on the router itself. If it does, the packet has just

arrived at its destination. The router analyzes the Protocol field in the IP header,

identifying the upper-layer protocol, and hands the packet’s payload over to the

appropriate upper-protocol driver.

5. If the destination IP address does not match any of the router’s configured address-

es, the packet must be routed. The router first verifies whether the TTL of the packet

is greater than 1. If not, the packet is dropped and an ICMP Time Exceeded message

is sent to the packet’s sender.

6. The router checks its IP routing table for the most specific prefix match of the pack-

et’s destination IP address.

7. The matched routing table entry includes the outgoing interface and next-hop router.

This information is used by the router to look up the next-hop router’s Layer 2

address in the appropriate mapping table, such as ARP, IP/DLCI, IP/VPI-VCI, dialer

maps, and so on. This lookup is needed to build a new Data Link frame and option-

ally dial the proper number.

8. Before creating a new frame, the router updates the IP header TTL or Hop Count

field, requiring a recomputation of the IPv4 header checksum.

9. The router encapsulates the IP packet in a new Data Link header (including the desti-

nation address) and trailer (including a new FCS) to create a new frame.

The preceding list is a generic view of the process. Next, a few words on how Cisco rout-

ers can optimize the routing process by using Cisco Express Forwarding (CEF).

Process Switching, Fast Switching, and Cisco Express Forwarding

Steps 6 and 7 from the generic routing logic shown in the preceding section are the most

computation-intensive tasks in the routing process. A router must find the best route to

use for every packet, requiring some form of table lookup of routing information. Also,

a new Data Link header and trailer must be created, and the information to put in the

header (like the destination Data Link address) must be found in another table.

Cisco has created several different methods to optimize the forwarding processing inside

routers, termed switching paths . This section examines the two most likely methods to

exist in Cisco router networks today: fast switching and CEF.

With fast switching, the first packet to a specific destination IP address is process

switched , meaning that it follows the same general algorithm as shown in Figure 6-1 .

With the first packet, the router adds the results of this daunting lookup to the fast-

switching cache , sometimes called the route cache , organized for fast lookups. The

cache contains the destination IP address, the next-hop information, and the data-link

header information that needs to be added to the packet before forwarding (as in Step 6

in Figure 6-1 ). Future packets to the same destination address match the cache entry, so

it takes the router less time to process and forward the packet, as all results are already

stored in the cache. This approach is also sometimes termed route once, forward many

times .

ptg13046388

Chapter 6: IP Forwarding (Routing) 273

Although it is much better than process switching, fast switching has significant draw-

backs. The first packet must be process switched, because an entry can be added to the

cache only when a packet is routed and the results of its routing (next hop, egress inter-

face, Layer 2 rewrite information) are computed. A huge inflow of packets to destinations

that are not yet recorded in the route cache can have a detrimental effect on the CPU

and the router’s performance, as they all need to be process switched. The cache entries

are timed out relatively quickly, because otherwise the cache could get overly large as it

has an entry per each destination address, not per destination subnet/prefix. If the rout-

ing table or Layer 3–to–Layer 2 tables change, parts of the route cache must be invali-

dated rather than updated, causing packets for affected destinations to become process

switched again. Also, load balancing can only occur per destination with fast switching.

Overall, fast switching was a great improvement at the time it was invented, but since that

time, better switching mechanisms have been developed. One of them, Cisco Express

Forwarding (CEF), has become the major packet-forwarding mechanism in all current

Cisco IP routing implementations, with fast switching becoming practically unused. The

support for unicast fast switching has therefore been discontinued and removed from IOS

Releases 12.2(25)S and 12.4(20)T onward.

To learn the basic idea behind CEF as an efficient mechanism to perform routing deci-

sions, it is important to understand that the crucial part of routing a packet through a

router is finding out how to construct the Layer 2 frame header to allow the packet to

be properly encapsulated toward its next hop, and forward the packet out the correct

interface. Often, this operation is called a Layer 2 frame rewrite because that is what it

resembles: A packet arrives at a router, and the router rewrites the Layer 2 frame, encap-

sulating the packet appropriately, and sends the packet toward the next hop. The packet’s

header does not change significantly—in IPv4, only the TTL and checksum are modi-

fied; with IPv6, only the Hop Count is decremented. An efficient routing mechanism

should therefore focus on speeding up the construction of Layer 2 rewrite information

and egress interface lookup. The process switching is highly inefficient in this aspect: The

routing table lookup is relatively slow and might need recursive iterations until the direct-

ly attached next hop and egress interface are identified. The next-hop information must

then be translated in ARP or other Layer 3–to–Layer 2 mapping tables to the appropriate

Layer 2 address and the frame header must be constructed, and only then the packet can

be encapsulated and forwarded. With each subsequent packet, this process repeats from

the beginning.

One important observation is that while the routing table can hold tens of thousands of

destination networks (prefixes), a router typically has only a handful of neighbors—the

next hops toward all the known destinations. All destinations reachable through a par-

ticular next hop are using the same Layer 2 rewrite information. To reach any of the

networks behind a particular adjacent next hop, the packets will be encapsulated into

frames having the same Layer 2 header addresses and sent out the same egress interface.

It makes sense, then, to trade memory for speed: Preconstruct the Layer 2 frame headers

and egress interface information for each neighbor, and keep them ready in an adjacency

table stored in the router’s memory. This adjacency table can be constructed immediately

as the routing table is populated, using IP addresses of next hops in the routing table

and utilizing ARP or other Layer 3–to–Layer 2 mapping tables to translate next-hop

Key

Topic

Key

Topic

ptg13046388

274 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

IP addresses into their corresponding Layer 2 addresses. A packet that is to be routed

through a particular next hop will then simply use the preconstructed Layer 2 frame

header for that next hop, without needing to visit the ARP or similar tables over and over

again. The process of routing a packet will then transform itself to the process of decid-

ing which entry from the adjacency table should be used to encapsulate and forward the

packet. After the proper entry is selected, encapsulating the packet and forwarding it out

the egress interface can be done in an extremely rapid way, as all necessary data is readily

available.

Another important observation is that the routing table itself is not truly optimized for

rapid lookups. It contains lots of information crucial to its construction but not that

important for routing lookups, such as origin and administrative distances of routes, their

metrics, age, and so on. Entries in the routing table can require recursive lookups: After

matching a destination network entry, the next-hop information might contain only the

IP address of the next hop but not the egress interface, so the next hop’s IP address has

to be looked up in the routing table in the next iteration—and the depth of this recursion

is theoretically unlimited. Even after matching the ultimate entry in the routing table that

finally identifies the egress interface, it does not really say anything about the Layer 2

rewrite that is necessary to forward the packet. The last found next-hop IP address dur-

ing this lookup process has to be further matched in the ARP or similar mapping tables

for the egress interface to find out how to construct the Layer 2 frame header. All these

shortcomings can be improved, though: The destination prefixes alone from the routing

table can be stored in a separate data structure called the Forwarding Information Base ,

or FIB, optimized for rapid lookups (usually, tree-based data structures meet this require-

ment). Instead of carrying the plain next hop’s IP address from the routing table over into

the FIB, each entry in the FIB that represents a destination prefix can instead contain

a pointer toward the particular entry in the adjacency table that stores the appropriate

rewrite information: Layer 2 frame header and egress interface indication. Any necessary

recursion in the routing table is resolved while creating the FIB entries and setting up the

pointers toward appropriate adjacency table entries. No other information needs to be

carried over from the routing table into the FIB. In effect, the FIB stores only destination

prefixes alone. The forwarding information itself is stored as Layer 2 rewrite information

in the adjacency table, and entries in the FIB point toward appropriate entries in the adja-

cency table. All FIB entries that describe networks reachable through a particular next

hop point to the same adjacency table entry that contains prepared Layer 2 header and

egress information toward that next hop.

After the FIB and adjacency table are created, the routing table is not used anymore to

route packets for which all forwarding information is found in the FIB/adjacency table.

With FIB-based routers, the routing table can be used for packets that require more com-

plex processing not available through straightforward Layer 2 rewrite; however, for plain

packet routing, only the FIB and the adjacency table are used. The routing table therefore

becomes more of a source of routing data to build the FIB and adjacency table contents

but is not necessarily used to route packets anymore. Therefore, such a routing table is

Key

Topic

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 275

called the Routing Information Base (RIB) —it is the master copy of routing information

from which the FIB and other structures are populated, but it is not necessarily used to

route packets itself. Note that many routing protocols including Open Shortest Path First

(OSPF) and Border Gateway Protocol (BGP) construct their own internal routing tables

that are also called RIBs. These per-protocol RIBs are usually separate from the router’s

routing table and shall not be confused with the RIB discussed in this chapter.

Advantages of this approach should be immediately obvious. The FIB contains only the

essential information to match a packet’s destination address to a known prefix. A single

lookup in the FIB immediately produces a pointer toward complete Layer 2 rewrite infor-

mation for the packet to be forwarded. If the next hop for a destination changes, only

the pointer in the respective FIB entry needs to be updated to point toward the new adja-

cency table entry; the FIB entry itself that represents the destination prefix is unchanged.

Both FIB and adjacency tables can be readily constructed from the routing table and the

available Layer 3–to–Layer 2 mapping tables, without requiring any packet flows as was

the case in fast switching. To those readers familiar with database systems, the FIB can be

seen as an index over the adjacency table, with IP prefixes being the lookup keys and the

indexed data being the Layer 2 rewrite entries in the adjacency table.

These ideas are at the core of Cisco Express Forwarding, or CEF. Conceptually, CEF con-

sists of two parts—the Forwarding Information Base and the adjacency table . The FIB

contains all known destination prefixes from the routing table, plus additional specific

entries, organized as a so-called mtrie or a multiway prefix tree . The adjacency table

contains a Layer 2 frame header prepared for each known next hop or directly attached

destination.

The CEF as just described can be implemented in a relatively straightforward way in

software, and this is exactly what all software-based Cisco routers do: They implement

CEF purely in software, as part of the operating system they run. Both FIB and adjacency

tables are maintained in router’s memory, and lookups in these structures are done by the

CPU as part of interrupt handler executed when a packet is received. Figure 6-2 , reused

from the Cisco document “How to Choose the Best Router Switching Path for Your

Network,” Document ID 13706 available on the Cisco website, illustrates the concept.

Multilayer switches and high-end Cisco router platforms go even further, and instead

of software-based FIB, they use specialized circuits (specifically, Ternary Content

Addressable Memory [TCAM]) to store the FIB contents and perform even faster look-

ups. Using a TCAM, an address lookup is performed in an extremely short time that does

not depend on the number of FIB entries, as the TCAM performs the matching on its

entire contents in parallel. On these platforms, the CEF structures are distributed to indi-

vidual linecards if present, and stored in TCAMs and forwarding ASICs.

ptg13046388

276 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Forwarding Information

Base (FIB Tree)

Adjacency Table

root

...

252

253

254

255

254

253

252

...

252

253

254

255

Forwarding Information

Adjacency Table

253

254252

...

CEF Table

Figure 6-2 Cisco Express Forwarding Basic Architecture

To illustrate the CEF in action, consider the network in Figure 6-3 and related Example 6-1 .

In this network, Router R1 is connected to two other routers and one multilayer switch.

The Data Link Layer technologies interconnecting the devices are diverse: Between

R1 and R2, HDLC is used; R1 and R3 are connected over a PPP link; R1 and MLS4

are using Ethernet interconnection in two VLANs—native VLAN and VLAN 2. OSPF

is the routing protocol in use. R2 advertises networks 10.2.0.0/24 through 10.2.3.0/24

and FD00:2::/64 through FD00:2:3::/64. In a similar fashion, R3 advertises networks

10.3.4.0/24 through 10.3.7.0/24 and FD00:3:4::/64 through FD00:3:7::/64. MLS4 adver-

tises networks 10.4.8.0/24 and 10.4.9.0/24, and FD00:4:8::/64 and FD00:4:9::/64, over

both VLANs. Multiple interface encapsulations and multiple networks reachable over a

single next hop are used in this example to show how potentially numerous destination

prefixes map to a single adjacent next hop and how the Layer 2 rewrite information is

built depending on the Data Link Layer technology. CEF is activated for both IPv4 and

IPv6 using the ip cef and ipv6 cef global configuration commands on R1.

ptg13046388

Chapter 6: IP Forwarding (Routing) 277

Example 6-1 CEF FIB and Adjacency Table

! On R1, show ip route ospf shows a portion of the RIB

R1# show ip route ospf

10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks

O 10.2.0.0/24 [110/782] via 192.168.12.2, 00:07:06, Serial0/0/0

O 10.2.1.0/24 [110/782] via 192.168.12.2, 00:07:06, Serial0/0/0

O 10.2.2.0/24 [110/782] via 192.168.12.2, 00:07:06, Serial0/0/0

O 10.2.3.0/24 [110/782] via 192.168.12.2, 00:07:06, Serial0/0/0

O 10.3.4.1/32 [110/782] via 192.168.13.3, 00:07:06, Serial0/0/1

O 10.3.5.0/24 [110/782] via 192.168.13.3, 00:07:06, Serial0/0/1

O 10.3.6.0/24 [110/782] via 192.168.13.3, 00:07:06, Serial0/0/1

O 10.3.7.0/24 [110/782] via 192.168.13.3, 00:07:06, Serial0/0/1

O 10.4.8.0/24 [110/2] via 192.168.24.4, 00:07:06, FastEthernet0/0.2

[110/2] via 192.168.14.4, 00:07:06, FastEthernet0/0

O 10.4.9.0/24 [110/2] via 192.168.24.4, 00:07:06, FastEthernet0/0.2

[110/2] via 192.168.14.4, 00:07:06, FastEthernet0/0

! Another crucial part of information is the ARP table that resolves

! next hop IP addresses of hosts connected via Ethernet to MAC addresses

! Serial interface technologies in this example are point-to-point and

! hence require no Layer 3-to-Layer 2 mapping tables. This information will

! be used in construction of adjacency table entries

R1# show ip arp

Protocol Address Age (min) Hardware Addr Type Interface

Internet 192.168.14.4 41 0017.9446.b340 ARPA FastEthernet0/0

10.4.<8–9>.0/24

FD00:4:<8–9>::/64

10.3.<4–7>.0/24

FD00:3:<4–7>::/64

Serial0/0/0: HDLC

192.168.12.0/24

FD00:12::/64

Serial0/0/1: PPP

192.168.13.0/24

FD00:13::/64

MLS4

Fa0/0: Native VLAN

192.168.14.0/24

FD00:14::/64

Fa0/0.2: VLAN 2

192.168.24.0/24

FD00:24::/64

10.2.<0–3>.0/24

FD00:2:<0–3>::/64

Figure 6-3 Example Network Showcasing CEF Operation

ptg13046388

278 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Internet 192.168.14.1 - 0019.e87f.38e4 ARPA FastEthernet0/0

Internet 192.168.24.1 - 0019.e87f.38e4 ARPA FastEthernet0/0.2

Internet 192.168.24.4 41 0017.9446.b341 ARPA FastEthernet0/0.2

! show ip cef shows the FIB contents. In the following output, only routes

! learned via OSPF are shown for brevity reasons. Note how a set of prefixes

! resolves through a particular adjacency (next hop IP and egress interface).

R1# show ip cef 10.0.0.0 255.0.0.0 longer-prefixes

Prefix Next Hop Interface

10.2.0.0/24 192.168.12.2 Serial0/0/0

10.2.1.0/24 192.168.12.2 Serial0/0/0

10.2.2.0/24 192.168.12.2 Serial0/0/0

10.2.3.0/24 192.168.12.2 Serial0/0/0

10.3.4.1/32 192.168.13.3 Serial0/0/1

10.3.5.0/24 192.168.13.3 Serial0/0/1

10.3.6.0/24 192.168.13.3 Serial0/0/1

10.3.7.0/24 192.168.13.3 Serial0/0/1

10.4.8.0/24 192.168.24.4 FastEthernet0/0.2

192.168.14.4 FastEthernet0/0

10.4.9.0/24 192.168.24.4 FastEthernet0/0.2

192.168.14.4 FastEthernet0/0

! Similarly, for IPv6, the relevant outputs are:

R1# show ipv6 route ospf

! Output shortened and reformatted for brevity

O FD00:2::/64 [110/782] via FE80::2, Serial0/0/0

O FD00:2:1::/64 [110/782] via FE80::2, Serial0/0/0

O FD00:2:2::/64 [110/782] via FE80::2, Serial0/0/0

O FD00:2:3::/64 [110/782] via FE80::2, Serial0/0/0

O FD00:3:4::/64 [110/782] via FE80::3, Serial0/0/1

O FD00:3:5::/64 [110/782] via FE80::3, Serial0/0/1

O FD00:3:6::/64 [110/782] via FE80::3, Serial0/0/1

O FD00:3:7::/64 [110/782] via FE80::3, Serial0/0/1

O FD00:4:8::/64 [110/2] via FE80:24::4, FastEthernet0/0.2

via FE80:14::4, FastEthernet0/0

O FD00:4:9::/64 [110/2] via FE80:24::4, FastEthernet0/0.2

via FE80:14::4, FastEthernet0/0

R1# show ipv6 neighbors

IPv6 Address Age Link-layer Addr State Interface

FD00:14::4 1 0017.9446.b340 STALE Fa0/0

FD00:24::4 1 0017.9446.b341 STALE Fa0/0.2

FE80::3 - - REACH Se0/0/1

FE80:14::4 2 0017.9446.b340 STALE Fa0/0

ptg13046388

Chapter 6: IP Forwarding (Routing) 279

FE80:24::4 1 0017.9446.b341 STALE Fa0/0.2

R1# show ipv6 cef

! Output shortened and reformatted for brevity

FD00:2::/64 nexthop FE80::2 Serial0/0/0

FD00:2:1::/64 nexthop FE80::2 Serial0/0/0

FD00:2:2::/64 nexthop FE80::2 Serial0/0/0

FD00:2:3::/64 nexthop FE80::2 Serial0/0/0

FD00:3:4::/64 nexthop FE80::3 Serial0/0/1

FD00:3:5::/64 nexthop FE80::3 Serial0/0/1

FD00:3:6::/64 nexthop FE80::3 Serial0/0/1

FD00:3:7::/64 nexthop FE80::3 Serial0/0/1

FD00:4:8::/64 nexthop FE80:24::4 FastEthernet0/0.2

nexthop FE80:14::4 FastEthernet0/0

FD00:4:9::/64 nexthop FE80:24::4 FastEthernet0/0.2

nexthop FE80:14::4 FastEthernet0/0

! The show adjacency shows an abbreviated list of adjacency table entries

! Note that separate entries are created for IPv4 and IPv6 adjacencies,

! as the Protocol or EtherType field value in pre-constructed frame headers

! is different for IPv4 and IPv6

R1# show adjacency

Protocol Interface Address

IPV6 Serial0/0/0 point2point(12)

IP Serial0/0/0 point2point(13)

IPV6 Serial0/0/1 point2point(10)

IP Serial0/0/1 point2point(15)

IPV6 FastEthernet0/0.2 FE80:24::4(12)

IP FastEthernet0/0 192.168.14.4(23)

IPV6 FastEthernet0/0 FE80:14::4(12)

IP FastEthernet0/0.2 192.168.24.4(23)

IPV6 Serial0/0/1 point2point(4)

IPV6 FastEthernet0/0.2 FD00:24::4(5)

IPV6 FastEthernet0/0 FD00:14::4(7)

! Now focus on the adjacency table details. There are adjacencies via multiple

! interfaces. Serial0/0/0 is running HDLC. Note in the show adjacency detail

! command output the prepared HDLC header for all IPv6 prefixes (0F0086DD)

! and IP prefixes (0F000800) resolving through this adjacency.

R1# show adjacency s0/0/0 detail

Protocol Interface Address

IPV6 Serial0/0/0 point2point(12)

0 packets, 0 bytes

0F0086DD

ptg13046388

280 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

IPv6 CEF never

Epoch: 2

IP Serial0/0/0 point2point(13)

0 packets, 0 bytes

0F000800

CEF expires: 00:02:43

refresh: 00:00:43

Epoch: 2

! Similar output can be achieved for Serial0/0/1 that runs PPP. In the following

! output, note the prepared PPP headers for IPv6 (FF030057) and IPv4 (FF030021)

! prefixes resolving through these adjacencies. There are two IPv6 adjacencies

! present as IPV6CP specifically installs an adjacency towards the neighbor's link

! local address.

R1# show adjacency s0/0/1 detail

Protocol Interface Address

IPV6 Serial0/0/1 point2point(10)

0 packets, 0 bytes

FF030057

IPv6 CEF never

Epoch: 2

IP Serial0/0/1 point2point(15)

0 packets, 0 bytes

FF030021

CEF expires: 00:02:30

refresh: 00:00:30

Epoch: 2

IPV6 Serial0/0/1 point2point(4)

0 packets, 0 bytes

FF030057

IPv6 ND never

Epoch: 2

! Adjacencies on Fa0/0 show preconstructed Ethernet headers for the neighbors

! 192.168.14.4, FE80:14::4 and FD00:14::4 - destination MAC, source MAC, EtherType.

! Compare the MAC addresses with contents of ARP and IPv6 ND tables above.

R1# show adjacency fa0/0 detail

Protocol Interface Address

IP FastEthernet0/0 192.168.14.4(23)

0 packets, 0 bytes

00179446B3400019E87F38E40800

ARP 02:29:07

Epoch: 2

ptg13046388

Chapter 6: IP Forwarding (Routing) 281

IPV6 FastEthernet0/0 FE80:14::4(12)

0 packets, 0 bytes

00179446B3400019E87F38E486DD

IPv6 ND never

Epoch: 2

IPV6 FastEthernet0/0 FD00:14::4(7)

0 packets, 0 bytes

00179446B3400019E87F38E486DD

IPv6 ND never

Epoch: 2

! Finally, adjacencies on Fa0/0.2 show preconstructed Ethernet headers for

! neighbors 192.168.24.4, FE80:24::4 and FD00:24::4 - destination MAC, source MAC,

! 802.1Q VLAN tag, EtherType. Compare the MAC addresses with contents of ARP and

! IPv6 ND tables.

R1# show adjacency fa0/0.2 detail

Protocol Interface Address

IPV6 FastEthernet0/0.2 FE80:24::4(12)

0 packets, 0 bytes

00179446B3410019E87F38E481000002

86DD

IPv6 ND never

Epoch: 2

IP FastEthernet0/0.2 192.168.24.4(23)

0 packets, 0 bytes

00179446B3410019E87F38E481000002

0800

ARP 02:26:57

Epoch: 2

IPV6 FastEthernet0/0.2 FD00:24::4(5)

0 packets, 0 bytes

00179446B3410019E87F38E481000002

86DD

IPv6 ND never

Epoch: 2

Table 6-2 summarizes a few key points about the three main options for router switching

paths.

ptg13046388

282 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 6-2 Matching Logic and Load-Balancing Options for Each Switching Path

Switching Path Structures That Hold the Forwarding

Information

Load-Balancing Method

Process switching Routing table Per packet

Fast switching Fast-switching cache (per flow route

cache)

Per destination IP address

CEF FIB tree and adjacency table Per a hash of the packet

source and destination, or

per packet

The ip cef global configuration command enables CEF for all interfaces on a Cisco router.

For IPv6, the ipv6 cef command is used to activate CEF support. Note that it is possible

to run IPv4 CEF without IPv6 CEF, but the converse is not true: To run IPv6 CEF, IPv4

CEF must be active. The no ip route-cache cef interface subcommand can then be used

to selectively disable CEF on an interface.

Load Sharing with CEF and Related Issues

One of major advantages of CEF is its native support for different load-sharing mecha-

nisms, allowing the use of multiple paths toward a destination network if present in the

FIB. CEF supports two modes of load sharing: per-packet and per-destination. With

per-packet load sharing, packets destined to a destination network are distributed across

multiple paths in a packet-by-packet fashion. With the per-destination mode, the CEF

actually takes the source and destination IP address and optionally other data to produce

a hash value that identifies the particular path to carry the packet. In effect, for a particu-

lar source and destination pair, all packets flow through a single path. Other particular

source/destination address combinations toward the same destination network can

produce a different hash and thus be forwarded over a different path. In fact, the per-

destination load-sharing mode in CEF would be better called per-flow load sharing.

The per-destination load-sharing mode is the default (hardware-based CEF implementa-

tions might not support the per-packet load sharing mode), and in general, it is preferred

because it avoids packet reordering within a single conversation.

Per-destination load sharing in CEF is technically achieved by placing a so-called load-

share table between the FIB and the adjacency table. This loadshare table contains up

to 16 pointers to entries in the adjacency table, and the individual loadshare entries are

populated so that the counts of loadshare pointers to particular adjacency entries are

proportional to the costs of parallel routes toward the same destination. (That is, if there

are two equal-cost paths to the same destination, eight loadshare entries will point to one

next-hop adjacency entry while another eight loadshare entries will point to another next-

hop adjacency entry. If there are three equal cost paths, only 15 loadshare entries will be

populated, with each five loadshare entries pointing to one of the three next-hop adja-

cency entries.) When a packet arrives, the router performs a hashing operation over the

packet’s source and destination address fields, and uses the hash result value as an index

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 283

into the loadshare table to select one of the possible paths toward the destination. This

concept is illustrated in Figure 6-4 , also taken from the Cisco document “How to Choose

the Best Router Switching Path for Your Network,” Document ID 13706.

Forwarding Information

root

...

252

253

254

255

254

253

252

...

252

253

254

255

Loadshare Table Adjacency Table

253

Hash

254252

...

CEF Table

Figure 6-4 CEF Load Balancing

The particular method of per-packet or per-destination load sharing can be activated

on egress interfaces of a router using the ip load-share { per-destination | per-packet }

interface-level command. The availability of this command might be limited depending on

the hardware capabilities of the device. Often, multilayer switches performing hardware-

accelerated switching do not support this command while software-based ISR routers do.

With the hashing performed over fixed packet and/or segment address fields, a single

hash function produces the same result for all packets in a flow. While this is desirable

on a single router to always select a single path for a flow, it leads to unpleasant conse-

quences in a network where multiple routers down a path to a destination have multiple

routes toward it.

ptg13046388

284 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Consider the network shown in the Figure 6-5 .

64 Flows

32 Flows 32 Flows

10.0.0.0/24

R2 R3

R4 R5 R6 R7

Figure 6-5 CEF Polarization

Router R1 has two neighbors, R2 and R3, toward the destination network 10.0.0.0/24.

Let’s assume that it is receiving 64 different flows destined to stations inside the network

10.0.0.0/24. Under ideal conditions, 32 flows will be forwarded from R1 through R2 and

32 other flows will be forwarded through R3. On R2, we now expect that it again bal-

ances the 32 received flows across its neighbors, forwarding 16 flows through R4 and

another 16 flows through R5. However, if R2 is using the same hashing function as R1,

this is no longer the case. All 32 flows received by R2 have produced the same hashing

value on R1—that is why R2 is receiving all of them in the first place. Running the same

hashing function over these 32 flows will again produce the same value for all of them,

and as a result, R2 will no longer load-share them; rather, all 32 flows will be forwarded

from R2 through a single path to the destination. Thus, no load sharing will occur farther

down the path below R1. Quite the same fate will meet the remaining 32 flows on R3.

This phenomenon is called CEF polarization, and will cause the advantage of load sharing

to be lost quickly.

To avoid this, the basic CEF load-sharing mechanism has been enhanced. Each router

chooses a random 4B-long number called a Universal ID (details of its selection are not

public). This Universal ID is used as a seed in the hashing function used by CEF. Because

with high probability, different routers will have unique Universal IDs, they will also

produce different hashing results for a particular packet flow. As a result, a set of flows

producing a single hashing value on one router might produce a set of different hashing

values on another router, enabling the set of flows to be load-balanced again across mul-

tiple paths.

Key

Topic

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 285

In recent IOSs, there are multiple variations of the CEF load-sharing algorithm:

■ Original algorithm: As the name suggests, this is the original unseeded implementa-

tion prone to CEF polarization.

■ Universal algorithm: An improved algorithm using the Universal ID to avoid the

CEF polarization.

■ Tunnel algorithm: A further improvement on the Universal algorithm especially suit-

able to environments where tunnels are extensively deployed, possibly resulting in a

relatively small number of outer source/destination pairs. Avoids the CEF polariza-

tion. Might not be available for IPv6 CEF.

■ L4 port algorithm: Based on the Universal algorithm while also taking the L4 source

and/or destination ports into account. Avoids the CEF polarization.

Except from the Original algorithm, all other algorithms listed here avoid the CEF polar-

ization issue by seeding the hash function using the Universal ID. This ID can be speci-

fied for these algorithms in the ip cef load-sharing algorithm and ipv6 cef load-sharing

algorithm global configuration commands manually if necessary. This command is also

used to select the particular load-sharing algorithm as described in the preceding list. To

verify the current load-sharing mechanism and Universal ID value, the output of show

cef state , show ip cef summary , or show ip cef detail , especially the heading, shall be

examined (the output of these commands differs on different platforms).

The Catalyst 6500 platform (and some others that are directly derived from it, such as

selected 7600 Series supervisors and linecards), enjoying a long history of existence dur-

ing the time the details of CEF were fleshed out and perfected in software-based IOSs,

has its own set of workarounds about the CEF polarization problem. On this platform,

instead of the ip cef load-sharing algorithm command, the mls ip cef load-sharing com-

mand is used to select the load-sharing algorithm. The individual options are as follows:

■ Default ( default mls ip cef load-sharing ): Uses source and destination IP, plus the

Universal ID if supported by the hardware. Avoids CEF polarization.

■ Full ( mls ip cef load-sharing full ): Uses source IP, destination IP, source L4 port, and

destination L4 port. Does not use Universal ID. Prone to CEF polarization. However,

to alleviate its impact, this load-balancing algorithm causes the traffic to split equally

among multiple paths only if the number of paths is odd. With an even number of

parallel paths, the ratio of traffic split will not be uniform.

■ Simple ( mls ip cef load-sharing simple ): Uses source and destination IP only. Does

not use Universal ID. Prone to CEF polarization.

■ Full Simple ( mls ip cef load-sharing full simple ): Uses source IP, destination IP,

source L4 port, and destination L4 port. Does not use Universal ID. Prone to CEF

polarization. The difference from Full mode is that all parallel paths receive an equal

weight, and fewer adjacency entries in hardware are used. This mode avoids unequal

traffic split seen with Full mode.

ptg13046388

286 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Multilayer Switching

Multilayer Switching (MLS) refers to the process by which a LAN switch, which oper-

ates at least at Layer 2, also uses logic and protocols from layers other than Layer 2 to

forward data. The term Layer 3 switching refers specifically to the use of the Layer 3

destination address, compared to the routing table (or equivalent), to make the forward-

ing decision. (The latest switch hardware and software from Cisco uses CEF switching to

optimize the forwarding of packets at Layer 3.)

MLS Logic

Layer 3 switching configuration works similarly to router configuration—IP addresses

are assigned to interfaces, and routing protocols are defined. The routing protocol con-

figuration works just like a router. However, the interface configuration on MLS switches

differs slightly from routers, using VLAN interfaces, routed interfaces, and Port-channel

Layer 3 interfaces.

VLAN interfaces give a Layer 3 switch a Layer 3 interface attached to a VLAN. Cisco

often refers to these interfaces as switched virtual interfaces (SVI) . To route between

VLANs, a switch simply needs a virtual interface attached to each VLAN, and each

VLAN interface needs an IP address in the respective subnets used on those VLANs.

Note Although it is not a requirement, the devices in a VLAN are typically configured in

the same single IP subnet. However, you can use secondary IP addresses on VLAN inter-

faces to configure multiple subnets in one VLAN, just like on other router interfaces.

The operational state of SVI interfaces deserves a word on its own. For an MLS, an SVI

is the Layer 3 interface that interconnects the internal “router” inside the MLS with the

particular VLAN, much like an interface on a real router connects it to a particular net-

work. An MLS can directly send packets to or through a particular VLAN by forwarding

them over the corresponding SVI. These SVIs will be present in an MLS’s routing table as

egress interfaces for packets delivered into or through particular VLANs. The operational

state of an SVI should therefore reflect the true ability of the MLS to directly forward

packets into the corresponding VLAN. The SVI—despite being a virtual interface—must

not be in the “up, line protocol up” state if the MLS is not truly capable of forwarding

packets into the corresponding VLAN. In other words, the state of SVIs must mimic the

behavior of ordinary routers. If an interface is not in the “up, line protocol up” state, the

configured directly connected network on that interface and all routes formerly reachable

over it must be removed from the routing table, and can be put back only if the interface

becomes fully operational again.

There are two primary reasons why an MLS might be unable to forward packets into a

particular VLAN: Either that VLAN is not created and active on the MLS, or the VLAN

exists and is active but there is no physical Layer 2 interface on the switch allowing it to

forward frames into that VLAN. Consequently, the state of an SVI can be one of the

following:

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 287

■ Administratively down, line protocol down: The SVI interface is shut down.

■ Down, line protocol down: The corresponding VLAN does not exist, or is not in an

active state (the state suspend or shutdown commands were issued in the VLAN’s

configuration).

■ Up, line protocol down: The corresponding VLAN exists, but it is not allowed and

in an STP forwarding state on any Layer 2 switch port (access or trunk).

■ Up, line protocol up: The VLAN is created and the MLS is capable of forwarding

frames (and hence packets) into that VLAN.

To avoid the “up, line protocol down,” at least one of the following conditions must be

true:

■ At least one physical trunk that is itself in the “up, line protocol up” state must have

this VLAN allowed, not VTP pruned, and in the STP forwarding state. This can be

verified, for example, using the show interfaces trunk command (check the bottom-

most section labeled with “Vlans in spanning tree forwarding state and not pruned”).

■ At least one physical switch port that is itself in the “up, line protocol up” state must

have this VLAN configured as an access or voice VLAN and in the STP forwarding

state. This can be verified, for example, using show vlan and show spanning-tree

commands.

When using VLAN interfaces, the switch must take one noticeable but simple additional

step when routing a packet. Like typical routers, MLS makes a routing decision to for-

ward a packet. As with routers, the routes in an MLS routing table entry list an outgoing

interface (a VLAN interface in this case), as well as a next-hop Layer 3 address. The adja-

cency information (for example, the IP ARP table or the CEF adjacency table) lists the

VLAN number and the next-hop device’s MAC address to which the packet should be

forwarded—again, typical of normal router operation.

At this point, a true router would know everything it needs to know to forward the pack-

et. An MLS switch, however, then also needs to use Layer 2 logic to decide which physi-

cal interface to physically forward the packet already encapsulated in a Layer 2 frame.

The switch will simply find the next-hop device’s MAC address in the CAM and forward

the frame to that address based on the CAM.

Using Routed Ports and Port-channels with MLS

In some point-to-point topologies, VLAN interfaces are not required. For example, when

an MLS switch connects to a router using a cable from a switch interface to a router’s

LAN interface, and the only two devices in that subnet are the router and that one physi-

cal interface on the MLS switch, the MLS switch can be configured to treat that one

interface as a routed port . (Another typical topology for using router ports is when two

MLS switches connect for the purpose of routing between the switches, again creating a

case with only two devices in the VLAN/subnet.)

Key

Topic

Key

Topic

ptg13046388

288 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

A routed port on an MLS switch has the following characteristics:

■ The interface is not placed into any user-defined VLAN (internally in an MLS switch,

an internal usage VLAN is created for each individual routed port).

■ On most Catalyst platforms, a routed port cannot be configured with subinterfaces.

■ The switch does not keep any Layer 2 switching table information for the interface.

■ Layer 3 settings, such as the IP address, are configured under the physical interface,

just like a router.

■ The adjacency table lists the outgoing physical interface or Port-channel, which

means that Layer 2 switching logic is not required in these cases.

The internal usage VLAN created on behalf of a routed port deserves a special mention.

For a VLAN-aware MLS, all operations are performed within the context of a VLAN

in which the frame or packet is processed. The most natural way for these switches to

implement a routed port is in fact to create a hidden, standalone, and dedicated VLAN

for each separate routed port, and deactivate the typical Layer 2 control plane protocols

on it. These dedicated VLANs are called internal usage VLANs . On Catalyst switches

supporting an extended VLAN range, these internal usage VLANs are allocated from the

extended range, depending on the setting of the vlan internal allocation policy { ascend-

ing | descending } global configuration command. If the ascending option is used, inter-

nal usage VLANs are allocated from VLAN ID 1006 upward. Conversely, if the descend-

ing option is used, internal usage VLANs are allocated from VLAN ID 4094 downward.

On lower-end Catalyst platforms, this command is present in the configuration with the

ascending option but cannot be modified.

The current allocation of internal usage VLANs can be displayed only using the show

vlan internal usage command; they do not appear in common show vlan output. As an

example, observe the output in the Example 6-2 .

Example 6-2 Internal Usage VLANs Created for Routed Ports

! On this 3560G switch, ports GigabitEthernet0/12 and GigabitEthernet0/13 will

! be configured as routed ports, and the internal usage VLANs will be observed.

! The switch is configured with vlan internal allocation policy ascending

Switch(config)# do show vlan internal usage

VLAN Usage

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

Switch(config)# interface gi0/12

Switch(config-if)# no switchport

Switch (config-if)# do show vlan internal usage

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 289

VLAN Usage

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

1006 GigabitEthernet0/12

Switch(config-if)# exit

Switch(config)# interface gi0/13

Switch(config-if)# no switchport

Switch(config-if)# do show vlan internal usage

VLAN Usage

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

1006 GigabitEthernet0/12

1007 GigabitEthernet0/13

Internal usage VLANs are internal to the switch, and regardless of the VTP mode, they

are not stored in the VLAN database and are not advertised to any other switch in the

VTP domain. The assignment of internal usage VLANs to routed ports is therefore only

done at runtime and can differ between restarts of a switch, depending on the order that

the routed ports are configured and on the unused extended VLAN IDs.

Because of the relatively discreet nature of internal usage VLANs (they are not visible

in ordinary show vlan output), conflicts can ensue if an administrator tries to create an

extended VLAN whose ID is—unknowingly to the administrator—already used by an

internal usage VLAN, as shown in the Example 6-3 .

Example 6-3 Possible Internal Usage VLAN Conflict While Creating Extended VLANs

! Building on the previous example, internal usage VLANs 1006 and 1007 exist

! on this switch. An administrator is not aware about their existence, though,

! and tries to create VLAN 1006 for its own use. Notice how the switch refuses

! to add the VLAN only after exiting the VLAN configuration.

Switch(config)# do show vlan internal usage

VLAN Usage

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

1006 GigabitEthernet0/12

1007 GigabitEthernet0/13

Switch(config)# vlan 1006

Switch(config-vlan)# name SomeExtendedVLAN

Switch(config-vlan)# exit

% Failed to create VLANs 1006

VLAN(s) not available in Port Manager.

%Failed to commit extended VLAN(s) changes.

ptg13046388

290 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

This problem can become especially unpleasant if VTPv3 is used that is capable of han-

dling extended VLAN IDs. If the administrator creates an extended range VLAN on a

VTP Primary Server switch, and the particular VLAN ID is already used by an internal

usage VLAN on some other switch in the domain, VTP will fail to create this VLAN

on that switch, resulting in connectivity issues. The conflict will be logged only on

the switch experiencing the VLAN ID collision and so can elude the administrator’s

attention.

It is therefore generally recommended that if extended VLANs are used, they should be

allocated from the end of the extended VLAN range that is opposite to the current inter-

nal VLAN allocation policy, to minimize the risk of creating VLAN ID collisions.

Keeping all these facts in mind, a routed port is practically equivalent to a switch port

placed into a dedicated VLAN, with the Layer 2 control plane protocols deactivated on

that port. From this viewpoint, a routed port is a syntactical device in the configuration

to make the configuration quick and convenient, while the switch continues to handle the

port internally as a switch port with a slightly modified operation.

The following two configuration snippets in Example 6-4 are practically equivalent; just

the routed port is simpler to configure.

Example 6-4 Routed Port and Its Internal Treatment by a Multilayer Switch

! Following the previous example, assume the Gi0/12 is configured as follows:

Switch(config)# int gi0/12

Switch(config-if)# no switchport

Switch(config-if)# ip address 192.168.12.1 255.255.255.0

Switch(config-if)# do show vlan internal usage

VLAN Usage

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

1006 GigabitEthernet0/12

! The above configuration is effectively equivalent to the following configuration:

Switch(config)# vlan 1006

Switch(config-vlan)# exit

Switch(config)# no spanning-tree vlan 1006

Switch(config)# no mac address-table learning vlan 1006

Switch(config)# interface GigabitEthernet0/12

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan 1006

Switch(config-if)# switchport nonegotiate

Switch(config-if)# no vtp

Switch(config-if)# exit

Switch(config)# interface Vlan1006

Switch(config-if)# ip address 192.168.12.1 255.255.255.0

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 291

Ethernet Port-channels can be used as routed interfaces as well. To do so, physical inter-

faces must be configured with the no switchport command before adding them to a

channel group. The automatically created Port-channel interface inherits the configura-

tion of the first physical interface added to the channel group; if that interface is config-

ured as a routed interface, the entire Port-channel will be working as a routed port. An

existing Layer 2 Port-channel cannot be changed from Layer 2 to Layer 3 operation and

vice versa. If such a modification is necessary, it is first required to completely delete

the entire Port-channel, unbundle the physical ports, reconfigure them into the desired

mode of operation, and then add them into a channel group again, re-creating the Port-

channel interface in the process. Also, when using a Port-channel as a routed interface,

Port-channel load balancing should be based on Layer 3 addresses because the Layer 2

addresses will mostly be the MAC addresses of the two MLS switches on either end of

the Port-channel. Port-channels can also be used as Layer 2 interfaces when doing MLS.

In that case, VLAN interfaces would be configured with an IP address, and the Port-

channel would simply act as any other Layer 2 interface.

Table 6-3 lists some of the specifics about each type of Layer 3 interface.

Table 6-3 MLS Layer 3 Interfaces

Interface Forwarding to Adjacent

Device

Configuration Requirements

VLAN interface Uses Layer 2 logic and

Layer 2 MAC address

table

Create VLAN interface; VLAN must

also exist

Physical (routed)

interface

Forwards out physical

interface

Use the no switchport command to

create a routed interface

Port-channel

(switched) interface

Not applicable; just

used as another Layer 2

forwarding path

No special configuration; useful with

VLAN interfaces

Port-channel (routed)

interface

Balances across links in

Port-channel

Needs the no switchport command to

be used as a routed interface; optionally

change load-balancing method

MLS Configuration

The upcoming MLS configuration example is designed to show all the configuration

options. The network design is shown in Figures 6-6 and 6-7 . In Figure 6-6 , the physical

topology is shown, with routed ports, VLAN trunks, a routed Port-channel, and access

links. Figure 6-7 shows the same network, with a Layer 3 view of the subnets used in the

network.

Key

Topic

ptg13046388

292 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

MLS

FA0/0

FA0/1

FA0/0

MLS VLAN 12

VLAN 11

Server 1

Server 2

Server 3

Server 4

VLAN 12

VLAN 11

— Trunk (also a switchport)

— Routed Port

SW1

SW2

SW3

SW4

Figure 6-6 Physical Topology: Example Using MLS

MLS

172.31.21.0/24

172.31.22.0/24

172.31.23.0/24

MLS

Server 1

Server 2

Server 4

Server 3

V11

V12

VLAN 11

172.31.11.0/24

VLAN 12

172.31.12.0/24

Vx — VLAN Interface x

SW1

SW2

Figure 6-7 Layer 3 Topology View: Example Using MLS

A few design points bear discussion before jumping into the configuration. First, SW1

and SW2 need Layer 2 connectivity to support traffic in VLANs 11 and 12. In this

particular example, a trunk is used between SW1 and SW2 as well as between SW1/

SW2 and SW3/SW4. Focusing on the Layer 2 portions of the network, SW1 and SW2,

both distribution MLS switches, connect to SW3 and SW4, which are access layer

ptg13046388

Chapter 6: IP Forwarding (Routing) 293

switches. SW1 and SW2 are responsible for providing full connectivity in VLANs 11 and

12. Having full Layer 2 connectivity between switches in a topology is the traditional

approach. In newer deployments, a new approach is favored in which SW1 and SW2 are

interconnected through a routed port (Layer 3 link) only, and the connections toward

access layer switches are Layer 2 or even Layer 3. This allows for shrinking the size of

Layer 2 domain and the resulting scope of STP operation. If only a routed link was left

between SW1 and SW2, the Layer 2 topology between SW1/SW2 and SW3/SW4 would

be physically loop-free and there would be no ports blocked by STP, requiring little or no

reaction of STP if a link is added or removed.

Additionally, this design uses SW1 and SW2 as Layer 3 switches, so the hosts in VLANs

11 and 12 will use SW1 or SW2 as their default gateway. For better availability, the two

switches should use HSRP, VRRP, or GLBP. Regardless of which protocol is used, both

SW1 and SW2 need to be in VLANs 11 and 12, with connectivity in those VLANs, to be

effective as default gateways.

In addition to a Layer 2 trunk between SW1 and SW2, to provide effective routing,

it makes sense for SW1 and SW2 to have a routed path between each other as well.

Certainly, SW1 needs to be able to route packets to Router R1, and SW2 needs to be able

to route packets to Router R2. However, routing between SW1 and SW2 allows for easy

convergence if R1 or R2 fails.

Figure 6-6 shows two alternatives for routed connectivity between SW1 and SW2, and

one option for Layer 2 connectivity. For Layer 2 connectivity, a VLAN trunk needs to

be used between the two switches. Figure 6-6 shows a pair of trunks between SW1 and

SW2 (labeled with a circled T) as a Layer 2 Port-channel. The Port-channel would support

the VLAN 11 and 12 traffic.

To support routed traffic, the figure shows two alternatives: Simply route over the Layer

2 Port-channel using VLAN interfaces or use a separate routed Port-channel. First, to

use the Layer 2 Port-channel, SW1 and SW2 could simply configure VLAN interfaces

in VLANs 11 and 12. The alternative configuration uses a second Port-channel that will

be used as a routed Port-channel. However, the routed Port-channel does not function as

a Layer 2 path between the switches, so the original Layer 2 Port-channel must still be

used for Layer 2 connectivity. Upcoming Example 6-5 shows both configurations.

Finally, a quick comment about Port-channels is needed. This design uses Port-channels

between the switches, but they are not required. Most links between switches today use

at least two links in a Port-channel, for the typical reasons—better availability, better

convergence, and less STP overhead. This design includes the Port-channel to point out a

small difference between the routed interface configuration and the routed Port-channel

configuration.

Example 6-5 shows the configuration for SW1, with some details on SW2.

ptg13046388

294 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 6-5 MLS-Related Configuration on Switch1

! Below, note that the switch is in VTP transparent mode, and VLANs 11 and 12 are

! configured, as required. Also note the ip routing global command, without which

! the switch will not perform Layer 3 switching of IP packets.

vlan 11

vlan 12

! The ip routing global command is required before the MLS will perform

! Layer 3 forwarding. Similarly, ipv6 unicast-routing is required for

! IPv6 routing to be enabled. On selected Catalyst platforms, the use of

! distributed keyword is required, as the CEF operates in distributed mode

! on these switches - over multiple ASICs or line cards.

ip routing

ipv6 unicast-routing distributed

vtp domain CCIE-domain

vtp mode transparent

! Next, the configuration shows basic Port-channel creation commands, with the

! no switchport command being required before bundling physical ports into

! a Port-channel. Note the Port-channel interface will be created automatically.

interface GigabitEthernet0/1

no switchport

no ip address

channel-group 1 mode desirable

interface GigabitEthernet0/2

no switchport

no ip address

channel-group 1 mode desirable

! Next, the Port-channel interface is assigned an IP address.

interface Port-channel1

ip address 172.31.23.201 255.255.255.0

! Below, similar configuration on the interface connected to Router1.

ptg13046388

Chapter 6: IP Forwarding (Routing) 295

interface FastEthernet0/1

no switchport

ip address 172.31.21.201 255.255.255.0

! Next, interface Vlan 11 gives Switch1 an IP presence in VLAN11. Devices in VLAN

! 11 can use 172.31.11.201 as their default gateway. However, using HSRP is

! better, so Switch1 has been configured to be HSRP primary in VLAN11, and Switch2

! to be primary in VLAN12, with tracking so that if Switch1 loses its connection

! to Router1, HSRP will fail over to Switch2.

interface Vlan11

ip address 172.31.11.201 255.255.255.0

standby 11 ip 172.31.11.254

standby 11 priority 90

standby 11 preempt

standby 11 track FastEthernet0/1

! Below, VLAN12 has similar configuration settings, but with a higher (better)

! HSRP priority than Switch2's VLAN 12 interface.

interface Vlan12

ip address 172.31.12.201 255.255.255.0

standby 12 ip 172.31.12.254

standby 12 priority 110

standby 12 preempt

standby 12 track FastEthernet0/1

Note For MLS switches to route using VLAN interfaces, the ip routing global command

must be configured. MLS switches will not perform Layer 3 routing without the ip routing

command, which is not enabled by default. Similar comments apply to IPv6 routing that

needs to be enabled by ipv6 unicast-routing.

As stated earlier, the routed Port-channel is not required in this topology. It was included

to show an example of the configuration, and to provide a backdrop from which to dis-

cuss the differences. However, as configured, SW1 and SW2 are Layer 3 adjacent over the

routed Port-channel as well as through their VLAN 11 and 12 interfaces. So, they could

exchange interior gateway protocol (IGP) routing updates over three separate subnets. In

such a design, the routed Port-channel was probably added so that it would be the normal

Layer 3 path between SW1 and SW2. Care should be taken to tune the IGP implementa-

tion so that this route is chosen instead of the routes over the VLAN interfaces.

ptg13046388

296 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Policy Routing

All the options for IP forwarding (routing) in this chapter had one thing in common: The

destination IP address in the packet header was the only thing in the packet that was used

to determine how the packet was forwarded. Policy routing (or Policy-Based Routing

[PBR]) allows a router to make routing decisions based on information besides the desti-

nation IP address.

Policy routing’s logic begins, depending on IPv4 or IPv6 in use, with the ip policy or

ipv6 policy command on an interface. This command tells the IOS to process incoming

packets on that interface with different logic before the normal forwarding logic takes

place. (To be specific, policy routing intercepts the packet after Step 4, but before Step 5,

in the routing process shown in Figure 6-1 .) The IOS compares the received packets using

the route-map referenced in the ip policy or ipv6 policy command. Figure 6-8 shows the

basic logic.

Policy

Routing

Enabled?

Match

1st

Clause?

Match

2nd

Clause?

Permit

Deny?

Yes

Permit

Deny

No No

Match

Last

Clause?

Route Based on

set Command

Destination Based

Routing (Normal)

Figure 6-8 Basic Policy Routing Logic

Specifying the matching criteria for policy routing is relatively simple compared to defin-

ing the routing instructions using the set command. The route maps used by policy rout-

ing must match either based on referring to an ACL (numbered or named IPv4/IPv6 ACL,

using the match ip address or match ipv6 address command) or based on packet length

(using the match length command). To specify the routing instructions—in other words,

where to forward the packet next—use the set command. Table 6-4 lists the set com-

mands and provides some insight into their differences.

ptg13046388

Chapter 6: IP Forwarding (Routing) 297

Table 6-4 Policy Routing Instructions ( set Commands)

Command Comments

set ip next-hop ip-address [ .... ip-address ] Next-hop addresses must be in a connected

subnet; forwards to the first address in the

list for which the associated interface is up.

Supported for both IPv4 and IPv6.

set ipv6 next-hop ipv6-address [ ... ipv6-

address ]

set ip default next-hop ip-address [....

ip-address ]

Same logic as previous command, except policy

routing first attempts to route based on the

routing table, and only if no match is found in

the routing table, the packet will be handled

by PBR. Default route in the routing table is

ignored; that is, if the packet’s destination is

matched only by the default route, the packet

will be handled by PBR. Supported for both

IPv4 and IPv6.

set ipv6 default next-hop ipv6-address

[ ... ipv6-address ]

set interface interface-type interface-

number [ .... interface-type interface-

number ]

Forwards packets using the first interface in the

list that is up. Recommended only for point-

to-point interfaces; strongly discouraged for

multiaccess interfaces. Supported for both IPv4

and IPv6.

set default interface interface-type

interface-number [. . . interface-type

interface-number ]

Same logic as previous command, except policy

routing first attempts to route based on the

routing table, and only if no match is found in

the routing table, the packet will be handled

by PBR. Default route in the routing table is

ignored, that is, if the packet’s destination is

matched only by the default route, the packet

will be handled by PBR. Recommended

only for point-to-point interfaces; strongly

discouraged for multiaccess interfaces.

Supported for both IPv4 and IPv6.

set ip df number Sets the IP DF bit; can be either 0 or 1.

Supported only for IPv4.

set ip precedence number | name Sets IP precedence bits; can be a decimal value

in the range 0–7 or a textual name (IPv4 only).

Supported for both IPv4 and IPv6.

set ipv6 precedence number

set ip tos number | name Sets the ToS bits (delay, throughput, reliability,

monetary cost); can be decimal value or ASCII

name. Supported for IPv4 only.

The first four set commands in Table 6-4 are the most important ones to consider.

Essentially, you set either the next-hop IP address or the outgoing interface. Use the out-

going interface option only when it is of point-to-point technology type—for example,

do not refer to a LAN interface or multipoint Frame Relay subinterface. This will almost

Key

Topic

ptg13046388

298 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

certainly cause the policy-based routing to fail or act unexpectedly; details will be dis-

cussed later. Most importantly, note the behavior of the default keyword in the set com-

mands. Use of the default keyword essentially means that policy routing tries the default

(destination-based) routing first, and resorts to using the set command details only when

the router finds no matching route in the routing table. Note that a default route is not

considered a matching route by the default keyword. If a packet’s destination is matched

only by the default route, PBR treats this as if no match occurred, and the packet is eli-

gible to be forwarded according to the set commands using the default keyword.

The remaining set commands set the bits inside the ToS byte of the packet; refer to

Chapter 5 , “Classification and Marking,” in Volume II for more information about the

ToS byte and QoS settings. Note that you can have multiple set commands in the same

route-map clause. For example, you might want to define the next-hop IP address and

mark the packet’s ToS at the same time. A single route map entry can even contain mul-

tiple set statements specifying where the packet shall be forwarded. In such cases, the set

statements are evaluated in the following order:

1. set ip next-hop / set ipv6 next-hop

2. set interface

3. set ip default next-hop / set ipv6 default next-hop

4. set default interface

The use of set interface and set default interface is strongly recommended only with

point-to-point interfaces. Using multiaccess interfaces in these commands will lead to

PBR failing in most cases. IPv6 PBR using set [ default ] interface with a multiaccess

interface fails outright; differences in very selected cases have been observed under dif-

ferent IOS versions. IPv4 PBR under the same circumstances might appear to work but

the background processes are unintuitive: The router first performs a normal routing

table lookup for the packet’s destination IP address to look for the connected next-hop

address, and then tries to translate this next-hop address into the appropriate Layer

2 address on the multiaccess interface specified in the set [ default ] interface com-

mand. This can fail for obvious reasons: The routing table might provide no match for

the packet’s destination and thus the set [ default ] interface is skipped, or the next hop

itself might be connected to a different interface. Even Proxy ARP, if applicable, is not

going to help much—Cisco routers perform a validity check on received ARP responses

similar to a unicast reverse path forwarding check. A router verifies using its routing table

whether the sender IPv4 address in the ARP response’s body (the address whose MAC

address is being asked for) is reachable through the interface the ARP response came in.

If this check fails, the router will drop the ARP response, claiming that it arrived over the

“wrong cable” in the debug arp output. Once again, the use of set [ default ] interface

is appropriate only with point-to-point interfaces. IOS Releases 15.x display an explicit

warning if the command is used with multiaccess interface types.

The IPv6 PBR with set interface in particular has one more peculiarity: In some IOS ver-

sions, the router checks whether there is a matching route (ignoring the default route) for

the packet’s destination even if the packet is to be handled by PBR. If there is no match-

ing route in the routing table, the set interface command is ignored. It is also noteworthy

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 299

to mention that on some platforms, this behavior also depends on the state IPv6 CEF. The

particular behavior of the IOS in question should therefore be verified using debug ipv6

policy .

If PBR is required on a multilayer switch, many lower-end switches, such as Catalyst

3550, 3560, or 3750, require that the TCAM in the switch is repartitioned in a different

way, providing TCAM space for PBR entries while taking away space from entries of

other types. On these platforms, the size of TCAM regions for individual applications

cannot be configured individually; instead, a set of templates is prepared for typical

switch deployments. A switch should be configured with an appropriate TCAM parti-

tioning template that allocates the most space to the types of entries most required in the

particular switch’s mode of deployment. A template that provides space for PBR entries

must be active before the PBR can be configured. These templates are called Switch

Database Management templates, or SDM templates for short. Current SDM templates

can be shown using the show sdm prefer command, also displaying an approximate

space for different TCAM entry types. This command can be also used to view the

TCAM allocation policy for different templates if the show sdm prefer template-name

form is used. To allow for PBR usage on the switch models mentioned previously, either

the routing , access , or dual-ipv4-and-ipv6 routing (if supported) SDM template needs

to be used. On Catalyst 3650 and 3850 Series, the advanced SDM template is required.

To activate a particular template, the sdm prefer template-name global configuration

level command is used. After you issue this command, the switch must be reloaded. It is

strongly recommended to consult the appropriate switch model documentation for the

list of supported SDM templates and the individual features they activate.

Apart from PBR, changing the SDM template on an MLS might also be required if rout-

ing or IPv6 support are to be activated. One of indications that an inappropriate SDM

template is currently active is very visible: The IOS CLI appears to lack the commands

necessary to configure routing, PBR, or IPv6, even though the IOS should support these

features and the appropriate licenses are in place.

Routing Protocol Changes and Migration

The proper selection of a routing protocol for a network is always a sensitive (and under-

standably difficult) task. Many factors need to be taken into consideration, ranging from

the protocol’s scalability and speed of convergence through advanced features, ending

with compatibility issues especially in multivendor environments; all of these are related

to the network’s design and requirements. As the network evolves, it might become nec-

essary to reevaluate the choice of a particular routing protocol, and if it is found to be

inappropriate, it might need to be replaced.

Migrating from one routing protocol to another is always a disruptive change to the net-

work. It requires careful planning to minimize the outages, and even then, they are inevi-

table, although their duration can be kept very low. Therefore, a routing protocol migra-

tion always requires a maintenance window.

Key

Topic

ptg13046388

300 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Routing protocol migration is usually accomplished with the following steps:

Step 1. Plan the migration strategy.

Step 2. Activate the new routing protocol on all routers in the topology, raising its

administrative distance (AD) above the ADs of the current IGP. If the new IGP

is Routing Information Protocol (RIP) or Enhanced Interior Gateway Routing

Protocol (EIGRP), redistribution from the current into the new IGP has to be

configured on each router as well. The current IGP is left intact.

Step 3. Verify the new IGP’s adjacencies and optionally the working database

contents.

Step 4. Deactivate the current IGP in a gradual fashion.

Step 5. Remove the temporary settings from the new IGP.

We describe each of these steps in closer detail.

Planning the Migration Strategy

The deployment of a new routing protocol should be preplanned for the entire network,

including the division of network into separate areas if and when a link-state IGP is to

be used. Additionally, protocol features such as prefix summarization/filtration, stub

features, and external information redistribution can further isolate areas of the network

from one another. This planning should also involve the order in which routers will be

migrated over from the current IGP to the new one. Ideally, routers should be migrated

so that they form a contiguous, ever-growing part of the network running the new IGP,

gradually shrinking the contiguous remainder of the network in which both the current

and new IGP are run. If the current IGP is a link-state protocol, it is advisable to perform

the migration in a per-area fashion. The backbone routers should be the last ones to

migrate.

Activating New IGP While Keeping the Current IGP Intact

According to the planning in the previous step, the new IGP should be activated on the

routers in the network, first setting its administrative distance (AD) to a higher value

than the current IGP’s AD, and only then adding interfaces and networks to the new IGP

and activating selected features. The current IGP is left running and its configuration is

unchanged throughout this entire step. If the current IGP uses various ADs for different

network types (for example, EIGRP uses 90 and 170 for internal and external routes,

respectively), the new IGP’s AD should be reconfigured to be higher than the highest

AD used by the existing IGP. As an example, if the current IGP is OSPF and the new IGP

should be EIGRP, the ADs of EIGRP should, for the duration of the migration, be recon-

figured to, say, 210 and 220 for internal and external EIGRP routes, respectively. This

way, the new IGP can be deployed across the network, creating adjacencies between rout-

ers as usual but not influencing the routing tables and routing just yet. If the current IGP

configuration includes redistribution from other sources (static routes, directly connected

networks, and so on), the new IGP shall be configured similarly.

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 301

If the new IGP is a distance-vector routing protocol (RIP or EIGRP), each router must also

be configured with redistribution from the current IGP into the new IGP. Reasons for this

are explained later in the chapter.

Verifying New IGP Adjacencies and Working Database Contents

After the new IGP has been configured across the entire network, it should have created

adjacencies in the usual fashion though the routing tables are not populated by its routes

yet. These adjacencies should be verified to make sure that they are complete. After the

current IGP is deactivated, these adjacencies are the only routing protocol adjacencies left

between migrated routers, and so must be working as expected before the current IGP

starts being removed.

It is often recommended to verify the contents of the working databases in the new IGP

to check whether all expected networks are present, even though not placed into rout-

ing tables because of higher ADs. This step might be difficult to accomplish, though,

because of two reasons. First, the amount and format of the data can be overwhelming

to a human, requiring some kind of automated processing. The second reason is relevant

only if the new IGP is a distance-vector protocol, that is, either RIP or EIGRP. These

protocols advertise a learned route only if it is also installed in the routing table by the

same protocol. This additional advertisement logic in distance-vector routing protocols is

based on the fact that a router should not advertise a route it is not using itself. Because

the AD of the new IGP has been configured to be higher than the current IGP’s AD,

routes learned by the new IGP will not be placed into the router’s routing table as long as

the current IGP is still running on the router, and hence will not be advertised further. As

a result, if the new IGP is RIP or EIGRP, its working databases will contain only partial

contents until the migration starts, making the verification before migration impossible.

This behavior of distance-vector IGPs will be discussed in closer detail later in the chap-

ter. Note that this additional advertisement logic does not apply to link-state IGPs such

as OSPF and IS-IS, as the nature of routing information they generate and the flooding

mechanism are strongly different from distance-vector IGPs and do not allow for such

additional checks.

Deactivating Current IGP

The next step in the routing protocol migration involves the actual removal of the cur-

rent IGP from a contiguous set of routers, one router at a time, allowing the new routing

protocol to populate the routing table instead, and then proceeding to the next router.

Alternatively, instead of plainly deleting the current IGP configuration from the router, it

can be configured using the passive-interface default command that will effectively shut

it down. In recent IOS versions, selected routing protocols even support the protocol

shutdown or shutdown command. The obvious advantage of this approach is that the

configuration of the current IGP is preserved, should it ever be necessary to activate it

again quickly.

The removal or deactivation of the current IGP should be done in such a way that the

network always consists of at most two regions. In one, both routing protocols are run

Key

Topic

ptg13046388

302 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

(the unmigrated part of network), and in the other, only the new protocol is running (the

migrated part of the network) and both regions are contiguous.

During a properly executed migration, the network consists of a contiguous region that

runs both IGPs and of a contiguous region that runs the new IGP only. Traffic crossing

the network enters either an unmigrated or a migrated router, and is destined to a net-

work that is directly connected to a router that is again either migrated or unmigrated yet.

These options have an impact on which IGPs carry the information about the destination

and thus what source of routing information is used by routers along the way.

If traffic enters an unmigrated router and is destined to a network connected to an

unmigrated router, the destination network is advertised in both IGPs but the new IGP

has been configured with a higher AD, so it has no impact on the routing table contents.

Consequently, the traffic completely follows the path provided by the current IGP, as if

no migration was taking place.

If traffic enters a migrated router and is destined to a network connected to a migrated

router, the destination network is advertised only in the new IGP, as the current IGP has

been removed from the destination router. The current IGP does not advertise this net-

work anymore and does not compete about this particular network with the new IGP

(recall that it would otherwise be resolved in favor of the current IGP thanks to its lower

AD). Consequently, all routers, both migrated and unmigrated, know about this destina-

tion only through the new IGP, and follow the path provided by the new IGP.

If traffic enters an unmigrated router and is destined to a network connected to a

migrated router, the situation is very similar. As the current IGP has been removed from

the destination router, the destination network is advertised only in the new IGP. All rout-

ers therefore know about this network through the new IGP only and follow the path

provided by the new IGP.

Finally, if traffic enters a migrated router and is destined to a network connected to an

unmigrated router, the situation is slightly more complex. The destination router adver-

tises the network through both IGPs. Other unmigrated routers know the destination net-

work through both IGPs and prefer the current IGP, while migrated routers, including the

ingress router, know the network through the new IGP only. In the migrated path of the

network, the traffic will be routed according to the new IGP until it is forwarded to the

first unmigrated router. Starting with this router, all other routers on the path toward the

destination still prefer the path provided by the current IGP. Therefore, beginning with

this router, the traffic will be routed according to the current IGP.

This analysis shows that during a properly executed migration, the network remains fully

connected and destinations should remain fully reachable. Transient outages can occur at

the moment when the current IGP is removed from a router, as the routes provided by the

current IGP will need to be flushed from the routing table and replaced by routes learned

through the new IGP.

Key

Topic

ptg13046388

Chapter 6: IP Forwarding (Routing) 303

Removing New IGP’s Temporary Settings

After the network has been completely migrated to the new IGP and the previous IGP

has been completely removed from all routers, the new IGP still contains temporary set-

tings that were necessary for a seamless migration, especially the modified AD values,

leftovers from redistribution of the previous IGP into the new IGP, and so on. These set-

tings should be removed as the last step of the migration procedure. In link-state routing

protocols, removing the temporary settings should not cause any additional interruptions

in network service. However, in EIGRP, modifying the AD values causes the router to

drop and reestablish its EIGRP adjacencies with neighboring routers, causing a transient

disruption in network connectivity. These changes must therefore be also performed dur-

ing a maintenance window.

Specifics of Distance-Vector Protocols in IGP Migration

Ideally, migrating to a different routing protocol should not involve any route redistribu-

tion between the current and the new IGP, as the redistribution involves additional com-

plexity to the migration process. However, if the new IGP is a distance-vector protocol

(such as RIP or EIGRP), a temporary redistribution is inevitable. The reason lies in the

advertisement logic of these routing protocols: A learned route will be advertised further

only if the router has placed that very learned route into the routing table as well. In

other words, a learned route is advertised through the same routing protocol only if the

router is using that route itself. As the migration process involves temporarily configuring

the new IGP’s administrative distance (AD) to be higher than the AD of the current IGP,

none of the learned routes through the new IGP are going to be placed into the routing

table if the current IGP is still running. If the new IGP happens to be RIP or EIGRP, any

route learned through that protocol won’t make it into the router’s routing table and will

not be advertised further as a result. To illustrate this concept, consider the network in

Figure 6-9 (split horizon rules in EIGRP have been omitted for simplicity).

R2R1 R3 R4

10.1.0.0/24 10.2.0.0/24 10.3.0.0/24 10.4.0.0/24

10.12.0.0/24 10.23.0.0/24 10.34.0.0/24

EIGRP R1 R2 R3 R4

Advertises 10.1.0.0/24

10.12.0.0/23

10.12.0.0/24

10.2.0.0/24

10.23.0.0/24

10.3.0.0/24

10.34.0.0/24

10.4.0.0/24

Learns 10.2.0.0/24

10.23.0.0/24

10.1.0.0/24

10.3.0.0/24

10.34.0.0/24

10.12.0.0/24

10.2.0.0/24

10.4.0.0/24

10.23.0.0/24

10.3.0.0/24

Figure 6-9 Example Network Topology for Routing Protocol Migration

ptg13046388

304 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

OSPF is the current routing protocol in this network, and the network is planned to

be migrated to EIGRP. All four routers are therefore configured with EIGRP as well,

the EIGRP AD is set to 210 for internal and 220 for external routes, and all interfaces

are added to EIGRP on all routers. OSPF’s operation is not influenced in any way, and

because its AD remains at 110, routes still keep OSPF-learned routes in their routing

table. If we focus on R1’s operation and on the 10.1.0.0/24 network in particular, R1

advertises its directly connected networks, including 10.1.0.0/24 to R2 through EIGRP.

R2 will have this route in its EIGRP topology table but will be unable to install it into the

routing table because of EIGRP’s modified AD of 210. As a result, R2 will not propagate

the EIGRP-learned route 10.1.0.0/24 through EIGRP to R3, so neither R3 nor R4 will learn

about this network through EIGRP. This limited propagation of networks in EIGRP will

take place on each router in this topology: Each router will advertise its directly con-

nected networks in EIGRP to its immediate neighbors, but these neighbors are prevented

from advertising them further, as shown in Figure 6-9 . Looking into EIGRP topology

tables of all routers confirms this, as shown in Example 6-6 .

Example 6-6 Contents of EIGRP Topology Tables in Figure 6-9 Topology

! On all routers in the topology from Figure 6-9 , EIGRP is configured identically:

router eigrp 1

network 10.0.0.0

distance eigrp 210 220

no auto-summary

! It is assumed that OSPF is also running on all four routers.

! show ip eigrp topology on R1:

R1# show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.12.0.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.12.0.0/24, 1 successors, FD is 832000

via Connected, Serial0/0/0

P 10.2.0.0/24, 0 successors, FD is Inaccessible

via 10.12.0.2 (857600/281600), Serial0/0/0

P 10.1.0.0/24, 1 successors, FD is 281600

via Connected, FastEthernet0/0

P 10.23.0.0/24, 0 successors, FD is Inaccessible

via 10.12.0.2 (1344000/832000), Serial0/0/0

! show ip eigrp topology on R2:

R2# show ip eigrp topology

ptg13046388

Chapter 6: IP Forwarding (Routing) 305

IP-EIGRP Topology Table for AS(1)/ID(10.23.0.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.12.0.0/24, 1 successors, FD is 832000

via Connected, Serial0/0/1

P 10.2.0.0/24, 1 successors, FD is 281600

via Connected, FastEthernet0/0

P 10.3.0.0/24, 0 successors, FD is Inaccessible

via 10.23.0.3 (857600/281600), Serial0/0/0

P 10.1.0.0/24, 0 successors, FD is Inaccessible

via 10.12.0.1 (857600/281600), Serial0/0/1

P 10.23.0.0/24, 1 successors, FD is 832000

via Connected, Serial0/0/0

P 10.34.0.0/24, 0 successors, FD is Inaccessible

via 10.23.0.3 (1344000/832000), Serial0/0/0

! show ip eigrp topology on R3:

R3# show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.34.0.3)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.12.0.0/24, 0 successors, FD is Inaccessible

via 10.23.0.2 (1344000/832000), Serial0/0/1

P 10.2.0.0/24, 0 successors, FD is Inaccessible

via 10.23.0.2 (857600/281600), Serial0/0/1

P 10.3.0.0/24, 1 successors, FD is 281600

via Connected, FastEthernet0/0

P 10.4.0.0/24, 0 successors, FD is Inaccessible

via 10.34.0.4 (857600/281600), Serial0/0/0

P 10.23.0.0/24, 1 successors, FD is 832000

via Connected, Serial0/0/1

P 10.34.0.0/24, 1 successors, FD is 832000

via Connected, Serial0/0/0

! show ip eigrp topology on R4:

R4# show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.34.0.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

ptg13046388

306 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

P 10.3.0.0/24, 0 successors, FD is Inaccessible

via 10.34.0.3 (857600/281600), Serial0/0/1

P 10.4.0.0/24, 1 successors, FD is 281600

via Connected, FastEthernet0/0

P 10.23.0.0/24, 0 successors, FD is Inaccessible

via 10.34.0.3 (1344000/832000), Serial0/0/1

P 10.34.0.0/24, 1 successors, FD is 832000

via Connected, Serial0/0/1

Note that on each router, only directly connected networks of its immediate neighbors

are learned through EIGRP, and all these networks are marked with a “0 successors, FD is

Inaccessible” indication in their heading, preventing them from being advertised further.

After OSPF is removed from R4’s configuration as a step in the migration procedure, the

OSPF-learned 10.1.0.0/24 will be removed from R4’s routing table without being replaced

by an EIGRP-learned route, as R2 is still running OSPF and does not advertise this route

through EIGRP. This will cause connectivity outages: R4 will learn only about directly

connected networks from R3 through EIGRP, missing all other networks, and R3—still

running OSPF—will be unable to forward EIGRP-learned routes from R4 back to R2.

Clearly, full connectivity in this network will be restored only after OSPF is completely

removed.

The solution to this problem is to configure route redistribution from the current IGP into

the new IGP on each router in the topology. In the example network, the situation will

be significantly different, then: Because each router knows about all networks through

OSPF, redistributing them from OSPF into EIGRP allows each router to advertise them all

to each directly connected neighbor. While the neighbor will not be allowed to advertise

them further if still running OSPF, its EIGRP topology database will nonetheless be pop-

ulated with the full set of networks from its own neighbors. When OSPF is deactivated

on a router, EIGRP-learned routes will take over—they will get installed into the routing

table, and the router will be able to forward them further.

If the new IGP is a link-state protocol, this redistribution is unnecessary and shall not be

configured. Flooding of topological information in link-state protocols is not constrained

by routing table contents. Routers will always flood the routing information in a link-state

protocol, regardless of whether routes derived from that information are installed into

routing tables or not.

To analyze how this approach works, assume that the migration of the network in Figure

6-9 continues by gradual deactivation of OSPF, starting on R4 and proceeding router by

router toward R1. Table 6-5 summarizes how the individual networks are visible in the

routing tables of individual routers. Only the first two octets of each prefix are listed for

brevity. Prefixes in the O row are learned by OSPF; prefixes in the D row are learned by

EIGRP. Directly connected networks are not listed, as they are not influenced by changes

in routing protocols.

ptg13046388

Chapter 6: IP Forwarding (Routing) 307

Table 6-5 Contents of Routing Tables in Different Migration Stages

OSPF Run On R1 R2 R3 R4

R1 to R4 O 10.2/24

10.23/24

10.3/24

10.34/24

10.4/24

10.1/24

10.3/24

10.34/24

10.4/24

10.1/24

10.12/24

10.2/24

10.4/24

10.1/24

10.12/24

10.2/24

10.23/24

10.3/24

D None None None None

R1 to R3 O 10.2/24

10.23/24

10.3/24

10.34/24

10.1/24

10.3/24

10.34/24

10.1/24

10.12/24

10.2/24

None

D 10.4/24 10.4/24 10.4/24 10.1/24 (EX)

10.12/24 (EX)

10.2/24 (EX)

10.23/24

10.3/24

R1 to R2 O 10.2/24

10.23/24

10.1/24 None None

D 10.3/24

10.34/24

10.4/24

10.3/24

10.34/24

10.4/24

10.1/24 (EX)

10.12/24

10.2/24

10.4/24

10.1/24 (EX)

10.12/24

10.2/24

10.23/24

10.3/24

R1 only O None None None None

D 10.2/24

10.23/24

10.3/24

10.34/24

10.4/24

10.1/24

10.3/24

10.34/24

10.4/24

10.1/24

10.12/24

10.2/24

10.4/24

10.1/24

10.12/24

10.2/24

10.23/24

10.3/24

ptg13046388

308 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Key observations about this table are as follows:

■ Prefixes advertised from routers running both the original and new routing protocol

are learned by the original routing protocol on all routers still running it.

■ Prefixes advertised from routers running only the new routing protocol are learned

by the new routing protocol across the entire network.

■ At all times, all routers know about all prefixes.

■ Traffic entering a router running both routing protocols and destined to a network

on a router running both protocols is routed completely according to the original

routing protocol without changes. This is because the network is advertised in both

protocols and the new routing protocol’s AD has been intentionally raised above the

original protocol’s AD.

■ Traffic entering a router running the new routing protocol and destined to a network

on a router running the new protocol is routed completely according to the new rout-

ing protocol. This is because the network in question is not injected into the original

routing protocol anymore, so the only source of the information is the new protocol.

■ Traffic entering a router running both routing protocols and destined to a network

on a router running the new routing protocol is routed completely according to the

new routing protocol. The reason is the same as in the previous item.

■ Traffic entering a router running the new routing protocol and destined to a net-

work on a router running both routing protocols will be routed according to the

new routing protocol until it hits the first router that still runs both routing proto-

cols. Afterward, it will be routed according to the original routing protocol. This is

because in the migrated part of the network, routers run only the new routing proto-

col, while in the remaining part of network running both protocols, the original rout-

ing protocol is preferred.

The last four items are valid if the migration is performed in such a way that the network

always consists of at most two contiguous regions. In one, both routing protocols are run

(the unmigrated part of network), and in the other, only the new protocol is running (the

migrated part of the network). Also, if this rule is maintained throughout the migration

process, the boundary between the new and original routing protocol as described in the

last item is crossed only once.

ptg13046388

Chapter 6: IP Forwarding (Routing) 309

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter, as well as review items noted with a Key Topic icon.

Table 6-6 lists the protocols mentioned in or pertinent to this chapter and their respective

standards documents.

Table 6-6 Protocols and Standards for Chapter 6

Name Standardized In

Address Resolution Protocol (ARP) RFC 826

IPv6 Neighbor Discovery RFC 4861, RFC 5942

Differentiated Services Code Point (DSCP) RFC 2474

Table 6-7 lists some of the key IOS commands related to the topics in this chapter. (The

command syntax for switch commands was taken from the Catalyst 3560 Multilayer

Switch Command Reference, 15.0(2)SE . Router-specific commands were taken from the

IOS Release 15 mainline Command Reference.)

Table 6-7 Command Reference for Chapter 6

Command Description

show ip arp EXEC command that displays the contents of the IP ARP

cache.

show ipv6 neighbors EXEC command that displays the contents of the IPv6

neighbor cache.

[ no ] switchport Switch interface subcommand that toggles an interface

between a Layer 2 switched function ( switchport ) and a

routed port ( no switchport ).

[ no ] ip route-cache cef Interface subcommand that enables or disables CEF

switching on an interface.

[ no ] ip cef Global configuration command to enable (or disable) CEF

on all interfaces.

[ no ] ipv6 cef Global configuration command to enable (or disable) CEF

for IPv6 on all interfaces. For IPv6 CEF to be activated, ip

cef must also be present.

ptg13046388

310 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Description

[ no ] ip routing Enables IP routing; defaults to no ip routing and no ipv6

unicast-routing on a multilayer switch.

[ no ] ipv6 unicast-routing

ip policy route-map map-tag Router interface subcommand that enables policy routing

for the packets entering the interface.

ipv6 policy route-map

map-tag

Refer to Table 6-4 for the list of set commands related to policy routing.

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Fill In Key Tables from Memory

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD to check your answers.

Definitions

Next, take a few moments to write down the definitions for the following terms:

policy routing, process switching, CEF, polarization, MLS, ARP, Proxy ARP, routed

interface, fast switching, TTL, RIB, FIB, adjacency table, control plane, switched

interface, data plane, IP routing, IP forwarding

Refer to the glossary to check your answers.

Further Reading

For a great overview of router switching paths, refer to www.cisco.com/en/US/tech/

tk827/tk831/technologies_white_paper09186a00800a62d9.shtml .

For a good reference on load balancing with CEF, refer to http://cisco.com/en/US/tech/

tk827/tk831/technologies_tech_note09186a0080094806.shtml .

Details on implementing and troubleshooting static routing can be found in numerous

documents on the Cisco website. Recommended documents include "Specifying a Next

Hop IP Address for Static Routes" (Document ID 27082), "Route Selection in Cisco

Routers" (Document ID 8651), and "IOS Configuration Guide," in particular, the "IP

Routing: Protocol-Independent Configuration Guide" section.

ptg13046388

This page intentionally left blank

ptg13046388

Blueprint topics covered in this chap ter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ Introduction to dynamic routing protocols

■ Routing Information Protocol v.2

■ Routing Information Protocol for IPv6

ptg13046388

This chapter covers Routing Information Protocol version 2 (RIPv2) and Routing

Information Protocol next generation (RIPng) for IPv6, including most of the features,

concepts, and commands. Chapter 11 , “IGP Route Redistribution, Route Summarization,

Default Routing, and Troubleshooting,” covers some RIP details, in particular, route redis-

tribution between RIP and other routing protocols, and route summarization.

“Do I Know This Already?” Quiz

Table 7-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 7-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in This Section Score

RIPv2 Basics 1–2

RIPv2 Convergence and Loop Prevention 3–5

RIPv2 Configuration 6–7

Total Score

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. Which of the following items are true of RIP version 2?

a. Supports VLSM

b. Sends Hellos to 224.0.0.9

c. Allows for route tagging

d. Defines infinity as 255 hops

e. Authentication allows the use of 3DES

CHAPTER 7

RIPv2 and RIPng

ptg13046388

314 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

2. In an internetwork that solely uses RIPv2, after the network is stable and converged,

which of the following is true?

a. Routers send updates every 30 seconds.

b. Routers send updates every 90 seconds.

c. Routers send Hellos every 10 seconds, and send updates only when routes

change.

d. A routing update sent out a router’s Fa0/0 interface includes all RIPv2 routes in

the IP routing table.

e. A RIPv2 update’s routes list the same metric as is shown in that router’s IP rout-

ing table.

3. R1 previously had heard about only one route to 10.1.1.0/24, metric 3, through an

update received on its S0/0 interface, so it put that route in its routing table. R1 gets

an update from that same neighboring router, but the same route now has metric 16.

R1 immediately sends a RIP update out all its interfaces that advertises a metric 16

route for that same subnet. Which of the following are true for this scenario?

a. Split Horizon must have been disabled on R1’s S0/0 interface.

b. R1’s update is a triggered update.

c. R1’s metric 16 route advertisement is an example of a route poisoning.

d. The incoming metric 16 route was the result of a counting-to-infinity problem.

4. R1 is in a network that uses RIPv2 exclusively, and RIP has learned dozens of sub-

nets through several neighbors. Which of the following commands displays the cur-

rent value of at least one route’s age?

a. show ip route

b. show ip rip database

c. debug ip rip

d. debug ip rip event

ptg13046388

Chapter 7: RIPv2 and RIPng 315

5. R1 is in a network that uses RIPv2 exclusively, and RIP has learned dozens of sub-

nets through several neighbors. From privileged EXEC mode, the network engineer

types in the command clear ip route * . What happens?

a. R1 removes all routes from its IP routing table and tries to repopulate it.

b. R1 removes only RIP routes from its IP routing table.

c. After the command, R1 will relearn its routes when the neighboring router’s

Update timers cause them to send their next updates.

d. R1 immediately sends updates on all interfaces, poisoning all routes, so that all

neighbors immediately send triggered updates—which allow R1 to immediately

relearn its routes.

e. R1 will relearn its routes immediately by sending RIP requests out all its RIP-

enabled nonpassive interfaces.

f. None of the other answers is correct.

6. R1 has been configured for RIPv2 using only version 2 , network statements and no

auto-summary . The configuration includes a network 10.0.0.0 command. Which of

the following statements are true about R1’s RIP behavior?

a. R1 will send advertisements out any of its nonpassive interfaces in network

10.0.0.0.

b. R1 will process received advertisements in any of its interfaces in network

10.0.0.0, including passive interfaces.

c. R1 will send updates only after receiving a RIP Hello message from a neighbor-

ing router.

d. R1 can disable the sending of routing updates on an interface using the passive-

interface interface subcommand.

e. R1 will advertise the subnets of any of its interfaces connected to subnets of

network 10.0.0.0.

7. Which of the following represents a default setting for the Cisco IOS implementation

of RIPv2?

a. Split Horizon is enabled on all types of interfaces.

b. Split Horizon is disabled on Frame Relay physical interfaces and multipoint sub-

interfaces.

c. The default authentication mode, normally set with the ip rip authentication

mode interface subcommand, is MD5 authentication.

d. RIP will send triggered updates when a route changes.

ptg13046388

316 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Foundation Topics

Introduction to Dynamic Routing

Chapter 6 , “IP Forwarding (Routing),” focused on the processes concerned with using

a router’s routing table contents after it has been populated. Creating the contents of a

routing table and sharing it among routers, however, is one of the largest—and arguably

the most interesting—aspects of router operation. Apart from static routing, which is the

elementary approach to populating a routing table, dynamic routing protocols are used

in the majority of cases to fill routing tables on routers with correct information about

reachable networks and appropriate routes to them. Dynamic routing protocols constitute

messages exchanged between routers to detect their mutual presence and convey infor-

mation about the existing networks in the topology, and algorithms necessary to process

this information and advertise it throughout the network.

Each dynamic routing protocol covered on the CCIE Routing and Switching exam will be

devoted a separate chapter in this book. The general characteristics of all routing proto-

cols given in this particular section should therefore be taken as an introduction into the

subject matter, establishing the basic terminology and concepts. Although the chapter

focuses on an archetypal distance-vector routing protocol, RIP, this section also intro-

duces path-vector and link-state paradigms and compares them to the distance-vector

approach, so that the similarities and differences between the individual routing protocol

principles can be highlighted in one place.

Cisco routers and multilayer switches support a number of routing protocols, including

RIPv2, EIGRP, OSPF, IS-IS, and BGP. Each of these can be categorized by different cri-

teria. However, one of the most common—and most discerning—is the underlying prin-

ciple and nature of information the routing protocol uses to construct the routing table

contents: distance-vector and link-state.

Distance-vector-type routing protocols are principally founded on the exchange of dis-

tance vectors ; that is, arrays of distances to known networks. The term vector here

refers to a unidimensional array; in computer science, terms vector and unidimensional

array are synonyms. The term distance refers to the measure of feasibility, or a metric, of

reaching a particular network. Indeed, in distance-vector routing protocols, key messages

exchanged between routers contain arrays, with each element containing information

about one particular network known to the router originating the message, and that rout-

er’s distance to this network. A router learns about the existence of a network by receiv-

ing a message from its neighboring router that advertises the network. This neighbor then

becomes the next hop toward this network. If there are multiple neighbors that advertise

the same network, the router will choose that neighbor which provides the least total

metric to the network. If there are multiple such routers available, all of them can be used

as next hops (equal-cost multipath). After a router learns about a network from one or

more of its neighbors, chooses a next hop, and installs the route into its routing table, it

advertises the route itself, announcing its own distance from the destination. As a conse-

quence, each router advertises its own directly connected networks added to the routing

Key

Topic

ptg13046388

Chapter 7: RIPv2 and RIPng 317

protocol, plus all routes learned by that protocol that have been placed into the routing

table. (This is a sanity check performed by all distance-vector routing protocols on Cisco

routers: A route learned by a routing protocol will be further advertised only if it is also

placed into the router’s routing table; a router advertises only those routes used by itself.)

In distance-vector routing protocols, routers by definition exchange only lists of known

networks and their distances. They do not exchange information about the network’s

topology. Information present in any router’s working database does not allow recon-

structing the topology of the network. Processing the exchanged information is, from

the viewpoint of memory and algorithmic complexity, relatively simple. However, the

simplicity and limited nature of the information also makes these protocols generally

prone to the creation of routing loops. Various methods have been implemented to avoid

the creation of routing loops; however, only Enhanced Interior Gateway Routing Protocol

(EIGRP), using its advanced properties, is guaranteed to provide loop-free routing at

every instant. Both RIPv2 and EIGRP are distance-vector routing protocols.

An extension of the distance-vector principle is the path-vector routing protocol. The

path-vector paradigm is fundamentally the same as with distance-vector routing proto-

cols. Routers exchange messages about known networks and their distances, but in addi-

tion, each network is also accompanied by a list of path elements describing the path

toward the network. These path elements can be theoretically anything—router IDs of

individual routers, area numbers, and so on. In Border Gateway Protocol (BGP), the most

widely used path-vector routing protocol, these path elements are autonomous system

numbers: the list of autonomous systems the packet must traverse to reach its destination.

This path description can be used as a part of a best-path selection algorithm, but its

primary purpose is different: to allow routing loop avoidance. A router will not accept an

advertisement about a network whose path description already includes the identifier the

router would put into that advertisement itself. This prevents routing loops from occur-

ring. BGP is the only common routing protocol of the path-vector type. Some sources

even consider BGP simply as a distance-vector protocol.

In contrast to the distance-vector and path-vector paradigm, a link-state routing protocol

exchanges information about individual objects in the topology and their mutual inter-

connection. These objects include routers, multiaccess networks, routers on borders of

areas or entire autonomous systems, and networks from other areas or from outside the

autonomous system. In fact, the primary objects of interest in the link-state routing pro-

tocol are the routers themselves, and their links—interfaces connecting them together. IP

prefixes are often treated only as attributes, or properties, of these objects. After a router

has generated a message in which it describes itself and its links to immediately neighbor-

ing objects, this message is flooded without any modification to every other router in an

area. As a result, every router has exact information about the entire area’s topology: It

knows every router, every network, and every link. This detailed information about each

object in an area then allows the router to construct a so-called directed graph of the

topology (in essence a map of the topology) and use one of possibly many algorithms

that computes a tree of shortest paths (also called a shortest path tree) on this graph to

find all reachable destinations and least-cost paths toward them. Usually, the Shortest

Path First (SPF) algorithm invented by Edsger W. Dijkstra is used.

Key

Topic

Key

Topic

ptg13046388

318 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Link-state routing protocols operate over a very detailed representation of the network.

Dijkstra’s algorithm by its very nature does not construct routes containing loops.

Therefore, link-state routing protocols are significantly less prone to, though not guar-

anteed to avoid, routing loop creation. Temporary routing loops, or microloops, can still

occur when routers do not compute shortest paths using the same information—usu-

ally during network convergence. A single router’s detailed knowledge about the net-

work topology allows running network applications not possible with distance-vector

approaches, such as MPLS Traffic Engineering and MPLS Fast Re-Route (note that these

particular technologies are indicated as examples; they are not part of the CCIE Routing

& Switching blueprint).

It is often perceived that the downside to the link-state approach is the amount and

complexity of data that needs to be maintained in a router’s working database, as each

router has complete knowledge of the network topology. It is true that link-state routing

protocols require a router to hold more information, and processing the information into

a shortest-path tree is more CPU intensive in comparison to the distance-vector approach.

However, with the amounts of RAM and CPU power in modern routers, this argument

has become moot, and so have the rules of thumb that recommend no more than 50 rout-

ers in a single area.

What is, however, a fundamental property of link-state routing protocols—one that can

indeed be considered a downside—is their inability to perform route summarization,

filtering, or applying offset-lists in arbitrary places in network. This is because the topo-

logical information can only be modified by its originating router, and must not be other-

wise altered or filtered by any other router. Route summarization, filtering, and applying

offset-lists, on the other hand, constitute just that: modifying information that was pos-

sibly originated by a different router. Within an area, therefore, none of these operations

is available. If route summarization or filtering is required, it can be accomplished only

on area border routers, as these routers are in charge of carrying (that is, re-originating)

information in a distance-vector fashion from one area to another. Multiarea design with

link-state protocols in modern network deployments is therefore driven more by the

requirement to perform route summarization, filtering, and failure domain containment

rather than saving memory or CPU cycles.

As with all other mechanisms, there is no perfect routing protocol that suits each and

every purpose. The choice of a routing protocol is always an iterative task taking multiple

variables into account, and any particular choice might possibly require revisiting as the

network evolves and requirements change.

RIPv2 Basics

CCIE candidates might already know many of the features and configuration options

of RIPv2. Although RIPv2 is among the simplest routing protocols, it is clearly helpful

to review its operations to strengthen your grasp on interior gateway protocols (IGP) in

general and the differences between distance-vector and link-state protocols. This chap-

ter summarizes RIPv2’s protocol features and concepts. Table 7-2 provides a high-level

overview of RIPv2’s operation. We completely omit the details about RIPv1, though; the

classful nature of this protocol makes it unsuitable for today’s networks.

Key

Topic

ptg13046388

Chapter 7: RIPv2 and RIPng 319

Table 7-2 RIPv2 Feature Summary

Function Description

General

characteristic

Classless, distance-vector, timer-driven routing protocol

Transport protocol User Datagram Protocol (UDP), port 520

Metric Hop count, with 15 as the maximum usable metric, and 16 considered

to be infinite

Hello interval None; RIPv2 relies on the regular full routing updates instead

Update destination 224.0.0.9 multicast for RIPv2

Update interval 30 seconds

Full or partial

updates

Full updates each interval. For on-demand circuits, allows RIPv2 to

send full updates once, and then remain silent until changes occur, per

RFC 2091

Triggered updates Yes, when routes change

Authentication Allows both plain-text and MD5 authentication

Route tags Allows RIPv2 to tag routes as they are redistributed into RIPv2

Next Hop field Supports the assignment of a next-hop IP address for a route, allowing

a router to advertise a next-hop router that is different from itself

RIPv2 exchanges routes by sending RIPv2 updates on each RIPv2-enabled interface

based on the Update timer (update interval). A RIPv2 router advertises its connected

routes, as well as other RIPv2-learned routes that are in the router’s IP routing table.

RIPv2 routers do not form neighbor relationships, nor do they use a Hello protocol. Each

router simply sends updates, with destination address 224.0.0.9. RIPv2 routers can also

be configured to use the 255.255.255.255 broadcast IP address using the ip rip v2-

broadcast per-interface command, although this is not commonly done.

RIPv2 actually uses two types of messages: Requests and Responses. The message for-

mat for both message types is identical and is shown in Figure 7-1 .

RIPv2 Message

Octet 1 Octet 2 Octet 3 Octet 4

Command Version Must Be Zero

Address Family ID Route Tag

IP Address

Subnet Mask

Next Hop

Metric

Route Entry, Up to 25

in a Single RIP Message

Message Header

Figure 7-1 RIPv2 Message Format

Key

Topic

ptg13046388

320 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

A RIP message consists of a 4B-long header containing the command field (set to 1 for

Request, 2 for Response) and the version field (2 for RIPv2). The remaining two octets

are unused. The remainder of the message consists of routing entries, with each routing

entry occupying 20 octets in total. At most 25 routing entries can be placed into a single

RIP message. Each routing entry contains the address family identifier identifying the

format of the address information carried in the routing entry (only the value 2, IPv4—

also known as AF_INET—is commonly supported), route tag, and the route itself—its

address, netmask, recommended next hop, and metric.

A Request message is used to ask a neighbor to send a partial or a full RIP update imme-

diately, rather than waiting for the Update timer to expire, speeding the convergence. A

full RIP update is requested by a Request message containing exactly one routing entry

with the address family ID set to 0 and metric set to 16. Otherwise, if a Request message

lists one or more particular networks, only the update on these networks is requested. On

Cisco routers, Request messages for full updates are sent when the RIP process is being

started, a RIP-enabled interface comes up, or when the clear ip route * command is used

to clear the routing table. Partial requests do not appear to be used.

RIPv2 uses the hop-count metric, counting the number of routers that need to be tra-

versed till the destination network is reached, with 15 being the largest valid metric, and

16 considered to be infinity. Interestingly, a RIPv2 router does not put its own metric

in the route of a sent routing update; rather, it first adds 1 to each metric when build-

ing the update. For example, if a router has a route with metric 2, it advertises that route

with metric 3. In essence, RIPv2 increments the metric when sending updates; RIPng and

EIGRP increment metrics when receiving updates.

When Cisco RIPv2 routers learn multiple routes to the same subnet, the lowest-metric

route is chosen, of course. If multiple equal-hop routes exist, the router (by default)

installs up to 4 such routes in its routing table by default, or between 1 and 16 or even

32 of such routes, based on the maximum-paths setting under the router rip section.

The actual upper limit depends on the IOS version and router platform, and is not in fact

related to RIPv2 or any other protocol.

RIPv2 Convergence and Loop Prevention

The most interesting and complicated part of RIPv2—if there is anything truly compli-

cated in RIPv2—relates to loop-prevention methods used during convergence after a

route has failed. Some protocols, like OSPF, IS-IS, and EIGRP, include loop prevention as

a side effect of their underlying route computations. However, RIPv2, being a relatively

naïve distance vector protocol, uses several supplementary loop-prevention tools, most

of which constitute an added intelligence about where and when a route shall be adver-

tised and when a learned route shall be accepted, but which do not really change the

underlying fundamental nature of RIPv2’s best-path selection. Unfortunately, these loop-

prevention tools can also significantly increase convergence time—a fact that is among

the biggest negative features of RIPv2. Table 7-3 summarizes some of the key features

and terms related to RIPv2 convergence, with further explanations following the table.

ptg13046388

Chapter 7: RIPv2 and RIPng 321

Table 7-3 RIPv2 Features Related to Convergence and Loop Prevention

Function Description

Counting to Infinity If the next hop to a particular destination network advertises

that network with a suddenly increased metric, accept

the advertisement immediately and update our metric

accordingly. If the updated metric reaches infinity, stop using

that next hop.

Split Horizon Instead of advertising all routes out a particular interface,

RIPv2 omits the routes whose outgoing interface field

matches the interface out which the update would be sent.

Split Horizon with Poisoned

Reverse

A stronger variant of Split Horizon: All routes whose

outgoing interface matches the interface out which the

update would be sent are advertised with an infinite metric.

Route poisoning The process of sending an infinite-metric route in routing

updates when that route fails, prompting its rapid removal

from routing tables.

Triggered update The immediate sending of a new update when routing

information changes, instead of waiting for the Update timer

to expire. Only the changed network is sent in the triggered

update. Complete updates continue to be sent in regular

intervals.

Update timer The timer that specifies the time interval over which updates

are sent, defaulting to 30 seconds.

Invalid after timer A per-route timer (default 180 seconds) that is reset and

begins after an update about a route has been received from

its next hop. If the updates about the route from its next hop

cease to be received and the Invalid after timer reaches its

limit, the route is declared invalid and the Holddown timer

starts for this route.

Holddown timer A per-route timer (default 180 seconds) that begins after

a route has been declared invalid (that is, after the Invalid

after timer expires). The router starts advertising that route

as unreachable, does not accept any updated information,

and does not modify the routing table entry for that route

until the Holddown timer for that route expires.

Flushed after timer A per-route timer (default 240 seconds) that is reset and

begins after an update about a route has been received from

its next hop. If the updates about the route from its next hop

cease to be received and the Flushed after timer reaches its

limit, the router removes the route from the routing table

entirely.

Key

Topic

ptg13046388

322 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Several of these mechanisms are surprisingly misunderstood and even poorly docu-

mented. A few words about each of them are therefore in order.

The basic working principle of distance-vector routing protocols states that routers

exchange lists (that is, vectors) of known networks and their distances. For each network,

a router chooses the neighbor providing the least total metric as the next hop toward that

network, and installs the network through that particular neighbor into its routing table.

All other routers advertising the same network with a higher total distance are ignored.

There is only one crucial exception to this rule: If the next-hop router for a destination

network suddenly advertises a higher distance than the last time, this advertisement is not

ignored but rather accepted immediately. The receiving router will update the total dis-

tance to the network in its routing table, and it will advertise the increased total distance

itself but it will otherwise keep the network and its current next hop in the routing table.

Only a subsequent arrival of an update from a different neighbor providing a lower total

metric would cause the router to change the next hop. While perhaps slightly surprising,

the logic here is straightforward: If a next hop has become more distant from the desti-

nation than it was before, so have become all routers that still traverse through this next

hop.

This logic immediately leads to the existence of the mechanism known as Counting to

Infinity. If, for some reason (usually caused by deactivated Split Horizon and race condi-

tions in timing), two neighboring routers start mutually considering themselves as next

hops toward the same destination network, each of them will derive its own metric from

the metric of its neighbor. Assume two neighbors, routers X and Y, pointing to each other

in a tight routing loop for a destination network N. If X advertises the network N with a

metric of 1, Y will advertise this network with a metric of 2. Because Y is X’s next hop,

X will accept this update right away and increase its own metric to 3. After advertising

it, Y will also accept this update immediately, as X is Y’s next hop, and increase its own

metric to 4. After Y sends another advertisement to X, the metric on X will increase to 5,

after which X will advertise this network to Y, causing it to raise its distance to 7, and so

on. This process will—theoretically—continue ad infinitum, hence the name Counting to

Infinity. Because distance-vector routing protocols have a concept of an infinite metric—

a metric whose value represents an unreachable network—after one of routers X or Y

reaches this metric, it will drop the route from its routing table, finally breaking the loop.

This is how the Counting to Infinity mechanism leads to gradual, albeit slow, elimination

of routing loops after they have occurred. It is noteworthy to mention that Counting to

Infinity is not an additional enhancement to the distance-vector principle but simply a

consequence of it.

The Split Horizon is a well-known principle, stating that a network should never be

advertised back over the interface that is used to reach that network , because that

interface leads back to the next hop toward that route and we do not want to risk a situ-

ation where the next hop suddenly loses the route while we inadvertently trick it into

believing we are providing a backup path. In the Cisco RIPv2 implementation, Split

Horizon is by default activated on most interfaces, notable exceptions being physical

Frame Relay and ATM interfaces. The state of RIPv2 Split Horizon can be verified in the

show ip interface command output.

Key

Topic

Key

Topic

ptg13046388

Chapter 7: RIPv2 and RIPng 323

An augmented version of Split Horizon is the addition of the Poisoned Reverse mecha-

nism, resulting in Split Horizon with Poisoned Reverse. This principle states that a net-

work should always be explicitly advertised as unreachable over the interface that is

used to reach that network . This version of Split Horizon is stronger than its basic ver-

sion: Instead of simply not advertising the route back toward its next hop, silently hoping

the next hop has never considered us a possible backup for this path, we explicitly force

the next-hop router to avoid and ignore us when choosing the best path to the network.

While more effective, it is not implemented in the Cisco RIPv2.

Route Poisoning is a mechanism used to rapidly flush a route that has become unreach-

able. Doing this is accomplished by advertising this route with the metric set to infinity. A

router that receives an update about a network from its next hop with an infinite metric

will immediately remove the route to the network through that particular next hop from

its routing table. If this was the only route to the network, the router will itself advertise

that network as being unreachable to its neighbors. As a result, the information about the

unreachability will propagate toward and through all routers whose old path to the (now

unreachable) network traversed through the failure point. Routers that receive an update

about an unreachable network from different neighbors than their respective next hops

are not influenced (the message is indistinguishable from a Split Horizon with Poisoned

Reverse advertisement—they process it accordingly but it has no effect on their routing

tables). Hence, routers on the affected route expire the old route rapidly, allowing it to

converge on a backup path significantly faster.

Even though a route is removed from the routing table during a Route Poisoning proce-

dure, RIP will still keep the route in its internal database (see the show ip rip database

command), marked as possibly down . This is done to allow the route to be repeatedly

advertised as unreachable, as a single advertisement can get lost (keep in mind that RIP

is UDP-based and has no acknowledgments). The unreachable route will be flushed from

the RIP internal database after Flushed after – Invalid after seconds. These timers will

be discussed in more detail further in the chapter.

It is important to distinguish between the relatively similar terms Poisoned Reverse and

Route Poisoning . They both refer to an action of advertising a network with an infinite

metric. What makes the two terms different is the purpose of advertising a network as

unreachable: Poisoned Reverse is an extension to the Split Horizon principle that adver-

tises a route as unreachable back to its next hop to prevent it from creating a routing

loop, while Route Poisoning advertises a truly unreachable route to quickly flush it from

routing tables and to allow a backup path to take over.

Triggered updates are updates in RIPv2 that are sent in the moment of detecting a change

in reachability of a network, rather than waiting for the full Update interval to expire.

Connecting or learning about a new network, disconnecting it or learning about its

unreachability, or a change to its metric will cause a router to immediately send an adver-

tisement with the updated information. This update commonly carries only the changed

network, without listing all other known networks. They continue to be advertised, along

with the changed information, in regular intervals driven by the Update timer. In debugs

and Cisco documents, these triggered updates are also called flash updates . Triggered

updates in RIPv2 shall not be confused with Triggered Extensions to RIPv2 covered in

Key

Topic

Key

Topic

Key

Topic

ptg13046388

324 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

RFC 2091, which are a different mechanism (adaptation of RIPv2 for on-demand circuits

so that the updates are sent only in moments of topology change to avoid keeping the

on-demand circuit permanently up).

The Holddown mechanism is frequently misunderstood. Its main purpose is to delay

processing updates about a network whose reachability has become questionable,

as the received updates might not yet contain up-to-date information . To understand

this mechanism better, assume that a router suddenly stopped receiving updates about

a particular network from its only next hop toward that network. This network has not

been declared unreachable by the next hop. Rather, updates (if any) received from that

next hop simply do not list that network anymore. This can happen for various reasons,

including the following:

■ Update might have been lost in transit or dropped (ACLs, rate limit, and so on).

■ Next-hop router might have been turned off or crashed without the link going down.

■ Next-hop router might have started considering us as its own next hop and uses plain

Split Horizon.

■ RIPv2 process on the next-hop router might have been removed.

■ Summarization, route filtering, or passive interface might have been activated.

■ Next-hop router might be running a RIPv2 implementation that does not support

Route Poisoning, so when a network truly goes down, it simply stops being adver-

tised.

In any case, the ongoing lack of any information about a network from its next hop is

tolerable for a limited time period (to account for UDP’s lack of reliability), but if its

absence exceeds a reasonable time, it is clear that “something happened.” Unfortunately,

it is not clear what exactly has occurred, and it is even less clear whether the non-next-

hop neighbors that claim reachability to this network already know about this possible

outage and use a different route. Therefore, the router that has detected a sudden loss of

reachability information for a network must not immediately accept the updates from its

neighbors; rather, it must give them certain time to learn about the outage and converge

to a different path. Only after this time, updates from other routers regarding the missing

network can be accepted as trustworthy again.

To accomplish this, Cisco routers implement two independent RIPv2 timers: the Invalid

after timer and the Holddown timer. The Invalid after timer is reset every time an

update about a network from its next hop arrives, and is incremented each second. A

route is considered perfectly usable if an update about it has been received within the last

180 seconds, which is the default upper limit for the Invalid after timer. If, however, the

Invalid after timer has reached the upper limit and an update about this network has not

been received, the network is considered invalid. In such case, the following happens:

■ Router declares the network invalid—to be of questionable reachability. This is vis-

ible in the show ip route output by a comment of “is possibly down.” The Invalid

after timer is stopped for this network.

Key

Topic

ptg13046388

Chapter 7: RIPv2 and RIPng 325

■ Router starts the Holddown timer for this network. While the timer runs (180 sec-

onds by default), the router itself advertises the network with infinite metric (Route

Poisoning) to force its neighbors to find an alternative route if possible. Additionally,

the router locks the routing entry in its routing table, still pointing toward the former

next hop. Absolutely no updates whatsoever are accepted until the Holddown timer

expires, regardless of who sends them and what metric they claim.

■ After the Holddown timer expires, the router unlocks the routing entry in its rout-

ing table and converges through a neighbor that offers the lowest metric route to the

network.

There are a number of noteworthy facts about this entire procedure. First, the procedure

is not triggered by the arrival of an update that advertises an unreachable network. Such

an update would be nothing else than Route Poisoning that would cause the route to be

dropped from the routing table immediately (even though it would be kept in the RIP

internal database for Flushed after – Invalid after seconds as described earlier, to allow

the route to be advertised as unreachable for a period of time). Rather, this procedure is

invoked after the reachability of a network can be neither confirmed nor refuted for a

period of time.

Second, after a router puts a route into the invalid state, it advertises that route as

unreachable itself. This action is very natural—it is like saying: “I know there is some

problem in reaching this network, although I do not know what exactly happened.

Whoever uses me as a next hop, stop doing that, and try to find another route that

bypasses me.” As a result, after a router has put a route into the invalid state, it forces its

neighbors to find a detour if any exists. If a neighbor still advertises the network some

time after it has been told it is not reachable through us anymore, it must know a differ-

ent path to it.

Third, a router never updates an invalid route while the Holddown timer runs. Before it

was declared invalid, it pointed toward a next hop. After the next hop stopped advertis-

ing that network altogether and the Invalid after timer expired, the route was declared

invalid and started being advertised as unreachable, but the router still keeps it locked

in the routing table, pointing toward the former next hop, until the Holddown timer

expires. The general idea here is that it is better to blackhole the traffic rather than create

a routing loop by prematurely trusting a different neighbor that claims to have a route

toward the failed network.

Fourth, the last bullet in the previous holddown procedure assumes that there is an alter-

native route to the destination. If there truly is a detour path, the router will learn about it

after the Holddown timer expires and the routing entry is unlocked. However, the failed

route might have been the only path to the destination, and there might be no alternative

path available, so no neighbor will advertise it. That would cause the routing entry to lin-

ger in the routing table indefinitely, still pointing toward the previous next hop.

Therefore, to prevent a route that has stopped being advertised from lingering in rout-

ing tables indefinitely, yet another timer is present: the Flushed after timer. Similarly to

Invalid after , the Flushed after timer is reset every time an update about a network from

its next hop arrives, and is incremented each second. If the Flushed after timer reaches

Key

Topic

ptg13046388

326 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

its upper limit, the route is immediately flushed from the routing table. If this was the last

instance of the route toward a particular network, the network will be also advertised as

unreachable along with its removal. That will conclude its existence in routing tables.

The default setting of RIPv2 timers on Cisco routers is 30 seconds for Update , 180 sec-

onds for Invalid after and Holddown , and 240 seconds for Flushed after . The default

timer setting actually does not allow the Holddown timer to completely expire. If a net-

work stops being advertised by its next hop, it will be put into an invalid state 180 sec-

onds after the last update about it arrived from the next hop. The Holddown timer then

starts, but after 60 seconds, the Flushed after timer that starts in tandem with the Invalid

after timer will expire, and the router will remove the route entirely along with all associ-

ated timers. As a result, the effective Holddown period is only 60 seconds.

It turns out that in Cisco implementation, the Flushed after timer’s value is verified

only after the route has been moved to invalid state (that is, after the Invalid after timer

expires). As an example, if the Invalid after was set to 180 seconds but the Flushed after

was set just to 120 seconds, both timers would be reset and increasing simultaneously

after the last update, but if the updates ceased, the route would be kept in the routing

table until the Invalid after timer fired, that is, the next 180 seconds. At that moment,

the router would also check the Flushed after timer and find out the route should have

been removed 60 seconds ago, so it would remove it within a few seconds. In other

words, the Flushed after timer has no effect on a route that is still considered valid (that

is, its age is less than the upper limit of Invalid after ). If you perform an experiment to

verify this behavior in a lab, you might find that the reaction to the Flushed after timer is

delayed by roughly 10 seconds, probably caused by the timing granularity used by IOS.

The rest of this section shows examples of the convergence features, using RIP show

and debug command output to show examples of their use. Figure 7-2 shows the sample

internetwork that is used in these examples of the various loop-prevention tools.

103.3/24

E0/0

103.4/24

E0/0

24.1/30

S0/0.2

24.2

S0/0.4

11.2/24

11.1/24

Fa0/0

13.2/30

S0/0.1

Falling Interfaces

13.1/30

S0/0.3

Network 172.31.0.0

Figure 7-2 Sample Internetwork Used for Loop-Prevention Examples

ptg13046388

Chapter 7: RIPv2 and RIPng 327

Converged Steady-State Operation

Example 7-1 shows a few details of R1’s operation while all interfaces in Figure 7-2 are up

and working. The example lists the basic (and identical) RIPv2 configuration on all four

routers; configuration will be covered in more detail later in the chapter. As configured,

all four routers are using only RIPv2, on all interfaces shown in Figure 7-2 . Read the com-

ments in Example 7-1 for explanations of the output. In a stable network, no triggered

updates need to be sent, and all routers send their updates each Update interval seconds,

which is 30 by default.

Example 7-1 Steady-State RIPv2 Operation in Figure 7-2

! All routers use the same three lines of RIPv2 configuration.

router rip

network 172.31.0.0

version 2

! Below, the show ip protocols command lists many of RIPv2's operational settings,

! including RIPv2 timers, version used, and neighbors from which RIPv2 updates have

! been received (listed as "Routing Information Sources").

R1# show ip protocols

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 24 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Redistributing: RIPv2

Default version control: send version 2, receive version 2

Interface Send Recv Triggered RIP Key-chain

FastEthernet0/0 2 2

Serial0/0.3 2 2

Automatic network summarization is in effect

Maximum path: 4

Routing for Networks:

172.31.0.0

Routing Information Sources:

Gateway Distance Last Update

172.31.11.2 120 00:00:15

172.31.13.2 120 00:00:08

Distance: (default is 120)

! Below, the current age is listed by each RIP route. Note that it took

! about 3 seconds between the above show ip protocols command and the upcoming

! show ip route command, so the last update from 172.31.13.2 (above)

! was 8 seconds; 3 seconds later, the age for a route learned from

ptg13046388

328 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! 172.31.13.2 is now 11 seconds.

R1# show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.31.0.0/16 is variably subnetted, 4 subnets, 2 masks

R 172.31.24.0/30 [120/1] via 172.31.11.2, 00:00:18, FastEthernet0/0

C 172.31.11.0/24 is directly connected, FastEthernet0/0

C 172.31.13.0/30 is directly connected, Serial0/0.3

R 172.31.103.0/24 [120/1] via 172.31.13.2, 00:00:11, Serial0/0.3

! Below, the show ip rip database command lists information for each route

! considered by RIP.

R1# show ip rip database

172.31.0.0/16 auto-summary

172.31.11.0/24 directly connected, FastEthernet0/0

172.31.13.0/30 directly connected, Serial0/0.3

172.31.24.0/30

[1] via 172.31.11.2, 00:00:01, FastEthernet0/0

172.31.103.0/24

[1] via 172.31.13.2, 00:00:23, Serial0/0.3

Note The show ip rip database command lists all RIP learned routes and all connected

routes that RIP is advertising.

Triggered (Flash) Updates and Poisoned Routes

When RIPv2 knows for sure that a route to a subnet has failed, RIPv2 can converge to an

alternate route relatively quickly. Example 7-2 details the steps behind one such example,

using Figure 7-2 , with the steps outlined in the following list (the comments in Example

7-2 refer to these steps by number):

1. RIPv2 debug messages show R1’s RIPv2 updates, including R1’s use of split horizon.

2. R3’s E0/0 interface is shut down, simulating a failure.

ptg13046388

Chapter 7: RIPv2 and RIPng 329

3. R3 immediately sends a triggered update (also called a flash update), because R3

knows for sure that the route has failed. R3’s behavior combines a triggered update

with route poisoning, as R3’s advertised route is a poisoned route to now unreach-

able network 172.31.103.0/24.

4. R1 immediately (because of triggered updates) sends a triggered update out all its

interfaces, advertising a poisoned route for 172.31.103.0/24.

5. R1 removes its route to 172.31.103.0/24 from its routing table.

6. R1 waits for R2’s next update, sent based on R2’s Update timer on its Fa0/0 interface.

That update includes a route to 172.31.103.0/24. R1 adds that route to its routing

table.

Example 7-2 R1’s Convergence for 172.31.103.0/24 Upon R3’s E0/0 Interface Failure

! First, the debug ip RIPv2 command enables RIPv2 debugging. This command will show

! messages that show every route in the sent and received updates.

R1# debug ip RIPv2

RIPv2 protocol debugging is on

! (Step 1) Below, the output exhibits split horizon - for example, 172.31.103.0/24

! is not advertised out s0/0.3, but it is advertised out Fa0/0.

*Mar 3 22:44:08.176: RIPv2: sending v2 update to 224.0.0.9 via S0/0.3 (172.31.13.1)

*Mar 3 22:44:08.176: RIPv2: build update entries

*Mar 3 22:44:08.176: 172.31.11.0/24 via 0.0.0.0, metric 1, tag 0

*Mar 3 22:44:08.176: 172.31.24.0/30 via 0.0.0.0, metric 2, tag 0

*Mar 3 22:44:12.575: RIPv2: sending v2 update to 224.0.0.9 via Fa0/0 (172.31.11.1)

*Mar 3 22:44:12.575: RIPv2: build update entries

*Mar 3 22:44:12.575: 172.31.13.0/30 via 0.0.0.0, metric 1, tag 0

*Mar 3 22:44:12.575: 172.31.103.0/24 via 0.0.0.0, metric 2, tag 0

! Next, R1 receives a RIPv2 update from R3. The metric 1 route in the update below

! is R1's best route, and is placed into R1's routing table. Note that the metric

! in the received update is R1's actual metric to reach the route.

*Mar 3 22:44:21.265: RIPv2: received v2 update from 172.31.13.2 on S0/0.3

*Mar 3 22:44:21.269: 172.31.24.0/30 via 0.0.0.0 in 2 hops

*Mar 3 22:44:21.269: 172.31.103.0/24 via 0.0.0.0 in 1 hops

! (Step 2) R3's E0/0 interface is shut down at this point. (Not shown).

! (Step 3) Below, R1 receives a triggered update, with two poisoned routes from

! R3 - the same two routes that R3 advertised in the previous routing update above.

! Note that the triggered update only includes changed routes, with full updates

! continuing on the same update interval.

ptg13046388

330 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

*Mar 3 22:44:46.338: RIPv2: received v2 update from 172.31.13.2 on S0/0.3

*Mar 3 22:44:46.338: 172.31.24.0/30 via 0.0.0.0 in 16 hops (inaccessible)

*Mar 3 22:44:46.338: 172.31.103.0/24 via 0.0.0.0 in 16 hops (inaccessible)

! (Step 4) Above, R1 reacts to its receipt of poisoned routes, sending a triggered

! update out its Fa0/0 interface. Note that the debug refers to the triggered

! update as a flash update.

*Mar 3 22:44:48.341: RIPv2: sending v2 flash update to 224.0.0.9 via Fa0/0

(172.31.11.1)

*Mar 3 22:44:48.341: RIPv2: build flash update entries

*Mar 3 22:44:48.341: 172.31.103.0/24 via 0.0.0.0, metric 16, tag 0

! (Step 4) R1 also sends a triggered update out S0/0.3 to R3, which includes

! a poison reverse route to 172.31.103.0/24, back to R3. R1 does not send back a

! poison route to 172.31.24.0, because R1's route to 172.31.24.0 was

! pointing towards R2, not R3 - so R1's route to 172.31.24.0/24 did not fail.

*Mar 3 22:44:48.345: RIPv2: sending v2 flash update to 224.0.0.9 via S0/0.3

(172.31.13.1)

*Mar 3 22:44:48.345: RIPv2: build flash update entries

*Mar 3 22:44:48.345: 172.31.103.0/24 via 0.0.0.0, metric 16, tag 0

! (Step 5) Below, note the absence of a route to 103.0/24 in R1's routing table.

R1# show ip route 172.31.103.0 255.255.255.0

% Subnet not in table

! (Step 6) Below, 23 seconds since the previous message, R2's next routing

! update arrives at R1, advertising 172.31.103.0/24. Following that, R1 now has

! a 2-hop route, through R2, to 172.31.103.0/24.

*Mar 3 22:45:11.271: RIPv2: received v2 update from 172.31.11.2 on Fa0/0

*Mar 3 22:45:11.271: 172.31.24.0/30 via 0.0.0.0 in 1 hops

*Mar 3 22:45:11.271: 172.31.103.0/24 via 0.0.0.0 in 2 hops

R1# show ip route 172.31.103.0 255.255.255.0

Routing entry for 172.31.103.0/24

Known via "RIPv2", distance 120, metric 2

Redistributing via RIPv2

Last update from 172.31.11.2 on FastEthernet0/0, 00:00:01 ago

Routing Descriptor Blocks:

* 172.31.11.2, from 172.31.11.2, 00:00:01 ago, via FastEthernet0/0

Route metric is 2, traffic share count is 1

ptg13046388

Chapter 7: RIPv2 and RIPng 331

If you examine the debug message time stamps in Example 7-2 , you will see that between

25 and 45 seconds passed from when R1 heard the poisoned routes until R1 heard R2’s

new routing update with a now-best route to 172.31.103.0/24. While not on par with

EIGRP or OSPF, this convergence is reasonably fast for RIPv2.

Note Do not confuse the term triggered update with the term triggered extensions to

RIPv2. RFC 2091 defines how RIPv2 can choose to send full updates only once, and then

be silent, to support demand circuits. The feature is enabled per interface by the ip rip

triggered interface subcommand.

RIPv2 Convergence When Routing Updates Cease

When a router ceases to receive routing updates, RIPv2 must wait for some timers to

expire before it decides that routes previously learned from the now-silent router can

be considered to be failed routes. To deal with such cases, RIPv2 uses its Invalid after ,

Flushed after , and Holddown timers to prevent loops. Coincidentally, RIPv2’s conver-

gence time increases to several minutes as a result.

Example 7-3 details just such a case, where R1 simply ceases to hear RIPv2 updates from

R3. (To create the failure, R3’s s0/0.1 subinterface was configured as passive, emulating a

silent passing away of the router without the interface actually going down.) The example

uses the internetwork illustrated in Figure 7-2 again, and begins with all interfaces up,

and all four routes known in each of the four routers. The example follows this sequence

(the comments in Example 7-3 refer to these steps by number):

1. R3’s s0/0.1 subinterface fails, but R1’s subinterface stays up, so R1 must use its timers

to detect route failures.

2. R 1 ’ s Invalid after and Flushed after timers for route 172.31.103.0/24 grow because

R1 does not hear any further updates from R3.

3. After the Invalid after timer expires (180 seconds) for R1’s route to 172.31.103.0/24,

R1 starts a Holddown timer for the route. Holddown starts at (default) 180 seconds

and counts down.

4. The Flushed after timer expires after a total of 240 seconds, or 60 seconds past the

Invalid after timer. As a result, R1 flushes the route to 172.31.103.0/24 from its rout-

ing table, which also removes the Holddown timer for the route.

Example 7-3 R1 Ceases to Hear R3’s Updates: Invalid After, Flushed After, Holddown

Timers

! First, the debug ip ripv2 event command is used which displays messages when

! updates are sent and received, but does not display the contents of the updates.

R1# debug ip ripv2 event

RIPv2 event debugging is on

ptg13046388

332 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! (Step 1) Not Shown: R3's S0/0.1 subinterface is made passive.

! (Step 2) Below, the age for 172.31.103.0/24 has reached 35 seconds, meaning

! that 35 seconds have passed since the last received update from which this route

! was learned. An age of a RIPv2-learned route over 30 seconds means that at least

! one RIPv2 update was not received.

R1# show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.31.0.0/16 is variably subnetted, 4 subnets, 2 masks

R 172.31.24.0/30 [120/1] via 172.31.11.2, 00:00:09, FastEthernet0/0

C 172.31.11.0/24 is directly connected, FastEthernet0/0

C 172.31.13.0/30 is directly connected, Serial0/0.3

R 172.31.103.0/24 [120/1] via 172.31.13.2, 00:00:35, Serial0/0.3

! Below, one example set of debug messages are shown. (Many more debug messages

! occurred while waiting for convergence, but those were omitted.) The messages

! about R1's received updates from R2 occur every 30 seconds or so. The contents

! include a 2-hop route to 172.31.103.0/24, which R1 ignores until the Flushed

! after timer expires.

*Mar 3 21:59:58.921: RIPv2: received v2 update from 172.31.11.2 on FastEthernet0/0

*Mar 3 21:59:58.921: RIPv2: Update contains 2 routes

! (Step 3) Below, the Invalid after timer expires, roughly 3 minutes after the

! failure. Note that the route is listed as "possibly down," which occurs when the

! Invalid after timer has expired but the Flushed after timer has not.

R1# show ip route 172.31.103.0 255.255.255.0

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

ptg13046388

Chapter 7: RIPv2 and RIPng 333

Gateway of last resort is not set

172.31.0.0/16 is variably subnetted, 4 subnets, 2 masks

R 172.31.24.0/30 [120/1] via 172.31.11.2, 00:00:20, FastEthernet0/0

C 172.31.11.0/24 is directly connected, FastEthernet0/0

C 172.31.13.0/30 is directly connected, Serial0/0.3

R 172.31.103.0/24 is possibly down,

routing via 172.31.13.2, Serial0/0.3

! (Step 3) Next, the command shows the metric as inaccessible, meaning an

! infinite metric, as well as the current age timer (3:23), which counts up.

! While not shown in this example, R1 itself advertises the route with infinite

! metric as the Invalid after timer expired and the route has been declared

! invalid. Also, the Holddown timer for this route has started (at 180 seconds),

! with 159 seconds in its countdown. The Holddown timer prevents R1 from using

! the route heard from R2.

R1# show ip route 172.31.103.0 255.255.255.0

Routing entry for 172.31.103.0/24

Known via "RIPv2", distance 120, metric 4294967295 (inaccessible)

Redistributing via RIPv2

Last update from 172.31.13.2 on Serial0/0.3, 00:03:23 ago

Hold down timer expires in 159 secs

! (Step 4) Below, just after 4 minutes has passed, the Flushed after timer has

! expired, and the route to 172.31.103.0/24 has been flushed from the routing

! table.

R1# show ip route 172.31.103.0 255.255.255.0

% Subnet not in table

At the end of the example, the only remaining step for convergence is for R1 to receive

R2’s next regular full routing update, which includes a two-hop route to 172.31.103.0/24.

R2 will send that update based on R2’s regular Update interval. R1 would place that route

in its routing table, completing convergence.

Note that either the Flushed after timer or the Holddown timer must expire before

new routing information would be used in this case. Here, the Flushed after timer for

route 172.31.103.0/24 expired first, resulting in the route being removed from R1’s rout-

ing table. When the route is flushed (removed), any associated timers are also removed,

including the Holddown timer. Had the Holddown timer been smaller, and had it expired

before the Flushed after timer, R1 would have been able to use the route advertised by

R2 at that point in time.

ptg13046388

334 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Convergence Extras

Convergence in Example 7-3 took a little over 4 minutes, but it could be improved in

some cases. The RIPv2 timers can be tuned with the timers basic update invalid hold-

down flush subcommand under router rip , although care should be taken when changing

these timers. The timers should be consistent across routers, and smaller values increase

the chance of transient routing loops being formed during convergence.

The clear ip route * command also speeds convergence by removing all routes (not just

RIP-learned) from the routing table, along with any per-route timers. In Example 7-3 , the

clear ip route 172.31.103.0 command would have worked as well, just deleting that one

route. Because the clear command bypasses loop-prevention features by deleting the

route and timers, it can be risky, but it certainly speeds convergence. Also, after the clear

ip route * command, R1 would immediately issue RIPv2 request packets, which cause the

neighboring routers to send full routing updates to R1, instead of waiting on their next

update time.

RIPv2 Configuration

This chapter does not go into detail on configuring RIPv2. However, make sure to review

the list of RIPv2 configuration commands, and command syntax, listed in Table 7-6 of

the “Foundation Summary” section for this chapter.

Figure 7-3 shows the internetwork that will be used to illustrate RIPv2 configuration

concepts in Example 7-4 . Note that most of the subnets are part of network 172.31.0.0,

except where noted.

103.3/24

E0/0

104.144/26

105.5/24

E0/0

10.1.106/24

10.1.26.6/24 10.1.26.6/24

E0/0

24.1/30

16.6/24

25.1/30

25.2/30

24.2/30

23.2/30

23.1/30

14.2/30

11.2/24

11.1/24

11.201/24

Fa0/0

Fa0/0 RIP

OSPF

13.2/30

14.1/30

16.1/24

13.1/30

Network 172.31.0.0, Except where Shown

11.202/24

211.202/24

212.202/24

213.202/24

221.202/24

222.202/24

223.202/24

FR VLAN 1

172.31.11.0/24

R3 R1 S1

R6 R2

Figure 7-3 Sample Internetwork Used for RIPv2 Configuration Examples

ptg13046388

Chapter 7: RIPv2 and RIPng 335

Enabling RIPv2 and the Effects of Autosummarization

Example 7-4 covers basic RIPv2 configuration, the meaning and implication of the RIPv2

network command, and the effects of the default setting for autosummarization. To

examine just those functions, Example 7-4 shows the related RIPv2 configuration on R1,

R2, and R6, along with some command output.

Example 7-4 Basic RIPv2 Configuration on R1, R2, R4, and S1

! First, the three lines of configuration are the same on R1 and S1

! (Point 1): the version 2 command tells R1 to send and receive only RIPv2

! updates, and to ignore RIPv1 updates. The network command always recomputes

! its argument (the network address) into a classful representation.

router rip

version 2

network 172.31.0.0

! Next, the configuration for R2 and R6 is shown, which includes a network 10.0.0.0

! command, enabling RIPv2 on their interfaces in network 10.0.0.0/8.

router rip

version 2

network 10.0.0.0

network 172.31.0.0

! Below, R1 shows that only v2 updates are being sent and received, and that

! autosummarization is in effect.

R1# show ip protocols

Routing Protocol is "RIPv2"

Sending updates every 30 seconds, next due in 26 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Redistributing: RIPv2

Default version control: send version 2, receive version 2

Interface Send Recv Triggered RIPv2 Key-chain

FastEthernet0/0 2 2 carkeys

Serial0/0.3 2 2

Serial0/0.4 2 2 anothersetofkeys

Serial0/0.6 2 2

Automatic network summarization is in effect

! Lines omitted for brevity

! Below, the show ip route 10.0.0.0 command lists all of R1's known routes to

! network 10.0.0.0; the only route is for 10.0.0.0/8, because R2 and R6

ptg13046388

336 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! automatically summarize (by default) at the classful network boundary.

R1# show ip route 10.0.0.0

Routing entry for 10.0.0.0/8

Known via "RIPv2", distance 120, metric 1

Redistributing via RIPv2

Last update from 172.31.11.2 on FastEthernet0/0, 00:00:01 ago

Routing Descriptor Blocks:

172.31.16.6, from 172.31.16.6, 00:00:08 ago, via Serial0/0.6

Route metric is 1, traffic share count is 1

* 172.31.11.2, from 172.31.11.2, 00:00:01 ago, via FastEthernet0/0

Route metric is 1, traffic share count is 1

A couple of points from this example need a little more explanation. The RIPv2 network

command only allows for a classful network as a parameter, which in turn enables RIPv2

on all of that router’s interfaces that are part of that network. Even if a subnetwork address

is entered as the network command’s parameter, the router will automatically compute the

corresponding classful network’s address and store it in the configuration. Enabling RIPv2

on an interface makes the router begin sending RIPv2 updates, listening for RIPv2 updates

(UDP port 520), and advertising that interface’s connected subnet.

Because the RIPv2 network command has no way to simply match one interface at a

time, a RIPv2 configuration might enable these three functions on an interface for which

some or all of these functions are not required. The three RIPv2 functions can be indi-

vidually disabled on an interface with some effort. Table 7-4 lists these three functions,

along with how to disable each feature.

Table 7-4 RIPv2 Per-Interface Actions, and How to Disable Them When Enabled

RIPv2 Function How to Disable

Sending RIPv2 updates Make the interface passive: configure router rip , followed by

passive-interface type number

Listening for RIPv2 updates Filter all incoming routes using a distribute list, or filter

incoming RIPv2 packets using a per-interface ACL

Advertising the connected

subnet

Filter outbound advertisements on other interfaces using

distribute lists, filtering an interface’s connected subnet

Another way that you can limit advertisements on multiaccess networks is to use the

neighbor ip-address RIP subcommand. This command tells RIP to send unicast RIP

updates to that neighbor. For example, when using a multipoint Frame Relay subinterface,

there might be four routers reachable using that subinterface. If you want to send RIP

updates to only one of them, make the interface passive, and then use the neighbor com-

mand to cause RIP to send updates, but only to that particular neighbor.

RIPv2 uses autosummarization at classful network boundaries by default. To reiterate,

automatic summarization applies whenever a router intends to advertise a subnetwork of

Key

Topic

ptg13046388

Chapter 7: RIPv2 and RIPng 337

a particular classful network X (also called major network ) out an interface that is itself

in a different classful network Y. In that case, the router will advertise only the class-

ful network X instead of the individual subnet. In Example 7-4 , R2 and R6 connect to

parts of classful networks 10.0.0.0/8 and network 172.31.0.0/16. Advertisements sent out

interfaces in network 172.31.0.0/16 advertise a summarized route of the complete class

A network 10.0.0.0/8. In the example, R2 and R6 both advertise a summarized network

10.0.0.0/8 to R1. As a result, as seen with the show ip route 10.0.0.0 command on R1,

R1 knows two equal-cost routes to classful network 10.0.0.0. In this case, R1 would send

some packets meant for subnet 10.1.106.0/24 through R2 first, a seemingly poor choice.

To advertise the subnets of network 10.0.0.0, R2 and R6 could be configured with the

no auto-summary command under router rip . Disabling the automatic summarization

should be considered a mandatory part of any RIPv2 configuration.

Note that RIPv2 allows for discontiguous networks, but autosummarization must be dis-

abled for a design using discontiguous networks to work.

RIPv2 Authentication

RIPv2 authentication, much like EIGRP and OSPF authentication, requires the creation

of keys and requires authentication to be enabled on an interface. The keys are used

either as clear-text passwords or as the secret (private) key used in an MD5 calculation.

Multiple keys are allowed, and are grouped together using a construct called a key chain .

A key chain is simply a set of related keys, each of which has a different number and

might be restricted to a time period. By allowing multiple related keys in a key chain,

with each key valid during specified time periods, the engineer can easily plan for migra-

tion to new keys in the future. (NTP is recommended when keys are restricted by time

ranges. Beware of a chicken-and-egg problem, though, when keys are not considered

usable until correct time is set on a router, and a correct time cannot be obtained from a

remote NTP server because the routing requires the use of correct keys.)

Cisco IOS enables the RIPv2 (and EIGRP) authentication process on a per-interface basis,

referring to the key chain that holds the keys with the ip rip authentication key-chain

name interface subcommand. The router looks in the key chain and selects the key(s)

valid at that particular time. If multiple keys are valid for signing outgoing RIPv2 packets,

the key with the lowest sequence number will be used. With RIPv2, the type of authen-

tication (clear-text password or MD5 digest) is chosen per interface as well, using the ip

rip authentication mode { text | md5 } interface subcommand. If this command is omitted,

the authentication type defaults to text , meaning that the key is used as a clear-text

password.

When authentication is enabled, the maximum number of prefixes that can be advertised

in a RIPv2 message is reduced by 1 to a value of 24. The first route entry in each RIPv2

message would be carrying 20 bytes of authentication data. If cryptographic authentica-

tion methods are used, further authentication data is placed after the entire RIPv2 mes-

sage. As a single RIPv2 message can carry at most 25 route entries, the first one would be

occupied by authentication data, the remaining 24 entries would carry routing informa-

tion, and the remaining authentication data would be placed after the 25th entry.

Key

Topic

ptg13046388

338 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

RIPv2 Next-Hop Feature and Split Horizon

This section covers the split horizon and next-hop features of RIPv2. These two features

do not typically need to be considered at the same time, but in some cases they do.

First, Cisco IOS controls the split horizon setting per interface, using the [ no ] ip split-

horizon interface subcommand. Split Horizon is on by default, except for cases in which

Frame Relay or ATM is configured with the IP address on the physical interface.

The RIPv2 next-hop feature allows a RIPv2 router to advertise a different next-hop router

than the advertising router. Although this is not a common requirement, this little-known

feature permits a RIPv2 router to point to a different next hop on the same segment

than itself, potentially eliminating an extra hop. The original motivation for the next-hop

feature is described in RFC 2453 Appendix A . On Cisco routers, this feature is not con-

figurable, though, and is almost unused. In fact, the only instance in which the next-hop

field was seen to be set to a nonzero address is when RIPv2 is run over Non Broadcast

Multiple Access (NBMA) interfaces, facilitating direct spoke-to-spoke routing (and pos-

sibly causing issues if direct spoke-to-spoke communication is not available).

RIPv2 Offset Lists

RIPv2 offset lists allow RIPv2 to add to a route’s metric, either before sending an update,

or for routes received in an update. The offset list refers to an ACL (standard, extended,

or named) to match the routes; the router then adds the specified offset, or extra metric,

to any matching routes. Any routes not matched by the offset list are unchanged. The

offset list also specifies which routing updates to examine by referring to a direction ( in

or out ) and, optionally, an interface. If the interface is omitted from the command, all

updates for the defined direction are examined.

Route Filtering with Distribute Lists and Prefix Lists

Outbound and inbound RIPv2 updates can be filtered at any interface, or for the entire

RIPv2 process. To filter the routes, the distribute-list command is used under router rip ,

referencing an IP ACL or an IP prefix list. Any subnets matched with a permit clause in

the ACL make it through; any that match with a deny action are filtered. The distribution

list filtering can be performed for either direction of flow ( in or out ) and, optionally, for

a particular interface. If the interface option is omitted, all updates coming into or out of

the RIPv2 process are filtered. (Routes can also be filtered at redistribution points, a topic

covered in Chapter 11 .)

The generic command, when creating a RIPv2 distribution list that uses an ACL, is

distribute-list { access-list-number | name } { in | out }

[ interface-type interface-number ]

A RIPv2 distribute list might refer to a prefix list instead of an ACL to match routes.

Prefix lists are designed to match a range of subnets, as well as a range of subnet masks

associated with the subnets. The distribute list must still define the direction of the

updates to be examined ( in or out ), and optionally an interface.

Key

Topic

Key

Topic

ptg13046388

Chapter 7: RIPv2 and RIPng 339

Chapter 11 includes a more complete discussion of the syntax and formatting of prefix

lists; this chapter focuses on how to call and use a prefix list for RIPv2. Use of prefix lists

is generally recommended. To reference a prefix list, use the following router rip subcom-

mand:

distribute-list prefix prefix-list-name { in | out } [ interface-type

interface-number ]

RIPng for IPv6

While RIP is in many aspects an inferior protocol to EIGRP, OSPF, or IS-IS, its simplicity

nonetheless makes it suitable for small office/home office (SOHO) routers and simple net-

works. Its wide adoption and support over a wide range of routers from multiple vendors

prompted the creation of the IPv6 version of RIP named RIP next generation (RIPng) .

Although the name RIPng suggests major reworking, RIPng is in fact just a straightfor-

ward adaptation of RIPv2 for IPv6 operation with practically no changes to underly-

ing protocol mechanisms. RIPng remains a plain distance-vector protocol utilizing User

Datagram Protocol (UDP) as its transport protocol, using port 521 instead of 520 to

avoid clashes with existing RIPv1/RIPv2 implementations. The destination IPv6 address

for multicasted RIPng messages is FF02::9. Metric is again based on hop count, with 15

being the maximum usable metric and 16 representing infinity. RIPng differs, though, in

its metric handling: The metric is incremented by the receiver of a RIPng advertisement,

not by the advertisement sender anymore. All loop avoidance techniques described in

previous sections are used by RIPng in precisely the same way.

Figure 7-4 shows the RIPng message format—similar to RIPv2 messages.

RIPng Message

Octet 1 Octet 2 Octet 3 Octet 4

Command Version Must Be Zero

Route Tag Prefix Len

IPv6 Prefix

Metric

Route Entry, as Many Entries

as Permitted by Link MTU

Message Header

Figure 7-4 RIPng Message Format

Similar to RIPv2, the RIPng message starts with a header containing a Command field (value

1 for Request, 2 for Response) and a Version field (currently set to 1). After the header, a

variable number of route entries follows. The number of route entries in a RIPng message is

limited only by the IPv6 MTU on the link, and the protocol itself poses no limitations on

their count. Route entry fields are self-explanatory. Two facts are worth mentioning:

■ As RIPng does not assume any multiprotocol capability, the address family ID field

has been omitted.

Key

Topic

ptg13046388

340 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ Because the next-hop field was relatively unused in RIPv2, keeping a per-prefix next-

hop field in a route entry would uselessly occupy quite a significant space (128 bits).

Therefore, the next hop field—if necessary—is specified by a separate route entry

containing the IPv6 next-hop address (a link-local address) in the IPv6 prefix field,

the metric value set to 255, and route tag and prefix length fields set to 0. All subse-

quent route entries are to be processed with this particular next hop until another

next-hop route entry is encountered in the RIPng message. A route entry with the

IPv6 next-hop address set to :: (all-zero) will revert to the sender of the message

being the next hop.

Authentication is not handled by RIPng anymore; rather, similar to OSPFv3, these func-

tions are offloaded to IPsec. RIPng implementation in current Cisco IOS is relatively

simple and lacks several features supported by RIPv2:

■ Authentication or encryption by IPsec is not supported.

■ Split Horizon can be activated or deactivated only on a per-process basis, not on

individual interfaces.

■ Passive interfaces are not supported.

■ Static (manual) neighbors cannot be configured (no neighbor command).

■ Per-process offset lists are not supported.

Still, there are management improvements over RIPv2 implemented in the Cisco RIPng:

■ Multiple RIPng processes can be run on a router; however, at the time of writing, at

most four simultaneously running RIPng processes were supported on IOS-based

routers. Individual processes are distinguished by an alphanumeric name that is local

to the router and does not need to match between different routers.

■ Route Poisoning, as an enhancement of the Split Horizon mechanism, can be acti-

vated on a per-process basis.

■ Interfaces can be configured with a metric-offset value that is added to the metric in

all received advertisements over that interface, effectively allowing RIPng to operate

with link costs rather than hop counts.

■ The default route can be originated on a per-interface basis, including an option of

suppressing all other updates over that interface.

Example 7-5 shows a simple configuration of RIPng on a router with two interfaces.

Example 7-5 Basic RIPng Configuration on a Router

! First, IPv6 unicast routing support must be activated, and IPv6 CEF is activated

! as well

ipv6 unicast-routing

ipv6 cef

ptg13046388

Chapter 7: RIPv2 and RIPng 341

! Fa0/0 interface is connected to a stub router. Only default route needs to be

! sent.

R1(config)# interface FastEthernet0/0

R1(config-if)# ipv6 address 2001:DB8:1::1/64

R1(config-if)# ipv6 rip 1 enable

R1(config-if)# ipv6 rip 1 default-information only

! S0/0/0 interface simply connects to another router. However, the metric of this

! interface is increased to 3 from 1

R1(config)# interface Serial0/0/0

R1(config-if)# ipv6 address 2001:DB8:2::1/64

R1(config-if)# ipv6 rip 1 enable

R1(config-if)# ipv6 rip 1 metric-offset 3

! In global IPv6 RIPng process 1, Poison Reverse is activated and settings are

! verified afterwards using show ipv6 rip command

R1(config)# ipv6 router rip 1

R1(config-rtr)# poison-reverse

R1(config-rtr)# do show ipv6 rip

RIP process "1", port 521, multicast-group FF02::9, pid 246

Administrative distance is 120. Maximum paths is 16

Updates every 30 seconds, expire after 180

Holddown lasts 0 seconds, garbage collect after 120

Split horizon is on; poison reverse is on

Default routes are generated

Periodic updates 18, trigger updates 2

Full Advertisement 2, Delayed Events 0

Interfaces:

Serial0/0/0

FastEthernet0/0

Redistribution:

None

ptg13046388

342 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter, as well as review items noted with a Key Topic icon.

Table 7-5 lists the protocols mentioned in this chapter and their respective standards

documents.

Table 7-5 Protocols and Standards for Chapter 7

Protocol or Feature Standard

RIPv2 (RIP version 2) RFC 2453

RIPv2 Cryptographic Authentication RFC 4822

RIPv2 Triggered Extensions for On-Demand Circuits RFC 2091

RIPng for IPv6 RFC 2080

Table 7-6 lists some of the most significant Cisco IOS commands related to the topics in

this chapter.

Table 7-6 Command Reference for Chapter 7

Command Command Mode and Description

router rip Global config; puts user in RIP configuration

mode.

network ip-address RIP config mode; defines classful network, with

all interfaces in that network sending and able to

receive RIP advertisements.

[ no ] auto-summary RIP config mode; activates or deactivates

automatic network summarization on classful

boundaries whenever a prefix from one major

network is advertised out an interface in a

different major network.

distribute-list [ access-list-number

| name | prefix name ] | { in | out }

[ interface-type interface-number ]

RIP config mode; defines ACL or prefix list to

filter RIP updates.

[ no ] ip split-horizon Interface mode; enables or disables split horizon.

ip summary-address rip address

netmask

Interface mode; defines manual network

summarization.

ptg13046388

Chapter 7: RIPv2 and RIPng 343

Command Command Mode and Description

passive-interface [ default ] { interface-

type interface-number }

RIP config mode; causes RIP to stop sending

updates on the specified interface.

timers basic update invalid holddown

flush

RIP config mode; sets the values for RIP timers.

version { 1 | 2 } RIP config mode; sets the RIP version to version 1

or version 2.

offset-list { access-list-number | access-

list-name } { in | out } offset [ interface -

type interface-number ]

RIP config mode; defines rules for RIP to add to

the metrics of particular routes.

neighbor ip-address RIP config mode; identifies a neighbor to which

unicast RIP updates will be sent.

show ip route rip User mode; displays all routes in the IP routing

table learned by RIP.

show ip rip database User mode; lists all routes learned by RIP even if a

route is not in the routing table because of a route

with lower administrative distance.

debug ip rip Enable mode; displays details of RIP processing

show ip protocols User mode; lists RIP timer settings, current

protocol status, autosummarization actions, and

update sources.

clear ip route { network [ mask ] | * } Enable mode; clears the routing table entry, and

with RIP, sends RIP requests, quickly rebuilding

the routing table.

show ip interface [ type number ] [ brief ] User mode; lists many interface settings, including

split horizon.

key chain name-of-chain

Global config; defines name of key chain for

routing protocol authentication.

key key-id Key config mode; identifies a key by number.

key-string string Key config mode; defines the text of the key.

send-lifetime [ start-time { infinite | end-

time | duration seconds }]

Key config mode; defines when the key is valid to

be used for sent updates.

accept-lifetime [ start-time { infinite |

end-time | duration seconds }]

Key config mode; defines when the key is valid

for received updates.

ip rip authentication key-chain name-

of-chain

Interface mode; enables RIPv2 authentication on

the interface.

ip rip authentication mode { text | md5 } Interface mode; defines RIPv2 authentication as

clear text (default) or MD5.

ptg13046388

344 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Command Mode and Description

ipv6 router rip word Global config; puts user in RIPng configuration

mode. The word is the name of the RIPng

instance.

distribute-list prefix name { in | out }

[ interface-type interface-number ]

RIPng config mode; defines an IPv6 prefix list to

filter RIPng updates.

split-horizon RIPng config mode; activates simple Split

Horizon.

poison-reverse RIPng config mode; activates Split Horizon with

Poisoned Reverse. If both split-horizon and

poison-reverse are configured, poison-reverse

takes precedence.

port port multicast-group group RIPng config mode; defines the UDP port and

multicast address to send and listen for RIPng

packets. Used if multiple processes are to

communicate over a single interface, as multiple

processes cannot listen on the same UDP port.

timers update timeout holddown

garbage-collection

RIPng config mode; defines the RIPng timers.

Update is the time between RIPng update

messages, Timeout is equivalent to the Invalid

after timer, Holddown is the hold down timer,

and the Garbage Collection timer is similar to

Flushed after with a notable difference: The

Garbage Collection timer starts only after the

Timeout timer expired. The default values of

these timers are 30, 180, 0, 120, respectively.

ipv6 rip word enable Interface mode; activates a RIPng instance

identified by the word on the interface. All

unicast prefixes of this interface except the link-

local address will be advertised by RIPng.

ipv6 rip word default-information {

only | originate } [ metric metric ]

Interface mode; advertises the default route out

the interface. If the only keyword is used, all

other prefixes are suppressed.

ipv6 rip word metric-offset offset Interface mode; defines the offset by which the

metric in received RIPng updates is incremented.

By default, the offset value is 1.

ipv6 rip word summary-address ipv6-

prefix/prefix-length

Interface mode; defines manual prefix

summarization.

ptg13046388

Chapter 7: RIPv2 and RIPng 345

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD to check your answers.

Definitions

Next, take a few moments to write down the definitions for the following terms:

Holddown timer, Invalid after timer, Flushed after timer, authentication, Update

timer, triggered updates, flash updates, split horizon, route poisoning, poison

reverse, counting to infinity, hello interval, full update, partial update, Route Tag

field, Next Hop field, Triggered Extensions to RIPv2 for On-Demand Circuits, MD5,

offset list, prefix list, distribution list, distance vector, metric

Refer to the glossary to check your answers.

Further Reading

This chapter focuses on TCP/IP protocols; much more information can be found in the

RFCs mentioned throughout the chapter.

The RIP RFCs listed in Table 7-5 provide good references for RIPv2 concepts.

Jeff Doyle’s Routing TCP/IP, Volume I , Second Edition (Cisco Press), has several excel-

lent configuration examples and provides a complete explanation of RIPv2 concepts.

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ Describe Packet Types

■ Implement and Troubleshoot Neighbor Relationship

■ Implement and Troubleshoot Loop-Free Path

Selection

■ Implement and Troubleshoot Operations

■ Implement and Troubleshoot EIGRP Stub

■ Implement and Troubleshoot Load Balancing

■ Implement EIGRP Named Mode

■ Implement, Troubleshoot, and Optimize EIGRP

Convergence and Scalability

ptg13046388

This chapter covers most of the features, concepts, and commands related to Enhanced

Interior Gateway Routing Protocol (EIGRP). Chapter 11 , “IGP Route Redistribution,

Route Summarization, Default Routing, and Troubleshooting,” covers a few other details

of EIGRP—in particular, route redistribution, route filtering when redistributing, and

route summarization.

“Do I Know This Already?” Quiz

Table 8-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 8-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in This Section Score

EIGRP Metrics, Packets, and Adjacencies 1–11

Diffusing Update Algorithm 12–25

EIGRP Named Mode 26

Additional and Advanced EIGRP Features 27–31

Total Score

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. Which of the following items are true of EIGRP?

a. Authentication can be done using MD5 or clear text.

b. Uses UDP port 88.

c. Sends full or partial updates as needed.

d. Multicasts updates to 224.0.0.10 or FF02::A.

CHAPTER 8

EIGRP

ptg13046388

348 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

2. What classic metric components can be used by EIGRP for metric computation and

best path selection?

a. Bandwidth

b. Cost

c. Delay

d. Hop count

e. Load

f. Expense

g. MTU

h. Reliability

3. Which of the following accurately describe the manipulation with the component

metrics?

a. Reliability is maximized.

b. Delay is summed.

c. Load is minimized.

d. Reliability is minimized.

e. Bandwidth is summed.

f. Load is maximized.

g. Bandwidth is minimized.

4. Which statement is true regarding EIGRP’s use of Reliability and Load metric com-

ponents on regular interfaces such as Ethernet or PPP?

a. EIGRP sends updates and recalculates the composite metric immediately

whenever the Reliability and Load values on an interface change, regardless of

K-value settings.

b. EIGRP sends updates and recalculates the composite metric immediately

whenever the Reliability and Load values on an interface change but only when

K-values are configured to take these components into account.

c. EIGRP samples the Reliability and Load in regular intervals and sends updates

along with recalculating the composite metric when the sampled Reliability and

Load values change.

d. EIGRP takes a snapshot of the interface Reliability and Load values in the

moment of advertising a network, but changes to their values do not trigger

sending further updates.

ptg13046388

Chapter 8: EIGRP 349

5. What are the shortcomings solved by Wide Metrics?

a. Gradual loss of resolution caused by repetitive descaling and scaling of

Bandwidth and Delay components in integer arithmetics

b. Inability to use Reliability and Load without incurring routing table instabilities

c. Loss of resolution for interfaces with speeds over 1 Gbps

d. Inability to extend the metrics with additional future factors

6. What are the component metrics used in Wide Metrics that can be used for best

path selection?

a. Throughput

b. Latency

c. Reliability

d. Load

e. MTU

f. Hop Count

g. E x t e n d e d M e t r i c s

7. Which of the following EIGRP packets are considered reliable packets?

a. H e l l o

b. Ack

c. Update

d. Query

e. Reply

f. SIA-Query

g. SIA-Reply

8. Which of the following EIGRP packets can be sent as multicasts?

a. H e l l o

b. Ack

c. Update

d. Query

e. Reply

f. SIA-Query

g. SIA-Reply

ptg13046388

350 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

9. Which statements are true about Hello packets?

a. Hello packets must be confirmed.

b. Hello packets sent by a router contain a list of all detected neighbors on the

interface.

c. Hello packets are usually sent as multicasts.

d. Default interval between Hello packets is 5 seconds on all interfaces.

e. Hello packets do not contain routing information.

10. Which EIGRP packet types are acknowledged?

a. H e l l o

b. Ack

c. Update

d. Query

e. Reply

f. SIA-Query

g. SIA-Reply

11. Which EIGRP packet types can themselves act as acknowledgments?

a. H e l l o

b. Ack

c. Update

d. Query

e. Reply

f. SIA-Query

g. SIA-Reply

12. What is the Computed Distance for a destination?

a. The current total distance to the destination computed over a particular neigh-

bor router

b. The lowest known distance to the destination since the last time the destination

transitioned from Active to Passive state

c. The current distance of a particular neighbor to the destination

d. The lowest known distance of a particular neighbor to the destination since the

last time the destination transitioned from Active to Passive state

ptg13046388

Chapter 8: EIGRP 351

13. How many Computed Distances for a destination exist?

a. Only one, not bound to any particular neighbor

b. One per each neighbor that advertises the destination

c. One per each Successor

d. One per each Feasible Successor

14. What is the Reported Distance for a destination?

a. The current total distance to the destination computed over a particular neigh-

bor router

b. The lowest known distance to the destination since the last time the destination

transitioned from Active to Passive state

c. The current distance of a particular neighbor to the destination

d. The lowest known distance of a particular neighbor to the destination since the

last time the destination transitioned from Active to Passive state

15. How many Reported Distances for a destination exist?

a. Only one, not bound to any particular neighbor

b. One per each neighbor that advertises the destination

c. One per each Successor

d. One per each Feasible Successor

16. What is the Feasible Distance for a destination?

a. The current total distance to the destination computed over a particular neigh-

bor router

b. The lowest known distance to the destination since the last time the destination

transitioned from Active to Passive state

c. The current distance of a particular neighbor to the destination

d. The lowest known distance of a particular neighbor to the destination since the

last time the destination transitioned from Active to Passive state

17. How many Feasible Distances for a destination exist?

a. Only one, not bound to any particular neighbor

b. One per each neighbor that advertises the destination

c. One per each Successor

d. One per each Feasible Successor

ptg13046388

352 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

18. Which statement correctly constitutes the Feasibility Condition in EIGRP?

a. The neighbor must be closer to the destination than I have ever been since the

last time the destination became Passive .

b. The neighbor must be closer to the destination than I am .

c. The neighbor must be farther from the destination than I am .

d. The neighbor must be farther from the destination than I have ever been .

19. What statements correctly apply to a Successor?

a. It is a route over a particular neighbor.

b. It is a particular neighbor.

c. It must provide a loop-free path.

d. The Computed Distance over the Successor must be the lowest available.

e. The Computed Distance over the Successor does not need to be the lowest

available.

f. In a connected network, there is always at least one Successor to a destination.

20. What statements correctly apply to a Feasible Successor?

a. It is a route over a particular neighbor.

b. It is a particular neighbor.

c. It must provide a loop-free path.

d. The Computed Distance over the Feasible Successor must be the lowest

available.

e. The Computed Distance over the Feasible Successor does not need to be the

lowest available.

f. There is always at least one Feasible Successor to a destination.

21. What is a local computation?

a. The process of local processing of all received Updates and Replies

b. The process of reevaluating and possibly changing a next hop to a destination

locally that does not require the router to send Queries and wait for Replies

before making its own decision

c. The process of computing the composite metric from individual components

d. The process of coordinating a change in the next hop to a destination by send-

ing out Queries and waiting for Replies before making its own next-hop

s e l e c t i o n

ptg13046388

Chapter 8: EIGRP 353

22. What is a diffusing computation?

a. The process of local processing of all received Updates and Replies

b. The process of reevaluating and possibly changing a next hop to a destination

locally that does not require the router to send Queries and wait for Replies

before making its own decision

c. The process of computing the composite metric from individual components

d. The process of coordinating a change in the next hop to a destination by send-

ing out Queries and waiting for Replies before making its own next-hop

s e l e c t i o n

23. Is the following statement true? “If a router has a Feasible Successor for a destina-

tion identified in its topology table, it will always be used in place of the current

Successor if the Successor fails.”

a. Ye s

b. N o

24. How long at most will a diffusing computation run by default on a router before

being terminated forcibly?

a. Indefinitely

b. 3 minutes

c. 3 minutes if the SIA-Query and SIA-Reply messages are not supported; 6 min-

utes if the SIA-Query and SIA-Reply are supported

d. 15 seconds

25. What are some of the factors contributing to the occurrence of SIA states?

a. The use of route filtering and summarization

b. Excessive redundancy in the network

c. The use of the EIGRP Stub feature

d. Excessive network diameter

e. Large amount of routing information

f. The use of the EIGRP Add-Path feature

ptg13046388

354 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

26. What statements are true about running EIGRP Named Mode?

a. Verbal names of EIGRP processes on neighboring routers must match for the

routers to establish adjacencies.

b. Multiple autonomous system instances for a single address family can be run in

a single EIGRP named process.

c. Multiple autonomous system instances for different address families can be run

in a single EIGRP named process.

d. Both classic and named mode can be used on a router as long as they do not

conflict on the address family and the autonomous system number.

e. The use of named mode still permits that per-interface commands can be

applied to interfaces to maintain backward compatibility.

f. The named mode contains a superset of all commands from the classic mode.

27. What statements are true about EIGRP RID?

a. EIGRP has no concept of a RID.

b. The RID is equal to the autonomous system number.

c. The RID is advertised with all external and, in recent IOS releases, also with all

internal routes.

d. The RID indicates the immediate neighbor advertising a route.

e. The RID indicates the originator of the routing information.

28. What statements are true about unequal cost load balancing in EIGRP?

a. Feasible Successors are required for this feature.

b. Multiple unequal cost paths can be advertised by a router to its neighbors.

c. Each unequal-cost path will be assigned a share of traffic in inverse proportion

to how many times worse it is than the current best path.

d. EIGRP allows using any worse-cost path as long as the neighbor advertising this

path is closer to the destination than this router.

29. What statements are true about the EIGRP Stub Router feature?

a. No Queries are sent by a stub router.

b. No Queries are usually sent to a stub router.

c. All Queries sent to a stub router are responded to by Replies indicating unreach-

ability.

d. Depending on what routes the stub router is allowed to advertise, some Queries

can be responded to normally while others will elicit a Reply indicating unreach-

ability.

e. Neighbors of a stub router must be configured to treat that router as a stub.

f. A router is capable of advertising itself as a stub.

ptg13046388

Chapter 8: EIGRP 355

30. What statements are true about EIGRP authentication?

a. In recent IOS versions, SHA-2 with 256-bit digests is supported.

b. MD5 digest is always supported.

c. Key chains or passwords can be used for SHA-2 authentication.

d. Key chains or passwords can be used for MD5 authentication.

e. IPv6 EIGRP uses IPsec for authentication purposes.

31. What of the following are true regarding the default route injection into EIGRP?

a. The network 0.0.0.0 command is the preferred way of injecting the default route

into EIGRP.

b. A default route can be injected into EIGRP by redistribution.

c. A default route can be injected into EIGRP by summarization.

d. Neighbors of stub routers send a default route to stub routers automatically.

ptg13046388

356 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Foundation Topics

EIGRP Basics and Evolution

Many CCIE candidates have already learned the majority of the details of EIGRP opera-

tion and configuration. Because of its former proprietary nature, however, there are many

misconceptions and misunderstandings about various fundamental details of EIGRP

operation. With that in mind, this chapter strives to review the key terms and concepts in

depth, and then get to specific examples that detail EIGRP operation on a Cisco router.

It is noteworthy to mention that in 2013, Cisco decided to open up the EIGRP specifica-

tion and publish it as an IETF Internet Draft, a precursor to an RFC; the document name

is draft-savage-eigrp . Basic EIGRP is thus no longer a closed, proprietary protocol. An

open source EIGRP implementation based on the Quagga routing platform already exists

and is being actively developed.

Table 8-2 lists the selected key features related to EIGRP.

Table 8-2 EIGRP Feature Summary

Feature Description

Transport IP, protocol type 88 (does not use UDP or TCP). Implements

its own Reliable Transport Protocol, providing reliable

unicast and multicast packet delivery.

Metric Based on constrained bandwidth and cumulative delay by

default, and optionally load reliability, and extended metrics.

Hello interval Interval at which a router sends EIGRP Hello messages on an

interface.

Hold timer Timer used to determine when a neighboring router has

failed, based on a router not receiving any EIGRP messages,

including Hellos, in this timer period.

Update destination address Normally sent to 224.0.0.10 or FF02::A, with retransmissions

being sent to each neighbor’s unicast IP address.

Full or partial updates Full updates are used when new neighbors are discovered;

otherwise, partial updates are used.

Authentication Supports MD5 and SHA-based authentication.

VLSM/classless EIGRP includes the mask with each route, also allowing it to

support discontiguous networks and VLSM.

Route Tags Enables EIGRP to tag and filter internal and external routes

using distribute-lists and route-maps.

Next-hop field Supports the advertisement of routes with a different next-

hop router than the advertising router.

ptg13046388

Chapter 8: EIGRP 357

Feature Description

Manual route summarization Allows route summarization at any point in the EIGRP

network.

Multiprotocol Supports the advertisement of IPv4 and IPv6. Former

implementations also supported IPX and AppleTalk routes.

EIGRP Roots: Interior Gateway Routing Protocol

To understand EIGRP roots better, we start our discussion with a brief look into the past,

focusing on a dead protocol that was an immediate predecessor to EIGRP.

In the mid-1980s, Cisco developed the Interior Gateway Routing Protocol (IGRP), an

alternative protocol to Routing Information Protocol version 1 (RIPv1). The most signifi-

cant goal was to eliminate RIP’s working but naïve hop count metric and the hop network

diameter limitation of 15 hops. IGRP relied on a composite metric made up of a variety

of route variables and even went so far as to provide a way for the weighting of specific

variables over others so that the protocol could reflect the specific characteristics and

needs of a diverse array of networks.

Benefits that IGRP offered over RIP included

■ Wider network diameter, up to 255 hops

■ Complex multivariate metric

■ Unequal-cost load sharing

■ An update period of 90 seconds, three times longer than RIP’s

■ A more efficient update packet format

IGRP was designed to interoperate with multiple routed protocols including IPv4, ISO

Connectionless Network Protocol (CLNP), Novell IPX, or AppleTalk. Like RIP, IGRP

broadcasted a Request packet out all IGRP-enabled interfaces at startup and performed a

sanity check on received Update packets to verify that the source address of the packet

belonged to the same subnet on which the Update was received. Update packets them-

selves were sent periodically each 90 seconds.

IGRP was also like RIPv1 in that it was a classful distance-vector protocol that periodically

broadcasted its entire gathered knowledge. The protocol also relied on Split Horizon, trig-

gered updates, Invalid after, and Holddown and Flushed after timers for functional stability;

IGRP summarized advertised addresses at network boundaries.

Overall, IGRP was better than RIP for larger networks but it still had many of the funda-

mental limitations found in RIP that had an adverse impact on its scalability and speed of

convergence.

ptg13046388

358 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Moving from IGRP to Enhanced IGRP

Most significant IGRP weaknesses and detractors include

■ Sending full routing updates periodically

■ The lack of variable-length subnet mask (VLSM) support

■ Slow convergence

■ The lack of adequate loop-prevention mechanisms

Making changes to the metric calculation did not remove the fundamental shortcomings

of the basic distance-vector routing protocol paradigm; a new approach was necessary.

To address these specific issues, Cisco created an “Enhanced” version of IGRP. Enhanced

Interior Gateway Routing Protocol (EIGRP) is a protocol that is significantly more capa-

ble than its predecessor, containing numerous improvements over IGRP. In fact, EIGRP

is so much different that simply calling it an “Enhanced IGRP” is somewhat of an under-

statement. There is in fact very little left of the original IGRP in EIGRP—even though

EIGRP still is a distance-vector routing protocol, albeit an advanced one.

IGRP was based on timers, and similarly to RIP, it advertised its entire database of known

networks on each Update interval expiry. In both RIP and IGRP, the periodic origination

of Update packets served multiple purposes: detecting neighbors, verifying their continu-

ous presence, learning new routes, and refreshing or withdrawing existing learned routes.

In fact, these periodic Updates provide two separate and unrelated functions—first,

detecting neighbors and their liveliness, and second, carrying routing information. To

allow EIGRP to become an incremental, event-based protocol, it was first necessary to

decouple building and maintaining adjacencies from exchanging routing information. The

first task is accomplished in EIGRP by using a Hello protocol . Thanks to the Hello proto-

col, it is no longer necessary to periodically send Update packets to announce a router’s

continuous presence on a network; instead, the Hello protocol takes over this responsibil-

ity. EIGRP routers use the Hello protocol to build and maintain neighbor adjacencies in

a way that’s similar to Open Shortest Path First (OSPF) and other protocols. The Hello

protocol keeps the periodic nature of former Update packets without carrying the rout-

ing information.

To advertise routing information whenever there is a change, without requiring routers

to advertise it periodically, EIGRP implements the Reliable Transport Protocol (RTP;

do not confuse it with the Real-time Transport Protocol, which is a different and unre-

lated protocol used in media-streaming applications), a Layer 3–independent transport

protocol capable of reliable unicast and multicast delivery. The use of RTP allows routers

to initially exchange the complete routing information when synchronizing for the first

time, and afterward, advertise changed routes only. RTP makes sure that all updates—if

any—are delivered reliably. The lack of updates therefore does not indicate a connectivity

issue but rather simply a stable network state in which the routing information does not

change. The use of Hellos to establish and maintain router adjacencies and RTP to carry

all updates reliably allows EIGRP to completely abandon the periodic updating process

and operate in an event-driven, incremental fashion.

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 359

IGRP as a distance-vector routing protocol was prone to the creation of temporary rout-

ing loops during network convergence. To maintain a loop-free operation at every instant,

EIGRP uses a so-called Feasibility Condition criterion to identify neighbors, providing

guaranteed loop-free paths to a given destination. This criterion allows an EIGRP router

to avoid forwarding packets to a neighbor that could, even possibly, form a routing loop.

Considering the fact that EIGRP is still a distance-vector protocol and carries the same

detail of information about the network as IGRP in its messages, the importance of the

Feasibility Condition is paramount.

Another important addition working in tandem with the Feasibility Condition is the

use of the so-called diffusing computations . Under circumstances, a router detecting a

topology change can be adversely affected by this change, meaning that the Feasibility

Condition can cause its neighbor providing the current least-cost path to be considered

ineligible. In this case, an EIGRP router can actively query all its neighbors to update

their own best-path selection with respect to the topology change that triggered this

event, and reply with their updated distances. Neighbors that are not adversely affected

will simply respond right away with a (possibly updated) distance; neighbors that are

adversely affected will propagate the query further and can respond only after receiving

all replies and making a choice themselves. In a sense, the task of searching for a replace-

ment path to a destination diffuses into the affected part of the network, hence the name

diffusing computations . This way, EIGRP actively involves the affected part of the net-

work into updating the best-path selection in a highly coordinated manner. The use of

diffusing computations is at the core of EIGRP’s rapid convergence.

To handle multiple topology changes during a single diffusing computation, EIGRP

implements a finite state machine called Diffusing Update Algorithm (DUAL) that con-

trols the run of a diffusing computation, processing the replies and eventually inserting

the gathered information into the routing table or commencing an additional diffusing

computation. The DUAL is not the diffusing computation algorithm itself; it is a control

mechanism on top of diffusing computations that decides when it is necessary to start a

diffusing computation and how the results should be processed.

EIGRP was designed as a successive version of IGRP to allow for an easy migration path.

While the mechanisms used in IGRP and EIGRP strongly differ, many of the ideas that

worked very well for IGRP were applied to EIGRP. As an example, EIGRP has a default

hop-count limitation of 100; however, this value can be manually adjusted using the com-

mand illustrated in Example 8-1 .

Example 8-1 Adjusting Hop-Count Limitation

Router(config-router)# metric maximum-hops ?

<1-255> Hop count

Another area of similarity is the choice of metric components. EIGRP basically reuses the

metric computation first used by IGRP, including the component metrics of bandwidth,

delay, and optionally reliability and load. This similarity will be discussed in further detail

in the upcoming sections.

Key

Topic

Key

Topic

Key

Topic

ptg13046388

360 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

EIGRP makes a distinction between internal and external routes. Internal routes are those

injected into EIGRP by the network command. External routes are redistributed into

EIGRP from a different routing source. EIGRP internal and external routes can be distin-

guished within the routing table by their default administrative distance (AD). Internal

prefixes will have an AD of 90, and external will be 170 by default. Example 8-2 demon-

strates how these default values can be changed under the routing protocol.

Example 8-2 Adjusting Administrative Distance Based on Route Type

Router(config-router)# distance eigrp ?

<1-255> Distance for internal routes

Router(config-router)# distance eigrp 90 ?

<1-255> Distance for external routes

Router(config-router)# distance eigrp 90 100

After this fleeting overview of what enhancements EIGRP has over other distance-vector

routing protocols, it is time to take an even closer look at the protocol’s operation and

features.

EIGRP Metrics, Packets, and Adjacencies

Many people are tempted to overlook or browse past this type of content. Reading

through a topic that appears to be all too familiar can be tiring at first, but we nonethe-

less encourage you to read the following sections very carefully. There are lots of hidden

details about EIGRP that we have strived to uncover. Also, it will make concepts like fil-

tration, summarization, and stub routing (to name a few) easier for you to understand.

EIGRP Classic Metrics

EIGRP uses several types of metrics, also called component metrics or metric compo-

nents , to describe selected technical properties of a route. These component metrics are

bandwidth, delay, reliability, load, MTU, and hop count. Out of these six components,

the first four are combined together using a well-known formula to produce a single num-

ber that we will call the composite metric or, where there is no risk of confusion, sim-

ply as metric, distance , or cost . This single composite metric is then used by EIGRP to

choose the best path toward a destination. Originally, the idea of combining several tech-

nical measures of a route into a single number came in IGRP that strived to be “smarter”

than RIP and cover more properties of a route in a single metric value. When EIGRP was

developed, to serve as a drop-in replacement for IGRP, it retook its system of metric cal-

culation.

The component metrics as described in this section are also called Classic Metrics and

are the standard set of metrics supported by all current EIGRP implementations. EIGRP

shipped with recent IOS versions also supports so-called Wide Metrics, which expand

the allowable range of existing Classic Metrics. These Wide Metrics will be described in

the next section.

ptg13046388

Chapter 8: EIGRP 361

Let us now have a closer look at the individual Classic Metric components and how

EIGRP uses them.

Bandwidth Metric Component

The bandwidth is a static metric assigned to each router interface using the bandwidth

interface level command. The meaning of this metric component is obvious: It describes

the transmission speed of an interface. The bandwidth command expresses the interface

bandwidth in terms of kilobits per second. If no bandwidth command is configured

explicitly, IOS assigns an implicit bandwidth value to each interface, depending on its

hardware type and operational characteristics. With selected interface types, as with

Ethernet interfaces, the implicit bandwidth value reflects the true speed negotiated by

the interface with its link partner. On other interface types, the value has no realistic rela-

tion to the interface capabilities (common with Serial or Tunnel interfaces, for example).

When calculating the composite metric to a destination, EIGRP takes the minimal band-

width along the route into account. This is done by comparing the bandwidth as adver-

tised by a neighboring router to the bandwidth of the interface toward the advertising

neighbor, and taking the lower value of these two.

With Classic Metrics, EIGRP is capable of describing the bandwidth in the range of 1

kbps up to 10 Gbps.

Delay Metric Component

The delay is a static metric assigned to each interface using the delay interface command.

This metric component estimates the serialization delay incurred by the interface. Of

course, in real life, the serialization delay would depend both on the interface transmis-

sion speed as well as the serialized packet’s size. Being a static value not related to any

true characteristic of an interface, the delay metric component of an interface can be seen

more like an average delay incurred by the interface for typical traffic.

The delay command expresses the delay in somewhat inconvenient units—tens of micro-

seconds. Configuring a delay of 123 on an interface defines its delay to be 1230 micro-

seconds. The show interface command output already reports interface delay directly in

microseconds. This difference between the units used in show interface output and in the

delay command is subtle but significant. The show interface output will always display a

value ten times higher than the configured value. If the delay is not configured explicitly,

IOS assigns an implicit delay value to each interface, depending on the interface hardware

type.

When calculating the composite metric to a destination, EIGRP takes the total delay into

account. This is done by taking the delay as advertised by a neighboring router and sum-

ming it with the delay of the interface toward the advertising neighbor.

With Classic Metrics, EIGRP is capable of describing the delay in the range of 10 to

167,772,140 microseconds (1 to 16,777,214 tens of microseconds). A delay of 16,777,215

tens of microseconds is used to indicate an infinite distance and is the key to the abil-

ity of advertising an unreachable network. Split Horizon with Poisoned Reverse, Route

Key

Topic

Key

Topic

ptg13046388

362 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Poisoning, withdrawing a route—all these techniques in EIGRP use the maximum delay

as an indication of an unreachable route.

Reliability Metric Component

The reliability is a dynamically estimated metric of an interface that evaluates its reliabil-

ity, or the ratio between the count of successfully received and the count of all received

frames. This ratio is expressed as a fraction of 255. To illustrate, a reliability of 255

expresses a 100 percent reliability, a reliability of 230 expresses a 90 percent reliability,

and a reliability of 26 expresses a 10 percent reliability. The reliability metric is dynami-

cally updated by IOS.

When calculating the composite metric to a destination, EIGRP takes the minimal reli-

ability into account. This is done by comparing the reliability as advertised by a neigh-

boring router to the reliability of the interface toward the advertising neighbor, and taking

the lower value of these two.

There is an important fact regarding the EIGRP’s handling of reliability metric. While

EIGRP does advertise the information about the path reliability and optionally factors

it into the composite metric (this depends on K-value settings described later in this

section), EIGRP does not send updates when an interface’s reliability changes. In other

words, a change in interface reliability value does not trigger sending EIGRP updates. The

reliability metric of a route is just a snapshot of its then-current reliability when it was

last advertised.

To understand this, recall that EIGRP metrics are retaken from IGRP, which was a timer-

driven protocol. EIGRP, on the other hand, is an event-driven protocol. If the reliability

metric change was a trigger event for EIGRP, it could potentially induce a routing table

oscillation into the network, bringing the traffic on and off the unreliable link and aggra-

vating the swings in the reliability metric more and more, creating a feedback loop. In

fact, the reliability metric component was retaken into EIGRP primarily to facilitate the

smooth transition from IGRP. As a result, in EIGRP, the reliability metric component is

currently just a relic carried over from its predecessor, with no particular usability.

Load Metric Component

The load is a dynamically estimated metric of an interface that measures the amount of

traffic flowing through the interface in relation to its maximum capacity. Similar to reli-

ability, the load is also expressed as a fraction of 255, with the load of 1 representing an

empty interface and the load of 255 representing a fully utilized interface. To account for

large differences in the momentary load caused by bursty traffic, IOS actually computes

an exponentially weighted average over the momentary load that smooths out short-lived

load swings. Because an interface can be differently utilized in the ingress and egress

data flow direction, IOS maintains two independent load metric counters, the Txload for

outgoing traffic and Rxload for incoming traffic.

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 363

When calculating the composite metric to a destination, EIGRP takes the maximal

Txload into account. This is done by comparing the load as advertised by a neighbor-

ing router to the Txload of the interface toward the advertising neighbor, and taking the

higher value of these two.

EIGRP’s handling of the load metric component is the same as with reliability: While

advertised and optionally factored into the composite metric, the changes in the Txload

values on interfaces do not trigger EIGRP updates. The load metric of a route is just a

snapshot of its then-current load when it was last advertised. The load, along with the

reliability, is a relic from IGRP with no particular usability in EIGRP.

MTU Metric Component

There is widespread confusion regarding the maximum transmission unit (MTU) metric

component in EIGRP and its use. Similar to bandwidth and reliability, EIGRP advertises

the minimum MTU along the route to the destination. However, even though carried in

EIGRP messages, the MTU is completely unused in the best-path selection process. It is

not factored into the composite metric, nor is it used as any kind of a tiebreaker. Simply

put, the use of the MTU in EIGRP’s best-path selection algorithm has never been imple-

mented.

Hop Count Metric Component

The hop count metric component is simply a counter of routers (hops) in the path toward

the destination. It is just a fallback security measure: EIGRP routers can be configured

to advertise each route having its hop count over a predefined threshold as unreachable,

thereby breaking any potential routing loops. By default, this limit is 100, and can be con-

figured in the range of 1 to 255. The hop count is not factored into the composite metric

calculation and does not impact the best-path selection in any way.

Calculating the Composite Metric

Because EIGRP treats each metric component differently (delay is summed, bandwidth

and reliability are minimized, load is maximized), EIGRP routers exchange these compo-

nent metrics as separate values. To arrive at a single composite metric value, each router

must independently compute the resulting composite metric on its own. This composite

metric is used locally on a router, and is never advertised as a single number in EIGRP

messages. The only exception to this rule is when a route is redistributed from one EIGRP

process to another. Even in this case, however, the composite metric of the redistributed

route is retaken only for diagnostic purposes and carried separately from the seed com-

ponent metrics specified in the redistribute command that activates the redistribution

and defines the starting component metrics for redistributed routes.

Using the bandwidth, delay, reliability, and load, each EIGRP router computes a compos-

ite metric value using the formula shown in Figure 8-1 .

Key

Topic

Key

Topic

ptg13046388

364 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

CM =

BWs =BandwidthMin

Ds =

256 • 107

K1 • BWsK2

K3Ds

256 • DelaySummed

256 ⫺ LoMax K4 ⫹ RMin

BWs⫹⫹ •••

Figure 8-1 Classic Composite Metric Computation Formula

The constants K

1 through K

5 , commonly called K-values, are weight constants in the range

0–255 that can be tweaked to influence the impact of individual metric components on the

overall composite metric. It is crucial that all EIGRP routers in an autonomous system com-

pute the composite metric in the same way. Therefore, K-values on all routers must match.

If K-values on two neighboring routers differ, the routers will be unable to establish an adja-

cency. By default, K

1 and K

are set to 1, and all other K-values are set to 0, causing EIGRP

to take only bandwidth and delay into account. If K

5 is 0 (which it is by default), the entire

term in the right parentheses, that is, K

5 /(K 4 + R

Min ), is not used in the metric computation.

The BW Scaled term is in effect telling how many times the minimal bandwidth along the

path is smaller than a 10

7 -Kbps = 10-Gbps link, multiplied by 256. The D

Scaled term is a

sum of all interface delays along the path to the destination in tens of microseconds, mul-

tiplied by 256. The multiplication by 256 in both terms is the result of expanding the for-

mer IGRP 24-bit metric into a 32-bit metric used by EIGRP. The remaining terms—Lo

Max

standing for maximum load and R

Min standing for minimum reliability—are taken without

further modification.

Note once again that neither MTU nor hop count is a part of the composite metric for-

mula. The hop count only causes a route reaching the predefined hop count limit to be

advertised as unreachable; the MTU is unused. Neither of these metric components influ-

ences the choice of best path.

EIGRP Wide Metrics

With the speeds of interfaces ever increasing, the EIGRP Classic Metrics faced issues

with interfaces faster than 1 Gbps. The Bandwidth component itself is unable to differen-

tiate between a 10-Gbps and faster interfaces. In addition, the default Delay component

metric is already set to the lowest value of 1 (10 microseconds) on 1-Gbps interfaces

and cannot be made smaller on faster interfaces. Also, the bandwidth and delay metric

components are carried in EIGRP packets in their scaled form. This requires each router

to descale them first to obtain the Bandwidth

Min and Delay

Summed values to perform the

necessary minimization of bandwidth and summing the delay, and then scale them again

when computing the composite metric and advertising the route to its neighbors. Because

Cisco routers perform integer arithmetic, the round-off errors during this repetitive scal-

ing and descaling can introduce a gradual loss of resolution.

These reasons prompted EIGRP developers to design an improved set of metrics that

allow for a greater range of key parameters and that are carried in EIGRP packets in their

Key

Topic

ptg13046388

Chapter 8: EIGRP 365

raw form, avoiding the loss of precision. These metrics are amply named Wide Metrics.

To see whether your router supports Wide Metrics, check out the output of selected

show eigrp commands, as shown in Example 8-3 .

Example 8-3 Confirming the Presence of EIGRP Wide Metrics Support

! In the show eigrp plugins command output, check whether the version

! of eigrp-release plugin is at least 8.00.00. In this output,

! the eigrp-release plugin is of version 12.00.00.

Router# show eigrp plugins

EIGRP feature plugins:::

eigrp-release : 12.00.00 : Portable EIGRP Release

: 2.00.09 : Source Component Release(rel12)

parser : 2.02.00 : EIGRP Parser Support

igrp2 : 2.00.00 : Reliable Transport/Dual Database

[ ... output omitted ... ]

! Alternatively, check out the output of show eigrp tech-support command

! and look for Wide Metrics support claimed explicitly

Router# show eigrp tech-support

EIGRP feature plugins:::

eigrp-release : 12.00.00 : Portable EIGRP Release

: 2.00.09 : Source Component Release(rel12)

+ HMAC-SHA-256 Authentication

parser : 2.02.00 : EIGRP Parser Support

igrp2 : 2.00.00 : Reliable Transport/Dual Database

+ Wide Metrics

[ ... output omitted ... ]

! Yet another easy way of detecting the support of Wide Metrics is the

! show ip protocols output. Note the presence of the K6 constant,

! the rib-scale of 128 and 64-bit metric version – all these indicate

! that Wide Metrics are supported.

Router# show ip protocols

Routing Protocol is "eigrp 1"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Default networks flagged in outgoing updates

Default networks accepted from incoming updates

EIGRP-IPv4 VR(Test) Address-Family Protocol for AS(1)

Metric weight K1=0, K2=0, K3=1, K4=0, K5=0 K6=0

Metric rib-scale 128

Metric version 64bit

[ ... output omitted ... ]

ptg13046388

366 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

With Wide Metrics, the general philosophy of EIGRP metrics is maintained; however,

the metric components whose range has been extended carry a new name to distinguish

them from their classic counterparts.

EIGRP Wide Metrics consist of following components:

■ Throughput: This metric is analogous to the classic Bandwidth component. The

throughput metric of an interface is calculated as 65536×10

7 /Interface Bandwidth,

with the interface bandwidth expressed in kbps. The throughput component effec-

tively tells how many times slower the interface is than a 655.36-Tbps link.

■ Latency: This metric is analogous to the classic Delay component. The latency

metric of an interface is calculated as 65536×Interface Delay/10

6 , with the interface

delay expressed in picoseconds. Because the delay metrics have sensible defaults

only on interfaces with physical bandwidths up to 1 Gbps, the computation of per-

interface delay metric differs based on its physical capability and configuration,

making it somewhat counterintuitive.

■ On interfaces physically operating on speeds of 1 Gbps and lower without band-

width and delay commands, the interface delay is simply its IOS-based default

delay converted to picoseconds.

■ On interfaces physically operating on speeds over 1 Gbps without bandwidth

and delay commands, the interface delay is computed as 10

13 / interface default

bandwidth .

■ On interfaces conﬁ gured with the explicit bandwidth command and without the

delay command, regardless of their physical operating speed, the interface delay

is the IOS-based default delay converted to picoseconds.

■ On interfaces conﬁ gured with explicit delay command, regardless of their physi-

cal operating speed and the bandwidth setting, the interface delay is computed

as its speciﬁ ed delay value converted to picoseconds, that is, 10

7 ×value of the

delay command (recall that the delay command deﬁ nes the delay in tens of

microseconds).

■ Reliability: This metric is identical to the classic Reliability component and has not

changed in Wide Metrics.

■ Load: This metric is identical to the classic Load metric component and has not

changed in Wide Metrics.

■ MTU: This metric is identical to the classic MTU metric component, and just like in

Classic Metrics, it is advertised but unused.

■ Hop Count: This metric is identical to the classic Hop Count metric component, and

just like in Classic Metrics, it is advertised but unused in path selection; it only pre-

vents potential routing loops.

■ Extended Metrics: These metric components are considered as placeholders for

future extensions to the composite metric computation. As of this writing, three

extended metrics were defined: Jitter, Energy, and Quiescent Energy. To incorporate

Key

Topic

ptg13046388

Chapter 8: EIGRP 367

these components into the composite metric, the K

6 constant was introduced. These

metric components are not usually used or supported.

Using the throughput, latency, reliability, load, and extended metrics, each EIGRP router

computes a wide composite metric value using the formula shown in Figure 8-2 .

WM =K1 • TMin K2

K3LaSummed

TMin =BandwidthMin

65536 • 107

LaSummed =

elayInterface =

106

65536 • DelayInterface

1013

DefaultBandwidthInterface

DefaultDelayInterface [picosec]

107 • ConfiguredDelayInterface

for interfaces ≤ 1 Gbps

or where bandwidth is configured,

for interfaces > 1 Gbps,

where delay is configured

256 ⫺ LoMax

K4 ⫹ RMin

TMin ⫹⫹ •

•

K6ExtM

⫹•

Figure 8-2 Wide Composite Metric Computation Formula

In this formula, T

Min is the throughput computed using the least bandwidth along the

path to the destination, La

Summed is the sum of latencies for each interface along the path

to the destination, Lo

Max is the maximum load on the path, R

Min is the minimum reliabil-

ity on the path, and ExtM are the extended metrics.

The Wide Metric support is available when EIGRP is configured in named mode as

described later in the chapter, and is automatically activated—there is no command to

control the activation of Wide Metrics. EIGRP routers supporting Wide Metrics auto-

matically detect whether their neighbors also support Wide Metrics, and use the appro-

priate metric type when talking to them. Wide Metrics are preferred; if all neighbors on

an interface support Wide Metrics, they will be used automatically instead of Classic

Metrics. In the case of mixed neighbors on a common interface, EIGRP routers support-

ing Wide Metrics will use both metric formats in their messages, allowing each neighbor

to process the metric format it supports.

Because the Wide Metrics composite value can well result in a number wider than 32

bits while the routing table (Routing Information Base, RIB) is capable of handling only

32-bit metrics, the Wide Metrics composite value has to be downscaled before the route

can be passed down to the RIB in IOS. This is done by dividing the Wide Metrics

Key

Topic

ptg13046388

368 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

composite value by a factor configured in the metric rib-scale EIGRP command. The

default value is 128 and can be configured in the range 1–255. Note that this downscaled

value is not used by EIGRP in any way. EIGRP makes all its path selections based on the

Wide Metrics composite value; only after a best path toward a destination is selected, its

composite metric value is downscaled as the route is installed to the RIB.

Tweaking Interface Metrics to Influence Path Selection

As should be obvious from the discussion about EIGRP metric components so far, the

only EIGRP metric components that can be manually influenced are the Bandwidth and

Delay. It might be tempting to use the bandwidth command to force EIGRP to use or not

to use a particular path. The answer to this idea, however, is a resolute and resounding no .

Following is an adapted quotation from the public EIGRP Internet Draft document draft-

savage-eigrp that considers this issue to be grave enough to warrant a special mention:

When trying to manually influence EIGRP path selection through interface band-

width/delay configuration, the modification of bandwidth is discouraged for follow-

ing reasons:

■ The change will only affect the path selection if the configured value is the low-

est bandwidth over the entire path. Changing the bandwidth can have impact

beyond affecting the EIGRP metrics. For example, quality of service (QoS) also

looks at the bandwidth on an interface.

■ EIGRP by default throttles to use 50 percent of the configured bandwidth.

Lowering the bandwidth can cause problems like starving EIGRP neighbors from

getting packets because of the throttling back. Configuring an excessively high

bandwidth can lead EIGRP to consume more bandwidth than physically avail-

able, leading to packet drops.

■ Changing the delay does not impact other protocols nor does it cause EIGRP to

throttle back, and because, as it’s the sum of all delays, has a direct effect on path

selection.

In other words, the bandwidth parameter of an interface should always be configured to

the true bandwidth of the interface and should never be used to influence EIGRP’s path

selection. Instead, the delay is a parameter that has absolutely no impact on any other

IOS subsystem and even to EIGRP; it constitutes only a constant to be summed together

with the existing path delay to compute the total path delay. Being the only cumulative

parameter in EIGRP’s metric computation, the delay is the right metric that can be manu-

ally modified to affect the best-path selection.

EIGRP Packet Format

EIGRP packets are carried directly in IP packets, using protocol number 88. The maxi-

mum length of an EIGRP packet is derived from the maximum IP MTU on the particu-

lar interface—typically 1500 bytes for the entire IP packet, leaving 1480 bytes for the

EIGRP packet itself.

Key

Topic

ptg13046388

Chapter 8: EIGRP 369

Figure 8-3 and Table 8-3 explain the generic format of an EIGRP packet. Each EIGRP

packet carries a 20-byte header, followed by a variably sized body indicated in Figure

8-3 as TLVs , standing for Type-Length-Value triplets. These TLVs carry diverse informa-

tion including EIGRP and TLV versions, K-values, Hold timers, control information to

facilitate reliable multicasting, and most importantly, route reachability information. With

respect to RTP, there is no clearly delineated RTP header. Instead, the Flags, Sequence

number, and Acknowledgment number fields are the ones that provide most of the RTP

functionality in EIGRP; some others are implemented using specific TLVs. With a certain

degree of simplification, the entire EIGRP packet header can also be considered an RTP

header.

32 Bit

VERSION=2 OPCODE

FLAGS

SEQUENCE NUMBER

TLVs

…

ACKNOWLEDGMENT NUMBER

VIRTUAL ROUTER ID AUTONOMOUS SYSTEM NUMBER

CHECKSUM

Figure 8-3 Basic EIGRP Packet Format

Table 8-3 EIGRP Packet Format Details

Field Description

Version Field 4-bit field used to indicate the protocol version of the originating

EIGRP process. The version of the EIGRP protocol itself has not

changed since its release and is set to 2.

Opcode 4-bit field that specifies the EIGRP packet type. Relevant types are

1 = Update, 3 = Query, 4 = Reply, 5 = Hello/Ack, 10 = SIA Query, 11

= SIA Reply. Other types have been allocated for different, mostly

unimplemented purposes, or are obsolete; only the indicated packet

types are used.

Checksum 24-bit field that is used to run a sanity check on the EIGRP packet.

This field is based on the entire EIGRP packet excluding the IP header.

Flags 32-bit field indicating specific flags: 0x1 = Init (used during initial

adjacency buildup), 0x2 = Conditional Receive (used by RTP to

allow this message to be received only by a subset of receivers), 0x4

= Restart (indicates that a router has restarted), 0x8 = End-of-Table

(indicates that the transmission of the entire EIGRP database is

complete).

Key

Topic

ptg13046388

370 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Field Description

Sequence 32-bit field that contains a sequence number used by RTP. This

facilitates orderly delivery of reliable packets.

Acknowledgment 32-bit field used by RTP that contains the sequence number of the

last packet heard from the neighbor to which this packet is being sent.

A Hello packet with a nonzero ACK field will be treated as an ACK

packet rather than as a Hello. Note that an ACK field will only be

nonzero if the packet itself is unicast because acknowledgments are

never multicasted.

Virtual Router ID 16-bit field identifying the virtual router this packet is associated

with. Currently used values are 0x1 = Unicast Address Family, 0x2 =

Multicast Address Family, 0x8000 = Unicast Service Address Family

(in Service Advertisement Framework).

Autonomous

System Number

16-bit field that identifies the number of the EIGRP domain.

Type-Length-Value Field used to carry route entries as well as provide EIGRP DUAL

information. EIGRP supports several different types of TLVs:

0x0001 EIGRP Parameters ( General TLV Types )

0x0002 Authentication Type ( General TLV Types )

0x0003 Sequence ( General TLV Types )

0x0004 Software Version ( General TLV Types )

0x0005 Next Multicast Sequence ( General TLV Types )

0x0102 IPv4 Internal Routes ( IP-Specific TLV Types )

0x0103 IPv4 External Routes ( IP-Specific TLV Types )

0x0402 IPv6 Internal Routes ( IP-Specific TLV Types )

0x0403 IPv6 External Routes ( IP-Specific TLV Types )

0x0602 Multi Protocol Internal Routes ( AFI-Specific TLV Types )

0x0603 Multi Protocol External Routes ( AFI-Specific TLV Types )

TLVs (Type-Length-Values) are a particular format of storing and transmitting different

types of information in a single datagram; each TLV contains a particular piece of infor-

mation that the sender wants to advertise. TLVs are not only found within EIGRP packets;

they are also common in other protocols like IS-IS, CDP, and LLDP as well.

As the name suggests, TLVs are formatted as triplets containing Type, Length, and Value

fields. The Type and Length fields are fixed in size (typically 1–4 bytes), and the Value

field is of variable size.

■ Type: A numeric code that indicates the kind of information stored in the Value

field.

ptg13046388

Chapter 8: EIGRP 371

■ Length: The total size of Type, Length, and Value fields. Note that some other pro-

tocols (not EIGRP) store only the length of the Value field in the Length.

■ Value: Variable-sized series of bytes that contain the actual information.

Each Internal and External Route TLV contains a single route entry. The Update, Query,

Reply, SIA-Query, and SIA-Reply packets contain at least one such TLV to advertise a

particular network or to query for it. The list, or the array (the vector), of Internal and

External Route TLVs in these packets is what constitutes the distance-vector nature of

EIGRP. Each TLV advertises a particular network and a distance toward it, with multiple

TLVs constituting a vector of such distances.

Details about the format and use of individual TLVs in EIGRP can be found in the EIGRP

Internet Draft published on the Internet Engineering Task Force (IETF) web page, at the

time of this writing named draft-savage-eigrp .

EIGRP Packets

EIGRP uses seven different packet types when communicating with its neighboring

routers:

■ Hello packets

■ Acknowledgment packets

■ Update packets

■ Query packets

■ Reply packets

■ SIA-Query packets

■ SIA-Reply packets

The Update, Query, Reply, SIA-Query, and SIA-Reply packets are also called reliable

packets because EIGRP makes sure that they are all delivered and in proper order.

EIGRP Packets in Action

Statistics about all sent and received EIGRP packets can be obtained using the show ip

eigrp traffic command, as illustrated in Example 8-4 .

Example 8-4 EIGRP Traffic Counters

R1# show ip eigrp traffic

EIGRP-IPv4 VR(CCIE) Address-Family Traffic Statistics for AS(1)

Hellos sent/received: 1132/6090

Updates sent/received: 169/428

Queries sent/received: 0/0

Replies sent/received: 0/0

Acks sent/received: 74/191

ptg13046388

372 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

SIA-Queries sent/received: 0/0

SIA-Replies sent/received: 0/0

Hello Process ID: 246

PDM Process ID: 244

Socket Queue: 0/10000/7/0 (current/max/highest/drops)

Input Queue: 0/2000/7/0 (current/max/highest/drops)

The sections that follow describe all these packets in more detail.

Hello Packets

EIGRP sends periodic Hello packets once it has been enabled on a router for a particu-

lar interface. These Hello messages are used to identify neighbors, verify whether these

neighbors are compatibly configured (residing on a common IP subnet, using the same

AS number, K-values, and authentication if configured), and serve as a keepalive mecha-

nism between neighbors. EIGRP Hello packets are sent to the link-local multicast group

address 224.0.0.10 in IPv4, and FF02::A in IPv6. If static neighbors are configured, Hello

packets are sent as unicasts to the neighbor’s explicitly configured address. The default

Hello interval is 5 seconds; on NBMA interfaces with the bandwidth setting of 1544

kbps and less, the default Hello interval is 60 seconds. EIGRP Hello packets have an

Opcode of 5 and are not acknowledged.

Acknowledgment Packets

An EIGRP Acknowledgment (ACK) packet is used to acknowledge selected received

EIGRP packets to facilitate their reliable delivery. ACKs are sent in response to Update,

Query, Reply, SIA-Query, and SIA-Reply packets, and are always unicasted to the sender

of the acknowledged packet. With respect to the packet format, EIGRP ACK is essen-

tially a Hello packet with an empty body (that is, no TLVs), carrying only the common

EIGRP packet header as shown in Figure 8-3 , and having a non-zero Acknowledgment

number field whose value is set to the Sequence number of the reliable packet being

acknowledged. The ACK uses the same Opcode as the Hello packet, that is, 5.

Note in Figure 8-3 that the header of each EIGRP packet carries an Acknowledgment

number field. In EIGRP, it is allowed to use any unicast reliable packet to also carry

an acknowledgment number. If a router has both a unicast reliable packet to send to a

neighbor and also needs to acknowledge a previously received reliable packet from that

neighbor, the sequence number of the received reliable packet can be sent along with

the outbound reliable packet in its Acknowledgment number field. It is not necessary

to send a standalone ACK in this case; the unicast reliable packet carrying a nonzero

Acknowledgment number field will be processed by its recipient both by its true type

and as an ACK.

EIGRP’s use of the Acknowledgment number field is very similar to that of TCP: After a

TCP session is established, each TCP segment can both contain data in its payload and

carry an acknowledgment in its Acknowledgment number header field. If a sender of a

Key

Topic

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 373

TCP segment has any data to send to its peer, it will send it along with the acknowledg-

ment of the last received octet (plus 1). If there is no data to be sent to the peer, only a

TCP segment header with an empty body is sent, carrying the proper acknowledgment.

In EIGRP, it is quite the same: If both an ACK and a reliable packet are waiting to be sent

to the same neighbor, EIGRP can put the acknowledgment number into the reliable pack-

et’s Acknowledgment number field, saving the need to send a standalone ACK. If there is

no reliable packet waiting to be sent to a neighbor, just an acknowledgment is outstand-

ing, EIGRP chooses the packet type for which it makes most sense to have an empty

body, which is obviously a Hello packet, to carry the acknowledgment number, hence the

standalone ACK—in reality a Hello with no TLVs and just its Acknowledgment number

field set. Noting that the ACK essentially consists of just the EIGRP packet header, the

similarity to TCP’s use of segment headers with empty payloads to carry acknowledg-

ments is striking.

Keep in mind that out of reliable packets, only those that are unicasted can be also used

to carry acknowledgment numbers. It would not make sense to put acknowledgment

numbers into multicast reliable packets as they are received by multiple routers while the

acknowledgment is itself always relevant only to a single packet from a single neighbor.

Update Packets

EIGRP Update packets contain routing information updates and are used to convey the

reachability of destinations. Update packets can be both unicasted and multicasted.

Regarding the use of multicast or unicast to send Update packets, the rules can be sum-

marized as follows:

■ During a new adjacency buildup, Update packets are unicasted between the newly

discovered neighbors. In specific cases, when multiple new neighbors are detected

on a single multiaccess interface in a short time span, EIGRP might choose to syn-

chronize to them using multicasts for efficiency reasons (for example, when a hub

router in a Dynamic Multipoint VPN [DMVPN] network starts and detects tens or

hundreds of spoke routers). Details on the choice process of unicast or multicast

Update packets during adjacency buildup are proprietary. The particular choice only

impacts the efficiency of the initial synchronization process, and has no influence on

the actual contents of exchanged information.

■ After routers have fully synchronized, further Updates are sent as multicasts.

■ If a neighbor does not acknowledge the arrival of an Update packet, EIGRP will

retransmit the Update as unicast to the unresponsive neighbor.

■ On point-to-point interfaces and for statically configured neighbors, EIGRP always

uses unicast to send Updates.

Update packets are delivered reliably, meaning that they are always acknowledged and

retransmitted if no acknowledgment is heard in a certain time. Update packets are

assigned an Opcode of 1.

Key

Topic

ptg13046388

374 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Query Packet

EIGRP Query packets are used to involve neighbors in the task of searching for the best

route toward a destination. Similarly to Updates, Queries are also delivered reliably.

Queries can be both unicasted and multicasted; by default, on multiaccess interfaces with

only dynamic neighbors, Queries are sent as multicasts. If not acknowledged in proper

time by a neighbor, a Query is retransmitted to the unresponsive neighbor as unicast. On

point-to-point interfaces and toward statically configured neighbors, Queries are always

sent as unicasts. Note that while each received Query must be acknowledged by send-

ing an ACK, this ACK does not constitute a response to the Query message, only an

acknowledgment that the Query has been received. The following packet type, the Reply,

is used for that purpose. EIGRP Query packets are assigned an Opcode of 3.

Reply Packets

EIGRP Reply packets are sent in response to Query packets and carry their sender’s

current distance to the destination after taking into account the topology change that

prompted the Query. Reply packets are always unicasted to the originator of the Query

and delivered reliably. The EIGRP Reply packets are assigned an Opcode of 4.

SIA-Query and SIA-Reply Packets

These two packet types are used during a prolonged diffusing computation to verify

whether a neighbor that has not yet sent a Reply to a Query is truly reachable and still

engaged in the corresponding diffusing computation. The SIA-Query packet is used to

ask a particular neighbor to confirm that it is still working on the original Query. If the

neighbor is reachable and is still engaged in the diffusing computation for the destination

specified in the SIA-Query, it will immediately respond with an SIA-Reply packet. As a

result, the timer that governs the maximum time a diffusing computation is allowed to

run is reset, giving the computation extra time to finish. Both SIA-Query and SIA-Reply

packets are unicast and reliably delivered. SIA-Query uses an Opcode of 10, and SIA-

Reply uses an Opcode of 11.

Reliable Transport Protocol

The Reliable Transport Protocol (RTP) manages the delivery and reception of EIGRP

packets. Reliable delivery means that delivery is guaranteed and that packets will be

delivered in order. This is accomplished by means of a Cisco-invented algorithm known

as reliable multicast. Packet types that are to be delivered reliably are Update, Query,

Reply, SIA-Query, and SIA-Reply, regardless of whether they are unicasted or multi-

casted (SIA-Query, Reply, and SIA-Reply are only unicasted, of course). Each of these

packets carries a nonzero Sequence number in its header. The Sequence number is a

global value maintained per each EIGRP process instance on a router and is incremented

whenever one of these packets is originated by the instance, regardless of which EIGRP-

enabled interface the packet is going to be sent from. Each neighbor receiving an Update,

Query, Reply, SIA-Query, or SIA-Reply is required to send back an ACK packet with the

Key

Topic

Key

Topic

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 375

Acknowledgment number set to the Sequence number of the packet to be acknowledged.

A neighbor can also acknowledge a reliable packet by “piggybacking” the acknowledg-

ment onto its own reliable packet (if it has any to send to this router) by appropriately set-

ting the Acknowledgment number field in the packet’s header, as explained earlier in the

“Acknowledgment Packets” section. If an acknowledgment is not received within a certain

time period, the packet is retransmitted as unicast to the unresponsive neighbor.

Packets that are not to be delivered reliably (Hello and ACK packets) set their Sequence

number to zero and do not cause the global Sequence number to increase.

With a naïve reliable multicast, each recipient of a multicasted message must acknowl-

edge its arrival before the sender can move on to transmit another message. If some recip-

ient does not acknowledge the message, the sender has to postpone further sending of

multicast packets and retransmit the missing message to the intended recipient as unicast

until the recipient successfully acknowledges its arrival. Obviously, a single misbehaving,

overloaded, or poorly connected recipient can negatively impact the performance of the

entire reliable multicast streaming. A natural solution would be to continue sending the

multicast packets while, in parallel, retransmitting the unacknowledged and subsequent

delayed packets in their proper order to the “lagging” recipient as unicasts to allow it to

eventually catch up. This poses a problem, however: The lagging neighbor is still a mem-

ber of the multicast group, and if it by chance received the next multicast packet without

first receiving the packet it has missed before, it would be processing the streamed mes-

sages out of correct order.

To cope with this situation, RTP has an additional distinctive feature called Conditional

Receive. This feature allows EIGRP to partition all its neighbors on a multiaccess interface

into two groups: a group of well-behaved neighbors that have been able to acknowledge

all multicast messages sent so far and a group of “lagging” routers that have failed to

acknowledge at least one transmitted reliable EIGRP packet and that must be handled

individually. If EIGRP wants to continue sending the multicast packets in parallel with

retransmitting the unacknowledged packets to the lagging routers as unicasts, it has to

send the in-order multicast packets with a special flag saying “this packet is only for

those routers that have received all multicast packets so far.”

This is accomplished by the sender first transmitting a Hello packet with two specific

TLVs called the Sequence TLV and the Next Multicast Sequence TLV, often called a

Sequenced Hello. The Next Multicast Sequence TLV contains the upcoming sequence

number of the next reliable multicasted message. The Sequence TLV contains a list of

all lagging neighbors by their IP address, in effect saying “whoever finds himself in this

list, ignore the next multicast message with the indicated sequence number.” A neighbor

receiving this Sequenced Hello packet and not finding itself in the Sequence TLV will

know that it is expected to receive the upcoming multicast packet, and will put itself into

a so-called Conditional Receive mode (CR-mode). A neighbor receiving this Sequenced

Hello packet and finding itself in the Sequence TLV, or a neighbor not receiving this Hello

packet at all for whatever reason will not put itself into the CR-mode. Afterward, the

sending router will send the next multicast packet with the CR flag set in its Flags field.

Routers in CR-mode will process this packet as usual and then exit the CR-mode; routers

not in CR-mode will ignore it. As a result, the router is able to continue using multicast

ptg13046388

376 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

with those routers that have no issues receiving and acknowledging it, while making sure

that the lagging neighbors won’t process the multicasts until they are able to catch up.

Each lagging neighbor that has not acknowledged one or more multicast packets will be

sent these packets as unicasts in their proper sequence.

The time to wait for an ACK before declaring a neighbor as lagging and switching from

multicast to unicast is specified by the multicast flow timer . The time between the sub-

sequent unicasts is specified by the retransmission timeout (RTO) . Both the multicast

flow timer and the RTO are calculated for each neighbor from the smooth round-trip

time (SRTT) . The SRTT is the average elapsed time, measured in milliseconds, between

the transmission of a reliable packet to the neighbor and the receipt of an acknowledg-

ment. The formulas for calculating the exact values of the SRTT, the RTO, and the multi-

cast flow timer are beyond the scope of this book.

Router Adjacencies

EIGRP routers establish and maintain neighbor adjacencies. EIGRP by default discovers

neighboring routers dynamically, or it can discover neighbors through manual administra-

tor configuration (static).

Dynamic neighbor discovery is performed by sending EIGRP Hello packets to the desti-

nation multicast group address 224.0.0.10 or FF02::A. This is performed as soon as EIGRP

is activated on an interface. Static EIGRP neighbor relationships require manual neighbor

configuration on the router. When static EIGRP neighbors are configured, the local router

uses the unicast neighbor address to send packets to these routers. You would typically

use static neighbor configuration when being deployed across media that does not native-

ly support broadcast or multicast packets, such as Frame Relay.

After a static neighbor is defined, all EIGRP multicasts on the interface through which

the neighbor is reachable will be disabled. As a result, EIGRP-enabled routers will not

establish an adjacency if one router is configured to use unicast (static) while another

uses multicast (dynamic) on the same link. Here’s another way of putting this rule: Either

all neighbors on a common network segment are statically configured for each other, or

none of them are.

It is important to understand that simply enabling EIGRP between two or more routers

does not guarantee that a neighbor relationship will be established. An EIGRP neighbor

relationship requires that neighbors agree on all the following parameters:

■ EIGRP Authentication Parameters (if configured)

■ EIGRP K-Values

■ EIGRP Autonomous System (AS) Number

■ Use of primary addresses for EIGRP neighbor relationships

■ Use of the common IP network address on a single subnet

If two routers differ in any of these parameters, they will not become EIGRP neighbors.

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 377

Note that the timers (that is, Hello and Hold) do not need to match between neighbors.

The default Hello interval (60 seconds on nonbroadcast multiaccess [NBMA] interfaces

with the configured bandwidth equal to T1 or slower, and 5 seconds on all other inter-

faces) can be changed with the interface command illustrated in Example 8-5 .

Example 8-5 Adjusting EIGRP Hello Intervals

Router(config-if)# ip hello-interval eigrp 100 ?

<1-65535> Seconds between hello transmissions

The Hold time tells the router the maximum time it should wait to receive subsequent

valid EIGRP packets from a neighbor. If the Hold timer expires before any acceptable

EIGRP packet is received, the neighbor is declared unreachable and DUAL is informed of

the loss of a neighbor. By default, the Hold time is three times the Hello, equaling either

15 or 180 seconds, depending on the interface type. Be aware, however, that changing the

Hello interval does not result in automatic recalculation of the Hold time. This can, under

certain circumstances, result in problems with flapping adjacencies if the Hello interval

is manually configured to be close or even higher than the default Hold time, without

changing the Hold timer itself.

As detailed in Example 8-6 , these defaults can be changed at the interface level.

Example 8-6 Adjusting EIGRP Hold Time

Router(config-if)# ip hold-time eigrp 100 ?

<1-65535> Seconds before neighbor is considered down

The process of establishing adjacency in EIGRP is illustrated in Figure 8-4 .

Hello

R1 R2

Hello

Null Update with Init, Seq=x

Init Received from R2

Ack Received from R2

R1 Puts R2 to Up

Acknowledgment, Ack=y

Database Synchronization

Using Updates and Acks

Null Update with Init, Seq=y, Ack=x

R1 Puts R2 to Pending

R2 Puts R1 to Pending

Init and Ack Received from R1

R2 Puts R1 to Up

Figure 8-4 Adjacency Creation Between EIGRP Neighbors

ptg13046388

378 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The process starts by a router discovering its new neighbor by receiving a Hello packet

from it. In Figure 8-4 , R2 receives a Hello packet from R1. R2 will expedite sending its

own Hello packet onto the interface, allowing R1 to quickly discover it as well. As soon

as a new neighbor is discovered through a Hello packet, it is put into a so-called Pending

state. The purpose of this Pending state is to defer sending and accepting any EIGRP mes-

sages containing routing information between these neighbors until their bidirectional

connectivity has been confirmed.

Continuing the process, R2 sends R1 an empty Update packet, also called a null Update,

with the Init flag set. This null Update carries a nonzero sequence number but contains

no routing information. The Init flag is an indication to the neighbor that this adjacency

is starting over from scratch and the neighbor is requested to send its full database after

the bidirectional visibility is confirmed. R1 is required to acknowledge the arrival of this

null Update, thereby confirming the bidirectional connectivity, and it must also send R2

its own null Update packet with the Init flag set, acknowledging that the neighbor also

considers this adjacency to be starting over from scratch. R2 finally acknowledges R1’s

null Update, completing the initial exchange. The acknowledgments in this procedure can

either be sent as standalone ACK packets, or they can be carried in the null Update pack-

ets by setting the Acknowledgment Number field in their header to the sequence number

of the other router’s null Update packet—either of these options is valid.

While in Pending state, the only packets that can be exchanged in both directions with

the neighbor are the unreliable packets (Hello, Ack) and reliable packets with the Init flag

set that indicate the startup of an adjacency. In addition, because the bidirectional con-

nectivity with a neighbor in the Pending state has not yet been confirmed, it makes no

sense to send or process reliable packets containing meaningful routing information. As

a result, the only sensible reliable packet that can be exchanged with a neighbor in the

Pending state is exactly the null Update packet.

A neighbor is moved from the Pending to the Up state if and only if it acknowledges the

null Update received from the router and sends its own null Update with the Init flag set

to this router (in any order). In other words, the router must receive an acknowledgment

for its own null Update to the neighbor and must receive an Init-flagged packet from the

neighbor to move the neighbor from the Pending to the Up state. In a sense, this proce-

dure can be likened to the process of opening a TCP session. The Init flag is similar to the

SYN flag in TCP. The first null Update+Init from R2 toward R1 is similar to a TCP SYN

segment, R1’s null Update+Init with the piggybacked acknowledgment is similar to a TCP

SYN/ACK segment, and R2’s Ack packet confirming the R1’s null Update+Init is similar to

a TCP ACK segment.

After this initial three-way handshake, the routers will exchange complete routing infor-

mation using Update packets. After the synchronization is completed, EIGRP neighbors

will send only incremental updates to advise neighbors of status or routing changes and

will not send their full databases again unless restarted or resynchronization is manually

invoked.

Information about each neighbor is recorded in a neighbor table . To see the contents

of the neighbor table, use the show ip eigrp neighbors command in accordance with

Example 8-7 .

Key

Topic

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 379

Example 8-7 EIGRP Neighbor Table

R1# show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

1 10.10.10.3 Fa0/0 11 00:00:08 87 522 0 6

0 10.10.10.2 Fa0/0 14 00:01:54 1300 5000 0 3

The neighbor table records information about each detected neighbor with whom this

router has established an adjacency. The H (Handle) column shows the internal number

that EIGRP assigns to each neighbor. The handle number is used in EIGRP to internally

identify neighbors in an address-family independent way. The Address and Interface col-

umns hold the neighbor’s IP address and this router’s interface toward the neighbor. The

Hold time is derived from the value advertised by the neighbor and decremented each

second; it is reset every time any acceptable EIGRP packet from the neighbor is received.

The Uptime shows the time the neighbor has been up for the last time.

The SRTT , the Smooth Round Trip Time, estimates the turnover time between sending a

reliable packet to the neighbor and receiving an appropriate acknowledgment. The RTO,

or Retransmit Time Out, is the time that the router will wait for an acknowledgment of a

retransmitted unicast packet after its previous delivery was not acknowledged. If the RTO

expires before an ACK is received, another copy of the queued packet is sent. Both these

timers are shown in milliseconds.

The Q Cnt indicates the number of enqueued reliable packets, that is, packets that

have been prepared for sending and even possibly sent but for which no ACK has been

received yet from the neighbor. In a stable network, the Q Cnt value must be zero; non-

zero values are normal during initial router database synchronization or during network

convergence. If the Q Cnt value remains nonzero for prolonged periods of time, however,

it indicates a communication problem with the neighbor.

Finally, the Sequence number shows the sequence number of the last reliable packet

(Update, Query, Reply, SIA-Query, or SIA-Reply) received from the neighbor. RTP tracks

these sequence numbers to ensure that reliable packets from the neighbor are processed

in ascending order. Note that the Sequence number in EIGRP is a per-process variable

incremented each time a new reliable packet is originated and transmitted. If a neighbor

is involved in a reliable communication on one of its interfaces and then needs to send

another reliable packet to this router, the sequence number in this column might incre-

ment by more than 1. It is thus normal to see sequence numbers increasing by different

increments as long as they form an ascending series.

Table 8-4 summarizes the fields you see in the neighbor table.

ptg13046388

380 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 8-4 EIGRP Neighbor Table Columns

Field Description

H Internal reference to a neighbor, also called a neighbor handle, starting at 0.

Address The IP address of the neighbor.

Interface The interface toward the neighbor.

Hold The Hold timer for the neighbor. If it decreases to 0, the neighbor is considered

down.

Uptime Timer for how long the neighbor relationship has been up.

SRTT This is the Smooth Round Trip Time, which is the time it takes to send a

reliable EIGRP packet and receive an acknowledgment.

RTO This is the Retransmission Time Out, which is the amount of time the router

will wait between retransmitting an EIGRP reliable packet if an Ack is not

received.

Q Cnt This is the number of EIGRP reliable packets sent and waiting to be sent to the

neighbor but not acknowledged yet.

Seq Num This is the sequence number of the last EIGRP reliable packet received from the

neighbor. This is to ensure that packets from the neighbor are processed in the

correct order.

Diffusing Update Algorithm

The Diffusing Update Algorithm (DUAL) is a convergence algorithm that replaces the

Bellman-Ford algorithm used by other distance-vector protocols. Routing loops, even

those that might come into existence temporarily as our protocols fully converge, are det-

rimental to the performance of a network. To prevent the possibility of loop formation,

DUAL uses a concept of diffusing computations to perform distributed shortest-path

computation while maintaining freedom from loops during those calculations. DUAL is at

the center of the EIGRP routing protocol.

Topology Table

The central data store of an EIGRP process is the topology table . The choice of this

name is perhaps not particularly fortunate, as EIGRP, being a distance-vector routing pro-

tocol, has no information about the network’s topology per se. Nonetheless, the topology

table is the place where EIGRP stores its entire routing information including

■ The prefix of each known destination network (address/netmask)

■ Feasible Distance of the destination network

■ Address of each neighboring router that advertised the destination network, includ-

ing the egress interface toward the neighbor

Key

Topic

ptg13046388

Chapter 8: EIGRP 381

■ Metrics of the destination network as advertised by each neighbor, and the resulting

metrics of the path to the destination network through that neighbor

■ State of the destination network

■ Additional information about the network (various internal flags, network type and

origin, and others)

The topology table is populated and updated by locally injected networks (directly

connected interfaces added to EIGRP, routes redistributed locally) and by contents of

received EIGRP Update, Query, Reply, SIA-Query, and SIA-Reply messages. For each

remote network learned through EIGRP and stored in the topology table, EIGRP will

look up the neighbor that provides the least total cost path to the destination and verify

that the neighbor provides a loop-free path, and if so, install the network through that

neighbor into the routing table. An important fact to remember is that a remote network

must first be present in the topology table before being installed in the routing table.

Each network recorded in the topology table has a state associated with it. This state

can be either Passive , meaning that the shortest path to the network has already been

found and EIGRP is satisfied with it, or it can be Active , meaning that EIGRP is currently

actively involved in a search for a new shortest path. In a stable topology, all routes shall

be in the Passive state. The Active state is always related to the router sending Query

packets, asking its neighbors for cooperation in the search for a new path. While in an

Active state, the router is prohibited from modifying the routing table entry for this net-

work, meaning that the route must not be removed or its next hop changed. The Active

state can be successfully terminated only by this router receiving a Reply from all its

neighbors. Only then can the route enter the Passive state again and the router can make

a new shortest-path selection, finally updating the routing table. As already stated, EIGRP

is designed to avoid routing loops at every instant. Keeping the formerly usable (and

loop-free) route unchanged in the routing table during the Active state makes sure that

the router stays with the former route—it might be suboptimal or cause traffic blackhol-

ing but is still loop-free. After the computation terminates, the router can choose a new

loop-free best path and start using it. EIGRP essentially behaves in a transactional way,

always moving from a loop-free path to another loop-free path, with no intermediary

states of transient routing loops ever possible. The exact rules of entering the Active state

will be explained later in the “Local and Diffusing Computations in EIGRP” section; at

this point, they can be summarized as follows:

■ Whenever a router needs to select a new shortest path and the neighbor providing

that path can be proven not to create a routing loop, the route stays in the Passive

state because the router already has all the information to make a correct choice.

■ If the neighbor providing the least-cost path can be guaranteed not to create a rout-

ing loop, or if no such neighbor exists, the route will need to enter the Active state.

Example 8-8 shows the contents of an EIGRP topology table of a router. Outputs in this

example were taken from Router R1 shown in Figure 8-5 in the following section. This

network runs IPv6 EIGRP, with the serial links between R1 and all other routers config-

ured using only IPv6 link-local addresses in the form of FE80::< RouterNumber >. The

ptg13046388

382 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

LAN at the right side of Figure 8-5 is configured as a passive network (R2, R3, and R4

have their interfaces into the LAN configured as passive; hence, no EIGRP adjacencies

are established over it), and it is assigned a global IPv6 prefix of 2001:DB8:CC1E::/64. R4

also redistributes a static route toward 2001:DB8:FFFF::/48 into EIGRP. To simplify met-

ric calculations, EIGRP in this network is configured to take only the delay metric com-

ponent into account (K3=1, all other K-values are set to 0). Delays on individual interfaces

are configured to the values shown in the figure. IPv6 is chosen for this example because

it allows operating this network with most interconnections configured with link-local

addresses only. This makes the outputs of various show and debug commands much

more readable. Also, for simplicity, this example was created on routers using the Classic

Metrics. Keep in mind that EIGRP multiplies the calculated classic metric by 256. Take

care to read the comments in the example carefully.

Example 8-8 EIGRP Topology Table Contents

! The show ipv6 eigrp topology output shows the AS number of the EIGRP process,

! its Router ID, and the collected knowledge of all networks locally injected

! into EIGRP or learned from other EIGRP neighbors. Towards 2001:DB8:CC1E::/64,

! only next hops FE80::2 (R2) and FE80::3 (R3) are displayed, as R4 currently

! does not meet the Feasibility Condition to be considered a prospective next hop.

! The show ipv6 eigrp topology is one of very few commands in EIGRP that actually

! shows the Router ID of the EIGRP process.

R1# show ipv6 eigrp topology

IPv6-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 2001:DB8:FFFF::/48, 1 successors, FD is 1024

via FE80::4 (1024/1), Serial1/2

P 2001:DB8:CC1E::/64, 1 successors, FD is 2560

via FE80::2 (2560/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

! Using the all-links keyword, all neighbors advertising a network, including

! those who fail to meet the Feasibility Condition check, are displayed.

! The reason there is just a single neighbor for the 2001:DB8:FFFF::/48

! displayed even with all-links is the Split Horizon with Poisoned Reverse

! used by EIGRP. As routers R2 and R3 are using R1 as their next hop towards

! 2001:DB8:FFFF::/48, they advertise it back to R1 with an infinite metric.

R1# show ipv6 eigrp topology all-links

IPv6-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Key

Topic

ptg13046388

Chapter 8: EIGRP 383

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 2001:DB8:FFFF::/48, 1 successors, FD is 1024, serno 3

via FE80::4 (1024/1), Serial1/2

P 2001:DB8:CC1E::/64, 1 successors, FD is 2560, serno 2

via FE80::2 (2560/256), Serial1/0

via FE80::4 (4096/3072), Serial1/2

via FE80::3 (5120/1280), Serial1/1

! By referencing a particular network, detailed information about it can be

! displayed. Notice the individual information stored about the network:

! State, Number of Successors, Feasible Distance, per-neighbor information

! covering the route type, individual metric components of the path over

! the neighbor, and resulting composite calculated metrics.

R1# show ipv6 eigrp topology 2001:DB8:CC1E::/64

IPv6-EIGRP (AS 1): Topology entry for 2001:DB8:CC1E::/64

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560

Routing Descriptor Blocks:

FE80::2 (Serial1/0), from FE80::2, Send flag is 0x0

Composite metric is (2560/256), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 100 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

FE80::4 (Serial1/2), from FE80::4, Send flag is 0x0

Composite metric is (4096/3072), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 160 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

FE80::3 (Serial1/1), from FE80::3, Send flag is 0x0

Composite metric is (5120/1280), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 200 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

ptg13046388

384 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! If detailed information about an external (redistributed) network is

! pulled from the topology table, apart from the obvious information,

! external networks also carry information about the router that performs

! the redistribution, and about the origins of the redistributed route

! such as what is its original type, AS number, or metric.

R1# show ipv6 eigrp topology 2001:DB8:FFFF::/48

IPv6-EIGRP (AS 1): Topology entry for 2001:DB8:FFFF::/48

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1024

Routing Descriptor Blocks:

FE80::4 (Serial1/2), from FE80::4, Send flag is 0x0

Composite metric is (1024/1), Route is External

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 40 microseconds

Reliability is 0/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

External data:

Originating router is 10.255.255.4

AS number of route is 0

External protocol is Static, external metric is 0

Administrator tag is 0 (0x00000000)

Computed, Reported, and Feasible Distances, and Feasibility

Condition

Toward a particular destination network, EIGRP keeps track of various distances as a part

of its operation. Unfortunately, the details about these distances, and their purpose and

operation, are often poorly explained and understood. A correct in-depth understand-

ing of EIGRP therefore requires that we revisit these concepts in detail. EIGRP uses a

composite metric; however, for simplicity, the remainder of this section assumes that the

EIGRP metric is a single dimensionless number, as it makes no difference to the opera-

tion of underlying mechanisms. As explained in the “EIGRP Classic Metrics” and “EIGRP

Wide Metrics” sections, earlier in the chapter, the metric components are combined into

a single number; the words distance and cost used interchangeably in this section refer

to this combined value. Also, for simplicity, throughout this section, EIGRP routers are

assumed to operate without Split Horizon.

Consider the topology shown in Figure 8-5 .

ptg13046388

Chapter 8: EIGRP 385

2001:DB8:CC1E::/64

Delay = 1

Delay = 9

Delay = 4

Delay = 15

Delay = 12

Delay = 5

Figure 8-5 Sample Network Operating EIGRP in IPv6 Mode

Assuming that the network has been properly configured and EIGRP has converged,

Example 8-9 shows the output of selected show commands issued on R1 that we will

analyze in greater detail. Throughout this discussion, we focus on R1’s behavior toward

destination network 2001:DB8:CC1E::/64. The redistribution on R4 has been removed.

Example 8-9 EIGRP Topology Table on R1

R1# show ipv6 route eigrp

IPv6 Routing Table - 2 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

U - Per-user Static route, M - MIPv6

I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary

O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2

ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

D - EIGRP, EX - EIGRP external

D 2001:DB8:CC1E::/64 [90/2560]

via FE80::2, Serial1/0

R1# show ipv6 eigrp topology

IPv6-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 2001:DB8:CC1E::/64, 1 successors, FD is 2560

via FE80::2 (2560/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

R1# show ipv6 eigrp topology all-links

IPv6-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

ptg13046388

386 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 2001:DB8:CC1E::/64, 1 successors, FD is 2560, serno 4

via FE80::2 (2560/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

via FE80::4 (4096/3072), Serial1/2

The show ip eigrp topology all-links command is of particular interest. The

2001:DB8:CC1E::/64 network is shown here with three possible next hops: Routers R2,

R3, and R4. Each of the “via” lines describes a possible route to the destination through

a particular neighbor and contains, besides the next hop’s IPv6 address and egress inter-

face, two numbers enclosed in parentheses. The number after the slash sign is called the

Reported Distance (RD) and corresponds to the current best distance of the particular

neighbor to the destination. In other words, the RD is the neighbor’s distance to the desti-

nation as reported in an EIGRP packet received from that neighbor. R1 learns about these

distances by receiving an EIGRP message from these neighbors that carries routing infor-

mation—an Update, Query, Reply, SIA-Query, or SIA-Reply. In some sources, RD is also

called an Advertised Distance , but because this term (and its acronym AD) is easily con-

fused with Administrative Distance, we will avoid using it. The RD values for routers R2,

R3, and R4 shown in Example 8-9 correspond to their delay values indicated in Figure 8-5

multiplied by 256 (256 = 1 × 256, 1280 = 5 × 256, 3072 = 12 × 256).

The number in parentheses before the slash sign is called the Computed Distance (CD)

and shows the total metric of reaching the destination over the particular neighbor. The

CD is computed as the RD of the neighbor plus the cost of the link between R1 and the

neighbor. Current values in Example 8-9 correspond to the total sum of delays from R1

through each particular neighbor multiplied by 256 (2560 = 10 × 256, 5120 = 20 × 256,

4096 = 16 × 256).

For each destination network, there is exactly one CD and one RD per each neighbor.

These distances are displayed in the “via” lines of the show ip eigrp topology output in

the form of (CD/RD).

Just as with any other routing protocol, EIGRP’s goal is to identify paths with the least

metric to the destination. To accomplish this, EIGRP chooses the path with the low-

est CD and installs it, after verifying that the path is not looped, into the routing table.

Example 8-9 shows that currently, the smallest distance to the destination network is

through R2 with the CD of 2560. This route is also installed into R1’s routing table, using

this CD as the route metric.

Both CD and RD correspond to the current distance, that is, the momentary total dis-

tance of this router to the destination through a particular neighbor (CD), and the neigh-

bor’s own distance to that destination as known by this router (RD). EIGRP also main-

tains a record of yet another distance for each destination: the Feasible Distance (FD) .

The FD is one of the most misunderstood and poorly explained concepts in EIGRP. For

each destination, FD is a record of the lowest known distance since the last transition

Key

Topic

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 387

from the Active to Passive state . In other words, FD is a historical record, or a histori-

cal copy, of the smallest known CD toward a particular destination, with the history

starting anew with the last Active-to-Passive transition. Being a record of the smallest

known CD since the route entered the Passive state for the last time, FD is not necessar-

ily equal to the current best CD to a destination. By its definition, in the Passive state,

after the FD has been initialized, it can only decrease (if the current best CD happens to

fall below the current value of FD) or remain at its current value (if the current best CD

rises but the route remains Passive). There is exactly one FD per each destination, regard-

less of the number of neighbors. It is important to note that the FD is an internal variable

maintained for each network known to EIGRP whose value is never advertised to another

router.

To better illustrate the behavior of FD, consider Example 8-10 , with comments inserted

directly into the output. Keep in mind that all metric modifications in this example are

carefully chosen to avoid violating the Feasibility Condition and causing the route toward

2001:DB8:CC1E::/64 entering the Active state. This example shows the behavior of the

FD while the route is kept in the Passive state.

Example 8-10 Feasible Distance Behavior in EIGRP

! Before performing any changes to the network, it is in the state shown

! in Figure 8-5 and Example 8-9 . Now assume that the delay of link between

! R1 and R2 has increased from 9 to 11. Note in the following output that

! while the CD via R2 has changed from 2560 to 3072 and so has the metric

! in the routing table, FD indicated in the network heading remained at its

! current value of 2560. At this moment, the value of FD says that "at some

! point in the past, R1 was as close as 2560 units to the destination", even

! though the current best CD is different. R2's RD did not change, either,

! because R2's best path to the destination has not been influenced in any way.

R1# show ipv6 eigrp topology all-links

! Legend removed for brevity

P 2001:DB8:CC1E::/64, 1 successors, FD is 2560, serno 5

via FE80::2 (3072/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

via FE80::4 (4096/3072), Serial1/2

R1# show ipv6 route eigrp

! Legend removed for brevity

D 2001:DB8:CC1E::/64 [90/3072]

via FE80::2, Serial1/0

! Further assume that subsequently, R2's LAN interface's delay increases

! from 1 to 3. Now, both R2's RD and CD through R2 change: R2's RD increases

! to 768 and CD via R2 increases to 3584 but again, the FD remains at its

! former value of 2560, as at some point in the past, our best CD was 2560.

Key

Topic

ptg13046388

388 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

R1# show ipv6 eigrp topology all-links

! Legend removed for brevity

P 2001:DB8:CC1E::/64, 1 successors, FD is 2560, serno 6

via FE80::2 (3584/768), Serial1/0

via FE80::3 (5120/1280), Serial1/1

via FE80::4 (4096/3072), Serial1/2

R1# show ipv6 route eigrp

! Legend removed for brevity

D 2001:DB8:CC1E::/64 [90/3584]

via FE80::2, Serial1/0

! Now, assume that R2's LAN interface's delay returns back to 1, and moreover,

! the delay of R1-R2 link decreases to 7. Because the total delay of 8 is now

! better than any experienced so far, not only the R2's RD and CD via R2 change,

! but also the FD as the record of the smallest known CD changes from 2560 to 2048.

R1# show ipv6 eigrp topology all-links

! Legend removed for brevity

P 2001:DB8:CC1E::/64, 1 successors, FD is 2048, serno 8

via FE80::2 (2048/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

via FE80::4 (4096/3072), Serial1/2

R1# show ipv6 route eigrp

! Legend removed for brevity

D 2001:DB8:CC1E::/64 [90/2048]

via FE80::2, Serial1/0

! Now when the delay of the R1-R2 link increases back to 9, the CD via R2

! increases and the best distance returns to the former value of 2560. However,

! FD will now keep its value of 2048 as this distance has become the new

! historical minimum of the distance towards 2001:DB8:CC1E::/64. At the end

! of this example, the delays on network interfaces have completely returned

! back to the original state from Figure 8-5; yet, because of its properties,

! the FD has changed from 2560 to 2048 although the CD of the current best

! route via FE80::2 is back to the original value of 2560.

R1# show ipv6 eigrp topology all-links

! Legend removed for brevity

P 2001:DB8:CC1E::/64, 1 successors, FD is 2048, serno 9

via FE80::2 (2560/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

via FE80::4 (4096/3072), Serial1/2

ptg13046388

Chapter 8: EIGRP 389

R1# show ipv6 route eigrp

! Legend removed for brevity

D 2001:DB8:CC1E::/64 [90/2560]

via FE80::2, Serial1/0

Note how, in several cases in Example 8-10 , FD was different from the actual lowest CD

that was also visible in the show ipv6 route output. When advertising its distance to the

2001:DB8:CC1E::/64, R1 would advertise its actual distance instead of FD. Once again,

FD is an internal value that is used by EIGRP to select loop-free paths, but its value is

never advertised in any EIGRP packets.

To explain the motivation behind the FD as previously described, consider the scenario

in Figure 8-6 . This topology is similar to Figure 8-5 , with a change: R4 is only connected

to R1 and is not connected to the LAN. The delay on the R1–R4 link is configured to 2.

As a result, R4 points to R1 to reach 2001:DB8:CC1E::/64, and R4’s total metric to this

network will be (2+9+1) × 256 = 12 × 256 = 3072, identical to the original situation in

F i g u r e 8 - 5 .

2001:DB8:CC1E::/64

Delay = 1

Delay = 9

Delay = 2

Delay = 15

Delay = 5

Figure 8-6 Modified Sample Network Operating EIGRP in IPv6 Mode

Assume now that the R1–R2 link suddenly fails. At the exact moment of the failure, R1

and R2 are the only routers that are aware of the topology change. Neither R3 nor R4

knows about the change yet. If R1 immediately proceeded to choose a replacement next

hop toward the destination, it would choose R4 because with R2 unreachable, R4 appar-

ently provides the next least-cost path with the metric of (2+12) × 256 = 3584. However,

this would cause a routing loop because at the moment the R1–R2 link failed and R1

tried to find another next hop, R4 was not yet updated about the topology change, and

therefore its RD of 12 × 256 = 3072 was outdated. Trusting it blindly would be a mistake.

This is where FD comes in. With the FD set to 2560, R1 knows that at some point in the

past, it had a workable, loop-free path to the destination with the distance as low as 2560.

Naturally, by virtue of all links in the topology having positive (that is, non-negative and

nonzero) costs, neighbors that provided this path must have been even closer, meaning

that their RDs must have been strictly less than 2560. At that point in the past, any neigh-

bor whose distance was less than 2560 was safe to be used by R1, as that neighbor would

never forward packets back to R1, neither directly nor over any chain of multiple routers

Key

Topic

ptg13046388

390 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

looping back to R1: If the neighbor’s own distance was less than R1’s, why would it for-

ward packets over a path whose distance was higher than its own?

Now if R1’s actual distance increases over time, it is one more reason for these neighbors

with their distances less than 2560 to avoid using R1 to reach the network because, just

as before, why should they forward packets through R1 whose distance was higher than

their own and even grew further? Note that in this logic, the neighbors do not even need

to know that R1’s distance has increased from 2560 to a higher value, so to make this fea-

sibility check , it is not even important they have up-to-date information from R1—which

is exactly what we need!

This idea forms the basis of Feasible Distance and the related Feasibility Condition

check. FD, being the record of the smallest known distance to a destination since the last

time the route went Passive, is a value that describes the metric of the best path to the

destination this router has known. Any neighbor whose current distance is lower would

never pass packets back to this router, and it would even less consider passing packets

back if it knew that this router’s distance has increased for whatever reasons. Therefore,

any neighbor that is closer to the destination than this router has been since the last

time the destination became Passive cannot form a routing loop , or more technically,

any neighbor whose Reported Distance is strictly smaller than this router’s Feasible

Distance cannot form a routing loop . Both these formulations constitute the Feasibility

Condition, one of several sufficient conditions for loop freedom that were proposed and

mathematically proven by Dr. J. J. Garcia-Luna-Aceves in the late 1980s and early 1990s.

This particular Feasibility Condition, stating that every neighbor satisfying the inequality

RD < FD provides a loop-free path, is also sometimes called the Source Node Condition.

Note that the FC is a sufficient condition, not a necessary condition for loop freedom;

this means that every neighbor satisfying the FC provides a loop-free path. However, not

every loop-free path satisfies the FC. Compare Figures 8-5 and 8-6 to see why this is the

case. In both figures, R4’s distance to the destination 2001:DB8:CC1E::/64 as reported to

R1 is 12 × 256 = 3072. In Figure 8-5 , R4 is directly connected to the destination network

and forwards packets to this network directly. If R4 received packets from R1 toward the

LAN, it would forward them onto the LAN without causing any routing loop. In Figure

8-6 , however, R4 uses R1 as its next hop toward the LAN network, and if R1 tried to

route packets to the LAN through R4, it would receive them back in a routing loop. In

other words, if a neighbor’s RD is equal to or higher than R1’s FD, it might ( Figure 8-6 ) or

might not ( Figure 8-5 ) cause a routing loop; in the distance-vector approach, R1 has no

further information to verify that. However, it is certain and guaranteed that if a neigh-

bor’s RD is lower than R1’s FD (that is, if the neighbor is closer to the destination than R1

has ever been since the last time the destination became Passive), it will not cause a rout-

ing loop. The FC basically splits all neighbors of a router into two groups: neighbors that

are guaranteed to provide a loop-free path and all other neighbors about which the router

cannot be sure.

Key

Topic

ptg13046388

Chapter 8: EIGRP 391

For a destination, all neighbors that pass the FC and thus are safe to use as next hops

are called Feasible Successors . In other words, a Feasible Successor is a neighbor that is

guaranteed to provide a loop-free path toward a destination; Feasible Successors are iden-

tified by passing the FC check. Among these Feasible Successors, one or more provide

the least CD to the destination; these are called Successors . Both Feasible Successors

and Successors must meet the FC and thus are guaranteed to provide a loop-free

path; Successors must in addition provide the shortest path available. Technically, each

Successor is also a Feasible Successor because it meets the FC. However, in common

language, the term Feasible Successor is used to denote only the neighbor that provides

a loop-free, yet not the shortest, path available. All Successors and Feasible Successors to

a destination can be seen in the show ip eigrp topology output. Neighbors that do not

meet the FC are not displayed in this output; to display them as well, the show ip eigrp

topology all-links command must be used.

In Figure 8-6 , using the FC will prevent R1 from creating a routing loop through R4 when

the R1–R2 link fails. Because R4’s RD is 3584 while R1’s FD is 2560, R1 assumes that R4

might be using it as its own next hop to the LAN. Therefore, R4 does not pass the FC

check and is not considered a Feasible Successor. In the precise moment of R1–R2 link

failure, when only R1 and R2 are aware of the failure, R1 now knows that even though R4

appears to provide the next least-cost path, it cannot be trusted. This prevents R1 from

pointing toward R4, creating a temporary routing loop.

An EIGRP router is always allowed to use any Successor and Feasible Successor to reach

the destination, without any further coordination with them. Using a Successor will make

the packets flow to the destination through the shortest loop-free path; using a Feasible

Successor will cause the packets to go over a longer but still loop-free path. While the

route is in the Passive state, there is usually no reason to route packets through Feasible

Successors because that would make them flow over suboptimal paths, yet this is exactly

the idea of unequal-cost load balancing that EIGRP is capable of.

Local and Diffusing Computations in EIGRP

After having explained the concepts of Reported Distance, Computed Distance, Feasible

Distance, and Feasibility Condition, describing the handling of topology changes in

EIGRP is relatively straightforward. A topology change occurs whenever the distance

to a network changes or a new neighbor comes online that advertises the network. The

distance change can be detected either through receiving an Update, Query, Reply, SIA-

Query, or SIA-Reply packet from a neighbor that carries updated metric information

about the network, or because a local interface metric has changed. Also, the event of

a neighbor going down is processed by setting the CD/RD of all networks reachable

through that neighbor to infinity. Whatever the reason for the topology change is, the

router can immediately verify in its topology table whether the new shortest path is

Key

Topic

ptg13046388

392 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

provided by a router passing the FC check, that is, a Feasible Successor. If it is, the router

performs the following steps:

1. The Feasible Successor providing the least CD is made the new Successor.

2. If the CD over the new Successor is less than the current FD, the FD will be updated

to the new CD; otherwise it stays at its current value.

3. The routing table is updated to point toward the new Successor.

4. If the current distance to the destination has changed as a result of switching to a

new Successor, an Update packet is sent to all neighbors, advertising the router’s

updated distance to the destination.

This action is called a local computation in EIGRP, performed solely by using informa-

tion already stored in the router’s topology table, without needing to coordinate with the

neighboring routers. Throughout this procedure, the route has remained in the Passive

state.

If, however, after detecting a topology change, the router finds out that the new short-

est path is provided by a neighbor that is not a Feasible Successor, the router cannot use

such a neighbor right away because it could cause a routing loop. Therefore, the router

commences a diffusing computation by performing the following steps:

1. The entry in the routing table, still pointing to the current unchanged Successor, is

locked: It must not be removed nor its next hop changed until the diffusing compu-

tation is finished and the route has been moved to the Passive state again.

2. The FD is set to the current (possibly increased) CD through the current unchanged

Successor. Also, if this router ever needs to advertise its distance to the network

while in the Active state, it will also use the value of the current CD through the

Successor.

3. The network is put into the Active state and the router sends out a Query packet

to all its neighbors. This Query packet contains the Active network’s prefix and the

router’s current CD toward it.

Each neighbor receiving a Query packet will process it by updating its own topology

table using the distance information advertised in the Query and reevaluating its own

choice of Successors and Feasible Successors. Two possibilities now exist: Either the

neighbor still has its own Feasible Successor or a Successor that provides it with the least-

cost loop-free path, or the information contained in the Query causes the neighbor to

stop considering the path through its current Successor the shortest available and none of

its own neighbors that offer the shortest path are a Feasible Successor.

In the first case, when the neighbor still has a Successor, it will simply send back a Reply

packet, indicating the neighbor’s current distance to the destination (performing its own

local computation if necessary). The neighbor did not become engaged in the diffusing

computation as it did not need to put the network into the Active state itself. Thanks to

this, the diffusing computation was bounded by this neighbor and did not propagate

further.

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 393

In the second case, the neighbor will itself join the diffusing computation, send out its

own Query packet, and advertise its own current distance through its current Successor.

As a result, the wave of Query messages propagates through the part of the network

that is affected by the change. Other parts of the network that are not affected will not

engage in the diffusing computation. This fact explains the somewhat more marketing

than technical claims about EIGRP using “partial, bounded updates”: any EIGRP signal-

ing that by its nature covers only the changed information (partial) and is propagated

only into the affected part of the network (bounded).

After a router becomes Active for a destination and sends out Query packets to its neigh-

bors, it must wait for a Reply packet from each of its neighbors to come back. Until then,

the route remains in the Active state, and its routing table is unchanged. Only after all

Reply packets are received, the router can put the route back to the Passive state, simply

choose the neighbor offering the shortest path available while skipping the FC check,

and reinitialize the FD to the CD offered by the selected neighbor. Now the routing table

entry can finally be updated. If this router itself became Active by receiving a Query,

it now starts sending its own Reply and possibly Update packets, as only now its own

distance to the destination has been determined; otherwise, the router sends out Update

packets only.

It is noteworthy to mention that the crucial information carried in Update, Query, Reply,

SIA-Query, and SIA-Reply packets is always simply the sender’s current distance to a

particular destination, informing its receiver about the packet originator’s distance to the

destination and optionally requesting a response (in the case of Query and SIA-Query

packets). Whether any of these packets causes its receiver to go Active for a destination

depends exclusively on how the information in the message impacts the receiver’s choice

of the shortest path and FC check performed over its neighbor offering the shortest path.

It is a widespread belief about EIGRP that if the current Successor fails, a Feasible

Successor (if one exists) will always be promoted to the Successor role. This statement is

not entirely correct, however. Consider again the topology in Figure 8-5 in the state we

have left it at the end of Example 8-10 . On R1, the FD of the LAN remained at 2048, and

the best path currently goes through R2, the Successor, its CD being 2560. R3 is identi-

fied as the Feasible Successor as its RD is 1280, less than the FD (2048), and the CD

through R3 is 5120. Note that R4 actually provides a better path than R3 with the CD of

4096, but because of R4’s RD of 3072, R4 does not pass the FC and R1 does not con-

sider it to be a Feasible Successor.

If the link between R1 and R2 fails, the common belief is that R1 would first check

whether it has a Feasible Successor available—and it does indeed; it is R3—so it would

be promoted to the Successor role and R1 would install a route to the LAN through R3.

This would not be correct, however. If R1 was simply satisfied with R3, it would be using

a workable but not necessarily the shortest available path, and would never explore the

possibility of using a shorter path. What really happens in EIGRP is the following:

■ Whenever EIGRP detects a topology change, it first records the change into the

topology table and updates the RD and CD of the neighbor that advertised the

change (in case of a received EIGRP message) or was influenced by it (in case of a

link metric change).

Key

Topic

ptg13046388

394 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ From among all neighbors that advertise the network, EIGRP identifies the one that

provides the least CD, taking into account the updated CDs. Note that the FC is not

invoked at this step.

■ Only after identifying the neighbor offering the least CD, EIGRP verifies whether

this neighbor meets the FC and is therefore a Feasible Successor. If it is, EIGRP will

promote it to the Successor and start using it right away. If, however, that neighbor

does not meet the FC, EIGRP will put the route into the Active state and send out

Queries, asking its neighbors to assist in locating the best route.

In other words, EIGRP—just like any other routing protocol—always tries to choose the

shortest path toward a destination, but before using it, EIGRP verifies whether it meets

the FC to be loop-free. If it does, EIGRP will use it. If it does not, EIGRP puts the desti-

nation into the Active state.

Consider Example 8-11 , which explains how the network in Figure 8-5 would react if the

R1–R2 link was shut down. Read the comments in the example carefully.

Example 8-11 Use of a Neighbor Failing the FC and Providing the Next Least Distance

! The IPv6 routing table shows the LAN network routed via R2

R1# show ipv6 route eigrp

! Legend removed for brevity

D 2001:DB8:CC1E::/64 [90/2560]

via FE80::2, Serial1/0

! In the EIGRP topology table, R2 is identified as the Successor, and R3

! is identified as the Feasible Successor. R4 is not displayed here, as

! it does not meet the FC. Note the FD remained at 2048 after the changes

! performed in the Example 8-10 ; the delays on links have nonetheless been

! configured back to the values shown in Figure 8-5.

R1# show ipv6 eigrp topology

! Legend removed for brevity

P 2001:DB8:CC1E::/64, 1 successors, FD is 2048

via FE80::2 (2560/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

! Using the all-links keyword, R4 can be displayed as well but it is clear

! from the (CD/RD) values that R4's RD of 3072 is not strictly less than

! the FD of 2048. R2 and R3 pass this check, however.

R1# show ipv6 eigrp topology all-links

! Legend removed for brevity

P 2001:DB8:CC1E::/64, 1 successors, FD is 2048, serno 9

via FE80::2 (2560/256), Serial1/0

via FE80::3 (5120/1280), Serial1/1

via FE80::4 (4096/3072), Serial1/2

ptg13046388

Chapter 8: EIGRP 395

! The debug eigrp fsm is used to display EIGRP's DUAL FSM actions.

R1# debug eigrp fsm

EIGRP FSM Events/Actions debugging is on

R1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)# int s1/0

R1(config-if)# shutdown

*Mar 1 12:20:35.380: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 1: Neighbor FE80::2

(Serial1/0) is down: interface down

*Mar 1 12:20:35.384: DUAL: linkdown: start - FE80::2 via Serial1/0

! After the Serial1/0 interface is shut down, note that the loss of R2

! is represented in the topology table as if R2 advertised an infinite metric.

! R1 evaluates all neighbor entries for the destination in the topology table

! and determines that while the minimum available distance (Dmin) is 4096,

! obviously via R4, this router does not meet the FC – that is the reason

! of the "not found" comment in the debug output; the "not found" does not

! really relate to the FE80::4 line on which it is printed out (the debug

! output is just wrapped confusingly).

*Mar 1 12:20:35.384: DUAL: Destination 2001:DB8:CC1E::/64

*Mar 1 12:20:35.384: DUAL: Find FS for dest 2001:DB8:CC1E::/64. FD is 2048, RD is

2560

*Mar 1 12:20:35.384: DUAL: FE80::2 metric 4294967295/4294967295

*Mar 1 12:20:35.384: DUAL: FE80::3 metric 5120/1280

*Mar 1 12:20:35.384: DUAL: FE80::4 metric 4096/3072 not found Dmin is 4096

*Mar 1 12:20:35.384: DUAL: Peer total 2 stub 0 template 2

! Because the neighbor providing the least cost path does not meet the FC,

! R1 enters the Active state, sends out Queries, and expects Replies.

*Mar 1 12:20:35.384: DUAL: Dest 2001:DB8:CC1E::/64 entering active state.

*Mar 1 12:20:35.384: DUAL: Set reply-status table. Count is 2.

*Mar 1 12:20:35.384: DUAL: Not doing split horizon

*Mar 1 12:20:35.384: DUAL: linkdown: finish

! R3 responds; it is not influenced by the failure of the R1/R2 link, so

! the CD/RD are the same as already stored.

*Mar 1 12:20:35.440: DUAL: rcvreply: 2001:DB8:CC1E::/64 via FE80::3 metric

5120/1280

*Mar 1 12:20:35.440: DUAL: reply count is 2

*Mar 1 12:20:35.440: DUAL: Clearing handle 2, count now 1

ptg13046388

396 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! R4 responds; it is not influenced by the failure of the R1/R2 link, so

! the CD/RD are the same as already stored.

*Mar 1 12:20:35.440: DUAL: rcvreply: 2001:DB8:CC1E::/64 via FE80::4 metric

4096/3072

*Mar 1 12:20:35.440: DUAL: reply count is 1

*Mar 1 12:20:35.440: DUAL: Clearing handle 1, count now 0

*Mar 1 12:20:35.440: DUAL: Freeing reply status table

! Now that all replies have been received, R1 is free to reset the FD

! and choose any neighbor that provides the least CD. Obviously, it is R4.

! The "RT installed" shows the route and the next hop that are installed

! into the routing table.

*Mar 1 12:20:35.444: DUAL: Find FS for dest 2001:DB8:CC1E::/64. FD is 4294967295,

RD is 4294967295 found

*Mar 1 12:20:35.444: DUAL: Removing dest 2001:DB8:CC1E::/64, nexthop FE80::2,

infosource FE80::2

*Mar 1 12:20:35.448: DUAL: RT installed 2001:DB8:CC1E::/64 via FE80::4

*Mar 1 12:20:35.448: DUAL: Send update about 2001:DB8:CC1E::/64. Reason: metric

chg

*Mar 1 12:20:35.448: DUAL: Send update about 2001:DB8:CC1E::/64. Reason: new if

*Mar 1 12:20:37.308: %LINK-5-CHANGED: Interface Serial1/0, changed state to

administratively down

*Mar 1 12:20:38.308: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0,

changed state to down

! The outputs below now show that the FD has been reset and updated to the new

! least CD available – 4096 via R4. The route via R4 is also installed into

! the IPv6 routing table. Note that R3 was, and has remained, a Feasible Successor

! without being ever promoted to the Successor role.

R1(config-if)# do show ipv6 eigrp topology

! Legend removed for brevity

P 2001:DB8:CC1E::/64, 1 successors, FD is 4096

via FE80::4 (4096/3072), Serial1/2

via FE80::3 (5120/1280), Serial1/1

R1(config-if)# do show ipv6 route eigrp

! Legend removed for brevity

D 2001:DB8:CC1E::/64 [90/4096]

via FE80::4, Serial1/2

ptg13046388

Chapter 8: EIGRP 397

DUAL FSM

The mechanisms described so far—the concept of Feasible Distance, Successors and

Feasible Successors, local computations, and diffusing computations that grow by send-

ing Queries and shrink by receiving Replies—allow a router to efficiently compute a new

path to a destination, assuming that over the entire duration of the diffusing computa-

tion, no other topological changes take place. However, this is a very strong assumption.

Therefore, on top of all these mechanisms, EIGRP uses a control mechanism called the

Diffusing Update Algorithm, or DUAL, that takes care of handling multiple topology

changes occurring during a single diffusing computation. Figure 8-7 shows the DUAL

Finite State Machine (FSM).

FC Satisfied

Input Event Other Than

Last Reply or Query from S

Last Reply, FC Not

Satisfied with FD

Last Reply, FC

Satisfied with Current FD

Query from Successor,

FC Not Satisfied

Last Reply, Set FD =

∞

Last Reply, Set FD =

∞

Last Reply, FC Satisfied

with Current FD

Input Event Other han Query

from Successor, FC not Satisfied

Input Event Other Than Query

from Successor, FC Not Satisfied

Increase in D

Input Event Other Than Last Reply,

Increase in D or Query from S

Input Event Other

Than Last Reply

Input Event Other

Than Last Reply or Increase in D

Query from S

Last Reply, FC Not

Satisfied with FD

Increase in D

Figure 8-7 Diffusing Update Algorithm Finite State Machine

In Figure 8-7 , the acronyms D, S, FC, and FD stand for Distance, Successor, Feasible

Condition, and Feasible Distance, respectively. The DUAL FSM has one passive and four

active states denoted as P and A

0 through A

3 . These Active states also have names by

which we will refer to them later in the section, and the names refer to the origin of the

diffusing computation—which router appears to have started it:

■ A 0 : Local Origin with Distance Increase

■ A 1 : Local Origin

■ A 2 : Multiple Origins

■ A 3 : Successor Origin

ptg13046388

398 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Comments by the arrows explain events that the DUAL FSM reacts to, and the arrows

describe the state transitions caused by these events. Explaining the DUAL FSM in depth

is beyond the scope of this book; however, its basic behavior can be summarized in these

rules (all rules always focusing on a single particular destination at a time):

■ Unless a change in distance occurs such that the neighbor providing the least

Computed Distance fails to meet the Feasibility Condition, the route remains

passive.

■ If a Query is received from the current Successor and, after processing the distance

indicated in this Query, the neighbor that provides the least Computed Distance

fails to meet the Feasibility Condition, the route will enter the A

3 active state, also

called the Successor Origin Active State. The router will send out Queries and wait

for Replies. If no further distance increase is detected while waiting for the Replies,

the last Reply allows the router to transition back to the Passive state, reinitialize

the Feasible Distance, and choose any neighbor that provides the least Computed

Distance as the new Successor.

■ If a distance change caused by other means than a Query from a Successor is

detected (this can be caused by receiving an Update, changing an interface metric,

or losing a neighbor) and after processing the change, the neighbor that provides

the least Computed Distance fails to meet the Feasibility Condition, the route will

enter the A

1 active state, also called the Local Origin Active State. The router will

send out Queries and wait for Replies. If no further distance increase or Query from

the current Successor is received while waiting for the Replies, the last Reply allows

the router to transition back to the Passive state, reinitialize the Feasible Distance,

and choose any neighbor that provides the least Computed Distance as the new

Successor.

■ If during the stay in the A

3 (Successor Origin) or A

1 (Local Origin) active states,

another distance increase caused by other means than the Successor’s Query is

detected, another topology change during the diffusing computation has occurred.

Because the router cannot advertise this updated distance while it is in the Active

state, other routers might not be informed about it and their Replies might not

take this new increased distance into account. Therefore, extra scrutiny is applied

to the received Replies instead of simply choosing the neighbor that provides the

least Computed Distance. This is accomplished first by changing the state from A

(Successor Origin) to A

2 (called Multiple Origins ), or from A

1 (Local Origin) to

0 (no official name; we will call it Local Origin with Distance Increase ) states.

In A

2 or A

0 states, the router waits to receive all remaining Replies. When the last

Reply arrives, the router will first check whether the neighbor providing the least

Computed Distance passes the Feasible Condition check using the Feasibility

Distance value set when the route entered the Active state (recall that it was set to

the increased distance through the current Successor at the moment of transition-

ing to the Active state). This extra check essentially mimics a situation in which the

router is actually using the path through the current Successor and has just detected

the distance increase, so it uses the current value of Feasibility Distance to verify

whether the neighbor providing the least Computed Distance passes the Feasibility

ptg13046388

Chapter 8: EIGRP 399

Condition. If it does, the route becomes Passive again, and the neighbor is chosen

as the Successor. If it does not, however, the route will return from A

0 (Local Origin

with Distance Increase) to A

1 (Local Origin) or from A

2 (Multiple Origins) to A

(Successor Origin) and the router will commence another diffusing computation by

again sending a Query.

■ If during the stay in A

1 (Local Origin) or A

0 (Local Origin with Distance Increase)

active states a Query from the Successor is received, another topology change dur-

ing the diffusing computation has occurred. Because the router cannot advertise this

updated distance while it is in the Active state, other routers might not be informed

about it and their Replies might not take this new increased distance into account.

Therefore, extra scrutiny is applied to the received Replies. This is accomplished by

changing the state to A

2 (Multiple Origins) and then proceeding from that state just

like in the previous case.

The number of the Active state, that is, 0 to 3, is stored in a so-called query origin flag

that is visible in the EIGRP topology table during the Active state. Consult Example 8-12

for more information. Routers in this example are running IPv4 EIGRP and have again

been configured to take only the Delay metric component into account. The routers in

this topology have been daisy-chained (RouterX is connected to RouterY; RouterY is con-

nected to RouterZ and not shown in the example). To elicit long-lasting Active states, the

Hold timers on interfaces have been configured to 10000 seconds and the timers active-

time disabled command was used on all routers to allow the diffusing computation to

run indefinitely. In addition, an access list dropping all inbound packets was placed on the

RouterY interface toward RouterX before causing a topology change; this ACL prevented

Queries and Replies from being exchanged between RouterX and RouterY, causing the

diffusing computation to stall. Topology changes were caused by shutting down loop-

back interfaces whose networks were advertised in EIGRP, and optionally increasing the

Delay metrics on interfaces during the diffusing computation.

Example 8-12 Active States of an EIGRP Route

! In this example, a local loopback interface has been shut down, prompting

! the router to start a diffusing computation. The following outputs show

! that the origin of the query is the local router. In the output of

! show ip eigrp topology active command, the query-origin is shown as

! "Local origin", and the detailed output on the 10.255.255.1/32 entry

! claims the Query origin flag to be 1, hinting at the A

1 state.

RouterX(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.255.255.1/32, 1 successors, FD is Inaccessible, Q

1 replies, active never, query-origin: Local origin

via Connected (Infinity/Infinity), Loopback0

ptg13046388

400 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Remaining replies:

via 10.0.12.2, r, Serial1/0

RouterX(config-if)# do show ip eigrp topology 10.255.255.1/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.1/32

State is Active, Query origin flag is 1, 1 Successor(s), FD is 4294967295

Waiting for 1 replies

Routing Descriptor Blocks:

0.0.0.0 (Loopback0), from Connected, Send flag is 0x0

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 0 Kbit

Total delay is 167772159 microseconds

Reliability is 0/255

Load is 0/255

Minimum MTU is 1514

Hop count is 0

! In the next output, an entry is shown for which the router received a Query

! from its Successor. The query-origin is indicated as "Successor Origin",

! and the Query origin flag having the value of 3, hinting at the A

3 state.

RouterY(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.255.255.3/32, 1 successors, FD is Inaccessible, Q

1 replies, active never, query-origin: Successor Origin

via 10.0.23.3 (Infinity/Infinity), Serial1/0

Remaining replies:

via 10.0.12.1, r, Serial1/1

RouterY(config-if)# do show ip eigrp topology 10.255.255.3/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.3/32

State is Active, Query origin flag is 3, 1 Successor(s), FD is 4294967295

Waiting for 1 replies

Routing Descriptor Blocks:

10.0.23.3 (Serial1/0), from 10.0.23.3, Send flag is 0x0

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 0 Kbit

Total delay is 167772159 microseconds

Reliability is 0/255

Load is 0/255

ptg13046388

Chapter 8: EIGRP 401

Minimum MTU is 1514

Hop count is 0

! The following output shows a router that received an Update from its Successor

! that forced it to enter the A1 state, and detecting another distance increase

! during the diffusing computation, moving it to the A0 state. Note that the

! verbose name of the query-origin is displayed as "Clear", having no meaning.

! The numerical value of the Query origin flag is 0, hinting at the A

0 state.

RouterY(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.255.255.4/32, 1 successors, FD is 256256, Q

1 replies, active never, query-origin: Clear

via 10.0.23.3 (512000/256000), Serial1/0

Remaining replies:

via 10.0.12.1, r, Serial1/1

RouterY(config-if)# do show ip eigrp topo 10.255.255.4/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.4/32

State is Active, Query origin flag is 0, 1 Successor(s), FD is 256256

Waiting for 1 replies

Routing Descriptor Blocks:

10.0.23.3 (Serial1/0), from 10.0.23.3, Send flag is 0x0

Composite metric is (512000/256000), Route is Internal

Vector metric:

Minimum bandwidth is 1000 Kbit

Total delay is 20000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

! Finally, the next output shows a router that, during the diffusing computation,

! detected a distance increase and received a Query from its Successor. Note

! the Query origin being displayed as "Multiple Origins" and the value of the

! Query origin flag is 2, hinting at the A

2 state.

RouterY(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

ptg13046388

402 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

A 10.255.255.5/32, 1 successors, FD is 256256, Q

1 replies, active never, query-origin: Multiple Origins

via 10.0.23.3 (Infinity/Infinity), Serial1/0

Remaining replies:

via 10.0.12.1, r, Serial1/1

RouterY(config-if)# do show ip eigrp topology 10.255.255.5/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.5/32

State is Active, Query origin flag is 2, 1 Successor(s), FD is 256256

Waiting for 1 replies

Routing Descriptor Blocks:

10.0.23.3 (Serial1/0), from 10.0.23.3, Send flag is 0x0

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 0 Kbit

Total delay is 167772159 microseconds

Reliability is 0/255

Load is 0/255

Minimum MTU is 1514

Hop count is 0

Stuck-In-Active State

If a router joins the diffusing computation for a particular destination by putting it into

the Active state and sending out Queries, it must first wait for all its neighbors to send

back a Reply before it can conclude the diffusing computation itself, make a new best-

path selection, and start sending its own Replies. Consequently, if a router sends a Query

and that Query causes at least one of its directly connected neighbors to also become

Active, the router will now become dependent not only on its Active neighbor but also

on that neighbor’s own neighbors. If they fail to respond, the router’s neighbor cannot

conclude the diffusing computation and send a final Reply back to the router, meaning

that the router cannot conclude the diffusing computation either. By simple extension, a

router in the Active state is dependent on the entire chained sequence of routers that have

become Active as a result of this router’s Query. Any single misbehaving router up this

chain that is unable to send a Reply for whatever reason will cause all the routers depend-

ing on it to stall, possibly never being allowed to conclude the diffusing computation and

converge.

There are several reasons why the EIGRP neighbor router(s) might not respond to the

Query. Common reasons for this include the following:

■ The neighbor router’s CPU is overloaded and the router either cannot respond in

time or is even unable to process all incoming packets including the EIGRP packets.

■ Quality issues on the link are causing packets to be lost.

■ Low-bandwidth links are congested and packets are being delayed or dropped.

Key

Topic

ptg13046388

Chapter 8: EIGRP 403

■ The network topology is excessively large or complex, either requiring the Query to

propagate to a significant depth or causing an inordinate number of prefixes to be

impacted by a single link or node failure.

This chained dependency of routers in the Active state is somewhat of EIGRP’s Achilles

heel. Therefore, EIGRP implements multiple mechanisms to cope with this situation.

When a Query is first sent out by a router, a timer called the Active timer for the route is

started. The default value of the Active timers is 3 minutes and it can be set to any value

between 1 and 65535 minutes or set to infinity using the timers active-time command in

the router eigrp context. If all expected Replies are not received before the Active timer

expires, the route in question will be designated as Stuck-In-Active (SIA). The neighbor

or neighbors that did not reply will be removed from the neighbor table and their adja-

cencies torn down, and the diffusing computation will consider these neighbors to have

responded with an infinite metric.

SIA states in EIGRP are extremely unpleasant and generally difficult to diagnose. In the

worst case, an unresponsive router can prevent a significant portion of the network from

ever converging in the time allotted by the Active timer. In addition, dropping an adja-

cency to a neighbor as a consequence of the SIA state can introduce further instability

to the network, as all networks learned from that neighbor will be flushed and possibly

learned again after the neighbor comes back up within the Hello interval time.

The difficulty in solving the SIA states in first EIGRP implementations was aggravated by

the fact that if a neighbor did not send a Reply until the Active timer expired, the router

would drop the adjacency toward that neighbor even though the neighbor itself was not

the root cause of the SIA. Clearly, doing so unlocked the SIA state, but at the same time,

it penalized a router that might have been innocent and provided no hint as to where the

real cause of the problem was located. To at least partially contain and localize the true

place where a difficulty in the Query/Reply message exchange causes the diffusing com-

putation to stall, more recent EIGRP implementations use the SIA-Query and SIA-Reply

messages.

If a neighbor does not respond to a Query message with its Reply within half of the

Active timer time, the router will send the neighbor a SIA-Query message. The SIA-

Query stands for a message saying “Are you still working on my Query?” If the neigh-

bor is able to receive and process this SIA-Query, it will immediately respond with the

SIA-Reply message. The contents of the SIA-Reply can either say “Yes, I still expect my

own neighbors to send me the Replies I’ve asked them for” or “No, the computation

is finished; this is my current metric to the destination.” In any case, the SIA-Reply is

sent immediately as a response to the SIA-Query message; there is nothing to wait for.

Receiving an SIA-Reply allows the Active timer to be reset, giving the diffusing computa-

tion an additional time to complete. At most three SIA-Queries can be sent, each after

half of the Active timer. If the diffusing computation is not finished by the time the third

SIA-Query was replied to by an SIA-Reply and the half of the Active timer expired again,

the adjacency to the neighbor will be dropped. The same will happen if an SIA-Query

is not responded to by an SIA-Reply within the next half of the Active timer. With the

default setting of the Active timer to 180 seconds, three consecutive SIA-Query packets

Key

Topic

ptg13046388

404 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

allow extending the diffusing computation to a maximum of 4 × 90 = 360 seconds (90

seconds to the first SIA-Query, plus each SIA-Query buying another 90 seconds).

As a result, if two neighbors can communicate without issues, an SIA-Query will be

responded to by an SIA-Reply almost instantly. If, however, two routers have issues

talking to each other, it is also probably the place where the normal Query and Reply

messages are lost, and there is a good chance of the SIA-Query also going unanswered.

Hence, the adjacency will be dropped between the routers that are likely to be the cause

of the SIA state.

Example 8-13 shows an SIA situation. Similar to Example 8-12 , three routers in a row,

RouterX, RouterY, and RouterZ (not shown in the topology) are connected, running

IPv4 EIGRP. The Active timer is at its default setting of 3 minutes. The Hold interval is

increased to 10000 seconds on each interface in the topology, and an ACL dropping all

packets is placed in the inbound direction on the RouterY interface toward RouterZ. On

RouterX, the local loopback is shut down. RouterX sends a Query to RouterY, which in

turn sends a Query to RouterZ. However, because of the ACL, the Reply from RouterZ is

not received by RouterY, leading to an SIA state. The following example documents the

EIGRP’s handling of the issue. Read the comments in the example carefully.

Example 8-13 Handling of Stuck-In-Active State

! Right after the loopback is shut down on RouterX, it sends out a Query to

! its neighbor RouterY. Note the origin of the Query is Local.

! The lowercase 'r' flag shown in the "Remaining replies" section indicates

! a Reply packet is expected from 10.0.12.2 (RouterY) but has not arrived yet.

! Until a SIA-Query has been sent, the output of show ip eigrp topology and

! show ip eigrp topology active is entirely identical, with the active keyword

! automatically limiting output just to active entries.

RouterX(config-if)# do show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

! Lines omitted for brevity

A 10.255.255.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:00:10, query-origin: Local origin

Remaining replies:

via 10.0.12.2, r, Serial1/0

RouterX(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

ptg13046388

Chapter 8: EIGRP 405

A 10.255.255.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:00:10, query-origin: Local origin

via Connected (Infinity/Infinity), Loopback0

Remaining replies:

via 10.0.12.2, r, Serial1/0

R1(config-if)# do show ip eigrp topology 10.255.255.1/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.1/32

State is Active, Query origin flag is 1, 1 Successor(s), FD is 4294967295

Waiting for 1 replies

Routing Descriptor Blocks:

0.0.0.0 (Loopback0), from Connected, Send flag is 0x0

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 0 Kbit

Total delay is 167772159 microseconds

Reliability is 0/255

Load is 0/255

Minimum MTU is 1514

Hop count is 0

! On RouterY, the route is reported with the Query origin of Successor Origin.

! Also here notice the 'r' flag in the "Remaining replies" section, indicating

! a Reply packet is expected from 10.0.23.3 (RouterZ) but has not arrived yet.

! This Reply will never arrive due to the ACL between RouterY and RouterZ.

! The 'Q' flag in the entry heading indicates that a Query has been sent for

! this route but it has not been acknowledged yet (also due to the ACL).

RouterY(config-if)# do show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

! Lines omitted for brevity

A 10.255.255.1/32, 1 successors, FD is Inaccessible, Q

1 replies, active 00:00:16, query-origin: Successor Origin

Remaining replies:

via 10.0.23.3, r, Serial1/0

RouterY(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

ptg13046388

406 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

A 10.255.255.1/32, 1 successors, FD is Inaccessible, Q

1 replies, active 00:00:16, query-origin: Successor Origin

via 10.0.12.1 (Infinity/Infinity), Serial1/1

Remaining replies:

via 10.0.23.3, r, Serial1/0

RouterY(config-if)# do show ip eigrp topology 10.255.255.1/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.1/32

State is Active, Query origin flag is 3, 1 Successor(s), FD is 4294967295

Waiting for 1 replies

Routing Descriptor Blocks:

10.0.12.1 (Serial1/1), from 10.0.12.1, Send flag is 0x0

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 0 Kbit

Total delay is 167772159 microseconds

Reliability is 0/255

Load is 0/255

Minimum MTU is 1514

Hop count is 0

! After the half of the Active timer elapses, both RouterX and RouterY will

! try to find out whether their neighbors that have not responded yet are

! still working on the Query. To accomplish this, both RouterX and RouterY

! will send a SIA-Query to their unresponsive neighbors.

! The "retries(1)" on RouterX shows that it has sent one SIA-Query to

! RouterY and has received a SIA-Reply response. This is visible in a number

! of places: a topology table entry of Infinity/Infinity via 10.0.12.2

! has been added in the show ip eigrp active output as a result of receiving

! the SIA-Reply, and this entry has an 'r' flag indicating that a regular

! Reply is still being expected but has no 's' flag that would indicate

! that no SIA-Reply was received. Compare this output later to the output of

! RouterY below.

RouterX(config-if)# do show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

! Lines omitted for brevity

A 10.255.255.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:01:41, query-origin: Local origin, retries(1)

ptg13046388

Chapter 8: EIGRP 407

Remaining replies:

via 10.0.12.2, r, Serial1/0

RouterX(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.255.255.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:01:41, query-origin: Local origin, retries(1)

via Connected (Infinity/Infinity), Loopback0

via 10.0.12.2 (Infinity/Infinity), r, Serial1/0, serno 20

RouterX(config-if)# do show ip eigrp topology 10.255.255.1/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.1/32

State is Active, Query origin flag is 1, 1 Successor(s), FD is 4294967295

Waiting for 1 replies

Routing Descriptor Blocks:

0.0.0.0 (Loopback0), from Connected, Send flag is 0x0

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 0 Kbit

Total delay is 167772159 microseconds

Reliability is 0/255

Load is 0/255

Minimum MTU is 1514

Hop count is 0

10.0.12.2 (Serial1/0), from 10.0.12.2, Send flag is 0x0, outstanding reply

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 1000 Kbit

Total delay is 167772159 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 0

! On RouterY, it is also visible that a SIA-Query has been sent to RouterZ.

! However, this SIA-Query has not been responded to. In the basic

! show ip eigrp topology command output, the RouterZ (10.0.23.3) is marked

! as SIA-Stuck. In the show ip eigrp topology active output, the topology

! table entry for RouterZ (10.0.23.3) shows that not only a Reply is still

! expected (the 'r' flag) but also that a SIA-Reply is expected (the 's' flag)

! but has not arrived yet. The 'q' flag indicates that a SIA-Query was sent

! to the neighbor but no ACK was received yet (because of the ACL).

ptg13046388

408 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! Eventually, after next half Active timer interval with no SIA-Reply arriving,

! RouterY decides to drop the adjacency to RouterZ.

RouterY(config-if)# do show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

! Lines omitted for brevity

A 10.255.255.1/32, 1 successors, FD is Inaccessible, Qqr

1 replies, active 00:01:46, query-origin: Successor Origin, retries(1)

Remaining replies:

via 10.0.23.3, r, Serial1/0

SIA-Stuck: 1 peers

Peers:

via 10.0.23.3, s, Serial1/0

RouterY(config-if)# do show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.255.255.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.255.255.1/32, 1 successors, FD is Inaccessible, Qqr

1 replies, active 00:01:47, query-origin: Successor Origin, retries(1)

via 10.0.12.1 (Infinity/Infinity), Serial1/1, serno 24

via 10.0.23.3 (Infinity/Infinity), rs, q, Serial1/0, serno 23, anchored

RouterY(config-if)# do show ip eigrp topology 10.255.255.1/32

IP-EIGRP (AS 1): Topology entry for 10.255.255.1/32

State is Active, Query origin flag is 3, 1 Successor(s), FD is 4294967295

Waiting for 1 replies

Routing Descriptor Blocks:

10.0.12.1 (Serial1/1), from 10.0.12.1, Send flag is 0x0

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 0 Kbit

Total delay is 167772159 microseconds

Reliability is 0/255

Load is 0/255

Minimum MTU is 1514

Hop count is 0

10.0.23.3 (Serial1/0), from 10.0.23.3, Send flag is 0x40, outstanding reply

ptg13046388

Chapter 8: EIGRP 409

Composite metric is (4294967295/4294967295), Route is Internal

Vector metric:

Minimum bandwidth is 1000 Kbit

Total delay is 167772159 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 0

R2(config-if)#

*Mar 1 00:14:35.919: %DUAL-3-SIA: Route 10.255.255.1/32 stuck-in-active state in

IP-EIGRP(0) 1. Cleaning up

*Mar 1 00:14:35.927: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.23.3

(Serial1/0) is down: stuck in active

Note that it is possible for a router to receive a Query for a destination while it is Active

for that destination. Assume the topology shown in Figure 8-8 .

Delay = 9

Delay = 1

Delay = 90

Figure 8-8 Active State in a Network with Physical Loops

The situation would be as follows:

■ R1 has a LAN network directly connected.

■ Both R2 and R3 will choose R1 as their next hop toward the LAN, with the

Computed Distance of 10.

■ Neither R2 nor R3 considers itself to be a Feasible Successor for the route toward

the R1 LAN.

■ After the LAN interface on R1 is shut down, R1 will send out a Query for this net-

work to all its neighbors, indicating an infinite distance. Assume, however, that there

are significant delays in the delivery of the Query packet to R1’s neighbors, and R2 is

the first router to receive this Query.

■ Because the Query causes R2 to stop considering R1 as the Successor (it no longer

passes the FC check on R2) and R2 has no Feasible Successors, it will go Active and

send its own Query to R3.

ptg13046388

410 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ Meanwhile, assume that R1’s Query arrived at R3. For R3, the situation is identical.

R3 will also become Active and send a Query to R2, while R2’s Query is already

being transmitted down the R2/R3 link.

■ As a result, R2 and R3 have sent a Query to each other, causing each of them to

receive a Query for a destination while already being in the Active state for that des-

tination.

Some sources state that precisely this situation causes the SIA states, as they assume that

this causes a deadlock. A router in an Active state for a destination has not concluded its

computation yet and cannot send Replies, causing the two or more routers to mutually

wait for themselves and never receive the expected Reply to each other. In reality, this

is a gross misunderstanding. Such situations never cause SIA states to occur. Recall that

when a router enters the Active state for a destination, it sends out a Query indicating its

current distance to the destination after the topology change that triggered the transition

to the Active state. If, during the Active state, the router receives another Query for this

destination, it simply sends back a Reply packet immediately, claiming exactly the same

distance as originally advertised in its own Query packet. In other words, the router sim-

ply restates the same distance it has already advertised in its own Query. Any deadlock

scenario is thereby averted.

With respect to Figure 8-8 , after R2 and R3 send a Query to each other while already in

the Active state, they will simply send a Reply to each other right away with the same

distance they already indicated in their Query packets, that is, infinity. After this, R2 and

R3 receive all Replies they wait for, so they both conclude the diffusing computation,

arrive at the conclusion that no backup path exists, and send a Reply indicating an infi-

nite distance back to R1, terminating the diffusing computation entirely.

To avoid SIA states, proper network design that limits the depth of Query propagation

and the number of prefixes impacted by a link or node failure is crucial. Proper hierarchi-

cal network design coupled with judicious use of passive interfaces, appropriate route fil-

tering and/or summarization, and the EIGRP Stub feature are the key tools that help limit

the probability of an SIA state occurrence to an absolute minimum.

EIGRP Named Mode

Starting with IOS Release 15.0(1)M, an EIGRP process on a router can be configured

using a so-called named mode. The common way of configuring EIGRP processes di -

rectly by their autonomous system numbers separately for IPv4 and IPv6 was retroactive-

ly named the classic mode , sometimes also called the autonomous system mode . The

named mode is the preferred mode of configuring EIGRP after the IOS supports it, and

all commands for new features in EIGRP will be made available in the named mode only.

The classic mode remains to provide backward compatibility with older configurations

but it will not be enhanced with new commands. On a single router, you can run mul-

tiple EIGRP processes, some configured using the classic mode and others configured in

named mode.

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 411

Reasons for EIGRP developers to move to named mode were motivated primarily by the

fact that many new features were added both to IPv4 and IPv6 EIGRP. It was becoming

clear that this called for a better unified, more consistent configuration interface, ulti-

mately provided by the named configuration mode. Readers knowledgeable with Border

Gateway Protocol (BGP) configuration will find the EIGRP named mode actually famil-

iar: a single EIGRP process configuration that consists of one or more address family

sections, each of them specifying details of EIGRP operation for the particular address

family. The unification in the named mode configuration even went as far as providing

commands to configure every aspect of EIGRP operation including former per-interface

commands (timers, authentication, next hop handling, Split Horizon, summarization, and

others) within the context of the named mode. With named mode, the entire EIGRP con-

figuration is located in a single place. If an EIGRP instance is configured in named mode,

all EIGRP-related commands outside the named mode (such as per-interface commands)

will be ignored if configured.

It is very important to stress that the classic and named mode are just two different ways

of how EIGRP is configured. They do not constitute two different versions of EIGRP.

There is no difference to EIGRP packet format or operation, except (of course) the new

configurable features for which the commands are available only in the named mode.

As the named mode is best explained in a real configuration, Example 8-14 contains

a fairly typical named mode configuration for an IPv4/IPv6 EIGRP on a router. Three

building blocks of a named EIGRP configuration can be discerned:

■ Address Family (AF) section: Created using the address-family command, this is a

mandatory section directly inside router eigrp name configuration that specifies the

particular address family for which an EIGRP instance shall be started. The autono-

mous system number is a part of the AF section definition.

■ Per-AF-interface section: This optional section configured by the af-interface com-

mand and located inside a particular AF holds EIGRP settings pertaining to the

specified interface and AF. One per-AF-interface section can be created for each

routed interface or subinterface. In addition, a per-AF-interface section is configured

using af-interface default holds settings that will be applied to all interfaces enabled

for EIGRP. In the case both af-interface default and an interface-specific af-interface

section define the same setting, the interface-specific section is preferred.

■ Per-AF-topology section: This is a section present inside a particular AF, related to

the support of Multi Topology Routing (MTR) in EIGRP. The topology base per-AF-

topology section will always be present in the configuration, even if the IOS has no

support for multiple routing topologies.

Read the comments in the example carefully.

ptg13046388

412 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 8-14 EIGRP Named Mode Configuration

! Named mode is entered for both IPv4 and IPv6 EIGRP using the router eigrp

! command and referring to an arbitrary name.

router eigrp CCIE

! Here, IPv4 EIGRP address family for AS number 1 is enabled.

address-family ipv4 unicast autonomous-system 1

! Within the AF section, a number of per-AF-interface sections is created.

! The af-interface default section contains timer settings that apply to

! all EIGRP-enabled interfaces. The af-interface Loopback0 section defines

! the Lo0 interface to be passive.

af-interface default

hello-interval 1

hold-time 3

exit-af-interface

af-interface Loopback0

passive-interface

exit-af-interface

! The topology base section defines EIGRP behavior related to the base routing

! topology. On routers without Multi Topology Routing support, this will be

! the only per-AF-topology section present. Here, the variance is configured

! and the number of parallel paths to the same destination is increased.

topology base

maximum-paths 6

variance 4

exit-af-topology

! The network commands to enable EIGRP on selected interfaces are placed

! in the AF section itself.

network 10.0.0.1 0.0.0.0

network 10.255.255.1 0.0.0.0

exit-address-family

! In the same EIGRP process, an IPv6 address family for AS number 1 is enabled.

address-family ipv6 unicast autonomous-system 1

ptg13046388

Chapter 8: EIGRP 413

! Somewhat surprisingly, each interface on which IPv6 is enabled is automatically

! added to IPv6 EIGRP. In other words, as soon as the IPv6 EIGRP address family

! is configured, it immediately runs on all IPv6-enabled interfaces.

! The following af-interface default section therefore stops this EIGRP instance

! from automatically running on all IPv6-enabled interfaces. Selected interfaces

! are then added to this instance in their specific af-interface sections.

af-interface default

shutdown

exit-af-interface

af-interface Loopback0

no shutdown

exit-af-interface

af-interface FastEthernet0/0

no shutdown

exit-af-interface

! Here, the Active timer defining the maximum time for a diffusing computation

! is shortened to one minute.

topology base

timers active-time 1

exit-af-topology

exit-address-family

After briefly getting used to the new location of familiar commands, the named mode

configuration comes off as a very natural way of configuring EIGRP and all related set-

tings in a single place.

A few notes about the named mode are in order. The named mode is entered using the

router eigrp name global configuration command, where name is an arbitrary text name,

also called a virtual instance name, of the EIGRP process. Multiple-name EIGRP pro-

cesses can be started on a single router as long as their names are unique. The process

name is not sent in EIGRP messages; it is a locally significant value and is never compared

to process names on other routers.

Each named EIGRP process can hold only a single instance for an address family. In other

words, it is not allowed to run two or more instances for the same address family inside

a single named EIGRP process. If it is necessary to run, say, two IPv4 EIGRP instances,

one for AS number 1 and the other for AS number 64512, each of them must be placed

into a separate EIGRP process with a unique name. Also, two or more distinct named

EIGRP processes cannot run the same address family instance with the same AS number.

Simply put, there is a one-to-one correspondence between an EIGRP named process and

an address family instance with a particular AS number.

ptg13046388

414 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

On the other hand, running several different address families under a single named EIGRP

process is perfectly allowed, as shown in Example 8-14 . In this case, the AS numbers of

EIGRP instances for individual address families in the same EIGRP process do not even

need to match (meaning that you can run an IPv4 instance for AS number 1 and an IPv6

instance in the same process for AS number 2), but such a configuration is confusing at

best, so it is not recommended.

Readers familiar with the classic mode configuration of IPv6 EIGRP surely remember

the fact that an IPv6 EIGRP process was shut down by default after configuring it, and

a no shutdown command was necessary to actually start it. In the named configuration

mode, this is no longer true. In fact, there is an opposite extreme already described in

Example 8-14 : As soon as you configure an IPv6 address family, it automatically adopts

all interfaces on which IPv6 has been enabled (even a link-local address is sufficient) and

starts running on them. As this is usually not the desired behavior for production net-

works, Example 8-14 shows how to use the af-interface default section to first keep the

IPv6 address family instance off all interfaces, and only activate it on selected interfaces

later. Note the difference between deactivating an EIGRP address family instance on an

interface using the shutdown command and declaring an interface as passive using the

passive-interface command (both used in an af-interface section): No EIGRP adjacencies

will be formed over a passive interface, but its global prefixes will still be advertised over

other interfaces. Deactivating an EIGRP address family instance makes the EIGRP com-

pletely ignore the interface, not forming any adjacencies over it and also not advertising

any of its prefixes.

Let us now have a closer look at the commands available in each of the three AF-related

sections of named EIGRP configuration.

Address Family Section

This section is where any configurations specific to the EIGRP process itself are applied.

Commonly used commands include network and neighbor statements, or a manual

EIGRP Router ID specification. It is also the section that holds the per-AF-interface and

per-AF-topology sections. Example 8-15 shows the first-order commands available in the

IPv4 Address Family section.

Example 8-15 EIGRP Address Family Configuration Mode

R1(config-router-af)# ?

Address Family configuration commands:

af-interface Enter Address Family interface configuration

default Set a command to its defaults

eigrp EIGRP Address Family specific commands

exit-address-family Exit Address Family configuration mode

help Description of the interactive help system

maximum-prefix Maximum number of prefixes acceptable in aggregate

metric Modify metrics and parameters for advertisement

neighbor Specify an IPv4 neighbor router

network Enable routing on an IP network

Key

Topic

ptg13046388

Chapter 8: EIGRP 415

no Negate a command or set its defaults

shutdown Shutdown address family

timers Adjust peering based timers

topology Topology configuration mode

Per-AF-Interface Configuration Section

This configuration section is where all EIGRP interface-specific commands are applied.

Except non-EIGRP-specific commands such as bandwidth and delay (although arguably,

the delay is used only by EIGRP), every other EIGRP-related command can now be con-

figured in this section. This includes, but is not limited to, features such as EIGRP authen-

tication, Split Horizon, and manual summarization. Example 8-16 shows the list of all

first-order commands available in a per-AF-interface section for a selected interface. Note

that the list of commands for the af-interface default section would omit the summary-

address command; otherwise the list of supported commands would be identical.

Example 8-16 EIGRP Address-Family Interface Configuration Mode

R1(config-router-af-interface)# ?

Address Family Interfaces configuration commands:

add-paths Advertise add paths

authentication authentication subcommands

bandwidth-percent Set percentage of bandwidth percentage limit

bfd Enable Bidirectional Forwarding Detection

dampening-change Percent interface metric must change to cause update

dampening-interval Time in seconds to check interface metrics

default Set a command to its defaults

exit-af-interface Exit from Address Family Interface configuration mode

hello-interval Configures hello interval

hold-time Configures hold time

next-hop-self Configures EIGRP next-hop-self

no Negate a command or set its defaults

passive-interface Suppress address updates on an interface

shutdown Disable Address-Family on interface

split-horizon Perform split horizon

summary-address Perform address summarization

One of the neat consequences of having all EIGRP-related interface commands central-

ized in the af-interface section is that there is no longer a requirement for the eigrp key-

word in any of these commands. This globalizes the EIGRP commands against the format

used through any of the other routing protocols, and simultaneously provides a place for

all configurations that affect the operation, implementation, and regulation of EIGRP as

a whole.

Key

Topic

ptg13046388

416 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Per-AF-Topology Configuration Section

This configuration mode relates to the support of multiple routing topologies in EIGRP.

While multiple routing topologies are outside the scope of CCIE Routing and Switching

certification, a few words are certainly useful as the named EIGRP mode always presents

us with the topology base configuration section.

Within the context of Multi Topology Routing, a topology is defined as a subset of rout-

ers and links in a network for which a separate set of routes is calculated. The entire net-

work itself, for which the usual set of routes is calculated, is known as the base topology .

The base topology is the default routing environment that exists prior to enabling MTR.

Any additional topologies are known as class-specific topologies and are a subset of the

base topology. Each class-specific topology carries a class of traffic and is characterized

by an independent set of Network Layer Reachability Information (NLRI) that is used to

maintain separate routing tables and FIB databases. This design allows the router to per-

form independent route calculation and forwarding for each topology. Multiple topolo-

gies can be used to segregate different classes of traffic, such as data, voice, and video,

and carry them over different links in the same physical network, or to keep separate and

independent topologies for IPv4 and IPv6 routing. Multiple topologies are not equivalent

to Virtual Routing and Forwarding (VRF) tables because they share the common address

space, and they are not intended to provide address conservation or reuse.

EIGRP is capable of keeping separate routing information for different topologies, and its

behavior per specific topology within an address family can be configured in the per-AF-

topology section. On routers without MTR support, only the topology base command

will be available; on routers supporting MTR, the topology command will allow referenc-

ing a particular separate topology table definition by its name.

Example 8-17 shows the first-order commands available in the topology base section.

Note that these commands comprise the most commands related to route and metric

handling.

Example 8-17 EIGRP Address-Family Topology Configuration Mode

R1(config-router-af-topology)# ?

Address Family Topology configuration commands:

auto-summary Enable automatic network number summarization

default Set a command to its defaults

default-information Control distribution of default information

default-metric Set metric of redistributed routes

distance Define an administrative distance

distribute-list Filter entries in eigrp updates

eigrp EIGRP specific commands

exit-af-topology Exit from Address Family Topology configuration mode

maximum-paths Forward packets over multiple paths

metric Modify metrics and parameters for advertisement

no Negate a command or set its defaults

offset-list Add or subtract offset from EIGRP metrics

redistribute Redistribute IPv4 routes from another routing protocol

Key

Topic

ptg13046388

Chapter 8: EIGRP 417

snmp Modify snmp parameters

summary-metric Specify summary to apply metric/filtering

timers Adjust topology specific timers

traffic-share How to compute traffic share over alternate paths

variance Control load balancing variance

To sum up the EIGRP named mode configuration, as you might have learned by now,

everything you know about EIGRP classic mode configuration still applies in the EIGRP

named mode. The only slight inconvenience is related to relearning the placement of the

well-known commands into individual per-AF sections.

Together with the named mode, related show commands have also been updated. Instead

of show ip eigrp ... the new show eigrp address-family ipv4 ... syntax is used. Similarly,

instead of show ipv6 eigrp ... the new show eigrp address-family ipv6 ... syntax is used.

The older show commands will still be accepted, though, even if EIGRP is configured

in the named mode. Be aware, though, that for new EIGRP features, relevant show com-

mands might be only available in the new command syntax.

Additional and Advanced EIGRP Features

This section covers selected advanced EIGRP features.

Router ID

As with many protocols, EIGRP also uses a concept of a Router ID (RID), a single 4-byte

number representing a particular router instance. Each address family instance has its own

independent RID. It is however allowed for multiple EIGRP processes and address family

instances on the same router to use the same RID.

Originally, the primary use of the EIGRP RID has been to prevent routing loops in EIGRP

environments using redistribution. The RID identifies the originating router for external

routes injected into the EIGRP domain. Each external route was attached the RID of the

router that redistributed it into EIGRP. If an external route is received with the same RID

as the local router, the route is discarded. This feature is designed to reduce the possibil-

ity of routing loops in networks where route redistribution is being performed on more

than one router. EIGRP RID was not originally advertised with internal routes.

With recent IOS releases, however, the EIGRP RID is also advertised with internal routes.

As a result, each route advertised in EIGRP, internal or external, carries the RID of the

router that injected it into EIGRP. The logic of using the RID remains the same—a router

will discard every received route carrying the router’s own RID. Example 8-18 shows the

EIGRP RID carried along with advertised routes.

Key

Topic

ptg13046388

418 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 8-18 EIGRP Router ID

! The 10.0.2.0/24 is reported as internal, yet the route carries the RID

! of the advertising router – it is 10.255.255.2.

R1# show eigrp address-family ipv4 topology 10.0.2.0/24

EIGRP-IPv4 VR(CCIE) Topology Entry for AS(1)/ID(10.255.255.1) for 10.0.2.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 13189120, RIB is

103040

Descriptor Blocks:

10.0.0.2 (FastEthernet0/0), from 10.0.0.2, Send flag is 0x0

Composite metric is (13189120/163840), route is Internal

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 101250000 picoseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

Originating router is 10.255.255.2

! The next output shows a redistributed route 192.0.2.0/24 also carrying

! the originating router's ID. It is 10.255.255.2, also originated by the same

! router as before.

R1# show eigrp address-family ipv4 topology 192.0.2.0/24

EIGRP-IPv4 VR(CCIE) Topology Entry for AS(1)/ID(10.255.255.1) for 192.0.2.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 13172736, RIB is

102912

Descriptor Blocks:

10.0.0.2 (FastEthernet0/0), from 10.0.0.2, Send flag is 0x0

Composite metric is (13762560/7208960), route is External

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 110000000 picoseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

Originating router is 10.255.255.2

External data:

AS number of route is 0

External protocol is Static, external metric is 0

Administrator tag is 0 (0x00000000)

ptg13046388

Chapter 8: EIGRP 419

The rules of RID value selection are the same as with OSPF. First, the eigrp router-id

command in EIGRP configuration is preferred. If not configured, the highest IP address

among nonshutdown loopback interfaces is chosen as the RID. If no loopback interfaces

are configured or active, the highest IP address among all other nonshutdown interfaces

is used as the RID. After it is chosen, the RID will not be reinitialized until the EIGRP

process is removed, the RID is manually configured, or a manually configured RID is

removed. If you are configuring RID manually using the eigrp router-id command,

the values 0.0.0.0 and 255.255.255.255 are disallowed. Any other RID value is valid and

usable. If a router’s RID changes, it drops and reestablishes its adjacencies; a brief connec-

tivity outage might therefore ensue.

When you are changing interface addresses of a running router without restarting it, the

EIGRP RID will remain unchanged. This can cause unpleasant issues when a new router

is introduced into the network, retaking other routers’ addresses and tasks, while the old

router is renumbered without restarting it. As a result, it is possible that these two rout-

ers have the same EIGRP RID and they will not learn routes injected into EIGRP by each

other. There is no logging message to point to this phenomenon, apart from a relatively

obscure logging message in the EIGRP event log, as shown in Example 8-19 .

Example 8-19 Message in EIGRP Event Log If Route Is Denied Because of Duplicate

RID

! The 172.16.1.0/24 route is ignored in a received update because the RID

! of the router that injected the route into EIGRP matches this router's RID.

R7# show eigrp address-family ipv4 events

Event information for AS 1:

1 19:15:07.806 Ignored route, metric: 172.16.1.0/24 metric(3283435520)

2 19:15:07.802 Ignored route, dup routerid int: 10.255.255.1

! Output omitted

Finding out the current RID value was originally somewhat cumbersome. In older IOS

revisions, the only place that displayed the router’s RID was the heading of the show ip

eigrp topology and show ipv6 eigrp topology command output, as shown in Example

8-18 . Starting with IOS Release 15.0(1)M, there is a new show eigrp protocols command

that also contains information about the EIGRP RID. In newer IOS revisions, the EIGRP

RID is displayed in the show ip protocols command output as well.

Example 8-20 demonstrates the ways of displaying the RID. The router on which this

output was captured is the R1 router configured according to Example 8-14 . Its RID is

initialized from a loopback interface 10.255.255.1/32.

Example 8-20 EIGRP Router ID

! The following two commands all display the same output, as for both IPv4

! and IPv6, this router uses the same RID. In place of these commands,

! the new show eigrp address-family ipv4 topology

! and show eigrp address-family ipv6 topology commands can be used.

ptg13046388

420 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

R1# show ip eigrp topology | i Topology

EIGRP-IPv4 VR(CCIE) Topology Table for AS(1)/ID(10.255.255.1)

R1# show ipv6 eigrp topology | i Topology

EIGRP-IPv6 VR(CCIE) Topology Table for AS(1)/ID(10.255.255.1)

! The show eigrp protocols command covers all configured processes and address

! family instances in a single output. RID is displayed in the Router-ID line.

R1# show eigrp protocols

EIGRP-IPv4 VR(CCIE) Address-Family Protocol for AS(1)

Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0

Metric rib-scale 128

Metric version 64bit

NSF-aware route hold timer is 240

Router-ID: 10.255.255.1

Topology : 0 (base)

! Lines omitted for brevity

EIGRP-IPv6 VR(CCIE) Address-Family Protocol for AS(1)

Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0

Metric rib-scale 128

Metric version 64bit

NSF-aware route hold timer is 240

Router-ID: 10.255.255.1

Topology : 0 (base)

! Lines omitted for brevity

Unequal-Cost Load Balancing

Unlike most internal routing protocols, EIGRP has a feature that allows you to distribute

the load of your traffic across multiple unequal-cost paths and not just over paths provid-

ing the least distance to a destination. This feature is amply named unequal-cost load

balancing .

The key to unequal-cost load balancing is the presence of Feasible Successors. These

routers provide a guaranteed loop-free path to the destination, although not necessarily

the shortest one. Precisely this fact can be leveraged by EIGRP: Paths through Feasible

Successors can be installed to the routing table and used along with the best available

path even when the route is in the Passive state.

Unequal-cost load balancing is enabled through the variance multiplier command. In

named mode, the variance is configured in the topology base section. The multiplier

value essentially defines how many times worse than the best path a route through a

Feasible Successor can be to be still used by EIGRP for unequal-cost load balancing.

More precisely, if the variance is set to the value V, for each destination individually, the

ptg13046388

Chapter 8: EIGRP 421

router checks whether any path over a Feasible Successor meets the following condition

(CD stands for Computed Distance):

CD via Successor < CD via Feasible Successor in question < V × CD via Successor

If it does, it will be installed into the routing table through the corresponding Feasible

Successor.

A multiplier of 1, which is the default, implies that no unequal-cost load balancing is

being performed. The current value of the variance multiplier can always be verified in

the show ip protocols command output.

If multiple unequal-cost paths to a destination are installed into the routing table, the

router will forward proportionally less traffic over the worse paths, and vice versa. The

amount of traffic flowing over a particular path can be computed as this ratio:

Highest Installed Path Metric / Path Metric

As an example, if there are four paths over Successors and Feasible Successors to a desti-

nation with metrics 1100, 1100, 2000, and 4000, the amounts of traffic over these paths

would be 4000/1100 = 3, 4000/1100 = 3, 4000/2000 = 2, and 4000/4000 = 1, so the true

traffic share ratio would be 3:3:2:1 (recall that IOS routers perform integer division).

It is once again important to realize that the key to performing unequal-cost load balanc-

ing is first to have Feasible Successors toward a destination identified in the topology

table. Routers that do not meet the Feasibility Condition and thus are not considered

Feasible Successors are not considered in the unequal-cost load balancing, either. To uti-

lize several neighbors as Feasible Successors, you might need to perform judicious metric

tweaking so that the neighbors pass the Feasibility Condition check.

Keep in mind that the unequal-cost paths installed into the routing table also count

toward the maximum number of parallel paths to a destination configured using the

maximum-paths command. Depending on your network topology and requirements, it

might be necessary to modify this setting.

Add-Path Support

In certain scenarios, such as Dynamic Multipoint VPN (DMVPN) deployments in which

multiple branch offices are dual homed, hub routers usually have information about both

routes to a particular dual-homed branch office, and can perform equal-cost load balanc-

ing on their end. However, without an additional mechanism, a hub is unable to advertise

these equal-cost routes to other spoke routers. As a result, the other spokes only see a

single route to the dual-homed branch office without an ability to perform load balancing

over multiple paths, and if the single route they know about fails, they need to go over

the usual reconvergence process in EIGRP to learn about the other route.

To support these scenarios, starting with IOS Release 15.3(2)T, EIGRP was extended with

a so-called Add-Path support, allowing a hub to advertise multiple equal-cost routes to

the same destination. The prerequisite for a hub router to be able to advertise multiple

equal-cost routes is to first have them installed in its routing table. This might require tun-

ing the metrics and the maximum-paths command value first. Also, the hub router must

Key

Topic

Key

Topic

ptg13046388

422 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

have the Split Horizon deactivated on the multipoint tunnel interface toward individual

spokes.

The Add-Path feature can be configured only in the named mode, and is controlled on a

per-interface basis using the add-paths path-count command in the af-interface section.

The add-paths command allows advertising additional path-count equal-cost routes in

addition to the route that would be advertised nonetheless. The path-count is a manda-

tory argument in the range of 1 to 4. Using the Add-Path feature, therefore, at most four

additional equal-cost paths to any destination can be advertised from a hub router, in

total allowing the spokes to learn about five different equal paths to a particular des-

tination.

Spoke routers do not need to be specifically configured for the Add-Path feature, apart

from possible tuning of the maximum-paths command to be allowed to insert multiple

equal-cost paths into their routing tables.

The Variance (Unequal Cost Load Balancing) and Add-Path features are not compatible

with each other. When using the Add-Path, always be sure to set the variance to 1.

Example 8-21 shows the use of the Add-Path feature.

Example 8-21 Configuring the EIGRP Add-Path Feature

! First, the variance is deactivated, and the maximum-paths is set to 6.

! Then, on the Tunnel0 interface, split horizon is deactivated (a mandatory

! step; otherwise, multiple equal cost paths cannot be advertised to spokes).

! In addition, the next-hop-self setting must be deactivated, allowing the R1-Hub

! to retain the original next hop value instead of asserting itself as the

! next hop. Finally, the add-paths 4 allows advertising additional 4 equal-cost

! routes to a destination if the hub knows about them via the same EIGRP process

! instance and has them installed in its own routing table.

R1-Hub(config)# router eigrp CCIE

R1-Hub(config-router)# address-family ipv4 unicast autonomous-system 1

R1-Hub(config-router-af)# topology base

R1-Hub(config-router-af-topology)# variance 1

R1-Hub(config-router-af-topology)# maximum-paths 6

R1-Hub(config-router-af-topology)# exit

R1-Hub(config-router-af)# af-interface Tunnel0

R1-Hub(config-router-af-interface)# no split-horizon

R1-Hub(config-router-af-interface)# no next-hop-self

R1-Hub(config-router-af-interface)# add-paths 4

The no next-hop-self command has an additional no-ecmp-mode keyword not included

in Example 8-21 . To understand what this keyword does, first assume a topology in

which a DMVPN hub is dual homed itself, using two ISPs and two different multipoint

tunnel interfaces to reach the spoke routers. It is now possible for the hub to learn about

equal-cost paths to a spoke site over each tunnel interface, for example, two equal-cost

paths over Tunnel1 and next hops N

11 and N

12 , and two more equal-cost paths over

ptg13046388

Chapter 8: EIGRP 423

Tunnel2 and next hops N

21 and N

22 . When using the next-hop-self command on these

tunnel interfaces, EIGRP internally optimizes its work: It takes only the first entry in the

topology table (obviously pointing to a Successor) and verifies whether the Successor is

reachable over the tunnel interface through which the route is going to be readvertised

(thanks to deactivated Split Horizon), and if it is, the hub will keep the Successor address

in the advertisement, not asserting itself as the next hop. Additional entries in the topol-

ogy table are not subject to this test. This can lead to the no next-hop-self setting on an

interface being ignored for an advertised route, causing the hub router to impose itself

as the next hop even though it is not supposed to. For example, if the first entry in the

topology table is learned over Tunnel1 and next hop N

11 , this route will be advertised

over the Tunnel2 interface with the hub imposing itself as the next hop. The fact that

the same route with the same cost is also learned over Tunnel2 and next hops N

21 and

22 reachable on this interface, and should in fact be subject to no next-hop-self , will be

ignored.

The no-ecmp-mode command deactivates this internal optimization and forces EIGRP

to always walk over all equal-cost paths to a destination recorded in the topology table,

making sure that if any of these routes’ Successors can be reached over the interface

on which the route is going to be readvertised, the no next-hop-self command will be

honored and the Successor’s address will be retained in the advertisement. The use of no-

ecmp-mode is recommended with the Add-Path feature if the hub uses multiple tunnel

interfaces to reach the spoke sites.

Stub Routing

Stub routing is an EIGRP feature primarily designed to improve network scalability and

stability. The stub routing feature is most commonly used in hub-and-spoke networks.

This feature is configured only on spoke routers. When configured on a spoke router, the

router announces its stub router status using an additional TLV in its EIGRP Hello mes-

sages. The results of configuring a router as a stub are multifold:

■ A stub router does not propagate routes learned through EIGRP to its neighbors,

with the exception of EIGRP-learned routes that are explicitly selected using a so-

called leak-map construct. This prevents a stub router from ever being considered a

Feasible Successor for remote networks by its neighbors and possibly becoming a

transit router at some point in the future.

■ A stub router advertises only a subset of its own EIGRP-enabled networks to its

neighbors. This subset can be defined in the eigrp stub command using the sum-

mary , connected , static , redistributed , and receive-only keywords.

■ Neighbors of a stub router aware of its stub status (thanks to the specific TLV in the

stub router’s Hello packets) will never send a Query packet to a stub router. This pre-

vents the neighbors from converging through a stub router to reach networks that are

remote to the stub router.

Key

Topic

ptg13046388

424 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

There is a slight misunderstanding related to how a stub router itself handles Queries.

Several sources, including documents on the Cisco website, insist that a stub router sum-

marily responds to every received Query immediately with a Reply indicating infinite

distance. This is not entirely true. The following rules summarize the stub router behavior

with respect to handling Query packets:

■ Originating Query packets is not modified in any way. Rules for entering the Active

state and sending Queries are precisely the same.

■ Processing received Query packets depends on what network was queried for. If

the network in the received Query is a network the stub router is allowed to adver-

tise, meaning that it falls under the configured category of summary , connected ,

static , or redistributed , the router will process the Query normally (even possi-

bly causing the stub router to become Active itself) and send back an appropriate

Reply. The same is valid for an EIGRP-learned network that is allowed to be further

advertised using a leak-map —a Query for such a network would be processed and

responded to in the usual way. If the Query contains a network that the stub router

knows about but is not allowed to advertise (the network does not fall under the

configured category, or is learned through EIGRP but not allowed for further adver-

tisement by a leak-map ), it will be processed in the usual way as described earlier,

but the Reply will always indicate infinite distance, regardless of what the stub router

truly knows about the network. Receiving a Query for an unknown network will

immediately cause the router to respond with a Reply and an infinite distance; how-

ever, this is regular EIGRP behavior not related to the stub feature.

At this point, you might ask why a stub router would receive a Query, as its stub status

should instruct its neighbors to avoid sending Queries to it. There are two primary rea-

sons why even a stub router might receive a Query. First, a stub router’s neighbor might

be running an old IOS that does not recognize the stub TLV yet. Such a neighbor will cre-

ate an adjacency to a stub router just fine, but it will also happily send Queries to it, not

knowing that the router is a stub router. Second, if there are multiple routers on a com-

mon segment and all of them are configured as stub routers, if any of these stub routers

need to send a Query, it will also send it to all its stub neighbors. This is done to support

multihomed branch offices that usually have two branch routers configured as stubs.

Each of these branch routers is connected to the headquarters through its own uplink,

and they are also connected together by a common intra-site link. If the uplink on one of

the branch routers fails, the affected router needs to converge through its neighbor branch

router, and this might require a permission to send Queries to its fellow stub neighbor.

Therefore, on a common segment with all routers configured as stubs, Queries are sent as

usual.

In case of multiaccess segments with mixed neighbors (stub and nonstub), EIGRP solves

the problem of sending Queries only to nonstub neighbors in two ways: Either it sends

the Queries as unicasts to the nonstub neighbors or it uses the Conditional Receive

mode in RTP to send multicast Queries in such a way that only nonstub routers will

process them. The choice of a particular mechanism depends on the number of nonstub

neighbors. While mixing stub and nonstub routers on a common segment is not a recom-

mended practice, it is inevitable, for example, in cases where the hubs and spokes are

interconnected by a DMVPN or a VPLS service.

Key

Topic

ptg13046388

Chapter 8: EIGRP 425

The EIGRP stub routing feature provides important advantages when implemented in

hub-and-spoke networks:

■ It prevents suboptimal routing from occurring within hub-and-spoke networks.

■ It prevents stub routers with low-speed links from being used as transit routers.

■ It significantly limits the number of Query packets and the depth of their propaga-

tion, allowing the EIGRP network to convergence faster and avoid the SIA states.

The advantage of limiting the propagation of a Query packet should be immediately

obvious. Assume a network with 100 branch office routers, each of these branch office

routers being connected through a pair of point-to-point links to hub routers at the

headquarters (dual-hub design). Any Query originating at the headquarters can possibly

propagate to any branch office router through both links, and if a branch router is unable

to respond, it might need to originate a Query itself. The number of Queries and Replies

expected grows easily to orders of hundreds. A single misbehaving router, or an over-

loaded or faulty link, can cause major trouble and the diffusing computation will have

difficulties terminating, again risking the SIA state. With the stub feature, these issues are

eliminated easily.

Stub routing is enabled with the router process command demonstrated in Example 8-22 .

In named mode, the eigrp stub command is used in the particular address family section.

Example 8-22 EIGRP Stub Router Configuration

Router(config-router)# eigrp stub ?

connected Do advertise connected routes

leak-map Allow dynamic prefixes based on the leak-map

receive-only Set IP-EIGRP as receive only neighbor

redistributed Do advertise redistributed routes

static Do advertise static routes

summary Do advertise summary routes

<cr>

The receive-only keyword configures the router as a receive-only router. In other words,

when this keyword is used, the stub router does not advertise any prefixes. It only

receives prefixes advertised to it by its neighbors. Obviously, either static routing on its

neighbors or NAT/PAT on the stub router is required in this case to allow the networks

behind the stub router to communicate with the outside world. This keyword cannot be

used with any other keywords when configuring stub routing.

The leak-map name keyword configures the stub router to advertise selected EIGRP-

learned routes that would not be ordinarily advertised. The name references a route-

map that matches one or more ACLs or prefix lists that permit the matched subnets or

addresses to be leaked. This leaking is crucial in scenarios where a branch office uses a

pair of interconnected routers configured as stub routers. If these routers are to provide

backup connectivity to each other, they must be allowed to readvertise EIGRP-learned

routes to each other, even in stub mode. Route leaking accomplishes that.

ptg13046388

426 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The connected keyword configures the stub router to advertise connected subnets. These

are subnets on any interface directly connected to the router. Note that the directly con-

nected interfaces will not be advertised automatically; it is still necessary to add them to

EIGRP using the usual network command.

The static keyword configures the stub router to advertise static routes. The static routes

need to be redistributed into EIGRP to be advertised.

The summary keyword configures the stub router to advertise summary routes if config-

ured on interfaces.

The redistributed keyword configures the stub router to advertise routes that have been

redistributed into EIGRP from other route sources.

By default, when this command is enabled without additional keywords, both connected

and summary are assumed.

To check the current stub settings, inspect the show ip protocols output, as shown in

Example 8-23 . The current stub mode, if any, will be indicated in the output. Also, if it is

necessary to verify whether any neighbor is configured as a stub, use the show ip eigrp

neighbors detail command. If a neighbor is configured as a stub router, this command

will reveal it along with the information about which route categories it is advertising.

Keep in mind that activating, deactivating, or modifying the stub feature settings on a

router will cause it to drop and reestablish adjacencies with its neighbors.

Example 8-23 EIGRP Stub Status as Advertised in show Commands

! On R2, EIGRP Stub is configured. The show ip protocols shows that both

! connected and summary networks will be advertised.

R2# show ip protocols

Routing Protocol is "eigrp 1"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Default networks flagged in outgoing updates

Default networks accepted from incoming updates

EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

EIGRP maximum hopcount 100

EIGRP maximum metric variance 1

EIGRP stub, connected, summary

Redistributing: eigrp 1

EIGRP NSF-aware route hold timer is 240s

Automatic network summarization is not in effect

Maximum path: 4

Routing for Networks:

10.0.0.0

Routing Information Sources:

Gateway Distance Last Update

ptg13046388

Chapter 8: EIGRP 427

10.0.12.1 90 00:00:07

Distance: internal 90 external 170

! On R1 which is R2's direct neighbor, the show ip eigrp neighbors detail reveals

! that R2 is a stub connected+summary router, and R1 will not send Queries to R2.

R1# show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 10.0.12.2 Se1/0 10 00:03:50 26 300 0 3

Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 1

Stub Peer Advertising ( CONNECTED SUMMARY ) Routes

Suppressing queries

Note that the stub router feature has no impact on what routes the hub router will adver-

tise to its stub spokes. Without an additional configuration on the hub router, the spokes

will be populated with full routing tables. Considering the fact that in a hub-and-spoke

network, any other network beyond the branch networks is reachable through the hub,

having full routing tables on spoke routers with most of their entries pointing toward the

hub router is not particularly useful. Therefore, in these networks, the stub feature on

spokes is usually combined with route filtering and summarization on the hub router. The

hub router can be configured to advertise only the default route to the spoke router(s),

filtering out all other more specific route entries, effectively reducing the routing table on

the spoke to a single EIGRP-learned default route entry.

Route Summarization

Already a well-known concept to all CCIE Routing and Switching candidates, route

summarization reduces the amount of routing information that routers must exchange,

process, and maintain, which allows for faster convergence and less router load within

the network. Summarization also restricts the size of an area that is affected by network

changes by hiding the changes in the individual networks behind a single advertised sum-

mary route.

With particular respect to EIGRP, summarization is also a powerful tool to create a

boundary for Query propagation: If a router receives a Query for a network it does not

have in its topology table, it will immediately send back a Reply indicating an unreachable

destination, without itself going active and propagating the Query further. With summa-

rization, this is a natural scenario. Neighbors of a router performing route summarization

do not know the individual component routes. Queries originated inside the summarized

part of network, including those for component routes, will be propagated according

to the usual rules; a router performing route summarization does not modify the Query

contents nor influence its flooding scope. However, when a Query asking for a particular

component route is forwarded to the summarizing router’s neighbor, this neighbor has no

knowledge of the component, so it immediately responds with a Reply containing infinite

Key

Topic

ptg13046388

428 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

distance. As a result, summarization causes the propagation of Queries to be bounded by

directly connected neighbors of routers that perform route summarization.

Historically, EIGRP supports two types of route summarization: automatic summariza-

tion and manual summarization. Automatic summarization is a concept originally utilized

in classful routing protocols, whereby a subnet of a particular major network is advertised

as the major network itself if the subnet is to be advertised out an interface that lies in a

different major network. In EIGRP, automatic summarization does not apply to external

routes unless there is also an internal network that belongs to the same major network as

the external routes. EIGRP is a classless protocol, though, and the automatic summariza-

tion was implemented in it mostly to provide a smooth transition from classful protocols

to EIGRP. However, the concept of automatic summarization is practically unusable in

today’s networks, and in fact, starting with IOS Release 15.0(1)M, it is deactivated by

default; for older IOS releases, the no auto-summary command should be used in the

EIGRP configuration to deactivate it.

Manual summarization allows summarizing routes at any chosen router and its interface

in the network. As opposed to RIP implementation in IOS that does not allow supernet-

ting in summarization (using a shorter-than-classful netmask), EIGRP poses no limitations

on the particular manual summary address/netmask combination. If it suits you, you can

summarize even into a default route. Furthermore, configuring multiple overlapping sum-

mary addresses on an interface is also supported—in that case, EIGRP will advertise each

configured summary address for which at least one component route exists. This allows

for a sort of traffic engineering in which a part of a network with multiple border routers

advertises the same summary route covering the entire contained address range from each

border router (for example, 172.20.32.0/19), plus each of the border routers also advertis-

ing a different, more specific summary route covering only a portion of the contained

address range (for example, one border router advertising 172.20.32.0/20 and the other

advertising 172.20.48.0/20). Routers in other parts of the network will learn both the less

specific summary route from all border routers, thereby knowing that each border router

can be used to reach this prefix, and the more specific summaries, each advertised from

a different border router. Thanks to the longest prefix match paradigm in IP routing, traf-

fic to different destinations in the summarized part of the network will first follow the

path through the border router that advertised the more specific summary route matching

the destination. Only if that border router is unavailable or does not advertise the more

specific summary, traffic will follow the shortest route toward the less specific summary

through the nearest border router.

In EIGRP, manual summarization is configured on a per-interface basis. If you are using

the classic configuration mode, summarization is configured directly on an interface

using the ip summary-address eigrp autonomous-system address netmask [ distance

] [ leak-map name ] command. In named mode, summarization is configured in the cor-

responding af-interface section using the summary-address address netmask [ leak-map

name ] command. The optional leak-map argument allows referring to a route-map to

allow more specific components of the summary route to be selectively advertised as

unsummarized along with the summary route. This is used in certain scenarios where

leaking a particular component route helps to avoid suboptimal routing toward it.

ptg13046388

Chapter 8: EIGRP 429

Whenever a summary route is advertised, the router performing the summarization auto-

matically installs a so-called discard route for this summary route into its routing table.

The network and netmask in this discard route are identical to the network and netmask

of the advertised summary, and the outgoing interface is set to Null0. The discard route

prevents suboptimal routing or routing loops in situations when a router advertises a

summary route but has no knowledge of a more specific matching subnet for incoming

traffic. By virtue of the longest prefix match rule, any known component routes of a

summary route would be matched in the routing table before hitting the corresponding

discard route, and hence routed normally. For any presently unknown destinations within

an advertised summary, the discard route makes sure that the traffic is dropped rather

than routed over a possibly unrelated route, such as a default route.

A discard route’s administrative distance is 5 by default. In most scenarios, it is not nec-

essary to modify it. However, there are situations in which the summarizing router is

configured to advertise a manual summary route exactly matching a route that is already

learned by the router from another source. In that case, adding the corresponding discard

route can possibly replace the learned route in the routing table, rendering it unreachable.

For example, when summarizing into the default route, the router will attempt to install

a discard route to 0.0.0.0/0 into its routing table. If there already is a default route in the

routing table with its administrative distance higher than 5, the discard route will replace

it, causing the router to lose connectivity provided by the former default route. In such

cases, it is necessary to raise the discard route’s administrative distance above that of the

learned route. This can be accomplished using either the admin-distance optional argu-

ment in the ip summary-address eigrp per-interface command when using classic con-

figuration mode, or in the named mode by entering the topology base section and using

the summary-metric address netmask distance admin-distance command. In recent

IOS releases that support the named EIGRP configuration mode, the admin-distance

argument is removed from the ip summary-address eigrp command, and the summary-

metric command in the topology base mode must be used to change the administrative

distance.

Be careful about setting the discard route’s administrative distance to 255. In earlier IOS

releases, this prevented the discard route from being installed into the routing table, but

the summary address was nonetheless advertised. In more recent IOS releases, setting the

administrative distance of a discard route to 255 not only prevents the router from install-

ing the discard route into its routing table, but it also causes it to stop advertising the

summary route altogether. In other words, neither the summary route nor the component

routes will be advertised to neighbors, and the discard route will not be installed into the

routing table. This is similar to the OSPF area range address mask not-advertise com-

mand, which essentially prevents all routes falling under the defined address and mask

from being advertised, not even advertising the summarized route or installing a discard

route.

By default, when an EIGRP router originates a summary route, it looks up the lowest met-

ric from among all known component routes that are covered by this summary, and uses

this metric as the metric of the summary route itself. This means, however, that whenever

the lowest metric from among all known component routes changes, EIGRP has to select

the new lowest metric and advertise the summary route again with an updated metric.

Key

Topic

Key

Topic

Key

Topic

ptg13046388

430 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

In scenarios when multiple hundreds or thousands of component routes are summarized

into a single summary route, walking through this number of routes and identifying the

new lowest metric each time a component route is updated (added, removed, its metric

changed) can be CPU intensive, and at the same time, not worth the effort: The summary

route itself does not change; only its metric is updated. Therefore, the summary-metric

command in the topology base section can also be used to define a static metric for a

particular summary route. The summary route will then always be advertised with the

configured metric, relieving the router of the need to walk the topology table to identify

the least metric of covered components.

Example 8-24 shows the use of summarization commands in named mode, and selected

commands to verify whether the summarization has been configured properly.

Example 8-24 Summarization Configuration and Verification in Named Mode

! A prefix list and a route-map for route leaking are configured, allowing

! the 172.20.63.0/24 prefix to be leaked unsummarized

R2(config)# ip prefix-list LeakPrefixes permit 172.20.63.0/24

R2(config)# route-map EIGRPLeak permit 10

R2(config-route-map)# match ip address prefix-list LeakPrefixes

! In the EIGRP process, manual summarization is configured on the Fa0/0 interface

! to advertise a summary network of 172.20.32.0/19. Notice that the CIDR notation

! is also accepted in the command. A route-map is referenced in the leak-map

! optional keyword, allowing the prefixes permitted by the route-map to be

! advertised unsummarized along with the summary route.

R2(config-route-map)# router eigrp CCIE

R2(config-router)# address-family ipv4 unicast autonomous-system 1

R2(config-router-af)# af-interface FastEthernet0/0

R2(config-router-af-interface)# summary-address 172.20.32.0/19 leak-map EIGRPLeak

R2(config-router-af-interface)# exit-af-interface

! For this summary address, a static metric is configured in standard EIGRP

! component form, specifying the bandwidth of 1000000, delay of 1, reliability

! of 255, load of 1, and MTU of 1500. Setting the metric of the summary route

! statically allows the router to save CPU cycles by alleviating it from

! the need to traverse the topology table and search for the minimum metric

! among all covered component routes. Also, the administrative distance of the

! discard route is set to 10. For typographical reasons, the command keywords

! have been truncated; summary-m stands for summary-metric , dist stands for distance

R2(config-router-af)# topology base

R2(config-router-af-topology)# summary-m 172.20.32.0/19 1000000 1 255 1 1500 dist 10

R2(config-router-af-topology)# exit-af-topology

ptg13046388

Chapter 8: EIGRP 431

! There are several ways to verify the configured summarization. Following are

! selected ways of checking whether the summarization is configured and active.

! The show ip protocols command will list all configured summaries and interfaces

! they are placed on, including the advertised computed metric. In show ip route

! the corresponding discard route will be shown if the summary is being advertised,

! and the EIGRP topology table will contain the advertised summary route with

! the Null0 as the next hop interface.

R2(config-router-af)# do show ip protocols | section Summ

Automatic Summarization: disabled

Address Summarization:

172.20.32.0/19 for Fa0/0

Summarizing 32 components with metric 1310720

R2(config-router-af)# do show ip route eigrp | i Null

D 172.20.32.0/19 is a summary, 00:31:34, Null0

R2(config-router-af)# do show eigrp address-family ipv4 topology 172.20.32.0/19

EIGRP-IPv4 VR(CCIE) Topology Entry for AS(1)/ID(10.255.255.2) for 172.20.32.0/19

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1310720, RIB is

10240

Descriptor Blocks:

0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0

Composite metric is (1310720/0), route is Internal

Vector metric:

Minimum bandwidth is 1000000 Kbit

Total delay is 10000000 picoseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 0

Originating router is 10.255.255.2

R2(config-router)#

Passive Interfaces

When EIGRP is enabled for a network, the router begins to send out Hello packets and

process incoming EIGRP packets on all interfaces that fall within the specified network

range. This allows EIGRP to dynamically discover neighbors and establish network rela-

tionships, as we have previously discussed. This is desired on interfaces that are actually

connected toward neighboring routers. However, this default behavior also results in an

unnecessary waste of router resources on logical interfaces, such as loopback interfaces,

that will never have any other device connected or have an EIGRP neighbor relationship

form. Also, it is useless, even dangerous, to send and process EIGRP packets on interfaces

connected to networks with end hosts where no further routers are intended to be.

ptg13046388

432 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

To prevent this type of squandering of router resources, you can use the passive-

interface command. A passive interface does not send or process received EIGRP pack-

ets, but the network configured on the interface is still advertised. In the classic configu-

ration mode, the passive-interface command accepts an interface name or the default

keyword, causing all interfaces to be considered passive; in that case, the no passive-

interface command can subsequently be used to make selected interfaces active again.

In the named configuration mode, the passive-interface command is used in the corre-

sponding af-interface sections, as already shown in Example 8-24 . To make all interfaces

passive by default, use the passive-interface command in the af-interface default section,

and no passive-interface in the specific af-interface sections for those interfaces that you

want to keep active.

Graceful Shutdown

Graceful Shutdown in EIGRP is a long-implemented feature that cannot in fact be con-

trolled—it is only used, mostly not even knowing it is there. The Graceful Shutdown

allows a router to advertise that it is being deactivated, either on an interface, for a partic-

ular address family, or as the entire process, thereby allowing its neighbors to react imme-

diately, rather than wait for the Hold timer to expire. Technically, the Graceful Shutdown

is accomplished by means of a Goodbye message, which is really a normal Hello packet

having all K-values set to 255.

Classic EIGRP configuration mode allows you to gracefully shut down an EIGRP instance

only for IPv6 EIGRP using the shutdown command. IPv4 EIGRP has no direct shutdown

command. In the classic mode, the Goodbye message was usually sent when shutting

down interfaces, configuring them as passive, removing the related network or ipv6 eigrp

commands, or removing the entire EIGRP process or restarting the router.

In the named mode, the shutdown command can be used in various places:

■ Directly in the router eigrp mode, causing all configured address family instances

under that process name to be deactivated

■ In the particular address family mode, causing the entire particular address family

instance to be deactivated

■ In the particular af-interface section in the address family mode, causing the EIGRP

to cease all operations on that interface for the particular address family, effectively

ignoring the interface altogether

Securing EIGRP with Authentication

Since its inception, EIGRP supports Message Digest 5 (MD5) hashing to ensure the integ-

rity of EIGRP messages and to prevent the injection of false routing information into

the EIGRP domain. In addition, starting with IOS Releases 15.1(2)S and 15.2(1)T, EIGRP

authentication support has been extended with the second-generation Secure Hash

Algorithm, also known as SHA-2, in particular, with its 256-bit variant. MD5 authentica-

tion can be configured both in classic and named mode; SHA authentication can only be

configured in the named mode.

Key

Topic

Key

Topic

Key

Topic

ptg13046388

Chapter 8: EIGRP 433

The configuration of EIGRP authentication is fairly straightforward and consists of con-

figuring at least one key chain to hold the used keys along with their numbers (also called

key IDs), key strings, and optionally the validity time ranges, and activating the authenti-

cation on selected interfaces. As with all key chain–based authentication schemes, for the

authentication between two neighbors to succeed, they must match on the key ID and

key string used to authenticate exchanged packets. The key chain names themselves are

used only locally in the configuration and do not need to match.

With SHA authentication, there is also an option of configuring passwords directly in

the interface configuration, without creating key chains. This approach might be slightly

simpler to configure; however, it will prevent you from performing a seamless rollover to

a new key, as there can always be only a single per-interface key configured.

If using the classic mode, the per-interface commands to activate MD5 EIGRP authenti-

cation are the ip authentication mode eigrp and ip authentication key-chain eigrp com-

mands. There is no way to configure EIGRP authentication for all interfaces at once; each

EIGRP-enabled interface has to be configured individually. In named mode, per-interface

configuration steps are accomplished in the af-interface section using the authentication

mode and authentication key-chain commands. If used in the af-interface default sec-

tion, the authentication settings will apply automatically to all EIGRP-enabled interfaces;

these can be overridden later on selected interfaces using the appropriate af-interface

section.

Example 8-25 shows a process of configuring various types of authentication in EIGRP

named mode. Read the comments in the example carefully.

Example 8-25 EIGRP Authentication

! Key chain EIGRPKeys with a single key is configured

R1(config)# key chain EIGRPKeys

R1(config-keychain)# key 1

R1(config-keychain-key)# key-string EIGRPRocks

! MD5 authentication is configured on all EIGRP-enabled interfaces,

! using the EIGRPKeys key chain

R1(config)# router eigrp CCIE

R1(config-router)# address-family ipv4 autonomous-system 1

R1(config-router-af)# af-interface default

R1(config-router-af-interface)# authentication mode md5

R1(config-router-af-interface)# authentication key-chain EIGRPKeys

R1(config-router-af-interface)# exit

! On Fa0/0, the authentication type is overridden to SHA-256, using the key

! configured in the EIGRPKeys key chain. Note a particular peculiarity:

! At the time of writing, the authentication mode hmac-sha-256 command

! required that a password was specified even if a key chain was being used.

ptg13046388

434 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! In such case, both will be used for authentication. Also notice that the use of

! the EIGRPKeys key chain is already specified in the af-interface default

! section. Referring to the same key chain in the section for Fa0/0 is

! therefore not required, and the authentication key-chain EIGRPKeys command

! would in fact not appear in the af-interface Fa0/0 section. Nevertheless,

! always specifying it explicitly when SHA-256 authentication with a key chain

! is to be used can be considered a best practice.

R1(config-router-af)# af-interface FastEthernet0/0

R1(config-router-af-interface)# authentication mode hmac-sha-256 SomePhonyPass

R1(config-router-af-interface)# authentication key-chain EIGRPKeys

R1(config-router-af-interface)# exit

! On Fa0/1, the authentication type is overridden to SHA-256, using

! a per-interface configured password. Notice that to specifically stop

! using the EIGRPKeys key chain defined for all EIGRP-enabled interfaces

! in the af-interface default section, the no authentication key-chain command

! is used. Again, always stating it explicitly when a SHA-256 with a per-interface

! password authentication is to be used can be considered a best practice. If no

! default key chain is configured, the command will not appear in the config.

R1(config-router-af)# af-interface FastEthernet0/1

R1(config-router-af-interface)# authentication mode hmac-sha-256 BigP4ssw0rd

R1(config-router-af-interface)# no authentication key-chain

R1(config-router-af-interface)# exit

! Finally, the Serial1/0 interface is entirely exempted from authentication

! that would otherwise apply to it because of the af-interface default section.

R1(config-router-af)# af-interface Serial1/0

R1(config-router-af-interface)# no authentication mode

R1(config-router-af-interface)# exit

! Apart from verifying the configuration using show run | section router eigrp

! the authentication, if any, can be checked for a particular interface by

! the show eigrp address-family ... interfaces detail command.

R1(config-router-af)# do show eigrp address-family ipv4 int detail fa0/0

! Lines omitted for brevity

Authentication mode is HMAC-SHA-256, key-chain is "EIGRPKeys"

R1(config-router-af)# do show eigrp address-family ipv4 int detail fa0/1

! Lines omitted for brevity

Authentication mode is HMAC-SHA-256, key-chain is not set

ptg13046388

Chapter 8: EIGRP 435

R1(config-router-af)# do show eigrp address-family ipv4 int detail s1/1

! Lines omitted for brevity

Authentication mode is md5, key-chain is "EIGRPKeys"

R1(config-router-af)# do show eigrp address-family ipv4 int detail s1/0

! Lines omitted for brevity

Authentication mode is not set

When using key chains, each key can be time limited in its usability to sign sent packets

(by the send-lifetime per-key command) and to authenticate received packets (by the

accept-lifetime per-key command). If multiple keys in the key chain are eligible to sign

egress packets, the key with the lowest key ID will be used. To authenticate received

packets, EIGRP will try to use the key indicated by its ID in the received packet if the

key is still valid. This behavior allows for a seamless key rollover procedure:

■ On all routers, add the new key with a higher key ID into the key chain. While the

key chain will now hold both the old and the new key, the old key (assuming that it

has a lower key ID than the new key) will continue to be used both to sign outgoing

packets and authenticate incoming packets.

■ After the new key has been added to all routers, configure the old key on all routers

with a send-lifetime that is already in the past. This will cause each router to stop

using the old key and migrate to using the new key. Note that regardless of which

key (the old or the new) a router uses to sign outgoing packets, its neighbors will

accept them because the particular key ID used to sign a packet is carried in the

packet, and both old and new keys are still valid to authenticate received packets.

■ After the send-lifetime has been set to a past time for the old key on all routers, the

entire network now uses the new key both to sign sent and authenticate received

packets. The old key can now be removed completely from key chains, completing

the migration.

Default Routing Using EIGRP

EIGRP has no dedicated command to inject a default route into an EIGRP domain.

Instead, it uses other well-known techniques to advertise a default route:

■ Redistributing the default route from other routing source into EIGRP, often the

most straightforward method.

■ Using manual summarization to summarize all advertised routes into a default route.

Often used in hub-and-spoke scenarios, this requires a suitable topology.

EIGRP formerly also supported the use of the ip default-network command, originally

retaken from IGRP, to flag a specific advertised route as a so-called candidate default

network. This network, however, had to be a classful network and had to be advertised

in EIGRP in addition to being flagged as a candidate default. The overall configuration

required to advertise this classful network into EIGRP and flagging it as a candidate

Key

Topic

ptg13046388

436 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

default network was of the same complexity, if not higher, as redistributing the default

route directly. As a result, this approach was seldom feasible, and in recent IOS versions,

EIGRP no longer appears to honor the candidate default flag. It is best to avoid using this

command altogether.

Many sources claim that the network 0.0.0.0 command causes EIGRP to generate and

inject the default route into the routing domain. Such claims are based on a somewhat

confusing behavior of EIGRP: If a static route is configured using only the egress inter-

face and not the next-hop IP address, IOS treats this route also as being directly con-

nected. As a result, the network command can be used to advertise such a directly

con nected static route in EIGRP much like any other directly connected network. If the

default route happens to be configured as a static route out an interface, for example, ip

route 0.0.0.0 0.0.0.0 Dialer0 , using the network 0.0.0.0 command in EIGRP seemingly

does the right thing—it makes EIGRP advertise this default route. In reality, however,

configuring network 0.0.0.0 is almost never a good idea:

■ It will cause all IPv4-enabled interfaces on the router to be enabled for EIGRP. In

other words, EIGRP will start advertising all directly connected IPv4 networks on

the router, and it will try to establish adjacencies over any IPv4 interface.

■ If the default route on the router is not configured specifically as a directly con-

nected static route, the network 0.0.0.0 command has no effect on it and will not

cause it to be advertised, defeating the entire purpose of configuring it in the first

place.

Split Horizon

Split Horizon is a generic distance-vector protocol feature that mandates that a route must

not be advertised over an interface used to reach it. This prevents the “re-advertising”

of routing information back to the next hop from which it is learned in the first place.

EIGRP in particular uses the Split Horizon with Poisoned Reverse, advertising each

learned network out the interface toward its Successor with an infinite metric.

While Split Horizon with Poisoned Reverse is a powerful loop-prevention mechanism, it

is sometimes necessary to deactivate it. This is particularly important in hub-and-spoke

networks, where multiple spoke routers are reachable over a single interface on a hub.

Examples include neighbors reachable over Frame Relay or ATM multipoint interfaces, or

spoke routers reachable through multipoint GRE tunnels in DMVPN deployments. With

the Split Horizon with Poisoned Reverse in place, a hub learns about networks from each

spoke but is forced to advertise each of these networks as unreachable out the same inter-

face toward other spokes. As a result, neither spoke will learn about networks on other

spokes.

If the topology and requirements permit it, the most scalable solution to this issue is to

advertise a default route to all spokes, making the hub attract all spoke-to-spoke traffic

for which the spokes have no more specific routes. The spoke-to-spoke traffic will then

naturally flow through the hub. In cases where this approach is not usable, EIGRP can be

configured to deactivate the Split Horizon with Poisoned Reverse on a per-interface basis.

Key

Topic

ptg13046388

Chapter 8: EIGRP 437

In the classic mode, the no { ip | ipv6 } split-horizon eigrp interface command can be

used to deactivate the Split Horizon. In the named mode, the corresponding no split-

horizon command in an af-interface section can be used.

EIGRP Over the ToP

A fairly recent addition to the EIGRP feature collection is the so-called Over the ToP, or

OTP. This feature allows creating overlay multipoint VPNs between customer edge rout-

ers running EIGRP without any special cooperation with the service provider that oper-

ates the network interconnecting the edge routers, greatly simplifying many issues that

usually arise with operating a possibly multihomed Layer 3 VPN over a service provider’s

network.

The key to the OTP functionality is the Locator/Identifier Separation Protocol, or LISP.

While LISP is beyond the scope of the CCIE Routing and Switching exam, it is necessary

to explain its basic principles very briefly to understand how EIGRP and OTP make use

of it.

In traditional understanding, an IP address consists of two parts: the network prefix and

the host suffix (the network ID and the host ID). In essence, the network prefix identifies

the location of the particular host, while the host suffix identifies the host itself. When the

host moves to a different network, its entire IP address changes (possibly both in network

and host parts) even though the host is still the same; just its location has changed. Also,

because the location and identity are tied together in a single address of a particular type

(either IPv4 or IPv6), a single address also implies—and limits—communication with the

particular host to the corresponding protocol only.

The Locator/Identifier Separation Protocol (LISP) aims at decoupling the location of a

host from its identity, allowing the host to retain its identity regardless of its location in

a network. The general idea in LISP is to separate the identity and location into two inde-

pendent entities, each of them represented by a complete address, and provide a mapping

service so that the address representing the identity of a host can be resolved into the

address that represents its location. A tunneling mechanism is then used to encapsulate

packets between end hosts addressed using end host identities into new packets that are

destined to the addresses representing end host locations. This allows a host to change its

location while retaining its identity and all open sessions without losing connectivity, and

it also allows for interesting IPv4/IPv6 migration scenarios in which the location of a host

(say, IPv6) is different from its location (reachable over an IPv4 network).

More precisely, in LISP, a host has an Endpoint ID, or EID, that identifies its identity

that never needs to change. This EID can be an IPv4 address, an IPv6 address, or any

other address format as needed, although at the time of this writing, IPv4 and IPv6 were

the only supported formats. In Figure 8-9 , all hosts at the LISP Site 1 have an EID in the

space 10.0.1.0/24, while all hosts at the LISP Site 2 have an EID in the space 10.0.2.0/24.

To reach any host at these sites from outside, packets must be tunneled to the router

behind which this host is currently located. The outside address of this router effec-

tively represents the location of the EID and is denoted as Routing Locator, or RLOC.

Many EIDs can be located behind a single RLOC. In Figure 8-9 , the RLOC for all EIDs

Key

Topic

ptg13046388

438 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

in the space 10.0.1.0/24 is the R1 address 192.0.2.31. The RLOC for all EIDs in the space

10.0.2.0/24 is the R2 address 198.51.100.62. Traffic flowing from the source 10.0.1.11 at

LISP Site 1 to the destination 10.0.2.12 at LISP Site 2 will be encapsulated by R1 into new

packets and destined to the RLOC of 198.51.100.62, the R2’s address. Responses flowing

back to 10.0.1.11 will be encapsulated by R2 and sent to the RLOC of 192.0.2.31, the R1’s

address. These routers perform ingress and egress tunneling of traffic that flows between

the LISP sites, and are also responsible for making all necessary EID-to-RLOC registra-

tion and resolution to allow the LISP sites to communicate successfully.

LISP Site 1

10.0.1.11 10.0.2.12

RLOC

192.0.2.31

RLOC

198.51.100.62

EID-prefix

10.0.1.0/24

EID-prefix

10.0.2.0/24

LISP Site 2

Figure 8-9 Location and Identifier Separation in LISP

LISP hence has both a control and a data plane. The control plane in LISP comprises the

registration protocol and procedures by which the tunnel routers R1 and R2 register the

EIDs they are responsible for along with their RLOCs in a LISP-mapping service, and

using these registrations they map EIDs into RLOCs. The data plane defines the actual

tunnel encapsulation used between Routers R1 and R2 when two hosts from each LISP

sites communicate.

In OTP, EIGRP serves as the replacement for LISP control plane protocols. Instead of

doing dynamic EID-to-RLOC mappings in native LISP-mapping services, EIGRP routers

running OTP over a service provider cloud create targeted sessions, use the IP addresses

provided by the service provider as RLOCs, and exchange routes as EIDs. Consider

Figure 8-9 again. If R1 and R2 ran OTP to each other, R1 would learn about the network

10.0.2.0/24 from R2 through EIGRP, treat the prefix 10.0.2.0/24 as an EID prefix, and

take the advertising next hop 198.51.100.62 as the RLOC for this EID prefix. Similarly,

R2 would learn from R1 about the network 10.0.1.0/24 through EIGRP, treat the prefix

10.0.1.0/24 as an EID prefix, and take the advertising next hop 192.0.2.31 as the RLOC

for this EID prefix. On both routers, this information would be used to populate the LISP

mapping tables. Whenever a packet from 10.0.1.0/24 to 10.0.2.0/24 would arrive at R1, it

would use its LISP mapping tables just like in ordinary LISP to discover that the packet

has to be LISP encapsulated and tunneled toward 198.51.100.62, and vice versa. The LISP

data plane is reused in OTP and does not change; however, the native LISP mapping and

resolving mechanisms are replaced by EIGRP.

OTP is based on creating targeted EIGRP sessions between customer edge routers, and

using the routing information carried by EIGRP to populate both routing tables and LISP

mapping tables. The edge routers do not exchange any routing information with the ser-

vice provider routers. Thus, this solution is fully controlled by a customer and requires no

cooperation with the service provider, apart from providing full IP connectivity between

Key

Topic

ptg13046388

Chapter 8: EIGRP 439

customer routers. In many ways, the resulting connectivity between customer sites close-

ly resembles a Dynamic Multipoint VPN (DMVPN). The key differences are

■ DMVPN uses multipoint GRE tunnels, encapsulating both data and control plane

traffic. As a result, certain priming in DMVPN is necessary for it to start, such as

creating tunnel interfaces on all member routers, assigning addresses to these tun-

nels, and manually mapping the tunnel address of the hub router to its real address

on each spoke. OTP uses LISP UDP-based encapsulation for data plane traffic while

running EIGRP natively, without additional encapsulation, between the customer

edge routers. No tunnel interface configuration is required, and the only mandatory

static configuration is specifying the remote static neighbor in EIGRP configuration.

Optionally, the entire OTP traffic (both control and data plane) can be protected

using Group Encrypted Transport Virtual Private Network (GETVPN).

■ Apart from running a routing protocol such as EIGRP, DMVPN also depends on run-

ning the Next Hop Resolution Protocol (NHRP) to provide mappings between mul-

tipoint tunnel interfaces and real router addresses. In OTP, EIGRP itself serves as the

mapping mechanism. No other control plane protocol is required.

Configuring two or more routers for direct EIGRP OTP peerings is as simple as configur-

ing static EIGRP neighbors; see Example 8-26 and included comments.

Example 8-26 EIGRP Over the ToP Configuration and Verification for a Pair of Routers

! On R1, Gi0/0 is the interface toward the service provider. Basic IP

! configuration is performed, followed by LISP and EIGRP configuration.

! Configuring the LISP0 interface is not required; however, the default

! bandwidth setting on the LISP0 interface is 56 Kbps, causing EIGRP to

! compute very high metric values, therefore, the setting was updated.

! The OTP is started by the neighbor command referring to the remote neighbor

! 198.51.100.62 reachable over the Gi0/0 interface, specifying a hop count

! of 100 and the lisp-encap activating the LISP-based OTP functionality.

! At the time of writing, it was required to add the Gi0/0 interface

! to EIGRP, otherwise no static neighborships would form over it,

! hence the network 192.0.2.31 0.0.0.0 command. This was conformant to

! the usual EIGRP behavior that static neighborships form only over interfaces

! added to EIGRP. This limitation may be lifted in future. Also, a local

! network 10.0.1.0/24 is advertised in EIGRP.

interface LISP0

bandwidth 1000000

interface GigabitEthernet0/0

ip address 192.0.2.31 255.255.255.0

ip route 0.0.0.0 0.0.0.0 192.0.2.2

router eigrp CCIE

ptg13046388

440 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

address-family ipv4 unicast autonomous-system 64512

topology base

exit-af-topology

neighbor 198.51.100.62 GigabitEthernet0/0 remote 100 lisp-encap

network 10.0.1.0 0.0.0.255

network 192.0.2.31 0.0.0.0

! On R2, the configuration is very similar:

interface LISP0

bandwidth 1000000

interface GigabitEthernet0/1

ip address 198.51.100.62 255.255.255.0

ip route 0.0.0.0 0.0.0.0 198.51.100.1

router eigrp CCIE

address-family ipv4 unicast autonomous-system 64512

topology base

exit-af-topology

neighbor 192.0.2.31 GigabitEthernet0/1 remote 100 lisp-encap

network 10.0.2.0 0.0.0.255

network 198.51.100.62 0.0.0.0

! On R1, show ip route and show eigrp address-family ipv4 neighbor commands

! produce a fairly common output, showing that the remote network 10.0.2.0/24

! is reachable over LISP0 interface while the remote neighbor itself can be

! reached through Gi0/0 interface (recall that control plane traffic in OTP is

! sent natively while data plane traffic is LISP-encapsulated). The show ip cef

! command shows that the traffic for 10.0.2.0/24 will be LISP-encapsulated

! and forwarded over the current default route next hop 192.0.2.2 to the other

! tunnel endpoint 198.51.100.62.

R1# show ip route eigrp

! Lines omitted for brevity

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

D 10.0.2.0/24 [90/2570880] via 198.51.100.62, 00:36:24, LISP0

R1# show eigrp addr ipv4 nei

EIGRP-IPv4 VR(CCIE) Address-Family Neighbors for AS(64512)

ptg13046388

Chapter 8: EIGRP 441

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 198.51.100.62 Gi0/0 13 00:36:55 11 100 0 6

R1# show ip cef 10.0.2.0/24 internal

10.0.2.0/24, epoch 0, RIB[I], refcnt 5, per-destination sharing

sources: RIB

feature space:

IPRM: 0x00028000

ifnums:

LISP0(17): 198.51.100.62

path list 1381A4AC, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn]

path 12BED5A0, share 1/1, type attached nexthop, for IPv4

nexthop 198.51.100.62 LISP0, IP midchain out of LISP0, addr 198.51.100.62

13C2AD00

output chain:

IP midchain out of LISP0, addr 198.51.100.62 13C2AD00

IP adj out of GigabitEthernet0/0, addr 192.0.2.2 1289B118

Running OTP between remote routers does not even require that a route toward the

remote neighbor (including a default route) is configured on the router. Because the

neighbor command specifies the interface toward the remote neighbor, EIGRP in fact

places its packets on the interface queue directly, bypassing the routing table and caus-

ing the IP driver to simply do its job after it has a packet enqueued: Do the encapsulation

of the packet into a data link layer frame, using the packet’s destination IP address to

look up the particular destination Layer 2 address to put into the frame. If the interface

is a point-to-point interface, the task of encapsulating the EIGRP packet into a frame is

simple. If the interface is an Ethernet interface, however, this will cause the router to send

ARP requests for the static remote neighbor’s IP address out the interface to the service

provider, effectively relying on the Proxy ARP feature activated on the service provider’s

edge router. Note that this is an unintuitive fact, and if the service provider disables

Proxy ARP on its edge router, the OTP peering will not come up until static ARP map-

pings are configured on the OTP router.

With just a few OTP routers, configuring a full mesh of static neighbors is relatively easy.

However, if the OTP network grows, this would not be a scalable approach. Therefore,

OTP also introduces a special router role, a so-called route reflector . This router role

borrows heavily from BGP, and in fact, it provides the same functionality to EIGRP: It

allows collapsing the full mesh of OTP neighbors to a hub-and-spoke model of neighbor

configuration, with the route reflector collecting learned networks from its clients and

readvertising them back to individual clients, optionally maintaining the original next-

hop value. With route reflectors, all clients of a route reflector are configured similarly to

Router R2, as shown in Example 8-26 , with the route reflector being their only statically

defined OTP neighbor; there is otherwise no change to their configuration. The configu-

ration of the route reflector router is shown in Example 8-27 , now assuming that R1 is the

route reflector.

Key

Topic

ptg13046388

442 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 8-27 EIGRP Over the ToP Route Reflector Configuration

! The basic IP configuration is similar to the Example 8-26 .

interface LISP0

bandwidth 1000000

interface GigabitEthernet0/0

ip address 192.0.2.31 255.255.255.0

ip route 0.0.0.0 0.0.0.0 192.0.2.2

! Instead of configuring neighbors on the route reflector statically,

! the remote-neighbors command is used, identifying the interface whose

! IP address is used by remote neighbors to reach this route reflector

! (meaning that this interface's IP address is used in the neighbor command

! on the remote neighbors) and that will be used by R1 to speak to remote

! neighbors. Usually, the physical interface toward the service provider

! network or a loopback will be used here. Just as before, this interface

! also must be added to EIGRP using the corresponding network command.

! In addition, the af-interface section for this interface specifies two

! commands: no split-horizon to allow learned routes to be reflected to other

! neighbors, accomplishing the very task of R1 as a route reflector,

! and no next-hop-self , facilitating direct spoke-to-spoke communication. If

! all traffic is intended to flow over the route reflector as in hub-and-spoke

! scenarios, the no next-hop-self can be omitted. The no split-horizon , however,

! must always be present.

router eigrp CCIE

address-family ipv4 unicast autonomous-system 64512

af-interface GigabitEthernet0/0

no next-hop-self

no split-horizon

exit-af-interface

topology base

exit-af-topology

remote-neighbors source GigabitEthernet0/0 unicast-listen lisp-encap

network 10.0.1.1 0.0.0.0

network 192.0.2.31 0.0.0.0

The remote-neighbors command also allows you to refer to a named ACL using the

optional allow-list acl-name keyword, narrowing the source addresses of permitted route

reflector clients.

ptg13046388

Chapter 8: EIGRP 443

EIGRP Logging and Reporting

EIGRP event logging configuration parameters are configured in router configuration

mode, as demonstrated in Example 8-28 . If named mode is used, these commands are

located in the address family section.

Example 8-28 EIGRP Logging and Reporting

Router(config-router)# eigrp ?

event-log-size Set EIGRP maximum event log entries

event-logging Log IP-EIGRP routing events

log-neighbor-changes Enable/Disable IP-EIGRP neighbor logging

log-neighbor-warnings Enable/Disable IP-EIGRP neighbor warnings

The eigrp event-logging configuration command is the default. This EIGRP command

enables the router to store a log of EIGRP events. The contents of the EIGRP log can be

viewed by issuing the show eigrp address-family { ipv4 | ipv6 } events command. By

default, the EIGRP event log stores up to 500 lines of events. This default behavior can be

changed by running the command, under router processor, event-log-size < 0-443604 > .

The eigrp log-neighbor-changes router configuration command allows the router to log

EIGRP neighbor relationship changes. This command is enabled by default. The eigrp

log-neighbor-warnings [ seconds ] router configuration command is also enabled by

default. This command logs EIGRP neighbor warning messages at 10-second intervals.

EIGRP Route Filtering

Outbound and inbound EIGRP updates can be filtered at any interface, or for the entire

EIGRP address family instance, in either direction. To filter the routes, the distribute-list

command is used. In classic mode, the command is applied directly in the EIGRP process

configuration. In named mode, distribute-list is configured under topology base in the

particular address family.

EIGRP allows ACLs, prefix lists, and route-maps to be used for route filtering in a

distribute-list command. Depending on the filtering mechanism, there are multiple vari-

ants of this command available:

■ ACLs: distribute-list acl-number | acl-name { in | out } [ interface ]

■ Prefix lists: distribute-list prefix prefix-list-name { in | out } [ interface ]

■ Route maps: distribute-list route-map route-map-name { in | out } [ interface ]

In general, the use of prefix lists is recommended, as they are specifically designed to

match ranges of networks and netmasks.

Interestingly enough, distribute lists do not directly limit the propagation of Queries.

Instead, what they do is more involved:

■ For distribute lists in the out direction: All outgoing Updates, Queries, Replies, SIA-

Queries, and SIA-Replies will indicate the correct metric for permitted prefixes and

infinite metric for denied prefixes.

ptg13046388

444 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ For distribute lists in the in direction: In all incoming Updates, Replies, and SIA-

Replies, permitted prefixes are processed normally while denied prefixes are ignored.

Received Queries and SIA-Queries are not influenced by the distribute list and are

processed without modification.

EIGRP Offset Lists

EIGRP offset lists allow EIGRP to add to a route’s metric, either before sending an update

or for routes received in an update. The offset list refers to an ACL (standard, extended,

or named) to match the routes; any matched routes have the specified offset , or extra

metric, added to their Delay metric component. Any routes not matched by the offset list

are unchanged. The offset list also specifies which routing updates to examine by speci-

fying a direction (in or out) and, optionally, an interface. If the interface is omitted from

the command, all updates for the defined direction will be examined.

Offset lists are much more applicable to RIP than EIGRP because RIP has such a limited

metric range. With EIGRP, because of the metric’s complexity, it is doubtful that you

would manipulate EIGRP metrics this way. Because several other filtering methods and

ways to influence EIGRP metrics are available, offset lists see limited use in EIGRP and

are therefore not covered in more detail in this chapter.

Clearing the IP Routing Table

The clear ip route * command clears the IP routing table. However, because EIGRP keeps

all possible routes in its topology table, a clear ip route * command does not cause

EIGRP to send any messages or learn any new topology information; the router simply

refills the IP routing table with the best routes from the existing topology table.

The clear eigrp address-family { ipv4 | ipv6 } neighbors command can be used to clear

all neighbor relationships and have the router reestablish them from scratch. An optional

soft keyword allows for a graceful restart, in which the topology databases between the

router and its neighbors are resynchronized but the adjacencies are not torn down.

ptg13046388

Chapter 8: EIGRP 445

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter, as well as review items noted with a Key Topic icon.

Table 8-5 lists some of the most popular Cisco IOS commands related to the topics in this

chapter.

Table 8-5 Command Reference for Chapter 8

Command Command Mode and Description

[ipv6] router eigrp as-number

router eigrp name

Global config; puts user in EIGRP classic

configuration mode (first command) or

in named configuration mode (second

command).

eigrp upgrade-cli name EIGRP classic mode. Automatically converts

the classic configuration to the named

configuration using the entered name as the

process name.

address-family { ipv4 | ipv6 } [ vrf vrf-name ]

autonomous-system as-number

Named EIGRP mode, creates an instance for

a particular address family and configures it

with an autonomous system number.

af-interface { default | interface-type

interface-number }

Named EIGRP mode, address family

instance. Holds per-interface EIGRP settings.

topology { base | topology-name tid

number }

Named EIGRP mode, address family

instance. Holds EIGRP settings for a

particular routing topology.

eigrp router-id EIGRP classic config mode or address family

named mode. Configures RID manually.

eigrp stub [receive-only] | { [ leak-map

name ] [connected] [static] [summary]

[redistributed] }

EIGRP classic config mode or address family

named mode. Designates the router as a stub

router.

network ip-address [ wildcard-mask ] EIGRP classic config mode or IPv4 address

family named mode; defines matching

parameters, compared to interface IP

addresses, to pick interfaces on which to

enable EIGRP.

ipv6 eigrp as-number Interface subcommand; activates interface

for IPv6 EIGRP. Used only in classic mode

config.

ptg13046388

446 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Command Mode and Description

[no] {ip | ipv6} split-horizon eigrp

autonomous-system

[no] split-horizon

Interface subcommand; enables or disables

Split Horizon. The first form is used in the

classic mode configuration. The second form

is used in the af-interface section in named

mode.

[no] passive-interface [ default ] { interface-

type interface-number }

[no] passive-interface

EIGRP config mode; causes EIGRP to stop

sending and processing EIGRP packets on

the specified interface, or enables them again.

The first form is used in the classic mode

configuration. The second form is used in the

af-interface section in named mode.

[no] shutdown EIGRP named mode, valid in the router

eigrp section, particularly the address family

section or af-interface section. Deactivates

or activates the EIGRP operation within the

defined scope.

{ip | ipv6} hello-interval eigrp as-number

seconds

hello-interval seconds

Interface subcommand; sets the interval

for periodic Hellos sent by this interface.

The first form is used in the classic mode

configuration. The second form is used in the

af-interface section in named mode.

{ip | ipv6} hold-time eigrp as-number

seconds

hold-time seconds

Interface subcommand; sets the countdown

timer to be used by a router’s neighbor when

monitoring for incoming EIGRP messages

from this interface. The first form is used in

the classic mode configuration. The second

form is used in the af-interface section in

named mode.

[no] auto-summary EIGRP classic config mode or per-AF-

topology named mode; enables or disables

automatic summarization at classful network

boundaries.

{ip | ipv6} summary-address eigrp

as-number prefix [ admin-distance ] [ leak-

map name ]

summary-address prefix [ admin-distance [

leak-map name ] ]

Interface subcommand; configures the

manual summarization and optional route

leaking. The first form is used in the classic

mode configuration. The second form is used

in the af-interface section in named mode.

summary-metric prefix { Bandwidth

Delay Reliability Load MTU [ distance

administrative-distance ] | distance

administrative-distance }

Named EIGRP mode, per-AF-topology

section. Defines a constant advertised metric

for an advertised summary route, optionally

also modifying the corresponding discard

route’s administrative distance.

ptg13046388

Chapter 8: EIGRP 447

Command Command Mode and Description

metric weights 0 k 1

k 2

k 3

k 4

k 5

[ k 6

] EIGRP classic config mode or per-AF-

topology named mode; defines the per-

ToS K-values to be used in EIGRP metric

calculations; however, only ToS 0 is

supported.

metric rib-scale scale-value EIGRP address family named mode. Defines

a scaling value to downscale the computed

wide metrics into a metric value offered to

RIB.

{ip | ipv6} bandwidth-percent eigrp

as-number percent

bandwidth-percent percent

Interface subcommand; defines the maximum

percentage of interface bandwidth to be used

for EIGRP messages. The first form is used in

the classic mode configuration. The second

form is used in the af-interface section in

named mode.

{ip | ipv6} authentication mode eigrp

as-number md5

authentication mode { md5 | hmac-sha-256

password }

Enables authentication of EIGRP packets.

The first form is used directly on an interface

for classic configuration mode, and allows

only for MD5 authentication. The second

form is used in the af-interface section

in named mode, and allows choosing the

hashing algorithm. The password for SHA-

256 is used only if no key chain is specified.

{ip | ipv6} authentication key-chain eigrp

as-number key-chain-name

authentication key-chain key-chain-name

Specifies the authentication key chain for

EIGRP. The first form is used directly on an

interface for classic configuration mode. The

second form is used in af-interface section in

named mode.

[no] {ip | ipv6} split-horizon eigrp

as-number

[no] split-horizon

Interface subcommand; allows activating or

deactivating the Split Horizon mechanism.

The first form is used in the classic mode

configuration. The second form is used in the

af-interface section in named mode.

[no] {ip | ipv6} next-hop-self eigrp

as-number

[no] next-hop-self

Interface subcommand; allows or prevents

the router from asserting itself as the next

hop in routes readvertised over the interface.

The first form is used in the classic mode

configuration. The second form is used in the

af-interface section in named mode.

add-paths path-count Named EIGRP mode,

af-interface section.

Allows the router to advertise up to four

additional equal-cost paths.

ptg13046388

448 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Command Mode and Description

variance multiplier EIGRP classic config mode or per-AF-

topology named mode. Allows the router

to use worse paths over Feasible Successors

whose metric is up to multiplier times worse

than the current best-path metric.

neighbor { ip-address | ipv6-address }

interface-type interface-number [ remote

maximum-hops [ lisp-encap [ lisp-id ] ] ]

EIGRP classic config mode or address family

named mode. Specifies a static neighbor.

OTP-related keywords are available only in

named mode.

remote-neighbors source interface-type

interface-number { multicast-group group-

address | unicast-listen lisp-encap [ lisp-top-

id ] } [ allow-list access-list-name ] [ max-

neighbor max-remote-peers ]

EIGRP address family named mode. Defines

dynamic remote neighbor discovery, required

for OTP route reflector functionality.

distribute-list { access-list-number | name } {

in | out } [ interface-type interface-number ]

EIGRP classic config mode or per-AF-

topology named mode. Specifies an access

list for filtering routing updates to/from the

EIGRP topology table.

distribute-list prefix prefix-list-name { in |

out } [ interface-type interface-number ]

EIGRP classic config mode or per-AF-

topology named mode. Specifies a prefix

list for filtering routing updates to/from the

EIGRP topology table.

timers active-time [ time-limit |

disabled ]

EIGRP classic config mode or per-AF-

topology named mode; sets the time limit for

how long a route is in the active state before

becoming stuck-in-active.

show {ip | ipv6} eigrp topology [ vrf vrf-

name | as-number | network [ mask ] | prefix

pending | summary | zero-successors ]

show eigrp address-family { ipv4 | ipv6 }

[ vrf vrf-name ] [ as-number ] [multicast]

interfaces [detail] [ interface-type interface-

number ]

User mode; lists different parts of the EIGRP

topology table, depending on the options

used.

show ip eigrp [ vrf vrf-name ] [ as-number ]

interfaces [ detail ] [ type number ]

show eigrp address-family { ipv4 | ipv6 }

[ vrf vrf-name ] [ as-number ] [multicast]

interfaces [detail] [ interface-type interface-

number ]

User mode; lists EIGRP protocol timers and

statistics per interface.

ptg13046388

Chapter 8: EIGRP 449

Command Command Mode and Description

show {ip | ipv6} eigrp traffic [ as-number ]

show eigrp address-family { ipv4 | ipv6 }

[ vrf vrf-name ] [ as-number ] [multicast]

traffic

User mode; displays EIGRP traffic statistics.

show {ip | ipv6} protocols User mode; lists EIGRP timer settings,

current protocol status, automatic

summarization actions, and update sources.

show {ip | ipv6} eigrp [ as-number ] neighbors

show eigrp address-family { ipv4 | ipv6 }

[ vrf vrf-name ] [ as-number ] [multicast]

neighbors [static] [detail] [ interface-type

interface-number ]

User mode; lists EIGRP neighbors.

clear ip eigrp [ vrf vrf-name [ as-number ]

| as-number ] neighbors [ ip-address |

interface-type interface-number ] [soft]

Privileged mode; drops current neighbor

adjacencies, removing topology table

entries associated with each neighbor. The

soft keyword causes the router to perform

resynchronization with neighbors without

dropping adjacencies.

show ip interface [ type number ] User mode; lists many interface settings,

including Split Horizon.

Table 8-6 summarizes the types of EIGRP packets and their purposes.

Table 8-6 EIGRP Message Summary

EIGRP Packet Purpose

Hello Identifies neighbors, exchanges parameters, and is sent periodically as a

keepalive function

Ack Acknowledges Update, Query, Reply, SIA-Query, and SIA-Reply packets

Update Informs neighbors about updated routing information

Query Asks neighboring routers to update their routing tables in a coordinated

fashion and respond with their actual distance after having their routing

tables updated

Reply Sent by neighbors to reply to a Query, informing the router about

the actual neighbor’s distance to the destination after processing the

information in the Query

SIA-Query Asks a particular neighbor whose Reply to a Query packet is outstanding for

a prolonged time to confirm whether it is still working on this router’s Query

SIA-Reply Sent by a neighbor as a response to an SIA-Query to ascertain its state

ptg13046388

450 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Fill In Key Tables from Memory

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD, to check your answers.

Definitions

Next, take a few moments to write down the definitions for the following terms:

hello interval, full update, partial update, MD5, DUAL, Hold timer, K-value, neigh-

bor, adjacency, RTP, SRTT, RTO, Update, Ack, Query, Reply, Hello, Goodbye, RD,

FD, feasibility condition, successor route, Feasible Successor, input event, local

computation, active, passive, going active, stuck-in-active, query scope, EIGRP stub

router, limiting query scope, variance, Named Mode

Refer to the glossary to check your answers.

Further Reading

Jeff Doyle’s Routing TCP/IP , Volume I, Second Edition (Cisco Press), has several excel-

lent examples of configuration, as well as several examples of the DUAL algorithm and

the Active Query process.

EIGRP Network Design Solutions , by Ivan Pepelnjak, contains wonderfully complete

coverage of EIGRP. It also has great, detailed examples of the Query process.

draft-savage-eigrp , an Internet draft available through Internet Engineering Task Force

web pages, documents the open parts of the protocol.

The CCIE Routing and Switching v5.0 exam blueprint also mentions the EIGRP IP Fast

Reroute feature. More information about it can be found on the Cisco website in the

IP Routing EIGRP Configuration Guide for Cisco IOS Release 15S, specifically in

the “EIGRP Loop-Free Alternate Fast Reroute” section. Also, many Cisco Live! ses-

sions cover this feature, including “IP LFA (Loop-Free-Alternative): Architecture and

Troubleshooting” (BRKRST-3020) and “Routed Fast Convergence” (BRKRST-3363), avail-

able at www.ciscolive365.com. At the time of writing, this feature was supported only on

service provider IOS, IOS-XE, and IOS-XR image builds and will not be present on the

Lab exam. The Written exam might cover general properties of this feature.

ptg13046388

This page intentionally left blank

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ Packet Types

■ LSA Types

■ Route Types

■ Neighbor Relationship and Database

Synchronization

■ Network Types, Area Types, and Router Types

■ Path Preference

■ M e t r i c s

■ SPF Tuning

ptg13046388

This chapter covers Open Shortest Path First (OSPF), one of the two link-state routing

protocols covered by the CCIE Routing and Switching exam blueprint. As with the other

routing protocol chapters, this chapter includes most of the features, concepts, and com-

mands related to OSPF. Chapter 11 , “IGP Route Redistribution, Route Summarization,

Default Routing, and Troubleshooting,” covers a few other details of OSPF, in particular,

route redistribution, route filtering in redistribution, and route summarization.

“Do I Know This Already?” Quiz

Table 9-1 outlines the major sections in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 9-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section Questions Covered in This

Section

S c o r e

OSPF Database Exchange 1 – 5

OSPF Design and LSAs 6 – 9

OSPF Configuration 10 – 12

OSPFv3 13 – 16

Total Score

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. R1 has received an OSPF LSU from R2. Which of the following methods can be

used by R1 to acknowledge receipt of the LSU from R2?

a. TCP on R1 acknowledges using the TCP Acknowledgment field.

b. R1 sends back an identical copy of the LSU.

c. R1 sends back an LSAck to R2.

d. R1 sends back a DD packet with LSA headers whose sequence numbers match

the sequence numbers in the LSU.

CHAPTER 9

OSPF

ptg13046388

454 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

2. Fredsco has an enterprise network with one core Frame Relay connected router, with

a hub-and-spoke network of PVCs connecting to ten remote offices. The network

uses OSPF exclusively. The core router (R-core) has all ten PVCs defined under mul-

tipoint subinterface s0/0.1. Each remote router also uses a multipoint subinterface.

Fred, the engineer, configures an ip ospf network non-broadcast command under

the subinterface on R-core and on the subinterfaces of the ten remote routers. Fred

also assigns an IP address to each router from subnet 10.3.4.0/24, with R-core using

the .100 address, and the remote offices using .1 through .10. Assuming that all other

related options are using defaults, which of the following would be true about this

network?

a. The OSPF hello interval would be 30 seconds.

b. The OSPF dead interval would be 40 seconds.

c. The remote routers could learn all routes to other remote routers’ subnets, but

only if R-core became the designated router.

d. No designated router will be elected in subnet 10.3.4.0/24.

3. Which of the following interface subcommands, used on a multipoint Frame Relay

subinterface, creates a requirement for a DR to be elected for the attached subnet?

a. ip ospf network point-to-multipoint

b. ip ospf network point-to-multipoint non-broadcast

c. ip ospf network non-broadcast

d. None of these answers is correct.

4. The following routers share the same LAN segment and have the stated OSPF set-

tings: R1: RID 1.1.1.1, hello 10, priority 3; R2: RID 2.2.2.2, hello 9, priority 4; R3, RID

3.3.3.3, priority 3; and R4: RID 4.4.4.4, hello 10, priority 2. The LAN switch fails

and recovers, and all routers attempt to elect an OSPF DR and form neighbor rela-

tionships at the same time. No other OSPF-related parameters were specifically set.

Which of the following are true about negotiations and elections on this LAN?

a. R1, R3, and R4 will expect Hellos from R2 every 9 seconds.

b. R2 will become the DR but have no neighbors.

c. R3 will become the BDR.

d. R4’s dead interval will be 40 seconds.

e. All routers will use R2’s hello interval of 9 after R2 becomes the designated

router.

ptg13046388

Chapter 9: OSPF 455

5. Which of the following must be true for two OSPF routers that share the same LAN

data link to be able to become OSPF neighbors?

a. Must be in the same area

b. Must have the same LSRefresh setting

c. Must have differing OSPF priorities

d. Must have the same Hello timer, but can have different dead intervals

6. R1 is an OSPF ASBR that injects an E1 route for network 200.1.1.0/24 into the OSPF

backbone area. R2 is an ABR connected to area 0 and to area 1. R2 also has an

Ethernet interface in area 0, IP address 10.1.1.1/24, for which it is the designated

router, and has established OSPF adjacencies over this interface with other rout-

ers. R3 is a router internal to area 1. Enough links are up and working for the OSPF

design to be working properly. Which of the following are true regarding this topol-

ogy? (Assume that no other routing protocols are running, and that area 1 is not a

stub area.)

a. R1 creates a type 7 LSA and floods it throughout area 0.

b. R3 will not have a specific route to 200.1.1.0/24.

c. R2 forwards the LSA that R1 created for 200.1.1.0/24 into area 1.

d. R2 will create a type 2 LSA for subnet 10.1.1.0/24 and flood it throughout

area 0.

7. R1 is an OSPF ASBR that injects an E1 route for network 200.1.1.0/24 into the

OSPF backbone area. R2 is an ABR connected to area 0 and to area 1. R2 also has

an Ethernet interface in area 0, IP address 10.1.1.1/24, for which it is the designated

router but there are no other OSPF routers on the segment. R3 is a router internal to

area 1. Enough links are up and working for the OSPF design to be working properly.

Which of the following are true regarding this topology? (Assume that no other

routing protocols are running, and that area 1 is a totally NSSA.)

a. R3 could inject external routes into the OSPF domain.

b. R3 will not have a specific route to 200.1.1.0/24.

c. R2 forwards the LSA that R1 created for 200.1.1.0/24 into area 1.

d. R2 will create a type 2 LSA for subnet 10.1.1.0/24 and flood it throughout

area 0.

ptg13046388

456 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

8. The routers in area 55 all have the area 55 stub no-summary command configured

under the router ospf command. OSPF has converged, with all routers in area 55

holding an identical link-state database for area 55. All IP addresses inside the area

come from the range 10.55.0.0/16; no other links outside area 55 use addresses in this

range. R11 is the only ABR for the area. Which of the following is true about this

design?

a. The area is a stubby area.

b. The area is a totally stubby area.

c. The area is an NSSA.

d. ABR R11 is not allowed to summarize the type 1 and 2 LSAs in area 55 into the

10.55.0.0/16 prefix because of the no-summary keyword.

e. Routers internal to area 55 can have routes to specific subnets inside area 0.

f. Routers internal to area 55 can have routes to E1, but not E2, OSPF routes.

9. R1 is an OSPF ASBR that injects an E1 route for network 200.1.1.0/24 into the OSPF

backbone area. R2 is an ABR connected to area 0 and to area 1. R2 also has an

Ethernet interface in area 0, IP address 10.1.1.1/24, for which it is the designated

router. R3 is a router internal to area 1. Enough links are up and working for the

OSPF design to be working properly. Which of the following are true regarding this

topology? (Assume that no other routing protocols are running, and that area 1 is

not a stubby area.)

a. R3’s cost for the route to 200.1.1.0 will be the cost of the route as it was injected

into the OSPF domain by R1, without considering any internal cost.

b. R3’s cost for the route to 200.1.1.0 will be the cost of reaching R1, plus the

external cost listed in the LSA.

c. R3’s cost for the route to 10.1.1.0/24 will be the same as its cost to reach

ABR R2.

d. R3’s cost for the route to 10.1.1.0/24 will be the sum of its cost to reach ABR R2

plus the cost listed in the type 3 LSA created for 10.1.1.0/24 by ABR R2.

e. It is impossible to characterize R3’s cost to 10.1.1.0/24 because R3 uses a sum-

mary type 3 LSA, which hides some of the costs.

ptg13046388

Chapter 9: OSPF 457

10. R1 and R2 each connect through Fast Ethernet interfaces to the same LAN, which

should be in area 0. R1’s IP address is 10.1.1.1/24, and R2’s is 10.1.1.2/24. The only

OSPF-related configuration is as follows:

hostname R1

router ospf 1

network 0.0.0.0 255.255.255.255 area 0

auto-cost reference-bandwidth 1000

hostname R2

router ospf 2

network 10.0.0.0 0.0.0.255 area 0

Which of the following statements are true about the configuration?

a. The network command on R2 does not match IP address 10.1.1.2, so R2 will not

attempt to send Hellos or discover neighbors on the LAN.

b. The different process IDs in the router ospf command will prevent the two rout-

ers from becoming neighbors on the LAN.

c. R2 will become the DR as a result of having a cost of 1 associated with its Fast

Ethernet interface.

d. R1 and R2 could never become neighbors because of the difference in cost

values.

e. R1’s OSPF cost for its Fast Ethernet interface would be 10.

11. Which of the following are true about setting timers with OSPF?

a. The ip ospf dead-interval minimal hello-multiplier 4 interface subcommand

sets the hello interval to 4 ms.

b. The ip ospf dead-interval minimal hello-multiplier 4 interface subcommand

sets the dead interval to 4 seconds.

c. The ip ospf dead-interval minimal hello-multiplier 4 interface subcommand

sets the hello interval to 250 ms.

d. On all interfaces, the ip ospf hello-interval 30 interface subcommand changes

the hello interval from 10 to 30.

e. The ip ospf hello-multiplier 5 interface subcommand sets the dead interval to

five times the then-current hello interval.

f. Cisco IOS defaults the hello and dead intervals to 30/120 on interfaces using the

OSPF nonbroadcast network type.

ptg13046388

458 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

12. R1 has been configured for OSPF authentication on its Fa0/0 interface as shown

here. Which of the following is true about the configuration?

interface Fa0/0

ip ospf authentication-key hannah

ip ospf authentication

ip ospf message-digest-key 2 md5 jessie

router ospf 2

area 0 authentication message-digest

a. R1 will attempt simple-text authentication on the LAN with key hannah .

b. R1 will attempt MD5 authentication on the LAN with key jessie .

c. R1 will attempt OSPF type 2 authentication on Fa0/0.

d. R1 will attempt OSPF type 3 authentication on Fa0/0.

13. Which of the following statements about OSPFv3 are true?

a. Type 1 and 2 LSAs do not carry addressing information.

b. OSPFv3 messages are encapsulated directly into Layer 2 frames.

c. OSPFv3 uses 128-bit Router IDs.

d. There are three flooding scopes defined for OSPFv3 LSAs: link, area, and AS.

e. Multiple OSPFv3 instances can run over a single link.

f. OSPFv3 implements its own authentication mechanisms.

14. Which statements are true about Link LSA and Intra-Area-Prefix LSA in OSPFv3?

a. Link LSAs have AS flooding scope.

b. Intra-Area-Prefix LSAs have area flooding scope.

c. Link LSAs carry information about link-local addresses.

d. Intra-Area-Prefix LSAs carry information about global prefixes.

e. When an updated Link or Intra-Area-Prefix LSA is flooded, a router is required

to schedule a full SPF run.

f. Link and Intra-Area-Prefix LSAs have entirely replaced the Router and Network

LSAs.

15. How does OSPFv3 handle authentication?

a. OSPFv3 implements its own authentication and encryption mechanisms.

b. SSL/TLS is used by OSPFv3 to provide authentication and encryption.

c. OSPFv3 relies on IPsec to authenticate and encrypt its packets.

d. OSPFv3 makes use of ISAKMP/IKE protocols to negotiate authentication and

encryption parameters between routers.

e. The use of AH and ESP is mutually exclusive in OSPFv3.

ptg13046388

Chapter 9: OSPF 459

16. Which statements are true about address family support in OSPFv3?

a. When running multiple address families, a single link-state database on a router

holds information from all address families.

b. Each address family is run as a separate OSPFv3 instance, keeping all its data

and state separate.

c. Multiple address families are distinguished by separate OSPFv3 process IDs.

d. Running IPv4 and IPv6 address families simultaneously under a single OSPFv3

process will result in a significantly smaller memory footprint than running a

separate IPv4 OSPFv2 and IPv6 OSPFv3 process.

e. Type 8 and 9 LSAs are reused to carry both IPv4 and IPv6 prefixes.

f. Even if running OSPFv3 for IPv4 address family, interfaces must be configured

for IPv6 connectivity.

ptg13046388

460 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Foundation Topics

Link-state routing protocols define the content and structure of data that describes net-

work topology, and define the processes by which routers exchange that detailed topol-

ogy information. The name “link state” refers to the fact that the topology information

includes information about each data link , along with each link’s current operational

state . All the topological data together comprises the link-state database (LSDB) . Each

link-state router applies the Dijkstra algorithm to the database to calculate the current

best routes to each subnet.

This chapter breaks down the OSPF coverage into three major sections. The first section

details how the topology data is exchanged. The second section covers OSPF design

and the contents of the LSDB, which comprises different types of link-state advertise-

ments (LSA) . (The second section covers both design and the LSDB because the design

choices directly impact which types of LSAs are forwarded into the differing parts of an

OSPF network.) The third section covers the majority of the OSPF configuration details

of OSPF for this chapter, although a few configuration topics are interspersed in the first

two sections.

OSPF Database Exchange

OSPF defines five different messages that routers can use to establish adjacencies and

exchange routing information. The process by which LSAs are exchanged does not

change whether a single area or multiple areas are used, so this section will use a single

OSPF area (area 0).

OSPF Router IDs

Before an OSPF router can send any OSPF messages, it must choose a unique 32-bit iden-

tifier called the OSPF router identifier (RID) . Cisco routers use the following sequence

to choose their OSPF RID, only moving on to the next step in this list if the previous step

did not supply the OSPF RID:

1. Use the router ID configured in the router-id id subcommand under router ospf .

2. Use the highest numeric IP address on any currently nonshutdown loopback inter-

face that has not yet been allocated as a RID by any other OSPF process.

3. Use the highest numeric IP address on any currently nonshutdown, nonloopback

interface that has not yet been allocated as a RID by any other OSPF process.

The sequence and logic are very simple, but some details are hidden in the sequence:

■ Multiple OSPF processes running on a single router try to choose unique RIDs. Each

of the OSPF processes performs the same three steps to choose a RID, skipping IP

addresses that have already been used as RIDs by other OSPF processes running on

the router.

Key

Topic

ptg13046388

Chapter 9: OSPF 461

■ The interface from which the RID is taken does not have to be matched by an OSPF

network command.

■ It is sufficient for the interface to be in the down/down state to be considered by

OSPF as a prospective interface for RID selection.

■ OSPF does not have to advertise a route to reach the RID’s subnet.

■ The RID does not have to be reachable per the IP routing table.

■ Steps 2 and 3 look at the then-current interface state to choose the RID when the

OSPF process is started.

■ Routers consider changing the OSPF RID when the OSPF process is restarted, or

when the RID is changed through configuration.

■ If a router’s RID changes, the rest of the routers in the same area will have to perform

a new SPF calculation, even if the network topology has not changed. The reason is

that a RID change is indistinguishable from a process of replacing one router with

another.

■ If the RID is configured with the router-id command, and the command remains

unchanged, that router’s RID will never change.

For these reasons, many people set their RIDs with the router-id command and use an

obvious numbering scheme to make it easy to identify a router by its RID.

Becoming Neighbors, Exchanging Databases, and Becoming Adjacent

OSPF directly encapsulates the five different types of OSPF messages inside IP packets,

using IP protocol 89, as listed in Table 9-2 .

Table 9-2 OSPF Messages

Message Description

Hello Used to discover neighbors, bring a neighbor

relationship to a 2-Way state, and monitor a

neighbor’s continuous liveliness

Database Description (DD or DBD) Used to exchange LSA headers during the initial

topology exchange, so that a router knows a list of

that neighbor’s LSAs including their versions

Link-State Request (LSR) A packet that identifies one or more LSAs about

which the sending router would like the neighbor to

supply full details about the LSAs

Link-State Update (LSU) A packet that contains fully detailed LSAs, sent in

response to an LSR message or in the event of a

topological change

Link-State Acknowledgment (LSAck) Sent to confirm receipt of an LSU message

Key

Topic

ptg13046388

462 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

These messages together allow routers to discover each other’s presence (Hello), learn

which LSAs are missing from their LSDBs (DD), request and reliably exchange the LSAs

(LSR/LSU/LSAck), and monitor their neighbors for any changes in the topology (Hello).

Note that the LSAs themselves are not OSPF messages. An LSA is a data structure, held

inside a router’s LSDB and exchanged inside LSU messages.

When a particular data link first comes up, OSPF routers first become neighbors using

the Hello message. At that point, they exchange topology information using the other

four OSPF messages. Figure 9-1 outlines the overall process between two routers.

Init

2-way

ExStart

DR Election,

if needed

DR Election,

if needed

Exchange

Full

Hello, Seen [null], RID 1.1.1.1

RID 1.1.1.1 RID 2.2.2.2

Hello, Seen [1.1.1.1], RID 2.2.2.2

Hello, Seen [1.1.1.1, 2.2.2.2], RID 1.1.1.1

Hello, DR=z.z.z.z

DD (LSA Headers)

LSR, LSU, LSAck (Full LSAs)

Neighbor State

Down

(R1 to R2 Link comes up ...)

Init

2-way

ExStart

Exchange

Full

Neighbor State

Down

R1 R2

Figure 9-1 Overview of OSPF LSDB Exchange

Figure 9-1 shows the overall message flow, along with the neighbor state on each router.

An OSPF router keeps a state machine for each neighbor, listing the current neighbor

state in the output of the show ip ospf neighbor command. These neighbor states change

as the neighbors progress through their messaging; in this example, the neighbors settle

into a full state , meaning fully adjacent , when the process is completed.

The “Foundation Summary” section at the end of this chapter includes a reference table

( Table 9-14 ) listing the neighbor states and their meanings. The next few sections explain

the details behind the process shown in Figure 9-1 .

OSPF Neighbor States

OSPF routers go through a series of adjacency states when establishing a relation. Some

of these states are transitory, reflecting different stages of building an adjacency, while

ptg13046388

Chapter 9: OSPF 463

some of them are stable states in which routers can, in the absence of topological

changes, remain for an unlimited period of time. The knowledge of these states is crucial

for proper understanding of OSPF adjacency buildup and troubleshooting.

Before diving into the details, it is important to note that these states are in fact neighbor

states—they indicate how a router treats its particular neighbor. Although sometimes

popularly described as adjacency states, these states do not reflect the state of the entire

adjacency but rather a state of a particular router’s neighbor in this adjacency. Two routers

building an adjacency can temporarily, though validly, consider each other to be in a dif-

ferent state (for example, one router might consider the other to be in the Loading state

while the other might consider the first one to be already in the Full state). Ultimately,

however, both routers must arrive at the same state.

■ Down: This is the initial state for a neighbor. This state is mostly seen when a work-

ing adjacency to a neighbor is torn down (for example, because no valid OSPF

packets have been received during the Dead interval), or when a manually configured

neighbor does not respond to our initial Hello packets. Note that having a neighbor

in the Down state implies that the router already knows about this neighbor’s IP

address.

■ Attempt: This state is valid only on nonbroadcast multiaccess (NBMA) and point-

to-multipoint nonbroadcast networks. On these networks, a neighbor is immediately

placed into the Attempt state and contacted by Hello packets sent at usual intervals.

If, however, the neighbor does not respond within the Dead interval, it will be placed

back into the Down state, and contacted at a (possibly) reduced rate.

■ Init: A neighbor is placed into the Init state if a valid Hello packet has been received

from it but the list of seen routers in this Hello packet does not contain the receiving

router’s RID. This means that this router can hear the other router but it is not certain

whether the other router can hear this router.

■ 2-Way: A neighbor is placed into the 2-Way state if a valid Hello packet has been

received from it and the list of seen routers in this Hello packet includes the receiving

router’s RID. This state confirms a bidirectional visibility between the two routers.

The 2-Way is a stable state between routers on multiaccess networks that do not

intend to become fully adjacent.

■ ExStart: A neighbor is moved from Init or 2-Way into the ExStart state if the bidi-

rectional visibility has been confirmed and it is decided that this router shall become

fully adjacent to it. The purpose of the ExStart state is to establish the Master/Slave

relationship. In the ExStart state, routers exchange empty Database Description

packets to compare their Router IDs, determine the Master and Slave roles for each

router, and agree on a common starting sequence number used to acknowledge sub-

sequent Database Description packets used in the Exchange state.

■ Exchange: A neighbor is moved from ExStart to Exchange state after the Master/

Slave relationship has been established. During the Exchange state, Database

Description packets are exchanged between the routers carrying the list of link-state

database elements (that is, LSAs) known by each router. During the Exchange state,

Key

Topic

ptg13046388

464 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

each router builds a list of LSAs to be subsequently downloaded from the other

router.

■ Loading: A neighbor is moved from the Exchange to Loading state after it has adver-

tised the complete list of LSAs and this router needs to download some of the LSAs

from the neighbor. The neighbor is kept in the Loading state during the LSA down-

load.

■ Full: A neighbor is moved from the Exchange or Loading state to the Full state when

all required LSAs have been downloaded from the neighbor, so all missing or out-

dated LSAs have been acquired. The Full state is a stable state between routers that

have become fully adjacent.

Becoming Neighbors: The Hello Process

Hello messages perform four major functions:

■ Discover other OSPF-speaking routers on common subnets

■ Check for agreement on selected configuration parameters

■ Verify bidirectional visibility between routers

■ Monitor health of the neighbors to react if the neighbor fails

To discover neighbors, Cisco OSPF routers listen for multicast Hello messages sent to

224.0.0.5—the All OSPF Routers multicast address—on any interfaces that have been

enabled for OSPF. The Hellos are sourced from that router’s primary IP address on the

interface; in other words, Hellos are not sourced from secondary IP addresses. (OSPF

routers will advertise secondary IP addresses, but they will not send Hellos from those

IP addresses, and never form neighbor relationships using secondary addresses. This

holds for EIGRP and RIP as well.) Furthermore, OSPF neighbors will become fully adja-

cent if one or both of the neighbors are using unnumbered interfaces for the connection

between them.

After two routers discover each other by receiving Hellos from the other router, the rout-

ers perform the following parameter checks based on the receive Hellos:

■ Must pass the authentication process

■ Must be in the same primary subnet, including the same subnet mask

■ Must be in the same OSPF area

■ Must be of the same area type (regular, stub, not-so-stubby area [NSSA])

■ Must not have duplicate RIDs

■ OSPF Hello and Dead timers must be equal

If any of these items do not match, the two routers simply do not form a neighbor

relationship. Also of note is one important item that does not have to match: the OSPF

Key

Topic

ptg13046388

Chapter 9: OSPF 465

process ID (PID), as configured in the router ospf process-id command. Be aware of the

fact that the maximum transmission unit (MTU) must be equal for the DD packets to be

successfully processed between neighbors, but this parameter check is technically not

part of the Hello process. The MTU mismatch would negatively affect the database syn-

chronization process in the ExStart and Exchange phases, but it would not prevent rout-

ers from becoming successful neighbors up to and including the 2-Way state.

The third function of Hello packets is to verify bidirectional visibility between routers on

the same segment. Each Hello packet contains a list of neighbors from whom the sending

router received valid and acceptable Hellos. This list of variable size is located in the trail-

ing part of each Hello and contains RIDs of routers whose Hellos were seen and accepted

by the router originating this Hello. If a router finds its own RID in the list of seen routers

in a Hello received from a neighbor, it can be sure that they can hear each other.

Finally, the fourth important function for a Hello is to maintain a heartbeat function

between neighbors. The neighbors send Hellos every hello interval ; failure to receive

a Hello within the longer dead interval causes a router to believe that its neighbor has

failed. The hello interval defaults to 10 seconds on interfaces with an OSPF broadcast or

point-to-point network type, and 30 seconds on interfaces with an OSPF nonbroadcast

or point-to-multipoint network type; the dead interval defaults to four times the hello

interval.

Example 9-1 lists some basic OSPF command output related to the neighbor establish-

ment with Hellos, and the hello and dead intervals.

Example 9-1 Hello Mismatches and Basic Neighbor Parameters

! Below, debug messages show that this router disagrees with the hello and dead

! intervals on router 10.1.111.4; The "C" and "R" mean "configured" and "received,"

! respectively, meaning that this router uses 30/120 for hello/dead, and the other

! router is trying to use 10/40.

R1# debug ip ospf hello

OSPF hello events debugging is on

Jan 12 06:41:20.940: OSPF: Mismatched hello parameters from 10.1.111.4

Jan 12 06:41:20.940: OSPF: Dead R 40 C 120, Hello R 10 C 30 Mask R 255.255.255.0 C

255.255.255.0

! Below, R1's hello and dead intervals are listed for the same interface.

R1# show ip ospf int s 0/0.100

Serial0/0.100 is up, line protocol is up

Internet Address 10.1.111.1/24, Area 0

Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64

Transmit Delay is 1 sec, State DR, Priority 1

Designated Router (ID) 1.1.1.1, Interface address 10.1.111.1

No backup designated router on this network

ptg13046388

466 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

! Lines omitted for brevity

! Below, R1 shows a neighbor on S0/0.100, in the full state, meaning the routers

! have completed LSDB exchange. Note the current Dead timer counts down, in this

! case from 2 minutes; the value of 1:58 means R1 last received a Hello from

! neighbor 10.1.111.6 two seconds ago.

R1# sh ip ospf neighbor 6.6.6.6

Neighbor 6.6.6.6, interface address 10.1.111.6

In the area 0 via interface Serial0/0.100

Neighbor priority is 0, State is FULL, 8 state changes

DR is 10.1.111.1 BDR is 0.0.0.0

Poll interval 120

Options is 0x42

Dead timer due in 00:01:58

Neighbor is up for 00:17:22

! Lines omitted for brevity

Transmitting LSA Headers to Neighbors

When two routers hear Hellos, and the parameter check passes, they do not immedi-

ately send packets holding the LSAs. Instead, each router creates and sends Database

Description ( DD , or sometimes called DBD ) packets, which contain the headers of each

LSA. The headers include just enough information to uniquely identify each LSA and its

revision without transmitting its body. Essentially, the routers exchange an index list of

all the LSAs they each know about; the next step in the process is letting a router request

a new copy of only those LSAs it does not have or which are less recent.

The DD messages use an OSPF-defined simple error-recovery process. Each DD packet,

which can contain several LSA headers, has a sequence number assigned. The receiver

acknowledges a received DD packet by sending a DD packet with the identical sequence

number back to the sender. The sender uses a window size of one packet and then waits

for the acknowledgment before sending the next DD packet.

Database Description Exchange: Master/Slave Relationship

As a neighbor relationship forms between two routers (specifically, at the ExStart stage of

the neighborship), the neighbors determine which router is to be the master and which is

to be the slave during the database exchange between them. The roles of master and slave

define the responsibilities of routers during the exchange of DD packets. Only the mas-

ter is allowed to send DD packets on its own accord as well as to set and increase their

sequence numbers. A slave is allowed to send a DD packet only as a response to a DD

packet received from master router, and must use the same sequence number. In effect, a

slave is polled by the master and only responds to it.

ptg13046388

Chapter 9: OSPF 467

Among other fields, a DD packet header contains three flags:

■ Master (MS) flag: Set in all DD packets sent by the master, and cleared in all packets

sent by the slave

■ More (M) flag: Set when a router intends to send an additional DD packet after this

one

■ Init (I) flag: Indicates that this is the initial DD packet that starts the exchange, and

subsequent DD packets, either from master or slave, have the I flag cleared

The M flag requires further explanation. Before two routers synchronize their link-state

databases, the count of LSAs in their databases can considerably differ. One router might

hold hundreds or more LSAs in its database while the other might have just a handful of

them. During the DD packet exchange, one router might need to send many DD packets

while the other might be able to list all its known LSAs in a single DD packet. There are,

however, two rules to sending DD packets that must be observed at all times:

1. Each DD packet sent from the master must be replied to by the slave (that is, the

number of DD packets sent from master to slave must match the number of DD

packets sent from slave to master).

2. A slave can send a DD packet only as a response to receiving a master’s DD packet

(that is, without receiving a DD packet from master, a slave is not allowed to send a

DD packet on its own).

How shall these rules be obeyed if the routers have different counts of DD packets to

send?

Satisfying the first rule is actually very simple: If a router has no more LSA headers to

advertise but its peer requires it to send more DD packets, the router will simply send

empty DD packets.

Satisfying the second rule is really concerned about the slave letting the master know

whether it has more DD packets to send. If it does, the master must continue polling the

slave, even if it has no more LSAs to advertise itself. This is accomplished by the slave set-

ting the M flag in its DD packet sent in response to the master’s DD packet. If the master

receives a DD packet from the slave with the M flag set, it knows that the slave has at

least one more DD packet to send, so it must poll it again. A master will stop send send-

ing DD packets to a slave when it has no more LSA headers to advertise, and the slave’s

last received DD packet has the M flag cleared, indicating that the slave itself has adver-

tised its entire LSA list.

Apart from the slave setting the M flag to ask the master to poll it again, both master and

slave appropriately set the M flag in their DD packets to indicate when they have com-

pleted advertising their entire link-state database. This knowledge is necessary to move

the neighbor to the appropriate state, either Loading or Full, when the complete list of

LSAs in the neighbor’s database is known.

ptg13046388

468 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

In the beginning of the exchange, each router places the other into the ExStart state. Each

of them considers itself to be the master, and sends an empty DD packet to the other

router, containing a randomly chosen sequence number, and MS (Master), M (More), and

I (Init) flags set to 1. After receiving the neighbor’s DD packet, however, the router with

the lower RID will change its role to slave, and it will respond with a DD packet with

MS and I flags cleared and the sequence number set to the sequence number of master’s

DD packet. This accomplishes the master/slave selection, and both routers move to the

Exchange state. The master will then send a DD packet with the sequence number incre-

mented by 1, optionally containing one or more LSA headers, and the slave will respond

with a DD packet reusing the same sequence number from the received packet, option-

ally advertising its own LSA headers. The exchange continues in the same fashion, with

the master incrementing the sequence number of each subsequent DD packet, until both

routers have advertised all known all LSA headers (the master will stop sending DD pack-

ets when it has advertised all LSA headers itself and the last DD response from the slave

has the M flag cleared).

Requesting, Getting, and Acknowledging LSAs

After all LSA headers have been exchanged using DD packets, each neighboring router

has a list of LSAs known by the neighbor. Using that knowledge, a router needs to

request a full copy of each LSA that is missing from its own LSDB.

To know whether a neighbor has a more recent copy of a particular LSA, a router looks at

the sequence number of the LSA in its LSDB and compares it to the sequence number of

that same LSA learned from the DD packet. Each LSA’s sequence number is incremented

every time the LSA changes or is reoriginated. So, if a router received (through a DD

packet) an LSA header with a later sequence number for a particular LSA (as compared

with the LSA in the LSDB), that router knows that the neighbor has a more recent LSA.

For example, R1 sent R2 an LSA header for the type 1 LSA that describes R1 itself,

with sequence number 0x80000004. If R2’s database already held that LSA, but with a

sequence number of 0x80000003, R2 would know that it needs to ask R1 to send the lat-

est copy (sequence number 0x80000004) of that LSA.

Note In OSPF, LSA sequence numbers form a space of linearly ordered signed 32-bit

integers going from –231+1 to 231–1, or from –2,147,483,647 to 2,147,483,647. The value

231 is reserved to detect when the LSA numbers wrap, and is not used as a sequence

number. Because in most computer systems, negative integers are stored in two’s comple-

ment, printing out the value of the two’s complement of a negative number in hexadecimal

form yields values 0x80000001 (corresponds to –231+1) through 0xFFFFFFFF (cor-

responds to –1). Hence, when printed out in hexadecimal, LSA sequence numbers start

with 0x80000001 (–231+1); increase through 0xFFFFFFFF (–1), 0x00000000 (0), and

0x00000001 (1); and finish at 0x7FFFFFFF (231–1). If the sequence number of an LSA was

to be increased to 0x80000000, this LSA would need to be flushed from the LSDB and

then reoriginated with the sequence number starting again at 0x80000001. The sequence

number 0x80000000 never appears on the wire.

Key

Topic

Key

Topic

ptg13046388

Chapter 9: OSPF 469

Routers use Link-State Request (LSR) packets to request one or more LSAs from a

neighbor. The neighboring router replies with Link-State Update (LSU) packets, which

hold one or more full LSAs. As shown in Figure 9-1 , both routers sit in a Loading state

while the LSR/LSA process continues. After the process is complete, they settle into a

Full state, which means that the two routers should have fully exchanged their databases,

resulting in identical copies of the LSDB entries for that area on both routers.

The LSR/LSA process uses a reliable protocol that has two options for acknowledging

packets. First, an LSU can be acknowledged by the receiver of the LSU simply repeating

the exact same LSU back to the sender. Alternatively, a router can send back an LSAck

packet to acknowledge the packet, which contains a list of acknowledged LSA headers.

At the end of the process outlined in Figure 9-1 , two neighbors have exchanged their

LSDBs. As a result, their LSDBs should be identical. At this point, they can each indepen-

dently run the Dijkstra’s Shortest Path First (SPF) algorithm to calculate the best routes

from their own perspectives.

Designated Routers on LANs

OSPF optimizes the LSA flooding process on multiaccess data links by using the con-

cept of a designated router (DR) . Without the concept of a DR, each pair of routers

that share a data link would become fully adjacent neighbors. Each pair of routers would

directly exchange their LSDBs with each other, as shown in Figure 9-1 . On a LAN with

only six routers, without a DR, 15 different pairs of routers would exist, and 15 differ-

ent instances of full database flooding would occur. OSPF uses a DR (and a backup DR ,

or BDR ) on a LAN or other multiaccess network. The flooding occurs through the DR,

reducing the unnecessary exchange of redundant LSAs.

Note The true optimization of flooding provided by the DR depends on the situation

that prompts the flooding. If a router on a common segment needs to advertise an update,

the concept of a DR requires that the update is actually flooded twice: first from the router

that advertises the update to the DR/BDR, and second, from the DR to all routers on the

segment. This double flooding can hardly be considered an optimization. However, when a

new multiaccess segment with multiple routers boots up, or if a new router is connected to

such a segment, the presence of a DR/BDR allows the routers to synchronize only to a DR

and BDR, alleviating the need of synchronizing to each other, possibly flooding the same

set of LSAs multiple times. Hence, the optimization provided by the DR/BDR is most vis-

ible during the initial synchronization of router databases.

In reality, DRs have a different crucial and the only truly irreplaceable function: They cre-

ate a type 2 LSA that represents the multiaccess network segment. LSA types are covered

in the next major section, “OSPF Design and LSAs.”

The next section goes through the basics of the DR/BDR process on LANs, which is fol-

lowed by coverage of options of OSPF network types and how they impact OSPF flood-

ing on Frame Relay links.

ptg13046388

470 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Designated Router Optimization on LANs

The basic rule about exchanging LSDB contents states that only routers in the Full state

are allowed to exchange LSAs. On a multiaccess segment, every router is in the Full state

only with DR and BDR routers. The DR and BDR are in the Full state with all routers

on the segment and with each other as well. If the DR or BDR needs to send an update,

it simply does it directly by sending an LSU packet containing the updated LSA to the

multicast IP address 224.0.0.5, the All OSPF Routers group. Every other OSPF router on

the multiaccess segment will receive this LSU and acknowledge its arrival by sending a

unicast LSAck packet to the router that sourced the LSU.

A router on a multiaccess segment that is neither DR nor BDR is in the Full state only

with the DR and BDR. If it needs to send an update, it sends an LSU packet to the mul-

ticast IP address 224.0.0.6, the All OSPF DR Routers group that contains only the DR

and BDR. Both the DR and BDR will store the updated LSA from the LSU in their LSDB.

The DR then floods a new LSU packet containing the same updated LSA to all OSPF

routers on the segment using the multicast IP address 224.0.0.5. Neither the DR nor BDR

acknowledge the original LSU with an LSAck—while they could, and it would be a valid

acknowledgment, it is not necessary. Instead, the LSU flooded by the DR serves as an

implicit acknowledgment to the original router that sent the update. Other routers on the

segment including the BDR, except the original router, will acknowledge the DR’s LSU

with a unicast LSAck sent to the DR.

Note In topologies without a DR, the LSU packets are typically sent to the 224.0.0.5 All

OSPF Routers multicast IP address.

Example 9-2 shows the output of a show ip ospf neighbor command issued on Router

R1 connected to a common Fast Ethernet segment with three other routers. According to

this output, the router with the OSPF RID of 8.8.8.8 is the DR, the router with the OSPF

RID of 7.7.7.7 is the BDR, and both these neighbors have reached the Full state with

respect to R1. Another router on the segment with the OSPF RID of 2.2.2.2 is neither the

DR nor the BDR. Because R1 is obviously not a DR or BDR itself, Routers R1 and 2.2.2.2

remain in the 2-Way state.

Example 9-2 show ip ospf neighbor Command

R1# sh ip ospf neighbor fa 0/0

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 1 2WAY/DROTHER 00:00:35 10.1.1.2 FastEthernet0/0

7.7.7.7 1 FULL/BDR 00:00:38 10.1.1.3 FastEthernet0/0

8.8.8.8 1 FULL/DR 00:00:34 10.1.1.4 FastEthernet0/0

When a DR is used on a link, routers end up as DR, BDR, or neither; a router that is

neither a DR or a BDR is called a DROther router. The DR and BDR form full adjacen-

cies with all other neighbors on the link, so they reach a Full state when the database

exchange process is complete. However, two neighbors that are both DROthers do not

ptg13046388

Chapter 9: OSPF 471

become fully adjacent; they stop at the 2-Way state, as shown in Example 9-2 . Stopping at

the 2-Way state between two DROther routers is normal. It simply means that the Hello

parameter match and bidirectional visibility check worked, but the neighbors do not need

to proceed to the point of synchronizing their LSDBs directly, because they do not need

to when a DR is present.

To describe the fact that some neighbors do not directly exchange DD and LSU packets,

OSPF makes a distinction between the terms neighbors and adjacent , as follows:

■ Neighbors: Two routers that share a common data link and that exchange Hello mes-

sages, and the Hellos must match for certain parameters.

■ Adjacent (fully adjacent): Two neighbors that have completed the process of fully

exchanging DD and LSU packets directly between each other.

Note that although DROther routers do not exchange DD and LSU packets directly with

each other, like R1 and R2 in Figure 9-2 , the DROther routers do end up with an identical

copy of the LSDB entries by exchanging them with the DR.

DR Election on LANs

As noted in Figure 9-1 , if a DR is elected, the election occurs after the routers have

become neighbors, but before they send DD packets and reach the ExStart neighbor

state. When an OSPF router reaches the 2-Way state with the first neighbor on an inter-

face, it has already received at least one Hello from that neighbor and has found its RID in

the list of seen routers in the received Hello. If the Hello messages state a DR of 0.0.0.0—

meaning that none have been elected—the router waits before attempting to elect a DR.

This typically occurs after a failure on the LAN. OSPF routers wait with the goal of giv-

ing all the routers on that subnet a chance to finish initializing after a failure so that all

the routers can participate in the DR election; otherwise, the first router to become active

would always become the DR. (The time period is called the OSPF wait time , which is

set to the same value as the Dead timer.)

However, if the received Hellos already list the DR’s RID, the router does not have to wait

before beginning the election process. This typically occurs when one router lost its con-

nection to the LAN, but other routers remained and continued to work. In this case, the

newly connected router does not attempt to elect a new DR, assuming that the DR listed

in the received Hello is indeed the current DR.

The election process allows for the possibility of many different scenarios for which rout-

ers might and might not become the DR or BDR. Generally speaking, the following rules

govern the DR/BDR election process:

■ Any router with its OSPF priority set to 1–255 inclusive is eligible to become a DR

or BDR. A router with its OSPF priority set to 0 is ignored in DR/BDR elections.

■ Each router performs the elections locally based on the collected data from other

neighbors on the segment; however, the algorithm makes sure that all routers ulti-

mately arrive at the same conclusion.

Key

Topic

ptg13046388

472 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ During the wait interval, whose length is automatically set to the Dead interval on

the interface, each router collects the priorities and RIDs of other neighbors on the

segment by listening to received Hellos, adding its own RID and priority to the list

as well. However, a router does not assert itself as the DR or BDR during the wait

interval, and all Hellos it sends indicate that the DR and BDR are not yet elected (the

IP addresses in the DR and BDR fields in Hellos are set to 0.0.0.0).

■ If, during the wait interval, a Hello packet arrives from a neighbor that claims itself

to be the BDR (meaning both DR and BDR have already been elected and the BDR

is alive), or if a neighbor that claims to be the DR and no BDR address is indicated in

the Hello (meaning that the DR has already been elected and there is no BDR present

on the network), the router immediately proceeds to the DR/BDR election process.

Otherwise, the full wait interval period on the interface needs to expire.

■ The election is performed only for those roles that are not yet claimed in neighbor

Hellos (either both DR and BDR, or just BDR). A router examines the list of priorities

and RIDs it has collected over the wait interval, choosing the router with the highest

priority as the DR (if the role is not taken already) and the router with the second-

highest priority as the BDR (if the role is not taken already). If multiple routers adver-

tise the same highest or second-highest priority, still competing for the role of DR or

BDR, the higher RID is used to break the tie.

■ After the election has completed, if a new router arrives or an existing router

improves its priority, it cannot preempt the existing DR and take over as DR (or as

BDR).

■ When a DR is elected and the DR fails, the BDR becomes the DR, and a new election

is held for a new BDR.

In certain scenarios, two or more routers might temporarily arrive at a different result of

DR/BDR elections. This can happen if, for example, two or more routers are connected to

a switched network that undergoes an STP topology change that requires 50 seconds to

heal (for example, an indirect link failure). While the network is partitioned, routers arrive

at different results of DR/BDR elections, as each network partition will elect its own DR

and BDR. After the network becomes connected again, different routers will claim dif-

ferent DRs/BDRs in their Hellos. When this happens, the rule about DR/BDR elections

being nonpreemptive is ignored (upholding it would prevent the routers from arriving at a

single DR/BDR), and the contending routers enter the election phase again.

Designated Routers on WANs and OSPF Network Types

Using a DR makes good sense on a LAN because it might improve LSA flooding

efficiency. Likewise, not using a DR on a point-to-point WAN link also makes sense,

because with only two routers on the subnet, there is no inefficiency upon which to

improve. However, on nonbroadcast multiaccess (NBMA) networks, arguments can be

made regarding whether a DR is helpful. So, OSPF includes several options that include a

choice of whether to use a DR on WAN interfaces.

ptg13046388

Chapter 9: OSPF 473

Cisco router interfaces can be configured to use, or not use, a DR, plus a couple of other

key behaviors, based on the OSPF network type for each interface. The OSPF network

type determines that router’s behavior regarding the following:

■ Whether the router tries to elect a DR on that interface

■ Whether the router must statically configure a neighbor (with the neighbor com-

mand), or find neighbors using the typical multicast Hello packets

■ Whether more than two neighbors should be allowed on the same subnet

For example, LAN interfaces default to use an OSPF network type of broadcast . OSPF

broadcast networks elect a DR, use Hellos to dynamically find neighbors, and allow

more than two routers to be in the same subnet on that LAN. For High-Level Data Link

Control (HDLC) and Point-to-Point Protocol (PPP) links, OSPF uses a network type of

point-to-point , meaning that no DR is elected, only two IP addresses are in the subnet,

and neighbors can be found through Hellos.

Table 9-3 summarizes the OSPF interface types and their meanings. Note that the inter-

face type values can be set with the ip ospf network type interface subcommand; the

first column in the table not only describes the interface type but also lists the exact key-

word for the type argument. Also, for cases in which a DR is not elected, all routers that

become neighbors also attempt to become adjacent by the direct exchange of DD, LSR,

and LSU packets.

Table 9-3 OSPF Network Types

Interface Type Uses DR/

BDR?

Default Hello

Interval

Requires

a neighbor

Command?

More Than Two

Hosts Allowed

in the Subnet?

Broadcast Yes 10 No Yes

Point-to-point 1 N o 1 0 N o N o

Non-broadcast 2 (NBMA) Yes 30 Yes Yes

Point-to-multipoint No 30 No Yes

Point-to-multipoint

nonbroadcast

No 30 Yes Yes

Loopback 3 N o – – N o

1 Default on Frame Relay point-to-point subinterfaces.

2 Default on Frame Relay physical and multipoint subinterfaces.

3 Cannot be configured manually—used on loopback interfaces automatically.

Key

Topic

Key

Topic

ptg13046388

474 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Caveats Regarding OSPF Network Types over NBMA Networks

When configuring OSPF over Frame Relay, the OSPF network type concept can become

a bit troublesome. In fact, many CCIE Routing and Switching lab preparation texts and

lab books focus on the variety of combinations of OSPF network types used with Frame

Relay for various interfaces/subinterfaces. The following list contains many of the key

items you should check when looking at an OSPF configuration over Frame Relay, when

the OSPF network types used on the various routers do not match:

■ Make sure that the default Hello/Dead timers do not cause the Hello parameter

check to fail. (See Table 9-3 for the defaults for each OSPF network type.)

■ If one router expects a DR to be elected, and the other does not, the neighbors

might come up and full LSAs be communicated. However, show command output

might show odd information, and next-hop routers might not be reachable. So, make

sure that all routers in the same NBMA subnet use an OSPF network type that either

uses a DR or does not.

■ If a DR is used, the DR and BDR must have a permanent virtual circuit (PVC) to

every other router in the subnet. If not, routers will not be able to learn routes,

because the DR must forward the LSU packets to each of the other routers, and in

addition, the type 2 LSA originated by the DR for the common subnet will contain

incomplete information. Routers that do not have a PVC to every other router must

not be permitted to become a DR/BDR.

■ If neighbors need to be configured statically, configuring the neighbor command

on a single router is sufficient to bring up the OSPF adjacency with the configured

neighbor. For clarity and stability, however, it is better to configure neighbor com-

mands on both routers.

Two simple options exist for making OSPF work over Frame Relay—both of which do

not require a DR and do not require neighbor commands. If the design allows for the use

of point-to-point subinterfaces, use those and take the default OSPF network type of

point-to-point, and no additional work is required. If multipoint subinterfaces are needed,

or if the configuration must not use subinterfaces, adding the ip ospf network point-

to-multipoint command on all the routers works, without requiring additional effort to

manually define neighbors or worry about which router becomes the DR.

Example of OSPF Network Types and NBMA

On NBMA networks with an OSPF network type that requires that a DR be elected,

you must take care to make sure that the correct DR is elected. The reason is that the

DR and BDR must each have a PVC connecting them to all the DROther routers and to

each other. Otherwise, appropriate LSA flooding will not be possible and the type 2 LSA

generated for the NBMA network might contain incomplete information, or there might

even be multiple conflicting type 2 LSAs. So, with partial meshes, the election should be

influenced by configuring the routers’ priority and RIDs such that the hub site of a hub-

and-spoke partial mesh becomes the DR. Figure 9-2 shows an example network for which

R1 should be the only router allowed to become the DR or BDR.

ptg13046388

Chapter 9: OSPF 475

RID 1.1.1.1

10.3.1.3/23

S0/0.1 Mpt

S0/0.1 P-P

S0/0

Phy.

S0.1 Mpt

E0/0

10.3.1.4/23

10.1.111.0/24

E0/0

10.5.1.5/24

E0/0

10.6.1.6/24

E0/0

Figure 9-2 Network Used in the Frame Relay Priority and Network Type Example

Example 9-3 depicts the following scenarios relating to DR election in Figure 9-2 :

■ The R1, R3, and R5 configuration is correct for operating with the default OSPF net-

work type nonbroadcast in a partial mesh.

■ R6 has omitted the ip ospf priority interface subcommand, causing it to inadvisably

become the DR.

■ R4 will be used as an example of what not to do, in part to point out some interest-

ing facts about OSPF show commands.

Note Figure 9-2 and Example 9-3 do not depict a suggested design for Frame Relay and

OSPF. With this topology, using point-to-point subinterfaces in all cases, using four small

(/30) subnets, and defaulting to OSPF network type point-to-point would work well. Such

a design, however, would not require any thought regarding the OSPF network type. So,

this example is purposefully designed to provide a backdrop from which to show how the

OSPF network types work.

Example 9-3 shows only the nondefault OSPF configuration settings; also, the routers

have an obvious RID numbering scheme (1.1.1.1 for R1, 2.2.2.2 for R2, and so on).

Example 9-3 Setting Priority on NBMA Networks

! R1 configuration – the neighbor commands default to a priority value of 0,

! meaning R1's perception of that neighbor is priority 0.

router ospf 1

log-adjacency-changes detail

network 0.0.0.0 255.255.255.255 area 0

neighbor 10.1.111.3

ptg13046388

476 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

neighbor 10.1.111.4

neighbor 10.1.111.5

neighbor 10.1.111.6

! R3 configuration – R3's interface priority is set to 0; R1 will use the higher

! of R3's announced priority 0 (based on R3's ip ospf priority interface

! subcommand) and the priority value on R1's neighbor command, which defaulted

! to 0. So, R3 will not ever become a DR/BDR.

interface Serial0/0.1 multipoint

ip address 10.1.111.3 255.255.255.0

ip ospf priority 0

frame-relay interface-dlci 100

! R4 configuration – note from Figure 9-2 that R4 is using a point-to-point

! subinterface, with all defaults. This is not a typical use of a point-to-point

! subinterface, and is shown to make a few points later in the example.

router ospf 1

network 0.0.0.0 255.255.255.255 area 0

! R5's configuration is equivalent to R3 in relation to the OSPF network type

! and its implications.

interface Serial0.1 multipoint

ip address 10.1.111.5 255.255.255.0

ip ospf priority 0

frame-relay interface-dlci 100

router ospf 1

network 0.0.0.0 255.255.255.255 area 0

! R6 configuration – R6 forgot to set the interface priority with the

! ip ospf priority 0 command, defaulting to priority 1.

router ospf 1

network 0.0.0.0 255.255.255.255 area 0

! Below, the results of R6's default interface priority of 1 – R6, with RID

! 6.6.6.6, and an announced priority of 1, wins the DR election. Note that the

! command is issued on R1.

R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

6.6.6.6 1 FULL/DR 00:01:52 10.1.111.6 Serial0/0

3.3.3.3 0 FULL/DROTHER 00:01:46 10.1.111.3 Serial0/0

ptg13046388

Chapter 9: OSPF 477

N/A 0 ATTEMPT/DROTHER – 10.1.111.4 Serial0/0

5.5.5.5 0 FULL/DROTHER 00:01:47 10.1.111.5 Serial0/0

! Next, R1's neighbor command was automatically changed to "priority 1" based on

! the Hello, with priority 1, that R1 received from R6. To prevent this dynamic

! reconfiguration, you could add an ip ospf priority 0 command under R6's s0/0.1

! interface.

R1# show run | beg router ospf 1

router ospf 1

network 0.0.0.0 255.255.255.255 area 0

neighbor 10.1.111.6 priority 1

neighbor 10.1.111.3

neighbor 10.1.111.4

neighbor 10.1.111.5

! Lines omitted for brevity

! Below, R4 is OSPF network type "point to point," with Hello/dead of 10/40.

! R1's settings, based on Table 9-3, would be nonbroadcast, 30/120.

R4# show ip ospf int s 0/0.1

Serial0/0.1 is up, line protocol is up

Internet Address 10.1.111.4/24, Area 0

Process ID 1, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 1562

Transmit Delay is 1 sec, State POINT_TO_POINT,

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

! Lines omitted for brevity

! Below, R4 changes its network type to yet a different value, one that expects

! neighbor commands, but does not expect a DR to be used.

R4# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R4(config)# int s 0/0.1

R4(config-subif)# ip ospf network point-to-multipoint non-broadcast

! Next, R1 and R4 become neighbors now that the Hello parameters match. Note that

! R1 believes that R4 is DROther.

R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

! Lines omitted for brevity

4.4.4.4 1 FULL/DROTHER 00:01:56 10.1.111.4 Serial0/0

! Below, R4 agrees it is in a full state with R1, but does not list R1 as DR,

ptg13046388

478 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! because R4 is not using the concept of a DR at all due to R4's network type.

R4# sh ip ospf neigh

Neighbor ID Pri State Dead Time Address Interface

1.1.1.1 0 FULL/ – 00:01:42 10.1.111.1 Serial0/0.1

In the following text, it is assumed that all neighbor statements define neighbors reach-

able over a single interface. If there are static neighbors configured that are reachable over

different interfaces, the following text applies individually to each group of static neigh-

bors reachable over a particular interface.

One of the important points from Example 9-3 is the use of the priority setting in the

neighbor command. There is much confusion regarding its use. Somewhat surprisingly,

the priority specified in the neighbor command is never used in DR/BDR elections. For

that purpose, exclusively the interface priority configured by the ip ospf priority inter-

face command is taken into account. However, if there are multiple neighbor statements

configured and at least one of them has a nonzero priority specified in the statement

(the default neighbor priority setting is 0 when unspecified), the router will first send

Hello packets only to those neighbors with a nonzero priority. Only after DR/BDR elec-

tions have completed between these routers, the router will start sending Hello packets

to all remaining neighbors. In consequence, if the priority setting in the neighbor com-

mand matches the interface priority of the neighbor, the router will first engage in DR/

BDR elections with only those neighbors that have a chance of becoming DR/BDR. This

optimization increases the chances that the DR and BDR roles will be taken up by appro-

priate routers, and prevents routers from competing in DR/BDR elections with neighbors

that are not entitled to these roles.

The priorities specified in the neighbor commands do not need to match the real priori-

ties of these neighbors, but if they differ, the router can engage in DR/BDR elections

with neighbors not entitled to become a DR/BDR. In any case, though, real priorities of

these neighbors as seen in their Hello packets will be used to complete the DR/BDR elec-

tions. Some IOS versions might even automatically update the priority in the neighbor

statements in case a mismatch is detected; however, in recent IOS versions, the configura-

tion is not updated automatically.

If all neighbor statements omit the priority setting, this optimization is not used, and all

neighbors are contacted immediately. Also, if the neighbors are reachable over an inter-

face whose priority has been set to 0 using the ip ospf priority command, the router will

automatically remove all corresponding neighbor statements from the configuration. This

behavior prevents the router from participating in any way in the DR/BDR elections (even

though an advertised priority of 0 would suffice alone to prevent the router from ever

becoming a DR or BDR), and it forces the router to wait for its neighbors to contact it. In

this case, the router knows about no neighbors on its own, and is dependent on the DR

and BDR contacting it thanks to their own neighbor statements.

Also note that, although neighbors must be statically configured for some network types,

the neighbor command needs to be configured on only one router. R3 and R5, with cor-

rect working configurations, did not actually need a neighbor command.

Key

Topic

ptg13046388

Chapter 9: OSPF 479

Finally, it might seem that all is now fine between R1 and R4 by the end of the example,

but even though the neighbors are fully adjacent, R4 cannot route packets to R3, R5, or

R6 over the Frame Relay network. For example, R5 could have some routes that point to

10.1.111.4 (R4’s Frame Relay IP address) as the next hop. However, because R5 is using

a multipoint subinterface, R5 will not know what PVC to use to reach 10.1.111.4. In this

case, the routers with multipoint subinterfaces would need to add frame-relay map com-

mands. For example, R5 would need a frame-relay map ip 10.1.111.4 100 broadcast

command, causing packets to next-hop 10.1.111.4 to go over DLCI 100 to R1, which

would then route the packet on to R4. Keep in mind that R4’s configuration is not a rec-

ommended configuration.

SPF Calculation

So far, this chapter has covered a lot of ground related to the exchange of LSAs.

Regardless of the OSPF network type and whether DRs are used, after a router has new

or different information in its LSDB, it uses the Dijkstra SPF algorithm to examine the

LSAs in the LSDB and derive the new tree of shortest paths to available destinations. The

LSAs in the LSDB contain information to create a math equivalent of a figure of a net-

work. This mathematical model has routers, links, costs for each link, and the current (up/

down) status of each link. Figure 9-3 represents the SPF model of a sample network.

C 100

C 100 VLAN 1

Route S2 – R1 – R5 : Cost 1 + 100 + 10 = 111

Route S2 – R2 – R5 : Cost 1 + 64 + 10 = 75

10.5.1.0/24 10.5.25.0/24

10.5.15.0/24

C 10 C 50

C 1

C 64

C 1 C 1

10.1.1.0/24

R2R5 S2

Figure 9-3 Single-Area SPF Calculation: Conceptual View

In this simple network, humans can easily see the conclusion that the SPF algorithm will

reach, even though the algorithm itself requires a couple of steps to arrive at the same

conclusion. SPF on a router constructs least-cost paths from this router to all possible

destinations, summing the costs for each outgoing interface along a path to a destination

and picking the path with the lowest total cost. Found destinations and corresponding

next hops on the least-cost paths toward these destinations are then placed into the rout-

ing table. For example, S2 calculates two possible routes to subnet 10.5.1.0/24, with the

better route being out S2’s VLAN 1 interface, with R2 as the next-hop router. Also note

in Figure 9-3 that the cost values are per interface, and it is each outgoing interface’s cost

that SPF adds to come up with the total cost of the route.

ptg13046388

480 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Steady-State Operation

Even after a network has stabilized, all routers in the same area have the exact same LSAs,

and each router has chosen its best routes using SPF, the following is still true of routers

running OSPF:

■ Each router sends Hellos, based on per-interface hello intervals.

■ Each router expects to receive Hellos from neighbors within the dead interval on

each interface; if not, the neighbor is considered to have failed.

■ Each router originally advertising an LSA refloods each LSA (after incrementing its

sequence number by 1) based on a per-LSA Link-State Refresh (LSRefresh) interval

(default 30 minutes).

■ Each router expects to have its LSA refreshed within each LSA’s MaxAge timer

(default 60 minutes).

OSPF Design and LSAs

This section covers two major topics:

■ OSPF design

■ OSPF LSA types

Although these might seem to be separate concepts, most OSPF design choices directly

impact the LSA types in a network and impose restrictions on which neighbors can

exchange those LSAs. This section starts with an OSPF design and terminology review,

and then moves on to LSA types. Toward the end of the section, OSPF area types are

covered, including how each variation changes how LSAs flow through the different

types of OSPF stubby areas.

OSPF Design Terms

OSPF design calls for grouping links into contiguous areas. Routers that connect to

links in different areas are Area Border Routers (ABR) . ABRs must connect to area 0,

the backbone area , and to one or more other areas as well. It is noteworthy to mention

that RFC 2328 defines an ABR simply as a router “attached to multiple areas.” While it

does not explicitly state that one of these areas must be the backbone area 0, it nonethe-

less implicitly assumes it throughout its contents. This slight ambiguity has led different

vendors to implement ABR functionality in slightly different ways. It is therefore strongly

recommended to become familiar with RFC 3509, “Alternative Implementations of OSPF

Area Border Routers,” which explains in detail the Cisco approach to implementing ABR

functionality. The key takeaway is that in the Cisco implementation, only a router that is

actively attached to multiple areas (that is, has at least one active interface in these areas),

including the backbone area , considers itself an ABR and performs the appropriate func-

tions. A router actively attached to multiple areas but not to the backbone area does not

consider itself an ABR and does not act like one.

ptg13046388

Chapter 9: OSPF 481

Autonomous System Boundary Routers (ASBR) inject routes external to OSPF into the

OSPF domain, having learned those routes from wide-ranging sources from the Border

Gateway Protocol (BGP) on down to simple redistribution of static routes. Figure 9-4

shows the terms in the context of a simple OSPF design.

Transit Network

Area x

Internal Router

Area y

Stub Network

Area Border

Router

Area Border

Router Backbone

Router

Backbone

Router

Area 0

Backbone

Area

Autonomous System

Border Router

Another

Routing

Protocol

ABR2

BB2

ABR1 BB1 ASBR1

Figure 9-4 OSPF Design Terminology

Conceptually, an OSPF router keeps an independent and separate LSDB for each area to

which it is connected. An internal router to an area has a single LSDB; an ABR has multi-

ple separate LSDBs, one for each connected area (one of them must be the backbone area

0). By default, the contents of per-area LSDBs are completely isolated; that is, one LSDB

does not leak into another. It is only the ABR role that is entitled to translate and carry

information in a controlled way between LSDBs and thus between areas. When com-

puting a routing table, SPF is run in each LSDB separately, and the results are combined

in a single routing table subject to OSPF path preference rules. While this chapter uses

the LSDB as a term to describe the entire link-state information maintained by the OSPF

process (that is, the union of all per-area LSDBs) for simplicity reasons, it is important

to keep in mind that in multiarea OSPF, ABRs maintain separate per-area LSDBs and run

SPF in each of them independently, and then combine the results and use them to popu-

late per-area LSDBs with condensed information about other areas.

Networks can use a single OSPF area, but using OSPF areas helps speed convergence and

reduce overhead in an OSPF network. Using areas provides the following benefits:

■ Generally smaller per-area LSDBs, requiring less memory.

■ Faster SPF computation thanks to the sparser LSDB.

■ A link failure in one area only requires a partial SPF computation in other areas.

Key

Topic

Key

Topic

ptg13046388

482 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ Routes can be summarized and filtered only at ABRs (and ASBRs). Having areas

permits summarization, again shrinking the LSDB and improving SPF calculation

performance.

When comparing the use of one area versus using many areas, the number of routers or

subnets does not shrink, but the size of the LSDB on most routers should shrink. The

LSDB shrinks because an ABR does not pass denser and more detailed type 1 and 2 LSAs

from one area to another—instead, it passes type 3 summary LSAs. LSA types 1 and

2 can be thought of as the detailed topology information that causes most of the com-

puting-intensive parts of the SPF algorithm. By representing these detailed type 1 and 2

LSAs in a different way in other areas, OSPF achieves its goal of reducing the effects

of SPF.

OSPF Path Selection Process

OSPF has specific rules for selecting a path that crosses areas. Before studying the details

of OSPF LSAs, it might help at this point to understand those rules:

■ OSPF always chooses an intra-area route over an inter-area route for the same prefix,

regardless of metric.

■ ABRs ignore type 3 LSAs learned in a nonbackbone area during SPF calculation,

which prevents an ABR from choosing a route that goes into a nonbackbone area and

then back into the backbone.

Note that these conditions can result in both asymmetric routing and suboptimal routing

across multiarea OSPF networks. An example will be given in the section “Best-Path Side

Effects of ABR Loop Prevention,” later in this chapter. This fact must be considered in

both the design and troubleshooting of OSPF networks.

LSA Types

Table 9-4 lists the LSA types and their descriptions for reference; following the table,

each type is explained in more detail, in the context of a working network. An important

fact concerning all LSA types is that only a router that has originated a particular LSA

is allowed to modify it or withdraw it. Other routers must process and flood this LSA

within its defined flooding scope if they recognize the LSA’s type and contents, but they

must not ever change its contents, block it, or drop it before its maximum lifetime has

expired. In other words, LSAs created by other routers are intangible and must be pro-

cessed and forwarded unmodified. This requirement makes sure that all routers in an area

have the same LSDB contents and have a consistent view of the network. It also brings

along a strong limitation typical for all link-state routing protocols: Summarization and

route filtering can be done in a very limited fashion, unlike in distance vector protocols,

where summarization and route filtering can be performed at any point in the network.

ptg13046388

Chapter 9: OSPF 483

Table 9-4 OSPF LSA Types

LSA Type Common Name Description

1 Router One per router per area, listing the router’s RID and

all interface IP addresses in that area. Represents stub

networks as well. Flooded only within its area of origin.

2 Network One per transit network. Created by the DR on the

subnet, and represents the subnet and the router

interfaces connected to the subnet. Flooded only within

its area of origin.

3 Net Summary Created by ABRs to represent networks present in one

area when being advertised into another area. Defines

the subnets in the origin area, and cost, but no topology

data. Flooded only within its area of origin; reoriginated

on ABRs.

4 ASBR Summary Like a type 3 LSA, except it advertises a host route used

to reach an ASBR. Flooded only within its area of origin;

reoriginated on ABRs.

5 AS External Created by ASBRs for external routes injected into OSPF.

Flooded to all regular areas.

6 Group Membership Defined for MOSPF; not supported by Cisco IOS.

7 NSSA External Created by ASBRs inside an NSSA, instead of a type 5

LSA. Flooded only within its area of origin; converted to

type 5 LSA on an ABR toward other areas.

8 External Attributes Created by ASBRs during BGP-to-OSPF redistribution to

preserve BGP attributes of redistributed networks. Not

implemented in Cisco routers.

9–11 Opaque Used as generic LSAs to allow for easy future extension

of OSPF; for example, type 10 has been adapted for

MPLS traffic engineering. These LSAs have different

flooding scope: Type 9 has link-local flooding scope,

type 10 has area-local flooding scope, type 11 has

autonomous system flooding scope equivalent to the

flooding scope of type 5 LSAs (not flooded into stubby

areas and NSSAs).

Before diving into the coverage of LSA types, two more definitions are needed:

■ Transit network: A network over which two or more OSPF routers have become

neighbors and elected a DR so that traffic can transit from one to the other. An

exception to this rule is a point-to-point interconnection between two routers: This

interconnection is treated by OSPF as a combination of a point-to-point link and a

Key

Topic

ptg13046388

484 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

stub IP network on this link. This is done to facilitate using unnumbered point-to-

point links.

■ Stub network: A subnet on which a router has not formed any neighbor

relationships.

Now on to the LSA types!

LSA Types 1 and 2

Each router creates and floods a type 1 LSA for itself. These LSAs describe the router, its

interfaces (in that area), and a list of neighboring routers (in that area) on each interface.

The LSA itself is identified by a link-state ID (LSID) equal to that router’s RID.

Type 2 LSAs represent a transit subnet for which a DR has been elected. The LSID is the

DR’s interface IP address on that subnet. Note that type 2 LSAs are not created for sub-

nets on which no DR has been elected.

Armed with an LSDB with all the type 1 and 2 LSAs inside an area, a router’s SPF algo-

rithm is able to create a topological graph of the network, calculate the possible routes,

and finally choose the best routes. For example, Figure 9-5 shows a sample internetwork

that is used in several upcoming examples. Switches S1 and S2 in the figure are multilayer

switches running OSPF, so for OSPF purposes, they are indistinguishable from routers.

Figure 9-6 shows a graphical view of the type 1 and type 2 LSAs created in area 3.

Transit, with DR

10.3.0.0/23 Transit, no DR

10.3.13.0/24

C 1

E0/0

C 10

C 64

C 1

RID 10.3.3.33

Area 3

Stub 10.3.2.0/23

RID 3.3.3.3

Area 4

Area 5

E0/0 C 1562

RID 4.4.4.4

10.4.1.4/23 10.4.14.0/24

E0/0 C 50

C 100

C 64

RID 5.5.5.5 RID

2.2.2.2

10.5.1.5/24 10.5.25.0/24

10.5.15.0/24 C 100

Area 0

RID

8.8.8.8

RID

1.1.1.1

ASBR

RID

7.7.7.7

10.1.1.0/24 Externals:

192.168.1.0/24 (E1)

192.168.2.0/24 (E2)

R33

R5 R2

R1 S1

Figure 9-5 Network Used in LSA Examples

ptg13046388

Chapter 9: OSPF 485

LSA Type 1

RID 10.3.3.33

E0/0

Stub 10.3.2.33/23

Cost 1

Represents

R33

Represents Transit

Net 10.3.0.0/23

Represents R3 Represents R1

E0/0

10.3.1.33

To Transit with DR 10.3.1.3

Cost 1

E0/0

10.3.1.3

Transit with DR 10.3.1.3

Cost 10

S0/0.1

Stub 10.3.13.3/24

To RID 1.1.1.1

Cost 64

S0/0.3

Stub 10.3.13.1/24

To RID 3.3.3.3

Cost 64

To RID 10.3.3.33

Interface 10.3.1.33

To RID 3.3.3.3

Interface 10.3.1.3

LSA Type 2

DR 10.3.1.3

Subnet

10.3.0.0/23

LSA Type 1

RID 3.3.3.3

LSA Type 1

RID 1.1.1.1

Figure 9-6 Graph of Type 1 and 2 LSAs for Area 3

For subnets without a DR, the type 1 LSAs hold enough information for the SPF algo-

rithm to create the math model of the topology. For example, R1 and R3 use point-to-

point subinterfaces and the OSPF point-to-point network type. SPF can match up the

information shown in the type 1 LSAs for R1 and R3 in Figure 9-6 to know that the two

routers are connected.

For transit networks with DRs, OSPF uses a type 2 LSA to model the subnet as a node in

the SPF mathematical model. Because the SPF process treats the type 2 LSA as a node

in the graph, this LSA is sometimes called a pseudonode . The type 2 LSA includes

references to the RIDs of all routers that are currently neighbors of the DR on that sub-

net. That information, combined with the type 1 LSAs for each router connected to the

subnet represented by the type 2 LSA, allows SPF to construct an accurate picture of the

network.

Example 9-4 shows the LSAs in area 3 ( Figures 9-5 and 9-6 ) through show commands.

Be aware of a long-term glitch in the show ip ospf database output: The Link ID col-

umn is a misnomer; correctly, it should say Link State ID. This seemingly subtle differ-

ence is serious enough to warrant a mention: While Link State ID is a unique identifier

of an entire LSA, a Link ID is a particular entry specifically in a type 1 LSA body that

describes an adjacency to a neighboring object of a router. A single type 1 LSA identified

by a single Link State ID can describe several adjacencies represented by several Link ID

entries. These two terms are not interchangeable.

ptg13046388

486 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 9-4 LSA Types 1 and 2 in Area 3

! R3's LSDB is shown, with type 1 LSAs listed as "Router Link States" and type 2

! LSAs as "Net Link States." The command output shows a section for each LSA type,

! in sequential order. The Link ID column should correctly spell Link State ID.

R3# show ip ospf database

OSPF Router with ID (3.3.3.3) (Process ID 1)

Router Link States (Area 3)

Link ID ADV Router Age Seq# Checksum Link count

1.1.1.1 1.1.1.1 1203 0x80000025 0x0072C3 2

3.3.3.3 3.3.3.3 779 0x80000027 0x003FB0 3

10.3.3.33 10.3.3.33 899 0x80000020 0x002929 2

Net Link States (Area 3)

Link ID ADV Router Age Seq# Checksum

10.3.1.3 3.3.3.3 1290 0x8000001F 0x00249E

! Lines omitted for brevity

! Next, the specific LSA's link ID is included in the show command, listing detail

! for the one LSA type 2 inside area 3. Note that the "Link ID" is the DR's

! interface address on the subnet. The network keyword refers to the network LSAs

! (type 2 LSAs).

R3# show ip ospf database network 10.3.1.3

OSPF Router with ID (3.3.3.3) (Process ID 1)

Net Link States (Area 3)

Routing Bit Set on this LSA

LS age: 1304

Options: (No TOS-capability, DC)

LS Type: Network Links

Link State ID: 10.3.1.3 (address of Designated Router)

Advertising Router: 3.3.3.3

LS Seq Number: 8000001F

Checksum: 0x249E

Length: 32

Network Mask: /23

Attached Router: 3.3.3.3

Attached Router: 10.3.3.33

! Next, the type 1 LSA for R3 is listed. The link ID is the RID of R3. Note that

! the LSA includes reference to each stub and transit link connected to R3. The

ptg13046388

Chapter 9: OSPF 487

! router keyword refers to the router LSAs (type 1 LSAs).

R3# show ip ospf database router 3.3.3.3

OSPF Router with ID (3.3.3.3) (Process ID 1)

Router Link States (Area 3)

LS age: 804

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 3.3.3.3

Advertising Router: 3.3.3.3

LS Seq Number: 80000027

Checksum: 0x3FB0

Length: 60

Number of Links: 3

! Note how each network object adjacent to R3 is described by a separate

! entry, each now being correctly labeled as Link ID.

Link connected to: another Router (point-to-point)

(Link ID) Neighboring Router ID: 1.1.1.1

(Link Data) Router Interface address: 10.3.13.3

Number of TOS metrics: 0

TOS 0 Metrics: 64

Link connected to: a Stub Network

(Link ID) Network/subnet number: 10.3.13.0

(Link Data) Network Mask: 255.255.255.0

Number of TOS metrics: 0

TOS 0 Metrics: 64

! Note that R3's LSA refers to a transit network next, based on its DR IP address;

! these lines allow OSPF to know that this router (R3) connects to the transit

! network whose type 2 LSA has LSID 10.3.1.3, derived from DR's IP address

! in that network.

Link connected to: a Transit Network

(Link ID) Designated Router address: 10.3.1.3

(Link Data) Router Interface address: 10.3.1.3

Number of TOS metrics: 0

TOS 0 Metrics: 10

! Below, the routes from R3 and R1 to 10.3.2.0/23 are shown. Note the cost values

! for each reflect the cumulative costs of the outgoing interfaces used to reach

! the subnet – for instance, R3's cost is the sum of its outgoing interface cost

! (10) plus R33's outgoing interface cost (1). R1's cost is based on three outgoing

! links: R1 (cost 64), R3 (cost 10), and R33 (cost 1), for a total of 75. Also

ptg13046388

488 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! note that the time listed in the route is the time since this LSA first arrived

! at the router, even if the LSA has been refreshed due to the LSRefresh interval.

R3# show ip route ospf 1 | include 10.3.2.0

O 10.3.2.0/23 [110/11] via 10.3.1.33, 17:08:33, Ethernet0/0

R1# show ip route ospf | include 10.3.2.0

O 10.3.2.0/23 [110/75] via 10.3.13.3, 17:10:15, Serial0/0.3

The show ip ospf database command lists the LSAs in that router’s LSDB, with LSA

type 1 LSAs (router LSAs) first, then type 2 (network link states), continuing sequentially

through the LSA types. Also note that the LSDB for area 3 should be identical on R33,

R3, and R1. However, on R1, the show ip ospf database command lists all of R1’s LSDB

entries, including LSAs from other areas, so using an internal router to look at the LSDB

might be the best place to begin troubleshooting a problem. Also note the costs for the

routes on R3 and R1 at the end of the example—the SPF algorithm simply added the out-

going costs along the routes, from each router’s perspective.

Note To signify a network that is down, the appropriate type 1 or 2 LSA is either reorigi-

nated and the disconnected network is removed from that LSA, or the entire LSA is pre-

maturely aged by setting its age to 3600 seconds and flooding it, causing it to immediately

expire from all LSDBs.

LSA Type 3 and Inter-Area Costs

ABRs do not forward type 1 and 2 LSAs from one area to another. Instead, ABRs adver-

tise type 3 LSAs into one area to represent subnets described in both the type 1 and 2

LSAs in another area. Each type 3 summary LSA describes a simple inter-area destina-

tion—the subnet, the mask, and the ABR’s cost to reach that subnet, as shown in

F i g u r e 9 - 7 .

Area 0

R2’s Three Type 3 LSAs:

Routing Table:

Add: My cost to reach

R1 (cost 1) to Type 3

LSA’s costs

Subnet 10.3.2.0/23, Cost 75

Subnet 10.3.0.0/23, Cost 74

Subnet 10.3.13.0/24, Cost 64

10.3.2.0/23: Cost 76

10.3.0.0/23: Cost 75

10.3.13.0/24: Cost 65

Figure 9-7 Representation of Area 3 Subnets as Type 3 LSAs in Area 0

Example 9-5 focuses on the three subnets inside area 3, looking at the type 3 summary

LSAs created for those subnets by ABR R1. Note the example show commands on S2; S2

has identical area 0 LSDB entries as compared with R1.

ptg13046388

Chapter 9: OSPF 489

Example 9-5 LSA Type 3 Created by R1 for Area 3’s Subnets

! S2, internal to area 0, does not have the type 1 and 2 LSAs seen by R3 back in

! Example 9-4. However, type 3 LSAs (listed as "Summary Net Links") show all

! three subnets inside area 3. R1 is listed as the advertising router because it

! created the type 3 LSAs.

S2# show ip ospf database

! Lines omitted for brevity

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

10.3.0.0 1.1.1.1 257 0x80000001 0x00A63C

10.3.2.0 1.1.1.1 257 0x80000001 0x009A45

10.3.13.0 1.1.1.1 261 0x80000021 0x007747

! Lines omitted for brevity

! Below, note that the summary keyword is used to view type 3 LSAs. The metric

! reflects R1's cost to reach the subnet inside area 3.

S2# show ip ospf database summary 10.3.0.0

OSPF Router with ID (8.8.8.8) (Process ID 1)

Summary Net Link States (Area 0)

Routing Bit Set on this LSA

LS age: 341

Options: (No TOS-capability, DC, Upward)

LS Type: Summary Links(Network)

Link State ID: 10.3.0.0 (summary Network Number)

Advertising Router: 1.1.1.1

LS Seq Number: 80000001

Checksum: 0xA63C

Length: 28

Network Mask: /23

TOS: 0 Metric: 74

! Next, S2's routes to all three subnets are listed. S2 calculates its cost

! based on its cost to reach R1, plus the cost listed in the type 3 LSA. For

! example, the cost (above) in the type 3 LSA for 10.3.0.0/23 is 74; S2 adds

! that to S2's cost to reach ABR R1 (cost 1), for a metric of 75.

S2# show ip route ospf | include 10.3

O IA 10.3.13.0/24 [110/65] via 10.1.1.1, 00:16:04, Vlan1

O IA 10.3.0.0/23 [110/75] via 10.1.1.1, 00:05:08, Vlan1

O IA 10.3.2.0/23 [110/76] via 10.1.1.1, 00:05:12, Vlan1

ptg13046388

490 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! Next, S2's cost to reach RID 1.1.1.1 is listed as cost 1.

S2# show ip ospf border-routers

OSPF Process 1 internal Routing Table

Codes: i – Intra-area route, I – Inter-area route

i 1.1.1.1 [1] via 10.1.1.1, Vlan1, ABR, Area 0, SPF 18

i 2.2.2.2 [1] via 10.1.1.2, Vlan1, ABR, Area 0, SPF 18

i 7.7.7.7 [1] via 10.1.1.3, Vlan1, ASBR, Area 0, SPF 18

! Below, the show ip ospf statistics command lists the number of SPF calculations.

R1# show ip ospf stat

OSPF process ID 1

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

Area 0: SPF algorithm executed 6 times

Area 3: SPF algorithm executed 15 times

Area 4: SPF algorithm executed 6 times

Area 5: SPF algorithm executed 5 times

! Lines omitted for brevity

Example 9-5 shows how S2 calculated its cost to the area 3 subnets. Routers calculate the

cost for a route to a subnet defined in a type 3 LSA by adding the following items:

■ The calculated cost to reach the ABR that created and advertised the type 3 LSA

■ The cost as listed in the type 3 LSA

You can see the cost of the type 3 LSA with the show ip ospf database summary link-

id command, and the cost to reach the advertising ABR with the show ip ospf border-

routers command, as shown in Example 9-5 .

The beauty of this two-step cost calculation process is that it allows a significant reduc-

tion in the number of SPF calculations. When a type 1 or 2 LSA changes in some way

that affects the underlying routes—for example, a link failure—each router in the area

runs SPF, but routers inside other areas do not. They only perform minor modification to

their already computed shortest path trees—a process called a partial run , partial SPF ,

or partial route calculation .

For example, imagine that in Figure 9-5 , R33’s LAN interface cost increases from 1 to 10.

R33 will originate a new type 1 LSA and flood it. All routers in area 3 will run a full SPF

and will update the metric of the path toward the network 10.3.2.0/23. R1, being an ABR,

will then flood an updated type 3 LSA regarding the network 10.3.2.0/23 into areas 0, 4,

and 5, indicating the new cost of 84. All other routers in area 0 will install the updated

LSA into their LSDB, add the indicated cost of 84 to their cost of reaching R1 as the ABR

advertising the LSA, and use the updated cost as the total cost of reaching the 10.3.2.0/23

through R1. No full SPF run was required on any of the routers in area 0. The same would

be valid for areas 4 and 5.

Key

Topic

ptg13046388

Chapter 9: OSPF 491

For a more complex scenario, imagine that R3’s LAN interface fails. This event consti-

tutes two topological changes to OSPF: R3’s link to the transit network 10.3.0.0/23 is

down, and because R3 was the DR in this network, the type 2 LSA it had originated is

no longer valid because the interface on which it was DR became inoperable. R3 will

therefore flood two updates. First, it will create and flood an updated type 1 LSA with

an incremented sequence number that describes all R3’s currently working links in area

3, leaving out the former link to the transit network that is no longer operable. Second,

it will withdraw the type 2 LSA describing the transit network by setting its age to 3600

seconds without incrementing the sequence number and flooding it.

Upon receiving these updates, R1 will install the updated type 1 LSA from R3 into its

area 3 LSDB and will flush the type 2 LSA regarding the transit network 10.3.0.0/23.

After running the SPF in area 3 over the updated area 3 LSDB, R1 finds out that the net-

work 10.3.0.0/23 no longer exists, and while the R33’s type 1 LSA still exists in the LSDB,

it is not reachable: There is no continuous sequence of type 1 and 2 LSAs pointing one to

another that can be traversed to reach R33 from R1. As a result, networks 10.3.0.0/23 and

10.3.2.0/23 will be removed from the routing table on R1, so R1 will withdraw the type 3

LSAs about these two networks from areas 0, 4, and 5. Withdrawal of type 3 LSAs does

not require a full SPF run. Instead, routers in these areas simply check whether there is

another type 3 LSA concerning the same networks providing a backup path, and when

they find there is none, they simply remove the affected networks from their routing

tables.

Instead of flushing type 3 LSAs to indicate that the inter-area network is not reachable

anymore, it is also possible to advertise an updated type 3 LSA regarding that network

with the metric set to 2

24 –1, or 16,777,215. This metric value represents an infinite path

cost, and routers will ignore such path. This approach is seldom used, however. RFC 2328

prefers premature aging instead.

Of particular importance is that partial calculations happen without any route summari-

zation. With OSPF, route summarization does help reduce the overall number of routes

that require SPF calculations, but route summarization is not required for partial calcula-

tions to occur.

Type 3 summary LSAs are flooded only within the area into which they were originated

by ABRs. They do not cross area boundaries. Instead, ABRs compute an internal OSPF

routing table for the backbone area using all types of LSAs received in the backbone

area, and for each intra-area and inter-area route, they originate a new type 3 LSA to be

flooded to their attached nonbackbone areas. For example, in Figure 9-5 , R1 creates and

floods a type 3 LSA on behalf of the network 10.3.2.0/23 in area 3 into the backbone

area. R2 computes its internal routing table for the backbone area using all LSAs received

through the backbone, including R1’s summary LSA, and installs an inter-area route to

10.3.2.0/23 through R1. Subsequently, for all intra-area and inter-area routes, including the

10.3.2.0/23 in the backbone area, R2 will create and flood a separate type 3 LSA to its

attached nonbackbone area 5.

ptg13046388

492 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The following are two important rules about originating and processing type 3 LSAs:

■ An ABR uses only those type 3 LSAs that are received over a backbone area in its

SPF calculation. Type 3 LSAs received over nonbackbone areas will be skipped

during the ABR’s SPF computation, though they are stored in the ABR’s LSDB and

flooded within that nonbackbone area as usual.

■ When an ABR creates and floods type 3 LSAs to advertise networks from one area

to another, only intra-area routes from nonbackbone areas are advertised into the

backbone; both intra-area and inter-area routes are advertised from the backbone

into nonbackbone areas.

The second rule is in fact only a direct consequence of the first rule. Because an ABR

must not use type 3 LSAs received over a nonbackbone area when running SPF over the

associated per-area LSDB, the SPF computation produces no inter-area routes related to

that nonbackbone area. Consequently, no inter-area routes from a nonbackbone area can

be advertised to the backbone because there are none. Nevertheless, these rules are often

stated independently.

LSA Types 4 and 5, and External Route Types 1 and 2

OSPF allows for two types of external routes, aptly named types 1 and 2. The type

determines whether only the external metric is considered by SPF when picking the best

routes (external type 2, or E2), or whether both the external and internal metrics are

added together to compute the metric (external type 1, or E1). The choice of external

metric types is always done by a network administrator, depending on the requirements.

By default, Cisco routers use the E2 metric type in redistribution.

When an ASBR injects an external route, it creates a type 5 LSA for the subnet. The LSA

lists the metric and the metric type. The ASBR then floods the type 5 LSA throughout all

regular areas. Other routers process the LSA depending on the metric type. If the LSA con-

tains the E1 metric, the total cost of reaching the external network is computed as the cost

of reaching the ASBR, plus the E1 cost of the external network carried in the LSA. In other

words, the E1 metric is added to the metric of the path between the calculating router and

the ASBR to produce the total metric of the path. If there are multiple paths of reaching the

same E1 external network, the path with the least total cost is used. If there are still mul-

tiple paths to the same network having the same least cost, all of them will be used.

If the LSA contains the E2 metric, this metric is used exactly as it is indicated in the LSA.

No additional costs are ever summed with the E2 metric. This is because the E2 metric is

considered to be orders of magnitude larger than any path cost inside the OSPF domain,

or in other words, costs of paths inside the OSPF domain are considered to be negligible

(that is, practically zero) in comparison to the E2 metric. If there are multiple paths of

reaching the same E2 external network, the path with the lowest E2 metric is used. If

there are still multiple paths to the same network with the same lowest E2 metric, the

path through the closest ASBR is used. In case there are still multiple paths to the net-

work, it follows that they must have the same lowest E2 metric and the same lowest met-

ric of reaching the corresponding ASBRs, and all of them will be used.

Key

Topic

Key

Topic

ptg13046388

Chapter 9: OSPF 493

Hence, the total cost of E1 external routes is computed as the cost of reaching the ASBR

advertising the network, plus the E1 cost of the external network. The path with the

least total cost is used; if there are multiple such paths, use them all. The total cost of

E2 external routes is immediately the E2 cost of the external network. The path with the

least E2 cost is used, and in case of a tie, the path having the least cost to an advertising

ASBR is used; if there are still multiple paths, use them all. If there are both E1 and E2

routes to the same external network available, the E1 is always preferred to E2.

Both with E1 and E2 metric types, it is necessary to compute the metric to the ASBR

advertising an external network. Within the same area where the ASBR resides, this is

simply the least-cost path from the computing router to the ASBR that can be comfort-

ably computed using type 1 and 2 LSAs. This topological information is not present in

other areas, however, so without additional help, routers in other areas would not be able

to compute their metric to reach the ASBR. Fortunately, what routers in other areas really

need to know is only what ABR can be used to reach the ASBR, and what is the path cost

between them. Therefore, when an ABR then floods the type 5 LSA into another area,

the ABR creates a type 4 LSA, containing the ASBR’s RID and the ABR’s metric to reach

the ASBR that created the type 5 LSA. Routers in other areas use the type 4 LSA to

know what ASBRs in other areas exist, what ABRs can be used to reach them, and what

is the distance of each ABR to a particular ASBR. For a router in a different area than an

ASBR’s, the total cost of reaching the ASBR through an ABR is then the sum of the cost

between the router and an ABR in the router’s area, plus the cost indicated in the type 4

LSA advertised by the ABR toward a particular ASBR. Whenever a cost of reaching an

ASBR is therefore required, if the ASBR is in the same area as the computing router, it is

computed using the type 1 and 2 LSAs in that area. If the ASBR is in a different area, the

cost of reaching it is computed using the type 1 and 2 LSAs in the computing router’s

area toward an ABR, plus the cost from the ABR’s type 4 LSA toward the ASBR. Rules

concerning the evaluation of E1 and E2 routes explained earlier therefore hold for routers

in all areas.

Note that a type 4 LSA concerning a particular ASBR is not required in the area where

the ASBR resides. It is therefore never flooded into it. Only other areas require the type

4 LSA to be able to compute their metrics toward ASBRs and external networks behind

them.

Figure 9-8 outlines the mechanics of how the LSAs are propagated, and how the metrics

are calculated.

E1 routes by definition include the cost as assigned when the ASBR injected the route

into OSPF, plus any cost inside the OSPF domain. To calculate the cost for the E1 route,

a router inside a different area than the ASBR must use two steps to calculate the internal

cost to ASBR, and a third step to add the external cost. For example, when R3, internal to

area 3, calculates the cost to reach 192.168.1.0/24 (an E1 route), R3 adds the following:

■ R3’s calculated area 3 cost to reach ABR R1 (RID 1.1.1.1).

■ R1’s cost to reach the ASBR that advertised the route (S1, RID 7.7.7.7). R1 announces

this cost in the LSA type 4 that describes R1’s cost to reach ASBR 7.7.7.7.

■ The external metric for the route, as listed in the type 5 LSA created by the ASBR.

ptg13046388

494 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 9-6 shows the components of the metrics and LSAs for two external routes:

192.168.1.0/24 E1 with metric 20, and 192.168.2.0/24 E2, also with metric 20.

Example 9-6 Calculating the Metric for External Types 1 and 2

! R3 has learned the two type 5 LSAs.

R3# show ip ospf database | begin Type-5

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

192.168.1.0 7.7.7.7 1916 0x8000002B 0x0080EF 0

192.168.2.0 7.7.7.7 1916 0x80000028 0x00FEF2 0

! Next, the detail for E2 192.168.2.0 is listed, with "metric type" referring

! to the external route type E2. (192.168.1.0, not shown, is type 1.)

R3# show ip ospf database external 192.168.2.0

OSPF Router with ID (3.3.3.3) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA

LS age: 1969

Options: (No TOS-capability, DC)

LS Type: AS External Link

Link State ID: 192.168.2.0 (External Network Number)

Advertising Router: 7.7.7.7

LS Seq Number: 80000028

Checksum: 0xFEF2

Length: 36

Area 3

• Cost to E2 Route: Metric in

LSA Type 5

• Cost to E1 Route: Add:

My Cost to ABR R1, Plus

the LSA Type 4’s Cost, Plus

the LSA Type 5’s Cost

• Create/Flood Type 4:

List R1’s Metric to Reach

the ASBR

• Flood Type 5’s, Metric

Unchanged

Area 0

• Create/Flood Type 5’s, Metric 20

ASBR

RID 7.7.7.7

ABR

RID 1.1.1.1

Internal

Router

Note: Arrows Show Propagation of LSAs.

Externals:

192.168.1.0/24 (E1)

192.168.2.0/24 (E2)

R3 R1

Figure 9-8 LSA Types 4 and 5 Propagation and the Effect on Type 1 External Routes

Key

Topic

ptg13046388

Chapter 9: OSPF 495

Network Mask: /24

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 0.0.0.0

External Route Tag: 0

! Next, R1's advertised cost of 1 between itself and the ASBR is listed. Note

! that S1's RID (7.7.7.7) is listed, with the ABR that forwarded the LSA into

! area 3, R1 (RID 1.1.1.1) also listed.

R3# show ip ospf database asbr-summary

OSPF Router with ID (3.3.3.3) (Process ID 1)

Summary ASB Link States (Area 3)

Routing Bit Set on this LSA

LS age: 923

Options: (No TOS-capability, DC, Upward)

LS Type: Summary Links(AS Boundary Router)

Link State ID: 7.7.7.7 (AS Boundary Router address)

Advertising Router: 1.1.1.1

LS Seq Number: 8000000A

Checksum: 0x12FF

Length: 28

Network Mask: /0

TOS: 0 Metric: 1

! Below, R3's calculated cost to R1 (64) and then to S1 (7.7.7.7) are listed. Note

! that the total of 65 is the cost 64 to reach the ABR, plus the cost 1 for the

! ABR to reach the ASBR.

R3# show ip ospf border-routers

OSPF Process 1 internal Routing Table

Codes: i – Intra-area route, I – Inter-area route

i 1.1.1.1 [64] via 10.3.13.1, Serial0/0.1, ABR, Area 3, SPF 30

I 7.7.7.7 [65] via 10.3.13.1, Serial0/0.1, ASBR, Area 3, SPF 30

! Below, each route is noted as E1 or E2, with the E1 route's metric including

! the external cost (20), plus cost to reach the ASBR (65).

R3# show ip route | include 192.168

O E1 192.168.1.0/24 [110/85] via 10.3.13.1, 00:50:34, Serial0/0.1

O E2 192.168.2.0/24 [110/20] via 10.3.13.1, 00:50:34, Serial0/0.1

ptg13046388

496 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

OSPF Design in Light of LSA Types

OSPF’s main design trade-offs consist of choosing links for particular areas, with the goal

of speeding convergence, reducing memory and computing resources, and keeping rout-

ing tables small through route summarization. For example, by using a larger number of

areas, and the implied conversion of dense types 1 and 2 LSAs into sparser type 3 LSAs,

the OSPF LSDBs can be made smaller. Also, link flaps in one area require SPF calculations

only in that area, thanks to the partial calculation feature. Additionally, ABRs and ASBRs

can be configured to summarize routes, reducing the number of Type 3 and Type 5 LSAs

introduced into other areas as well. (Route summarization is covered in Chap ter 11 .)

The OSPF design goals to reduce convergence time, reduce overhead processing, and

improve network stability can be reached using the core OSPF protocols and features

covered so far. Another key OSPF design tool, stubby areas, will be covered next.

Note Before we move on, a comment is in order about the relative use of the word sum-

mary in OSPF. The typical uses within OSPF include the following:

■ Type 3 and 4 LSAs are called summary LSAs in the OSPF RFCs.

■ The term LSA summary refers to the LSA headers that identify LSAs and are sent

inside DD packets.

The term summary can also be used to refer to summary routes created with the area

range and summary-address commands.

Stubby Areas

The areas described so far allow OSPF to limit the complexity of the information stored

in the LSDB, simplify and thus accelerate its processing, and optionally perform summa-

rization. The visibility of networks (intra-area, inter-area, external) was not affected. Such

areas that do not perform any automatic filtering on the type of accepted information are

called regular areas. All areas described so far were regular areas.

OSPF can further reduce overhead by treating each area with one of several variations of

rules, based on a concept called a stubby area . Stubby areas take advantage of the fact

that, depending on the actual network topology, not all areas need to have knowledge

about individual external networks. In particular, if a nonbackbone area does not contain

any ASBRs and does not inject any external routes into the OSPF domain, any informa-

tion about external networks (if present) must have come in through ABRs from other

areas.

Knowing the particular external networks one by one, then, is useful only to a limited

degree:

■ Because to reach the external networks, a packet must still be routed through an

ABR toward the area where the ASBR is located.

ptg13046388

Chapter 9: OSPF 497

■ Because there is no ASBR in the current area, there can never be a possibility of the

local ASBR providing a better path to any external network.

This is what forms the concept of a stubby area —an area that does not contain an ASBR

and thus does not mediate an external connectivity to the entire OSPF domain. Such

an area does not really benefit from knowing about individual external networks. The

advantage of knowing the external networks one by one in an area without its own ASBR

would be visible if there were multiple ABRs in the current area and multiple ASBRs in

other areas. In this case, the knowledge of individual external networks would allow for

choosing the least total cost path to each of the networks individually. In most other

cases, however, the connectivity to external networks can be equivalently provided to a

stubby area by replacing the list of external networks with a simple default route injected

by the area’s ABRs.

Therefore, if an area is configured as a stubby area, ABRs will stop advertising type 4 and

5 LSAs into this area. In addition, every internal router in a stubby area will ignore any

received type 5 LSAs, and will not originate any such LSAs itself. As a result, no external

networks or ASBRs will be known by any internal router in a stubby area. In addition,

ABRs in a stubby area will automatically inject a default route into the area as a type 3

LSA. The connectivity to external networks reachable through other areas will be main-

tained thanks to the default routes through ABRs. As a result, internal routers will still

be able to reach the external networks but their LSDBs will be sparser. The visibility of

intra-area and inter-area networks in a stubby area is not affected in any way.

RFC 2328 is vague on the point of whether type 4 LSAs are also ignored upon arrival,

but common sense dictates that type 4 LSAs are usable only in conjunction with type 5

LSAs, and because stubby areas explicitly prohibit the use of type 5 LSAs, the type 4

LSAs are useless in such areas and should be treated in the same way as type 5 LSAs.

To sum up, a stubby area is an area that does not contain an ASBR and is not intended

to. Such an area can benefit from filtering out type 4 and 5 LSAs, replacing the list of

all external networks with a default route. A stubby area can contain one or more ABRs.

For example, the only way out of area 3 in Figure 9-5 is through the only ABR, R1. So,

R1 could advertise a default route into area 3 instead of advertising any external type 5

LSAs.

Also in Figure 9-5 , area 5 has two ABRs. If area 5 were a stubby area, both ABRs would

inject default routes into the area. This configuration would work, but it might result in

suboptimal routing. This is not really a limitation of OSPF. Replacing a set of routes with

a default route is a form of route summarization, and route summarization always goes

hand in hand with a certain loss of granularity in the available choices.

OSPF defines several different types of stubby areas. By definition, all stubby areas stop

type 4 (ASBR summary) and type 5 (external) LSAs from being injected into them by

the ABRs. However, depending on the variation, a stubby area might also prevent type 3

LSAs from being injected, causing the area to stop seeing individual inter-area routes as

well. The other variation includes whether a router inside the stubby area can redistribute

routes into OSPF, thereby injecting an external route. Table 9-5 lists the variations on

stubby areas, and their names.

ptg13046388

498 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Note in Table 9-5 that all four stub area types stop type 4 and 5 LSAs from entering the

area. When the name includes “totally,” type 3 LSAs are also not passed into the area by

ABRs except a type 3 LSA carrying the default route, significantly reducing the size of

the LSDB. If the name includes “NSSA,” it means that external routes can be redistrib-

uted into OSPF by routers inside the stubby area; note that the LSAs for these external

routes would be type 7 because type 5 LSAs are still prohibited in such areas.

Table 9-5 OSPF Stubby Area Types

Area Type Stops Injection of

Type 4/5 LSAs?

Stops Injection

of Type 3 LSAs?

Allows Creation of Type

7 LSAs Inside the Area?

Stubby Yes No No

Totally stubby (TS) Yes Yes No

Not-so-stubby area

(NSSA)

Yes No Yes

Totally NSSA

(NSSA-TS)

Yes Yes Yes

To configure stubby areas, all routers attached to the area must be configured with the

exact same command for each stubby area type, as listed in Table 9-6 . However, in areas

that are totally stubby, non-ABRs should omit the no-summary keyword because the

additional type 3 LSA filtering is performed only on ABRs.

Table 9-6 Stub Area Configuration Options

Stub Type Router OSPF Subcommand

NSSA area area-id nssa

Totally NSSA area area-id nssa no-summary

Stubby area area-id stub

Totally stubby area area-id stub no-summary

NSSAs require a few comments. The motivation for NSSAs comes from the fact that

while an area might not require knowing the full list of external networks reachable

through other areas, it is nevertheless often necessary to inject a couple of external net-

works into the OSPF domain in such areas. If such an area was configured as a stubby

area, external networks known in other areas would indeed not be advertised into it.

However, because any external network is strictly prohibited in a stubby area, it would

not be possible to configure route redistribution to inject the external routes. The NSSA

type lifts the second limitation. An NSSA is still a stubby area in the sense that external

routes from other areas are not advertised to it. However, an NSSA can hold an ASBR

and perform external route injection. This external information is carried in type 7 LSAs

Key

Topic

Key

Topic

ptg13046388

Chapter 9: OSPF 499

to distinguish it from normal external routes in type 5 LSAs, which are still prohibited

even in NSSAs. In addition, the ABR with the highest RID will perform a translation from

type 7 LSA to type 5 LSA and thereby inject the external route to other areas. An NSSA

is therefore a sensible compromise: It is allowed to inject external routing information

and “upload” it to backbone and other regular areas, and yet it still does not “download”

external routing information from the backbone or other areas, keeping its LSBD rela-

tively small. The NSSA is also the only nonregular type of area into which a default route

is not advertised automatically. To advertise a default route into an NSSA, ABRs must be

configured with the area area-id nssa default-information-originate command. All other

nonregular area types will inject a default route automatically, including totally NSSA

(NSSA-TS).

Example 9-7 , based on Figure 9-5 , shows the results of the following configuration:

■ Area 3 is configured as a totally NSSA.

■ R3 will inject an external route to 192.168.21.0/24 as a type 7 LSA.

■ Area 4 is configured as a totally stubby area.

■ Area 5 is configured as simply stubby.

Example 9-7 Stub Area Example

! R3, in a totally NSSA area, knows intra-area routes (denoted with an "IA"

! near the front of the output line from show ip route ), but the only

! inter-area route is the default route created and sent by R1, the ABR.

R3# show ip route ospf

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

O 10.3.2.0/23 [110/11] via 10.3.1.33, 00:00:00, Ethernet0/0

O*IA 0.0.0.0/0 [110/65] via 10.3.13.1, 00:00:00, Serial0/0.1

! Still on R3, the LSA type 3 summary, created by ABR R1, is shown first.

! Next, the External NSSA LSA type 7 LSA created by R3 is listed.

R3# show ip ospf database | begin Summary

Summary Net Link States (Area 3)

Link ID ADV Router Age Seq# Checksum

0.0.0.0 1.1.1.1 704 0x80000004 0x00151A

Type-7 AS External Link States (Area 3)

Link ID ADV Router Age Seq# Checksum Tag

192.168.21.0 3.3.3.3 17 0x80000003 0x00C12B 0

ptg13046388

500 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! R1, because it is attached to area 3, also has the R3-generated NSSA external

! LSA. Note the advertising router is R3, and it is an E2 external route.

R1# show ip ospf database nssa-external

OSPF Router with ID (1.1.1.1) (Process ID 1)

Type-7 AS External Link States (Area 3)

Routing Bit Set on this LSA

LS age: 188

Options: (No TOS-capability, Type 7/5 translation, DC)

LS Type: AS External Link

Link State ID: 192.168.21.0 (External Network Number)

Advertising Router: 3.3.3.3

LS Seq Number: 80000003

Checksum: 0xC12B

Length: 36

Network Mask: /24

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 10.3.13.3

External Route Tag: 0

! Below, the same command on R2, not in area 3, shows no type 7 LSAs. ABRs

! convert type 7 LSAs to type 5 LSAs before forwarding them into another area.

R2# show ip ospf database nssa-external

OSPF Router with ID (2.2.2.2) (Process ID 2)

! Next, R2 does have a type 5 LSA for the subnet; R1 converts the type 7 to a type

! 5 before flooding it into other areas.

R2# show ip ospf database | begin Type-5

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

192.168.1.0 7.7.7.7 521 0x80000050 0x003615 0

192.168.2.0 7.7.7.7 521 0x8000004D 0x00B418 0

192.168.21.0 1.1.1.1 1778 0x80000019 0x006682 0

! Below, R4 is in a totally stubby area, with only one inter-area route.

R4# show ip route ospf

O*IA 0.0.0.0/0 [110/1563] via 10.4.14.1, 00:11:59, Serial0/0.1

ptg13046388

Chapter 9: OSPF 501

! R5, in a stubby area, has several inter-area routes, but none of the

! external routes (e.g. 192.168.1.0). R5's default points to R2.

R5# show ip route ospf

10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks

O IA 10.3.13.0/24 [110/115] via 10.5.25.2, 13:45:49, Serial0.2

O IA 10.3.0.0/23 [110/125] via 10.5.25.2, 13:37:55, Serial0.2

O IA 10.1.1.0/24 [110/51] via 10.5.25.2, 13:45:49, Serial0.2

O IA 10.4.0.0/16 [110/1613] via 10.5.25.2, 13:45:49, Serial0.2

O*IA 0.0.0.0/0 [110/51] via 10.5.25.2, 13:45:49, Serial0.2

! Below, R5's costs on its interfaces are shown. Note that

! the default route's metric (51) comes from the 50 below, plus an advertised

! cost of 1 in the summary (type 3) for default 0.0.0.0/0 generated by R2. R5

! simply chose to use the default route with the lower metric.

R5# sh ip ospf int brief

Interface PID Area IP Address/Mask Cost State Nbrs F/C

Se0.1 1 5 10.5.15.5/24 64 P2P 1/1

Se0.2 1 5 10.5.25.5/24 50 P2P 1/1

Et0 1 5 10.5.1.5/24 10 DR 0/0

! Next, R2 changes the cost of its advertised summary from 1 to 15.

R2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R2(config)# router ospf 2

R2(config-router)# area 5 default-cost 15

! Below, R5's metrics to both R1's and R2's default routes tie,

! so both are now in the routing table.

R5# show ip route ospf

! Lines omitted for brevity

O*IA 0.0.0.0/0 [110/65] via 10.5.25.2, 00:00:44, Serial0.2

[110/65] via 10.5.15.1, 00:00:44, Serial0.1

The legend in the top of the output of a show ip route command lists several identifiers

that pertain to OSPF. For example, the acronym “IA” refers to inter-area OSPF routes, E1

refers to external type 1 routes, and E2 refers to external type 2 routes. If using NSSAs,

N1 refers to NSSA-external type 1 routes in NSSAs, and N2 refers to NSSA-external

type 2. The differences are equivalent to differences between E1 and E2 routes.

ptg13046388

502 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

OSPF Path Choices That Do Not Use Cost

Under most circumstances, when an OSPF router runs the SPF algorithm and finds more

than one possible route to reach a particular subnet, the router chooses the route with

the least cost. However, OSPF does consider a few conditions other than cost when mak-

ing this best-path decision. This short section explains the remaining factors that impact

which route, or path, is considered best by the SPF algorithm.

Choosing the Best Type of Path

As mentioned earlier, some routes are considered to be intra-area routes, some are inter-

area routes, and two are types of external routes (E1/N1 and E2/N2). It is possible for a

router to find multiple routes to reach a given subnet where the type of route (intra-area,

inter-area, E1/N1, or E2/N2) is different. In these cases, RFC 2328 specifies that the

router should ignore the costs and instead chooses the best route based on the following

order of preference:

1. Intra-area routes

2. Inter-area routes

3. E1/N1 routes (the E1 and N1 routes are considered equivalent)

4. E2/N2 routes (the E2 and N2 routes are considered equivalent)

For example, if a router using OSPF finds one intra-area route for subnet 1 and one inter-

area route to reach that same subnet, the router ignores the costs and simply chooses

the intra-area route. Similarly, if a router finds one inter-area route, one E1/N1 route, and

one E2/N2 route to reach the same subnet, that router chooses the inter-area route, again

regardless of the cost for each route.

Best-Path Side Effects of ABR Loop Prevention

The other item that affects OSPF best-path selection relates to some OSPF loop-

avoidance features. Inside an area, OSPF uses Link State logic, but between areas, OSPF

acts as a Distance Vector (DV) protocol. For example, the advertisement of a type 3 LSA

from one area to another hides the topology in the original area from the second area,

just listing a destination subnet, metric (cost), and the ABR through which the subnet can

be reached—all DV concepts.

OSPF does not use all the traditional DV loop-avoidance features, but it does use some

of the same underlying concepts, including Split Horizon. In OSPF’s case, it applies Split

Horizon for several types of LSAs so that information from an LSA is not advertised into

one nonbackbone area and then advertised back into the backbone area. Figure 9-9 shows

an example in which ABR1 and ABR2 both advertise type 3 LSAs into area 1, but then

they both choose to not originate a type 3 LSA containing the same network back into

area 0. This corresponds to one of the rules about type 3 LSA origination described ear-

lier: From a nonbackbone area, only internal routes can be advertised into the backbone.

Key

Topic

ptg13046388

Chapter 9: OSPF 503

Cost 1

Cost 100

Cost 1

Subnet 1

Area 2

Area 0

Area 1

Type 3 LSAs

ABR3

ABR1 ABR2

R1 R2

Figure 9-9 Split Horizon per Area with OSPF

The figure shows the propagation of some of the LSAs for subnet 1. ABR3 generates a

type 3 LSA for subnet 1 and floods that LSA within area 0. ABR1 computes its routing

table in area 0 and floods its own type 3 LSA for subnet 1 into area 1. However, when

ABR2 gets this LSA from ABR1, ABR2 does not use it in its SPF computation because

the only type 3 LSAs used in SPF by ABRs are those received over the backbone. In addi-

tion, no inter-area routes from nonbackbone areas can be advertised to backbone. These

two rules prevent ABR2 from processing this LSA and advertising the contained network

back into the backbone area. (To reduce clutter, the figure does not include arrowed lines

for the opposite direction, in which ABR2 floods a type 3 LSA into area 1, and then

ABR1 chooses not to flood a corresponding type 3 LSA back into area 0.)

Let’s restate once again the rules regarding originating and processing type 3 LSAs on

ABRs. First, when an ABR originates type 3 LSAs on behalf of known routes, it translates

only intra-area routes from a nonbackbone area into type 3 LSAs and floods them into

the backbone, and it translates both intra-area and inter-area routes from the backbone

area into type 3 LSAs and floods them into nonbackbone areas. Second, when an ABR

runs the SPF algorithm, it ignores all type 3 LSAs received over nonbackbone areas.

The first rule essentially makes sure that the only valid way of one area learning about

routes in another area is through the backbone, and that the backbone is never fed a

route that must have already traversed the backbone. An internal route begins its life as

an intra-area route in some area. If that area is a nonbackbone area, an ABR will create a

type 3 LSA on behalf of this network and flood it into the backbone. Other ABRs in the

backbone will use these type 3 LSAs along with others to compute their routing tables,

and they will create their own type 3 LSAs for both intra-area (internal to backbone) and

inter-area (behind backbone) routes and flood them into their own attached nonbackbone

areas.

ptg13046388

504 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The second rule makes sure that an ABR does not traverse a nonbackbone area to reach

a network that is located in the backbone or in some other nonbackbone area. In other

words, an ABR never uses a nonbackbone area to reach an inter-area network. Especially

when a nonbackbone area has multiple ABRs and their mutual distance in the nonback-

bone area is smaller than their distance in the backbone, one ABR could choose an inter-

area path over the nonbackbone area rather than through the backbone. The second rule

prevents this. However, the consequences of this rule can be rather surprising.

For example, without this second rule, in the internetwork of Figure 9-10 , router ABR2

would calculate a cost 3 path to subnet 1: from ABR2 to ABR1 inside area 1 and then

from ABR1 to ABR3 in area 0. ABR2 would also calculate a cost 101 path to subnet 1,

going from ABR2 through area 0 to ABR3. Clearly, the first of these two paths, with cost

3, is the least-cost path. However, ABRs use this additional loop-prevention rule, mean-

ing that ABR2 ignores the type 3 LSA advertised by ABR1 for subnet 1. This behavior

prevents ABR2 from choosing the path through ABR1, so in actual practice, ABR2 would

find only one possible path to subnet 1: the path directly from ABR2 to ABR3.

Cost 1

Cost 100

Cost 1

Cost 100

Cost 1

Subnet 1

Area 2

Area 0

Area 1

Cost 3 path Cost 101 path

Cost 1

ABR3

ABR1 ABR2

R1 R2

Figure 9-10 Effect of ABR2 Ignoring Path to Subnet 1 Through Area 1

It is important to notice that the link between ABR1 and ABR2 is squarely inside non-

backbone area 1. If this link were in area 0, ABR2 would pick the best route to reach

ABR3 as being ABR2 – ABR1 – ABR3, choosing the lower-cost route.

This loop-prevention rule has some even more interesting side effects for internal routers.

Again in Figure 9-10 , consider the routes calculated by internal Router R2 to reach subnet

1. R2 learns a type 3 LSA for subnet 1 from ABR1, with the cost listed as 2. To calculate

the total cost for using ABR1 to reach subnet 1, R2 adds its cost to reach ABR1 (cost 2),

totaling cost 4. Likewise, R2 learns a type 3 LSA for subnet 1 from ABR2, with cost 101.

ptg13046388

Chapter 9: OSPF 505

R2 calculates its cost to reach ABR2 (cost 1) and adds that to 101 to arrive at cost 102 for

this alternative route. As a result, R2 picks the route through ABR1 as the best route.

However, the story gets even more interesting with the topology shown in Figure 9-10 .

R2’s next-hop router for the R2 – ABR2 – ABR1 – ABR3 path is ABR2. So, R2 forwards

packets destined to subnet 1 to ABR2 next. However, as noted just a few paragraphs ago,

ABR2’s route to reach subnet 1 points directly to ABR3. As a result, packets sent by R2,

destined to subnet 1, actually take the path from R2 – ABR2 – ABR3. As you can see,

these decisions can result in arguably suboptimal routes, and even asymmetric routes, as

would be the case in this particular example.

OSPF Configuration

This section covers the core OSPF configuration commands, along with the OSPF con-

figuration topics not already covered previously in the chapter. (If you happened to skip

the earlier parts of this chapter, planning to review OSPF configuration, make sure to go

back and look at the earlier examples in the chapter. These examples cover OSPF stubby

area configuration, OSPF network types, plus OSPF neighbor and priority commands.)

Example 9-8 shows configuration for the routers in Figure 9-5 , with the following design

goals in mind:

■ Proving that OSPF process IDs do not have to match on separate routers, though

best practice recommends using the same process IDs across the network

■ Using the network command to match interfaces, thereby triggering neighbor dis-

covery inside network 10.0.0.0

■ Configuring S1’s RID as 7.7.7.7

■ Setting priorities on the backbone LAN to favor S1 and S2 to become the DR/BDR

■ Configuring a minimal dead interval of 1 second, with hello multiplier of 4, yielding

a 250-ms hello interval on the backbone LAN

Example 9-8 OSPF Configuration Basics and OSPF Costs

! R1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! R1 has been configured for a (minimal) 1-second dead interval, and 1/4-second

! (250 ms) hello interval based on 4 Hellos per 1-second dead interval.

interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.0

ip ospf dead-interval minimal hello-multiplier 4

! R1 uses the same stub area configuration as in Example 9-7, with network

! commands matching based on the first two octets. Note that the network commands

! place each interface into the correct area.

router ospf 1

Key

Topic

ptg13046388

506 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

area 3 nssa no-summary

area 4 stub no-summary

area 5 stub

network 10.1.0.0 0.0.255.255 area 0

network 10.3.0.0 0.0.255.255 area 3

network 10.4.0.0 0.0.255.255 area 4

network 10.5.0.0 0.0.255.255 area 5

! R2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! The R2 configuration also uses the Fast Hello feature, otherwise it

! would not match hello and dead intervals with R1. Also, OSPF on R2 is activated

! directly on interfaces using ip ospf process-id area area-id command that

! replaces

! the use of network commands. It is assumed that all interfaces are configured

! using this command so the router ospf section contains no network commands

interface FastEthernet0/0

ip address 10.1.1.2 255.255.255.0

ip ospf dead-interval minimal hello-multiplier 4

ip ospf 2 area 0

! Below, R2 uses a different PID than R1, but the PID is only used locally.

! R1 and R2 will become neighbors. Also, all routers in a stubby area must be

! configured to be that type of stubby area; R2 does that for area 5 below.

router ospf 2

area 5 stub

! R3 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Note that R3's area 3 nssa no-summary command matches R1's area command.

! However, R3 should omit the no-summary keyword, because R3 is not an ABR.

router ospf 1

area 3 nssa no-summary

network 10.0.0.0 0.255.255.255 area 3

! R4 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

router ospf 1

area 4 stub no-summary

network 10.0.0.0 0.255.255.255 area 4

! S1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! S1 matches hello and dead intervals on the LAN. Also, it sets its OSPF

! priority to 255, the maximum value, hoping to become the DR.

ptg13046388

Chapter 9: OSPF 507

interface Vlan1

ip address 10.1.1.3 255.255.255.0

ip ospf dead-interval minimal hello-multiplier 4

ip ospf priority 255

! Below, S1 sets its RID manually, removing any reliance on an interface address.

router ospf 1

router-id 7.7.7.7

network 10.1.0.0 0.0.255.255 area 0

! S2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Below, S2 also matches timers, and sets its priority to 1 less than S1, hoping

! to be the BDR.

interface Vlan1

ip address 10.1.1.4 255.255.255.0

ip ospf dead-interval minimal hello-multiplier 4

ip ospf priority 254

router ospf 1

network 10.0.0.0 0.255.255.255 area 0

Note that R3 and R4 do not need the no-summary option on the area command; this

parameter is only needed at the ABR, in this case R1. The parameters are shown here to

stress the variations of stubby areas.

OSPF Costs and Clearing the OSPF Process

Example 9-9 highlights a few details about clearing (restarting) the OSPF process, and

looks at changes to OSPF costs. This example shows the following sequence:

1. R3’s OSPF process is cleared, causing all neighbors to fail and restart.

2. R 3 ’ s log-adjacency-changes detail configuration command (under router ospf )

causes more detailed neighbor state change messages to appear.

3. R5 has tuned its cost settings with the ip ospf cost 50 interface subcommand under

S0.2 to prefer R2 over R1 for reaching the core.

4. R2 is configured to use a new reference bandwidth, changing its cost calculation per

interface.

ptg13046388

508 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 9-9 Changing RIDs, Clearing OSPF, and Modifying Cost Settings

R3# clear ip ospf process

Reset ALL OSPF processes? [no]: y

! Above, all OSPF processes are cleared on R3. R3 has the log-adjacency-changes

! detail command configured, so that a message is generated at each state

! change, as shown below for neighbor R33 (RID 192.168.1.1). (Messages for

! other routers are omitted.)

00:02:46: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Ethernet0/0 from FULL to

DOWN, Neighbor Down: Interface down or detached

00:02:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Ethernet0/0 from DOWN to

INIT, Received Hello

00:02:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Ethernet0/0 from INIT to

2WAY, 2-Way Received

00:02:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Ethernet0/0 from 2WAY to

EXSTART, AdjOK?

00:02:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Ethernet0/0 from EXSTART

to EXCHANGE, Negotiation Done

00:02:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Ethernet0/0 from EXCHANGE

to LOADING, Exchange Done

00:02:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Ethernet0/0 from LOADING to

FULL, Loading Done

! Next R5 has costs of 50 and 64, respectively, on interfaces s0.2 and s0.1.

R5# show ip ospf int brief

Interface PID Area IP Address/Mask Cost State Nbrs F/C

Se0.2 1 5 10.5.25.5/24 50 P2P 1/1

Se0.1 1 5 10.5.15.5/24 64 P2P 1/1

Et0 1 5 10.5.1.5/24 10 DR 0/0

! Below, S0.1's cost was based on bandwidth of 1544 Kbps, using the formula

! 100,000 Kbps / bandwidth with bandwidth in Kbps.

R5# sh int s 0.1

Serial0.1 is up, line protocol is up

Hardware is HD64570

Internet address is 10.5.15.5/24

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation FRAME-RELAY

Last clearing of "show interface" counters never

! Next, R2's interface costs are shown, including the minimum cost 1 on Fa0/0.

ptg13046388

Chapter 9: OSPF 509

R2# sho ip ospf int brief

Interface PID Area IP Address/Mask Cost State Nbrs F/C

Fa0/0 2 0 10.1.1.2/24 1 BDR 3/3

Se0/0.5 2 5 10.5.25.2/24 64 P2P 1/1

! Below, R2 changes its reference bandwidth from the default of 100 Mbps to

! 10,000 Mbps. That in turn changes R2's calculated cost values to be 100 times

! larger than before. Note that IOS allows this setting to differ on the routers,

! but recommends against it.

R2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R2(config)# router ospf 2

R2(config-router)# auto-cost reference-bandwidth 10000

% OSPF: Reference bandwidth is changed.

Please ensure reference bandwidth is consistent across all routers.

R2# show ip ospf int brief

Interface PID Area IP Address/Mask Cost State Nbrs F/C

Fa0/0 2 0 10.1.1.2/24 100 BDR 3/3

Se0/0.5 2 5 10.5.25.2/24 6476 P2P 1/1

While Examples 9-8 and 9-9 show some details, the following list summarizes how IOS

chooses OSPF interface costs:

1. Set the cost per neighbor using the neighbor neighbor cost value command. (This is

valid only on OSPF point-to-multipoint nonbroadcast network types.)

2. Set the cost per interface using the ip ospf cost value interface subcommand.

3. Allow the cost to default based on interface bandwidth and the OSPF Reference

Bandwidth (Ref-BW) (default 10

5 Kbps). The formula is Ref-BW / bandwidth (Kbps).

4. Default based on bandwidth, but change Ref-BW using the auto-cost reference-

bandwidth value command within the OSPF process.

The only slightly tricky part of the cost calculation math is to keep the units straight,

because the IOS interface bandwidth is kept in Kbps and the auto-cost reference-

bandwidth command’s units are Mbps. For example, on R5 in Example 9-9 , the cost is

calculated as 100 Mbps divided by 1544 Kbps, where 1544 Kbps is equal to 1.544 Mbps.

The result is rounded down to the nearest integer, 64 in this case. On R2’s Fa0/0 interface,

the bandwidth is 100,000 Kbps, or 100 Mbps, making the calculation yield a cost of 1.

After changing the reference bandwidth to 10,000, which means 10,000 Mbps, R2’s calcu-

lated costs were 100 times larger.

ptg13046388

510 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Note When choosing the best routes to reach a subnet, OSPF also considers whether a

route is an intra-area route, inter-area route, E1/N1 route, or E2/N2 route. OSPF prefers

intra-area over all the rest, then inter-area, then E1/N1, and finally E2/N2 routes. Under

normal circumstances, routes to a single subnet should all be the same type; however, it

is possible to have multiple route paths to reach a single subnet in the OSPF SPF tree, but

with some of these routes being a different type. Example 11-7 in Chapter 11 demon-

strates this.

Alternatives to the OSPF network Command

As of Cisco IOS Software Release 12.3(11)T, OSPF configuration can completely omit the

network command, instead relying on the ip ospf process-id area area-id interface sub-

command. This new command enables OSPF on the interface and selects the area.

The network and ip ospf area commands have some minor differences when second-

ary IP addresses are used. With the network command, OSPF advertises stub networks

for any secondary IP subnets that are matched by the command. (“Secondary subnet”

is jargon that refers to the subnet in which a secondary IP address resides.) The ip ospf

area interface subcommand causes any and all secondary subnets on the interface to be

advertised as stub networks—unless the optional secondaries none parameter is included

at the end of the command.

Regardless of the network or ip ospf area command, OSPF will always establish adjacen-

cies over an interface only using the primary IP address. OSPF will never use secondary

addresses to establish an adjacency.

OSPF Filtering

Intra-routing protocol filtering presents some special challenges with link-state routing

protocols like OSPF. Link-state protocols do not advertise routes—they advertise topol-

ogy information. Also, SPF loop prevention relies on each router in the same area hav-

ing an identical copy of the LSDB for that area. As mentioned in the section about LSA

types, only the router that has originated an LSA is ever allowed to modify its contents.

Filtering or changing LSA contents in transit could conceivably make the LSDBs differ on

different routers, causing routing irregularities.

IOS supports three variations of what could loosely be categorized as OSPF route filter-

ing. These three major types of OSPF filtering are as follows:

■ Filtering routes, not LSAs: Using the distribute-list in command, a router can fil-

ter the routes that its SPF process is attempting to add to its routing table, without

affecting the LSDB.

■ ABR type 3 LSA filtering: A process of preventing an ABR from creating particular

type 3 summary LSAs.

Key

Topic

ptg13046388

Chapter 9: OSPF 511

■ Using the area range no-advertise option: Another process to prevent an ABR from

creating specific type 3 summary LSAs.

Each of these three topics is discussed in sequence in the next few sections.

Filtering Routes Using the distribute-list Command

For RIP and EIGRP, the distribute-list command can be used to filter incoming and out-

going routing updates. The process is straightforward, with the distribute-list command

referring to ACLs or prefix lists. With OSPF, the distribute-list in command filters what

ends up in the IP routing table, and only on the router on which the distribute-list in

command is configured.

Note The redistribute command, when used for route distribution between OSPF and

other routing protocols, does control what enters and leaves the LSDB. Chapter 11 covers

Further Reading

Jeff Doyle’s Routing TCP/IP , Volume I, Second Edition—every word a must for CCIE

Routing and Switching.

Cisco OSPF Command and Configuration Handbook , by Dr. William Parkhurst, covers

every OSPF-related command available in Cisco IOS at the time of that book’s publica-

tion, with examples of each one.

The CCIE Routing and Switching v5.0 exam blueprint also mentions the OSPF IP Fast

Reroute features. More information about them can be found on the Cisco website in the

IP Routing: OSPF Configuration Guide for Cisco IOS Release 15S, specifically in the

"OSPFv2 Loop-Free Alternate Fast Reroute" and "OSPF IPv4 Remote Loop-Free Alternate

IP Fast Reroute" sections. Also, many Cisco Live! sessions cover these features, including

"IP LFA (Loop-Free-Alternative): Architecture and Troubleshooting" (BRKRST-3020) and

"Routed Fast Convergence" (BRKRST-3363), available at www.ciscolive365.com. At the

time of writing, these features were supported only on service provider IOS, IOS-XE, and

IOS-XR image builds and will not be present on the Lab exam. The Written exam might

cover general properties of these features.

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ Describe a Basic IS-IS Network in a Single Area and

a Single Topology

■ Describe Neighbor Relationships

■ Describe Network Types, Routing Levels, and

Router Types

■ Describe IS-IS Operations

■ Describe Metrics and Wide Metrics

ptg13046388

This chapter covers IS-IS, the other link-state routing protocol covered by the CCIE

Routing and Switching exam. Inclusion of the Intermediate System–to–Intermediate

System (IS-IS) into the Routing and Switching track might be surprising, as IS-IS is more

associated with service provider environments. Still, with the ever-increasing prolifera-

tion of IPv6, TRILL, and FabricPath, compounded with the intrinsic OSPFv3 complex-

ity, IS-IS, with its inherent multiprotocol capability, simplicity, and general flexibility, is

becoming more interesting, even for enterprise deployments.

“Do I Know This Already?” Quiz

Table 10-1 outlines the major sections in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 10-1 “Do I Know This Already?” Foundation Topics Section-to-Question

Mapping

Foundation Topics Section Questions Covered in This

Section

S c o r e

OSI Network Layer and Addressing 1–4

Levels of Routing in OSI Networks 5–7

IS-IS Metrics, Levels, and Adjacencies 8–10

IS-IS Packet Types 11–15

IS-IS Operation over Different Network Types 16–20

Areas in IS-IS 21–24

Authentication in IS-IS 25–27

IPv6 Support in IS-IS 28–29

Configuring IS-IS 30–33

Total Score

CHAPTER 10

IS-IS

ptg13046388

564 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.” In all

items, try to select all correct answers.

1. How many NSAP addresses are usually configured on a router?

a. One per every active (up/up) interface with IS-IS configured

b. One per every interface with IS-IS configured

c. One per area

d. One per node

2. What is the size of an NSAP address?

a. Fixed length of 20 octets

b. Fixed length of 32 octets

c. Variable length ranging from 8 to 20 octets

d. Variable length ranging from 16 to 32 octets

3. What is the common length of the System ID field?

a. 8 octets

b. 6 octets

c. 4 octets

d. 1 octet

e. 4 bits

4. In the NSAP 49.0001.FF11.2233.4455.6600, what is the value of the System ID field?

a. 49.0001

b. FF11.2233

c. FF11.2233.4455

d. FF11.2233.4455.6600

e. 2233.4455

f. 2233.4455.6600

g. 1122.3344.5566

5. In OSI terminology, intra-area routing is also called which of the following?

a. L0 routing

b. L1 routing

c. L2 routing

d. L3 routing

ptg13046388

Chapter 10: IS-IS 565

6. In OSI terminology, inter-area routing within a domain is also called which of the

following?

a. L0 routing

b. L1 routing

c. L2 routing

d. L3 routing

7. In OSI terminology, interdomain routing is also called which of the following?

a. L0 routing

b. L1 routing

c. L2 routing

d. L3 routing

8. What is the range of metrics defined by the original IS-IS standard?

a. 6 bits for interface metric, 10 bits for total metric

b. 8 bits for interface metric, 16 bits for total metric

c. 16 bits for interface metric, 32 bits for total metric

d. 24 bits for interface metric, 32 bits for total metric

9. What is the width of metrics if wide metrics are activated?

a. 24 bits for interface metric, 32 bits for total metric

b. 16 bits for interface metric, 24 bits for total metric

c. 32 bits for interface metric, 32 bits for total metric

d. There is no concept of wide metrics in IS-IS.

10. Select the correct answer about the established adjacency type, assuming that the

routers are directly connected.

a. R1: L1L2, R2: L2, both in the same area. L2 adjacency will be created.

b. R1: L1L2, R2: L2, both in the same area. L1 and L2 adjacencies will be created.

c. R1: L1L2, R2: L1L2, each in a different area. L1 and L2 adjacencies will be

created.

d. R1: L1L2, R2: L1L2, each in a different area. L2 adjacency will be created.

e. R1: L1, R2: L1L2, both in the same area. L1 and L2 adjacencies will be created.

f. R1: L1, R2: L1L2, both in the same area. L1 adjacency will be created.

g. R1: L1 R2: L1, each in a different area. No adjacency will be created.

h. R1: L2 R2: L2, each in a different area. L2 adjacency will be created.

ptg13046388

566 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

11. How many IIH types are sent in default configuration over a broadcast link?

a. One; L1 IIH

b. One; L2 IIH

c. One; L1L2 IIH

d. Two, L1 and L2 IIHs

12. Do the timers on neighboring IS-IS routers need to match?

a. Ye s

b. Only on point-to-point links

c. Only on broadcast links

d. N o

13. Which of the following fields can be used to identify an LSP?

a. Area ID

b. System ID

c. NSEL

d. Pseudonode ID

e. Fragment

f. S N PA

14. Can an LSP be fragmented?

a. Yes. Any router can fragment any LSP according to its interface MTU.

b. Yes, but only the originator of an LSP can fragment it.

c. Yes, but only backbone routers can fragment an LSP (regardless of its origi-

nator).

d. No. LSP packets cannot be fragmented.

15. Which packets are used to request or acknowledge an LSP?

a. IIH

b. SNPA

c. CSNP

d. PSNP

ptg13046388

Chapter 10: IS-IS 567

16. Which of the following states are valid adjacency states in IS-IS?

a. D o w n

b. Init

c. 2 W a y

d. Exchange

e. Full

f. U p

17. How is a Backup DIS elected in IS-IS?

a. By its priority

b. By its SNPA

c. By its System ID

d. There is no Backup DIS in IS-IS.

18. What is the DIS election based on?

a. Interface priority

b. U p t i m e

c. System ID

d. SNPA

e. IP address

19. Does the IS priority of 0 have any special significance?

a. N o

b. Yes. The router will not participate in DIS elections.

c. Yes. The router will not be considered by others during their SPF run.

d. Yes. The router will act as an area boundary router.

20. How many DISs are going to be elected on a common broadcast segment with ten

routers in default IS-IS configuration if the router adjacencies have been fully estab-

lished?

a. Only one. A DIS function is shared between L1 and L2.

b. Two, one for L1 and one for L2, each level having a different router as the DIS.

c. Two, one for L1 and one for L2, with the same router winning DIS in both levels.

d. None. IS-IS treats all links as point-to-point by default.

ptg13046388

568 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

21. It is possible to renumber, merge, or split areas in IS-IS without network disruption.

a. False

b. T r u e

22. What IPv4/IPv6 prefixes are advertised in an L1 LSP?

a. Directly attached networks

b. Networks from a router’s own area

c. Networks from other areas

d. Redistributed networks if redistribution into L1 is configured

23. What IPv4/IPv6 prefixes are advertised in an L2 LSP?

a. Directly attached networks

b. Networks from a router’s own area

c. Networks from other areas

d. R e d i s t r i b u t e d n e t w o r k s

24. In what mode must a backbone router operate if all other routers in its own area are

L1-only routers?

a. L1-only

b. L 1 L 2

c. L2-only

d. As the area is a totally stubby area, the level setting on the backbone router is

irrelevant.

25. Which statements are true about authentication in IS-IS?

a. All packet types are always authenticated by a common password.

b. P2P IIH packets can be authenticated independently for each level.

c. LAN IIH packets can be authenticated independently for each level.

d. Each of LSP, CSNP, and PSNP packet types can be authenticated by an inde-

pendent password.

e. IIH packets can be authenticated independently from LSP+CSNP+PSNP

packets.

f. If authentication is configured, LSP+CSNP+PSNP packets are authenticated by

a common password for both levels.

g. If authentication is configured, LSP+CSNP+PSNP packets can be authenticated

in each level independently.

ptg13046388

Chapter 10: IS-IS 569

26. What authentication mechanisms are currently available for IS-IS?

a. Plaintext

b. AES

c. 3DES

d. MD5

27. Which statements are true about authentication in IS-IS?

a. If using key chains, key numbers must match, even with the plaintext authenti-

cation method.

b. If using key chains, key numbers do not need to match, even with the MD5

authentication method.

c. Authentication password for L1 LSP+CSNP+PSNP must match only between

directly connected neighbors.

d. Authentication password for L1 LSP+CSNP+PSNP must match across the area.

e. Authentication password for L1 LSP+CSNP+PSNP must match across the

domain.

f. Authentication password for L2 LSP+CSNP+PSNP must match only between

directly connected neighbors.

g. Authentication password for L2 LSP+CSNP+PSNP must match across the area.

h. Authentication password for L2 LSP+CSNP+PSNP must match across the

domain.

28. Which statements are true about IPv6 support in IS-IS?

a. When IPv6 support is activated, IS-IS packets are sent to the FF02::2 multicast

IPv6 address.

b. Separate LSPs are generated for IPv4 and IPv6 prefixes.

c. IPv4 and IPv6 prefixes can coexist in a single LSP.

d. Separate NSAP/NET addresses have to be configured for IPv4 and IPv6 IS-IS

instances.

e. A single IS-IS process advertises both IPv4 and IPv6 routes.

f. The System ID of an IS-IS router has to be derived from its IPv6 loopback

address.

ptg13046388

570 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

29. Which statements are true regarding advertising a local interface’s IPv6 prefix in

IS-IS?

a. The address-family ipv6 section must be created in router isis mode before

IS-IS can start advertising IPv6 prefixes.

b. The ip router isis command in interface configuration mode applies both to

IPv4 and IPv6 prefixes configured on the interface.

c. The prefix command in the address-family ipv6 section of the router isis mode

can be used to advertise locally connected prefixes.

d. The ipv6 router isis command in interface configuration mode is used to adver-

tise that interface’s IPv6 prefixes.

30. Which values can be used to manually derive a System ID for an IS-IS router?

a. Any arbitrary value as long as it is unique

b. Any router’s MAC address

c. Any router’s IP address after an appropriate transliteration

d. None of these answers applies; Cisco routers derive a System ID automatically.

31. How can the logging of neighbor state changes be activated for an IS-IS process?

a. The logging is activated automatically; no action is necessary.

b. log-adjacency-changes all command in router isis m o d e

c. isis log-neighbor-changes command in global configuration mode

d. isis neighbor log-changes command in interface configuration mode

32. How can a local interface’s IPv4 prefix be advertised in IS-IS?

a. Using the network command in router isis m o d e

b. Using the ip router isis command in interface configuration mode

c. Using the passive-interface command in router isis m o d e

d. No command is necessary; IS-IS automatically advertises IPv4 prefixes of all

local interfaces on a router.

33. How can summarization be configured in IS-IS?

a. Using the summary-address command in router isis mode for IPv4 prefixes

b. Using the summary-prefix command in the address-family ipv6 section of the

router isis mode for IPv6 prefixes

c. Using the isis summary command in interface mode for both IPv4 and IPv6

prefixes

d. IS-IS does not support summarization.

ptg13046388

Chapter 10: IS-IS 571

Foundation Topics

IS-IS is covered in this chapter in more depth than the CCIE Routing and Switching exam

blueprint officially requires. Considering, however, the perceived “otherworldliness” of

IS-IS, we felt it was necessary to provide a significantly larger overview of Open Systems

Interconnection (OSI) protocol operations with particular focus on IS-IS, to put things

into perspective, and to show you that some ideas from OSI networks on which IS-IS is

also based can be found, in a certain modification, in our TCP/IP environments. It is natu-

ral for us humans to treat a nonmainstream, different approach to things with a reserved

attitude, and if you are relatively new to IS-IS, you will very probably have this feeling

of “why did they do it so differently?” more often than not. Nevertheless, try to keep an

open, unbiased mind. Discovering and learning about different ways to do things can be

extremely enlightening.

IS-IS is a link-state routing protocol originally specified in ISO/IEC standard 10589:2002,

and initially created for OSI networks. Internally, it uses the same Dijkstra Shortest Path

First (SPF) algorithm as Open Shortest Path First (OSPF). The true dependence of IS-IS

on OSI protocols and principles is remarkably low, though. IS-IS uses so-called Network

Service Access Point (NSAP) addressing, described in the following section, to iden-

tify individual routers, their area memberships, and their adjacencies, and is designed

to provide Level 1 (intra-area) and Level 2 (inter-area) routing according to OSI rout-

ing hierarchies. Apart from that, however, there is little OSI-specific left. IS-IS does not

run over any network layer protocol; instead, it encapsulates its messages directly into

data-link frames. Adjacency and addressing information in IS-IS messages is encoded as

Type-Length-Value (TLV) records, thereby providing excellent flexibility and extendabil-

ity. Enhancing IS-IS for a new address family is a matter of defining new TLVs to carry

the desired addressing information along the existing topology information, without

requiring any changes to the underlying protocol operations or message formats. Based

on these characteristics, IS-IS is best described as being protocol-agnostic. RFC 1195

specified how the original IS-IS for OSI networks can be extended to support IP routing

along with OSI routing in a single IS-IS instance, coining the term Integrated IS-IS. Since

then, IS-IS development and further extensions have been strongly driven by the IETF in

numerous RFCs.

The chapter begins with a light introduction into OSI networks and focuses on NSAP

addressing in these networks that is retained by IS-IS. After discussing the routing levels,

IS-IS is introduced in greater detail, its packet types are discussed, and link-state database

is explained. We then have a look at the IS-IS operation on point-to-point and broad-

cast links; discuss the multiarea routing in IS-IS, authentication, and IPv6 support; and

end with a commented configuration example. The chapter predominantly focuses on

explaining the principles and fundamentals of IS-IS. Its configuration is relatively simple,

and while shown in a relatively extensive way, the CCIE Routing and Switching blueprint

itself focuses more on the “Describe” aspect of IS-IS, rather than “Configure, Maintain,

Operate, and Troubleshoot.”

ptg13046388

572 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Originally, IS-IS started as a routing protocol for ISO OSI networks and is naturally influ-

enced in its fundamental aspects by the OSI approach to networking. Therefore, to under-

stand IS-IS well, it is important to review the key concepts of OSI networks first.

OSI Network Layer and Addressing

Whenever the OSI acronym is mentioned, a person working in networking immedi-

ately thinks of the OSI Reference Model developed by the International Standards

Organization. The OSI Reference Model is common knowledge among networkers, and

no doubt every well-prepared CCIE candidate could talk about it even in his sleep. It is

somewhat less known, however, that ISO also created protocol specifications for individ-

ual layers of this reference model, and many of those protocols are actually implemented

and in use. While they have never been anywhere near TCP/IP’s popularity and adoption

(for several reasons not to be discussed here), ISO OSI protocols have been nonetheless

widely implemented, for example, in telecommunications equipment and networks and

in aviation. The OSI Reference Model and related protocols were developed indepen-

dently of the TCP/IP protocol suite, and TCP/IP creators never intended to follow the OSI

Reference Model. As a result, many aspects of OSI networks are foreign to network pro-

fessionals who have been in touch only with TCP/IP networks. While it might be tempt-

ing to approach these differences with distrust or contempt, it is best to keep an open

mind without biases or preconceptions.

ISO OSI terminology is significantly different. In ISO-speak, as many authors call it,

there are no hosts or routers. Instead, the term End System (ES) is used for a host, and

the term Intermediate System (IS) is used for a router. The term System alone describes

a network node. Also, the term Circuit stands for interface, and the term Domain stands

for autonomous system. Hence, an end-to-end communication between two End Systems

(hosts) in a Domain (autonomous system) involves zero or more Intermediate Systems

(routers) interconnected by Circuits (interfaces). We will introduce a couple of other

terms later in the chapter.

The network layer specification of the OSI Reference Model that is concerned with end-

to-end communication between two ES entities calls for two basic services: connection-

less-mode and connection-mode network layer communication. The connectionless mode

of operation is identical to the way that IP operates, as a pure datagram service without

any prior session establishments. In OSI networks, the Layer 3 network protocol that

provides a connectionless communication between ES entities is called ConnectionLess-

mode Network Protocol (CLNP) and is specified in ISO/IEC 8473-1:1998. The ITU-T

republished its specification in the X.233 recommendation. The CLNP protocol is to OSI

networks what IPv4/IPv6 are to TCP/IP networks. The set of services provided by CLNP

is called ConnectionLess Network Services, or simply CLNS. We will be seeing a number

of commands, mostly of the show clns... format, that refer to a router’s operation in OSI

connectionless mode, including IS-IS. For connection-oriented mode in OSI networks, an

adaptation of the X.25 protocol is used. There is no analogous connection-oriented net-

work layer protocol in TCP/IP networks.

Key

Topic

ptg13046388

Chapter 10: IS-IS 573

End-to-end communication requires addressing on the network layer. The addressing

used in OSI networks, both in connectionless and connection-oriented mode, is called

NSAP addressing , with the acronym standing for Network Service Access Point repre-

senting an address of a particular network service on a particular network node in the

network. This form of addressing is defined in its basic form in ISO/IEC 8348, and the

ITU-T republished this standard in its X.213 recommendation. Further details of NSAP

addressing are specified in the IS-IS ISO/IEC 10589:2002 standard. This chapter explains

the NSAP addressing by combining knowledge from both standards.

NSAP addressing bears many differences to addressing in TCP/IP networks. An NSAP

address is assigned to the entire network node , not to its individual interfaces. A single

node requires only one NSAP address in a common setup, regardless of how many net-

work interfaces it uses. As a result, NSAP addressing does not have the notion of per-

interface subnets similar to IP subnets. An approximate analogy can be created in an IPv6

network by assigning each node a global IPv6 address to its loopback interface only, leav-

ing all physical network interfaces running only with IPv6 link-local addresses, and run-

ning a routing protocol over all loopbacks and physical links to allow all nodes to learn

about each other’s global address and the path toward it.

Figure 10-1 shows the basic format of an NSAP address.

IDP DSP

AFI IDI HO-DSP System ID SEL

Figure 10-1 NSAP Address Format

At a high level, an NSAP address consists of two parts:

■ The Initial Domain Part (IDP)

■ The Domain Specific Part (DSP)

The internal format and length of these two parts are variable to a large extent and

depend on the actual application in which the NSAP addressing is used. As a result, an

NSAP address has a variable length.

The IDP itself consists of two fields: the Authority and Format Identifier (AFI) and the

Initial Domain Identifier (IDI). The AFI value (1 octet in the range of 00 to FF) indicates

the format of the remaining address fields. The IDI field has a variable length depending

on the address format indicated by AFI and might even be omitted. Together, the AFI and

IDI indicate the routing domain (the autonomous system) in which the node is located.

The format of DSP is again dependent on the particular address format. However, at least

in a general approach, the DSP consists of a variable-length High-Order Domain Specific

Part (HO-DSP) that identifies the part (or an area ) of the domain in which the node is

located. This field can be further structured into subfields. The System ID is the unique

identifier of the node itself. While NSAP allows this field to be from 1 to 8 octets long,

all current implementations fix the length of the System ID field to 6 octets. Finally, the

Key

Topic

Key

Topic

ptg13046388

574 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

SEL field, also called an NSAP Selector or NSEL, is a 1-octet-long field that identifies

the particular service in or above the network layer on the destination node that should

process the datagram. A rough analogy in the IP world would be the particular protocol

above IP, or the transport port.

Table 10-2 lists some of the most often used NSAP address formats.

Table 10-2 Selected NSAP Address Formats

AFI Meaning IDI Length and Contents HO-DSP Length

and Contents

39 Use of Data Country

Code (ISO 3166)

2 octets; numeric country code

according to ISO 3166

10 octets; area

number

45 Use of international phone

numbers (ITU-T E.164)

8 octets; international phone

number according to E.164

4 octets; area

number

47 Use of International Code

Designator (ISO 6523)

2 octets; international organization

code according to ISO 6523

10 octets; area

number

49 Locally defined format

(private addressing; free

format)

Formally not present Between 0 and 12

octets; area number

In each of these AFI types, the HO-DSP (the area number) can be further internally

structured; however, these details are not relevant at this point. In typical IS-IS deploy-

ments, the addressing uses the AFI of 49 in which the length and meaning of the

HO-DSP field are entirely up to the administrator. While this system of addressing might

be perceived as complex and possibly cumbersome, it is nonetheless very flexible and

adaptable to various enumeration approaches.

The minimum size of an NSAP address is 8 octets—with only AFI, System ID, and SEL

fields present. The maximum NSAP address size is 20 octets.

The SEL octet deserves a special mention. As mentioned earlier, it is used to address the

datagram to a particular service at the destination node. As an example, the SEL value

of 22 or 1D indicates the OSI TP4 transport layer protocol (different vendors appear

to use different SEL values); the value of 2F indicates a GRE IP-over-CLNP tunneling.

Specifically, if the value of the SEL octet is 0, no particular service is being addressed,

and the entire NSAP address simply identifies the destination node itself without refer-

ring to any particular service on that node. An NSAP address in which the SEL octet is

set to 0 is called a Network Entity Title (NET), and this is the address that is configured

on the node. Configuration of NETs will be a mandatory part of IS-IS configuration.

To summarize, NSAP addresses can be thought to contain, in a single instance, informa-

tion about the destination’s autonomous system, area, unique identifier, and even the

requested upper-layer service.

ptg13046388

Chapter 10: IS-IS 575

The written format of NSAP addresses uses hexadecimal digits separated into groups

of one or more octets by a dot. Usually, the AFI value (1 octet; 2 hexadecimal digits) is

immediately separated by a dot for better readability, with the remainder of the NSAP

address simply written in two-octet groups, for example, 49.0001.1234.5678.3333.00. In

this address, the AFI is 49, signifying a local address; the 0001 is the area number; the

1234.5678.3333 is the System ID of the node; and the trailing 00 is the SEL value, mak-

ing this NSAP address also a NET. The use of the dot, however, is arbitrary, as long as it

separates groups of integer octet length. Therefore, all the following notations represent

the same address:

49.0001.1234.5678.3333.00

4900.0112.3456.7833.3300

49.00.01.12.34.56.78.33.33.00

49000112.34.5678.33.3300

49000112345678333300

Whenever any of these NSAP addresses is configured on a Cisco router, it rewrites the

address into the notation used in the first line.

An NSAP address is often easier to read from right to left. In the NSAP address

49.0001.1234.5678.3333.00, the rightmost octet is the SEL value (00), the following six

octets are the System ID (1234.5678.3333), followed by other HO-DSP octets (0001), IDI

(not present in this NSAP) and ending with the leftmost octet, the AFI (49).

To visualize a network using NSAP addressing, consider the topology shown in Figure

10-2 .

49.0001.1234.5678.3333.00

49.0001.90AB.CDEF.2222.00

49.0001.0000.0000.1111.00

49.0001.FFFF.0000.0001.00

49.0001.FFFF.0000.0002.00

49.0001.DEAD.BEEF.4444.00

49.0001.600D.CAFE.5555.00

Figure 10-2 Network with NSAP Addressing

Addressing in Figure 10-2 again uses the local NSAP space, indicated by the AFI value

of 49. For better readability, the System ID portion of the NSAP address has been under-

lined in the figure. Note that all nodes in the network are in the same area, 0001. Each

node has a unique System ID. As there is no concept of a subnet, routing between the

two networks is accomplished by each IS assembling a list of all attached ES nodes and

advertising it to its neighbors.

Key

Topic

ptg13046388

576 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Individual interfaces are not assigned their own addresses at the network layer. However,

their Layer 2 addresses are used in the same way as TCP/IP networks use them: When a

packet is routed, it is encapsulated into a frame addressed to the next directly attached

hop identified by its Layer 2 address. In OSI networks, a Layer 2 address of an interface

is called a Sub Network Point of Attachment (SNPA).

Finally, for purposes of distinguishing between interfaces of the same node, an IS enu-

merates its interfaces by a locally significant 1-octet number called the Local Circuit ID,

which increments by 1 with every interface added to the IS-IS instance beginning with 0

on Cisco routers.

Levels of Routing in OSI Networks

Routing in OSI networks has a concept of hierarchies, or levels , depending on the net-

work scope in which the routing is performed. Four levels of routing are defined:

■ Level 0 routing: Routing between two ES nodes on the same link, or between an ES

node and its nearest IS

■ Level 1 routing: Routing between ES nodes in a single area of a domain

■ Level 2 routing: Routing between ES nodes in different areas of a domain

■ Level 3 routing: Routing between ES nodes in different domains

Level 0 routing is concerned with the way that an ES (end node) discovers its nearest IS

(gateway), and conversely, how an IS knows which ES nodes are connected to it. This is

accomplished by both ES and IS sending a periodic Hello message advertising their exis-

tence. Aptly named, Hellos sent by ES nodes are called ES Hello (ESH), while Hellos sent

by IS nodes are called IS Hello (ISH). Level 0 routing is also referred to as ES-IS routing

(the ES-IS protocol is covered in publicly available standard ISO 9542). In IPv6-based

networks, Level 0 routing is vaguely similar to routers sending Router Advertisement

messages, allowing stations to detect their presence, and hosts sending Neighbor

Advertisements, although the Neighbor Advertisements are not sent periodically.

Level 1 routing is concerned with intra-area routing, that is, routing between ES nodes

that are members of the same area. An area is understood in the usual meaning: It is an

administrative partitioning of a domain, and in terms of link-state routing, IS nodes in an

area will have a detailed and complete visibility of the entire area’s topology. On Level 1,

IS nodes collect lists of all ES nodes directly attached to them, and advertise these lists to

each other to learn the placement of all ES nodes.

Level 2 routing is concerned with inter-area routing within the same domain, that is, rout-

ing between ES nodes that reside in different areas of the same domain. On Level 2, IS

nodes do not advertise the list of connected ES nodes anymore. Instead, in this level, IS

nodes exchange area prefixes to learn how to reach particular areas. If a Level 1 IS deter-

mines that the packet’s destination ES is in a different area, it will forward the packet

toward the nearest IS capable of Level 2 routing, regardless of the destination area. The

packet will then be forwarded by Level 2–capable IS nodes until it reaches the area with

Key

Topic

ptg13046388

Chapter 10: IS-IS 577

the destination ES where it will again be forwarded by Level 1 IS nodes. Hence, Level 1

routing can be described as routing by System ID, while Level 2 routing can be described

as routing by area prefix. Level 2 routing constitutes the backbone of a domain, providing

communication between individual areas of the domain. Level 1 and Level 2 routing are

provided by the IS-IS routing protocol (ISO 10589), which is the focus of this chapter.

Level 3 routing is concerned with interdomain routing. In a TCP/IP world, this is a fairly

direct analogy of inter-autonomous system routing provided by Border Gateway Protocol

(BGP). In OSI networks, the original intended routing protocol was Inter Domain Routing

Protocol (IDRP, ISO 10747). However, with BGP being a multiprotocol interdomain rout-

ing protocol also capable of carrying information about NSAP addresses, today’s OSI

networks are replacing IDRP with BGP.

IS-IS provides Level 1 and Level 2 routing. Level 0 and Level 3 routing are provided by

different mechanisms and are not relevant for TCP/IP networks.

IS-IS Metrics, Levels, and Adjacencies

IS-IS metrics are assigned to individual interfaces (links). The original IS-IS specification

defines four types of metrics:

■ Default: Required to be supported by all IS-IS implementations; usually relates to

the bandwidth of the link (higher value represents a slower link)

■ Delay: Relates to the transit delay on the link

■ Expense: Relates to the monetary cost of carrying data through the link

■ Error: Relates to the residual bit error rate of the link

Each of these metrics is intended to be evaluated independently in the SPF calculation,

effectively resulting in four independent shortest-path trees (and thus routing tables),

each one computed according to a particular metric. Most IS-IS implementations today

support only the default metric.

Cisco IS-IS implementation assigns all interfaces the default metric of 10, regardless of

their bandwidth. Contrary to OSPF implementation, Cisco IOS does not automatically

recalculate an interface’s bandwidth into its IS-IS metric. It is up to the administrator to

configure different interface metrics if necessary using the isis metric metric [ level ]

per-interface command. Other types of metrics can be configured but are advertised as

unsupported in IS-IS advertisements.

The original IS-IS specification and RFC 1195 define any single interface (link) and

attached network metric to be 6 bits wide, resulting in the range of 1–63, and the com-

plete path metric as 10 bits wide in the range of 1–1023. At the time IS-IS was defined,

these metric widths were considered adequate. Today’s requirements, however, call for a

much wider range of metrics. Therefore, in RFC 3784 (now RFC 5305), so-called wide

metrics were introduced, allowing for a 24-bit width for the interface metric and a 32-bit

width for the entire path metric. The same RFC also defines a set of information elements

augmenting the wide metrics for use in MPLS Traffic Engineering applications. The

Key

Topic

Key

Topic

ptg13046388

578 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

original metrics were retroactively named narrow metrics . It is strongly recommended to

use wide metrics whenever available and supported; however, all routers in an area must

use the same type of metrics.

IS-IS routers operate on each routing level independently. For each routing level, be it

Level 1 or Level 2, an IS-IS router establishes separate adjacencies with its neighbors

running on the same level, and maintains a separate link-state database. A router config-

ured for Level 1 routing establishes adjacencies only with those neighbors that are also

configured for Level 1 routing. Similarly, a router configured for Level 2 routing creates

adjacencies only with neighbors also configured for Level 2 routing. A Level 1–only

router will not establish an adjacency to a Level 2–only router. Two neighboring routers

configured for both Level 1 and Level 2 routing will create two independent adjacencies,

one for each level. In addition, as each router belongs to a single area (recall that only

a single NET is usually configured on a router, and the NET carries the area identifier),

Level 1 adjacencies are created only between routers with the same area identifier. Table

10-3 documents the resulting adjacency for different combinations of neighboring rout-

ers’ levels.

Table 10-3 Adjacencies Between Routers

1st Neighbor’s Level 2nd Neighbor’s Level Resulting Adjacency

Level 1 only Level 1 only Level 1 if area matches

Level 1 only Level 1 + 2 Level 1 if area matches

Level 1 only Level 2 only No adjacency

Level 1 + 2 Level 1 + 2 Level 1 if area matches

Level 2

Level 1 + 2 Level 2 only Level 2

Level 2 only Level 2 only Level 2

IS-IS routers maintain a separate link-state database for each routing level they operate

on. For each enabled level, a router originates and floods a Link State PDU (LSP; not to

be confused with Label Switched Path, which is an unrelated term from MPLS using the

same acronym). An LSP is similar to an OSPF Link State Update packet with one or more

Link State Advertisements. IS-IS routers use Level 1 and Level 2 LSPs to describe their

adjacencies on that particular level. As a result, a Level 1 link-state database contains only

Level 1 LSPs describing only Level 1 adjacencies of their respective originating routers.

Similarly, a Level 2 link-state database contains only Level 2 LSPs describing only Level

2 adjacencies of their originating routers. Contents of a Level 1 link-state database are

exchanged only over Level 1 adjacencies, and Level 2 link-state database contents are

exchanged over Level 2 adjacencies only. Illustratively, albeit slightly imprecisely, IS-IS

can be thought as running a separate instance (or a process) on each routing level. While

individual LSPs never leak between Level 1 and Level 2 databases, routing information

Key

Topic

ptg13046388

Chapter 10: IS-IS 579

computed using a particular link-state database can be injected in a very controlled way

into the other database. Rules of doing that will be discussed further in the chapter.

IS-IS Packet Types

IS-IS defines four basic types of packets:

■ Hello packet

■ Link State PDU

■ Complete Sequence Numbers PDU

■ Partial Sequence Numbers PDU

To ease the understanding, we will often be comparing IS-IS packet types to OSPF packet

types, drawing on their similarities and differences, assuming that the reader is already

well-acquainted with OSPF packets, their purpose, and contents. However, OSPF and

IS-IS have been developed independently, and any comparisons here are used only to

highlight similarities and differences, and should not suggest in any way that one proto-

col tries to mimic, more or less successfully, the other.

Hello Packets

Hello packets, also denoted as IIH (IS-IS Hello), are used to perform the usual task of

detecting neighboring routers (and also their loss), verifying bidirectional visibility,

establishing and maintaining adjacencies, and electing a Designated IS (DIS—similar to

a Designated Router in OSPF). On broadcast-type interfaces, IS-IS routers use separate

Hello packet types for L1 and L2 adjacencies. On point-to-point type interfaces, for

efficiency reasons, a single L1L2 Hello, also called a point-to-point Hello, is used. Each

router sends Hello packets every 10 seconds by default; the interval can be configured in

the range of 1 to 65535 seconds using a per-interface isis hello-interval seconds [ level ]

command for a particular routing level. Instead of defining a Hold timer directly, a Hello

multiplier value is used to compute the Hold time as the Hello value multiplied by the

Hello multiplier value. The default Hello multiplier value is 3, resulting in a Hold time of

30 seconds. The multiplier value can be changed by a per-interface isis hello-multiplier

multiplier [ level ] command. As opposed to OSPF, timers do not need to match on

neighboring routers.

On a DIS, the individual timers are always one-third of the configured timers (with

default settings)—a DIS sends Hellos every 10/3=3.333 seconds, and the Hold interval is

30/3=10 seconds. With settings changed to a Hello time of 6 seconds and a Hello mul-

tiplier of 4, for example, a DIS would then send Hello packets every 6/3=2 seconds, and

advertise a Hold interval of 24/3=8 seconds. This is done to detect a DIS or its outage

Further Reading

Jeff Doyle’s Routing TCP/IP , Volume I, Second Edition; every word a must for CCIE

Routing and Switching.

Jeff Doyle’s OSPF and IS-IS: Choosing an IGP for Large-Scale Networks is yet another

book specifically devoted to these two routing protocols, and—as can be expected—it is

a great book to read.

IS-IS and OSPF: A Comparative Anatomy : A presentation available online by Dave

Katz under this title is a great introduction into both protocols and a very nice compari-

son of their common and different features.

Another in-depth comparison of OSPF and IS-IS can be found in an Internet draft avail-

able online with the filename draft-bhatia-manral-diff-isis-ospf-01.txt .

ptg13046388

This page intentionally left blank

ptg13046388

Blueprint topics covered in this chapter:

This chapter covers the following subtopics from the

Cisco CCIE Routing and Switching written exam

blueprint. Refer to the full blueprint in Table I-1 in the

Introduction for more details on the topics covered in

each chapter and their context within the blueprint.

■ Manual Summarization and Autosummarization

■ Route Redistribution

■ Default Routing

■ Performance Routing

■ Troubleshooting Complex Layer 3 Problems

ptg13046388

This chapter covers several topics related to the use of multiple internal gateway protocol

(IGP) routing protocols. IGPs can use default routes to pull packets toward a small set of

routers, with those routers having learned routes from some external source. IGPs can use

route summarization with a single routing protocol, but it is often used at redistribution

points between IGPs as well. Route redistribution by definition involves moving routes

from one routing source to another. This chapter takes a look at each topic.

New to the qualification exam blueprint are a number of troubleshooting topics. One of

them, troubleshooting complex Layer 3 problems, is covered in this chapter. The goal is

to provide you with a process and tools to troubleshoot these types of problems.

For perspective, note that this chapter includes coverage of Routing Information Protocol

version 2 (RIPv2) redistribution topics. Even though RIPv2 has been removed from the

CCIE Routing and Switching qualifying exam blueprint, you might still see exam ques-

tions on redistribution involving RIPv2. Therefore, this chapter includes coverage of that

topic.

“Do I Know This Already?” Quiz

Table 11-1 outlines the major headings in this chapter and the corresponding “Do I Know

This Already?” quiz questions.

Table 11-1 “Do I Know This Already?” Foundation Topics Section-to-Question

Mapping

Foundation Topics Section Questions Covered in This Section Score

Route Maps, Prefix Lists, and

Administrative Distance

1–2

Route Redistribution 3–6

Route Summarization 7

Default Routes 8

Troubleshooting Layer 3 Problems 9–10

Performance Routing 11–12

Total Score

CHAPTER 11

IGP Route Redistribution, Route

Summarization, Default Routing, and

Troubleshooting

ptg13046388

634 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

To best use this pre-chapter assessment, remember to score yourself strictly. You can find

the answers in Appendix A , “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. A route map has several clauses. A route map’s first clause has a permit action con-

figured. The match command for this clause refers to an ACL that matches route

10.1.1.0/24 with a permit action, and matches route 10.1.2.0/24 with a deny action. If

this route map is used for route redistribution, which of the following are true?

a. The route map will attempt to redistribute 10.1.1.0/24.

b. The question does not supply enough information to determine whether

10.1.1.0/24 is redistributed.

c. The route map will not attempt to redistribute 10.1.2.0/24.

d. The question does not supply enough information to determine whether

10.1.2.0/24 is redistributed.

2. Which of the following routes would be matched by this prefix list command: ip

prefix-list fred permit 10.128.0.0/9 ge 20 ?

a. 10.1.1.0 255.255.255.0

b. 10.127.1.0 255.255.255.0

c. 10.200.200.192 255.255.255.252

d. 10.128.0.0 255.255.240.0

e. None of these answers is correct.

3. A router is using the following configuration to redistribute routes. This router has

several working interfaces with IP addresses in network 10.0.0.0, and has learned

some network 10 routes with EIGRP and some with OSPF. Which of the following is

true about the redistribution configuration?

router eigrp 1

network 10.0.0.0

redistribute ospf 2

router ospf 2

network 10.0.0.0 0.255.255.255 area 3

redistribute eigrp 1 subnets

R1# show ip route 10.0.0.0

Routing entry for 10.0.0.0/24, 5 known subnets

Attached (2 connections)

Redistributing via eigrp 1

O E1 10.6.11.0 [110/84] via 10.1.6.6, 00:21:52, Serial0/0/0.6

O E2 10.6.12.0 [110/20] via 10.1.6.6, 00:21:52, Serial0/0/0.6

C 10.1.6.0 is directly connected, Serial0/0/0.6

O IA 10.1.2.0 [110/65] via 10.1.1.5, 00:21:52, Serial0/0/0.5

C 10.1.1.0 is directly connected, Serial0/0/0.5

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 635

a. EIGRP will not advertise any additional routes because of redistribution.

b. OSPF will not advertise any additional routes because of redistribution.

c. Routes redistributed into OSPF will be advertised as E1 routes.

d. The redistribute ospf 2 command would be rejected because of missing

parameters.

4. Examine the following router configuration and excerpt from its IP routing table.

Which routes could be redistributed into OSPF?

router eigrp 1

network 12.0.0.0

router ospf 2

redistribute eigrp 1 subnets

network 13.0.0.0 0.255.255.255 area 3

An excerpt from the routing table is shown next:

C 12.1.6.0 is directly connected, Serial0/0/0.6

D 12.0.0.0/8 [90/2172416] via 13.1.1.1, 00:01:30, Serial0/0/0.5

C 13.1.1.0 is directly connected, Serial0/0/0.5

a. 1 2 . 1 . 6 . 0

b. 12.0.0.0

c. 13.1.1.0

d. None of these answers is correct.

5. Two corporations merged. The network engineers decided to redistribute between

one company’s EIGRP network and the other company’s OSPF network, using two

mutually redistributing routers (R1 and R2) for redundancy. Assume that as many

defaults as is possible are used for the redistribution configuration. Assume that

one of the subnets in the OSPF domain is 10.1.1.0/24. Which of the following is true

about a possible suboptimal route to 10.1.1.0/24 on R1—a route that sends packets

through the EIGRP domain, and through R2 into the OSPF domain?

a. The suboptimal routes will occur unless the configuration filters routes at R1.

b. R1’s administrative distance must be manipulated, such that OSPF routes have an

administrative distance less than EIGRP’s default of 90.

c. EIGRP prevents the suboptimal routes by default.

d. Using route tags is the only way to prevent the suboptimal routes.

ptg13046388

636 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

6. Which of the following statements is true about the type of routes created when

redistributing routes?

a. Routes redistributed into OSPF default to be external type 2.

b. Routes redistributed into EIGRP default to external, but can be set to internal

with a route map.

c. Routes redistributed into RIP are external by default.

d. Routes redistributed into OSPF by a router in an NSSA area default to be exter-

nal type 1.

7. Which of the following is not true about route summarization?

a. The advertised summary is assigned the same metric as the lowest-metric com-

ponent subnet.

b. The router does not advertise the summary when its routing table does not have

any of the component subnets.

c. The router does not advertise the component subnets.

d. Summarization, when used with redistribution, prevents all cases of suboptimal

routes.

8. Which of the following is/are true regarding the default-information originate router

subcommand?

a. It is not supported by EIGRP.

b. It causes OSPF to advertise a default route, but only if a static route to 0.0.0.0/0

is in that router’s routing table.

c. The always keyword in the default-information originate command, when used

for OSPF, means that OSPF will originate a default route even if no default route

exists in its own IP routing table.

d. None of the other answers is correct.

9. An EIGRP router is showing intermittent reachability to 172.30.8.32/27. Which

command(s) reveals the source by which this prefix is being advertised to the local

router?

a. show ip protocols

b. show ip route eigrp

c. show ip eigrp neighbor

d. show ip eigrp topology 172.30.8.32

e. show ip route 172.30.8.32

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 637

10. You suspect that a routing loop exists in your network because a subnet is intermit-

tently reachable. What is the most specific way to determine that a routing loop is

the cause?

a. ping

b. traceroute

c. debug ip packet detail

d. debug ip routing

e. show ip protocols

11. What routing optimization feature exists to change existing routing parameters of an

IGP such that it will add new prefixes and manipulate overall data forwarding at the

network’s edge?

a. Overlay transport virtualization

b. OSPFv3

c. Enhanced traffic selection

d. Performance Routing (PfR)

12. What solution is used to ensure that rogue devices cannot be used to poison the

manipulation of route optimization through adding dynamic static routes to the rout-

ing information base of a given border router?

a. MD5

b. Key chains

c. Clear text password

d. S H A 1

ptg13046388

638 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Foundation Topics

Route Maps, Prefix Lists, and Administrative Distance

Route maps, IP prefix lists, and administrative distance (AD) must be well understood

to do well with route redistribution topics on the CCIE Routing and Switching written

exam. This section focuses on the tools themselves, followed by coverage of route redis-

tribution.

Configuring Route Maps with the route-map Command

Route maps provide programming logic similar to the If/Then/Else logic seen in other

programming languages. A single route map has one or more route-map commands in it,

and routers process route-map commands in sequential order based on sequence num-

bers. Each route-map command has underlying matching parameters, configured with the

aptly named match command. (To match all packets, the route-map clause simply omits

the match command.) Each route-map command also has one or more optional set com-

mands that you can use to manipulate information—for example, to set the metric for

some redistributed routes. The general rules for route maps are as follows:

■ Each route-map command must have an explicitly configured name, with all com-

mands that use the same name being part of the same route map.

■ Each route-map command has an action ( permit or deny ).

■ Each route-map command in the same route map has a unique sequence number,

allowing deletion and insertion of single route-map commands.

■ When a route map is used for redistribution, the route map processes routes taken

from the then-current routing table.

■ The route map is processed sequentially based on the sequence numbers.

■ After a particular route is matched by the route map, it is not processed beyond that

matching route-map command (specific to route redistribution).

■ When a route is matched in a route-map statement, if the route-map command has a

permit parameter, the route is redistributed (specific to route redistribution).

■ When a route is matched in a route-map statement, if the route-map statement has a

deny parameter, the route is not redistributed (specific to route redistribution).

Route maps can be confusing at times, especially when using the deny option on the

route-map command. To help make sure that the logic is clear before getting into redis-

tribution, Figure 11-1 shows a logic diagram for an example route map. (This example is

contrived to demonstrate some nuances of route map logic; a better, more efficient route

map could be created to achieve the same results.) In the figure, R1 has eight loopback

interfaces configured to be in class A networks 32 through 39. Figure 11-1 shows how the

contrived route-map picky would process the routes.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 639

34, 35, 36, 38

Not Matched

End of List: implied deny all

Null

route-map picky deny 40

match ip address 33

33, 34, 35, 36, 38

Not Matched

route-map picky deny 33

match ip address d-38-p39

33, 34, 35, 36, 38, 39

Not Matched

route-map picky permit 25

match ip address d-36-p-37

33, 34, 35, 36, 37, 38, 39

Not Matched

Matched

Permit route-map picky permit 10

match ip address 32

32, 33, 34, 35, 36, 37, 38, 39

33, 34, 35, 36, 38, 39

32, 37

33, 39

32, 37

39C32, 37A

null

32, 37

nullC32A

AThe set of routes to redistribute

BRoutes for which no decision

has been made yet

CThe set of routes that are not

redistributed

Matched

Permit

Deny

Matched

Deny

ACL 32:

Permits Network 32

Default Deny Any at End

ACL 33:

Permits Network 33

Default Deny Any at End

ACL d-36-p-37:

Denies Network 36

Permits Network 37

Default Deny Any at End

ACL d-38-p-39:

Denies Network 38

Permits Network 39

Default Deny Any at End

Figure 11-1 Route Map Logic Example

First, a few clarifications about the meaning of Figure 11-1 are in order. The top of the

figure begins with the set of connected networks (32 through 39), labeled with a “B,”

which is the set of routes still being considered for redistribution. Moving down the fig-

ure, four separate route-map commands sit inside this single route map. Each route-map

clause (the clause includes the underlying match and set commands) in turn moves routes

from the list of possible routes (“B”) to either the list of routes to redistribute (“A”) or the

list to not redistribute (“C”). By the bottom of the figure, all routes will be noted as either

to be redistributed or not to be redistributed.

The route map chooses to redistribute a route only if the route-map command has a

permit option; the only time a route-map clause chooses to not redistribute a route is

when the clause has a deny option. Ignoring the matching logic for a moment, the first two

route-map commands (sequence numbers 10 and 25) use the permit option. As a result of

those clauses, routes are either added to the list of routes to redistribute (“A”) or left in the

list of candidate routes (“B”). The third and fourth clauses (sequence numbers 33 and 40)

use the deny option, so those clauses cause routes to be either added to the list of routes

to not redistribute (“C”) or left in the list of candidate routes (“B”). In effect, after a

ptg13046388

640 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

route-map clause has matched a route, that route is flagged either as to be redistributed or

as not to be redistributed, and the route is no longer processed by the route map.

One point that can sometimes be confused is that if a route is denied by an access con-

trol list (ACL) used by a match command, it does not mean that the route is prevented

from being redistributed. For example, the match ip address 32 command in clause 10

refers to ACL 32, which has one explicit access control entry (ACE) that matches net-

work 32, with a permit action. Of course, ACL 32 has an implied deny all at the end, so

ACL 32 permits network 32, and denies 33 through 39. However, denying networks 33

through 39 in the ACL does not mean that those routes are not redistributed—it simply

means that those routes do not match route-map clause 10, so those routes are eligible

for consideration by a later route-map clause.

The following list summarizes the key points about route map logic when used for redis-

tribution:

■ route-map commands with the permit option either cause a route to be redistrib-

uted or leave the route in the list of routes to be examined by the next route-map

clause.

■ route-map commands with the deny option either filter the route or leave the route

in the list of routes to be examined by the next route-map clause.

■ If a clause’s match commands use an ACL, an ACL match with the deny action does

not cause the route to be filtered. Instead, it just means that route does not match

that particular route-map clause.

■ The route-map command includes an implied deny all clause at the end; to configure

a permit all, use the route-map command, with a permit action, but without a match

command.

Route Map match Commands for Route Redistribution

Route maps use the match command to define the fields and values used for matching

the routes being processed. If more than one match command is configured in a single

route-map clause, a route is matched only if all the match commands’ parameters match

the route. The logic in each match command itself is relatively straightforward. Table 11-2

lists the match command options when used for IGP route redistribution.

Table 11-2 match Command Options for IGP Redistribution

match Command Description

match interface interface-type interface-

number [ ... interface-type interface-

number ]

Looks at outgoing interface of routes

* match ip address {[ access-list-number |

access-list-name ] | prefix-list prefix-list-

name }

Examines route prefix and prefix length

Key

Topic

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 641

match Command Description

* match ip next-hop { access-list-number |

access-list-name }

Examines route’s next-hop address

* match ip route-source { access-list-

number | access-list-name }

Matches advertising router’s IP address

mat ch metric metric-value [+ – deviation ] Matches route’s metric exactly, or optionally

a range of metrics (plus/minus the configured

deviation)

match route-type { internal | external

[ type-1 | type-2 ] | level-1 | level-2 }

Matches route type

match tag tag-value [ ...tag-value ] Tag must have been set earlier

*Can reference multiple numbered and named ACLs on a single command.

Route Map set Commands for Route Redistribution

When used for redistribution, route maps have an implied action—either to allow the

route to be redistributed or to filter the route so that it is not redistributed. As described

earlier in this chapter, that choice is implied by the permit or deny option in the route-

map command. Route maps can also change information about the redistributed routes

by using the set command. Table 11-3 lists the set command options when used for IGP

route redistribution.

Table 11-3 set Command Options for IGP Redistribution

set Command Description

set level { level-1 | level-2 | level-1-2 |

stub-area | backbone }

Defines database(s) into which the route is

redistributed

set metric metric-value Sets the route’s metric for OSPF, RIP, and IS-IS

set metric bandwidth delay reliability

loading mtu

Sets the IGRP/EIGRP route’s metric values

set metric-type { internal | external |

type-1 | type-2 }

Sets the type of route for IS-IS and OSPF

set tag tag-value Sets the unitless tag value in the route

IP Prefix Lists

IP prefix lists provide mechanisms to match two components of an IP route:

■ The route prefix (the subnet number)

■ The prefix length (the subnet mask)

ptg13046388

642 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The redistribute command cannot directly reference a prefix list, but a route map can

refer to a prefix list by using the match command.

A prefix list itself has similar characteristics to a route map. The list consists of one or

more statements with the same text name. Each statement has a sequence number to

allow deletion of individual commands, and insertion of commands into a particular

sequence position. Each command has a permit or deny action—but because it is used

only for matching packets, the permit or deny keyword just implies whether a route is

matched ( permit ) or not ( deny ). The generic command syntax is as follows:

ip prefix-list list-name [ seq seq-value ] { deny network / length | permit

network / length }[ ge ge-value ] [ le le-value ]

The sometimes tricky and interesting part of working with prefix lists is that the mean-

ing of the network/length , ge-value , and le-value parameters changes depending on

the syntax. The network / length parameters define the values to use to match the route

prefix. For example, a network / length of 10.0.0.0/8 means “any route that begins with a

10 in the first octet and has a /8 mask.” The ge and le options are used for comparison

to the prefix length—in other words, to the number of binary 1s in the subnet mask. For

example, ge 20 le 22 matches only routes whose masks are /20, /21, or /22. So, prefix list

logic can be summarized into a two-step comparison process for each route:

1. The route’s prefix must be within the range of addresses implied by the prefix-list

command’s network / length parameters.

2. The route’s prefix length must match the range of prefixes implied by the prefix-

list command.

The potentially tricky part of the logic relates to knowing the range of prefix lengths

checked by this logic. The range is defined by the ge-value and le-value parameters,

which stand for greater-than-or-equal-to and less-than-or-equal-to . Table 11-4 formal-

izes the logic, including the default values for ge-value and le-value . In the table, note

that conf-length refers to the prefix length configured in the network / prefix (required)

parameter, and route-length refers to the prefix length of a route being examined by the

prefix list.

Table 11-4 LE and GE Parameters on IP Prefix List, and the Implied Range of Prefix

Lengths

Prefix List Parameters Range of Prefix Lengths

Neither conf-length = route-length

Only le conf-length <= route-length <= le-value

Only ge ge-value <= route-length <= 32

Both ge and le ge-value <= route-length <= le-value

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 643

Several examples can really help nail down prefix list logic. The following routes will be

examined by a variety of prefix lists, with the routes numbered for easier reference:

1. 10.0.0.0/8

2. 10.128.0.0/9

3. 10.1.1.0/24

4. 10.1.2.0/24

5. 10.128.10.4/30

6. 10.128.10.8/30

Next, Table 11-5 shows the results of seven different one-line prefix lists applied to these

six example routes. The table lists the matching parameters in the prefix-list commands,

omitting the first part of the commands. The table explains which of the six routes would

match the listed prefix list and why.

Table 11-5 Example Prefix Lists Applied to the List of Routes

prefix-list Command

Parameters

Routes

Matched

Results

10.0.0.0/8 1 Without ge or le configured, both the prefix

(10.0.0.0) and length (8) must be an exact match.

10.128.0.0/9 2 Without ge or le configured, the prefix

(10.128.0.0) and length (9) must be an exact

match; only the second route in the list is

matched by this prefix list.

10.0.0.0/8 ge 9 2–6 The 10.0.0.0/8 means “all routes whose first octet

is 10,” effectively representing an address range.

The prefix length must be between 9 and 32,

inclusive.

10.0.0.0/8 ge 24 le 24 3, 4 The 10.0.0.0/8 means “all routes whose first octet

is 10,” and the prefix range is 24 to 24—meaning

only routes with prefix length 24.

10.0.0.0/8 le 28 1–4 The prefix length needs to be between 8 and 28,

inclusive.

0.0.0.0/0 None 0.0.0.0/0 means “match all prefixes, with prefix

length of exactly 0.” So, it would match all

routes’ prefixes but none of their prefix lengths.

Only a default route would match this prefix list.

0.0.0.0/0 le 32 All The range implied by 0.0.0.0/0 is all IPv4

addresses. The le 32 then implies any prefix

length between 0 and 32, inclusive. This is the

syntax for “match all” prefix list logic.

ptg13046388

644 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Administrative Distance

A single router can learn routes using multiple IP routing protocols, as well as through

connected and static routes. When a router learns a particular route from multiple sources,

the router cannot use the metrics to determine the best route, because the metrics are

based on different units. So, the router uses each route’s administrative distance (AD) to

determine which is best, with the lower number being better. Table 11-6 lists the default

AD values for the various routing sources.

Table 11-6 Administrative Distances

Route Type Administrative Distance

Connected 0

Static 1

EIGRP summary route 5

EBGP 20

EIGRP (internal) 90

IGRP 100

OSPF 110

IS-IS 115

RIP 120

EIGRP (external) 170

iBGP 200

Unreachable 255

The defaults can be changed by using the distance command. The command differs

among all three IGPs covered in this book. The generic versions of the distance router

subcommand for RIP, Enhanced Interior Gateway Routing Protocol (EIGRP), and Open

Shortest Path First (OSPF), respectively, are as follows:

distance distance

distance eigrp internal-distance external-distance

distance ospf {[ intra-area dist1 ] [ inter-area dist2 ] [ external dist3 ]}

As you can see, EIGRP and OSPF can set a different AD depending on the type of route

as well, whereas RIP cannot. You can also use the distance command to set a router’s

view of the AD per route, as is covered later in this chapter.

Key

Topic

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 645

Route Redistribution

Although using a single routing protocol throughout an enterprise might be preferred,

many enterprises use multiple routing protocols because of business mergers and acqui-

sitions, organizational history, or in some cases for technical reasons. Route redistribu-

tion allows one or more routers to take routes learned through one routing protocol and

advertise those routes through another routing protocol so that all parts of the internet-

work can be reached.

To perform redistribution, one or more routers run both routing protocols, with each

routing protocol placing routes into that router’s routing table. Then, each routing pro-

tocol can take all or some of the other routing protocol’s routes from the routing table

and advertise those routes. This section begins by looking at the mechanics of how to

perform simple redistribution on a single router, and ends with a discussion of tools and

issues that matter most when redistributing on multiple routers.

Mechanics of the redistribute Command

The redistribute router subcommand tells one routing protocol to take routes from

another routing protocol. This command can simply redistribute all routes or, by using

matching logic, redistribute only a subset of the routes. The redistribute command also

supports actions for setting some parameters about the redistributed routes—for exam-

ple, the metric.

The full syntax of the redistribute command is as follows:

redistribute protocol [ process-id ] [ level-1 | level-1-2 | level-2 ] [ as-number ]

[ metric metric-value ] [ metric-type type-value ] [ match { internal | external 1 |

external 2 }] [ tag tag-value ] [ route-map map-tag ] [ subnets ]

The redistribute command identifies the routing source from which routes are taken, and

the router command identifies the routing process into which the routes are advertised.

For example, the redistribute eigrp 1 command tells the router to take routes from

EIGRP process 1; if that command were under router rip , the routes would be redistrib-

uted into RIP, enabling other RIP routers in the network to see some or all routes coming

from EIGRP AS 1.

The redistribute command has a lot of other parameters as well, most of which will

be described in upcoming examples. The first few examples use the network shown in

Figure 11-2 . In this network, each IGP uses a different class A network just to make the

results of redistribution more obvious. Also note that the numbering convention is such

that each of R1’s connected WAN subnets has 1 as the third octet, and each LAN subnet

off R3, R4, and R5 has 2 as the third octet.

ptg13046388

646 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

13.1.2.3/24

13.1.1.0/24 15.1.1.0/24

Fa0/0

15.1.2.5/24

Fa0/0

RID

1.1.1.1

RID 5.5.5.5

0/0/0.1 .5

0/0.1

.1 .1

14.1.2.4/24 14.1.1.0/24

Fa0/0 .4

0/0/0.1

RIP

Network 13.0.0.0

OSPF 1 (Two Areas, with R5 as ABR)

Network 15.0.0.0

EIGRP 1

Network 14.0.0.0

R3 R5

Figure 11-2 Sample Network for Default Route Examples

Redistribution Using Default Settings

The first example configuration meets the following design goals:

■ R1 redistributes between each pair of IGPs—RIP, EIGRP, and OSPF.

■ Default metrics are used whenever possible; when required, the metrics are config-

ured on the redistribute command.

■ Redistribution into OSPF uses the nondefault subnets parameter, which causes sub-

nets to be advertised into OSPF.

■ All other settings use default values.

Example 11-1 shows R1’s configuration for each routing protocol, along with show com-

mands from all four routers to highlight the results of the redistribution.

Example 11-1 Route Redistribution with Minimal Options

! EIGRP redistributes from OSPF (process ID 1) and RIP. EIGRP must

! set the metric, as it has no default values. It also uses the

! no auto-summary command so that subnets will be redistributed into

! EIGRP.

router eigrp 1

redistribute ospf 1 metric 1544 5 255 1 1500

redistribute rip metric 1544 5 255 1

network 14.0.0.0

no auto-summary

! OSPF redistributes from EIGRP (ASN 1) and RIP. OSPF defaults the

! metric to 20 for redistributed IGP routes. It must also use the

! subnets option in order to redistribute subnets.

router ospf 1

router-id 1.1.1.1

redistribute eigrp 1 subnets

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 647

redistribute rip subnets

network 15.0.0.0 0.255.255.255 area 0

! RIP redistributes from OSPF (process ID 1) and EIGRP (ASN 1). RIP

! must set the metric, as it has no default values. It also uses the

! no auto-summary command so that subnets will be redistributed into

! EIGRP.

router rip

version 2

redistribute eigrp 1 metric 2

redistribute ospf 1 metric 3

network 13.0.0.0

no auto-summary

! R1 has a connected route (x.x.1.0) in networks 13, 14, and 15, as well as

! an IGP-learned route (x.x.2.0).

R1# show ip route

! lines omitted for brevity

10.0.0.0/24 is subnetted, 1 subnets

C 10.1.1.0 is directly connected, FastEthernet0/0

13.0.0.0/24 is subnetted, 2 subnets

C 13.1.1.0 is directly connected, Serial0/0/0.3

R 13.1.2.0 [120/1] via 13.1.1.3, 00:00:07, Serial0/0/0.3

14.0.0.0/24 is subnetted, 2 subnets

D 14.1.2.0 [90/2172416] via 14.1.1.4, 00:58:20, Serial0/0/0.4

C 14.1.1.0 is directly connected, Serial0/0/0.4

15.0.0.0/24 is subnetted, 2 subnets

O IA 15.1.2.0 [110/65] via 15.1.1.5, 00:04:25, Serial0/0/0.5

C 15.1.1.0 is directly connected, Serial0/0/0.5

! R3 learned two routes each from nets 14 and 15.

! Compare the metrics set on R1's RIP redistribute command to the metrics below.

R3# show ip route rip

14.0.0.0/24 is subnetted, 2 subnets

R 14.1.2.0 [120/2] via 13.1.1.1, 00:00:19, Serial0/0/0.1

R 14.1.1.0 [120/2] via 13.1.1.1, 00:00:19, Serial0/0/0.1

15.0.0.0/24 is subnetted, 2 subnets

R 15.1.2.0 [120/3] via 13.1.1.1, 00:00:19, Serial0/0/0.1

R 15.1.1.0 [120/3] via 13.1.1.1, 00:00:19, Serial0/0/0.1

! R4 learned two routes each from nets 13 and 15.

! EIGRP injected the routes as external (EX), which are considered AD 170.

R4# show ip route eigrp

13.0.0.0/24 is subnetted, 2 subnets

D EX 13.1.1.0 [170/2171136] via 14.1.1.1, 00:09:57, Serial0/0/0.1

D EX 13.1.2.0 [170/2171136] via 14.1.1.1, 00:09:57, Serial0/0/0.1

15.0.0.0/24 is subnetted, 2 subnets

D EX 15.1.2.0 [170/2171136] via 14.1.1.1, 01:00:27, Serial0/0/0.1

D EX 15.1.1.0 [170/2171136] via 14.1.1.1, 01:00:27, Serial0/0/0.1

! R5 learned two routes each from nets 13 and 14.

ptg13046388

648 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

! OSPF by default injected the routes as external type 2, cost 20.

R5# show ip route ospf

13.0.0.0/24 is subnetted, 2 subnets

O E2 13.1.1.0 [110/20] via 15.1.1.1, 00:36:12, Serial0/0.1

O E2 13.1.2.0 [110/20] via 15.1.1.1, 00:36:12, Serial0/0.1

14.0.0.0/24 is subnetted, 2 subnets

O E2 14.1.2.0 [110/20] via 15.1.1.1, 00:29:56, Serial0/0.1

O E2 14.1.1.0 [110/20] via 15.1.1.1, 00:36:12, Serial0/0.1

! As a backbone router, OSPF on R1 created type 5 LSAs for the four E2 subnets.

! If R1 had been inside an NSSA stub area, it would have created type 7 LSAs.

R5# show ip ospf data | begin Type-5

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

13.1.1.0 1.1.1.1 1444 0x80000002 0x000785 0

13.1.2.0 1.1.1.1 1444 0x80000002 0x00FB8F 0

14.1.1.0 1.1.1.1 1444 0x80000002 0x00F991 0

14.1.2.0 1.1.1.1 1444 0x80000002 0x00EE9B 0

Metrics must be set through configuration when redistributing into RIP and EIGRP,

whereas OSPF uses default values. In the example, the two redistribute commands under

router rip used hop counts of 2 and 3 just so that the metrics could be easily seen in the

show ip route command output on R3. The EIGRP metric in the redistribute command

must include all five metric components, even if the last three are ignored by EIGRP’s

metric calculation (as they are by default). The redistribute rip metric 1544 5 255 1

1500 command lists EIGRP metric components of bandwidth, delay, reliability, load, and

MTU, in order. OSPF defaults to cost 20 when redistributing from an IGP, and 1 when

redistributing from BGP.

The redistribute command redistributes only routes in that router’s current IP routing

table. When redistributing from a given routing protocol, the redistribute command

takes routes listed in the IP routing table as being learned from that routing protocol.

Interestingly, the redistribute command can also pick up connected routes. For example,

R1 has an OSPF route to 15.1.2.0/24, and a connected route to 15.1.1.0/24. However, R3

(RIP) and R4 (EIGRP) redistribute both of these routes—the OSPF-learned route and one

connected route—as a result of their respective redistribute ospf commands. As it turns

out, the redistribute command causes the router to use the following logic to choose

which routes to redistribute from a particular IGP protocol:

1. Take all routes in my routing table that were learned by the routing protocol from

which routes are being redistributed.

2. Take all connected subnets matched by that routing protocol’s network commands.

Example 11-1 shows several instances of exactly how this two-part logic works. For

example, R3 (RIP) learns about connected subnet 14.1.1.0/24, because RIP redistributes

from EIGRP, and R1’s EIGRP network 14.0.0.0 command matches that subnet.

Key

Topic

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 649

The redistribute command includes a subnets option, but only OSPF needs to use it. By

default, when redistributing into OSPF, OSPF redistributes only routes for classful net-

works, ignoring subnets. By including the subnets option, OSPF redistributes subnets as

well. The other IGPs redistribute subnets automatically; however, if at a network bound-

ary, the RIP or EIGRP auto-summary setting would still cause summarization to use the

classful network. In Example 11-1 , if either RIP or EIGRP had used auto-summary , each

redistributed network would show just the classful networks. For example, if RIP had

configured auto-summary in Example 11-1 , R3 would have a route to networks 14.0.0.0/8

and 15.0.0.0/8, but no routes to subnets inside those class A networks.

Setting Metrics, Metric Types, and Tags

Cisco IOS provides three mechanisms for setting the metrics of redistributed routes, as

follows:

1. Call a route map from the redistribute command, with the route map using the set

metric command. This method allows different metrics for different routes.

2. Use the metric option on the redistribute command. This sets the same metric for

all routes redistributed by that redistribute command.

3. Use the default-metric command under the router command. This command sets the

metric for all redistributed routes whose metric was not set by either of the other

two methods.

The list implies the order of precedence if more than one method defines a metric. For

example, if a route’s metric is set by all three methods, the route map’s metric is used. If

the metric is set on the redistribute command and there is a default-metric command as

well, the setting on the redistribute command takes precedence.

The redistribute command also allows a setting for the metric-type option, which really

refers to the route type. For example, routes redistributed into OSPF must be OSPF

external routes, but they can be either external type 1 (E1) or type 2 (E2) routes. Table

11-7 summarizes the defaults for metrics and metric types.

Table 11-7 Default Metrics and Route Metric Types in IGP Route Redistribution

IGP into Which Routes Are

Redistributed

Default

Metric

Default (and Possible) Metric Types

RIP None RIP has no concept of external routes

EIGRP None External

OSPF 20/1* E2 (E1 or E2)

IS-IS 0 L1 (L1, L2, L1/L2, or external)

* OSPF uses cost 20 when redistributing from an IGP, and cost 1 when redistributing from BGP.

Key

Topic

Key

Topic

ptg13046388

650 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Redistributing a Subset of Routes Using a Route Map

Route maps can be referenced by any redistribute command. The route map can actually

let all the routes through, setting different route attributes (for example, metrics) for dif-

ferent routes. Or it might match some routes with a deny clause, which prevents the route

from being redistributed. (Refer to Figure 11-1 for a review of route map logic.)

Figure 11-3 and Example 11-2 show an example of mutual redistribution between EIGRP

and OSPF, with some routes being either filtered or changed using route maps.

Subnet

Tagged 5 15.1.2.0/24

14.1.1.4/24 15.1.1.5

15.1.1.0/24

15.1.6.0/24

Fa0/0

15.1.2.5/24

Fa0/0

RID 1.1.1.1

RID 6.6.6.6

14.0.0.0 on the Left (EIGRP)

15.0.0.0 on the Right (OSPF)

From Other EIGRP Routers:

14.2.16.0/23

14.2.18.0/23

14.2.20.0/24

14.2.21.0/24

14.2.22.4/30

14.2.22.8/30

14.3.8.0/24 Tagged 99

14.3.9.0/24 Tagged 99

Externals:

15.6.11.0/24 (E1)

15.6.12.0/24 (E2)

Tagged 6

Figure 11-3 OSPF and EIGRP Mutual Redistribution Using Route Maps

The following list details the requirements for redistribution from OSPF into EIGRP.

These requirements use R1’s perspective, because it is the router doing the redistribution.

■ Routes with next-hop address 15.1.1.5 (R5) should be redistributed, with route tag 5.

■ E1 routes sourced by R6 (RID 6.6.6.6) should be redistributed, and assigned a route

tag of 6.

■ No other routes should be redistributed.

The requirements for redistributing routes from EIGRP into OSPF are as follows, again

from R1’s perspective:

■ Routes beginning with 14.2, and with masks /23 and /24, should be redistributed,

with metric set to 300.

■ Other routes beginning with 14.2 should not be redistributed.

■ Routes beginning with 14.3 should be redistributed, with route tag 99.

■ No other routes should be redistributed.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 651

Most of the explanation of the configuration is provided in the comments in Example

11-2 , with a few additional comments following the example.

Example 11-2 Route Redistribution Using Route Maps

! No metrics are set on the redistribute commands; either the default metric

! is used, or the route maps set the metrics. The default-metric command

! sets the unused EIGRP metric parameters to "1" because something must be

! configured, but the values are unimportant.

router eigrp 1

redistribute ospf 1 route-map ospf-into-eigrp

network 14.0.0.0

default-metric 1544 5 1 1 1

no auto-summary

! While this configuration strives to use other options besides the options

! directly on the redistribute command, when used by OSPF, you must still

! include the subnets keyword for OSPF to learn subnets from other IGPs.

router ospf 1

router-id 1.1.1.1

redistribute eigrp 1 subnets route-map eigrp-into-ospf

network 15.0.0.0 0.255.255.255 area 0

! ACL A-14-3-x-x matches all addresses that begin 14.3. ACL A-15-1-1-5 matches

! exactly IP address 15.1.1.5. ACL A-6-6-6-6 matches exactly address 6.6.6.6.

ip access-list standard A-14-3-x-x

permit 14.3.0.0 0.0.255.255

ip access-list standard A-15-1-1-5

permit 15.1.1.5

ip access-list standard A-6-6-6-6

permit 6.6.6.6

! The prefix lists matches prefixes in the range 14.2.0.0 through 14.2.255.255,

! with prefix length 23 or 24.

ip prefix-list e-into-o seq 5 permit 14.2.0.0/16 ge 23 le 24

! route-map ospf-into-eigrp was called by the redistribute command under router

! eigrp , meaning that it controls redistribution from OSPF into EIGRP.

! Clause 10 matches OSPF routes whose next hop is 15.1.1.5, which is R5's serial

! IP address. R1's only route that meets this criteria is 15.1.2.0/24. This route

! will be redistributed because the route-map clause 10 has a permit action.

! The route tag is also set to 5.

route-map ospf-into-eigrp permit 10

match ip next-hop A-15-1-1-5

set tag 5

! Clause 15 matches OSPF routes whose LSAs are sourced by router with RID 6.6.6.6,

! namely R6, and also have metric type E1. R6 sources two external routes, but

! only 15.6.11.0/24 is E1. The route is tagged 6.

route-map ospf-into-eigrp permit 15

match ip route-source A-6-6-6-6

match route-type external type-1

ptg13046388

652 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

set tag 6

! route-map eigrp-into-ospf was called by the redistribute command under router

! ospf , meaning that it controls redistribution from EIGRP into OSPF.

! Clause 10 matches using a prefix list, which in turn matches prefixes that begin

! with 14.2, and which have either a /23 or /24 prefix length. By implication, it

! does not match prefix length /30. The metric is set to 300 for these routes.

route-map eigrp-into-ospf permit 10

match ip address prefix-list e-into-o

set metric 300

! Clause 18 matches routes that begin 14.3. They are tagged with a 99.

route-map eigrp-into-ospf permit 18

match ip address A-14-3-x-x

set tag 99

! Next, the example shows the routes that could be redistributed, and then

! shows the results of the redistribution, pointing out which routes were

! redistributed. First, the example shows, on R1, all routes that R1 could

! try to redistribute into EIGRP.

R1# show ip route 15.0.0.0

Routing entry for 15.0.0.0/24, 5 known subnets

Attached (2 connections)

Redistributing via eigrp 1

O E1 15.6.11.0 [110/84] via 15.1.6.6, 00:21:52, Serial0/0/0.6

O E2 15.6.12.0 [110/20] via 15.1.6.6, 00:21:52, Serial0/0/0.6

C 15.1.6.0 is directly connected, Serial0/0/0.6

O IA 15.1.2.0 [110/65] via 15.1.1.5, 00:21:52, Serial0/0/0.5

C 15.1.1.0 is directly connected, Serial0/0/0.5

! R4 sees only two of the five routes from 15.0.0.0, because only two matched

! either of

! the route-map clauses. The other three routes matched the default deny clause.

R4# show ip route 15.0.0.0

Routing entry for 15.0.0.0/24, 2 known subnets

Redistributing via eigrp 1

D EX 15.6.11.0 [170/2171136] via 14.1.1.1, 00:22:21, Serial0/0/0.1

D EX 15.1.2.0 [170/2171136] via 14.1.1.1, 00:22:21, Serial0/0/0.1

! Still on R4, the show ip eigrp topology command displays the tag. This command

! filters the output so that just one line of output lists the tag values.

R4# sho ip eigrp topo 15.1.2.0 255.255.255.0 | incl tag

Administrator tag is 5 (0x00000005)

R4# sho ip eigrp topo 15.6.11.0 255.255.255.0 | incl tag

Administrator tag is 6 (0x00000006)

! Next, the example shows the possible routes that could be redistributed from

! EIGRP into OSPF.

! The next command (R1) lists all routes that could be redistributed into OSPF.

R1# show ip route 14.0.0.0

Routing entry for 14.0.0.0/8, 10 known subnets

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 653

Attached (1 connections)

Variably subnetted with 3 masks

Redistributing via eigrp 1, ospf 1

D 14.3.9.0/24 [90/2297856] via 14.1.1.4, 00:34:48, Serial0/0/0.4

D 14.3.8.0/24 [90/2297856] via 14.1.1.4, 00:34:52, Serial0/0/0.4

D 14.1.2.0/24 [90/2172416] via 14.1.1.4, 00:39:27, Serial0/0/0.4

C 14.1.1.0/24 is directly connected, Serial0/0/0.4

D 14.2.22.8/30 [90/2297856] via 14.1.1.4, 00:35:49, Serial0/0/0.4

D 14.2.20.0/24 [90/2297856] via 14.1.1.4, 00:36:12, Serial0/0/0.4

D 14.2.21.0/24 [90/2297856] via 14.1.1.4, 00:36:08, Serial0/0/0.4

D 14.2.16.0/23 [90/2297856] via 14.1.1.4, 00:36:34, Serial0/0/0.4

D 14.2.22.4/30 [90/2297856] via 14.1.1.4, 00:35:53, Serial0/0/0.4

D 14.2.18.0/23 [90/2297856] via 14.1.1.4, 00:36:23, Serial0/0/0.4

! Next, on R5, note that the two /30 routes beginning with 14.2 were correctly

! prevented from getting into OSPF. It also filtered the redistribution of the

! two routes that begin with 14.1. As a result, R5 knows only 6 routes in

! network 14.0.0.0, whereas R1 had 10 subnets of that network it could have

! redistributed. Also below, note that the /23 and /24 routes inside 14.2 have

! metric 300.

R5# show ip route 14.0.0.0

Routing entry for 14.0.0.0/8, 6 known subnets

Variably subnetted with 2 masks

O E2 14.3.9.0/24 [110/20] via 15.1.1.1, 00:22:41, Serial0/0.1

O E2 14.3.8.0/24 [110/20] via 15.1.1.1, 00:22:41, Serial0/0.1

O E2 14.2.20.0/24 [110/300] via 15.1.1.1, 00:22:41, Serial0/0.1

O E2 14.2.21.0/24 [110/300] via 15.1.1.1, 00:22:41, Serial0/0.1

O E2 14.2.16.0/23 [110/300] via 15.1.1.1, 00:22:41, Serial0/0.1

O E2 14.2.18.0/23 [110/300] via 15.1.1.1, 00:22:41, Serial0/0.1

! The show ip ospf database command confirms that the route tag was set

! correctly.

R5# show ip ospf data external 14.3.8.0 | incl Tag

External Route Tag: 99

Note Route maps have an implied deny clause at the end of the route map. This implied

deny clause matches all packets. As a result, any routes not matched in the explicitly

configured route-map clauses match the implied deny clause, and are filtered. Both route

maps in the example used the implied deny clause to actually filter the routes.

ptg13046388

654 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Mutual Redistribution at Multiple Routers

When multiple routers redistribute between the same two routing protocol domains,

several potential problems can occur. One type of problem occurs on the redistributing

routers, because those routers will learn a route to most subnets through both routing

protocols. That router uses the AD to determine the best route when comparing the best

routes from each of the two routing protocols; this typically results in some routes using

suboptimal paths. For example, Figure 11-4 shows a sample network, with R3 choosing

its AD 110 OSPF route to 10.1.2.0/24 over the probably better AD 120 RIP route.

10.1.2.0/24

10.1.3.0/24

10.1.1.0/24

10.1.4.0/24

10.1.5.0/24

10.1.23.0/24

10.1.12.0/24

10.1.34.0/24

10.1.15.0/24

10.1.45.0/24

Fa0/0

S0/0/0.2

RID

4.4.4.4

S0/0/0.3

Possible routes to 10.1.2.0/24:

RIP 1 hop through R2, AD 120

OSPF cost 244 through R4, AD 110

S0/0/0.5

RIP – AD 120

OSPF Area 0 – AD 110

R1 Redistributes

RIP into OSPF

R1 Redistributes

RIP into OSPF

Figure 11-4 OSPF and RIP Redistribution

Note The OSPF configuration for this network matches only the interfaces implied by

the OSPF box in Figure 11-4. RIP does not have a wildcard-mask option in the network

command, so R1’s and R3’s network commands will match all of their interfaces, as all are

in network 10.0.0.0.

In Figure 11-4 , R3 learns of subnet 10.1.2.0/24 through RIP updates from R2. Also, R1

learns of the subnet with RIP and redistributes the route into OSPF, and then R3 learns of

a route to 10.1.2.0/24 through OSPF. R3 chooses the route with the lower administrative

distance; with all default settings, OSPF’s AD of 110 is better that RIP’s 120.

If both R1 and R3 mutually redistribute between RIP and OSPF, the suboptimal route

problem would occur on either R1 or R3 for each RIP subnet, all depending on timing.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 655

Example 11-3 shows the redistribution configuration, along with R3 having the subop-

timal route shown in Figure 11-4 . However, after R1’s fa0/0 interface flaps, R1 now has a

suboptimal route to 10.1.2.0/24, but R3 has an optimal route.

Example 11-3 Suboptimal Routing at Different Redistribution Points

! R1's related configuration follows:

router ospf 1

router-id 1.1.1.1

redistribute rip subnets

network 10.1.15.1 0.0.0.0 area 0

router rip

redistribute ospf 1

network 10.0.0.0

default-metric 1

! R3's related configuration follows:

router ospf 1

router-id 3.3.3.3

redistribute rip subnets

network 10.1.34.3 0.0.0.0 area 0

router rip

redistribute ospf 1

network 10.0.0.0

default-metric 1

! R3 begins with an AD 110 OSPF route, and not a RIP route, to 10.1.2.0/24.

R3# sh ip route | incl 10.1.2.0

O E2 10.1.2.0 [110/20] via 10.1.34.4, 00:02:01, Serial0/0/0.4

! R1 has a RIP route to 10.1.2.0/24, and redistributes it into OSPF, causing R3

! to learn an OSPF route to 10.1.2.0/24.

R1# sh ip route | incl 10.1.2.0

R 10.1.2.0 [120/1] via 10.1.12.2, 00:00:08, FastEthernet0/0

! Next, R1 loses its RIP route to 10.1.2.0/24, causing R3 to lose its OSPF route.

R1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)# int fa 0/0

R1(config-if)# shut

! R3 loses its OSPF route, but can then insert the RIP route into its table.

R3# sh ip route | incl 10.1.2.0

R 10.1.2.0 [120/1] via 10.1.23.2, 00:00:12, Serial0/0/0.2

! Not shown: R1 brings up its fa0/0 again

! However, R1 now has the suboptimal route to 10.1.2.0/24, through OSPF.

R1# sh ip route | incl 10.1.2.0

O E2 10.1.2.0 [110/20] via 10.1.15.5, 00:00:09, Serial0/0/0.5

ptg13046388

656 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The key concept behind this seemingly odd example is that a redistributing router pro-

cesses only the current contents of its IP routing table. When this network first came up,

R1 learned its RIP route to 10.1.2.0/24, and redistributed into OSPF, before R3 could do

the same. So, R3 was faced with the choice of putting the AD 110 (OSPF) or AD 120

(RIP) route into its routing table, and R3 chose the lower AD OSPF route. Because R3

never had the RIP route to 10.1.2.0/24 in its routing table, R3 could not redistribute that

RIP route into OSPF.

Later, when R1’s fa0/0 failed (as shown in Example 11-3 ), R3 had time to remove the

OSPF route and add the RIP route for 10.1.2.0/24 to its routing table—which then

allowed R3 to redistribute that RIP route into OSPF, causing R1 to have the suboptimal

route.

To solve this type of problem, the redistributing routers must have some awareness of

which routes came from the other routing domain. In particular, the lower-AD routing

protocol needs to decide which routes came from the higher-AD routing protocol, and

either use a different AD for those routes or filter the routes. The next few sections show

a few different methods of preventing this type of problem.

Preventing Suboptimal Routes by Setting the Administrative Distance

One simple and elegant solution to the problem of suboptimal routes on redistributing

routers is to flag the redistributed routes with a higher AD. A route’s AD is not advertised

by the routing protocol. However, a single router can be configured such that it assigns

different AD values to different routes, which then impacts that one router’s choice of

which routes end up in that router’s routing table. For example, back in Figure 11-4 and

Example 11-3 , R3 could have assigned the OSPF-learned route to 10.1.2.0/24, an AD

higher than 120, thereby preventing the original problem.

Figure 11-5 shows a more complete example, with a route from the RIP domain

(10.1.2.0/24) and another from the OSPF domain (10.1.4.0/24). Redistributing Router R3

will learn the two routes both from RIP and OSPF. When you configure R3’s logic to

treat OSPF internal routes with default AD 110, and OSPF external routes with AD 180

(or any other value larger than RIP’s default of 120), R3 will choose the optimal path for

both RIP and OSPF routes.

Example 11-4 shows how to configure both R1 and R3 to use a different AD for external

routes by using the distance ospf external 180 command, under the router ospf process.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 657

Example 11-4 Preventing Suboptimal Routes with the distance Router Subcommand

! Both R1's and R3's configurations look like they do in Example 11-3 's, but with

! the addition of the distance command.

router ospf 1

distance ospf external 180

! R3 has a more optimal RIP route to 10.1.2.0/24, as does R1.

R3# sh ip route | incl 10.1.2.0

R 10.1.2.0 [120/1] via 10.1.23.2, 00:00:19, Serial0/0/0.2

! R1 next...

R1# show ip route | incl 10.1.2.0 _

R 10.1.2.0 [120/1] via 10.1.12.2, 00:00:11, FastEthernet0/0

! R1 loses its next-hop interface for the RIP route, so now its OSPF route, with

! AD 180, is its only and best route to 10.1.2.0/24.

R1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)# int fa 0/0

R1(config-if)# shut

R1(config-if)# do sh ip route | incl 10.1.2.0

O E2 10.1.2.0 [180/20] via 10.1.15.5, 00:00:05, Serial0/0/0.5

10.1.4.0/2410.1.2.0/24

10.1.4.0/24

RIP

RIP – AD 120

OSPF:

Internal AD 110

External AD 180

10.1.2.0/24

RIP

10.1.2.0/24

RIP

10.1.2.0/24

OSPF E2

10.1.2.0/24

OSPF E2

10.1.4.0/24

OSPF Int.

10.1.4.0/24

RIP

10.1.4.0/24

OSPF Int.

Routing Info for 10.1.2.0/24 Routing Info for 10.1.4.0/24

• For 10.1.2.0/24: Pick AD 120 RIP

route over AD 180 OSPF route

• For 10.1.4.0/24: Pick AD 110

OSPF route over AD 120 RIP

route

Figure 11-5 Effect of Differing ADs for Internal and External Routes

ptg13046388

658 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

EIGRP supports the exact same concept by default, using AD 170 for external routes

and 90 for internal routes. In fact, if EIGRP were used instead of OSPF in this example,

neither R1 nor R3 would have experienced any of the suboptimal routing. You can reset

EIGRP’s distance for internal and external routes by using the distance eigrp router sub-

command. (At the time of this writing, neither the Intermediate System–to–Intermediate

System [IS-IS] nor RIP distance commands support setting external route ADs and inter-

nal route ADs to different values.)

In some cases, the requirements might not allow for setting all external routes’ ADs to

another value. For example, if R4 injected some legitimate external routes into OSPF, the

configuration in Example 11-4 would result in either R1 or R3 having a suboptimal route

to those external routes that pointed through the RIP domain. In those cases, the dis-

tance router subcommand can be used in a different way, influencing some of or all the

routes that come from a particular router. The syntax is as follows:

distance { distance-value ip-address { wildcard-mask } [ ip-standard-list ]

[ ip-extended-list ]

This command sets three key pieces of information: the AD to be set, the IP address of

the router advertising the routes, and optionally, an ACL with which to match routes.

With RIP, EIGRP, and IS-IS, this command identifies a neighboring router’s interface

address using the ip-address wildcard-mask parameters. With OSPF, those same param-

eters identify the RID of the router owning (creating) the link-state advertisement (LSA)

for the route. The optional ACL then identifies the subset of routes for which the AD will

be set. The logic boils down to something like this:

Set this AD value for all routes, learned from a router that is defined by the IP

address and wildcard mask, and for which the ACL permits the route.

Example 11-5 shows how the command could be used to solve the same suboptimal

route problem on R1 and R3, while not causing suboptimal routing for other external

routes. The design goals are summarized as follows:

■ Set a router’s local AD for its OSPF routes for subnets in the RIP domain to a value

of 179, thereby making the RIP routes to those subnets better than the OSPF routes

to those same subnets.

■ Do not set the AD for any other routes.

Example 11-5 Using the distance Command to Reset Particular Routes’ ADs

! R1 config. Note that the command refers to 3.3.3.3, which is R3's RID. Other

! commands not related to resetting the AD are omitted. Of particular importance,

! the distance command on R1 refers to R3's OSPF RID, because R3 created the OSPF

! LSAs that we are trying to match--the LSAs created when R3 injected the

! routes redistributed from RIP.

router ospf 1

distance 179 3.3.3.3 0.0.0.0 only-rip-routes

ip access-list standard only-rip-routes

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 659

permit 10.1.12.0

permit 10.1.3.0

permit 10.1.2.0

permit 10.1.23.0

! R3 config. Note that the command refers to 1.1.1.1, which is R1's RID. Other

! commands not related to resetting the AD are omitted. Also, the only-rip-routes

! ACL is identical to R1's only-rip-routes ACL.

router ospf 1

distance 179 1.1.1.1 0.0.0.0 only-rip-routes

Preventing Suboptimal Routes by Using Route Tags

Another method of preventing suboptimal routing on the redistributing routers is to sim-

ply filter the problematic routes. Using subnet 10.1.2.0/24 as an example again, R3 could

use an incoming distribute-list command to filter the OSPF route to 10.1.2.0/24, allowing

R3 to use its RIP route to 10.1.2.0/24. R1 would need to perform similar route filtering as

well to prevent its suboptimal route.

Performing simple route filtering based on IP subnet number works, but the redistributing

routers will need to be reconfigured every time subnets change in the higher-AD rout-

ing domain. The administrative effort can be improved by adding route tagging to the

process. When you tag all routes taken from the higher-AD domain and advertised into

the lower-AD domain, the distribute-list command can make a simple check for that tag.

Figure 11-6 shows the use of this idea for subnet 10.1.2.0/24.

10.1.4.0/2410.1.2.0/24

RIP – AD 120 OSPF: AD 110

Filtering Routes with Tag 9999

10.1.2.0/24

RIP

10.1.2.0/24

RIP

10.1.2.0/24

Tag 9999

10.1.2.0/24

Tag 9999

Filter incoming OSPF routes:

Don’t put routes tagged 9999 in

my routing table!

When injecting RIP

routes into OSPF, tag

them with 9999

R4R2

Figure 11-6 Filtering with Reliance on Route Tags

ptg13046388

660 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Route tags are simply unitless integer values in the data structure of a route. These tags,

typically either 16 or 32 bits long depending on the routing protocol, allow a router to

imply something about a route that was redistributed from another routing protocol. For

example, R1 can tag its OSPF-advertised route to 10.1.2.0/24 with a tag—say, 9999. OSPF

does not define what a tag of 9999 means, but the OSPF protocol includes the tag field

in the LSA so that it can be used for administrative purposes. Later, R3 can filter routes

based on their tag, solving the suboptimal route problem.

Figure 11-6 and Example 11-6 depict an example of route tagging and route filtering,

used to solve the same old problem with suboptimal routes. R1 and R3 tag all redistrib-

uted RIP routes with tag 9999 as they enter the OSPF domain, and then R1 and R3 filter

incoming OSPF routes based on the tags. This design works well because R1 can tag all

redistributed RIP routes, thereby removing the need to change the configuration every

time a new subnet is added to the RIP domain. (Note that both R1 and R3 will tag routes

injected from RIP into OSPF as 9999, and both will then filter OSPF-learned routes with

tag 9999. Figure 11-6 just shows one direction to keep the figure less cluttered.)

Example 11-6 Using Route Tags and Distribute Lists to Prevent Suboptimal Routes at

Redistributing Routers

! R1 config. The redistribute command calls the route map that tags routes taken

! from RIP as 9999. distribute-list looks at routes learned in OSPF that were

! earlier tagged by R3.

router ospf 1

redistribute rip subnets route-map tag-rip-9999

network 10.1.15.1 0.0.0.0 area 0

distribute-list route-map check-tag-9999 in

! Clause 10, a deny clause, matches all tagged 9999 routes--so those

! routes are filtered. Clause 20 permits all other routes, because with no match

! subcommand, the clause is considered to "match all."

route-map check-tag-9999 deny 10

match tag 9999

route-map check-tag-9999 permit 20

! tag-rip-9999 matches all routes (it has no match command), and then

! tags them all with tag 9999. This route-map is used only for routes taken from

! RIP into OSPF.

route-map tag-rip-9999 permit 10

set tag 9999

! R3 Config

! The R3 configuration does not have to use the same names for route maps, but

! the essential elements are identical, so the route maps are not repeated here.

router ospf 1

redistribute rip subnets route-map tag-rip-9999

network 10.1.34.3 0.0.0.0 area 0

distribute-list route-map check-tag-9999 in

! R3 (shown) and R1 have RIP routes to 10.1.2.0, as well as other routes from the

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 661

! RIP domain. Also, note that the OSPF LSDB shows the tagged values on the routes.

R3# show ip route | incl 10.1.2.0

R 10.1.2.0 [120/1] via 10.1.23.2, 00:00:26, Serial0/0/0.2

R3# sh ip ospf data | begin Type-5

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

10.1.1.0 1.1.1.1 834 0x80000006 0x00CE86 9999

10.1.1.0 3.3.3.3 458 0x80000003 0x0098B7 9999

10.1.2.0 1.1.1.1 834 0x80000006 0x00C390 9999

10.1.2.0 3.3.3.3 458 0x80000003 0x008DC1 9999

! lines omitted for brevity

! Next, the unfortunate side effect of filtering the routes--R3 does not have an

! alternative route to RIP subnets, although OSPF internal routers (like R4

! in Figure 11-6 ) will.

R3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R3(config)# int s0/0/0.2

R3(config-subif)# shut

R3(config-subif)# ^Z

R3# sh ip route | incl 10.1.2.0

R3#

The last few lines of the example show the largest negative of using route filtering to pre-

vent the suboptimal routes. When R3 loses connectivity to R2, R3 does not use the alter-

nate route through the OSPF domain. R3’s filtering of those routes occurs regardless of

whether R3’s RIP routes are available or not. As a result, using a solution that manipulates

the AD might ultimately be the better solution to this suboptimal-routing problem.

Using Metrics and Metric Types to Influence Redistributed Routes

A different set of issues can occur for a router that is internal to a single routing domain,

like R4 and R5 in Figure 11-4 . The issue is simple—with multiple redistributing routers,

an internal router learns multiple routes to the same subnet, so it must pick the best route.

As covered earlier in the chapter, the redistributing routers can set the metrics; by setting

those metrics with meaningful values, the internal routers can be influenced to use a par-

ticular redistribution point.

Interestingly, internal routers might not use metric as their first consideration when

choosing the best route. For example, an OSPF internal router will first take an intra-area

route over an inter-area route, regardless of their metrics. Table 11-8 lists the criteria an

internal router will use when picking the best route, before considering the metrics of the

different routes.

ptg13046388

662 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 11-8 IGP Order of Precedence for Choosing Routes Before Considering the

Metric

IGP Order of Precedence of Metric

RIP No other considerations

EIGRP Internal, then external

OSPF Intra-area, inter-area, E1, then E2*

IS-IS L1, L2, external

* For E2 routes whose metric ties, OSPF also checks the cost to the advertising ASBR.

To illustrate some of these details, Example 11-7 focuses on R4 and its routes to

10.1.2.0/24 and 10.1.5.0/24 from Figure 11-4 . The example shows the following, in order:

1. R1 and R3 advertise 10.1.2.0/24 as an E2 route, metric 20. R4 uses the route through

R3, because R4’s cost to reach ASBR R3 is lower than its cost to reach ASBR R1.

2. After changing R1 to advertise redistributed routes into OSPF as E1 routes, R4 uses

the E1 routes through R1, even though the metric is larger than the E2 route

through R3.

3. R4 uses it higher-metric intra-area route to 10.1.5.0/24 through R5. Then, the R4-R5

link fails, causing R4 to use the OSPF external E2 route to 10.1.5.0/24—the route

that leads through the RIP domain and back into OSPF through the R3-R2-R1-R5

path.

Example 11-7 Demonstration of the Other Decision Criteria for Choosing the Best

Routes

! R4 has E2 routes to all the subnets in the RIP domain, and they all point to R3.

R4# sh ip route ospf

10.0.0.0/24 is subnetted, 10 subnets

O 10.1.15.0 [110/128] via 10.1.45.5, 00:03:23, Serial0/0/0.5

O E2 10.1.12.0 [110/20] via 10.1.34.3, 00:03:23, Serial0/0/0.3

O E2 10.1.3.0 [110/20] via 10.1.34.3, 00:03:23, Serial0/0/0.3

O E2 10.1.2.0 [110/20] via 10.1.34.3, 00:03:23, Serial0/0/0.3

O E2 10.1.1.0 [110/20] via 10.1.34.3, 00:03:23, Serial0/0/0.3

O 10.1.5.0 [110/65] via 10.1.45.5, 00:03:23, Serial0/0/0.5

O E2 10.1.23.0 [110/20] via 10.1.34.3, 00:03:23, Serial0/0/0.3

! R4 chose the routes through R3 instead of R1 due to the lower cost to R3.

R4# show ip ospf border-routers

OSPF Process 1 internal Routing Table

Codes: i - Intra-area route, I - Inter-area route

i 1.1.1.1 [128] via 10.1.45.5, Serial0/0/0.5, ASBR, Area 0, SPF 13

i 3.3.3.3 [64] via 10.1.34.3, Serial0/0/0.3, ASBR, Area 0, SPF 13

! (Not Shown): R1 is changed to redistribute RIP routes as E1 routes by

! adding the metric-type 1 option on the redistribute command on R1.

Key

Topic

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 663

! R4 picks routes through R1 because they are E1 routes, even though the metric

! (148) is higher than the routes through R3 (cost 20)

R4# show ip route ospf

10.0.0.0/24 is subnetted, 10 subnets

O E1 10.1.2.0 [110/148] via 10.1.45.5, 00:00:11, Serial0/0/0.5

! lines omitted for brevity

! R4's route to 10.1.5.0/24 below is intra-area, metric 65

R4# show ip route | incl 10.1.5.0

O 10.1.5.0 [110/65] via 10.1.45.5, 00:04:48, Serial0/0/0.5

! (Not Shown): R4 shuts down link to R5

! R4's new route to 10.1.5.0/24 is E2, learned from R3, with metric 20

R4# show ip route | incl 10.1.5.0\

O E2 10.1.5.0 [110/20] via 10.1.34.3, 00:10:52, Serial0/0/0.3

Route Summarization

Route summarization creates a single route whose numeric range, as implied by the pre-

fix/prefix length, is larger than the one or more smaller component routes. For example,

10.1.0.0/16 is a summary route that includes component subnets 10.1.1.0/24, 10.1.4.132/30,

and any other subnets with the range 10.1.0.0 through 10.1.255.255.

Note I use the term component route to refer to a route whose range of IP addresses is

a subset of the range specified by a summary route; however, I have not seen this term in

other reference materials from Cisco.

The following list details some of the key features that the three IGPs covered in this

book have in common with regard to how route summarization works (by default):

■ The advertised summary is assigned the same metric as the currently lowest-metric

component subnet.

■ The router does not advertise the component subnets.

■ The router does not advertise the summary when its routing table does not have any

of the component subnets.

■ The summarizing router creates a local route to the summary, with destination null0,

to prevent routing loops.

■ Summary routes reduce the size of routing tables and topology databases, indirectly

improving convergence.

■ Summary routes decrease the amount of specific information in routing tables,

sometimes causing suboptimal routing.

Figure 11-7 depicts the suboptimal-routing side effect when using route summarization. It

also depicts the effect of using a summary to null0 on the summarizing router.

ptg13046388

664 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Subnets That All

Begin with 10.1

R3 Routing Table:

10.1.1.0/24…

10.1.2.0/24…

10.2.2.0/24…

10.0.0.0/8, to null0

R4 Routing Table:

10.0.0.0/8, to R3

Subnets That All

Begin with 10.2

Subnet 10.2.2.0/24

Packet to 10.3.3.1

Packet to 10.2.2.1

Summary 10.0.0.0/8

Both packets match my

best route to 10.0.0.0/8,

which points to R3

• Packet to 10.3.3.1 matches

route to Null0 – Discard

• Packet to 10.2.2.1 matches

specific route – Forward

Represents Routing Updates

Represents Example Packets

R3 R4

Figure 11-7 Route Summarization Suboptimal Routing and Routing to Null0

In Figure 11-7 , R4 learned two paths to summary route 10.0.0.0/8, and picked the route

through R3 based on the metric. Because R4 does not have a route for 10.2.2.0/24, R4

then sends any packets to that subnet based on its route to network 10.0.0.0/8, through

R3. So, although subnets like 10.2.2.0/24 might be topologically closer to R4 through R1,

R4 sends the packets through the scenic, suboptimal route through R3.

Also note that R4’s summary route to 10.0.0.0/8 matches packets for which the compo-

nent subnet does not exist anywhere in the network. In that case, routers like R4 forward

the packets based on the larger summary, but when the packet reaches the router that cre-

ated the summary, the packet is discarded by the summarizing router because of its null

route. For example, Figure 11-7 shows R4 forwarding a packet destined to 10.3.3.1 to R3.

R3 does not have a more specific route than its route to 10.0.0.0/8, with next-hop inter-

face null0. As a result, R3 discards the packet.

The sections that follow provide a few details about summarization with each routing

protocol.

EIGRP Route Summarization

EIGRP provides the easiest and most straightforward rules for summarizing routes as

compared with RIPv2, OSPF, and IS-IS. To summarize routes, the ip summary-address

eigrp as-number network-address subnet-mask [ admin-distance ] command is placed

under an interface. If any of the component routes are in that router’s routing table,

EIGRP advertises the summary route out that interface. The summary is defined by the

network-address subnet-mask parameters.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 665

One of the more interesting features of the EIGRP summary is the ability to set the AD

of the summary route. The AD is not advertised with the route. The summarizing router,

however, uses the configured AD to determine whether the null route for the summary

should be put into its routing table. The EIGRP AD for summary routes defaults to 5.

OSPF Route Summarization

All OSPF routers in the same area must have identical link-state databases (LSDB) after

flooding is complete. As a result, all routers in the same OSPF area must have the same

summary routes, and must be missing the same component subnets of each summary.

To make that happen, OSPF allows route summarization only as routes are injected into

an area, either by an Area Border Router ABR (inter-area routes) or by an Autonomous

System Boundary Router ASBR (external routes).

OSPF uses two different configuration commands to create the summary routes, depend-

ing on whether the summary is for inter-area or external routes. Table 11-9 lists the two

commands. Both commands are configured under router ospf .

Table 11-9 OSPF Route Summarization Commands

Where Used Command

ASBR summary-address {{ ip-address mask } | { prefix mask }} [ not-advertise ] [ tag tag ]

ABR area area-id range ip-address mask [ advertise | not-advertise ] [ cost cost ]

The commands have a couple of important attributes. First, the area range command

specifies an area; this area is the area in which the component subnets reside, with the

summary being advertised into all other areas . Also, the area range command can set

the cost for the summary route, instead of using the lowest cost of all component routes.

Also, the not-advertise keyword can essentially be used to filter the subnets implied by

the summary, as covered in Chapter 9 , “OSPF.”

The summary-address command summarizes external routes as they are injected into

OSPF as an ASBR. The cost can be assigned, and the routes can be filtered using the not-

advertise keyword.

Default Routes

Routers forward packets using a default route when there are no specific routes that

match a packet’s destination IP address in the IP routing table. Routing protocols can

advertise default routes, with each router choosing the best default route to list as that

router’s gateway of last resort . This section covers how a router can create a default

route and then cause an IGP to advertise the default route.

In addition to the advertisement of default routes, each router can use one of two options

for how the default route is used. As described in Chapter 6 , “IP Forwarding (Routing),”

Key

Topic

ptg13046388

666 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

each router’s configuration includes either the (default) ip classless command or the no ip

classless command. With ip classless , if a packet’s destination does not match a specific

route in the IP routing table, the router uses the default route. With no ip classless , the

router first checks to see whether any part of the destination address’s classful network

is in the routing table. If so, that router will not use the default route for forwarding that

packet.

Note The topic of default routing requires discussion of the configuration on one router,

plus configuration of the other routers using the same IGP. For this section, I will call the

router with the default routing configuration the “local” router and other routers using the

same IGP “other” routers.

Cisco IOS supports five basic methods of advertising default routes with IGPs, four of

which are covered here. One method for advertising a default route is for one routing pro-

tocol to redistribute another routing protocol’s default route. Because route redistribution

has already been covered heavily, this section of the chapter covers other methods. Of

the other four methods, not all are supported by all IGPs, as you can see in Table 11-10 .

Table 11-10 Four Methods for Learning Default Routes

Feature RIP EIGRP OSPF

Static route to 0.0.0.0, with the redistribute static command Yes Yes No

The default-information originate command Yes No Yes

The ip default-network command Yes Yes No

Using summary routes No Yes No

Interestingly, when a router learns of multiple default routes, using any of these methods,

it will use the usual process for choosing the best route: administrative distance, route

type (per Table 11-8 , earlier in this chapter), and lowest metric, in that order.

Note Table 11-10 has details that might be difficult to memorize. To make it easier, you

could start by ignoring the use of summary static routes, because it is not recommended

by Cisco. Then, note that RIP supports the other three methods, whereas EIGRP supports

two methods and OSPF supports only one—with EIGRP and OSPF not supporting any of

the same options.

Figure 11-8 shows a sample network used with all the default route examples, in which

R1 is the local router that configures the default routing commands.

Key

Topic

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 667

13.1.2.3/24

13.1.1.0/24 15.1.1.0/24

17.1.1.0/24

Fa0/0

15.1.2.5/24

Fa0/0

17.1.2.7/24

Fa0/0

RID 1.1.1.1

RID 5.5.5.5

0/0/0.1

0/0.1

.1 .1

.1 .1 .7

14.1.2.4/24 14.1.1.0/24

10.1.1.102/24

Fa0/0

0/0/0.1

RIP

Network 13.0.0.0

OSPF 1 (Two Areas, with R5 as ABR)

Network 15.0.0.0

IS-IS (Both Routers Are L2)

Network 17.0.0.0

EIGRP 1

Network 14.0.0.0

Figure 11-8 Sample Network for Default Route Examples

Using Static Routes to 0.0.0.0, with redistribute static

Routers consider a route to 0.0.0.0/0 as a default route. RIP and EIGRP support redistribu-

tion of static routes, including such a default static route. The rules and conditions for

redistributing static defaults into RIP and EIGRP are as follows:

■ The static ip route 0.0.0.0 0.0.0.0 and redistribute static commands need to be con-

figured on the same local router.

■ The metric must be defaulted or set, using the same methods covered earlier in this

chapter.

■ The redistribute command can refer to a route map , which examines all static routes

(not just the default).

■ EIGRP treats the default route as an external route by default, with default AD 170.

■ This method is not supported by OSPF.

Example 11-8 shows how R1 can inject defaults through RIP to R3 and through EIGRP to

R4. The EIGRP configuration refers to a route map that examines all static routes, match-

ing only static default routes. If other static routes existed, EIGRP would not advertise

those routes based on the route map.

Example 11-8 Static Default Route with Route Redistribution

! R1 Config--note that ip classless is configured, but it does not impact the

! advertisement of the static route at all.

router eigrp 1

redistribute static route-map just-default

network 10.0.0.0

network 14.0.0.0

default-metric 1544 10 1 1 1

Key

Topic

ptg13046388

668 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

router rip

version 2

redistribute static

network 13.0.0.0

default-metric 1

ip classless

! The static route is configured next, followed by the prefix list that matches

! the default route, and the route map that refers to the prefix list.

ip route 0.0.0.0 0.0.0.0 10.1.1.102

ip prefix-list zero-prefix seq 5 permit 0.0.0.0/0

route-map just-default permit 10

match ip address prefix-list zero-prefix

route-map just-default deny 20

! Next, R3, the RIP router, lists R1 (13.1.1.1) as its gateway of last resort,

! based on the RIP route to 0.0.0.0/0, next hop 13.1.1.1.

R3# sh ip route

! Lines omitted for brevity

Gateway of last resort is 13.1.1.1 to network 0.0.0.0

13.0.0.0/24 is subnetted, 2 subnets

C 13.1.1.0 is directly connected, Serial0/0/0.1

C 13.1.2.0 is directly connected, FastEthernet0/0

R* 0.0.0.0/0 [120/1] via 13.1.1.1, 00:00:12, Serial0/0/0.1

! Next, R4, the EIGRP router, lists R1 (14.1.1.1) as its gateway of last resort,

! based on the EIGRP route to 0.0.0.0/0, next hop 14.1.1.1. Note that the default

! points to 0.0.0.0/0, AD 170, as it is an external route, due to the EX listed

! in the output of the show ip route command.

R4# sh ip route

! lines omitted for brevity

Gateway of last resort is 14.1.1.1 to network 0.0.0.0

D 10.0.0.0/8 [90/2172416] via 14.1.1.1, 00:01:30, Serial0/0/0.1

14.0.0.0/24 is subnetted, 2 subnets

C 14.1.2.0 is directly connected, FastEthernet0/0

C 14.1.1.0 is directly connected, Serial0/0/0.1

D*EX 0.0.0.0/0 [170/2172416] via 14.1.1.1, 00:01:30, Serial0/0/0.1

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 669

Using the default-information originate Command

OSPF does not support redistribution of statically defined default routes. Instead, OSPF

requires the default-information originate router subcommand, which essentially tells

OSPF to redistribute any default routes found in the routing table, either static routes or

routes from another routing protocol. The following list summarizes the default routing

features when using the default-information originate command with OSPF:

■ Redistributes any default route (0.0.0.0/0) in the routing table.

■ The command can set the metric and metric type directly, with OSPF defaulting to

cost 1 and type E2.

■ OSPF allows the use of the always keyword, which means that a default is sourced

regardless of whether a default route is in the routing table.

■ Not supported by EIGRP.

■ Supported by RIP, with some differences. (Refer to the text following Example 11-9

for an explanation of the differences.)

Example 11-9 shows an example of using the default-information originate command

with OSPF. In this case, R1 has learned a route to 0.0.0.0/0 through BGP from R9 in Figure

11-8 .

Example 11-9 Static Default Route with Route Redistribution

router ospf 1

network 15.0.0.0 0.255.255.255 area 0

default-information originate

! R5 has a default route, defaulting to type E2, cost 1. It as advertised as a

! type 5 LSA.

R5# show ip route ospf

O*E2 0.0.0.0/0 [110/1] via 15.1.1.1, 00:18:07, Serial0/0.1

R5# sh ip ospf data | begin Type-5

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

0.0.0.0 1.1.1.1 1257 0x80000001 0x008C12 1

As mentioned earlier, RIP does support the default-information originate command;

however, the command behaves slightly differently in RIP than it does in OSPF. With

RIP, this command creates and advertises a default route if either no default route exists

or a default route was learned from another routing protocol. However, if a static route

to 0.0.0.0/0 is in the local routing table, the default-information originate command does

not cause RIP to inject a default. The reason behind this behavior is that RIP already sup-

ports redistribution of static routes, so redistribute static should be used in that case.

Key

Topic

ptg13046388

670 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Using the ip default-network Command

RIP and EIGRP can inject default routes by using the ip default-network command. To

do so, the following must be true on the local router:

■ The local router must configure the ip default-network net-number command, with

net-number being a classful network number.

■ The classful network must be in the local router’s IP routing table, through any

means.

■ For EIGRP only, the classful network must be advertised by the local router into

EIGRP, again through any means.

■ This method is not supported by OSPF.

When using the ip default-network command, RIP and EIGRP differ in how they adver-

tise the default. RIP advertises a route to 0.0.0.0/0, but EIGRP flags its route to the class-

ful network as a candidate default route. Because EIGRP flags these routes as candidates,

EIGRP must then also be advertising those classful networks. However, because RIP does

not flag the classful network as a candidate default route, RIP does not actually have to

advertise the classful network referenced in the ip default-network command.

Example 11-10 shows the key difference between RIP and EIGRP with regard to the ip

default-network command. In this case, R1 will advertise about classful network 10.0.0.0

using EIGRP because of the auto-summary command.

Example 11-10 Static Default Route with Route Redistribution

! EIGRP will advertise classful network 10.0.0.0/8 due to its network command,

! matching R1's fa0/0 interface, and the auto-summary command. Also, R1 must have

! a route to classful network 10.0.0.0/8, in this case due to a static route.

! RIP will not advertise classful network 10.0.0.0/8, but it will still be able

! to inject a default route based on the ip default-network command.

router eigrp 1

network 10.0.0.0

network 14.0.0.0

auto-summary

router rip

version 2

network 13.0.0.0

ip classless

ip default-network 10.0.0.0

ip route 10.0.0.0 255.0.0.0 10.1.1.102

! On R3, RIP learns a route to 0.0.0.0/0 as its default.

R3# show ip route rip

R* 0.0.0.0/0 [120/1] via 13.1.1.1, 00:00:19, Serial0/0/0.1

! On R4, note that EIGRP learned a route to 10.0.0.0/8, shown with a * that

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 671

! flags the route as a candidate default route.

R4# show ip route

! lines omitted for brevity

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 14.1.1.1 to network 10.0.0.0

D* 10.0.0.0/8 [90/2172416] via 14.1.1.1, 00:05:35, Serial0/0/0.1

14.0.0.0/24 is subnetted, 2 subnets

C 14.1.2.0 is directly connected, FastEthernet0/0

C 14.1.1.0 is directly connected, Serial0/0/0.1

Using Route Summarization to Create Default Routes

Generally speaking, route summarization combines smaller address ranges into a small

number of larger address ranges. From that perspective, 0.0.0.0/0 is the largest possible

summary, because it includes all possible IPv4 addresses. And, as it turns out, EIGRP

route summarization supports summarizing the 0.0.0.0/0 supernet, effectively creating a

default route.

Because route summarization causes a null route to be created for the summary, some

Cisco documentation advises against using route summarization to create a default route.

For example, in Figure 11-8 , imagine that R9 is owned by this network’s ISP, and R1

learns a default route (0.0.0.0/0) through EBGP from R9. However, when R1 configures

an EIGRP default route using route summarization, R1 will also create a local route to

0.0.0.0/0 as well, but with destination null0. The EBGP route has a higher AD (20) than the

EIGRP summary route to null0 (AD 5), so R1 will now replace its BGP-learned default

route with the summary route to null0—preventing R1 from being able to send packets to

the Internet.

Route summarization can still be used to create default routes with the proper precau-

tions. The following list details a few of the requirements and options:

■ The local router creates a local summary route, destination null0, using AD 5

(EIGRP), when deciding whether its route is the best one to add to the local routing

table.

■ EIGRP advertises the summary to other routers as AD 90 (internal).

■ This method is not supported by RIP and OSPF.

■ To overcome the caveat of EIGRP’s default route being set to null by having a low

AD, set the AD higher (as needed) with the ip summary-address command.

Example 11-11 lists a sample configuration on R1 again, this time creating summary

routes to 0.0.0.0/0 for EIGRP.

ptg13046388

672 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 11-11 EIGRP Configuration for Creating Default Summary Routes

! EIGRP route summarization is done under s0/0/0.4, the subnet connected to R4. In

! this example, the AD was changed to 7 (default 5) just to show how to change the

! AD. To avoid the problem with the default route to null0 on R1, the AD should

! have been set higher than the default learned via BGP.

interface Serial0/0/0.4 point-to-point

ip address 14.1.1.1 255.255.255.0

ip summary-address eigrp 1 0.0.0.0 0.0.0.0 7

! In this example, R1 has two sources for a local route to 0.0.0.0/0: EIGRP

! (AD 7, per the ip summary-address command), and BGP from R9

! (AD 20). R1 installs the EIGRP route based on the lowest AD.

R1# show ip route eigrp

14.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

D 14.1.2.0/24 [90/2172416] via 14.1.1.4, 00:01:03, Serial0/0/0.4

D 14.0.0.0/8 is a summary, 05:53:19, Null0

D* 0.0.0.0/0 is a summary, 00:01:08, Null0

! Next, R4's EIGRP route shows AD 90, instead of the AD 7 configured at R1. AD is

! a local parameter--R4 uses its default AD of 90 for internal routes.

R4# show ip route eigrp

D* 0.0.0.0/0 [90/2172416] via 14.1.1.1, 00:01:14, Serial0/0/0.1

Performance Routing (PfR)

Cisco Systems began experimenting with routing protocols that could make best route

selection based on variable parameters like load and bandwidth as early as the 1980s.

The Cisco-proprietary routing protocol EIGRP was the first attempt at this approach,

expanding route selection criteria. EIGRP gave us the “K Values” that we could select to

make dynamic changes to the selection process. The problem with this approach was that

the dynamic nature of the circuits connecting neighbors resulted in what could only be

described as unstable links and adjacencies based on network load and traffic utilization.

So the advised best practice became to simply turn off the K values that impacted net-

work stability.

Not satisfied with this, Cisco continued to research other protocol enhancements. These

efforts ultimately culminated in the creation of Optimized Edge Routing (OER). This

technology gave us the capability to perform prefix-based route optimizations. Now this

is not to be confused with what is currently referred to as Performance Routing (PfR). We

will start at the beginning and work our way forward to PfR.

OER promised many things; among those promises was the ability to extend the capabili-

ties of routers to more optimally route traffic. In OER, the network performance criteria

use to manipulate traffic was limited. Specifically, OER relied on packet loss, response

time, path availability, and traffic load distribution to make its decisions. Each of these

criteria was a significant deviation from how typical routing protocols operate and could

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 673

be used to significantly enhance network performance. But we have to realize that as

technology advances, so do the needs of modern networks. Herein lay the Achilles heel

of OER.

Modern networks benefited greatly from the more granular control that OER brought to

the table, but one element was missing from OER. Keep in mind that we described opti-

mized edge routing as a “Prefix-based Route Optimization” enhancement. But modern

networks needed something even more capable, something that would take application-

specific needs into account, not just route and prefix information. Thus, Performance

Routing was introduced.

PfR was built on OER’s foundation and extended its capabilities to include route opti-

mization criteria that could be based on application type, application performance

requirements, as well as the traditional network performance criteria available in OER. In

light of this fundamental enhancement to the protocol, the decision to change the name

from OER (a “Prefix-based Route Optimization” protocol) to Performance Routing (an

“Application Path Optimization” protocol) made perfect sense. Despite these feature

enhancements and the expanded deployment options we now have available to us, the

fundamental operation of PfR is still identical to OER. By this we are referring to what is

commonly called the OER Phases wheel.

Performance Routing Operational Phases

Cisco created the idea of the Phases Wheel to help illustrate and explain the operation

of OER/PfR. The problem with this notion is the fact that in operation these phases

are not so easy to identify, and the lines between them become somewhat blurred and

hard to recognize. What we will do in this section is look at each of the five phases and

attempt to quantify what the goal of each is. I personally feel that this is the best method

for using this multiphased approach to describe this technology and how it operates.

However, after the configurations have been applied and we begin to look at what is hap-

pening in a working deployment, we will make reference to these different phases in a

loose context. The key point to remember at this juncture of our discussion is the fact

that each of these phases makes a repeating cycle, thus the term “phases wheel,” that will

run constantly after OER has been configured and enabled on our network devices.

■ Profile Phase: Learn flows that have high latency and throughput sometimes referred

to as the “Learning” phase. Traffic that is being “profiled or learned” is referred to as

a traffic class. The list of all monitored traffic classes (MTC) is referred to as an MTC

list.

■ Measure Phase: Collect and compute performance metrics for the traffic identified

in the MTC list.

■ Apply Policy Phase: Create low and high thresholds to define in-policy and out-of-

policy (OOP) performance categories.

■ Control Phase: Influence traffic by manipulating routing or by using policy-based

routing (PBR).

ptg13046388

674 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

■ Verify Phase: After controls have been introduced, OER will verify OOP event per-

formance and make necessary adjustments to bring back in-policy performance.

When we understand that each of these phases constantly repeats, we clearly see that the

process is designed to be constantly adjusting. In a way, this is no different than the finite

state machine (FSM) process that runs between adjacent neighbors like those found in

OSPF or EIGRP, but instead of a neighbor peering status, we are checking to see whether

the network needs optimizing or whether a decision to optimize made previously is still

valid.

The “phases wheel” is not the only logical construct that we have to get our minds around

when it comes to understanding PfR. There are a number of classifications, capabilities,

and roles that need to be discussed before we move on.

Performance Routing Concepts

There are three primary interface types that we will need to understand to configure PfR.

These interface types are defined based on their roles in the PfR environment. These roles

are used to identify whether interfaces are used to forward packets out of the network

or into the network. Each of these interface types is required in a topology to correctly

deploy PfR:

■ Internal Interfaces: These interfaces are used to connect to the internal network and

will always be the interfaces used for communication with the device in the infra-

structure that is designated as the control plane manager for the performance rout-

ing environment. This device is known as the Master Controller. We will cover this

device in greater detail in a subsequent section.

■ External Interfaces: These are the physical interfaces that are used to transmit pack-

ets out of the local network. There must be at least two interfaces identified as exter-

nal interfaces to successfully deploy OER. These are the interfaces where prefixes

and exit link performance will be monitored.

■ Local Interfaces: These are interfaces that are used in the formation of the control

plane mechanism that drives the OER process. Specifically, this interface defines the

source interface that will be used to communicate to the Master Controller we men-

tioned earlier.

Authentication

The next section discusses the physical and logical roles associated with the component

elements found in a typical PfR deployment. Suffice it to say that the component devices,

one of which is the Master Controller we have alluded to and the routers it controls, all

work in concert to optimize network performance. We have to realize that these commu-

nications all serve to change existing routing parameters, add new prefixes, and manipu-

late overall network performance at the network’s edge. This translates into handing over

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 675

network control to the Master Controller. For our discussions, a Master Controller will

be a router that will manage all optimization decisions. Simply put, it will control what

happens at the periphery of the local domain. However, handing over control to a device

brings with it some level of risk. The foremost risk is that the newly created control plane

mechanism could be leveraged by an unauthorized party or parties.

In an effort to mitigate this level of risk, Performance Routing incorporates mandatory

authentication. Specifically, communication between the Master Controller and its slave

devices is protected by key-chain authentication. This authentication key must be con-

figured on all devices involved in the process before communications can be established.

The key chain is created under the global configuration mode on each device to include

the Master Controller. Thus far, we have been careful to avoid discussing device roles,

because it is more important for us to understand the fundamental concepts at this junc-

ture rather than the actual operational roles fulfilled by each device. Now that we have

a firm grasp of these concepts, we will move into a more detailed discussion about how

OER accomplishes optimization and what specific tasks are accomplished by devices

assuming different operational roles.

Performance Routing Operational Roles

Cisco PfR requires two primary components—a Master Controller and one or more bor-

der routers. The Master Controller is the decision maker, whereas the border routers are

network edge devices with exit interfaces. These exit interfaces can be used to connect

with the Internet or as outbound links to other network resources.

Master Controller (MC)

In any PfR environment, there will be a single device that manages all aspects of PfR

operations. The job of the MC is to maintain communication and authenticate the ses-

sions with the border routers. The Master Controller will monitor outbound traffic flows

and then apply policies to optimize routing for network prefixes and exit links. Even

though the MC manages all aspects of PfR, it must be noted that it is not necessary for

the MC to be in the forwarding path taken by the network traffic, but it must be reach-

able by the border routers. A single MC can support up to ten individual border routers

or up to 20 managed exit interfaces (external interfaces).

This device can be configured in multiple fashions based on network size.

The simplest configuration is where the MC and the border router are running on a single

device. This configuration is used most often in small office or home office networks that

have multihomed connectivity to the Internet. In these environments, it must be noted

that authentication is still required for PfR to function. Another very common topology

employed in branch office networks is to have the master control coreside on one of mul-

tiple border routers. Figure 11-9 illustrates these MC deployments.

ptg13046388

676 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

SOHO Small Business

MC/BR

MC/BR1

BR2

Figure 11-9 Colocated MC/BR Deployments

Figure 11-10 illustrates that the third method of deployment for an MC is a standalone

MC. This design is the most common, because it distributes CPU and resource utilization

more evenly and can be found in medium to large enterprises. The benefits of being able

to spread the control aspects of Performance Routing to multiple devices along the edge

of the local network is where most organizations see a real return when using a technol-

ogy like PfR.

BR2

Headquarters/Data Center

BR1

Figure 11-10 Sample Network for Standalone MC Deployment

Border Router

In the context of PfR, a border router is a router with one or more interfaces serving as

exit links to either ISP, in the case of multihoming, or to other attached networks. The

border router is where all policy decisions and routing changes will be enforced. It is the

border router, under the control of the MC, that participates in prefix monitoring. It is

the individual border routers that report prefix and transit link measurements back to the

MC, where policy decisions are made. The MC will then instruct the appropriate border

router to enforce any selected policy changes by injecting a preferred route to alter the

course of packet flow in the network. Remember that the border router process we are

describing can be, and often will be, enabled on the same router running the Master

Controller process in small environments.

At this juncture in our discussion about performance routing, we have only really dis-

cussed the fundamental theory behind how it operates. We have been careful to avoid

getting very detailed about device roles and how they are to be assigned. In the next

section, we will begin to narrow our focus and start using our new understanding of the

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 677

basic elements we have discussed thus far to practice PfR deployment while expanding

our knowledge of the operation of the protocol to critical observation and testing.

PfR Basic Configuration

Figure 11-11 illustrates the topology that we are going to work with in this section. We

will perform all the basic tasks necessary to configure a working PfR topology. In this

section, however, our primary focus will be to simply create the MC and BRs illustrated

in Figure 11-11 . In doing so, we will explore the commands necessary to establish the

peering and exchange of communication that we have discussed; now we will start mak-

ing the theoretical concepts tangible.

6.6.6.6/24

10.1.200.0/24

10.1.12.0/24 10.1.13.0/24

10.1.14.0/24

OSPF

Area 0

BR BR

F0/0

S0/0.31

301

103

S0/0.13

F0/0

S0/0.12

102

201

S0/0.21

F0/0

Lo0

R2 R3

Figure 11-11 Sample Network for Basic PfR Configuration

Configuration of the Master Controller

First we will look at the most basic configuration commands necessary to create a Master

Controller. Note that the majority of the Performance Routing configuration is actually

done on this particular component.

ptg13046388

678 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step 1. Create the authentication key chain.

As we mentioned in the previous section, PfR requires authentication before

it will even operate, and the method employed by the protocol to do this is

the MD5 key chain/key-string approach. This configuration is made under the

global configuration context of all devices that will fulfill operational roles

as they are defined in PfR; this includes the MC and all BRs. We will wait to

configure the key chains on the BRs in our topology until we reach the border

router subtopic in this section. In our topology, R4 is our MC, so it is on that

device that we will be working. The following example shows the MC con-

figuration:

R4# conf t

R4(config)# key chain PFR_AUTH

R4(config-keychain)# key 1

R4(config-keychain-key)# key-string CISCO

R4(config-keychain-key)# end

!We can see the detail about the key chain we just configured via the

! show key chain !command.

R4# show key chain

Key-chain PFR_AUTH:

key 1 -- text "CISCO"

accept lifetime (always valid) - (always valid) [valid now]

send lifetime (always valid) - (always valid) [valid now]

Now that we have the key chain configured, we can move to the next step of

the Master Controller configuration process.

Step 2. Enable the PfR process.

This is accomplished with one simple command; however, there are several

available configuration options available:

R4# conf t

R4(config)# pfr master

R4(config-pfr-mc)#

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

!Observe that we are now inside the PfR master controller

!configuration context. At this point it is worthwhile for us to

!explore the array of commands that we have available to us in this

!mode. We can do that simply by using "?".

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

R4(config-pfr-mc)# ?

PFR master controller configuration commands:

active-probe Manually create an active probe for a known

target

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 679

api OER API related configuration

application Define application

backoff Specify backoff timer parameters

border Enter OER managed border router configuration

submode

default Set a command to its defaults

delay Specify delay parameters

exit Exit from OER master controller configuration

submode

holddown Specify hold-down timer parameter

jitter Specify jitter parameters

keepalive Specify keepalive interval

learn Enter prefix and traffic class learning

submode

logging Event Logging

loss Specify loss parameters

max Specify the upper limit

max-range-utilization Configure the maximum range for utilization of

all exits

mode Specify OER operating mode settings

mos Specify mos parameters

no Negate a command or set its defaults

periodic Specify periodic rotation timer value

policy-rules Name of oer-map defining OER policy

port Specify tcp port number for OER communication

resolve Specify OER policy resolver settings

shutdown Disable OER master controller functionality

traceroute Configure Traceroute global parameters

unreachable Specify unreachable parameters

There are only 26 commands available under this configuration context, and

3 of them are “exit,” “shutdown,” and “no.” That leaves 23 commands relevant

to the configuration of the Master Controller. Before we have finished this

example, we will have discussed each and every one of these commands, to

include what role they play, and to describe how they can be manipulated to

obtain desired outcomes or performances. The point we are trying to make

here is that there is not only a finite range of commands, but also the true

point of fact is that there are only a handful of commands. To be honest,

there are about as many commands to be found in PfR as there are in RIP. This

should help to alleviate any concerns regarding the operational complexity of

this protocol.

Thus far, we have created the authentication key chain and enabled PfR,

but without border routers and internal and external interfaces, our MC is

worthless. So we need to move on to the next step of our configuration and

discussion.

ptg13046388

680 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step 3. Designate internal/external interfaces.

The MC needs something to control, and based on our discussions these con-

trolled devices are referred to as border routers. It is the border routers that

host the internal and external interfaces. The interesting point that we need to

make at this point is that even though the interfaces exist on the discreet BR,

we must designate which interfaces are which on the MC. Yes, it is the MC

that tells the BR which of its interfaces are considered internal or external.

This configuration is made on the MC under the “config-pfr-mc” configura-

tion context. To do this, we will first use the border command on the MC to

enter the Master Controller border router configuration mode. We will use

the loopback 0 addresses of our border routers to identify them, and remem-

ber we are required to use the key chain we created. We will start with the BR

2.2.2.2 (R2) as seen here:

R4(config-pfr-mc)# border 2.2.2.2 key-chain PFR_AUTH

R4(config-pfr-mc-br)#

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

!!It is under this context that we will specify and designate the

!!interface roles for R2. This is done via the interface command:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

R4(config-pfr-mc-br)# interface Serial0/0.21 internal

R4(config-pfr-mc-br)# interface FastEthernet0/0 external

R4(config-pfr-mc-br-if)# exit

R4(config-pfr-mc-br)# exit

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

!!Now we know that we have two BRs R2 and R3 so this configuration will

!! need to be repeated for R3 on the MC.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

R4(config-pfr-mc)# border 3.3.3.3 key-chain OER_AUTH

R4(config-pfr-mc-br)# interface Serial0/0.31 internal

R4(config-pfr-mc-br)# interface FastEthernet0/0 external

R4(config-pfr-mc-br-if)# exit

R4(config-pfr-mc-br)# exit

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

!!This has created the master border configuration on R4.

!!We know that we have not made

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 681

!!any configuration on the border routers so we should not expect this

!!to create a working configuration. We can however still use the show

!!oer master border command on

!!R4 to look at the status of the MC to BR relationship.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

R4(config-pfr-mc)# do show oer master border

Border Status UP/DOWN AuthFail Version

3.3.3.3 INACTIVE DOWN 0 0.0

2.2.2.2 INACTIVE DOWN 0 0.0

R4(config-pfr-mc)#

Configuration of the Border Router

We will move now to R2 and create the basic configuration necessary to enable it as a BR

in our topology.

Step 1. Create the authentication key chain.

As we mentioned in the previous section, PfR requires authentication before it

will even operate, and the method employed by the protocol to do this is the

MD5 key chain/key-string approach. We will make this configuration under

the global configuration context of R2 as seen here:

R4(config-pfr-mc)# border 2.2.2.2 key-chain PFR_AUTH

R4(config-pfr-mc-br)#

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

!!It is under this context that we will specify and designate the

!!interface roles for

!!R2. This is done via the interface command:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

R4(config-pfr-mc-br)# interface Serial0/0.21 internal

R4(config-pfr-mc-br)# interface FastEthernet0/0 external

R4(config-pfr-mc-br-if)# exit

R4(config-pfr-mc-br)# exit

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

!!Now we know that we have two BRs R2 and R3 so this configuration

!! will need to be repeated for R3 on the MC.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!

R4(config-pfr-mc)# border 3.3.3.3 key-chain PFR_AUTH

ptg13046388

682 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step 2. Enable the PfR process.

In this instance, we are going to enable the PfR process on R2, but we will

actually be activating the BR process as seen here:

R2# conf t

R2(config)# pfr border

R2(config-pfr-br)# master 4.4.4.4 key-chain OER_AUTH

R2(config-pfr-br)#

Step 3. Specify the local interface.

We employed the use of the loopback 0 addresses for BRs when we made the

configuration on the MC. We will need to ensure that the BRs source their

TCP sessions to the MC using these addresses as well. This is where we will

specify the local interface. The local interface is the interface used by the BRs

to communicate to the MC; this process is demonstrated here:

R2(config-pfr-br)# local loopback0

R2(config-pfr-br)#

Task Completion on R3

We will need to configure the same setup parameters on R3 to have two working BRs

in our topology. Remember, we need one MC and at least two external interfaces. These

interfaces can be on a single BR or distributed across multiple BRs. Rather than apply

these configurations in a stage approach, we will simply get R3 up and running as a BR,

as illustrated in the configuration that follows and move to the MC to conduct verifica-

tions:

R3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R3(config)# key chain PFR_AUTH

R3(config-keychain)# key 1

R3(config-keychain-key)# key-string CISCO

R3(config-keychain-key)# exit

R3(config-keychain)# exit

R3(config)#

R3(config)# pfr border

R3(config-pfr-br)# master 4.4.4.4 key-chain OER_AUTH

R3(config-pfr-br)# local loopback0

R3(config-pfr-br)# logging

R3(config-pfr-br)# port 3950

R3(config-pfr-br)# end

R3#

%OER_BR-5-NOTICE: MC 4.4.4.4 UP

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 683

The following output on R4 is provided to the console by the logging feature under the

PfR process we enabled:

R4#

%PFR_MC-5-NOTICE: BR 2.2.2.2 UP

%PFR_MC-5-NOTICE: BR 2.2.2.2 IF Fa0/0 UP

%PFR_MC-5-NOTICE: BR 2.2.2.2 IF Se0/0.21 UP

%PFR_MC-5-NOTICE: BR 2.2.2.2 Active

R4#

%PFR_MC-5-NOTICE: BR 3.3.3.3 UP

%PFR_MC-5-NOTICE: BR 3.3.3.3 IF Fa0/0 UP

%PFR_MC-5-NOTICE: BR 3.3.3.3 IF Se0/0.31 UP

%PFR_MC-5-NOTICE: BR 3.3.3.3 Active

The behavior we are observing is very important. Note that, as we have discussed previ-

ously, we need two external interfaces before the MC process will become active. We can

see the MC process come “up” on R4 after we have two external interfaces. Observe that

this requires both BRs to be operational in our topology.

%PFR_MC-5-NOTICE: MC Active

Troubleshooting Complex Layer 3 Issues

In troubleshooting, perhaps the easiest way to find the source of most problems is

through the show run command or variations of it. Therefore, as in Chapter 3 , “Spanning

Tree Protocol,” we’ll institute a simple “no show run ” rule in this section that will force

you to use your knowledge of more in-depth troubleshooting commands in the Cisco

IOS portion of this section.

In addition, you can expect that the issues that you’ll face in this part of the written exam

will need more than one command or step to isolate and resolve. You will need strong

mastery of the commands associated with the Layer 3 protocols tested in the CCIE

Routing & Switching track, and especially of OSPF, EIGRP, and BGP troubleshooting

commands. Those topics are addressed in other chapters in this book, and you should

know them well before going into the exam.

In this section, focus on the process first and then on specific techniques. We also pro-

vide a table of several of the more subtle types of Layer 3 problems that you’re likely to

encounter and describe ways of isolating those problems using Cisco IOS commands.

Because there are so many possible causes of trouble at Layer 3, we won’t spend these

pages on specific examples. Although you might become good at solving specific prob-

lems through examples, this section focuses more on the approach than on specific

examples because the approach and tools will get you through many more situations than

a few specific examples would.

ptg13046388

684 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Layer 3 Troubleshooting Process

You can expect that many difficulties that appear at Layer 3 are not really Layer 3 prob-

lems at all, but rather are the result of troubles in other layers of the protocol stack. Here

are some examples of issues at other layers that can impact Layer 3 protocols in subtle or

misleading ways:

■ An MTU mismatch on a link

■ A unidirectional link

■ A duplex mismatch

■ A link with a high error rate in one or both directions

■ Layer 2 configuration issues

■ Access list (ACL or VACL) filtering with unintended consequences (don’t forget that

implicit deny !)

■ Security policy that blocks required traffic

■ A TTL setting that’s too low for Layer 3 protocol operation

■ Two or more Layer 3 subnets configured in the same VLAN, which is especially

problematic with Layer 3 protocols that use broadcast or multicast traffic to form

adjacencies

From the standpoint of troubleshooting techniques, two basic stack-based approaches

come into play, depending on what type of issue you’re facing. The first is the climb-

the-stack approach, where you begin at Layer 1 and work your way up until you find the

problem. Alternatively, you can start at Layer 7 and work your way down; however, in the

context of the CCIE Routing and Switching exams, the climb-the-stack approach gener-

ally makes more sense.

The second approach is often referred to as the divide-and-conquer method. With this

technique, you start in the middle of the stack (usually where you see the problem; in this

case we’ll assume Layer 3) and work your way down or up the stack from there until you

find the problem. In the interest of time, which is paramount in an exam environment,

the divide-and-conquer approach usually provides the best results. In that vein, let’s start

by looking at some basic Layer 3 configuration items that can break routing protocols if

they’re incorrectly configured.

First, consider any field in the IP packet header that has configuration options. Some

fields in the IP header to check are these:

■ Mismatched subnet masks within a subnet.

■ A too-short TTL can cause some routing protocol adjacencies (specifically eBGP) to

fail to form, or stop IP communications from taking place across a path with mul-

tiple Layer 3 hops.

■ An MTU too low on a link can cause large packets to be dropped.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 685

■ An MTU mismatch on a link can cause large packets to be dropped on the low-MTU

end when they arrive.

■ Multicast traffic is not supported, disabled, or rate-limited on one or more links.

■ An overloaded link can result in packet loss, long latency, and jitter.

■ QoS configuration can cause packet loss, especially of keepalives.

After you’ve gotten past these core IP issues, you can begin to look for more in-depth

issues at Layer 3. These are likely to be specific to routing protocol configuration or

operation. However, in keeping with the scope of this section, we won’t consider simpler,

one-command issues such as adjacencies failing to form or authentication failures. These

issues are covered in the earlier chapters of this book. Some of the common sources of

problems in routing include the following:

■ Incorrect split-horizon configuration. This is challenging to find quickly because the

result is usually that most routes are propagated correctly, but some are not propa-

gated.

■ Incorrect redistribution configuration, especially with multiple points of redistribu-

tion or mutual redistribution. Incorrectly configured filtering or a lack of filtering

can cause routing loops.

■ Protocols not advertising routes when they appear to be configured to do so.

■ Protocols not redistributing routes when they appear to be configured to do so.

■ Incorrect route filtering because of incorrect masks applied in an access list or prefix

list.

■ EIGRP stuck-in-active (SIA) issues.

■ Incorrect summarization.

■ Administrative distance manipulation causing fundamental routing rules to be super-

seded.

■ Metric calculations configured differently on different routers (particularly affecting

metric calculations in OSPF or mismatched EIGRP k values).

■ Metric manipulation on a router.

■ NAT configuration with unintended consequences.

■ Policy-based routing configuration issues or unintended consequences.

■ Interface damping activity causing intermittent or flapping operation.

■ Mismatched timer settings, which sometimes result in adjacencies flapping.

When you’re troubleshooting Layer 3 issues, it’s a good idea to start with the basics:

Verify reachability, verify that the correct path is being used, and check the routing table

carefully. Make sure that routes are being learned through the correct protocols and from

the correct neighbors. Then look for deeper issues.

ptg13046388

686 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Layer 3 Protocol Troubleshooting and Commands

In addition to the myriad protocol-specific troubleshooting commands that you’ve

learned in previous chapters, this section addresses commands that can help you isolate

problems through a solid understanding of the information they present. We’ll use a vari-

ety of command output examples to illustrate the key parameters you should understand.

Note that this section doesn’t address Layer 2–specific commands because Chapter 3

covers those areas in the troubleshooting section.

IP Routing Processes

The show ip protocols command reveals a great deal of helpful information, as shown

in Example 11-12 . Comments are inserted between lines and begin with an exclamation

point for clarity.

Example 11-12 show ip protocols Command

Rush1# show ip protocols

Routing Protocol is "eigrp 1"

! Note the AS number.

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

! Note the filter list, which would be specified in these two lines.

Outgoing routes in Serial0/0.4 will have 1 added to metric if on list 11

! This is an example of metric manipulation, which can have unintended

! consequences.

Default networks flagged in outgoing updates

Default networks accepted from incoming updates

EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0

EIGRP maximum hopcount 100

! These two lines show configuration options that must match throughout

! the EIGRP AS 1 domain for correct EIGRP operation.

EIGRP maximum metric variance 1

Redistributing: eigrp 1

! Provides details of redistribution, including less obvious sources

! of redistribution such as connected and static routes.

EIGRP NSF-aware route hold timer is 240s

Automatic network summarization is not in effect

Maximum path: 4

Routing for Networks:

172.31.0.0

! The list of networks being advertised can provide clues to routing

! problems.

Routing Information Sources:

Gateway Distance Last Update

172.31.14.2 90 2d18h

Distance: internal 90 external 170

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 687

! Administrative distances are shown. In most cases these should

! match from router to router within a routing domain. Watch for

! non-default AD settings.

Routing Protocol is "ospf 1"

! Note the process ID.

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Router ID 150.1.1.1

It is an area border router

Number of areas in this router is 2. 2 normal 0 stub 0 nssa

Details of areas and area types, as well as the router's role (ABR).

Maximum path: 4

Routing for Networks:

144.222.100.0 0.0.0.255 area 0

144.254.254.0 0.0.0.255 area 0

150.1.1.0 0.0.0.255 area 1

Routing Information Sources:

Gateway Distance Last Update

150.1.3.129 110 2d20h

150.1.1.1 110 2d20h

Distance: (default is 110)

Routing Protocol is "bgp 200"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

IGP synchronization is disabled

Automatic route summarization is disabled

! These two lines show important information about fundamentals of BGP

! configuration.

Neighbor(s):

Address FiltIn FiltOut DistIn DistOut Weight RouteMap

172.31.14.2

Maximum path: 1

Routing Information Sources:

Gateway Distance Last Update

Distance: external 20 internal 200 local 200

Next, consider what interface statistics from a router can point toward the source of trou-

ble in Layer 3 protocols. Example 11-13 shows settings and statistics on a serial interface,

with comments as in the previous example. In this example, we show two interface show

commands ( show interfaces and show ip interface ) for the same interface, to illustrate

the differences between them and the significance of a small difference in a command.

Example 11-14 examines the differences between these commands on an Ethernet inter-

face to show the difference between serial Frame Relay interfaces and Ethernet interfaces.

ptg13046388

688 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Example 11-13 show interfaces and show ip interface Commands

RDXC# show interfaces s0/0.4

Serial0/0.4 is up, line protocol is up

Hardware is PowerQUICC Serial

Internet address is 172.31.14.1/30

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

! Reliability shows that the link is not experiencing any receive errors.

! Remember to check the other end of the link, because this parameter

! shows only inbound errors.

! The txload and rxload parameters indicate that the link is not near its

! load limits in either direction.

Encapsulation FRAME-RELAY

Last clearing of "show interface" counters never

RDXC# sh ip int s0/0.4

Serial0/0.4 is up, line protocol is up

Internet address is 172.31.14.1/30

Broadcast address is 255.255.255.255

Address determined by non-volatile memory

MTU is 1500 bytes

! MTU configuration can affect protocol operation.

Helper address is not set

Directed broadcast forwarding is disabled

Multicast reserved groups joined: 224.0.0.10

! Multicast is enabled and operating on the interface.

Outgoing access list is not set

Inbound access list is not set

Proxy ARP is enabled

Local Proxy ARP is disabled

! Proxy ARP configuration affects protocol operation through an

! interface.

Security level is default

Split horizon is enabled

! Split horizon affects distance-vector routing protocol operation.

ICMP redirects are always sent

ICMP unreachables are always sent

ICMP mask replies are never sent

IP fast switching is enabled

IP fast switching on the same interface is enabled

IP Flow switching is disabled

IP CEF switching is disabled

IP Fast switching turbo vector

IP multicast fast switching is enabled

IP multicast distributed fast switching is disabled

IP route-cache flags are Fast

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 689

Router Discovery is disabled

IP output packet accounting is disabled

IP access violation accounting is disabled

TCP/IP header compression is disabled

RTP/IP header compression is disabled

Policy routing is disabled

Network address translation is disabled

! NAT can adversely affect many protocols if the appropriate exceptions

! aren't made.

WCCP Redirect outbound is disabled

WCCP Redirect inbound is disabled

WCCP Redirect exclude is disabled

BGP Policy Mapping is disabled

Along the same lines as Example 11-13 , Example 11-14 shows the same show commands

on an Ethernet interface with the appropriate annotations.

Example 11-14 show interfaces and show ip interface Commands on Fast Ethernet

R9# show interfaces fa0/0

FastEthernet0/0 is up, line protocol is up

Hardware is PQUICC_FEC, address is 000b.be90.5907 (bia 000b.be90.5907)

Internet address is 204.12.1.9/24

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

! Key interface settings and statistics. See Example 11-13 for more details.

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

! Details of speed and duplex settings, which must be configured

! appropriately or unexpected consequences will develop.

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:11, output 00:00:08, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

! The queuing stats include drops, which can cause L3 protocol problems.

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

992849 packets input, 114701010 bytes

Received 992541 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

! On a healthy Ethernet interface, this is what you should see. A large

! number for any of these metrics usually indicates a Layer 1 problem

! or a Layer 2 configuration issue such as a duplex mismatch.

0 watchdog

ptg13046388

690 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

0 input packets with dribble condition detected

785572 packets output, 89170479 bytes, 0 underruns

3 output errors, 0 collisions, 3 interface resets

2 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

3 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

! Depending on how many input and output packets the interface

! shows, and when the interface timers were last reset, the stats

! shown on these lines can indicate Layer 1 or Layer 2 problems.

R9# show ip interface fa0/0

FastEthernet0/0 is up, line protocol is up

Internet address is 204.12.1.9/24

Broadcast address is 255.255.255.255

Address determined by setup command

MTU is 1500 bytes

! Remaining output is omitted because it duplicates that in

! Example 11-13 from this point onward

Among the other useful troubleshooting commands in diagnosing Layer 3 problems are

the following:

■ show ip nat translations

■ show ip access-list

■ show ip interface brief

■ show dampening

■ show logging

■ show policy-map

■ traceroute

■ ping (and extended ping )

■ show route-map

■ show standby

■ show vrrp

■ show track

■ show ip route prefix

In your use of show commands, don’t overlook the amount of information available in

the show ip route command and its more detailed variant, show ip route prefix . For

example, you can use the show ip route 172.31.14.0 command to learn detailed informa-

tion about the 172.31.14.0 network, including its next hop and other pertinent informa-

tion. Example 11-15 shows a sample of that output.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 691

Example 11-15 Displaying Detailed Information for a Prefix

Routing entry for 172.31.14.0/30

Known via "eigrp 1", distance 90, metric 1024000, type internal

Redistributing via eigrp 1

Last update from 172.31.24.1 on Serial0/0.4, 01:23:40 ago

Routing Descriptor Blocks:

* 172.31.24.1, from 172.31.24.1, 01:23:40 ago, via Serial0/0.4

Route metric is 1024000, traffic share count is 1

Total delay is 40000 microseconds, minimum bandwidth is 64 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

Note the details that this command provides for an individual prefix in the routing table

under the Routing Descriptor Blocks. The same command for an OSPF route includes

information on key items such as the type of route (that is, inter-area or intra-area) that

can be helpful in troubleshooting.

Another command that yields considerable detail is the extended ping command.

Example 11-16 shows the variety of configuration options it provides. Of particular note

is this command’s ability to test using multiple protocols including IPv4 and IPv6, to

sweep a range of packet sizes to test for MTU-related issues, to permit testing with vari-

ous ToS values in the packet headers, and to specify the source interface to help deter-

mine the source of routing issues.

Example 11-16 Using the Extended ping Command

R8# ping

Protocol [ip]:

Target IP address: 192.10.1.8

Repeat count [5]: 100

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: fastethernet0/0

Type of service [0]: 3

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]: y

Sweep min size [36]:

Sweep max size [18024]:

Sweep interval [1]:

Type escape sequence to abort.

Sending 1798900, [36..18024]-byte ICMP Echos to 192.10.1.8, timeout is 2 seconds:

Packet sent with a source address of 192.10.1.8

ptg13046388

692 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[output omitted]

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (3565/3565), round-trip min/avg/max = 1/4/76 ms

The idea of using the ping utility is to see whether the path to a destination prefix is

operational, and thanks to the echo reply mechanism, we know that both the send and

receive paths are okay. However, if there are problems, ping cannot be used to find where

the problems might exist in the infrastructure; for that, we need to rely on the traceroute

utility.

If you execute the traceroute command on a route, that device will send IP packets

toward the destination with a Time To Live (TTL) value that will increment up to the

defined maximum specified hop count. This is 30 by default. Typically, each router in the

path toward the destination decrements the TTL field by 1 unit while it forwards these

packets. When a router in the middle of the path finds a packet with TTL = 1, it responds

with an Internet Control Message Protocol (ICMP) “time exceeded” message to the

source. This message lets the source know that the packet traversed that particular router

as a hop.

The TTL for the initial User Datagram Protocol (UDP) datagram probe is set to 1 in the

basic traceroute utility. The destination UDP port of the initial datagram probe is set to

33434 by default. The source UDP port of the initial datagram probe is randomized and

has logical operator OR with 0x8000 (ensures a minimum source port of 0x8000). These

steps illustrate what happens when the UDP datagram is launched:

Step 1. The UDP datagram is sent with TTL = 1, destination UDP port = 33434, and

the source port randomized.

Step 2. The UDP destination port is incremented, the source UDP port is random-

ized, and the second datagram is dispatched. (This process is repeated for up

to three probes. For each of the probes sent, a “TTL exceeded” message is

received, which is used to build a step-by-step path to the destination host.)

The TTL is incremented, and this cycle repeats with incremental destination port numbers

if the ICMP “time exceeded” message is received. You can also get one of these mes-

sages:

■ An ICMP type 3, code 3 (“destination unreachable,” “port unreachable”) message,

which indicates that a host has been reached

■ A “host unreachable,” “net unreachable,” “maximum TTL exceeded,” or “timeout”

type of message, which means that the probe is resent

Cisco routers send UDP probe packets with a random source port and an incremental

destination port (to distinguish the different probes). Cisco routers send the ICMP mes-

sage “time exceeded” back to the source from where the UDP/ICMP packet was received.

We can see how to employ the extended version of traceroute in Example 11-17 .

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 693

Example 11-17 Using the Extended traceroute Command

Router A> enable

Router A# traceroute

Protocol [ip]:

Target IP address: 192.168.40.2

Source address: 172.16.23.2

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 192.168.40.2

1 172.31.20.2 16 msec 16 msec 16 msec

2 172.20.10.2 28 msec 28 msec 32 msec

3 192.168.40.2 32 msec 28 msec *

The extended traceroute command can be used to see what path packets take to get to

a destination. The command can also be used to check routing at the same time. This is

helpful for when you troubleshoot routing loops, or for when you determine where pack-

ets are getting lost. You can use the extended ping command to determine the type of

connectivity problem, and then use the extended traceroute command to narrow down

where the problem occurs.

A “time exceeded” error message indicates that an intermediate communication server

has seen and discarded the packet. A “destination unreachable” error message indicates

that the destination node has received the probe and discarded it because it could not

deliver the packet. If the timer goes off before a response comes in, traceroute prints

an asterisk (*). The command terminates when any of these happens, the destination

responds, the maximum TTL is exceeded, or the user interrupts the trace with the escape

sequence. In Cisco routers, the codes for a traceroute command reply are

■ ! — success

■ * — time out

■ N — network unreachable

■ H — host unreachable

■ P — protocol unreachable

■ A — admin denied

■ Q — source quench received (congestion)

■ ? — unknown (any other ICMP message)

ptg13046388

694 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

These commands make it easier for us to actually interpret the results of our traceroute

test and should not be overlooked when learning how to use this utility.

Perhaps the most powerful Cisco IOS troubleshooting tools are the array of debug com-

mands that Cisco provides. The most appropriate debug command for tracking down

Layer 3 problems is debug ip routing , which reveals a great deal about the Layer 3 envi-

ronment. Although this command might be of limited help in the qualification exam,

understanding what it can provide in the way of information is especially helpful for lab

exam preparation, where you will use this command and its IPv6 sibling, debug ipv6

routing , extensively. Example 11-18 shows some debug ip routing output to show the

information it provides.

Example 11-18 Output from the debug ip routing Command

R2# debug ip routing

R2#

May 25 22:03:03.664: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.24.1

(Serial0/0.4) is down: peer restarted

! An EIGRP neighbor in AS 1 went down because it was restarted.

May 25 22:03:03.664: RT: delete route to 172.31.14.0 via 172.31.24.1, eigrp metric

[90/1024000]

May 25 22:03:03.664: RT: no routes to 172.31.14.0

May 25 22:03:03.664: RT: NET-RED 172.31.14.0/30

May 25 22:03:03.668: RT: NET-RED queued, Queue size 1

May 25 22:03:03.668: RT: delete subnet route to 172.31.14.0/30

! The route to 172.31.14.0 was removed from the routing table.

May 25 22:03:03.668: RT: NET-RED 172.31.14.0/30

May 25 22:03:03.668: RT: NET-RED queued, Queue size 2

May 25 22:03:03.672: destroy peer: 172.31.24.1

May 25 22:03:05.071: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.31.24.1

(Serial0/0.4) is up: new adjacency

! The EIGRP neighbor came back up.

May 25 22:03:05.668: RT: add 172.31.14.0/30 via 172.31.24.1, eigrp metric

[90/1024000]

May 25 22:03:05.668: RT: NET-RED 172.31.14.0/30

! The route to 172.31.14.0 was restored to the routing table.

May 25 22:03:05.668: RT: NET-RED queued, Queue size 1

Not shown in this example, but particularly helpful, is what happens if a route or a set of

routes is flapping because of a loop. You’ll see a consistent set of learn/withdraw mes-

sages from each routing source, usually quite evenly timed, indicating the loop’s pres-

ence. The ping and traceroute commands are usually your first clue to a loop.

If you need to dig really deep into a particular issue, you can use the debug ip packet

detail acl command to filter the IP packet debugging function through an access list.

Create an access list that filters all but the specific information you’re seeking; otherwise,

you’ll get so much information that it’s difficult, at best, to interpret. At worst, it can

cause the router to hang or reboot.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 695

Approaches to Resolving Layer 3 Issues

In this final section of the chapter, we present a table with several generalized types of

issues and ways of approaching them, including the relevant Cisco IOS commands. Table

11-11 summarizes these techniques.

Table 11-11 Troubleshooting Approach and Commands

Problem Approach Helpful IOS

Commands

Intermittent reachability to

a subnet.

Use ping to gather information.

Verify that the route(s) exist in the

routing tables. Find where the routing

information stops or becomes unstable.

Eliminate Layer 1 issues with show

interface commands.

Use traceroute to verify the path.

show interface

show ip interface

ping

traceroute

show ip route prefix

debug ip routing

Redistributed routes do not

make it to all the desired

routers.

Verify the maximum number of hops

(EIGRP) configured using the metric

hopcount x EIGRP subcommand.

Check split horizon configuration in a

multipoint network.

show ip protocols

show ip route

show ip interface

A router does not

appear to be advertising

prefixes that it should be

configured to advertise.

Verify configuration using show ip

protocols .

Verify summarization.

Check metrics and administrative

distance.

Check interface filters.

Check route maps.

Check for split-horizon issues.

show ip protocols

show ip interface

show ip route

show ip route prefix

show route-map

ptg13046388

696 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Foundation Summary

This section lists additional details and facts to round out the coverage of the topics in

this chapter. Unlike most of the Cisco Press Exam Certification Guides, this “Foundation

Summary” does not repeat information presented in the “Foundation Topics” section of

the chapter. Please take the time to read and study the details in the “Foundation Topics”

section of the chapter, as well as review items noted with a Key Topic icon.

Table 11-12 lists some of the most relevant Cisco IOS commands related to the topics in

this chapter. Also refer to Tables 11-2 and 11-3 for the match and set commands.

Table 11-12 Command Reference for Chapter 11

Command Command Mode and Description

redistribute protocol [ process-id ] { level-

1 | level-1-2 | level-2 } [ as-number ] [ metric

metric-value ] [ metric-type type-value ]

[ match { internal | external 1 | external

2 }] [ tag tag-value ] [ route-map map-tag ]

[ subnets ]

Router config mode; defines the routing

protocol from which to take routes, several

matching parameters, and several things that

can be marked on the redistributed routes.

ip prefix-list list-name [ seq seq-value ] { deny

network/length | permit network/length }

[ ge ge-value ] [ le le-value ]

Global config mode; defines members of a

prefix list that match a prefix (subnet) and

prefix length (subnet mask).

ip prefix-list list-name sequence-number

description text

Global config; sets a description to a line in a

prefix list.

distance value { ip-address { wildcard-mask }}

[ ip-standard-list ] [ ip-extended-list ]

Router config mode; identifies the route

source, and an optional ACL to define a

subnet of routes, for which this router’s AD

is changed. Influences the selection of routes

by selectively overriding the default AD.

distance eigrp internal-distance external-

distance

EIGRP config; sets the AD for all internal and

external routes.

distance ospf {[ intra-area dist1 ] [ inter-area

dist2 ] [ external dist3 ]}

OSPF config; sets the AD for all intra-area,

inter-area, and external routes.

ip summary-address eigrp as-number

network-address subnet-mask [ admin-

distance ]

Interface mode; configures an EIGRP route

summary.

ip summary-address rip ip-address

ip-network-mask

Interface mode; configures a RIP route

summary.

area area-id range ip-address mask

[ advertise | not-advertise ] [ cost cost ]

OSPF mode; configures an OSPF summary

between areas.

summary-address {{ ip-address mask } |

{ prefix mask }} [ not-advertise ] [ tag tag ]

OSPF mode; configures an OSPF summary

of external routes.

ptg13046388

Chapter 11: IGP Route Redistribution, Route Summarization, Default Routing, and Troubleshooting 697

Command Command Mode and Description

ip default-network network-number Global config; sets a network from which to

derive default routes.

default-information originate [ route-map

map-name ]

IS-IS config; tells IS-IS to advertise a default

route if it is in the routing table.

default-information originate [ always ]

[ metric metric-value ] [ metric-type type-

value ] [ route-map map-name ]

OSPF config; tells OSPF to advertise a

default route, either if it is in the routing

table or always.

ip route prefix mask { ip-address | interface-

type interface-number [ ip-address ]}

[ distance ] [ name ] [ permanent ] [ tag tag ]

Global config; used to create static IP routes,

including static routes to 0.0.0.0 0.0.0.0, which

denotes a default route.

debug ip routing Enables displaying output of all IPv4 routing

table events for troubleshooting purposes.

debug ipv6 routing Enables displaying output of all IPv6 routing

table events for troubleshooting purposes.

debug Provides many protocol-specific debug

functions for indicating routing protocol

events (such as debug ip ospf neighbor

events, as one example).

ping Allows extended testing of reachability using

packets of different sizes, ToS values, and

other variables for testing reachability issues,

with a specified source interface for testing

routing-related reachability issues.

traceroute Similar to the extended ping command,

provides extended traceroute capability.

show ip route [ prefix ] Provides specific routing information for

individual IPv4 prefixes present in the

routing table.

pfr Enables a PfR process and configures a

router as a PfR border router or as a PfR

Master Controller.

show pfr border defined Displays all applications that are defined to

be monitored by a PfR border router.

show pfr master defined Displays all applications that are defined on a

PfR Master Controller.

show pfr master nbar application Displays information about the status of an

application identified using Network-Based

Application Recognition (NBAR) for each

PfR border router.

ptg13046388

698 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Memory Builders

The CCIE Routing and Switching written exam, like all Cisco CCIE written exams, covers

a fairly broad set of topics. This section provides some basic tools to help you exercise

your memory about some of the broader topics covered in this chapter.

Fill In Key Tables from Memory

Appendix E , “Key Tables for CCIE Study,” on the CD in the back of this book, contains

empty sets of some of the key summary tables in each chapter. Print Appendix E , refer

to this chapter’s tables in it, and fill in the tables from memory. Refer to Appendix F ,

“Solutions for Key Tables for CCIE Study,” on the CD to check your answers.

Definitions

Next, take a few moments to write down the definitions for the following terms:

default route, route redistribution, external route, aggregate route, route map, IP pre-

fix list, summary route, component route, gateway of last resort

Refer to the glossary to check your answers.

Further Reading

Routing TCP/IP , Volume I, Second Edition, by Jeff Doyle and Jennifer DeHaven Carroll

CCIE Practical Studies , Volume II, by Karl Solie and Leah Lynch

“Troubleshooting IP Routing Protocols,” www.ciscopress.com/bookstore/

product.asp?isbn=1587050196

ptg13046388

This page intentionally left blank

ptg13046388

The first 11 chapters of this book cover the portion of

technologies, protocols, and considerations required

to be prepared to pass the 400-101 CCIE Routing and

Switching written exam. While these chapters supply the

detailed information, most people need more preparation

than simply reading the first 11 chapters of this book.

This chapter details a set of tools and a study plan to

help you complete your preparation for the exams.

This short chapter has two main sections. The first sec-

tion lists the exam preparation tools useful at this point

in the study process. The second section lists a suggested

study plan now that you have completed all the earlier

chapters in this book.

Note Appendix E, “Key Tables for CCIE Study,” and

Appendix F, “Solutions for Key Tables for CCIE Study,”

exist as soft-copy appendices on the CD included in the

back of this book.

ptg13046388

Tools for Final Preparation

This section lists some information about the available tools and how to access the tools.

Pearson Cert Practice Test Engine and Questions on the CD

The CD in the back of the book includes the Pearson Cert Practice Test engine—soft-

ware that displays and grades a set of exam-realistic multiple-choice questions. Using the

Pearson Cert Practice Test engine, you can either study by going through the questions in

Study Mode, or take a simulated (timed) CCIE Routing and Switching Written Exam.

The installation process requires two major steps. The CD in the back of this book has a

recent copy of the Pearson Cert Practice Test engine. The practice exam—the database

of CCIE Routing and Switching exam questions—is not on the CD.

Note The cardboard CD case in the back of this book includes the CD and a piece of

paper. The paper lists the activation key for the practice exam associated with this book.

Do not lose the activation key.

Install the Software from the CD

The software installation process is pretty routine as compared with other software

installation processes. To be complete, the following steps outline the installation pro-

cess:

Step 1. Insert the CD into your PC.

Step 2. The software that automatically runs is the Cisco Press software to access and

use all CD-based features, including the exam engine and the CD-only appen-

dices. From the main menu, click the option to Install the Exam Engine .

Step 3. Respond to Windows prompts as with any typical software installation process.

CHAPTER 12

Final Preparation

ptg13046388

702 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The installation process will give you the option to activate your exam with the activation

code supplied on the paper in the CD sleeve. This process requires that you establish a

Pearson website login. You will need this login to activate the exam, so please do register

when prompted. If you already have a Pearson website login, there is no need to register

again. Just use your existing login.

Activate and Download the Practice Exam

After the exam engine is installed, you should then activate the exam associated with this

book (if you did not do so during the installation process) as follows:

Step 1. Start the Pearson Cert Practice Test (PCPT) software from the Windows Start

menu or from your desktop shortcut icon.

Step 2. To activate and download the exam associated with this book, from the My

Products or Tool s tab, click the Activate button.

Step 3. At the next screen, enter the activation key from the paper inside the card-

board CD holder in the back of the book. After it is entered, click the

Activate button.

Step 4. The activation process will download the practice exam. Click Next , and then

click Finish.

After the activation process is completed, the My Products tab should list your new

exam. If you do not see the exam, make sure that you have selected the My Products

tab on the menu. At this point, the software and practice exam are ready to use. Simply

select the exam and click the Use button.

To update a particular exam that you have already activated and downloaded, simply

select the To ol s tab and click the Update Products button. Updating your exams will

ensure that you have the latest changes and updates to the exam data.

If you want to check for updates to the Pearson Cert Practice Test exam engine software,

simply select the To ol s tab and click the Update Application button. This will ensure that

you are running the latest version of the software engine.

Activating Other Exams

The exam software installation process, and the registration process, only has to happen

once. Then, for each new exam, only a few steps are required. For example, if you buy

another new Cisco Press Official Cert Guide or Pearson IT Certification Cert Guide,

extract the activation code from the CD sleeve in the back of that book—you don’t even

need the CD at this point. From there, all you have to do is start the exam engine (if not

still up and running), and perform Steps 2 through 4 from the previous list.

ptg13046388

Chapter 12: Final Preparation 703

Premium Edition

In addition to the free practice exam provided on the CD-ROM, you can purchase addi-

tional exams with expanded functionality directly from Pearson IT Certification. The

Premium Edition of this title contains an additional two full practice exams as well as an

eBook (in both PDF and ePub format). In addition, the Premium Edition title also has

remediation for each question to the specific part of the eBook that relates to that

question.

Because you have purchased the print version of this title, you can purchase the Premium

Edition at a deep discount. There is a coupon code in the CD sleeve that contains a one-

time use code as well as instructions for where you can purchase the Premium Edition.

To view the Premium Edition product page, go to www.informit.com/title/

9780133481648 .

The Cisco Learning Network

Cisco provides a wide variety of CCIE Routing and Switching preparation tools at a

Cisco Systems website called the Cisco Learning Network. This site includes a large vari-

ety of exam preparation tools, including sample questions, forums on each Cisco exam,

learning video games, and information about each exam.

To reach the Cisco Learning Network, go to www.cisco.com/go/learningnetwork , or just

search for “Cisco Learning Network.” You will need to use the login that you created at

www.cisco.com . If you don’t have such a login, you can register for free. To register, sim-

ply go to www.cisco.com , click Register at the top of the page, and supply the requested

information.

Memory Tables

Like most Official Cert Guides from Cisco Press, this book purposefully organizes infor-

mation into tables and lists for easier study and review. Rereading these tables can be very

useful before the exam. However, it is easy to skim over the tables without paying atten-

tion to every detail, especially when you remember having seen the table’s contents when

reading the chapter.

Instead of simply reading the tables in the various chapters, this book’s Appendices E and

F give you another review tool. Appendix E lists partially completed versions of many of

the tables from the book. You can open Appendix F (a PDF on the CD that comes with

this book) and print the appendix. For review, you can attempt to complete the tables.

This exercise can help you focus on the review. It also exercises the memory connectors

in your brain; plus it makes you think about the information without as much informa-

tion, which forces a little more contemplation about the facts.

Appendix F , also a PDF located on the CD, lists the completed tables to check yourself.

You can also just refer to the tables as printed in the book.

ptg13046388

704 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter-Ending Review Tools

Chapters 1 – 11 have several features in the “Foundation Summary” sections at the end of

the chapter. You might have already worked through these in each chapter. It can also be

useful to use these tools again as you make your final preparations for the exam.

Suggested Plan for Final Review/Study

This section lists a suggested study plan from the point at which you finish reading the

last chapter of Volume 2 of this book, until you take the 400-101 CCIE Routing and

Switching written exam. Certainly, you can ignore this plan, use it as is, or just take sug-

gestions from it.

The plan uses three steps:

Step 1. Review Key Topics and DIKTA Questions: You can use the table that lists

the key topics in each chapter, or just flip through the pages looking for key

topics. Also, reviewing the “Do I Know This Already?” (DIKTA) questions

from the beginning of the chapter can be helpful for review.

Step 2. Complete Memory Tables: Open Appendix E on the CD and print the entire

appendix, or print the tables by major part. Then complete the tables.

Step 3. Use the Pearson Cert Practice Test Engine to Practice: The Pearson Cert

Practice Test engine on the CD can be used to study using a bank of unique

exam-realistic questions available only with this book.

Using the Exam Engine

The Pearson Cert Practice Test engine on the CD includes a database of questions cre-

ated specifically for this book. The Pearson Cert Practice Test engine can be used either

in study mode or practice exam mode, as follows:

■ Study mode: Study mode is most useful when you want to use the questions for

learning and practicing. In study mode, you can select options like randomizing the

order of the questions and answers, automatically viewing answers to the questions

as you go, testing on specific topics, and many other options.

■ Practice Exam mode: This mode presents questions in a timed environment, provid-

ing you with a more exam-realistic experience. It also restricts your ability to see

your score as you progress through the exam and view answers to questions as you

are taking the exam. These timed exams not only allow you to study for the actual

400-101 CCIE Routing and Switching written exam, but they also help you simulate

the time pressure that can occur on the actual exam.

When doing your final preparation, you can use study mode, practice exam mode, or

both. However, after you have seen each question a couple of times, you will likely start

to remember the questions, and the usefulness of the exam database might go down. So,

consider the following options when using the exam engine:

ptg13046388

Chapter 12: Final Preparation 705

■ Use this question database for review. Use study mode to study the questions by

chapter, just as with the other final review steps listed in this chapter. Plan on getting

another exam (possibly from the Premium Edition) if you want to take additional

simulated exams.

■ Save the question database, not using it for review during your review of each book

part. Save it until the end so that you will not have seen the questions before. Then,

use practice exam mode to simulate the exam.

Picking the correct mode from the exam engine’s user interface is pretty obvious. The

following steps show how to move to the screen from which to select study or practice

exam mode:

Step 1. Click the My Products tab if you are not already in that screen.

Step 2. Select the exam that you want to use from the list of available exams.

Step 3. Click the Use button.

When you take these actions, the engine should display a window from which you can

choose Study Mode or Practice Exam Mode . When in study mode, you can further

choose the book chapters, limiting the questions to those explained in the specified

chapters of the book.

Summary

The tools and suggestions listed in this chapter have been designed with one goal in

mind: to help you develop the skills required to pass the 400-101 CCIE Routing and

Switching written exam. This book has been developed from the beginning to not just

tell you the facts but also to help you learn how to apply the facts. No matter what your

experience level leading up to taking the exams, it is our hope that the broad range of

preparation tools, and even the structure of the book, will help you pass the exam with

ease. We hope you do well on the exam.

ptg13046388

This page intentionally left blank

ptg13046388

Chapter 1

1. C and E

2. A

3. D

4. B and C

5. B and C

6. B

7. A, B, and D

8. C

9. C

10. D

11. C

12. D

Chapter 2

1. A and D

2. A and B

3. C

4. B

5. A

6. A

7. A and B

8. A, B, and C

9. A, C, and D

10. C

Chapter 3

1. B

2. C

3. A and C

4. B and C

5. C

6. D

7. C, D, and F

8. E

9. A, B, and C

10. C

11. D

Chapter 4

1. D

2. C

3. D

4. A and D

5. A

6. C and D

7. B

8. A and B

9. B

10. C

11. A

APPENDIX A

Answers to the “Do I Know This

Already?” Quizzes

ptg13046388

708 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 5

1. C and D

2. A and E

3. B and D

4. D

5. D

6. D

7. B and D

8. A, C, and D

9. C

10. A

11. A

12. A, B, C, and D

13. E

14. A

15. B

Chapter 6

1. C

2. C

3. B

4. C, D, and E

5. B and D

6. A

7. E

8. E

9. C

10. C

11. A and C

Chapter 7

1. A, B, and C

2. A

3. B and C

4. A

5. A and E

6. A, B, D, and E

7. B and D

Chapter 8

1. C and D

2. A, C, E, and H

3. B, D, F, and G

4. D

5. A, C, and D

6. A, B, C, D, and G

7. C, D, E, F, and G

8. A, C, and D

9. C and E

10. C, D, E, F, and G

11. A, B, C, D, E, F, and G

12. A

13. B

14. C

15. B

16. B

17. A

18. A

19. B, C, D, and F

20. B, C, and E

21. B

22. D

ptg13046388

Appendix A: Answers to the “Do I Know This Already?” Quizzes 709

23. B

24. C

25. B, D, and E

26. C, D, and F

27. C and E

28. A and C

29. B, D, and F

30. A, B, and C

31. B and C

Chapter 9

1. B and C

2. A and C

3. C

4. B and D

5. A

6. C and D

7. A and B

8. B

9. B and D

10. A and E

11. C and F

12. A

13. A, D, and E

14. B, C, and D

15. C and E

16. B, E, and F

Chapter 10

1. D

2. C

3. B

4. G

5. B

6. C

7. D

8. A

9. A

10. A, D, F, G, and H

11. D

12. D

13. B, D, and E

14. B

15. C and D

16. A, B, and F

17. D

18. A, C, and D

19. A

20. C

21. B

22. A and D

23. A, B, and D

24. B

25. C, E, and G

26. A and D

27. B, D, and H

28. C and E

29. D

30. A, B, and C

31. B

32. B and C

33. A and B

ptg13046388

710 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 11

1. A and D

2. C and D

3. A

4. A and B

5. C

6. A

7. D

8. A and C

9. B, D, and E

10. D

11. D

12. B

ptg13046388

This page intentionally left blank

ptg13046388

This page intentionally left blank

ptg13046388

Over time, reader feedback enables Cisco Press to gauge which topics give our readers

the most problems when taking the exams. Additionally, Cisco might make small changes

in the breadth of exam topics or in the emphasis of certain topics. To assist readers with

those topics, the author creates new materials clarifying and expanding upon those trou-

blesome exam topics.

The document you are viewing is Version 1.0 of this appendix and there are no updates.

You can check for an updated version at www.ciscopress.com/title/9781587143960 .

APPENDIX B

CCIE Exam Updates

ptg13046388

Index

Numerics

2-Way state, OSPF routers, 463

802.1d STP. See STP (Spanning Tree

Protocol)

802.1Q trunking, 69-70

configuring, 71-75

802.1Q-in-Q tunneling, 79-83

802.1s. See MST (Multiple Spanning

Trees)

802.1w RSTP. See RSTP (Rapid STP)

ABRs (Area Border Routers), 480

best path selection, 502-505

access ports, protecting

BPDU Filter, 150-151

BPDU Guard, 149-150

accessing Cisco IOS routers and

switches

HTTPS access, implementing,

257-258

SSH access, implementing, 258

Telnet access, implementing, 258

ACK packets (EIGRP), 372-373

Acknowledgment field, EIGRP pack-

ets, 369

Active state (EIGRP), 381

active switches (VSS), 30

active VLANs, 76

Add-Path support (EIGRP), 421-423

Address Family configuration mode,

414-415

address family support, OSPFv3,

548-551

addresses, Ethernet, 15-18

format, 17-18

most significant byte, 17

adjacencies, IS-IS, 578-579, 587

Adjacency State TLV, 589-591

adjusting

administrative distance (EIGRP), 360

EIGRP hop-count limitations, 359

administrative distance, 644

EIGRP, adjusting, 360

preventing suboptimal routes,

656-659

advertising default routes, 665-672

using default-information originate

command, 669

using ip default-network command,

670-671

using redistribute static command,

667-668

AFI (Authority and Format Identifier),

573-574

AFT (Address Family Translation),

220

agents (SNMP), 244

AH (Authentication Header), 546

alarms (RMON), 255

allowed VLANs, 76

Alternate Ports (RSTP), 130

anycast addresses, 216

ptg13046388

architecture, CEF, 275-276

areas

ABRs, best path selection, 502-505

IS-IS

inter-area routing, 598-600

intra-area routing, 599

stubby areas, 496-501

configuring, 498-501

NSSAs, 498-499

ARP (Address Resolution Protocol),

232-233

ASBRs (Autonomous System

Boundary Routers), 481

ATT flag (LSPs), 602-603

Attempt state, OSPF routers, 463

authentication

EIGRP, 356, 432-435

IS-IS, 608-610

key chains, 337

OSPF

configuring, 517-520

SHA-HMAC, configuring,

520-522

on virtual links, configuring,

520

OSPFv3, 546-547

PfR, 674-675

RIPng, 340

RIPv2, configuring, 337

SNMP, 245

automatic route summarization, 428

autonegotiation (Ethernet), 9

autosummarization, 335-337

AVG (Active Virtual Gateway), 239

bandwidth metric component, 361

basic configuration, SPAN, 26

BDRs (backup DRs), 469

best path selection, 317

OSPF, 502-505

BGP (Border Gateway Protocol), 317

binary shortcuts

exclusive summary routes, finding,

204-205

finding all subnets of a network,

196-198

inclusive summary routes, finding,

202-203

bitwise Boolean ANDs, 193

Blocking state (STP), 107

transitioning to Forwarding state, 119

BOOTP (Bootstrap Protocol),

233-234

comparing with DHCP and RARP,

236

border routers (PfR), 676-677

configuring, 681-683

BPDU Filter, 150-151

BPDU Guard, 149-150

ptg13046388

716 BPDUs (Bridge Protocol Data Units)

BPDUs (Bridge Protocol Data Units),

107-109

Configuration BPDUs, 108

Dispute mechanism, 154

format, 107

priorities, 108

RBID, 109

RSTP, 132-133

Topology Change BPDUs, 108

BRAS (Broadband Remote Access

Server), 96

Bridge Assurance, 154

broadcast address, discovering, 195-196

broadcast links, 587

IS-IS over, 592-598

DIS, election process, 592-593

IS-IS router synchronization,

593-594

pseudonodes, 594-598

broadcast MAC addresses, 15

broadcast networks, 473

broadcast subnets, 192

cabling

Category 5, 8-9

crossover, 8

straight-through, 8

calculating

composite metric, 363-364

OSPF cost, 508-509

CAM (Content Addressable Memory),

updating, 117-119

canonical bit order, 17

Category 5 wiring, 8-9

CD (Computed Distance), 386-387

CDP (Cisco Discovery Protocol), trou-

bleshooting Layer 2 issues, 163-165

CEF (Cisco Express Forwarding),

273-285

architecture, 275-276

example of, 277-281

FIB, 274

load sharing, 282-285

algorithms, 285

lookup process, 274

polarization, 284-285

RIB, 274

channel-group command, 33

channel-protocol command, 161

Checksum field, EIGRP packets, 369

CIDR (classless interdomain routing),

206-207

Cisco Catalyst switches, SPAN, 22-25

Cisco Flexible NetFlow, 250-252

configuring, 251-252

Cisco IOS Embedded Event Manager,

253-254

Cisco IOS IP SLA, 249-250

configuring, 250

Cisco Learning Network, 703

Cisco switch ports, configuring, 11-14

CIST (Common and Internal Spanning

Tree), 140-141

Class Metrics, 360-362

classful addressing, 189-191

classic mode (EIGRP), 410

classic OSPF authentication, configur-

ing, 517-520

classless addressing, 191

clear eigrp address-family command,

444

clear ip ospf process command,

508-509

clear ip route command, 444

clearing

IP routing table, 444

OSPF process, 507-510

CLNP (ConnectionLess-mode Network

Protocol), 572

clusters, 247

ptg13046388

configuring 717

collision domains, 10-11

collisions, CSMA/CD, 10

commands

channel-group, 33

channel-protocol, 161

clear eigrp address-family, 444

clear ip ospf process, 508-509

clear ip route, 444

debug pppoe, 98

default-information originate, 669

distance, 658-659

distribute-list, 511-513

extended ping, 691-692

extended traceroute, 693-694

ip cef, 282

ip cef load-sharing algorithm, 285

ip default-network, 670-671

ip eigrp traffic, 371-372

ip ftp, 256

ip load-share, 283

is-is circuit-type, 618

network 0.0.0.0, 436

passive-interface, 431-432

pppoe session, 98

redistribute, 645

redistribute static command, 667-668

route-map, 638-640

router isis, 616

router process, 425-426

set commands (PBR), 296-299

show clns, 620-622

show interfaces, 167-169, 688-690

show ip ospf database, 488

show ip protocols, 426-427, 686-687

show ip route isis, 617

show ip route ospf, 516-517

show ip sla monitor statistics, 250

show isis database, 601-603

show isis hostname, 581-583

show rmon alarm, 255

show rmon event, 255

show running-config, 240-241

show sdm prefer, 299

switch convert mode virtual, 33-34

tftp-server, 257

communication rules for Private VLANs,

64-65

communities (SNMP), 242

community VLANs, 61

comparing

ARP and Proxy ARP, 232

BOOTP with DHCP and RARP, 236

ISL and 802.1Q, 69

LSAs and LSPs, 584-585

OSPFv2 and OSPFv3, 533-534

complex configuration, SPAN, 26

component metrics, 360-361

bandwidth, 361

delay, 361-362

hop count, 363

influencing path selection with, 368

load, 362-363

MTU, 363

reliability, 362

component routes, 663

composite metric, calculating, 363-364

Conditional Receive, 375

Configuration BPDUs, 108-109

configuration files, copying with FTP,

256

configuring

802.1Q trunking, 71-75

Cisco Flexible NetFlow, 251-252

Cisco IOS Embedded Event Manager,

254

Cisco IOS IP SLA, 250

Cisco switch ports, 11-14

DHCP, 235-236

Dynamic NAT without PAT, 212-214

ptg13046388

718 configuring

EIGRP

Add-Path feature, 422-423

authentication, 432-435

named mode, 410-417

OTP, 439-442

route summarization, 430-431

ERSPAN, 27-28

EtherChannel Port-channels, 157-161

HSRP, 237-238

IPv6

host addresses, 216-217

Stateless Address

Autoconfiguration, 217

IS-IS, 613-624

authentication, 608-610

ISL, 71-75

MLS, 291-295

MST, 144-148

NTP, 240-241

OSPF, 505-507

authentication, 517-520

incremental SPF, 527-528

LSA Throttling, 526-527

SPF Throttling, 524-525

stubby areas, 498-501

virtual links, 515-517

OSPFv3, 537-545

over Frame Relay, 537

PAT (Port Address Translation), 212-214

PfR (Performance Routing), 677

border routers, 681-683

MC, 677-681

PPPoE, 96-98

Private VLANs, 67-68

RIPng, 340-341

RIPv2, 334-339

authentication, 337

RMON, 255

route maps

match commands, 640-641

with route-map command,

638-640

RSPAN, 26-27

SNMP, 245

SPAN

basic configuration, 26

complex configuration, 26

STP, 124-128

stub routing, 529-530

trunking

options, 76-77

on routers, 77-79

VLANs, 51-52

in configuration mode, 56-57

interfaces, 55-56

operational states, 57-69

VSS, 31-34

VTP, 89-95

extended-range VLANs, 94

global configuration options,

90-91

normal-range VLANs, 94

storing the configuration, 94-95

WCCP, 248-249

confirming Wide Metric support,

365-366

conflicts, 88

connection-mode operation (OSI), 572

connectionless-mode operation, OSI net-

work layer, 572

content engines, WCCP, 246-249

contents of EIGRP topology table,

382-384

Control field (Ethernet), 15

control plane, 266

ptg13046388

DHCP (Dynamic Host Configuration Protocol) 719

convergence

RIPv2, 334

steady-state operation, 327-328

timers for stalled routing update

reception, 331-333

triggered updates, 328-331

STP, 115-117

copying

configuration files with FTP, 256

SCP, 257

costs

OSPF, 507-510

STP, 113

Counting to Infinity, 322

creating VLANs in VLAN database con-

figuration mode, 52-55

crossover cabling, 8

CSMA/CD (Carrier Sense Multiple

Access with Collision Detection), 10

CSNP (Complete Sequence Numbers

PDU) packets, 585-586

CST (Common Spanning Tree), 120-124

data plane, 266

database exchange, OSPF

DD packet exchange, 466-468

dead interval, 465

DRs, 469

Hello messages, 464-466

LSAs

requesting, 468-469

sequence numbers, 468

neighbor states, 462-464

RIDs, 460-461

transmitting LSA headers to neighbors,

466

DBD (Database Description) messages,

461

DD (Database Description) packet

exchange, 466-468

deactivating current IGPs, 301-303

dead interval (OSPF), 465

debug commands, troubleshooting Layer

3 issues, 694

debug pppoe command, 98

decimal shortcuts

all subnets of a network, finding,

198-200

broadcast address, finding, 195-196

inclusive summary routes, finding,

203-204

subnet number, finding, 194-196

default-information originate command,

669

default routing, 665-672

EIGRP, 435-436

using default-information originate

command, 669

using ip default-network command,

670-671

using redistribute static command,

667-668

using route summarization, 671-672

default settings for route redistribution,

646-649

delay metric component, 361-362

DES (Digital Encryption Standard), 245

designing OSPF networks, 496

ABRs, 480

ASBRs, 481

path selection, 482

Destination Service Access Point field

(Ethernet), 15

DHCP (Dynamic Host Configuration

Protocol), 233-236

configuring, 235-236

database agents, 235

ptg13046388

720 DHCPv6

DHCPv6, 217-218

diagnostic commands, IS-IS, 620-622

diffusing computation (EIGRP), 359,

392-396

Dijkstra SPF algorithm, 479

DIS (Designated IS), 579

election process, 592-593

discard routes, 429

Discarding state (RSTP), 129

displaying RID, 419-420

Dispute mechanism (BPDUs), 154

distance command, 658-659

distance-vector routing protocols,

316-317

best path selection, 317

Counting to Infinity, 322

EIGRP

ACK packets, 372-373

Add-Path support, 421-423

administrative distance, adjusting,

360

authentication, 432-435

bandwidth metric component, 361

clearing IP routing table, 444

composite metric, calculating,

363-364

default routing, 435-436

delay metric component, 361-362

diffusing computations, 359

DUAL, 359, 380-410

dynamic neighbor discovery, 376

event logging, 443

Feasibility Condition, 359

Graceful Shutdown, 432

Hello packets, 372

Hello protocol, 358

history of, 357

hop count metric component, 363

hop-count limitations, adjusting,

359

load metric component, 362-363

metrics, 360-361

neighbor table, 379

offset lists, 444

OTP, 437-442

packets, 368-374

passive interfaces, 431-432

Query packets, 374

reliability metric component, 362

Reply packets, 374

RID, 417-420

route filtering, 443-444

route summarization, 427-431,

664-665

router adjacencies, 376-379

RTP, 358, 374-376

Sequence number, 374

SIA-Query packets, 374

SIA-Reply packets, 374

Split Horizon, 436-437

stub routing, 423-427

topology table, 384-385

unequal-cost load balancing,

420-421

unreachable routes, 362

Update packets, 373

Wide Metrics, 364-368

migration strategy, 299-308

activating new IGP, 300-301

deactivating current IGPs,

301-303

verifying working database con-

tents, 301

path-vector routing protocols, 317

RIPv2, 318-320

autosummarization, 335-337

configuring, 334-339

convergence, 334

distribute lists, 338-339

features, 318

ptg13046388

EIGRP (Enhanced Interior Gateway Routing Protocol) 721

Flushed after timer, 326

Holddown timer, 324-325

Invalid timer, 324-325

loop prevention, 320-326

messages, 319-320

metrics, 320

next-hop feature, 338

offset lists, 338

prefix lists, 338-339

Route Poisoning, 323

Split Horizon, 322, 338

steady-state convergence, 327-328

timers for stalled routing update

reception, 331-333

triggered updates, 323, 328-331

distribute lists, 338-339

distribute-list command, 511-513

Down state, OSPF routers, 463

downloading practice exam, 702

DP (Designated Port), selecting,

113-115

draft-savage-eigrp, 356

DRs (designated routers)

on LANs, 469

election process, 471-472

optimizing, 470-471

on WANs, 472-474

DSCP (Differentiated Services Code

Point), 251

DSP (Domain Specific Part), 573-574

DUAL (Diffusing Update Algorithm),

359, 380-410

FSM, 397-402

SIA states, 402-410

topology table, 380-384

dual stack, 218-219

duplex settings, 9

Dynamic NAT without PAT, 210-211

configuring, 212-214

dynamic neighbor discovery (EIGRP),

376

dynamic routing, 316-318

edge routers, WCCP, 246-247

EIGRP (Enhanced Interior Gateway

Routing Protocol)

Add-Path support, 421-423

administrative distance, adjusting, 360

authentication, 356, 432-435

Class Metrics, 362

default routing, 435-436

diffusing computations, 359

DUAL, 359, 380-410

SIA states, 402-410

topology table, 380-384

dynamic neighbor discovery, 376

event logging, 443

Feasibility Condition, 359

features, 356

Graceful Shutdown, 432

Hello protocol, 358

history of, 357

hop-count limitations, adjusting, 359

IP routing table, clearing, 444

LISP, 437-438

manual route summarization, 357

metrics, 360-361

bandwidth, 361

composite metric, calculating,

363-364

delay, 361-362

hop count, 363

ptg13046388

722 EIGRP (Enhanced Interior Gateway Routing Protocol)

influencing path selection with,

368

load, 362-363

MTU, 363

reliability, 362

Wide Metrics, 364-368

named mode, 410-417

Address Family configuration

mode, 414-415

Per-AF Interface configuration

mode, 415

Per-AF Topology configuration

mode, 416-417

neighbor table, 379

offset lists, 444

open source implementation, 356

OTP, 437-442

configuring, 439-442

packets, 368-374

ACK packets, 372-373

format, 368-371

Hello packets, 372

Query packets, 374

Reply packets, 374

SIA-Query packets, 374

SIA-Reply packets, 374

TLVs, 369

Update packets, 373

passive interfaces, 431-432

RID, 417-420

displaying, 419-420

value selection, 419

route filtering, 443-444

route redistribution

into OSPF, 650

route summarization, 427-431, 664-665

automatic route summarization,

428

configuring, 430-431

discard routes, 429

manual route summarization, 428

route tags, 356

router adjacencies, 376-379

Hold time, 377

Pending state, 378

Q Cnt, 379

Up state, 378

RTP, 358, 374-376

Conditional Receive, 375

Sequence number, 374

Split Horizon, 436-437

stub routing, 423-427

Query handling, 424

topology table, 384-385

Active state, 381

CD, 386-387

contents of, 382-384

diffusing computation, 392-396

FD, 387-391

local computation, 392

Passive state, 381

RD, 386-387

show commands, 385-387

topology changes, 391-396

unequal-cost load balancing, 420-421

unreachable routes, 362

Wide Metrics

latency, 366

throughput, 366

election process

DISs, 592-593

DRs, 471-472

root switch, 110-111

Embedded Event Manager. See Cisco

IOS Embedded Event Manager

ptg13046388

external routes (OSPF) 723

enabling OSPFv3, 537-545

ERSPAN (Encapsulated Remote SPAN),

22-25

configuring, 27-28

restrictions, 24-25

traffic supported, 25

ES (End System), 571

ESP (Encapsulating Security Payload),

546

EtherChannel, 154-161

CSMA/CD, 10

LACP, 159-161

load balancing, 154-156

MEC, 31

PAgP, 159-161

Port-channels, configuring, 157-161

RJ-45 pinouts, 8-9

switching loops, 159

troubleshooting, 174-175

Ethernet, 3-2

addresses, 15-18

format, 17-18

most significant byte, 17

autonegotiation, 9

Category 5 cabling, 8-9

Cisco switch ports, configuring, 11-14

collision domains, 10-11

duplex settings, 9

framing, 14-15

Length field, 18

Type field, 18

header fields, 15

hubs, 10

PPPoE, configuring, 96-98

SNAP headers, 14

speed, 9

switches, 11

MAC address learning process,

19-22

VSS, 28-38

active and standby switches, 30

configuring, 31-34

MEC, 31

verifying, 35-38

VSL, 30

event detectors, 253

event logging

Cisco IOS Embedded Event Manager,

253-254

EIGRP, 443

Syslog, 245-246

events (RMON), 254

examples

of CEF operation, 277-281

of OSPF over NBMA networks,

474-479

of prefix lists, 643

of RITE, 252

exception dumps, sending with FTP, 256

Exchange state, OSPF routers, 463

exclusive summary routes, finding,

204-205

ExStart state, OSPF routers, 463

extended cryptographic OSPF authenti-

cation, configuring, 517-520

Extended Local Circuit IDs, 587-589

extended metrics (EIGRP), 366

extended ping command, 691-692

extended traceroute command, 693-694

extended-range VLANs, configuring, 94

external costs (MST), 140

external interfaces, 674

external routes (OSPF), 492-495

ptg13046388

724 fast switching

fast switching, 272-273

FD (Feasible Distance), 387-391

FDX (full duplex), 9

Feasibility Condition (EIGRP), 359

Feasible Successors

diffusing computation, 392-396

unequal-cost load balancing, 420-421

features

EIGRP, 356

of RIPv2, 318

of VTP, 84

FED (Forwarding Engine Driver), 40

FFM (Forwarding and Feature

Manager), 40

FIB (Forwarding Information Base), 274

fields

of EIGRP packets, 368-371

of Ethernet headers, 15

filtering OSPF

route filtering, 510-513

Type 3 LSA filtering, 513-515

finding

all subnets of a network

binary shortcut, 196-198

decimal shortcut, 198-200

broadcast address, decimal shortcut,

195-196

exclusive summary routes, binary short-

cut, 204-205

inclusive summary routes

binary shortcut, 202-203

decimal shortcut, 203-204

subnet number, decimal shortcut,

194-196

valid range of IP addresses, decimal

shortcut, 194-196

Flags field, EIGRP packets, 369

flooding

double flooding, 469

LSAs, 469

LSPs, 591-592

flow exporters (NetFlow), 251

flow monitors (NetFlow), 251

flow samplers (NetFlow), 251

Flushed after timer, 326

format

of BPDUs, 107

of EIGRP packets, 368-371

of Ethernet addresses, 17-18

of IP addresses, 192

of IPv6 addresses, 215

of NSAP addresses, 574-575

Forwarding state (STP), 119

fragmentation, 214

LSPs, 581

Frame Relay, configuring OSPFv3 over,

537

framing, Ethernet, 14-15

Length field (Ethernet), 18

Type field, 18

FSM (DUAL Finite State Machine),

397-402

FTP (File Transfer Protocol), 255-256

Full state, OSPF routers, 464

Garcia-Luna-Aceves, Dr. J. J., 390

GLBP (Gateway Load Balancing

Protocol), 239

global configuration options, VTP, 90-91

GR (Graceful Restart), 530-532

Graceful Shutdown, 432

OSPF, 532

OSPFv3, 552

ptg13046388

IP addressing 725

HDX (half duplex), 9

Hello messages (OSPF), 461, 464-466

Hello packets

EIGRP, 372

IS-IS, 579-580

authentication, 608-610

Hello protocol (EIGRP), 358

history of EIGRP, 357

HO-DSP (High-Order Domain Specific

Part), 574

Hold time, 377

Holddown timer (RIPv2), 324-325

hop count metric component, 363

hop-count limitations (EIGRP), adjust-

ing, 359

host addresses (IPv6), configuring,

216-217

HSRP (Hot Standby Router Protocol),

236-239

configuring, 237-238

MHSRP, 239

HTTPS access, implementing, 257-258

hub-and-spoke networks, stub routing,

425

hubs (Ethernet), 10

IDI (Initial Domain Identifier), 573-574

IDP (Initial Domain Part), 573

IDSs (intrusion detection systems), RITE

implementation, 252-253

IETF Internet Drafts, draft-savage-

eigrp, 356

I/G (Individual/Group) bit, 17-18

IGRP (Interior Gateway Routing

Protocol), 357

timers, 357-358

Update packets, 357-358

weaknesses of, 358

IIH (IS-IS Hello) packets

Adjacency State TLV, 589-591

authentication, 608-610

implementing

Cisco IOS IP SLA, 249-250

NetFlow, 250-252

RITE, 252-253

RMON, 254-255

inclusive summary routes, finding

binary shortcut, 202-203

decimal shortcut, 203-204

incremental SPF, 527-528

inferior BPDUs, 108

influencing route redistribution with

metrics, 661-663

Init state, OSPF routers, 463

initiating FTP transfers, 256

installing Pearson Cert Practice Test

engine, 700-702

Integrated IS-IS, 571

inter-area routing (IS-IS), 598-600

interface states (STP), 119

interface subcommands, configuring

OSPF, 518-520

interfaces, creating on VLANs, 55-56

internal interfaces, 674

internal usage VLANs, 288-290

internetworks, 191

intra-area routing (IS-IS), 599

Invalid timer (RIPv2), 324-325

IOS-XE, 38-40

IP addressing. See also IPv6

address format, 192

bitwise Boolean ANDs, 193

CIDR, 206-207

ptg13046388

726 IP addressing

classful addressing, 189-191

classless addressing, 191

fragmentation, 214

IP, 187

NAT, 207-208

Dynamic NAT without PAT,

210-214

PAT, 211-214

Static NAT, 209-210

private addressing, 207

route summarization, 201-205

inclusive summary routes, finding,

202-204

subnetting. See subnetting

TCP, 187-188

UDP, 188

VLSM, 200-201

ip cef command, 282

ip cef load-sharing algorithm command,

285

ip default-network command, 670-671

ip eigrp traffic command, 371-372

ip ftp command, 256

ip load-share command, 283

ip ospf process-id area area-id interface

subcommand, 510

IP routing

CEF, 273-285

architecture, 275-276

example of, 277-281

FIB, 274

load sharing, 282-285

lookup process, 274

polarization, 284-285

RIB, 274

fast switching, 272-273

forwarding process, 271-272

MLS, 286-295

configuring, 291-295

Layer 3 interfaces, 291

logic, 286-287

Port-channels, 291

routed ports, 287-291

SVI, 286-287

PBR, 296-299

logic, 296

matching criteria, specifying, 296

SDM templates, 299

set commands, 296-299

IP routing table, clearing, 444

IP services

ARP, 232-233

BOOTP, 233-234

DHCP, 233-236

configuring, 235-236

database agents, 235

FTP, 255-256

GLBP, 239

HSRP, 236-239

HTTPS access, implementing, 257-258

MHSRP, 239

NTP, 240-241

Proxy ARP, 232-233

RARP, 233-234

SCP, 257

SNMP, 241-245

communities, 242

configuring, 245

MIB, 242, 244

protocol messages, 243-244

RMON, 244

security, 245

Traps, 244

versions, 242

Syslog, 245-246

ptg13046388

IST (Internal Spanning Tree) 727

Telnet access, implementing, 258

VRRP, 239

WCCP, 246-249

IP SLA. See Cisco IOS IP SLA

IP Traffic Export. See RITE (Router IP

Traffic Export)

IPCP (IP Configuration Protocol), 96

IPsec, OSPFv3 configuration, 546-547

IPv6, 214-220

address format, 215

address types, 216

DHCPv6, 217-218

fragmentation, 214

host address, configuring, 216-217

IS-IS support for, 610-613

network prefix, 215-216

RIPng, 339-341

authentication, 340

messages, 339

Stateless Address Autoconfiguration,

217

stateless DHCPv6, 218

transition technologies, 218-220

IS-IS

adjacencies, 578-579, 587

areas, 598-608

inter-area routing, 598-600

intra-area routing, 599

authentication, 608-610

broadcast links, 587

configuring, 613-624

diagnostic commands, 620-622

DIS, 579

IPv6 support, 610-613

link-state database in multiarea net-

works, 603-608

metrics, 577-578

NSAP addressing, 571

over broadcast links, 592-598

DIS, election process, 592-593

IS-IS router synchronization,

593-594

pseudonodes, 594-598

over point-to-point links, 587-592

Local Circuit IDs, 588

three-way handshakes, 589-592

packets, 579-586

CSNP packets, 585-586

Hello packets, 579-580

LSPs, 580-585

PSNP packets, 585-586

System IDs, creating, 613

is-is circuit-type command, 618

ISL (Inter-Switch Link), 69-70

configuring, 71-75

ISO OSI (International Standards

Organization Open Systems

Interconnection)

ES, 571

Extended Local Circuit IDs, 587-589

Level 0 routing, 576

Level 1 routing, 576

Level 2 routing, 576-577

Level 3 routing, 577

Local Circuit IDs, 587

network layer (OSI), modes of opera-

tion, 572

NSAP addressing, 573-576

DSP, 574

format, 574-575

IDP, 573

NSEL, 574

SNPA, 576

Isolated PVLAN Trunks, 66-67

isolated VLANs, 61

IST (Internal Spanning Tree), 139-140

ptg13046388

728 key chains

J-K

key chains, 337

K-values, 364

L4 port algorithm, 285

LACNIC (Latin American and Caribbean

Internet Addresses Registry), 207

LACP (Link Aggregation Control

Protocol), 159-161

LANs

DRs, 469

election process, 471-472

optimizing, 470-471

switch forwarding behavior, 19

Layer 2

frame rewrites, 273

troubleshooting, 161-169, 175-176

with CDP, 163-165

with LLDP, 165-167

show interfaces command,

167-169

Layer 3

MLS interfaces, 291

troubleshooting, 695

debug commands, 694

extended ping command, 691-692

extended traceroute command,

693-694

show commands, 690-691

show interfaces command,

688-690

show ip interface command,

688-690

show ip protocols command,

686-687

Length field (Ethernet), 15, 18

Level 0 routing, 576

Level 1 routing, 576

Level 2 routing, 576-577

Level 3 routing, 577

Link Aggregation, 154-161

load balancing, 154-156

link-state database (IS-IS) in multiarea

networks, 603-608

link-state routing protocols, 317-318

IS-IS

adjacencies, 578-579, 587

broadcast links, 587

DIS, 579

IPv6 support, 610-613

metrics, 577-578

NSAP addressing, 571

over broadcast links, 592-598

over point-to-point links, 587-592

packets, 579-586

System IDs, creating, 613

migration strategy, 299-308

activating new IGP, 300-301

deactivating current IGPs,

301-303

verifying working database con-

tents, 301

OSPF, 464-466

ABRs, 480

ASBRs, 481

best path selection, 502-505

configuring, 505-507

costs, 507-510

DRs, 469

external routes, 492-495

GR, 530-532

Graceful Shutdown, 532

incremental SPF, 527-528

LSA Throttling, 526-527

messages, 461-462

neighbor states, 462-464

network types, 473

ptg13046388

LSR (Link-State Request) messages 729

NSF, 530-532

over NBMA networks, 474-479

path selection, 482

prefix suppression (OSPF),

528-529

RIDs, 460-461

route summarization, 665

SPF calculation, 479

steady-state operation, 480

stub routers, configuring, 529-530

stubby areas, 496-501

transmitting LSA headers to

neighbors, 466

TTL Security Check, 522-523

Type 1 LSAs, 484-488

Type 2 LSAs, 484-488

Type 3 LSAs, 488-492

Type 4 LSAs, 492-495

Type 5 LSAs, 492-495

LISP (Locator/Identifier Separation

Protocol), 437-438

LLDP (Link Layer Discovery Protocol),

troubleshooting Layer 2 issues,

165-167

load balancing

EtherChannel, 154-156

GLBP, 239

methods for switching paths, 281

PVST+, 119-124

unequal-cost load balancing, 420-421

load metric component, 362-363

load sharing, CEF, 282-285

algorithms, 285

Loading state, OSPF routers, 464

Local Circuit IDs, 587

local computation, 392

local interfaces, 674

logging

EIGRP, 443

Syslog, 245-246

logic

MLS, 286-287

PBR, 296

of prefix lists, 642

route maps, 638-640

lookup process, CEF, 274

Loop Guard, 259

loop prevention

best path selection side effects on,

502-505

RIPv2, 320-326

loopback networks, 473

LSA Throttling, 526-527

LSAck (Link-State Acknowledgment)

messages, 461

LSAs

comparing with LSPs, 584-585

flooding, 469

OSPFv3 types, 534-536

pseudonodes, 485

requesting, 468-469

sequence numbers, 468

transmitting headers to neighbors, 466

Type 1 LSAs, 484-488

Type 2 LSAs, 484-488

Type 3 LSAs, 488-492

filtering, 513-515

Type 4 LSAs, 492-495

Type 5 LSAs, 492-495

LSDBs (Link-State Databases), 481-482

LSPs (Link State Protocol Data Units),

580-585

ATT flag, 602-603

comparing with LSAs, 584-585

flooding, 591-592

fragmentation, 581

O flag, 603

Partition repair flag, 603

Remaining Lifetime value, 581

sequence numbers, 580-581

LSR (Link-State Request) messages, 461

ptg13046388

730 MAC addresses

MAC addresses, 15-18

format, 17-18

switch learning process, 19-22

managers (SNMP), 244

manual route summarization, 357, 428

master/slave relationship, DD packet

exchange, 466-468

match commands for route maps,

640-641

matching criteria for PBR, specifying,

296

math used in subnetting, 192

MC (Master Controller), 675-676

configuring, 677-681

measuring performance, Cisco IOS IP

SLA, 249-250

MEC (Multichassis EtherChannel), 31

messages

OSPF, 461-462

Hello process, 464-466

RIPng, 339

RIPv2, 319-320

SNMP protocol messages, 243-244

VTP, 85-86

metrics

EIGRP, 360-361

bandwidth, 361

composite metric, calculating,

363-364

delay, 361-362

extended metrics, 366

hop count, 363

influencing path selection with,

368

load, 362-363

MTU, 363

reliability, 362

Wide Metrics, 364-368

IS-IS, 577-578

RIPv2, 320

route redistribution, influencing,

661-663

setting for route redistribution, 649

Wide Metrics, 365-368

latency, 366

support for, confirming, 365-366

MHSRP (Multiple HSRP), 239

MIB (Management Information Base),

242, 244

migration strategy for routing protocols,

299-308

activating new IGP, 300-301

deactivating current IGPs, 301-303

distance-vector routing protocols,

303-308

verifying working database contents,

301

MLS (Multilayer Switching), 286-295

configuring, 291-295

Layer 3 interfaces, 291

logic, 286-287

Port-channels, 291

routed ports, 287-291

SVI, 286-287

modifying VLAN operational states,

57-69

most significant byte, 17

MST (Multiple Spanning Trees), 137-148

Bridge Assurance, 154

CIST, 140-141

configuring, 144-148

external costs, 140

interoperability with other STP versions,

141-144

PortFast, 148-149

principles of operation, 138-141

MTU metric component, 363

multiaccess links, IS-IS, 587

ptg13046388

OSI (Open Systems Interconnection) 731

multicast

naïve reliable multicast, 375

reliable multicast, 374

multicast addresses, 216

multicast MAC addresses, 15

mutual redistribution at multiple routers,

654-656

naïve reliable multicast, 375

named mode (EIGRP), 410-417

Address Family configuration mode,

414-415

Per-AF Interface configuration mode,

415

Per-AF Topology configuration mode,

416-417

NAT (Network Address Translation),

207-208

Dynamic NAT without PAT, 210-211

PAT, 211-212

Static NAT, 209-210

NBMA networks, 473

OSPF over

caveats, 474

example, 474-479

OSPFv3 over, 536-537

neighbor states (OSPF), 462-464

neighbor table (EIGRP), 379

NetFlow

configuring, 251-252

implementing, 250-252

network 0.0.0.0 command, 436

network layer (OSI), modes of opera-

tion, 572

network prefix (IPv6), 215-216

network types, OSPF, 473

Next Multicast Sequence TLV, 375

next-hop feature (RIPv2), 338

Non-Edge Designated ports, 135

normal-range VLANs, configuring, 94

NSAP (Network Service Access Point)

addressing, 571, 573-576

DSP, 574

format, 574-575

IDP, 573

NSEL (NSAP Selector), 574

NSF (Non Stop Forwarding), 530-532

NSSAs (not-so-stubby areas), 498-499

NTP (Network Time Protocol), 240-241

O flag (LSPs), 603

offset lists, 338

offset lists (EIGRP), 444

Opcode field, EIGRP packets, 369

open source EIGRP implementation, 356

operating systems, IOS-XE, 38-40

operational roles, PfR, 675

operational states of VLANs, modifying,

57-69

optimizing

DRs on LANs, 470-471

STP with PortFast, 148-149

OSI (Open Systems Interconnection)

ES, 571

Extended Local Circuit IDs, 587-589

IS-IS dependence on, 571

Level 0 routing, 576

Level 1 routing, 576

Level 2 routing, 576-577

Level 3 routing, 577

Local Circuit IDs, 587

network layer, modes of operation, 572

NSAP addressing, 573-576

DSP, 574

format, 574-575

IDP, 573

ptg13046388

732 OSI (Open Systems Interconnection)

NSEL, 574

SNPA, 576

OSPF. See also OSPFv3

ABRs, 480

ASBRs, 481

authentication

classic OSPF authentication, con-

figuring, 517-520

SHA-HMAC, configuring,

520-522

configuring, 505-507

costs, 507-510

database exchange

DD packet exchange, 466-468

LSAs, 468-469

transmitting LSA headers to

neighbors, 466

dead interval, 465

DRs

on LANs, 469

optimizing, 470-471

on WANs, 472-474

external routes, 492-495

filtering

route filtering, 510-513

Type 3 LSA filtering, 513-515

GR, 530-532

Graceful Shutdown, 532

incremental SPF, 527-528

LSAs

Type 1 LSAs, 484-488

Type 2 LSAs, 484-488

Type 3 LSAs, 488-492

Type 4 LSAs, 492-495

Type 5 LSAs, 492-495

messages, 461-462

Hello process, 464-466

neighbor states, 462-464

network types, 473

NSF, 530-532

versus OSPFv3, 533-534

over NBMA networks

caveats, 474

example of, 474-479

path selection

best path selection, 502-505

path choices not using cost, 502

performance tuning

LSA Throttling, 526-527

SPF Throttling, 524-525

prefix suppression, 528-529

RIDs, 460-461

route redistribution into EIGRP, 650

route summarization, 665

SPF calculation, 479

steady-state operation, 480

stub routers, configuring, 529-530

stubby areas, 496-501

TTL Security Check, 522-523

virtual links

authentication, configuring, 520

configuring, 515-517

OSPFv3

address family support, 548-551

authentication, 546-547

configuring, 537-545

Graceful Shutdown, 552

LSA types, 534-536

NBMA networks, 536-537

versus OSPFv2, 533-534

over Frame Relay, configuring, 537

SPI, 546

verifying configuration, 541-545

virtual links, 534

OTP (Over the ToP), 437-442

configuring, 439-442

LISP, 437-438

OUI (Organizationally Unique Identifier)

field, 15

ptg13046388

point-to-multipoint nonbroadcast networks 733

packets. See also IP routing

EIGRP, 368-374. See also RTP (Reliable

Transport Protocol)

ACK packets, 372-373

format, 368-371

Hello packets, 372

Query packets, 374

Reply packets, 374

SIA-Query packets, 374

SIA-Reply packets, 374

TLVs, 369

Update packets, 373

forwarding process, 271-272

fast switching, 272-273

IGRP, Update packets, 357-358

IS-IS, 579-586

authentication, 608-610

CSNP packets, 585-586

Hello packets, 579-580

LSPs, 580-585

PSNP packets, 585-586

PAgP (Port Aggregation Protocol),

159-161

Partition repair flag (LSPs), 603

passive interfaces (EIGRP), 431-432

Passive state (EIGRP), 381

passive-interface command, 431-432

passwords, VTP, 87

PAT (Port Address Translation), 211-212

configuring, 212-214

path selection

influencing with interface metrics, 368

OSPF, 482

best path selection, 502-505

path choices not using cost, 502

path-vector routing protocols, 317

PBR (Policy-Based Routing), 296-299

logic, 296

SDM templates, 299

set commands, 296-299

specifying matching criteria, 296

Pearson Cert Practice Test engine,

700-705

installing, 700-702

practice exam, downloading, 702

Pending state (EIGRP), 378

Per-AF Interface configuration mode

(EIGRP), 415

Per-AF Topology configuration mode

(EIGRP), 416-417

per-destination load sharing, 282-283

performance

Cisco IOS IP SLA, 249-250

OSPF

LSA Throttling, 526-527

SPF Throttling, 524-525

per-packet load sharing, 282

PfR (Performance Routing), 672-683

authentication, 674-675

border routers, 676-677

configuring, 681-683

configuring, 677

external interfaces, 674

internal interfaces, 674

local interfaces, 674

MC, 675-676

configuring, 677-681

operational roles, 675

phases wheel, 673-674

phases wheel (PfR), 673-674

PID (process ID), 465

pinouts, RJ-45, 8-9

point-to-multipoint networks, 473

point-to-multipoint nonbroadcast net-

works, 473

ptg13046388

734 point-to-point links, IS-IS over

point-to-point links, IS-IS over, 587-592

Local Circuit IDs, 588

three-way handshakes, 589-592

point-to-point networks, 473

polarization, CEF, 284, 285

policy routing. See PBR (Policy-Based

Routing)

Port-channels, 291

configuring, 157-161

PortFast, 148-149

ports

Cisco switch ports, configuring, 11-14

promiscuous ports, 65

routed ports, 287-291

RSTP, 128-131

Alternate ports, 130

Backup Ports, 130

Non-Edge Designated ports, 135

roles, 129

types, 131

VSL, configuring, 33

PPPoE (Point-to-Point Protocol over

Ethernet), configuring, 96-98

pppoe session command, 98

practice exam, downloading, 702

Preamble field (Ethernet), 15

prefix lists, 338-339, 641-643

examples, 643

logic, 642

prefix suppression

OSPF, 528-529

OSPFv3, 552

prefixes, 191

Premium Edition of this book, 703

preparing for exam

Cisco Learning Network, 703

memory tables, 703

Pearson Cert Practice Test engine,

700-705

preventing suboptimal routes

setting administrative distance, 656-659

using route tags, 659-661

primary servers, 88

principles of MST operation, 138-141

priorities, 108

private addressing, 207

Private VLANs, 60-68

communication rules, 64-65

configuring, 67-68

Isolated PVLAN Trunks, 66-67

secondary VLANs, 61-63

tagging rules, 64

on trunks, 65-67

Promiscuous PVLAN Trunks, 66

promiscuous ports, 65

Promiscuous PVLAN Trunks, 66

Proposal/Agreement process (RSTP),

133-136

protocol messages (SNMP), 243-244

Proxy ARP, 232-233

pseudonodes, 485

IS-IS, 594-598

PVST+ (Per VLAN Spanning Tree Plus),

119-124

Q Cnt, 379

QoS (Quality of Service), evaluating

with Cisco IOS IP SLA, 249-250

Quagga, 356

Query packets (EIGRP), 374

handling by stub routers, 424

ptg13046388

route-map command 735

RARP (Reverse ARP), 233-234

comparing with BOOTP and DHCP, 236

RBID (Root Bridge ID), 109

RD (Reported Distance), 386-387

records (NetFlow), 251

redistribute command, 645

redistribute static command, 667-668

reliability metric component, 362

reliable multicast, 374

Remaining Lifetime value (LSPs), 581

Reply packets (EIGRP), 374

requesting LSAs, 468-469

resolving

Layer 2 issues, 175-176

Layer 3 issues, 695

restrictions of SPAN, 24-25

revision numbers, VTP, 86-87

RFC 1195, 571

RFC 6860, 528

RIB (Routing Information Base), 274,

368

RID (Router ID), 417-420

displaying, 419-420

OSPF, 460-461

value selection, 419

RIPng (RIP next generation), 339-341

authentication, 340

configuring, 340-341

messages, 339

RIPv1 (Routing Information Protocol

version 1), 357

RIPv2 (Routing Information Protocol

version 2), 318-320

authentication, configuring, 337

autosummarization, 335-337

configuring, 334-339

convergence, 334

steady-state operation, 327-328

timers for stalled routing update

reception, 331-333

distribute lists, 338-339

features, 318

Flushed after timer, 326

Holddown timer, 324-325

Invalid timer, 324-325

loop prevention, 320-326

messages, 319-320

metrics, 320

next-hop feature, 338

offset lists, 338

prefix lists, 338-339

Route Poisoning, 323

Split Horizon, 322, 338

triggered updates, 323, 328-331

RITE (Router IP Traffic Export),

252-253

RMON (Remote Monitoring), 244,

254-255

alarms, 255

configuring, 255

events, 254

roles of RSTP ports, 129

Root Guard, 149

root switch, election process, 110-111

route filtering

EIGRP, 443-444

OSPF, 510-513

Type 3 LSA filtering, 513-515

route-map command, 638-640

ptg13046388

736 route maps

route maps, 650-653

configuring with route-map command,

638-640

logic, 638-640

match commands, 640-641

set commands, 641

Route Poisoning, 323

route redistribution, 645-663

EIGRP into OSPF, 650

influencing with metrics, 661-663

metrics, setting, 649

mutual redistribution at multiple rout-

ers, 654-656

OSPF into EIGRP, 650

prefix lists, 641-643

redistribute command, 645

route maps, 638-640, 650-653

set commands, 641

suboptimal routes, 655-656

preventing by setting administra-

tive distance, 656-659

preventing using route tags,

659-661

using default settings, 646-649

route summarization, 201-205, 427-431,

663-665

automatic route summarization, 428

component routes, 663

configuring, 430-431

default routing, 671-672

discard routes, 429

EIGRP, 664-665

exclusive summary routes, finding,

204-205

manual route summarization, 428

OSPF, 665

route tags, 356

suboptimal routes, preventing, 659-661

routed ports, 287-291

router adjacencies (EIGRP), 376-379

Hold time, 377

Pending state, 378

Q Cnt, 379

Up state, 378

router isis command, 616

router process command, 425-426

routers

configuring trunking on, 77-79

implementing TFTP on, 256-257

routing loops (EIGRP), Feasibility

Condition, 359

routing protocols, migration strategy,

299-308

activating new IGP, 300-301

deactivating current IGPs, 301-303

distance-vector routing protocols,

303-308

verifying working database contents,

301

“routing through a failure,” 531

RP (Root Port)

selecting, 109, 111-113

RPC (Root Path Cost), 108

RPID (Receiver Port ID), 109

RPVST+ (Rapid Per-VLAN Spanning

Tree Plus), 137

Bridge Assurance, 154

RSPAN (Remote SPAN), 22-25

configuring, 26-27

restrictions, 24-25

traffic supported, 25

RSTP (Rapid STP), 107, 128-137

BPDUs, 132-133

Discarding state, 129

links, 131

PortFast, 148-149

ptg13046388

SLSM (static length subnet masking) 737

ports, 128-131

Alternate Ports, 130

Non-Edge Designated ports, 135

roles, 129

types, 131

proposal/agreement process, 133-136

RPVST+, 137

topology change handling, 136-137

RTO (retransmission timeout), 376

RTP (Reliable Transport Protocol), 358,

374-376

Conditional Receive, 375

RTR (Response Time Reporter). See

Cisco IOS IP SLA

SAA (Service Assurance Agent). See

Cisco IOS IP SLA

SBID (Sender Bridge ID), 108

SCP (Secure Copy Protocol), 257

SDM (Switch Database Management)

templates, 299

secondary servers, 88

secondary VLANs, 61-63

security

authentication

EIGRP, 356, 432-435

IS-IS, 608-610

OSPF, 517-520

OSPFv3, 546-547

PfR, 674-675

IDSs, RITE implementation, 252-253

as motivating factor in VLAN design,

SNMP, 245

VTP passwords, 87

selecting RPs, 109

sending exception dumps with FTP, 256

Sequence field, EIGRP packets, 369

sequence numbers, 374

LSAs, 468

LSPs, 580-581

Sequence TLV, 375

Set command (SNMP), 244

set commands

for PBR, 296-299

for route maps, 641

setting

administrative distance to prevent sub-

optimal routes, 656-659

metrics for route redistribution, 649

SHA-HMAC (Secure Hash Algorithm

Hash Message Authentication Code),

OSPF configuration, 517-520

show clns command, 620-622

show interfaces command, 167-169,

688-690

show ip interface command, 688-690

show ip ospf database command, 488

show ip protocols command, 426-427

troubleshooting Layer 3 issues, 686-687

show ip route isis command, 617

show ip route ospf command, 516-517

show ip sla monitor statistics command,

250

show isis database command, 601-603

show isis hostname command, 581-583

show rmon alarm command, 255

show rmon event command, 255

show running-config command, 240-241

show sdm prefer command, 299

SIA (Stuck-In-Active) states, 402-410

SIA-Query packets (EIGRP), 374

SIA-Reply packets (EIGRP), 374

slave/master relationship, DD packet

exchange, 466-468

SLSM (static length subnet masking),

197, 200

ptg13046388

738 SNAP (Sub-Network Access Protocol)

SNAP (Sub-Network Access Protocol),

SNMP (Simple Network Management

Protocol), 241-245

agents, 244

communities, 242

configuring, 245

managers, 244

MIBs, 242, 244

protocol messages, 243-244

RMON, 244

security, 245

Traps, 244

versions, 242

SNPA (Sub Network Point of

Attachment), 576

Source Service Access Point field

(Ethernet), 15

SPAN (Switch Port Analyzer), 22-25

configuring

basic configuration, 26

complex configuration, 26

restrictions, 24-25

traffic supported, 25

speed (Ethernet), 9

speed interface subcommand, 9

SPF Throttling, tuning OSPF perfor-

mance with, 524-525

SPI (Security Parameter Index), 546

SPID (Sender Port ID), 109

Split Horizon, 322, 338, 436-437

Split Horizon with Poisoned Reverse,

321

spoke routers, stub routing, 423-427

SPs (service providers), Private VLANs,

SRTT (smooth round-trip time), 376

SSH (Secure Shell), 257-258

standby switches (VSS), 30

Start of Frame Delimiter field (Ethernet),

Stateless Address Autoconfiguration,

217

stateless DHCPv6, 218

Static NAT, 209-210

static routing, 316

steady-state convergence, RIPv2,

327-328

steady-state operation (OSPF), 480

storing VTP configuration, 94-95

STP (Spanning Tree Protocol)

Blocking state, 107

transitioning to Forwarding state,

119

BPDU Filter, 150-151

BPDU Guard, 149-150

BPDUs, 107-109

RBID, 109

CAM, updating, 117-119

configuring, 124-128

converging to new topology, 115-117

costs, 113

CST, 120-124

DP, selecting, 113-115

interface states, 119

Loop Guard, 259

MST, 137-148

CIST, 140-141

configuring, 144-148

external costs, 140

interoperability with other STP

versions, 141-144

principles of operation, 138-141

PortFast, 148-149

PVST+, 119-124

root ports, selecting, 109

ptg13046388

tftp-server command 739

root switch, election process, 110-111

RP, selecting, 111-113

RSTP, 128-137

BPDUs, 132-133

Discarding state, 129

links, 131

ports, 128-131

Proposal/Agreement process,

133-136

RPVST+, 137

topology change handling,

136-137

System ID Extension, 111

TCN, 117-119

troubleshooting, 170

UDLD, 152-154

unidirectional links, 151-154

straight-through cabling, 8

stub routing, 423-427

configuring, 529-530

Query handling, 424

stubby areas, 496-501

configuring, 498-501

subnet number, discovering, 194-196

subnetting, 188-205

all subnets of a network, finding

binary shortcut, 196-198

decimal shortcut, 198-200

bitwise Boolean ANDs, 193

broadcast address, finding, 195-196

broadcast subnets, 192

classful addressing, 189-191

classless addressing, 191

math used in, 192

subnet number, finding, 194-196

valid range of IP addresses, finding,

194-196

VLSM, 200-201

zero subnets, 192

suboptimal routes, preventing

setting administrative distance, 656-659

using route tags, 659-661

summarization (EIGRP), 427-431

automatic route summarization, 428

configuring, 430-431

discard routes, 429

manual route summarization, 428

superior BPDUs, 108

SVI (switched virtual interfaces),

286-287

switch convert mode virtual command,

33-34

switches

IOS-XE, 38-40

MAC address learning process, 19-22

SPAN, 22-25

VLANs, 51

Private VLANs, 60-68

VSS, 28-38

switching loops (EtherChannel), 159

synchronization of IS-IS routers,

593-594

Syslog, 245-246

System ID Extension, 111

System IDs (IS-IS), creating, 613

tagging rules for Private VLANs, 64

TCN (Topology Change Notification),

117-119

TCP (Transport Control Protocol),

187-188

Telnet access, implementing, 258

TFTP (Trivial File Transfer Protocol)

servers, implementing on routers,

256-257

tftp-server command, 257

ptg13046388

740 three-way handshakes (IS-IS)

three-way handshakes (IS-IS), 589-592

throughput metric, 366

timers

Flushed after timer, 326

Holddown timer, 324-325

IGRP, 357-358

Invalid timer, 324-325

TLVs (Type-Length-Values), 369-371

Adjacency State TLV, 589-591

Next Multicast Sequence TLV, 375

Sequence TLV, 375

topologies

changes in, RSTP handling of, 136-137

STP convergence, 115-117

Topology Change BPDUs, 108-109

topology table, 384-385

Active state, 381

CD, 386-387

contents of, 382-384

diffusing computation, 392-396

DUAL

FSM, 397-402

SIA states, 402-410

FD, 387-391

Feasible Successors, unequal-cost load

balancing, 420-421

local computation, 392

Passive state, 381

RD, 386-387

show commands, 385-387

topology changes, 391-396

transfers (FTP), initiating, 256

transition technologies for IPv6,

218-220

translation, IPv6, 220

Traps (SNMP), 244

triggered updates, 323, 328-331

troubleshooting

EtherChannel, 174-175

Layer 2 issues, 161-169

with CDP, 163-165

with LLDP, 165-167

with show interfaces command,

167-169

Layer 3 issues, 683-695

debug commands, 694

extended ping command, 691-692

extended traceroute command,

693-694

show commands, 690-691

show interfaces command,

688-690

show ip interface command,

688-690

show ip protocols command,

686-687

STP, 170

trunking, 171-172

VTP, 172-173

trunking

802.1Q, 69-70

configuring, 71-75

802.1Q-in-Q tunneling, 79-83

active VLANs, 76

allowed VLANs, 76

configuring

options, 76-77

on routers, 77-79

ISL, 69-70

configuring, 71-75

Private VLANs, 65-67

Isolated PVLAN Trunks, 66-67

Promiscuous PVLAN Trunks, 66

troubleshooting, 171-172

VTP, 83-95

configuring, 89-95

conflicts, 88

ptg13046388

VLANs 741

messages, 85-86

revision numbers, 86-87

storing the configuration, 94-95

update process, 86-87

versions of, 83-84

TTL Security Check, 522-523

tuning performance of OSPF

with LSA Throttling, 526-527

with SPF Throttling, 524-525

tunnel load-sharing algorithm, 285

tunneling

802.1Q-in-Q tunneling, 79-83

IPv6, 219-220

Txload, 363

Type field (Ethernet), 15, 18

types of LSAs, 482-496

UDLD (Unidirectional Link Detection),

152-154

UDP (User Datagram Protocol), 188

U/L (Universal/Local) bit, 17-18

unequal-cost load balancing, 420-421

unicast addresses, 216

unicast MAC addresses, 15

unidirectional links, 151-154

Universal ID, 284

universal load-sharing algorithm, 285

unreachable routes, 362

Up state (EIGRP), 378

Update packets (EIGRP), 373

Update packets (IGRP), 357-358

update process, VTP, 86-89

updates, EIGRP, 356

updating CAMs, 117-119

valid range of IP addresses, finding,

194-196

value selection (RID), 419

vectors, 322

verifying

Cisco IOS IP SLA performance, 250

NetFlow configuration, 252

OSPFv3 configuration, 541-545

VSS, 35-38

Version field, EIGRP packets, 369

versions

of SNMP, 242

of VTP, 83-84

virtual links

OSPF

authentication, configuring, 520

configuring, 515-517

OSPFv3, 534

Virtual Router ID field, EIGRP packets,

369

VLAN database configuration mode

VLANs

creating, 52-55

interfaces, configuring, 55-56

VLANs, 51

configuring, 51-52

in configuration mode, 56-57

interfaces, configuring, 55-56

internal usage VLANs, 288-290

operational state, modifying, 57-69

Private VLANs, 60-68

configuring, 67-68

Isolated PVLAN Trunks, 66-67

Promiscuous PVLAN Trunks, 66

secondary VLANs, 61-63

tagging rules, 64

trunking, 65-67

ptg13046388

742 VLANs

trunking

802.1Q, 69-75

802.1Q-in-Q tunneling, 79-83

active VLANs, 76

allowed VLANs, 76

configuring, 76-79

ISL, 69-75

troubleshooting, 171-172

VTP

configuring, 89-95

troubleshooting, 172-173

VLSM (variable-length subnet masking),

200-201

VPNs, OTP, 437-442

VRRP (Virtual Router Redundancy

Protocol), 239

VSL (Virtual Switch Link), 30

VSS (Virtual Switch System), 28-38

active switches, 30

configuring, 31-34

MEC, 31

standby switches, 30

verifying, 35-38

VSL, 30

VTP (VLAN Trunking Protocol),

83-95

configuring, 89-95

extended-range VLANs, 94

global configuration options,

90-91

normal-range VLANs, 94

conflicts, 88

passwords, 87

revision numbers, 86-87

storing the configuration, 94-95

troubleshooting, 172-173

versions of, 83-84

VTPv1

messages, 85-86

update process, 86-87

VTPv2

messages, 85-86

update process, 86-87

VTPv3, update process, 87-89

WANs, DRs, 472-474

WCCP (Web Cache Communication

Protocol), 246-249

weaknesses of IGRP, 358

websites, Cisco Learning Network, 703

Wide Metrics, 360-361, 364-368

latency, 366

support for, confirming, 365-366

throughput, 366

wiring, Category 5, 8-9

X-Y-Z

zero subnets, 192

ptg13046388

Check out the NEW learning

materials for v5.0 exam release!

Cisco CCIE Routing

and Switching v5.0

Configuration Practice Labs

9780133786316

Cisco CCIE Routing and

Switching v5.0 Troubleshooting

Practice Labs

9780133786330

Cisco CCIE Routing and

Switching v5.0 Configuration

and Troubleshooting

Practice Labs Bundle

9780133786323

Cisco CCIE Routing and

Switching v5.0 Official

Cert Guide, Volume 1

9781587143960

SAVE ON ALL NEW

CCIE R&S v5.0 Products

www.CiscoPress.com/CCIE

Increase learning, comprehension, and certification readiness

with these Cisco Press products!

New Resource

Cisco CCIE

Routing and Switching

v5.0 Official Cert Guide,

Volume 1 Premium Edition

eBook/Practice Test

9780133481648

Cisco CCIE

Routing

and Switching v5.0

Official Cert Guide,

Volume 2

9781587144912

New Resource

Cisco CCIE Routing and

Switching v5.0 Official

Cert Guide, Volume 2

Premium Edition

eBook/Practice Test

9780133591057

Cisco CCIE Routing and

Switching v5.0 Official

Cert Guide Library

9781587144929

New Resource

CCIE Routing and Switching

v5.0 Exam Roundup

LiveLessons (Networking Talks)

9780789754035

ptg13046388

Activate your FREE Online Edition at

informit.com/safarifree

STEP 1: Enter the coupon code: TZNSSZG.

STEP 2: New Safari users, complete the brief registration form.

Safari subscribers, just log in.

If you have diﬃ culty registering on Safari or accessing the online edition,

please e-mail customer-service@safaribooksonline.com

Your purchase of CCIE Routing and Switching v5.0 Ofﬁ cial Cert Guide, Volume 1 includes

access to a free online edition for 45 days through the Safari Books Online subscription service.

Nearly every Cisco Press book is available online through Safari Books Online, along with

thousands of books and videos from publishers such as Addison-Wesley Professional, Exam

Cram, IBM Press, O’Reilly Media, Prentice Hall, Que, Sams, and VMware Press.

Safari Books Online is a digital library providing searchable, on-demand access to thousands

of technology, digital media, and professional development books and videos from leading

publishers. With one monthly or yearly subscription price, you get unlimited access to learning

tools and information on topics including mobile app and software development, tips and tricks

on using your favorite gadgets, networking, project management, graphic design, and much more.

FREE

Online Edition

ptg13046388

This page intentionally left blank

ptg13046388

This appendix provides a handy reference for converting between decimal and binary

formats for the decimal numbers 0 through 255. Feel free to refer to this table when prac-

ticing the subnetting problems in Appendix D, “IP Addressing Practice,” which is on the

CD.

Although this appendix is useful as a reference tool, note that if you plan to convert val-

ues between decimal and binary when doing subnetting-related exam questions, instead

of using the shortcut processes that mostly avoid binary math, you will likely want to

practice converting between the two formats before the exam. For practice, just pick any

decimal value between 0 and 255, convert it to 8-bit binary, and then use this table to

find out whether you have the right answer. Also, pick any 8-bit binary number, convert it

to decimal, and again use this table to check your work.

APPENDIX C

Decimal to Binary Conversion Table

ptg13046388

4 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Dec

Value

Bin Value Dec

Value

Bin Value Dec

Value

Bin Value Dec

Value

Bin Value

0 00000000 32 00100000 64 01000000 96 01100000

1 00000001 33 00100001 65 01000001 97 01100001

2 00000010 34 00100010 66 01000010 98 01100010

3 00000011 35 00100011 67 01000011 99 01100011

4 00000100 36 00100100 68 01000100 100 01100100

5 00000101 37 00100101 69 01000101 101 01100101

6 00000110 38 00100110 70 01000110 102 01100110

7 00000111 39 00100111 71 01000111 103 01100111

8 00001000 40 00101000 72 01001000 104 01101000

9 00001001 41 00101001 73 01001001 105 01101001

10 00001010 42 00101010 74 01001010 106 01101010

11 00001011 43 00101011 75 01001011 107 01101011

12 00001100 44 00101100 76 01001100 108 01101100

13 00001101 45 00101101 77 01001101 109 01101101

14 00001110 46 00101110 78 01001110 110 01101110

15 00001111 47 00101111 79 01001111 111 01101111

16 00010000 48 00110000 80 01010000 112 01110000

17 00010001 49 00110001 81 01010001 113 01110001

18 00010010 50 00110010 82 01010010 114 01110010

19 00010011 51 00110011 83 01010011 115 01110011

20 00010100 52 00110100 84 01010100 116 01110100

21 00010101 53 00110101 85 01010101 117 01110101

22 00010110 54 00110110 86 01010110 118 01110110

23 00010111 55 00110111 87 01010111 119 01110111

24 00011000 56 00111000 88 01011000 120 01111000

25 00011001 57 00111001 89 01011001 121 01111001

26 00011010 58 00111010 90 01011010 122 01111010

27 00011011 59 00111011 91 01011011 123 01111011

28 00011100 60 00111100 92 01011100 124 01111100

29 00011101 61 00111101 93 01011101 125 01111101

30 00011110 62 00111110 94 01011110 126 01111110

31 00011111 63 00111111 95 01011111 127 01111111

ptg13046388

Appendix C: Decimal to Binary Conversion Table 5

Dec

Value

Bin Value Dec

Value

Bin Value Dec

Value

Bin Value Dec

Value

Bin Value

128 10000000 160 10100000 192 11000000 224 11100000

129 10000001 161 10100001 193 11000001 225 11100001

130 10000010 162 10100010 194 11000010 226 11100010

131 10000011 163 10100011 195 11000011 227 11100011

132 10000100 164 10100100 196 11000100 228 11100100

133 10000101 165 10100101 197 11000101 229 11100101

134 10000110 166 10100110 198 11000110 230 11100110

135 10000111 167 10100111 199 11000111 231 11100111

136 10001000 168 10101000 200 11001000 232 11101000

137 10001001 169 10101001 201 11001001 233 11101001

138 10001010 170 10101010 202 11001010 234 11101010

139 10001011 171 10101011 203 11001011 235 11101011

140 10001100 172 10101100 204 11001100 236 11101100

141 10001101 173 10101101 205 11001101 237 11101101

142 10001110 174 10101110 206 11001110 238 11101110

143 10001111 175 10101111 207 11001111 239 11101111

144 10010000 176 10110000 208 11010000 240 11110000

145 10010001 177 10110001 209 11010001 241 11110001

146 10010010 178 10110010 210 11010010 242 11110010

147 10010011 179 10110011 211 11010011 243 11110011

148 10010100 180 10110100 212 11010100 244 11110100

149 10010101 181 10110101 213 11010101 245 11110101

150 10010110 182 10110110 214 11010110 246 11110110

151 10010111 183 10110111 215 11010111 247 11110111

152 10011000 184 10111000 216 11011000 248 11111000

153 10011001 185 10111001 217 11011001 249 11111001

154 10011010 186 10111010 218 11011010 250 11111010

155 10011011 187 10111011 219 11011011 251 11111011

156 10011100 188 10111100 220 11011100 252 11111100

157 10011101 189 10111101 221 11011101 253 11111101

158 10011110 190 10111110 222 11011110 254 11111110

159 10011111 191 10111111 223 11011111 255 11111111

ptg13046388

This page intentionally left blank

ptg13046388

Chapter 4 , “IP Addressing,” covers many details related to analyzing IP addresses, sub-

nets, and summarized IP routes. That chapter suggests some decimal math algorithms

that allow you to find the answers to some typical questions without having to perform

time-consuming conversions between binary and decimal.

As promised in Chapter 4 , this appendix provides some practice problems that should

help you perfect the use of the algorithms in Chapter 4 . Note that the goal of this prac-

tice is not to make you memorize the algorithms. Instead, the goal is to help you become

so familiar with the patterns in the decimal math that you can look at a problem and visu-

alize the answer quickly. The intent is to enable you, after you have practiced enough, to

simply look at a problem and do the math in your head, ignoring the specific steps in the

book.

This appendix covers the decimal math processes to answer the following four types of

questions:

1. Given an IP address and mask/prefix length, list the number of subnets (assuming

SLSM), the number of hosts per subnet (assuming SLSM), the subnet number, the

broadcast address, and the range of valid IP addresses in that same subnet.

2. Given an IP network and a static mask/prefix length, list the subnet numbers.

3. Given a set of routes, find the smallest inclusive summary route.

4. Given a set of routes, find the smallest exclusive summary route(s).

These topics are covered in order in this appendix.

Subnetting Practice

This appendix lists 25 separate questions, asking you to derive the subnet number, broad-

cast address, and range of valid IP addresses. In the solutions, the binary math is shown,

as is the process that avoids binary math using the “subnet chart” described in Chapter 4 .

You might want to review Chapter 4 ’s section on IP addressing before trying to answer

these questions.

APPENDIX D

IP Addressing Practice

ptg13046388

4 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

25 Subnetting Questions

Given each IP address and mask, supply the following information for each of these 25

examples:

■ Size of the network part of the address

■ Size of the subnet part of the address

■ Size of the host part of the address

■ The number of hosts per subnet

■ The number of subnets in this network

■ The subnet number

■ The broadcast address

■ The range of valid IP addresses in this network:

1. 10.180.10.18, mask 255.192.0.0

2. 10.200.10.18, mask 255.224.0.0

3. 10.100.18.18, mask 255.240.0.0

4. 10.100.18.18, mask 255.248.0.0

5. 10.150.200.200, mask 255.252.0.0

6. 10.150.200.200, mask 255.254.0.0

7. 10.220.100.18, mask 255.255.0.0

8. 10.220.100.18, mask 255.255.128.0

9. 172.31.100.100, mask 255.255.192.0

10. 172.31.100.100, mask 255.255.224.0

11. 172.31.200.10, mask 255.255.240.0

12. 172.31.200.10, mask 255.255.248.0

13. 172.31.50.50, mask 255.255.252.0

14. 172.31.50.50, mask 255.255.254.0

15. 172.31.140.14, mask 255.255.255.0

16. 172.31.140.14, mask 255.255.255.128

17. 192.168.15.150, mask 255.255.255.192

18. 192.168.15.150, mask 255.255.255.224

19. 192.168.100.100, mask 255.255.255.240

20. 192.168.100.100, mask 255.255.255.248

21. 192.168.15.230, mask 255.255.255.252

22. 10.1.1.1, mask 255.248.0.0

23. 172.16.1.200, mask 255.255.240.0

24. 172.16.0.200, mask 255.255.255.192

25. 10.1.1.1, mask 255.0.0.0

ptg13046388

Appendix D: IP Addressing Practice 5

Suggestions on How to Attack the Problem

If you are ready to go ahead and start answering the questions, go ahead! If you want

more explanation of how to attack such questions, refer to the section on IP subnetting

in Chapter 4 . However, if you have already read Chapter 4 , a reminder of the steps in the

process to answer these questions, with a little binary math, is repeated here:

Note The examples shown here assume classful IP addressing, so the number of subnets

per IP network is listed as 2n – 2. If using classless IP addressing, the numbers would sim-

ply be 2n.

Step 1. Identify the structure of the IP address.

a. Identify the size of the network part of the address, based on Class A,

B, and C rules.

b. Identify the size of the host part of the address, based on the number

of binary 0s in the mask. If the mask is “tricky,” use the chart of typical

mask values to convert the mask to binary more quickly.

c. The size of the subnet part in bits is what’s “left over”; mathematically, it

is 32 – (network + host).

d. Declare the number of subnets, which is 2

number-of-subnet-bits – 2 .

e. Declare the number of hosts per subnet, which is 2

number-of-host-bits – 2 .

Step 2. Create the subnet chart that will be used in Steps 3 and 4.

a. Create a generic subnet chart.

b. Write the decimal IP address and subnet mask in the first two rows of

the chart.

c. If an easy mask is used, draw a vertical line between the 255s and the

0s in the mask, from top to bottom of the chart. If a hard mask is used,

draw a box around the interesting octet.

d. Copy the address octets to the left of the line or the box into the final

four rows of the chart.

Step 3. Derive the subnet number and the first valid IP address.

a. On the line on the chart where you are writing the subnet number, write

0s in the octets to the right of the line or the box.

ptg13046388

6 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

b. If the mask is difficult, so that there is a box in the chart, use the magic

number trick to find the decimal value of the subnet’s interesting octet,

and write it down. Remember, the magic number is found by subtracting

the interesting (non-0 or 255) mask value from 256. The magic number

multiple that’s closest to but not larger than the IP address’s interesting

octet value is the subnet value in that octet.

c. To derive the first valid IP address, copy the first three octets of the sub-

net number and add 1 to the fourth octet of the subnet number.

Step 4. Derive the broadcast address and the last valid IP address for this subnet.

a. Write down 255s in the broadcast address octets to the right of the line

or the box.

b. If the mask is difficult, so that there is a box in the chart, use the magic

number trick to find the value of the broadcast address’s interesting

octet. In this case, you add the subnet number’s interesting octet value

to the magic number, and subtract 1.

c. To derive the last valid IP address, copy the first three octets of the

broadcast address and subtract 1 from the fourth octet of the broadcast

address.

Question 1: Answer

The answers begin with the analysis of the three parts of the address, the number of

hosts per subnet, and the number of subnets of this network using the stated mask. The

binary math for subnet and broadcast address calculation follows. The answer finishes

with the easier mental calculations using the subnet chart described in Chapter 4 .

Table D-1 Question 1: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Item Example Rules to Remember

Address 10.180.10.18 N/A

Mask 255.192.0.0 N/A

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 22 Always defined as number of binary 0s in

mask

Number of subnet bits 2 32 – (network size + host size)

Number of subnets 2 2 – 2 = 2 2

number-of-subnet-bits – 2

Number of hosts 2 22 – 2 =

4,194,302

2 number-of-host-bits – 2

ptg13046388

Appendix D: IP Addressing Practice 7

The binary calculations of the subnet number and broadcast address are shown in Table

D-2 . To calculate the two numbers, perform a Boolean AND on the address and mask. To

find the broadcast address for this subnet, change all the host bits to binary 1s in the sub-

net number. The host bits are in bold print in the table.

Table D-2 Question 1: Binary Calculation of Subnet and Broadcast Addresses

Address 10.180.10.18 0000 1010 10 11 0100 0000 1010 0001 0010

Mask 255.192.0.0 1111 1111 11 00 0000 0000 0000 0000 0000

AND result (subnet

number)

10.128.0.0 0000 1010 10 00 0000 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.191.255.255 0000 1010 10 11 1111 1111 1111 1111 1111

To get the first valid IP address, just add 1 to the subnet number; to get the last valid IP

address, just subtract 1 from the broadcast address. In this case:

10.128.0.1 through 10.191.255.254

10.128.0.0 + 1= 10.128.0.1

10.191.255.255 – 1= 10.191.255.254

Steps 2, 3, and 4 in the process use a table like Table D-3 , which lists the way to get the

same answers using the subnet chart and magic math described in Chapter 4 . Figure D-1

at the end of this problem shows the fields in Table D-3 that are filled in at each step in

the process. Remember, subtracting the interesting (non-0 or 255) mask value from 256

yields the magic number. The magic number multiple that’s closest to but not larger than

the IP address’s interesting octet value is the subnet value in that octet.

Table D-3 Question 1: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4 Comments

Address 10 180 10 18 N/A

Mask 255 192 0 0 N/A

Subnet number 10 128 0 0 Magic number = 256 – 192 =

First valid address 10 128 0 1 Add 1 to last octet of subnet

Broadcast 10 191 255 255 128 + 64 – 1 = 191

Last valid address 10 191 255 254 Subtract 1 from last octet

Subnet rule: Multiple of magic number closest to, but not more than, IP address value in interesting octet

Broadcast rule: Subnet + magic – 1

ptg13046388

8 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The second octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 192 = 64 in this case (256 – the

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 128 is the multiple of 64 that’s closest

to 180 but not larger than 180. So, the second octet of the subnet number is 128.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 128 +

64 – 1 = 191.

Finally, Figure D-1 shows Table D-3 with comments about when each part of the table

was filled in, based on the steps in the process at the beginning of the chapter.

2C: draw

box

2A:

create

chart

2D: copy

address

Address

Mask

Subnet

number

First

address

Broadcast

Last

address

255

180

192

128 3B

128

191 4B

191

255

255 4A

254 4C

0 3A

1 3C

Magic number = 256

– 192 = 64

Add 1 to last octet

of subnet

128 + 64 – 1 = 191

Subract 1 from

last octet

2B: Write down address

2B: Write down mask

Octet

Comments

Figure D-1 Steps 2, 3, and 4 for Question 1

Question 2: Answer

Table D-4 Question 2: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.200.10.18 N/A

Mask 255.224.0.0 N/A

ptg13046388

Appendix D: IP Addressing Practice 9

Step Example Rules to Remember

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 21 Always defined as number of binary

0s in mask

Number of subnet bits 3 32 – (network size + host size)

Number of subnets 2 3 – 2 = 6 2

number-of-subnet-bits – 2

Number of hosts 2 21 – 2 = 2,097,150 2

number-of-host-bits – 2

Table D-5 presents the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-5 Question 2: Binary Calculation of Subnet and Broadcast Addresses

Address 10.200.10.18 0000 1010 110 0 1000 0000 1010 0001 0010

Mask 255.224.0.0 1111 1111 111 0 0000 0000 0000 0000 0000

AND result (subnet

number)

10.192.0.0 0000 1010 110 0 0000 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.223.255.255 0000 1010 110 1 1111 1111 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.192.0.1 through 10.223.255.254

Table D-6 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The second octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 224 = 32 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 192 is the multiple of 32 that’s closest

to 200 but not larger than 200. So, the second octet of the subnet number is 192.

ptg13046388

10 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-6 Question 2: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4 Comments

Address 10 200 10 18 N/A

Mask 255 224 0 0 N/A

Subnet number 10 192 0 0 Magic number = 256 – 224 =

First valid address 10 192 0 1 Add 1 to last octet of subnet

Broadcast 10 223 255 255 192 + 32 – 1 = 223

Last valid address 10 223 255 254 Subtract 1 from last octet

Subnet rule: Multiple of magic number closest to, but not more than, IP address value in interesting octet

Broadcast rule: Subnet + magic – 1

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 192 +

32 – 1 = 223.

Question 3: Answer

Table D-7 Question 3: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.100.18.18 N/A

Mask 255.240.0.0 N/A

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 20 Always defined as number of binary 0s in

mask

Number of subnet bits 4 32 – (network size + host size)

Number of subnets 2 4 – 2 = 14 2

number-of-subnet-bits – 2

Number of hosts 2 20 – 2 = 1,048,574 2

number-of-host-bits – 2

ptg13046388

Appendix D: IP Addressing Practice 11

The binary calculations of the subnet number and broadcast address are shown in Table

D-8 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

Table D-8 Question 3: Binary Calculation of Subnet and Broadcast Addresses

Address 10.100.18.18 0000 1010 0110 0100 0001 00100001 0010

Mask 255.240.0.0 1111 1111 1111 0000 0000 0000 0000 0000

AND result (subnet

number)

10.96.0.0 0000 1010 0110 0000 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.111.255.255 0000 1010 0110 1111 1111 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.96.0.1 through 10.111.255.254

Table D-9 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-9 Question 3: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4 Comments

Address 10 100 18 18 N/A

Mask 255 240 0 0 N/A

Subnet number 10 96 0 0 Magic number = 256 – 240 =

First valid address 10 96 0 1 Add 1 to last octet of subnet

Broadcast 10 111 255 255 96 + 16 – 1 = 111

Last valid address 10 111 255 254 Subtract 1 from last octet

Subnet rule: Multiple of magic number closest to, but not more than, IP address value in interesting octet

Broadcast rule: Subnet + magic – 1

ptg13046388

12 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The second octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 240 = 16 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 96 is the multiple of 16 that’s closest

to 100 but not larger than 100. So, the second octet of the subnet number is 96.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 96 +

16 – 1 = 111.

Question 4: Answer

Table D-10 Question 4: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.100.18.18 N/A

Mask 255.248.0.0 N/A

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 19 Always defined as number of binary 0s in

mask

Number of subnet bits 5 32 – (network size + host size)

Number of subnets 2 5 – 2 = 30 2

number-of-subnet-bits – 2

Number of hosts 2 19 – 2 = 524,286 2

number-of-host-bits – 2

The binary calculations of the subnet number and broadcast address are shown in Table

D-11 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

Table D-11 Question 4: Binary Calculation of Subnet and Broadcast Addresses

Address 10.100.18.18 0000 1010 0110 0 100 0001 00100001 0010

Mask 255.248.0.0 1111 1111 1111 1 000 0000 0000 0000 0000

AND result (subnet

number)

10.96.0.0 0000 1010 0110 0 000 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.103.255.255 0000 1010 0110 0 111 1111 1111 1111 1111

ptg13046388

Appendix D: IP Addressing Practice 13

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.96.0.1 through 10.103.255.254

Table D-12 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-12 Question 4: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4 Comments

Address 10 100 18 18 N/A

Mask 255 248 0 0 N/A

Subnet number 10 96 0 0 Magic number = 256 – 248 = 8

First valid address 10 96 0 1 Add 1 to last octet of subnet

Broadcast 10 103 255 255 96 + 8 – 1 = 103

Last valid address 10 103 255 254 Subtract 1 from last octet

Subnet rule: Multiple of magic number closest to, but not more than, IP address value in interesting octet

Broadcast rule: Subnet + magic – 1

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The second octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 248 = 8 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 96 is the multiple of 8 that’s closest to

100 but not larger than 100. So, the second octet of the subnet number is 96.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 96 +

8 – 1 = 103.

ptg13046388

14 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Question 5: Answer

Table D-13 Question 5: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.150.200.200 N/A

Mask 255.252.0.0 N/A

Number of network

bits

8 Always defined by Class A, B, C

Number of host bits 18 Always defined as number of binary 0s in mask

Number of subnet

bits

6 32 – (network size + host size)

Number of subnets 2 6 – 2 = 62 2

number-of-subnet-bits – 2

Number of hosts 2 18 – 2 = 262,142 2

number-of-host-bits – 2

The binary calculations of the subnet number and broadcast address are shown in Table

D-14 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

Table D-14 Question 5: Binary Calculation of Subnet and Broadcast Addresses

Address 10.150.200.200 0000 1010 1001 01 10 1100 1000 1100 1000

Mask 255.252.0.0 1111 1111 1111 11 00 0000 0000 0000 0000

AND result (subnet

number)

10.148.0.0 0000 1010 0110 01 00 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.151.255.255 0000 1010 0110 01 11 1111 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.148.0.1 through 10.151.255.254

Table D-15 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

ptg13046388

Appendix D: IP Addressing Practice 15

Table D-15 Question 5: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4 Comments

Address 10 150 200 200 N/A

Mask 255 252 0 0 N/A

Subnet number 10 148 0 0 Magic number = 256 – 252 = 4

First valid

address

10 148 0 1 Add 1 to last octet of subnet

Broadcast 10 151 255 255 148 + 4 – 1 = 151

Last valid

address

10 151 255 254 Subtract 1 from last octet

Subnet rule: Multiple of magic number closest to, but not more than, IP address value in interesting octet

Broadcast rule: Subnet + magic – 1

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The second octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 252 = 4 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 148 is the multiple of 4 that’s closest

to 150 but not larger than 150. So, the second octet of the subnet number is 148.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 148 +

4 – 1 = 151.

Question 6: Answer

Table D-16 Question 6: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.150.200.200 N/A

Mask 255.254.0.0 N/A

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 17 Always defined as number of binary 0s in

mask

ptg13046388

16 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step Example Rules to Remember

Number of subnet bits 7 32 – (network size + host size)

Number of subnets 2 7 – 2 = 126 2

number-of-subnet-bits – 2

Number of hosts 2 17 – 2 = 131,070 2

number-of-host-bits – 2

The binary calculations of the subnet number and broadcast address are shown in Table

D-17 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

Table D-17 Question 6: Binary Calculation of Subnet and Broadcast Addresses

Address 10.150.200.200 0000 1010 1001 011 0 1100 1000 1100 1000

Mask 255.254.0.0 1111 1111 1111 111 0 0000 0000 0000 0000

AND result (subnet

number)

10.150.0.0 0000 1010 0110 011 0 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.151.255.255 0000 1010 0110 011 1 1111 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.150.0.1 through 10.151.255.254

Table D-18 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-18 Question 6: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 10 150 200 200

Mask 255 254 0 0

Subnet number 10 150 0 0

First valid address 10 150 0 1

Broadcast 10 151 255 255

Last valid address 10 151 255 254

ptg13046388

Appendix D: IP Addressing Practice 17

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The second octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 254 = 2 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 150 is the multiple of 2 that’s closest

to 150 but not larger than 150. So, the second octet of the subnet number is 150.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 150 +

2 – 1 = 151.

Question 7: Answer

Table D-19 Question 7: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.220.100.18 N/A

Mask 255.255.0.0 N/A

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 16 Always defined as number of binary 0s in

mask

Number of subnet bits 8 32 – (network size + host size)

Number of subnets 2 8 – 2 = 254 2

number-of-subnet-bits – 2

Number of hosts 2 16 – 2 = 65,534 2

number-of-host-bits – 2

The binary calculations of the subnet number and broadcast address are shown in Table

D-20 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

Table D-20 Question 7: Binary Calculation of Subnet and Broadcast Addresses

Address 10.220.100.18 0000 1010 1101 1100 0110 0100 0001 0010

Mask 255.255.0.0 1111 1111 1111 1111 0000 0000 0000 0000

AND result (subnet

number)

10.220.0.0 0000 1010 1101 1100 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.220.255.255 0000 1010 1101 1100 1111 1111 1111 1111

ptg13046388

18 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.220.0.1 through 10.220.255.254

Table D-21 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 .

Table D-21 Question 7: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 10 220 100 18

Mask 255 255 0 0

Subnet number 10 220 0 0

First valid address 10 220 0 1

Broadcast 10 220 255 255

Last valid address 10 220 255 254

This subnetting scheme uses an easy mask because all the octets are a 0 or a 255. No

math tricks are needed!

Question 8: Answer

Table D-22 Question 8: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.220.100.18 N/A

Mask 255.255.128.0 N/A

Number of network

bits

8 Always defined by Class A, B, C

Number of host bits 15 Always defined as number of binary 0s in mask

Number of subnet bits 9 32 – (network size + host size)

Number of subnets 2 9 – 2 = 510 2

number-of-subnet-bits – 2

Number of hosts 2 15 – 2 = 32,766 2

number-of-host-bits – 2

ptg13046388

Appendix D: IP Addressing Practice 19

The binary calculations of the subnet number and broadcast address are shown in Table

D-23 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

Table D-23 Question 8: Binary Calculation of Subnet and Broadcast Addresses

Address 10.220.100.18 0000 1010 1101 1100 0 110 0100 0001 0010

Mask 255.255.128.0 1111 1111 1111 1111 1 000 0000 0000 0000

AND result (subnet

number)

10.220.0.0 0000 1010 1101 1100 0 000 0000 0000 0000

Change host to 1s

(broadcast address)

10.220.127.255 0000 1010 1101 1100 0 111 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.220.0.1 through 10.220.127.254

Table D-24 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-24 Question 8: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 10 220 100 18

Mask 255 255 128 0

Subnet number 10 220 0 0

First valid address 10 220 0 1

Broadcast 10 220 127 255

Last valid address 10 220 127 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 128 = 128 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 0 is the multiple of 128 that’s closest

to 100 but not larger than 100. So, the third octet of the subnet number is 0.

ptg13046388

20 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 0 +

128 – 1 = 127.

This example tends to confuse people because a mask with 128 in it gives you subnet

numbers that just do not seem to look right. Table D-25 gives you the answers for the

first several subnets, just to make sure that you are clear about the subnets when using

this mask with a Class A network.

Table D-25 Question 8: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Zero Subnet First Valid

Subnet

Second Valid

Subnet

Third Valid

Subnet

Subnet 10.0.0.0 10.0.128.0 10.1.0.0 10.1.128.0

First address 10.0.0.1 10.0.128.1 10.1.0.1 10.1.128.1

Last address 10.0.127.254 10.0.255.254 10.1.127.254 10.1.255.254

Broadcast 10.0.127.255 10.0.255.255 10.1.127.255 10.1.255.255

Question 9: Answer

Table D-26 Question 9: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.100.100 N/A

Mask 255.255.192.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 14 Always defined as number of binary 0s in

mask

Number of subnet bits 2 32 – (network size + host size)

Number of subnets 2 2 – 2 = 2 2

number-of-subnet-bits – 2

Number of hosts 2 14 – 2 = 16,382 2

number-of-host-bits – 2

The binary calculations of the subnet number and broadcast address are shown in Table

D-27 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

ptg13046388

Appendix D: IP Addressing Practice 21

Table D-27 Question 9: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.100.100 1010 1100 0001 1111 01 10 0100 0110 0100

Mask 255.255.192.0 1111 1111 1111 1111 11 00 0000 0000 0000

AND result (subnet

number)

172.31.64.0 1010 1100 0001 1111 01 00 0000 0000 0000

Change host to 1s

(broadcast address)

172.31.127.255 1010 1100 0001 1111 01 11 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.64.1 through 172.31.127.254

Table D-28 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-28 Question 9: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 100 100

Mask 255 255 192 0

Subnet number 172 31 64 0

First valid address 172 31 64 1

Broadcast 172 31 127 255

Last valid address 172 31 127 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 192 = 64 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 64 is the multiple of 64 that’s closest

to 100 but not larger than 100. So, the third octet of the subnet number is 64.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 64 +

64 – 1 = 127.

ptg13046388

22 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Question 10: Answer

Table D-29 Question 10: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.100.100 N/A

Mask 255.255.224.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 13 Always defined as number of binary 0s in mask

Number of subnet bits 3 32 – (network size + host size)

Number of subnets 2 3 – 2 = 6 2

number-of-subnet-bits – 2

Number of hosts 2 13 – 2 = 8190 2

number-of-host-bits – 2

The binary calculations of the subnet number and broadcast address are shown in Table

D-30 . To calculate the subnet number, perform a Boolean AND of the address with the

subnet mask. To find the broadcast address for this subnet, change all the host bits to

binary 1s in the subnet number. The host bits are in bold print in the table.

Table D-30 Question 10: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.100.100 1010 1100 0001 1111 011 0 0100 0110 0100

Mask 255.255.224.0 1111 1111 1111 1111 111 0 0000 0000 0000

AND result (subnet

number)

172.31.96.0 1010 1100 0001 1111 011 0 0000 0000 0000

Change host to 1s

(broadcast address)

172.31.127.255 1010 1100 0001 1111 011 1 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.96.1 through 172.31.127.254

Table D-31 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

ptg13046388

Appendix D: IP Addressing Practice 23

Table D-31 Question 10: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 100 100

Mask 255 255 224 0

Subnet number 172 31 96 0

First valid address 172 31 96 1

Broadcast 172 31 127 255

Last valid address 172 31 127 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 224 = 32 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 96 is the multiple of 32 that’s closest

to 100 but not larger than 100. So, the third octet of the subnet number is 96.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 96 +

32 – 1 = 127.

Question 11: Answer

Table D-32 Question 11: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.200.10 N/A

Mask 255.255.240.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 12 Always defined as number of binary 0s in

mask

Number of subnet bits 4 32 – (network size + host size)

Number of subnets 2 4 – 2 = 14 2

number-of-subnet-bits – 2

Number of hosts 2 12 – 2 = 4094 2

number-of-host-bits – 2

ptg13046388

24 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-33 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-33 Question 11: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.200.10 1010 1100 0001 1111 1100 1000 0000 1010

Mask 255.255.240.0 1111 1111 1111 1111 1111 0000 0000 0000

AND result (subnet

number)

172.31.192.0 1010 1100 0001 1111 1100 0000 0000 0000

Change host to 1s

(broadcast address)

172.31.207.255 1010 1100 0001 1111 1100 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.192.1 through 172.31.207.254

Table D-34 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-34 Question 11: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 200 10

Mask 255 255 240 0

Subnet number 172 31 192 0

First valid address 172 31 192 1

Broadcast 172 31 207 255

Last valid address 172 31 207 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 240 = 16 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 192 is the multiple of 16 that’s closest

to 200 but not larger than 200. So, the third octet of the subnet number is 192.

ptg13046388

Appendix D: IP Addressing Practice 25

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 192 +

16 – 1 = 207.

Question 12: Answer

Table D-35 Question 12: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.200.10 N/A

Mask 255.255.248.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 11 Always defined as number of binary 0s in mask

Number of subnet bits 5 32 – (network size + host size)

Number of subnets 2 5 – 2 = 30 2

number-of-subnet-bits – 2

Number of hosts 2 11 – 2 = 2046 2

number-of-host-bits – 2

Table D-36 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-36 Question 12: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.200.10 1010 1100 0001 1111 1100 1 000 0000 1010

Mask 255.255.248.0 1111 1111 1111 1111 1111 1 000 0000 0000

AND result (subnet

number)

172.31.200.0 1010 1100 0001 1111 1100 1 000 0000 0000

Change host to 1s

(broadcast address)

172.31.207.255 1010 1100 0001 1111 1100 1 111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.200.1 through 172.31.207.254

Table D-37 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

ptg13046388

26 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-37 Question 12: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 200 10

Mask 255 255 248 0

Subnet number 172 31 200 0

First valid address 172 31 200 1

Broadcast 172 31 207 255

Last valid address 172 31 207 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 248 = 8 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 200 is the multiple of 8 that’s closest

to 200 but not larger than 200. So, the third octet of the subnet number is 200.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 200 +

8 – 1 = 207.

Question 13: Answer

Table D-38 Question 13: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.50.50 N/A

Mask 255.255.252.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 10 Always defined as number of binary 0s in mask

Number of subnet bits 6 32 – (network size + host size)

Number of subnets 2 6 – 2 = 62 2

number-of-subnet-bits – 2

Number of hosts 2 10 – 2 = 1022 2

number-of-host-bits – 2

ptg13046388

Appendix D: IP Addressing Practice 27

Table D-39 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-39 Question 13: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.50.50 1010 1100 0001 1111 0011 00 10 0011 0010

Mask 255.255.252.0 1111 1111 1111 1111 1111 11 00 0000 0000

AND result (subnet

number)

172.31.48.0 1010 1100 0001 1111 0011 00 00 0000 0000

Change host to 1s

(broadcast address)

172.31.51.255 1010 1100 0001 1111 0011 00 11 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.48.1 through 172.31.51.254

Table D-40 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-40 Question 13: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 50 50

Mask 255 255 252 0

Subnet number 172 31 48 0

First valid address 172 31 48 1

Broadcast 172 31 51 255

Last valid address 172 31 51 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 252 = 4 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 48 is the multiple of 4 that’s closest to

50 but not larger than 50. So, the third octet of the subnet number is 48.

ptg13046388

28 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 48 +

4 – 1 = 51.

Question 14: Answer

Table D-41 Question 14: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.50.50 N/A

Mask 255.255.254.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 9 Always defined as number of binary 0s in mask

Number of subnet bits 7 32 – (network size + host size)

Number of subnets 2 7 – 2 = 126 2

number-of-subnet-bits – 2

Number of hosts 2 9 – 2 = 510 2

number-of-host-bits – 2

Table D-42 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-42 Question 14: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.50.50 1010 1100 0001 1111 0011 001 0 0011 0010

Mask 255.255.254.0 1111 1111 1111 1111 1111 111 0 0000 0000

AND result (subnet

number)

172.31.50.0 1010 1100 0001 1111 0011 001 0 0000 0000

Change host to 1s

(broadcast address)

172.31.51.255 1010 1100 0001 1111 0011 001 1 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.50.1 through 172.31.51.254

Table D-43 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

ptg13046388

Appendix D: IP Addressing Practice 29

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-43 Question 14: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 50 50

Mask 255 255 254 0

Subnet number 172 31 50 0

First valid address 172 31 50 1

Broadcast 172 31 51 255

Last valid address 172 31 51 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 254 = 2 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 50 is the multiple of 2 that’s closest to

50 but not larger than 50. So, the third octet of the subnet number is 50.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 50 +

2 – 1 = 51.

Question 15: Answer

Table D-44 Question 15: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.140.14 N/A

Mask 255.255.255.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 8 Always defined as number of binary 0s in mask

Number of subnet bits 8 32 – (network size + host size)

Number of subnets 2 8 – 2 = 254 2

number-of-subnet-bits – 2

Number of hosts 2 8 – 2 = 254 2

number-of-host-bits – 2

ptg13046388

30 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-45 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-45 Question 15: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.140.14 1010 1100 0001 1111 1000 1100 0000 1110

Mask 255.255.255.0 1111 1111 1111 1111 1111 1111 0000 0000

AND result (subnet

number)

172.31.140.0 1010 1100 0001 1111 1000 1100 0000 0000

Change host to 1s

(broadcast address)

172.31.140.255 1010 1100 0001 1111 1000 1100 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.140.1 through 172.31.140.254

Table D-46 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 .

Table D-46 Question 15: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 140 14

Mask 255 255 255 0

Subnet number 172 31 140 0

First valid address 172 31 140 1

Broadcast 172 31 140 255

Last valid address 172 31 140 254

This subnetting scheme uses an easy mask because all the octets are a 0 or a 255. No

math tricks are needed!

ptg13046388

Appendix D: IP Addressing Practice 31

Question 16: Answer

Table D-47 Question 16: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.31.140.14 N/A

Mask 255.255.255.128 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 7 Always defined as number of binary 0s in mask

Number of subnet bits 9 32 – (network size + host size)

Number of subnets 2 9 – 2 = 510 2

number-of-subnet-bits – 2

Number of hosts 2 7 – 2 = 126 2

number-of-host-bits – 2

Table D-48 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-48 Question 16: Binary Calculation of Subnet and Broadcast Addresses

Address 172.31.140.14 1010 1100 0001 1111 1000 1100 0 000 1110

Mask 255.255.255.128 1111 1111 1111 1111 1111 1111 1 000 0000

AND result (subnet

number)

172.31.140.0 1010 1100 0001 1111 1000 1100 0 000 0000

Change host to 1s

(broadcast address)

172.31.140.127 1010 1100 0001 1111 1000 1100 0 111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.31.140.1 through 172.31.140.126

Table D-49 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

ptg13046388

32 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-49 Question 16: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 31 140 14

Mask 255 255 255 128

Subnet number 172 31 140 0

First valid address 172 31 140 1

Broadcast 172 31 140 127

Last valid address 172 31 140 126

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The fourth octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 128 = 128 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 0 is the multiple of 128 that’s closest

to 14 but not larger than 14. So, the fourth octet of the subnet number is 0.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 0 +

128 – 1 = 127.

Question 17: Answer

Table D-50 Question 17: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 192.168.15.150 N/A

Mask 255.255.255.192 N/A

Number of network bits 24 Always defined by Class A, B, C

Number of host bits 6 Always defined as number of binary 0s in mask

Number of subnet bits 2 32 – (network size + host size)

Number of subnets 2 2 – 2 = 2 2

number-of-subnet-bits – 2

Number of hosts 2 6 – 2 = 62 2

number-of-host-bits – 2

ptg13046388

Appendix D: IP Addressing Practice 33

Table D-51 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-51 Question 17: Binary Calculation of Subnet and Broadcast Addresses

Address 192.168.15.150 1100 0000 1010 1000 0000 1111 10 01 0110

Mask 255.255.255.192 1111 1111 1111 1111 1111 1111 11 00 0000

AND result (subnet

number)

192.168.15.128 1100 0000 1010 1000 0000 1111 10 00 0000

Change host to 1s

(broadcast address)

192.168.15.191 1100 0000 1010 1000 0000 1111 10 11 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

192.168.15.129 through 192.168.15.190

Table D-52 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-52 Question 17: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 192 168 15 150

Mask 255 255 255 192

Subnet number 192 168 15 128

First valid address 192 168 15 129

Broadcast 192 168 15 191

Last valid address 192 168 15 190

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The fourth octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 192 = 64 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 128 is the multiple of 64 that’s closest

to 150 but not larger than 150. So, the fourth octet of the subnet number is 128.

ptg13046388

34 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 128 +

64 – 1 = 191.

Question 18: Answer

Table D-53 Question 18: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 192.168.15.150 N/A

Mask 255.255.255.224 N/A

Number of network bits 24 Always defined by Class A, B, C

Number of host bits 5 Always defined as number of binary 0s in mask

Number of subnet bits 3 32 – (network size +host size)

Number of subnets 2 3 – 2 = 6 2

number-of-subnet-bits – 2

Number of hosts 2 5 – 2 = 30 2

number-of-host-bits – 2

Table D-54 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-54 Question 18: Binary Calculation of Subnet and Broadcast Addresses

Address 192.168.15.150 1100 0000 1010 1000 0000 1111 100 1 0110

Mask 255.255.255.224 1111 1111 1111 1111 1111 1111 111 0 0000

AND result (subnet

number)

192.168.15.128 1100 0000 1010 1000 0000 1111 100 0 0000

Change host to 1s

(broadcast address)

192.168.15.159 1100 0000 1010 1000 0000 1111 100 1 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

192.168.15.129 through 192.168.15.158

Table D-55 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

ptg13046388

Appendix D: IP Addressing Practice 35

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-55 Question 18: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 192 168 15 150

Mask 255 255 255 224

Subnet number 192 168 15 128

First valid address 192 168 15 129

Broadcast 192 168 15 159

Last valid address 192 168 15 158

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The fourth octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 224 = 32 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 128 is the multiple of 32 that’s closest

to 150 but not larger than 150. So, the fourth octet of the subnet number is 128.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 128 +

32 – 1 = 159.

Question 19: Answer

Table D-56 Question 19: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 192.168.100.100 N/A

Mask 255.255.255.240 N/A

Number of network

bits

24 Always defined by Class A, B, C

Number of host bits 4 Always defined as number of binary 0s in mask

Number of subnet bits 4 32 – (network size + host size)

ptg13046388

36 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step Example Rules to Remember

Number of subnets 2 4 – 2 = 14 2

number-of-subnet-bits – 2

Number of hosts 2 4 – 2 = 14 2

number-of-host-bits – 2

Table D-57 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-57 Question 19: Binary Calculation of Subnet and Broadcast Addresses

Address 192.168.100.100 1100 0000 1010 1000 0110 0100 0110 0100

Mask 255.255.255.240 1111 1111 1111 1111 1111 1111 1111 0000

AND result (subnet

number)

192.168.100.96 1100 0000 1010 1000 0110 0100 0110 0000

Change host to 1s

(broadcast address)

192.168.100.111 1100 0000 1010 1000 0110 0100 0110 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

192.168.100.97 through 192.168.100.110

Table D-58 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-58 Question 19: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 192 168 100 100

Mask 255 255 255 240

Subnet number 192 168 100 96

First valid address 192 168 100 97

Broadcast 192 168 100 111

Last valid address 192 168 100 110

ptg13046388

Appendix D: IP Addressing Practice 37

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The fourth octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 240 = 16 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 96 is the multiple of 16 that’s closest

to 100 but not larger than 100. So, the fourth octet of the subnet number is 96.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 96 +

16 – 1 = 111.

Question 20: Answer

Table D-59 Question 20: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 192.168.100.100 N/A

Mask 255.255.255.248 N/A

Number of network bits 24 Always defined by Class A, B, C

Number of host bits 3 Always defined as number of binary 0s in mask

Number of subnet bits 5 32 – (network size + host size)

Number of subnets 2 5 – 2 = 30 2

number-of-subnet-bits – 2

Number of hosts 2 3 – 2 = 6 2

number-of-host-bits – 2

Table D-60 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-60 Question 20: Binary Calculation of Subnet and Broadcast Addresses

Address 192.168.100.100 1100 0000 1010 1000 0110 0100 0110 0 100

Mask 255.255.255.248 1111 1111 1111 1111 1111 1111 1111 1 000

AND result (subnet

number)

192.168.100.96 1100 0000 1010 1000 0110 0100 0110 0 000

Change host to 1s

(broadcast address)

192.168.100.103 1100 0000 1010 1000 0110 0100 0110 0 111

ptg13046388

38 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

192.168.100.97 through 192.168.100.102

Table D-61 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-61 Question 20: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 192 168 100 100

Mask 255 255 255 248

Subnet number 192 168 100 96

First valid address 192 168 100 97

Broadcast 192 168 100 103

Last valid address 192 168 100 102

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The fourth octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 248 = 8 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 96 is the multiple of 8 that’s closest to

100 but not larger than 100. So, the fourth octet of the subnet number is 96.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 96 +

8 – 1 = 103.

ptg13046388

Appendix D: IP Addressing Practice 39

Question 21: Answer

Table D-62 Question 21: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 192.168.15.230 N/A

Mask 255.255.255.252 N/A

Number of network bits 24 Always defined by Class A, B, C

Number of host bits 2 Always defined as number of binary 0s in mask

Number of subnet bits 6 32 – (network size + host size)

Number of subnets 2 6 – 2 = 62 2

number-of-subnet-bits – 2

Number of hosts 2 2 – 2 = 2 2

number-of-host-bits – 2

Table D-63 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-63 Question 21: Binary Calculation of Subnet and Broadcast Addresses

Address 192.168.15.230 1100 0000 1010 1000 0000 1111 1110 01 10

Mask 255.255.255.252 1111 1111 1111 1111 1111 1111 1111 11 00

AND result (subnet

number)

192.168.15.228 1100 0000 1010 1000 0000 1111 1110 01 00

Change host to 1s

(broadcast address)

192.168.15.231 1100 0000 1010 1000 0000 1111 1110 01 11

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

192.168.15.229 through 192.168.15.230

Table D-64 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

ptg13046388

40 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-64 Question 21: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 192 168 15 230

Mask 255 255 255 252

Subnet number 192 168 15 228

First valid address 192 168 15 229

Broadcast 192 168 15 231

Last valid address 192 168 15 230

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The fourth octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 252 = 4 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 228 is the multiple of 4 that’s closest

to 230 but not larger than 230. So, the fourth octet of the subnet number is 228.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 228 +

4 – 1 = 231.

Question 22: Answer

Table D-65 Question 22: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.1.1.1 N/A

Mask 255.248.0.0 N/A

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 19 Always defined as number of binary 0s in

mask

Number of subnet bits 5 32 – (network size + host size)

Number of subnets 2 5 – 2 = 30 2

number-of-subnet-bits – 2

Number of hosts 2 19 – 2 = 524,286 2

number-of-host-bits – 2

ptg13046388

Appendix D: IP Addressing Practice 41

Table D-66 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-66 Question 22: Binary Calculation of Subnet and Broadcast Addresses

Address 10.1.1.1 0000 1010 0000 0 001 0000 0001 0000 0001

Mask 255.248.0.0 1111 1111 1111 1 000 0000 0000 0000 0000

AND result (subnet

number)

10.0.0.0 0000 1010 0000 0 000 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.7.255.255 0000 1010 0000 0 111 1111 1111 1111 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.0.0.1 through 10.7.255.254

Take a closer look at the subnet part of the subnet address, as is shown in bold here: 0000

1010 0000 0 000 0000 0000 0000 0000. The subnet part of the address is all binary 0s,

making this subnet a zero subnet.

Table D-67 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-67 Question 22: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 10 1 1 1

Mask 255 248 0 0

Subnet number 10 0 0 0

First valid address 10 0 0 1

Broadcast 10 7 255 255

Last valid address 10 7 255 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The second octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 248 = 8 in this case (256 –

ptg13046388

42 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 0 is the multiple of 8 that’s closest to

1 but not larger than 1. So, the second octet of the subnet number is 0.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 0 +

8 – 1 = 7.

Question 23: Answer

Table D-68 Question 23: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.16.1.200 N/A

Mask 255.255.240.0 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 12 Always defined as number of binary 0s in

mask

Number of subnet bits 4 32 – (network size + host size)

Number of subnets 2 4 – 2 = 14 2

number-of-subnet-bits – 2

Number of hosts 2 12 – 2 = 4094 2

number-of-host-bits – 2

Table D-69 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-69 Question 23: Binary Calculation of Subnet and Broadcast Addresses

Address 172.16.1.200 1010 1100 0001 0000 0000 0001 1100 1000

Mask 255.255.240.0 1111 1111 1111 1111 1111 0000 0000 0000

AND result (subnet

number)

172.16.0.0 1010 1100 0001 0000 0000 0000 0000 0000

Change host to 1s

(broadcast address)

172.16.15.255 1010 1100 0001 0000 0000 1111 1111 1111

ptg13046388

Appendix D: IP Addressing Practice 43

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.16.0.1 through 172.16.15.254

Take a closer look at the subnet part of the subnet address, as shown in bold here: 1010

1100 0001 0000 0000 0000 0000 0000. The subnet part of the address is all binary 0s,

making this subnet a zero subnet.

Table D-70 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

Table D-70 Question 23: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 16 1 200

Mask 255 255 240 0

Subnet number 172 16 0 0

First valid address 172 16 0 1

Broadcast 172 16 15 255

Last valid address 172 16 15 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The third octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 240 = 16 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 0 is the multiple of 16 that’s closest to

1 but not larger than 1. So, the third octet of the subnet number is 0.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 0 +

16 – 1 = 15.

ptg13046388

44 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Question 24: Answer

Table D-71 Question 24: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 172.16.0.200 N/A

Mask 255.255.255.192 N/A

Number of network bits 16 Always defined by Class A, B, C

Number of host bits 6 Always defined as number of binary 0s in

mask

Number of subnet bits 10 32 – (network size + host size)

Number of subnets 2 10 – 2 = 1022 2

number-of-subnet-bits – 2

Number of hosts 2 6 – 2 = 62 2

number-of-host-bits – 2

Table D-72 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-72 Question 24: Binary Calculation of Subnet and Broadcast Addresses

Address 172.16.0.200 1010 1100 0001 0000 0000 0000 11 00 1000

Mask 255.255.255.192 1111 1111 1111 1111 1111 1111 11 00 0000

AND result (subnet

number)

172.16.0.192 1010 1100 0001 0000 0000 0000 11 00 0000

Change host to 1s

(broadcast address)

172.16.0.255 1010 1100 0001 0000 0000 0000 11 11 1111

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

172.16.0.193 through 172.16.0.254

Table D-73 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 . Remember, subtracting the interesting (non-0 or 255) mask value

from 256 yields the magic number. The magic number multiple that’s closest to but not

larger than the IP address’s interesting octet value is the subnet value in that octet.

ptg13046388

Appendix D: IP Addressing Practice 45

Table D-73 Question 24: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 172 16 0 200

Mask 255 255 255 192

Subnet number 172 16 0 192

First valid address 172 16 0 193

Broadcast 172 16 0 255

Last valid address 172 16 0 254

This subnetting scheme uses a hard mask because one of the octets is not a 0 or a 255.

The fourth octet is “interesting” in this case. The key part of the trick to get the right

answers is to calculate the magic number, which is 256 – 192 = 64 in this case (256 –

mask’s value in the interesting octet). The subnet number’s value in the interesting octet

(inside the box) is the multiple of the magic number that’s not larger than the original IP

address’s value in the interesting octet. In this case, 192 is the multiple of 64 that’s closest

to 200 but not larger than 200. So, the fourth octet of the subnet number is 192.

The second tricky part of this process calculates the subnet broadcast address. The full

process is described in Chapter 4 , but the tricky part is, as usual, in the “interesting”

octet. Take the subnet number’s value in the interesting octet, add the magic number, and

subtract 1. That’s the broadcast address’s value in the interesting octet. In this case, 192 +

64 – 1 = 255.

You can easily forget that the subnet part of this address, when using this mask, actu-

ally covers all the third octet as well as 2 bits of the fourth octet. For example, the valid

subnet numbers in order are listed here, starting with the first valid subnet by avoiding

subnet 172.16.0.0—the zero subnet in this case:

172.16.0.64

172.16.0.128

172.16.0.192

172.16.1.0

172.16.1.64

172.16.1.128

172.16.1.192

172.16.2.0

172.16.2.64

172.16.2.128

172.16.2.192

ptg13046388

46 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

172.16.3.0

172.16.3.64

172.16.3.128

172.16.3.192

And so on.

Question 25: Answer

Congratulations, you made it through all the extra subnetting practice! Here’s an easy one

to complete your review—one with no subnetting at all!

Table D-74 Question 25: Size of Network, Subnet, Host, Number of Subnets, Number of

Hosts

Step Example Rules to Remember

Address 10.1.1.1 N/A

Mask 255.0.0.0 N/A

Number of network bits 8 Always defined by Class A, B, C

Number of host bits 24 Always defined as number of binary 0s in

mask

Number of subnet bits 0 32 – (network size + host size)

Number of subnets 0 2 number-of-subnet-bits – 2

Number of hosts 2 24 – 2 = 16,777,214 2

number-of-host-bits – 2

Table D-75 shows the binary calculations of the subnet number and broadcast address.

To calculate the subnet number, perform a Boolean AND of the address with the subnet

mask. To find the broadcast address for this subnet, change all the host bits to binary 1s

in the subnet number. The host bits are in bold print in the table.

Table D-75 Question 25: Binary Calculation of Subnet and Broadcast Addresses

Address 10.1.1.1 0000 1010 0000 0001 0000 0001 0000 0001

Mask 255.0.0.0 1111 1111 0000 0000 0000 0000 0000 0000

AND result (subnet

number)

10.0.0.0 0000 1010 0000 0000 0000 0000 0000 0000

Change host to 1s

(broadcast address)

10.255.255.255 0000 1010 1111 1111 1111 1111 1111 1111

ptg13046388

Appendix D: IP Addressing Practice 47

Just add 1 to the subnet number to get the first valid IP address; just subtract 1 from the

broadcast address to get the last valid IP address. In this case:

10.0.0.1 through 10.255.255.254

Table D-76 lists the way to get the same answers using the subnet chart and magic math

described in Chapter 4 .

Table D-76 Question 25: Subnet, Broadcast, and First and Last Addresses Calculated

Using Subnet Chart

Octet 1 Octet 2 Octet 3 Octet 4

Address 10 1 1 1

Mask 255 0 0 0

Network number 10 0 0 0

First valid address 10 0 0 1

Broadcast 10 255 255 255

Last valid address 10 255 255 254

Discovering All Subnets When Using SLSM: 13

Questions

This section covers the second class of IP addressing problems mentioned in the intro-

duction to this appendix. The question is as follows:

Assuming SLSM, what are the subnets of this network?

For practice, answer that question for the following networks and masks:

1. 10.0.0.0, mask 255.192.0.0

2. 10.0.0.0, mask 255.224.0.0

3. 10.0.0.0, mask 255.248.0.0

4. 10.0.0.0, mask 255.252.0.0

5. 10.0.0.0, mask 255.255.128.0

6. 10.0.0.0, mask 255.255.192.0

7. 172.31.0.0, mask 255.255.224.0

8. 172.31.0.0, mask 255.255.240.0

9. 172.31.0.0, mask 255.255.252.0

10. 172.31.0.0, mask 255.255.255.224

ptg13046388

48 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

11. 192.168.15.0, mask 255.255.255.192

12. 192.168.15.0, mask 255.255.255.224

13. 192.168.15.0, mask 255.255.255.240

These questions are mostly a subset of the same 25 subnetting questions covered in

the first section of this appendix. The explanations of the answers will be based on

the seven-step algorithm from Chapter 4 , repeated here for convenience. Also, keep in

mind that this formal algorithm assumes that the subnet field is 8 bits in length or less.

However, some problems in this appendix have a longer subnet field. For those problems,

the answer explains how to expand the logic in this baseline algorithm.

Step 1. Write the classful network number.

Step 2. For the first (lowest numeric) subnet number, copy the entire network num-

ber. That is the first subnet number, and is also the zero subnet.

Step 3. Decide which octet contains the entire subnet field; call this octet the inter-

esting octet. (Remember, this algorithm assumes 8 subnet bits or less.)

Step 4. Calculate the magic number by subtracting the mask’s interesting octet value

from 256.

Step 5. Copy the previous subnet number’s noninteresting octets onto the next line as

the next subnet number; only one octet is missing at this point.

Step 6. Add the magic number to the previous subnet’s interesting octet, and write

that as the next subnet number’s interesting octet, completing the next subnet

number.

Step 7. Repeat Steps 5 and 6 until the new interesting octet is 256. That subnet is not

valid. The previously calculated subnet is the last valid subnet, and also the

broadcast subnet.

Question 1: Answer

This question begins with the following basic facts:

Network 10.0.0.0

Mask 255.192.0.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 2nd

Magic number: 256 – 192 = 64

From there, Table D-77 shows the rest of the steps for the process.

ptg13046388

Appendix D: IP Addressing Practice 49

Table D-77 Question 1 Answer: Network 10.0.0.0, Mask 255.192.0.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 64 0 0

6) Next subnet 10 128 0 0

6) Broadcast subnet 10 192 0 0

7) Invalid subnet* 10 256 0 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the broadcast subnet number might not have been obvious until attempting to

write the final (invalid) next subnet number, as seen in the last row of the table. You can

follow the steps shown in the table, knowing that when the interesting octet’s value is

256, you have gone too far. The broadcast subnet is the subnet that was found one step

prior.

Alternately, you can find the broadcast subnet based on the following fact: The broadcast

subnet’s interesting octet is equal to the subnet mask value in that same octet.

Question 2: Answer

This question begins with the following basic facts:

Network 10.0.0.0

Mask 255.224.0.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 2nd

Magic number: 256 – 224 = 32

From there, Table D-78 shows the rest of the steps for the process.

Table D-78 Question 2 Answer: Network 10.0.0.0, Mask 255.224.0.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 32 0 0

6) Next subnet 10 64 0 0

6) Next subnet 10 96 0 0

ptg13046388

50 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step Octet 1 Octet 2 Octet 3 Octet 4

6) Generic representation of next subnet 10 X 0 0

6) Broadcast subnet 10 224 0 0

7) Invalid subnet* 10 256 0 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the subnet numbers’ interesting octet (second octet in this case) simply incre-

ments by the magic number. To reduce the space required by the table, after the pattern is

obvious, the table represents the remaining subnet numbers before the broadcast subnet

as a generic value, 10.X.0.0. The subnets not specifically listed are 10.128.0.0, 10.160.0.0,

and 10.192.0.0.

Question 3: Answer

This question begins with the following basic facts:

Network 10.0.0.0

Mask 255.248.0.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 2nd

Magic number: 256 – 248 = 8

From there, Table D-79 shows the rest of the steps for the process.

Table D-79 Question 3 Answer: Network 10.0.0.0, Mask 255.248.0.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 8 0 0

6) Next subnet 10 16 0 0

6) Next subnet 10 24 0 0

6) Generic representation of next subnet 10 X 0 0

6) Broadcast subnet 10 248 0 0

7) Invalid subnet* 10 256 0 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

ptg13046388

Appendix D: IP Addressing Practice 51

Note that the subnet numbers’ interesting octet (second octet in this case) simply incre-

ments by the magic number. To reduce the space required by the table, after the pattern is

obvious, the table represents the remaining subnet numbers before the broadcast subnet

as a generic value, 10.X.0.0. The subnets not specifically listed simply have a multiple of 8

in the second octet.

Question 4: Answer

This question begins with the following basic facts:

Network 10.0.0.0

Mask 255.252.0.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 2nd

Magic number: 256 – 252 = 4

From there, Table D-80 shows the rest of the steps for the process.

Table D-80 Question 4 Answer: Network 10.0.0.0, Mask 255.252.0.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 4 0 0

6) Next subnet 10 8 0 0

6) Next subnet 10 12 0 0

6) Generic representation of next subnet 10 X 0 0

6) Broadcast subnet 10 252 0 0

7) Invalid subnet* 10 256 0 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the subnet numbers’ interesting octet (second octet in this case) simply incre-

ments by the magic number. To reduce the space required by the table, after the pattern is

obvious, the table represents the remaining subnet numbers before the broadcast subnet

as a generic value, 10.X.0.0. The subnets not specifically listed simply have a multiple of 4

in the second octet.

ptg13046388

52 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Question 5: Answer

This question begins with the following basic facts:

Network 10.0.0.0

Mask 255.255.128.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 3rd

Magic number: 256 – 128 = 128

This question actually uses a subnet field that spans all the second octet, and a single bit

in the third octet. As a result, the original seven-step process, which assumes a 1-octet-or-

less subnet field, cannot be used. However, an expanded process is described along with

the answer to this question.

Note Many of you might intuitively see the way to find the complete answer to this

question, long before you finish reading the revised process listed here. If you think you

are getting the idea, you probably are, so do not let the details in the text get in the way.

First, Table D-81 shows the beginning of the process, which occurs just like the earlier

examples, except that the interesting octet is now the third octet.

Table D-81 Question 5 Answer, Part 1: Network 10.0.0.0, Mask 255.255.128.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 0 128 0

7) Invalid subnet* 10 0 256 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

At this point, the last number is obviously an invalid subnet number due to the 256 in

the third octet. Instead of that fact signifying the end of the process, it means that you

should do the following:

Record the next subnet, based on the following changes to the previous valid subnet

number: Add 1 to the octet to the left of the interesting octet, and set the interesting

octet to 0.

ptg13046388

Appendix D: IP Addressing Practice 53

In this case, this new step runs as follows:

■ The previous valid subnet is 10.0.128.0.

■ Add 1 to the octet to the left of the interesting octet (value 0); the next subnet num-

ber’s second octet will then be 1.

■ The next subnet number’s interesting octet will be 0.

Each time the next subnet number would have had a 256 in the interesting octet, you

instead follow this new step. It is a little like normal decimal addition. For example, when

you add 319 and 1, you add 1 and 9, write a 0, and carry the 1 to the next digit to the

left. It is much more obvious through examples, though. So, to complete the logic, Table

D-82 shows the example, with this new logic implemented. (Note that the new step has

been labeled as Step 8.)

Table D-82 Question 5 Answer, Part 2: Network 10.0.0.0, Mask 255.255.128.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 0 128 0

8) Increment in the octet to the left, and

use 0 in the interesting octet

10 1 0 0

5) Next subnet 10 1 128 0

8) Increment in the octet to the left, and

use 0 in the interesting octet

10 2 0 0

5) Next subnet 10 2 128 0

8) Increment in the octet to the left, and

use 0 in the interesting octet

10 3 0 0

5) Next subnet 10 3 128 0

8) Increment in the octet to the left, and

use 0 in the interesting octet

10 4 0 0

5) Next subnet 10 4 128 0

5) Generic view 10 X 0/128 0

6) Broadcast subnet 10 255 128 0

7) Invalid subnet* 10 256 0 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

The end of the table is found in this example when the octet to the left of the interesting

octet reaches 256. The previously listed subnet is the broadcast subnet.

ptg13046388

54 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Question 6: Answer

This question begins with the following basic facts:

Network 10.0.0.0

Mask 255.255.192.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 3rd

Magic number: 256 – 192 = 64

Like the previous question, this question actually uses a subnet field larger than 1 octet.

As a result, the expanded version of the seven-step process is used. First, Table D-83

shows the beginning of the process, which occurs just like the standard seven-step

process.

Table D-83 Question 6 Answer, Part 1: Network 10.0.0.0, Mask 255.255.192.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 0 64 0

5) Next subnet 10 0 128 0

5) Next subnet 10 0 192 0

7) Invalid subnet* 10 0 256 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

After finding a 256 in the interesting octet, the extra bit of logic is applied, as follows:

Record the next subnet, based on the following changes to the previous valid subnet

number: Add 1 to the octet to the left of the interesting octet, and set the interesting

octet to 0.

Table D-84 shows the actual values.

Table D-84 Question 6 Answer, Part 2: Network 10.0.0.0, Mask 255.255.192.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 10 0 0 0

2) Zero subnet 10 0 0 0

5) Next subnet 10 0 64 0

5) Next subnet 10 0 128 0

5) Next subnet 10 0 192 0

ptg13046388

Appendix D: IP Addressing Practice 55

Step Octet 1 Octet 2 Octet 3 Octet 4

8) Increment in the octet to the left, and

use 0 in the interesting octet

10 1 0 0

5) Next subnet 10 1 64 0

5) Next subnet 10 1 128 0

5) Next subnet 10 1 192 0

8) Increment in the octet to the left, and

use 0 in the interesting octet

10 2 0 0

5) Next subnet 10 2 64 0

5) Generic view 10 X 0/64/128/192 0

6) Broadcast subnet 10 255 192 0

7) Invalid subnet* 10 256 0 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

The end of the table is found in this example when the octet to the left of the interesting

octet reaches 256. The previously listed subnet is the broadcast subnet.

Question 7: Answer

This question begins with the following basic facts:

Network 172.31.0.0

Mask 255.255.224.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 3rd

Magic number: 256 – 224 = 32

From there, Table D-85 shows the rest of the steps for the process.

Table D-85 Question 7 Answer: Network 172.31.0.0, Mask 255.255.224.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 172 31 0 0

2) Zero subnet 172 31 0 0

5) Next subnet 172 31 32 0

5) Next subnet 172 31 64 0

5) Next subnet 172 31 96 0

5) Next subnet 172 31 128 0

ptg13046388

56 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step Octet 1 Octet 2 Octet 3 Octet 4

5) Next subnet 172 31 160 0

5) Next subnet 172 31 192 0

6) Broadcast subnet 172 31 224 0

7) Invalid subnet* 172 31 256 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the subnet numbers’ interesting octet (third octet in this case) simply incre-

ments by the magic number.

Question 8: Answer

This question begins with the following basic facts:

Network 172.31.0.0

Mask 255.255.240.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 3rd

Magic number: 256 – 240 = 16

From there, Table D-86 shows the rest of the steps for the process.

Table D-86 Question 8 Answer: Network 172.31.0.0, Mask 255.255.240.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 172 31 0 0

2) Zero subnet 172 31 0 0

5) Next subnet 172 31 16 0

5) Next subnet 172 31 32 0

5) Next subnet 172 31 48 0

5) Next subnet 172 31 64 0

5) Next subnet 172 31 X 0

6) Broadcast subnet 172 31 240 0

7) Invalid subnet* 172 31 256 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the subnet numbers’ interesting octet (third octet in this case) simply increments

by the magic number. To reduce the space required by the table, the table represents the

remaining subnet numbers before the broadcast subnet as a generic value, 172.31.X.0. The

subnets not specifically listed simply have a multiple of 16 in the third octet.

ptg13046388

Appendix D: IP Addressing Practice 57

Question 9: Answer

This question begins with the following basic facts:

Network 172.31.0.0

Mask 255.255.252.0

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 3rd

Magic number: 256 – 252 = 4

From there, Table D-87 shows the rest of the steps for the process.

Table D-87 Question 9 Answer: Network 172.31.0.0, Mask 255.255.252.0

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 172 31 0 0

2) Zero subnet 172 31 0 0

5) Next subnet 172 31 4 0

5) Next subnet 172 31 8 0

5) Next subnet 172 31 12 0

5) Next subnet 172 31 16 0

5) Next subnet 172 31 X 0

6) Broadcast subnet 172 31 252 0

7) Invalid subnet* 172 31 256 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the subnet numbers’ interesting octet (third octet in this case) simply incre-

ments by the magic number. To reduce the space required by the table, the table rep-

resents the remaining subnet numbers before the broadcast subnet as a generic value,

172.31.X.0. The subnets not specifically listed simply have a multiple of 4 in the third

octet.

Question 10: Answer

This question begins with the following basic facts:

Network 172.31.0.0

Mask 255.255.255.224

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 4th

Magic number: 256 – 224 = 32

ptg13046388

58 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

This question uses a subnet field larger than 1 octet, requiring the expanded version of

the process as seen in Questions 5 and 6. Table D-88 shows the beginning of the process.

Table D-88 Question 10 Answer, Part 1: Network 172.31.0.0, Mask 255.255.255.224

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 172 31 0 0

2) Zero subnet 172 31 0 0

5) Next subnet 172 31 0 32

5) Next subnet 172 31 0 64

5) Next subnet 172 31 0 96

5) Next subnet 172 31 0 128

5) Next subnet 172 31 0 160

5) Next subnet 172 31 0 192

5) Next subnet 172 31 0 224

7) Invalid subnet* 172 31 0 256

*The invalid subnet row is just a reminder used by this process as to when to stop.

After finding a 256 in the interesting octet, the extra bit of logic is applied, as follows:

Record the next subnet, based on the following changes to the previous valid subnet

number: Add 1 to the octet to the left of the interesting octet, and set the interesting

octet to 0.

Table D-89 shows the actual values.

Table D-89 Question 10 Answer, Part 2: Network 172.31.0.0, Mask 255.255.255.224

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 172 31 0 0

2) Zero subnet 172 31 0 0

5) Next subnet 172 31 0 32

5) Next subnet 172 31 0 64

5) Next subnet 172 31 0 128

5) Next subnet 172 31 0 192

5) Next subnet 172 31 0 224

8) Increment in the octet to the left, and

use 0 in the interesting octet

172 31 1 0

5) Next subnet 172 31 1 32

ptg13046388

Appendix D: IP Addressing Practice 59

Step Octet 1 Octet 2 Octet 3 Octet 4

5) Next subnet 172 31 1 64

5) Next subnet 172 31 1 128

5) Next subnet 172 31 1 160

5) Next subnet 172 31 1 192

5) Next subnet 172 31 1 224

8) Increment in the octet to the left, and

use 0 in the interesting octet

172 31 2 0

5) Generic view 172 31 X Y

6) Broadcast subnet 172 31 255 224

7) Invalid subnet* 172 31 256 0

*The invalid subnet row is just a reminder used by this process as to when to stop.

The end of the table is found in this example when the octet to the left of the interesting

octet reaches 256. The previously listed subnet is the broadcast subnet.

Question 11: Answer

This question begins with the following basic facts:

Network 192.168.15.0

Mask 255.255.255.192

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 4th

Magic number: 256 – 192 = 64

From there, Table D-90 shows the rest of the steps for the process.

Table D-90 Question 11 Answer: Network 192.168.15.0, Mask 255.255.255.192

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 192 168 15 0

2) Zero subnet 192 168 15 0

5) Next subnet 192 168 15 64

5) Next subnet 192 168 15 128

6) Broadcast subnet 192 168 15 192

7) Invalid subnet* 192 168 15 256

*The invalid subnet row is just a reminder used by this process as to when to stop.

ptg13046388

60 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Note that the subnet numbers’ interesting octet (fourth octet in this case) simply incre-

ments by the magic number.

Question 12: Answer

This question begins with the following basic facts:

Network 192.168.15.0

Mask 255.255.255.224

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 4th

Magic number: 256 – 224 = 32

From there, Table D-91 shows the rest of the steps for the process.

Table D-91 Question 12 Answer: Network 192.168.15.0, Mask 255.255.255.224

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 192 168 15 0

2) Zero subnet 192 168 15 0

5) Next subnet 192 168 15 32

5) Next subnet 192 168 15 64

5) Next subnet 192 168 15 96

5) Generic view 192 168 15 X

6) Broadcast subnet 192 168 15 224

7) Invalid subnet* 192 168 15 256

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the subnet numbers’ interesting octet (fourth octet in this case) simply incre-

ments by the magic number. To reduce the space required by the table, the table rep-

resents the remaining subnet numbers before the broadcast subnet as a generic value,

192.168.15.X. The subnets not specifically listed simply have a multiple of 32 in the

fourth octet.

Question 13: Answer

This question begins with the following basic facts:

Network 192.168.15.0

Mask 255.255.255.240

ptg13046388

Appendix D: IP Addressing Practice 61

From there, Steps 3 and 4 ask for the following pieces of information:

Interesting octet: 4th

Magic number: 256 – 240 = 16

From there, Table D-92 shows the rest of the steps for the process.

Table D-92 Question 13 Answer: Network 192.168.15.0, Mask 255.255.255.240

Step Octet 1 Octet 2 Octet 3 Octet 4

1) Network number 192 168 15 0

2) Zero subnet 192 168 15 0

5) Next subnet 192 168 15 16

5) Next subnet 192 168 15 32

5) Next subnet 192 168 15 48

5) Generic view 192 168 15 X

6) Broadcast subnet 192 168 15 240

7) Invalid subnet* 192 168 15 256

*The invalid subnet row is just a reminder used by this process as to when to stop.

Note that the subnet numbers’ interesting octet (fourth octet in this case) simply incre-

ments by the magic number. To reduce the space required by the table, the table rep-

resents the remaining subnet numbers before the broadcast subnet as a generic value,

192.168.15.X. The subnets not specifically listed simply have a multiple of 16 in the

fourth octet.

Discovering the Smallest Inclusive Summary Route:

10 Questions

The last two major sections of this appendix provide practice questions to find the best

inclusive and exclusive summary routes, respectively. For the following ten lists of sub-

nets, discover the subnet/mask or prefix/length for the smallest possible inclusive sum-

mary route:

1. 10.20.30.0/24, 10.20.40.0/24, 10.20.35.0/24, 10.20.45.0/24

2. 10.20.7.0/24, 10.20.4.0/24, 10.20.5.0/24, 10.20.6.0/24

3. 10.20.3.0/24, 10.20.4.0/24, 10.20.5.0/24, 10.20.6.0/24, 10.20.7.0/24, 10.20.8.0/24

4. 172.16.200.0/23, 172.16.204.0/23, 172.16.208.0/23

5. 172.16.200.0/23, 172.16.204.0/23, 172.16.208.0/23, 172.16.202.0/23, 172.16.206.0/23

6. 172.16.120.0/22, 172.16.112.0/22, 172.16.124.0/22, 172.16.116.0/22

ptg13046388

62 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

7. 192.168.1.16/29, 192.168.1.32/29, 192.168.1.24/29

8. 192.168.1.16/29, 192.168.1.32/29

9. 10.1.80.0/25, 10.1.81.0/25, 10.1.81.128/25

10. 10.1.80.0/26, 10.1.81.0/26, 10.1.81.128/26

The following steps are a repeat of the algorithm found in Chapter 4 . Chapter 4 only

explained details assuming consecutive subnets and SLSM, but the algorithm works fine

with SLSM or VLSM, and with nonconsecutive subnets. However, nonconsecutive sub-

nets typically require more passes through the algorithm logic. If VLSM is used, at Step

2, you subtract y from the longest prefix length to start the process, again requiring many

more steps through the process.

Step 1. Count the number of subnets; then, find the smallest value of y , such that 2

=> that number of subnets.

Step 2. For the next step, use a the longest prefix length used among the component

subnets, minus y .

Step 3. Pretend that the lowest subnet number in the list of component subnets is

an IP address. Using the new, smaller prefix from Step 2, calculate the subnet

number in which this pretend address resides.

Step 4. Repeat Step 3 for the largest numeric component subnet number and the same

prefix. If it is the same subnet derived as in Step 3, the resulting subnet is the

best summarized route, using the new prefix.

Step 5. If Steps 3 and 4 do not yield the same resulting subnet, repeat Steps 3 and 4,

with another new prefix length of 1 less than the last prefix length.

Question 1: Answer

This question begins with the following routes that need to be summarized:

10.20.30.0/24

10.20.35.0/24

10.20.40.0/24

10.20.45.0/24

The first two steps are as follows:

1. y = 2, because there are 4 component routes, and 2

2 => 4

2. Start with a prefix length of 24 – 2 = 22

From there, Table D-93 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the two steps match.

ptg13046388

Appendix D: IP Addressing Practice 63

Table D-93 Question 1 Answer: Inclusive Summary of 4 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

22 10.20.30.0/22 yields a subnet of

10.20.28.0/22

10.20.45.0/22 yields a subnet of

10.20.44.0/22

21 10.20.30.0/21 yields a subnet of

10.20.24.0/21

10.20.45.0/21 yields a subnet of

10.20.40.0/21

20 10.20.30.0/20 yields a subnet of

10.20.16.0/20

10.20.45.0/20 yields a subnet of

10.20.32.0/20

19 10.20.30.0/19 yields a subnet of

10.20.0.0/19

10.20.45.0/19 yields a subnet of

10.20.32.0/19

18 10.20.30.0/18 yields a subnet of

10.20.0.0/18

10.20.45.0/18 yields a subnet of

10.20.0.0/18

This question requires that you iterate through several progressively shorter prefix lengths

until you find the correct answer. Finally, the process shows that 10.20.0.0/18 would be

the smallest inclusive summary. For questions in which the component subnets are not

consecutive, as was the case in this question, you might try to guess a better starting

point for the prefix length (a few bits shorter) rather than starting with Steps 1 and 2 of

the stated process. Regardless, the process will give you the right answer.

Question 2: Answer

This question begins with the following routes that need to be summarized:

10.20.4.0/24

10.20.5.0/24

10.20.6.0/24

10.20.7.0/24

The first two steps are as follows:

1. y = 2, because there are 4 component routes, and 2

2 => 4

2. Start with a prefix length of 24 – 2 = 22

From there, Table D-94 shows the iterations through Steps 3 and 4. Remember, you do

the math using the original smallest and largest component subnets as if they were IP

addresses, using progressively shorter prefix lengths, until the results are the same. If the

results are the same, you have found the smallest inclusive summary.

ptg13046388

64 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-94 Question 2 Answer: Inclusive Summary of 4 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

22 10.20.4.0/22 yields a subnet of

10.20.4.0/22

10.20.7.0/22 yields a subnet of

10.20.4.0/22

Question 3: Answer

This question begins with the following routes that need to be summarized:

10.20.3.0/24

10.20.4.0/24

10.20.5.0/24

10.20.6.0/24

10.20.7.0/24

10.20.8.0/24

The first two steps are as follows:

1. y = 3, because there are 6 component routes, and 2

3 => 6

2. Start with a prefix length of 24 – 3 = 21

From there, Table D-95 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

Table D-95 Question 3 Answer: Inclusive Summary of 6 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

21 10.20.3.0/21 yields a subnet of

10.20.0.0/21

10.20.8.0/21 yields a subnet of

10.20.8.0/21

20 10.20.3.0/20 yields a subnet of

10.20.0.0/20

10.20.8.0/20 yields a subnet of

10.20.0.0/20

After two passes through Steps 3 and 4, the results are equal, implying that 10.20.0.0/20

is the smallest inclusive summary.

ptg13046388

Appendix D: IP Addressing Practice 65

Question 4: Answer

This question begins with the following routes that need to be summarized:

172.16.200.0/23

172.16.204.0/23

172.16.208.0/23

Note that the subnets are not consecutive in this case, but the algorithm still works. The

first two steps are as follows:

1. y = 2, because there are 3 component routes, and 2

2 => 3

2. Start with a prefix length of 23 – 2 = 21

From there, Table D-96 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

Table D-96 Question 4 Answer: Inclusive Summary of 3 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

21 172.16.200.0/21 yields a subnet of

172.16.200.0/21

172.16.208.0/21 yields a subnet of

172.16.208.0/21

20 172.16.200.0/20 yields a subnet of

172.16.192.0/20

172.16.208.0/20 yields a subnet of

172.16.208.0/20

19 172.16.200.0/19 yields a subnet of

172.16.192.0/19

172.16.208.0/19 yields a subnet of

172.16.192.0/19

After three passes through Steps 3 and 4, the results are equal, implying that

172.16.192.0/19 is the smallest inclusive summary.

Question 5: Answer

This question begins with the following routes that need to be summarized:

172.16.200.0/23

172.16.202.0/23

172.16.204.0/23

172.16.206.0/23

172.16.208.0/23

The first two steps are as follows:

1. y = 3, because there are 5 component routes, and 2

3 => 5

2. Start with a prefix length of 23 – 3 = 20

ptg13046388

66 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

From there, Table D-97 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

Table D-97 Question 5 Answer: Inclusive Summary of 5 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

20 172.16.200.0/20 yields a subnet of

172.16.192.0/20

172.16.208.0/20 yields a subnet of

172.16.208.0/20

19 172.16.200.0/19 yields a subnet of

172.16.192.0/19

172.16.208.0/19 yields a subnet of

172.16.192.0/19

After two passes through Steps 3 and 4, the results are equal, implying that

172.16.192.0/19 is the smallest inclusive summary.

Question 6: Answer

This question begins with the following routes that need to be summarized:

172.16.112.0/22

172.16.116.0/22

172.16.120.0/22

172.16.124.0/22

The first two steps are as follows:

1. y = 2, because there are 4 component routes, and 2

2 => 4

2. Start with a prefix length of 22 – 2 = 20

From there, Table D-98 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

Table D-98 Question 6 Answer: Inclusive Summary of 4 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

20 172.16.112.0/20 yields a subnet of

172.16.112.0/20

172.16.124.0/20 yields a subnet of

172.16.112.0/20

ptg13046388

Appendix D: IP Addressing Practice 67

Question 7: Answer

This question begins with the following routes that need to be summarized:

192.168.1.16/29

192.168.1.24/29

192.168.1.32/29

The first two steps are as follows:

1. y = 2, because there are 3 component routes, and 2

2 => 3

2. Start with a prefix length of 29 – 2 = 27

From there, Table D-99 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

Table D-99 Question 7 Answer: Inclusive Summary of 3 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

27 192.168.1.16/27 yields a subnet of

192.168.1.0/27

192.168.1.32/27 yields a subnet of

192.168.1.32/27

26 192.168.1.16/26 yields a subnet of

192.168.1.0/26

192.168.1.32/26 yields a subnet of

192.168.1.0/26

Question 8: Answer

This question begins with the following routes that need to be summarized:

192.168.1.16/28

192.168.1.32/28

The first two steps are as follows:

1. y = 1, because there are 2 component routes, and 2

1 => 2

2. Start with a prefix length of 28 – 1 = 27

From there, Table D-100 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

ptg13046388

68 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-100 Question 8 Answer: Inclusive Summary of 2 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

27 192.168.1.16/27 yields a subnet of

192.168.1.0/27

192.168.1.32/27 yields a subnet of

192.168.1.32/27

26 192.168.1.16/26 yields a subnet of

192.168.1.0/26

192.168.1.32/26 yields a subnet of

192.168.1.0/26

Question 9: Answer

This question begins with the following routes that need to be summarized:

10.1.80.0/25

10.1.81.0/25

10.1.81.128/25

The first two steps are as follows:

1. y = 2, because there are 3 component routes, and 2

2 => 3

2. Start with a prefix length of 25 – 2 = 23

From there, Table D-101 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

Table D-101 Question 9 Answer: Inclusive Summary of 3 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

23 10.1.80.0/23 yields a subnet of

10.1.80.0/23

10.1.81.128/23 yields a subnet of

10.1.80.0/23

Question 10: Answer

This question begins with the following routes that need to be summarized:

10.1.80.0/26

10.1.81.0/26

10.1.81.128/26

The first two steps are as follows:

1. y = 2, because there are 3 component routes, and 2

2 => 3

2. Start with a prefix length of 26 – 2 = 24

ptg13046388

Appendix D: IP Addressing Practice 69

From there, Table D-102 shows the iterations through Steps 3 and 4, using progressively

shorter prefix lengths, until the right answer is found.

Table D-102 Question 10 Answer: Inclusive Summary of 3 Routes

Prefix

Length

Step 3 (Lowest Component Subnet) Step 4 (Highest Component Subnet)

24 10.1.80.0/24 yields a subnet of

10.1.80.0/24

10.1.81.128/24 yields a subnet of

10.1.81.0/24

23 10.1.80.0/23 yields a subnet of

10.1.80.0/23

10.1.81.128/23 yields a subnet of

10.1.80.0/23

Discovering the Smallest Exclusive Summary Routes:

5 Questions

The last section of this appendix provides practice problems and answers for finding

exclusive summaries. Per Chapter 4 ’s conventions, an exclusive summary can include

multiple prefixes/subnets, but it can only include address ranges inside the original com-

ponent prefixes/subnets.

For the following five lists of subnets, discover the set of exclusive summary routes:

1. 10.20.7.0/24, 10.20.4.0/24, 10.20.5.0/24, 10.20.6.0/24

2. 10.20.3.0/24, 10.20.4.0/24, 10.20.5.0/24, 10.20.6.0/24, 10.20.7.0/24, 10.20.8.0/24

3. 172.16.200.0/23, 172.16.204.0/23, 172.16.208.0/23, 172.16.202.0/23, 172.16.206.0/23

4. 172.16.120.0/22, 172.16.112.0/22, 172.16.124.0/22, 172.16.116.0/22

5. 192.168.1.16/29, 192.168.1.32/29, 192.168.1.24/29

The following steps are a repeat of the decimal algorithm for finding exclusive summaries

found in Chapter 4 . Remember, the process assumes that all the component subnets have

the same mask/prefix length.

Step 1. Find the best inclusive summary route; call it a candidate exclusive sum-

mary route.

Step 2. Determine whether the candidate summary includes any address ranges it

should not. To do so, compare the summary’s implied address range with the

implied address ranges of the component subnets.

Step 3. If the candidate summary only includes addresses in the ranges implied by

the component subnets, the candidate summary is part of the best exclusive

summarization of the original component subnets.

ptg13046388

70 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Step 4. If instead the candidate summary includes some addresses matching the can-

didate summary routes, and some addresses that do not match, split the cur-

rent candidate summary in half, into two new candidate summary routes, each

with a prefix 1 longer than before.

Step 5. If the candidate summary only includes addresses outside the ranges implied

by the component subnets, the candidate summary is not part of the best

exclusive summarization, and it should not be split further.

Step 6. Repeat Steps 2–4 for each of the two possible candidate summary routes cre-

ated at Step 4.

Question 1: Answer

This question begins with the following routes that need to be summarized:

10.20.4.0/24, range 10.20.4.0–10.20.4.255

10.20.5.0/24, range 10.20.5.0–10.20.5.255

10.20.6.0/24, range 10.20.6.0–10.20.6.255

10.20.7.0/24, range 10.20.7.0–10.20.7.255

The inclusive summary for these routes is

10.20.4.0/22

Table D-103 shows what turns out to be a single pass through the algorithm, because the

inclusive summary and exclusive summary are the same for this problem.

Table D-103 Question 1 Answer: Exclusive Summary of 4 Routes

Split Candidate

Exclusive Summary

Range of

Addresses

Analysis

Inclusive summary 10.20.4.0/22 10.20.4.0–10.20.7.255 Part of exclusive

summary

Comparing the range of IP addresses in the problem statement with the range of address-

es implied by the original inclusive summary, you can see that it is the exact same set of

addresses. As a result, 10.20.4.0/22 is part of the exclusive summary—in fact, no other

summary routes are required.

Question 2: Answer

This question begins with the following routes that need to be summarized:

10.20.3.0/24, range 10.20.3.0–10.20.3.255

10.20.4.0/24, range 10.20.4.0–10.20.4.255

10.20.5.0/24, range 10.20.5.0–10.20.5.255

ptg13046388

Appendix D: IP Addressing Practice 71

10.20.6.0/24, range 10.20.6.0–10.20.6.255

10.20.7.0/24, range 10.20.7.0–10.20.7.255

10.20.8.0/24, range 10.20.8.0–10.20.8.255

The inclusive summary for these routes is

10.20.0.0/20

Table D-104 begins by showing three passes through the algorithm. These three passes

do not determine all the exclusive summary routes in the answer; Tables D-105 and D-106

complete the answer.

Before examining Table D-104 , first consider the overall flow of the repeated iterations

through the table. Think of the original inclusive summary route as one large group of

addresses. If it is not also the exclusive summary, you iterate through the algorithm again,

halving the original inclusive summary. If that does not produce an answer, you halve

each of the halves for the next iteration through the algorithm. So, you can think of the

second splitting of the candidate summaries as breaking them into quarters. Another pass

would break the original inclusive summary into eighths, and so on. The table’s first col-

umn denotes what each row means based on whether it is for the original inclusive sum-

mary, the first split (into halves), the second split (into quarters), and so on.

Table D-104 Question 2 Answer: Inclusive Summary of 6 Routes, Part 1

Split Candidate

Exclusive Summary

Range Analysis

Inclusive

summary

10.20.0.0/20 10.20.0.0–10.20.15.255 Includes too many

addresses

1st split, lower

half

10.20.0.0/21 10.20.0.0–10.20.7.255 Includes 10.20.0.0–

10.20.2.255, which should

not be included

1st split,

higher half

10.20.8.0/21 10.20.8.0–10.20.15.255 Includes 10.20.9.0–

10.20.15.255, which should

not be included

2nd split,

lowest quarter

10.20.0.0/22 10.20.0.0–10.20.3.255 Includes 10.20.0.0–

10.20.2.255, which should

not be included

2nd split, 2nd

quarter

10.20.4.0/22 10.20.4.0–10.20.7.255 Includes only 10.20.4.0–

10.20.7.255; it is part of

exclusive summary

2nd split, 3rd

quarter

10.20.8.0/22 10.20.8.0–10.20.11.255 Includes 10.20.9.0–

10.20.11.255, which should

not be included

2nd split,

highest

quarter

10.20.12.0/22 10.20.12.0–10.20.15.255 Includes 10.20.12.0–

10.20.15.255, totally

outside the range— don’t

split again

ptg13046388

72 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

The last four rows of the table show the results of the second split (per Step 4 in the

algorithm). Two of these four candidate exclusive summaries need to be split again

(10.20.0.0/22 and 10.20.8.0/22) because they contain some addresses within the original

ranges, but some outside the range. One summary (10.20.4.0/22) holds only addresses

inside the original ranges, so that route is one of the routes comprising the exclusive

summary. Finally, one candidate route (10.20.12.0/22) contains only addresses outside the

original range; as a result, you can stop splitting that range when looking for the exclusive

summaries.

Tables D-105 and D-106 complete the official algorithm, but through some basic inspec-

tion, you might be able to (rightfully) guess that no additional summary routes will be

found. Consider the original routes, and whether the process has found a summary route

to include the addresses yet:

10.20.3.0/24—still looking for summary

10.20.4.0/24—found summary

10.20.5.0/24—found summary

10.20.6.0/24—found summary

10.20.7.0/24—found summary

10.20.8.0/24—still looking for summary

Thinking about the problem from this point forward, the remaining component sub-

nets—10.20.3.0/24 and 10.20.8.0/24—are separated by the previously discovered

10.20.4.0/22 summary. There is only one original route on each side of that summary. So,

there is no possibility of summarizing those two individual routes.

The algorithm will reach that same conclusion, as shown in the next two tables. The third

split is in Table D-105 ( Table D-104 showed up through the second split), and the fourth

split is in Table D-106 . Keep in mind that, per Table D-104 , only two prefixes need split-

ting for the next step in the process—10.20.0.0/22 and 10.20.8.0/22. The “Split” column in

the table lists the halves of these two prefixes.

Table D-105 Question 2 Answer, Third Split

Split Candidate

Exclusive

Summary

Range Analysis

Lower half of

10.20.0.0/22

10.20.0.0/23 10.20.0.0–10.20.1.255 Holds none of the original

addresses— don’t split again

Higher half of

10.20.0.0/22

10.20.2.0/23 10.20.2.0–10.20.3.255 Includes too many addresses— split

again

Lower half of

10.20.8.0/22

10.20.8.0/23 10.20.8.0–10.20.9.255 Includes too many addresses— split

again

Higher half of

10.20.8.0/22

10.20.10.0/23 10.20.10.0–10.20.11.255 Holds none of the original

addresses— don’t split again

ptg13046388

Appendix D: IP Addressing Practice 73

(Note: Per Table D-105 , only 10.20.2.0/23 and 10.20.8.0/23 need splitting; their halves are

noted in the first column.)

Table D-106 Question 2 Answer: Fourth Split

Split Candidate

Exclusive

Summary

Range Analysis

Lower half of

10.20.2.0/23

10.20.2.0/24 10.20.2.0–10.20.2.255 Holds none of the original

addresses— don’t split again

Higher half of

10.20.2.0/23

10.20.3.0/24 10.20.3.0–10.20.3.255 Part of exclusive summary

Lower half of

10.20.8.0/23

10.20.8.0/24 10.20.8.0–10.20.8.255 Part of exclusive summary

Higher half of

10.20.8.0/23

10.20.9.0/23 10.20.9.0–10.20.9.255 Holds none of the original

addresses— don’t split again

The other two components of the set of exclusive summary routes are finally found in

Table D-106 . As a result, looking at all three tables, the answer for this question is as fol-

lows:

10.20.3.0/24

10.20.4.0/22

10.20.8.0/24

Question 3: Answer

This question begins with the following routes that need to be summarized:

172.16.200.0/23, range 172.16.200.0–172.16.201.255

172.16.202.0/23, range 172.16.202.0–172.16.203.255

172.16.204.0/23, range 172.16.204.0–172.16.205.255

172.16.206.0/23, range 172.16.206.0–172.16.207.255

172.16.208.0/23, range 172.16.208.0–172.16.209.255

The inclusive summary for these routes is

172.16.192.0/19

Table D-107 begins by showing three passes through the algorithm. These three passes

do not determine all the summary routes in the answer.

ptg13046388

74 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table D-107 Question 3 Answer: Inclusive Summary of 5 Routes

Split Candidate

Exclusive

Summary

Range Analysis

Inclusive summary 172.16.192.0/19 172.16.192.0–

172.16.223.255

Includes too many addresses

1st split, lower half 172.16.192.0/20 172.16.192.0–

172.16.207.255

Includes 172.16.192.0–

172.16.199.255, which should

not be included

1st split, higher half 172.16.208.0/20 172.16.208.0–

172.16.223.255

Includes 172.16.210.0–

172.16.223.255, which should

not be included

2nd split, lowest

quarter

172.16.192.0/21 172.16.192.0–

172.16.199.255

Includes only addresses totally

outside the range— don’t split

again

2nd split, 2nd quarter 172.16.200.0/21 172.16.200.0–

172.16.207.255

Includes only addresses in the

range— it’s part of exclusive

summary

2nd split, 3rd quarter 172.16.208.0/21 172.16.208.0–

172.16.215.255

Includes some addresses that

should not be included

2nd split, highest

quarter

172.16.216.0/21 172.16.216.0–

172.16.223.255

Includes only addresses totally

outside the range— don’t split

again

The last four rows of the table show the results of the second split (per Step 4 in the

algorithm). Two of these four candidate exclusive summaries (172.16.192.0/21 and

172.16.216.0/21) only contain addresses outside the range that needs to be summarized,

so these do not need to be split further. 172.16.200.0/21 is part of the exclusive summary,

so it does not need to be split again. Only 172.16.208.0/21 needs further splitting at this

point.

Under closer examination, at this point in the process, no further work is actually needed.

Only one original component subnet has not had its address range summarized. For ref-

erence, the following list describes which ranges are part of the one exclusive summary

route that has already been uncovered (172.16.200.0/21), and those that are not inside that

summary route:

172.16.200.0/24—part of summary 172.16.200.0/21

172.16.202.0/24—part of summary 172.16.200.0/21

172.16.204.0/24—part of summary 172.16.200.0/21

172.16.206.0/24—part of summary 172.16.200.0/21

172.16.208.0/24—still looking for summary

ptg13046388

Appendix D: IP Addressing Practice 75

Because only one component subnet still needs to be summarized, there is no possibility

that a larger exclusive summary route will be found, because there are no other compo-

nent subnets to combine with 172.16.208.0/24. As a result, the final answer for this prob-

lem (the exclusive summary routes for the component subnets) is as follows:

172.16.200.0/21

172.16.208.0/24

Question 4: Answer

This question begins with the following routes that need to be summarized:

172.16.112.0/22, range 172.16.112.0–172.16.115.255

172.16.116.0/22, range 172.16.116.0–172.16.119.255

172.16.120.0/22, range 172.16.120.0–172.16.123.255

172.16.124.0/22, range 172.16.124.0–172.16.127.255

The inclusive summary for these routes is

172.16.112.0/20, range 172.16.112.0–172.16.127.255

By simply inspecting the inclusive summary, you can see that it exactly matches the col-

lective ranges of IP addresses in the four component subnets. So, the exclusive summary

for these four subnets is also 172.16.112.0/20.

Question 5: Answer

This question begins with the following routes that need to be summarized:

192.168.1.16/29, range 192.168.1.16–192.168.1.23

192.168.1.24/29, range 192.168.1.24–192.168.1.31

192.168.1.32/29, range 192.168.1.32–192.168.1.39

The inclusive summary for these routes is

192.168.1.0/26

Table D-108 begins by showing three passes through the algorithm. These three passes

do not determine all the summary routes in the answer.

Table D-108 Question 2 Answer: Inclusive Summary of Three Routes

Split Candidate

Exclusive Summary

Range Analysis

Inclusive summary 192.168.1.0/26 192.168.1.0–

192.168.1.63

Includes too many addresses

1st split, lower half 192.168.1.0/27 192.168.1.0–

192.168.1.31

Includes too many

addresses—split again

ptg13046388

76 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Split Candidate

Exclusive Summary

Range Analysis

1st split, higher half 192.168.1.32/27 192.168.1.32–

192.168.1.63

Includes too many

addresses—split again

2nd split, lowest

quarter

192.168.1.0/28 192.168.1.0–

192.168.1.15

Includes only addresses

totally outside the range—

don’t split again

2nd split, 2nd quarter 192.168.1.16/28 192.168.1.16–

192.168.1.31

Includes only addresses

in the range— it’s part of

exclusive summary

2nd split, 3rd quarter 192.168.1.32/28 192.168.1.32–

192.168.1.47

Includes some addresses that

should not be included

2nd split, highest

quarter

192.168.1.48/28 192.168.1.48–

192.168.1.63

Includes only addresses

totally outside the range—

don’t split again

The last four rows of the table show the results of the second split (per Step 4 in the

algorithm). Two of these four candidate exclusive summaries (192.168.1.0/28 and

192.168.1.48/28) only contain addresses outside the range that needs to be summarized,

so these do not need to be split further. 192.168.1.16/28 is part of the exclusive summary,

so it does not need to be split again. Only 192.168.32.0/28 needs further splitting at this

point.

Under closer examination, at this point in the process, no further work is actually needed.

Only one original component subnet has not had its address range summarized. For ref-

erence, the following list describes which ranges are part of the one exclusive summary

route that has already been uncovered (192.168.1.16/28), and those that are not inside that

summary route:

192.168.1.16/29—part of summary 192.168.1.16/28

192.168.1.24/29—part of summary 192.168.1.16/28

192.168.1.16/29—still looking for summary

Because only one component subnet still needs to be summarized, there is no possibility

that a larger exclusive summary route will be found. As a result, the final answer for this

problem (the exclusive summary routes for the component subnets) is as follows:

192.168.1.16/28

192.168.1.32/29

ptg13046388

This page intentionally left blank

ptg13046388

This page intentionally left blank

ptg13046388

Chapter 1

Table 1-2 Ethernet Cabling Types

Type of Cable Pinouts Key Pins Connected

Straight-through T568A (both ends) or T568B (both ends)

Crossover T568A on one end, and T568B on the other

Table 1-3 Ethernet Header Fields

Field Description

Provides synchronization and signal

transitions to allow proper clocking of the

transmitted signal. Consists of 62 alternating

1s and 0s, and ends with a pair of 1s.

Same purpose and binary value as DIX

preamble; 802.3 simply renames the 8-byte

DIX preamble as a 7-byte preamble and a

1-byte Start of Frame Delimiter (SFD).

Type (or Protocol Type) (DIX)

Length (802.3)

Destination Service Access Point (802.2)

APPENDIX E

Key Tables for CCIE Study

ptg13046388

4 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Field Description

Source Service Access Point (802.2)

Control (802.2)

Organizationally Unique Identifier (SNAP)

Type (SNAP)

Table 1-4 Three Types of Ethernet/MAC Address

Type of Ethernet/MAC

Address

Description and Notes

Fancy term for an address that represents a single LAN

interface. The I/G bit, the least significant bit in the most

significant byte, is set to 0.

An address that means “all devices that reside on this LAN

right now.” Always a value of hex FFFFFFFFFFFF.

A MAC address that implies some subset of all devices

currently on the LAN. By definition, the I/G bit is set to 1.

Table 1-5 I/G and U/L Bits

Field Meaning

I/G

U/L

ptg13046388

Appendix E: Key Tables for CCIE Study 5

Table 1-7 LAN Switch Forwarding Behavior

Type of Address Switch Action

Known unicast

Unknown unicast

Broadcast

Multicast

Table 1-9 Switch Internal Processing

Switching Method Description

The switch fully receives all bits in the frame (store) before

forwarding the frame (forward). This allows the switch to

check the frame check sequence (FCS) before forwarding the

frame, thus ensuring that errored frames are not forwarded.

The switch performs the address table lookup as soon as the

Destination Address field in the header is received. The first

bits in the frame can be sent out the outbound port before

the final bits in the incoming frame are received. This does

not allow the switch to discard frames that fail the FCS check,

but the forwarding action is faster, resulting in lower latency.

This performs like cut-through switching, but the switch waits

for 64 bytes to be received before forwarding the first bytes

of the outgoing frame. According to Ethernet specifications,

collisions should be detected during the first 64 bytes of the

frame, so frames that are in error because of a collision will

not be forwarded.

Table 1-12 Ethernet Types and Cabling Standards

Standard Cabling Maximum Single Cable Length

10BASE5 Thick coaxial

10BASE2 Thin coaxial

10BASE-T UTP Cat 3, 4, 5, 5e, 6

100BASE-FX Two strands, multimode

100BASE-T UTP Cat 3, 4, 5, 5e, 6, 2 pair

ptg13046388

6 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Standard Cabling Maximum Single Cable Length

100BASE-T4 UTP Cat 3, 4, 5, 5e, 6, 4 pair

100BASE-TX UTP Cat 3, 4, 5, 5e, 6, or STP,

2 pair

1000BASE-LX Long-wavelength laser, MM

or SM fiber

(SM)

(MM)

1000BASE-SX Short-wavelength laser, MM

fiber

____ m with 62.5-micron fiber; ____

m with 50-micron fiber

1000BASE-ZX Extended wavelength, SM

fiber

1000BASE-CS STP, 2 pair

1000BASE-T UTP Cat 5, 5e, 6, 4 pair

Chapter 2

Table 2-2 Private VLAN Communications Between Ports

Description of Who Can Talk to Whom Primary

VLAN Ports

Community

VLAN Ports

Isolated

VLAN Ports

Talk to ports in primary VLAN

(promiscuous ports)

Talk to ports in the same secondary VLAN

(host ports)

Talks to ports in another secondary VLAN

Talk to trunks

1 Community and isolated VLANs are secondary VLANs.

2 Promiscuous ports, by definition in the primary VLAN, can talk to all other ports.

Table 2-6 VTP Modes and Features

Function Server

Mode

Client

Mode

Transparent

Mode

O f f

Mode*

Originates VTP advertisements

Processes received advertisements to update its

VLAN configuration

Forwards received VTP advertisements

ptg13046388

Appendix E: Key Tables for CCIE Study 7

Function Server

Mode

Client

Mode

Transparent

Mode

O f f

Mode*

Saves VLAN configuration in NVRAM or vlan.

dat

Can create, modify, or delete VLANs using

configuration commands

* The Off mode is supported only with VTPv3.

Table 2-8 Valid VLAN Numbers, Normal and Extended

VLAN

Number

Normal or

Extended?

Can Be Advertised

and Pruned by VTP

Versions 1 and 2?

Comments

Not available for use

On Cisco switches, the default VLAN

for all access ports; cannot be deleted or

changed

—

Defined specifically for use with FDDI

and TR translational bridging

—

Not available for use

Table 2-9 VLAN Configuration and Storage for VTPv1 and VTPv2

Function When in VTP Server Mode When in VTP Transparent

Mode

Normal-range VLANs can be

configured from

Extended-range VLANs can

be configured from

VTP and normal-range VLAN

configuration commands are

stored in

Extended-range VLAN

configuration commands are

stored in

1 When a switch reloads, if the VTP mode or domain name in the vlan.dat file and the startup config file

differs, the switch uses only the vlan.dat file’s contents for VLAN configuration.

ptg13046388

8 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 3

Table 3-2 Three Major 802.1D STP Process Steps

Major Step Description

Elect the root switch

Determine each switch’s

Root Port

Determine the Designated

Port for each segment

Table 3-3 Default Port Costs

Port Speed Pre-802.1D-1998 Cost 802.1D-1998 Cost 802.1D-2004 Cost

10 Mbps 100

100 Mbps 10

1 Gbps 1

10 Gbps 1

Table 3-4 IEEE 802.1D Spanning Tree Interface States

State Forwards Data

Frames?

Learns Source MACs of

Received Frames?

Transitory or

Stable State?

Blocking

Listening

Learning

Forwarding

Disabled

ptg13046388

Appendix E: Key Tables for CCIE Study 9

Table 3-5 RSTP and STP Port States

Administrative State STP State (802.1D) RSTP State (802.1w)

Disabled Disabled

Enabled Blocking

Enabled Listening

Enabled Learning

Enabled Forwarding

Table 3-6 RSTP Port Roles

RSTP Role Definition

Root Port

Designated Port

Alternate Port

Backup Port

Table 3-9 Types of STP Inconsistencies and Their Causes

Inconsistency Type Description and Probable Cause of Inconsistency

Type

(*TYPE_Inc)

Port VLAN ID

(*PVID_Inc)

PVST Simulation

(*PVST_Inc)

ptg13046388

10 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Inconsistency Type Description and Probable Cause of Inconsistency

Loop

(*LOOP_Inc)

Root

(*ROOT_Inc)

Bridge Assurance (*BA_Inc)

Table 3-12 IEEE 802.1D STP Timers

Timer Default Purpose

Hello

Forward Delay

MaxAge

Chapter 4

Table 4-2 Classful Network Review

Class of

Address

Size of Network

and Host Parts of

the Addresses

Range of First

Octet Values

Default Mask

for Each Class

of Network

Identifying Bits

at Beginning of

Address

ptg13046388

Appendix E: Key Tables for CCIE Study 11

Table 4-3 Finding the Size of the Network, Subnet, and Host Fields in an IP Address

Name of Part of

the Address

Process to Find Its Size Size per Figure

4-1 Example

Network

Subnet

Host

Table 4-4 Binary Math to Calculate the Subnet Number and Broadcast Address

Address

Mask

Subnet Number (Result

of AND)

Broadcast

Table 4-5 Quick Math to Find the Subnet Number—172.31.103.41, 255.255.252.0

Octet Comments

1 2 3 4

Address

Mask Equivalent to /22.

Subnet number results after

Steps 1 and 2

Magic number will be 256 – 252

= 4.

Subnet number after

completing the interesting octet

100 is the multiple of 4 closest to,

but not exceeding, 103.

Table 4-6 Quick Math to Find the Broadcast Address—172.31.103.41, 255.255.252.0

Octet Comments

1 2 3 4

Subnet number (per Step 1)

Mask (for reference) Equivalent to /22

Results after Steps 1 to 4 Magic number will be 256 – 252 = 4

Subnet number after

completing the empty octet

Subnet’s third octet (100), plus magic

number (4), minus 1 is 103

ptg13046388

12 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-7 Binary Method to Find All Subnets—Steps 1 Through 4

Octet

Subnet 1 2 3 4

Network number/zero subnet 10101100 000 11111

2nd subnet 10101100 000 11111

3rd subnet 10101100 000 11111

4th subnet 10101100 000 11111

5th subnet 10101100 000 11111

6th subnet 10101100 000 11111

7th subnet 10101100 000 11111

8th subnet (2 y = 8); broadcast subnet 10101100 000 11111

Table 4-8 Binary Method to Find All Subnets—Step 5

Octet

Subnet 1 2 3 4

Network number/zero subnet 10101100 00011111

2nd subnet 10101100 00011111

3rd subnet 10101100 00011111

4th subnet 10101100 00011111

5th subnet 10101100 00011111

6th subnet 10101100 00011111

7th subnet 10101100 00011111

8th subnet (2 y = 8); broadcast subnet 10101100 00011111

ptg13046388

Appendix E: Key Tables for CCIE Study 13

Table 4-10 Example of Finding the Best Inclusive Summary—Binary

Octet 1 Octet 2 Octet 3 Octet 4

172.31.20.0/24

172.31.21.0/24

172.31.22.0/24

172.31.23.0/24

Prefix length: 22

Inclusive summary

Table 4-12 RFC 1918 Private Address Space

Range of IP Addresses Class of Networks Number of Networks

10.0.0.0 to 10.255.255.255

172.16.0.0 to 172.31.255.255

192.168.0.0 to 192.168.255.255

Table 4-13 NAT Terminology

Name Location of Host

Represented by Address

IP Address Space in

Which Address Exists

Inside Local address

Inside Global address

Outside Local address

Outside Global address

Table 4-16 Command Reference for Chapter 4

Command Description

ip address ip-address mask [ secondary ]

ip nat { inside | outside }

ptg13046388

14 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Description

ip nat inside source { list { access-list-

number | access-list-name } | route-map

name } { interface type number | pool pool-

name } [ overload ]

ip nat inside destination list { access-list-

number | name } pool name

ip nat outside source { list { access-list-

number | access-list-name } | route-map

name } pool pool-name [ add-route ]

ip nat pool name start-ip end-ip { netmask

netmask | prefix-length prefix-length }

[ type rotary ]

show ip nat statistics

show ip nat translations [ verbose ]

clear ip nat translation { * | [ inside global-ip

local-ip ] [ outside local-ip global-ip ]}

debug ip nat

show ip interface [ type number ] [ brief ]

Table 4-17 IP Header Fields

Field Meaning

Version

Header Length

DS Field

ptg13046388

Appendix E: Key Tables for CCIE Study 15

Field Meaning

Packet Length

Identification

Flags

Fragment Offset

Time to Live (TTL)

Protocol

Header Checksum

Source IP Address

Destination IP Address

Optional Header Fields and

Padding

Table 4-18 IP Protocol Field Values

Protocol Name Protocol Number

ICMP

TCP

UDP

EIGRP

OSPF

PIM

ptg13046388

16 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-19 IPv6 Header Fields

Field Meaning

Version

Traffic Class

Flow Label

Payload Length

Next Header

Hop Limit

Source Address

Destination Address

Chapter 5

Table 5-2 Comparing RARP, BOOTP, and DHCP

Feature RARP BOOTP DHCP

Relies on server to allocate IP addresses

Encapsulates messages inside IP and UDP so that they can be

forwarded to a remote server

Client can discover its own mask, gateway, DNS, and

download server

Dynamic address assignment from a pool of IP addresses,

without requiring knowledge of client MACs

Allows temporary lease of IP address

Includes extensions for registering client’s FQDN with a DNS

ptg13046388

Appendix E: Key Tables for CCIE Study 17

Table 5-3 SNMP Version Summaries

SNMP Version Description

Table 5-4 SNMP Protocol Messages (RFCs 1157 and 1905)

Message Initial

Version

Response

Message

Typically

Sent By

Main Purpose

Get 1

GetNext

GetBulk 2

Response 1

Set 1

Trap 1

Inform 2

ptg13046388

18 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 5-6 Command Reference for Chapter 5

Command Description

ip dhcp pool name

default-router address [ address2 ... address8 ]

dns-server address [ address2 ... address8 ]

lease { days [ hours ][ minutes ] | infinite }

network network-number [ mask | prefix-

length ]

ip dhcp excluded-address [ low-address

high-address ]

host address [ mask | prefix-length ]

hardware-address hardware-address type

show ip dhcp binding [ ip-address ]

show ip dhcp server statistics

standby [ group-number ] ip [ ip-address

[ secondary ]]

track object-number interface type-number

{ line-protocol | ip routing }

standby [ group-number ] preempt [ delay

{ minimum delay | reload delay | sync delay }]

show track [ object-number [ brief ] | interface

[ brief ] | ip route [ brief ] | resolution | timers ]

standby [ group-number ] priority priority

standby [ group-number ] timers [ msec ]

hellotime [ msec ] holdtime

standby [ group-number ] track object-

number

show standby [ type number [ group ]] [ brief

| all ]

ptg13046388

Appendix E: Key Tables for CCIE Study 19

Command Description

ntp peer ip-address [ version number ] [ key

keyid ] [ source interface ] [ prefer ]

ntp server ip-address [ version number ] [ key

keyid ] [ source interface ] [ prefer ]

ntp broadcast [ version number ]

ntp broadcast client

ntp master [ stratum ]

show ntp associations

show ntp status

logging trap level

logging host {{ ip-address | hostname } |

{ ipv6 ipv6-address | hostname }} [ transport

{ udp [ port port-number ] | tcp [ port port-

number ]}] [ alarm [ severity ]]

ip wccp { web-cache | service-number }

[ service-list service-access-list ] [ mode { open

| closed }] [ group-address multicast-address ]

[ redirect-list access-list ] [ group-list access-

list ] [ password [ 0-7 ] password ]

ip wccp { web-cache | service-number }

redirect { in | out }

show ip wccp

snmp-server enable traps

snmp-server host { hostname | ip-address }

[ vrf vrf-name ] [ traps | informs ] [ version { 1

| 2c | 3 [ auth | noauth | priv ]}] community-

string [ udp-port port ] [ notification-type ]

ptg13046388

20 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Description

snmp-server community string [ view view-

name ] [ ro | rw ] [ access-list-number ]

show snmp mib ifmib ifindex interface-id

ip sla monitor operation-index

type [ jitter | udp-echo | echo protocol

icmpecho | dns | ftp operation | http

operation | mpls ping ipv4 | pathecho |

pathjitter | tcpconnect | voip delay post-dial |

udp-jitter | udp-jitter codec ]

ip sla key-chain key-chain-name

ip sla monitor schedule operation-number

[ life { forever | seconds }] [ start-time

{ hh : mm [: ss ] [ month day | day month ] |

pending | now | after hh : mm : ss }] [ ageout

seconds ] [ recurring ]

ip sla monitor responder

show ip sla monitor statistics [ operation ]

detail

show ip sla responder

ip ssh [ timeout seconds | authentication-

retries integer ]

crypto key generate rsa

transport input ssh

ip http server

ip http secure-server

ptg13046388

Appendix E: Key Tables for CCIE Study 21

Command Description

ip traffic-export profile profile-name

ip traffic-export apply profile-name

event manager applet applet-name [ class

class-options ] [ trap ]

event cli pattern regular-expression

{[ default ] [ enter ] [ questionmark ] [ tab ]} [ sync

{ yes | no skip { yes | no }] [ mode variable ]

[ occurs num-occurrences ] [ period period-

value ] [ maxrun maxruntime-number ]

ip flow-top-talkers

flow monitor flow-name

flow exporter exporter-name

rmon event

rmon alarm

Copy

tftp-server flash [ partition-number: ]

filename1 [ alias filename2 ] [ access-list-

number ]

aaa new-model

aaa authentication

aaa authorization

ip scp server enable

ptg13046388

22 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 6

Table 6-2 Matching Logic and Load-Balancing Options for Each Switching Path

Switching Path Structures That Hold the

Forwarding Information

Load-Balancing Method

Process switching

Fast switching

CEF

Chapter 7

Table 7-2 RIPv2 Feature Summary

Function Description

General

characteristic

Transport

protocol

Metric

Hello interval

Update

destination

Update interval

Full or partial

updates

Triggered

updates

Authentication

Route tags

Next Hop field

ptg13046388

Appendix E: Key Tables for CCIE Study 23

Table 7-3 RIPv2 Features Related to Convergence and Loop Prevention

Function Description

Counting to Infinity

Split Horizon

Split Horizon with Poisoned

Reverse

Route poisoning

Triggered update

Update timer

Invalid after timer

Holddown timer

Flushed after timer

ptg13046388

24 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 7-4 RIPv2 Per-Interface Actions, and How to Disable Them When Enabled

RIPv2 Function How to Disable

Sending RIPv2 updates

Listening for RIPv2 updates

Advertising the connected

subnet

Chapter 8

Table 8-2 EIGRP Feature Summary

Feature Description

Transport

Metric

Hello interval

Hold timer

Update destination

address

Full or partial updates

Authentication

VLSM/classless

Route Tags

Next-hop field

Manual route

summarization

Multiprotocol

ptg13046388

Appendix E: Key Tables for CCIE Study 25

Table 8-4 EIGRP Neighbor Table Columns

Field Description

Address

Interface

Hold

Uptime

SRTT

RTO

Q Cnt

Seq Num

Table 8-6 EIGRP Message Summary

EIGRP Packet Purpose

Hello

Ack

Update

Query

SIA-Query

SIA-Reply

ptg13046388

26 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 9

Table 9-2 OSPF Messages

Message Description

Hello

Database Description (DD

or DBD)

Link-State Request (LSR)

Link-State Update (LSU)

Link-State Acknowledgment

(LSAck)

Table 9-3 OSPF Network Types

Interface Type Uses

DR/BDR?

Default Hello

Interval

Requires

a neighbor

Command?

More Than Two

Hosts Allowed

in the Subnet?

Broadcast

Point-to-point 1

Non-broadcast 2 (NBMA)

Point-to-multipoint

nonbroadcast

Loopback 3

1 Default on Frame Relay point-to-point subinterfaces.

2 Default on Frame Relay physical and multipoint subinterfaces.

3 Cannot be configured manually—used on loopback interfaces automatically.

ptg13046388

Appendix E: Key Tables for CCIE Study 27

Table 9-4 OSPF LSA Types

LSA Type Common Name Description

1 Router

2 Network

3 Net Summary

4 ASBR Summary

5 AS External

6 Group Membership

7 NSSA External

8 External Attributes

9–11 Opaque

Table 9-5 OSPF Stubby Area Types

Area Type Stops Injection of

Type 4/5 LSAs?

Stops Injection

of Type 3 LSAs?

Allows Creation

of Type 7 LSAs

Inside the Area?

Stubby

Totally stubby (TS)

Not-so-stubby area (NSSA)

Totally NSSA (NSSA-TS)

ptg13046388

28 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 9-6 Stub Area Configuration Options

Stub Type Router OSPF Subcommand

NSSA

Totally NSSA

Stubby

Totally stubby

Table 9-7 OSPF Authentication Types

Type Meaning Enabling Interface

Subcommand

Authentication Key Configuration

Interface Subcommand

0 None

1 Clear text

2 MD5

Table 9-8 Effect of the area authentication Command on OSPF Interface Authentication

Settings

area authentication Command Interfaces in That Area Default to Use

area area-id authentication

area area-id authentication message-digest

Table 9-9 Configuring OSPF Authentication on Virtual Links

Type Command Syntax for Virtual Links

ptg13046388

Appendix E: Key Tables for CCIE Study 29

Table 9-10 OSPFv3 LSA Types

LSA Type Common Name Description Flooding Scope

1 Router LSA

2 Network LSA

3 Inter-Area Prefix LSA

4 Inter-Area Router LSA

5 Autonomous System

External LSA

7 NSSA LSA

8 Link LSA

9 Intra-Area-Prefix LSA

Table 9-15 OSPF Neighbor States

State Meaning

Down

Attempt

Init

2-Way

ptg13046388

30 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

State Meaning

ExStart

Exchange

Full

Chapter 10

Table 10-3 Adjacencies Between Routers

1st Neighbor’s Level 2nd Neighbor’s Level Resulting Adjacency

Level 1 only Level 1 only

Level 1 only Level 1 + 2

Level 1 only Level 2 only

Level 1 + 2 Level 1 + 2

Level 1 + 2 Level 2 only

Level 2 only Level 2 only

Table 10-7 IS-IS Timer Summary

Timer Meaning

MaxAge, a.k.a.

RemainingLifetime

ZeroAgeLifetime

Hello

Hold

CSNP Interval

ptg13046388

Appendix E: Key Tables for CCIE Study 31

Table 10-8 IS Neighbor States

State Meaning

Down

Init

Table 10-9 OSI Terminology

Term Meaning

System

End System (ES)

Intermediate System (IS)

Domain

Circuit

Local Circuit ID

Extended Local Circuit ID

Network Service Access Point (NSAP)

Network Entity Title

Initial Domain Part (IDP)

Domain Specific Part (DSP)

Address Format ID (AFI)

Initial Domain ID (IDI)

High-Order Domain Specific Part

(HO-DSP)

ptg13046388

32 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Term Meaning

System ID

NSAP Selector (NSEL, SEL)

Sub Network Point of Attachment

(SNPA)

Designated IS (DIS)

Network Layer Protocol ID (NLPID)

Chapter 11

Table 11-2 match Command Options for IGP Redistribution

match Command Description

match interface interface-type interface-

number [ ... interface-type interface-number ]

* match ip address {[ access-list-number |

access-list-name ] | prefix-list prefix-list-

name }

* match ip next-hop { access-list-number |

access-list-name }

* match ip route-source { access-list-number |

access-list-name }

match metric metric-value [+ – deviation ]

match route-type { internal | external [ type-1

| type-2 ] | level-1 | level-2 }

match tag tag-value [ ...tag-value ]

*Can reference multiple numbered and named ACLs on a single command.

ptg13046388

Appendix E: Key Tables for CCIE Study 33

Table 11-3 set Command Options for IGP Redistribution

set Command Description

set level { level-1 | level-2 | level-1-2 | stub-area

| backbone }

set metric metric-value

set metric bandwidth delay reliability

loading mtu

set metric-type { internal | external | type-1

| type-2 }

set tag tag-value

Table 11-4 LE and GE Parameters on IP Prefix List, and the Implied Range of Prefix

Lengths

Prefix List Parameters Range of Prefix Lengths

Neither

Only le

Only ge

Both ge and le

Table 11-5 Example Prefix Lists Applied to the List of Routes

prefix-list Command

Parameters

Routes

Matched

Results

10.0.0.0/8 1

10.128.0.0/9 2

10.0.0.0/8 ge 9 2–6

10.0.0.0/8 ge 24 le 24 3, 4

ptg13046388

34 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

prefix-list Command

Parameters

Routes

Matched

Results

10.0.0.0/8 le 28 1–4

0.0.0.0/0 None

0.0.0.0/0 le 32 All

Table 11-6 Administrative Distances

Route Type Administrative Distance

Connected

Static

EIGRP summary route

EBGP

EIGRP (internal)

IGRP

OSPF

IS-IS

RIP

EIGRP (external)

iBGP

Unreachable

ptg13046388

Appendix E: Key Tables for CCIE Study 35

Table 11-7 Default Metrics and Route Metric Types in IGP Route Redistribution

IGP into Which Routes Are

Redistributed

Default Metric Default (and Possible) Metric

Types

RIP

EIGRP

OSPF

IS-IS

* OSPF uses cost 20 when redistributing from an IGP, and cost 1 when redistributing from BGP.

Table 11-8 IGP Order of Precedence for Choosing Routes Before Considering the

Metric

IGP Order of Precedence of Metric

RIP

EIGRP

OSPF

IS-IS

* For E2 routes whose metric ties, OSPF also checks the cost to the advertising ASBR.

Table 11-9 OSPF Route Summarization Commands

Where Used Command

ASBR

ABR

Table 11-10 Four Methods for Learning Default Routes

Feature RIP EIGRP OSPF

Static route to 0.0.0.0, with the redistribute static command

The default-information originate command

The ip default-network command

Using summary routes

ptg13046388

This page intentionally left blank

ptg13046388

Chapter 1

Table 1-2 Ethernet Cabling Types

Type of Cable Pinouts Key Pins Connected

Straight-through T568A (both ends) or T568B (both ends) 1–1; 2–2; 3–3; 6–6

Crossover T568A on one end, and T568B on the other 1–3; 2–6; 3–1; 6–2

Table 1-3 Ethernet Header Fields

Field Description

Preamble (DIX) Provides synchronization and signal

transitions to allow proper clocking of the

transmitted signal. Consists of 62 alternating

1s and 0s, and ends with a pair of 1s.

Preamble and Start of Frame Delimiter

(802.3)

Same purpose and binary value as DIX

preamble; 802.3 simply renames the 8-byte

DIX preamble as a 7-byte preamble and a

1-byte Start of Frame Delimiter (SFD).

Type (or Protocol Type) (DIX) 2-byte field that identifies the type of

protocol or protocol header that follows the

header. Allows the receiver of the frame to

know how to process a received frame.

Length (802.3) Describes the length, in bytes, of the data

following the Length field, up to the Ethernet

trailer. Allows an Ethernet receiver to predict

the end of the received frame.

Destination Service Access Point (802.2) DSAP; 1-byte protocol type field. The size

limitations, along with other uses of the low-

order bits, required the later addition of SNAP

headers.

APPENDIX F

Solutions for Key Tables for CCIE

Study

ptg13046388

4 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Field Description

Source Service Access Point (802.2) SSAP; 1-byte protocol type field that

describes the upper-layer protocol that

created the frame.

Control (802.2) 1- or 2-byte field that provides mechanisms

for both connectionless and connection-

oriented operation. Generally used only

for connectionless operation by modern

protocols, with a 1-byte value of 0x03.

Organizationally Unique Identifier (SNAP) OUI; 3-byte field, generally unused today,

providing a place for the sender of the

frame to code the OUI representing the

manufacturer of the Ethernet NIC.

Type (SNAP) 2-byte Type field, using same values as the

DIX Type field, overcoming deficiencies with

size and use of the DSAP field.

Table 1-4 Three Types of Ethernet/MAC Address

Type of Ethernet/MAC

Address

Description and Notes

Unicast Fancy term for an address that represents a single LAN

interface. The I/G bit, the least significant bit in the most

significant byte, is set to 0.

Broadcast An address that means “all devices that reside on this LAN

right now.” Always a value of hex FFFFFFFFFFFF.

Multicast A MAC address that implies some subset of all devices

currently on the LAN. By definition, the I/G bit is set to 1.

Table 1-5 I/G and U/L Bits

Field Meaning

I/G Binary 0 means that the address is a unicast; Binary 1 means

that the address is a multicast or broadcast.

U/L Binary 0 means that the address is vendor assigned; Binary 1

means that the address has been administratively assigned,

overriding the vendor-assigned address.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 5

Table 1-7 LAN Switch Forwarding Behavior

Type of Address Switch Action

Known unicast Forwards frame out the single interface associated with the

destination address

Unknown unicast Floods frame out all interfaces, except the interface on which

the frame was received

Broadcast Floods frame identically to unknown unicasts

Multicast Floods frame identically to unknown unicasts, unless

multicast optimizations are configured

Table 1-9 Switch Internal Processing

Switching Method Description

Store-and-forward The switch fully receives all bits in the frame (store) before

forwarding the frame (forward). This allows the switch to

check the frame check sequence (FCS) before forwarding the

frame, thus ensuring that errored frames are not forwarded.

Cut-through The switch performs the address table lookup as soon as the

Destination Address field in the header is received. The first

bits in the frame can be sent out the outbound port before

the final bits in the incoming frame are received. This does

not allow the switch to discard frames that fail the FCS check,

but the forwarding action is faster, resulting in lower latency.

Fragment-free This performs like cut-through switching, but the switch waits

for 64 bytes to be received before forwarding the first bytes

of the outgoing frame. According to Ethernet specifications,

collisions should be detected during the first 64 bytes of the

frame, so frames that are in error because of a collision will

not be forwarded.

Table 1-12 Ethernet Types and Cabling Standards

Standard Cabling Maximum Single Cable Length

10BASE5 Thick coaxial 500 m

10BASE2 Thin coaxial 185 m

10BASE-T UTP Cat 3, 4, 5, 5e, 6 100 m

100BASE-FX Two strands, multimode 400 m

100BASE-T UTP Cat 3, 4, 5, 5e, 6, 2 pair 100 m

ptg13046388

6 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Standard Cabling Maximum Single Cable Length

100BASE-T4 UTP Cat 3, 4, 5, 5e, 6, 4 pair 100 m

100BASE-TX UTP Cat 3, 4, 5, 5e, 6, or STP,

2 pair

100 m

1000BASE-LX Long-wavelength laser, MM

or SM fiber

10 km (SM)

3 km (MM)

1000BASE-SX Short-wavelength laser, MM

fiber

220 m with 62.5-micron fiber;

550 m with 50-micron fiber

1000BASE-ZX Extended wavelength, SM

fiber

100 km

1000BASE-CS STP, 2 pair 25 m

1000BASE-T UTP Cat 5, 5e, 6, 4 pair 100 m

Chapter 2

Table 2-2 Private VLAN Communications Between Ports

Description of Who Can Talk to Whom Primary

VLAN Ports

Community

VLAN Ports

Isolated

VLAN Ports

Talk to ports in primary VLAN

(promiscuous ports)

Yes Yes Yes

Talk to ports in the same secondary VLAN

(host ports)

N/A 2 Ye s N o

Talks to ports in another secondary VLAN N/A

2 N o N o

Talk to trunks Yes Yes Yes

1 Community and isolated VLANs are secondary VLANs.

2 Promiscuous ports, by definition in the primary VLAN, can talk to all other ports.

Table 2-6 VTP Modes and Features

Function Server

Mode

Client

Mode

Transparent

Mode

O f f

Mode*

Originates VTP advertisements Yes Yes No No

Processes received advertisements to update its

VLAN configuration

Ye s Ye s N o N o

Forwards received VTP advertisements Yes Yes Yes No

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 7

Function Server

Mode

Client

Mode

Transparent

Mode

O f f

Mode*

Saves VLAN configuration in NVRAM or vlan.

dat

Yes Yes Yes Yes

Can create, modify, or delete VLANs using

configuration commands

Yes No Yes Yes

* The Off mode is supported only with VTPv3.

Table 2-8 Valid VLAN Numbers, Normal and Extended

VLAN

Number

Normal or

Extended?

Can Be Advertised

and Pruned by VTP

Versions 1 and 2?

Comments

0 Reserved — Not available for use

1 Normal No On Cisco switches, the default VLAN

for all access ports; cannot be deleted or

changed

2–1001 Normal Yes —

1002–1005 Normal No Defined specifically for use with FDDI

and TR translational bridging

1006–4094 Extended No —

4095 Reserved No Not available for use

Table 2-9 VLAN Configuration and Storage for VTPv1 and VTPv2

Function When in VTP Server Mode When in VTP Transparent

Mode

Normal-range VLANs can be

configured from

Both VLAN database and

configuration modes

Both VLAN database and

configuration modes

Extended-range VLANs can

be configured from

Nowhere—cannot be

configured

Configuration mode only

VTP and normal-range VLAN

configuration commands are

stored in

vlan.dat in Flash Both vlan.dat in Flash and

running configuration

Extended-range VLAN

configuration commands are

stored in

Nowhere—extended range

not allowed in VTP server

mode

Running configuration only

1 When a switch reloads, if the VTP mode or domain name in the vlan.dat file and the startup config file

differs, the switch uses only the vlan.dat file’s contents for VLAN configuration.

ptg13046388

8 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 3

Table 3-2 Three Major 802.1D STP Process Steps

Major Step Description

Elect the root switch The switch with the lowest bridge ID; the standard bridge ID

is 2-byte priority followed by a MAC address unique to that

switch.

Determine each switch’s

Root Port

The one port on each nonroot switch that receives the

superior resulting BPDU from among all received BPDUs on

all its ports.

Determine the Designated

Port for each segment

When multiple switches connect to the same segment, this is

the switch that forwards the superior BPDU from among all

forwarded BPDUs onto that segment.

Table 3-3 Default Port Costs

Port Speed Pre-802.1D-1998 Cost 802.1D-1998 Cost 802.1D-2004 Cost

10 Mbps 100 100 2000000

100 Mbps 10 19 200000

1 Gbps 1 4 20000

10 Gbps 1 2 2000

Table 3-4 IEEE 802.1D Spanning Tree Interface States

State Forwards Data

Frames?

Learns Source MACs of

Received Frames?

Transitory or

Stable State?

Blocking No No Stable

Listening No No Transitory

Learning No Yes Transitory

Forwarding Yes Yes Stable

Disabled No No Stable

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 9

Table 3-5 RSTP and STP Port States

Administrative State STP State (802.1D) RSTP State (802.1w)

Disabled Disabled Discarding

Enabled Blocking Discarding

Enabled Listening Discarding

Enabled Learning Learning

Enabled Forwarding Forwarding

Table 3-6 RSTP Port Roles

RSTP Role Definition

Root Port Same as 802.1D Root Port.

Designated Port Same as 802.1D Designated Port.

Alternate Port A replacement Root Port. Alternate ports are ports receiving BPDUs

from other switches but not meeting requirements to become Root or

Designated. Such a port is attached to a neighboring switch and provides

a possible alternate path toward the root. Upon the loss of the current

Root Port, the Alternate Port receiving the best resulting BPDUs will be

rapidly promoted to the role of Root Port and moved to the Forwarding

state.

Backup Port A replacement Designated Port. Backup ports are ports receiving

BPDUs from the same switch but not meeting requirements to become

Designated. Such a port is attached to the same link as another port on

the same switch, but the other port is Designated for that segment. The

Backup Port is ready to take over if the DP fails; however, this takeover is

not rapid. Rather, it is driven by timers.

Table 3-9 Types of STP Inconsistencies and Their Causes

Inconsistency Type Description and Probable Cause of Inconsistency

Type

(*TYPE_Inc)

PVST+ BPDUs are received on a non-802.1Q port. Usually

caused by interconnecting access and trunk ports.

Port VLAN ID

(*PVID_Inc)

PVST+ BPDUs are received in a different VLAN than they

were originated in. Usually caused by native VLAN mismatch

on a trunk.

PVST Simulation

(*PVST_Inc)

PVST+ BPDUs received on an MST boundary port do not

meet the PVST Simulation consistency criteria.

ptg13046388

10 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Inconsistency Type Description and Probable Cause of Inconsistency

Loop

(*LOOP_Inc)

A Root or Alternate Port tried to become Designated after

BPDUs stopped arriving. Seen only on Loop Guard–protected

ports.

Root

(*ROOT_Inc)

A port tried to become a Root Port after receiving superior

BPDUs. Seen only on Root Guard–protected ports. Also, on

older switches, this state was displayed in place of the PVST_

Inc state if PVST Simulation Inconsistency was encountered

on a port.

Bridge Assurance (*BA_Inc) A port stopped receiving BPDUs. Seen only on Bridge

Assurance–protected ports.

Table 3-12 IEEE 802.1D STP Timers

Timer Default Purpose

Hello 2 sec Interval at which the root sends Configuration BPDUs

Forward Delay 15 sec Time that switch leaves a port in the Listening state and the

Learning state; also used as the short CAM timeout timer

MaxAge 20 sec Time without hearing a Hello before expiring the stored BPDU

Chapter 4

Table 4-2 Classful Network Review

Class of

Address

Size of Network

and Host Parts of

the Addresses

Range of First

Octet Values

Default Mask for

Each Class of

Network

Identifying Bits

at Beginning of

Address

A 8/24 1–126 255.0.0.0 0

B 16/16 128–191 255.255.0.0 10

C 24/8 192–223 255.255.255.0 110

D — 224–239 — 1110

E — 240–255 — 1111

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 11

Table 4-3 Finding the Size of the Network, Subnet, and Host Fields in an IP Address

Name of Part of

the Address

Process to Find Its Size Size per Figure

4-1 Example

Network 8, 16, or 24 bits based on class rules 16

Subnet 32 minus network and host bits 8

Host Equal to the number of binary 0s in the mask 8

Table 4-4 Binary Math to Calculate the Subnet Number and Broadcast Address

Address 172.31.103.41 1010 1100 0001 1111 0110 0111 0010 1001

Mask 255.255.255.0 1111 1111 1111 1111 1111 1111 0000 0000

Subnet Number (Result

of AND)

172.31.103.0 1010 1100 0001 1111 0110 0111 0000 0000

Broadcast 172.31.103.255 1010 1100 0001 1111 0110 0111 1111 1111

Table 4-5 Quick Math to Find the Subnet Number—172.31.103.41, 255.255.252.0

Octet Comments

1 2 3 4

Address 172 31 103 41

Mask 255 255 252 0 Equivalent to /22.

Subnet number results after

Steps 1 and 2

172 31 0 Magic number will be 256 – 252 = 4.

Subnet number after

completing the interesting octet

172 31 100 0 100 is the multiple of 4 closest to,

but not exceeding, 103.

Table 4-6 Quick Math to Find the Broadcast Address—172.31.103.41, 255.255.252.0

Octet Comments

1 2 3 4

Subnet number (per Step 1) 172 31 100 0

Mask (for reference) 255 255 252 0 Equivalent to /22

Results after Steps 1 to 4 172 31 255 Magic number will be 256 – 252 = 4

Subnet number after

completing the empty octet

172 31 103 255 Subnet’s third octet (100), plus magic

number (4), minus 1 is 103

ptg13046388

12 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-7 Binary Method to Find All Subnets—Steps 1 Through 4

Octet

Subnet 1 2 3 4

Network number/zero subnet 10101100 000 11111 000 00000 00000000

2nd subnet 10101100 000 11111 00000 00000000

3rd subnet 10101100 000 11111 00000 00000000

4th subnet 10101100 000 11111 00000 00000000

5th subnet 10101100 000 11111 00000 00000000

6th subnet 10101100 000 11111 00000 00000000

7th subnet 10101100 000 11111 00000 00000000

8th subnet (2 y = 8); broadcast subnet 10101100 000 11111 00000 00000000

Table 4-8 Binary Method to Find All Subnets—Step 5

Octet

Subnet 1 2 3 4

Network number/zero subnet 10101100 00011111 000 00000 00000000

2nd subnet 10101100 00011111 001 00000 00000000

3rd subnet 10101100 00011111 010 00000 00000000

4th subnet 10101100 00011111 011 00000 00000000

5th subnet 10101100 00011111 100 00000 00000000

6th subnet 10101100 00011111 101 00000 00000000

7th subnet 10101100 00011111 110 00000 00000000

8th subnet (2 y = 8); broadcast subnet 10101100 00011111 111 00000 00000000

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 13

Table 4-10 Example of Finding the Best Inclusive Summary—Binary

Octet 1 Octet 2 Octet 3 Octet 4

172.31.20.0/24 10101100 00011111 000101 00 00000000

172.31.21.0/24 10101100 00011111 000101 01 00000000

172.31.22.0/24 10101100 00011111 000101 10 00000000

172.31.23.0/24 10101100 00011111 000101 11 00000000

Prefix length: 22

Inclusive summary 10101100 00011111 000101 00 00000000

Table 4-12 RFC 1918 Private Address Space

Range of IP Addresses Class of Networks Number of Networks

10.0.0.0 to 10.255.255.255 A 1

172.16.0.0 to 172.31.255.255 B 16

192.168.0.0 to 192.168.255.255 C 256

Table 4-13 NAT Terminology

Name Location of Host

Represented by Address

IP Address Space in Which

Address Exists

Inside Local address Inside the enterprise network Part of the enterprise IP address

space; typically a private IP address

Inside Global address Inside the enterprise network Part of the public IP address space

Outside Local

address

In the public Internet; or,

outside the enterprise network

Part of the enterprise IP address

space; typically a private IP address

Outside Global

address

In the public Internet; or,

outside the enterprise network

Part of the public IP address space

Table 4-16 Command Reference for Chapter 4

Command Description

ip address ip-address mask [ secondary ] Interface subcommand to assign an IPv4

address

ip nat { inside | outside } Interface subcommand; identifies inside or

outside part of network

ptg13046388

14 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Description

ip nat inside source { list { access-list-

number | access-list-name } | route-map

name } { interface type number | pool pool-

name } [ overload ]

Global command that defines the set of inside

addresses for which NAT will be performed,

and corresponding outside addresses

ip nat inside destination list { access-list-

number | name } pool name

Global command used with destination NAT

ip nat outside source { list { access-list-

number | access-list-name } | route-map

name } pool pool-name [ add-route ]

Global command used with both destination

and dynamic NAT

ip nat pool name start-ip end-ip { netmask

netmask | prefix-length prefix-length }

[ type rotary ]

Global command to create a pool of addresses

for dynamic NAT

show ip nat statistics Lists counters for packets and for NAT

table entries, as well as basic configuration

information

show ip nat translations [ verbose ] Displays the NAT table

clear ip nat translation { * | [ inside global-ip

local-ip ] [ outside local-ip global-ip ]}

Clears all or some of the dynamic entries

in the NAT table, depending on which

parameters are used

debug ip nat Issues log messages describing each packet

whose IP address is translated with NAT

show ip interface [ type number ] [ brief ] Lists information about IPv4 on interfaces

Table 4-17 IP Header Fields

Field Meaning

Version Version of the IP protocol. Most networks use IPv4 today,

with IPv6 becoming more popular. The header format reflects

IPv4.

Header Length Defines the length of the IP header, including optional fields.

Because the length of the IP header must always be a multiple

of 4, the IP header length (IHL) is multiplied by 4 to give the

actual number of bytes.

DS Field Differentiated Services Field. This byte was originally called

the Type of Service (ToS) byte, but was redefined by RFC

2474 as the DS Field. It is used for marking packets for the

purpose of applying different quality of service (QoS) levels

to different packets.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 15

Field Meaning

Packet Length Identifies the entire length of the IP packet, including the

data.

Identification Used by the IP packet fragmentation process. If a single

packet is fragmented into multiple packets, all fragments of

the original packet contain the same identifier so that the

original packet can be reassembled.

Flags 3 bits used by the IP packet fragmentation process.

Fragment Offset A number set in a fragment of a larger packet that identifies

the fragment’s location in the larger original packet.

Time to Live (TTL) A value used to prevent routing loops. Routers decrement

this field by 1 each time the packet is forwarded; when it

decrements to 0, the packet is discarded.

Protocol A field that identifies the contents of the data portion of the

IP packet. For example, protocol 6 implies that a TCP header

is the first thing in the IP packet data field.

Header Checksum A value used to store a frame check sequence (FCS) value,

whose purpose is to determine whether any bit errors

occurred in the IP header (not the data) during transmission.

Source IP Address The 32-bit IP address of the sender of the packet.

Destination IP Address The 32-bit IP address of the intended recipient of the packet.

Optional Header Fields and

Padding

IP supports additional header fields for future expansion

through optional headers. Also, if these optional headers

do not use a multiple of 4 bytes, padding bytes are added,

composed of all binary 0s, so that the header is a multiple of

4 bytes in length.

Table 4-18 IP Protocol Field Values

Protocol Name Protocol Number

ICMP 1

TCP 6

UDP 17

EIGRP 88

OSPF 89

PIM 103

ptg13046388

16 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 4-19 IPv6 Header Fields

Field Meaning

Version 4 bits. IPv6 version number.

Traffic Class 8 bits. Internet traffic priority delivery value.

Flow Label 20 bits. Used for specifying special router handling from the

source to the destination(s) for a sequence of packets.

Payload Length 16 bits. Specifies the length of the data in the packet. When

cleared to 0, the option is a hop-by-hop Jumbo payload.

Next Header 8 bits. Specifies the next encapsulated protocol. The values

are compatible with those specified for the IPv4 protocol

field.

Hop Limit 8 bits. For each router that forwards the packet, the hop limit

is decremented by 1. When the hop limit field reaches 0, the

packet is discarded. This replaces the TTL field in the IPv4

header that was originally intended to be used as a time-based

hop limit.

Source Address 16 bytes. The IPv6 address of the sending node.

Destination Address 16 bytes. The IPv6 address of the destination node.

Chapter 5

Table 5-2 Comparing RARP, BOOTP, and DHCP

Feature RARP BOOTP DHCP

Relies on server to allocate IP addresses Yes Yes Yes

Encapsulates messages inside IP and UDP so that they can be

forwarded to a remote server

No Yes Yes

Client can discover its own mask, gateway, DNS, and

download server

No Yes Yes

Dynamic address assignment from a pool of IP addresses,

without requiring knowledge of client MACs

N o N o Ye s

Allows temporary lease of IP address No No Yes

Includes extensions for registering client’s FQDN with a DNS No No Yes

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 17

Table 5-3 SNMP Version Summaries

SNMP Version Description

1 Uses SMIv1, simple authentication with communities, but used MIB-I

originally.

2 Uses SMIv2, removed requirement for communities, added GetBulk and

Inform messages, but began with MIB-II originally.

2c Pseudo-release (RFC 1905) that allowed SNMPv1-style communities with

SNMPv2; otherwise, equivalent to SNMPv2.

3 Mostly identical to SNMPv2, but adds significantly better security, although

it supports communities for backward compatibility. Uses MIB-II.

Table 5-4 SNMP Protocol Messages (RFCs 1157 and 1905)

Message Initial

Version

Response

Message

Typically

Sent By

Main Purpose

Get 1 Response Manager A request for a single variable’s value.

GetNext 1 Response Manager A request for the next single MIB leaf

variable in the MIB tree.

GetBulk 2 Response Manager A request for multiple consecutive MIB

variables with one request. Useful for

getting complex structures, for example, an

IP routing table.

Response 1 None Agent Used to respond with the information in Get

and Set requests.

Set 1 Response Manager Sent by a manager to an agent to tell the

agent to set a variable to a particular value.

The agent replies with a Response message.

Trap 1 None Agent Allows agents to send unsolicited

information to an SNMP manager. The

manager does not reply with any SNMP

message.

Inform 2 Response Manager A message used between SNMP managers

to allow MIB data to be exchanged.

ptg13046388

18 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 5-6 Command Reference for Chapter 5

Command Description

ip dhcp pool name Creates DHCP pool.

default-router address [ address2 ... address8 ] DHCP pool subcommand to list the

gateways.

dns-server address [ address2 ... address8 ] DHCP pool subcommand to list DNS

servers.

lease { days [ hours ][ minutes ] | infinite } DHCP pool subcommand to define the lease

length.

network network-number [ mask | prefix-

length ]

DHCP pool subcommand to define IP

addresses that can be assigned.

ip dhcp excluded-address [ low-address

high-address ]

Global command to disallow these addresses

from being assigned.

host address [ mask | prefix-length ] DHCP pool subcommand, used with

hardware-address or client-identifier , to

predefine a single host’s IP address.

hardware-address hardware-address type DHCP pool subcommand to define MAC

address; works with the host command.

show ip dhcp binding [ ip-address ] Lists addresses allocated by DHCP.

show ip dhcp server statistics Lists stats for DHCP server operations.

standby [ group-number ] ip [ ip-address

[ secondary ]]

Interface subcommand to enable an HSRP

group and define the virtual IP address.

track object-number interface type-number

{ line-protocol | ip routing }

Configures a tracking object that can be

used by HSRP, VRRP, or GLBP to track the

status of an interface.

standby [ group-number ] preempt [ delay

{ minimum delay | reload delay | sync delay }]

Interface subcommand to enable pre-

emption and set delay timers.

show track [ object-number [ brief ] | interface

[ brief ] | ip route [ brief ] | resolution | timers ]

Displays status of tracked objects.

standby [ group-number ] priority priority Interface subcommand to set the HSRP

group priority for this router.

standby [ group-number ] timers [ msec ]

hellotime [ msec ] holdtime

Interface subcommand to set HSRP group

timers.

standby [ group-number ] track object-

number

Interface subcommand to enable HSRP

to track defined objects, usually for the

purpose of switching active routers on an

event related to that object.

show standby [ type number [ group ]] [ brief

| all ]

Lists HSRP statistics.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 19

Command Description

ntp peer ip-address [ version number ] [ key

keyid ] [ source interface ] [ prefer ]

Global command to enable symmetric active

mode NTP.

ntp server ip-address [ version number ] [ key

keyid ] [ source interface ] [ prefer ]

Global command to enable static client mode

NTP.

ntp broadcast [ version number ] Interface subcommand on an NTP server to

cause NTP broadcasts on the interface.

ntp broadcast client Interface subcommand on an NTP client to

cause it to listen for NTP broadcasts.

ntp master [ stratum ] Global command to enable NTP server.

show ntp associations Lists associations with other NTP servers

and clients.

show ntp status Displays synchronization status, stratum

level, and other basic information.

logging trap level Sets the severity level for syslog messages;

arguments are 0–7, where 0=emergencies,

1=alerts, 2=critical, 3=errors, 4=warnings,

5=notifications, 6=informational,

7=debugging (default).

logging host {{ ip-address | hostname } |

{ ipv6 ipv6-address | hostname }} [ transport

{ udp [ port port-number ] | tcp [ port port-

number ]}] [ alarm [ severity ]]

Configures the IP or IPv6 address or host

name to which to send syslog messages and

permits setting the transport protocol and

port number.

ip wccp { web-cache | service-number }

[ service-list service-access-list ] [ mode { open

| closed }] [ group-address multicast-address ]

[ redirect-list access-list ] [ group-list access-

list ] [ password [ 0-7 ] password ]

Enables WCCP and configures filtering and

service parameters.

ip wccp { web-cache | service-number }

redirect { in | out }

Interface configuration command to enable

WCCP and configure it for outbound or

inbound service.

show ip wccp Displays WCCP configuration settings and

statistics.

snmp-server enable traps Enables sending of all types of traps

available on the router or switch.

snmp-server host { hostname | ip-address }

[ vrf vrf-name ] [ traps | informs ] [ version { 1

| 2c | 3 [ auth | noauth | priv ]}] community-

string [ udp-port port ] [ notification-type ]

Configures the SNMP server to send traps

or informs to a particular host, along with

options for setting the SNMP version for

traps and the UDP port (default is 162). The

notification-type field specifies the types of

traps to send; if no types are specified, all

available categories of traps will be sent.

ptg13046388

20 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Command Description

snmp-server community string [ view view-

name ] [ ro | rw ] [ access-list-number ]

Sets the read-only or read-write community

string and access list for host filtering for

access to SNMP reads and writes on the

router or switch.

show snmp mib ifmib ifindex interface-id Shows the router’s interface ID for a

particular interface. Particularly useful for

RMON configuration.

ip sla monitor operation-index Enters IP SLA monitor configuration mode

for an individual monitor function.

type [ jitter | udp-echo | echo protocol

icmpecho | dns | ftp operation | http

operation | mpls ping ipv4 | pathecho |

pathjitter | tcpconnect | voip delay post-dial |

udp-jitter | udp-jitter codec ]

Configures the IP SLA monitor type with

options (not shown) including source and

destination IP address and source and

destination port number, plus other relevant

options to the particular type.

ip sla key-chain key-chain-name Configures a key chain for MD5

authentication of IP SLA operations.

ip sla monitor schedule operation-number

[ life { forever | seconds }] [ start-time

{ hh : mm [: ss ] [ month day | day month ] |

pending

| now | after hh : mm : ss }] [ ageout

seconds ] [ recurring ]

Configures the schedule for a particular

IP SLA monitor. If the IP SLA monitor is

deleted from the configuration, the schedule

is also deleted.

ip sla monitor responder Enables the IP SLA responder function

globally. More specific options for this

command can be configured for specific

responder types, ports, and so on.

show ip sla monitor statistics [ operation ]

detail

Shows the statistics for a specified IP

SLA operation or all configured IP SLA

operations.

show ip sla responder Shows currently configured IP SLA

responders and recent activity (source IP

address, and so on).

ip ssh [ timeout seconds | authentication-

retries integer ]

Sets SSH access crypto key.

crypto key generate rsa Generates RSA keys. Required for SSH

configuration.

transport input ssh In vty configuration mode, permits SSH

connections.

ip http server Enables HTTP server.

ip http secure-server Enables HTTPS server.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 21

Command Description

ip traffic-export profile profile-name Enables and enters configuration mode for a

RITE profile.

ip traffic-export apply profile-name Applies a RITE profile to an interface.

event manager applet applet-name [ class

class-options ] [ trap ]

Enters EEM applet configuration mode.

event cli pattern regular-expression

{[ default ] [ enter ] [ questionmark ] [ tab ]} [ sync

{ yes | no skip { yes | no }] [ mode variable ]

[ occurs num-occurrences ] [ period period-

value ] [ maxrun maxruntime-number ]

Configures EEM to match a CLI command

string.

ip flow-top-talkers NetFlow aggregator. Aggregates traffic for

unclassified top talkers.

flow monitor flow-name Enters configuration mode for a NetFlow

monitor.

flow exporter exporter-name Configures a NetFlow exporter and the

destination server to which to send NetFlow

information for a particular flow monitor.

rmon event Configures an RMON event to monitor a

particular SNMP object, along with rising

and falling thresholds.

rmon alarm Configures an alarm action for an RMON

event’s rising or falling threshold.

Copy With FTP option in the source or destination

field, copies a file to or from an FTP server.

tftp-server flash [ partition-number: ]

filename1 [ alias filename2 ] [ access-list-

number ]

Configures a TFTP server on the router to

serve a file, optionally with an alias, and

optionally through an ACL.

aaa new-model Enables AAA on the router.

aaa authentication Configures AAA authentication methods.

aaa authorization Configures AAA authorization methods.

ip scp server enable Enables the SCP server on the router.

Requires AAA authentication and AAA

authorization to be configured.

ptg13046388

22 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 6

Table 6-2 Matching Logic and Load-Balancing Options for Each Switching Path

Switching Path Structures That Hold the

Forwarding Information

Load-Balancing Method

Process switching Routing table Per packet

Fast switching Fast-switching cache (per flow route

cache)

Per destination IP address

CEF FIB tree and adjacency table Per a hash of the packet source

and destination, or per packet

Chapter 7

Table 7-2 RIPv2 Feature Summary

Function Description

General

characteristic

Classless, distance-vector, timer-driven routing protocol

Transport

protocol

User Datagram Protocol (UDP), port 520

Metric Hop count, with 15 as the maximum usable metric, and 16 considered to

be infinite

Hello interval None; RIPv2 relies on the regular full routing updates instead

Update

destination

224.0.0.9 multicast for RIPv2

Update interval 30 seconds

Full or partial

updates

Full updates each interval. For on-demand circuits, allows RIPv2 to send

full updates once, and then remain silent until changes occur, per RFC

2091

Triggered

updates

Yes, when routes change

Authentication Allows both plain-text and MD5 authentication

Route tags Allows RIPv2 to tag routes as they are redistributed into RIPv2

Next Hop field Supports the assignment of a next-hop IP address for a route, allowing a

router to advertise a next-hop router that is different from itself

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 23

Table 7-3 RIPv2 Features Related to Convergence and Loop Prevention

Function Description

Counting to Infinity If the next hop to a particular destination network advertises

that network with a suddenly increased metric, accept the

advertisement immediately and update our metric accordingly.

If the updated metric reaches infinity, stop using that next

hop.

Split Horizon Instead of advertising all routes out a particular interface,

RIPv2 omits the routes whose outgoing interface field

matches the interface out which the update would be sent.

Split Horizon with Poisoned

Reverse

A stronger variant of Split Horizon: All routes whose

outgoing interface matches the interface out which the update

would be sent are advertised with an infinite metric.

Route poisoning The process of sending an infinite-metric (hop count 16)

route in routing updates when that route fails, prompting its

rapid removal from routing tables.

Triggered update The immediate sending of a new update when routing

information changes, instead of waiting for the Update timer

to expire. Only the changed network is sent in the triggered

update. Complete updates continue to be sent in regular

intervals.

Update timer The timer that specifies the time interval over which updates

are sent. Each interface uses an independent timer, defaulting

to 30 seconds.

Invalid after timer A per-route timer (default 180 seconds) that is reset and

begins after an update about a route has been received from

its next hop. If the updates about the route from its next hop

cease to be received and the Invalid after timer reaches its

limit, the route is declared invalid and the Holddown timer

starts for this route.

Holddown timer A per-route timer (default 180 seconds) that begins after

a route has been declared invalid (that is, after the Invalid

after timer expires). The router starts advertising that route as

unreachable, does not accept any updated information, and

does not modify the routing table entry for that route until

the Holddown timer for that route expires.

Flushed after timer A per-route timer (default 240 seconds) that is reset and

begins after an update about a route has been received from

its next hop. If the updates about the route from its next hop

cease to be received and the Flushed after timer reaches its

limit, the router removes the route from the routing table

entirely.

ptg13046388

24 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 7-4 RIPv2 Per-Interface Actions, and How to Disable Them When Enabled

RIPv2 Function How to Disable

Sending RIPv2 updates Make the interface passive: configure router rip , followed by

passive-interface type number

Listening for RIPv2 updates Filter all incoming routes using a distribute list, or filter

incoming RIPv2 packets using a per-interface ACL

Advertising the connected

subnet

Filter outbound advertisements on other interfaces using

distribute lists, filtering an interface’s connected subnet

Chapter 8

Table 8-2 EIGRP Feature Summary

Feature Description

Transport IP, protocol type 88 (does not use UDP or TCP). Implements its

own Reliable Transport Protocol, providing reliable unicast and

multicast packet delivery.

Metric Based on constrained bandwidth and cumulative delay by

default, and optionally load reliability, and extended metrics.

Hello interval Interval at which a router sends EIGRP Hello messages on an

interface.

Hold timer Timer used to determine when a neighboring router has failed,

based on a router not receiving any EIGRP messages, including

Hellos, in this timer period.

Update destination

address

Normally sent to 224.0.0.10, with retransmissions being sent to

each neighbor’s unicast IP address.

Full or partial updates Full updates are used when new neighbors are discovered;

otherwise, partial updates are used.

Authentication Supports MD5 and SHA-based authentication.

VLSM/classless EIGRP includes the mask with each route, also allowing it to

support discontiguous networks and VLSM.

Route Tags Allows EIGRP to tag routes as they are redistributed into EIGRP.

Next-hop field Supports the advertisement of routes with a different next-hop

router than the advertising router.

Manual route

summarization

Enables EIGRP to tag and filter internal and external routes using

distribute-lists and route-maps.

Multiprotocol Supports the advertisement of IPv4 and IPv6. Former

implementations also supported IPX and AppleTalk routes.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 25

Table 8-4 EIGRP Neighbor Table Columns

Field Description

H Internal reference to a neighbor, also called a neighbor handle, starting at 0.

Address The IP address of the neighbor.

Interface The interface toward the neighbor.

Hold The Hold timer for the neighbor. If it decreases to 0, the neighbor is

considered down.

Uptime Timer for how long the neighbor relationship has been up.

SRTT This is the Smooth Round Trip Time, which is the time it takes to send a

reliable EIGRP packet and receive an acknowledgment.

RTO This is the Retransmission Time Out, which is the amount of time the

router will wait between retransmitting an EIGRP reliable packet if an Ack

is not received.

Q Cnt This is the number of EIGRP reliable packets sent and waiting to be sent to

the neighbor but not acknowledged yet.

Seq Num This is the sequence number of the last EIGRP reliable packet received

from the neighbor. This is to ensure that packets from the neighbor are

processed in the correct order.

Table 8-6 EIGRP Message Summary

EIGRP Packet Purpose

Hello Identifies neighbors, exchanges parameters, and is sent periodically as a

keepalive function

Ack Acknowledges Update, Query, Reply, SIA-Query, and SIA-Reply packets

Update Informs neighbors about updated routing information

Query Asks neighboring routers to update their routing tables in a coordinated

fashion and respond with their actual distance after having their routing

tables updated

Reply Sent by neighbors to reply to a Query, informing the router about

the actual neighbor’s distance to the destination after processing the

information in the Query

SIA-Query Asks a particular neighbor whose Reply to a Query packet is outstanding

for a prolonged time to confirm whether it is still working on this router’s

Query

SIA-Reply Sent by a neighbor as a response to an SIA-Query to ascertain its state

ptg13046388

26 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Chapter 9

Table 9-2 OSPF Messages

Message Description

Hello Used to discover neighbors, bring a neighbor relationship to a

2-Way state, and monitor a neighbor’s continuous liveliness

Database Description (DD

or DBD)

Used to exchange LSA headers during the initial topology

exchange, so that a router knows a list of that neighbor’s

LSAs including their versions

Link-State Request (LSR) A packet that identifies one or more LSAs about which the

sending router would like the neighbor to supply full details

about the LSAs

Link-State Update (LSU) A packet that contains fully detailed LSAs, sent in response

to an LSR message or in the event of a topological change

Link-State Acknowledgment

(LSAck)

Sent to confirm receipt of an LSU message

Table 9-3 OSPF Network Types

Interface Type Uses

DR/BDR?

Default Hello

Interval

Requires

a neighbor

Command?

More Than Two

Hosts Allowed in

the Subnet?

Broadcast Yes 10 No Yes

Point-to-point 1 N o 1 0 N o N o

Nonbroadcast 2 (NBMA) Yes 30 Yes Yes

Point-to-multipoint No 30 No Yes

Point-to-multipoint

nonbroadcast

No 30 Yes Yes

Loopback 3 N o – – N o

1 Default on Frame Relay point-to-point subinterfaces.

2 Default on Frame Relay physical and multipoint subinterfaces.

3 Cannot be configured manually—used on loopback interfaces automatically.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 27

Table 9-4 OSPF LSA Types

LSA Type Common Name Description

1 Router One per router per area, listing the router’s RID and

all interface IP addresses in that area. Represents stub

networks as well. Flooded only within its area of origin.

2 Network One per transit network. Created by the DR on the subnet,

and represents the subnet and the router interfaces con-

nected to the subnet. Flooded only within its area of origin.

3 Net Summary Created by ABRs to represent networks present in one area

when being advertised into another area. Defines the subnets

in the origin area, and cost, but no topology data. Flooded

only within its area of origin; reoriginated on ABRs.

4 ASBR Summary Like a type 3 LSA, except it advertises a host route used

to reach an ASBR. Flooded only within its area of origin;

reoriginated on ABRs.

5 AS External Created by ASBRs for external routes injected into OSPF.

Flooded to all regular areas.

6 Group Membership Defined for MOSPF; not supported by Cisco IOS.

7 NSSA External Created by ASBRs inside an NSSA, instead of a type 5

LSA. Flooded only within its area of origin; converted to

type 5 LSA on an ABR toward other areas.

8 External Attributes Created by ASBRs during BGP-to-OSPF redistribution to

preserve BGP attributes of redistributed networks. Not

implemented in Cisco routers.

9–11 Opaque Used as generic LSAs to allow for easy future extension of

OSPF; for example, type 10 has been adapted for MPLS

traffic engineering. These LSAs have different flooding

scope: Type 9 has link-local flooding scope, type 10 has

area-local flooding scope, type 11 has autonomous system

flooding scope equivalent to the flooding scope of type 5

LSAs (not flooded into stubby areas and NSSAs).

Table 9-5 OSPF Stubby Area Types

Area Type Stops Injection of

Type 4/5 LSAs?

Stops Injection

of Type 3 LSAs?

Allows Creation of

Type 7 LSAs Inside

the Area?

Stubby Yes No No

Totally stubby (TS) Yes Yes No

Not-so-stubby area (NSSA) Yes No Yes

Totally NSSA (NSSA-TS) Yes Yes Yes

ptg13046388

28 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Table 9-6 Stub Area Configuration Options

Stub Type Router OSPF Subcommand

NSSA area area-id nssa

Totally NSSA area area-id nssa no-summary

Stubby area area-id stub

Totally stubby area area-id stub no-summary

Table 9-7 OSPF Authentication Types

Type Meaning Enabling Interface

Subcommand

Authentication Key Configuration

Interface Subcommand

0 None ip ospf authentication null —

1 Clear text ip ospf authentication ip ospf authentication-key key-value

2 MD5 ip ospf authentication

message-digest

ip ospf message-digest-key key-

number md5 key-value

Table 9-8 Effect of the area authentication Command on OSPF Interface Authentication

Settings

area authentication Command Interfaces in That Area Default to Use

<no command> Type 0

area area-id authentication Type 1

area area-id authentication message-digest Type 2

Table 9-9 Configuring OSPF Authentication on Virtual Links

Type Command Syntax for Virtual Links

0 area area-id virtual-link router-id authentication null

1 area area-id virtual-link router-id authentication authentication-key key-value

2 area area-id virtual-link router-id authentication message-digest message-

digest-key key-num md5 key-value

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 29

Table 9-10 OSPFv3 LSA Types

LSA Type Common Name Description Flooding Scope

1 Router LSA Describes a router and its links to its

neighboring objects within one area.

Area

2 Network LSA Generated by a DR to represent the

multiaccess transit network and its

connection to member routers.

Area

3 Inter-Area Prefix LSA Originated by ABRs to describe

inter-area networks in other areas.

Area

4 Inter-Area Router

LSA

Originated by ABRs to advertise the

existence of ASBRs in other areas.

Area

5 Autonomous System

External LSA

Originated by an ASBR in a regular

area to describe networks learned

from other protocols (redistributed

routes).

Autonomous

System

7 NSSA LSA Originated by an ASBR in an NSSA

to describe networks learned from

other protocols (redistributed routes).

Area

8 Link LSA Advertises link-local address and

prefix(es) of a router to all other

routers on the link, as well as option

information. Sent only if more than

one router is present on a link.

Link

9 Intra-Area-Prefix LSA Performs one of two functions:

■ Associates a list of IPv6 prefixes

with a transit network by

pointing to a Network LSA.

■ Associates a list of IPv6 prefixes

with a router by pointing to a

R o u t e r L S A .

Area

Table 9-15 OSPF Neighbor States

State Meaning

Down No Hellos have been received from this neighbor for more than the dead interval.

Attempt This router is sending Hellos to a manually configured neighbor.

Init A Hello has been received from the neighbor, but it did not have the receiving

router’s RID in it.

2-Way A Hello has been received from the neighbor, and it has the receiving router’s RID

in it. This is a stable state for pairs of DROther neighbors.

ptg13046388

30 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

State Meaning

ExStart Currently negotiating the DD sequence numbers and master/slave logic used for

DD packets.

Exchange Finished negotiating and currently exchanging DD packets.

Loading All DD packets exchanged, and currently pulling the complete LSDB entries with

LSU packets.

Full Neighbors are adjacent (fully adjacent), and should have identical LSDB entries for

the area in which the link resides. Routing table calculations begin.

Chapter 10

Table 10-3 Adjacencies Between Routers

1st Neighbor’s Level 2nd Neighbor’s Level Resulting Adjacency

Level 1 only Level 1 only Level 1 if area matches

Level 1 only Level 1 + 2 Level 1 if area matches

Level 1 only Level 2 only No adjacency

Level 1 + 2 Level 1 + 2 Level 1 if area matches

Level 2

Level 1 + 2 Level 2 only Level 2

Level 2 only Level 2 only Level 2

Table 10-7 IS-IS Timer Summary

Timer Meaning

MaxAge, a.k.a.

RemainingLifetime

The maximum remaining lifetime of an LSP without receiving a newer

copy of the LSP, before the LSP expires. Default is 1200 seconds.

ZeroAgeLifetime The minimum time an LSP must be retained in the link-state database

after expiring or initiating an LSP purge. Default is 60 seconds.

Hello Per interface; time interval between Hellos. Default is 10 seconds.

Independent for L1 and L2 Hellos on broadcast interfaces.

Hold Per interface; time interval in which a Hello should be received from

a neighbor. If not received, the neighbor is considered to have failed.

Default is three times Hello.

CSNP Interval Per interface; defines the time interval between sending consecutive CSNP

packets if the router is a DIS on that interface. Defaults to 10 seconds.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 31

Table 10-8 IS Neighbor States

State Meaning

Down The initial state. No IIHs have been received from the neighbor.

Init IIHs have been received from the neighbor, but it is not certain that the neighbor is

properly receiving this router’s IIH.

Up IIHs have been received from the neighbor, and it is certain that the neighbor is

properly receiving this router’s IIH.

Table 10-9 OSI Terminology

Term Meaning

System Network node.

End System (ES) End node; host.

Intermediate System (IS) Intermediate node; router.

Domain Autonomous system.

Circuit Interface; working interconnection to another host

or a router.

Local Circuit ID Internal enumeration of circuits by a router, 1 octet.

Extended Local Circuit ID Internal enumeration of point-to-point circuits for

three-way handshaking purpose, 4 octets.

Network Service Access Point (NSAP) Layer 3 address of a node.

Network Entity Title NSAP address in which the SEL octet is set to 0;

identifies the node itself without addressing any

particular network service.

Initial Domain Part (IDP) High-order octets of an NSAP address identifying

its format and the domain in which the node is

located.

Domain Specific Part (DSP) Low-order octets of an NSAP address identifying

the area, individual host, and network service that is

being addressed.

Address Format ID (AFI) The most significant octet of NSAP address;

identifies the format of the address.

Initial Domain ID (IDI) A part of the NSAP address following the AFI

identifying the domain.

High-Order Domain Specific Part

(HO-DSP)

A part of the NSAP address following the IDI (if

any) identifying the internal partitioning of the

domain.

ptg13046388

32 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Term Meaning

System ID Identifier of the network node, 6 octets.

NSAP Selector (NSEL, SEL) Identifier of the network service on the node, 1

octet.

Sub Network Point of Attachment

(SNPA)

Layer 2 address relevant to an interface (if any).

Designated IS (DIS) Designated router on a broadcast segment.

Network Layer Protocol ID (NLPID) Supported Layer 3 protocol (address family) on a

router.

Chapter 11

Table 11-2 match Command Options for IGP Redistribution

match Command Description

match interface interface-type interface-

number [ ... interface-type interface-number ]

Looks at outgoing interface of routes

* match ip address {[ access-list-number |

access-list-name ] | prefix-list prefix-list-

name }

Examines route prefix and prefix length

* match ip next-hop { access-list-number |

access-list-name }

Examines route’s next-hop address

* match ip route-source { access-list-number |

access-list-name }

Matches advertising router’s IP address

match metric metric-value [+ – deviation ] Matches route’s metric exactly, or optionally

a range of metrics (plus/minus the configured

deviation)

match route-type { internal | external [ type-1

| type-2 ] | level-1 | level-2 }

Matches route type

match tag tag-value [ ...tag-value ] Tag must have been set earlier

*Can reference multiple numbered and named ACLs on a single command.

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 33

Table 11-3 set Command Options for IGP Redistribution

set Command Description

set level { level-1 | level-2 | level-1-2 | stub-area

| backbone }

Defines database(s) into which the route is

redistributed

set metric metric-value Sets the route’s metric for OSPF, RIP, and

IS-IS

set metric bandwidth delay reliability

loading mtu

Sets the IGRP/EIGRP route’s metric values

set metric-type { internal | external | type-1

| type-2 }

Sets the type of route for IS-IS and OSPF

set tag tag-value Sets the unitless tag value in the route

Table 11-4 LE and GE Parameters on IP Prefix List, and the Implied Range of Prefix

Lengths

Prefix List Parameters Range of Prefix Lengths

Neither conf-length = route-length

Only le conf-length <= route-length <= le-value

Only ge ge-value <= route-length <= 32

Both ge and le ge-value <= route-length <= le-value

Table 11-5 Example Prefix Lists Applied to the List of Routes

prefix-list Command

Parameters

Routes

Matched

Results

10.0.0.0/8 1 Without ge or le configured, both the prefix (10.0.0.0)

and length (8) must be an exact match.

10.128.0.0/9 2 Without ge or le configured, the prefix (10.128.0.0) and

length (9) must be an exact match; only the second

route in the list is matched by this prefix list.

10.0.0.0/8 ge 9 2–6 The 10.0.0.0/8 means “all routes whose first octet is 10,”

effectively representing an address range. The prefix

length must be between 9 and 32, inclusive.

10.0.0.0/8 ge 24 le 24 3, 4 The 10.0.0.0/8 means “all routes whose first octet is 10,”

and the prefix range is 24 to 24—meaning only routes

with prefix length 24.

ptg13046388

34 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

prefix-list Command

Parameters

Routes

Matched

Results

10.0.0.0/8 le 28 1–4 The prefix length needs to be between 8 and 28,

inclusive.

0.0.0.0/0 None 0.0.0.0/0 means “match all prefixes, with prefix length

of exactly 0.” So, it would match all routes’ prefixes but

none of their prefix lengths. Only a default route would

match this prefix list.

0.0.0.0/0 le 32 All The range implied by 0.0.0.0/0 is all IPv4 addresses. The

le 32 then implies any prefix length between 0 and 32,

inclusive. This is the syntax for “match all” prefix list

logic.

Table 11-6 Administrative Distances

Route Type Administrative Distance

Connected 0

Static 1

EIGRP summary route 5

EBGP 20

EIGRP (internal) 90

IGRP 100

OSPF 110

IS-IS 115

RIP 120

EIGRP (external) 170

iBGP 200

Unreachable 255

ptg13046388

Appendix F: Solutions for Key Tables for CCIE Study 35

Table 11-7 Default Metrics and Route Metric Types in IGP Route Redistribution

IGP into Which Routes Are

Redistributed

Default Metric Default (and Possible) Metric

Types

RIP None RIP has no concept of external routes

EIGRP None External

OSPF 20/1* E2 (E1 or E2)

IS-IS 0 L1 (L1, L2, L1/L2, or external)

* OSPF uses cost 20 when redistributing from an IGP, and cost 1 when redistributing from BGP.

Table 11-8 IGP Order of Precedence for Choosing Routes Before Considering the Metric

IGP Order of Precedence of Metric

RIP No other considerations

EIGRP Internal, then external

OSPF Intra-area, inter-area, E1, then E2*

IS-IS L1, L2, external

* For E2 routes whose metric ties, OSPF also checks the cost to the advertising ASBR.

Table 11-9 OSPF Route Summarization Commands

Where Used Command

ASBR summary-address {{ ip-address mask } | { prefix mask }} [ not-advertise ] [ tag

tag ]

ABR area area-id range ip-address mask [ advertise | not-advertise ] [ cost cost ]

Table 11-10 Four Methods for Learning Default Routes

Feature RIP EIGRP OSPF

Static route to 0.0.0.0, with the redistribute static command Yes Yes No

The default-information originate command Yes No Yes

The ip default-network command Yes Yes No

Using summary routes No Yes No

ptg13046388

Appendix G

Study Planner

Reading Task

Element Task Goal Date

First Date

Completed

Second Date

Completed

(Optional)

Introduction Read Introduction

1) Ethernet Basics Read Foundation Topics

1) Ethernet Basics Do Exam Prep Tasks

2) Virtual LANs and VLAN Trunking Read Foundation Topics

2) Virtual LANs and VLAN Trunking Do Exam Prep Tasks

3) Spanning Tree Protocol Read Foundation Topics

3) Spanning Tree Protocol Do Exam Prep Tasks

Part I Review

Take practice test in study

mode using Exam Bank #1

questions for chapters 1-3

in practice test software

4) IP Addressing Read Foundation Topics

4) IP Addressing Do Exam Prep Tasks

5) IP Services Read Foundation Topics

5) IP Services Do Exam Prep Tasks

Part II Review

Take practice test in study

mode using Exam Bank #1

questions for chapters 4-5

in practice test software

6) IP Forwarding (Routing) Read Foundation Topics

6) IP Forwarding (Routing) Do Exam Prep Tasks

7) RIPv2 and RIPng Read Foundation Topics

7) RIPv2 and RIPng Do Exam Prep Tasks

8) EIGRP Read Foundation Topics

8) EIGRP Do Exam Prep Tasks

9) OSPF Read Foundation Topics

9) OSPF Do Exam Prep Tasks

10) IS-IS Read Foundation Topics

10) IS-IS Do Exam Prep Tasks

ptg13046388

11) IGP Route Redistribution, Route

Summarization, Default Routing, and

Troubleshooting

Read Foundation Topics

11) IGP Route Redistribution, Route

Summarization, Default Routing, and

Troubleshooting

Do Exam Prep Tasks

Part III Review

Take practice test in study

mode using Exam Bank #1

questions for chapters 6-

11 in practice test software

12) Final Review

Take practice test in study

mode for all Book

Questions in practice test

software

12) Final Review

Reivew all Key Topics in

all chapters

12) Final Review

Complete all memory

tables from appendix E

12) Final Review Practice CLI Skills

12) Final Review

Take practice test in

practice exam mode using

Exam Bank #2 questions

for all chapters

From the Library of Patriz Meulendijks

ptg13046388

Numerics

224.0.0.5 The All OSPF Routers multicast IP address, listened for by all OSPF routers.

224.0.0.6 The All OSPF DR Routers multicast IP address, listened for by DR and BDR

routers.

2-Way In OSPF, a neighbor state that signifies that the other router has reached the basic

neighbor status, having passed the parameter and bidirectional visibility check.

6to4 Tunnel An Internet transition mechanism for migrating from IPv4 to IPv6, a system

that allows IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 Internet)

without the need to configure explicit tunnels by embedding the IPv4 tunnel endpoint

address into the IPv6 address of hosts behind that endpoint.

802.1Q The IEEE standardized protocol for carrying VLAN membership information in

Ethernet frames to implement VLAN trunking.

802.1Q-in-Q A mechanism used to tag the original 802.1Q traffic with another 802.1Q

tag, effectively allowing 802.1Q-tagged traffic to be enclosed into and carried within another

VLAN. It allows a service provider to support transparent VLAN services with multiple cus-

tomers, even if the customers use overlapping VLAN numbers.

ABR S e e Area Border Router .

Ack In TCP, one of header flags indicating that the Acknowledgment number in the TCP

header is valid and shall be processed. In EIGRP, a packet type that is used to acknowledge

reliable EIGRP packets, namely Update, Query, Reply, SIA-Query, and SIA-Reply. Acks do not

require an Ack themselves.

active A state for a route in an EIGRP topology table that indicates that the router is ac -

tively sending Query messages for this route, attempting to validate and/or learn the current

best route to that subnet.

address family Addressing format as used by a particular routed protocol, and its particu-

lar use in the device operation. For example, IPv4 unicast address family refers to the IPv4

addressing and the use of this addressing information to deliver unicast-addressed packets.

Glossary

ptg13046388

4 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Address Resolution Protocol Defined in RFC 826, a protocol used on LANs so that an IP

host can discover the MAC address of another device that is using a particular IP address.

adjacency Often used synonymously with neighbor , but with emphasis on the fact that all

required parameters match, allowing routing updates to be exchanged between the routers.

adjacency table A table used by CEF that holds preconstructed frame headers for each

adjacent IP host to whom or through whom packets can be forwarded.

adjacent Any OSPF neighbor for which the database synchronization process has com-

pleted.

AFI (Authority and Format Identifier) The first octet of an ISO OSI NSAP address indi-

cating its format and structure.

AFT (Address Family Translation) AFT involves the translation of an address from one IP

address family to another.

aggregate route A n o t h e r t e r m f o r summary route ; however, aggregation is a term used

often in relation to BGP, hinting at the possibility that the resulting aggregate route’s mask can

be shorter than the natural classful mask, in effect aggregating multiple classful networks.

All OSPF DR Routers The multicast IP address 224.0.0.6, listened for by DR and BDR

routers.

All OSPF Routers The multicast IP address 224.0.0.5, listened for by all OSPF routers.

Alternate role An 802.1w RSTP port role. An Alternate port is a possible replacement port

for the Root Port. If the current Root Port fails, the Alternate port receiving the best resulting

BPDUs will be promoted to the Root Port and moved to Forwarding state rapidly.

area In OSPF and IS-IS, a contiguous part of a network in which all member routers share

the complete and detailed topology information.

Area Border Router An OSPF router that connects to the backbone area and to one or

more nonbackbone areas.

ARP S e e Address Resolution Protocol .

ASBR (Autonomous System Boundary Router) An OSPF router that redistributes routes

from some other source into OSPF.

ATTached bit A flag in an IS-IS Link State PDU indicating whether the originating router

has a working connection to another area, that is, whether it can be used as a backbone router

to reach other areas.

authentication With routing protocols, the process by which the router receiving a routing

update determines whether the routing update came from a trusted router.

autonegotiation Ethernet process by which devices attached to the same cable negotiate

their speed and the duplex settings over the cable.

ptg13046388

Glossary 5

backbone A part, or a subdomain, of a network that provides interconnection between

different network areas. In OSPF, Area 0 serves as the backbone. In IS-IS, the backbone is the

contiguous subdomain of the network consisting of Level-2-capable routers.

backbone area Area 0; the area that provides communication between other areas and to

which all other OSPF areas must connect.

Backup Designated Router (BDR) In OSPF, a router that is prepared to take over for the

designated router.

Backup role An 802.1w RSTP port role. A Backup Port is a possible replacement port for

the Designated Port of the same switch on a common segment. If the current Designated Port

fails, the Backup Port will be promoted to the Designated Port and moved to the Forwarding

state gradually (the transition is not rapid; rather, it is driven by the forward_delay timer).

BDR S e e Backup Designated Router .

Blocking state An 802.1D STP port state in which the port does not send or receive frames

or learn MAC addresses, except for listening for received Hello BPDUs.

BOOTP (Boot Protocol) A standard (RFC 951) protocol, a predecessor to DHCP, by

which a LAN-attached host can dynamically broadcast a request for a server to assign it an IP

address, along with other configuration settings, including a subnet mask and default gateway

IP address.

BPDU Guard Cisco-proprietary STP feature in which a switch port monitors for STP

BPDUs of any kind, err-disabling the port upon receipt of any BPDU.

broadcast address An address describing all possible receivers on a LAN. On Ethernet,

the broadcast MAC address is FF:FF:FF:FF:FF:FF. In IPv4, the broadcast address is an IP

address in which all host bits are set to 1.

broadcast domain A set of all devices that receive broadcast frames originating from any

device within the set. Devices in the same VLAN are in the same broadcast domain.

broadcast subnet When subnetting a Class A, B, or C network, the subnet for which

all subnet bits are binary 1. The broadcast address in this subnet is numerically equal to the

broadcast address of the former unsubnetted Class A, B, or C network.

CEF (Cisco Express Forwarding) An optimized Layer 3 forwarding path through a

router or a multilayer switch. CEF optimizes routing table lookup by creating a special, eas-

ily searched structure based on the contents of the IP routing table, and preconstructs frame

headers for directly connected end hosts and next hops. The forwarding information is called

the Forwarding Information Base (FIB), and the frame rewrite information is called the adja-

cency table.

ptg13046388

6 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

CIDR (Classless Inter-Domain Routing) Defined in RFCs 1517–1520, a scheme to help

reduce Internet routing table sizes by removing the classful address semantics and adminis-

tratively allocating large blocks of consecutive IP network numbers to ISPs for use in differ-

ent global geographies. CIDR results in large blocks of networks that can be summarized, or

aggregated, into single routes.

circuit ISO OSI term for an interface.

CIST (Common and Internal Spanning Tree) A spanning tree in MST created by joining

together the Common Spanning Tree interconnecting individual MST regions with the Internal

Spanning Tree within each of these regions.

classful IP addressing A particular semantics of IP addresses in which ranges, also called

classes , of IP addresses were defined by convention and each class was assigned an implicit,

also called classful , network mask. When a network was allocated from a class to a customer,

the entire network according to the classful mask was always allocated; there were no provi-

sions to allocate a smaller or a larger subnet.

classless IP addressing A particular semantics of IP addresses in which addressing infor-

mation is always accompanied by an explicitly specified mask (alternatively called a prefix

length), and the former address classes including their implicit netmasks and related limita-

tions are ignored.

community port With private VLANs, a switched port associated with a particular sec-

ondary community VLAN.

community VLAN With private VLANs, a secondary VLAN in which the ports can send

and receive frames with each other, with promiscuous ports and with trunks, but not with

ports in other secondary VLANs.

component route A term used in this book to refer to a route that is included in a larger

summary route.

control plane A conceptual component of a network device that is responsible for creating,

updating, and exchanging information that controls the device operation over data flows. As

an example, in IP routing, the control plane refers to the building of IP routing tables by IP

routing protocols.

counting to infinity An intrinsic routing loop resolution property of distance-vector pro-

tocols. If a next hop to a particular destination suddenly advertises an increased metric, rout-

ers using this next hop will accept the advertisement immediately and update their metrics

accordingly. In a routing loop, routers derive their metrics from each other in sequence, caus-

ing the metric to increment with each update, eventually arriving at a maximum allowed value

after which the routing protocol no longer accepts the advertisement, finally breaking the

routing loop.

crossover cable Copper cable with RJ-45 connectors in which the transmit and receive

pairs are swapped on one end of the cable, allowing the interconnection of devices whose

own sockets are connected identically to each other. A light crossover cable version exchang-

es pins 1,2 with pins 3,6. A full crossover cable also exchanges pins 4,5 with pins 7,8.

ptg13046388

Glossary 7

CSMA/CD (Carrier Sense Multiple Access with Collision Detection) A media-access

mechanism where devices ready to transmit data first check the channel for a carrier. If no

carrier is sensed for a specific period of time, a device can transmit. If two devices transmit

simultaneously, a collision occurs and is detected by all transmitting devices. This collision

subsequently causes each device to stop the transmission and back off for a random period of

time before attempting to retransmit the data.

CSNP (Complete Sequence Number PDU) An IS-IS packet type used in the link-state

database synchronization procedure between routers.

CST (Common Spanning Tree) A single instance of STP that is applied to multiple

VLANs, typically when using the 802.1Q trunking standard. Particularly in MST, CST refers

to the spanning tree that interconnects individual MST regions and provides interoperation

with non-MST regions.

data plane A conceptual component of a network device that performs the actual opera-

tion over data flows. As an example, in IP routing, this term refers to the process of forward-

ing packets through a router.

DD (Database Description) A type of OSPF packet used to exchange LSA headers dur-

ing the initial topology exchange so that a router knows a list of its neighbor’s LSAs including

their versions. Sometimes called DBD .

dead time/interval With OSPF, the timer used to determine when a neighboring router

has failed, based on a router not receiving any OSPF messages, including Hellos, in this timer

period.

default route A route that is used for forwarding packets when the packet does not match

any more specific routes in the IP routing table.

Designated Port With Spanning Tree Protocol, the single port on each LAN segment from

which the best Hello BPDU is forwarded.

DHCP (Dynamic Host Configuration Protocol) A standard (RFC 2131) protocol by

which a host can dynamically broadcast a request for a server to assign to it an IP address,

along with other configuration settings, including a subnet mask and default gateway IP

address. DHCP provides a great deal of flexibility and functionality compared with RARP and

B O O T P.

DHCPv6 A network protocol that is used for configuring IPv6 hosts with IP addresses, IP

prefixes, and/or other configuration required to operate on an IPv6 network.

Dijkstra Alternate name for the SPF algorithm, named for its inventor, Edsger W. Dijkstra.

DIS (Designated Intermediate System) An IS-IS router role analogous to OSPF

Designated Router. A DIS is responsible for representing a multiaccess network segment in

the link-state database and assists in the link-state database synchronization of routers con-

nected to the multiaccess segment.

ptg13046388

8 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Disabled state An 802.1D STP port state in which the port has been administratively

disabled.

Discarding state An 802.1w RSTP port state in which the port is not forwarding or receiv-

ing; covers 802.1D port states disabled, blocking, and listening.

distance vector The underlying fundamental principle of a class of routing protocols,

based on the fact that for a routed network to converge in a finite time, it is sufficient for each

router to advertise just a list (a vector) of known networks and its own distance to each of

them.

distribution list A Cisco IOS configuration tool for routing protocols by which routing

updates can be filtered.

domain ISO OSI term for autonomous system.

DR (Designated Router) With PIM on a multiaccess network, the PIM router with the

highest IP address on the subnet. PIM DR is responsible for acting on behalf of directly con-

nected hosts with respect to the PIM-SM protocol (sends Joins and Prunes as the result of

IGMP signaling, and performs the Register process for local multicast senders). With OSPF,

the OSPF router that wins an election among all current neighbors. The DR is responsible for

flooding on the subnet, and for creating and flooding the type 2 LSA for the subnet.

DR election The process by which neighboring OSPF routers examine their Hello messages

and elect the DR. The decision is based on priority (highest), or RID (highest) if priority is a tie.

DROther The term that describes a router that is neither the DR nor the BDR on a subnet

that elects a DR and BDR.

DSL (Digital Subscriber Line) A common Internet access service type for residential and

business customers.

DSP (Domain Specific Part) A specific portion of an ISO OSI NSAP address local to the

domain, usually containing information about the internal structure of the domain, identifica-

tion of a host, and a requested network service.

DTP (Dynamic Trunking Protocol) A Cisco-proprietary protocol used to dynamically

negotiate whether the devices on an Ethernet segment want to form a trunk and, if so, which

type (ISL or 802.1Q).

DUAL (Diffusing Update Algorithm) In EIGRP, DUAL is a finite state machine that

decides how topology changes should be handled, when a diffusing computation should be

started, and how its results should be processed.

E1 route An OSPF external route for which internal OSPF cost is added to the cost of the

route as it was redistributed into OSPF.

E2 route An OSPF external route for which internal OSPF cost is not added to the cost of

the route as it was redistributed into OSPF.

ptg13046388

Glossary 9

EIGRP stub router A router that should not be used to forward packets between other

routers. An EIGRP stub router does not propagate EIGRP-learned routes, responds to Queries

in a limited way, and instructs other routers not to send it Query packets.

encapsulation The process of taking a datagram and adding layer-specific headers and

optionally trailers to create a new datagram.

encapsulation replication Form of a SPAN session that retains the original encapsulation

of monitored frames including VLAN tags, if any.

ERSPAN (Encapsulated Remote Switched Port ANalyzer) Technology for remote

monitoring of switched ports, utilizing GRE tunnels to carry the monitored traffic across a

routed network to a remote monitoring destination.

ES (End System) An ISO OSI term for an end host.

external route From the perspective of one routing protocol, a route that was learned from

a different source by using route redistribution.

fast switching An optimized Layer 3 forwarding path through a router. Fast switching

optimizes routing table lookup by creating a special, easily searched table of known flows

between hosts (essentially a route lookup cache).

FD (Feasible Distance) With EIGRP, the lowest known distance to a particular destination

since the last time the destination transitioned from Active to Passive state, in other words,

the historical minimum of the distance to that destination.

feasibility condition With EIGRP, a sufficient condition for loop freedom. If, for a particu-

lar destination, a neighbor’s Reported Distance is strictly less than the destination’s Feasible

Distance, the neighbor provides a loop-free path.

feasible successor With EIGRP, for a particular destination, any neighboring router that

satisfies the feasibility condition and thus provides a loop-free path.

FED (Forwarding Engine Driver) / FFM (Forwarding and Feature Manager) I n I O S -

XE, the Control plane and Data plane separation are provided through Forward and Feature

Manager, or FFM. FFM provides a set of APIs to the Control plane processes. FFM programs

the Data plane through the Forward Engine Driver, or FED, and maintains the forwarding

state for the system.

FIB (Forwarding Information Base) In CEF, Forwarding Information Base is an optimized

copy of the Routing Information Base organized for rapid lookups, either as a tree-based soft-

ware structure in RAM in software routers or downloaded into TCAM on multilayer switches.

flash updates S e e triggered updates .

flooding scope In OSPF, the part of a network into which a particular LSA type can be

flooded. OSPFv2 uses two flooding scopes, area-local and autonomous system, with an added

link-local scope for specific opaque LSA types. OSPFv3 uses link-local, area-local, and auton-

omous system flooding scopes as part of its basic operation.

ptg13046388

10 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Flushed after timer A per-route timer in RIP that is reinitialized each time an update about

a route has been received from its next hop. If the next hop ceases to advertise the network

and the Flushed after timer reaches its limit, the router flushes the route from the routing

table.

Forward Delay timer An STP timer that dictates how long a port should stay in the listen-

ing state and the learning state.

Forwarding state An 802.1D STP port state in which the port sends and receives data

frames.

full duplex Ethernet feature in which a NIC or Ethernet port can both transmit and receive

at the same instant in time. It can be used only when there is no possibility of collisions.

Loopback circuitry on NICs is disabled to use full duplex.

full SPF calculation An SPF calculation as a result of changes inside the same area as a

router, for which the SPF run must examine the full LSDB.

full update A routing protocol feature by which the routing update includes the entire set

of routes, even if some of or all the routes are unchanged.

fully adjacent Any OSPF neighbor for which the database flooding process has completed.

gateway of last resort The notation in a Cisco IOS IP routing table that identifies the

route used by that router as the default route.

Get In the context of SNMP, the Get command is sent by an SNMP manager, to an agent,

requesting the value of a single MIB variable identified in the request. The Get request identi-

fies the exact variable whose value the manager wants to retrieve. Introduced in SNMPv1.

GetBulk In the context of SNMP, the GetBulk command is sent by an SNMP manager, to

an agent, requesting the values of multiple variables. The GetBulk command allows retrieval of

complex structures, like a routing table, with a single command, as well as easier MIB walking.

GetNext In the context of SNMP, the GetNext command is sent by an SNMP manager, to

an agent, requesting the value of a single MIB variable. The GetNext request identifies a vari-

able for which the manager wants the variable name and value of the next MIB leaf variable in

sequence.

GLBP (Gateway Load Balancing Protocol) A Cisco-proprietary feature by which mul-

tiple routers can provide interface IP address redundancy, as well as cause a set of clients to

load-balance their traffic across multiple routers inside the GLBP group.

going active EIGRP jargon meaning that EIGRP has placed a route into active status.

Goodbye An EIGRP message that is used by a router to notify its neighbors when the

router is gracefully shutting down.

ptg13046388

Glossary 11

graceful restart As defined in RFC 3623, graceful restart allows for uninterrupted for-

warding in the event that an OSPF router’s OSPF routing process must restart. The router does

this by first notifying the neighbor routers that the restart is about to occur; the neighbors

must be RFC 3623 compliant, and the restart must occur within the defined grace period.

graceful shutdown A feature in routing protocols allowing a router to inform its neighbors

about its impending deactivation. The neighbors can react to this indication immediately,

instead of waiting for the Hold or Dead intervals to expire.

half duplex Ethernet feature in which a NIC or Ethernet port can only transmit or receive at

the same instant in time, but not both. Half duplex is required when a possibility of collisions

exists.

Hello A periodic message used in several protocols to advertise a device’s presence on a

network, discover neighbors, perform configuration parameter verification, establish adjacen-

cies, and monitor neighbor liveliness. Protocols such as EIGRP, OSPF, IS-IS, PIM, and LDP use

Hello signaling.

hello interval With some routing protocols, the time period between successive Hello

messages.

Hello timer An STP timer that dictates the interval at which the Root switch generates and

sends Hello BPDUs.

HO-DSP (High Order Domain Specific Part) A specific portion of an ISO OSI NSAP

address local to the domain, usually containing information about the internal structure of the

domain, such as area number, down to but not including the identification of a host and the

requested network service.

Hold timer With EIGRP, the timer used to determine when a neighboring router has failed,

based on a router not receiving any EIGRP messages, including Hellos, in this timer period.

Holddown timer With RIP, a per-route timer (default 180 seconds) that begins when a

route has not been advertised by its next hop for a period longer than the Invalid after timer.

During the time the Holddown timer runs for a route, this route is advertised as unreachable,

any updates regarding the route are ignored, and the routing table entry is not modified.

HSRP (Hot Standby Router Protocol) A Cisco-proprietary feature by which multiple

routers can provide interface IP address redundancy so that hosts using the shared, virtual IP

address as their default gateway can still reach the rest of a network even if one or more rout-

ers fail.

ptg13046388

12 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

I/G bit Individual/Group bit. The least significant bit in the most significant octet of an

Ethernet MAC address. Its value implies that the address is a unicast MAC address (binary

0) or a group address (binary 1). Note that in Ethernet, individual octets are transmitted in

reverse order of bits, starting with the least-significant bit. The I/G bit will therefore be the

first bit of the MAC address a NIC will see.

IDI (Initial Domain Identifier) A specific portion of an ISO OSI NSAP address identifying

the domain where the host resides.

IDP (Initial Domain Part) A specific portion of an ISO OSI NSAP address comprising the

AFI and IDI fields.

IIH (IS-IS Hello) Hello packet used in IS-IS between routers.

inferior BPDU Out of two BPDUs being compared, the one that is “worse,” that is, the

one that contained a higher numerical value in the first field that broke the tie (the fields are

compared in the sequence Root Bridge ID, Root Path Cost, Sending Bridge ID, and Sending

Port ID).

Inform In the context of SNMP, the Inform command is sent by an SNMP manager to com-

municate a set of variables, and their values, to another SNMP manager. The main purpose is

to allow multiple managers to exchange MIB information, and work together, without requir-

ing each manager to individually use Get commands to gather the data.

input event Any occurrence that could change a router’s EIGRP topology table, including

a received Update or Query, change in interface metrics, a failed interface, or the loss of a

neighbor.

Inside Global address A NAT term describing the IP address of a host located in the

inside part of the network, as seen by hosts in the outside part of the network (inside host’s IP

address after possible translation).

Inside Local address A NAT term describing the IP address of a host located in the inside

part of the network, as seen by other hosts in the inside part of the network (inside host’s true

IP address).

instance ID A field in OSPFv3 packet headers, allowing multiple independent instances of

OSPFv3 to be run over a single link.

internal router In OSPF and IS-IS, a router whose interfaces are all located in the same

single area.

Invalid after timer A per-route timer that is reset and begins after an update about a route

has been received from its next hop. If the updates about the route from its next hop cease to

be received and the Invalid after timer reaches its limit, the route is declared invalid and the

Holddown timer starts for this route.

IP forwarding The process of forwarding packets through a router. Also called IP routing .

IP prefix list A Cisco IOS configuration tool that can be used to match routing updates

based on a base network address, a prefix, and a range of possible masks used inside the val-

ues defined by the base network address and prefix.

ptg13046388

Glossary 13

IP routing The process of forwarding packets through a router. Also called IP forwarding .

IPv4 Version 4 of the IP protocol, which is the generally deployed version worldwide (at

press time) and uses 32-bit IP addresses.

IPv6 The latest version of the Internet Protocol (IP), the communications protocol that

provides an identification and location system for computers on networks and routes traffic

across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal

with the long-anticipated problem of IPv4 address exhaustion.

IS (Intermediate System) An ISO OSI term for a router.

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) An IPv6 transition mecha-

nism meant to transmit IPv6 packets between dual-stack nodes on top of an IPv4 network.

ISH (Intermediate System Hello) A PDU sent from routers toward end hosts to provide

gateway discovery function.

ISL (Inter-Switch Link) Cisco-proprietary VLAN trunking protocol.

isolated port With private VLANs, a switched port associated with a particular secondary

isolated VLAN.

isolated VLAN With private VLANs, a secondary VLAN in which the ports can send and

receive frames only with trunks and promiscuous ports in the associated primary VLAN.

K-value In EIGRP, configurable integer constants used in the composite metric calculation

formula. Different K values correspond to different metric components (K1 controls band-

width, K2 controls bandwidth and load, K3 controls delay, K4 and K5 control reliability, and

K6 controls extended metric components), allowing EIGRP to ignore or take into account

individual metric components and modify their weight.

LACP (Link Aggregation Control Protocol) Defined in IEEE 802.1AX, defines a messag-

ing protocol used to negotiate the dynamic creation of PortChannels (EtherChannels) and to

choose which ports can be placed into an EtherChannel.

Layer 2 protocol tunneling Additional feature related to 802.1Q-in-Q, allowing the tunnel-

ing of Layer 2 control protocols such as CDP, STP, and VTP across a VLAN-based network.

lead content engine The content engine in a WCCP cluster that determines how traffic

will be distributed within the cluster.

Learning state An 802.1D STP transitory port state in which the port does not send or

receive frames, but does learn the source MAC addresses from incoming frames.

Level 1 routing In IS-IS, routing between hosts within the same area.

Level 2 routing In IS-IS, routing between hosts in different areas.

ptg13046388

14 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

Level 2 subdomain A contiguous part of the network consisting of Level-2-capable rout-

ers, allowing inter-area communication and thus forming the backbone.

limiting query scope An effort to reduce the query scope with EIGRP, using route sum-

marization or EIGRP stub routers.

link-state routing protocol Any routing protocol that uses the concept of using the SPF

algorithm with an LSDB to compute routes.

Listening state An 802.1D STP transitory port state in which the port does not send or

receive frames, and does not learn MAC addresses, but still sends and receives BPDUs to

determine its role in the spanning-tree topology.

local computation An EIGRP router’s reaction to an input event, leading to the use of the

current successor or a feasible successor without going active on a route.

Loop Guard Protects against problems caused by unidirectional links between two

switches. Watches for loss of received Hello BPDUs, in which case it transitions to a loop-

inconsistent state instead of transitioning to a forwarding state.

loopback circuitry A feature of Ethernet NICs. When the NIC transmits an electrical

signal, it “loops” the transmitted electrical current back onto the receive pair. By doing so, if

another NIC transmits a frame at the same time, the NIC can detect the overlapping received

electrical signals and sense that a collision has occurred.

LSA (Link State Advertisement) The OSPF data structure that describes topology infor-

mation.

LSA flooding The process of successive neighboring routers exchanging LSAs such that all

routers have an identical LSDB for each area to which they are attached.

LSA type A definition that determines the data structure and information implied by a par-

ticular LSA.

LSAck (Link-State Acknowledgment) A type of OSPF packet used to acknowledge LSU

packets.

LSDB (link-state database) The data structure used by OSPF routers to hold LSAs.

LSP (Label Switched Path) The combination of MPLS labels and links over which a pack-

et will be forwarded over an MPLS network, from the point of ingress to the MPLS network

to the point of egress.

LSP (Link State PDU) In IS-IS, a packet type that carries topological, addressing, and

possibly other information about the router that has originated it. LSPs and their contents are

stored in LSDB and processed during SPF computation.

LSP fragmentation In IS-IS, a process of originating a Link State PDU in several fragments

if its size exceeds the MTU of router’s interfaces. IS-IS LSPs can only be fragmented by their

originating router.

LSRefresh Link-State Refresh. A timer that determines how often the originating router

should reflood an LSA, even if no changes have occurred to the LSA.

LSU (Link-State Update) A type of OSPF packet, used to communicate LSAs to another

router.

ptg13046388

Glossary 15

Maxage An OSPF timer that determines how long an LSA can remain in the LSDB without

having heard a reflooded copy of the LSA.

MaxAge timer An STP timer that dictates the maximum time until a BPDU stored on a

port can expire.

MD5 (Message Digest 5) A widely used cryptographic hash function producing 128-bit

results, used to verify the integrity of transmitted data and provide authentication informa-

tion while protecting the shared secret that was used to compute the authentication infor-

mation.

metric With routing protocols, the measurement of favorability that determines which

entry will be installed in a routing table if more than one router is advertising that exact net-

work and mask.

MIB (Management Information Base) The definitions for a particular set of data vari-

ables, with those definitions following the SMI specifications. See also SMI .

MIB walk In SNMP, the process of a manager using successive GetNext and GetBulk

commands to discover the exact MIB structure supported by an SNMP agent. The process

involves the manager asking for each successive MIB leaf variable.

MIB-I The original standardized set of generic SNMP MIB variables, defined in RFC 1158.

MIB-II The most recent standardized set of generic SNMP MIB variables, defined in RFC

1213 and updated in RFCs 2011 through 2013.

MLS (Multilayer Switching) A process whereby a switch, when making a forwarding deci-

sion, uses not only Layer 2 logic but also other OSI layer equivalents as well.

monitor session The command used to initialize a SPAN or RSPAN session on a Catalyst

switch.

MST (Multiple Spanning Trees) Defined in IEEE 802.1s, a specification for multiple STP

instances when using 802.1Q trunks.

multicast address An address describing a group of receivers. On Ethernet, multicast

MAC addresses have their first octet as an odd number. In IPv4, the range of multicast

addresses is 224.0.0.0/4. In IPv6, the range of multicast addresses is FF00::/8.

Named Mode A new style of EIGRP process configuration in which a process is identified

by its verbal name, and all EIGRP-related configuration is contained within this named pro-

cess section.

NAT (Network Address Translation) Defined in RFC 1631, a method of translating IP

addresses in headers with the goal of allowing multiple hosts to share single public IP address-

es, thereby reducing IPv4 public address depletion.

ptg13046388

16 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

native VLAN The one VLAN on an 802.1Q trunk for which the endpoints do not add the

4-byte 802.1Q tag when transmitting frames in that VLAN, and to which they assign received

frames without an 802.1Q tag.

neighbor With EIGRP, a router sharing the same primary subnet, with which Hellos are

exchanged, parameters match, and with which routes can be exchanged. With OSPF, any

other router, sharing a common data link, with which a router exchanges Hellos, and for which

the parameters in the Hello pass the parameter-check process.

neighbor state A state variable kept by a router for each known neighbor or potential

neighbor.

NET (Network Entity Title) A specific type of ISO OSI NSAP address in which the

Network Selector octet value is 0x00. NET is a complete address of a host without specifying

any particular network service.

network type A characteristic of OSPF interfaces that determines whether a DR election is

attempted, whether or not neighbors must be statically configured, and the default Hello and

Dead timer settings.

Next Hop field With a routing update, or routing table entry, the portion of a route that

defines the next router to which a packet should be sent to reach the destination subnet. With

routing protocols, the Next Hop field can define a router other than the router sending the

routing update.

NLPID (Network Layer Protocol ID) A field in the RFC 2427 header that is used as a

Protocol Type field to identify the type of Layer 3 packet encapsulated inside a Frame Relay

frame. Also a TLV type used by IS-IS to advertise the routed protocols supported on a router.

NSAP (Network Service Access Point) ISO OSI Layer 3 address format.

NSSA (not-so-stubby area) A type of OSPF stub area that, unlike stub areas, can inject

external routes using its own ASBR but does not receive external routes from the backbone

area.

NTP (Network Time Protocol) An Internet standard (RFC 1305) that defines the messages

and modes used for IP hosts to synchronize their time-of-day clocks.

NTP client mode An NTP mode in which an NTP host adjusts its clock in relation to an

NTP server’s clock.

NTP server mode An NTP mode in which an NTP host does not adjust its clock, but in

which it sends NTP messages to clients so that the clients can update their clocks based on

the server’s clock.

NTP symmetric active mode An NTP mode in which two or more NTP servers mutually

synchronize their clocks.

ptg13046388

Glossary 17

offset list A Cisco IOS configuration tool for RIP and EIGRP for which the list matches

routes in routing updates, and adds a defined value to the sent or received metric for the

routes. The value added to the metric is the offset .

Outside Global address A NAT term describing the IP address of a host located in the

outside part of the network, as seen by other hosts in the outside part of the network (outside

host’s true IP address).

Outside Local address A NAT term describing the IP address of a host located in the out-

side part of the network, as seen by hosts in the inside part of the network (outside host’s IP

address after possible translation).

Overload bit A flag in an IS-IS Link State PDU. If set, it indicates that the router should not

be considered as a transit router in the SPF calculation; only directly connected networks on

that router shall be considered.

overloading A n o t h e r t e r m f o r Port Address Translation .

PAgP (Port Aggregation Protocol) A Cisco-proprietary messaging protocol used to

negotiate the dynamic creation of EtherChannel bundles and to choose which ports can be

placed into an EtherChannel bundle.

partial SPF calculation An SPF calculation for which a router does not need to run SPF

for any LSAs inside its area, but instead runs a very simple algorithm for changes to LSAs out-

side its own area.

partial update A routing protocol feature by which the routing update includes only routes

that have changed rather than the entire set of routes.

passive A state for a route in an EIGRP topology table that indicates that the router

believes that the route is stable, and it is not currently looking for any new routes to that

subnet.

PAT (Port Address Translation) A NAT term describing the process of multiplexing TCP

and UDP flows, based on port numbers, to a small number of public IP addresses. Also called

NAT overloading .

poison reverse Loop-prevention technique used in distance-vector routing protocols, the

full name is Split Horizon with Poisoned Reverse. Under this technique, a network will be

explicitly advertised as unreachable over the interface that is used to reach that network.

polarization In CEF load balancing, the undesirable effect of a path selection function

producing the same result for all data flows that have already been load balanced, preventing

these flows from ever being load balanced again.

policy routing Cisco IOS router feature by which a route map determines how to forward a

packet, typically based on information in the packet other than the destination IP address.

ptg13046388

18 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

PortFast Cisco-proprietary STP feature in which a switch port, known to not have a bridge

or switch attached to it, transitions from the disabled to forwarding state without using any

intermediate states.

PPPoE (Point-to-Point Protocol over Ethernet) An encapsulation protocol and related

control protocol that allows creating and carrying PPP sessions over Ethernet. Very often

used in DSL deployments.

prefix A numeric value between 0 and 32 for IPv4, or 0 and 128 for IPv6 (inclusive) that

defines the number of beginning bits in an IP address for which all IP addresses in the same

group have the same value. Alternative: The number of binary 1s beginning a subnet mask,

written as a single decimal value, used as a more convenient form of representing the subnet

mask.

prefix list A Cisco IOS configuration tool that can be used to match routing updates based

on a base network address, a prefix, and a range of possible masks used inside the values

defined by the base network address and prefix.

prefix suppression In OSPF, a feature that prevents prefixes on transit links from being

advertised.

priority In OSPF, an administrative setting, included in Hellos, that is the first criterion for

electing a DR. The highest priority wins, with values from 1 to 255, with priority 0 meaning

that a router cannot become DR or BDR.

private addresses RFC 1918–defined IPv4 network numbers that are not assigned as pub-

lic IP address ranges, and are not routable on the Internet. Intended for use inside enterprise

networks.

private VLAN A Cisco switch feature that allows separation of ports as if they were in

separate VLANs, while allowing the use of a single IP subnet for all ports.

process switching A Layer 3 forwarding path through a router that does not optimize the

forwarding path through the router.

promiscuous port With private VLANs, a port that can send and receive frames with all

other ports in the private VLAN and associated secondary VLANs.

proxy ARP A router feature used when a router sees an ARP request searching for an IP

host’s MAC, when the router believes that the IP host could not be on that LAN because

the host is in another subnet. If the router has a route to reach the subnet where the ARP-

determined host resides, the router replies to the ARP request with the router’s MAC address.

pseudonode In OSPF and IS-IS, the concept of representing a multiaccess network as a

standalone node (a pseudonode) in the link-state database. OSPF represents each multiaccess

network by a corresponding type 2 LSA. IS-IS generates a standalone Link State PDU.

PSNP (Partial Sequence Number PDU) An IS-IS packet type used in the link-state data-

base synchronization procedure between routers.

PVST+ (Per-VLAN Spanning Tree Plus) A Cisco-proprietary STP implementation, cre-

ated many years before IEEE 802.1s and 802.1w, that speeds convergence and allows for one

STP instance for each VLAN.

ptg13046388

Glossary 19

quartet A set of four hex digits listed in an IPv6 address. Each quartet is separated by a

colon.

query An EIGRP message that is used to ask neighboring routers to verify their route to a

particular subnet. Query messages require an Ack.

query scope The characterization of how far EIGRP Query messages flow away from the

router that first notices a failed route and goes active for a particular subnet.

RARP (Reverse ARP) A standard (RFC 903) protocol by which a LAN-attached host can

dynamically broadcast a request for a server to assign it an IP address. See also ARP .

RD (reported distance) In EIGRP, the metric (distance) of a route as reported by a neigh-

boring router.

RD (Route Distinguisher) A 64-bit extension to the BGP NLRI field, used by MPLS for

the purpose of making MPLS VPN customer routes unique to BGP and its operation in spite

of the possibility of overlapping IPv4 address spaces in different customer networks.

remote VLAN The destination VLAN for an RSPAN session.

Reply An EIGRP message that is used by neighbors to reply to a query. Reply messages

require an Ack.

Response In the context of SNMP, the Response command is sent by an SNMP agent,

back to a manager, in response to any of the three types of Get requests, or in response to

a Set request. It is also used by a manager in response to a received Inform command from

another SNMP manager. The Response holds the value(s) of the requested variables.

RIB (Routing Information Base) The basic, unoptimized routing table on a router that

serves as a master copy of routing information used to build CEF FIB. RIB can also refer

to internal routing tables maintained by individual routing protocols. Routes in these per-

protocol internal routing tables can be used in the routing protocol operation, and best routes

can be offered to the router’s routing table manager.

RID (router ID) The 32-bit number used to represent a router in a particular protocol.

OSPF, EIGRP, BGP, and LDP are examples of protocols that make use of router IDs.

Root Guard Cisco-proprietary STP feature in which a switch port monitors for incoming

superior Hellos, and reacts to a superior Hello by putting the port into the root-inconsistent

blocking state to prevent any switch connected to that port from becoming root.

Root Port The single port on each nonroot switch upon which the best resulting Hello

BPDU is received.

route map A configuration tool in Cisco IOS that allows basic programming logic to be

applied to a set of items. Often used for decisions about what routes to redistribute, and for

setting particular characteristics of those routes—for example, metric values.

ptg13046388

20 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

route poisoning The process of sending an infinite-metric route in routing updates when

that route fails.

route redistribution The process of taking routes known through one routing protocol and

advertising those routes with another routing protocol.

Route Tag field A field within a route entry in a routing update, used to associate a generic

number with the route. It is used when passing routes between routing protocols, allowing an

intermediate routing protocol to pass information about a route that is not natively defined to

that intermediate routing protocol. Frequently used for identifying certain routes for filtering

by a downstream routing process.

routed interface An interface on a Cisco IOS–based switch that is treated as if it were an

interface on a router.

RPVST+ (Rapid Per-VLAN Spanning Tree Plus) The combination of PVST+ and Rapid

Spanning Tree. It provides subsecond convergence time and is compatible with PVST+ and

MSTP.

RSPAN (Remote Switched Port Analyzer) A method of collecting traffic received on a

switch port or a VLAN and sending it to specific destination ports on a switch other than the

one on which it was received.

RSTP (Rapid Spanning Tree Protocol) Defined in IEEE 802.1w, a specification to

enhance the 802.1D standard to improve the speed of STP convergence.

RTO (Retransmission Timeout) With EIGRP, a timer starts when a reliable (to be

acknowledged) message is transmitted. For any neighbor(s) failing to respond in its RTO, the

RTP protocol causes retransmission. RTO is calculated based on SRTT.

RTP (Reliable Transport Protocol) A protocol used for reliable multicast and unicast

transmissions. Used by EIGRP.

SEL (Selector) Also known as Network Selector. The last octet of an ISO OSI NSAP

address describing the requested network service on the host identified by the NSAP address.

If the value of the SEL octet is 0x00, the NSAP address refers to the host as a unit, not to any

particular network service, and is also called the Network Entity Title (NET).

sequence number In many protocols, the sequence number is a datagram number or a

pointer into a data stream, used to facilitate ordered and optionally reliable delivery and data-

gram loss detection. In Weighted Fair Queuing, a term for the number assigned to a packet as

it is enqueued into a WFQ. WFQ schedules the currently lowest SN packet next.

Set In the context of SNMP, the Set command is sent by an SNMP manager, to an agent,

requesting that the agent set a single identified variable to the stated value. The main purpose

is to allow remote configuration and remote operation, such as shutting down an interface by

using an SNMP Set of an interface state MIB variable.

SLSM (static length subnet masking) A strategy for subnetting a classful network for

which all masks/prefixes are the same value for all subnets of that one classful network.

ptg13046388

Glossary 21

SMI (Structure of Management Information) The SNMP specifications, standardized in

RFCs, defining the rules by which SNMP MIB variables should be defined.

SNMP agent A process on a computing device that accepts SNMP requests, responds with

SNMP-structured MIB data, and initiates unsolicited Trap messages back to an SNMP man-

agement station.

SNMP manager A process on a computing device that issues requests for SNMP MIB vari-

ables from SNMP agents, receives and processes the MIB data, and accepts unsolicited Trap

messages from SNMP agents.

SNPA (Sub Network Point of Attachment) ISO OSI term for a Layer 2 address.

SPAN (Switched Port Analyzer) A method of collecting traffic received on a switch port

or a VLAN and sending it to specific destination ports on the same switch.

SPF algorithm The algorithm used by OSPF and IS-IS to compute routes based on the

LSDB.

SPF calculation The process of running the SPF algorithm against the LSDB, with the

result being the determination of the current best route(s) to each subnet.

split horizon Instead of advertising all routes out a particular interface, the routing protocol

omits the routes whose outgoing interface field matches the interface out which the update

would be sent.

SRTT (Smoothed Round-Trip Time) With EIGRP, a purposefully slowly changing mea-

surement of round-trip time between neighbors, from which the EIGRP RTO is calculated.

STP (Spanning Tree Protocol) Defined in IEEE 802.1D, a protocol used on LAN bridges

and switches to dynamically define a logical network topology that allows all devices to be

reached, but prevents the formation of loops.

straight-through cable Copper cable with RJ-45 connectors in which both ends of a cable

use an identical pinout.

stub area An OSPF area into which external (type 5) LSAs are not introduced by its ABRs;

instead, the ABRs originate and inject default routes into the area.

stub area type S e e stub area .

stub network A network/subnet to which only one OSPF router is connected.

stub router In EIGRP, a router that should not be used to forward packets between other

routers. A stub router will not propagate EIGRP-learned routes and will respond to Queries in

a limited way. Other routers will not send Query messages to a stub router. In OSPF, a router

that should either permanently or temporarily not be used as a transit router. Can wait a cer-

tain time after the OSPF process starts, or after BGP notifies OSPF that BGP has converged,

before ceasing to be a stub router.

stuck-in-active The condition in which a route has been in an EIGRP active state for longer

than the router’s Active timer.

ptg13046388

22 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

subnet A subset of a classful IP network, as defined by a subnet mask, which is used to

address IP hosts on the same Layer 2 network in much the same way as a classful network is

used.

subnet broadcast address A single address in each subnet for which packets sent to this

address will be broadcast to all hosts in the subnet. It is the highest numeric value in the range

of IP addresses implied by a subnet number and prefix/mask.

subnet mask A dotted-decimal number used to help define the structure of an IP address.

The binary 0s in the mask identify the host portion of an address, and the binary 1s identify

either the combined network and subnet part (when thinking classfully) or the network prefix

(when thinking classlessly).

subnet number A dotted-decimal number that represents a subnet. It is the lowest numeric

value in the range of IP addresses implied by a subnet number and prefix/mask.

subnet zero When subnetting a Class A, B, or C address, the subnet for which all subnet

bits are binary 0. The network address of this subnet is numerically identical to the address of

the former unsubnetted Class A, B, or C network.

successor route With EIGRP, for a particular destination, a route through the successor,

meaning a route whose total metric is the lowest available, and that uses a neighbor guaran-

teed to provide a loop-free path.

summary route A route that is created to represent one or more smaller component routes,

typically in an effort to reduce the size of routing and topology tables.

superior BPDU Out of two BPDUs being compared, the one that is “better,” that is, the

one that contained a lower numerical value in the first field that broke the tie (the fields are

compared in the sequence Root Bridge ID, Root Path Cost, Sending Bridge ID, and Sending

Port ID).

switched interface An interface on a Cisco IOS–based switch that is treated as if it were

an interface on a switch.

three-way handshake A process of establishing a communication relation in which both

communication parties mutually and explicitly indicate their willingness to engage into the

relation and acknowledge the other party’s indication. The three-way handshake is used in

several protocols including TCP, EIGRP (during initial adjacency creation), and IS-IS (during

initial adjacency creation on point-to-point links).

TLV (Type-Length-Value) A particular format of storing and transmitting information of

multiple types in a single datagram.

totally NSSA area A type of OSPF NSSA area for which neither external (type 5) LSAs are

introduced, nor type 3 summary LSAs; instead, the ABRs originate and inject default routes

into the area. External routes can be injected into a totally NSSA area by its own ASBR.

ptg13046388

Glossary 23

totally stubby area A type of OSPF stub area for which neither external (type 5) LSAs are

introduced, nor type 3 summary LSAs; instead, the ABRs originate and inject default routes

into the area. External routes cannot be injected into a totally stubby area.

transit network A network/subnet over which two or more OSPF routers have become

neighbors, thereby being able to forward packets from one router to another across that

network.

transit router A router that is allowed to receive a packet from an OSPF router and then

forward the packet to another OSPF router.

Trap In the context of SNMP, the Trap command is sent by an SNMP agent, to a manager,

when the agent wants to send unsolicited information to the manager. Trap is not followed by

a Response message from the receiving SNMP manager.

Triggered Extensions to RIPv2 for On-Demand Circuits Defined in RFC 2091, the

extensions define how RIP can send a full update once, and then send updates only when

routes change, when an update is requested, or when a RIP interface changes state from down

to up.

triggered updates A routing protocol feature for which the routing protocol sends routing

updates immediately upon hearing about a changed route, even though it might normally only

send updates on a regular update interval.

TTL (Time to Live) A field in the IP header that is decremented at each pass through a

Layer 3 forwarding device.

U/L bit Universal/Local bit. The second least significant bit in the most significant byte

of an Ethernet MAC address. A value of binary 0 implies that the address is a Universally

Administered Address (UAA) (also known as a Burned-In Address [BIA]), and a value of binary

1 implies that the MAC address is a locally configured address.

UDLD (UniDirectional Link Detection) Cisco-proprietary protocol used to detect unidi-

rectional link conditions and deactivate such links to prevent a switching loop from occurring.

unicast address An address describing a single receiver.

Update An EIGRP message that informs neighbors about routing information. Update mes-

sages require an Ack.

Update timer With RIP, the regular interval at which updates are sent. Each interface uses

an independent timer, defaulting to 30 seconds.

ptg13046388

24 CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1

variance An integer setting for EIGRP. Allows using paths provided by feasible successors

as long as these are at most variance times longer than the corresponding shortest paths.

virtual IP address The IP address used by hosts as the default gateway in a VRRP configu-

ration. This address is shared by two or more VRRP routers.

virtual link With OSPF, the encapsulation of OSPF messages inside IP, to a router with

which no common subnet is shared, for the purpose of either mending partitioned areas or

providing a connection from some remote area to the backbone area.

VLAN (virtual LAN) A 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.

VLAN filtering Removing unwanted VLANs from a Layer 2 path.

VLSM (variable-length subnet masking) A strategy for subnetting a classful network for

which masks/prefixes are different for some subnets of that one classful network.

VRRP (Virtual Router Redundancy Protocol) A standard (RFC 3768) feature by which

multiple routers can provide interface IP address redundancy so that hosts using the shared,

virtual IP address as their default gateway can still reach the rest of a network even if one or

more routers fail.

VRRP Master router The router in a VRRP group that is currently actively forwarding IP

packets. Conceptually the same as an HSRP Active router.

VSL (Virtual Switch Link) An interchassis link carrying control and data traffic between a

pair of Catalyst 4500 or 6500 series switches that are combined into a single network element

using the Virtual Switching System technology. See also VSS .

VSS (Virtual Switching System) Cisco-proprietary technology that allows a pair of

Catalyst 4500 or 6500 Series switches to be interconnected and combined into a single net-

work element.

VTP pruning VTP process that prevents the flow of broadcasts and unknown unicast

Ethernet frames in a VLAN from being sent to switches that have no ports in that VLAN.

CCIE Routing And Switching V5.0 Official Cert Guide, Volume 1, 5/e & V5 Guide.Volume.1.5th.Edition

Navigation menu

Versions of this User Manual:

Views

Navigation