CCIE Enterprise Infrastructure
Foundation
Narbik Kocharians
Cisco Press
CCIE Enterprise Infrastructure Foundation
Narbik Kocharians
Copyright© 2023 Pearson Education, Inc.
Published by: Cisco Press
All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction,
storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information
regarding permissions, request forms, and the appropriate contacts within the Pearson Education Global Rights & Permissions Department, please visit
www.pearson.com/permissions.
No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of
this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of
the information contained herein.
ScoutAutomatedPrintCode
Library of Congress Control Number: 2022902108
ISBN-13: 978-0-13-737424-3
ISBN-10: 0-13-737424-0
Warning and Disclaimer
This book is designed to provide information about the CCIE Enterprise Infrastructure certification. 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 accompany it.
The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.
Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been appropriately 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 intlcs@pearson.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.
Editor-in-Chief: Mark Taub
Alliances Manager, Cisco Press: Arezou Gol
Director, ITP Product Management: Brett Bartow
Executive Editor: James Manly
Managing Editor: Sandra Schroeder
Development Editor: Ellie Bru
Project Editor: Mandie Frank
Copy Editor: Kitty Wilson
Technical Editors: Sarah Anand; Dante McNeil
Editorial Assistant: Cindy Teeters
Designer: Chuti Prasertsith
Composition: codeMantra
Indexer: Timothy Wright
Proofreader: Donna E. Mulder
Credits
Unnumbered figures on pages 860-861
PuTTY
Pearson’s Commitment to Diversity, Equity, and Inclusion
Pearson is dedicated to creating bias-free content that reflects the diversity of all learners. We embrace the many dimensions of
diversity, including but not limited to race, ethnicity, gender, socioeconomic status, ability, age, sexual orientation, and religious or
political beliefs.
Education is a powerful force for equity and change in our world. It has the potential to deliver opportunities that improve lives and
enable economic mobility. As we work with authors to create content for every product and service, we acknowledge our responsibility to demonstrate inclusivity and incorporate diverse scholarship so that everyone can achieve their potential through learning.
As the world’s leading learning company, we have a duty to help drive change and live up to our purpose to help more people create a better life for themselves and to create a better world.
Our ambition is to purposefully contribute to a world where
Everyone has an equitable and lifelong opportunity to succeed through learning
Our educational products and services are inclusive and represent the rich diversity of learners
Our educational content accurately reflects the histories and experiences of the learners we serve
Our educational content prompts deeper discussions with learners and motivates them to expand their own learning (and
worldview)
While we work hard to present unbiased content, we want to hear from you about any concerns or needs with this Pearson product
so that we can investigate and address them.
Please contact us with concerns about any potential bias at https://www.pearson.com/report-bias.html.
About the Author
Narbik Kocharians, CCIE No. 12410 (Routing and Switching, Service Provider, and Security) is a triple CCIE with more than 46
years of experience in this industry. He has designed, implemented, and supported numerous small, mid-size, and large enterprise
networks.
Narbik is the president of Micronics Networking and Training, Inc. (www.MicronicsTraining.com), where almost all Cisco-authorized
and custom courses are conducted, including CCIE-DC, CCIE-SP, CCIE-Enterprise Infrastructure, CCDE, ACI, and many more.
About the Technical Reviewers
Sarah Anand has been affiliated with different networking technologies, including Cisco-specific implementations, for 7 years, with
a focus on routing/switching and service provider technologies. Currently she works as a technical writer and editor, training network engineers in vendor-specific and industry-standard technologies. She has a degree in computer science and enjoys spending
free time exploring passions in web design and search engine optimization.
Dante McNeil has 10 years of IT networking experience in the nonprofit, enterprise, K–12, and higher education spaces, with a focus on advanced networking implementations and Cisco technologies. He also spends time writing and creating network training
content for networking engineers. He holds a bachelor of science degree in computing information sciences from Jacksonville
University. In his spare time, he enjoys roller coasters, video games, and road trips.
Dedications
I would like to dedicate this book to my beautiful wife, Janet, my children and their spouses, Chris and Nona (aka Siroon Achik),
Patrick and Diana (aka Bestelik Jan), Alexandra (aka Achiko) and Sevak, and Daniel (aka Chompolik), as well as our first grandson, Matthew (aka Jigar), whom I LOVE so much, he brightens my day every morning!
I would like to acknowledge with gratitude the support, sacrifice, and love of my family for making this book possible. I thank God
for the health and wisdom that He has instilled in me, my lovely family, my first grandson Mathew, and my father, who was my best
friend.
Acknowledgments
A very special thanks to James and Eleanor. I remember brainstorming with James for hours about this book, and eventually he
came up with the ultimate solution. I would like to thank Eleanor for having a tremendous amount of patience and professionalism.
I would also like to thank my tech editors, Sarah Anand and Dante McNeil, two gifted network engineers with a tremendous amount
of knowledge. God willing, I will be working with these two champions for a long time to come. They are not CCIEs yet, but their
knowledge is on par with the best CCIEs out there.
Contents at a Glance
Introduction
Chapter 1
Switching
Chapter 2
IP Prefix Lists
Chapter 3
RIPv2
Chapter 4
EIGRP
Chapter 5
OSPF
Chapter 6
BGP
Chapter 7
DMVPN
Chapter 8
MPLS and L3VPNs
Chapter 9
IPv6
Chapter 10
SD-WAN
Chapter 11
SD-Access
Index
Reader Services
Register your copy at www.ciscopress.com/title/ISBN for convenient access to downloads, updates, and corrections as they become available. To start the registration process, go to www.ciscopress.com/register and log in or create an account*. Enter the
product ISBN 9780137374243 and click Submit. When the process is complete, you will find any available bonus content under
Registered Products.
*Be sure to check the box that you would like to hear from us to receive exclusive discounts on future editions of this product.
Contents
Introduction
Chapter 1
Switching
Lab 1: Configuring Trunks
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Task 15
Task 16
Task 17
Task 18
Task 19
VTP Pruning
Task 20
Task 21
Task 22
Task 23
Task 24
Task 25
Task 26
Task 27
Task 28
Lab 2: Configuring EtherChannels
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Lab 3: Introducing Spanning Tree Protocol
802.1D Per-VLAN Spanning Tree Protocol
Task 1
Task 2
Task 3
Task 4
Configuration Tasks: 802.1D
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
802.1w Per-VLAN Rapid Spanning Tree Protocol
Task 1
Task 2
Task 3
Task 4
802.1w Configuration Tasks
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
802.1s Multiple Spanning Tree Protocol
Task 1
Task 2
Task 3
Task 4
Let’s Explore 802.1s
Task 1
Task 2
Task 3
Task 4
Chapter 2
IP Prefix Lists
Lab 1: Prefix Lists
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Chapter 3
RIPv2
Lab 1: Configuring RIPv2
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Task 15
Task 16
Task 17
Task 18
Task 19
Task 20
Lab 2: Helper Map
Task 1
Task 2
Task 3
Task 4
Lab 3: RIPv2 Challenge Lab
Ticket 1
Ticket 2
Ticket 3
Ticket 4
Ticket 5
Ticket 6
Ticket 7
Ticket 8
Ticket 9
Chapter 4
EIGRP
Lab 1: EIGRP Named Mode
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Lab 2: EIGRP and Bidirectional Forwarding Detection (BFD)
Task 1
Task 2
Task 3
Task 4
Lab 3: EIGRP Stub
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Lab 4: EIGRP Filtering
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Lab 5: Advanced EIGRP Lab
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Lab 6: EIGRP Authentication
Task 1
Task 2
Task 3
Lab 7: EIGRP Challenge Lab
Ticket 1
Ticket 2
Ticket 3
Ticket 4
Ticket 5
Ticket 6
Ticket 7
Ticket 8
Chapter 5
OSPF
Lab 1: Running OSPF on the Interfaces
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Lab 2: OSPF Broadcast Networks
Task 1
Task 2
Task 3
Lab 3: OSPF Non-broadcast Networks
Task 1
Task 2
Lab 4: OSPF Point-to-Point Networks
Task 1
Task 2
Lab 5: OSPF Point-to-Multipoint and Point-to-Multipoint Non-broadcast Networks
Task 1
Task 2
Task 3
Lab 6: OSPF Area Types
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Task 15
Lab 7: OSPF Filtering
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Task 15
Task 16
Task 17
Task 18
Task 19
Task 20
Lab 8: OSPF Summarization
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Lab 9: Virtual Links and GRE Tunnels
Task 1
Task 2
Task 3
Task 4
Lab 10: Default Route Injection
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Lab 11: OSPF Authentication
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Lab 12: OSPF Best-Path Determination
Task 1
Task 2
Task 3
Lab 13: OSPF Challenge Lab
Ticket 1
Ticket 2
Ticket 3
Ticket 4
Ticket 5
Ticket 6
Ticket 7
Ticket 8
Chapter 6
BGP
Lab 1: Establishing a BGP Session Using the Correct TTL Value
BGP Peering Session Overview
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Lab 2: Establishing Neighbor Adjacency Using Different Methods
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Lab 3: Route Reflectors
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Lab 4: BGP Confederation
Task 1
Task 2
Task 3
Task 4
Lab 5: BGP Backdoor and Conditional Advertisement
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Lab 6: BGP Aggregation
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Lab 7: BGP Filtering
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Task 15
Task 16
Task 17
Lab 8: BGP Load Balancing
Task 1
Task 2
Task 3
Task 4
Task 5
Lab 9: Remove-Private-AS: A Walkthrough
Lab 10: AS Migration
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Lab 11: BGP Best-Path Algorithm: A Walkthrough
Introduction
Building Blocks of BGP
Path Vector
Controlling Routing to Paths
Path Attributes
Modifying Path Attributes
The Best-Path Algorithm
Step 1: WEIGHT
Step 2: Local Preference
5.1.5. LOCAL_PREF
Step 3: Locally Originated
Step 4: AS_PATH
AS_PATH Inbound
5.3. AS_PATH and Path Selection
Step 5: Origin Code
Step 6: MED
Step 7: eBGP over iBGP
Confederations
Step 8: Lowest IGP Metric to the Next Hop
Step 9: Determine if Multiple Paths Exist
Step 10: Oldest Route
Step 11: Lowest Router ID
Step 12: Minimum Cluster List Length
Step 13: Lowest Neighbor Address
Chapter 7
DMVPN
Introduction to DMVPN
DMVPN Mechanics
DMVPN Designs
Phase 1: Hub-and-Spoke
Dynamic Spoke-to-Spoke Tunnels
The Need for Spoke-to-Spoke Tunnels
Enabling Multipoint GRE on Spokes
Forming Spoke-to-Spoke Tunnels
Triggering NHRP Resolutions
Phase 2: Spoke-Initiated Spoke-to-Spoke Tunnels
Phase 2 Spoke-to-Spoke Tunnel Caveats
Phase 3: Hub-Initiated Spoke-to-Spoke Tunnels
Shortcut or Override
Conclusion
Lab 1: Single Hub, Single Cloud
Implement Phase 1
Design Goal
DMVPN Tunnel Configuration
Implement OSPF
Summarization with OSPF
Implement EIGRP
Implement iBGP
Implement eBGP
Implement Phase 2
Design Goal
DMVPN Tunnel Configuration
Implement OSPF
Implement EIGRP
Implement iBGP
Implement eBGP
Implement Phase 3
Design Goal
DMVPN Tunnel Configuration
Implement OSPF
Implement EIGRP
Implement iBGP
Implement eBGP
Lab 2: Single Hub, Dual Cloud
Implement Phase 1
Design Goal
DMVPN Tunnel Configuration
Implement OSPF
Broadcast Network Type
Implement EIGRP
Implement iBGP
Implement eBGP
Implement Phase 2
Design Goal
DMVPN Tunnel Configuration
Implement OSPF
Implement EIGRP
Implement iBGP
Implement eBGP
Potential Solution to Above Problems
Implement Phase 3
Design Goal
DMVPN Tunnel Configuration
Implement EIGRP
Implement iBGP
Implement eBGP
Lab 3: Dual Hub, Single Cloud
Implement Phase 3
Design Goal
DMVPN Tunnel Configuration
Implement EIGRP
Implement iBGP
Implement eBGP
Lab 4: Dual Hub, Dual Cloud
Implement Phase 3
Design Goal
DMVPN Tunnel Configuration
Implement EIGRP
Implement iBGP
Implement eBGP
Lab 5: DMVPN NHS Clustering
Task 1
Task 2
Task 3
Task 4
Lab 6: DMVPN and DHCP
Task 1
Task 2
Task 3
Chapter 8
MPLS and L3VPNs
Lab 1: Configuring Label Distribution Protocol
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Task 15
Task 16
Lab 2: Static and RIPv2 Routing in a VPN
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Lab 3: EIGRP Routing in a VPN
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Lab 4: EIGRP Site-of-Origin
Task 1
Task 2
Task 3
Task 4
Task 5
Lab 5: OSPF Routing in a VPN
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Lab 6: Backdoor Links and OSPF
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Lab 7: BGP Routing in a VPN
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Lab 8: MPLS and NAT
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Lab 9: Route Targets, Import Maps, and Export Maps
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Lab 10: Internet Access Methods: Partial Internet Routes
Task 1
Task 2
Task 3
Task 4
Chapter 9
IPv6
Lab 1: Acquiring an IPv6 Address
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Lab 2: DMVPN and IPv6
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Lab 3: Configuring OSPFv3
Task 1
Task 2
Task 3
Lab 4: Summarization of Internal and External Networks
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Lab 5: OSPFv3 Broadcast Networks
Task 1
Task 2
Task 3
Task 4
Lab 6: OSPFv3 Non-Broadcast Networks
Task 1
Task 2
Lab 7: OSPFv3 Point-to-Point Networks
Task 1
Task 2
Lab 8: OSPFv3 Point-to-Multipoint Networks
Task 1
Task 2
Task 3
Lab 9: OSPFv3 Cost and Auto-Cost
Task 1
Task 2
Task 3
Lab 10: LSAs in OSPFv3
Task 1
Task 2
Task 3
Task 4
Task 5
Lab 11: OSPFv3 Area Types
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Lab 12: OSPFv3 Authentication
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Lab 13: EIGRPv6
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Task 13
Task 14
Lab 14: BGP Configuration
Task 1
Task 2
Task 3
Task 4
Chapter 10
SD-WAN
Lab 1: Onboarding WAN Edge Devices
Site 2: CSR 1000v Onboarding
Lab 2: Exploring Unicast Routing
Lab 3: Configuring Segmentation in All Sites Using VRF 100 and VRF 200
Branch-1
Branch-2
Lab 4: Configuring vEdge Using a Feature Template
Lab 5: Configuring vEdge Using a vManage Feature Template
Lab 6: Configuring cEdge Using a BR-2–Specific vManage Feature Template
Lab 7: Configuring vEdge Using a vManage Feature Template and ZTP
Creating a DHCP Server on ISP-1
Lab 8: Configuring an Application-Aware Routing Policy
Chapter 11
SD-Access
Lab 1: Configuring the SDA Policy Engine
Task 1: ISE Integration with DNA Center
Task 2: Finalize the Integration on DNA Center
Lab 2: SDA Design
Task 1: Design the Network Hierarchy
Task 2: Configure Common Network Settings
Task 3: Configure Device Credentials
Task 4: Create and Reserve IP Address Pools
Lab 3: Building the SDA Campus Fabric
Task 1: Discover Devices
Task 2: Provisioning the Devices
Lab 4: LAN Automation
Index
Command Syntax Conventions
The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference.
The Command Reference describes these conventions as follows:
Boldface indicates commands and keywords that are entered literally as shown. In actual configuration examples and output
(not general command syntax), boldface indicates commands that are manually input by the user (such as a show command).
Italic indicates arguments for which you supply actual values.
Vertical bars (|) separate alternative, mutually exclusive elements.
Square brackets ([ ]) indicate an optional element.
Braces ({ }) indicate a required choice.
Braces within brackets ([{ }]) indicate a required choice within an optional element.
Introduction
Enterprise networking has undergone many small changes over the years, building from
simple shared bus LANs to intricate routing and switching architectures and wireless
communications. Behind all of this is a need to ensure high reliability, agility, and speed.
Through the decades, many different networking technologies, from physical connections
to software protocols, have been created to assist enterprise networks in reaching
those goals. For seasoned networking veterans, working with the various protocols and
architectures is second nature. However, those who are just starting to build their careers
and trying to study more advanced areas of network engineering may be overwhelmed
by the multitude of routing protocols, Layer 2 features, and new buzzwords like “softwaredefined.”
This book is written as a foundation guide for the most common enterprise networking
concepts that are required for a network engineer looking to move forward to more
advanced aspects of networking. It combines aspects of theory instruction with practical
application. Topics such as LAN switching, IP routing, and overlay networking technologies
such as DMVPN are explained as foundational topics, including examples. Each
chapter also functions as a lab manual with a task-oriented structure. Lab scenarios are
presented as either configuration objectives, troubleshooting scenarios, or design scenarios.
Each lab scenario includes full solutions and explanations. For beginner to intermediate
readers, the solutions can be read while solving the tasks. Advanced readers can challenge
their knowledge and skills by solving tasks first and then comparing their solutions
to the ones provided in this book.
This book is not meant to be an exhaustive study of all the included technologies. It is
meant to provide enough information on all topics to allow you to speak intelligently
about each technology and even implement some of the configurations, if necessary, in
your own environment. It takes topics from Cisco’s CCIE Enterprise Infrastructure certification
blueprint but includes some legacy topics, where necessary, to facilitate understanding.
Who This Book Is For
Although the title of this book is CCIE Enterprise Infrastructure Foundation, the target
audience is not limited to just those seeking expert-level certification. Any person
looking to learn a little bit more about these foundational technologies will find this
book very accessible.
This book breaks down complicated topics and provides examples to maximize understanding.
It does, however, assume some basic networking knowledge. The following types of readers will
get the most out of this book:




Those who have completed CCNA certification and are part of the way through
their preparation for CCNP Enterprise certification
Those who have completed CCNP Enterprise certification and are pursuing CCIE
Those who are currently working in an environment that is implementing specific
technologies covered in this book
Those who are migrating from another vendor to a Cisco environment and need to
understand Cisco configurations for common networking protocols
How This Book Is Organized
This book is divided into the 11 chapters described here. Every chapter can stand alone
and can be used as a reference for the technologies it covers.
Chapter 1: Switching
Chapter 1 introduces Layer 2 concepts such as preventing loops with Spanning Tree
Protocol, segmenting with VLANs, extending VLANs between switches through trunking,
and bonding multiple Ethernet links together to increase bandwidth between network
nodes. It covers topics such as Spanning Tree Protocol, RSTP, MSTP, VTP and
VTP pruning, 802.1Q and ISL trunking, and LACP and PAgP.
Chapter 2: IP Prefix Lists
Chapter 2 introduces a common route filtering mechanism known as a prefix list. It
explains why prefix lists were invented and why they are used over access lists for route
filtering. This chapter shows how to write prefix lists and apply them in various routing
protocols for filtering routes.
Chapter 3: RIPv2
Chapter 3 introduces Routing Information Protocol (RIP). RIP may not be included on
the exam, but it is a perfect example of a simple distance vector routing protocol that
follows all the standard distance vector designs. It focuses on the simplicity of RIP configuration,
advanced RIP filtering scenarios, and RIP configuration challenges.
Chapter 4: EIGRP
Chapter 4 focuses on Cisco’s improvement on its own version of Interior Gateway
Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP). It introduces
EIGRP as a distance vector protocol that forms neighbor relationships and keeps
a topology table like some other protocols. EIGRP is considered an advanced distance
vector protocol that uses more than simple hop counts to learn loop-free paths through
a network. This chapter covers EIGRP configuration topics such as EIGRP classic and
address family configuration, EIGRP stub routing, and EIGRP with BFD.
Chapter 5: OSPF
Chapter 5 introduces the Open Shortest Path First (OSPF) routing protocol. It begins
with an analysis of how OSPF builds its link-state database (LSDB) with various linkstate
advertisements (LSA) and uses that information to calculate loop-free routed paths
through a network. This chapter also details multiarea OSPF design, filtering, and virtual
links. It includes a detailed walkthrough on OSPF’s best-path determination to help you
understand OSPF’s path selection process.
Chapter 6: BGP
Chapter 6 introduces Border Gateway Protocol (BGP), the protocol that routes the
Internet. It explains BGP operation between autonomous systems (external BGP, or
eBGP) and within a single autonomous system (internal BGP, or iBGP). Topics covered
include BGP session establishment, route reflectors and confederations, aggregation, and
filtering. This chapter includes a detailed walkthrough of the BGP best-path determination
process.
Chapter 7: DMVPN
Chapter 7 focuses on Cisco’s original SD-WAN technology, known as Dynamic
Multipoint VPN (DMVPN). It explains DMVPN from the ground up, introducing concepts
such as overlay and underlay networking, the link between DMVPN and NHRP,
DMVPN routing using common routing protocols, and different DMVPN designs.
It covers DMVPN Phase 1 through Phase 3 configurations, NHRP shortcut switching
enhancements, hub-and-spoke networking designs, and (m)GRE tunnels.
Chapter 8: MPLS and L3VPNs
Chapter 8 introduces Multiprotocol Label Switching (MPLS) and the suite of services
MPLS can provide. This chapter begins with an introduction to MPLS labels and Label
Distribution Protocol (LDP). It also introduces the most common MPLS service, MPLS
Layer 3 VPN (L3VPN). Topics covered include CE and PE routers, MPLS core configuration,
LDP session establishment, BGP route targets and route distinguishers, and
exchange of IGP routes between two sites connected by an MPLS L3VPN.
Chapter 9: IPv6
Chapter 9 introduces Internet Protocol Version 6 (IPv6), which is the successor to IPv4
due to its massive address space. It also details IPv6 address types, assignment, and configuration.
Topics covered include IPv6 NDP, IPv6 SLAAC, DMVPN for IPv6, OSPF for
IPv6 (OSPFv3), EIGRP for IPv6, and BGP for IPv6.
Chapter 10: SD-WAN
Chapter 10 introduces Cisco’s new SD-WAN platform, which is based on its acquisition
of Viptela. This chapter details basic SD-WAN components, such as vSmart, vManage,
and vBond, as well as the setup and configuration required to join vEdge routers to an
SD-WAN solution. Topics covered include onboarding WAN edge devices, unicast routing,
segmentation, vManage device templates, ZTP, and application-aware policies.
Chapter 11: SD-Access
Chapter 11 introduces Cisco’s SD-Access solution for creating scalable, automated, and
resilient enterprise fabric. This chapter covers configuration of the SD-Access policy
engine as well as SDA design and implementation. Topics covered include Cisco ISE,
pxGrid, XMPP, SDA hierarchy global IP pools, DNAC, and LAN automation.
Chapter 1
CCIE
Enterprise Infrastructure
Foundation
v1.0
www.MicronicsTraining.com
Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP
Switching
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 1
Lab 1
Configuring Trunks
What is covered in this lab:
This lab focuses mainly on configuring trunk links and VLANs and controlling which
VLANs are allowed on a particular trunk link. This lab covers the following topics:
dynamic trunks, basic VTP operation, how to modify the allowed VLAN lists on trunk
links, and VTP pruning.
Task 1
Shut down all ports on all six switches and configure the VTP domain name to be
TST.
When receiving a switch and beginning the configuration process for the first time, it is always a best
practice to shut down all ports that are connected to neighboring switches or end devices. Doing so
prevents potential catastrophic harm to the network during the configuration change should an
accidental misconfiguration occur. Such misconfigurations could introduce Layer 2 Bridging loops or lost
VLAN configuration information.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 2
Once the configuration changes have been made and verified, it is then safe to bring the ports up and
verify once again that the desired change has been met. This task starts off by shutting down all ports
on all six switches. Normally, such a task would be very time consuming. Each interface would have to
be manually configured with the shutdown command one-by-one. However, Cisco IOS switches have
what is known as the interface range command that allows selection of multiple interfaces at once for
configuration. This and future tasks make full use of this command to shut down the interfaces on the
switch.
The next part of the task begins the configuration for the VTP settings for the switched domain. VTP is
the VLAN Trunking Protocol developed by Cisco. It was developed to allow switches to dynamically
synchronize the contents of their VLAN databases with each other to ease VLAN configuration in the
network. VTP switches that synchronize their VLAN databases belong to the same VTP domain which
can be manually configured. VTP is automatically enabled on all trunk ports in the topology with some
default settings.
The following “show vtp status” output reveals some of the default settings the switch uses for VTP:
On Any Switch:
Switch#show vtp status
VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
:
VTP Pruning Mode
: Disabled
VTP Traps Generation
: Disabled
Device ID
: aabb.cc80.0e00
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
-------------VTP Operating Mode
Maximum VLANs supported locally
Number of existing VLANs
Configuration Revision
MD5 digest
CCIE by Narbik Kocharians
: Server
: 1005
: 5
: 0
: 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
0x56 0x9D 0x4A 0x3E 0xA5 0x69 0x35 0xBC
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 3
Notice the VTP domain name in the above output is empty. An empty or blank VTP domain name means
that the switch currently does not belong to any VTP domain. In addition, the switch is operating as a
VTP server. This is the default mode on Cisco IOS. In this mode, the devices advertise the contents of
their VLAN databases to neighboring VTP switches. Addtionally, a device in this mode can create,
modify and delete VLANs.
By default, all switches belong to the {NULL} VTP domain. While initialized with a {NULL} VTP Domain
value, the switch will not send any of its own VTP advertisements, but will respond and react to
received VTP advertisements. The switch will adopt the VTP domain name of any VTP advertisement
received as its own VTP domain name and begins sending its own VTP advertisements out of its own
trunk links in accordance to its VTP operating mode.
The task specifies that all switches should be manually configured with the VTP domain name of TST.
This is configured with the VTP domain name domain-name command in global configuration mode.
The following is the complete configuration required on all switches to complete this task:
On All Switches:
SWx(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/03,e6/0-3
SWx(config-if-range)#shut
SWx(config)#vtp domain TST
You should see the following console message:
Changing VTP domain name from NULL to TST
To Verify the configuration:
Switch#show vtp status
VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
: TST
VTP Pruning Mode
: Disabled
VTP Traps Generation
: Disabled
Device ID
: aabb.cc80.0e00
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 4
Feature VLAN:
-------------VTP Operating Mode
Maximum VLANs supported locally
Number of existing VLANs
Configuration Revision
MD5 digest
: Server
: 1005
: 5
: 0
: 0xAD 0x9C 0xE6 0xFA 0x40 0x3D 0x31 0x02
0xFA 0xD9 0xA9 0xE3 0x84 0x71 0x45 0xDD
Task 2
Configure the following hostnames:
Second switch: SW2
Third switch: SW3
Fourth switch: SW4
Fifth switch: SW5
On the second switch:
SW2(config)#hostname SW2
On the third switch:
SW3(config)#hostname SW3
On the fourth switch:
SW4(config)#hostname SW4
On the fifth switch:
SW5(config)#hostname SW5
Task 3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 5
Configure a dot1q trunk between SW3 and SW5 using their E5/0 interfaces, based on the
following policy:
SW3, E5/0
This port should be configured into a permanent trunk mode, and it should negotiate to
convert the neighboring interface into a trunk.
SW5, E5/0
This port should be configured to actively attempt to convert the link to a trunk. You
should not configure switchport trunk encapsulation dot1q on this port.
Cisco switch interfaces can operate in Trunk mode, where multiple VLANs can be carried across the link,
or Access mode, where only a single VLAN is carried across the link. These modes can be configured in
one of two ways:

Static configuration

Dynamic configuration
Static configuration involves manual configuration of the switchport mode command under the interface,
explicitly specifying whether the port is in access or trunk mode. Dynamic configuration relies on the
Dynamic Trunking Protocol or DTP to determine the trunk status.
DTP isn’t limited to only determining the trunk mode, it can also be used to determine the trunk
encapsulation. Cisco switches support both the Cisco-proprietary InterSwitch Link (ISL) and IEEE’s 802.1q
trunk encapsulation styles. DTP makes this determination either automatically or based on the settings
specified by the switchport trunk encapsulation command in interface configuration mode.
The two solutions (ISL, 802.1q) take different approaches to encode the VLAN information. Cisco’s ISL takes the
approach of encapsulating the entire ethernet frame with an ISL header and trailer. Within the ISL header, among other
fields, is the VLAN ID field that corresponds to the VLAN the Ethernet frame originated from. The ISL header is 24bytes in total with a 4-byte CRC trailer used to detect errors in transmission. In total, ISL adds an additional 40 bytes of
overhead to the Ethernet frame, but does not require any modification of the original Ethernet frame.
The IEEE 802.1Q encapsulation method isn’t really encapsulating the Ethernet frame as ISL does. Instead, it inserts a
VLAN “shim” header into the Ethernet frame. The 802.1Q header is greatly simplified from the ISL header containing
only Protocol Identifier, Priority, VLAN ID, and Canonical format indicator fields. Of particular note is the VLAN ID field
which carries the VLAN ID of the VLAN from which the frame originated. The 802.1Q header is 4-bytes in total and is
inserted after the source address field of the original Ethernet header. Since 802.1Q modifies the ethernet header, the
switch must recalculate the FCS trailer of the original Ethernet frame to compensate for the additional header length.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 6
Aside from the physical encoding of the Ethernet frame, the method of operation is the same for both protocols. On
Cisco switches, interfaces that need to carry VLAN information are called trunk ports. Trunk ports can be dynamically
configured or statically assigned. When the switch needs to forward a frame out of a trunk port, it looks at the trunk
port’s configured VLAN encapsulation method. If it is ISL, the switch computes the ISL header and trailer, encapsulates
the Ethernet frame and sends it across the trunk link. If it is 802.1Q, the switch calculates the 802.1Q “shim” header,
inserts it into the Ethernet frame, recalculates the Ethernet FCS and forwards the new Ethernet frame out of the trunk
link. Because 802.1Q merely inserts a “shim” header, the resulting frame can be referred to as an 802.1Q-tagged
frame. This fact is reflected in most non-Cisco hardware where such ports are called “tagged” ports instead of “trunk”
ports.
Switches connected by an interswitch link, must be configured to use the same encapsulation method for encoding
VLAN membership for ethernet frames, otherwise the link will not function properly. In both cases, the receiving switch
examines the ethernet packet, checks the VLAN ID of the ISL or 802.1Q header, removes the VLAN encapsulation (if
necessary) and forwards the bare Ethernet frame out the appropriate ports only if they are a member of the same
VLAN as indicated in the VLAN ID field.
This task states that an 802.1q trunk should be configured between SW3 and SW5’s E5/0 interfaces. The
subtask requirements state that SW3’s E5/0 interface should permanently be in a trunk mode and should
cause the neighboring interface to convert into a trunk mode. The task is completed by first setting SW3’s
E5/0 interface to use 802.1q trunk encapsulation using the switchport trunk encapsulation dot1q
interface-level configuration command. Then, the interface is set to be a static trunk port using the
switchport mode trunk interface-level configuration command, as seen below:
On SW3:
Switch(config)#interface e5/0
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#no shut
NOTE: When statically declaring a port to operate in trunk mode, the trunk encapsulation must be
defined with the switchport trunk encapsulation command first. Failing to do so results in the command
switchport mode trunk being rejected by IOS. In such a situation, the switch will log the following error
message:
SW3(config-if)#switchport mode trunk
Command rejected: An interface whose trunk encapsulation is "Auto" can
not be configured to "trunk" mode.
As the second part of the task states, SW5’s interface should be configured to dynamically negotiate its
trunking mode. This is accomplished by enabling DTP using the switchport mode dynamic desirable
command show below:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 7
On SW5:
SW5(config)#interface e5/0
SW5(config-if)#switchport mode dynamic desirable
SW5(config-if)#no shut
NOTE: On some switch platforms, the default port mode is dynamic desirable.
Once configured with the above command, the switch will perform dynamic trunk mode and
encapsulation negotiation with the other side of the link using DTP. SW5 will send DTP frames out of its
E5/0 interface with the intention of negotiating a trunk link with SW3. The task also restricts the usage of
the switchport trunk encapsulation dot1q command on the E5/0 interface. This is because the trick lies
within SW3.
SW3, being configured as a static 802.1q trunk, will send its own DTP frame to SW5 that indicates that it
would like to participate in an 802.1q trunk as shown in the packet capture below.
--- DTP Packet capture --Dynamic Trunk Protocol: (Operating/Administrative): Trunk/On (0x81)
(Operating/Administrative): 802.1Q/802.1Q (0xa5): aa:bb:cc:00:0b:05
Version: 1
Domain
Trunk Status
Type: Trunk Status (0x0002)
Length: 5
Value: Trunk/On (0x81)
1... .... = Trunk Operating Status: Trunk (0x1)
.... .001 = Trunk Administrative Status: On (0x1) Trunk Type
Type: Trunk Type (0x0003)
Length: 5
Value: 802.1Q/802.1Q (0xa5)
101. .... = Trunk Operating Type: 802.1Q (0x5) .... .101 = Trunk Administrative Type: 802.1Q
(0x5)
[ -- output omitted for brevity -- ]
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 8
This happens because static configuration of trunk mode or encapsulation does not disable the DTP on an
interface. In other words, the switchport mode trunk command does not disable transmission of DTP
frames on a link.
SW5 will use the information from the DTP frame that SW3 sent and set the encapsulation on its E5/0
interface to 802.1q. SW3 is forcing SW5 to negotiate an 802.1q trunk relationship. The following shows
the complete configuration commands and show command verification output required to complete the
task
On SW3:
SW3(config)#interface e5/0
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
SW3(config-if)#no shut
On SW5:
SW5(config)#interface e5/0
SW5(config-if)#switchport mode dynamic desirable
SW5(config-if)#no shut
To verify the configuration:
On SW3:
SW3#show interfaces trunk | include 802
Et5/0
on
802.1q
trunking
1
On SW5:
SW5#show interfaces trunk | include 802
Et5/0
desirable
n-802.1q
trunking
1
As seen in the show interfaces trunk output above, SW3’s E5/0 interface is configured as a static 802.1q
trunk whereas E5/0 on SW5 has been negotiated as an 802.1q trunk. This is evidenced by the “desirable”
and “n-802.1q” output on SW5. The “desirable” relates to the dynamic configuration and the “n-802.1q”
means it negotiated 802.1q encapsulation on the trunk link.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 9
In addition to the show interfaces trunk command the show interface switchport command can confirm
the same settings as shown below. The Administrative Mode on SW3 is set to “trunk” while on SW5 it is
set to “dynamic desirable.” This relates to the explicit configuration of the switchport. The Operational
Mode on each switch is set to “trunk” indicating that both switch ports are operating in the trunk mode:
On SW3:
SW3#show interfaces e5/0 switchport
Name: Et5/0
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
(The rest of the output is omitted for brevity)
On SW5:
SW5#show interfaces e5/0 switchport
Name: Et5/0
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
(The rest of the output is omitted for brevity)
Finally, the Administrative and Operational Trunking Encapsulation is set to “dot1q” on SW3 because it
has been statically configured as an 802.1q trunk. The Administrative Trunking Encapsulation on SW5 is
“negotiate” because it is configured to dynamically negotiate the trunk encapsulation based on the
switchport mode dynamic desirable command entered earlier. The Operational Trunking Encapsulation
for SW5 is set to “802.1q” because it has negotiated an 802.1q encapsulation with SW3.
The Administrative Mode in this context is an expression of the administrator’s intended configuration
for the trunk port. On SW3, the administrator intends the port to operate as a trunk using 802.1q
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 10
encapsulation. On SW5, the administrator intends on the port dynamically determining whether or not to
become an 802.1q trunk, ISL trunk, or a simple access port. The inclusion of this dynamic negotiation
creates the need for the Operational Mode. The Operational Mode confirms the results of the dynamic
negotiation. In case of SW3, because dynamic negotiation is not enabled, it will always operate as an
802.1q Trunk regardless. SW5, on the other hand, can operate in any of the three modes. The Operational
status here indicates that it has negotiated an 802.1q trunk.
Task 4
Configure a trunk between SW3 and SW5, using their E5/1 interfaces. You should use an
industry-standard protocol for the trunk encapsulation, based on the following policy:
SW3, E5/1
This port should be configured into permanent trunk mode, and it should negotiate to
convert the neighboring interface into a trunk.
SW5, E5/1
This port should be configured to negotiate a trunk only if it receives negotiation packets
from a neighboring port; this port should never start the negotiation process. You should
not configure switchport trunk encapsulation dot1q on this port.
Currently there are two main methods of trunking encapsulation: The Cisco Proprietary Inter-Switch
Link (ISL) and IEEE Standard 802.1Q encapsulation. Since the task explicitly states to use an industry
standard protocol, the 802.1q encapsulation method will be configured on theE5/1 link between SW3
and SW5.
First, the task requires the following:

Setting the E5/1 interface on SW3 in a permanent trunking mode.

The restriction in sub task 2 prevents the use of switchport trunk encapsulation dot1q
command on SW5’s E5/1 interface.

CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 11
The above requirements and restrictions are similar to SW3’s configuration for its E5/0 interface in
Task 3 resulting in same configuration commands on its E5/1 interface:
On SW3:
SW3(config)#interface e5/1
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
SW3(config-if)#no shut
The configuration for SW5 for its E5/1 interface in this task is however slightly different from task 3:
On SW5:
SW5(config)#interface e5/1
SW5(config-if)#switchport mode dynamic auto
SW5(config-if)#no shut
Unlike task 3, task 4 requires SW5 to convert its E5/1 interface into a trunk port provided it receives DTP
negotiation packets from SW3 over that link. As already mentioned, SW3 will send DTP packets even if
the trunk mode has been statically set for its E5/1 interface. Therefore, all SW5 has to do is react to
these DTP frames from SW3 and convert its own E5/1 interface to trunk. This feature can be activated
with dynamic auto setting on SW5’s E5/1 interface.
In the Auto mode (configured with the switchport mode dynamic auto command in interface
configuration mode), DTP on SW5’s e5/1 interface passively waits to receive a DTP frame from the
neighboring switch, SW3. Once a DTP frame is received, SW5 will respond with its own DTP frame.
Depending on the settings on the far end of the trunk link, the interface will negotiate to become a trunk
or an access port. If the far end indicates trunking mode then the port will negotiate to trunk mode. If
the far end indicates access mode, then the port will negotiate to access mode. In the case where the
interface negotiates to become a trunk port, DTP will also negotiate the trunk encapsulation, just as
seen in Task 3.
This operation is opposite of the dynamic desirable mode where the local switch port will actively send
DTP frames in an attempt to negotiate a trunk link with a potential far-end switch interface. In Auto
mode, no such frames are sent until a DTP frame has been received from a far-end switch.
Because SW3’s e5/1 interface is configured as a static 802.1q trunk, SW3 will send DTP frames to
negotiate the other end to be an 802.1q trunk as well. SW5’s E5/1 interface, upon receiving these
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 12
frames, will accept the configuration because it has been configured to operate in the dynamic auto
mode.
The following details the relevant configuration commands required on SW3 and SW5 to complete the
task:
On SW3:
SW3(config)#interface e5/1
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
SW3(config-if)#no shut
On SW5:
SW5(config)#interface e5/1
SW5(config-if)#switchport mode dynamic auto
SW5(config-if)#no shut
To verify the configuration:
On SW3:
SW3#show interfaces trunk
Port
Et5/0
Et5/1
Mode
on
on
Encapsulation
802.1q
802.1q
Status
trunking
trunking
Native vlan
1
1
(The rest of the output is omitted for brevity)
On SW5:
In the output of the following show command you should note the difference between “dynamic
desirable” and “Dynamic auto”.
SW5#show interfaces trunk
Port
Et5/0
Et5/1
Mode
desirable
auto
Encapsulation
n-802.1q
n-802.1q
Status
trunking
trunking
Native vlan
1
1
(The rest of the output is omitted for brevity)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 13
The show interfaces E5/1 switchport command output can also be used to verify the above settings.
SW3’s administrative and operation mode setting reflect the static configurations made by the
administrator. SW5’s administrative mode shows dynamic auto (as result of the switchport dynamic
auto command) and the operational mode is trunk (as a result of DTP negotiation between itself and
SW3). The administrative trunking encapsulation is negotiated with SW3 as well, resulting in dot1q
encapsulation being used on the trunk link. The 802.1q trunk link is now operational between SW3
and SW5’s E5/1 interfaces.
On SW3:
SW3#show interfaces e5/1 switchport
Name: Et5/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
(The rest of the output is omitted for brevity)
On SW5:
SW5#show interfaces e5/1 switchport
Name: Et5/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: dot1q
(The rest of the output is omitted for brevity)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 14
Task 5
Configure a trunk link between SW4 and SW5, using their E4/0 interfaces. These ports
should be configured to negotiate the neighboring interface into a dot1q trunk, but they
should not be in permanent trunk mode.
This task forbids a permanent trunk mode on SW4 and SW5’s E4/0 link. This hints towards not
configuring the switchport mode trunk command on SW4 and SW5’s E4/0 interface and instead have
the both the switches dynamically negotiate the trunk mode. In addition, the task also specifies the
802.1.q trunk encapsulation method.
When configuring automatic trunk negotiation, there are two options desirable and auto. In desirable
mode, the switch will actively send DTP frames out of the configured port in an attempt to negotiate a
trunk port. In auto mode, the switch will wait passively to receive a DTP frame from the far end before
negotiating a trunk link. The task requires the switches to be configured to negotiate the trunk but not
be in a permanent trunking mode. This hints to the desirable configuration on the interfaces.
In addition to sending DTP frames, the contents of the DTP frame is important. The task states that
the trunk link should be an 802.1q trunk but that this should be negotiated. In this case, it is not
sufficient to only input the dynamic desirable command on the interfaces. This is because both
switches support ISL trunk encapsulation as well as shown in the below:
On SW4:
SW4(config)#interface e4/0
SW4(config-if)#switchport trunk encapsulation ?
dot1q
isl
negotiate
Interface uses only 802.1q trunking encapsulation when trunking
Interface uses only ISL trunking encapsulation when trunking
Device will negotiate trunking encapsulation with peer on
interface
On SW5:
SW5(config)#interface e4/0
SW5(config-if)#switchport trunk encapsulation ?
dot1q
isl
negotiate
Interface uses only 802.1q trunking encapsulation when trunking
Interface uses only ISL trunking encapsulation when trunking
Device will negotiate trunking encapsulation with peer on
interface
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 15
By default, the trunk port operates in the negotiate mode. In this mode, if the trunk encapsulation
isn’t explicitly set to 802.1q, DTP will negotiate an ISL trunk. For this reason, to complete the task, the
switchport trunk encapsulation dot1q command needs to be entered on both sides of the trunk link.
This command constrains DTP to only negotiate an 802.1q trunk link during negotiation.
Keeping the above in mind, the task is completed by issuing the switchport trunk encapsulation dot1q
and the switchport mode dynamic desirable command on SW4 and SW5’s E4/0 interface:
On Both Switches:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk encapsulation dot1q
SWx(config-if)#switchport mode dynamic desirable
SWx(config-if)#no shut
To verify the configuration:
On SW4:
SW4#show interfaces trunk | include 802
Et4/0
desirable
802.1q
trunking
1
On SW5:
SW5#show interfaces trunk | include 802
Et4/0
Et5/0
Et5/1
desirable
desirable
auto
802.1q
n-802.1q
n-802.1q
trunking
trunking
trunking
1
1
1
The administrative mode on both switches shows dynamic desirable. This output confirms that both
switches are configured to actively send DTP frames to negotiate the trunking mode. The “802.1q”
indicates the encapsulation method has been statically set to 802.1q The static configuration of
802.1q, once again, forces DTP to use 802.1q encapsulation as its negotiated encapsulation method.
It also forces the “802.1q” to be displayed in the output of the show interfaces trunk command
instead of “n-802.1q” as shown in the output above for the Et5/0 and Et5/1 interfaces. The key here
is that the mode is set to “desirable” AND the encapsulation method is statically set to 802.1q. This
is an indication that DTP will attempt to negotiate an 802.1q trunk. The “n” only appears if the
local switch does not have a static setting for trunk encapsulation as an indication that the method
was negotiated and not statically set by the administrator.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 16
Once both switches receive each other’s DTP frames, negotiation occurs. The result of this
negotiation is seen as trunk as the operational mode. The administrative and operational trunk
encapsulation on both ends show the manually configured encapsulation method of dot1q.
On SW4:
SW4#show interfaces e4/0 switchport
Name: Et4/0
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
On SW5:
SW5#show interfaces e4/0 switchport
Name: Et4/0
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Task 6
Configure a dot1q trunk between SW4 and SW5, using their E4/1 interfaces, based on
the following policy:
SW4, E4/1
This port should be configured to actively attempt to convert the link to a trunk. This
port should not be in permanent trunk mode.
SW5, E4/1
This port should be configured to negotiate a trunk only if it receives negotiation packets
from a neighboring port; this port should never start the negotiation process or be
configured with the switchport trunk encapsulation dot1q command.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 17
This task demonstrates the trunking capabilities when both sides of the link are in dynamic trunk
mode. In this case, the SW4 side of the trunk negotiation should be configured in the desirable trunk
mode as follows:
On SW4:
SW4(config)#interface e4/1
SW4(config-if)#switchport trunk encapsulation dot1q
SW4(config-if)#switchport mode dynamic desirable
SW4(config-if)#no shut
With the above configuration, SW4 actively sends DTP frames out its E4/1 interface connected to SW5
with the intention of forming an 802.1q trunk link. The switchport trunk encapsulation dot1q
command ensures that 802.1q is theencapsulation method SW4 attempts to negotiate with SW5 on
the other side of the link.
SW5, on the other hand, should not begin negotiations for forming a trunk link nor should it have a
preference for trunk encapsulation mode. This is a clear hint towards using the dynamic auto mode of
trunk negotiation. The configuration on SW5 as seen below configures it to passively wait to receive
DTP frames from the far end switch port by configuring the dynamic auto mode.
On SW5:
SW5(config)#interface e4/1
SW5(config-if)#switchport mode dynamic auto
SW5(config-if)#no shut
Notice how this time, the switchport trunk encapsulation dot1q command is omitted in the
configuration. This omission was a direct result of the task requirements, stating that it should not be
configured with the “switchport trunk encapsulation dot1q” command.
After configuring both ends of the trunk, the show interface trunk output on SW4 and SW5 is as follows
To verify the configuration:
On SW4:
SW4#show interfaces trunk
Port
Et4/0
Mode
desirable
CCIE by Narbik Kocharians
Encapsulation
802.1q
Status
trunking
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Native vlan
1
Page 18
Et4/1
desirable
802.1q
trunking
1
Encapsulation
802.1q
n-802.1q
n-802.1q
n-802.1q
Status
trunking
trunking
trunking
trunking
Native vlan
1
1
1
1
On SW5:
SW5#show interfaces trunk
Port
Et4/0
Et4/1
Et5/0
Et5/1
Mode
desirable
auto
desirable
auto
The output above confirms that SW4’s E4/1 interface is configured in the dynamic desirable mode
using 802.1q trunk encapsulation. SW5’s E4/1 interface is configured in the dynamic auto mode. Its
trunk encapsulation shows that it has negotiated 802.1q trunking with the “n-” in front of the 802.1q
designation.
The show interfaces E4/1 switchport output below also confirms the above configuration. Since SW4
is actively sending out DTP frames to negotiate a trunk, the administrative mode shows dynamic
desirable. SW5 is configured to passively listen to DTP frames as indicated with the administrative
mode dynamic auto below. SW4 will send DTP frames to SW5 to negotiate an 802.1q trunk link. SW5
will respond and agree to the configuration. As a result, the operational mode for the E4/1 interface
on both SW4 and SW5 is shown as trunk.
On SW4:
SW4#show interfaces e4/1 switchport
Name: Et4/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
On SW5:
SW5#show interfaces e4/1 switchport
Name: Et4/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 19
Operational Trunking Encapsulation: dot1q
Since the encapsulation is manually set on SW4, the administrative trunking encapsulation is seen as
dot1q. SW5 sets the encapsulation method to 802.1q based on the DTP frames received from SW4. As
such, the administrative trunking encapsulation is seen as negotiate, while the operational trunk
encapsulation has been set to dot1q as a result of the DTP negotiation process.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 20
Task 7
Configure a dot1q trunk between SW3 and SW4, using their E6/0 interfaces; these
switches should be configured into permanent trunk mode and negotiate the neighboring
interface into a trunk.
The configuration for this task is very simple. The trunk mode should be manually set on both
switches with the switchport mode trunk command. Prior to this, however, IOS needs to be instructed
on the encapsulation method to be used for this link or else the static trunk command will be rejected
by the software. Thus, the switchport trunk encapsulation dot1q command should be entered first, to
designate the trunk encapsulation mode followed by the switchport mode trunk command to set the
permanent trunking mode as seen below:
On Both Switches:
SWx(config)#interface e6/0
SWx(config-if)#switchport trunk encapsulation dot1q
SWx(config-if)#switchport mode trunk
SWx(config-if)#no shut
The show interface trunk command output from SW3 and SW4 below verify the result of the above
configuration settings:
To verify the configuration:
On SW3:
SW3#show interfaces trunk | include 802
Port
Et5/0
Et5/1
Et6/0
Mode
on
on
on
Encapsulation
802.1q
802.1q
802.1q
Status
trunking
trunking
trunking
Native vlan
1
1
1
Status
trunking
trunking
trunking
Native vlan
1
1
1
On SW4:
SW4#show interfaces trunk | include 802
Port
Et4/0
Et4/1
Et6/0
Mode
desirable
desirable
on
CCIE by Narbik Kocharians
Encapsulation
802.1q
802.1q
802.1q
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 21
As seen above, the trunk mode and encapsulation on both switches is set to on, indicating trunk mode
is statically configured as “on”, and 802.1q. This is also reflected in the below output where both the
administrative modes and operational modes are set to trunk and 802.1q:
On SW3:
SW3#show interfaces e6/0 switchport
Name: Et6/0
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
On SW4:
SW4#show interfaces e6/0 switchport
Name: Et6/0
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
The ports have been configured as permanent trunk interfaces. As a result, they will still send DTP
messages out to “negotiate” a trunk link. The difference is the port will only operate in trunk mode
and will advertise this in the DTP messages it sends out. In this way, the port is saying that its own
operating mode is non-negotiable because of its static configuration and will force other ports
operating in dynamic modes to be in trunking mode.
Task 8
Configure a dot1q trunk between SW3 and SW4, using their E6/1 interfaces. These ports
should not use DTP to negotiate a trunk.
This task requires configuring a dot1q trunk on the E6/1 interface between SW3 and SW4 without the use
of DTP. On certain switching platforms, DTP is turned on by default even if the port is statically
configured to function as an access or trunk port
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 22
DTP can be turned off using the switchport nonegotiate command in interface configuration mode. In this
mode, the switch will disable DTP on the port, preventing the processing and sending of DTP frames.
However, issuing this command by itself results in IOS rejecting the command as seen below:
SW3(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status on
this interface: Et6/1
This is because, prior to turning off DTP, the switch needs to be told manually about the encapsulation
method and the mode in which the port should operate. On most Cisco switching platforms, the default
mode of operation is to use dynamic negotiation for trunk status as shown below:
SW3:
SW3#show interfaces e6/1 switchport
Name: Et6/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
In order for the port to function properly without DTP, Cisco IOS needs to have the static configuration
settings. To comply, first, set the encapsulation method to 802.1.q with the switchport trunk
encapsulation dot1q command. Then, set the trunk mode with the switchport mode trunk command.
Finally, DTP is turned off with the switchport nonegotiate command. The following configurations are
made on SW3 and SW4:
On Both Switches:
SWx(config)#interface e6/1
SWx(config-if)#switchport trunk encapsulation dot1q
SWx(config-if)#switchport mode trunk
SWx(config-if)#switchport nonegotiate
SWx(config-if)#no shut
Remember, the above commands are order specific. This means switchport mode trunk cannot be
entered before the switchport trunk encapsulation dot1q command. Likewise, the switchport nonegotiate
command cannot be entered before the switchport mode trunk command.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 23
The show interfaces trunk output below confirms the manual setting of an 802.1q trunk link with the on
and 802.1q keywords. This output however by itself does not reveal that DTP is disabled on the E6/1
link. To confirm DTP is not enabled the show interfaces E6/1 switchport command output can be used:
To verify the configuration:
On SW3:
SW3#show interfaces trunk
Port
Et5/0
Et5/1
Et6/0
Et6/1
Mode
on
on
on
on
Encapsulation
802.1q
802.1q
802.1q
802.1q
Status
trunking
trunking
trunking
trunking
Native vlan
1
1
1
1
Status
trunking
trunking
trunking
trunking
Native vlan
1
1
1
1
SW3#show interfaces e6/1 switchport
Name: Et6/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
On SW4:
SW4#show interfaces trunk
Port
Et4/0
Et4/1
Et6/0
Et6/1
Mode
desirable
desirable
on
on
Encapsulation
802.1q
802.1q
802.1q
802.1q
SW4#show interfaces e6/1 switchport
Name: Et6/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 24
Task 9
Configure trunking on the E4/0-1 interfaces of SW2 and SW3, the E5/0-1 interfaces
on SW2 and SW4, and the E6/0-1 interfaces of SW2 and SW5. These ports should be in
permanent trunk mode.
This task requires statically configuring the mentioned ports to trunk. For this, following the order as
described in tasks 7 and 8, first the encapsulation method is manually set to 802.1q with the switchport
trunk encapsulation dot1q command. Then the command switchport mode trunk is issued to set the ports
to permanent trunking mode. To ease with configuration, the interface range command is used to
configure multiple ports at the same time on all of the switches:
On SW2:
SW2(config)#interface range e4/0-1,e5/0-1,e6/0-1
SW2(config-if-range)#switchport trunk encapsulation dot1q
SW2(config-if-range)#switchport mode trunk
SW2(config-if-range)#no shut
On SW3:
SW3(config)#interface range e4/0-1
SW3(config-if-range)#switchport trunk encapsulation dot1q
SW3(config-if-range)#switchport mode trunk
SW3(config-if-range)#no shut
On SW4:
SW4(config)#interface range e5/0-1
SW4(config-if-range)#switchport trunk encapsulation dot1q
SW4(config-if-range)#switchport mode trunk
SW4(config-if-range)#no shut
On SW5:
SW5(config)#interface range e6/0-1
SW5(config-if-range)#switchport trunk encapsulation dot1q
SW5(config-if-range)#switchport mode trunk
SW5(config-if-range)#no shut
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 25
To verify the configuration:
On SW2:
SW2#show interfaces trunk | include 802
Et4/0
Et4/1
Et5/0
Et5/1
Et6/0
Et6/1
on
on
on
on
on
on
802.1q
802.1q
802.1q
802.1q
802.1q
802.1q
trunking
trunking
trunking
trunking
trunking
trunking
1
1
1
1
1
1
802.1q
802.1q
802.1q
802.1q
802.1q
802.1q
trunking
trunking
trunking
trunking
trunking
trunking
1
1
1
1
1
1
802.1q
802.1q
802.1q
802.1q
802.1q
802.1q
trunking
trunking
trunking
trunking
trunking
trunking
1
1
1
1
1
1
trunking
trunking
trunking
trunking
trunking
trunking
1
1
1
1
1
1
On SW3:
SW3#show interfaces trunk
Et4/0
Et4/1
Et5/0
Et5/1
Et6/0
Et6/1
on
on
on
on
on
on
On SW4:
SW4#show interfaces trunk
Et4/0
Et4/1
Et5/0
Et5/1
Et6/0
Et6/1
desirable
desirable
on
on
on
on
On SW5:
SW5#show interfaces trunk | include 802
Et4/0
desirable
802.1q
Et4/1
auto
n-802.1q
Et5/0
desirable
n-802.1q
Et5/1
auto
n-802.1q
Et6/0
on
802.1q
Et6/1
on
802.1q
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 26
Task 10
Configure the following VLANs on SW2 and ensure that they are propagated to the
other switches:
VLANs 2–10, 100, 200, 300, 400, 230, 350, 450, 240, 250, and 340
This task requires configuring the VLANs mentioned only on SW2. Configuring VLANs can be a manual
process. However, recall in Task 1, SW2 through SW5 were all configured to belong to the VTP domain
TST. All tasks up to this point configured trunk links between switches. Now that all of the switch-toswitch links are properly configured as trunk ports, they can relay and receive VTP messages.
In other words, through VTP, the VLANs configured on SW2 will be advertised and synchronized to all the
other switches in this topology. VTP performs this synchronization through the use of three message
types:
1. Summary Advertisements
2. Subset Advertisements
3. Advertisement Requests
To help demonstrate what each advertisement type does, picture the following small, switched network
below:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 27
All switches above have been configured to participate in VTP domain TST.
Without any changes happening in the network, VTP servers will periodically send out VTP summary
advertisements every 300 seconds or whenever a change is detected in the VLAN database. These
advertisements contain information about the sending switch’s VTP version, its configured domain name,
and the configuration revision number.
The VTP version can be either 1, 2, or 3. The domain name indicates to which VTP domain the advertising
switch belongs. If the domain name in the summary advertisement doesn’t match the locally configured
domain name, the switch will ignore and drop the summary advertisement message. The revision number
is an indication of how many times the VLAN database has been updated by the switch sending the
summary advertisement. This number is increased every time a change is made to the VLAN
configuration. It is also used to help neighboring switches determine if their version of the VLAN database
has the latest configuration revision.
The VTP summary advertisement also includes a field called the followers field. This field indicates how
many additional subset advertisements the switch is sending out after the summary advertisement. For
example, VLAN 100, pictured above, is added to SW1. As a reaction, Switch-1 sends the following VTP
summary advertisement message to Switch-2 and Switch-3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 28
VLAN Trunking Protocol
Version: 0x01
Code: Summary Advertisement (0x01)
Followers: 1
Management Domain Length: 3
Management Domain: TST
Configuration Revision Number: 1
Updater Identity: 0.0.0.0
Update Timestamp: 20-07-05 16:09:57
MD5 Digest: 7d5a50584977788466c5ebd8eae182b5
From the summary advertisement above, Switch-2 and Switch-3 know the following:
1.
2.
3.
4.
Switch-1 is using VTPv1 messaging
Switch-1 is in the VTP domain TST
Switch-1’s VTP database is at configuration revision 1
There is one subset advertisement following this message
After sending the summary advertisement, Switch-1 follows up with a VTP subset advertisement. Subset
advertisements are VTP messages that contain actual information about the VLANs configured on the
switch including but not limited to VLAN number, name, and type information. They are usually sent after
summary advertisements. In Switch-1’s case, its subset advertisement contains information about the
newly created VLAN 100 shown below:
VLAN Trunking Protocol
Version: 0x01
Code: Subset Advertisement (0x02)
Sequence Number: 1
Management Domain Length: 3
Management Domain: TST
Configuration Revision Number: 1
VLAN Information
VLAN Information
VLAN Information Length: 20
Status: 0x00
VLAN Type: Ethernet (0x01)
VLAN Name Length: 8
ISL VLAN ID: 0x0064
MTU Size: 1500
802.10 Index: 0x00018704
VLAN Name: VLAN0100
VLAN Information
VLAN Information
VLAN Information
VLAN Information
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 29
When the Switch-2 and Switch-3 receive the subset advertisement above, they will update their own VLAN
databases with the information contained. In this case, the switches will create VLAN 100 if they do not
already have it created in their local VLAN database. If the VLAN exists, it will have the information, such as
type, name, and MTU, updated to match what was advertised in the subset message.
The above all leads to the following sequence of events for VTP to synchronize VLAN configuration among
a group of switches:
1. VTP server sends out VTP summary advertisement with followers field set to 1 or greater
2. VTP clients receive the summary advertisement and expect subset advertisements to follow
3. VTP server sends subset advertisements accordingly.
This process works well if there is a change made on the server that requires subset advertisements to follow
the summary advertisement. There are situations where a new switch comes online with a revision number of
0 and receives a periodic summary message that has the followers field set to 0 and a higher revision number.
The followers field set to 0 means there will not be any subset advertisements following the summary
message.
In the above case, the new switch will make use of the third VTP message type, the advertisement request
message. The advertisement request message is sent by a switch to indicate that it requires VLAN
configuration information to update its local VLAN database. The following is an example of an
advertisement request message.
VLAN Trunking Protocol
Version: 0x01
Code: Advertisement Request (0x03)
Reserved: 00
Management Domain Length: 4
Management Domain: TST
Start Value: 0x0000
The advertisement request message has the simplest form with the only notable field being the VTP domain
name which is used to ensure only VTP servers participating in the same domain respond to the
advertisement request. Switches send this message out whenever they receive a summary advertisement with
a higher revision number than its own and followers field set to 0. When a VTP server receives the
advertisement request message, it will respond with a subset advertisement containing the contents of the
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 30
current version of the VLAN database. From this subset advertisement, the receiving switch can update its
own local VLAN database to be synchronized with the rest of the VTP domain.
As an example, the E0/1 interface that connects to Switch-1 on Switch-2 is shutdown. VLAN 200 is
configured on Switch-1.
On Switch-2:
Switch-2(config)#interface e0/1
Switch-2(config-if)#shut ! Interface shutdown on Switch-2
On Switch-1:
Switch-1(config)#vlan 200 ! VLAN 200 added on Switch-1
Switch-1(config-vlan)#exit
When the interface is brought back up on Switch-2, it receives a summary advertisement from
Switch-1 with a higher configuration revision number than its own and the followers field set to 0.
This value of 0 indicates that Switch-1 is not planning on sending a subset advertisement following its
summary advertisement.
Switch-2:
Switch-2#show vtp status
VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
: TST
VTP Pruning Mode
: Disabled
VTP Traps Generation
: Disabled
Device ID
: aabb.cc80.0200
Configuration last modified by 0.0.0.0 at 7-5-20 16:09:57
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
-------------VTP Operating Mode
Maximum VLANs supported locally
Number of existing VLANs
Configuration Revision
MD5 digest
: Server
: 1005
: 6
: 1 ! Revision number 1 on Switch-2
: 0x7D 0x5A 0x50 0x58 0x49 0x77 0x78 0x84
0x66 0xC5 0xEB 0xD8 0xEA 0xE1 0x82 0xB5
Switch-2(config)#interface e0/1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 31
Switch-2(config-if)#no shut ! Interface unshut on Switch-2
! Summary Advertisement with revision number 2 from Switch-1
VLAN Trunking Protocol
Version: 0x01
Code: Summary Advertisement (0x01)
Followers: 0 ! Followers field is set to 0
Management Domain Length: 3
Management Domain: TST
Configuration Revision Number: 2
Updater Identity: 0.0.0.0
Update Timestamp: 20-07-05 16:22:47
MD5 Digest: bfe9a9d0ddf6bef5d9d1633a811ebd35
This discrepancy obviously means that the VLAN database on Switch-2 isn’t updated. Since Switch-2
needs to synchronize its own VLAN database to match the rest of the VTP domain, it sends an
advertisement request to Switch-1 to get the subset advertisements it needs.
In response, Switch-1 sends a subset advertisement that carries information about its updated VLAN
database. The capture below shows the adverisment request from Switch-2 and the subset advertisement
response by Switch-1
! Advertisement request sent to Switch-1
VLAN Trunking Protocol
Version: 0x01
Code: Advertisement Request (0x03)
Reserved: 00
Management Domain Length: 3
Management Domain: TST
Start Value: 0x0000
! Subset Advertisement sent by Switch-1
VLAN Trunking Protocol
Version: 0x01
Code: Subset Advertisement (0x02)
Sequence Number: 1
Management Domain Length: 3
Management Domain: TST
Configuration Revision Number: 2
VLAN Information
VLAN Information
VLAN Information
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 32
VLAN Information Length: 20
Status: 0x00
VLAN Type: Ethernet (0x01)
VLAN Name Length: 8
ISL VLAN ID: 0x00c8
MTU Size: 1500
802.10 Index: 0x00018768
VLAN Name: VLAN0200
VLAN Information
VLAN Information
VLAN Information
VLAN Information
It is this exchange of summary advertisements, subset advertisements, and advertisement request that
allows VTP to synchronize VLAN information between switches. Summary advertisements and
advertisement requests organize the exchange of subset advertisements. Subset advertisements contain
the actual data that should be synchronized. The above example was to demonstrate how the VLAN
information entered on SW2 in the lab topology will be distributed to all of the other switches in the
domain.
VLANs are configured with the VLAN keyword. Multiple VLANs can be configured with a single command
with each VLAN or VLAN range separated by a comma. As the task requires, the following shows the
VLANs configuration on SW2.
Note : It is important to issue the exit command after configuring VLANs for the VLANs to be added to the
VLAN database:
On SW2
SW2(config)#vlan 2-10,100,200,300,400,230,350,450,240,250,340
You must “exit” for the VLANs to be propagated:
SW2(config-vlan)#exit
After configuring the above VLANs, SW2 first sends out a VTP summary advertisement frame out of all of
its trunk links. This summary advertisement frame contains all of the information in SW2’s VLAN database
that has changed. An example packet capture of the summary advertisement sent to SW5 over the E6/1
trunk link is shown below:
Frame 56: 103 bytes on wire (824 bits), 103 bytes captured (824 bits) on interface 0
Ethernet II, Src: aa:bb:cc:00:0a:06 (aa:bb:cc:00:0a:06), Dst: CDP/VTP/DTP/PAgP/UDLD
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 33
(01:00:0c:cc:cc:cc)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1
Logical-Link Control
VLAN Trunking Protocol
Version: 0x01
Code: Summary Advertisement (0x01)
Followers: 1
Management Domain Length: 3
Management Domain: TST
Configuration Revision Number: 1
Updater Identity: 0.0.0.0
Update Timestamp: 20-07-01 18:30:03
MD5 Digest: 0f71b236b776e0a7d9f6ee6a3ee312dc
As seen above, the summary advertisement carries within itself, the VTP domain name TST. When SW5
receives this summary advertisement, it compares the VTP domain name to its own. Since the advertised
domain name matches its own, SW5 then computes the MD5 digest of the message. If it results in the
same value then SW5 knows definitively that it should accept the VTP information in the VTP frame.
Below is SW5’s VTP information:
SW5#show vtp status
VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
: TST
VTP Pruning Mode
: Disabled
VTP Traps Generation
: Disabled
Device ID
: aabb.cc80.0d00
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
-------------VTP Operating Mode
Maximum VLANs supported locally
Number of existing VLANs
Configuration Revision
MD5 digest
: Client
: 1005
: 5
: 0
: 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
0x56 0x9D 0x4A 0x3E 0xA5 0x69 0x35 0xBC
NOTE: the MD5 digest is recalculated based on the contents of the VLAN database whenever a VTP
message is received. See the show vtp status output for confirmation of SW5’s MD5 calculation
The followers field in the summary advertisement lets SW5 know that a subset advertisement is following
SW2’s summary advertisement. The subset advertisement is what actually carries the VLAN information.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 34
The packet capture below shows the subset advertisement sent to SW5. Each of the VLAN information
entries below corresponds to the VLANs configured on SW2.
Frame 57: 610 bytes on wire (4880 bits), 610 bytes captured
(4880 bits) on interface 0
Ethernet II, Src: aa:bb:cc:00:0a:06 (aa:bb:cc:00:0a:06), Dst:
CDP/VTP/DTP/PAgP/UDLD (01:00:0c:cc:cc:cc)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1
Logical-Link Control
VLAN Trunking Protocol
Version: 0x01
Code: Subset Advertisement (0x02)
Sequence Number: 1
Management Domain Length: 3
Management Domain: TST
Configuration Revision Number: 1
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
VLAN Information
For a detailed look into the VLAN Information entries, the following expands one entry that carries
information for the VLAN 230:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 35
VLAN Information
VLAN Information Length: 20
Status: 0x00
VLAN Type: Ethernet (0x01)
VLAN Name Length: 8
ISL VLAN ID: 0x00e6
MTU Size: 1500
802.10 Index: 0x00018786
VLAN Name: VLAN0230
The “ISL VLAN ID” field in the above carries the VLAN ID in hexadecimal. In the above the hex code 0x00e6
translates to decimal 230 which is one of the VLANs configured on SW2.
All of the above VLAN information in subset advertisements is advertised by SW2 out of all its trunk
interfaces. All switches in the topology receive this information and populate their own VLAN databases
with the VLANs configured on SW2. This can be verified on all the switches with the show vlan brief |
include VLAN command. As an example, the following output is displayed from SW5:
To verify the configuration:
On All Switches:
SWx#show vlan brief | include VLAN
VLAN Name
2
VLAN0002
3
VLAN0003
4
VLAN0004
5
VLAN0005
6
VLAN0006
7
VLAN0007
8
VLAN0008
9
VLAN0009
10
VLAN0010
100 VLAN0100
200 VLAN0200
230 VLAN0230
240 VLAN0240
250 VLAN0250
300 VLAN0300
340 VLAN0340
CCIE by Narbik Kocharians
Status
active
active
active
active
active
active
active
active
active
active
active
active
active
active
active
active
Ports
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 36
350
400
450
VLAN0350
VLAN0400
VLAN0450
active
active
active
After adding the VLANs, SW5’s show vtp status output reveals when the configuration was last updated,
its revision number has incremented, and the MD5 digest now matches that which was advertised by
SW2:
SW5#show vtp status
VTP Version capable
VTP version running
VTP Domain Name
: 1 to 3
: 1
: TST
VTP Pruning Mode
: Disabled
VTP Traps Generation
: Disabled
Device ID
: aabb.cc80.0d00
Configuration last modified by 0.0.0.0 at 20-07-01 18:30:03
Feature VLAN:
-------------VTP Operating Mode
Maximum VLANs supported locally
Number of existing VLANs
Configuration Revision
MD5 digest
: Client
: 1005
: 24
: 1
: 0x0F 0x71 0xB2 0x36 0xB7 0x76 0xE0 0xA7
0xD9 0xF6 0xEE 0x6A 0x3E 0xE3 0x12 0xDC
Task 11
Configure the trunks based on the following policy:
Policy Item
1
2
3
4
5
6
Trunk Interface
E4/1
E5/0
E4/0
E5/0
E6/0
E6/0
CCIE by Narbik Kocharians
Between Switches
SW2  SW3
SW3  SW5
SW4  SW5
SW2  SW4
SW2  SW5
SW3  SW4
Allowed VLAN/s
ONLY 230
ONLY 350
ONLY 450
ONLY 240
ONLY 250
ONLY 340
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 37
Trunk links have a list of VLANs that are allowed to flow over them. By default, all VLANs are included in
this list. This task specifies several VLAN policies that make changes to the list of VLANs that should be
allowed over a particular trunk link. Each policy lists the trunk interface and switch pair to which the
policy applies and which VLANs are allowed or disallowed to be carried across the trunk.
The allowed VLAN list of a trunk link is configured using the switchport trunk allowed vlan {{ add | except
| remove } vlan_list | all | none } command.
Without additional parameters, the command configures the allowed VLAN list to match the specified
VLAN list exactly. This task examines this use-case for the command.
Policy item 1:
As seen below, all VLANs are allowed on the E4/1 trunk interface as expected by the default settings of
trunk links:
On SW2:
SW2#show interfaces trunk | include Vlans|Et4/1
Et4/1
Port
Et4/1
Port
Et4/1
Port
Et4/1
on
802.1q
trunking
1
Vlans allowed on trunk
1-4094
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
1-10,100,200,230,240,250,300,340,350,400,450
On SW3:
SW3#show interfaces trunk | include Vlans|Et4/1
Et4/1
Port
Et4/1
Port
Et4/1
Port
Et4/1
on
802.1q
trunking
1
Vlans allowed on trunk
1-4094
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
1-10,100,200,230,240,250,300,340,350,400,450
To configure the first policy in the task:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 38
On SW2 and SW3:
The policy for this trunk interface states that only VLAN 230 should be allowed on this trunk link. This is
achieved with the switchport trunk allowed vlan 230 command on the E4/1 interfaces on SW2 and SW3:
SWx(config)#interface e4/1
SWx(config-if)#switchport trunk allowed vlan 230
To verify the configuration:
On SW2:
As a result of the above command, the show interfaces trunk command output on SW2 and SW3 verify
230 to be the only VLAN allowed on the E4/1 interface:
SW2#show interfaces trunk | include Vlans|Et4/1
Et4/1
Port
Et4/1
Port
Et4/1
Port
Et4/1
on
802.1q
trunking
1
Vlans allowed on trunk
230
Vlans allowed and active in management domain
230
Vlans in spanning tree forwarding state and not pruned
230
Similar configurations as the above are made on the remaining trunk links stated in this
task
Policy item 2:
To configure the second policy in the task:
On SW3 and SW5:
SWx(config)#interface e5/0
SWx(config-if)#switchport trunk allowed vlan 350
To verify the configuration:
On SW3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 39
SW3#show interfaces trunk | include Vlan|Et5/0
Et5/0
Port
Et5/0
Port
Et5/0
Port
Et5/0
on
802.1q
trunking
1
Vlans allowed on trunk
350
Vlans allowed and active in management domain
350
Vlans in spanning tree forwarding state and not pruned
350
On SW5:
SW5#show interfaces trunk | include Vlans|Et5/0
Et5/0
Port
Et5/0
Port
Et5/0
Port
Et5/0
desirable
n-802.1q
trunking
1
Vlans allowed on trunk
350
Vlans allowed and active in management domain
350
Vlans in spanning tree forwarding state and not pruned
none
Policy item 3:
To configure the third policy in the task:
On SW4 and SW5:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk allowed vlan 450
To verify the configuration:
On SW4:
SW4#show interfaces trunk | include Vlan|Et4/0
Et4/0
Port
Et4/0
Port
Et4/0
Port
desirable
802.1q
trunking
1
Vlans allowed on trunk
450
Vlans allowed and active in management domain
450
Vlans in spanning tree forwarding state and not pruned
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 40
Et4/0
450
On SW5:
SW5#show interfaces trunk | include Vlan|Et4/0
Et4/0
Port
Et4/0
Port
Et4/0
Port
Et4/0
desirable
802.1q
trunking
1
Vlans allowed on trunk
450
Vlans allowed and active in management domain
450
Vlans in spanning tree forwarding state and not pruned
none
Policy item 4:
To configure the fourth policy in the task:
On SW2 and SW4:
SWx(config)#interface e5/0
SWx(config-if)#switchport trunk allowed vlan 240
To verify the configuration:
On SW2:
SW2#show interfaces trunk | include Vlans|Et5/0
Et5/0
Port
Et5/0
Port
Et5/0
Port
Et5/0
on
802.1q
trunking
1
Vlans allowed on trunk
240
Vlans allowed and active in management domain
240
Vlans in spanning tree forwarding state and not pruned
240
On SW4:
SW4#show interfaces trunk | inc Vlans|Et5/0
Et5/0
Port
Et5/0
on
802.1q
Vlans allowed on trunk
240
CCIE by Narbik Kocharians
trunking
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
1
Page 41
Port
Et5/0
Port
Et5/0
Vlans allowed and active in management domain
240
Vlans in spanning tree forwarding state and not pruned
240
Policy item 5:
To configure the fifth policy in the task:
On SW2 and SW5:
SWx(config)#interface e6/0
SWx(config-if)#switchport trunk allowed vlan 250
To verify the configuration:
On SW2:
SW2#show interfaces trunk | include Vlan|Et6/0
Et6/0
Port
Et6/0
Port
Et6/0
Port
Et6/0
on
802.1q
trunking
1
Vlans allowed on trunk
250
Vlans allowed and active in management domain
250
Vlans in spanning tree forwarding state and not pruned
250
On SW5:
SW5#show interfaces trunk | include Vlan|Et6/0
Et6/0
Port
Et6/0
Port
on
802.1q
trunking
1
Vlans allowed on trunk
250
Vlans allowed and active in management domain
Et6/0
Port
Et6/0
250
Vlans in spanning tree forwarding state and not pruned
250
Policy item 6:
To configure the sixth policy in the task:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 42
On SW3 and SW4:
Cat-x(config)#interface e6/0
Cat-x(config-if)#switchport trunk allowed vlan 340
To verify the configuration:
On SW3:
SW3#show interfaces trunk | include Vlan|Et6/0
Et6/0
Port
Et6/0
Port
Et6/0
Port
Et6/0
on
802.1q
trunking
1
Vlans allowed on trunk
340
Vlans allowed and active in management domain
340
Vlans in spanning tree forwarding state and not pruned
340
On SW4:
SW4#show interfaces trunk | include Vlan|Et6/0
Et6/0
Port
Et6/0
Port
Et6/0
Port
Et6/0
on
802.1q
trunking
1
Vlans allowed on trunk
340
Vlans allowed and active in management domain
340
Vlans in spanning tree forwarding state and not pruned
none
Task 12
Add VLANs to the allowed list of the trunks, based on the following chart:
Policy Item
1
2
3
Trunk Interface
E4/1
E5/0
E4/0
CCIE by Narbik Kocharians
Between Switches
SW2  SW3
SW3  SW5
SW4  SW5
Add to the Allowed VLAN/s
100
200
300
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 43
4
E6/0
SW2  SW5
400
Similar to Task 11, this task specifies several VLAN policies that make changes to the list of VLANs that
should be allowed over a particular trunk link. Each policy lists the trunk interface and switch pair to
which the policy applies and which VLANs are allowed or disallowed to be carried across the trunk.
The allowed VLAN list of a trunk link is configured using the switchport trunk allowed vlan {{ add | except
| remove } vlan_list | all | none } command.
When used with the add parameter, the switch will add the indicated VLANs to the current list of allowed
VLANs on the trunk link. This operation is examined in this task below.
Policy item 1:
The command switchport trunk allowed VLAN add vlan number can be used to add an additional VLAN to
the already existing allowed VLAN list.
The following is the output of the show int trunk | include Vlans|Et4/1 command. As seen, the only VLAN
allowed over the E4/1 trunk interface between SW2 and SW3 is VLAN 230:
SW2#show interfaces trunk | include Vlans|Et4/1
Et4/1
on
802.1q
trunking
1
Port
Vlans allowed on trunk
Et4/1
230
Port
Vlans allowed and active in management domain
Et4/1
230
Port
Vlans in spanning tree forwarding state and not pruned
Et4/1
230
To configure the first policy in the task:
To add VLAN 100 as an addition to the allowed VLAN list as the policy requires, the command switchport
trunk allowed VLAN add 100 is configured under the E4/1 interface on SW2 and SW3:
On SW2 and SW3:
SWx(config)#interface e4/1
SWx(config-if)#switchport trunk allowed vlan add 100
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 44
The show interfaces trunk | include Vlans|Et4/1 command outputs below, verify the above configuration
where traffic for both 100 and 230 are now allowed to be carried over the trunk link E4/1 between SW2
and SW3:
On SW2:
SW2#show interfaces trunk | include Vlans|Et4/1
Et4/1
Port
Et4/1
Port
Et4/1
Port
Et4/1
on
802.1q
trunking
1
Vlans allowed on trunk
100,230
Vlans allowed and active in management domain
100,230
Vlans in spanning tree forwarding state and not pruned
230
On SW3:
SW3#show interfaces trunk | include Vlans|Et4/1
Et4/1
Port
Et4/1
Port
Et4/1
Port
Et4/1
on
802.1q
trunking
1
Vlans allowed on trunk
100,230
Vlans allowed and active in management domain
100,230
Vlans in spanning tree forwarding state and not pruned
none
Similar configurations as above are made on the respective switches for the remaining
policies in this task below:
Policy item 2:
To configure the second policy in the task:
On SW3 and SW5:
SWx(config)#interface e5/0
SWx(config-if)#switchport trunk allowed vlan add 200
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 45
On SW3:
SW3#show interfaces trunk | include Vlan|Et5/0
Et5/0
Port
Et5/0
Port
Et5/0
Port
Et5/0
on
802.1q
trunking
1
Vlans allowed on trunk
200,350
Vlans allowed and active in management domain
200,350
Vlans in spanning tree forwarding state and not pruned
200,350
On SW5:
SW5#show interfaces trunk | include Vlan|Et5/0
Et5/0
Port
Et5/0
Port
Et5/0
Port
desirable
n-802.1q
trunking
1
Vlans allowed on trunk
200,350
Vlans allowed and active in management domain
200,350
Vlans in spanning tree forwarding state and not pruned
Et5/0
none
Policy item 3:
To configure the third policy in the task:
On SW4 and SW5:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk allowed vlan add 300
To verify the configuration:
On SW4:
SW4#show interfaces trunk | include Vlan|Et4/0
Et4/0
Port
Et4/0
Port
desirable
802.1q
trunking
1
Vlans allowed on trunk
300,450
Vlans allowed and active in management domain
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 46
Et4/0
Port
Et4/0
300,450
Vlans in spanning tree forwarding state and not pruned
300,450
On SW5:
SW5#show interfaces trunk | include Vlan|Et4/0
Et4/0
Port
Et4/0
Port
Et4/0
Port
Et4/0
desirable
802.1q
trunking
1
Vlans allowed on trunk
300,450
Vlans allowed and active in management domain
300,450
Vlans in spanning tree forwarding state and not pruned
none
Policy item 4:
To configure the fourth policy in the task:
On SW2 and SW5:
SWx(config)#interface e6/0
SWx(config-if)#switchport trunk allowed vlan add 400
To verify the configuration:
On SW2:
SW2#show interfaces trunk | include Vlan|Et6/0
Et6/0
Port
Et6/0
Port
Et6/0
Port
Et6/0
on
802.1q
trunking
1
Vlans allowed on trunk
250,400
Vlans allowed and active in management domain
250,400
Vlans in spanning tree forwarding state and not pruned
250,4000
On SW5:
SW5#show interfaces trunk | include Vlan|Et6/0
Et6/0
on
CCIE by Narbik Kocharians
802.1q
trunking
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
1
Page 47
Port
Et6/0
Port
Et6/0
Port
Et6/0
Vlans allowed on trunk
250,400
Vlans allowed and active in management domain
250,400
Vlans in spanning tree forwarding state and not pruned
250,400
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 48
Task 13
Remove VLANs from the allowed list of trunks, based on the following chart:
Policy Item
1
2
Trunk Interface
E5/1
E5/1
Between Switches
SW2  SW4
SW3  SW5
Allowed VLAN/s
Remove 1, 4 – 10 ONLY
Remove 2, 4 – 10 ONLY
This task, too, specifies several VLAN policies that make changes to the list of VLANs that should be
allowed over a particular trunk link. Each policy lists the trunk interface and switch pair to which the
policy applies and which VLANs are allowed or disallowed to be carried across the trunk.
The allowed VLAN list of a trunk link is configured using the switchport trunk allowed vlan {{ add |
except | remove } vlan_list | all | none } command.
When used with the remove parameter, the switch will remove only the indicated VLANs from the
current list of allowed VLANs on the trunk link. This operation is examined in this task below.
Policy item 1:
The show interfaces trunk | include Vlan|Et5/1 output from SW2 reveals that all VLANs are currently
allowed to traverse the E5/1 trunk link between SW2 and SW4:
SW2#show interfaces trunk | include Vlan|Et5/1
Et5/1
Port
Et5/1
Port
Et5/1
Port
Et5/1
on
802.1q
trunking
1
Vlans allowed on trunk
1-4094
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
1-10,100,200,230,240,250,300,340,350,400,450
To configure the first item in the task:
As seen above, all VLANs are allowed to traverse the E5/1 trunk link. Policy 1 of this task requires
prohibiting traffic belonging to VLAN 1 and VLANs 4 through 10 from traversing this link. This is
accomplished using the switchport trunk allowed vlan remove 1, 4-10 command on the E5/1 interface
on SW2 and SW4 as shown below.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 49
On SW2 and SW4:
SWx(config)#interface e5/1
SWx(config-if)#switchport trunk allowed vlan remove 1,4-10
To verify the configuration:
On SW2:
SW2#show interfaces trunk | include Vlan|Et5/1
Et5/1
Port
Et5/1
Port
Et5/1
Port
Et5/1
on
802.1q
trunking
1
Vlans allowed on trunk
2-3,11-4094
Vlans allowed and active in management domain
2-3,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
2-3,100,200,230,240,250,300,340,350,400,450
On SW4:
SW4#show interfaces trunk | include Vlan |Et5/1
Et5/1
Port
Et5/1
Port
Et5/1
Port
Et5/1
on
802.1q
trunking
1
Vlans allowed on trunk
2-3,11-4094
Vlans allowed and active in management domain
2-3,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
2-3,100,200,230,250,300,340,350,400,450
Policy item 2:
To configure the second policy in the task:
On SW3 and SW5:
SWx(config)#interface e5/1
SWx(config-if)#switchport trunk allowed vlan remove 2,4-10
To verify the configuration:
On SW3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 50
SW3#show interfaces trunk | include Vlan|Et5/1
Et5/1
Port
Et5/1
Port
Et5/1
Port
Et5/1
on
802.1q
trunking
1
Vlans allowed on trunk
1,3,11-4094
Vlans allowed and active in management domain
1,3,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
1,3,100,200,230,240,250,300,340,350,400,450
On SW5:
SW5#show interface trunk | include Vlan|Et5/1
Et5/1
Port
Et5/1
Port
Et5/1
Port
Et5/1
auto
n-802.1q
trunking
1
Vlans allowed on trunk
1,3,11-4094
Vlans allowed and active in management domain
1,3,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
none
Task 14
Configure SW2, SW3, and SW5, based on the following chart:
Policy Item
1
2
Trunk Interface
E4/0
E6/1
Between Switches
SW2  SW3
SW2  SW5
Allowed VLAN/s
None
None
This task continues the theme, specifying several VLAN policies that make changes to the list of VLANs
that should be allowed over a particular trunk link. Each policy lists the trunk interface and switch pair to
which the policy applies and which VLANs are allowed or disallowed to be carried across the trunk.
The allowed VLAN list of a trunk link is configured using the switchport trunk allowed vlan {{ add | except
| remove } vlan_list | all | none } command.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 51
When using the base command with no additional parameters and none as the VLAN list, the switch will
remove ALL VLANs from the allowed VLAN list on the trunk link. The following task demonstrates this
function.
Policy item #1:
As seen in the show interfaces trunk | include Vlan|Et4/0 command output from SW2 below, all VLANs
are currently allowed on the E4/0 trunk link between SW2 and SW3.
SW2#show interfaces trunk | include Vlan |Et4/0
Et4/0
Port
Et4/0
Port
Et4/0
Port
Et4/0
on
802.1q
trunking
1
Vlans allowed on trunk
1-4094
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
1-10,100,200,230,240,250,300,340,350,400,450
To configure the first policy in the task:
Policy 1 states that no VLANs should be allowed on this trunk link. This can be achieved with the
switchport trunk allowed vlan none command on the E4/0 interfaces on SW2 and SW3:
On SW2 and SW3:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk allowed vlan none
On SW2:
SW2#show interfaces trunk | include Vlan |Et4/0
Et4/0
Port
Et4/0
Port
Et4/0
Port
Et4/0
on
802.1q
trunking
1
Vlans allowed on trunk
none
Vlans allowed and active in management domain
none
Vlans in spanning tree forwarding state and not pruned
none
On SW3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 52
SW3#show interfaces trunk | include Vlan |Et4/0
Et4/0
Port
Et4/0
Port
Et4/0
Port
Et4/0
on
802.1q
trunking
1
Vlans allowed on trunk
none
Vlans allowed and active in management domain
none
Vlans in spanning tree forwarding state and not pruned
none
Policy item #2:
To configure the second policy in the task:
A similar policy as above is configured on the trunk link E6/1 between SW2 and SW5 to prevent any VLANs
from traversing this link. The show interfaces trunk | include Vlan|Et6/1 command output on both
switches confirms the same:
On SW2 and SW5:
SWx(config)#interface e6/1
SWx(config-if)#switchport trunk allowed vlan none
To verify the configuration:
On SW2:
SW2#show interfaces trunk | include Vlan |Et6/1
Et6/1
Port
Et6/1
Port
Et6/1
Port
Et6/1
on
802.1q
trunking
1
Vlans allowed on trunk
none
Vlans allowed and active in management domain
none
Vlans in spanning tree forwarding state and not pruned
none
On SW5:
SW5#show interfaces trunk | include Vlan |Et6/1
Port
Vlans allowed on trunk
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 53
Et6/1
none
Port
Et6/1
Vlans allowed and active in management domain
none
Port
Et6/1
Vlans in spanning tree forwarding state and not pruned
none
Task 15
Configure SW2, SW4, and SW5, based on the following chart:
Policy Item
1
2
Trunk Interface
E4/1
E5/1
Between Switches
SW4  SW5
SW2  SW4
Allowed VLAN/s
All except 450
All except 240
This task specifies additional VLAN policies that make changes to the list of VLANs that should be
allowed over a particular trunk link. Each policy lists the trunk interface and switch pair to which the
policy applies and which VLANs are allowed or disallowed to be carried across the trunk.
The allowed VLAN list of a trunk link is configured using the switchport trunk allowed vlan {{ add |
except | remove } vlan_list | all | none } command.
When used with the except parameter, the switch will allow all VLANs except for the VLANs included in
the VLAN list. This operation is examined in this task below.
Policy item #1:
As seen below, currently all VLANs are allowed on the E4/1 trunk link between SW4 and SW5:
SW4#show interfaces trunk | include Vlan |Et4/1
Et4/1
Port
Et4/1
Port
Et4/1
Port
Et4/1
desirable
802.1q
trunking
1
Vlans allowed on trunk
1-4094
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400,450
Vlans in spanning tree forwarding state and not pruned
1-10,100,200,230,240,250,300,340,350,400,450
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 54
To configure the first policy in the task:
Policy 1 in this task requires that the E4/1 trunk between SW4 and SW5 carry traffic for all VLANs except
VLAN 450. This can be done with the switchport trunk allowed vlan except 450 command on the E4/1
interfaces on SW4 and SW5 as seen below:
The following command allows all VLANs except 450:
On SW4 and SW5:
SWx(config)#interface e4/1
SWx(config-if)#switchport trunk allowed vlan except 450
To verify the configuration:
On SW4:
SW4#show interfaces trunk | include Vlan |Et4/1
Et4/1
desirable
802.1q
trunking
1
Port
Et4/1
Port
Et4/1
Port
Et4/1
Vlans allowed on trunk
1-449,451-4094
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400
Vlans in spanning tree forwarding state and not pruned
1-10,100,200,230,240,250,300,340,350,400
On SW5:
SW5#show interfaces trunk | include Vlan |Et4/1
Et4/1
Port
Et4/1
auto
n-802.1q
Vlans allowed on trunk
1-449,451-4094
Port
Et4/1
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400
Port
Et4/1
Vlans in spanning tree forwarding state and not pruned
2-10,200,240,340,350
CCIE by Narbik Kocharians
trunking
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
1
Page 55
Policy item #2:
To configure the second policy in the task:
Similar configurations as the above are made to allow all VLANs except VLAN 240 on the E5/1 trunk link
between SW2 and SW4. The show int trunk | include Vlan|Et5/1 command output verifies the result of
the configuration:
On SW2 and SW4:
Cat-x(config)#interface e5/1
Cat-x(config-if)#switchport trunk allowed vlan except 240
To verify the configuration:
On SW2:
SW2#show interfaces trunk | include Vlan |Et5/1
Et5/1
Port
Et5/1
on
802.1q
Vlans allowed on trunk
1-239,241-4094
trunking
1
Port
Et5/1
Vlans allowed and active in management domain
1-10,100,200,230,250,300,340,350,400,450
Port
Et5/1
Vlans in spanning tree forwarding state and not pruned
2-3,100,200,230,250,300,340,350,400,450
On SW4:
SW4#show interfaces trunk | include Vlan |Et5/1
Et5/1
Port
Et5/1
on
802.1q
Vlans allowed on trunk
1-239,241-4094
Port
Et5/1
Vlans allowed and active in management domain
1-10,100,200,230,250,300,340,350,400,450
Port
Vlans in spanning tree forwarding state and not pruned
CCIE by Narbik Kocharians
trunking
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
1
Page 56
Et5/1
1-10,100,200,230,250,300,340,350,400,450
Task 16
Configure SW3 and SW4, based on the following chart. You may override some of the
previous tasks to accomplish this task.
Policy Item
1
2
Trunk Interface
E6/0
E6/1
Between Switches
SW3  SW4
SW3  SW4
Allowed VLAN/s
All
All
This task is the final specification of VLAN policies that make changes to the list of VLANs that should be
allowed over a particular trunk link. Each policy lists the trunk interface and switch pair to which the policy
applies and which VLANs are allowed or disallowed to be carried across the trunk.
The allowed VLAN list of a trunk link is configured using the switchport trunk allowed vlan {{ add | except |
remove } vlan_list | all | none } command.
When used with no additional parameters and all as the VLAN list, the switch will allow all VLANs across the
trunk link. This operation is examined in this task below.
Policy item #1:
To configure the first policy in the task:
This task requires permitting ALL Vlans on the E6/0 trunk link between SW3 and SW4. The show interfaces
trunk output below shows the only VLAN allowed on this trunk link is VLAN 340.
SW3#show interfaces trunk | include Vlan |Et6/0
Et6/0
Port
Et6/0
Port
Et6/0
Port
Et6/0
on
802.1q
trunking
1
Vlans allowed on trunk
340
Vlans allowed and active in management domain
340
Vlans in spanning tree forwarding state and not pruned
340
On SW3 and SW4:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 57
SWx(config)#interface e6/0
SWx(config-if)#switchport trunk allowed vlan all
To verify the configuration:
On SW3:
SW3#show interfaces trunk | include Vlan |Et6/0
Et6/0
Port
Et6/0
on
802.1q
Vlans allowed on trunk
1-4094
trunking
1
Port
Et6/0
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400,450
Port
Et6/0
Vlans in spanning tree forwarding state and not pruned
1-10,100,200,230,240,250,300,340,350,400,450
On SW4:
SW4#show interfaces trunk | include Vlan |Et6/0
Et6/0
Port
Et6/0
on
802.1q
Vlans allowed on trunk
1-4094
trunking
1
Port
Et6/0
Vlans allowed and active in management domain
1-10,100,200,230,240,250,300,340,350,400,450
Port
Et6/0
Vlans in spanning tree forwarding state and not pruned
1-10,200,240,250,300,340,350,400,450
Task 17
Erase the config.text and vlan.dat files on SW1-5 and reload them before proceeding to
the next task.
VLAN information on Cisco switches is stored in a separate file in the switch’s flash storage known as
the VLAN database. This means wiping the configuration of the device by removing the startup
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 58
configuration file, is not enough to remove the VLAN configurations themselves. In order to wipe VLAN
configurations from a switch, the VLAN database needs to be deleted from flash storage with the delete
command. The file typically exists as flash:vlan.dat. The startup configuration file is then erased with the
erase startup-config command and the switch is then rebooted.
Note: On virtual platforms such as EVE-ng, the VLAN.dat file can be found under the unix directory.
To follow the task and the VLAN.dat file, issue the following commands on SW2 through SW5 and then
reload all the devices for the changes to effect:
On the first Switch:
Switch#delete vlan.dat-00009
Delete filename [vlan.dat-00009]?
Delete unix:/vlan.dat-00009? [confirm]
Switch#write erase
Erasing the nvram filesystem will remove all configuration files!
Continue? [confirm]  Press Enter
Switch#reload
On SW2:
SW2#delete vlan.dat-00160
Delete filename [vlan.dat-00160]?  The name may be different in your IOS
Delete unix:/vlan.dat-00160? [confirm]
SW2#write erase
Erasing the nvram filesystem will remove all configuration files!
Continue? [confirm]  Press Enter
SW2#reload
On SW3:
SW2# delete vlan.dat-00176
Delete filename [vlan.dat-00176]?  The name may be different in your IOS
Delete unix:/vlan.dat-00176? [confirm]
SW2#write erase
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 59
Erasing the nvram filesystem will remove all configuration files!
Continue? [confirm]  Press Enter
SW2#reload
On SW4:
SW2#delete vlan.dat-00192
Delete filename [vlan.dat-00192]?  The name may be different in your IOS
Delete unix:/vlan.dat-00192? [confirm]
SW2#write erase
Erasing the nvram filesystem will remove all configuration files!
Continue? [confirm]  Press Enter
SW2#reload
On SW5:
SW2#delete vlan.dat-00208
Delete filename [vlan.dat-00208]?  The name may be different in your IOS
Delete unix:/vlan.dat-00208? [confirm]
SW2#write erase
Erasing the nvram filesystem will remove all configuration files!
Continue? [confirm]  Press Enter
SW2#reload
Task 18
Configure SW2 and SW3 based on the following policies:




Configure the hostnames of Switch 2 and Switch 3 to be SW2 and SW3,
Shut down all the ports on SW2 and SW3.
Configure a dot1q trunk between SW2 and SW3 using port E4/0.
Ensure that both switches belong to the VTP domain TST.
The policies above represent a good base configuration for the two switches and
combine all of the tasks learned previously into one test. The interface range command
is used extensively to make quick configurations to ports that share the same
configuration state.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 60
The ports are all shut down initially. Then, the E4/0 interface is configured as a static
802.1q trunking port on each switch. Finally, the VTP domain name is set to “TST”.
On switch 2:
Switch(config)#hostname SW2
On switch 3:
Switch(config)#hostname SW3
On both switches:
SWx(config)#interface range e0/1-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/03,e6/0-3
SWx(config-if-range)#shut
On SW2 and SW3:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk encapsulation dot1q
SWx(config-if)#switchport mode trunk
SWx(config-if)#no shut
SWx(config)#vtp domain TST
Changing VTP domain name from NULL to TST
To verify the configuration:
On SW3:
SW3#show vtp status | include Domain
VTP Domain Name
: TST
Task 19
Configure VLAN 100 on SW2 and assign its E0/1 interface to this VLAN.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 61
This task requires configuring the E0/1 interface on SW2 as an access port that belongs to VLAN 100.
VLAN 100 currently does not exist on SW2. There are two ways to achieve this.
As seen earlier, one of the ways to create a VLAN on a switch with the vlan vlan number command.
Alternatively, when configuring an access port for a particular VLAN with the switchport access vlan
vlan-number command, IOS automatically creates the VLAN if it doesn’t already exist. This can be seen
below where SW2’s E0/1 is first statically set to function as an access port with the switchport mode
access command. The port is then assigned the VLAN 100 with the switchport access vlan 100
command:
On SW2:
SW2(config)#interface e0/1
SW2(config-if)#switchport mode access
SW2(config-if)#switchport access vlan 100
% Access VLAN does not exist. Creating vlan 100
SW2(config-if)#no shut
Notice the message “% Access VLAN does not exist. Creating vlan 100”. This is a confirmation that IOS
recognized the indicated VLAN (100 in this case) was not already defined in the switch and automatically
added it to the configuration.
The show vlan brief | include VLAN command output confirms the VLAN 100 creation along with the
port assignment:
To verify the configuration:
On SW2:
SW2#show vlan brief | include VLAN
VLAN Name
100 VLAN0100
Status
active
Ports
Et0/1
Status
active
Ports
On SW3:
SW3#show vlan brief | include VLAN
VLAN Name
100 VLAN0100
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 62
VTP Pruning
In Task 10, it was explained that VTP is a protocol that can be used to synchronize the
VLAN databases between switches that participate in the same VTP domain. VTP uses three
message types to achieve this synchronization: summary advertisement, advertisement
request, and subset advertisements. This synchronization process makes it such
that an administrator only needs to configure VLANs on a single VTP server switch and
have those configurations propagated for synchronization to all remaining switches in the
VTP domain.
VTP can be used for more than simple VLAN database synchronization. It can be used
to reduce unnecessary broadcast flooded traffic originating in a specific VLAN from
entering sections of the network that do not require that VLAN traffic. For example, the
sample topology from Task 10 is examined:
In this topology, the interfaces connecting Switch-1 to Switch-2 and Switch-3 are configured
as trunk links. All three switches belong to the same VTP domain, TST.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 63
Previously, VLAN 100 was created on Switch-1. Switch-1 propagated information about
this VLAN to Switch-2 and Switch-3 using VTP. Looking at the diagram, notice only
Switch-1 and Switch-3 have interfaces connected to hosts in VLAN 100. Switch-2 does
not have any interfaces connected to VLAN 100. Since Switch-2 has no interfaces in
VLAN 100, there is no need for it to receive broadcast traffic originating from hosts in
VLAN 100 connected to other switches in the network. Recall, ARP requests are
broadcasted to all devices in the same VLAN. They are generated by end hosts to resolve
the MAC address of a target device.
When PC-1 needs to reach PC-3 in the topology, it starts by sending a broadcast ARP
frame to learn PC-3’s MAC address. The following packet capture shows that the ARP
frame was broadcasted to both Switch-2 and Switch-3:
On Switch-3:
Frame 4990: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
Ethernet II, Src: aa:bb:cc:00:04:20 (aa:bb:cc:00:04:20), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 100
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: aa:bb:cc:00:04:20 (aa:bb:cc:00:04:20)
Sender IP address: 100.1.1.1
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 100.1.1.2
On Switch-2
Frame 4134: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
Ethernet II, Src: aa:bb:cc:00:04:20 (aa:bb:cc:00:04:20), Dst: aa:bb:cc:00:05:10
(aa:bb:cc:00:05:10)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 100
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: aa:bb:cc:00:04:20 (aa:bb:cc:00:04:20)
Sender IP address: 100.1.1.1
Target MAC address: aa:bb:cc:00:05:10 (aa:bb:cc:00:05:10)
Target IP address: 100.1.1.2
Switch-2 has received the broadcast traffic even though it will ultimately drop it because it
does not have any hosts in that VLAN. The VLAN 100 broadcast in this case was
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 64
unnecessarily broadcasted to Switch-2. This unnecessary broadcast was because Switch-1
has included VLAN 100 in its allowed VLAN list for the trunk link connected to Switch-2 as
shown below:
Switch-1#show interfaces trunk
Port
Et0/0
Et0/1
Mode
on
on
Encapsulation
802.1q
802.1q
Status
trunking
trunking
Native vlan
1
1
Port
Et0/0
Et0/1
Vlans allowed on trunk
1-4094
1-4094
Port
Et0/0
Et0/1
Vlans allowed and active in management domain
1,100,200
1,100,200
Port
Et0/0
Et0/1
Vlans in spanning tree forwarding state and not pruned
1,100
1,100 ! VLAN 100 is allowed on the trunk link to Switch-2
This inclusion extends VLAN 100’s broadcast domain to Switch-2. One way to stop the
unnecessary broadcast of VLAN 100 traffic to Switch-2 is to manually remove VLAN
100 from the Switch-1/Switch-2 trunk link by using the switchport trunk allowed-vlan
remove 100 command in interface configuration mode. This process, called manual
pruning, is demonstrated extensively in previous tasks.
The problem with manual pruning is that if a host were connected to Switch-2 in VLAN
100, that VLAN would need to be manually added to the allowed VLAN list on the
Switch-1/Switch-2 trunk link again. Multiply this process by hundreds of VLANs and
potentially hundreds of clients moving around in the network, and it is clear that this
manual pruning process can cause high administrative overhead.
This is where VTP pruning comes into play. VTP pruning is a feature of VTP that allows
dynamic pruning of VLANs from trunk links where the VLAN traffic is not needed. The
process utilizes a fourth VTP message type, called the VTP membership advertisement,
or VMA. These are basically VTP Join/Prune messages.
The basic process for VTP pruning is that a switch sends a VMA for all VLANs for which
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 65
it is interested in receiving traffic. The switch makes this determination based on whether
or not it contains any interfaces that are currently associated with a VLAN that exists in
the local switch’s VLAN database.
Once again, referring back to the sample topology shown earlier, when VTP pruning is
enabled on all the switches, they exchange VMAs with each other. Because Switch-3 is
interested in receiving traffic for VLAN 100, its VMA includes VLAN 1 and VLAN 100,
as shown in the following capture.
Note : VLAN 1 is pruning ineligible, which means this VLAN will always be included in
the advertised active VLAN field and cannot be removed.
From Switch-3:
VLAN Trunking Protocol
Version: 0x01
Code: Join/Prune Message (0x04)
Reserved: 00
Management Domain Length: 3
Management Domain: TST
First VLAN ID: 0
Last VLAN ID: 1007
Advertised active (i.e. not pruned) VLANs
VLAN: 1
VLAN: 100
The Advertised active (i.e. not pruned) VLANs field indicates the VLANs for which
Switch-3 is interested in receiving traffic. Any VLAN that is not assigned to an interface
on Switch-3 is omitted from this list. For example, the VMA sent from Switch-2 to
Switch-1 includes only VLAN 1. This is because Switch-2 does not have any interfaces
assigned to VLAN 100, and thus it has no need for VLAN 100 traffic. Any traffic sent
by Switch-1 to Switch-2 in VLAN 100 would inevitably be a futile effort since Switch-2
would end up dropping the traffic anyway.
From Switch-2:
VLAN Trunking Protocol
Version: 0x01
Code: Join/Prune Message (0x04)
Reserved: 00
Management Domain Length: 3
Management Domain: TST
First VLAN ID: 0
Last VLAN ID: 1007
Advertised active (i.e. not pruned) VLANs
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 66
VLAN: 1
The following shows the state of the show interface trunk output on Switch-1. As a
result of the VMA message exchanges, Switch-1 will now send traffic for VLAN 100 out
its trunk link E0/0 to Switch-3 only.
Switch-1#show interfaces trunk
Port
Mode
Native vlan
Et0/0
on
Et0/1
on
Encapsulation
Status
802.1q
802.1q
trunking
trunking
1
1
Port
Et0/0
Et0/1
Vlans allowed on trunk
1-4094
1-4094
Port
Et0/0
Et0/1
Vlans allowed and active in management domain
1,100,200
1,100,200
Port
pruned
Et0/0
Et0/1
Vlans in spanning tree forwarding state and not
1,100 ! VLAN 1 and 100 allowed to Switch-2
1 ! Only VLAN 1 allowed to Switch-2
VTP pruning is disabled by default and can be enabled by using the vtp pruning command
in global configuration mode. VTP keeps a list of VLANs that are allowed to be
dynamically pruned; it is called the pruning-eligible list or the pruning VLANs enabled
list, depending on the show command being used. This list can be seen using the show
interface switchport command, as shown here:
Switch-1#show interfaces e0/0 switchport | include Pruning
Pruning VLANs Enabled: 2-1001
The pruning-eligible list can be modified much like the allowed VLAN list of a trunk link
with the switchport trunk pruning vlan command and the following additional parameters:
Switch-1(config-if)#switchport trunk pruning vlan ?
WORD
VLAN IDs of the allowed VLANs when this port is in
trunking mode
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 67
add
except
none
remove
add VLANs to the current list
all VLANs except the following
no VLANs
remove VLANs from the current list
The result of this command can be seen with the sample topology shown earlier.
Before any configuration changes are made, the show interface e0/1 pruning command
output on Switch-1 reveals that it is pruning VLAN 100 on the E0/1 trunk link connected
to Switch-2. This is a result of the missing VLAN 100 in the VMA sent by Switch-2, as
shown here:
Switch-1#show interface e0/1 pruning
Port
neighbor
Et0/1
Vlans pruned for lack of request by
100
Port
Et0/1
Vlan traffic requested of neighbor
1,100
Next, VLAN 200 is configured on Switch-2. The pruning-eligible list on Switch-2 is then
modified to include only VLAN 200 with the switchport trunk pruning vlan 200 command:
Switch-2(config-if)#vlan 200
Switch-2(config-vlan)#exit
Switch-2(config)#int e0/1
Switch-2(config-if)#switchport trunk pruning vlan 200
Notice how the pruning-eligible list on Switch-2 shows only VLAN 200:
Switch-2#show interfaces e0/1 switchport | include Pruning
Pruning VLANs Enabled: 200
The result of this configuration is that all other VLANs are now considered to be pruning
ineligible. As a result, the VMA sent by Switch-2 to Switch-1 will include VLAN
100, thus preventing Switch-1 from pruning this VLAN off the trunk link connected to
Switch-2. You can see this in the following packet capture, where VLAN 100 is included
in the Advertised active (i.e. not pruned) VLANs field:
VLAN Trunking Protocol
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 68
Version: 0x01
Code: Join/Prune Message (0x04)
Reserved: 00
Management Domain Length: 3
Management Domain: TST
First VLAN ID: 0
Last VLAN ID: 1007
Advertised active (i.e. not pruned) VLANs
VLAN: 1
VLAN: 100
Task 20 through 27 below pertain to VTP pruning for the lab topology.
Task 20
Configure the switches such that they restrict flooded traffic to those trunk links the
traffic must use to access the appropriate network device(s).
This task gives a good representation of a vague question. At the onset it can be difficult to figure out what
exactly the task is asking. Understanding the results of prior configurations provides the proper context for
this task.
In Task 19, VLAN 100 on SW2 and SW3 was configured. Of the two switches, only SW2 actually has an access
port in VLAN 100, evidenced by the show vlan brief | include VLAN command output below.
On SW2:
SW2#show vlan brief | include VLAN
VLAN Name
100 VLAN0100
Status
active
Ports
Et0/1
Status
active
Ports
On SW3:
SW3#show vlan brief | include VLAN
VLAN Name
100 VLAN0100
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 69
Notice there are no ports indicated under the ports field on SW3. This simply indicates that SW3 does not
have any ports configured for VLAN 100. With default settings on the E4/0 trunk port, SW3 will still receive all
broadcast traffic sent to VLAN 100. With no ports configured for VLAN 100 on SW3, it is unnecessary for SW2
to send any traffic for VLAN 100 across the E4/0 trunk link to SW3 because it will ultimately be dropped.
The task’s goal is to clean up this interaction by preventing unnecessary flooded traffic to SW3 for VLANs
which it does not need. To accomplish this task, the VTP pruning feature is enabled.
The show vtp status | include Prunning outtput below, shows VTP pruning is by default turned off on both
switches:
On SW2:
SW2#show vtp status | include Prunning
VTP Pruning Mode
: Disabled
On SW3:
SW3#show vtp status | include Prunning
VTP Pruning Mode
: Disabled
To enable VTP pruning, the vtp pruning command is issued in global configuration mode on SW2. Once
enabled, SW2 will advertise this setting to the entire VTP domain, including SW3. The output of the command
show vtp status | include Prunning after configuration verifies this:
On SW2:
SW2#vtp pruning
Pruning switched on
To verify the configuration:
SW2#show vtp status | include Prunning
VTP Pruning Mode
: Enabled
On SW3:
SW3#show vtp status | include Prunning
VTP Pruning Mode
: Enabled
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 70
Once VTP pruning has been enabled, all of the switches in the VTP domain begin sending VMA messages to
their neighboring switches to indicate the VLANs from which they would like to receive traffic. The results of
this interaction are shown on SW3 using the show interface e4/0 pruning command:
SW3#show interfaces e4/0 pruning
! Section 1
Port
Et4/0
Vlans pruned for lack of request by neighbor
none
! Section 2
Port
Et4/0
Vlan traffic requested of neighbor
1
The output above is broken down into two sections:
The first section of the show interface pruning output lists the VLANs the local switch has pruned off the
trunk link. In the output above, SW3 is not pruning any VLANs from the E4/0 trunk link connected to SW2.
This is indicated by the none keyword and is the result of SW3 receiving VMAs including all configured VLANs
on the trunk link (in this case VLANs 1 and 100).
The second section of the show interface pruning output lists the VLANs for which the local switch has sent
VMAs. Because SW3 does not have any active ports configured for VLAN 100, it does not include the VLAN in
the VMA it sends to SW2. The only VLAN included in the VMA will be VLAN 1, and this is the reason the output
above shows 1 under the VLAN traffic requested of neighbor section.
SW2’s show interface E4/0 pruning output shows the other side of the pruning process. The first section
shows the VLANs SW2 will prune off the trunk link to SW3, VLAN 100 in this case. SW2 prunes this because it
has NOT received a VMA for VLAN 100 from SW3. As a result, SW2 will not send any VLAN 100 traffic out the
E4/0 link to SW3. The second section reveals the VLANs for which SW2 expects to receive traffic from SW3,
VLAN 1 and VLAN 100 as seen below. These are the VLANs for which SW2 has sent VMAs The complete output
is shown below:
SW2#show interfaces e4/0 pruning
! Section 1
Port
Vlans pruned for lack of request by neighbor
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 71
Et4/0
! Section 2
100
Port
Et4/0
Vlan traffic requested of neighbor
1,100
Task 21
Configure VLANs 200, 300, 400, 500, and 600 on SW2 and ensure that these VLANs are
propagated to SW3.
This task requires configuring VLANs 200, 300, 400, 500 and 600 on SW2. This is done with the vlan vlannumber command as seen below. Once again, it is important to issue the exit command after the vlan
configuring to allow the VLANs to be added to the database:
On SW2:
SW2(config)#vlan 200,300,400,500,600
SW2(config-vlan)#exit
NOTE: In the above configuration if “exit” is not entered, the VLANs will not be propagated.
The show vlan brief | include VLAN command output from SW3 verifies that the above VLANs have
been propagated via VTP to SW3:
On SW3:
SW3#show vlan brief | include VLAN
VLAN Name
100 VLAN0100
200 VLAN0200
300 VLAN0300
400 VLAN0400
500 VLAN0500
600 VLAN0600
Status
active
active
active
active
active
active
Ports
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 72
Since SW3 does not have any active ports configured for any of the above VLANs, it does not include
these VLANs in its VMAs to SW2. The result is SW2 prunes off these VLANs from the E4/0 trunk link
connected to SW3. This can be seen in the first section of the show interface pruning command output
from SW2 below:
On SW2:
SW2#show interfaces pruning
! Section 1
Port
Et4/0
Vlans pruned for lack of request by neighbor
100,200,300,400,500,600
! Section 2
Port
Et4/0
Vlan traffic requested of neighbor
1,100
In addition, since SW2 has active ports in VLAN 100 and VLAN 1 cannot be pruned, these VLANs are
included in its VMAs to SW3. This is reflected in the second section of the output above. The result of
this can also be seen in the highlighted output below where SW3 prunes off VLANs 200, 300, 400, 500,
and600 since it does not receive any VMAs for these VLANs from SW2:
On SW3:
SW3#show interfaces pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
200,300,400,500,600
Port
Et4/0
Vlan traffic requested of neighbor
1
Task 22
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 73
Configure the E3/3 interface of SW3 in VLAN 100.
This task requires assigning the E3/3 interface on SW3 to VLAN 100. The purpose of this task is to
demonstrate that once SW3 assigns VLAN 100 to the E3/3 interface, it will include VLAN 100 in the VMA
message sent to SW2. This will cause SW2 to unprune VLAN 100 from the E4/0 trunk link and flood any
traffic for VLAN 100 over it.
The following first configures the E3/3 interface as an access port with the switchport mode access
command. The port is then assigned to VLAN 100 with the switchport access vlan 100 command:
On SW3:
SW3(config)#interface e3/3
SW3(config-if)#switchport mode access
SW3(config-if)#switchport access vlan 100
SW3(config-if)#no shut
As a result of the above configuration, vlan traffic requested of neighbor portion of the output below
shows that SW3 expects to receive VLAN traffic for VLAN 1 and VLAN 100 over the trunk link:
Note: You may have to wait for 30 seconds for STP convergence:
On SW3:
SW3#show interfaces pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
200,300,400,500,600
Port
Et4/0
Vlan traffic requested of neighbor
1,100
This configuration can be verified on SW2 as well using the show interfacespruning command. The first
section of the output below shows the VLANs pruned off the trunk link to SW3. The second section lists
the VLANs SW2 has included in its VMAs to SW3, indicating the VLANs for which it wishes to receive
traffic:
On SW2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 74
SW2#show interfaces pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
200,300,400,500,600
Port
Et4/0
Vlan traffic requested of neighbor
1,100
The first section of the above output reveals that VLAN 100 is no longer pruned.
Task 23
Configure the switches such that only VLAN 300 is pruned.
To begin solving this task the show interface e4/0 pruning command output from SW2 is examined
below:
On SW2:
SW2#show interfaces e4/0 pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
200,300,400,500,600
Port
Et4/0
Vlan traffic requested of neighbor
1,100
As seen above, SW2 has pruned the VLANs 200, 300, 400, 500 and 600 from the E4/0 trunk link
connected to SW3. This is because SW3 has not requested traffic for these VLANs.
The task requires that only VLAN 300 is pruned off the trunk link. This can be achieved by modifying the
prune eligible list on both switches with the switchport trunk pruning vlan 300 command. This
command will configure the switches such that ONLY VLAN 300 is eligible for being pruned. The show int
erfacesinterfaces switchport command verifies the prune eligible list as seen below:
On SW2 and SW3:
SWx(config)#interface e4/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 75
SWx(config-if)#switchport trunk pruning vlan 300
On SW2:
SW2#show interfaces e4/0 switchport | include Pruning
Pruning VLANs Enabled: 300
On SW3:
SW3#show interfaces e4/0 switchport | include Pruning
Pruning VLANs Enabled: 300
Both switches now exchange VMAs with each other that excludes VLAN 300 from the “Advertised active
(i.e. not pruned) VLANs” list. As a result, the show interfaces pruning command output on SW2 and SW3
only shows VLAN 300 under the “Vlans pruned for lack of request by neighbor” section:
On SW2:
SW2#show interfaces e4/0 pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
300
Port
Et4/0
Vlan traffic requested of neighbor
1,100,200,400,500,600
On SW3:
SW3#show interfaces e4/0 pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
300
Port
Et3/0
Vlan traffic requested of neighbor
1,100,200,400,500,600
Task 24
Configure the switches such that VLAN 200 is also pruned. You should not use the
command from the previous task to accomplish this task.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 76
This task requires pruning off VLAN 200 as well from the trunk link E4/0 connecting SW2 and SW3. This
can be done with the add parameter of the switchport trunk pruning vlan command. The add keyword
results in adding VLAN 200 to the already existing VLAN pruning eligible list:
On SW2 and SW3:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk pruning vlan add 200
To verify the configuration:
Note: VLAN 200 is added to the list of pruned
VLANs
On SW2:
SW2#show interfaces pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
200,300
Port
Et4/0
Vlan traffic requested of neighbor
1,100,400,500,600
On SW3:
SW3#show interfaces pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
200,300
Note: VLAN 200 is added to the list of pruned VLANs
Port
Et4/0
Vlan traffic requested of neighbor
1,100,400,500,600
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 77
Task 25
Configure SW2 and SW3 such that none of the VLANs are pruned.
This task requires configuring the switches such that none of the VLANs are eligible for
pruning on the trunk link between SW2 and SW3. This can be done with the none
parameter added to the switchport trunk pruning vlan command as seen below. The
show interface e4/0 switchport command output also shows the prune eligible list to be
NONE:
On Both Switches:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk pruning vlan none
To verify the configuration:
On SW3:
SW3#show interfaces e4/0 switchport | include Pruning
Pruning VLANs Enabled: NONE
On SW2:
SW2#show interfaces e4/0 pruning
Port
Et4/0
Port
Et4/0
Vlans pruned for lack of request by neighbor
none
Note: None of the VLANs are pruned
Vlan traffic requested of neighbor
1,100,200,300,400,500,600
On SW3:
SW3#show interfaces e4/0 pruning
Port
Et4/0
Port
Et4/0
Vlans pruned for lack of request by neighbor
none
Note: None of the VLANs are pruned
Vlan traffic requested of neighbor
1,100,200,300,400,500,600
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 78
Task 26
Configure SW2 and SW3 such that all configured VLANs in the VLAN database are
pruned.
This task requires ALL VLANs in the VLAN database to be pruned from the trunk link E4/0 between SW2
and SW3. The current VLAN database holds VLANs 1,100,200,300,400,500,600. To remove these VLANs
the command switchport trunk pruning vlan 1,100,200,300,400,500,600 is issued on SW2 and SW3’s
E4/0 interface. However, such a configuration results in the following error message Command rejected:
Bad VLAN pruning list:
On Both Switches:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk pruning vlan 1,100,200,300,400,500,600
You should receive the following errors:
Command rejected Bad VLAN pruning list.
As already mentioned, VLAN 1 is prune ineligible. The above error message was generated because
VLAN 1 cannot be pruned. To bypass this error the command is entered again but this time without
specifying VLAN 1:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk pruning vlan 100,200,300,400,500,600
To verify the configuration:
Observing the output below we notice all the above listed VLANs except VLAN 100 has been pruned off
the trunk link E4/0 between SW2 and SW3. The reason for this is that Task 19 and Task 22 of this section
configured access ports in VLAN 100 on SW2 and SW3. In other words, VLAN 100 cannot be pruned
because both the switches have port membership in VLAN 100.
On SW2:
SW2#show interfaces e4/0 pruning
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 79
Port
Et4/0
Vlans pruned for lack of request by neighbor
200,300,400,500,600
Port
Et4/0
Vlan traffic requested of neighbor
1,100
To summarize the points in this task:


VLAN 1 cannot be pruned.
If the local switch has port membership in a given VLAN, that VLAN cannot be pruned.
Task 27
Configure SW2 and SW3 such that VLAN 200 is no longer pruned; do not use a
command that was used before to accomplish this task.
This task requires removing VLAN 200 from the existing VLAN prune eligible list. This can be done with
the switchport trunk pruning vlan remove 200 command on the trunk interface E4/0 on SW2 and SW3
as seen below:
On Both Switches:
SWx(config)#interface e4/0
SWx(config-if)#switchport trunk pruning vlan remove 200
To verify the configuration:
The switchport interface pruning command output below verifies the above configuration. VLAN 200 is
removed from the Vlans pruned for lack of request by neighbor section for the trunk link between SW2
and SW3:
On SW2:
SW2#show interfaces e4/0 pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
300,400,500,600
Port
Vlan traffic requested of neighbor
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 80
Et4/0
1,100,200
Note: VLAN 200 was removed from the
list of VLANs being pruned.
On SW3:
SW3#show interfaces e4/0 pruning
Port
Et4/0
Vlans pruned for lack of request by neighbor
300,400,500,600
Port
Et4/0
Vlan traffic requested of neighbor
1,100,200
NOTE: VLAN 200 was removed from the list of VLANs being
Pruned.
With the “switchport trunk pruning vlan remove” command, you are asking the switch to remove the
specified VLAN from the list of pruned VLANs, meaning “Do not prune this VLAN”.
Task 28
Erase the vlan.dat and config.text files and reload the switches before proceeding to the
next lab.
VLAN information on Cisco switches is stored in a separate file in the switch’s flash storage known as the
VLAN database. This means wiping the configuration of the device by removing the startup configuration
file, is not enough to remove the VLAN configurations themselves. In order to wipe VLAN configurations
from a switch, the VLAN database needs to be deleted from flash storage with the delete command. The
file typically exists as flash:vlan.dat. The startup configuration file is then erased with the erase startupconfig command and the switch is then rebooted.
Note: On virtual platforms such as EVE-ng, the VLAN.dat file can be found under the unix directory.
To follow the task and the VLAN.dat file, issue the following commands on the switches and then reload all
the devices for the changes to effect:
SWx#delete vlan.dat-00010 → This name may differ
Delete filename [vlan.dat-00010]?
Delete unix:/vlan.dat-00010? [confirm]
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 81
SWx#erase startup-config
Erasing the nvram filesystem will remove all configuration files!
Continue? [confirm]
[OK]
Erase of nvram: complete
Lab 2
Configuring EtherChannels
Task 1
Configure the hostname of the switches based on the provided diagram. Ensure that all
the ports of these four switches are in shutdown mode. Configure these four switches in
a VTP domain called TST.
The following first uses the hostname command on each switch to set the hostnames as shown in the
diagram. The interface range command is used on all switches to shutdown all the interfaces on the
switch. The VTP domain name is set manually on each switch with the vtp domain TST command:
On the second Switch:
Switch(config)#hostname SW2
SW2(config)#interface range e0/1-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/03,e6/0-3
SW2(config-if-range)#shut
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 82
SW2(config)#vtp domain TST
Changing VTP domain name from NULL to TST
On the third Switch:
Switch(config)#hostname SW3
SW3(config)#interface range e0/1-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/03,e6/0-3
SW3(config-if-range)#shut
SW3(config)#vtp domain TST
Changing VTP domain name from NULL to TST
On the fourth Switch:
Switch(config)#hostname SW4
SW4(config)#interface range e0/1-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3
SW4(config-if-range)#shut
SW4(config)#vtp domain TST
Changing VTP domain name from NULL to TST
On the fifth Switch:
Switch(config)#hostname SW5
SW5(config)#interface range e0/1-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3
SW5(config-if-range)#shut
SW5(config)#vtp domain TST
Changing VTP domain name from NULL to TST
Task 2
Configure ports E4/0 and E4/1 on SW2 and SW3 as trunk links, using an industrystandard
protocol. These links should appear to Spanning Tree Protocol as a single link. If
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 83
one of the links fails, the traffic should use the other link, without any interruption. The
ports on SW2 should be configured such that they only respond to PAgP packets and
never start the negotiation process.
The task above makes mention to a very specific problem the current topology has. Looking at the
topology diagram, SW2 and SW3 have redundant links connecting the two switches, E4/0 and E4/1. In
normal network operation, Spanning-Tree Protocol (STP) will only allow one of these two links to be in the
forwarding mode. This move by STP effectively halves the available bandwidth between the two switches.
The other link will only be used if the primary fails and after slowly transitioning through the STP states.
In order to allow both links to be used simultaneously, the switch needs to be able to represent them as a
single path to STP. This can be accomplished with EtherChannel Bundling. An EtherChannel bundle is a
collection of individual Ethernet links. These links are represented by a single logical interface known as
the Port Channel Interface. The port channel interface holds all of the configuration information for the
bundled links. It is also the interface that is presented to STP by the switch instead of the individual links
that make up the EtherChannel bundle. Traffic is load balanced between the available links within the
EtherChannel based on a load-balancing method.
Using EtherChannel, fault-tolerant, high-speed links can be created between switches. An EtherChannel
can consist of up to 8 bundled links. If a single link fails, traffic forwarding continues across the remaining
links. The downside to EtherChannel is the configuration. In order to function properly, all links within the
bundle must have identical configurations with regards to trunk mode, encapsulation, speed and duplex
settings.
For proper EtherChannel operation, both devices on either side of the EtherChannel link must agree that the
EtherChannel should exist between them. These hurdles make managing EtherChannel configurations
somewhat difficult. The reason is each device may send frames from the same ethernet source MAC
address across different links. If the far-end switch has not properly bundled the link, it may cause MAC
address flapping. Additionally, loops could form because STP BPDUs are only sent out of one link in the
bundle to the far-end switch. This means the far-end switch would only receive a BPDU on one of its ports,
making it assume the rest of the bundled ports are not connected to a neighboring bridge resulting in it
making its port Designated, forming a layer 2 loop.
To help with configuration consistency amongst member interfaces and with the remote EtherChannel
endpoint, two EtherChannel bundling protocols exist: Port Aggregation Protocol (PAgP) and Link
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 84
Aggregation Control Protocol (LACP). PAgP is a Cisco Proprietary protocol whereas LACP is an
industry standard, defined in the IEEE 802.3ad specification. Once configured, the EtherChannel protocol
handles the following tasks:
-
Ensures member interfaces have compatible configurations to participate in the EtherChannel
bundle
Ensures the far side switch agrees that the EtherChannel link exists between the two switches over
the proper connected interfaces.
If the EtherChannel protocol determines incompatible configurations on member interfaces, the
EtherChannel protocol will suspend the interface from participating in the EtherChannel bundle until the
configurations are made consistent. If the far end switch does not agree to the EtherChannel link, the
EtherChannel protocol will not bring the EtherChannel up on the local switch, allowing the member
interfaces to operate as independent interfaces.
Individual interfaces are configured to participate in an EtherChannel bundle using the channel-group
command. This command has five different options for configuring EtherChannel:
1. ON : Forces interfaces to operate as an EtherChannel without the use of PAgP or LACP. This is also
considered to be manual configuration.
2. ACTIVE : Enables LACP active negotiation for EtherChannel bundling with the remote interface
3. PASSIVE : Enables passive LACP negotiation. The interface will respond to LACP frames sent by
the remote interface but will not send any first.
4. DESIRABLE : Enables PAgP active negotiation for the EtherChannel bundling with the remote
interface.
5. AUTO - Enables passive PAgP negotiation for the EtherChannel bundling with the remote
interface. The interface will respond to PAgP frames sent by the remote interface but will not send
any first.
In EtherChannel bundles, both sides of the link must agree on the EtherChannel protocol (PAgP, LACP, or
none) and at least one side of the link must be configured to initiate the bundling process. The following
table indicates the different combinations of interface configurations and whether or not an EtherChannel
bundle will be formed:
If SW2 is configured If SW3 is configured
in
in
CCIE by Narbik Kocharians
Will an
EtherChannel be
Protocol used
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 85
established
Desirable
Desirable
YES
PAgP
Desirable
Auto
YES
PAgP
Auto
Auto
NO
-
Active
Active
YES
LACP
Active
Passive
YES
LACP
Passive
Passive
NO
-
On
On
YES
None
ON
Auto
NO
-
On
Desirable
NO
-
On
Passive
NO
-
On
Active
NO
-
Desirable
Active
NO
-
Desirable
Passive
NO
-
Auto
Passive
NO
-
Looking at the table above, the basic conclusion is in order for the EtherChannel bundle to form, one of
two things must be true:
1. If manual configuration is being used, both sides should be configured in
the ON mode.
2. If PAgP or LACP are in use, at least one side should be configured to
actively negotiate an EtherChannel.
For example, from the table, if one side is set to Auto and the other is set to Passive, they not only do
not agree on EtherChannel protocol (Auto indicates PAgP operation and Passive indicates LACP
operation) but neither side will actively attempt to bring up the EtherChannel. Instead, a combination
such as one side set to Desirable and the other set to Auto will work. In this case, both sides agree to
PAgP operation and the side set to Desirable will begin the EtherChannel negotiations.
The configuration of EtherChannels should be done in a certain order. The following is my
recommendation of the order when setting up EtherChannels:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 86
Step 1: Use the default interface command for all the interfaces that are to be bundled up into the same
port channel. The default interface command resets the interface back to their default values.
Additionally, for ease of configuration, the default interface range command can be used to reset multiple
interfaces to their default state.
Step 2: Configure the EtherChannel by issuing the channel-group channel-number mode command to the
physical interfaces. This will result in automatic port-channel interface creation. The channel-number
value does not have to match on both sides.
Step 3: Configure the trunk related parameters directly on the port-channel interface configuration mode
Step 4: Reset the ports in the group by first issuing the shutdown command followed by the no shutdown
command.
Task 2 requires bundling up the E4/0 and E4/1 interface on SW2 and SW3 into an EtherChannel. It
specifically requires the use of PAgP as the negotiation protocol. In addition, the task further states that
SW2 should never start the negotiation process. Instead, it should wait until it receives PAgP frames from
SW3 to form a bundle. This means, the port-channel on SW2 should be configured in the auto mode. In
this mode, the switch passively waits for PAgP frames from the far-end switch, SW3. The port-channel on
SW3 will be configured in desirable mode. With this configuration, SW3 will be actively attempting to
form a bundle with SW2 by sending out PAgP frames.
Finally, the configured port-channel between SW2 and SW3 will be used to carry traffic for multiple
VLANs. This means the port-channel between SW2 and SW3 needs to be configured as a trunk link. The
trunk parameters as specified in the task states to use the industry standard encapsulation protocol
802.1q. This is done with the switchport trunk encapsulation dot1q command under the port-channel
interfaces on SW2 and SW3. The port-channel is then manually set to function as a trunk port with the
switchport mode trunk command.
All of the above configurations are made on SW2 and SW3 below in the order specified above:
Step One:
On SW2:
SW2(config)#default interface range e4/0-1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 87
SW2(config)#interface range e4/0-1
SW2(config-if-range)#no shut
Step Two:
SW2(config)#interface range e4/0-1
SW2(config-if-range)#channel-group 23 mode auto
You should see the following console messages:
Creating a port-channel interface Port-channel 23
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet4/0, changed
state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet4/1, changed
state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet4/0, changed
state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet4/1, changed
state to up
Note: The interface port-channel 23 is created automatically:
SW2#show run interface port-channel 23 | begin interface
interface Port-channel23
end
Step Three:
SW2(config)#interface port-channel 23
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
On SW3:
SW3(config)#default interface range e4/0-1
SW3(config)#interface range e4/0-1
SW3(config-if-range)#channel-group 32 mode desirable
SW3(config)#interface port-channel 32
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 88
Step Four:
On SW2 and SW3:
SWx(config-if)#interface range e4/0-1
SWx(config-if-range)#shut
SWx(config-if-range)#no shut
To verify the configuration:
The result of the above configuration can be verified in the show interfaces trunk output below where the
port channel between SW2 and SW3 functions as a 802.1q trunk:
On SW2:
SW2#show interface trunk
Port
Po23
Mode
on
Encapsulation
802.1q
Status
trunking
Native vlan
1
Port
Po23
Vlans allowed on trunk
1-4094
Port
Po23
Vlans allowed and active in management domain
1
Port
Po23
Vlans in spanning tree forwarding state and not pruned
1
On SW3:
SW3#show interface trunk
Port
Po32
Mode
on
Port
Po32
Vlans allowed on trunk
1-4094
Port
Po32
Vlans allowed and active in management domain
1
Port
Vlans in spanning tree forwarding state and not pruned
CCIE by Narbik Kocharians
Encapsulation
802.1q
Status
trunking
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Native vlan
1
Page 89
Po32
1
The show interfaces e4/0 switchport | include Operational Mode command
shows the Operational Mode of the member interfaces of the EtherChannel
bundle have been set to trunk with the added mention that they belong to
a member of a PortChannel interface:
On SW2:
SW2#show interface e4/0 switchport | include Operational Mode
Operational Mode: trunk (member of bundle Po23)
SW2#show interface e4/1 switchport | include Operational Mode
Operational Mode: trunk (member of bundle Po23)
On SW3:
SW3#show interface e4/0 switchport | include Operational Mode
Operational Mode: trunk (member of bundle Po32)
SW3#show interface e4/1 switchport | include Operational Mode
Operational Mode: trunk (member of bundle Po32)
Another result of this configuration is how the switch perceives the two interfaces. Notice in the show
interfaces trunk output above only a single interface, the PortChannel interface, was listed as operating in
trunk mode. This is because the switch no longer considers each individual link as separate, but rather
identifies them as a single logical link represented by the PortChannel interface. This treatment extends to
how the switch presents the link to Spanning-Tree Protocol. The show spanning-tree vlan 1 output from
SW2 below confirms that the switch lists the PortChannel interface and not the individual links (e4/0 and
e4/1) as a link that is running the STP instance:
SW2#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address aabb.cc00.0a00
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority
32769 (priority 32768 sys-id-ext 1)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 90
Address aabb.cc00.0a00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15 sec
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- -------------------------------Po23
Desg FWD 56
128.65 P2p
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 91
Task 3
Configure ports E5/0 and E5/1 on SW2 and SW4 as trunk links, using an industrystandard
protocol. These links should appear to Spanning Tree Protocol as a single link.
If one of the links fails, the traffic should use the other link, without any interruption.
These ports should not negotiate an etherchannel by exchanging LACP or PAgP protocols
to accomplish this task.
This task requires EtherChannel bundling of the redundant links E5/0-1 connecting SW2 and SW4. The
configuration to establish the port-channel between SW2 and SW4 follows the configuration steps stated
earlier.
First, the E5/0-1 interfaces on SW2 and SW4 are reset to their default state with the default interface
range e5/0-1 command. The no shut command is then used to bring these interfaces up. These interfaces
are then assigned to their respective EtherChannel groups with the channel-group channel-group-number
command.
Since the task restricts the use of any dynamic negotiation protocol for port-channel establishment, the on
mode will be used to manually configure the port-channel between the switches. The port-channel between
SW2 and SW4 is then configured for a static 802.1q trunk with the switchport trunk encapsulation dot1q
and switchport mode trunk command. The physical interfaces are then reset by first shutting them down
with the shut command and then bringing them up with the no shut command:
On SW2:
Step One:
SW2(config)#default interface range e5/0-1
SW2(config)#interface range e5/0-1
SW2(config-if-range)#no shut
Step Two:
SW2(config)#interface range e5/0-1
SW2(config-if-range)#channel-group 24 mode on
Step Three:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 92
SW2(config-if-range)#interface port-channel 24
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
On SW4:
Step One:
SW4(config)#default interface range e5/0-1
SW4(config)#interface range e5/0-1
SW4(config-if-range)#no shut
Step Two:
SW4(config)#interface range e5/0-1
SW4(config-if-range)#channel-group 42 mode on
Step Three:
SW4(config-if-range)#interface port-channel 42
SW4(config-if)#switchport trunk encapsulation dot1q
SW4(config-if)#switchport mode trunk
Step Four:
On SW2 and SW4
SWx(config)#interface range e5/0-1
SWx(config-if-range)#shut
SWx(config-if-range)#no shut
To verify the configuration:
The show interface trunk command output from SW2 and SW4 verifies the 802.1q static trunk portchannel between them:
SW2#show interfaces trunk | include 802
Po23
Po24
on
on
CCIE by Narbik Kocharians
802.1q
802.1q
trunking
trunking
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
1
1
Page 93
On SW4:
SW4#show interfaces trunk | include 802
Port
Po42
Mode
on
Encapsulation
802.1q
Status
trunking
Native vlan
1
Notice the show etherchannel protocol command output from SW2 below. The highlighted output in
black is the port-channel set up between SW2 and SW3 in task 2. The Protocol portion of this output
shows the protocol used for this EtherChannel negotiation is PAgP. In contrast, the Protocol portion of the
output highlighted in green shows ON, meaning neither LACP or PAgP was used to negotiate this port
channel:
SW2#show etherchannel protocol
Channel-group listing:
---------------------Group: 23
---------Note: PAgP is used for EtherChannel negotiation
Protocol: PAgP
Group: 24
---------Protocol:
Note: PAgP or LACP is not in use
-
(Mode ON)
Finally, the show EtherChannel summary command provides a lot of information about the operational
state of the port channels. The output from SW4 is shown as an example. The SU in parenthesis in the
highlighted output below indicates that Po42 is a Layer 2 port-channel and is currently in use. The P
indicated against the physical interfaces show that these interfaces have been bundled to form the portchannel 42:
SW4#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
N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 94
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
A - formed by Auto LAG
Number of channel-groups in use: 1
Number of aggregators:
1
Group Port-channel Protocol
Ports
------+-------------+-----------+--------------------42
Po42(SU)
Et5/0(P)
Et5/1(P)
Task 4
Ensure that all the EtherChannels created on SW2 are load balanced based on the
destination MAC address.
When forwarding frames out of an EtherChannel bundle, the switch needs to determine which member
interface should be used to transmit the frame. The switch cannot send some bits of a frame over one
interface and the remaining over another. A single frame should be sent, in full, over a single interface.
The switch determines which individual link of an EtherChannel will be used to transmit the frame based
on a hashing algorithm. This algorithm is called the EtherChannel load-balancing method and is based on
the source/destination MAC address, source/destination IP address, or both depending on the setting and
switching platform being used. This algorithm is only applied whenever the switch determines an
incoming or self-generated frame should be forwarded out of an EtherChannel interface.
In order to achieve maximum load balancing between member interfaces, the EtherChannel loadbalancing method needs to be set to provide diverse hash value results. For instance, if the EtherChannel
bundle were connected to a single end device, using source MAC or IP address as the load-balancing
method would generate in the same hash result for all traffic originating from the device. This is because
the source MAC and IP address would be the same for all traffic sent by the single device. The result is
only a single link of the EtherChannel bundle would be utilized. Instead, in such a situation, a method that
incorporates destination MAC or IP addressing would be preferred as the variety would be much greater
for traffic originating from that device.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 95
The port-channel load-balance ? command options below reveals the load balancing options available on
these switches. These options may vary between different platforms.
SW2(config)#port-channel load-balance ?
dst-ip
dst-mac
src-dst-ip
src-dst-mac
src-ip
src-mac
Dst IP Addr
Dst Mac Addr
Src XOR Dst IP Addr
Src XOR Dst Mac Addr
Src IP Addr
Src Mac Addr
The following describes briefly each of the load balancing options presented above:
1. Destination IP address - With this option, when packets are forwarded to an EtherChannel, they
are distributed across the interfaces in the channel based on the destination IP address of the
incoming or self-generated frame.
2. Destination MAC address - With this option, when packets are forwarded to an EtherChannel, they
are distributed across the interfaces in the channel based on the destination MAC address of the
incoming or self-generated frame.
3. Source and Destination IP address - With this option, when packets are forwarded to a
EtherChannel, they are distributed across the interfaces in the channel based on the source and
destination IP address pair of the incoming or self-generated frame.
4. Source and Destination MAC address - With this option, when packets are forwarded to a
EtherChannel, they are distributed across the interfaces in the channel based on the source and
destination MAC address pair of the incoming or self-generated frame.
5. Source IP address - With this option, when packets are forwarded to a EtherChannel, they are
distributed across the interfaces in the channel based on the source IP address of the incoming or
self-generated frame.
6. Source MAC address - With this option, when packets are forwarded to a EtherChannel, they are
distributed across the interfaces in the channel based on the source MAC address of the incoming
or self-generated frame.
This task requires the load-balancing method on SW2 for all its port channels to be based on the
destination MAC address. The default load balancing method in use can be checked with the show
etherchannel load-balance command. As seen below, SW2 by default load balances on the Source and
Destination IP address pair:
SW2#show EtherChannel load-balance
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 96
EtherChannel Load-Balancing Configuration:
src-dst-ip
The task specifies that the switches should use destination MAC addresses as input to the hashing
algorithm.To modify the load balancing method to the specified destination MAC mode, the command
port-channel load-balance dst-mac is issued on SW2. The show etherchannel load-balance output
verifies this configuration change:
To configure the load balancing based on the destination MAC addresses:
SW2(config)#port-channel load-balance dst-mac
To verify the configuration:
SW2#show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
dst-mac
EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Destination MAC address
IPv4: Destination MAC address
IPv6: Destination MAC address
Since the command is entered in the global configuration mode, it effects all EtherChannel bundles
created on the local switch.
Task 5
Configure ports E6/0 and E6/1 on SW3 and SW4 as a single Layer 3 link; SW3 should be
configured with the IP address 34.1.1.3/24, and SW4 should be configured with the IP
address 34.1.1.4/24. These ports should not negotiate LACP or PAgP.
This task requires bundling the E6/0-1 interfaces connecting SW3 and SW4 into a Layer 3 port-channel. A
layer three port channel requires a different configuration flow compared to the Layer 2 port channels
configured earlier in this section. With Layer 2 port channels, the port channel interface was created
automatically when the channel-group command was issued on the interfaces. Layer 3 port channels must
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 97
first be defined by the interface port-channel command and then enabled for Layer 3 operation with the
no switchport command. The member interfaces are then associated with the configured Layer 3 port
channels after enabling Layer 3 operations on them individually.
Configuration order of Etherchannels
Configuration of Layer 3 Etherchannels should be done in a certain order. Following is my
recommendation of the order when setting up Layer 3 etherchannels:
Step 1 : Use the default interface command to reset the member interfaces to their default state
Step 2 : Configure the port-channel with the interface port-channel channel-group-number command.
Issue the no switchport for this port-channel to disable Layer 2 operations and enable Layer 3 operations.
Assign an Ip address to this port-channel
Step 3 : Issue the no switchport command under the physical interfaces that are to be bundled up into the
Layer 3 port channel. Assign the port-channel created in step 2 to the physical interfaces with the channelgroup channel-group-number mode command (the channel-group-number should match the channelgroup-number used to configure the port-channel interface in the interface port-channel channel-groupnumber command).
Step 4 : Flap the physical interfaces with the shutdown and then a no shut command
The above steps can be examined in the below configuration that completes this task by creating a Layer 3
EtherChannel between SW3 and SW4:
On SW3:
Step One:
SW3(config)#default interface range e6/0-1
Step Two:
SW3(config)#interface port-channel 34
SW3(config-if)#no switchport
SW3(config-if)#ip address 34.1.1.3 255.255.255.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 98
Step Three:
SW3(config)#interface range e6/0-1
SW3(config-if-range)#no switchport
SW3(config-if-range)#channel-group 34 mode on
Step Four:
SW3(config)#interface range e6/0-1
SW3(config-if-range)#shut
SW3(config-if-range)#no shut
On SW4:
Step One:
SW4(config)#default interface range e6/0-1
Step Two:
SW4(config)#interface port-channel 43
SW4(config-if)#no switchport
SW4(config-if)#ip address 34.1.1.4 255.255.255.0
Step Three:
SW4(config)#interface range e6/0-1
SW4(config-if-range)#no switchport
SW4(config-if-range)#channel-group 43 mode on
Step Four:
SW4(config)#interface range e6/0-1
SW4(config-if-range)#shut
SW4(config-if-range)#no shut
To verify and test the configuration:
Following the above configuration, the show etherchannel summary can be used to verify the Layer 3
port-channel. The example output below from SW4 highlights the relevant parts. Notice the RU in
parenthesis against the Po43. The R indicates that Po43 is a Layer 3 port-channel and is currently in use as
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 99
indicated with the U. The member physical interfaces once again have P assigned to them indicating that
these interfaces are bundled to form the Layer 3 port-channel 43:
SW4#sh etherc 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
N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
A - formed by Auto LAG
Number of channel-groups in use: 2
Number of aggregators:
2
Group Port-channel Protocol
Ports
-------+----------------+-----------+----------------------------42
Po42(SU)
PAgP
Et5/0(P)
Et5/1(P)
43
Po43(RU)
Et6/0(P)
Et6/1(P)
SW4#show ip interface brief | exclude unassigned
Interface
Port-channel43
IP-Address
34.1.1.4
OK? Method Status
YES manual up
Protocol
up
SW4#ping 34.1.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.1.1.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Task 6
Erase the startup configuration and vlan.dat files before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 100
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 101
Lab 3
An STP Walk Through
Spanning-tree Technology
Introduction Lab
This section is designed to teach basic to advanced concepts of Spanning Tree Protocol-.
It utilizes a common topology over which each version of Spanning Tree Protocol is
configured with a given set of requirements and restraints. The requirements and restraints
are engineered to explain the behaviors of each version of Spanning Tree Protocol,
highlighting the important limitations and enhancements of each feature.
This lab is entirely focused on Spanning Tree Protocol technologies and assumes basic
knowledge of the following:





Trunking configuration
VLAN configuration and usage
Layer 2 link aggregation
IP address configuration
Basic IP connectivity testing
*NOTE*: The solutions provided in this lab are not all inclusive. There may be
many ways to solve each task. All alternate solutions are acceptable, provided
that they do not violate previous restraints or tasks.
802.1D Per-VLAN Spanning Tree
Protocol
Initial Lab Setup
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 102
Referencing the 802.1D PVST+, 802.1w and the MST topology diagrams, the following is the
initial setup for the demonstration labs. Use this same initial set up when starting each lab.
Task 1
Change the hostname on each switch to SW#, where # is the number of the switch (for
example, Switch 1 = SW1).
SW1 through SW6 are each assigned hostnames with the hostname command as shown
below:
On SW1:
Switch(config)#hostname SW1
On SW2:
Switch(config)#hostname SW2
On SW3:
Switch(config)#hostname SW3
On SW4:
Switch(config)#hostname SW4
On SW5:
Switch(config)#hostname SW5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 103
On SW6:
Switch(config)#hostname SW6
Task 2
Ensure that only the following ports on the switches are in an up/up state:
For each sub task in task 2, the interface range command is first used to list all the
interfaces on the switches. The shutdown command is then issued to shutdown these
interfaces. Following this, the interface range lists interfaces specified in the task
that are brought back up with the no shut command:

SW1


E2/1-2
E3/1-2
On SW1:
SW1(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW1(config-if-range)#shut
SW1(config)#interface range e2/1-2,e3/1-2
SW1(config-if-range)#no shut
To verify the configuration:
SW1#show ip interface brief | exclude down
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
Ethernet3/2
IP-Address
unassigned
unassigned
unassigned
unassigned

SW2


OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
E1/1-2
E3/1-2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 104


E4/1-2
E5/1-2
On SW2:
SW2(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW2(config-if-range)#shut
SW2(config)#interface range e1/1-2,e3/1-2,e4/1-2,e5/1-2
SW2(config-if-range)#no shut
To verify the configuration:
SW2#show ip interface brief | ex down
Interface
Ethernet1/1
Ethernet1/2
Ethernet3/1
Ethernet3/2
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW3




OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
up
up
E1/1-2
E2/1-2
E4/1-2
E5/1-2
On SW3:
SW3(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW3(config-if-range)#shut
SW3(config)#interface range e1/1-2,e2/1-2,e4/1-2,e5/1-2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 105
SW3(config-if-range)#no shut
To verify the configuration:
SW3#show ip interface brief | exclude down
Interface
Ethernet1/1
Ethernet1/2
Ethernet2/1
Ethernet2/2
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW4



OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
up
up
E2/1-2
E3/1-2
E6/1-2
On SW4:
SW4(config)#interface rang e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW4(config-if-range)#shut
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#no shut
To verify the configuration:
SW4#show ip interface brief | exclude down
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
Ethernet3/2
Ethernet6/1
CCIE by Narbik Kocharians
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Protocol
up
up
up
up
up
Page 106
Ethernet6/2
unassigned

SW5



YES unset
up
up
E2/1-2
E3/1-2
E6/1-2
On SW5:
SW5(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW5(config-if-range)#shut
SW5(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW5(config-if-range)#no shut
To verify the configuration:
SW5#show ip interface brief | exclude down
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
Ethernet3/2
Ethernet6/1
Ethernet6/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW6


OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
E4/1-2
E5/1-2
On SW6:
SW6(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 107
SW6(config-if-range)#shut
SW6(config)#interface range e4/1-2,e5/1-2
SW6(config-if-range)#no shut
To verify the configuration:
SW6#show ip interface brief | exclude down
Interface
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
Task 3
Configure VLANs 10, 20, 30, and 40 on each switch, using any method.
This task requires configuring VLANs 10, 20, 30, 40 on the switches. Since the task does not state any
restrictions, for ease of configuration, VTP can also be used to propagate the VLANs to all the switches.
On All Switches:
SW1(config)#vlan 10,20,30,40
SW1(config-vlan)#exit
To verify the configuration:
On Any Switch:
SWx#show vlan brief | include VLAN
VLAN Name
10
VLAN0010
20
VLAN0020
30
VLAN0030
40
VLAN0040
CCIE by Narbik Kocharians
Status
active
active
active
active
Ports
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 108
Task 4
Configure trunk ports on all up/up interfaces.
The commands switchport trunk encapsulation dot1q and switchport mode trunk is configured on all
the interfaces on all the switches that were brought back up in the initial lab setup section of this lab. The
combination of these commands manually configures the interfaces to function as 802.1q trunk links.
On SW1:
SW1(config)#interface range e2/1-2,e3/1-2
SW1(config-if-range)#switchport trunk encapsulation dot1q
SW1(config-if-range)#switchport mode trunk
On SW2:
SW2(config)#interface range e1/1-2,e3/1-2,e4/1-2,e5/1-2
SW2(config-if-range)#switchport trunk encapsulation dot1q
SW2(config-if-range)#switchport mode trunk
On SW3:
SW3(config)#interface range e1/1-2,e2/1-2,e4/1-2,e5/1-2
SW3(config-if-range)#switchport trunk encapsulation dot1q
SW3(config-if-range)#switchport mode trunk
On SW4:
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#switchport trunk encapsulation dot1q
SW4(config-if-range)#switchport mode trunk
On SW5:
SW5(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW5(config-if-range)#switchport trunk encapsulation dot1q
SW5(config-if-range)#switchport mode trunk
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 109
On SW6:
SW6(config)#interface range e4/1-2,e5/1-2
SW6(config-if-range)#switchport trunk encapsulation dot1q
SW6(config-if-range)#switchport mode trunk
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 110
Configuration Tasks: 802.1D
Before getting into the tasks, it helps to review the basic operation of Spanning Tree
Protocol and some of the terms that will be used throughout the solution guide. These
concepts will be fleshed out more throughout the guide.
802.1D Spanning Tree Protocol is the protocol that is run between switches used to prevent
Layer 2 bridging loops. Loops can form in Layer 2 networks because the Layer 2
Ethernet frame format does not contain any maximum hop count limitation, such as the
TTL field in the IP header. This omission of maximum hop count means a single Ethernet
frame can be forwarded infinitely throughout a switched network. This is particularly
dangerous when the frame being forwarded is a broadcast frame.
Switches are called transparent bridges because they abstract the physical network
design from the end stations connecting to the LAN. In the past, all stations connected
to a Layer 2 LAN were physically connected to the same physical electrical bus via a
repeater. Only one station could speak on the segment at a time, and all stations were
considered directly connected. This setup was called a single collision domain because
there was a possibility that two stations would transmit at the same time, and those
transmissions could collide.
Later, bridges came about that allowed intelligent learning. An ethernet Bridge would be
used to combine two Layer 2 network segments into a single Layer 2 network. Bridges
learned MAC addresses and only forwarded traffic between the two network segments
when necessary. This operation was transparent to the end stations, because as far as the
stations could detect, they were directly connected to the remote stations they were
communicating with. The ethernet bridge in this way creates two separate collision
domains.
An ethernet switch is basically a multiport bridge. Instead of learning MAC addresses
only on two ports, a switch learns MAC addresses on all ports and forwards traffic based
on destination MAC addresses to destination ports. If two ethernet frames are destined
to the same port, the switch will buffer one frame while forwarding the other. Because
not all traffic forwarded across the LAN segment is repeated to all ports, the switch
achieves a single collision domain between each port on the switch and the stations
connected to those ports.
For the switch to do this, it must first learn which MAC addresses are reachable off its
various ports. To do so, the switch reads the source MAC address of all frames it receives
and records it associated to the receiving port in a MAC address table, also called a
Content Addressable Memory or CAM table. The switch switches traffic between ports
by performing a lookup in the CAM table based on the destination MAC address of the
ethernet frames. Through this, known unicast traffic can be forwarded only out the port
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 111
where the intended station exists.
The problem arises when a switch receives a frame destined to a MAC address it has not
learned. The switch cannot drop the frame because that would break the LAN
communication. Instead, it floods the frame out all ports in the same VLAN on the switch
(including trunk ports that carry those VLANs) except the port on which it initially received
the frame. This process, known as unknown unicast flooding, can cause a loop condition in
the switched network with broadcast frames.
Broadcast frames are frames that are intended to be received by all stations. They are
sent to the well-known broadcast destination MAC address FFFF.FFFF.FFFF. When a
switch encounters a broadcast frame, it performs unknown-unicast-type flooding for the
frame in question. It sends the traffic out all interfaces except the interface on which it
was received. The switch does this because the broadcast MAC address FFFF.FFFF.FFFF
will never be the source of an ethernet frame. Because it is never the source of an ethernet
frame, the switch will never associate the broadcast MAC address with a receiving
port in its CAM table, triggering the unknown unicast flooding behavior.
If there are redundant links in a multi-switch environment, where the chain of
interconnected links leads back to the switch that originally forwarded the broadcast traffic,
a broadcast storm occurs. In a broadcast storm, each receiving switch performs the same
unknown-unicast-type flooding on the broadcast packet. The broadcast packet is therefore
regenerated and looped endlessly throughout the switched network. This leads to
high CPU utilization on the switches and can quickly bring down the entire Layer 2
network.
Spanning Tree Protocol converts a switched network into a shortest-path tree. This tree
is constructed by designating a switch as the root of the tree, called the root bridge. The
root bridge is the only bridge in which all of the ports are considered designated ports. A
designated port is a port that is responsible for relaying spanning-tree-related messages
downstream from the root bridge to other leaf switches. From the root bridge’s
perspective, all other switches are downstream from it, and thus it should be designated on
all of its ports.
All non-root switches elect a single port to become their root port. The root port is the
port that the switch uses to reach the root bridge. This port also receives spanningtreerelated messages on the shortest-path tree to be relayed out all other designated ports
on the switch.
Finally, redundant links in the network are put into a blocking state. So-called blocking
ports are ports that receive BPDUs from a designated port that is not on the shortest-path
tree. In other words, they are alternate looped paths to the root bridge that are longer
than the path used by the root port. Blocking ports do not send BPDUs in traditional
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 112
Spanning Tree Protocol; instead, a blocking port receives a constant flow of BPDUs from
the neighboring designated port.
Through this system of designated, root, and blocking ports, STP creates a loop-free
network. Broadcast frames and frames undergoing unknown unicast flooding travel the
shortest path from leaf switch to root switch and are blocked (dropped) on redundant
links.
Task 1
Configure all switches to run 802.1D Spanning Tree Protocol.
Cisco switches run a single instance of spanning tree for every VLAN configured on the switch. This is called
Per-VLAN Spanning-Tree protocol (PVST). There are two versions of this: PVST and PVST+. The original
PVST variant was for compatibility with ISL trunks. PVST+ is compatible with 802.1Q trunks. The advantage
of running PVST+ on a switch is that a separate Spanning-tree can be calculated per VLAN. This allows the
administrator to load balance traffic over redundant links by VLAN. Some VLANs can take a different set of
paths while others take the unused paths. The switch calculates the blocking/forwarding state for each
individual VLAN running over the trunk link, allowing a single trunk port to be blocking for one VLAN, root
for another, and designated for yet another.
802.1D PVST+ is enabled on older Cisco switches by default and can be statically configured using the
spanning-tree mode pvst command in global configuration mode. The output of the show spanning-tree
command indicates which spanning-tree variant the switch is currently using.
On All Switches:
To change the mode to PVST:
SWx(config)#spanning-tree mode pvst
To verify the configuration:
On SW1:
SW1#show spanning-tree | include VLAN|protocol
VLAN0001
Spanning tree enabled protocol ieee
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 113
VLAN0010
Spanning tree enabled protocol ieee
VLAN0020
Spanning tree enabled protocol ieee
VLAN0030
Spanning tree enabled protocol ieee
VLAN0040
Spanning tree enabled protocol ieee
In the above output, the spanning tree protocol enabled is listed as ieee. This is a reference to 802.1D
PVST+ which is run as default on some cisco switching platforms.
Task 2
Ensure that SW1 is the root for every VLAN.
Switches running Spanning-tree protocol organize themselves into a shortest-path tree that spans the
entire switched network. The tree starts, or has its roots, at a central point in the network. This central
point is called the root bridge because it is the root of the resulting tree topology. To determine the root
bridge, the switches perform a root bridge election. The winner of the election is based on whichever
switch has the best Bridge ID. The Bridge ID of a switch is composed of the following parts:
1. 16-bit Priority value (includes 12-bits for VLAN using System ID extension)
2. 48-bit MAC address
The Bridge ID is exchanged in STP configuration frames called, Bridge Protocol Data Units or BPDUs,
between switches. A switch receiving a BPDU compares it to its own BPDU. The BPDU with the lowest
Bridge ID is considered to have originated from the Root Bridge.This comparison is first made by
comparing the configured Priority Value (defaults to 32,768 on cisco platforms). If the priority value is a
tie, then whichever switch has the lowest MAC address will be elected root. When a switch receives a
BPDU from the root, it replaces its own stored BPDU with the Root’s and will relay it the Root’s BPDU out
all non-blocking ports towards other switches in the network. Within the STP network, all switches should
agree on which switch is the Root Bridge.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 114
The administrator should be careful in choosing which switch becomes the Root Bridge because once the
spanning-tree synchronizes across the switched network, all traffic for the network could pass through the
Root. For this reason, the Root bridge should be the most capable or centrally-located switch in the
network. Due to the nature of the default selection algorithm, in a production network, if all switches are
left at default settings the oldest switch in the network (by production date) will become the root bridge.
This is due to how vendors create their products. All vendors have a pool of MAC addresses from which
they will assign to their products. This assignment is usually done in ascending order (counting up from 0).
Thus, newer created products will have higher MAC addresses than older products in general.
The administrator can select which switch becomes the root bridge by modifying the Priority Value that
makes up the Bridge ID. The chosen Root Bridge should have a priority value lower than all other switches
in the network. The priority value is configured using the spanning-tree vlan [vlan-list] priority [priority]
command.
The priority value specified needs to be in multiples of 4096. The value 4096 is set because of the system
extended ID which uses the last 12 bits of the priority value to encode the VLAN number. Encoding the
VLAN number allows each VLAN instance of STP to have a unique Bridge ID for Cisco switches running
PVST+, which is a requirement of the STP standard.
Alternatively, the spanning-tree vlan [vlan-list] root primary command can be used to automatically set
the switch’s priority to be lower than the current root by 4096. Keep in mind this command only processes
once as a macro. If another switch is configured with a lower priority value, this command does not reset
the intended root switch’s value lower.
Looking at the task, the administrator is required to set SW1 as the root bridge. For this lab, no extra
configuration is needed, since SW1 has already been designated as the root bridge for all VLANs. The
decision was made based on SW1’s MAC address (lowest) as all switches have a tied priority value of
32,768. The show spanning-tree vlan 1 example output from SW1 verifies this. SW1 is currently the root
for VLAN 1 and will be the root by default for all the VLANs configured for this topology:
NOTE: If SW1 is not the root bridge in your topology, use the spanning-tree vlan 1-4094 root primary
command to make it the root bridge.
On SW1:
SW1#show spanning-tree vlan 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 115
VLAN0001
Spanning tree enabled protocol ieee
Root ID
Priority
32769
Address
aabb.cc00.1f00
This bridge is the root
Hello Time
2 sec Max Age 20 sec
Bridge ID
Priority
Address
Hello Time
Aging Time
Forward Delay 15 sec
32769 (priority 32768 sys-id-ext 1)
aabb.cc00.1f00
2 sec Max Age 20 sec Forward Delay 15 sec
300 sec
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- -----Et2/1
Desg FWD 100
128.10
P2p
Et2/2
Desg FWD 100
128.11
P2p
Et3/1
Desg FWD 100
128.14
P2p
Et3/2
Desg FWD 100
128.15
P2p
Task 3
Ensure that all switches wait a total of 10 seconds in the listening and learning states
before moving a port to forwarding.
Before moving a port from the blocking to a forwarding state, 802.1D transitions between two
intermediary states called the listening and learning states.
During the listening state, the switch listens and transmits configuration BPDUs, but will not transmit any
data traffic and will discard any received data traffic. The duration the switch remains in the listening state
is equal to the forward delay time which is 15 seconds by default. After a duration of the forward delay
time, the switch moves the port into the learning state. This state is similar to the listening state, except
the switch learns MAC addresses from the data traffic received on a port while still not forwarding them
out other ports. The duration the switch remains in the learning state is also equal to the forward delay
timer, 15 seconds by default, after which the port is transitioned to the forwarding state. These values can
be confirmed in the show spanning-tree output as shown in the example output from SW2 below:
On SW2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 116
Notice the two sets of timers in the output below. The first forward delay is the delay set by the Root
Bridge and is propagated to all the switches. The second forward delay is the delay set by the local switch
and is used if the local switch becomes the root bridge.
SW2#show spanning-tree | include VLAN|Forward
VLAN0001
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay 15 sec
Forward Delay 15 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay 15 sec
Forward Delay 15 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay 15 sec
Forward Delay 15 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay 15 sec
Forward Delay 15 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay 15 sec
Forward Delay 15 sec
VLAN0010
VLAN0020
VLAN0030
VLAN0040
From this, it can be concluded that by using the default of 15 seconds in each intermediate state, it will
take a port a total of 30 seconds to transition from blocking to forwarding.
Because the forward delay timer is used twice in the calculation, the total time spent in the listening and
learning states by default will be 30 seconds. To reduce the total time the port stays in the listening or
learning states, the forward delay timer must be decreased. This reduction should be taken with care. The
default timer was set with the goal of providing enough time for all bridges in the STP network to
converge. The shorter the forward delay timer, the more likely it would be to form temporary bridging
loops if not all bridges have agreed about the STP topology.
This task requires ports to spend only 10 seconds in the listening and learning states. To do this the
forward delay timer must be modified. All switches in the STP network use the root bridge’s advertised
forward delay time as the agreed upon duration for their own forward delay timers. The spanning-tree
vlan 1-4094 forward-time command is used on the root bridge SW1 to change the default timer setting.
The exact value used requires some thought.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 117
The Forward Delay timer is used twice in the port transition process: to transition from listening to
learning and to transition from learning to forwarding. In order to spend a total of 10s in both listening and
learning states total, the forward delay timer should be set to 5 seconds. With this change, the port will
spend 5 seconds in the listening state and 5 seconds in learning state before forwarding, totaling 10
seconds as the task requires. The spanning-tree vlan 1-4094 forward-time 5 command implements this
change on the root bridge SW1:
On SW1:
SW1(config)#spanning-tree vlan 1-4094 forward-time 5
The show spanning-tree output below verifies the result from the configuration change. Notice now, the
forward delay timer now shows 5 seconds for all VLANs:
To verify the configuration:
SW1#show spanning-tree | include VLAN|Forward
VLAN0001
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay
Forward Delay
5 sec
5 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay
Forward Delay
5 sec
5 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay
Forward Delay
5 sec
5 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay
Forward Delay
5 sec
5 sec
Hello Time
Hello Time
2 sec
2 sec
Max Age 20 sec
Max Age 20 sec
Forward Delay
Forward Delay
5 sec
5 sec
VLAN0010
VLAN0020
VLAN0030
VLAN0040
All switches in the topology will inherit the new forward delay time set at the root bridge from the relayed
BPDUs they receive. As an example, the show spanning-tree root command below confirms SW2 accepts
the new forward delay time of 5s advertised by the root bridge SW1:
On SW2:
SW2#show spanning-tree root
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 118
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0001
24577 aabb.cc00.1f00
100
2
20
5
VLAN0010
24586 aabb.cc00.1f00
100
2
20
5
VLAN0020
24596 aabb.cc00.1f00
100
2
20
5
VLAN0030
24606 aabb.cc00.1f00
100
2
20
5
VLAN0040
24616 aabb.cc00.1f00
100
2
20
5
Root Port
--------Et1/1
Et1/1
Et1/1
Et1/1
Et1/1
Task 4
Ensure that if the current root bridge fails, SW2 becomes the new root bridge for all
VLANs.
As established previously, spanning-tree elects a root bridge by electing the switch that transmits a BPDU
with the lowest Bridge ID to be the root bridge. When the root bridge fails, the switch with the second
lowest Bridge ID will become the root bridge. Administrators can influence this decision just as with the
original root bridge selection. This can be done by either setting the priority to be higher than the current
root but lower than all other switches or using another macro command similar to the spanning-tree vlan
[vlan list] root primary command.
The spanning-tree vlan [vlan list] root secondary command is a one-time macro that sets the bridge
priority on the switch to 28,762. With all other switches set to default, the indicated priority value would
be lower than all other switches.
To complete the task, execute the spanning-tree vlan 1-4094 root secondary command on SW2 to
specify that SW2 acts as the root switch should the current root SW1 fail. However, a key point to note
here is that this command causes the switch that is configured to be the secondary root using this
command to always set its priority to 28,672 as shown below. This could result in SW2 becoming the root
since its priority is now lower than that of SW1’s if SW1’s priority was not set to a much lower value in the
second task.
On SW2:
SW2(config)#spanning-tree vlan 1-4094 root secondary
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 119
To verify the configuration:
SW2#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID
Priority
28673
Address
aabb.cc00.2000
This bridge is the root ! SW2 becomes the root
Hello Time
2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID
Priority
Address
Hello Time
Aging Time
28673 (priority 28672 sys-id-ext 1)
aabb.cc00.2000
2 sec Max Age 20 sec Forward Delay 15 sec
15 sec
SW2#show spanning-tree | include VLAN|priority
VLAN0001
Bridge ID
VLAN0010
Bridge ID
VLAN0020
Bridge ID
VLAN0030
Bridge ID
VLAN0040
Bridge ID
Priority
28673
(priority 28672 sys-id-ext 1)
Priority
28682
(priority 28672 sys-id-ext 10)
Priority
28692
(priority 28672 sys-id-ext 20)
Priority
28702
(priority 28672 sys-id-ext 30)
Priority
28712
(priority 28672 sys-id-ext 40)
This can be remedied by using the primary option with the spanning-tree vlan 1-4094 root primary
command on SW1 after trying to make SW2 the secondary root. As a result of this, the priority on SW1 is
now set to 24576 allowing it to regain its root status:
On SW1:
SW1(config)#spanning-tree vlan 1-4094 root primary ! Configures SW1 to
regain its root bridge status by setting a lower priority for itself
To verify the configuration:
SW1#show spanning-tree | include VLAN|priority
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 120
VLAN0001
Bridge ID
VLAN0010
Bridge ID
VLAN0020
Bridge ID
VLAN0030
Bridge ID
VLAN0040
Bridge ID
Priority
24577
(priority 24576 sys-id-ext 1)
Priority
24586
(priority 24576 sys-id-ext 10)
Priority
24596
(priority 24576 sys-id-ext 20)
Priority
24606
(priority 24576 sys-id-ext 30)
Priority
24616
(priority 24576 sys-id-ext 40)
Task 5
Ensure that SW2’s and SW3’s E1/2 interface is used as the root port for all VLANs. Do
not modify cost to achieve this.
The show spanning-tree root output on SW2 and SW3 below shows the E1/1 interface on these switches
as the root ports:
On SW2:
SW2#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- ---
Root Port
---------
VLAN0001
VLAN0010
VLAN0020
VLAN0030
VLAN0040
Et1/1
Et1/1
Et1/1
Et1/1
Et1/1
24577 aabb.cc00.1f00
24586 aabb.cc00.1f00
24596 aabb.cc00.1f00
24606 aabb.cc00.1f00
24616 aabb.cc00.1f00
100
100
100
100
100
2
2
2
2
2
20
20
20
20
20
5
5
5
5
5
On SW3:
SW3#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- --------VLAN0001
24577 aabb.cc00.1f00
100
2
20 5 Et1/1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 121
VLAN0010
VLAN0020
VLAN0030
VLAN0040
24586 aabb.cc00.1f00
24596 aabb.cc00.1f00
24606 aabb.cc00.1f00
24616 aabb.cc00.1f00
100
100
100
100
2
2
2
2
20
20
20
20
5
5
5
5
Et1/1
Et1/1
Et1/1
Et1/1
A root port on a switch is the one that receives the superior BPDU in comparison to the other ports on the
same switch. Root ports always point up the spanning tree towards the root bridge. A switch uses the
following algorithm to determine which port should become the root port:
1.
2.
3.
4.
Port with the least cost to reach the root (RPC)
Port that receives the BPDU with the lowest sender bridge ID (SBID)
Port that receives the BPDU with the lowest sender port ID (SPID)
Port with the lowest receiver port ID (RPID)
Note:
In the above, the RPC, SBID and the SPID values are included in a received configuration BPDU whereas the
RPID is not included in a configuration BPDU. This means, when a switch receives a configuration BPDU, in
order to determine a root port, the first three steps involve evaluating the values in a received
configuration BPDU. The RPID, which is the receiver's port ID is evaluated locally to determine a root port
should all other criteria tie.
All ports on switches have default port costs associated with them. These costs vary depending on the port
speed. For example, the default port cost for a 10 Mbps link for 802.1.D is 100. The total path cost to the
root on non-root switches is calculated by adding the port cost of an interface to the root path cost (RPC)
received in the configuration BPDUs.
In the lab topology, SW1 is the root bridge. Since its own cost to reach the root, which is itself, is 0, it sends
out configuration BPDUs with a root path cost or the RPC of 0. SW2 and SW3 receive this BPDU on their
E1/1-2 interfaces. They accept SW1’s BPDU as the superior BPDU making it the root bridge. They send
SW1’s BPDU out all of their other non-blocking ports. Before sending the BPDU out the other ports, SW2
and SW3 add their own cost to reach the root bridge to the total RPC reported in the received BPDU. In this
case, SW2 and SW3’s own cost of 100 to reach the root bridge SW1, is added to the cost of 0 advertised by
SW1 in its configuration BPDU to these switches. This results in a total cost of 100 (0 + 100). Using SW2 as
an example, this BPDU is sent out its E3/1-2, E4/1-2, and E5/1-2 interfaces towards SW3, SW4, and SW5
respectively.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 122
Because SW2 sends the BPDU out its interface towards SW3, SW3 receives two copies of the same BPDU
with different RPC values. (SW3 technically can receive a copy of the BPDU from SW4 and SW5, but these
BPDUs can be ignored in this explanation because they will be greatly inferior to the one received from
SW2 and SW1). SW3 adds its interface cost to the RPC received in the BPDU from SW2, 100 + 100 = 200,
and compares it to the BPDU received on all other ports, specifically the one sent from the root SW1 with a
cost of 100 (0 RPC advertised from the root plus the interface cost of 100) over its E1/1-2 interfaces.
Obviously, SW3 decides that the RPC through its interfaces towards SW1 is the best cost and it is this cost
that SW3 advertises in BPDUs towards other switches. At this point SW3 must choose which of those two
ports (E1/1 - E1/2) to mark as the root port.
The same process occurs on SW2 with respect to the BPDU received from SW3. Similar to SW3, SW2 must
choose between its two interfaces towards SW1 to be its root port.
The show spanning-tree detail command can be used to verify the cost to the root over different
interfaces. As an example, the show spanning-tree vlan 1 interface e1/1 detail and show spanning-tree
vlan 1 interface e3/1 detail is issued on SW2 below. The port path cost is the cost assigned to the port on
SW2. The designated path cost is the RPC received by the switch from its upstream designated port in
configuration BPDUs. The value here can be an indicator of whether or not this switch is directly connected
to the root bridge. If the root bridge is the directly connected designated port, the value will be 0. Any
other value indicates this switch is connected to a non-root switch.
On SW2:
SW2#show spanning-tree vlan 1 interface e1/1 detail
Port 6 (Ethernet1/1) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.6.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.10, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 159, received 4679
SW2#show spanning-tree vlan 1 interface e3/1 detail
Port 14 (Ethernet3/1) of VLAN0001 is designated forwarding
Port path cost 100, Port priority 128, Port Identifier 128.14.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 123
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 28673, address aabb.cc00.2000
Designated port id is 128.14, designated path cost 100
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 4888, received 5
In the above it was determined that SW2 and SW3 will choose one of their ports towards SW1 as root. The
Spanning-tree specification only allows a single root port to exist on a switch for any given instance of
spanning-tree. Thus, SW2 and SW3 need to determine which of the two ports connected to SW1 is
receiving the better BPDU.
As seen with the show spanning-tree detail output from SW2 and SW3 below, the cost to reach the root
over their E1/1 and E1/2 interfaces are both equal to 100 (Cost to the root = Port path cost + Designate
path Cost):
On SW2:
SW2#show spanning-tree vlan 1 interface e1/1 detail
Port 6 (Ethernet1/1) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.6.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.10, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 159, received 4828
SW2#show spanning-tree vlan 1 interface e1/2 detail
Port 7 (Ethernet1/2) of VLAN0001 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.7.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.11, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 148, received 4853
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 124
On SW3:
SW3#show spanning-tree vlan 1 interface e1/1 detail
Port 6 (Ethernet1/1) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.6.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.14, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 2
Link type is point-to-point by default
BPDU: sent 12, received 5046
SW3#show spanning-tree vlan 1 interface e1/2 detail
Port 7 (Ethernet1/2) of VLAN0001 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.7.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.15, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 0
Link type is point-to-point by default
BPDU: sent 2, received 5062
With the cost values being equal over the E1/1 and E1/2 interfaces, SW2 and SW3 need to move on to the
next tiebreaker to determine the root port between these interfaces. The next tie breaker calls to evaluate
the senders bridge ID, SBID in the received configuration BPDUs. In this case, the SBID in the BPDUs
received on the E1/1 and E1/2 interfaces are identical, meaning SW2 and SW3 will now have to use the
third tie breaker to determine the root port.
The third tie breaker compares the sender port ID, SPID, in the received configuration BPDUs. All ports on a
switch are assigned a port ID. The port ID is made up of two parts: Port priority which is a configurable
value, and port index which is the same as the SNMP ifindex value. When all else ties, the receiving switch
compares the SPIDs of the remote designated port that is included in the received configuration BPDUs.
The port that receives the lowest SPID is designated as the root port.
The show spanning-tree detail output can be used to verify the SPID. The output of this command refers to
SPID as the Designated port ID. The output below shows these values to be lower on the E1/1 interface on
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 125
SW2 and SW3 when compared to the E1/2 interfaces. With lower values being preferred with STP, the E1/1
interface on SW2 and SW3 finally get elected as the root port:
On SW2:
SW2#show spanning-tree vlan 1 interface e1/1 detail
Port 6 (Ethernet1/1) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.6.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.10, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 159, received 5177
SW2#show spanning-tree vlan 1 interface e1/2 detail
Port 7 (Ethernet1/2) of VLAN0001 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.7.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.11, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 148, received 5187
As we can see above, the Port ID over the E1/1 interface is 128.10 which is lower than the port ID of 128.11
over the E1/2 interface.
On SW3:
SW3#show spanning-tree vlan 1 interface e1/1 detail
Port 6 (Ethernet1/1) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.6.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.14, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 2
Link type is point-to-point by default
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 126
BPDU: sent 12, received 5437
SW3#show spanning-tree vlan 1 interface e1/2 detail
Port 7 (Ethernet1/2) of VLAN0001 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.7.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.15, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 0
Link type is point-to-point by default
BPDU: sent 2, received 5460
Port ID over the E1/1 interface is 128.14 which is lower than the port ID of 128.15 over the E1/2 interface.
The task requires SW2 and SW3 to use their E1/2 ports as root ports. One of the ways to achieve this is to
modify the cost values so as to make the path cost via E1/2 lower than that over E1/1. The task however
restricts modifying the cost. The next option would be to modify the configurable part of the SPID on the
root bridge SW1 so that the SPID in the BPDU received over the E1/2 interfaces on SW2 and SW3 is lower.
This is done with the spanning-tree vlan 1-4094 port-priority 64 command on the E2/2 and E3/2 interfaces
on SW1. As a result, SW2 and SW3 now designate their E1/2 interfaces as the root port and the E1/1
interfaces as alternate blocking:
Note: The spanning-tree port-priority value can be changed in increments of 16
On SW1:
SW1(config)#interface e2/2
SW1(config-if)#spanning-tree vlan 1-4094 port-priority 64
SW1(config)#interface e3/2
SW1(config-if)#spanning-tree vlan 1-4094 port-priority 64
On SW1:
SW1(config)#interface e2/2
SW1(config-if)#spanning-tree vlan 1-4094 port-priority 64
SW1(config)#interface e3/2
SW1(config-if)#spanning-tree vlan 1-4094 port-priority 64
On SW2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 127
After the above configurations on SW1, the port ID over the E1/2 interface is 64.11 which is lower than the
port ID of 128.10 over the E1/1 interface on SW2
SW2#show spanning-tree vlan 1 interface e1/1 detail
Port 6 (Ethernet1/1) of VLAN0001 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.6.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.10, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 159, received 5484
SW2#show spanning-tree vlan 1 interface e1/2 detail
Port 7 (Ethernet1/2) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.7.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 64.11, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 2
Link type is point-to-point by default
BPDU: sent 150, received 5557
On SW3:
After the above configurations on SW1, the port ID over the E1/2 interface is 64.15 which is lower than the
port ID of 128.14 over the E1/1 interface
SW3#show spanning-tree vlan 1 interface e1/1 detail
Port 6 (Ethernet1/1) of VLAN0001 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.6.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 128.14, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 2
Link type is point-to-point by default
BPDU: sent 12, received 5755
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 128
SW3#show spanning-tree vlan 1 interface e1/2 detail
Port 7 (Ethernet1/2) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.7.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 24577, address aabb.cc00.1f00
Designated port id is 64.15, designated path cost 0
Timers: message age 2, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 4, received 5779
Task 6
Ensure that SW5 uses its E3/1 port as the root port for VLANs 10 and 30. Do not
modify SW2 to achieve this.
As the topology stands now, SW5 designates its E2/1 interface as the root port for VLAN 10 and 30
towards the root switch SW1. The E3/1 interface is in a blocking state:
On SW5:
SW5#show spanning-tree vlan 10 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et2/1
Root FWD 100
128.10
P2p
Et2/2
Altn BLK 100
128.11
P2p
Et3/1
Altn BLK 100
128.14
P2p
Et3/2
Altn BLK 100
128.15
P2p
Et6/1
Desg FWD 100
128.26
P2p
Et6/2
Desg FWD 100
128.27
P2p
SW5#show spanning-tree vlan 30 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et2/1
Root FWD 100
128.10
P2p
Et2/2
Altn BLK 100
128.11
P2p
Et3/1
Altn BLK 100
128.14
P2p
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 129
Et3/2
Et6/1
Et6/2
Altn BLK 100
Desg FWD 100
Desg FWD 100
128.15
128.26
128.27
P2p
P2p
P2p
Using certain show commands helps understand why SW5 chooses E2/1 as its root port. First, using the
show spanning-tree vlan 10,30 interface e2/1 and show spanning-tree vlan 10,20 interface e3/1 outputs,
the cost to reach the root SW1 over these interfaces can be determined. The cumulative root cost is
calculated by adding the port path cost of the interface and the designated path cost over that interface.
Recall, the port path cost is the cost assigned to the interface whereas the designated path cost is the RPC
received by the switch from its upstream designated port in configuration BPDUs.
NOTE: SW5 may also receive BPDUs relayed from SW6, but this BPDU will be inferior to all other BPDUs
and as such is ignored in this explanation.
On SW5:
SW5#show spanning-tree vlan 10,30 interface e2/1 detail
Port 10 (Ethernet2/1) of VLAN0010 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.10.
Designated root has priority 24586, address aabb.cc00.1f00
Designated bridge has priority 28682, address aabb.cc00.2000
Designated port id is 128.22, designated path cost 100
Timers: message age 3, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 5, received 5747
Port 10 (Ethernet2/1) of VLAN0030 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.10.
Designated root has priority 24606, address aabb.cc00.1f00
Designated bridge has priority 28702, address aabb.cc00.2000
Designated port id is 128.22, designated path cost 100
Timers: message age 3, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 3, received 4988
SW5#show spanning-tree vlan 10,30 interface e3/1 detail
Port 14 (Ethernet3/1) of VLAN0010 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.14.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 130
Designated root has priority 24586, address aabb.cc00.1f00
Designated bridge has priority 32778, address aabb.cc00.2100
Designated port id is 128.22, designated path cost 100
Timers: message age 5, forward delay 0, hold 0
Number of transitions to forwarding state: 0
Link type is point-to-point by default
BPDU: sent 2, received 6043
Port 14 (Ethernet3/1) of VLAN0030 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.14.
Designated root has priority 24606, address aabb.cc00.1f00
Designated bridge has priority 32798, address aabb.cc00.2100
Designated port id is 128.22, designated path cost 100
Timers: message age 9, forward delay 0, hold 0
Number of transitions to forwarding state: 0
Link type is point-to-point by default
BPDU: sent 3, received 4847
Using this method of calculation, the RPC for VLANs 10 and 30 is 200 over the e2/1 and e3/1 interfaces on
SW5. With these cost values equal, SW5 uses the next tiebreaker to determine the root port, comparing
the sending switchs’ Bridge ID (SBIDs) in the received configuration BPDUs.
SW5 receives configuration BPDUs from SW2 and SW3. The BPDUs contain the SBID, which consists of the
priority and the MAC address, along with the Bridge ID of the current root bridge. Once again, because the
path costs tie between the two received BPDUs, SW5 will choose the port receiving the BPDU with the
lowest SBID.
In the above output, SW5 receives a BPDU on its E2/1 interface on VLAN 10 and 30 with the SBID priority
as 28682 from SW2. On its E3/1 interface, SW5 receives a BPDU with a SBID priority as 32798 from SW3.
These values are listed in the “Designated bridge has priority” section in the output. Because SW2’s BPDU
has a lower priority than SW3’s, SW5 places its E3/1 interface in blocking mode for both VLANs in
question.
NOTE: The ultimate determination for root port in this case is going to be the SPID. SW5 will choose the
BPDU received on its E2/1 interface over its E2/2 interface because SW2’s SPID over E2/1 is lower than
E2/2. The main focus on this task, however, is pointing out how the Bridge ID affects the decision-making
between the BPDU received from SW2 and the BPDU received from SW3.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 131
The task requires that SW5 designates its E3/1 interface as the root port for VLAN 10 and VLAN 30. One
way to do this would be to adjust SW3’s bridge priority to be lower than SW2. Doing so, however, would
violate the 4th task specifying that SW2 should be the secondary root should SW1 fail. In such a scenario,
SW3 with the lower bridge priority would be elected root bridge instead of SW2.
The easiest way to accomplish the task is to modify the costs such that the cost to reach the root over the
E3/1 interface is lower than that over the E2/1 interface for VLANs 10 and 30. The following configuration
shows the port cost is set to 50 (default 100) on the E3/1 interface on SW5 with the spanning-tree vlan
10,30 cost 50 command. On doing so, SW5 transitions the E3/1 interface to root and E2/1 to blocking as
evidenced by the debug spanning-tree events below.
On SW5:
Before changing the configuration:
SW5#debug spanning-tree events
Spanning Tree event debugging is on
SW5(config)#interface e3/1
SW5(config-if)#spanning-tree vlan 10,30 cost 50
STP: VLAN0010 new root port Et3/1, cost 150
STP: VLAN0010 Et3/1 -> listening
STP: VLAN0010 sent Topology Change Notice on Et3/1
STP[10]: Generating TC trap for port Ethernet2/1
STP: VLAN0010 Et2/1 -> blocking
STP: VLAN0030 new root port Et3/1, cost 150
STP: VLAN0030 Et3/1 -> listening
STP: VLAN0030 sent Topology Change Notice on Et3/1
STP[30]: Generating TC trap for port Ethernet2/1
STP: VLAN0030 Et2/1 -> blocking
SW5#show spanning-tree vlan 10,30 blockedports
Name
Blocked Interfaces List
-------------------- -----------------------------------VLAN0010
Et2/1, Et2/2, Et3/2
VLAN0030
Et2/1, Et2/2, Et3/2
Number of blocked ports (segments) in vlan 10,30: 6
SW5#show spanning-tree vlan 10,30 root
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 132
Root Hello Max Fwd
Vlan
Root ID
Cost Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- -----------VLAN0010
24586 aabb.cc00.1f00
150
2
20 15
Et3/1
VLAN0030
24606 aabb.cc00.1f00
150
2
20 15
Et3/1
! E3/1 now designated as the root port
SW5#u all
All possible debugging has been turned off
Task 7
Ensure that SW4 uses its E3/1 port as root port for VLANs 20 and 40. Do not modify
SW3 to achieve this.
The show spanning-tree vlan 20,40 output below shows the current root port for VLAN 20 and 40 on SW4
is its E2/1 interface:
On SW4:
SW4#show spanning-tree vlan 20 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et2/1
Root FWD 100
128.10
P2p
Et2/2
Altn BLK 100
128.11
P2p
Et3/1
Altn BLK 100
128.14
P2p
Et3/2
Altn BLK 100
128.15
P2p
Et6/1
Desg FWD 100
128.26
P2p
Et6/2
Desg FWD 100
128.27
P2p
SW4#show spanning-tree vlan 40 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et2/1
Root FWD 100
128.10
P2p
Et2/2
Altn BLK 100
128.11
P2p
Et3/1
Altn BLK 100
128.14
P2p
Et3/2
Altn BLK 100
128.15
P2p
Et6/1
Desg FWD 100
128.26
P2p
Et6/2
Desg FWD 100
128.27
P2p
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 133
The following determines SW4’s current root port selection. SW4 receives configuration BPDUs relayed
from SW2, SW3 and SW6. Among all the BPDUs received, the BPDUs from SW6 will be the most inferior
one due to higher cost to reach the root through SW6. The configuration BPDUs SW4 receives from SW2
and SW3 both result in an equal cost of 200 to the root SW1. With the cost tied, SW4 then uses the next
tie breaker of comparing the SBID to determine which BPDU is the most superior. Since the SBID of SW2 is
lower than the SBID of SW3, SW4 has to now consider which of the direct ports connected to SW2 it can
designate as the root port. At this point, SW4 uses the next tie breaker of comparing the SPID and
designates its E2/1 interface as the root port due to a lower SPID of SW2’s E4/1 interface.
The task requires ensuring that SW4’s E3/1 interface is designated as the root port. One of the ways this
can be achieved is to lower the BID of SW3, however the task restricts any changes from being made on
SW3 and similar to the previous task, doing so would violate the 4th task in the lab. So once again, the
easiest way to complete this task is by modifying the cost values such that the cost to reach the root
through SW4 over its E3/1 interface is lower than the cost to reach the root over its E2/1 interface. So, to
solve this task the interface level command spanning-tree vlan 20,40 cost 50 is configured on SW4’s E3/1
interface:
On SW4:
SW4(config)#interface e3/1
SW4(config-if)#spanning-tree vlan 20,40 cost 50
With the debug spanning-tree events turned on below, SW4 transitions the previously blocked E3/1
interface to a forwarding state for vlans 20 and 40. Notice the time taken from SW4 to transition the port
into a forwarding state from the blocking state is 10 seconds. This is a result of setting the forward delay
time to 5 seconds in task 3 of this section. The switch spends 5 seconds in the listening state, 5 seconds in
the learning state and then transitions to the forwarding state.
Note : The default settings would cause the switch to spend 15 seconds in each transitory state, resulting
in the switch taking 30 seconds to move from the blocking state to the forwarding state.
The show spanning-tree vlan 20 root and show spanning-tree vlan 40 root output further verifies E3/1 as
the new root port for VLAN 20 and 40:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 134
On SW4:
Port transitions from listening to forwarding in 10 seconds for VLAN 20
*Apr 13 11:28:14.376: STP: VLAN0020 new root port Et3/1, cost 150
*Apr 13 11:28:14.376: STP: VLAN0020 Et3/1 -> listening
*Apr 13 11:28:19.381: STP: VLAN0020 Et3/1 -> learning
*Apr 13 11:28:24.386: STP: VLAN0020 Et3/1 -> forwarding
For VLAN 40
*Apr 13 11:28:14.376: STP: VLAN0040 new root port Et3/1, cost 150
*Apr 13 11:28:14.376: STP: VLAN0040 Et3/1 -> listening
*Apr 13 11:28:19.381: STP: VLAN0040 Et3/1 -> learning
*Apr 13 11:28:24.386: STP: VLAN0040 Et3/1 -> forwarding
SW4#show spanning-tree vlan 20 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et2/1
Altn BLK 100
128.10
P2p
Et2/2
Altn BLK 100
128.11
P2p
Et3/1
Root FWD 50
128.14
P2p
Et3/2
Altn BLK 100
128.15
P2p
Et6/1
Desg FWD 100
128.26
P2p
Et6/2
Desg FWD 100
128.27
P2p
SW4#show spanning-tree vlan 40 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et2/1
Altn BLK 100
128.10
P2p
Et2/2
Altn BLK 100
128.11
P2p
Et3/1
Root FWD 50
128.14
P2p
Et3/2
Altn BLK 100
128.15
P2p
Et6/1
Desg FWD 100
128.26
P2p
Et6/2
Desg FWD 100
128.27
P2p
SW4#show spanning-tree vlan 20 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0020
24596 aabb.cc00.1f00
150
2
20
5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Root Port
--------Et3/1
Page 135
SW4#show spanning-tree vlan 40 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0040
24616 aabb.cc00.1f00
150
2
20
5
Root Port
--------Et3/1
This example showed how it can take a port up to 30s to transition from blocking to forwarding with
default timer settings. In the lab, this time period is reduced to 10s through forward delay timer
modifications. It should still be noted that, even at 10s, 802.1D is not a fast converging protocol, 10
seconds is a significant amount of time before restoring functionality and is the main drawback to timerbased convergence algorithms such as the one employed by traditional 802.1D Spanning-tree protocol.
Later on, in the lab, this deficiency is examined again when transitioning to 802.1w Rapid Spanning-tree
protocol, which utilizes a more event-based convergence system.
Task 8
Ensure that interfaces connected to non-switch hosts come online immediately.
Spanning-tree protocol, as mentioned early on, was invented to deal with the possibility of loops in the
switched network when multiple switches were connected by redundant links. To do so, spanning-tree
blocks redundant links based on a predetermined algorithm. This algorithm not only governs how switches
determine which redundant links to block but also what to do with links that are allowed to forward.
In 802.1D spanning-tree, ports that are deemed suitable for forwarding (ports that will not cause a loop),
transition from blocking → listening → learning → forwarding states. As stated in a task above, the port
will spend Forward Delay seconds in both the listening and learning states. The reasoning behind this
progression is that before a port moves to forwarding, it must be determined that doing so would not
cause a loop.
In the blocking state all traffic is discarded and only BPDUs are accepted (but not sent). The port then
transitions to the listening state where it is evaluating BPDUs that could possibly be received from another
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 136
switch. Next, the switch enters the learning phase where it learns MAC addresses from received data
traffic (still not forwarding the traffic) on the port. Finally, the port enters the forwarding state and normal
operation can begin.
These mechanisms work well for links connected between switches mainly because other switches are the
devices that can form the loops. The mechanisms are in place to allow time for BPDUs to progress
throughout the network and for all of the switches to synchronize the spanning-tree topology. The
mechanisms do not work well for the end hosts that are connected to the switches, nor are they
necessarily needed.
A switch will have two kinds of links, one to another switch and one to an end host. For the sake of this
explanation, an end host can be a router, PC, firewall, wireless access point, server, or any other device
that does not extend the Layer 2 broadcast domain between multiple switches. End hosts are the final
destinations for all inter-switch data traffic. Because end hosts do not extend the broadcast domain and
they are the destination for all inter-switch data traffic (they do not transit Layer 2 traffic), there is a low
probability that such ports will cause a loop in the forwarding state.
This low probability means the switch does not need to transition such ports from blocking to listening
because end hosts typically do not send BPDUs. It does not need to spend time in the learning state either
because the port will only learn the MAC address of the directly-connected end host. Logically, it is
feasible to transition such ports directly to forwarding instead of progressing through the blocking →
listening → learning → forwarding states.
In actuality, if the host has to wait the default 30 seconds before being allowed to forward traffic on the
LAN, it can delay or even break certain pre-boot tasks performed by the NICs of most end-hosts. The most
notable task being DHCP. DHCP is the protocol used by a host to acquire an IP address it can use on the
LAN for communication. If the switch port does not move from blocking to forwarding in enough time for
the host to receive a DHCP reply, some hosts will cease trying to obtain an IP address.
So, for such cases, a Cisco-proprietary STP optimization feature called portfast can be enabled on these
ports and this is what this task hints towards configuring. The portfast feature on SW4, SW5 and SW6 will
allow them to bypass the listening and learning states and transition their access ports immediately to a
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 137
forwarding state. This would result in providing immediate network connectivity to end devices for
external services such as DHCP. Without the portfast feature, end devices would have to wait for up to 30
seconds, the time taken for the access port to transition to the forwarding state from the blocking state.
The port fast feature can be enabled directly on an interface with the spanning-tree portfast edge
command or globally with the spanning-tree portfast edge default command. The difference between
these commands is that the interface-level command should be executed on all access ports by the
administrator. The global way of enabling the port fast feature automatically activates the port fast
feature on all access ports. Portfast can also be enabled on trunk links connected to end hosts such as
wireless autonomous or hybrid APs, datacenter hypervisors, or any other device that needs to receive
traffic from multiple VLANs using the spanning-tree portfast edge trunk command on the trunk port. Care
should be taken to ensure another switch is never mistakenly connected to the trunk port with portfast as
temporary bridging loops can occur.
Configuring host ports as portfast interfaces also carries another benefit. Once portfast is enabled, the
interface will not generate topology change notifications whenever the interface goes down. This is
important because host ports may shutdown repeatedly during the day as hosts come online and go
offline. Without portfast, each event would cause a topology change in the network, forcing all switches to
age out their MAC address tables prematurely, flooding unknown unicast traffic until MAC addresses are
relearned. Secondly, portfast-enabled interfaces do not age their MAC address entries in the CAM table
during a topology change event. The reasoning is since these ports connect to end hosts, those MAC
addresses will always be learned on the port. There is no need to flush the table only to relearn the exact
same information.
Since the lab topology does not explicitly ask to configure any access port, this task is solved by enabling
the portfast feature globally using the spanning-tree portfast edge default command on SW4, SW5 and
SW6. The show spanning-tree summary output can be used to verify the status of the feature as seen
below:
On SW4, SW5, and SW6:
SW4(config)#spanning-tree portfast edge default
%Warning: this command enables portfast by default on all interfaces.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 138
You should now disable portfast explicitly on switched ports leading to
hubs, switches and bridges as they may create temporary bridging loops.
To verify the configuration:
SWx#show spanning-tree summ | include Port
Portfast Default
Portfast Edge BPDU Guard Default
Portfast Edge BPDU Filter Default
is edge
is disabled
is disabled
a. If SW4 or SW5 detects a switch on these ports when they first come online, they
should process the BPDUs normally. Otherwise, it should not process received
BPDUs.
Ports configured with the portfast feature are supposed to be connected to end hosts. This is because it is
safe for interfaces connected to end hosts to immediately come online rather than waiting through the
listening and learning states. There are times, however, where portfast-enabled interfaces are connected
to another switch either by accident or on purpose. In such an event, the switch port will move directly
into forwarding state without transitioning properly to ensure there are no loops in the switched
network. This means temporary Layer 2 loops could exist in the network. In this case, it is desirable for
the interface to participate in STP if the portfast-enabled interface is connected to another switch.
The global BPDU Filter feature was created just for this purpose. The BPDU filter itself effectively disables
spanning-tree operation on a switch port. No BPDUs will be sent or processed on a BPDU-filter-enabled
port. BPDU filter is enabled on a per-port basis by using the spanning-tree bpdufilter enable command in
interface configuration mode. Enabled globally using the spanning-tree portfast edge bpdufilter default
command in global configuration mode, however, BPDU filter changes its operation in the following ways:
1. It is only enabled on portfast-enabled interfaces
2. It first waits a period of time before activating on the interface
a. If a BPDU is received on the portfast-enabled interface during the waiting period, the BPDU
filter is disabled and the port continues to process BPDUs.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 139
b. If a BPDU is not received on the portfast-enabled interface during the waiting period, the
port is allowed to transition directly to forwarding state. BPDUs will cease to be sent out of
the port unless one is received.
When enabled globally, BPDU filter only operates on portfast-enabled interfaces. Once a portfast-enabled
interface first comes online, BPDU filter allows the port to continue sending and receiving BPDUs for 10
hello intervals. The result is the switch will send 11 hello packets in total, one initially and then one for
each hello interval BPDU filter waits before activating. If no BPDUs are received, the port is allowed to
jump directly to the forwarding state. The switch port also ceases to send any new BPDUs out of the
BPDU-filter-enabled port unless a BPDU is first received. If a BPDU is received during the initial 11 BPDU
timespan, the BPDU filter and portfast is disabled. The port evaluates the BPDUs and transitions to the
listening and learning states before moving to forwarding based on the exchange of BPDUs like normal.
This operation works because a properly functioning spanning-tree-enabled switch will always send out
BPDUs when its port first comes online.
To solve subtask A, the BPDU filter feature should be enabled globally using the spanning-tree portfast
edge bpdufilter default command on SW4 and SW5. Once enabled, BPDU filter operation will take place
as described above. BPDU filter default configuration can be verified using the show spanning-tree
summary command as shown below:
On SW4 and SW5:
SWx(config)#spanning-tree portfast edge bpdufilter default
SW4#show spanning-tree summary | include Port
Portfast Default
Portfast Edge BPDU Guard Default
Portfast Edge BPDU Filter Default
is edge
is disabled
is enabled
SW5#show spanning-tree summary | include Port
Portfast Default
Portfast Edge BPDU Guard Default
Portfast Edge BPDU Filter Default
CCIE by Narbik Kocharians
is edge
is disabled
is enabled
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 140
b. If SW6 detects a switch on one of these ports, it should disable the port.
The issue with configuring portfast alone on a switch is that the portfast-enabled interface comes online
immediately. These ports are supposed to lead to end hosts and not other switches in the network. The
ports will, however, still process received BPDUs. Such behavior can allow rogue switches or malicious
users to hijack the spanning-tree topology by crafting spoofed BPDUs claiming their device is the root
bridge.
The BPDU filter feature helps mitigate it by telling the port to ignore all BPDUs and not to send out its own
BPDUs if a BPDU is received on an interface. This comes at an inherent risk. If the intended portfast
interface receives a BPDU, that means there is another spanning-tree-enabled device connected to the
port. This could be either another switch, a malicious user, or a host with two NICs connected to separate
wall jacks that is either intentionally or unintentionally bridging traffic between the two ports. In either
case, there is a problem with the network since that particular port has been designated as a port towards
an end host that should not cause loops in the network. If this point is not true, a loop can be formed in the
network.
Cisco has another feature designed to take a more aggressive approach to solving this problem. That
feature is known as BPDU guard. When BPDU guard is enabled on a port, if the configured port receives any
BPDUs, that port is shut down and placed into an err-disabled state. This state does not clear unless the
port is shut down and brought back up again.
Taking this approach protects the network from issues and also can serve as an alert of a misconfiguration
in the network. BPDU guard is enabled using the interface-level command spanning-tree bpduguard
enable. Like the BPDU filter, BPDU guard can also be enabled globally on the switch port. Once enabled
globally using the spanning-tree portfast edge bpduguard default command, BPDU guard only takes effect
on portfast-enabled interfaces. If a BPDU is received on any portfast enabled interface, that port is put in
err-disabled state and is immediately shut down.
It is worth mentioning the interaction between BPDU guard and BPDU filter when both are enabled on an
interface. If port-level BPDU guard and BPDU filter are configured on an interface, BPDU filter will take
precedence over BPDU guard. The interface will not process received BPDUs, thus BPDU guard will not shut
down the interface. The BPDU guard configuration is effectively rendered unnecessary.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 141
If both features are enabled globally, however, the two features mesh very well. BPDU filter will prevent
the port from sending BPDUs on the interface, however if a BPDU is received, BPDU guard will shut it down.
This configuration is good for interfaces that should lead to end hosts where it is not desirable to send out
BPDUs but if one is received the port should be deactivated for investigation.
This task requires that when a portfast enabled port on SW6 receives a BPDU, the port should be disabled
instead of functioning as a non edge port. BPDU guard will be enabled globally on SW6 to meet this
requirement with the spanning-tree portfast edge bpduguard default command shown below:
On SW6:
SW6(config)#spanning-tree portfast edge bpduguard default
SW6#show spanning-tree summary | include Port
Portfast Default
Portfast Edge BPDU Guard Default
Portfast Edge BPDU Filter Default
is edge
is enabled
is disabled
*NOTE*: The show interface status err-disabled command can be used to display any interface that has an
err-disabled state.
Task 9
Ensure that SW6 is able to fully utilize redundant links between neighboring switches.
Use a Cisco-specific approach to solve this.
This task aims to configure the mentioned switches such that multiple redundant links between them can
be utilized. This is a hint towards using EtherChannel bundling. In an etherchannel, the switch takes
multiple links and bundles them into one logical link. The logical link is called the port channel interface.
Once bundled, the switch will send traffic outbound across the individually bundled links based on a loadbalancing method.
When configuring etherchannels it is important that both devices on either side of the link agree that the
links should be bundled. The reason is each device may send frames from the same ethernet source MAC
address across different links. If the far-end switch has not properly bundled the link, it may cause MAC
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 142
address flapping on the far-end switch. Additionally, loops could form because STP BPDUs are only sent
out of one link in the bundle to the far-end switch. This means the far-end switch would only receive a
BPDU on one of its ports, making it assume the rest of the bundled ports are not connected to a
neighboring bridge. This assumption causes the far-end switch to set all of those same ports into
designated state. In this case, traffic can be looped from the local switch (configured with an
etherchannel bundle) and the far-end switch (not configured with an etherchannel bundle).
To help keep EtherChannel configurations consistent, two main protocols exist, standards-based LACP
and cisco-proprietary PAgP. If the EtherChannel is configured to run one of these protocols, messages
are exchanged between the switches that ensure consistent configuration and prevent the scenario
above. If misconfiguration is detected, the links will not be bundled and are kept as independent links.
Port channels will be created between SW4 - SW6 and SW5 - SW6 using PAgP since the task specifically
asks to use a Cisco specific approach. PAgP can be enabled on the links using the channel-group
{number} mode { desirable | auto } command. If enabled with the desirable option, the switch will send
PAgP frames to the far-end switch in an attempt to bring up the etherchannel. If enabled with the auto
option, the switch will wait to receive PAgP frames from the far-end switch before forming the bundle.
After entering the configuration commands, the switch creates a logical Port-Channel interface. The portchannel interface will replicate all future configurations applied to it to the member interfaces.
When configuring etherchannels it is best to follow the following procedures:
Step 1: Use the default interface command for all the interfaces that are to be bundled up into the same
port channel. The default interface command resets the interface back to their default values.
Additionally, for ease of configuration, the default interface range command can be used to reset
multiple interfaces to their default state.
Step 2: Configure the EtherChannel by issuing the channel-group channel-number mode command to the
physical interfaces. This will result in automatic port-channel interface creation. The channel-number
value does not have to match on both sides.
Step 3: Configure the trunk related parameters directly on the port-channel interface configuration mode
Step 4: Reset the ports in the group by first issuing the shutdown command followed by the no
shutdown command.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 143
Because the trunking ports have already been configured in earlier in the lab, only step 2 from the above
is configured in the output below:
On SW6:
SW6(config)#interface range e4/1-2
SW6(config-if-range)#channel-group 4 mode desirable
SW6(config)#interface range e5/1-2
SW6(config-if-range)#channel-group 5 mode desirable
On SW4:
SW4(config)#interface range e6/1-2
SW4(config-if-range)#channel-group 4 mode desirable
On SW5:
SW5(config)#interface range e6/1-2
SW5(config-if-range)#channel-group 5 mode desirable
The show EtherChannel summary output on the switches can be used to confirm the status of the port
channel with the SU indicating a in use Layer 2 bundle:
On SW6:
SW6#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
N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
A - formed by Auto LAG
Number of channel-groups in use: 2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 144
Number of aggregators:
2
Group Port-channel Protocol
Ports
------+-------------+-----------+-------------------4
Po4(SU)
PAgP
Et4/1(P)
Et4/2(P)
5
Po5(SU)
PAgP
Et5/1(P)
Et5/2(P)
SW4#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
N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
A - formed by Auto LAG
Number of channel-groups in use: 1
Number of aggregators:
1
Group Port-channel Protocol
Ports
------+-------------+-----------+-------------------4
Po4(SU)
PAgP
Et6/1(P)
Et6/2(P)
On SW5:
SW5#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
N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 145
w - waiting to be aggregated
d - default port
A - formed by Auto LAG
Number of channel-groups in use: 1
Number of aggregators:
1
Group Port-channel Protocol
Ports
------+-------------+-----------+-------------------------------------5
Po5(SU)
PAgP
Et6/1(P)
Et6/2(P)
Task 10
Ensure that SW6’s interface toward SW5 is used as the root port for all VLANs. If the
link between SW5 and SW6 goes down, SW6 should immediately switch to using its link
toward SW4.
After creating the port channel interfaces in the above task, the show spanning-tree root port command
output is shown below. As seen, port channel 4 connected to SW4 is designated as the root port by SW6
for VLANs 1, 20 and 40. Port channel 5 is designated as the root port for all other VLANs:
On SW6:
SW6#show spanning-tree root port
VLAN0001
VLAN0010
VLAN0020
VLAN0030
VLAN0040
Port-channel4
Port-channel5
Port-channel4
Port-channel5
Port-channel4
SW6 designates its port-channel 4 interface as the root port because of a lower root path cost over this
interface. This can be calculated by observing the show spanning-tree detail output.
This task requires the EtherChannel link to SW5 to be designated as the root port. This can be achieved by
ensuring that the cost to reach the root over the port-channel 5 is lower than that cost to reach the root
over the port-channel 4 with the spanning-tree vlan 1-4094 cost 5 command on SW6:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 146
On SW6:
SW6(config)#interface port-channel5
SW6(config-if)#spanning-tree vlan 1-4094 cost 5
SW6#show spanning-tree root port
VLAN0001
VLAN0010
VLAN0020
VLAN0030
VLAN0040
Port-channel5
Port-channel5
Port-channel5
Port-channel5
Port-channel5
The show spanning-tree root port command verifies the same as seen above. Port channel 5 is now the
root port for all VLANs as the task desires.
The task then hints towards configuring the uplinkfast feature on SW6. In the event of a link failure on the
root port, the switch must transition one of its blocking ports to be the new root port through the
Listening and Learning states before it can become fully operational and move to forwarding. This process
can take up to 30 seconds (with default timers).
If the switch is guaranteed to be a leaf node switch, meaning no other switch uses it to transit to the root,
there is little reason to move the new root port through the listening and learning states. The switch can
bring its alternate connection to the root bridge up immediately.
Uplinkfast is a feature that can speed up this process by making note of all blocking ports on the switch
that can be used as alternatives to the root bridge. This means the blocking ports are the redundant uplink
ports leading to the root bridge. It calculates the best of these ports and uses it as a spare in case the
current root port fails. When the root port fails, uplinkfast can immediately bring the new root port up
without transitioning it from the blocking to the listening and then the learning states that takes 30
seconds.
Uplinkfast is enabled globally for the entire switch with the spanning-tree uplinkfast command. After
doing so, the switch will automatically set its priority and port cost values artificially high in an attempt to
discourage any other switch in the network from using it as a transit switch. The show spanning-tree
summary | include Uplink command can be used to verify the uplink status:
On SW6:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 147
SW6(config)#spanning-tree uplinkfast
SW6#show spanning-tree summary | include Uplink
UplinkFast
is enabled
Task 11
Ensure that SW3’s interfaces is designated on the SW2/SW3 link for all VLANs.
As we’ve seen so far, after electing the root bridge, each non-root switch must determine its root port, the
port that leads directly to the root bridge. This is done by comparing the path costs for all links in the STP
network leading to the root. The Root bridge originates BPDUs with a cost of 0 out of all of its ports and
this cascades down to the non-root switches. They receive this BPDU and relay it to other switches, adding
their own cost to the root to the BPDU. The switch gathers all received BPDUs on all ports and selects the
port receiving the lowest cost as Root Port.
After electing the root bridge and root ports, the remaining switches need to determine on which nonroot ports they should act as the Designated Bridge. The designated bridge in spanning-tree is the switch
that is designated to relay BPDUs received from the root, downstream towards leaf node switches. They
also are responsible for forwarding data traffic upstream towards the root and downstream from the root
to leaf node switches. These ports are called Designated Ports.
NOTE: In a normal 802.1D STP implementation, only Designated Ports forward BPDUs.
The Designated Bridge is elected using the following criteria:
1. Lowest Root Path Cost to the Root Bridge
2. Lowest Sender Bridge ID
3. Lowest Sender Port ID
Observing just the show spanning-tree vlan 1 output on SW2 and SW3 as an example, the current
designated ports on the link between SW2 - SW3 is SW2’s E3/1 - 2 interfaces. The E2/1 - 2 interfaces on
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 148
SW3 are in a blocking state. This simply means, SW2 is the designated bridge on the SW2 - SW3 segment
for VLAN 1 and for all other VLANs.
Both SW2 and SW3 have a cost of 100 to reach the root bridge SW1. With the cost value equal, SW2 and
SW3 use the second tie breaker of the election criteria to determine the designated bridge. Since SW2 has
a lower bridge ID, it is elected as the designated bridge on this segment and designates its interfaces
connected to SW3 as designated ports:
On SW2:
SW2#show spanning-tree vlan 1 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et1/1
Altn BLK 100
128.6
P2p
Et1/2
Root FWD 100
128.7
P2p
Et3/1
Desg FWD 100
128.14
P2p
Et3/2
Desg FWD 100
128.15
P2p
Et4/1
Desg FWD 100
128.18
P2p
Et4/2
Desg FWD 100
128.19
P2p
Et5/1
Desg FWD 100
128.22
P2p
Et5/2
Desg FWD 100
128.23
P2p
On SW3:
SW3#show spanning-tree vlan 1 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et1/1
Altn BLK 100
128.6
P2p
Et1/2
Root FWD 100
128.7
P2p
Et2/1
Altn BLK 100
128.10
P2p
Et2/2
Altn BLK 100
128.11
P2p
Et4/1
Desg FWD 100
128.18
P2p
Et4/2
Desg FWD 100
128.19
P2p
Et5/1
Desg FWD 100
128.22
P2p
Et5/2
Desg FWD 100
128.23
P2p
The task specifies to ensure that SW3 is elected as the designated bridge on the segment for all VLANs.
Since both SW2 and SW3 have the same cost to the root switch, this task can be solved by modifying the
root cost on SW3 such that it is lower than the root cost on SW2 making SW3 the designated bridge on the
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 149
segment. This can be done by modifying the port cost on SW3’s current root port, E1/2, with the spanningtree cost 50. The output below shows the port cost modification on SW3 and the “show spanning-tree
vlan 1” output now confirms that SW3 is the designated bridge on the segment. Omitting the vlan number
in the spanning-tree cost command sets the port cost to 50 for all VLANs on the switch. This results in
SW3 becoming the designated bridge for the SW2 - SW3 segment for ALL VLANs as the task desires:
On SW3:
SW3(config)#interface e1/2
SW3(config-if)#spanning-tree cost 50
SW3#show spanning-tree vlan 1 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et1/1
Altn BLK 100
128.6
P2p
Et1/2
Root FWD 50
128.7
P2p
Et2/1
Desg FWD 100
128.10
P2p
Et2/2
Desg FWD 100
128.11
P2p
Et4/1
Desg FWD 100
128.18
P2p
Et4/2
Desg FWD 100
128.19
P2p
Et5/1
Desg FWD 100
128.22
P2p
Et5/2
Desg FWD 100
128.23
P2p
On SW2:
SW2#show spanning-tree vlan 1 | begin Interface
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----Et1/1
Altn BLK 100
128.6
P2p
Et1/2
Root FWD 100
128.7
P2p
Et3/1
Altn BLK 100
128.14
P2p
Et3/2
Altn BLK 100
128.15
P2p
Et4/1
Desg FWD 100
128.18
P2p
Et4/2
Desg FWD 100
128.19
P2p
Et5/1
Desg FWD 100
128.22
P2p
Et5/2
Desg FWD 100
128.23
P2p
It’s important to mention at this point that this task could also have been solved by setting the priority
value on SW3 to something lower than SW2’s priority. By resetting the priority on SW3 to a value lower
than SW2, SW2 would no longer be the secondary root bridge. This however would violate task 4 that
requires SW2 to always be the secondary root bridge and take over as the root if the current root SW1
were to fail.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 150
Task 12
Ensure that SW4 and SW5 can recover from an indirect link failure within 10 seconds.
Do not modify spanning-tree timers.
An indirect failure in STP is the loss of a root port for another switch that is not the local switch. Such a
failure is detected whenever STP receives an inferior BPDU on any port. This is a result of the process that
occurs whenever a switch loses connectivity to the root bridge. The switch experiencing the failure will
begin to announce itself as the root bridge out of all of its ports. Consider the following topology for a
better understanding of this process:
In the topology above, SW1 is the current root bridge. Link 1 on SW2 and Link 2 on SW3 are their current
root ports respectively. Following details on what happens when SW2 loses its current root port, link 1:
1. On losing its root port towards SW1, SW2 starts considering itself as the root. This is because it
does not receive any BPDUs relayed from SW3. SW3’s port towards SW2 is blocking and blocking
ports do not send any BPDUs
2. Claiming itself to be the root, SW2 now begins to send its BPDU to SW3. SW3 considers this to be
an inferior BPDU to the BPDU it has stored on its blocking port. This causes SW3 to ignore the
inferior BPDU from SW2 till the stored BPDU on the blocking port ages out. BPDUs age out in the
Max Age - Message Age seconds in STP.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 151
3. After the BPDU expires in the Max Age - Message Age seconds, the blocking port (link 3) on SW3
transitions to the listening state.
4. SW3 can now start sending the superior BPDUs from SW1 to SW2 on its link 3
5. SW2 receives this BPDU from SW3. Since the received BPDU is superior than the one SW2
generates, SW2 stops sending its own BPDU and moves its port towards SW3 from listening →
learning → forwarding state.
As we see in the above, the convergence after an indirect link failure took Max Age - Message Age seconds
(20 seconds at the first non-root switch and then decremented by 1 on every non-root switch
downstream) plus the forward delay time (30 seconds). During this period, the end devices face network
outage.
So using traditional STP, the switch receiving the inferior BPDU would have to wait for roughly 20 seconds
before transitioning its port or recalculating the STP topology. The Backbonefast functionality allows a
switch to bypass this delay in case of indirect link failures as in the example above. This is what the task
expects to be configured.
The backbonefast functionality is able to bypass the max age delay by:
1. Detecting a link failure as soon as possible by tracking inferior BPDUs received on a blocking port
2. Immediately checking the validity of the current superior BPDU
The above is made possible by implementing another Cisco proprietary process called the Root Link Query
(RLQ). Referring back to the example, the following happens with the backbonefast feature activated on
all the switches in the switched network:
1. On losing its root port on link 1 towards SW1, SW2 considers itself to be the root, generates BPDUs
and forwards them out its designated port to SW3
2. On receiving this inferior BPDU, the backbonefast functionality on SW3 is triggered. SW3 needs to
determine if the superior BPDU on its blocking port is still valid. If so, then SW3 can proceed to
bypass the max age delay time and immediately age out the stored BPDU on its blocking port.
3. For this purpose, SW3 sends an RLQ request out of all its non-designated ports. This means, SW3
sends the RLQ request to SW1 out its root port on link 2. SW1 receives this and since it is still the
current root bridge, it responds with an RLQ response.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 152
4. On receiving the RLQ response, SW3 is now able to confirm that the inferior BPDU received from
SW2 is wrong and invalidates it. It now immediately ages out the BPDU on the port and relays the
superior BPDU to SW2.
5. SW2 receives this BPDU from SW3. Since the received BPDU is superior than the one SW2
generates, SW2 stops relaying its own BPDU and moves its port towards SW3 from listening →
learning → forwarding state.
The RLQ request is basically sent to check the connectivity to the root bridge. It contains the BID of the
switch the sending switch believes to be the root. If the receiving switch is the root, and the owner of the
BID indicated in the RLQ request, it responds with a RLQ response. If the receiving switch is not the root,
the roots BID it knows of is the same as the one indicated in the RLQ request, this switch forwards the
query to the root.
Backbonefast is configured using the spanning-tree backbonefast and should be enabled on all the
switches because backbonefast requires the use of RLQ request and reply mechanisms. This is shown in
the configuration below. The show spanning-tree summary command output can be used to verify the
same:
Note: Task 3 of this section reduced the forward delay time from 30 seconds to 10 seconds. So, for this
lab, when the backbonefast feature is enabled, the switches will only spend 10 seconds (5 seconds in
listening and 5 seconds in learning) to recover from an indirect failure:
On All Switches:
SW6(config)#spanning-tree backbonefast
To verify the configuration:
SWx#show spanning-tree summary | include Back
BackboneFast
is enabled
Task 13
Ensure that SW2 only allows its ports toward SW1 to become root ports.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 153
This task requires configuring the Root Guard feature on SW2’s non-root ports.
In the same way a non-designated port receiving an inferior BPDU causes a topology change event, if any
port receives a superior BPDU, a topology change event will occur. In particular, this will cause the switch
to re-evaluate the location of its root port. This can be extremely devastating to the STP environment in
certain situations.
The Root Guard feature is designed to mitigate this threat. When a port is configured with Root Guard it
is automatically put in a root inconsistent state whenever it begins to receive superior BPDUs. This is
similar to the listening state where no traffic is forwarded through the port but BPDUs are still processed
and recieved. When the superior BPDUs cease, the port is put back into normal forwarding state by
transitioning it through the transient listening and learning states.
This feature is best deployed on designated ports on the switch on a per port basis. Designated ports are
ports that face away from the root bridge and as such should never become root ports.
To complete this task, configure spanning-tree guard root on all designated ports on SW2 as follows:
On SW2:
SW2(config)#interface range e4/1-2,e5/1-2
SW2(config-if-range)#spanning-tree guard root
*NOTE* Do not forget to reset the switch configurations to initial
configurations upon completing this exercise.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 154
802.1w Per-VLAN Rapid Spanning Tree Protocol
So far, we have explored the processes and functionality of traditional Spanning Tree
Protocol (also known as 802.1D). The original intent of 802.1D was to ensure that loopfree
paths exist in a Layer 2 switched network where redundant links are utilized. 802.1D
in its base form accomplishes this goal, but it does so at a price: convergence time.
802.1D utilizes timer-based convergence mechanics, which means ports must receive and
evaluate BPDUs to determine the root bridge.
The winning BPDU is stored by each port and relayed out all designated ports on the
switch until it is refreshed by the reception of the same BPDU on one of the switch’s
non-designated (blocking or root) ports. If a port does not receive a BPDU within the
Max Age time, the BPDU is aged out, and the topology reconverges. Furthermore, a port
that transitions from blocking to forwarding must first pass through listening and learning
states.
The entire convergence process for 802.1D, with default timers, can take up to 50 seconds
(20 seconds for Max Age time and 30 seconds for transitioning between listening and
learning states). As mentioned earlier in the lab, this is a considerable amount of downtime
for a modern network. It interferes with host operations such as acquiring a network
address to use for data communication.
Recognizing this inefficiency, the IEEE developed the 802.1w standard, which is also
called the Rapid Spanning Tree Protocol, or RSTP. The goal of RSTP is to drastically
reduce the amount of time it takes a network to converge during a convergence event and
whenever a switch is newly joined to a network. To do so, RSTP makes a few changes to
the 802.1D mechanics:




BPDUs are sent by all switches independently of reception of the root bridge’s
BPDU.
Listening and learning states are combined into a single learning state.
Port roles more clearly define what function a specific port plays in the network.
Timer-based convergence is replaced by a proposal/agreement process.
In 802.1D, switches do not originate BPDUs. Instead, they relay the received superior
BPDU from their root port out their designated ports. This superior BPDU is first originated
by the root bridge and acts as the heartbeat of the spanning tree. 802.1w modifies
this behavior. All RSTP-compliant switches generate their best stored BPDUs out
all of their designated ports at each hello interval, regardless of whether or not one was
received on the root ports. This transforms the BPDU from being a measurement of the
activity of the root bridge to being a keepalive between two bridges.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 155
This modification of BPDU generation means RSTP can determine if a neighboring switch is
active, based on when it last received a BPDU from the neighboring switch. If three Hello
intervals of BPDUs are missed (2-second intervals, for 6 seconds total), the switch can
immediately act. For blocking ports, that action is to become designated and send its own
BPDU. Thus, in order for a blocking port to remain in the blocking state, it must continue to
receive superior BPDUs from its upstream designated port.
In addition, the port states were revised. As mentioned earlier in 802.1D, there is little
difference
between a port that is blocking and a port that is listening or learning. In each of
these states, one of three actions is being performed:



The port is not forwarding traffic (that is, it is discarding traffic).
The port is learning about the STP topology while not forwarding traffic.
The port is learning MAC addresses while not forwarding traffic.
The first two actions correspond to the port refusing to process data frames even to the
point where MAC addresses are not being learned over the ports. Instead, state information
about the spanning-tree topology is being evaluated. These two functions fall within
the purview of the blocking and listening states of the original 802.1D. In 802.1w, they
are combined into a simple discarding state to signify that data traffic is being discarded
while spanning-tree BPDUs are still being processed. The last point corresponds to
the switch processing MAC address information to build MAC address tables on the
interfaces—a function of the learning state. This function was deemed necessary and has
been retained as the learning state in RSTP.
With these modifications, RSTP possesses only three states: discarding, learning, and
forwarding. These states describe what the port is actively doing but do not describe
what function in the spanning-tree topology these ports serve. This distinction is necessary
to allow rapid convergence in special circumstances. For this, RSTP utilizes
unused fields in the 802.1D BPDU (the flags field) to carry the port state and new port
roles describing both what action the port is taking and what role that port has in the
spanning-tree topology.
The port roles are:




Root: The port that receives the best BPDU of all BPDUs received by the local
switch
Designated: The port that sends the best BPDU on its LAN segment
Alternate: The port that receives a superior BPDU on the LAN segment; it is a
potential replacement for the root port
Backup: The port that receives the superior BPDU of the local switch’s own
designated
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 156
port; it is a potential replacement for the switch’s own designated port
Of all of the states, root and designated are the same and correspond to the root and
designated states in 802.1D. Alternate and backup ports are synonymous with blocking
ports in 802.1D, but their roles more clearly define where the port lies in the spanning tree.
An alternate port is a port that receives a superior BPDU from another bridge that is not the
best BPDU the switch has heard. Such ports provide alternative paths to the current root
bridge.
A backup port is a port that is self-looped back to the sending local switch. This port
could be connected to the same Layer 2 segment that does not speak Spanning Tree
Protocol. For example, if a switch is connected to a set of hosts through a hub, the hub
echoes all received frames out all ports except the port on which the frames were originally
received. For redundancy, the switch could connect to the hub through two ports.
If such a situation occurs, the BPDU sent by the switch on port A connected to the hub
would be echoed and received on port B, connected to the same hub. If port A is
determined to have the superior BPDU, port B would have the backup role because it
provides a redundant path to a LAN segment that does not lead back to the root bridge.
A port in 802.1w can be in any mixture of states and roles. For instance, a port can be
in the designated discarding role/state, which means it is a port that the switch believes
should be designated but has not transitioned to forwarding. This fact is important for
RSTP’s convergence algorithm.
In 802.1D, convergence is based on a timer-driven state machine. When a switch comes
online, it sends BPDUs claiming to be root. When it receives a superior BPDU, the ports
must transition from blocking, to listening, to learning, and finally to forwarding, based
on the Forward Delay timer (which defaults to 15 seconds, for 30 seconds total). If a
switch were to lose connection to the root port, it would announce itself as root toward
its neighbors. The neighbors would ignore this information for the Max Age period
(which is 20 seconds by default) before reacting to the topology change. The goal is to
allow the network to converge before a port is placed into the forwarding state.
802.1w does not use the same process as 802.1D but uses a newer proposal and
agreement process that goes as such:
1. A new link port on a switch tries to move from the blocking state to the forwarding
state.
2. The port receives a superior BPDU from the root bridge.
3. All other non-edge ports are blocked on the local switch.
4. Once all other switch ports are blocked, the local switch authorizes the root switch
to put its port into the forwarding state.
5. The same process occurs on all of the local switch’s remaining non-edge ports.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 157
In step 1, the new link initializes in the designated discarding state. It exchanges BPDUs
with the current root’s port (which is also in the designated discarding state). During this
time, both switches send a BPDU with the proposal bit set as an indication that they
want their ports to become the designated port on the segment. Upon receipt of the
superior BPDU at step 2, the local switch knows where its root port lies.
In step 3, the switch must ensure no loops can occur in the network based on this new
information. To do so, it places all of its non-edge ports into the discarding state; this is
called synchronization. Throughout this process, the root switch’s port is still in the
designated
discarding state.
At step 4, the local switch tells the root switch, through a BPDU with the agreement flag
set, that the root switch’s port can be moved to the designated forwarding state. This
happens because the local switch has blocked all of its other non-edge ports, preventing
any bridging loops.
At step 5, the local switch sends a BPDU with the proposal bit set out all of its remaining
designated discarding ports to start the rapid convergence process with other potential
spanning-tree bridges downstream from the root. Step 5 repeats the proposal/agreement
process with each switch to which the local switch has a direct connection. The same
process occurs: The switches exchange proposal BPDUs, the losing switch enters the
synchronization state, and it informs the designated switch it can move its port to the
designated forwarding state. In this way, the synchronization process flows downstream
from the root to the edge of the network.
This process relies heavily on the switch determining which ports are edge ports and
which are non-edge ports. RSTP keeps track of this by assigning an edge variable and link
type status to each switch port. The edge variable indicates whether or not the port leads
to an end host or sits at the edge of the network. Such ports do not connect to other
switches and should not receive BPDUs. If an edge port receives a BPDU, it loses its edge
status. Edge ports are allowed to immediately transition to a forwarding state; this is similar
to the spanning-tree PortFast feature.
Link type refers to whether or not the switch port can use rapid transitions, as previously
indicated. There are two link types: point-to-point and shared. A point-to-point link is
connected to exactly one other RSTP-compliant switch. A shared port is connected to a
shared LAN segment that utilizes hubs or repeaters and cannot transition rapidly, as in
the previous proposal agreement process.
Switches attempt to detect link type by using the duplex setting of the interface: Halfduplex
is considered shared, and full-duplex is considered point-to-point.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 158
802.1w also achieves rapid convergence by modifying what constitutes a topology change
in the network. In 802.1D, loss of a port or a port transitioning to blocking is considered
a topology change event. In 802.1w, only a non-edge (blocking or alternate) port
transitioning to the forwarding state generates a topology change event. The reason is that
the new non-edge port offers a new path in the network, and the remaining switches
should synchronize their MAC address tables accordingly to reflect the change. The TC-while
timer is started on the switch initiating the topology change. During this time, the switch
sends BPDUs with the TC flag set out all of its designated and root ports.
Switches that receive these BPDUs immediately age out all MAC addresses on all ports
except where the TC BPDU was received. This mechanism allows rapid transition of the
topology because TC BPDUs are originated by the switch experiencing the topology
change event and are not initiated by the root bridge, as is the case in 802.1D.
Finally, because BPDUs are necessary for a blocking port to remain blocking, if a blocking
port receives an inferior BPDU, it can react immediately to the information. This is
in contrast to the 802.1D specification, which requires the stored BPDU on a port to age out
before the switch converges the topology. In 802.1w, the switch receiving the inferior
BPDU can infer that a topology change event has occurred somewhere in the network.
If a functioning root port exists on the switch receiving an inferior BPDU, it can simply
respond with a proposal BPDU on its formerly blocking port, asking to be set to designated.
This allows the failed switch to recover rapidly. If there is no functioning root port
(meaning the inferior BPDU was received on a root port), the switch can assume that it
should be the new root switch and indicates that with all of its remaining, now downstream,
neighbors.
These are the key enhancements to 802.1D built into 802.1w. Some of them may sound
familiar as they relate to many of the Cisco enhancement features to 802.1D, such as
PortFast and Backbone Fast. The following lab demonstrates these enhancement features
of 802.1w and contrasts them with their 802.1D equivalents.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 159
Initial Configuration:
Task 1
Change the hostname on each switch to SW#, where # is the number of the switch (for
example, Switch 1 = SW1).
On SW1:
Switch(config)#hostname SW1
On SW2:
Switch(config)#hostname SW2
On SW3:
Switch(config)#hostname SW3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 160
On SW4:
Switch(config)#hostname SW4
On SW5:
Switch(config)#hostname SW5
On SW6:
Switch(config)#hostname SW6
Task 2
a. Ensure that only the following ports on the switches are in an up/up state:

SW1


E2/1-2
E3/1-2
On SW1:
SW1(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW1(config-if-range)#shut
SW1(config)#interface range e2/1-2,e3/1-2
SW1(config-if-range)#no shut
To verify the configuration:
SW1#show ip interface brief | exclude down
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
Ethernet3/2
CCIE by Narbik Kocharians
IP-Address
unassigned
unassigned
unassigned
unassigned
OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Protocol
up
up
up
up
Page 161

SW2




E1/1-2
E3/1-2
E4/1-2
E5/1-2
On SW2:
SW2(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW2(config-if-range)#shut
SW2(config)#interface range e1/1-2,e3/1-2,e4/1-2,e5/1-2
SW2(config-if-range)#no shut
To verify the configuration:
SW2#show ip interface brief | exclude down
Interface
Ethernet1/1
Ethernet1/2
Ethernet3/1
Ethernet3/2
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW3




OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
up
up
E1/1-2
E2/1-2
E4/1-2
E5/1-2
On SW3:
SW3(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW3(config-if-range)#shut
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 162
SW3(config)#interface range e1/1-2,e2/1-2,e4/1-2,e5/1-2
SW3(config-if-range)#no shut
To verify the configuration:
SW3#show ip interface brief | ex down
Interface
Ethernet1/1
Ethernet1/2
Ethernet2/1
Ethernet2/2
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW4



OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
up
up
E2/1-2
E3/1-2
E6/1-2
On SW4:
SW4(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW4(config-if-range)#shut
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#no shut
To verify the configuration:
SW4#show ip interface brief | ex down
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
CCIE by Narbik Kocharians
IP-Address
unassigned
unassigned
unassigned
OK? Method Status
YES unset up
YES unset up
YES unset up
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Protocol
up
up
up
Page 163
Ethernet3/2
Ethernet6/1
Ethernet6/2
unassigned
unassigned
unassigned

SW5



YES unset
YES unset
YES unset
up
up
up
up
up
up
E2/1-2
E3/1-2
E6/1-2
On SW5:
SW5(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW5(config-if-range)#shut
SW5(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW5(config-if-range)#no shut
To verify the configuration:
SW5#show ip interface brief | exclude down
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
Ethernet3/2
Ethernet6/1
Ethernet6/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW6


OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
E4/1-2
E5/1-2
On SW6:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 164
SW6(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW6(config-if-range)#shut
SW6(config)#interface range e4/1-2,e5/1-2
SW6(config-if-range)#no shut
To verify the configuration:
SW6#show ip interface brief | exclude down
Interface
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
Task 3
Configure VLANs 10, 20, 30, and 40 on each switch, using any method.
The task requires VLANs 10, 20, 30 and 40 to be configured on all the switches in the topology. As seen
below, these VLANs are configured on all the switches with the vlan command. However since the task
does not place any restriction, VTP can be used to propagate the VLANs between switches. The show vlan
brief | include VLAN command output can then be used to verify this configuration:
On All Switches:
SW1(config)#vlan 10,20,30,40
SW1(config-vlan)#exit
To verify the configuration:
On Any Switch:
SWx#show vlan brief | include VLAN
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 165
VLAN Name
10
VLAN0010
20
VLAN0020
30
VLAN0030
40
VLAN0040
Status
active
active
active
active
Ports
Task 4
Configure trunk ports on all up/up interfaces.
The commands switchport trunk encapsulation dot1q and switchport mode trunk is configured on all
the interfaces on all the switches that were brought back up earlier. The combination of these commands
manually configure the interfaces to function as 802.1q trunk links.
On SW1:
SW1(config)#interface range e2/1-2,e3/1-2
SW1(config-if-range)#switchport trunk encapsulation dot1q
SW1(config-if-range)#switchport mode trunk
On SW2:
SW2(config)#interface range e1/1-2,e3/1-2,e4/1-2,e5/1-2
SW2(config-if-range)#switchport trunk encapsulation dot1q
SW2(config-if-range)#switchport mode trunk
On SW3:
SW3(config)#interface range e1/1-2,e2/1-2,e4/1-2,e5/1-2
SW3(config-if-range)#switchport trunk encapsulation dot1q
SW3(config-if-range)#switchport mode trunk
On SW4:
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#switchport trunk encapsulation dot1q
SW4(config-if-range)#switchport mode trunk
On SW5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 166
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#switchport trunk encapsulation dot1q
SW4(config-if-range)#switchport mode trunk
On SW6:
SW5(config)#interface range e4/1-2,e5/1-2
SW5(config-if-range)#switchport trunk encapsulation dot1q
SW5(config-if-range)#switchport mode trunk
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 167
802.1w – Configuration Tasks
Task 1
Configure all switches to run 802.1w Rapid Spanning Tree Protocol.
The default spanning-tree mode on most switching platforms is 802.1D Spanning-Tree. In order to
activate 802.1w Rapid Spanning-Tree, issue the command spanning-tree mode rapid-pvst command in
global configuration mode as follows. The show spanning-tree output is then used to verify this change
as seen below:
On All Switches:
SWx(config)#spanning-tree mode rapid-pvst
To verify the configuration:
On All Switches:
SWx#show spanning-tree
| include VLAN|protocol
VLAN0001
Spanning tree enabled protocol rstp
VLAN0010
Spanning tree enabled protocol rstp
VLAN0020
Spanning tree enabled protocol rstp
VLAN0030
Spanning tree enabled protocol rstp
VLAN0040
Spanning tree enabled protocol rstp
Task 2
Ensure that SW1 is the root for all VLANs.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 168
RSTP uses the same logic as 802.1D spanning-tree to elect a root switch, choosing the switch with the
lowest BID in the switched network as the root bridge.
Similar to the same task in the PVST+ section, this task requires no extra configuration since SW1 has
already been designated as the root bridge for all VLANs. This decision was made based on SW1’s MAC
address as all switches have a tied priority value of 32,768.
NOTE: If SW1 is not the root bridge in your topology, use the spanning-tree vlan 1-4094 root primary
command to make it the root bridge.
A quick way to determine if the local switch is the root bridge for all VLANs is to use the show spanningtree root command. There is no need to know the MAC address of the local switch when using this
command. Because the root switch advertises a cost of 0 to reach itself out of all of its Designated ports,
all VLANs in the show spanning-tree root command output that have 0 listed in the “Root Cost” column
are VLANs for which the local switch is the root bridge as seen below:
On SW1:
SW1#show spanning-tree root
Root
Cost
Hello Max Fwd
Time Age Dly
Vlan
Root ID
Port
---------------- -------------------- --------- ----- --- --VLAN0001
32769 aabb.cc00.1f00
0
2
20 15
VLAN0010
32778 aabb.cc00.1f00
0
2
20 15
VLAN0020
32788 aabb.cc00.1f00
0
2
20 15
VLAN0030
32798 aabb.cc00.1f00
0
2
20 15
VLAN0040
32808 aabb.cc00.1f00
0
2
20 15
Root
------
Task 3
Ensure that if the current root bridge fails, SW2 becomes the new root for all VLANs.
Once again, similar to Task 4 in the PVST+ section, SW2 can be configured to be the secondary bridge
with the spanning-tree vlan [vlan list] root secondary command for all VLANs. Following this, to ensure
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 169
that SW1 retains its root status, the command spanning-tree vlan [vlan list] root primary should be
configured on SW1 for all VLANs:
On SW2:
SW2(config)#spanning-tree vlan 1-4094 root secondary
On SW1:
SW1(config)#spanning-tree vlan 1-4094 root primary
Task 4
Ensure that SW2’s and SW3’s E1/2 interface is used as the root port for all VLANs. Do
not modify cost to achieve this.
As explained in task 5 of the PVST+ section, SW2 and SW3 use the SPID value as the tiebreaker to elect
their E1/1 interface as the root port towards the root bridge. The show spanning-tree root command from
SW2 and SW3 verifies this:
On SW2:
SW2#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0001
24577 aabb.cc00.1f00
100
2
20 15
VLAN0010
24586 aabb.cc00.1f00
100
2
20 15
VLAN0020
24596 aabb.cc00.1f00
100
2
20 15
VLAN0030
24606 aabb.cc00.1f00
100
2
20 15
VLAN0040
24616 aabb.cc00.1f00
100
2
20 15
Root Port
--------Et1/1
Et1/1
Et1/1
Et1/1
Et1/1
On SW3:
SW3#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0001
24577 aabb.cc00.1f00
100
2
20 15
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Root Port
--------Et1/1
Page 170
VLAN0010
VLAN0020
VLAN0030
VLAN0040
24586 aabb.cc00.1f00
24596 aabb.cc00.1f00
24606 aabb.cc00.1f00
24616 aabb.cc00.1f00
100
100
100
100
2
2
2
2
20
20
20
20
15
15
15
15
Et1/1
Et1/1
Et1/1
Et1/1
This task requires making configuration changes such that SW2 and SW3 designate their E1/2 interfaces as
the root port. However, unlike the PVST+ section, this task restricts modifying the cost to make the E1/2
interfaces on SW2 and SW3 the root port. The task, however, places no restriction on modifying the SPIDs.
The spanning-tree vlan 1-4094 port-priority 64 command on the E2/2 and E3/2 interfaces on SW1 will
cause it to assign 64 as the port-priority for these interfaces. Since this is lower than the default portpriority value of 128, when comparing the SPIDs on the BPDUs received from SW1 on their E1/1 and E1/2
interfaces, both SW2 and SW3 will designate their E1/2 interfaces as the root port for all VLANs. This is
verified with the show spanning-tree root command output below:
On SW1:
SW1(config)#interface e1/2
SW1(config-if)#spanning-tree vlan 1-4094 port-priority 64
On SW2:
SW2#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0001
24577 aabb.cc00.1f00
100
2
20 15
VLAN0010
24586 aabb.cc00.1f00
100
2
20 15
VLAN0020
24596 aabb.cc00.1f00
100
2
20 15
VLAN0030
24606 aabb.cc00.1f00
100
2
20 15
VLAN0040
24616 aabb.cc00.1f00
100
2
20 15
Root Port
--------Et1/2
Et1/2
Et1/2
Et1/2
Et1/2
On SW3:
SW3#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Root Port
---------
Page 171
VLAN0001
VLAN0010
VLAN0020
VLAN0030
VLAN0040
24577 aabb.cc00.1f00
24586 aabb.cc00.1f00
24596 aabb.cc00.1f00
24606 aabb.cc00.1f00
24616 aabb.cc00.1f00
100
100
100
100
100
2
2
2
2
2
20
20
20
20
20
15
15
15
15
15
Et1/2
Et1/2
Et1/2
Et1/2
Et1/2
Task 5
Ensure that SW5 uses the following ports as root:




E2/1 for VLAN 10
E2/2 for VLAN 20
E3/1 for VLAN 30
E3/2 for VLAN 40
Do not modify SW5 to achieve any of this.
By default, the E2/1 interface on SW5 is designated as the root port for all VLANs as seen in the show
spanning-tree output below:
On SW5:
SW5#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0001
24577 aabb.cc00.1f00
200
2
20 15
VLAN0010
24586 aabb.cc00.1f00
200
2
20 15
VLAN0020
24596 aabb.cc00.1f00
200
2
20 15
VLAN0030
24606 aabb.cc00.1f00
200
2
20 15
VLAN0040
24616 aabb.cc00.1f00
200
2
20 15
Root Port
--------Et2/1
Et2/1
Et2/1
Et2/1
Et2/1
The reasoning for electing the E2/1 interface as the root port is as follows: SW5 receives BPDUs from SW2
and SW3 over its E2/1-2 and E3/1-2 interfaces. BPDUs from SW6 are the most inferior, so will not be
considered in the following explanation.
The cost to reach the root from both SW2 and SW3 equals to 100 from SW5. As a result of this tie in cost,
SW5 uses the next tie breaker, and chooses the switch with lower SBID which is SW2. SW5 then uses the
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 172
next tiebreaker, the lower SPID to determine which of its ports towards SW2 (E2/1, E2/2) should be
designated as the root. Since the SPID of SW2’s E5/1 interface is lower than the SPID of its E5/2 interface,
SW5 designates its E2/1 interface as the root port for all VLANs. The E2/2 interface is put in an alternate
blocking state. The example output for VLAN 1 details and confirms the lower SPID of SW2’s E5/1 interface.
SW5#show spanning-tree vlan 1 detail | section Ethernet2/1
Root port is 10 (Ethernet2/1), cost of root path is 200
from Ethernet2/1
Port 10 (Ethernet2/1) of VLAN0001 is root forwarding
Port path cost 100, Port priority 128, Port Identifier 128.10.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 28673, address aabb.cc00.2000
Designated port id is 128.22, designated path cost 100
Timers: message age 15, forward delay 0, hold 0
Number of transitions to forwarding state: 3
Link type is point-to-point by default
BPDU: sent 25, received 48781
Port 11 (Ethernet2/2) of VLAN0001 is alternate blocking
Port path cost 100, Port priority 128, Port Identifier 128.11.
Designated root has priority 24577, address aabb.cc00.1f00
Designated bridge has priority 28673, address aabb.cc00.2000
Designated port id is 128.23, designated path cost 100
Timers: message age 15, forward delay 0, hold 0
Number of transitions to forwarding state: 0
Link type is point-to-point by default
BPDU: sent 29, received 47912
The following sub tasks require changing the root ports for various VLANs on SW5:
1. e2/1 for VLAN 10
This task requires no extra configuration as the E2/1 interface is already being used as the root port for
VLAN 10. The show spanning-tree vlan 10 output confirms this:
On SW5:
SW5#show spanning-tree vlan 10 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0010
24586 aabb.cc00.1f00
200
2
20 15
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Root Port
--------Et2/1
Page 173
2. e2/2 for VLAN 20
The task restricts making any modifications on SW5. So one of the ways to ensure E2/2 is designated as the
root port for VLAN 20 on SW5, is to lower the port-priority value of SW2’s E5/2 interface to a value lower
than the default value of 128 on its E5/1 interface.This is achieved with the interface-level command
spanning-tree vlan 20 port-priority 64 as seen below:
On SW2:
Port Priority is set to 64 for SW2’s E5/2 interface
SW2(config)#interface e5/2
SW2(config-if)#spanning-tree vlan 20 port-priority 64
On SW5:
SW5#show spanning-tree vlan 20 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0020
24596 aabb.cc00.1f00
200
2
20 15
Root Port
--------Et2/2
SW5#show spanning-tree vlan 20 interface e2/1
Vlan
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- ----VLAN0020
Altn BLK 100
128.10
P2p
As a result, SW5 now uses its E2/2 interface as the root port and the E2/1 interface is now in an alternate
blocking state.
3. e3/1 for VLAN 30
The cost to reach the root bridge SW1 from SW2 and SW3 is equal. SW5 uses the tiebreaker of comparing
the SBIDs and designates its E2/1 interface as the root port. This task requires that SW5 uses the E3/1
interface connected to SW3 to reach the root. This can be achieved by modifying the BID of SW3 so that it
has a lower BID than SW2’s BID. However, this would violate Task 3 which requires that SW2 should take
over as the root in case the current root fails.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 174
So another way to solve this task would be modifying SW3’s cost to the root for VLAN 30 to something
lower than SW2’s cost to the root. The current cumulative cost to the root from SW5 is 200 via SW2 as
shown below.
On SW5:
SW5#show spanning-tree vlan 30 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0030
24606 aabb.cc00.1f00
200
2
20 15
Root Port
--------Et2/1
The spanning-tree vlan 30 cost 99 on SW3’s current root port would result in a lower cumulative cost of
199 to reach the root via SW3 for SW5. After this change, SW5 uses the lower SPID tiebreaker and
designates its E3/1 interface as the root port. This is verified in the show spanning-tree vlan 30 command
output below:
On SW3:
SW3(config)#interface e1/2
SW3(config-if)#spanning-tree vlan 30 cost 99
On SW5:
SW5#show spanning-tree vlan 30 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0030
24606 aabb.cc00.1f00
199
2
20 15
Root Port
--------Et3/1
Note: This task could have been solved by modifying the cost directly on SW5. However, since the task restricts
making any changes to SW5, the options are to either set a lower RPC on SW3 or a higher RPC on SW2.
4. e3/2 for VLAN 40
Once again, the current root port for VLAN 40 on SW5 is its E2/1 interface as seen below:
On SW5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 175
SW5#show spanning-tree vlan 40 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0040
24616 aabb.cc00.1f00
200
2
20 15
Root Port
--------Et2/1
This sub task requires SW5 to designate its E3/2 interface as the root port. To influence SW5’s decision, the
following two configuration changes are made on SW3 while complying with the task restriction of not
making any modification to SW5:
1. SW3’s cost to the root is modified to make it lower than SW2’s cost to the root, resulting in SW5
choosing SW3 to reach the root. This is achieved with the spanning-tree vlan 40 cost 99 command
on SW3’s root port E1/2
2. The port ID of SW3’s E5/2 interface is configured to be lower than the default port ID of 128 on its
E5/1 interface for VLAN 40 with the spanning-tree vlan 40 port-priority 64 command. This would
result in SW5 choosing its E3/2 interface as the root port as seen below:
On SW3:
SW3(config)#interface e1/2
SW3(config-if)#spanning vlan 40 cost 99
The above configuration change results in SW5 choosing its E3/1 interface connected to SW3 as the root
port:
On SW5:
SW5#show spanning-tree vlan 40 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0040
24616 aabb.cc00.1f00
199
2
20 15
Root Port
--------Et3/1
Finally, the port priority for SW3’s E5/2 interface is made lower to make the E3/2 port on SW5 more
preferable, hence, the root port:
On SW3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 176
SW3(config)#interface e5/2
SW3(config-if)#spanning-tree vlan 40 port-priority 64
To verify the configuration:
On SW5:
SW5#show spanning-tree vlan 40 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0040
24616 aabb.cc00.1f00
199
2
20 15
Root Port
--------Et3/2
Task 6
Ensure that SW4 uses its E3/1 port as the root port for VLAN 20.
The show spanning-tree vlan 20 root command output below shows the current root port on SW4 is its
E2/1 for VLAN 20. Since the cost to reach the root via SW2 and SW3 tie with the value of 200, SW4 uses the
next tie breaker of comparing the SBIDs and chooses to use a port towards SW2 (lower SBID) as the root:
On SW4:
SW4#show spanning-tree vlan 20 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0020
24596 aabb.cc00.1f00
200
2
20 15
Root Port
--------Et2/1
This task requires SW4 to use the interface E3/1 connected to SW3 as the root port. SBIDs cannot be
modified to make SW3 more preferable as this would violate Task 3. So, the easiest way to solve this task is
to modify the port cost on SW4’s E3/1 interface such that it is lower than the cost to reach the root over its
E2/1 interface. The cumulative cost to reach the root is 200 as seen above and the default port cost is 100.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 177
To make the E3/1 interface more preferable, the port cost on SW4’s E3/1 interface is reduced to 99 with
the spanning-tree vlan 20 cost 99 command:
On SW4:
SW4(config)#interface e3/1
SW4(config-if)#spanning-tree vlan 20 cost 99
Notice the cost below to reach the root is 199 which is lower than the cost to reach the root over its E2/1
interface
SW4#show spanning-tree vlan 20 root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0020
24596 aabb.cc00.1f00
199
2
20 15
Root Port
--------Et3/1
As seen above, with the port cost modification on SW4, the total cumulative cost to reach the root over it’s
E3/1 interface is now 199 resulting in SW4 designating this port as the root port.
Task 7
Ensure that RSTP features are enabled on all ports.
The beginning of this configuration lab explained the process RSTP uses to achieve rapid convergence. This
rapid convergence comes at a strict restriction. It only works between links between two switches. If, for
example, three switches were connected by a hub, there would be no way for the three switches to signal a
proposal or agreement to each other. The resulting spanning-tree topology would be difficult to work out.
For this reason, RSTP includes two important link types: shared and point-to-point.
A switch with a shared link connects to multiple neighboring switches. Due to the nature of such ports, the
RSTP convergence enhancements are not used. Instead, the normal timer-based convergence processes
are employed. A switch with a point-to-point link connects to a single neighboring switch. These links are
candidates for rapid convergence and take full advantage of RSTPs convergence enhancements. The show
spanning-tree output lists the ports, their role, state, cost, and link type information as in the example
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 178
output below:
On SW1:
SW1#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID
Priority
24577
Address
aabb.cc00.1f00
This bridge is the root
Hello Time
2 sec Max Age 20 sec
Bridge ID
Priority
Address
Hello Time
Aging Time
Forward Delay 15 sec
24577 (priority 24576 sys-id-ext 1)
aabb.cc00.1f00
2 sec Max Age 20 sec Forward Delay 15 sec
300 sec
Interface
Role Sts Cost
Prio.Nbr Type
------------------- ---- --- --------- -------- -----------------------Et2/1
Desg FWD 100
128.10
P2p
Et2/2
Desg FWD 100
64.11
P2p
Et3/1
Desg FWD 100
128.14
P2p
Et3/2
Desg FWD 100
64.15
P2p
In the above, the “Type” column indicates what link type the interface is operating under. The value is
“shared” for shared link type and “P2p” for point-to-point link type.
The switch attempts to predict what kind of link each port has based on the duplex setting. If the port is in
half-duplex mode, the switch considers the link to be a shared link. If the link is in full-duplex mode, the
switch considers a link to be a point-to-point link. This is a good assumption considering the only way to
connect multiple switches to the same port is to use an ethernet hub. Ethernet hubs force half-duplex
operation because all ports on a hub share the same broadcast domain and the CSMA-CD algorithm is used
to organize transmission on the wire. This leaves ports in full-duplex mode to only have a single switch or
other device connected and thus can be assumed to be point-to-point.
There are times where this assumption is not true especially in emulated environments where the auto
MDIX process may not work properly. If the auto MDIX process fails, ports fall back to half-duplex and thus
have a shared link type which bypasses all RSTP rapid convergence enhancements. In such a case, the
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 179
spanning-tree link-type [point-to-point | shared] interface-level command can be used to manually set the
link type in the topology.
The task specifies all ports should be candidates to benefit from all of RSTP’s rapid convergence properties.
As such, the spanning-tree link-type point-to-point interface-level command should be configured on all
switch ports. However, looking at the output above from the lab topology, the switch has already
appropriately designated the ports as point-to-point and as a result, no further configuration is required.
NOTE: If there are ports that are NOT in designated as point-to-point (P2p) in the show spanning-tree
output, use the spanning-tree link-type point-to-point command in interface configuration mode for those
ports.
Task 8
Ensure that interfaces connected to non-switch hosts come online immediately.
a. If SW4 or SW5 detects a switch on these ports when it first comes online, it should
process the BPDUs normally. Otherwise, it should not process received BPDUs.
b. If SW6 detects a switch on one of these ports, it should disable the port.
In 802.1D spanning-tree protocol, whenever a port moved from blocking to forwarding state it must first
move through the listening and learning states, a process that could take up to 30s with default timers.
Cisco implemented the portfast feature which allowed specifically configured ports to bypass these states
and move straight from blocking to forwarding.
The developers of RSTP borrowed this concept and created what is known as an edge port. Edge ports are
ports that connect to edge devices (end user stations, servers, APs, etc.). Such ports have a low possibility
of causing loops in the network and can move instantly to forwarding state. Edge ports are also very
important to RSTP because of the proposal/agreement process that allows fast convergence.
Recall that once a switch determines the location of its root port it first sets all of its non-edge ports to
discarding state. After setting non-edge ports to discarding state, the switch signals to its upstream
designated switch that it is safe to move the designated switch’s port to forwarding. The key part of the
process is that non-edge ports are set to discarding and not the edge ports themselves. Because edge
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 180
ports do not cause loops there is no need to set them to a discarding state upon a spanning-tree
recalculation, in other words they should not be affected by the Sync operation. This allows end stations
connected to the same switch to continue to forward traffic between each other if necessary. For this
reason, it is important to designate all ports leading to end stations as edge ports.
Another important side effect is that like the Cisco-proprietary portfast feature, if a BPDU is received on an
edge port, the port loses its edge status and performs the normal convergence steps. This step is
important because if the edge port is truly non-edge (meaning it connects to another switch) care must be
taken to ensure that no loops are formed. This includes setting the port to blocking during the
synchronization phase of the convergence process.
There is no mechanism in the 802.1w specification that detects edge port status for a particular port. For
Cisco switches, edge ports are designated by the portfast configuration on the interfaces.
The task requires all non-switch hosts should have their ports come online immediately. To do so, there
needs to be a way for the switch to detect whether an end host is indeed a switch or not. To solve this, the
spanning-tree portfast edge default command is configured in global configuration mode.
The command does the same thing for RSTP as explained in the 802.1D section of the lab. All access ports
on the switch will automatically be configured as portfast interfaces. For RSTP, this means all access ports
will automatically have edge port status, exempting them from becoming discarding during the
synchronization process.
Subtask A states that if a switch is detected on the port when it is first turned on for SW4 and SW5, the
switch should process the BPDUs normally, otherwise all BPDUs should be ignored on the interface. In the
802.1D section of the lab, the Cisco BPDU filter enhancement was enabled globally on the switch. Once
enabled, all portfast interfaces would wait briefly (10 hello intervals) before enabling the portfast feature.
If a BPDU was received during that initial time, the port would process the received BPDUs normally.
802.1w RSTP, the same BPDU filtering feature can be utilized with the same effect with the spanning-tree
portfast edge bpdufilter default command. By enabling the feature globally, all edge ports first wait for a
period of time to listen for potential BPDUs. After that time, if no BPDUs are heard, the ports will ignore all
future BPDUs received on the interface.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 181
Finally, subtask B requires the SW6 to shutdown any port connected to a host that receives a BPDU. There
is no automatic mechanism in RSTP to provide this functionality. So, just like in the 802.1D section of the
lab, the BPDU guard feature should be enabled globally on SW6 with the spanning-tree portfast edge
bpduguard default command. Once enabled, any portfast-enabled port that receives a BPDU will be put
into the err-disabled state and shut down.
Below are the complete configuration commands required to complete this task:
Enabling portfast on SW4, SW5 and SW6
On SW4, SW5, and SW6:
SWx(config)#spanning-tree portfast edge default
%Warning: this command enables portfast by default on all interfaces. You
should now disable portfast explicitly on switched ports leading to hubs,
switches and bridges as they may create temporary bridging loops.
To verify the configuration:
SW6#show spanning-tree summary | include Portfast
Portfast Default
Portfast Edge BPDU Guard Default
Portfast Edge BPDU Filter Default
is edge
is disabled
is disabled
Enabling BPDU filter on SW4 and SW5:
On SW4 and SW5:
SWx(config)#spanning-tree portfast edge bpdufilter default
To verify the configuration:
On SW4 or SW5:
SW4#show spanning-tree summary | include BPDU Filter
Portfast Edge BPDU Filter Default
is enabled
Enabling BPDU Guard on SW6:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 182
On SW6:
SW6(config)#spanning-tree portfast edge bpduguard default
To verify the configuration:
SW6#show spanning-tree summary
Portfast Edge BPDU Guard Default
| include BPDU Guard
is enabled
Task 9
SW6’s links towards SW5 should be used as root port for all VLANs except VLAN 10
a. Ensure that SW6’s links toward SW5 are used as the root port for all VLANs except
VLAN 10. If the link between SW5 and SW6 goes down, SW6 should immediately
switch to using one of its links toward SW4 as the single root port.
The first part of the configuration for this task requires configuring etherchannels between SW6 - SW5.
The task does not explicitly mention this. However, the fact that there can exist only one root port per
switch and the task requires all links towards SW5 to be designated as root port hints towards bundling
the Layer 2 links. So similar to task 9 from the PVST+ section, the following configuration creates logical
port-channels using PAgP between the switches. NOTE: The task does not specific which etherchannel
protocol to use, PAgP was arbitrarily chosen for this solution.
On SW6:
SW6(config)#interface range e5/1-2
SW6(config-if-range)#channel-group 5 mode desirable
On SW5:
SW5(config)#interface range e6/1-2
SW5(config-if-range)#channel-group 5 mode desirable
After configuring the port-channels, the show spanning-tree root command output on SW6 shows the
current root port for all VLANs is SW6’s port-channel 5 interface towards SW5:
On SW6:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 183
SW6#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0001
24577 aabb.cc00.1f00
256
2
20 15
VLAN0010
24586 aabb.cc00.1f00
256
2
20 15
VLAN0020
24596 aabb.cc00.1f00
256
2
20 15
VLAN0030
24606 aabb.cc00.1f00
255
2
20 15
VLAN0040
24616 aabb.cc00.1f00
255
2
20 15
Root Port
--------Po5
Po5
Po5
Po5
Po5
The task requires SW6 to use its port-channel interface connected to SW5 as the root port for all VLANs
except VLAN 10. However, as seen above, SW6 chooses the port channel interface for VLAN 10 as its root
port.
The reason SW6 makes this determination is due to the new cost associated with the port-channel
interface. By default, the cost is automatically computed based on the bandwidth of an interface. Because
a Port Channel interface is a grouping of multiple member links, its total bandwidth will be the total
bandwidth of all those member links. In this example, the bandwidth for the Po5 interface is 20Mbps
(shown below) because the e5/1 and e5/2 interfaces each have a negotiated bandwidth of 10mbps:
On SW6:
SW6#show interfaces port-channel 5 | include BW
MTU 1500 bytes, BW 20000 Kbit/sec, DLY 1000 usec,
SW6#show interfaces e5/1 | include BW
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
SW6#show interfaces e5/2 | include BW
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
The STP cost associated with that bandwidth is 56 instead of 100 making the total path cost to the root
through Po5, 256. To ensure SW6 uses its E4/1 interface to SW4 as the root port for VLAN 10, the port cost
of the port-channel needs to be set to a higher value with the spanning-tree vlan 10 cost 150 command.
As a result, due to a lower cost to reach the root for VLAN 10 over the interfaces connected to SW4, SW6
now designates its E4/1 interface as the root port for VLAN 10:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 184
On SW6:
SW6(config)#interface port-channel 5
SW6(config-if)#spanning-tree vlan 10 cost 150
SW6#show spanning-tree root
Root
Hello Max Fwd
Vlan
Root ID
Cost
Time Age Dly
---------------- -------------------- --------- ----- --- --VLAN0001
24577 aabb.cc00.1f00
256
2
20 15
VLAN0010
24586 aabb.cc00.1f00
300
2
20 15
VLAN0020
24596 aabb.cc00.1f00
256
2
20 15
VLAN0030
24606 aabb.cc00.1f00
255
2
20 15
VLAN0040
24616 aabb.cc00.1f00
255
2
20 15
Root Port
--------Po5
Et4/1
Po5
Po5
Po5
Subtask A requires that if the current root ports for all VLANs fail, the alternate connection to the root
bridge which is in the blocking state should immediately replace the failed root port. This immediate
transition of an alternate connection to root was possible by enabling the uplinkfast feature in 802.1D. The
uplinkfast enhancement, in case of 802.1D, caused the switch to bypass the listening and learning stages
and immediately move the port to a forwarding mode.
The designers of RSTP wanted to incorporate this functionality in the RSTP standard and did so with the
use of the alternate port role. Recall that an alternate port is a switch port that receives a less superior
BPDU to the current root port. This indicates that it provides an alternate loop-free path to the root
bridge. Since the neighboring switch port connected to the alternate discarding port is already designated
forwarding, the port can move to root forwarding immediately without the fear of causing a loop. As a
result, there is no need to explicitly configure this feature in RSTP. This fact is true in 802.1D as well, the
difference being, in 802.1D, the alternat discarding port would be in the blocking state. Due to the timerbased convergence process in 802.1D, the switch would have to transition the port through the listening
and learning states before finally making it to forwarding. A process that can take up to 30s with default
timers.
Task 10
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 185
Ensure that SW4 and SW5 can recover from an indirect link failure within 10 seconds.
Do not modify the spanning-tree timers.
One of the major drawbacks of 802.1D spanning tree was the timer-based convergence
mechanisms. If a designated bridge loses its connection to the root, it will begin
advertising itself as the root bridge to all of its connected ports. A downstream port
in the blocking state would receive these inferior BPDUs. In 802.1D, the blocking port
would completely ignore the information until the stored BPDU from the real root on
that blocking port expires (in 20 seconds, based on the default Max Age timer). Then the
switch signals a topology change event, and the port transitions to the forwarding state.
The entire process can take up to 50 seconds with default timers.
The Cisco Backbone Fast feature was created to help this process by utilizing the RLQ
protocol when a blocking port suddenly starts receiving inferior BPDUs. The RLQ messages
are sent out in order to determine if a path to the root exists on the switch. If a path
is found, the previously blocked port can bypass the Max Age timer and begin the transition
to the forwarding state, cutting 20 seconds of convergence time.
RSTP incorporates this function through its behavior of immediately accepting inferior
BPDUs that are received on a discarding port. An inferior BPDU being received on a
discarding port signifies that a topology change has occurred somewhere in the network.
Either the current root has failed and the local switch has stale information or
the upstream designated bridge has lost its connection to the root. In either case, the
spanning-tree topology needs to reconverge and can do so rapidly by using the proposal/
agreement processes.
Since this feature is built into RSTP, there is no configuration needed to accomplish
this task.
*NOTE* Do not forget to reset the switch configurations to initial configurations upon
completing this exercise.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 186
802.1s Multiple Spanning Tree Protocol
Initial Configuration:
Task 1
Change the hostname on each switch to SW#, where # is the number of the switch (for
example, Switch 1 = SW1).
On SW1:
Switch(config)#hostname SW1
On SW2:
Switch(config)#hostname SW2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 187
On SW3:
Switch(config)#hostname SW3
On SW4:
Switch(config)#hostname SW4
On SW5:
Switch(config)#hostname SW5
On SW6:
Switch(config)#hostname SW6
Task 2
a.
Ensure that only the following ports on the switches are in an up/up state:

SW1


E2/1-2
E3/1-2
On SW1:
SW1(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW1(config-if-range)#shut
SW1(config)#interface range e2/1-2,e3/1-2
SW1(config-if-range)#no shut
To verify the configuration:
SW1#show ip interface brief | exclude down
Interface
Ethernet2/1
Ethernet2/2
CCIE by Narbik Kocharians
IP-Address
unassigned
unassigned
OK? Method Status
YES unset up
YES unset up
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Protocol
up
up
Page 188
Ethernet3/1
Ethernet3/2
unassigned
unassigned

SW2




YES unset
YES unset
up
up
up
up
E1/1-2
E3/1-2
E4/1-2
E5/1-2
On SW2:
SW2(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW2(config-if-range)#shut
SW2(config)#interface range e1/1-2,e3/1-2,e4/1-2,e5/1-2
SW2(config-if-range)#no shut
To verify the configuration:
SW2#show ip interface brief | exclude down
Interface
Ethernet1/1
Ethernet1/2
Ethernet3/1
Ethernet3/2
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW3




OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
up
up
E1/1-2
E2/1-2
E4/1-2
E5/1-2
On SW3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 189
SW3(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW3(config-if-range)#shut
SW3(config)#interface range e1/1-2,e2/1-2,e4/1-2,e5/1-2
SW3(config-if-range)#no shut
To verify the configuration:
SW3#show ip interface brief | exclude down
Interface
Ethernet1/1
Ethernet1/2
Ethernet2/1
Ethernet2/2
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW4



OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
up
up
E2/1-2
E3/1-2
E6/1-2
On SW4:
SW4(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW4(config-if-range)#shut
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#no shut
To verify the configuration:
SW4#show ip interface brief | exclude down
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 190
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
Ethernet3/2
Ethernet6/1
Ethernet6/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW5



OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
E2/1-2
E3/1-2
E6/1-2
On SW5:
SW5(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW5(config-if-range)#shut
SW5(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW5(config-if-range)#no shut
To verify the configuration:
SW5#show ip interface brief | exclude down
Interface
Ethernet2/1
Ethernet2/2
Ethernet3/1
Ethernet3/2
Ethernet6/1
Ethernet6/2
IP-Address
unassigned
unassigned
unassigned
unassigned
unassigned
unassigned

SW6


OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
up
up
E4/1-2
E5/1-2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 191
On SW6:
SW6(config)#interface range e0/0-3,e1/0-3,e2/0-3,e3/0-3,e4/0-3,e5/0-3,e6/03,e7/0-3
SW6(config-if-range)#shut
SW6(config)#interface range e4/1-2,e5/1-2
SW6(config-if-range)#no shut
To verify the configuration:
SW6#show ip interface brief | exclude down
Interface
Ethernet4/1
Ethernet4/2
Ethernet5/1
Ethernet5/2
IP-Address
unassigned
unassigned
unassigned
unassigned
OK? Method Status
YES unset up
YES unset up
YES unset up
YES unset up
Protocol
up
up
up
up
Task 3
Configure VLANs 10, 20, 30, and 40 on each switch, using any method.
The task requires VLANs 10, 20, 30 and 40 to be configured on all the switches in the topology. As seen
below, these VLANs are configured on all the switches with the vlan command. However since the task
does not place any restriction, VTP can be used to propagate the VLANs between switches. The show vlan
brief | in VLAN command output can then be used to verify the VLANs configured:
On All Switches:
SW1(config)#vlan 10,20,30,40
SW1(config-vlan)#exit
To verify the configuration:
On Any Switch:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 192
SWx#show vlan brief | include VLAN
VLAN Name
10
VLAN0010
20
VLAN0020
30
VLAN0030
40
VLAN0040
Status
active
active
active
active
Ports
Task 4
Configure trunk ports on all up/up interfaces.
The command switchport trunk encapsulation dot1q on the interswitch links can be used to configure
802.1Q trunk. This is followed with the switchport mode trunk command that enables the interfaces for
static trunk configuration as shown below:
On SW1:
SW1(config)#interface range e2/1-2,e3/1-2
SW1(config-if-range)#switchport trunk encapsulation dot1q
SW1(config-if-range)#switchport mode trunk
On SW2:
SW2(config)#interface range e1/1-2,e3/1-2,e4/1-2,e5/1-2
SW2(config-if-range)#switchport trunk encapsulation dot1q
SW2(config-if-range)#switchport mode trunk
On SW3:
SW3(config)#interface range e1/1-2,e2/1-2,e4/1-2,e5/1-2
SW3(config-if-range)#switchport trunk encapsulation dot1q
SW3(config-if-range)#switchport mode trunk
On SW4:
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#switchport trunk encapsulation dot1q
SW4(config-if-range)#switchport mode trunk
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 193
On SW5:
SW4(config)#interface range e2/1-2,e3/1-2,e6/1-2
SW4(config-if-range)#switchport trunk encapsulation dot1q
SW4(config-if-range)#switchport mode trunk
On SW6:
SW5(config)#interface range e4/1-2,e5/1-2
SW5(config-if-range)#switchport trunk encapsulation dot1q
SW5(config-if-range)#switchport mode trunk
Let’s Explore 802.1s
One of the major drawbacks to spanning tree, be it the 802.1D Spanning Tree Protocol
or RSTP, is the fact that redundant links are blocked in the network, making their bandwidth
useless unless a failover event occurs. Cisco alleviated this impact by implementing
PVST/+ and PVRST/+, which allow administrators to load balance individual VLANs on
trunk links to better utilize the bandwidth.
The issue with this approach is that the switch must calculate a separate spanning tree
for each VLAN independently. As the total number of VLANs grows, the switch spends
more processor cycles calculating the spanning-tree topology. This is inefficient as the
total number of possible spanning-tree topologies is limited by the total number of
switches and links in the network. If there are only three switches in the network, then
there are effectively only three total topologies that can exist: one topology with each
switch as the root of the spanning tree. If there are a total of four VLANs in the same
sample network, it is reasonable to say that the fourth VLAN spanning-tree calculation
yields a redundant result to one of the previous three.
The IEEE 802.1s Multiple Spanning Tree Protocol (MST) standard mitigates this by providing
a standards-based way to run different instances of Spanning Tree Protocol on a
single switch. Instead of running a single instance for each VLAN, the administrator can
define the instances of Spanning Tree Protocol that will be run and their parameters, such
as priority and costs. Multiple VLANs are mapped to the configured instances, allowing
one instance to represent one or many VLANs.
With this construct, an administrator can group together VLANs with similar pathing
requirements in a single instance rather than tuning individual VLAN-specific spanningtree
instance settings. It is even possible to map all VLANs to a single instance and
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 194
reduce spanning-tree processing overhead for all VLANs. Doing this reduces the
computational load on the switches in the network.
The most noticeable way a switch saves computational cycles is through MST’s use of
a single BPDU for all instances. Instead of explicitly sending a BPDU for each VLAN or
each instance containing VLAN-to-instance mapping information, MST exchanges a single
BPDU. This BPDU contains information about the root bridge and special M-records.
These M-records carry the spanning-tree topology information for all instances configured
on the switch.
A switch running MST must be explicitly configured with the VLAN-to-instance mapping
in its MST configuration. The MST configuration first gives the MST process a
name. This process name is similar to the EIGRP autonomous system number. Then, the
process is explicitly given a revision number. Finally, the VLAN-to-instance mapping is
configured.
*NOTE: Unlike with EIGRP, there can be only one MST process running multiple instances
at a time on a switch. Cisco documentation calls the MST process an MST instance, but
for clarity between MST instances that have VLANs mapped to them, the term process is
used in this lab.
In order to operate, an MST network needs to be configured with the instances that
exist in the network and what VLANs are mapped to those instances. If, for example,
instance 1 on SWA contains VLAN 1 but instance 10 on SWB contains VLAN 1, SWA
and SWB could come to different conclusions about whether or not the port is forwarding
or blocking for both VLANs. However, because no explicit VLAN-to-Instance mapping
information is carried between switches, there is no way for two switches to know
whether or not they are configured similarly for MST operation.
MST validates VLAN-to-instance mapping consistency between two bridges by including
the MST process, the revision number, and a digest of the MST VLAN-to-instance
mapping table in the BPDU. If the received BPDU matches a switch’s internal configuration,
the switch knows it can trust the information contained in the M-records of the
BPDU. The set of switches in a network that all have matching MST process names, revision
numbers, and VLAN-to-instance mapping tables is called an MST region. Multiple
MST regions can exist in a network. Topology changes in one region do not affect other
regions. Also, each region builds an internal spanning tree separately as well as
cooperatively (between neighboring regions) with other regions to form one loop-free path
throughout the entire switched network.
Within a region, there always exists MST instance 0, which is called IST0. This instance
is the only instance that interacts with other regions and is the instance to which all
VLANs are initially mapped when MST is first enabled on a switch. IST0 elects a root
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 195
bridge called the IST0 root. A non-root switch calculates a loop-free path from itself to
the IST0 root. This ensures that no matter how many instances are added or VLANs are
moved around, there is always at least one loop-free path in the MST topology.
Switches exchange IST0 BPDUs that contain the M-records for all other instances in the
MST region. Using these records, independent spanning-tree topologies can be calculated
for each instance.
IST0 and M-records help create a loop-free path within an MST region. MST uses a separate
process to help negotiate a loop-free path between different MST regions. Switches
that connect to neighboring switches in different regions are called MST boundary
switches. The specific port that the local switch shares with the remote neighboring
switch in a different region is called the boundary port. On boundary ports, MST only
exchanges IST0 BPDU information. This makes sense because IST0 always exists within
the MST region and is guaranteed to be loop free at all times. The receiving switch
comparesthe IST0 bridge information to determine if it is superior or inferior to its own IST0
BPDU. This spanning tree running between regions is called the common spanning tree,
or CST.
It helps at this point to consider two MST regions as single switches. Because the boundary
switches hide the internal M-record topology from switches in different MST regions,
the topology becomes very simple from the receiving switch’s perspective. Because the
receiving switch cannot ensure that VLANs are mapped to the same instances as its own,
the receiving switch must make a blocking/forwarding decision on its boundary port for
all VLANs. This is the only way to ensure a loop-free path to the remote MST region.
The MST boundary switches only compare the IST0 information received from other
MST boundary switches. The boundary switches analyze this information and make
forwarding or discarding decisions for all VLANs on the boundary ports.
MST interacts with regular 802.1D spanning-tree regions in a similar way. A boundary
switch compares a received BPDU with its own IST0 BPDU to make a forwarding or
discarding decision for all VLANs on the boundary port. This process ensures that redundant
inter-region links are blocked between regions and not internally within a specific
region—in the same way a switch blocks ports between switches and not links within the
switch itself.
MST interacts with PVST regions a bit differently. This interaction is explained further
later on in this solution guide.
Task 1
Configure all the switches to utilize the following spanning-tree configuration for SW1,
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 196
SW2, and SW3:




MST is the operational mode.
The region name is 123.
The revision number is 1.
Configure the following instance-to-VLAN mappings:
 Instance 1: VLANs 10–19
 Instance 2: VLANs 20–29
 Instance 3: VLANs 30–39
 Instance 4: VLANs 40–49
This task sets the basic MST configuration settings for the network. MST can be enabled globally on the
switch using the spanning-tree mode mst command in global configuration mode. After configuration, the
switch automatically runs a single instance of MST with all VLANs mapped to it. This instance is the IST0
instance that always runs within an MST region, ensuring loop-free paths for all VLANs configured in the
region. Also, the revision number is initialized at 0 and the region name is considered null as shown below.
On SW1:
SW1#show spanning-tree mst configuration digest
Name
[]
Revision 0
Digest
Pre-std Digest
Instances configured 1
0xAC36177F50283CD4B83821D8AB26DE62
0xBB3B6C15EF8D089BB55ED10D24DF44DE
*Note*: The region name is synonymous to the aforementioned MST process name.
As stated previously, MST requires matching settings on all switches for the MST region name, revision
number, and VLAN-to-Instance mapping. These settings are configured in MST configuration mode. MST
configuration mode is accessed using the spanning-tree mst configuration command in global
configuration mode.
In this configuration mode, changes can be made to the MST configuration including, changing the region
name, incrementing the revision number, and modifying the VLAN-to-Instance mapping. Changes are
applied when exiting the MST configuration mode using the exit command. At any point in the
configuration, the show command can be used to see the pending changes to the MST configuration.
To complete the task, configure MST region name 123 with revision number 1. The name command is used
to specify the MST region name and the revision command specifies the current revision number. Omitting
the revision number and name causes the switch to automatically use a revision number of 0 and assign an
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 197
empty string to the name. Finally, the VLAN-to-Instance mapping is configured using the instance [instance
number] vlan [vlan-list] command for each instance configured as in the below:
On SW1:
SW1(config)#spanning-tree mst configuration
SW1(config-mst)#name 123
SW1(config-mst)#revision 1
SW1(config-mst)#instance 1 vlan 10-19
SW1(config-mst)#instance 2 vlan 20-29
SW1(config-mst)#instance 3 vlan 30-39
SW1(config-mst)#instance 4 vlan 40-49
SW1(config)#spanning-tree mode mst
On SW2:
SW2(config)#spanning-tree mst configuration
SW2(config-mst)#name 123
SW2(config-mst)#revision 1
SW2(config-mst)#instance 1 vlan 10-19
SW2(config-mst)#instance 2 vlan 20-29
SW2(config-mst)#instance 3 vlan 30-39
SW2(config-mst)#instance 4 vlan 40-49
SW2(config)#spanning-tree mode mst
On SW3:
SW3(config)#spanning-tree mst configuration
SW3(config-mst)#name 123
SW3(config-mst)#revision 1
SW3(config-mst)#instance 1 vlan 10-19
SW3(config-mst)#instance 2 vlan 20-29
SW3(config-mst)#instance 3 vlan 30-39
SW3(config-mst)#instance 4 vlan 40-49
SW3(config)#spanning-tree mode mst
The show spanning-tree mst configuration output displays the above region configuration on each switch.
On SW1, SW2, and SW3:
SWx#show spanning-tree mst configuration
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 198
Name
Revision
[123]
1
Instances configured 5
Instance
-------0
1
2
3
4
Vlans mapped
--------------------------1-9,50-4094
10-19
20-29
30-39
40-49
As we can see the VLANs that are not statically mapped they are automatically mapped to instance 0.
Task 2
Configure all the switches to utilize the following spanning-tree configuration for SW4,
SW5, and SW6:




MST is the operational mode.
The region name is 456.
The revision number is 1.
Configure the following instance-to-VLAN mappings:
 Instance 1: VLAN 10
 Instance 2: VLAN 20
 Instance 3: VLAN 30
 Instance 4: VLAN 40
Similar to the above task, this task configures a separate region in which SW4, SW5, and SW6 participate.
Notice how the region has a slightly different VLAN-to-Instance mapping table as well as a different region
name, configured below:
On SW4:
SW4(config)#spanning-tree mst configuration
SW4(config-mst)#name 456
SW4(config-mst)#revision 1
SW4(config-mst)#instance 1 vlan 10
SW4(config-mst)#instance 2 vlan 20
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 199
SW4(config-mst)#instance 3 vlan 30
SW4(config-mst)#instance 4 vlan 40
SW4(config)#spanning-tree mode mst
On SW5:
SW5(config)#spanning-tree mst configuration
SW5(config-mst)#name 456
SW5(config-mst)#revision 1
SW5(config-mst)#instance 1 vlan 10
SW5(config-mst)#instance 2 vlan 20
SW5(config-mst)#instance 3 vlan 30
SW5(config-mst)#instance 4 vlan 40
SW5(config)#spanning-tree mode mst
On SW6:
SW6(config)#spanning-tree mst configuration
SW6(config-mst)#name 456
SW6(config-mst)#revision 1
SW6(config-mst)#instance 1 vlan 10
SW6(config-mst)#instance 2 vlan 20
SW6(config-mst)#instance 3 vlan 30
SW6(config-mst)#instance 4 vlan 40
SW6(config)#spanning-tree mode mst
After configuring, the show spanning-tree mst configuration digest command can be used to verify the
MST database configurations between the two regions. It can be clearly seen that the region names and
configuration digest differ between the two configurations. This information is carried in the MST BPDU
sent between the switches. The switch compares the received digest information with that of its own. If it
matches, the switch knows the remote switch participates in the same MST region as itself. In the below,
the configuration digests on SW2 and SW4 are compared:
Example output from SW2 and SW4 for the digest comparison
On SW2:
SW2#show spanning-tree mst configuration digest
Name
[123]
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 200
Revision 1
Digest
Pre-std Digest
Instances configured 5
0xA5B19D386B025B4C642FE6DA07694259
0x43D31179EC2F20F3F0C5BF243BC569F3
On SW4:
SW4#show spanning-tree mst configuration digest
Name
[456]
Revision 1
Instances configured 5
Digest
0x566BFFFBE7C6CAAAA4ECE52E8A5D04BE
Pre-std Digest 0x15D7BEF8035C71289B5BBAF4E7D49A53
As an exercise, the region name on SW4 will be changed to match SW2. Notice that even though the
region names are the same, the differing MD5 digests will still prevent the switches from accepting each
other as participating in the same region. The MD5 calculation is generated from the VLAN-to-Instance
mapping table itself, providing an easier means of verifying its integrity from switch to switch. This digest
is calculated because, as stated earlier, the VLAN-to-Instance mapping table is NOT carried in the MST
BPDU.
! Example output from SW2 and SW4 for the digest comparison
SW2#show spanning-tree mst configuration digest
Name
[123]
Revision 1
Instances configured 5
Digest
0xA5B19D386B025B4C642FE6DA07694259
Pre-std Digest 0x43D31179EC2F20F3F0C5BF243BC569F3
SW4#show spanning-tree mst configuration digest
Name
[123]
Revision 1
Instances configured 5
Digest
0x566BFFFBE7C6CAAAA4ECE52E8A5D04BE
Pre-std Digest 0x15D7BEF8035C71289B5BBAF4E7D49A53
Task 3
Ensure that SW1 is the root for the entire topology.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 201
Similar to regular 802.1D spanning-tree, MST calculates a root bridge that is used as a reference point to
determine which ports should be blocked and which should be forwarding. MST uses the same logic as both
802.1D and 802.1w for selecting the root bridge; the only difference is a separate root bridge election
process is used for every instance configured in the MST region.
In the lab topology there are two MST regions. Each region will elect a root bridge for all instances within
their region, based on the lowest BID of all switches in the regions. The remaining switches will then work
out the loop-free spanning-tree topology for the entire layer 2 network. The problem comes in when a
decision must be made about the forwarding state of the links between the regions, specifically the
SW2/SW4, SW2/SW5, SW3/SW4, and SW3/SW5 links.
SW2/SW3 and SW4/SW5 participate in different MST regions and as a result have elected different switches
within their respective regions as the root bridge. Also, the two regions have VLANs mapped differently to
the specific instances running within the regions. Without this consistency and without a singular agreed
upon reference point, the switches cannot negotiate which of these links should be blocking or forwarding.
The network appears to be stuck.
MST alleviates these problems by utilizing the IST0 BPDU that is sent between MST switches. The IST0 BPDU
contains information about the IST0 root bridge elected in each MST region. Receiving MST switches
examine the received IST0 information and compare it to their own to determine which IST0 BPDU is
superior. The receiving switch ignores all other M-Record-related information in the accompanying BPDU.
The switch with the superior IST0 BID becomes the root switch for the entire topology. This election is held
using the same rules as 802.1D and 802.1w.
Once the two switches agree on the selection of a global root bridge, they can determine the state of their
ports on the link between them by interacting directly with the IST0 information received from the
neighboring MST switch. This interaction between the IST0 BPDUs of differing MST regions creates another
spanning-tree calculation called a Common Spanning-Tree or CST.
CST runs on the boundary links between two MST regions. The ports connecting these links are called
boundary ports and the switches with boundary ports are called boundary switches. A boundary switch
abstracts the internal MST configuration of another MST region by ignoring the M-record information
received as stated above. Instead, it treats the foreign region as if it were an STP switch, making a blocking
or forwarding decision for all VLANs based on the IST0 information in the received MST BPDU. Because IST0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 202
information is used to elect the CST root, there is a direct link between the IST0 root and the CST root. For a
switch in the MST region to become the CST root, it must also be the IST0 root in its own region. Thus, IST0
and CST are merged within the MST region on instance 0 as the Common and Internal Spanning-Tree or
CIST.
To complete the task, SW1 needs to become the root for the CST running between region 123 and region
456. To do that, SW1 must also become the root of the IST0 instance within its own region. The show
spanning-tree mst 0 output below on SW1 shows the current MST0 and CIST root.
On SW1:
SW1#show spanning-tree mst 0
##### MST0
Bridge
Root
Operational
Configured
vlans mapped:
1-9,50-4094
address aabb.cc00.1f00 priority
32768 (32768 sysid 0)
this switch for the CIST
hello time 2 , forward delay 15, max age 20, txholdcount 6
hello time 2 , forward delay 15, max age 20, max hops
20
Interface
Role Sts Cost
Prio.Nbr Type
---------------- ---- --- --------- -------- ----Et2/1
Desg FWD 2000000
128.10
P2p
Et2/2
Desg FWD 2000000
128.11
P2p
Et3/1
Desg FWD 2000000
128.14
P2p
Et3/2
Desg FWD 2000000
128.15
P2p
According to the above output, SW1 is already the CIST root for the topology. This is because SW1 has the
lowest MAC address in its own region. This IST0 information is compared on the boundary ports running
CST. For the same reason as above, the lower MAC address, SW1 is elected as the root for the CST. SW1 is
now the CIST root.
If SW1 were not the CIST root for any reason, its priority could be modified in the same way as in 802.1D and
802.1w. Because the goal is to affect the CST calculation, the priority change should be made on instance 0
of the MST configuration using the command spanning-tree mst 0 priority [priority-value] or spanning-tree
mst 0 root [primary | secondary] commands.
Task 4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 203
Configure Region 123 as follows:



SW1 should be the IST root for Instances 1 and 4.
SW2 should be the IST root for Instance 2.
SW3 should be the IST root for Instance 3.
This task demonstrates the internal topology flexibility of MST. Within a single MST region, different
switches can be the root bridge for individual instances. In this case, each instance equates to a separate
spanning-tree topology.
Applied to this task, each switch within Region 123 is going to be the root bridge for a particular instance.
This task can be solved with the spanning-tree mst [mst instance number] root primary command on SW1,
SW2 and SW3. Following this, the show spanning-tree mst [mst instance number] | include Root
command output can be used to verify the root bridge:
On SW1:
SW1(config)#spanning-tree mst 1,4 root primary
SW1#show spanning-tree mst 1,4
Root
Root
| include Root
this switch for MST1
this switch for MST4
On SW2:
SW2(config)#spanning-tree mst 2 root primary
SW2#show spanning-tree mst 2 | include Root
Root
this switch for MST2
On SW3:
SW3(config)#spanning-tree mst 3 root primary
SW3#show spanning-tree mst 3 | include Root
Root
this switch for MST3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 204
Configure Region 456 as follows:


SW6 should be the IST root for all instances except Instance 0.
SW5 should be the regional root.
In this task, SW6 is configured to become the root for all instances except Instance 0. The same
configuration steps used in the above can be used to achieve this result in this task.
On SW6:
SW6(config)#spanning-tree mst 1,2,3,4 root primary
SW6#show spanning-tree mst 1,2,3,4 | in Root
Root
Root
Root
Root
this switch for MST1
this switch for MST2
this switch for MST3
this switch for MST4
The next task specifies that SW5 should be considered the regional root switch. A regional root switch is the
switch within an MST region that possesses the best BPDU for the CIST root. This switch is designated as
the regional root switch and all inter-region traffic is forwarded through this switch. This concept makes
sense when examined.
Recall that at the region boundaries, MST switches abstract the received MST BPDU from a foreign region
by ignoring the specific M-Record information contained in the BPDU and only processing Instance 0
information. This means the two MST regions are represented to each other as one switch. With this analogy,
the physical switches that make up the MST region can be seen as individual “ports” of the region “switch”.
Applying normal spanning-tree operation to these “ports” the region “switch” must choose which of its
“ports” will be the root port used to reach the root bridge. In the lab example, there are two region
“switches”, “switch” 123, and “switch” 456. Region “switch” 123 is the root bridge of this two “switch”
network. Region “switch” 456 must choose which of its “ports” SW4 or SW5 will be the root port. It does
this by evaluating which “port” receives the best BPDU.
It is the result of this comparison where the MST region elects a regional switch. The regional switch is the
region’s root “port” towards the CIST root. All other switches solve the spanning-tree towards this switch.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 205
The task specifies that SW5 should be the regional root for region 456. The regional root is elected based
on the following criteria:
● Lowest external cost to reach the CIST root
● Lowest sender Bridge ID
The first point requires some special attention. When performing the calculation of cost to reach the CIST
root, only the external costs are incremented by the boundary switches. That is to say, the costs within
each region are not aggregated when the boundary switch relays BPDUs to its intra-region switch
neighbors.
To solve the task first the output of the show spanning-tree mst root command is compared between SW4
and SW5.
On SW4:
SW4#show spanning-tree mst 0 detail
##### MST0
Bridge
Root
vlans mapped:
1-9,11-19,21-29,31-39,41-4094
address aabb.cc00.2200 priority
32768 (32768 sysid 0)
address aabb.cc00.1f00 priority
32768 (32768 sysid 0)
port
Et2/1
path cost
2000000
Regional Root this switch
Operational
hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured
hello time 2 , forward delay 15, max age 20, max hops
20
---omitted for brevity---
On SW5:
SW5#show spanning-tree mst 0 detail
##### MST0
Bridge
Root
vlans mapped:
1-9,11-19,21-29,31-39,41-4094
address aabb.cc00.2300 priority
32768 (32768 sysid 0)
address aabb.cc00.1f00 priority
32768 (32768 sysid 0)
port
Et6/1
path cost
2000000
Regional Root address aabb.cc00.2200 priority
32768 (32768 sysid 0)
internal cost 4000000
rem hops 18
Operational
hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured
hello time 2 , forward delay 15, max age 20, max hops
20
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 206
--- omitted for brevity --SW4 and SW5 tie with an external cost of 2000000 to reach the CIST root. The next comparison is the BID of
which SW4 has the lower MAC address and is elected regional root. In order to make SW5 the new regional
root, either the cost assigned to its interfaces towards the current CIST root or its priority can be modified.
Because SW5 has multiple links pointing towards the CIST root, the lab will modify the priority value using
the spanning-tree mst 0 priority command.
Before doing so, care must be taken that SW5’s priority for IST0 does not fall below SW1’s priority. If SW5’s
priority value is lower than SW1’s for IST0, then SW5 will become the newly elected root for CIST. To
prevent this, first SW1’s priority should be set to a low value (the lab uses 0 as an example). Then, SW5’s
priority can be set to be lower than SW4’s accordingly.
On SW1 & SW4:
SWx(config)#spanning-tree mst 0 priority 0
On SW5:
SW5(config)#spanning-tree mst 0 priority 28672
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 207
Chapter 2
CCIE
Enterprise Infrastructure
Foundation
v1.0
www.MicronicsTraining.com
Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP
IP Prefix Lists
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 208
Lab 1
Prefix Lists
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
IP-Prefix-list folder  Lab-1.
Task 1
Configure R1 to filter 192.1.1.32/27 (an OSPF process ID 1 route) using a prefix list
through its G0/2 interface.
Beforing configuring the this task, following important facts about prefix-lists should be
kept in mind






Prefix lists were introduced in IOS 12.0(3)T.
Prefix-lists are configured to match on the actual prefix and the prefix length.
Prefix-lists are parsed and processed from the top to bottom. More accurately, from
the lowest sequence number to the highest sequence number.
Since sequence numbers are used, entries can be added or removed at any time.
Prefix-lists have an implicit deny all statement at the end just like access-lists.
Just like access-lists, prefix-lists can be used to identify, or filter prefixes.
The show ip route ospf command output from R1 is as follows:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 209
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
O
O
172.16.0.0/24 is subnetted, 4 subnets
172.16.0.0 [110/2] via 12.1.1.2, 00:19:29, GigabitEthernet0/2
172.16.1.0 [110/2] via 12.1.1.2, 00:19:29, GigabitEthernet0/2
172.16.2.0 [110/2] via 12.1.1.2, 00:19:29, GigabitEthernet0/2
172.16.3.0 [110/2] via 12.1.1.2, 00:19:29, GigabitEthernet0/2
192.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
192.1.1.1/32 [110/2] via 12.1.1.2, 00:19:29, GigabitEthernet0/2
192.1.1.32/27 [110/2] via 12.1.1.2, 00:19:29, GigabitEthernet0/2
As seen above, R1 has installed a few OSPF routes from R2. Of importance to this task demonstration are the
192.1.1.1/32 and 192.1.1.32/27 networks. This task requires configurations that result in filtering the
192.1.1.32/27 network from R1’s routing table.
A common question that arises often is - What is the difference between configuring a prefix-list and an
access-list?
To help illustrate the differences, let’s configure an access-list to deny any route to 192.1.1.0/24 from entering
the routing table on R1. As seen below, standard access list 1 is configured. The access-list 1 deny 192.1.1.0
0.0.0.255 statement denies the 192.1.1.0/24 network. The access-list 1 permit any command permits all
other networks.
R1(config)#access-list 1 deny 192.1.1.0 0.0.0.255
R1(config)#access-list 1 permit any
R1(config)#router ospf 1
R1(config-router)#distribute-list 1 in g0/2
Following this, a distribute-list under the OSPF router configuration mode is configured on R1. This
distribute-list references the access-list 1 created above. In addition, the distribute list is applied to the g0/2
interface on R1 in the in direction. For OSPF, this does not filter the actual LSAs, rather it causes R1 to filter
the routes as they are added to the routing table. In other words, it prevents routes that are not matched by the
distribute list from being installed into the local routing table. The in, in this context indicates “into R1's
routing table”. In this case, the distribute-list will use access-list 1 created earlier to find matches. Prefixes
that match a “permit” clause are permitted into the routing table while those that match a “deny” clause in the
route-map are not allowed (this includes the implicit deny at the end of all access-lists).
The show ip route ospf command is used to see the effects of the above configurations on R1:
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 210
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
172.16.0.0/24 is subnetted, 4 subnets
172.16.0.0 [110/2] via 12.1.1.2, 00:00:18, GigabitEthernet0/2
172.16.1.0 [110/2] via 12.1.1.2, 00:00:18, GigabitEthernet0/2
172.16.2.0 [110/2] via 12.1.1.2, 00:00:18, GigabitEthernet0/2
172.16.3.0 [110/2] via 12.1.1.2, 00:00:18, GigabitEthernet0/2
We can see that the access-list filtered both networks (192.1.1.1/32 and 192.1.1.32/27), because in the above
example, the access-list is denying prefixes that begin with “192.1.1” and have any other value in the 4th
octet, meaning the 4th octet can be any number.
What happens when a prefix list is used to filter the same network? The following configures such a prefix
list by first removing the previous configuration:
R1(config)#no access-list 1
R1(config)#router ospf 1
R1(config-router)#no distribute-list 1 in g0/2
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
O
O
172.16.0.0/24 is subnetted, 4 subnets
172.16.0.0 [110/2] via 12.1.1.2, 00:00:20, GigabitEthernet0/2
172.16.1.0 [110/2] via 12.1.1.2, 00:00:20, GigabitEthernet0/2
172.16.2.0 [110/2] via 12.1.1.2, 00:00:20, GigabitEthernet0/2
172.16.3.0 [110/2] via 12.1.1.2, 00:00:20, GigabitEthernet0/2
192.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
192.1.1.1/32 [110/2] via 12.1.1.2, 00:00:20, GigabitEthernet0/2
192.1.1.32/27 [110/2] via 12.1.1.2, 00:00:20, GigabitEthernet0/2
Next, a prefix-list called NET is configured on R1. The first prefix-list statement is configured to deny the
192.1.1.0/24 network with the ip prefix-list NET deny 192.1.1.0/24 command. The second statement is the
prefix-list equivalent of the access-list 1 permit any command. It basically matches any prefix with a prefix
length less than or equal to 32 and permits it. Since all prefixes have a prefix length less than or equal to 32,
all prefixes not matched by the explicit deny statement will be permitted by the prefix-list.
Following this, a new distribute-list is applied on R1 in the in direction for the G0/2 interface. This time
however, the distribute-list references the prefix-list NET:
R1(config)#ip prefix-list NET deny 192.1.1.0/24
R1(config)#ip prefix-list NET permit 0.0.0.0/0 le 32
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 211
R1(config)#router ospf 1
R1(config-router)#distribute-list prefix NET in g0/2
As we can see below, none of the networks (192.1.1.1/32, or 192.1.1.32/27) were affected:
To verify the configuration:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
O
O
172.16.0.0/24 is subnetted, 4 subnets
172.16.0.0 [110/2] via 12.1.1.2, 00:01:58, GigabitEthernet0/2
172.16.1.0 [110/2] via 12.1.1.2, 00:01:58, GigabitEthernet0/2
172.16.2.0 [110/2] via 12.1.1.2, 00:01:58, GigabitEthernet0/2
172.16.3.0 [110/2] via 12.1.1.2, 00:01:58, GigabitEthernet0/2
192.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
192.1.1.1/32 [110/2] via 12.1.1.2, 00:01:58, GigabitEthernet0/2
192.1.1.32/27 [110/2] via 12.1.1.2, 00:01:58, GigabitEthernet0/2
The reason is the difference between access-list filtering and prefix-list filtering. The access-list is only able
to match bits on the prefix itself while the prefix-list can match bits on both the prefix and the prefix length.
In the above example, since network 192.1.1.0/24 does NOT exist in the routing table on R1, none of the
networks were affected. With that understanding, let’s configure R1 to filter 192.1.1.32/27 and permit the
other prefixes using a prefix-list.
Note: The 192.1.1.0/24 entry in the routing table above is not an actual routing entry. It acts more like a folder
listing the routes that fall under that particular address range. In the case above, 192.1.1.1.32 and
192.1.1.32/27 are both components under 192.1.1.0/24.
First remove the IP prefix-list:
R1(config)#no ip prefix-list NET
Reconfigure the prefix-list NET:
R1(config)#ip prefix-list NET deny 192.1.1.32/27
R1(config)#ip prefix-list NET permit 0.0.0.0/0 le 32
The result of the above configuration can be seen in the show ip route ospf command output from R1 below.
Notice that ONLY 192.1.1.32/27 was filtered from the routing table. Unlike the results of the access-list
configuration, the 192.1.1.1 prefix is still present in the routing table:
To verify the configuration:
R1#show ip route ospf | begin Gate
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 212
Gateway of last resort is not set
O
O
O
O
O
172.16.0.0/24 is subnetted, 4 subnets
172.16.0.0 [110/2] via 12.1.1.2, 00:00:39, GigabitEthernet0/2
172.16.1.0 [110/2] via 12.1.1.2, 00:00:39, GigabitEthernet0/2
172.16.2.0 [110/2] via 12.1.1.2, 00:00:39, GigabitEthernet0/2
172.16.3.0 [110/2] via 12.1.1.2, 00:00:39, GigabitEthernet0/2
192.1.1.0/32 is subnetted, 1 subnets
192.1.1.1 [110/2] via 12.1.1.2, 00:00:39, GigabitEthernet0/2
When configuring prefix-lists, the prefix and the prefix-length MUST be configured to exactly match the
prefix and the prefix length of the prefix/network that we are trying to deny, permit, or identify. Otherwise,
the route will not be filtered in the routing table. In this way, prefix-lists are optimized for matching routes of
varying prefix/prefix-length combinations.\
NOTE: Notifce the 192.1.1.0/24 entry changed to a 192.1.1.0/32 entry in the above. This is because the only
remaining entry is a /32 entry 192.1.1.1/32. In this case, 192.1.1.0 is the major classful network. The prefix
length /32 is applied to all specific entries underneath that major network. Previously, because the router was
listing 192.1.1.1/32 and 192.1.1.32/27, it used the proper prefix length of /24 and individually listed the /32
and /27 prefix lengths that applied to both routes. This is normal IOS behavior.
Task 2
Configure R1 such that it only permits class A networks that are not subnetted and
filter the rest of the prefixes/networks. These are RIPv2 routes advertised by R3.
Before we configure the prefix-list, let’s observe the routing table of R1:
R1#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
1.0.0.0/8 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
10.0.0.0/24 is subnetted, 1 subnets
10.1.1.0 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
11.0.0.0/16 is subnetted, 1 subnets
11.1.0.0 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
22.0.0.0/24 is subnetted, 1 subnets
22.1.2.0 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
29.0.0.0/8 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
R
33.0.0.0/24 is subnetted, 1 subnets
33.0.0.0 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
R
R
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 213
R
R
44.0.0.0/8 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
201.1.3.0/24 [120/1] via 13.1.1.3, 00:00:12, GigabitEthernet0/3
This task states that ONLY class A networks that have NOT been subnetted should be allowed in the routing
table. In other words, subnetted Class A networks and all other networks should be filtered.
This statement carries the implication that while networks 10.1.1.0/24, 11.1.0.0/16, 22.1.2.0/24, 33.0.0.0/24
are Class A networks, they are subnets of the 10.0.0.0/8, 11.0.0.0/8 and 22.0.0.0/8 class A networks and
therefore should be filtered.
The reason those networks are considered subnets of major networks lies in what qualifies a particular
network as a Class A network. Class A networks are networks where the first bit of the first octet is set to 0.
For visual reference, see the picture below:
In the above, the letter “N” identifies the network bits and “H” identifies the host bits. Notice the leftmost bit
in the example is set to 0. The remaining “N” bits can be either 0 or 1. This limits the range of values for the
first octet to be 0-127. Any IP address that begins with 0-127 are considered Class A IP addresses, only
addresses 1-126 are usable as 0 and 127 are reserved. Class A networks all have a prefix-length of /8 meaning
the first octet identifies the network portion of the IP address.
To summarize the above, all class A networks have the following in common:
There are 8 total network bits in a class A network. The most significant bit (This is the bit in red) is
set to 0; therefore, there are 7 remaining network bits followed by 24 host bits.
● First Octet: 0 - 127
● 126 Class A networks exist (0 and 127 are reserved)
● 16,777,214 hosts in each Class A network
●
Because we know the most significant bit is equal to 0 in a class A network, it is possible to use a prefix-list
to match that specific bit using the prefix-length. Using a prefix length of /1 will match the first bit of the first
octet. We also know that a class A network has a /8 prefix-length. Thus any prefix-length attached to a Class
A network that isn’t a /8 has been subnetted.
Simply setting the prefix length to /1 is not enough. We need to make sure only true /8 networks exist in the
routing table. This is accomplished by using the ge and le options. The ge option stands for “greater than or
equal to and the le option stands for “less than or equal to”. These options are used to match a range of
prefix lengths.
Combining these two facts leads to the following configuration on R1:
On R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 214
R1(config)#ip prefix-list Class-A permit 0.0.0.0/1 ge 8 le 8
R1(config)#router rip
R1(config-router)#distribute-list prefix Class-A in g0/3
R1#clear ip route *
NOTE: Since we are filtering RIP routes, the filter will only apply to the next RIP update received by the
router. The clear ip route * command forces the router to send updates and re-evaluate the RIP routes to
reflect the distribute-list changes.
In the above, the prefix list statement for the “Class-A” prefix list is permit 0.0.0.0/1 ge 8 le 8. Breaking this
down, beginning after the “permit” line the 0.0.0.0/1 means to match any prefix that has the same first bit
as 0.0.0.0. In this case, the first bit of the prefix 0.0.0.0 is 0, which matches what the first bit of every class A
network should be. Next, the ge 8 le 8 means the prefix-length of the matched prefix can only be a number
that is both greater than or equal to 8 and less than or equal to 8. The only number that fulfills those criteria
is 8 itself. Thus, the prefix list will permit only the routes that are Class A networks which maintain their
default /8 prefix length.
This prefix-list is applied to a distribute-list configured in the in direction for routes coming in g0/3 on R1.
The distribute-list itself is configured under router RIP configuration mode. The effects of this configuration
can be seen in the below after clearing the RIP routes from the routing table using the “clear ip route”
command. Notice how only the class A networks that aren’t subnetted are present in the routing table now:
To verify the configuration:
R1#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
1.0.0.0/8 [120/1] via 13.1.1.3, 00:00:16, GigabitEthernet0/3
29.0.0.0/8 [120/1] via 13.1.1.3, 00:00:16, GigabitEthernet0/3
44.0.0.0/8 [120/1] via 13.1.1.3, 00:00:16, GigabitEthernet0/3
The above result can also be achieved by writing the above prefix-list to deny all subnetted class A networks
while permitting all class A networks that are not subnetted and all other networks (such as class B or class C
networks which are explained in the following tasks). Let’s configure and test:
On R1:
First remove the old prefix-list on R1:
R1(config)#no ip prefix-list Class-A
Next, configure the new prefix-list
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 215
R1(config)#ip prefix-list Class-A deny 0.0.0.0/1 ge 9
R1(config)#ip prefix-list Class-A permit 0.0.0.0/0 le 32
The first line of the prefix list read similar to the old version of the prefix list. Any prefix that starts with a
binary 0 will be matched by the 0.0.0.0/1 statement and denied. The last part also matches any prefix that is
greater than 9. This flows with the logic. If the first bit of the prefix is a 0, then we know it's a Class A
network. If the prefix-length is greater than or equal to 9 then we know it's been subnetted. This is because
the base prefix-length for a class A prefix is /8. If a prefix/length combination matches this line, it is denied.
The last line of the prefix-list allows all other networks, including class A networks with a mask of “/8” and
all class B, C, and D networks. The following verifies the configuration:
R1#clear ip route *
To verify the configuration:
R1#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
1.0.0.0/8 [120/1] via 13.1.1.3, 00:00:16, GigabitEthernet0/3
29.0.0.0/8 [120/1] via 13.1.1.3, 00:00:16, GigabitEthernet0/3
44.0.0.0/8 [120/1] via 13.1.1.3, 00:00:16, GigabitEthernet0/3
201.1.3.0/24 [120/1] via 13.1.1.3, 00:00:16, GigabitEthernet0/3
One good time saver when configuring prefix-lists is there is no need to configure the sequence numbers
since IOS will include them automatically in increments of 5. The following demonstrates this fact:
R1#show run | include ip prefix-list Class-A
ip prefix-list Class-A seq 5 deny 0.0.0.0/1 ge 9
ip prefix-list Class-A seq 10 permit 0.0.0.0/0 le 32
In the above, the prefix-list statements were entered in succession. IOS automatically assigned sequence
number 5 to the first statement entered and sequence 10 to the last. If another statement were added, it
would be assigned sequence number 15 (though no prefixes would match since all prefixes would match at
sequence 10).
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 216
Task 3
Configure R4 such that it only allows class B networks that are not subnetted. These
are OSPF routes advertised by R1.
Before the filter is configured and applied let’s check the routing table of R4:
On R4:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
O
O
128.1.0.0/16 [110/2] via 14.1.1.1, 01:21:01, GigabitEthernet0/1
131.1.0.0/16 [110/2] via 14.1.1.1, 01:21:01, GigabitEthernet0/1
180.1.0.0/24 is subnetted, 3 subnets
180.1.4.0 [110/2] via 14.1.1.1, 01:21:01, GigabitEthernet0/1
180.1.5.0 [110/2] via 14.1.1.1, 01:21:01, GigabitEthernet0/1
180.1.6.0 [110/2] via 14.1.1.1, 01:21:01, GigabitEthernet0/1
191.1.0.0/16 [110/2] via 14.1.1.1, 01:21:01, GigabitEthernet0/1
The routing table contains a collection of class B networks. According to the task requirements only class B
networks that are not subnetted should be allowed. This is a similar requirement as in Task 2, only this time
we are dealing with class B networks. The highlighted networks in the above are representative of
unsubnetted class B networks.
A class B network has the following bit pattern. Once again the letter “N” identifies the network bits and “H”
identifies the host bits.
Class B Networks are defined by the following:
● There are 16 total network bits. Of those bits, the most significant two bits in the first octet are set to
“10”; therefore, there are 14 network bits left to identify the networks and the remaining 16 bits
identify the host bits.
● With the first two bits set to “10” the Initial byte value can only be within the following range: 128 191
● 16,384 Class B networks exist
● 65,532 hosts on each Class B
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 217
Based on the above, if the most significant two bits of the first octet is set to “10” it is a class B network. The
prefix-list should be configured to match on the most significant two bit of the first octet by using a “/2”
prefix-length.
The following prefix-list matches on the most significant two bit of the first octet using a “/2” prefix-length,
with a network address of 128.0.0.0. The most significant two bits of the first octet of the decimal number
128 is “10” in binary which matches the designation for class B networks.
Since the task states that it should only allow class B networks that are not subnetted, the prefix-length
specifies “GE 16” and “LE 16”. This is because an unsubnetted class B network should have a prefix-length of
16.
The following configures this on R4 as indicated in the task. Once again, the prefix-list is applied to a
distribute-list that filters OSPF routes entering the routing table (in the in direction) on R4. Notice in the
output below, only class B networks that aren’t subnetted are present in the routing table:
R4(config)#ip prefix-list NET permit 128.0.0.0/2 ge 16 le 16
R4(config)#router ospf 1
R4(config-router)#distribute-list prefix NET in g0/1
To verify the configuration:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
128.1.0.0/16 [110/2] via 14.1.1.1, 00:00:48, GigabitEthernet0/1
131.1.0.0/16 [110/2] via 14.1.1.1, 00:00:48, GigabitEthernet0/1
191.1.0.0/16 [110/2] via 14.1.1.1, 00:00:48, GigabitEthernet0/1
Just like the previous task, the same result can be achieved by denying all class B networks that are
subnetted and permit only the class B networks that are NOT subnetted and all other network classes. Doing
so reinforces the understanding of prefix-length filtering. If a class B network has a prefix-length of 17 or
more, then it is a subnetted prefix. Let’s test and verify:
R4(config)#no ip prefix-list NET
R4(config)#ip prefix-list NET deny 128.0.0.0/2 ge 17
R4(config)#ip prefix-list NET permit 0.0.0.0/0 le 32
The first line of the prefix-list above denies any class B network that has a prefix-length of 17 or higher, which
means all the subnetted class B networks. The second allows the other networks to be installed in the routing
table, this includes Class B networks that are NOT subnetted.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 218
To verify the configuration:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
128.1.0.0/16 [110/2] via 14.1.1.1, 00:02:13, GigabitEthernet0/1
131.1.0.0/16 [110/2] via 14.1.1.1, 00:02:13, GigabitEthernet0/1
191.1.0.0/16 [110/2] via 14.1.1.1, 00:02:13, GigabitEthernet0/1
Task 4
Configure R5 such that it only allows class C networks that are not subnetted. These
are EIGRP routes that are advertised by R4.
Before this task is configured, we should verify the routing table on R5:
On R5:
R5#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
D
D
D
198.1.1.0/24 [90/130816] via 45.1.1.4, 02:45:34, GigabitEthernet0/4
199.1.1.0/24 [90/130816] via 45.1.1.4, 02:45:34, GigabitEthernet0/4
200.1.1.0/24 [90/130816] via 45.1.1.4, 02:45:34, GigabitEthernet0/4
200.1.4.0/29 is subnetted, 1 subnets
200.1.4.8 [90/130816] via 45.1.1.4, 02:45:34, GigabitEthernet0/4
200.1.5.0/30 is subnetted, 1 subnets
200.1.5.4 [90/130816] via 45.1.1.4, 02:45:34, GigabitEthernet0/4
223.1.1.0/24 [90/130816] via 45.1.1.4, 02:45:34, GigabitEthernet0/4
The output above is of several class C networks. According to the task requirements only class C networks
that are not subnetted should be allowed. This is a similar requirement as both Task 2 and Task 3, only this
time we are dealing with class C networks. As with the other tasks it helps to first identify what characterizes
a class C network.
Class C networks are identified with the following bit pattern. As with the previous tasks the letter “N”
identifies the network bits and “H” identifies the host bits.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 219
From the above, class C networks are defined as having the following:
● The first three octets are assigned to network bits and the last octet is assigned to host bits, leading to
24 network bits and 8 host bits
● Of the 24 network bits, the most significant three bits of the first octet are reserved to “110”.
● With the first three significant bits of the first byte reserved to “110”, the range of the first octet is 192
- 223
● 2,097,152 Class C networks exist
● Each class C network can handle 254 hosts
At this point the configuration explanation should be straightforward. The prefix list should match the first 3
bits of the first octet of the prefix 192.0.0.0. 192 in binary has “110” as the first three significant bits. Next, the
prefix-length should equal 24 using the ge 24 le 24 method.
The following is the configuration applied to a distribute-list configured in the in direction to filter routes
received on R5’s g0/4 interface:
On R5:
R5(config)#ip prefix-list NET permit 192.0.0.0/3 ge 24 le 24
R5(config)#router eigrp 1
R5(config-router)#distribute-list prefix NET in g0/4
You should proceed once you see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 45.1.1.4 (GigabitEthernet0/4) is
resync: intf route configuration changed
To verify the configuration:
R5#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
D
198.1.1.0/24 [90/130816] via 45.1.1.4, 02:55:54, GigabitEthernet0/4
199.1.1.0/24 [90/130816] via 45.1.1.4, 02:55:54, GigabitEthernet0/4
200.1.1.0/24 [90/130816] via 45.1.1.4, 02:55:54, GigabitEthernet0/4
223.1.1.0/24 [90/130816] via 45.1.1.4, 02:55:54, GigabitEthernet0/4
In the above, the only prefixes that are now added to the routing table are the unsubnetted class C networks.
The same result can be achieved by reversing the prefix-list to deny the subnetted class C networks and only
permit the class C networks that are not subnetted. The key here is, to explicitly deny the subnetted class C
networks, the matched prefix-length should be ge 25. This is an indication that any class C network with a
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 220
prefix-length 25 or greater has been subnetted. The same permit statement as configured previously is still
required to permit the unsubnetted class C networks:
R5(config)#no ip prefix-list NET
R5(config)#ip prefix-list NET deny 192.0.0.0/3 ge 25
R5(config)#ip prefix-list NET permit 192.0.0.0/3 ge 24 le 24
To verify the configuration:
R5#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
D
198.1.1.0/24 [90/130816] via 45.1.1.4, 00:00:17, GigabitEthernet0/4
199.1.1.0/24 [90/130816] via 45.1.1.4, 00:00:17, GigabitEthernet0/4
200.1.1.0/24 [90/130816] via 45.1.1.4, 00:00:17, GigabitEthernet0/4
223.1.1.0/24 [90/130816] via 45.1.1.4, 00:00:17, GigabitEthernet0/4
Task 5
Configure R4 such that it denies networks 10.4.4.33/27 and 10.4.5.65/26 and allows
the rest of the networks. You should configure a minimum number of lines in the
prefix list to accomplish this task. These are the RIPv2 routes advertised by R5.
This task carries a requirement to use the least amount of prefix-list statements as possible. Before
configuring the prefix-list, we should verify the existing routing table on R4:
On R4:
R4#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
10.4.4.32/27 [120/1] via 45.1.1.5, 00:00:06, GigabitEthernet0/5
10.4.5.64/26 [120/1] via 45.1.1.5, 00:00:06, GigabitEthernet0/5
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [120/1] via 45.1.1.5, 00:00:06, GigabitEthernet0/5
Whenever tasked to use the least number of lines to cover two prefixes, the best way to complete the task
is to find where the first change in the octets of the prefix occurs when both prefixes are converted to
binary. In this case, between 10.4.4.32 and 10.4.5.64, the first two octets are the same and the third and
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 221
fourth octets are different. Thus, we should focus on the third and fourth octets. The table below converts
these two octets to binary.
Once the third and the fourth octet of these two networks are converted to binary we will identify the
contiguous identical binary digits:
From the analysis above, we can see the first 7 bits of the third octet are identical. When combined with the
previous two octets of identical bits there is a total of 23 identical bits between the two prefixes. The
remaining bits (bit 8 of the third octet and the entire fourth octet) are converted to zeros and the entire
prefix is expressed in decimal to be 10.4.4.0. This is the prefix that should be matched in the prefix list that
will match both prefixes. Next, to match the first 23 bits, the /23 prefix-length is assigned to the prefix
making the first part of the prefix-list statement 10.4.4.0/23.
After figuring out the initial prefix, the next step is to match the prefix-length. The two prefixes have a /27
and /26 prefix length. To match them with a prefix-list we should use ge 26 le 27. The complete prefix-list
statement is deny 10.4.4.0/23 ge 26 le 27. Let’s configure the prefix-list and verify:
On R4:
R4(config)#ip prefix-list Task-5 deny 10.4.4.0/23 ge 26 le 27
R4(config)#ip prefix-list Task-5 permit 0.0.0.0/0 le 32
R4(config)#router rip
R4(config-router)#distribute-list prefix Task-5 in g0/5
R4#clear ip route *
To verify the configuration:
R4#show ip route rip | begin Gate
Gateway of last resort is not set
R
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [120/1] via 45.1.1.5, 00:00:07, GigabitEthernet0/5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 222
Task 6
Configure R5 to inject a default route in the RIP routing domain. If this configuration
is successful, R4 should see the default route in its routing table.
This task is in preparation for Task 7. R5 should be configured to send a default route to R4 through RIP. This
is accomplished using the default-information originate command in router rip configuration on R5 as
follows:
On R5:
R5(config)#router rip
R5(config-router)#default-information originate
R5#clear ip route *
To verify the configuration:
On R4:
R4#show ip route rip | begin Gate
Gateway of last resort is 45.1.1.5 to network 0.0.0.0
R*
R
0.0.0.0/0 [120/1] via 45.1.1.5, 00:00:06, GigabitEthernet0/5
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [120/1] via 45.1.1.5, 00:00:06, GigabitEthernet0/5
The result of the above configuration can be seen in R4’s routing table. As required by the task, R4 receives
the default route propagated by R5.
Task 7
R4 should be configured to filter the default route injected in the previous task.
On the surface, this task seems pretty straightforward. All we need to do is filter out the default route with a
prefix-list. However, previous configurations make this a bit more challenging. In Task 5 a prefix-list was
created and applied to a distribute-list in the in direction for the G0/5 interface as shown in the
configuration below:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 223
On R4:
R4#show run | section router rip
router rip
version 2
network 10.0.0.0
network 45.0.0.0
distribute-list prefix Task-5 in GigabitEthernet0/5
no auto-summary
One limitation of distribute-lists in route filtering is the fact that only a single distribute-list can be applied in
a single direction for the same interface. In other words, because a distribute-list is already configured in the
in direction for g0/5, a second distribute list cannot be configured. To complete the task, we must modify
the existing distribute-list’s prefix-list “Task-5” to explicitly deny the default route. The following show run
output shows the current prefix-list “Task-5” configuration:
R4#show run | include ip prefix-list Task-5
ip prefix-list Task-5 seq 5 deny 10.4.4.0/23 ge 24 le 27
ip prefix-list Task-5 seq 10 permit 0.0.0.0/0 le 32
The prefix-list “Task-5” has two statements with sequence numbers 5 and 10 respectively. The first
statement denies the two prefixes from Task 5. The last statement permits all other prefixes. This prefix-list
needs to be modified to deny the prefixes from Task 5 AND the default route for this task. The two deny
statements must come before the permit statement at sequence 10.
One way to accomplish the task is to simply remove the entire prefix-list and reconfigure it in the proper
order. An easier way, however, is to simply enter the new prefix-list statement and explicitly specify at what
sequence it should be inserted into the existing prefix-list “Task-5”. This is accomplished with the ip prefixlist prefix-list-name seq sequence-number command. This is done in 3 steps:
1. Identify what the new prefix-list statement should permit or deny
In this case, we are matching a default route with prefix 0.0.0.0/0. Thus our prefix-list statement should
deny 0.0.0.0/0.
2. Determine at what sequence number the new statement should be inserted
In this case, we need it to come before the permit 0.0.0.0/0 le 32 statement. A good place for this is at a
sequence number between the two existing statements. For this lab, sequence number 7 is chosen as it
serves as a good mid-way point between sequence 5 and 10.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 224
3. Combine the new statement with the determined sequence number
In this case the completed prefix-list statement should be ip prefix-list Task-5 seq 7 deny 0.0.0.0/0.
This configuration is applied on R4. The routing table on R4 no longer has a default route from and verified
in the following where R4’s routing table no longer has default route:
R4(config)#ip prefix-list Task-5 seq 7 deny 0.0.0.0/0
To verify the configuration:
R4#show run | inc ip prefix-list Task-5
ip prefix-list Task-5 seq 5 deny 10.4.4.0/23 ge 26 le 27
ip prefix-list Task-5 seq 7 deny 0.0.0.0/0
ip prefix-list Task-5 seq 10 permit 0.0.0.0/0 le 32
R4#clear ip route *
R4#show ip route rip | begin Gate
Gateway of last resort is not set
R
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [120/1] via 45.1.1.5, 00:00:07, GigabitEthernet0/5
Task 8
Configure R6 to filter any networks with a prefix length of 26 or less. These are
OSPF routes advertised by R5.
In this task, R6 should filter its OSPF routes received from R5 if they have a prefix-length less than or equal to 26. A
quick look at R6’s routing table reveals what prefixes we will be dealing with:
On R6:
R6#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
99.0.0.0/8 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
185.1.0.0/16 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 225
O
O
O
O
O
O
O
186.1.0.0/17 is subnetted, 1 subnets
186.1.128.0 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
189.1.0.0/24 is subnetted, 1 subnets
189.1.1.0 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
205.1.1.0/28 is subnetted, 1 subnets
205.1.1.240 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
206.1.1.0/30 is subnetted, 1 subnets
206.1.1.248 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
207.1.1.0/26 is subnetted, 1 subnets
207.1.1.192 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
208.1.1.0/25 is subnetted, 1 subnets
208.1.1.128 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [110/2] via 56.1.1.5, 03:27:56, GigabitEthernet0/5
The routing table on R6 shows prefixes with various prefix lengths such as : /8, /16, /17, /24, /25, /26, /27,
/28, and /30. To complete this task all prefixes with a prefix lengths /8, /16, /17, /24, /25 and /26 should be
removed from the routing table. At the end of all filtering only the 205.1.1.0/28, 206.1.1.0/30 and
211.4.4.0/27 prefixes should remain since the task requires R6 retaining these networks.
In this case, the prefix-list statement should be crafted to match any prefix so the 0.0.0.0/0 prefix is used.
Next, the prefix-list should match any prefix-length 26 and lower. The le 26 command accomplishes this
task. Combined the total prefix list statement is deny 0.0.0.0/0 le 26. Finally, all other prefixes need to be
allowed through using a permit 0.0.0.0/0 le 32 statement. The complete prefix-list is configured as follows
and applied to a distribute list in the in direction:
On R6:
R6(config)#ip prefix-list Task-8 deny 0.0.0.0/0 le 26
R6(config)#ip prefix-list Task-8 permit 0.0.0.0/0 le 32
R6(config)#router ospf 1
R6(config-router)#distribute-list prefix Task-8 in
The configuration is then verified using the show ip route ospf command. As the task requires, only prefixes
with prefix-length greater that /26 are present in the routing table:
To verify the configuration:
R6#show ip route ospf | begin Gate
Gateway of last resort is not set
O
205.1.1.0/28 is subnetted, 1 subnets
205.1.1.240 [110/2] via 56.1.1.5, 00:00:13, GigabitEthernet0/5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 226
O
O
206.1.1.0/30 is subnetted, 1 subnets
206.1.1.248 [110/2] via 56.1.1.5, 00:00:13, GigabitEthernet0/5
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [110/2] via 56.1.1.5, 00:00:13, GigabitEthernet0/5
Task 9
Reconfigure R6 to filter any networks with a prefix length of 26 or greater. These are
OSPF routes received from R5.
Task 9 configures the opposite of Task 8. This time all prefixes on R6 with a prefix-length greater than or
equal to 26 should be denied. As reminder, the following is the current routing table on R6:
On R6:
R6#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
205.1.1.0/28 is subnetted, 1 subnets
205.1.1.240 [110/2] via 56.1.1.5, 00:05:34, GigabitEthernet0/5
206.1.1.0/30 is subnetted, 1 subnets
206.1.1.248 [110/2] via 56.1.1.5, 00:05:34, GigabitEthernet0/5
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [110/2] via 56.1.1.5, 00:05:34, GigabitEthernet0/5
Before beginning, the previous prefix-list is removed and the resulting routing table is examined:
R6(config)#no ip prefix-list Task-8
To verify the configuration:
R6#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
99.0.0.0/8 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
185.1.0.0/16 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
186.1.0.0/17 is subnetted, 1 subnets
186.1.128.0 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
189.1.0.0/24 is subnetted, 1 subnets
189.1.1.0 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
205.1.1.0/28 is subnetted, 1 subnets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 227
O
O
O
O
O
205.1.1.240 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
206.1.1.0/30 is subnetted, 1 subnets
206.1.1.248 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
207.1.1.0/26 is subnetted, 1 subnets
207.1.1.192 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
208.1.1.0/25 is subnetted, 1 subnets
208.1.1.128 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
211.4.4.0/27 is subnetted, 1 subnets
211.4.4.32 [110/2] via 56.1.1.5, 00:00:26, GigabitEthernet0/5
To configure the task:
Now that the topology has been re-initialized, the prefix list is added again this time the deny statement
matches 0.0.0.0/0 ge 26 instead of 0.0.0.0/0 le 26.
R6(config)#ip prefix-list Task-8 deny 0.0.0.0/0 ge 26
R6(config)#ip prefix-list Task-8 permit 0.0.0.0/0 le 32
The result can be seen in R6’s routing table below. R6 now injects OSPF routes that have a prefix-length
lower than /26:
To verify the configuration:
R6#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
O
99.0.0.0/8 [110/2] via 56.1.1.5, 00:00:07, GigabitEthernet0/5
185.1.0.0/16 [110/2] via 56.1.1.5, 00:00:07, GigabitEthernet0/5
186.1.0.0/17 is subnetted, 1 subnets
186.1.128.0 [110/2] via 56.1.1.5, 00:00:07, GigabitEthernet0/5
189.1.0.0/24 is subnetted, 1 subnets
189.1.1.0 [110/2] via 56.1.1.5, 00:00:07, GigabitEthernet0/5
208.1.1.0/25 is subnetted, 1 subnets
208.1.1.128 [110/2] via 56.1.1.5, 00:00:07, GigabitEthernet0/5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 228
Task 10
Configure R7 to filter the following networks:





146.1.2.129/25
146.1.3.193/26
146.1.4.225/27
6.1.4.225/27
6.1.5.241/28
You should configure only three prefix list statements. These are EIGRP routes
advertised by R6.
This task is similar to Task number 5 where a single prefix-list statement was engineered to filter multiple
prefixes. In this task, using only three prefix-list statements, the above list of networks need to be filtered.
Before attempting to solve this task, the current routing table on R7 is examined to get a good idea of what
the current reality on R7 is:
On R7:
R7#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
D
D
D
D
D
D
D
6.0.0.0/8 is variably subnetted, 5 subnets, 5 masks
6.1.1.0/24 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
6.1.2.128/25 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
6.1.3.192/26 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
6.1.4.224/27 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
6.1.5.240/28 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
146.1.0.0/16 is variably subnetted, 5 subnets, 5 masks
146.1.1.0/24 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
146.1.2.128/25 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
146.1.3.192/26 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
146.1.4.224/27 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
146.1.5.240/28 [90/130816] via 67.1.1.6, 03:50:35, GigabitEthernet0/6
The highlighted prefixes are the targets of this task. There are only 3 prefix-list statements allowed. One
prefix-list statement should be dedicated to the permit 0.0.0.0/0 le 32 statement to allow all unmatched
prefixes to pass through the filter. That leaves 2 additional prefix-list statements. These statements should
be used to deny the highlighted prefixes above.
The remaining two prefix-list statements can be divided up between the two major networks represented
by the highlighted prefixes above the 6 and 146 networks. Beginning with the 146 networks the first two
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 229
octets are similar between all three prefixes, 146.1.2.128/25, 146.1.3.192/26, and 146.1.4.224/27. Utilizing
the same methodology as in Task-5, these octets are converted to binary and compared in the below:
In the third octet, the most significant 5 bits are identical. This means, the prefix-list statement should
match prefixes where the first 21 bits are identical (16 for the first two octets plus 5 from the third). The
remaining bits in the third octet and all bits in the 4th are set to zero and the whole prefix is converted back
to decimal yielding 146.1.0.0. Then the prefix-length /21 is applied to the prefix to indicate the first 21 bits
should match. The result is 146.1.0.0/21.
The next step is to determine what range of prefix-lengths should be matched by the prefix-list statement.
The three original prefixes have /25, /26, and /27 prefix-lengths. Therefore, any prefix length that is a 25,
26, or 27 should be matched. This is expressed by using the ge 25 le 27 statement.
Combining the two steps above leads to the following prefix-list statement:
ip prefix-list TST deny 146.1.0.0/21 ge 25 le 27
This prefix-list is applied to a distribute-list along with the permit 0.0.0.0/0 le 32 statement in the in
direction for the g0/6 interface on R7. This is in effort to verify the configuration before continuing to the
last set of prefixes:
R7(config)#ip prefix-list TST deny 146.1.0.0/21 ge 25 le 27
R7(config)#ip prefix-list TST permit 0.0.0.0/0 le 32
R7(config)#router eigrp 100
R7(config-router)#distribute-list prefix TST in g0/6
The routing table on R7 below verifies the prefix-list filtered the proper networks as the 146.1.2.128/25,
146.1.3.192/26, and 146.1.4.224/27 prefixes are not seen in the routing table.
To verify the configuration:
R7#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
6.0.0.0/8 is variably subnetted, 5 subnets, 5 masks
6.1.1.0/24 [90/130816] via 67.1.1.6, 00:00:24, GigabitEthernet0/6
6.1.2.128/25 [90/130816] via 67.1.1.6, 00:00:24, GigabitEthernet0/6
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 230
D
D
D
D
D
6.1.3.192/26 [90/130816] via 67.1.1.6, 00:00:24, GigabitEthernet0/6
6.1.4.224/27 [90/130816] via 67.1.1.6, 00:00:24, GigabitEthernet0/6
6.1.5.240/28 [90/130816] via 67.1.1.6, 00:00:24, GigabitEthernet0/6
146.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
146.1.1.0/24 [90/130816] via 67.1.1.6, 00:00:24, GigabitEthernet0/6
146.1.5.240/28 [90/130816] via 67.1.1.6, 00:00:24, GigabitEthernet0/6
Now that the “146” prefixes have been dealt with, attention can shift to the “6” prefixes, specifically
6.1.4.225/27 and 6.1.5.241/28 prefixes. First, the first octet where a difference is spotted is examined. This
is the third octet yet again. The third octet for both prefixes is converted to binary with the following
results:
In the third octet, the first seven bits are similar between the two prefixes. When combined with the
preceding two octets this means 23 bits in total are similar between the two prefixes. Converting the
remaining bits in the prefix to binary zero and converting back to decimal yields the prefix 6.1.4.0. Finally,
the 23 bits are matched using a /23 prefix to yield 6.1.4.0/23.
The next step again is to designate the range for the prefix-length. The two prefixes we are trying to match
have prefix-lengths of /27 and /28. Thus, the ge 27 le 28 statement should be used to cover those prefixes.
The complete prefix-list statement is deny 6.1.4.0/23 ge 27 le 28. This statement needs to be added to the
previous prefix-list TST before the last permit 0.0.0.0/0 le 32 statement. A quick show run | include ip
prefix-list TST on R7 verifies the current sequence set up for the TST prefix-list:
R7#show run | include ip prefix-list
ip prefix-list TST seq 5 deny 146.1.0.0/21 ge 25 le 27
ip prefix-list TST seq 10 permit 0.0.0.0/0 le 32
Similar to Task 7, the seq argument can be used along with the standard ip pefix-list command to insert the
new statement in the middle of the current list. Once again, seq 7 is applied to the statement in the
following:
R7#show ip prefix-list
ip prefix-list TST: 2 entries
seq 5 deny 146.1.0.0/21 ge 25 le 27
seq 10 permit 0.0.0.0/0 le 32
R7(config)#ip prefix-list TST seq 7 deny 6.1.4.0/23 ge 27 le 28
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 231
R7#show run | include ip prefix-list
ip prefix-list TST seq 5 deny 146.1.0.0/21 ge 25 le 27
ip prefix-list TST seq 7 deny 6.1.4.0/23 ge 27 le 28
ip prefix-list TST seq 10 permit 0.0.0.0/0 le 32
After configuring the prefix-list the show ip route eigrp | begin Gate command is used to verify the
configuration:
To verify the configuration:
R7#show ip route eigrp | begin Gate
Gateway of last resort is not set
6.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
D
D
D
D
D
6.1.1.0/24 [90/130816] via 67.1.1.6, 00:17:54, GigabitEthernet0/6
6.1.2.128/25 [90/130816] via 67.1.1.6, 00:17:54, GigabitEthernet0/6
6.1.3.192/26 [90/130816] via 67.1.1.6, 00:17:54, GigabitEthernet0/6
146.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
146.1.1.0/24 [90/130816] via 67.1.1.6, 00:17:54, GigabitEthernet0/6
146.1.5.240/28 [90/130816] via 67.1.1.6, 00:17:54, GigabitEthernet0/6
The show command output verifies the configuration is complete. Both the “146” and “6” networks
indicated in the task requirements have been denied using only 3 prefix-list statements.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 232
Task 11
Erase the startup configuration and reload the routers before proceeding to the next
lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 233
Chapter 3
CCIE
Enterprise Infrastructure
Foundation
v1.0
www.MicronicsTraining.com
Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP
RIPv2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 234
Lab 1
Configuring RIPv2
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
RIPv2 folder  Lab-1.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 235
Task 1
Configure RIPv2 on all routers and switches. Advertise their directly connected interfaces in
this routing domain. These devices should not have a classful nature. If this configuration is
successful, the routers and switches should successfully exchange routes.
Use the following policy when configuring this task:
1. R7 and R1 must use two static routes for reachability.
2. R1 and R4 must not use a static route(s). R1 cannot use any solution that’s used in
the previous policy or the next ones to provide reachability. You are allowed to
disable the sanity check.
3. You cannot use PBR to resolve any of the policies in this task.
4. The IP addresses configured on all the devices in the topology are correct.
The First Policy:
There are two versions of RIP for IPv4, RIPv2 and RIPv2. By default, on Cisco routers, RIP operates in
version 1 mode. To begin solving the first policy, as the task requires, the RIP version running between R1
and R7 is modified to RIPv2 with the version 2 command under the router rip configuration mode.
The task also explicitly specifies that the devices configured for RIP should not have a classful nature. This
alludes to turning off the automatic summarization when using RIPv2. By default, on IOS, RIP performs
automatic summarization of network prefixes when advertising prefixes across major classful network
boundaries.
This means, for example, if RIP were advertising the prefix 1.1.1.1/32 over an interface that was in the
192.168.1.0/24 subnet, RIP would summarize the update to 1.0.0.0/8 towards its neighbors in the
192.168.1.0/24 subnet. This is because the 1.1.1.1/32 network, a class A network, is crossing the major
classful network boundary 192.168.1.0/24, a class C network. This is the classful behaviour that the task
wants to prevent. Auto summarization for RIP is turned off with the no auto-summary command under the
RIP router configuration mode.
Both the above configurations are made on R1 and R7 as shown below:
On R1:
R1(config)#router rip
R1(config-router)#no auto-summary
R1(config-router)#version 2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 236
On R7:
R7(config)#router rip
R7(config-router)#no auto-summary
R7(config-router)#version 2
A show run | section router rip issued on R1 and R7 shows no RIP process has initialized on the routers.
R1#show run | section router rip
R1#
R7#show run | section router rip
R7#
The reason for this is that in order to initialize a RIP process, networks need to be first advertised into RIP.
For this purpose, the networks configured on the directly connected interfaces (including the loopback
addresses) on R1 and R7 are advertised into RIP with the network statement under the RIP router
configuration mode as seen below:
On R1:
R1(config)#router rip
R1(config-router)#network 10.0.0.0
R1(config-router)#network 12.0.0.0
R1(config-router)#network 14.0.0.0
R1(config-router)#network 200.1.1.0
On R7:
R7(config)#router rip
R7(config-router)#network 10.0.0.0
R7(config-router)#network 21.0.0.0
As a result of the above, the RIP database is populated with IP routes on R1 and R7 as seen below.
However, notice, the routing tables on both routers do not show any RIP learned routes from each other:
On R1:
R1#show ip rip database
10.0.0.0/8
auto-summary
10.1.100.0/24
directly connected, GigabitEthernet0/3
10.1.111.0/24
directly connected, GigabitEthernet0/7
12.0.0.0/8
auto-summary
12.1.1.0/24
directly connected, GigabitEthernet0/2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 237
14.0.0.0/8
14.1.1.0/24
200.1.1.0/24
200.1.1.0/24
auto-summary
directly connected, GigabitEthernet0/4
auto-summary
directly connected, GigabitEthernet0/9
R1#show ip route rip | begin Gate
Gateway of last resort is not set
! No RIP routes
On R7:
R7#show ip rip database
10.0.0.0/8
auto-summary
10.11.111.0/24
directly connected, GigabitEthernet0/1
21.0.0.0/8
auto-summary
21.1.0.0/16
directly connected, Loopback16
21.2.0.0/15
directly connected, Loopback15
21.4.0.0/14
directly connected, Loopback14
21.8.0.0/13
directly connected, Loopback13
21.16.0.0/12
directly connected, Loopback12
21.32.0.0/11
directly connected, Loopback11
21.64.0.0/10
directly connected, Loopback10
R7#show ip route rip | begin Gate
Gateway of last resort is not set
! No RIP routes
Observing the show run interface command output from R1 and R7 hints to the obvious problem. Notice
how the IP addresses configured on both routers on the interface that connect them are on different
networks:
On R1:
R1#show run interface g0/7 | include ip address
ip address 10.1.111.1 255.255.255.0
On R7:
R7#show run interface g0/1
| incclude ip address
ip address 10.11.111.111 255.255.255.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 238
A router running RIP will only accept RIP updates from its neighbor, if the source IP address of the RIP
update belongs to the same network as the local router’s receiving interface. This simply means, the
neighbor’s interface IP address should be on the same subnet as the local router’s interface that it is
connected to. Since the interface connecting R1 and R7 are configured in different networks, RIP updates
they send to each other are not accepted and are dropped. Enabling debugging for RIP with the debug ip
rip command on R1 confirms this process:
Jul 23 14:26:10.082: RIP: ignored v2 update from bad source
10.11.111.111 on GigabitEthernet0/7
IOS however provides a way to bypass this sanity check by using the no validate-update-source router
configuration command on R1 and R7. The command basically prevents a router from validating the source
IP address of the RIP update and accepting all updates. Notice in the output below, after issuing the no
validate-update-source command under the router rip configuration mode, R1 and R7’s routing tables are
now populated with RIP routes:
On R1:
R1(config)#router rip
R1(config-router)#no validate-update-source
R1#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
R
R
R
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/1] via 10.11.111.111, 00:00:23
21.2.0.0/15 [120/1] via 10.11.111.111, 00:00:23
21.4.0.0/14 [120/1] via 10.11.111.111, 00:00:23
21.8.0.0/13 [120/1] via 10.11.111.111, 00:00:23
21.16.0.0/12 [120/1] via 10.11.111.111, 00:00:23
21.32.0.0/11 [120/1] via 10.11.111.111, 00:00:23
21.64.0.0/10 [120/1] via 10.11.111.111, 00:00:23
On R7:
R7(config)#router rip
R7(config-router)#no validate-update-source
R7#show ip route rip | begin Gate
Gateway of last resort is not set
R
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
10.1.100.0/24 [120/1] via 10.1.111.1, 00:00:15
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 239
R
R
R
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [120/1] via 10.1.111.1, 00:00:15
14.0.0.0/24 is subnetted, 1 subnets
14.1.1.0 [120/1] via 10.1.111.1, 00:00:15
200.1.1.0/24 [120/1] via 10.1.111.1, 00:00:15
To test reachability, a ping is then issued from R1 to R7’s loopback 12 IP address 21.16.1.1. The ping fails,
and the result of debug ip packet displays the message unroutable:
On R1:
R1#debug ip packet
R1#ping 21.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.16.1.1, timeout is 2 seconds:
.....
*Jul 23 14:34:10.390: IP: s=10.1.100.1 (local), d=21.16.1.1, len 100,
unroutable.
The unroutable message is displayed because the router R1 does not know where to send the packet.
Since the ping is intended to an address on R7, R1 should send the packet to R7’s interface 10.11.111.111.
In other words, the next hop IP address for the 21.16.1.1 should be 10.11.111.111. This is confirmed below:
R1#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
R
R
R
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/1] via 10.11.111.111, 00:00:23
21.2.0.0/15 [120/1] via 10.11.111.111, 00:00:23
21.4.0.0/14 [120/1] via 10.11.111.111, 00:00:23
21.8.0.0/13 [120/1] via 10.11.111.111, 00:00:23
21.16.0.0/12 [120/1] via 10.11.111.111, 00:00:23
21.32.0.0/11 [120/1] via 10.11.111.111, 00:00:23
21.64.0.0/10 [120/1] via 10.11.111.111, 00:00:23
Even though the router has the proper route to the destination network, in order to forward the packet, it
needs to know out of which interface it should forward the packet. The route above to reach the 21.16.1.1
network does not lead to an exit interface, but to a next-hop IP address. In order to forward the packet to
the next-hop, it needs to perform a second routing lookup to determine out of which interface to forward
the packet to reach the indicated next-hop.
The problem in this scenario is R1 does not have a route to reach the next-hop 10.11.111.111 (R7). The
show ip cef 10.11.111.111 output below confirms this.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 240
R1#show ip cef 10.11.111.111
10.11.111.111/32
no route
Lacking this route, R1 cannot forward packets using the routing entry. The same issue plagues R7. It does
not have a route to reach R1’s interface address that connects the two routers. This is the situation the RIP
sanity check is intended to prevent. A situation where two routers do not have routes to reach each other
even though routes are advertised between them. This is because R1 and R7’s directly-connected
interfaces are not in the same subnet. Normally, the two interfaces would be in the same subnet.
Reachability to the next-hops would be provided by a connected route in the routing table for the direct
connection.
To solve this problem, two static routes can be configured, one on R1 for R7’s next-hop and one on R7 for
R1’s next-hop. The key here is that these static route should have an exit interface of the direct connection
between R1 and R7. On R1, the route should point to 10.11.111.111/32 with an exit interface of g0/7 and
on R7 it should point to 10.1.111.1/32 with an exit interface of g0/1 as shown below:
R1(config)#ip route 10.11.111.111 255.255.255.255 g0/7
On R7:
R7(config)#ip route 10.1.111.1 255.255.255.255 g0/1
Previous ping from R1 to 21.16.1.1 is repeated. It succeeds as shown below:
On R1:
R1#ping 21.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Continuing with completing the Task, R2 is configured to run RIPv2. Similar to the above, auto
summarization is turned off, R2 is configured for RIPv2 and the directly connected interfaces are advertised
into RIP:
On R2:
R2(config)#router rip
R2(config-router)#no auto-summary
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 241
R2(config-router)#version 2
R2(config-router)#network 12.0.0.0
R2(config-router)#network 24.0.0.0
R2(config-router)#network 28.0.0.0
The show ip route rip command shows the RIP routes R2 learns from R1. These include the directly
connected networks on R1 and the RIP routes R1 learns from R7:
R2#show ip route rip | begin Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
R
10.1.100.0/24 [120/1] via 12.1.1.1, 00:00:24,
GigabitEthernet0/1
R
10.1.111.0/24 [120/1] via 12.1.1.1, 00:00:24,
GigabitEthernet0/1
R
10.11.111.111/32 [120/1] via 12.1.1.1, 00:00:24,
GigabitEthernet0/1
14.0.0.0/24 is subnetted, 1 subnets
R
14.1.1.0 [120/1] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
R
21.1.0.0/16 [120/2] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
R
21.2.0.0/15 [120/2] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
R
21.4.0.0/14 [120/2] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
R
21.8.0.0/13 [120/2] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
R
21.16.0.0/12 [120/2] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
R
21.32.0.0/11 [120/2] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
R
21.64.0.0/10 [120/2] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
R
200.1.1.0/24 [120/1] via 12.1.1.1, 00:00:24, GigabitEthernet0/1
Next, R3 is configured to run RIPv2. Following the pattern so far, auto summary is disabled and the
networks on the directly connected are advertised into RIP:
On R3:
R3(config)#router rip
R3(config-router)#no auto-summary
R3(config-router)#version 2
R3(config-router)#network 3.0.0.0
R3(config-router)#network 10.0.0.0
R3(config-router)#network 113.0.0.0
R3(config-router)#network 200.1.1.0
The routing table on R3 as seen with the show ip route rip command output below shows R3 learns
various RIP routes over the G0/1 and G0/9 interfaces connected to R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 242
R3#show ip route rip | begin Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
R
10.1.111.0/24 [120/1] via 200.1.1.1, 00:00:22,
GigabitEthernet0/9
[120/1] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
R
10.11.111.111/32 [120/1] via 200.1.1.1, 00:00:22,
GigabitEthernet0/9
[120/1] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
12.0.0.0/24 is subnetted, 1 subnets
R
12.1.1.0 [120/1] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/1] via 10.1.100.1, 00:00:14, GigabitEthernet0/1
14.0.0.0/24 is subnetted, 1 subnets
R
14.1.1.0 [120/1] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/1] via 10.1.100.1, 00:00:14, GigabitEthernet0/1
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
R
21.1.0.0/16 [120/2] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
R
21.2.0.0/15 [120/2] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
R
21.4.0.0/14 [120/2] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
R
21.8.0.0/13 [120/2] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
R
21.16.0.0/12 [120/2] via 200.1.1.1, 00:00:22,
GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
R
21.32.0.0/11 [120/2] via 200.1.1.1, 00:00:22,
GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
R
21.64.0.0/10 [120/2] via 200.1.1.1, 00:00:22,
GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14,
GigabitEthernet0/1
24.0.0.0/24 is subnetted, 1 subnets
R
24.1.1.0 [120/2] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14, GigabitEthernet0/1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 243
R
28.0.0.0/24 is subnetted, 1 subnets
28.1.1.0 [120/2] via 200.1.1.1, 00:00:22, GigabitEthernet0/9
[120/2] via 10.1.100.1, 00:00:14, GigabitEthernet0/1
Policy 2
R4 is now configured to run RIPv2. However, looking at the diagram, we see that the IP addresses
configured on R1 and R4 for the link connecting them belong to different networks:
R1:
interface GigabitEthernet0/4
ip address 14.1.1.1 255.255.255.0
R4:
interface GigabitEthernet0/1
ip address 41.1.1.4 255.255.255.0
As already explained earlier, a router will accept RIP updates only if the source IP address belongs to the
same subnet as the receiving interface. Since both R1 and R4 have their common interfaces in different
subnets, they will reject each other's RIP updates. This issue was resolved earlier by disabling the sanity
check with no validate-update-source command.
In addition, both R1 and R4 will not have routes to the IP addresses assigned to their connecting interfaces.
This issue was resolved earlier with the use of static routes. This task however, restricts the use of the
same solution. So another way to resolve the reachability issue would be to use PPPoE.
With PPPoE configured, host routes are created and exchanged. The host routes end up pointing to the
neighboring router’s interface, facing the local router. The following PPPoE related configurations are
made on R1 and R4:
On R1:
R1(config)#interface g0/4
R1(config-if)#no ip address
R1(config-if)#interface virtual-template 14
R1(config-if)#ip address 14.1.1.1 255.255.255.0
R1(config-if)#peer default ip address pool R4
R1(config-if)#ip local pool R4 41.1.1.4 41.1.1.4
R1(config)#bba-group pppoe tst
R1(config-bba-group)#virtual-template 14
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 244
R1(config-bba-group)#interface g0/4
R1(config-if)#pppoe enable group tst
R1(config-if)#no shut
On R4:
R4(config-if)#interface dialer 41
R4(config-if)#encapsulation ppp
R4(config-if)#ip address negotiated
R4(config-if)#dial pool 100
R4(config-if)#interface g0/1
R4(config-if)#pppoe-client dial-pool-number 100
R4(config-if)#no shut
On completing the above, the show ip route connected command output on R1 shows the host route
installed for R4’s interface address, 41.1.1.4. Note : If you don’t see the host route, a shutdown and a no
shutdown needs to be issued:
On R1:
R1#show ip route connected | begin Gateway
41.0.0.0/32 is subnetted, 1 subnets
C
41.1.1.4 is directly connected, Virtual-Access2.1
A ping to the 14.1.1.1 address from R4 verifies rechability as seen below:
On R4:
R4#ping 14.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 14.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Next, R1 and R4 are configured for RIPv2. Once again, auto summarization is disabled and the networks on
the directly connected interfaces on R4 is advertised into RIP. The command no validate-update-source is
also configured under the RIP process on R4 to prevent the same subnet sanity check for RIP. Note : The
same needs to be configured on R1. This was taken care of in policy 1.
On R4:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 245
R4(config)#router rip
R4(config-router)#no auto-summary
R4(config-router)#version 2
R4(config-router)#network 46.0.0.0
R4(config-router)#network 45.0.0.0
R4(config-router)#network 41.0.0.0
R4(config-router)#network 24.0.0.0
R4(config-router)#network 10.0.0.0
R4(config-router)#no validate-update-source
The show ip route rip | begin Gate output verifies R4 learns all RIP routes from R1. Same is verified on R1
with the show ip route rip | include via 41.1.1.4 command:
R4#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
3.0.0.0/24 is subnetted, 4 subnets
3.3.0.0 [120/2] via 14.1.1.1, 00:00:25
3.3.1.0 [120/2] via 14.1.1.1, 00:00:25
3.3.2.0 [120/2] via 14.1.1.1, 00:00:25
3.3.3.0 [120/2] via 14.1.1.1, 00:00:25
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
10.1.100.0/24 [120/1] via 14.1.1.1, 00:00:25
10.1.111.0/24 [120/1] via 14.1.1.1, 00:00:25
10.11.111.111/32 [120/1] via 14.1.1.1, 00:00:25
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [120/1] via 24.1.1.2, 00:00:01, GigabitEthernet0/2
[120/1] via 14.1.1.1, 00:00:25
14.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
14.1.1.0/24 [120/2] via 24.1.1.2, 00:00:01, GigabitEthernet0/2
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/2] via 14.1.1.1, 00:00:25
21.2.0.0/15 [120/2] via 14.1.1.1, 00:00:25
21.4.0.0/14 [120/2] via 14.1.1.1, 00:00:25
21.8.0.0/13 [120/2] via 14.1.1.1, 00:00:25
21.16.0.0/12 [120/2] via 14.1.1.1, 00:00:25
21.32.0.0/11 [120/2] via 14.1.1.1, 00:00:25
21.64.0.0/10 [120/2] via 14.1.1.1, 00:00:25
28.0.0.0/24 is subnetted, 1 subnets
28.1.1.0 [120/1] via 24.1.1.2, 00:00:01, GigabitEthernet0/2
200.1.1.0/24 [120/1] via 14.1.1.1, 00:00:25
On R1:
R1#show ip route rip | include via 41.1.1.4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 246
R
R
R
R
10.1.4.0/24 [120/1] via 41.1.1.4, 00:00:28
24.1.1.0 [120/1] via 41.1.1.4, 00:00:28
45.1.1.0 [120/1] via 41.1.1.4, 00:00:28
46.1.1.0 [120/1] via 41.1.1.4, 00:00:28
Before a ping to R7’s loopback 12 IP address 21.16.1.1 from R4 is performed, one final configuration is
made on R1. The host route 41.1.1.4 is added to the RIP database on R1 with the network command to
provide rechability to this address from other routers in the RIP domain. A ping to the 21.16.1.1 address is
then shown to succeed below:
R1(config)#router rip
R1(config-router)#network 41.0.0.0
On R4:
R4#ping 21.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Next, RIP is configured on R5. As above, R5 is configure to run RIPv2, auto summarization is disabled and
the directly connected interfaces on R5 are advertised into RIPv2 as shown below:
On R5:
R5(config)#router rip
R5(config-router)#no auto-summary
R5(config-router)#version 2
R5(config-router)#network 50.0.0.0
R5(config-router)#network 211.1.1.0
R5(config-router)#network 212.1.1.0
R5(config-router)#network 45.0.0.0
R5(config-router)#network 10.0.0.0
On configuring the above, the show ip route rip command output below verifies the RIP routes R5 learns
from its RIP neighbor:
R5#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
3.0.0.0/24 is subnetted, 4 subnets
3.3.0.0 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
3.3.1.0 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 247
R
R
3.3.2.0 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
3.3.3.0 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
R
10.1.4.0/24 [120/1] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
10.1.100.0/24 [120/2] via 45.1.1.4, 00:00:02,
GigabitEthernet0/4
R
10.1.111.0/24 [120/2] via 45.1.1.4, 00:00:02,
GigabitEthernet0/4
R
10.11.111.111/32 [120/2] via 45.1.1.4, 00:00:02,
GigabitEthernet0/4
12.0.0.0/24 is subnetted, 1 subnets
R
12.1.1.0 [120/2] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
14.0.0.0/24 is subnetted, 1 subnets
R
14.1.1.0 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
R
21.1.0.0/16 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.2.0.0/15 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.4.0.0/14 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.8.0.0/13 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.16.0.0/12 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.32.0.0/11 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.64.0.0/10 [120/3] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
24.0.0.0/24 is subnetted, 1 subnets
R
24.1.1.0 [120/1] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
28.0.0.0/24 is subnetted, 1 subnets
R
28.1.1.0 [120/2] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
41.0.0.0/32 is subnetted, 1 subnets
R
41.1.1.4 [120/1] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
46.0.0.0/24 is subnetted, 1 subnets
R
46.1.1.0 [120/1] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
R
200.1.1.0/24 [120/2] via 45.1.1.4, 00:00:02, GigabitEthernet0/4
A ping to the 21.16.1.1 address issued to verify rechability from R5 succeeds:
R5#ping 21.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms
R6 is configured to run RIPv2 next. Again, similar to the above configurations, auto summary is disabled
and the networks on the directly connected interfaces are advertised into RIPv2:
On R6:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 248
R6(config)#router rip
R6(config-router)#no auto-summary
R6(config-router)#version 2
R6(config-router)#network 46.0.0.0
R6(config-router)#network 211.1.1.0
R6(config-router)#network 212.1.1.0
R6(config-router)#network 10.0.0.0
The routing table on R6 verifies the RIP routes learned from its neighbors:
R6#show ip route rip | begin Gate
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 4 subnets
R
3.3.0.0 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
3.3.1.0 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
3.3.2.0 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
3.3.3.0 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
R
10.1.4.0/24 [120/1] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
10.1.100.0/24 [120/2] via 46.1.1.4, 00:00:02,
GigabitEthernet0/4
R
10.1.111.0/24 [120/2] via 46.1.1.4, 00:00:02,
GigabitEthernet0/4
R
10.11.111.111/32 [120/2] via 46.1.1.4, 00:00:02,
GigabitEthernet0/4
12.0.0.0/24 is subnetted, 1 subnets
R
12.1.1.0 [120/2] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
14.0.0.0/24 is subnetted, 1 subnets
R
14.1.1.0 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
R
21.1.0.0/16 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.2.0.0/15 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.4.0.0/14 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.8.0.0/13 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.16.0.0/12 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.32.0.0/11 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
R
21.64.0.0/10 [120/3] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
24.0.0.0/24 is subnetted, 1 subnets
R
24.1.1.0 [120/1] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
28.0.0.0/24 is subnetted, 1 subnets
R
28.1.1.0 [120/2] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
41.0.0.0/32 is subnetted, 1 subnets
R
41.1.1.4 [120/1] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
45.0.0.0/24 is subnetted, 1 subnets
R
45.1.1.0 [120/1] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 249
R
R
[120/1] via 10.1.1.5, 00:00:27, GigabitEthernet0/9
50.0.0.0/24 is subnetted, 1 subnets
50.5.5.0 [120/1] via 10.1.1.5, 00:00:27, GigabitEthernet0/9
200.1.1.0/24 [120/2] via 46.1.1.4, 00:00:02, GigabitEthernet0/4
A ping to the 21.16.1.1 is issued to verify end to end rechability from R6:
R6#ping 21.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/6 ms
The following configuration activates RIPv2 on SW4 and disables auto summarization. The network
10.0.0.0 command is used to enable RIP on the VLAN 10 SVI of SW4 and advertise that subnet out all other
RIP-enabled interfaces. Note: In order to allow Layer 3 switches to perform IP routing, IP routing needs to
be enabled on the switches with the ip routing global configuration command.
On SW4:
SW4(config)#ip routing
SW4(config)#router rip
SW4(config-router)#no auto-summary
SW4(config-router)#version 2
SW4(config-router)#network 10.0.0.0
The show ip route rip command output on SW4 verifies the RIP routes learned by SW4. Note, it may take
up to 30 seconds for the routes to be populated.
SW4#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
R
3.0.0.0/24 is subnetted, 4 subnets
3.3.0.0 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
3.3.1.0 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
3.3.2.0 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
3.3.3.0 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
10.1.4.0/24 [120/2] via 10.1.1.6, 00:00:04, Vlan10
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 250
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
[120/2] via 10.1.1.5, 00:00:16, Vlan10
10.1.100.0/24 [120/3] via 10.1.1.6, 00:00:04, Vlan10
[120/3] via 10.1.1.5, 00:00:16, Vlan10
10.1.111.0/24 [120/3] via 10.1.1.6, 00:00:04, Vlan10
[120/3] via 10.1.1.5, 00:00:16, Vlan10
10.11.111.111/32 [120/3] via 10.1.1.6, 00:00:04, Vlan10
[120/3] via 10.1.1.5, 00:00:16, Vlan10
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [120/3] via 10.1.1.6, 00:00:04, Vlan10
[120/3] via 10.1.1.5, 00:00:16, Vlan10
14.0.0.0/24 is subnetted, 1 subnets
14.1.1.0 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
21.2.0.0/15 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
21.4.0.0/14 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
21.8.0.0/13 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
21.16.0.0/12 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
21.32.0.0/11 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
21.64.0.0/10 [120/4] via 10.1.1.6, 00:00:04, Vlan10
[120/4] via 10.1.1.5, 00:00:16, Vlan10
24.0.0.0/24 is subnetted, 1 subnets
24.1.1.0 [120/2] via 10.1.1.6, 00:00:04, Vlan10
[120/2] via 10.1.1.5, 00:00:16, Vlan10
28.0.0.0/24 is subnetted, 1 subnets
28.1.1.0 [120/3] via 10.1.1.6, 00:00:04, Vlan10
[120/3] via 10.1.1.5, 00:00:16, Vlan10
41.0.0.0/32 is subnetted, 1 subnets
41.1.1.4 [120/2] via 10.1.1.6, 00:00:04, Vlan10
[120/2] via 10.1.1.5, 00:00:16, Vlan10
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [120/1] via 10.1.1.5, 00:00:16, Vlan10
46.0.0.0/24 is subnetted, 1 subnets
46.1.1.0 [120/1] via 10.1.1.6, 00:00:04, Vlan10
50.0.0.0/24 is subnetted, 1 subnets
50.5.5.0 [120/1] via 10.1.1.5, 00:00:16, Vlan10
200.1.1.0/24 [120/3] via 10.1.1.6, 00:00:04, Vlan10
[120/3] via 10.1.1.5, 00:00:16, Vlan10
211.1.1.0/24 [120/1] via 10.1.1.6, 00:00:04, Vlan10
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 251
R
[120/1] via 10.1.1.5, 00:00:16, Vlan10
212.1.1.0/24 [120/1] via 10.1.1.6, 00:00:04, Vlan10
[120/1] via 10.1.1.5, 00:00:16, Vlan10
A ping to the 26.16.1.1 address on R7 from SW4 verifies rechability:
SW4#ping 21.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
Next, RIPv2 is configured on R8. Again, auto summary is turned off and the networks on the directly
connected interfaces on R8 is advertised into RIPv2:
On R8:
R8(config)#router rip
R8(config-router)#no auto-summary
R8(config-router)#version 2
R8(config-router)#network 28.0.0.0
The routing table on R8 verifies the RIP routes on R8:
R8#show ip route rip | begin Gate
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 4 subnets
3.3.0.0 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
3.3.1.0 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
3.3.2.0 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
3.3.3.0 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
R
10.1.1.0/24 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
R
10.1.4.0/24 [120/2] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
R
10.1.100.0/24 [120/2] via 28.1.1.2, 00:00:23,
GigabitEthernet0/2
R
10.1.111.0/24 [120/2] via 28.1.1.2, 00:00:23,
GigabitEthernet0/2
R
10.11.111.111/32 [120/2] via 28.1.1.2, 00:00:23,
GigabitEthernet0/2
12.0.0.0/24 is subnetted, 1 subnets
R
12.1.1.0 [120/1] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
14.0.0.0/24 is subnetted, 1 subnets
R
14.1.1.0 [120/2] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
R
R
R
R
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 252
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
21.2.0.0/15 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
21.4.0.0/14 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
21.8.0.0/13 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
21.16.0.0/12 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
21.32.0.0/11 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
21.64.0.0/10 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
24.0.0.0/24 is subnetted, 1 subnets
24.1.1.0 [120/1] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
41.0.0.0/32 is subnetted, 1 subnets
41.1.1.4 [120/2] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [120/2] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
46.0.0.0/24 is subnetted, 1 subnets
46.1.1.0 [120/2] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
50.0.0.0/24 is subnetted, 1 subnets
50.5.5.0 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
200.1.1.0/24 [120/2] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
211.1.1.0/24 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
212.1.1.0/24 [120/3] via 28.1.1.2, 00:00:23, GigabitEthernet0/2
A ping to the 26.16.1.1 address on R7 from R8 verifies rechability:
R8#ping 21.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
SW1 is next configured for RIPv2 as shown below:
On SW1:
SW1(config)#router rip
SW1(config-router)#no auto-summary
SW1(config-router)#version 2
SW1(config-router)#network 113.0.0.0
SW1(config-router)#network 112.0.0.0
SW1(config-router)#network 133.1.0.0
The routing table verifies the RIP routes SW1 learns from R3:
SW1#show ip route rip | begin Gate
Gateway of last resort is not set
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 253
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
3.0.0.0/24 is subnetted, 4 subnets
3.3.0.0 [120/1] via 113.1.1.3, 00:00:12, Ethernet0/3
3.3.1.0 [120/1] via 113.1.1.3, 00:00:12, Ethernet0/3
3.3.2.0 [120/1] via 113.1.1.3, 00:00:12, Ethernet0/3
3.3.3.0 [120/1] via 113.1.1.3, 00:00:12, Ethernet0/3
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
10.1.1.0/24 [120/4] via 113.1.1.3, 00:00:12, Ethernet0/3
10.1.4.0/24 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
10.1.100.0/24 [120/1] via 113.1.1.3, 00:00:12, Ethernet0/3
10.1.111.0/24 [120/2] via 113.1.1.3, 00:00:12, Ethernet0/3
10.11.111.111/32 [120/2] via 113.1.1.3, 00:00:12, Ethernet0/3
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [120/2] via 113.1.1.3, 00:00:12, Ethernet0/3
14.0.0.0/24 is subnetted, 1 subnets
14.1.1.0 [120/2] via 113.1.1.3, 00:00:12, Ethernet0/3
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
21.2.0.0/15 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
21.4.0.0/14 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
21.8.0.0/13 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
21.16.0.0/12 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
21.32.0.0/11 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
21.64.0.0/10 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
24.0.0.0/24 is subnetted, 1 subnets
24.1.1.0 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
28.0.0.0/24 is subnetted, 1 subnets
28.1.1.0 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
46.0.0.0/24 is subnetted, 1 subnets
46.1.1.0 [120/3] via 113.1.1.3, 00:00:12, Ethernet0/3
50.0.0.0/24 is subnetted, 1 subnets
50.5.5.0 [120/4] via 113.1.1.3, 00:00:12, Ethernet0/3
200.1.1.0/24 [120/1] via 113.1.1.3, 00:00:12, Ethernet0/3
211.1.1.0/24 [120/4] via 113.1.1.3, 00:00:12, Ethernet0/3
212.1.1.0/24 [120/4] via 113.1.1.3, 00:00:12, Ethernet0/3
A ping and a traceroute to test rechability to SW4’s VLAN 10 interface IP address 10.1.1.4 from SW1
succeeds as seen below:
SW1#ping 10.1.1.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.4, timeout is 2 seconds:
!!!!!
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 254
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/4 ms
SW1#traceroute 10.1.1.4
Type escape sequence to abort.
Tracing the route to 10.1.1.4
VRF info: (vrf in name/id, vrf out name/id)
1 113.1.1.3 1 msec 1 msec 1 msec
2 10.1.100.1 1 msec 2 msec 1 msec
3 41.1.1.4 2 msec 1 msec 2 msec
4 46.1.1.6 2 msec 1 msec 1 msec
5 10.1.1.4 3 msec * 3 msec
Next, RIPv2 is enabled on SW2 as shown below:
On SW2:
SW2(config)#router rip
SW2(config-router)#version 2
SW2(config-router)#no auto-summary
SW2(config-router)#network 112.0.0.0
SW2(config-router)#network 123.0.0.0
The routing table on SW2 verifies the RIPv2 routes it learns:
SW2#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
R
R
R
R
R
R
R
R
R
3.0.0.0/24 is subnetted, 4 subnets
3.3.0.0 [120/2] via 112.1.1.11, 00:00:08, Ethernet3/0
3.3.1.0 [120/2] via 112.1.1.11, 00:00:08, Ethernet3/0
3.3.2.0 [120/2] via 112.1.1.11, 00:00:08, Ethernet3/0
3.3.3.0 [120/2] via 112.1.1.11, 00:00:08, Ethernet3/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
10.1.1.0/24 [120/5] via 112.1.1.11, 00:00:08, Ethernet3/0
10.1.4.0/24 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
10.1.100.0/24 [120/2] via 112.1.1.11, 00:00:08, Ethernet3/0
10.1.111.0/24 [120/3] via 112.1.1.11, 00:00:08, Ethernet3/0
10.11.111.111/32 [120/3] via 112.1.1.11, 00:00:08, Ethernet3/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [120/3] via 112.1.1.11, 00:00:08, Ethernet3/0
14.0.0.0/24 is subnetted, 1 subnets
14.1.1.0 [120/3] via 112.1.1.11, 00:00:08, Ethernet3/0
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
21.2.0.0/15 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 255
R
R
R
R
R
R
R
R
R
R
R
R
R
R
21.4.0.0/14 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
21.8.0.0/13 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
21.16.0.0/12 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
21.32.0.0/11 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
21.64.0.0/10 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
24.0.0.0/24 is subnetted, 1 subnets
24.1.1.0 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
28.0.0.0/24 is subnetted, 1 subnets
28.1.1.0 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
46.0.0.0/24 is subnetted, 1 subnets
46.1.1.0 [120/4] via 112.1.1.11, 00:00:08, Ethernet3/0
50.0.0.0/24 is subnetted, 1 subnets
50.5.5.0 [120/5] via 112.1.1.11, 00:00:08, Ethernet3/0
113.0.0.0/24 is subnetted, 1 subnets
113.1.1.0 [120/1] via 112.1.1.11, 00:00:08, Ethernet3/0
200.1.1.0/24 [120/2] via 112.1.1.11, 00:00:08, Ethernet3/0
211.1.1.0/24 [120/5] via 112.1.1.11, 00:00:08, Ethernet3/0
212.1.1.0/24 [120/5] via 112.1.1.11, 00:00:08, Ethernet3/0
Ping and a traceroute to the 10.1.1.4 address on SW4 from SW2 is shown to succeed below:
SW2#traceroute 10.1.1.4
Type escape sequence to abort.
Tracing the route to 10.1.1.4
VRF info: (vrf in name/id, vrf out name/id)
1 112.1.1.11 0 msec 1 msec 0 msec
2 113.1.1.3 1 msec 1 msec 1 msec
3 10.1.100.1 6 msec 2 msec 1 msec
4 41.1.1.4 2 msec 3 msec 1 msec
5 45.1.1.5 3 msec 3 msec 3 msec
6 10.1.1.4 3 msec 4 msec *
Final RIPv2 configuration to provide end to end rechability between all devices is made on SW3 as seen
below:
On SW3:
SW3(config)#router rip
SW3(config-router)#no auto-summary
SW3(config-router)#version 2
SW3(config-router)#network 123.0.0.0
SW3(config-router)#network 133.1.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 256
The routing table on SW3 verifies all the RIPv2 learned routes:
SW3#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
3.0.0.0/24 is subnetted, 4 subnets
3.3.0.0 [120/3] via 123.1.1.22, 00:00:20, Ethernet4/0
3.3.1.0 [120/3] via 123.1.1.22, 00:00:20, Ethernet4/0
3.3.2.0 [120/3] via 123.1.1.22, 00:00:20, Ethernet4/0
3.3.3.0 [120/3] via 123.1.1.22, 00:00:20, Ethernet4/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
10.1.1.0/24 [120/6] via 123.1.1.22, 00:00:20, Ethernet4/0
10.1.4.0/24 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
10.1.100.0/24 [120/3] via 123.1.1.22, 00:00:20, Ethernet4/0
10.1.111.0/24 [120/4] via 123.1.1.22, 00:00:20, Ethernet4/0
10.11.111.111/32 [120/4] via 123.1.1.22, 00:00:20, Ethernet4/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [120/4] via 123.1.1.22, 00:00:20, Ethernet4/0
14.0.0.0/24 is subnetted, 1 subnets
14.1.1.0 [120/4] via 123.1.1.22, 00:00:20, Ethernet4/0
21.0.0.0/8 is variably subnetted, 7 subnets, 7 masks
21.1.0.0/16 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
21.2.0.0/15 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
21.4.0.0/14 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
21.8.0.0/13 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
21.16.0.0/12 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
21.32.0.0/11 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
21.64.0.0/10 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
24.0.0.0/24 is subnetted, 1 subnets
24.1.1.0 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
28.0.0.0/24 is subnetted, 1 subnets
28.1.1.0 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
46.0.0.0/24 is subnetted, 1 subnets
46.1.1.0 [120/5] via 123.1.1.22, 00:00:20, Ethernet4/0
50.0.0.0/24 is subnetted, 1 subnets
50.5.5.0 [120/6] via 123.1.1.22, 00:00:20, Ethernet4/0
112.0.0.0/24 is subnetted, 1 subnets
112.1.1.0 [120/1] via 123.1.1.22, 00:00:20, Ethernet4/0
113.0.0.0/24 is subnetted, 1 subnets
113.1.1.0 [120/2] via 123.1.1.22, 00:00:20, Ethernet4/0
200.1.1.0/24 [120/3] via 123.1.1.22, 00:00:20, Ethernet4/0
211.1.1.0/24 [120/6] via 123.1.1.22, 00:00:20, Ethernet4/0
212.1.1.0/24 [120/6] via 123.1.1.22, 00:00:20, Ethernet4/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 257
Ping and a traceroute to the 10.1.1.4 address on SW4 from SW3 is shown to succeed below:
SW3#ping 10.1.1.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
SW3#traceroute 10.1.1.4
Type escape sequence to abort.
Tracing the route to 10.1.1.4
VRF info: (vrf in name/id, vrf out name/id)
1 133.1.1.11 0 msec 1 msec 0 msec
2 113.1.1.3 2 msec 1 msec 1 msec
3 200.1.1.1 2 msec 1 msec 2 msec
4 41.1.1.4 3 msec 2 msec 2 msec
5 46.1.1.6 2 msec 2 msec 2 msec
6 10.1.1.4 3 msec * 4 msec
Task 2
1. Configure R4 such that it sends RIPv2 updates out of its G0/3 interface to a
broadcast destination.
a. Do not change RIP’s version.
2. Ensure that R1 is configured to send unicast updates to its neighboring router R7.
RIPv1 sends RIP updates to the broadcast address 255.255.255.255. RIPv2 however sends updates to the
multicast destination 224.0.0.9. All routers were configured to run RIPv2 in task 1. The first part of this task
requires modifying R4 so that it broadcasts RIP updates out its G0/3 interface instead of multicasting them,
while also restricting changing the RIP version to 1.
R4 can be configured to do so with the ip rip v2-broadcast interface level command. The command causes
R4 to send broadcast updates out the g0/3 interface. Such a configuration might be useful in situations
where the device at the far end does not listen to multicast.
The configuration is shown below on R4. The debug ip rip is turned on. Note the log messages on R4. As a
result of the ip rip v2-broadcast command configured on R4’s g0/3 interface, it broadcasts to the
255.255.255.255 address. In contrast, the RIP updates sent out the G0/5 interface is multicasted to the
224.0.0.9 address:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 258
On R4:
R4(config)#interface g0/3
R4(config-if)#ip rip v2-broadcast
To verify the configuration:
R4#debug ip rip
RIP protocol debugging is on
RIP: sending v2 update to 255.255.255.255 via GigabitEthernet0/3
(10.1.4.4)
RIP: build update entries
3.3.0.0/24 via 0.0.0.0, metric 3, tag 0
3.3.1.0/24 via 0.0.0.0, metric 3, tag 0
3.3.2.0/24 via 0.0.0.0, metric 3, tag 0
(The rest of the output is omitted for brevity)
The second part of the task requires R1 to unicast its RIP updates to R7. As mentioned, by default, RIPv2
will multicast all updates to the address 224.0.0.9. The neighbor neighbor-address command can be used
to unicast RIP updates to a neighbor. However, this command itself does stop RIP multicasting, resulting in
both multicast and unicast updates being sent to the neighbor.
To stop the router from multicasting RIPv2 updates, in conjunction with the neighbor command, the
interface must also be declared as passive under the RIP router configuration. Following shows these
command configurations on R1 for it’s neighbor R7. The log message after turning on debug ip rip verifies
the unicast RIP updates R1 send to R7:
On R1:
R1(config)#router rip
R1(config-router)#passive-interface g0/7
R1(config-router)#neighbor 10.11.111.111
To verify the configuration:
R1#debug ip rip
RIP protocol debugging is on
RIP: sending v2 update to 10.11.111.111 via GigabitEthernet0/7
(10.1.111.1)
RIP: build update entries
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 259
3.3.0.0/24 via 0.0.0.0, metric 2, tag 0
3.3.1.0/24 via 0.0.0.0, metric 2, tag 0
3.3.2.0/24 via 0.0.0.0, metric 2, tag 0
(The rest of the output is omitted for brevity)
Task 3
Configure the following loopback interfaces on R3. Starting with network 30.3.0.0/24, this
router should only advertise every other third octet network (for example, x.x.0.x, x.x.2.x,
x.x.4.x). These are networks 30.3.0.0, 30.3.2.0, 30.3.4.0, 30.3.6.0, 30.3.8.0, and
30.3.10.0/24.
int lo0 = 30.3.0.1 /24
int lo1 = 30.3.1.1 /24
int lo2 = 30.3.2.1 /24
int lo3 = 30.3.3.1 /24
int lo4 = 30.3.4.1 /24
int lo5 = 30.3.5.1 /24
int lo6 = 30.3.6.1 /24
int lo7 = 30.3.7.1 /24
int lo8 = 30.3.8.1 /24
int lo9 = 30.3.9.1 /24
int lo10 = 30.3.10.1 /24
To copy and paste the initial configurations, go to the Initial-config folder 
RIPv2 folder  Lab-1-Task3.
On R3:
This task requires some understanding of binary numbers and how to match them using an access-list’s
wildcard mask.
IP address
1st Octet
2nd Octet
3rd Octet
4th Octet
30.3.1.1
00011110
00000011
00000001
00000001
30.3.2.1
00011110
00000011
00000010
00000001
30.3.3.1
00011110
00000011
00000011
00000001
30.3.4.1
00011110
00000011
00000100
00000001
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 260
30.3.5.1
00011110
00000011
00000101
00000001
30.3.6.1
00011110
00000011
00000110
00000001
30.3.7.1
00011110
00000011
00000111
00000001
30.3.8.1
00011110
00000011
00001000
00000001
30.3.9.1
00011110
00000011
00001001
00000001
30.3.10.1
00011110
00000011
00001010
00000001
Of particular interest in the above is the third octet highlighted in red. What do we notice in the above? All IP
addresses that have an odd number in their third octet (red and yellow highlights), have a binary 1 as the last
bit. All IP addresses that have an even number in their third octet (red and blue highlights), have a binay 0 as
the last bit of that octet. This is true for all addresses.
For more clarity, let’s magnify just the third octet for each IP address listed above. In the table below, the
first column is the number in the third octet of the IP address. For example, the text in red in the first row is
1. This is the number in the third octet of the IP address 30.3.1.1. The columns following this are the binary
representation of this number:
Bit values of the third octet
IP
128
64
32
16
8
4
1
0
0
0
0
0
2
0
0
0
0
3
0
0
0
4
0
0
5
0
6
2
1
0
0
1
0
0
1
0
0
0
0
1
1
0
0
0
1
0
0
0
0
0
0
1
0
1
0
0
0
0
0
1
1
0
7
0
0
0
0
0
1
1
1
8
0
0
0
0
1
0
0
0
9
0
0
0
0
1
0
0
1
CCIE by Narbik Kocharians
D
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 261
10
0
0
0
0
1
0
1
0
So as is obvious in the table above, all odd numbers have their last binary bit set to 1. All even numbers have
their last binary bit set to 0. This means, IP addresses with an odd number in their third octet, such as
30.3.1.0, 30.3.3.0, 30.3.5.0, 30.3.7.0 and 30.3.9.0, have one thing in common, the last binary bit of their third
octet is 1. According to the task R3 should not advertise these odd numbered networks into RIPv2. Only, the
even numbered networks should be advertised into RIP.
One of the ways to do this is to instruct R3 to check the last binary bit of the third octet of the configured IP
addresses. If this last binary bit is 1, do not advertise this network into RIP. If this bit is not 1, meaning it is 0,
go on and advertise it. ACLs and wildcard masks can do just this.
ACLs are used to filter or sort packets or routes based on IP address, protocol, and port numbers. This sorting
is done by matching what is being sorted to a pattern. For example, if an ACL wanted to sort a group of IP
addresses such that all IP addresses that began with 192.168.0.0 are grouped it would need to be configured
to match any IP address where the first two octets have the exact bit pattern of “192.168”. To successfully
implement this, the ACL needs additional information to identify which specific bits should match. This is
what the wildcard mask does.
A wildcard mask is a 32-bit number that is represented in 4 octets just like a regular IP address. A wildcard
mask is related to a subnet mask in that they are both used to direct a networking device in how it should
interpret the individual bits of an IP address. In the case of a subnet mask, it identifies the consecutive string
of bits that indicate the subnet portion of the IP address (masked with a binary 1 in the subnet mask) and the
consecutive string of bits that indicate the host portion of the IP address (masked with a binary 0 in the
subnet mask).
A subnet mask of 255.255.255.0 has 24 consecutive binary 1 digits. These binary 1 digits indicate the
network portion of the IP address. In this case, the first 24 bits are the network identifier. The last 8 binary 0
bits of the subnet mask indicate the host portion of the IP address. Applied to the 192.168.1.1 IP address, the
255.255.255.0 subnet mask tells the networking device that 192.168.1.0 is the network and “1” is the host
address of the device on that network.
Wild card masks are used exclusively for identifying which bits should match when comparing two bit
patterns. They operate using the following matching logic:
1. If the binary bit in the wildcard mask is 1, the bit in the same position does NOT have match between
the two compared bit patterns
2. If the binary bit in the wildcard mask is 0, the bit in the same position HAS to match between the two
compared bit patterns
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 262
Thus a wildcard value of 0.0.255.255 is basically indicating that the first two octets of bit patterns should
match between two compared pattern values while the last two octets do not have to match. When
combined with an ACL statement such as permit 192.168.0.0 0.0.255.255 it powers the sorting function. Any
IP address whose first two octets have the same bit pattern that equals “192.168” will be matched by that
ACL statement because of the wildcard mask applied. The ACL statement is therefore read as “permit any
address where the first two octets have the bit pattern ‘192.168’”.
Wildcard masks are very powerful for bit pattern matching. Unlike subnet masks, wildcard masks do not
have to be written to match consecutive bit patterns. This means a wildcard mask of 0.255.0.255 is a valid
wildcard mask. It indicates the bit pattern for the first and third octet should match between two patterns.
This fact can be used to complete the task and craft an ACL that only denies the odd-number third octet
routes from being advertised in rip.
The ACL used to complete the task requires two parts: a bit pattern to match against and a wildcard mask to
indicate which bits should be matched.
According to the task only the routes that begin with 30.3.0.0 should be affected by this policy. This means
the first two octets of the filtered routes should be “30.3”. This forms the basis of the matching bit pattern
needed for the ACL. Next, the task says that starting with 30.3.0.0 every other network should be advertised.
These are only the even networks. This means the odd networks should be denied.
Armed with the knowledge that all odd binary numbers have a binary 1 as the last binary digit, the matching
bit pattern for the third octet should be “xxxxxxx1”. In other words, the first seven binary digits can be either
a “0” or “1” but the last binary digit MUST be a “1”. To make sure this is the matched bit any decimal odd
number needs to form the matching bit pattern in the third octet. For simplicity, the number 1 is used. This
makes the matching bit pattern “30.3.1”.
The task does not give any explicit instructions about what should be matched in the fourth octet. As such a
0 is enough. The final matching bit pattern is “30.3.1.0”. This completes the first part of the ACL.
The next step is to formulate a wildcard mask that describes what bits should match in the matching bit
pattern when compared to other patterns. These “other patterns” will be referred to as “incoming bit
patterns” from here out. Since the task explicitly states that the first two octets must be 30.3, these octets
MUST match between the matched pattern and the incoming bit patterns. Thus, the wildcard mask for these
two octets must include two octets of binary 0’s (“0.0”) to indicate the pattern must be the same.
The third and fourth octets are special. The only bit that needs to match in the third octet is the last bit. This
bit is a binary “1” and is present for all odd numbers. All other bits in the third and fourth octet do not have
to match. Thus the binary mask for these octets should be “1111110.11111111” when converted to decimal
the pattern is “254.255”. The final wildcard mask is “0.0.254.255”.
With these two pieces of information, the ACL statement to deny IP addresses in the 30.3.0.0/24 range if the
third octet is an odd number is deny 30.3.1.0 0.0.254.255. The wildcard mask properly indicates that any
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 263
incoming bit pattern should have the same first 16 consecutive bits and eight bit of the third octet as the bit
pattern 30.3.1.0. To see how this works, let’s assume the route 30.3.2.0/24 is examined by the access-list
statement that was just crafted. The following table examines third octet interaction specifically. In this
table, 30.3.2.0 is the incoming bit pattern, 30.3.1.0 is the matching bit pattern and 0.0.254.255 is the
wildcard mask.
Incoming bit
pattern
0
0
0
0
0
0
1
0
Matching bit
pattern
0
0
0
0
0
0
0
1
WC-bits
1
1
1
1
1
1
1
0
The Wildcard bits indicate that the last bit of the incoming bit pattern should match the last bit of the
matching bit pattern. The last bit of the incoming pattern is “0” while the last bit of the matched pattern is
“1”. Because these two numbers do not match, the incoming bit pattern does not match the “deny” ACL
statement and passes to the next ACL statement for matching. This means 30.3.2.0/24 is not an odd number.
To ensure the even third octet routes and all other routes pass through, the ACL statement permit any needs
to be added to the end of the ACL. The complete ACL is as follows:
R3(config)#access-list 30 deny 30.3.1.0 0.0.254.255
R3(config)#access-list 30 permit any
To perform the filter, distribute-lists are configured in the out direction for g0/1, g0/9 and g0/0 under router
RIP configuration mode to filter the RIP routing updates. The distribute-lists reference the previously
configured ACL 30 to sort the prefixes as seen below:
R3(config)#router rip
R3(config-router)#network 30.0.0.0
R3(config-router)#distribute-list 30 out g0/1
R3(config-router)#distribute-list 30 out g0/9
R3(config-router)#distribute-list 30 out g0/0
The routing table is observed on some of the routers to verify the result of the above configuration. Notice
these routers only have RIP routes for even numbered subnets in the third octet for the “30.3” networks:
R3#clear ip route *
To verify the configuration:
You may have to enter “clear ip route *” multiple times to see the result. Remember, RIP’s convergence is
VERY slow. The “clear ip route *” must be entered multiple times on all routers.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 264
On R1:
R1#show ip route rip | include 30.3.
R
R
R
R
R
R
30.3.0.0 [120/1] via 200.1.1.3, 00:00:04, GigabitEthernet9
30.3.2.0 [120/1] via 200.1.1.3, 00:00:04, GigabitEthernet9
30.3.4.0 [120/1] via 200.1.1.3, 00:00:04, GigabitEthernet9
30.3.6.0 [120/1] via 200.1.1.3, 00:00:04, GigabitEthernet9
30.3.8.0 [120/1] via 200.1.1.3, 00:00:04, GigabitEthernet9
30.3.10.0 [120/1] via 200.1.1.3, 00:00:04, GigabitEthernet9
On SW1:
SW1#show ip route rip | include 30.3.
R
R
R
R
R
R
30.3.0.0 [120/1] via 113.1.1.3, 00:00:09, Ethernet0/3
30.3.2.0 [120/1] via 113.1.1.3, 00:00:09, Ethernet0/3
30.3.4.0 [120/1] via 113.1.1.3, 00:00:09, Ethernet0/3
30.3.6.0 [120/1] via 113.1.1.3, 00:00:09, Ethernet0/3
30.3.8.0 [120/1] via 113.1.1.3, 00:00:09, Ethernet0/3
30.3.10.0 [120/1] via 113.1.1.3, 00:00:09, Ethernet0/3
On SW4:
SW4#show ip route rip | include 30.3.
R
R
R
R
R
R
30.3.0.0 [120/5] via 10.1.1.6, 00:00:16, Vlan10
30.3.2.0 [120/5] via 10.1.1.6, 00:00:16, Vlan10
30.3.4.0 [120/5] via 10.1.1.6, 00:00:16, Vlan10
30.3.6.0 [120/5] via 10.1.1.6, 00:00:16, Vlan10
30.3.8.0 [120/5] via 10.1.1.6, 00:00:16, Vlan10
30.3.10.0 [120/5] via 10.1.1.6, 00:00:16, Vlan10
Task 4
Configure the following loopback interfaces on R6. Starting with network 60.6.0.0/24, this
router should only advertise every eighth third octet subnet (for example, x.x.0.x, x.x.8.x,
x.x.16.x).
int lo0 = 60.6.0.1 /24
int lo1 = 60.6.1.1 /24
CCIE by Narbik Kocharians
int lo6 = 60.6.6.1 /24
int lo7 = 60.6.7.1 /24
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 265
int lo2 = 60.6.2.1 /24
int lo3 = 60.6.3.1 /24
int lo4 = 60.6.4.1 /24
int lo5 = 60.6.5.1 /24
int lo8 = 60.6.8.1 /24
int lo9 = 60.6.9.1 /24
int lo10 = 60.6.10.1 /24
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
RIPv2 folder  Lab-1-Task4.
This task uses the same logic as Task 3 in order to formulate an access-list that denies every 8th subnet in
the third octet.
On R6:
NOTE: If “248” which is the third octet in the inverse mask of the access-list is converted to binary, we
should see the following:
Decimal
Binary
128
1
64
1
32
1
16
1
8
1
4
0
2
0
1
0
Since decimal value of 8 is the last position used to represent the decimal value of 248 in binary, the
subsequent networks will be increments of 8. If 240 was used, the networks will be increments of 16. If
224 was used, the networks will be increments of 32 and so forth.
R6(config)#access-list 60 permit 60.6.0.0 0.0.248.255
R6(config)#access-list 60 deny 60.6.0.0 0.0.255.255
R6(config)#access-list 60 permit any
Next, distribute-lists are configured in the out direction for g0/4 and g0/9 under the router RIP
configuration mode to filter the RIP routing updates as seen below:
R6(config)#router rip
R6(config-router)#distribute-list 60 out g0/4
R6(config-router)#distribute-list 60 out g0/9
R6(config-router)#network 60.0.0.0
R6#clear ip route *
The routing table is observed on SW4, R2 and R1 to verify the result of the above configuration. The
output confirms that only every 8th subnet of the “60.6” networks has been advertised by R6 to R4 and
R2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 266
To verify the configuration:
On SW4:
SW4#clear ip route *
SW4#show ip route rip | include 60.6.
R
R
60.6.8.0 [120/1] via 10.1.1.6, 00:00:25, Vlan10
60.6.0.0 [120/1] via 10.1.1.6, 00:00:25, Vlan10
On R2:
R2#show ip route rip | include 60.6.
R
R
60.6.8.0 [120/2] via 24.1.1.4, 00:00:13, GigabitEthernet0/4
60.6.0.0 [120/2] via 24.1.1.4, 00:00:13, GigabitEthernet0/4
On R1:
R1#show ip route rip | include 60.6.
R
R
60.6.8.0 [120/2] via 41.1.1.4, 00:00:16
60.6.0.0 [120/2] via 41.1.1.4, 00:00:16
Task 5
Configure the following loopback interfaces on R4. This router should be configured
such that it only advertises the even-numbered hosts of the odd third octet networks
of these loopback interfaces plus all other networks (for example, x.x.1.x, x.x.3.x,
x.x.5.x).
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
RIPv2 folder  Lab-1-Task5.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 267
int lo1
int lo6
ip addr 40.4.1.1 255.255.255.0
ip addr 40.4.6.1 255.255.255.0
ip addr 40.4.1.2 255.255.255.255 sec ip addr 40.4.6.2 255.255.255.255 sec
ip addr 40.4.1.3 255.255.255.255 sec ip addr 40.4.6.3 255.255.255.255 sec
ip addr 40.4.1.4 255.255.255.255 sec ip addr 40.4.6.4 255.255.255.255 sec
ip addr 40.4.1.5 255.255.255.255 sec ip addr 40.4.6.5 255.255.255.255 sec
ip addr 40.4.1.6 255.255.255.255 sec ip addr 40.4.6.6 255.255.255.255 sec
ip addr 40.4.1.7 255.255.255.255 sec ip addr 40.4.6.7 255.255.255.255 sec
ip addr 40.4.1.8 255.255.255.255 sec ip addr 40.4.6.8 255.255.255.255 sec
ip addr 40.4.1.9 255.255.255.255 sec ip addr 40.4.6.9 255.255.255.255 sec
ip addr 40.4.1.10 255.255.255.255
sec
ip addr 40.4.6.10 255.255.255.255 sec
int lo2
int lo7
ip addr 40.4.2.1 255.255.255.0
ip addr 40.4.7.1 255.255.255.0
ip addr 40.4.2.2 255.255.255.255 sec ip addr 40.4.7.2 255.255.255.255 sec
ip addr 40.4.2.3 255.255.255.255 sec ip addr 40.4.7.3 255.255.255.255 sec
ip addr 40.4.2.4 255.255.255.255 sec ip addr 40.4.7.4 255.255.255.255 sec
ip addr 40.4.2.5 255.255.255.255 sec ip addr 40.4.7.5 255.255.255.255 sec
ip addr 40.4.2.6 255.255.255.255 sec ip addr 40.4.7.6 255.255.255.255 sec
ip addr 40.4.2.7 255.255.255.255 sec ip addr 40.4.7.7 255.255.255.255 sec
ip addr 40.4.2.8 255.255.255.255 sec ip addr 40.4.7.8 255.255.255.255 sec
ip addr 40.4.2.9 255.255.255.255 sec ip addr 40.4.7.9 255.255.255.255 sec
ip addr 40.4.2.10 255.255.255.255
sec
ip addr 40.4.7.10 255.255.255.255 sec
int lo3
int lo8
ip addr 40.4.3.1 255.255.255.0
ip addr 40.4.8.1 255.255.255.0
ip addr 40.4.3.2 255.255.255.255 sec ip addr 40.4.8.2 255.255.255.255 sec
ip addr 40.4.3.3 255.255.255.255 sec ip addr 40.4.8.3 255.255.255.255 sec
ip addr 40.4.3.4 255.255.255.255 sec ip addr 40.4.8.4 255.255.255.255 sec
ip addr 40.4.3.5 255.255.255.255 sec ip addr 40.4.8.5 255.255.255.255 sec
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 268
ip addr 40.4.3.6 255.255.255.255 sec ip addr 40.4.8.6 255.255.255.255 sec
ip addr 40.4.3.7 255.255.255.255 sec ip addr 40.4.8.7 255.255.255.255 sec
ip addr 40.4.3.8 255.255.255.255 sec ip addr 40.4.8.8 255.255.255.255 sec
ip addr 40.4.3.9 255.255.255.255 sec ip addr 40.4.8.9 255.255.255.255 sec
ip addr 40.4.3.10 255.255.255.255
sec
ip addr 40.4.8.10 255.255.255.255 sec
int lo4
int lo9
ip addr 40.4.4.1 255.255.255.0
ip addr 40.4.9.1 255.255.255.0
ip addr 40.4.4.2 255.255.255.255 sec ip addr 40.4.9.2 255.255.255.255 sec
ip addr 40.4.4.3 255.255.255.255 sec ip addr 40.4.9.3 255.255.255.255 sec
ip addr 40.4.4.4 255.255.255.255 sec ip addr 40.4.9.4 255.255.255.255 sec
ip addr 40.4.4.5 255.255.255.255 sec ip addr 40.4.9.5 255.255.255.255 sec
ip addr 40.4.4.6 255.255.255.255 sec ip addr 40.4.9.6 255.255.255.255 sec
ip addr 40.4.4.7 255.255.255.255 sec ip addr 40.4.9.7 255.255.255.255 sec
ip addr 40.4.4.8 255.255.255.255 sec ip addr 40.4.9.8 255.255.255.255 sec
ip addr 40.4.4.9 255.255.255.255 sec ip addr 40.4.9.9 255.255.255.255 sec
ip addr 40.4.4.10 255.255.255.255
sec
ip addr 40.4.9.10 255.255.255.255 sec
int lo5
int lo10
ip addr 40.4.5.1 255.255.255.0
ip addr 40.4.10.1 255.255.255.0
ip addr 40.4.5.2 255.255.255.255 sec ip addr 40.4.10.2 255.255.255.255 sec
ip addr 40.4.5.3 255.255.255.255 sec ip addr 40.4.10.3 255.255.255.255 sec
ip addr 40.4.5.4 255.255.255.255 sec ip addr 40.4.10.4 255.255.255.255 sec
ip addr 40.4.5.5 255.255.255.255 sec ip addr 40.4.10.5 255.255.255.255 sec
ip addr 40.4.5.6 255.255.255.255 sec ip addr 40.4.10.6 255.255.255.255 sec
ip addr 40.4.5.7 255.255.255.255 sec ip addr 40.4.10.7 255.255.255.255 sec
ip addr 40.4.5.8 255.255.255.255 sec ip addr 40.4.10.8 255.255.255.255 sec
ip addr 40.4.5.9 255.255.255.255 sec ip addr 40.4.10.9 255.255.255.255 sec
ip addr 40.4.5.10 255.255.255.255
sec
CCIE by Narbik Kocharians
ip addr 40.4.10.10 255.255.255.255 sec
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 269
This task may seem a bit complicated at first, but a quick breakdown can help understand what it requires. It
states that only the even hosts of odd third octet subnets should be advertised in RIP. This means that
40.4.5.2 should be advertised, while 40.4.5.1 should not. In other words, the third octet should be an odd
number and the fourth octet should be an even number of a “40.4” network in order to be permitted.
This task uses the same logic as Task 3 in order to formulate the proper access-list. Care must be taken with
the matched bit pattern as an odd number must be in the first octet while an even number should be in the
fourth octet. Even numbers in binary will never have a binary “1” as the last bit, while odd numbers will
always have a binary “1” as the last bit. The wildcard mask should match this bit with a binary “0” preceded
by seven binary “1’s”. Thus the following ACL has been derived:
On R4:
R4(config)#access-list 40 permit 40.4.1.0 0.0.254.254
R4(config)#access-list 40 deny 40.4.0.0 0.0.255.255
R4(config)#access-list 40 permit any
The above configuration adds an explicit deny for the 40.4.0.0 address. The reason this was added is
because it will NOT match the first ACL statement. Because a permit any statement is required to pass all
other non “40.4” routes, the 40.4.0.0 network will pass through even though it shouldn’t. The explicit deny
statement prevents this.
To configure the filtering distribute-lists referencing the access-list above are configured in router RIP
configuration mode in the out direction for g0/2, g0/3, g0/5, and g0/6 to filter the RIP routing updates as
seen below:
R4(config)#router rip
R4(config-router)#network 40.0.0.0
R4(config-router)#distribute-list 40 out dialer41
R4(config-router)#distribute-list 40 out g0/2
R4(config-router)#distribute-list 40 out g0/3
R4(config-router)#distribute-list 40 out g0/5
R4(config-router)#distribute-list 40 out g0/6
The routing table on R1 is checked to verify the result of the above configurations. Notice only odd third
octet and even fourth octet “40.4” routes have been advertised by R4 to the other routers:
On All Devices:
Rx#clear ip route *
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 270
To verify the configuration:
On R1:
R1#clear ip route *
R1#show ip route rip | include 40.4.
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
R1
40.4.1.0/24 [120/1] via 41.1.1.4, 00:00:19
40.4.1.2/32 [120/1] via 41.1.1.4, 00:00:19
40.4.1.4/32 [120/1] via 41.1.1.4, 00:00:19
40.4.1.6/32 [120/1] via 41.1.1.4, 00:00:19
40.4.1.8/32 [120/1] via 41.1.1.4, 00:00:19
40.4.1.10/32 [120/1] via 41.1.1.4, 00:00:19
40.4.3.0/24 [120/1] via 41.1.1.4, 00:00:19
40.4.3.2/32 [120/1] via 41.1.1.4, 00:00:19
40.4.3.4/32 [120/1] via 41.1.1.4, 00:00:19
40.4.3.6/32 [120/1] via 41.1.1.4, 00:00:19
40.4.3.8/32 [120/1] via 41.1.1.4, 00:00:19
40.4.3.10/32 [120/1] via 41.1.1.4, 00:00:19
40.4.5.0/24 [120/1] via 41.1.1.4, 00:00:19
40.4.5.2/32 [120/1] via 41.1.1.4, 00:00:19
40.4.5.4/32 [120/1] via 41.1.1.4, 00:00:19
40.4.5.6/32 [120/1] via 41.1.1.4, 00:00:19
40.4.5.8/32 [120/1] via 41.1.1.4, 00:00:19
40.4.5.10/32 [120/1] via 41.1.1.4, 00:00:19
40.4.7.0/24 [120/1] via 41.1.1.4, 00:00:19
40.4.7.2/32 [120/1] via 41.1.1.4, 00:00:19
40.4.7.4/32 [120/1] via 41.1.1.4, 00:00:19
40.4.7.6/32 [120/1] via 41.1.1.4, 00:00:19
40.4.7.8/32 [120/1] via 41.1.1.4, 00:00:19
40.4.7.10/32 [120/1] via 41.1.1.4, 00:00:19
40.4.9.0/24 [120/1] via 41.1.1.4, 00:00:19
40.4.9.2/32 [120/1] via 41.1.1.4, 00:00:19
40.4.9.4/32 [120/1] via 41.1.1.4, 00:00:19
40.4.9.6/32 [120/1] via 41.1.1.4, 00:00:19
40.4.9.8/32 [120/1] via 41.1.1.4, 00:00:19
40.4.9.10/32 [120/1] via 41.1.1.4, 00:00:19
Task 6
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 271
Configure the routers and switches in this routing domain based on the following
timers:





Periodic updates are sent every 30 seconds.
Routers and switches should declare a route invalid after 1.5 minutes.
Routers and switches should suppress routing information regarding a better
path for 1.5 minutes.
Routers and switches should flush routes 30 seconds after they are invalid.
Routers and switches should postpone their periodic updates by 100
milliseconds.
RIPv2 exchanges updates messages every 30 seconds. This timer is known as the update timer. The first part
of the task requires the update timer to remain at its default of 30 seconds.
The invalid timer dictates how long before a RIP route can be considered invalid. The default value is 180
seconds. If a router does not receive a RIP update from the next hop for a period of 180 seconds, the RIP
route is declared invalid. The router at this point activates another RIP route timer known as the hold down
timer that too defaults to 180 seconds. Sub-task 2 hints towards modifying the invalid timer on all the
devices from 180 seconds to 90 seconds.
During the period of the hold down timer of 180 seconds for a RIP route, the router does not accept any
updates, meaning it will suppress any new updates it might receive for that route. It is during this period
that the router announces the said route to be unreachable to its RIP neighboring routers. Sub-task 3 hints
towards modifying this suppression value to 90 seconds.
Sub-task 4 requires modifying the flushed after timer. The flushed after timer begins when a router receives
a RIP update. It runs for a duration of 240 seconds by default. If the router hasn’t received any RIP update
for a RIP route for 240 seconds, meaning the flushed after timer expires, the router will remove the RIP
route from the routing table. The task requires ensuring that flushed after timer expires 30 seconds after a
route has been declared as invaid. As seen earlier, the invalid timer as per the task requirement is to be set
to 90 seconds. This means, the flushed after timer will include the duration of the invalid timer of 90
seconds + 30 second, total of 120 seconds.
Finally, sub-task 5 requires postponing the periodic updates by 100 milliseconds. This is done by setting the
sleep timer value to 100 ms. The following configurations are made on all the devices in the topology to
implement the changes mentioned above in the specified order:
On All Routers:
(config)#router rip
(config-router)#timers basic 30 90 90 120 100
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 272
To verify the configuration:
The show ip protocol command output can then be used to verify the results of configuration changes as
seen in the example output below from R1:
On Any Router:
Rx#show ip protocol | include Send|Inv
Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Sending updates every 30 seconds, next due in 0 seconds
Invalid after 90 seconds, hold down 90, flushed after 120
Interface
Send Recv Triggered RIP Key-chain
Task 7
Since R1 is a very fast router, configure it such that it adds an inter-packet delay of 50
milliseconds between the updates.
The output-delay command under the RIP configuration mode can be used on a router to slow down the
speed at which it sends a RIP update to its neighboring router. This delay will help prevent loss of routing
information at the receiving router. The task requires an output delay of 50 milliseconds to be applied on R1.
The configuration for this is shown below:
On R1:
R1(config)#router rip
R1(config-router)#output-delay 50
The show ip protocols command output below verifies the above configuration:
R1#show ip protocols | section Routing Protocol is "rip"
Routing Protocol is "rip"
Output delay 50 milliseconds between packets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 273
Task 8
Configure R2 to set the number of received but not yet processed RIP update packets in the
RIP input queue to 100.
In contrast to the output-delay command used above, the input-queue command is issued on low speed
routers locally to prevent the loss of routing information. The input queue holds unprocessed RIP update
packets with a default queue depth of 50. The task requires making changes to increase the queue depth
to 100 on R2. This is done with the input-queue 100 command under the RIP router configuration mode
as shown below:
On R2:
R2(config)#router rip
R2(config-router)#input-queue 100
Task 9
Configure all routers to suppress a flash update when a topology change occurs 10 seconds
before a regular update.
RIP updates are regularly sent every 30 seconds by default. Flash updates are basically triggered updates
that are sent when a router detects a sudden loss of a route. For example if the directly connected
interface that is advertised into RIP is shutdown. In this case, the router immediately sends out a RIP
update response message with an infinite metric of 16, poisoning the route since it is now unreachable.
This way neighboring routers can flush the route from their routing tables.
In certain situations, RIP may need to send a flash update seconds before a regular update is due to be
sent. In this case, it would be more efficient for RIP to send the flash update information in a regular RIP
update. The RIP process can be configured to suppress flash updates if a regular update is due to be sent
within a configured threshold for efficiency.
The task requires that all devices suppress their flash updates if the next RIP regular update is due to be
sent in 10 seconds. All devices can be configured to do this with the command flash-update-threshold 10
under the RIP router configuration mode as shown below:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 274
On All routers:
(config)#router rip
(config-router)#flash-update-threshold 10
To verify the configuration:
On Any Router:
#show ip protocol | include Flash
Flash update is suppressed when next update due within 10 seconds
Task 10
Configure R1 and R2 to authenticate their routing updates through their direct connection.
Configure these two routers to use the unencrypted key ccie for this purpose.
RIPv2 supports both plain-text and MD5 authentication to authenticate RIP messages between neighbors.
Plain-text authentication is the default authentication method used in Cisco IOS. This method of
authentication is however discouraged for security purposes since routers exchange their authenticationrelated parameters to each other in plain text. The task however does ask for plain text authentication for
RIPv2 between R1 and R2.
To configure plain-text authentication first a key chain containing the password is configured on R1 and R2
with the key chain key-chain name command. A single key, key 1, is defined with the key 1 command and
the key string or the password is specified with the key-string ccie command. The result configures the
passphrase ccie to be used to authenticate any protocol that uses the key chain R1-R2 for key material.
After configuring the key chain, RIP on R1 and R2 is configured for authentication on the RIP-enabled
interface G0/2 and G0/1 connecting them using the ip rip authentication key-chain command. The key
chain name is “R1-R2” to match the configured key chain. Since the default authentication mode is plain
text, specifying the authentication mode using the ip rip authentication mode in not required:
On R1:
R1(config)#key chain R1-R2
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string ccie
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 275
R1(config-keychain-key)#interface g0/2
R1(config-if)#ip rip auth key-chain R1-R2
On R2:
R2(config)#key chain R2-R1
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string ccie
R2(config-keychain-key)#interface g0/1
R2(config-if)#ip rip auth key-chain R2-R1
To verify the configuration:
The show ip protocol command output on both routers verifies the above authentication configuration:
On R1:
R1#show ip protocol | i GigabitEthernet0/2|Key
Interface
GigabitEthernet0/2
Send
2
Recv
2
Triggered RIP
No
Key-chain
R1-R2
Triggered RIP
Key-chain
On R2:
R2#show ip protocol | i GigabitEthernet0/1|Key
Interface
GigabitEthernet0/1
Send
Recv
2
2
No
R2-R1
Task 11
Configure R5, R6, and SW4 to use authentication with the strongest authentication method
available to RIPv2. These routers should use Micronic? as their password.
As mentioned in the earlier task, RIPv2 supports both plain text and MD5 authentication. This task requires
ensuring that the RIP routing updates exchanged between R5, R6 and SW4 on their VLAN 10 segment are
secured with the MD5 authentication method.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 276
Similar to above, first a key chain is defined on all three devices. Key 1 is defined and the password specified
is Micronic?. The challenge however is, how to include the special character ? as part of the password
Micronic, without involving the context sensitive help in Cisco IOS. The trick is to press the “esc” key
followed by the Q key and then entering the special character ?.
Following this, ip rip authentication key-chain command is configured on the G0/9 and VLAN 10 interfaces
on R5, R6 and SW4 respectively. To change the authentication mode from plain text to MD5, the ip rip
authentication mode md5 command is issued on the interfaces:
On R5:
R5(config)#key chain R5-R6-SW4
R5(config-keychain)#key 1
R5(config-keychain-key)#key-string Micronic?
R5(config-keychain-key)#interface g0/9
R5(config-if)#ip rip authentication key-chain R5-R6-SW4
R5(config-if)#ip rip authentication mode md5
On R6:
R6(config)#key chain R5-R6-SW4
R6(config-keychain)#key 1
R6(config-keychain-key)#key-string Micronic?
R6(config-keychain-key)#interface g0/9
R6(config-if)#ip rip authentication key-chain R5-R6-SW4
R6(config-if)#ip rip authentication mode md5
On SW4:
SW4(config)#key chain R5-R6-SW4
SW4(config-keychain)#key 1
SW4(config-keychain-key)#key-string Micronic?
SW4(config-keychain-key)#interface vlan10
SW4(config-if)#ip rip authentication key-chain R5-R6-SW4
SW4(config-if)#ip rip authentication mode md5
To verify the configuration:
On R5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 277
R5#show key chain R5-R6-SW4 | include key 1
key 1 -- text "Micronic?"
On R6:
R6#show key chain R5-R6-SW4 | include key 1
key 1 -- text "Micronic?"
On SW4:
SW4#show key chain R5-R6-SW4 | include key 1
key 1 -- text "Micronic?"
Task 12
Configure R1 to accept existing and future routes that have a prefix length of 10 to 14.
These routes should be received from R7 only. Do not use an access list(s) or a neighbor
command to accomplish this task.
A show ip route rip | in 10.11.111.111 command on R1 reveals the RIP routes R1 learns from R7:
On R1:
R1#show ip route rip | include 10.11.111.111
R
R
R
R
R
R
R
21.1.0.0/16 [120/1] via 10.11.111.111, 00:00:05
21.2.0.0/15 [120/1] via 10.11.111.111, 00:00:05
21.4.0.0/14 [120/1] via 10.11.111.111, 00:00:05
21.8.0.0/13 [120/1] via 10.11.111.111, 00:00:05
21.16.0.0/12 [120/1] via 10.11.111.111, 00:00:05
21.32.0.0/11 [120/1] via 10.11.111.111, 00:00:05
21.64.0.0/10 [120/1] via 10.11.111.111, 00:00:05
The task requires configuration that results in R1 learning only those networks that have a prefix length
of /10, /11, /12, /13 or /14, specifically from R7. Meaning, the networks 21.1.0.0/16 and 21.2.0.0/15
should be filtered from R1’s routing table.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 278
The task restricts the use of access-lists to achieve this filtering. Another way to accomplish this would
be to configure a prefix list and use it with a distribute list under the RIP router configuration mode.
First, a prefix list identifying the networks to be permitted with the ip prefix-list NET permit 0.0.0.0/0 ge
10 le 14 command. The combination of 0.0.0.0/0 and ge 10 le 14 can be read as permit any networks
that have their prefix mask with /10, /11, /12, /13 or /14.
A second prefix is then configured to identify the source of the routing update with the ip prefix-list R7
permit 10.11.111.111/32 command. Since the task specifically requires the filtering to happen for RIP
updates from R7, the R7’s interface address connecting to R1 will be the source of these updates and
hence is used in this prefix list.
A distribute-list is then configured under the router RIP configuration mode with the distribute-list
prefix NET gateway R7 in g0/7. The gateway keyword refers to the source of the routing update that is
referenced in the prefix list, R7.
R1(config)#ip prefix NET permit 0.0.0.0/0 ge 10 le 14
R1(config)#ip prefix R7 permit 10.11.111.111/32
R1(config)#router rip
R1(config-router)#distribute-list prefix NET gateway R7 in g0/7
To verify the configuration:
On R1:
R1#clear ip route *
The result of the above configuration can be seen with the show ip route rip | include 10.11.111.111
command output below. Notice, R1 now filters the 21.1.0.0/16 and 21.2.0.0/15 networks since they are
not permitted in the prefix list NET, permitting only the networks with the prefix length /10,/11,/12,/13
and 14 as the task desires from R7:
R1#show ip route rip | include 10.11.111.111
R
R
R
R
R
21.4.0.0/14 [120/1] via 10.11.111.111, 00:00:10
21.8.0.0/13 [120/1] via 10.11.111.111, 00:00:10
21.16.0.0/12 [120/1] via 10.11.111.111, 00:00:10
21.32.0.0/11 [120/1] via 10.11.111.111, 00:00:10
21.64.0.0/10 [120/1] via 10.11.111.111, 00:00:10
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 279
Task 13
Configure R7 to inject a default route.
The default-information originate command can be used to generate a default route into the RIP
database. Routers configured with this command propagate a default route to their RIP neighbors.
The task requires R7 to generate a default route and advertise it to R1. However, recall from the
previous task, R1 was configured to only permit networks from R7 that matched specific prefix lengths.
The implicit deny at the end of the prefix list NET would prevent any other networks from being
accepted by R1, including a default route.
To allow R1 to accept a default route from R7, the prefix list NET on R1 needs to be modified by adding
an additional prefix-list statement that permits default routes. For this purpose, the command ip prefixlength NET permit 0.0.0.0/0 is added on R1 where 0.0.0.0/0 in this context means a default route. The
show ip prefix-list command output verifies this change. R7 is then configured with the defaultinformation originate command that causes it to generate and propagate a default route to R1:
On R1:
R1(config)#ip prefix-list NET permit 0.0.0.0/0
R1#show ip prefix-list
ip prefix-list NET: 2 entries
seq 5 permit 0.0.0.0/0 ge 10 le 14
seq 10 permit 0.0.0.0/0
On R7:
R7(config)#router rip
R7(config-router)#default-information originate
The show ip route rip | include 10.11.111.111 command on R1 verifies the default route from R7:
To verify the configuration:
On R1:
R1#show ip route rip | include 10.11.111.111
Gateway of last resort is 10.11.111.111 to network 0.0.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 280
R*
R
R
R
R
R
0.0.0.0/0 [120/1] via 10.11.111.111, 00:00:08
21.4.0.0/14 [120/1] via 10.11.111.111, 00:00:08
21.8.0.0/13 [120/1] via 10.11.111.111, 00:00:08
21.16.0.0/12 [120/1] via 10.11.111.111, 00:00:08
21.32.0.0/11 [120/1] via 10.11.111.111, 00:00:08
21.64.0.0/10 [120/1] via 10.11.111.111, 00:00:08
Task 14
Configure R4 to filter the default route injected by R7.
The default route generated at R7 as a result of the default-information originate command is propagated
to R1. R1 injects this into its own RIP database and propagates it further down all interfaces enabled for
RIPv2. This process continues on every router receiving the default route resulting in all devices running
RIPv2 in the topology receiving and installing the default route.
An example of this is seen in R4’s routing table who receives the default route from R1:
On R4:
R4#show ip route rip | i 0.0.0.0/0
R*
0.0.0.0/0 [120/2] via 14.1.1.1, 00:00:12
The task specifically requires filtering of this default route on R4. This is easily achieved by configuring a
prefix list on R4 that denies the default route 0.0.0.0/0 and an explicit permit statement that permits
everything else. A distribute-list referencing this prefix-list with the keyword in, indicating inbound
updates from the dialer and g0/2 interfaces is configured under the router rip configuration mode as seen
below
R4(config)#ip prefix TST seq 5 deny 0.0.0.0/0
R4(config)#ip prefix TST seq 10 permit 0.0.0.0/0 le 32
R4(config)#router rip
R4(config-router)#distribute-list prefix TST in g0/2
R4(config-router)#distribute-list prefix TST in dialer41
To verify the configuration:
R4#clear ip route *
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 281
After clearing the routing table with the clear ip route * command, the show ip route rip | include 0.0.0.0
verifies the filtering of the default route:
R4#show ip route rip | include 0.0.0.0/0
R4#
Task 15
Configure SW4 such that it always prefers to reach network 10.1.4.0/24 through R6.
1. SW4 should use R5 when R6 is down.
2. Restrictions: Do not use an offset list to accomplish this task.
SW4 receives similar RIP routing updates for the 10.1.4.0/24 network from both R5 and R6 and installs
paths via both routers in its routing table. This is seen below:
On SW4:
SW4#show ip route 10.1.4.0
Routing entry for 10.1.4.0/24
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 10.1.1.5 on Vlan10, 00:00:10 ago
Routing Descriptor Blocks:
10.1.1.6, from 10.1.1.6, 00:00:19 ago, via Vlan10
Route metric is 2, traffic share count is 1
* 10.1.1.5, from 10.1.1.5, 00:00:10 ago, via Vlan10
Route metric is 2, traffic share count is 1
The task requires making changes on SW4 such that it uses the path through R6 as the primary path and
should R6 fail, it switches over to the backup path via R5. One of the ways to achieve this would be by
modifying the metric through off set list to make the path via R6 more preferable. However, the task
restricts the use of offset-list to achieve this.
Another way to accomplish the change would be by modifying the administrative distance of the RIP
route from R5 to something higher than the default AD value of 120. This way, SW4 will prefer the route
with a lower AD value of 120 from R6 and install it in its routing table.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 282
For this first the network is identified with an access-list using the access-list 1 permit 10.1.4.0 0.0.0.255
command. The AD for a RIP route can then be modified with the distance 121 10.1.1.5 0.0.0.0 1
command. This command sets the distance for the prefix specified in the access-list 1 to 121 for updates
that are sourced from 10.1.1.5 address, which is R5’s interface on the 10.1.1.0/24 segment:
SW4(config)#access-list 1 permit 10.1.4.0 0.0.0.255
SW4(config)#router rip
SW4(config-router)#distance 121 10.1.1.5 0.0.0.0 1
SW4#clear ip route *
After issuing the clear ip route * command on SW4, the routing table on SW4 verifies it uses the path
from R6 to reach the 10.1.4.0 network:
To verify the configuration:
SW4#show ip route 10.1.4.0
Routing entry for 10.1.4.0/24
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 10.1.1.6 on Vlan10, 00:00:10 ago
Routing Descriptor Blocks:
* 10.1.1.6, from 10.1.1.6, 00:00:10 ago, via Vlan10
Route metric is 2, traffic share count is 1
To test the failover, the G0/9 interface on R6 is shutdown. The result is SW4 installing the path from R5
with an AD of 121 in its routing table:
To test the configuration:
On R6:
R6(config)#interface g0/9
R6(config-if)#shut
On SW4:
SW4#clear ip route *
SW4#show ip route 10.1.4.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 283
Routing entry for 10.1.4.0/24
Known via "rip", distance 121, metric 2
Redistributing via rip
Last update from 10.1.1.5 on Vlan10, 00:00:10 ago
Routing Descriptor Blocks:
* 10.1.1.5, from 10.1.1.5, 00:00:10 ago, via Vlan10
Route metric is 2, traffic share count is 1
On R6:
R6(config)#int g0/9
R6(config-if)#no shut
Task 16
Configure SW4 to filter network 50.5.5.0/24. Do not use an access list to accomplish this
task.
SW4 learns the 50.5.5.0/24 network from R5 as seen below:
On SW4:
SW4#show ip route rip | i 50.5.5.0
R
50.5.5.0 [120/1] via 10.1.1.5, 00:00:13, Vlan10
The task requires routing update filtering on SW4 to prevent this network from appearing in the routing
table while restricting the use of access-list to achieve the same. An alternative would be using a
combination of prefix-lists and distribute-lists to perform filtering:
First a prefix-list NET-50 is configured to deny the 50.5.5.0/24 network. This is followed with another
prefix-list statement that explicitly permits all routes - indicated with 0.0.0.0/0 le 32. The prefix-list is
then referenced in the distribute-list NET-50, that is applied inbound on the VLAN10 interface on SW4 as
seen below:
SW4(config)#ip prefix-list NET-50 deny 50.5.5.0/24
SW4(config)#ip prefix-list NET-50 permit 0.0.0.0/0 le 32
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 284
SW4(config)#router rip
SW4(config-router)#distribute-list prefix NET-50 in vlan10
The result of the above configuration is SW4 filtering the updates for the 50.5.5.0/24 network, while the
explicit prefix-list permit statement permits everything else. After issuing a clear ip route * on SW4, the
routing table on SW4 verifies the 55.5.5.0 network no longer exists:
To verify the configuration:
On SW4:
SW4#clear ip route *
SW4#show ip route 50.5.5.0
% Network not in table
Task 17
Configure R4 such that it injects a default route into the RIPv2 routing domain.
1. Restrictions :
a. This default route should not be given to R6.
b. Do not configure R6 to accomplish this task. R5 should only have a default
route from R4.
Similar to task 13, this task too requires propagation of a default route, but on R4. The task however
requires that the default route be propagated by R4 only to R5 and not to R6. In addition, the task
restricts making any configuration changes on R6 to achieve the same.
This can be achieved by using a route-map that specifies the output interface for the RIP routing update
with the set interface g0/5 command. The route-map is then appended to the default-information
originate command on R4. This results in R4 sending out a RIP update for the default route only out its
G0/5 interface connected to R5. Since the update is not sent out the G0/6 interface, R6 does not learn
the default route from R4.
The configuration for the above is implemented below:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 285
On R4:
R4(config)#route-map TST permit 10
R4(config-route-map)#set interface g0/5
You may get the following console message:
%Warning:Use P2P interface for routemap setinterface clause
R4(config)#router rip
R4(config-router)#default-information originate route-map TST
R4#clear ip route *
The show ip route 0.0.0.0 command output on R5 and R6 confirm R5 learns the default route from R4
and R6 does not learn the default route from R4. Note, the above configuration does not prevent R6
from learning the default route from R5 over the VLAN 10 segment and installing it in its routing table.
To verify the configuration:
On R5:
R5#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "rip", distance 120, metric 1, candidate default path
Redistributing via rip
Last update from 45.1.1.4 on GigabitEthernet0/4, 00:00:03 ago
Routing Descriptor Blocks:
* 45.1.1.4, from 45.1.1.4, 00:00:03 ago, via GigabitEthernet0/4
Route metric is 1, traffic share count is 1
R5#show ip route rip | i 0.0.0.0/0
R*
0.0.0.0/0 [120/7] via 45.1.1.4, 00:00:01, GigabitEthernet0/4
Task 18
Configure R3 to summarize its Loopback Lo0–Lo3, Lo30–Lo33 and advertise two summary
routes into the RIP routing domain.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 286
Following are the loopback addresses on R3. The task requires performing RIP summarization for the
Loopback 0 through Loopback 3 and Loopback 30 through Loopback 33 addresses:
On R3:
R3#show ip interface brief | exclude unassigned
Interface
Loopback0
Loopback1
Loopback2
Loopback3
Loopback4
Loopback5
Loopback6
Loopback7
Loopback8
Loopback9
Loopback10
Loopback30
Loopback31
Loopback32
Loopback33
IP-Address
30.3.0.1
30.3.1.1
30.3.2.1
30.3.3.1
30.3.4.1
30.3.5.1
30.3.6.1
30.3.7.1
30.3.8.1
30.3.9.1
30.3.10.1
3.3.0.3
3.3.1.3
3.3.2.3
3.3.3.3
OK? Method Status
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
YES manual up
Protocol
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
The show ip route rip | include 3.3 and show ip route rip | include 30.3 command output on R3’s
directly connected neighbors SW1 and R1 show the specific routes prior to any summarization:
On SW1:
SW1#show ip route rip | i 3.3.
R
R
R
R
3.3.0.0 [120/1] via 113.1.1.3, 00:00:19, Ethernet0/3
3.3.1.0 [120/1] via 113.1.1.3, 00:00:19, Ethernet0/3
3.3.2.0 [120/1] via 113.1.1.3, 00:00:19, Ethernet0/3
3.3.3.0 [120/1] via 113.1.1.3, 00:00:19, Ethernet0/3
SW1#show ip route rip | include 30.3.
R
R
R
R
R
R
30.3.0.0 [120/1] via 113.1.1.3, 00:00:28, Ethernet0/3
30.3.2.0 [120/1] via 113.1.1.3, 00:00:28, Ethernet0/3
30.3.4.0 [120/1] via 113.1.1.3, 00:00:28, Ethernet0/3
30.3.6.0 [120/1] via 113.1.1.3, 00:00:28, Ethernet0/3
30.3.8.0 [120/1] via 113.1.1.3, 00:00:28, Ethernet0/3
30.3.10.0 [120/1] via 113.1.1.3, 00:00:28, Ethernet0/3
On R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 287
R1#show ip route rip | include 3.3.
R
R
R
R
3.3.0.0 [120/1] via 200.1.1.3, 00:00:22, GigabitEthernet9
3.3.1.0 [120/1] via 200.1.1.3, 00:00:22, GigabitEthernet9
3.3.2.0 [120/1] via 200.1.1.3, 00:00:22, GigabitEthernet9
3.3.3.0 [120/1] via 200.1.1.3, 00:00:22, GigabitEthernet9
R1#show ip route rip | include 30.3.
R
R
R
R
R
R
30.3.0.0 [120/1] via 200.1.1.3, 00:00:00, GigabitEthernet9
30.3.2.0 [120/1] via 200.1.1.3, 00:00:00, GigabitEthernet9
30.3.4.0 [120/1] via 200.1.1.3, 00:00:00, GigabitEthernet9
30.3.6.0 [120/1] via 200.1.1.3, 00:00:00, GigabitEthernet9
30.3.8.0 [120/1] via 200.1.1.3, 00:00:00, GigabitEthernet9
30.3.10.0 [120/1] via 200.1.1.3, 00:00:00, GigabitEthernet9
RIP summarization can be performed with the ip summary-address rip interface level command. This
command is issued on the G0/0, G0/1 and G0/9 interfaces on R3. This causes R3 to send RIP updates for
the summary out these interfaces:
On R3:
R3(config)#interface g0/0
R3(config-if)#ip summary-address rip 3.3.0.0 255.255.252.0
R3(config-if)#ip summary-address rip 30.3.0.0 255.255.252.0
R3(config-if)#interface g0/1
R3(config-if)#ip summary-address rip 3.3.0.0 255.255.252.0
R3(config-if)#ip summary-address rip 30.3.0.0 255.255.252.0
R3(config-if)#interface g0/9
R3(config-if)#ip summary-address rip 3.3.0.0 255.255.252.0
R3(config-if)#ip summary-address rip 30.3.0.0 255.255.252.0
The show ip route rip | include /22 command output from SW1 and R1 verifies the above configuration.
Notice the missing specific routes from the earlier output have now been replace with summary routes:
On SW1:
SW1#show ip route rip | include /22
R
3.0.0.0/22 is subnetted, 1 subnets
30.3.0.0/22 [120/1] via 113.1.1.3, 00:00:11, Ethernet0/3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 288
On R1:
R1#show ip route rip | include /22
R
R
3.3.0.0/22 [120/1] via 200.1.1.3, 00:00:12, GigabitEthernet9
30.3.0.0/22 [120/1] via 200.1.1.3, 00:00:12, GigabitEthernet9
Task 19
Configure Lo200 with the IP address 120.2.2.2/24 on SW2. This switch should advertise this
network in the RIPv2 routing domain. Configure SW1 such that this network is never
advertised to any router downstream/beyond SW4, as those are future devices connected
to SW4.
The following first configures a loopback 200 interface on SW2 and assigns the IP Address 120.2.2.2/24
to it. The network is then advertised into RIP with a network statement:
On SW2:
SW2(config)#interface lo200
SW2(config-if)#ip address 120.2.2.2 255.255.255.0
SW2(config-if)#router rip
SW2(config-router)#network 120.0.0.0
SW4’s routing table verifies it learns a RIP route for the 120.2.2.0/24 network:
To verify the configuration:
On SW4:
SW4#show ip route rip | include 120.2.2.0
R
120.2.2.0 [120/6] via 10.1.1.6, 00:00:02, Vlan10
RIP uses a hop count metric to determine which routes are more preferred. The lower the hop count,
the more preferred the route will be. The hop-count is initialized as 1 by the router that originates the
route. This original router advertises the route to its RIP neighbor with the hop count of 1. The RIP
neighbor increments this metric by 1 as it advertises it to its own RIP neighbors. This process continues
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 289
until the metric grows to 15 hops which is the maximum metric that can be stored within RIP. If the
router receiving the route with metric 15 advertises it to another RIP neighbor, the hop count becomes
16 which is considered inaccessible in RIP.
To solve the task, this 15 hop count limit is exploited. To do so, configuration changes are made on SW1
such that once the route to 120.2.2.0/24 reaches SW4, its hop count is at 15. With the hop count at 15
on SW4, any other router SW4 advertises the route to will reject it because the hop count received
would be 16. In this way, the diameter of the RIP update in the network topology can be restrained to up
until SW4.
To make this a reality, SW1 just needs to advertise the route to R3 with a larger metric value. Looking at
the output above SW4 receives the prefix 120.2.2.0/24 with a hop count of 6. To complete the task, we
need this value to be 15. By computing 15 - 6, the value of 9 is obtained. This is the value that should be
artificially added to SW1’s advertisement to R3. To understand this, let’s configure an offset list on SW1
that modifies the metric to a value of 9 with an offset list for the 120.2.2.0/24 network.
A standard access-list identifying and permitting the 120.2.2.0/24 network is first created on SW1. The
access-list is then referenced on the offset list that specifies the hop count value, RIP metric of 9. It is
applied outbound for the G0/3 interface:
To configure SW1:
SW1(config)#access-list 1 permit 120.2.2.0 0.0.0.255
SW1(config)#router rip
SW1(config-router)#offset 1 out 9 g0/3
SW1#clear ip route *
On configuring the above, and issuing the clear ip route * command, following output shows the metric
as 11 for the 120.2.2.0/24 network on R3:
To verify the configuration:
On R3:
R3#show ip rout 120.2.2.0
Routing entry for 120.2.2.0/24
Known via "rip", distance 120, metric 11
Redistributing via rip
Last update from 113.1.1.11 on GigabitEthernet0/10, 00:00:20 ago
Routing Descriptor Blocks:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 290
* 113.1.1.11, from 113.1.1.11, 00:00:20 ago, via GigabitEthernet0/10
Route metric is 11, traffic share count is 1
The reason R3 has the route with a hop count of 11, is because in RIPv2, the hop count is incremented
on the way out. Therefore, SW2 advertises the route with a hop count of 1, SW1 adds one to the
received hop count when it advertises it to R3, but it also adds another 9 hops because of the offset-list
configured, this sums up to 11.
Following examines the hop count values at each device between R3 and SW4:
On R1:
R1#show ip route 120.2.2.0
Routing entry for 120.2.2.0/24
Known via "rip", distance 120, metric 12
Redistributing via rip
Last update from 10.1.100.3 on GigabitEthernet0/3, 00:00:06 ago
Routing Descriptor Blocks:
200.1.1.3, from 200.1.1.3, 00:00:23 ago, via GigabitEthernet0/9
Route metric is 12, traffic share count is 1
* 10.1.100.3, from 10.1.100.3, 00:00:06 ago, via GigabitEthernet0/3
Route metric is 12, traffic share count is 1
On R4:
R4#show ip route 120.2.2.0
Routing entry for 120.2.2.0/24
Known via "rip", distance 120, metric 13
Redistributing via rip
Last update from 14.1.1.1 00:00:19 ago
Routing Descriptor Blocks:
* 14.1.1.1, from 14.1.1.1, 00:00:19 ago
Route metric is 13, traffic share count is 1
On R5:
R5#show ip route 120.2.2.0
Routing entry for 120.2.2.0/24
Known via "rip", distance 120, metric 14
Redistributing via rip
Last update from 45.1.1.4 on GigabitEthernet0/4, 00:00:25 ago
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 291
Routing Descriptor Blocks:
* 45.1.1.4, from 45.1.1.4, 00:00:25 ago, via GigabitEthernet0/4
Route metric is 14, traffic share count is 1
On SW4:
SW4#show ip route 120.2.2.0
Routing entry for 120.2.2.0/24
Known via "rip", distance 120, metric 15
Redistributing via rip
Last update from 10.1.1.6 on Vlan10, 00:00:10 ago
Routing Descriptor Blocks:
* 10.1.1.6, from 10.1.1.6, 00:00:10 ago, via Vlan10
Route metric is 15, traffic share count is 1
10.1.1.5, from 10.1.1.5, 00:00:17 ago, via Vlan10
Route metric is 15, traffic share count is 1
The hop count for the update on SW4, as seen above, is 15. This means, when SW4 advertises this route
to a device that might connect to it at a later time, it will add one to the hop count value of 15. The
receiving RIP speaker will receive the update with the hop count of 16. Since an update for a network
with a hop count value of 16 is deemed as unreachable in RIP, devices that connect to SW4 will not
accept or install the route as the task desires.
Task 20
Erase the startup configuration of the routers, the startup configuration, and the VLAN.dat
file for each switch and reload the devices before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 292
Lab 2 – Helper Map
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
RIPv2 folder  Lab-2.
Task 1
Configure OSPF Area 0 on the following interfaces:

The G0/1, G0/3, and loopback0 interfaces of R2

All directly connected interfaces of R3

The G0/3 interface of R4
As required by the task, the following configures OSPF process 1 on R2, R3 and R4. OSPF for Area 0 is
enabled on all the interfaces specified in the task using the network statement under the OSPF router
configuration mode:
On R2:
R2(config)#router ospf 1
R2(config-router)#network 23.1.1.2 0.0.0.0 area 0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 293
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0
On R3:
R3(config)#router ospf 1
R3(config-router)#network 0.0.0.0 0.0.0.0 area 0
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/2 from
LOADING to FULL, Loading Done
On R4:
R4(config)#router ospf 1
R4(config-router)#network 34.1.1.4 0.0.0.0 area 0
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 34.1.1.3 on GigabitEthernet0/3 from
LOADING to FULL, Loading Done
To verify the configuration:
On R2:
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [110/2] via 23.1.1.3, 00:02:24, GigabitEthernet0/3
On R4:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [110/3] via 34.1.1.3, 00:01:09, GigabitEthernet0/3
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/2] via 34.1.1.3, 00:01:09, GigabitEthernet0/3
Task 2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 294
Configure RIPv2 on the:
 Lo0 and G0/2 interfaces of R1

G0/4 interface on R5
Disable auto-summarization on these devices.
The router rip command is first issued to enter the RIP configuration mode on R1 and R5. Following this, the
no auto-summary disables auto summary that is enabled by default. The RIP version is set to 2 with the
version 2 command. Finally, the network command is issued to advertise the networks on the interface
mentioned in the task:
On R1:
R1(config)#router rip
R1(config-router)#no auto-summary
R1(config-router)#version 2
R1(config-router)#network 12.0.0.0
R1(config-router)#network 1.0.0.0
On R5:
R5(config)#router rip
R5(config-router)#no auto-summary
R5(config-router)#version 2
R5(config-router)#network 45.0.0.0
Task 3
Configure multicasting on the appropriate routers such that R5 receives all the RIPv2
updates from R1.
 R2 should be configured as the RP and the BSR router. This router should use its
loopback interface as the source of all its BSR messages.
 You must use 224.1.1.1 to accomplish this task.
 Restrictions:
a. Do not run multiple unicast routing protocols on any of the routers.
b. Do not configure GRE, IPnIP, MPLS, LDP, or any type of tunneling to
accomplish this task.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 295
The setup of the lab is as follows:
1. R1 is configured for RIPv2. It is advertising it’s loopback address 1.1.1.1/32 and the 12.1.1.0/24
network into RIP
2. R5 is configured for RIPv2. It is advertising the 45.1.1.0/24 network into RIP
3. Routers R2, R3 and R4 in transit are not configured for RIP
In this lab, R1 is meant to advertise RIPv2 routes to R5. RIPv2 uses link-local multicast IP address 224.0.0.9
to send routing updates. Link-local multicast cannot be routed across multiple router hops. The result is,
RIP routes sent by R1 will not be received by R5 by default. This task's goal is to configure the network such
that R1’s routes reach R5 without configuring additional unicast routing protocols, tunnels, or MPLS label
switching.
Solving this task requires an understanding of multicast/broadcast traffic, how Cisco routers can be
configured to forward multicast/broadcast traffic, and advanced understanding of how RIP sends its
updates. First and foremost, an understanding of multicast and broadcast traffic is in order.
Broadcast traffic is considered one-to-all communication. A broadcast traffic sent onto a LAN is sent to all
hosts on that LAN. Broadcast traffic is constrained to the local network and is not allowed to be routed to
other networks by Layer 3 devices. Multicast traffic is one-to-many communication. Traffic sent as
multicast is only delivered to those devices that wish to receive the multicast stream. Because of this more
specific and constrained view of multicast traffic, it can be routed between subnets by Layer 3 devices. This
function is called multicast routing and is facilitated by multicast routing protocols such as Protocol
Independent Sparse Mode (PIM-SM).
Cisco IOS routers can be configured to forward multicast traffic. The ip multicast-routing command
enables multicast routing on the router. This command has a similar effect as the ip unicast-routing
command that is enabled by default. It enables the router to build and maintain the data structures
necessary to forward multicast traffic. This includes being able to participate in the multicast routing
protocol.
Cisco IOS routers can forward broadcast traffic but in a limited fashion. The ip helper-address command
can be used to convert broadcast traffic received on an interface into unicast packets to a specific
destination. This command is commonly used to forward BOOTP or DHCP packets received on a router’s
LAN interface to a DHCP server that exists in a different subnet. The ip helper-address command only
works on broadcast traffic that matches the following criteria according to Cisco documentation:
1. The MAC address of received frame must be the all-ones broadcast MAC address
FFFF.FFFF.FFFF
2. The destination IP address must be either:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 296
a. the all-ones broadcast address (255.255.255.255)
b. the subnet broadcast address for the receiving interface (for e.g.
192.168.1.255 where 192.168.1.0/24 is the subnet)
3. IP TTL is at least 2
4. IP protocol is UDP
5. UDP destination ports are:
a. TFTP , Domain Name System (DNS), Time , NetBIOS, ND, BOOTP or DHCP.
b. Any UDP port identified by the ip forward-protocol udp command
Cisco routers can also be configured to convert broadcast traffic to multicast traffic using the ip multicast
helper-map broadcast command. This command works similar to the ip helper-address command only this
time, broadcast UDP traffic that meets the same criteria as the ip helper-address command is converted to
a multicast group IP address.
To complete the picture, multicast traffic can be converted back to broadcast traffic using the ip multicast
helper-map command. This command works by specifying a multicast group address to match and convert
and the broadcast address to which it should be converted. The broadcast address can be the all-ones
broadcast or a subnet broadcast address.
Finally, RIP sends its routing updates in two different ways depending on which RIP version is enabled on
the router. RIPv1 broadcasts updates onto the LAN by default while, as mentioned earlier, RIPv2 multicasts
its updates to the 224.0.0.9 address. The router can, however, be configured to send multicast RIPv2
updates as broadcast messages out specific interfaces. This is achieved with the ip rip v2-broadcast
command in interface configuration mode.
All of these points above can be combined to solve this task. The basic idea is as follows:
1. Configure R1 to send RIPv2 updates to R2 as broadcast instead of multicast.
2. Configure R2 to convert the received RIP broadcast packets to multicast
3. Configure R2, R3, and R4 to route the converted RIP multicast updates
4. Configure R4 to convert the multicast RIP update to broadcast to R5’s subnet
The first step is necessary because the aim is to use the ip multicast helper-map command to convert the
traffic to multicast. As mentioned earlier, RIPv2 sends its packets as link-local multicast that cannot be
routed across subnets. The workaround is to have RIPv2 send its packets as broadcast and to have R2
convert the broadcast packets into routable multicast packets. The first part of this conversion is to
configure the ip rip v2-broadcast command on R1’s G0/2 interface towards R2.
On R1:
R1(config)#interface g0/2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 297
R1(config-if)#ip rip v2-broadcast
Step two configures R2 to perform the conversion of broadcast into multicast. Two things need to be
configured for this to be successful:
1. R2 must be configured to forward UDP RIP packets
2. R2 must identify which traffic should be converted to multicast
The first step is a requirement based on the criteria for triggering the ip multicast helper-map command.
The traffic being converted must be a broadcast sent to either to the specific UDP ports outlined above or
matched using the ip forward-protocol udp command. In this case, it is desired to forward RIP traffic which
is not forwarded by default. Because it is not forwarded by default, the ip forward-protocol udp rip
command must be configured to manually configure the router to forward and convert packets to UDP
port 520 which is the well-known UDP port for RIP.
The second part of this configuration is to identify what specific traffic flow should be converted to
multicast when the ip multicast helper-map command is configured. An extended ACL is used to serve this
purpose. The ACL must match RIP traffic broadcast by R1 and received on R2’s g0/1 interface. In this case,
the protocol is UDP, the source IP is 12.1.1.1 (R1), the source port is RIP (520), the destination can be the
broadcast address 255.255.255.255, and the destination port should also be RIP. The resulting ACL is:
access-list 100 permit udp host 12.1.1.1 eq rip host 255.255.255.255 eq rip.
With those two pieces configured, R2 can be configured with the ip multicast helper-map broadcast
command under its G0/1 interface. The ip multicast helper-map broadcast command should convert all
UDP packets matched by access-list 100 to the multicast group address 224.1.1.1. 224.1.1.1 is designated
as the multicast group address to be compliant with restrictions outlined in the task. Finally, the TTL of the
resulting packet is set to 3 to ensure the multicast only travels the span of the network. The resulting
command is ip multicast helper-map broadcast 224.1.1.1 100 ttl 3.
The following is the complete configuration on R2 for this step:
Enable helper forwarding for broadcast RIP packets
On R2:
R2(config)#ip forward-protocol udp rip
Identify RIP traffic originating from R1
R2(config)#access-list 100 permit udp host 12.1.1.1 eq rip host
255.255.255.255 eq rip
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 298
Convert identified broadcast traffic into multicast traffic
R2(config)#interface g0/1
R2(config-if)#ip multicast helper-map broadcast 224.1.1.1 100 ttl 3
Note in the above configurations that the access-list 100 is matched in the second argument of the ip
multicast helper-map broadcast command. This applies the filter for broadcast-to-multicast mapping to
only packets matched by ACL 100.
At this point, R1 is broadcasting RIPv2 updates to R2 and R2 is converting those RIPv2 updates to multicast.
The next step is to ensure R2, R3, and R4 can successfully route the multicast packets across the network.
This requires configuring IP multicast routing on those three routers. The task indirectly specifies what kind
of multicast routing should be utilized. It mentions that R2 should be the rendezvous point (RP) and
bootstrap router (BSR) for the multicast network using its loopback interface as the source of BSR
messages. The requirement points to the use of PIM-SM as the multicast routing protocol. PIM SM requires
the use of an RP to join multicast senders with multicast receivers.
The RP runs the control plane of the PIM-SM domain by being the default sender and receiver of all
multicast traffic. Routers will forward multicast traffic in encapsulated PIM tunnels to the RP when a
receiver is unknown and will send PIM Join messages to the RP when a receiver is online but a sender is
unknown. PIM-SM creates a multicast “pull” network where multicast traffic is only sent if requested by an
intended receiver.
In order for PIM-SM to work, all routers must know the location of the RP. This is what BSR is designed to
do. Routers that want to serve as RP advertise their willingness to the BSR. The BSR then advertises the set
of received RP advertisements in PIM messages to its PIM neighbors. Those neighbors advertise the same
set of RP advertisements to their PIM neighbors and so on. Once a router receives the set of RP
advertisements it runs a hashing algorithm to determine which router will be used as the RP.
To configure multicast routing, the ip multicast-routing command is first enabled on R2, R3 and R4. After
enabling multicast routing, the ip pim sparse-mode command is configured on R2’s g0/1 and g0/3
interfaces; on R3’s g0/2 and g0/4 interfaces; and on R4’s g0/3 interface. Then, R2 is configured as an RP
candidate using the ip pim rp-candidate lo0 and as the BSR using the ip pim bsr-candidate lo0 command.
The addition of the “lo0” designation forces R2 to use its own Loopback 0 interface as the source of its BSR
messages and as its RP address as directed by the task requirements.
First, multicast routing and PIM-SM are enabled on the routers as indicated:
On R2, R3 and R4:
Rx(config)#ip multicast-routing
On R2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 299
R2(config)#interface g0/1
R2(config-if)#ip pim sparse-mode
R2(config)#interface g0/3
R2(config-if)#ip pim sparse-mode
R2(config)#interface lo0
R2(config-if)#ip pim sparse-mode
On R3:
R3(config)#interface g0/2
R3(config-if)#ip pim sparse-mode
R3(config)#interface g0/4
R3(config-if)#ip pim sparse-mode
On R4:
R4(config)#interface g0/3
R4(config-if)#ip pim sparse-mode
After configuring the above the show ip pim neighbor | begin Interface command can be used to verify
the PIM neighborships have been established between the routers.
On R2:
R2#show ip pim neighbor | begin Interface
Neighbor
Address
34.1.1.3
Interface
Uptime/Expires
DR
Prio/Mode
00:00:44/00:01:30 v2
1 / S P G
GigabitEthernet0/3
ver
On R3:
R3#show ip pim neighbor | begin Interface
Neighbor
Address
23.1.1.2
34.1.1.4
Interface
Uptime/Expires
DR
Prio/Mode
00:01:01/00:01:43 v2
1 / S P G
00:00:44/00:01:29 v2
1 / S P G
GigabitEthernet0/2
GigabitEthernet0/4
ver
On R4:
R4#show ip pim neighbor | begin Interface
Neighbor
Address
Interface
CCIE by Narbik Kocharians
Uptime/Expires
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
ver
DR
Prio/Mode
Page 300
34.1.1.3
GigabitEthernet0/3
00:01:47/00:01:25 v2
1 / S P G
After PIM is verified, R2 is then configured to become the RP and BSR:
On R2:
R2(config)#ip pim rp-candidate lo0
R2(config)#ip pim bsr-candidate lo0
This configuration is verified using the show ip pim rp mapping as seen below. R3 and R4 both have R2
designated as the RP. Note : it may take up to 150 seconds for the BSR mapping to propagate to all the
routers.
On R3:
R3#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:10, expires: 00:02:24
On R4:
R4#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:01:24, expires: 00:02:09
After configuring the above and verifying the following has been completed:
1. R1 is broadcasting RIPv2 packets to R2
2. R2 is converting only those broadcast RIP packets to multicast packets destined to group address
224.1.1.1
3. R2, R3, and R4 are configured to route multicast packers across the network.
The final steps are to enable R4 to convert the multicast traffic it receives from its PIM neighbor R3 back
into broadcast traffic and send this traffic to R5. This process is very similar to the process used on R2. First,
R4 needs to be configured to forward the UDP RIP traffic using the ip forward-protocol udp rip command.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 301
Next, an ACL is configured to identify the specific multicast traffic flow to convert to broadcast. This ACL
matches any UDP 520 (RIP) packets sent by R1. The resulting ACL should be access-list 100 permit udp
host 12.1.1.1 eq rip any rip. Then the ip multicast helper-map 224.1.1.1 45.1.1.255 100 command is
configured. This command takes multicast traffic sent to the 224.1.1.1 multicast group address and
converts it to a subnet broadcast traffic sent to 45.1.1.255 if it matches ACL 100.
Why was the subnet broadcast address 45.1.1.5 chosen instead of a generic broadcast address? Using the
subnet broadcast address allows R4 to route the packet only to the indicated destination subnet and not
broadcast to all subnets once converted. Such packets are called directed broadcast packets because they
are “routable” broadcast packets that are sent to a specific subnet. The only caveat with directed
broadcasts is that, by default, the router will not forward directed broadcasts out of an interface for
security reasons. The behavior can be modified using the ip directed-broadcast command configured on
the intended exit interface which is R4’s g0/5 interface.
The following is the last part of the configuration for this section:
On R4:
Configure R4 to forward udp 520 (RIP) packets
R4(config)#ip forward-protocol udp rip
Configure an ACL to match traffic RIP traffic sourced from R1:
R4(config)#access-list 100 permit udp host 12.1.1.1 any eq rip
Configure this traffic to be forwarded as directed broadcast to the subnet broadcast address of the R4/R5
link
R4(config)#interface g0/3
R4(config-if)#ip multicast helper-map 224.1.1.1 45.1.1.255 100
Enable R4 to forward directed broadcast packets out its interface to R5
R4(config)#interface g0/5
R4(config-if)#ip directed-broadcast
The ip multicast helper-map command does more than just simply configure R4 to convert the multicast
packet into a directed broadcast packet. Once configured, R4 will actually send a PIM join to the RP to
begin receiving traffic for the multicast group indicated by the command as shown in the debug ip pim
output below.
Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 224.1.1.1
PIM(0): Insert (*,224.1.1.1) join in nbr 34.1.1.3's queue
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 302
Building Join/Prune packet for nbr 34.1.1.3
Adding v2 (2.2.2.2/32, 224.1.1.1), WC-bit, RPT-bit, S-bit Join
Send v2 join/prune to 34.1.1.3 (GigabitEthernet0/3)
This step is imperative to the PIM-SM pull model because multicast traffic would not be sent to R4 unless
R4 requests it.
After the above configuration everything is set for route advertisement. To verify the configuration, R1 can
be triggered to send updates by issuing the clear ip route * command multiple times.
To generate RIP traffic:
On R1:
R1#clear ip route *
R1#clear ip route *
R1#clear ip route *
R1#clear ip route *
After issuing the commands the routing table on R5 does not populate RIP routes from R1 evidenced by
the show ip route rip | begin Gate command output below. The included debug ip rip output on R5
reveals the reason:
On R5:
R5#show ip route rip | begin Gate
Gateway of last resort is not set
R5#debug ip rip
RIP: ignored v2 update from bad source 12.1.1.1 on GigabitEthernet0/4
R5 is ignoring the update received on its G0/4 interface because the source IP address is not on the same
subnet as R5’s IP address on that interface. To force R5 to bypass this check the no validate-update-source
command is executed on R5:
On R5:
R5(config)#router rip
R5(config-router)#no validate-update-source
RIP: received v2 update from 12.1.1.1 on GigabitEthernet0/4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 303
1.1.1.1/32 via 0.0.0.0 in 1 hops
In the above, after disabling the source verification, R5 logs that it received a RIP update from R1. The
resultant show ip route output proves that as the task desires, R5 received and processed the RIP update
from R1:
R5#show ip route rip | b Gate
Gateway of last resort is not set
R
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [120/1] via 12.1.1.1, 00:00:24
Task 4
Erase the startup configuration and reload the routers before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 304
Lab 3
RIPv2 Challenge Lab
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
RIPv2 folder  Lab-3.
Ticket 1
R1 is configured to filter its Lo41. However, this interface is still reachable from R5.

Restrictions:
a. Do not configure another access list, prefix list, or route map.
b. Use only two commands to accomplish this task.
Before solving this ticket, let’s first test the claim that R5 has rechability to IP address 192.168.4.1
configured on R1’s loopback 41 address. As seen below, the ping from R5 to 192.168.4.1 succeeds:
On R5:
R5#ping 192.168.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
.!!!!
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 305
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
The next step would be to verify the routing entries on R5 for this network with the show ip route
192.168.4.1 command:
R5#show ip route 192.168.4.1
Routing entry for 192.168.4.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.15.1 on GigabitEthernet0/1, 00:00:08 ago
Routing Descriptor Blocks:
* 5.100.157.1, from 5.100.157.1, 00:00:22 ago, via GigabitEthernet0/9
Route metric is 1, traffic share count is 1
5.100.15.1, from 5.100.15.1, 00:00:08 ago, via GigabitEthernet0/1
Route metric is 1, traffic share count is 1
In the output above, we notice that R5 has two paths in its routing table for the 192.168.4.1 network. This is
odd since the ticket claims R1 is configured to filter these networks from being advertised into RIPv2.
However, before confirming the filtering on R1, a keen observer would notice an anomaly in the output
above. The loopback 41 IP address 192.168.4.1 has been assigned a /32 mask on R1. R5’s routing table in
the above however shows that this prefix is rechabile via a /24 route.
To investigate this, let’s check the show ip protocol | section rip command output on R1:
On R1:
R1#show ip protocol | section rip
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
GigabitEthernet0/5 filtered by toR5 (per-user), default is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 27 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
GigabitEthernet0/5
2
2
GigabitEthernet0/9
2
2
TST
Loopback0
2
2
Loopback41
2
2
Loopback42
2
2
Automatic network summarization is in effect
Maximum path: 4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 306
Routing for Networks:
5.0.0.0
192.168.4.0
192.168.4.0
Routing Information Sources:
Gateway
Distance
5.100.15.5
120
Gateway
Distance
5.100.157.5
120
Distance: (default is 120)
Last Update
00:00:09
Last Update
00:00:02
We’ve spotted the culprit, auto summarization that is turned on by default in RIP, hasn’t been turned off on
R1. As a result of this, R1 advertises the 192.168.4.0/24 classful network to R3 and R5. Though R1 is
performing filtering, the access-list toR5 is configured to only filter the 192.168.4.1 prefix. It is not filtering
the 192.168.4.0/24 summary. The permit any ACL statement allows the summary to be advertised to R5:
On R1:
ip access-list standard toR5
deny 192.168.4.1
permit any
Let’s rectify this behaviour and turn off auto summarization with the no auto-summary command under the
RIP router configuration mode on R1 as seen below:
R1#show run | section router rip
router rip
version 2
network 5.0.0.0
network 192.168.4.0
distribute-list toR5 out GigabitEthernet0/5
We can see that the “no auto-summary” command is missing. Let’s correct this and verify.
R1(config)#router rip
R1(config-router)#no auto-summary
After the above configuration changes, R5 now receives the exact 192.168.4.1/32 prefix. However now
unlike the output shown earlier, R5’s routing table now shows only a single route to reach the 192.168.4.1
prefix via R3. Meaning, the 192.168.4.1 prefix is reachable only through R3 and not R1.
On R5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 307
R5#show ip route 192.168.4.1
Routing entry for 192.168.4.1/32
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.157.1 on GigabitEthernet0/9, 00:00:26 ago
Routing Descriptor Blocks:
* 5.100.157.1, from 5.100.157.1, 00:00:26 ago, via GigabitEthernet0/9
Route metric is 1, traffic share count is 1
A ping is issued again from R5 to verify rechability. As seen below, the ping succeeds and a traceroute
verifies the path via R3. Recall, the task requires that this address should not be reachable from R5:
R5#ping 192.168.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R5#traceroute 192.168.4.1
Type escape sequence to abort.
Tracing the route to 192.168.4.1
VRF info: (vrf in name/id, vrf out name/id)
1 5.100.157.1 1 msec * 1 msec
With the above we can conclude that R5 is performing some form of filtering since R5 is receiving the prefix
only from R3. Let’s observe the show ip protocol | inc filtered command output on R1:
On R1:
R1#show ip protocols | include filtered
GigabitEthernet0/5 filtered by toR5 (per-user), default is not set
Once again, another culprit has been identified. R1 is performing filtering as the ticket states, however, only
on the interface G0/5 that is connected to R5. R1 needs to be configured to filter the RIP update out its G0/9
interface as well, to prevent R3 from advertising it to R5. There are two ways this can be achieved:
1. Remove the current distribute-list and re-enter it without specifying any interface. This way, the
filtering is applied to all interface enable for RIP, OR
2. Reuse the same distribute-list and access-list combination, except this time, specify the interface
G0/9 (distribute-list toR5 out GigabitEthernet0/9)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 308
This lab solution chooses to use the first method where the interface specified is omitted from the
distribute-list resulting in the filtering be applied to ALL interfaces on R1 that are enabled for RIPv2:
R1(config)#router rip
R1(config-router)#no distribute-list toR5 out GigabitEthernet0/5
R1(config-router)#distribute-list toR5 out
On issuing a clear ip route * on R5, the routing table now shows no entries for the 192.168.4.1 prefix and as
the task desires. A pings issued to the 192.168.4.1 address fails:
On R5:
R5#show ip route 192.168.4.1
% Subnet not in table
R5#ping 192.168.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
.....
Ticket 2
R7 is configured to filter all even third octet networks (for example, x.x.2.x, x.x.4.x,
x.x.6.x) with the mask /24. However, this has affected all routes, and none of them are
reachable from R2.
The ticket claims that R2 does not have any rechability to any routes advertised by R7. Observing the routing table on
R2 below, verifies this claim. As seen, R2’s routing shows no routes have been learned from R7:
On R2:
R2#show ip route rip | b Gate
Gateway of last resort is not set
5.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 309
R
R
R
R
R
R
5.100.15.0/24 [120/1] via 5.100.245.5, 00:00:11, Tunnel1
5.100.99.1/32 [120/2] via 5.100.245.5, 00:00:11, Tunnel1
5.100.99.5/32 [120/1] via 5.100.245.5, 00:00:11, Tunnel1
5.100.157.0/24 [120/1] via 5.100.245.5, 00:00:11, Tunnel1
192.168.4.0/32 is subnetted, 2 subnets
192.168.4.1 [120/2] via 5.100.245.5, 00:01:59, Tunnel1
192.168.4.2 [120/2] via 5.100.245.5, 00:00:11, Tunnel1
We begin investigating by looking at the show ip protocol command output on R2 to check if the interface
G0/7 that connects to R7 is configured to receive RIPv2 updates:
R2#show ip protocol | b Interface
Interface
Send Recv Triggered RIP
GigabitEthernet0/7
2
2
Loopback0
2
2
Tunnel1
2
2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
5.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
5.100.245.5
120
00:00:28
Distance: (default is 120)
Key-chain
The highlighted output above does verify that R2 is listening for RIPv2 updates from R7. Let’s issue the
debug ip rip command on R2 to see if this hints to any issues:
R2#debug ip rip
RIP protocol debugging is on
RIP: ignored v1 packet from 5.100.212.21 (illegal version)
On turning on the debug, we notice a very peculiar message “illegal version” for the RIP packets sourced
from R7’s interface address 5.100.212.21. This message is seen when the neighboring router sends an
update that the local router is configured to not accept. R7 is configured to send only RIPv1 updates out its
interfaces, and R2 is configured to accept only RIPv2 updates. Notice the highlighted output below verifies
this on R7:
R2#undebug all
On R7:
R7#show ip protocol | begin Interface
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 310
Interface
Send Recv Triggered RIP
GigabitEthernet0/2
1
1 2
GigabitEthernet0/9
1
1 2
Automatic network summarization is not in effect
(The rest of the output is omitted for brevity)
Key-chain
txt
By default, a router configured for RIP is able to receive RIPv1 and RIPv2 packets, however it only sends
Version 1 packets. The show run | s router rip from R7 also shows the missing version 2 command:
R7#show run | sec router rip
router rip
passive-interface Loopback210
passive-interface Loopback211
passive-interface Loopback212
passive-interface Loopback213
passive-interface Loopback214
passive-interface Loopback215
passive-interface Loopback216
passive-interface Loopback217
passive-interface Loopback218
passive-interface Loopback219
network 5.0.0.0
network 192.168.210.0
network 192.168.211.0
network 192.168.212.0
network 192.168.213.0
network 192.168.214.0
network 192.168.215.0
no validate-update
network 192.168.216.0
network 192.168.217.0
network 192.168.218.0
network 192.168.219.0
distribute-list 10 out
no auto-summary
To ensure R7 sends version 2 packets, the version is specified with the version 2 command under the router
RIP configuration mode on R7:
R7(config)#router rip
R7(config-router)#version 2
R7#clear ip route *
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 311
As a result of the above changes, R2 now receives and accepts the RIPv2 packets from R7 and populates its
routing table with the RIP routes R7 is configured to send as seen below:
To verify the configuration:
On R2:
R2#show ip route rip | b Gate
Gateway of last resort is not set
R
R
R
R
R
R
R
R
R
R
5.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
5.100.15.0/24 [120/1] via 5.100.245.5, 00:00:19, Tunnel1
5.100.99.1/32 [120/2] via 5.100.245.5, 00:00:19, Tunnel1
5.100.99.5/32 [120/1] via 5.100.245.5, 00:00:19, Tunnel1
5.100.157.0/24 [120/1] via 5.100.245.5, 00:00:19, Tunnel1
[120/1] via 5.100.212.21, 00:00:14, GigabitEthernet0/7
192.168.4.0/32 is subnetted, 1 subnets
192.168.4.2 [120/2] via 5.100.245.5, 00:00:19, Tunnel1
192.168.211.0/24 [120/1] via 5.100.212.21, 00:00:14, GigabitEthernet0/7
192.168.213.0/24 [120/1] via 5.100.212.21, 00:00:14, GigabitEthernet0/7
192.168.215.0/24 [120/1] via 5.100.212.21, 00:00:14, GigabitEthernet0/7
192.168.217.0/24 [120/1] via 5.100.212.21, 00:00:14, GigabitEthernet0/7
192.168.219.0/24 [120/1] via 5.100.212.21, 00:00:14, GigabitEthernet0/7
Ticket 3
R4 can’t reach R1’s Lo42 using its Lo0 as the source:
 Use a single command to fix this problem.
A ping is issued from R4’s Ioopback 0 IP address, 5.100.99.1 to R1’s loopback 42 IP address, 192.168.4.2 to
verify the issue. As seen below, the ping fails:
On R4:
R4#ping 192.168.4.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.2, timeout is 2 seconds:
Packet sent with a source address of 5.100.99.4
.....
Success rate is 0 percent (0/5)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 312
Next a ping to the 192.168.4.2 address is issued again from R4, but this time without specifying any source
interface:
R4#ping 192.168.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/51/52 ms
When a specific source is not specified in a ping, the router will default to using the source interface it uses
to reach the destination. As seen below, R4’s routing table shows it uses its Tunnel 1 interface to reach the
192.168.4.2 address. This means, R4 sources the above ping from the IP address assigned to it’s Tunnel 1
interface, 5.100.245.5
R4#show ip route 192.168.4.2
Routing entry for 192.168.4.2/32
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 5.100.245.5 on Tunnel1, 00:00:06 ago
Routing Descriptor Blocks:
* 5.100.245.5, from 5.100.245.5, 00:00:06 ago, via Tunnel1
Route metric is 2, traffic share count is 1
With the above two tests, we conclude two things:
1. The ping sourced from the routers tunnel 1 interface succeeded. This means, R1 has a route to the IP
address 5.100.245.5 since it was able to return the ICMP traffic for the pings issued
2. The ping sourced from the 5.100.99.1 failed. Meaning, either R1 does not have a route to this
address to return the traffic or some form of filtering is preventing rechability.
Let’s look at the routing table on R1 to see if it has a route to the 5.100.99.4 address:
On R1:
R1#show ip route 5.100.99.4
% Subnet not in table
Clearly, as seen above, R1 does not have a route to this address. What about R5?
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 313
On R5:
R5#show ip route 5.100.99.4
% Subnet not in table
R5 does not have a route to the 5.100.99.4 address either. Let’s verify if R5 is receiving RIP updates from R4
for this prefix by turning on RIP debugging with the debug ip rip command:
R5#debug ip rip
RIP protocol debugging is on
*May 9 22:37:52.425: RIP: sending v2 update to 224.0.0.9 via Loopback0
(5.100.99.5)
RIP: build update entries
5.100.15.0/24 via 0.0.0.0, metric 1, tag 0
5.100.99.1/32 via 0.0.0.0, metric 2, tag 0
5.100.157.0/24 via 0.0.0.0, metric 1, tag 0
5.100.245.0/24 via 0.0.0.0, metric 1, tag 0
192.168.4.2/32 via 0.0.0.0, metric 2, tag 0
RIP: ignored v2 packet from 5.100.99.5 (sourced from one of our
addresses)
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (5.100.15.5)
RIP: build update entries
5.100.99.5/32 via 0.0.0.0, metric 1, tag 0
5.100.157.0/24 via 0.0.0.0, metric 1, tag 0
5.100.245.0/24 via 0.0.0.0, metric 1, tag 0
RIP: received v2 update from 5.100.15.1 on GigabitEthernet0/1
5.100.99.1/32 via 0.0.0.0 in 1 hops
5.100.157.0/24 via 0.0.0.0 in 1 hops
192.168.4.2/32 via 0.0.0.0 in 1 hops
RIP: sending v2 update to 224.0.0.9 via Tunnel1 (5.100.245.5)
RIP: build update entries
5.100.15.0/24 via 0.0.0.0, metric 1, tag 0
5.100.99.1/32 via 0.0.0.0, metric 2, tag 0
5.100.99.5/32 via 0.0.0.0, metric 1, tag 0
5.100.157.0/24 via 0.0.0.0, metric 1, tag 0
As seen above, we see no trace of any RIP updates for the 5.100.99.4 prefix on R5. Observing R4’s RIP
configuration reveals the issue:
R5#undebug all
All possible debugging has been turned off
Let’s verify R4’s RIP configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 314
On R4:
R4#show run | s router rip
router rip
version 2
passive-interface default
network 5.0.0.0
no auto-summary
R4 has been configured with the passive-interface default command. This command prevents the router
from sending RIP updates out ALL RIP enabled interfaces. As a result, information about the 5.100.99.4
prefix configured on R4 is not advertised out the tunnel 1 interface. To rectify the situation, issue the no
passive-interface tunnel 1 command under the router RIP configuration mode on R4 as shown below:
R4(config)#router rip
R4(config-router)#no passive-interface tunnel 1
As a result, R1’s routing table now has a route to the 5.100.99.4 address on R4. A ping from R4’s loopback 0
interface is now successful as seen below (Note : It may take a small delay for RIPv2 to converge before the
ping succeeds)
R4#ping 192.168.4.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.2, timeout is 2 seconds:
Packet sent with a source address of 5.100.99.4
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 2/2/2 ms
Ticket 4
R2 is configured to filter its G0/7 interface with the IP address 5.100.212.2/24, but R5 can’t
reach R2’s Lo0.
Loopback 0 on R2 has been assigned the IP address 5.100.99.2. The ticket claims that this address is not
reachable from R5. A ping from R5 to this address fails and the routing table verifies that R5 does not have a
route to this prefix:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 315
On R5:
R5#ping 5.100.99.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
On R5:
R5#show ip route 5.100.99.2
% Subnet not in table
The show ip protocol | section rip command output shows some form of outgoing filtering is configured for
ALL interfaces on R2. The prefix-list referenced for this filter is called plIn.
On R2:
R2#show ip protocol | section rip
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is (prefix-list) plIn
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 21 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
GigabitEthernet0/7
2
2
Loopback0
2
2
Tunnel1
2
2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
5.0.0.0
5.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
5.100.245.5
120
00:00:00
5.100.212.21
120
00:00:12
Distance: (default is 120)
A show ip prefix-list is issued on R2 to check the contents of the prefix-list:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 316
R2#show ip prefix-list
ip prefix-list plIn: 2 entries
seq 5 deny 5.100.212.0/24
seq 10 permit 0.0.0.0/0
As the ticket indicates, R2 is configured to filter the RIP updates for the network assigned to it’s G0/7
interface. The second prefix-list state permits 0.0.0.0/0. This explicit statement is erroneously configured to
permit a default route. The correct configuration should be a catch-all entry, that is permit everything else
with the permit 0.0.0.0/0 le 32. The configuration is rectified by removing the prefix-list, recreating it, but
this time adding le 32 to prefix list sequence 10 statement as seen below:
R2(config)#no ip prefix-list plIn
R2(config)#ip prefix-list plIn seq 5 deny 5.100.212.0/24
R2(config)#ip prefix-list plIn seq 10 permit 0.0.0.0/0 le 32
On issuing a clear ip route *, RIP updates for all networks except the 5.100.212.0/24 are sent out by R2. R5’s
routing table verifies this. It has now installed the route to R2’s loopback address 5.100.99.2/32:
R2#clear ip route *
Let’s verify and see if R5 can reach R2’s Lo0:
On R5:
R5#clear ip route *
R5#show ip route 5.100.99.2
Routing entry for 5.100.99.2/32
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.245.2 on Tunnel1, 00:00:01 ago
Routing Descriptor Blocks:
* 5.100.245.2, from 5.100.245.2, 00:00:01 ago, via Tunnel1
Route metric is 1, traffic share count is 1
A ping to this address from R5 now succeeds:
R5#ping 5.100.99.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
!!!!!
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 317
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/54/56 ms
Ticket 5
R4 can’t reach R2’s Lo0 interface.

Restrictions:
a. Do not configure the neighbor command.
b. Do not change the DMVPN phase or configure DMVPN in a dynamic manner.
A ping from R4 to R2’s loopback 0 IP address 5.100.99.2 fails as seen below:
On R4:
R4#ping 5.100.99.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
The routing table on R4 shows it has no route to the prefix:
R4#show ip route 5.100.99.2
% Subnet not in table
R2’s RIP configuration verifies that its correctly configured to advertise the 5.0.0.0 network into RIP:
On R2:
R2#show run | s rip
router rip
version 2
network 5.0.0.0
distribute-list prefix plIn out
no auto-summary
R5 routing table is checked to verify if it is receiving this network from R2 via RIP and as seen below, R5 has
a RIP route installed for the 5.100.99.2 prefix:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 318
On R5:
R5#show ip route 5.100.99.2
Routing entry for 5.100.99.2/32
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.245.2 on Tunnel1, 00:00:26 ago
Routing Descriptor Blocks:
* 5.100.245.2, from 5.100.245.2, 00:00:26 ago, via Tunnel1
Route metric is 1, traffic share count is 1
A ping from R5 to the 5.100.99.2 is issued to verify rechability:
R5#ping 5.100.99.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
So, from the above we conclude, R2 is advertising it’s loopback 0 address into RIP and R5’s routing table
confirms it is receiving it. The network however is missing from R4’s routing table.
The reason for this is split-horizon. As noted from the diagram, R5, R2 and R4 form a DMVPN with R5
servicing as the NHS, or the hub. When running a DV protocol like RIP over DMVPN, the hub by default will
not advertise routes it receives over an interface out the same interface. Meaning, in this topology, when R5
receives a RIP update from R2 over it’s tunnel interface, it will not advertise this update out the same tunnel
interface to R4 because of the split-horizon. The show ip interface tunnel 1 command output below verifies
that split-horizon is enabled:
R5#show ip interface tunnel 1
Tunnel1 is up, line protocol is up
Internet address is 5.100.245.5/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1476 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.9
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 319
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
To allow R5 to advertise the RIP update from R2 to R4, split-horizon needs to be disabled for RIP on R5’s
tunnel interface with the no ip split-horizon command. The show ip interface tunnel 1 verifies this change:
R5(config)#interface tunnel 1
R5(config-if)#no ip split-horizon
To verify the configuration:
R5#show ip interface tunnel 1
Tunnel1 is up, line protocol is up
Internet address is 5.100.245.5/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1476 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.9
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is disabled
On disabling split-horizon, the hub R5 now advertises RIP updates from R2 to R4. This is confirmed in the
output below where R4 now has a route to the 5.100.99.2 prefix:
On R4:
R4#show ip route 5.100.99.2
Routing entry for 5.100.99.2/32
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 5.100.245.2 on Tunnel1, 00:00:12 ago
Routing Descriptor Blocks:
* 5.100.245.2, from 5.100.245.5, 00:00:12 ago, via Tunnel1
Route metric is 2, traffic share count is 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 320
A ping to the 5.100.99.2 address is once again issued from R4 to verify rechability. However as noted below,
the pings still fail:
R4#ping 5.100.99.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Observing the tunnel configurations on R4 and R2 we notice R4 and R2 are missing each other's VPN-toNBMA mappings entries:
On R4:
interface Tunnel1
ip address 5.100.245.4 255.255.255.0
no ip redirects
ip nhrp map 5.100.245.5 192.1.5.5
ip nhrp map multicast 192.1.5.5
ip nhrp network-id 444
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
On R2:
interface Tunnel1
ip address 5.100.245.2 255.255.255.0
no ip redirects
ip nhrp map 5.100.245.5 192.1.5.5
ip nhrp map multicast 192.1.5.5
ip nhrp network-id 222
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
This is also confirmed with the conditional debugging turned on, on R4. While pinging R2’s tunnel IP address
5.100.245.2, R4 displays the message encapsulation failed:
On R4:
R4#debug condition interface tunnel 1
Condition 1 set
R4#debug ip packet
IP packet debugging is on
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 321
Now, let’s ping the next-hop IP address again:
R4#ping 5.100.245.2 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.100.245.2, timeout is 2 seconds:
IP: s=5.100.245.4 (local), d=224.0.0.9 (Tunnel1), len 72, sending
broad/multicast
IP: s=5.100.245.4 (local), d=224.0.0.9 (Tunnel1), len 72, sending full
packet
IP: s=5.100.245.4 (local), d=5.100.245.2 (Tunnel1), len 100, sending
IP: s=5.100.245.4 (local), d=5.100.245.2 (Tunnel1), len 100,
encapsulation failed.
Success rate is 0 percent (0/1)
The issues is rectified by creating static NHRP mapping entries on R2 and R4 for each others tunnel IP and
NBMA addresses as seen below:
R4#undebug all
All possible debugging has been turned off
R4(config)#interface tunnel 1
R4(config-if)#ip nhrp map 5.100.245.2 192.1.2.2
Static mapping on R2 for return traffic:
On R2:
R2(config)#interface tunnel 1
R2(config-if)#ip nhrp map 5.100.245.4 192.1.4.4
A ping to R2’s loopback 0 address from R4 now succeeds:
On R4:
R4#ping 5.100.99.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 322
Ticket 6
R3 can’t ping R1’s Lo0.
A ping from R3 to R1’s loopback 0 address 5.100.99.1 verifies the fail:
On R3:
R3#ping 5.100.99.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3’s routing table shows that is has no route to the 5.100.99.1 address:
R3#show ip route 5.100.99.1
% Subnet not in table
The command debug ip rip is issued on R3 to turn RIP debugging on. R3 seems to be receiving RIP updates
from R1, however the log message displays invalid authentication:
R3#debug ip rip
RIP protocol debugging is on
RIP: received packet with MD5 authentication
RIP: ignored v2 packet from 5.100.157.1 (invalid authentication)
The configurations on R1 and R3 are examined to spot the issue. As seen, both routers are configured with
key chains that contain a single key with the passphrase ccie. A show run | i _ccie$ on R1 and R3 however
reveals a problem. The command issued on R1 returns the key-string output. The same however issued on
R3, returns no output:
R3#undebug all
All possible debugging has been turned off
On R1:
R1#show run | section key chain
key chain TST
key 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 323
key-string ccie
R1#show run interface g0/9 | b interface
interface FastEthernet0/1
ip address 5.100.157.1 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain TST
end
R1#show run | i _ccie$
key-string ccie
The last command is entered to check for spaces after the password.
On R3:
R3#show run | section key chain
key chain TST
key 1
key-string ccie
R3#show run interface g0/9 | begin interface
interface GigabitEthernet0/9
ip address 5.100.157.3 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain TST
duplex auto
speed auto
media-type rj45
end
R3#show run | include _ccie$
R3#
The reason the command show run | include _ccie$ returns no output on R3 is because of the extra space
included when typing the password ccie on R3. To rectify the issue, the password is reentered on R3, this
time making sure no white space is added on after the key-string ccie:
R3(config)#key chain TST
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string ccie
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 324
To verify the problem:
On R3:
R3#show run | include _ccie$
key-string ccie
With the key-string values now matching on both ends, RIP updates are accepted at both ends. Pings from
R3 to R1’s address succeed as shown below:
To test the configuration:
On R3:
R3#ping 5.100.99.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.99.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Ticket 7
R3 is configured to filter all routes received from R5. However, the routes are still there. Do
not use another method to fix this problem; correct the existing problem.
A show ip route issued on R3 verifies it is receiving RIP routes from R5:
On R3:
R3#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
5.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
5.100.4.0/24 [120/2] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
5.100.15.0/24 [120/1] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
[120/1] via 5.100.157.1, 00:00:26, GigabitEthernet0/9
5.100.99.1/32 [120/1] via 5.100.157.1, 00:00:26, GigabitEthernet0/9
5.100.99.2/32 [120/2] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 325
R
R
R
R
R
R
R
R
R
5.100.99.4/32 [120/2] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
5.100.99.5/32 [120/1] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
5.100.245.0/24 [120/1] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
192.168.4.0/32 is subnetted, 1 subnets
192.168.4.2 [120/1] via 5.100.157.1, 00:00:26, GigabitEthernet0/9
192.168.211.0/24 [120/3] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
192.168.213.0/24 [120/3] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
192.168.215.0/24 [120/3] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
192.168.217.0/24 [120/3] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
192.168.219.0/24 [120/3] via 5.100.157.5, 00:00:09, GigabitEthernet0/9
The ticket however claims that R3 is configured to filter routes from R5. The show ip protocol command
output on R3 can be to verify any route filtering R3 is configured for. As seen in the highlighted output
below, R3 has been configured to filter RIP updates on its interfaces for the addresses specified in the ACL
157:
R3#show ip protocol | section rip
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is 157
Sending updates every 30 seconds, next due in 21 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
GigabitEthernet0/9
2
2
TST
Loopback0
2
2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
5.0.0.0
5.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
5.100.157.5
120
00:00:21
5.100.157.1
120
00:00:11
Distance: (default is 120)
Let’s verify the access-list:
R3#show access-list 157
Extended IP access list 157
10 deny ip any host 5.100.157.5
20 permit ip any any (182 matches)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 326
The above output reveals an incorrectly configured access-list. When using an extended access-list here for
route filtering purposes from a specific source, the source portion of the extended access-list should
reference the source of RIP update message, which is R5’s address 5.100.157.5, The destination portion of
the extended access-list should reference the actual routes that need to be permitted or denied from the
specified source. But as seen above, the addresses have been swapped.
To rectify the configuration, the access-list 157 is first removed on R3 with the no access-list 157 command.
The access-list is reconfigured this time keeping in mind to insert R5’s address 5.100.157.5 in the source
portion and the keyword any in the destination portion of the ACL:
On R3:
R3(config)#no access-list 157
R3(config)#access-list 157 deny ip host 5.100.157.5 any
R3(config)#access-list 157 permit ip any any
On issuing a clear ip route *, we notice the RIP routes from R5 no longer exist in the routing table on R3:
R3#clear ip route *
R3#show ip route rip | b Gate
Gateway of last resort is not set
R
R
R
5.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
5.100.15.0/24 [120/1] via 5.100.157.1, 00:00:14, GigabitEthernet0/9
5.100.99.1/32 [120/1] via 5.100.157.1, 00:00:14, GigabitEthernet0/9
192.168.4.0/32 is subnetted, 1 subnets
192.168.4.2 [120/1] via 5.100.157.1, 00:00:14, GigabitEthernet0/9
Ticket 8
R7 should not have any RIPv2 routes in its routing table. You must configure an outbound
filter using a standard numbered ACL and a distribute-list command on the G0/7 interface
of R2 to accomplish this task. You are allowed to remove one command.
First a single access-list statement denying all updates is configured on R2. The access-list is then referenced
in a distribute-list that is applied outbound on R2 in an attempt to prevent R2 from advertising RIP routes to
R7. This is then followed by a clear ip route * command on R2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 327
On R2:
R2(config)#access-list 1 deny any
R2(config)#router rip
R2(config-router)#distribute-list 1 out g0/7
R2#clear ip route *
The above configuration however does not result in the intended consequences. After issuing a clear ip
route * on R7, R7 still continues to receive RIP updates as seen below:
On R7:
R7#clear ip route *
R7#show ip route rip | begin Gate
Gateway of last resort is not set
R
R
R
R
R
R
R
R
R
5.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
5.100.4.0/24 [120/2] via 5.100.157.5, 00:00:03, GigabitEthernet0/9
5.100.15.0/24 [120/1] via 5.100.157.5, 00:00:03, GigabitEthernet0/9
[120/1] via 5.100.157.1, 00:00:08, GigabitEthernet0/9
5.100.99.1/32 [120/1] via 5.100.157.1, 00:00:08, GigabitEthernet0/9
5.100.99.2/32 [120/2] via 5.100.157.5, 00:00:03, GigabitEthernet0/9
5.100.99.3/32 [120/1] via 5.100.157.3, 00:00:07, GigabitEthernet0/9
5.100.99.4/32 [120/2] via 5.100.157.5, 00:00:03, GigabitEthernet0/9
5.100.99.5/32 [120/1] via 5.100.157.5, 00:00:03, GigabitEthernet0/9
5.100.245.0/24 [120/1] via 5.100.157.5, 00:00:03, GigabitEthernet0/9
192.168.4.0/32 is subnetted, 1 subnets
192.168.4.2 [120/1] via 5.100.157.1, 00:00:08, GigabitEthernet0/9
A peculiarity is the output above is the exit interface of G0/9 for the RIP routes on R7. The addresses above
exist on routers that are not directly connected to R7, namely R5, R3, R1. Pings are issued from R7 to R5, R3,
R1 to check it has rechability to them. The pings fail as seen below:
R7#ping 5.100.157.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.157.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R7#ping 5.100.157.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.157.1, timeout is 2 seconds:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 328
.....
Success rate is 0 percent (0/5)
R7#ping 5.100.157.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.100.157.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
With the above we can conclude that R7 does not have rechability to those routers, so it shouldn’t have
learned the RIP routes directly from them. However, observing SW2 helps expose how R7 is receiving routes
from routers it isn’t connected to. Have a look at the show interface e1/3 status on SW2:
On SW2:
SW2#show interface e1/3 status
Port
Name
Et1/3
Status
Vlan
monitoring
1
Duplex
Speed Type
half
auto RJ45
A monitor session is configured to take all traffic from R3’s G0/9 interface and forward it to the port that R7
is connected to . This is why R7 is receiving these routes. This problem is fixed with a no monitor session 1
command on SW2:
SW2#show run | include monitor session
monitor session 1 source interface Et0/3
monitor session 1 destination interface Et1/3
SW2(config)#no monitor session 1
On issuing a clear ip route *, we see R7 no longer receives any RIP routes as evidenced by the show ip route
rip command output below:
On R7:
R7#clear ip route *
R7#show ip route rip | begin Gate
Gateway of last resort is not set
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 329
Ticket 9
Erase the startup configuration and reload the devices before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 330
Chapter 4
CCIE
Enterprise Infrastructure
Foundation
v1.0
www.MicronicsTraining.com
Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP
EIGRP
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 331
Lab 1
EIGRP Named Mode
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
EIGRP folder  Lab-1.
Task 1
Configure EIGRP on R1, R2, and R3 based on the following policy:
Router
Interface
AS Number
R1
G0/9
G0/0
G0/2
G0/3
Loopback0–
Loopback3
200
100
100
100
100
R2
G0/9
200
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 332
R3



G0/1
G0/3
Loopback0
100
100
100
G0/1
G0/2
Loopback0
100
100
100
R1 should be configured to use unicast to establish an EIGRP neighbor adjacency
with R2.
R1 should use multicast to establish an EIGRP neighbor adjacency with R3.
R1, R2, and R3 should use an EIGRP named mode configuration to accomplish this
task.
EIGRP named mode is a new configuration mode for EIGRP that was introduced in IOS 15.0(1)M, 12.2(33)SRE,
12.2(33)XNE, and IOS XE release 2.5. It contains many enhancements to EIGRP, most notably unifying EIGRP
configuration commands to a single location in the router configuration.
Prior to EIGRP named mode, some EIGRP configuration commands such as authentication and
summarization, had to be configured under a specific interface. Certain commands such as redistribution and
setting the router ID could be configured in global configuration mode. EIGRP named mode allows all of
these configurations to exist in one location using global configuration mode. Interface-level commands are
configured using the af-interface command within the EIGRP router configuration.
EIGRP named mode also unifies IPv4 and IPv6 configuration. Previously, EIGRP IPv6 configuration needed to
be enabled separately using the ipv6 router eigrp command in global configuration mode. EIGRP named
mode supports both IPv4 and IPv6 using address families. The address-family ipv6 and address-family ipv4
commands configure the protocol to run for IPv6 and IPv4 respectively.
Basic EIGRP named mode configuration is similar to normal IPv4 configuration. The router eigrp command is
issued to enable the configuration. The difference is, instead of specifying the AS number, an alphanumeric
string (text containing letters or numbers) should be entered that designates the EIGRP virtual instance that
is being defined. This virtual instance name does not have to match between EIGRP neighbors. Only the
actual AS number configured for the routing protocol process must match between EIGRP neighbors. The
actual AS number is configured using the address-family [ipv4 | ipv6] unicast autonomous-system
command with the numeric AS number included.
Unlike RIP, automatic summarization is disabled by default in EIGRP. The show run does not display the
default setting of auto summary even if no auto-summary has been configured. However, the setting will be
displayed if auto summary is turned on.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 333
The following configurations are made on R1, R2 and R3 to run EIGRP in named mode and advertise the
networks specified in the task:
R1 is first configured to run EIGRP named mode for the virtual instance named tst with the router eigrp tst
command. Then the command address-family ipv4 unicast autonomous-system 100 is entered to create and
enter the IPv4 address-family configuration mode for AS 100. EIGRP is then enabled on the interface with the
network command as specified in the task above:
On R1:
R1(config)#router eigrp tst
R1(config-router)#address-family ipv4 unicast autonomous-system 100
R1(config-router-af)#network 12.1.1.1 0.0.0.0
R1(config-router-af)#network 13.1.1.1 0.0.0.0
R1(config-router-af)#network 145.1.1.1 0.0.0.0
R1(config-router-af)#network 1.1.0.1 0.0.0.0
R1(config-router-af)#network 1.1.1.1 0.0.0.0
R1(config-router-af)#network 1.1.2.1 0.0.0.0
R1(config-router-af)#network 1.1.3.1 0.0.0.0
Note : address-family ipv4 as 100 the shorter version of the command address-family ipv4 unicast
autonomous-system 100 is also accepted by IOS.
By default when EIGRP is enabled on an interface, it multicast EIGRP packets to the 224.0.0.10 address to
discover neighbors. The task however requires R1 to use unicast to form an EIGRP neighbor adjacency with
R2. This hints towards using the neighbor command on R1 and R2 to statically form EIGRP adjacencies with
each other. The neighbor command deactivates the transmission of the EIGRP multicast packets on the
specified interface and will cause the router to drop any packets multicasted to the address 224.0.0.10. R1 is
configured below to form a static EIGRP adjacency with R2 using the neighbor 12.1.1.2 G0/2 command.
When using the neighbor command, it is important to specify the interface over which the local router will
attempt to form unicast adjacencies with the neighbor.
R1(config-router-af)#neighbor 12.1.1.2 g0/2
The task specifies that R1 and R2 should also participate in EIGRP AS 200 over their g0/9 interface. EIGRP
named mode only supports a single ASN per address-family in a single virtual instance. Because of this, it is
not possible to configure a second ASN in the same tst EIGRP virtual instance configured on R1 and R2. In
order to complete this part of the task, a second EIGRP virtual instance called tst200 is created for IPv4 AS
200 on R1. This is done with the address-family ipv4 unicast autonomous-system 200 command under the
router eigrp tst200 configuration mode. EIGRP instance for AS 200 is enabled on the G0/9 interface with the
network 10.1.1.1 0.0.0.0 command:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 334
R1(config)#router eigrp tst200
R1(config-router)#address-family ipv4 as 200
R1(config-router-af)#network 10.1.1.1 0.0.0.0
Next, EIGRP named mode is configured on R2. First, a virtual instance called tst is created to hold the
configuration for EIGRP AS 100. Then, the interfaces g0/1, g0/3, and loopback 0 are all added to the EIGRP AS
100 process as indicated by the task. Finally, a static neighbor command is added to R2’s configuration to
allow it to form a neighbor adjacency with R1. Without this step, R2 would not be able to become neighbors
with R1 because of R1’s previous static neighbor configuration. The reason is because R1 is expecting unicast
hello packets from R2’s interface IP address while R2 is multicasting hellos onto the link. This mismatch
causes R1 to ignore the hellos received from R2.
The final, complete configuration for the virtual instance tst on R2 is as follows:
On R2:
R2(config)#router eigrp tst
R2(config-router)#address-family ipv4 as 100
R2(config-router-af)#network 12.1.1.2 0.0.0.0
R2(config-router-af)#network 23.1.1.2 0.0.0.0
R2(config-router-af)#network 2.2.2.2 0.0.0.0
R2(config-router-af)#neighbor 12.1.1.1 g0/1
As soon as R2 is configured with the neighbor statement, a console message indicating that a neighbor
adjacency has been established with neighbor 12.1.1.1 appears as seen below:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 12.1.1.1 (GigabitEthernet0/1)
is up: new adjacency
As with R1, R2 needs to run EIGRP ASN 200 over its G0/9 interface. This requires the creation of a second
virtual instance named tst200. Within this virtual instance, R2 is configured to run EIGRP in named mode for
AS 200 on its G0/9 interface using the network command as shown below:
R2(config)#router eigrp tst200
R2(config-router)#address-family ipv4 as 200
R2(config-router-af)#network 10.1.1.2 0.0.0.0
Finally, the same EIGRP named mode virtual instance tst is configured on R3 as well. Within this virtual
instance, R3’s g0/1, g0/2, and loopback 0 interfaces are enabled to run for EIGRP AS 100 using network
commands. Log messages indicating successful EIGRP neighbor adjacencies to R1 and R2 will appear on R3 as
shown below:
On R3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 335
R3(config)#router eigrp tst
R3(config-router)#address-family ipv4 as 100
R3(config-router-af)#network 23.1.1.3 0.0.0.0
R3(config-router-af)#network 13.1.1.3 0.0.0.0
R3(config-router-af)#network 3.3.3.3 0.0.0.0
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 23.1.1.2 (GigabitEthernet0/2)
is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 13.1.1.1 (GigabitEthernet0/1)
is up: new adjacency
To verify the configuration:
After completing the above configurations, the routing tables on all three routers are examined with the
show ip route eigrp 100 | begin Gate command to verify the EIGRP routes they learn from each other:
On R1:
R1#show ip route eigrp 100 | begin Gateway
Gateway of last resort is not set
D
D
D
2.0.0.0/8 [90/10880] via 12.1.1.2, 00:01:21, GigabitEthernet0/2
3.0.0.0/8 [90/10880] via 13.1.1.3, 00:01:20, GigabitEthernet0/3
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/15360] via 13.1.1.3, 00:01:21, GigabitEthernet0/3
[90/15360] via 12.1.1.2, 00:01:21, GigabitEthernet0/2
On R2:
R2#show ip route eigrp 100 | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
D
1.0.0.0/24 is subnetted, 4 subnets
1.1.0.0 [90/10880] via 12.1.1.1, 00:03:33, GigabitEthernet0/1
1.1.1.0 [90/10880] via 12.1.1.1, 00:03:33, GigabitEthernet0/1
1.1.2.0 [90/10880] via 12.1.1.1, 00:03:33, GigabitEthernet0/1
1.1.3.0 [90/10880] via 12.1.1.1, 00:03:33, GigabitEthernet0/1
3.0.0.0/8 [90/10880] via 23.1.1.3, 00:03:25, GigabitEthernet0/3
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [90/15360] via 23.1.1.3, 00:03:35, GigabitEthernet0/3
[90/15360] via 12.1.1.1, 00:03:35, GigabitEthernet0/1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 336
D
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [90/15360] via 12.1.1.1, 00:03:33, GigabitEthernet0/1
On R3:
R3#show ip route eigrp 100 | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
D
D
1.0.0.0/24 is subnetted, 4 subnets
1.1.0.0 [90/10880] via 13.1.1.1, 00:00:43, GigabitEthernet0/1
1.1.1.0 [90/10880] via 13.1.1.1, 00:00:43, GigabitEthernet0/1
1.1.2.0 [90/10880] via 13.1.1.1, 00:00:43, GigabitEthernet0/1
1.1.3.0 [90/10880] via 13.1.1.1, 00:00:43, GigabitEthernet0/1
2.0.0.0/8 [90/10880] via 23.1.1.2, 00:00:43, GigabitEthernet0/2
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 23.1.1.2, 00:00:43, GigabitEthernet0/2
[90/15360] via 13.1.1.1, 00:00:43, GigabitEthernet0/1
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [90/15360] via 13.1.1.1, 00:00:43, GigabitEthernet0/1
Task 2
Configure R4 and R5 in EIGRP AS 100. You must use named mode to accomplish this task.
As in the earlier task, R4 and R5 are configured to form EIGRP neighbor adjacencies using EIGRP named mode
as seen below. The network command under the address-family IPv4 EIGRP configuration mode enables and
advertises the networks on the interfaces specified in the task:
On R4:
R4(config)#router eigrp tst
R4(config-router)#address-family ipv4 as 100
R4(config-router-af)#network 145.1.1.4 0.0.0.0
R4(config-router-af)#network 4.4.4.4 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 145.1.1.1 (GigabitEthernet0/0)
is up: new adjacency
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 337
On R5:
R5(config)#router eigrp tst
R5(config-router)#address-family ipv4 as 100
R5(config-router-af)#network 5.5.5.5 0.0.0.0
R5(config-router-af)#network 145.1.1.5 0.0.0.0
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 145.1.1.4 (GigabitEthernet0/0)
is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 145.1.1.1 (GigabitEthernet0/0)
is up: new adjacency
On configuring above, R4 and R5 form EIGRP adjacencies with each other and R1. This is confirmed with the
show ip eigrp neighbors command. The show ip route eigrp | begin Gateway command is then used to
verify the EIGRP routes learned by R4 and R5 as seen below:
To verify the configuration:
On R4:
R4#show ip eigrp neighbors
EIGRP-IPv4 VR(tst) Address-Family Neighbors for AS(100)
H
Address
Interface
1
0
145.1.1.5
145.1.1.1
Gi0/0
Gi0/0
Hold Uptime
SRTT
(sec)
(ms)
12 00:04:00
1
11 00:04:46 1021
RTO
Q Seq
Cnt Num
100 0 6
5000 0 16
R4#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
D
D
D
D
1.0.0.0/24 is subnetted, 4 subnets
1.1.0.0 [90/10880] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
1.1.1.0 [90/10880] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
1.1.2.0 [90/10880] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
1.1.3.0 [90/10880] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
2.0.0.0/8 [90/16000] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
3.0.0.0/8 [90/16000] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
5.0.0.0/8 [90/10880] via 145.1.1.5, 00:03:31, GigabitEthernet0/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [90/15360] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 338
D
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/20480] via 145.1.1.1, 00:04:17, GigabitEthernet0/0
On R5:
R5#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
D
D
D
D
D
1.0.0.0/24 is subnetted, 4 subnets
1.1.0.0 [90/10880] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
1.1.1.0 [90/10880] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
1.1.2.0 [90/10880] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
1.1.3.0 [90/10880] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
2.0.0.0/8 [90/16000] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
3.0.0.0/8 [90/16000] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
4.0.0.0/8 [90/10880] via 145.1.1.4, 00:00:42, GigabitEthernet0/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [90/15360] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/20480] via 145.1.1.1, 00:00:42, GigabitEthernet0/0
Task 3
Configure R1, R4, and R5 to use unicast to establish their EIGRP neighbor adjacency.
The following first configures R1 to statically form EIGRP neighbor adjacencies with R4 and R5 using the
neighbor command with G0/0 specified as the interface:
On R1:
R1(config)#router eigrp tst
R1(config-router)#address-family ipv4 as 100
R1(config-router-af)#neighbor 145.1.1.4 g0/0
R1(config-router-af)#neighbor 145.1.1.5 g0/0
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 145.1.1.5 (GigabitEthernet0/0)
is down: Static peer configured
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 339
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 145.1.1.4 (GigabitEthernet0/0)
is down: Static peer configured
On issuing the static neighborship configuration on R1, the CLI displays certain log messages as seen above
indicating EIGRP neighborships to R4 and R5 have gone down. Following this, a show ip eigrp neighbors
command on R1 reveals it hasn’t restored the EIGRP neighborships with R4 and R5:
R1#show ip eigrp neighbors
EIGRP-IPv4 VR(tst) Address-Family Neighbors for AS(100)
H
Address
Interface
Hold Uptime
(sec)
1
13.1.1.3
Gi0/3
11 1d23h
0
12.1.1.2
Gi0/2
13 1d23h
SRTT
(ms)
1
1
RTO
Q Seq
Cnt Num
100 0 24
100 0 23
! No EIGRP adjacencies with R4 and R5
Why hasn’t R1 re-established its EIGRP adjacency to these routers? The answer lies in what happens when
you enable static configuration for EIGRP. As mentioned in Task 1, after configuring static neighbors, a router
expects to receive only unicast hellos from the neighbor on that interface. The use of EIGRP multicast is
entirely deactivated on that interface. This means, if a router receives a multicast hellos on that interface, it
will ignore it. This can be seen in action by turning on EIGRP debugging with the debug eigrp packets
command on R1:
R1#debug eigrp packets
(UPDATE, REQUEST, QUERY, REPLY, HELLO, UNKNOWN, PROBE, ACK, STUB,
SIAQUERY, SIAREPLY)
EIGRP Packet debugging is on
*Aug
*Aug
3 12:42:53.753: EIGRP: Ignore multicast Hello Gi0/0 145.1.1.4
3 12:42:54.016: EIGRP: Ignore multicast Hello Gi0/0 145.1.1.5
R4 and R5 continue to multicast EIGRP hellos in order to discover potential neighbors. R1 configured for
static EIGRP neighborships ignores the multicast hellos received from R4 and R5 as seen above. In fact, R4
and R5 are expecting to receive multicast hellos and as such ignore the unicast hellos transmitted by R1:
On R4 and R5:
*Aug 3 12:49:58.589: EIGRP: Ignore unicast Hello from GigabitEthernet0/0
145.1.1.1
This means, on a multiaccess segment, EIGRP cannot unicast to one or some neighbors and multicast to
others. If static neighborships are intended, all devices on that segment need to be configured to manually
form EIGRP neighbor adjacencies with each other. To complete this task, static neighbor configurations are
made on R4 and R5 as well:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 340
On R4:
R4(config)#router eigrp tst
R4(config-router)#address-family ipv4 as 100
R4(config-router-af)#neighbor 145.1.1.1 g0/0
R4(config-router-af)#neighbor 145.1.1.5 g0/0
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 145.1.1.1 (GigabitEthernet0/0)
is up: new adjacency
On R5:
R5(config)#router eigrp tst
R5(config-router)#address-family ipv4 as 100
R5(config-router-af)#neighbor 145.1.1.1 g0/0
R5(config-router-af)#neighbor 145.1.1.4 g0/0
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 145.1.1.1 (GigabitEthernet0/0)
is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 145.1.1.4 (GigabitEthernet0/0)
is up: new adjacency
On completing the above configuration, log messages confirm the adjacencies. The show ip eigrp neighbors
command also verifies the same and the show ip route eigrp command output verifies the EIGRP routes
learned:
To verify the configuration:
On R4:
R4#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
1.0.0.0/24 is subnetted, 4 subnets
1.1.0.0 [90/10880] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
1.1.1.0 [90/10880] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
1.1.2.0 [90/10880] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
1.1.3.0 [90/10880] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
2.0.0.0/8 [90/16000] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 341
D
D
D
D
3.0.0.0/8 [90/16000] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [90/15360] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/20480] via 145.1.1.1, 00:00:41, GigabitEthernet0/0
Task 4
Configure R6 in EIGRP AS 200. This router should run EIGRP AS 200 on its G0/9 and
Loopback0 interfaces. You should use an EIGRP named mode configuration to accomplish
this task.
The following configures EIGRP named mode for AS 200 on R6 and the network command enables EIGRP on
the interfaces specified:
On R6:
R6(config)#router eigrp tst200
R6(config-router)#address-family ipv4 as 200
R6(config-router-af)#netw 6.6.6.6 0.0.0.0
R6(config-router-af)#netw 10.1.1.6 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 200: neighbor 10.1.1.2 (GigabitEthernet0/9)
is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 200: neighbor 10.1.1.1 (GigabitEthernet0/9)
is up: new adjacency
The above results in EIGRP adjacencies between R1 and R6. R1’s routing table for EIGRP AS 200 verifies the
EIGRP routes it learns from R6:
To verify the configuration:
On R1:
R1#show ip route eigrp 200 | begin Gateway
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 342
Gateway of last resort is not set
D
6.0.0.0/8 [90/10880] via 10.1.1.6, 00:00:39, GigabitEthernet9
Task 5
Configure OSPF Area 0 on R6’s G0/9 and R7’s G0/9 and Loopback0 interfaces. The router ID
of these routers should be configured as 0.0.0.x, where x is the router number.
The following enables OSPF 1 for Area 0 on R6 and R7’s G0/9 interfaces using the network command. OSPF is
also enabled on the loopback interface on R7. Additionally, as required by the task, the OSPF router IDs are
manually set using the router-id command:
On R6:
R6(config)#router ospf 1
R6(config-router)#router-id 0.0.0.6
R6(config-router)#network 10.1.1.6 0.0.0.0 area 0
On R7:
R7(config)#router ospf 1
R7(config-router)#router-id 0.0.0.7
R7(config-router)#network 10.1.1.7 0.0.0.0 area 0
R7(config-router)#network 7.7.7.7 0.0.0.0 area 0
The following console log message appears on the router verifying the OSPF adjacencies:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.6 on GigabitEthernet0/9 from LOADING
to FULL, Loading Done
To verify the configuration:
On R6:
R6#show ip route ospf | begin Gateway
Gateway of last resort is not set
O
7.0.0.0/32 is subnetted, 1 subnets
7.7.7.7 [110/2] via 10.1.1.7, 00:00:27, GigabitEthernet0/9
Task 6
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 343
Configure R6 to redistribute OSPF into EIGRP such that R1 and R2 go directly to R7 to reach
the 7.0.0.0/8 network.
This task first requires configuring R6 to redistribute OSPF routes into EIGRP 200. Redistribution for EIGRP
named mode is done in topology base configuration mode. Topology base configuration mode is entered
using the topology base command within EIGRP router address-family configuration mode within an EIGRP
virtual instance. There are many EIGRP functions that are executed in topology base configuration mode. The
output below lists the variety of command options available:
On R6:
R6(config)#router eigrp tst200
R6(config-router)#address-family ipv4 as 200
R6(config-router-af)#topology base
R6(config-router-af-topology)#?
Address Family Topology configuration commands:
auto-summary
Enable automatic netw 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
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
The redistribute command in topology base configuration mode activates redistribution of other protocols
into EIGRP. When routes from other routing sources are redistributed into EIGRP, EIGRP, like all other routing
protocols, needs to be able to assign a metric value to the redistributed prefixes. This is no problem if the
source routing protocol is another EIGRP virtual instance running on the router because the metric values
used by the source protocol will be the same as EIGRP’s own metrics. When redistributing routes from a
different routing protocol, however, EIGRP cannot accept the metric values. Some routing protocols have a
default metric that is assigned to all redistributed prefixes, but EIGRP does not have such a function. Instead,
the administrator must manually provide the component metric information as a seed metric to be used for
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 344
all redistributed prefixes. Without this seed metric, EIGRP will not redistribute any routes from the intended
source protocol. The seed metric can be set using the metric option along with the redistribute command as
in the below:
R6(config)#router eigrp tst200
R6(config-router)#address-family ipv4 as 200
R6(config-router-af)#topology base
R6(config-router-af-topology)#redistribute ospf 1 metric 10000 1000 255 1
1500
The above configuration causes R6 to advertise the redistribute routes as EIGRP external routes to it’s EIGRP
neighbor R1. This can be verified on R1 with the show ip route 7.7.7.7 command as seen below:
To verify the configuration:
On R1:
R1#show
ip route 7.7.7.7
Routing entry for 7.7.7.7/32
Known via "eigrp 200", distance 170, metric 5637120, type external
Redistributing via eigrp 200
Last update from 10.1.1.6 on GigabitEthernet9, 00:03:28 ago
Routing Descriptor Blocks:
* 10.1.1.6, from 10.1.1.6, 00:03:28 ago, via GigabitEthernet0/9
Route metric is 5637120, traffic share count is 1
Total delay is 10010 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Notice in the output above the next hop IP Address for the 7.7.7.7 prefix on R1 is R6’s interface 10.1.1.6. The
same occurs on R2. Because R6 is the next-hop for the prefix, whenever R1 or R2 try to route packets to the
7.7.7.7 prefix, they will forward the packers to R6 which will then forward to R7. The task requirements state
that R1 and R2 should route directly to R7 for the 7.0.0.0/8 network. This would be a simple task if R1 and R2
were also running OSPF, but, in this case, R1 and R2 are not configured for OSPF and R7 isn’t running EIGRP.
The only way R1 and R2 receive the 7.0.0.0/8 prefixes is via redistribution into EIGRP from R6.
In order to meet the task requirement, changes must be made such that the R6 advertises R7, the original
next-hop from OSPF, as the next-hop in its EIGRP advertisement to R1 and R2. How can this be done? By
enabling the third-party next-hop feature.
The third-party next-hop feature prevents an advertising router from setting itself as the next hop for EIGRP
routes it advertises. The feature assumes that if all routers are in the same subnet, then they have
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 345
reachability to each other. Advertising the original next-hop prevents suboptimal routing situations like what
is currently present in the topology between R1, R2, R6, and R7.
In other words, R6 will retain the original next-hop address of R7 when advertising the 7.7.7.7 prefix to R1
and R2 via EIGRP. Since R1 and R2 belong to the same subnet as R7, the 10.1.1.0/24, they can directly route
packets to R7 instead of sending it to R6.
Certain protocols such as BGP have this feature turned on by default, EIGRP requires an extra configuration
step to enable this feature. By default as seen above, R6 resets the next hop to itself when advertising the
7.7.7.7 prefix. It can be prevented from doing this by using the no next-hop-self command in af-interface
configuration mode for its G0/9. This mode is entered from router address-family configuration mode using
the af-interface command:
On R6:
R6(config)#router eigrp tst200
R6(config-router)#address-family ipv4 as 200
R6(config-router-af)#af-interface g0/9
R6(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
R6(config-router-af-interface)#no next-hop-self
Once next-hop-self is disabled, the true next hop is now being retained by R6 when advertising to R1 and R2.
The show ip route 7.7.7.7 output on R1 and R2’s correctly list R7 as the next hop for the 7.7.7.7 prefix as
seen below:
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 346
On R1:
R1#show ip route 7.7.7.7
Routing entry for 7.7.7.7/32
Known via "eigrp 200", distance 170, metric 5637120, type external
Redistributing via eigrp 200
Last update from 10.1.1.7 on GigabitEthernet9, 00:02:25 ago
Routing Descriptor Blocks:
* 10.1.1.7, from 10.1.1.6, 00:02:25 ago, via GigabitEthernet0/9
Route metric is 5637120, traffic share count is 1
Total delay is 10010 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Task 7
Configure the hello interval of all routers in AS 200 to be twice the default hello interval.
The hello interval or the frequency at which EIGRP hello packets are transmitted defaults to 5 seconds. This is
confirmed with the show ip eigrp 200 interface detail | include interval output below from R1:
R1#show ip eigrp 200 interface detail | include interval
Hello-interval is 5, Hold-time is 15
The task requires doubling the hello interval on all routers configured for EIGRP AS 200, meaning, R1, R2 and
R6. The hello interval can be modified with the hello-interval command under the EIGRP af-interface
configuration mode. The value is set to 10 seconds (two times the default interval of 5) on the routers as
seen below:
On R1 and R2:
Rx(config)#router eigrp tst200
Rx(config-router)#address-family ipv4 as 200
Rx(config-router-af)#af-interface g0/9
Rx(config-router-af-interface)#hello-interval 10
On R6:
R6(config)#router eigrp tst200
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 347
R6(config-router)#address-family ipv4 as 200
R6(config-router-af)#af-interface g0/9
R6(config-router-af-interface)#hello-interval 10
The show ip eigrp 200 interface detail | include interval command output on these routers verify the
change:
To verify the configuration:
On R1:
R1#show ip eigrp 200 interface detail | include interval
Hello-interval is 10, Hold-time is 15
On R6:
R1#show ip eigrp 200 interface detail | include interval
Hello-interval is 5, Hold-time is 15
Hello-interval is 10, Hold-time is 15
Note: When the hello interval is changed the hold-time is NOT changed automatically.
Task 8
Configure R4 such that in the worst-case scenario, it uses 10% of the bandwidth for its
EIGRP updates. This policy should apply to the existing and future interfaces.
By default, EIGRP will ONLY consume 50 percent of its interface’s bandwidth for EIGRP control packets. This
default can be changed using the bandwidth-percent command in interface configuration mode or in the
af-interface configuration mode under the address-family. The following modifies the utilization to 10
percent on R4 under the af-interface default configuration mode. The af-interface default configuration
mode is a special interface configuration mode. Any configuration made in this mode is automatically
applied to all interfaces on the router as a default setting:
On R4:
R4(config)#router eigrp tst
R4(config-router)#address-family ipv4 as 100
R4(config-router-af)#af-interface default
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 348
R4(config-router-af-interface)#bandwidth-percent 10
The show ip eigrp interface detail output verifies the change:
To verify the configuration:
R4#show ip eigrp interface detail | include BW
Interface BW percentage is 10
Interface BW percentage is 10
Task 9
Configure R1 to summarize its loopback interfaces and advertise a single summary in the
EIGRP AS 100 routing domain.
Following loopback interfaces configured on R1 are to be summarized into a 1.1.0.0/22 summary address:
On R1:
R1#show ip interface brief | include Loopback
Loopback0
Loopback1
Loopback2
Loopback3
1.1.0.1
1.1.1.1
1.1.2.1
1.1.3.1
YES manual up
YES manual up
YES manual up
YES manual up
up
up
up
up
The af-interface default configuration mode in EIGRP named mode however does not include a
summarization option as seen below:
R1(config)#router eigrp tst
R1(config-router)#address-family ipv4 autonomous-system 100
R1(config-router-af)#af-interface default
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
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 349
exit-af-interface
hello-interval
hold-time
next-hop-self
no
passive-interface
shutdown
split-horizon
Exit from Address Family Interface configuration mode
Configures hello interval
Configures hold time
Configures EIGRP next-hop-self
Negate a command or set its defaults
Suppress address updates on an interface
Disable Address-Family on interface
Perform split horizon
! No summarization option
This means any summarization in EIGRP named mode needs to be done individually for each interface
under the af-interface configuration mode with the summary-address command. This is seen below on R1
where the summary-address 1.1.0.0 255.255.252.0 command is configured under each interface on R1
that is enabled for EIGRP:
R1(config)#router eigrp tst
R1(config-router)#address-family ipv4 as 100
R1(config-router-af)#af-interface g0/2
R1(config-router-af-interface)#summary-address 1.1.0.0 255.255.252.0
R1(config-router-af)#af-interface g0/3
R1(config-router-af-interface)#summary-address 1.1.0.0 255.255.252.0
R1(config-router-af)#af-interface g0/0
R1(config-router-af-interface)#summary-address 1.1.0.0 255.255.252.0
The result of the above configuration can be verified on the neighboring routers as seen below. R2, R3, R4
and R5 each receive a summary route from R1:
To verify the configuration:
On R2:
R2#sh ip route eigrp | b Gate
Gateway of last resort is not set
D
D
D
D
D EX
D
1.0.0.0/22 is subnetted, 1 subnets
1.1.0.0 [90/10880] via 12.1.1.1, 00:01:36, GigabitEthernet0/1
3.0.0.0/8 [90/10880] via 23.1.1.3, 06:57:00, GigabitEthernet0/3
4.0.0.0/8 [90/16000] via 12.1.1.1, 06:41:09, GigabitEthernet0/1
6.0.0.0/8 [90/10880] via 10.1.1.6, 05:27:20, GigabitEthernet0/9
7.0.0.0/32 is subnetted, 1 subnets
7.7.7.7 [170/5637120] via 10.1.1.7, 05:27:20, GigabitEthernet0/9
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [90/15360] via 23.1.1.3, 06:57:03, GigabitEthernet0/3
[90/15360] via 12.1.1.1, 06:57:03, GigabitEthernet0/1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 350
D
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [90/15360] via 12.1.1.1, 06:56:58, GigabitEthernet0/1
On R3:
R3#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
1.0.0.0/22 is subnetted, 1 subnets
1.1.0.0 [90/10880] via 13.1.1.1, 00:02:15, GigabitEthernet0/1
2.0.0.0/8 [90/10880] via 23.1.1.2, 06:57:37, GigabitEthernet0/2
4.0.0.0/8 [90/16000] via 13.1.1.1, 06:41:48, GigabitEthernet0/1
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 23.1.1.2, 06:57:37, GigabitEthernet0/2
[90/15360] via 13.1.1.1, 06:57:37, GigabitEthernet0/1
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [90/15360] via 13.1.1.1, 06:57:37, GigabitEthernet0/1
On R4:
R4#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
D
1.0.0.0/22 is subnetted, 1 subnets
1.1.0.0 [90/10880] via 145.1.1.1, 00:03:11, GigabitEthernet0/0
2.0.0.0/8 [90/16000] via 145.1.1.1, 06:42:55, GigabitEthernet0/0
3.0.0.0/8 [90/16000] via 145.1.1.1, 06:42:55, GigabitEthernet0/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 145.1.1.1, 06:42:55, GigabitEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [90/15360] via 145.1.1.1, 06:42:55, GigabitEthernet0/0
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/20480] via 145.1.1.1, 06:42:55, GigabitEthernet0/0
On R5:
R5#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
1.0.0.0/22 is subnetted, 1 subnets
1.1.0.0 [90/10880] via 145.1.1.1, 00:03:02, GigabitEthernet0/0
2.0.0.0/8 [90/16000] via 145.1.1.1, 00:03:02, GigabitEthernet0/0
3.0.0.0/8 [90/16000] via 145.1.1.1, 00:03:02, GigabitEthernet0/0
4.0.0.0/8 [90/10880] via 145.1.1.4, 00:02:51, GigabitEthernet0/0
12.0.0.0/24 is subnetted, 1 subnets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 351
D
12.1.1.0 [90/15360] via 145.1.1.1, 00:03:02, GigabitEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [90/15360] via 145.1.1.1, 00:03:02, GigabitEthernet0/0
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/20480] via 145.1.1.1, 00:03:02, GigabitEthernet0/0
D
D
Task 10
Configure R1 to limit the number of received prefixes from R5 to 10. R1 should be
configured to receive a warning message once 50% of this threshold is reached and a
warning message for every additional route that exceeds the threshold. You should
configure Lo1–Lo10 on R5 by copying and pasting the initial configuration, called EIGRP-Lab1-Task10.
EIGRP’s maximum-prefix configuration option allows for controlling the number of EIGRP prefixes a router
learns from a specific peer under an address-family. This function is enabled on a per-neighbor basis and is
configured in address-family configuration mode the neighbor neighbor-address maximum-prefix
maximum-value command.
This task requires R1 to be configured such that it only accepts 10 prefixes from its neighbor R5. In addition,
IOS should also display a warning message once it receives 50 percent of the maximum allowed prefixes
from that neighbor. Meaning, when R1 has received 5 prefixes from R5, it should display a warning. This can
be achieved by appending additional arguments to the neighbor maximum-prefix command by setting the
value to 50 before the warning-only keyword as shown below:
On R1:
R1(config)#router eigrp tst
R1(config-router)#address-family ipv4 as 100
R1(config-router-af)#neighbor 145.1.1.5 maximum-prefix 10 50 warning-only
To test the configuration, first EIGRP is enabled on the Loopback 1, Loopback 2 and Loopback 3 addresses on
R5:
On R5:
R5(config)#router eigrp tst
R5(config-router)#address-family ipv4 as 100
R5(config-router-af)#network 51.1.1.5 0.0.0.0
R5(config-router-af)#network 52.1.1.5 0.0.0.0
R5(config-router-af)#network 53.1.1.5 0.0.0.0
In total, since R1 has received only 4 EIGRP prefixes from R5, it will not display any warning messages. Next,
EIGRP is enabled on another loopback on R5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 352
R5(config-router-af)#network 54.1.1.5 0.0.0.0
The above results in R1 displaying a warning message that the threshold prefix level of 5 has been reached:
On R1:
We can see that the first message was received:
%DUAL-4-PFXLIMITTHR: EIGRP-IPv4 100: neighbor threshold prefix level(5)
reached.
EIGRP is then enabled on six more loopbacks on R5:
On R5:
R5(config-router-af)#network 55.1.1.5 0.0.0.0
R5(config-router-af)#network 56.1.1.5 0.0.0.0
R5(config-router-af)#network 57.1.1.5 0.0.0.0
R5(config-router-af)#network 58.1.1.5 0.0.0.0
R5(config-router-af)#network 59.1.1.5 0.0.0.0
Since R5 is now advertising 11 prefixes in total to R1, the following log message stating that the prefix limit
has been reached is displayed on R1:
On R1:
%DUAL-3-PFXLIMIT: EIGRP-IPv4 100: neighbor prefix limit reached(10).
Task 11
Configure R1 to limit the number of prefixes received from R4 to five. R1 should be
configured to tear down the adjacency if R4 exceeds the specified threshold. Copy and
paste the EIGRP-Lab-1-Task11 initial configuration on R4.
This task takes a similar direction as Task 10. It requires configuring R1 such that it only accepts a maximum
of five EIGRP prefixes from R4. In this case, if R1 receives more than five prefixes from R4, it should tear
down its EIGRP adjacency with R4.
To complete the task, we configure the neighbor 145.1.1.4 maximum-prefix 5 command under the addressfamily configuration mode on R1 with no other options specified.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 353
On R1:
R1(config)#router eigrp tst
R1(config-router)#address-family ipv4 as 100
R1(config-router-af)#neighbor 145.1.1.4 maximum-prefix 5
With no other options specified, by default, the threshold is set to 80 percent. Meaning, if R1 receives 80
percent of the configured maximum prefix value, it will display a warning message. If it reaches the
maximum prefix value, the neighborship to the neighbor is shut down.
To verify the configuration, R4’s loopback 1 interface is advertised in EIGRP. No warning message is
displayed since R1 is receiving only two EIGRP prefixes (4.0.0.0/8 and 41.0.0.0/8) from R4:
On R4:
R4(config)#router eigrp tst
R4(config-router)#address-family ipv4 as 100
R4(config-router-af)#network 41.1.1.4 0.0.0.0
To test the warning message, two more networks are advertised into EIGRP on R4 (Lo2, Lo3 and Lo4):
R4(config-router-af)#network 42.1.1.4 0.0.0.0
R4(config-router-af)#network 43.1.1.4 0.0.0.0
R1 now receiving 80 percent of the maximum allowed prefixes, displays a warning message indicating the
threshold prefix level:
%DUAL-4-PFXLIMITTHR: EIGRP-IPv4 100: neighbor threshold prefix level(3)
reached.
Finally, R4 is configured to advertise two more loopback addresses into EIGRP. The result is R1 displaying the
message prefix limit reached(5) and tearing down its EIGRP adjacency with R4 as shown below. The show ip
eigrp neighbor command verifies the same:
R4(config-router-af)#network 44.1.1.4 0.0.0.0
On R1:
%DUAL-3-PFXLIMIT: EIGRP-IPv4 100: neighbor prefix limit reached(5).
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 145.1.1.4
(GigabitEthernet0/0) is down: prefix-limit exceeded
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 354
We can see that the adjacency is torn down, let’s verify the neighbor table of R4:
R4#show ip eigrp neighbor
EIGRP-IPv4 VR(tst) Address-Family Neighbors for AS(100)
H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
1
145.1.1.5
Gi0/0
11 00:19:06
7
RTO
100
Q Seq
Cnt Num
0 29
R4#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
D
D
D
D
D
D
5.0.0.0/8 [90/10880] via 145.1.1.5, 00:20:25, GigabitEthernet0/0
51.0.0.0/8 [90/10880] via 145.1.1.5, 00:11:07, GigabitEthernet0/0
52.0.0.0/8 [90/10880] via 145.1.1.5, 00:11:02, GigabitEthernet0/0
53.0.0.0/8 [90/10880] via 145.1.1.5, 00:10:58, GigabitEthernet0/0
54.0.0.0/8 [90/10880] via 145.1.1.5, 00:10:33, GigabitEthernet0/0
55.0.0.0/8 [90/10880] via 145.1.1.5, 00:09:08, GigabitEthernet0/0
56.0.0.0/8 [90/10880] via 145.1.1.5, 00:08:49, GigabitEthernet0/0
57.0.0.0/8 [90/10880] via 145.1.1.5, 00:08:28, GigabitEthernet0/0
58.0.0.0/8 [90/10880] via 145.1.1.5, 00:08:16, GigabitEthernet0/0
59.0.0.0/8 [90/10880] via 145.1.1.5, 00:08:10, GigabitEthernet0/0
60.0.0.0/8 [90/10880] via 145.1.1.5, 00:07:42, GigabitEthernet0/0
We can see that R4 only exchanges routes with R5 and NOT R1.
Task 12
Erase the startup configuration and reload the routers before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 355
Lab 2
EIGRP and Bidirectional Forwarding
Detection (BFD)
Task 1
Configure the routers based on the previous diagram. Do not configure any routing
protocol.
Based on the diagram, the following configures IP Addressing on R5 and R6’s G0/6 and G0/5 interfaces
respectively. In addition, a loopback interface is created on each router and IP addresses are assigned to it
as shown in the diagram:
On R5:
R5(config)#interface g0/6
R5(config-if)#ip address 56.1.1.5 255.255.255.0
R5(config-if)#no shut
R5(config)#interface lo0
R5(config-if)#ip address 5.5.5.5 255.0.0.0
On R6:
R6(config)#interface g0/5
R6(config-if)#ip address 56.1.1.6 255.255.255.0
R6(config-if)#no shut
R6(config)#interface lo0
R6(config-if)#ip address 6.6.6.6 255.0.0.0
Task 2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 356
Configure EIGRP AS 100 on all directly connected interfaces of these two routers and ensure
reachability. R5 should be configured using EIGRP classical mode, and R6 should use the
EIGRP named mode configuration style.
Following configurations enable EIGRP using the classic mode on R5 and the named mode on R6. EIGRP is
enabled on their directly connected interfaces and loopback 0 with the network statement
On R5:
R5(config)#router eigrp 100
R5(config-router)#network 5.5.5.5 0.0.0.0
R5(config-router)#network 56.1.1.5 0.0.0.0
On R6:
R6(config)#router eigrp aaa
R6(config-router)#address ipv4 as 100
R6(config-router-af)#network 6.6.6.6 0.0.0.0
R6(config-router-af)#network 56.1.1.6 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 56.1.1.5
(GigabitEthernet0/5) is up: new adjacency
To verify the configuration:
The show ip route eigrp on both routers verify they have learned EIGRP routes from each other:
R6#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
5.0.0.0/8 [90/2570240] via 56.1.1.5, 00:01:22, GigabitEthernet0/5
On R5:
R5#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
6.0.0.0/8 [90/2848] via 56.1.1.6, 00:02:48, GigabitEthernet0/6
Task 3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 357
Configure and test BFD on these two routers.
Being able to detect whether a routing peer is down rapidly is imperative to the route reconvergence
process. It is so essential that each routing protocol institutes its own method of neighbor-down detection.
These detection mechanisms rely on the receipt of hello or keepalive packets at a predefined interval. The
problem with such systems is that most routing protocols are unable to achieve sub-second convergence
with their default timers. Even with some sub-second timers, the processing overhead required to keep
track of this process can become a resource drain on the router. In addition, if the network environment
includes multiple routing protocols, the differing timer values can make it inconsistent for building
automated processes around detection and recovery for neighbor down events.
The Bidirectional Forwarding Detection (BFD) protocol supported on Cisco platforms is a protocol that is
designed to provide fast neighbor down detection due to a failure in the forwarding path to a specific
destination. This protocol can be used to replace the normal routing protocol hello and keepalive
mechanisms. When used in this way, it provides a more consistent and predictable neighbor-down
detection system.
BFD works by establishing BFD sessions between neighbors. Each session is configured with different
parameters that determine when the router will consider the neighbor peer as having gone down. Once
BFD neighbors are established, BFD can be configured to send BFD echo packets at a specified interval to
the BFD neighbor. These echo packets are forwarded in hardware, requiring little processor interaction to
process.
The BFD echo packet is a special packet sent by the router with the source and destination address equal to
its own interface IP address. When received by the BFD neighbor, the BFD neighbor forwards this packet
back to the local router in hardware. When the local router receives this packet back, it knows the remote
peer is still online.
The BFD session state can be linked to routing protocol neighborships. If the BFD neighbor session goes
down, then the routing protocol neighborship is torn down. This process is called registering the protocol
to participate in BFD.
BFD is configured to run in two steps:
1. Configure the BFD session on a per-interface basis
2. Register the BFD session with the routing protocol of choice
The following configures BFD to run between R5 and R6 for fast failure detection.
In the first step, BFD is enabled on the G0/6 and G0/5 interfaces on R5 and R6 with the bfd interval
milliseconds min_rx milliseconds multiplier interval-multiplier command. This command allows for
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 358
specifying certain BFD parameters such as how often to transmit UDP echoes. The interval timer dictates
the rate at which the UDP echoes are generated. This value is set to 100ms on both R5 and R6. This means
every 100ms R5 and R6 will send a UDP BFD echo to each other.
The min_rx is the minimum receive time. It is the interval at which the local router expects to receive BFD
control packets. If a control packet is not received within this time, then the router considers that packet as
a missed packet. If the value specified here is 100 ms, the neighboring router should be configured to send
BFD packets equal or less than 100ms. In this case, this value is set to 100 ms as well on both routers.
Finally, the multiplier value is set to 3. The multiplier value specifies the number of packets that can be
missed before BFD declares the peer down.
STEP 1:
On R5:
R5(config)#interface g0/6
R5(config-if)#bfd interval 100 min_rx 100 multiplier 3
You should see the following console message:
*Aug 4 12:58:35.439: %BFD-6-BFD_IF_CONFIGURE: BFD-SYSLOG: bfd config
apply, idb:GigabitEthernet0/6
On R6:
R6(config)#interface g0/5
R6(config-if)#bfd interval 100 min_rx 100 multiplier 3
In Step 2, BFD is registered with EIGRP. BFD can be applied to a single interface, or all interfaces. For this
task, BFD for EIGRP is enabled only on the interface connecting R5 and R6. As such, in case of the classic
mode EIGRP configuration on R5, BFD is registered with EIGRP under the router configuration mode with
the bfd interface G0/6 command. In case of EIGRP named mode on R6, BFD is registered to run on the
G0/5 interface under the af-interface G0/5 configuration mode with the bfd command:
STEP 2:
On R5:
R5(config)#router eigrp 100
R5(config-router)#bfd interface g0/6
On R6:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 359
R6(config)#router eigrp aaa
R6(config-router)#address-family ipv4 as 100
R6(config-router-af)#af-interface g0/5
R6(config-router-af-interface)#bfd
The show bfd neighbor command can be used to verify the BFD session:
To verify the configuration:
R6#sh bfd neighbors
IPv4 Sessions
NeighAddr
56.1.1.5
LD/RD
1/1
RH/RS
Up
State
Up
Int
Gi0/5
Task 4
Erase the startup configuration of these two routers and reload the devices before
proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 360
Lab 3
EIGRP Stub
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
EIGRP folder  Lab-3.
Task 1
Configure EIGRP AS 100 on the G0/2 and G0/1 interfaces of R1 and R2, respectively, as
well as on all loopback interfaces of these two routers. On R1 configure EIGRP using the
classic mode, and on R2 configure EIGRP in named mode to accomplish this task. Do not
run EIGRP on the G0/1 interface of R1 or the G0/2 interface of R2.
The following configures EIGRP in classic mode on R1 and EIGRP in named mode on R2. The network
command then enables EIGRP on all the interfaces except the G0/1 and G0/2 interfaces on R1 andd R2
respectively:
On R1:
R1(config)#router eigrp 100
R1(config-router)#network 1.1.0.1 0.0.0.0
R1(config-router)#network 1.1.1.1 0.0.0.0
R1(config-router)#network 1.1.2.1 0.0.0.0
R1(config-router)#network 1.1.3.1 0.0.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 361
R1(config-router)#network 12.1.1.1 0.0.0.0
On R2:
R2(config)#router eigrp tst
R2(config-router)#address-family ipv4 as 100
R2(config-router-af)#network 2.2.0.2 0.0.0.0
R2(config-router-af)#network 2.2.1.2 0.0.0.0
R2(config-router-af)#network 2.2.2.2 0.0.0.0
R2(config-router-af)#network 2.2.3.2 0.0.0.0
R2(config-router-af)#network 12.1.1.2 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 12.1.1.1 (GigabitEthernet0/1)
is up: new adjacency
To verify the configuration:
The show ip route eigrp command output on each router verifies the EIGRP learned routes:
On R1:
R1#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
2.0.0.0/24 is subnetted, 4 subnets
2.2.0.0 [90/2848] via 12.1.1.2, 00:00:40, GigabitEthernet0/2
2.2.1.0 [90/2848] via 12.1.1.2, 00:00:40, GigabitEthernet0/2
2.2.2.0 [90/2848] via 12.1.1.2, 00:00:40, GigabitEthernet0/2
2.2.3.0 [90/2848] via 12.1.1.2, 00:00:40, GigabitEthernet0/2
On R2:
R2#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
1.0.0.0/24 is subnetted, 4 subnets
1.1.0.0 [90/2570240] via 12.1.1.1, 00:01:06, GigabitEthernet0/1
1.1.1.0 [90/2570240] via 12.1.1.1, 00:01:06, GigabitEthernet0/1
1.1.2.0 [90/2570240] via 12.1.1.1, 00:01:06, GigabitEthernet0/1
1.1.3.0 [90/2570240] via 12.1.1.1, 00:01:06, GigabitEthernet0/1
Task 2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 362
Configure R1 and R2 to summarize their loopback interfaces in EIGRP.
In the classic EIGRP, summarization is performed under the interface. R1 running EIGRP in classic mode is
configured with the ip summary-address eigrp 100.1.0.0 255.255.252.0 command to summarize its
loopback addresses.
On R1:
R1(config)#interface g0/2
R1(config-if)#ip summary-address eigrp 100 1.1.0.0 255.255.252.0
For named mode, summarization is configured with the summary-address command under the af-interface
for the address-family for IPv4 for EIGRP process tst. This is seen below on R2. Notice how IOS allows the
use of prefix length while summarizing instead of entering the full subnet mask:
On R2:
R2(config)#router eigrp tst
R2(config-router)#address-family ipv4 as 100
R2(config-router-af)#af-interface g0/1
R2(config-router-af-interface)#summary-address 2.2.0.0/22
The result of the above configurations can be viewed on the routing tables on R1 and R2 as seen below. As a
result of summarization, R1 no longer advertises specific prefixes to R2. It instead advertises the summary
route 1.1.0.0/22. Similarly, R2 no longer advertises specific prefixes, instead advertises the summary route
2.2.0.0/22:
To verify the configuration:
On R1:
R1#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
1.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
1.1.0.0/22 is a summary, 00:01:56, Null0
2.0.0.0/22 is subnetted, 1 subnets
2.2.0.0 [90/2848] via 12.1.1.2, 00:01:16, GigabitEthernet0/2
On R2:
R2#show ip route eigrp | begin Gateway
Gateway of last resort is not set
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 363
D
D
1.0.0.0/22 is subnetted, 1 subnets
1.1.0.0 [90/2570240] via 12.1.1.1, 00:02:24, GigabitEthernet0/1
2.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
2.2.0.0/22 is a summary, 00:01:44, Null0
Notice the null route created on each router. A null route is created when EIGRP summarization is
configured. The null interface is basically a discard interface. A router may receive traffic to an address that
is covered by the summary range, but the address does not actually exist. In this case, traffic to a nonexistent IP address is forwarded to the null interface to be discarded.
Earlier versions of IOS allowed removing the null route by setting the administrative distance of a null 0
route to 255. A route with an AD of 255 is deemed unreachable and isn’t installed in the routing table. The
distance value was appended to the summary command. For example : ip summary-address eigrp 100
1.1.0.0 255.255.252.0 255. Newer IOS versions however have deprecated the use of this syntax preventing
the removal of Null0 route. Issuing this command on the router results in the following message:
R1(config-if)#ip summary-address eigrp 100 10.1.0.0 255.255.0.0 255
%EIGRP: summary-address accepted but distance option deprecated; use summary-metric command for
distance.
Task 3
Configure the following static routes on R1 and R2 and redistribute them into EIGRP:
 On R1: 11.0.0.0/8 via G0/1
 On R2: 22.0.0.0/8 via G0/2
Static routes are configured with the ip route command on R1 and R2. These routes are then redistributed
into EIGRP using the redistribute static command. In classic EIGRP configuration mode on R1, this command
is issued in EIGRP router configuration mode. In named EIGRP configuration mode, redistribution
configuration is applied under the address-family IPv4 topology base configuration mode as seen on R2
below:
On R1:
R1(config)#ip route 11.0.0.0 255.0.0.0 g0/3
R1(config)#router eigrp 100
R1(config-router)#redistribute static
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 364
On R2:
R2(config)#ip route 22.0.0.0 255.0.0.0 g0/3
R2(config)#router eigrp tst
R2(config-router)#address-family ipv4 as 100
R2(config-router-af)#topology base
R2(config-router-af-topology)#redistribute static
Notice in the above how the redistribute statement does not include a seed metric. In earlier sections, it
was explained that EIGRP requires a seed metric whenever redistributing routes from another source
routing protocol that isn’t EIGRP. EIGRP, however, does not require a seed metric whenever redistributing
static or directly-connected routes from the routing table. EIGRP simply derives its component metrics from
the exit interface of the static or directly-connected route.
The show ip route eigrp command output below verifies the redistributed static routes at each end as
external EIGRP routes:
To verify the configuration:
On R1:
R1#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D EX
1.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
1.1.0.0/22 is a summary, 00:05:32, Null0
2.0.0.0/22 is subnetted, 1 subnets
2.2.0.0 [90/2848] via 12.1.1.2, 00:04:52, GigabitEthernet0/2
22.0.0.0/8 [170/3072] via 12.1.1.2, 00:00:42, GigabitEthernet0/2
On R2:
R2#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D EX
1.0.0.0/22 is subnetted, 1 subnets
1.1.0.0 [90/2570240] via 12.1.1.1, 00:06:07, GigabitEthernet0/1
2.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
2.2.0.0/22 is a summary, 00:05:27, Null0
11.0.0.0/8 [170/15360] via 12.1.1.1, 00:01:48, GigabitEthernet0/1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 365
Task 4
Advertise the G0/1 interface of R1 and the G0/2 interface of R2 into RIPv2 and disable autosummarization. You should redistribute RIPv2 into EIGRP and use any metric for the
redistributed routes.
The following first configures RIP on R1 and R2. The RIP version is specified with the version 2 command and
auto-summarization is disabled with the no auto-summary command. RIP is then enabled on the interfaces
specified in the task with the network statement:
On R1:
R1(config)#router rip
R1(config-router)#no auto-summary
R1(config-router)#version 2
R1(config-router)#network 200.1.1.0
On R2:
R2(config)#router rip
R2(config-router)#no auto-summary
R2(config-router)#version 2
R2(config-router)#network 200.2.2.0
R1 and R2 are then configured to redistribute RIP into EIGRP. In classic EIGRP configuration mode, the
redistribute command is issued in EIGRP router configuration mode. In named EIGRP configuration mode,
redistribution configuration is applied under the address-family IPv4 topology base configuration mode:
On R1:
R1(config)#router eigrp 100
R1(config-router)#redistribute rip metric 1000000 10 255 1 1500
On R2:
R2(config)#router eigrp tst
R2(config-router)#address-family ipv4 as 100
R2(config-router-af)#topology base
R2(config-router-af-topology)#redistribute rip metric 1000000 10 255 1
1500
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 366
To verify the configuration:
The show ip route eigrp command output on both routers verify the redistributed routes as EIGRP external
routes:
On R1:
R1#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D EX
D EX
1.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
1.1.0.0/22 is a summary, 00:08:40, Null0
2.0.0.0/22 is subnetted, 1 subnets
2.2.0.0 [90/2848] via 12.1.1.2, 00:08:40, GigabitEthernet0/2
22.0.0.0/8 [170/3072] via 12.1.1.2, 00:08:40, GigabitEthernet0/2
200.2.2.0/24 [170/5376] via 12.1.1.2, 00:00:34, GigabitEthernet0/2
On R2:
R2#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D EX
D EX
1.0.0.0/22 is subnetted, 1 subnets
1.1.0.0 [90/2570240] via 12.1.1.1, 00:18:39, GigabitEthernet0/1
2.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
2.2.0.0/22 is a summary, 00:17:59, Null0
11.0.0.0/8 [170/15360] via 12.1.1.1, 00:14:20, GigabitEthernet0/1
200.1.1.0/24 [170/61440] via 12.1.1.1, 00:01:54, GigabitEthernet0/1
Task 5
Configure EIGRP stub routing on R1 by using the command eigrp stub connected. Test this
option and verify the routes in the routing tables of both routers.
EIGRP supports what is known as the EIGRP stub routing feature. It is designed as a mechanism to help
constrain EIGRP query messages that are generated whenever an EIGRP router loses a route in its topology
table. Under normal circumstances, whenever an EIGRP router loses a route in its topology table, it sends an
EIGRP QUERY message to all of its neighbors. The QUERY message is basically the router’s way of asking if its
neighbors has another route to reach the network the local router lost. The local router will wait until it
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 367
receives REPLY messages from all neighbors to which it sent a QUERY. This process is called “going active”
for a route because EIGRP is actively trying to determine the status of the route.
Some routers will not have alternate routes to a lost network. This applies particularly to routers in a huband-spoke network. In this case, spokes receive their routes from the hub. If the hub goes down, there is no
reason for the hub to query the spokes for alternate paths. The hub is essentially wasting its efforts. The
EIGRP stub router feature gives stub routers (routers that only have a single connection to the network like
the spokes in the hub-and-spoke example) a way to signal to the upstream neighbor that they have no
alternate routes to networks. A router configured as stub sets the stub flag in its EIGRP hello packet it sends
to its neighbors. Upon seeing this, the neighbor will not query the stub router for lost routes.
The stub configuration can also be used to limit which routes the stub router will advertise to its neighbors.
The major options are “connected”, “summary-only”, and “redistributed.” The next tasks demonstrate the
effects of each configuration command.
In case of the classic EIGRP mode, the eigrp stub command under the EIGRP router configuration mode is
used to configure EIGRP stub routing. In the case of EIGRP named mode, stub routing is configured in
address-family for IPv4 configuration mode. Various options are available when configuring EIGRP stub
routing as seen below:
EIGRP Stub routing configuration in classic mode
R1(config)#router eigrp 100
R1(config-router)#eigrp stub ?
Connected.
Do advertise connected routes
leak-map.
Allow dynamic prefixes based on the leak-map
receive-only. Set receive only neighbor
redistributed Do advertise redistributed routes
static
Do advertise static routes
summary
Do advertise summary routes
EIGRP Stub routing configuration in named mode
R2(config)#router eigrp tst
R2(config-router)#address-family ipv4 unicast autonomous-system 100
R2(config-router-af)#eigrp stub ?
connected
Do advertise connected routes
leak-map
Allow dynamic prefixes based on the leak-map
receive-only
Set receive only neighbor
redistributed Do advertise redistributed routes
static
Do advertise static routes
summary
Do advertise summary routes
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 368
<cr>
This task requires configuring R1 as stub with the eigrp stub connected command. The eigrp stub connected
option causes the router to advertise only those connected routes that are covered by an EIGRP network
statement. R1’s configuration below shows a few network statements issued to advertise the connected
loopbacks on R1 into EIGRP:
On R1:
R1#show run | section router eigrp
router eigrp 100
network 1.1.0.1 0.0.0.0
network 1.1.1.1 0.0.0.0
network 1.1.2.1 0.0.0.0
network 1.1.3.1 0.0.0.0
network 12.1.1.1 0.0.0.0
redistribute static
redistribute rip metric 1000000 10 255 1 1500
With the eigrp stub connected command issued on R1 below, R1 will advertise the highlighted connected
networks to R2. If any of the network statements covering the loopback addresses are removed from the
above, those will not be advertised to R2.
On R1:
R1(config)#router eigrp 100
R1(config-router)#eigrp stub connected
R2’s routing table is observed below. Notice how only connected routes covered by network statements on
R1 are advertised to R2. The summary that was previously advertised to R2 is withdrawn and R1 instead
advertises the specific prefixes that match network statements. In addition, the static and RIP routes that
were redistributed into EIGRP on R1 are not present in R2’s routing table. This is a result of configuring eigrp
stub connected command that prevents R1 from advertising the D EX routes to R2.
To verify the configuration:
On R2:
R2#show ip route eigrp | include 12.1.1.1
D
1.1.0.0 [90/2570240] via 12.1.1.1, 00:02:21, GigabitEthernet0/1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 369
D
D
D
1.1.1.0 [90/2570240] via 12.1.1.1, 00:02:21, GigabitEthernet0/1
1.1.2.0 [90/2570240] via 12.1.1.1, 00:02:21, GigabitEthernet0/1
1.1.3.0 [90/2570240] via 12.1.1.1, 00:02:21, GigabitEthernet0/1
Task 6
Remove the eigrp stub connected option configured in the previous task and reconfigure
EIGRP stub routing on R1 by using the eigrp stub summary command. Test this option and
verify the routes in the routing tables of both routers.
The earlier configuration is removed from R1 with the no eigrp stub connected command:
On R1:
R1(config)#router eigrp 100
R1(config-router)#no eigrp stub connected
This task requires configuring the eigrp stub summary command. This stub configuration with the summary
option will cause the router to advertise summary routes. This means, only EIGRP summary routes are
advertised to neighbors. Any other networks covered by the network statement will not be advertised. This
would include routes that are not covered by the summary network. For example, if R1 advertised a route to
the 1.1.4.0/24 network, it would not be advertised to R2 even though the summary 1.1.0.0/22 does not
cover that network.
Task 2 of this section configured R1 to advertise a 1.1.0.0/22 summary route out its G0/2 interface to R2.
Prior to this however, following is the state of the routing table on R2. R2 receives a summary route and
EIGRP external routes from R1:
To verify the configuration:
On R2:
R2#show ip route eigrp | include 12.1.1.1
D
D EX
D EX
1.1.0.0 [90/2570240] via 12.1.1.1, 00:00:06, GigabitEthernet0/1
11.0.0.0/8 [170/15360] via 12.1.1.1, 00:00:06, GigabitEthernet0/1
200.1.1.0/24 [170/61440] via 12.1.1.1, 00:00:06, GigabitEthernet0/1
The eigrp stub summary command is issued on R1:
On R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 370
R1(config-if)#router eigrp 100
R1(config-router)#eigrp stub summary
The implications of the above configuration can be observed on R2. Notice how R2 now only receives the
summary route configured on R1. The static and RIP routes that were redistributed into EIGRP on R1 are not
advertised to R2:
On R2:
R2#show ip route eigrp
D
| include 12.1.1.1
1.1.0.0 [90/2570240] via 12.1.1.1, 00:03:50, GigabitEthernet0/1
Task 7
Remove the eigrp stub summary option configured in the previous task and reconfigure
EIGRP stub routing on R1 by using the command eigrp stub static. Test this option and
verify the routes in the routing tables of both routers.
The following first removes the configuration from Task 6:
On R1:
R1(config)#router eigrp 100
R1(config-router)#no eigrp stub summary
Once again, R2’s routing table is observed prior to any configuration changes. R2 is receiving the summary
route and the redistributed routes from R1:
To verify the configuration:
On R2:
R2#show ip route eigrp | include 12.1.1.1
D
D EX
D EX
1.1.0.0 [90/2570240] via 12.1.1.1, 00:00:04, GigabitEthernet0/1
11.0.0.0/8 [170/15360] via 12.1.1.1, 00:00:04, GigabitEthernet0/1
200.1.1.0/24 [170/61440] via 12.1.1.1, 00:00:04, GigabitEthernet0/1
This task requires configuring the eigrp stub static command on R1. The static keyword causes a router to
advertise static routes into EIGRP. However, in order to be eligible for advertisement, these static routes
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 371
have to be either covered by the network statement in EIGRP or redistributed into the EIGRP process with
the redistribute static command. Task 3 of this section configured the redistribute static command on R1.
Following configures the eigrp stub static command on R1:
On R1:
R1(config-if)#router eigrp 100
R1(config-router)#eigrp stub static
The implication of the above configuration can be seen on R2’s routing table below. As seen, R2 now learns
only about the static routes that redistributed on R1. The summary route and the EIGRP external network
200.1.1.0/24 are not being advertised by R1:
On R2:
R2#show ip route eigrp
D EX
| include 12.1.1.1
11.0.0.0/8 [170/15360] via 12.1.1.1, 00:00:16, GigabitEthernet0/1
Task 8
Remove the eigrp stub static option configured in the previous task and reconfigure EIGRP
stub routing on R1 by using the command eigrp stub redistributed. Test this option and
verify the routes in the routing tables of both routers.
The following first removes the configuration from Task 7:
On R1:
R1(config)#router eigrp 100
R1(config-router)#no eigrp stub static
The task requires issuing the eigrp stub redistributed command on R1. This stub option will cause a router
to advertise routes that were redistributed into EIGRP. These could be connected routes or routes from
other protocols that were injected into EIGRP using the redistribute statement. Both the static route to the
11.0.0.0/8 network and the RIP route for the network 200.1.1.0/24 that were redistributed into EIGRP are
eligible to be advertised when using this option.
The following verifies this. The eigrp stub redistributed command is first issued on R1:
R1(config)#router eigrp 100
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 372
R1(config-router)#eigrp stub redistributed
R2’s routing table verifies that it now receives only the redistributed routes from R1. Summary route
injected into EIGRP on R1 is not advertised to R2:
On R2:
R2#show ip route eigrp
| include 12.1.1.1
D EX 11.0.0.0/8 [170/15360] via 12.1.1.1, 00:05:22, GigabitEthernet0/1
D EX 200.1.1.0/24 [170/61440] via 12.1.1.1, 00:05:22,
GigabitEthernet0/1
Task 9
Remove the eigrp stub redistributed option configured in the previous task and reconfigure
EIGRP stub routing on R1 by using the command eigrp stub receive-only. Test this option
and verify the routes in the routing tables of both routers.
The following first removes the configuration from Task 8:
On R1:
R1(config)#router eigrp 100
R1(config-router)#no eigrp stub redistributed
This task requires configuring the eigrp stub receive-only variation. The receive-only keyword will prevent
the router from advertising any routes via EIGRP. The router however can receive EIGRP routes from its
neighbors. The following configures this option on R1:
R1(config)#router eigrp 100
R1(config-router)#eigrp stub receive-only
Observing the routing tables on R2 and R1, we see that R2 no longer has any EIGRP routes from R1. R1’s
routing table does however install the EIGRP summary route advertised by R2:
On R2:
R2#show ip route eigrp
R2#
CCIE by Narbik Kocharians
| include 12.1.1.1
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 373
On R1:
R1#show ip route eigrp | include 12.1.1.2
D
2.2.0.0 [90/2848] via 12.1.1.2, 00:00:20, GigabitEthernet0/2
Task 10
Remove the eigrp stub receive-only option configured in the previous task and reconfigure
EIGRP stub routing on R1 by using the command eigrp stub. Test this option and verify the
routes in the routing tables of both routers.
The following first removes the configuration from Task 9:
On R1:
R1(config)#router eigrp 100
R1(config-router)#no eigrp stub receive-only
This task requires configuring the eigrp stub command without any of the variations. The command by itself
will cause the router to advertise all the directly connected networks that are advertised into EIGRP with the
network statement and EIGRP summary routes created on the router:
Following configures eigrp stub on R1:
R1(config)#router eigrp 100
R1(config-router)#eigrp stub
The show run on R1 shows that even though just the eigrp stub command was issued, the router defaults to
advertising the connected and summary routes. This is seen in the highlighted output below:
R1#show run | section router eigrp
router eigrp 100
network 1.1.0.1 0.0.0.0
network 1.1.1.1 0.0.0.0
network 1.1.2.1 0.0.0.0
network 1.1.3.1 0.0.0.0
network 12.1.1.1 0.0.0.0
redistribute static
redistribute rip metric 1000000 10 255 1 1500
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 374
eigrp stub connected summary
R2’s routing table shows the only route it learns is the summary route. This might seem strange as the
connected loopback networks configured for EIGRP on R1 are missing from the routing table on R2:
On R2:
R2#show ip route eigrp | include 12.1.1.1
D
1.1.0.0 [90/2570240] via 12.1.1.1, 00:02:44, GigabitEthernet0/1
However, recall that configuring a EIGRP summary route on a router causes the router to only advertise the
summary route while suppressing the more specific prefixes. A simple test is implemented below to prove
this point.
A new loopback is created on R1 and is assigned the IP Address 100.1.1.1/24. The network command is
issued to advertise this network into EIGRP:
On R1:
R1(config)#interface lo100
R1(config-if)#ip address 100.1.1.1 255.255.255.0
R1(config)#router eigrp 100
R1(config-router)#network 100.1.1.1 0.0.0.0
Since the loopback 100 IP address down not fall under the summary range created on R1, 100.1.1.1 is
advertised to R2 The routing table on R2 show that it now learns both the summary and connected route
from R1:
To verify the configuration:
On R2:
R2#show ip route eigrp | i 12.1.1.1
Gateway of last resort is not set
D
D
1.1.0.0 [90/2570240] via 12.1.1.1, 00:08:40, GigabitEthernet0/1
100.1.1.0 [90/2570240] via 12.1.1.1, 00:00:05, GigabitEthernet0/1
Task 11
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 375
Erase the startup configuration and reload the routers before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 376
Lab 4
EIGRP Filtering
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
EIGRP folder  Lab-4.
Task 1
Configure EIGRP 100 on all routers and advertise their directly connected links into EIGRP.
Following configures EIGRP 100 al R1, R2, R3 and R4. All the directly connected networks (inluding
loopbacks) are advertised into EIGRP with the neighbor statement:
On R1:
R1(config)#router eigrp 100
R1(config-router)#network 1.1.1.1 0.0.0.0
R1(config-router)#network 11.1.1.1 0.0.0.0
R1(config-router)#network 12.1.1.1 0.0.0.0
R1(config-router)#network 111.1.1.1 0.0.0.0
On R2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 377
R2(config)#router eigrp 100
R2(config-router)#network 12.1.1.2 0.0.0.0
R2(config-router)#network 10.1.1.2 0.0.0.0
R2(config-router)#network 200.1.1.1 0.0.0.0
R2(config-router)#network 200.2.2.2 0.0.0.0
R2(config-router)#network 2.2.2.2 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 12.1.1.1 (GigabitEthernet0/1)
is up: new adjacency
On R3:
R3(config)#router eigrp 100
R3(config-router)#network 10.1.1.3 0.0.0.0
R3(config-router)#network 200.1.1.1 0.0.0.0
R3(config-router)#network 200.2.2.2 0.0.0.0
R3(config-router)#network 3.3.3.3 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.2
(GigabitEthernet0/10) is up: new adjacency
On R4:
R4(config)#router eigrp 100
R4(config-router)#network 10.1.1.4 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.3
(GigabitEthernet0/10) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.2
(GigabitEthernet0/10) is up: new adjacency
To verify the configuration:
The show ip route eigrp | b Gateway command output on R4 verifies the EIGRP routes it learns:
On R4:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 378
R4#show ip route eigrp | begin Gateway
Gateway of last resort is not set
D
D
D
D
D
D
D
D
1.0.0.0/8 [90/131072] via 10.1.1.2, 00:00:09, GigabitEthernet0/10
2.0.0.0/8 [90/130816] via 10.1.1.2, 00:00:09, GigabitEthernet0/10
3.0.0.0/8 [90/130816] via 10.1.1.3, 00:00:09, GigabitEthernet0/10
11.0.0.0/8 [90/131072] via 10.1.1.2, 00:00:09, GigabitEthernet0/10
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/3072] via 10.1.1.2, 00:00:09, GigabitEthernet0/10
111.0.0.0/8 [90/131072] via 10.1.1.2, 00:00:09, GigabitEthernet0/10
200.1.1.0/24 [90/130816] via 10.1.1.3, 00:00:09, GigabitEthernet0/10
200.2.2.0/24 [90/130816] via 10.1.1.3, 00:00:09, GigabitEthernet0/10
[90/130816] via 10.1.1.2, 00:00:09, GigabitEthernet0/10
Task 2
Configure R4 such that it filters existing (1.0.0.0/8, 11.0.0.0/8, and 111.0.0.0/8) and future
networks behind R1. Do not use distribute-list, access-list, prefix-list, or route-map to
accomplish this task.
R4 learns various EIGRP networks from its EIGRP neighbor R2. Of interest to this task, are the networks
behind R1, namely the 1.0.0.0/8, 11.0.0.0/8 and 111.0.0.0/8 networks. This task requires making
configuration changes such that R4 does not install these routes into its routing table via some filtering
mechanism. The task however restricts the use of filtering methods such as distribute-list, access-lists,
prefix-lists or route-maps.
An alternative way would be to modify the hop count of these networks on R4. Hop count is the number of
router traversals to a destination. In other words, if we observe the show ip eigrp topology output for these
prefixes as shown below, we notice the hop count as 2 for the 1.0.0.0/8, 11.0.0.0/8, and 111.0.0.0/8
networks:
On R4:
R4#show ip eigrp topology 11.0.0.0 255.0.0.0 | include Hop
Hop count is 2
R4#show ip eigrp topology 1.0.0.0 255.0.0.0 | include Hop
Hop count is 2
R4#show ip eigrp topology 111.0.0.0 255.0.0.0 | include Hop
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 379
Hop count is 2
Hop count of 2 means, from R4’s perspective, it has to pass through 2 routers in order to reach the above
destinations. EIGRP has a default maximum hop count limit of 100 for routes it learns. Meaning, if a router
receives an update with a hop count greater than 100, it will consider these routes as unreachable.
To solve this task, the maximum hop count value on R4 can be lowered to 1. This way, when R4 receives
prefixes that have a hop count value of 2 or higher, it will consider these routes as unreachable and not
install them into its routing table. The command metric maximum-hops 1 under the EIGRP router
configuration mode can be used to reset the default maximum hop count value as seen below:
On R4:
R4(config)#router eigrp 100
R4(config-router)#metric maximum-hops 1
Note: You should see the following console messages, this is because the policy for EIGRP is changed from
100 (default hop count) to only 1:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 10.1.1.2
(GigabitEthernet0/10) is down: Max hopcount changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 10.1.1.3
(GigabitEthernet0/10) is down: Max hopcount changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 10.1.1.2
(GigabitEthernet0/10) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: neighbor 10.1.1.3
(GigabitEthernet0/10) is up: new adjacency
Observing the routing table on R4 verifies the above configuration. The loopback addresses from R1 that R4
had learned from R2, no longer exist in the routing table since they have a hop count value greater than the
new default maximum hop value of 1. R4 will however continue to learn of the loopback addresses that
exist on R2 since the EIGRP hop count of these routes equal to 1:
To verify the configuration:
On R4:
R4#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
2.0.0.0/8 [90/130816] via 10.1.1.2, 00:01:10, GigabitEthernet0/10
3.0.0.0/8 [90/130816] via 10.1.1.3, 00:01:08, GigabitEthernet0/10
12.0.0.0/24 is subnetted, 1 subnets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 380
D
D
12.1.1.0 [90/3072] via 10.1.1.2, 00:01:10, GigabitEthernet0/10
200.1.1.0/24 [90/130816] via 10.1.1.3, 00:00:30, GigabitEthernet0/0
[90/130816] via 10.1.1.2, 00:00:30, GigabitEthernet0/0
D
200.2.2.0/24 [90/130816] via 10.1.1.3, 00:01:08, GigabitEthernet0/10
[90/130816] via 10.1.1.2, 00:01:08, GigabitEthernet0/10
Task 3
Configure R4 such that it uses R2 as its only connection to network 200.1.1.0 /24. You
should use an access list to accomplish this task.
On R4:
Observing the routing table for the 200.1.1.0/24 network, R4 currently has two equal cost paths to reach
this network. One via R2 and the other through R3. This is because the prefix has been configured on both
devices and advertised into EIGRP:
R4#show ip route 200.1.1.0
Routing entry for 200.1.1.0/24
Known via "eigrp 100", distance 90, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.3 on GigabitEthernet0/0, 00:08:12 ago
Routing Descriptor Blocks:
10.1.1.3, from 10.1.1.3, 00:08:12 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
* 10.1.1.2, from 10.1.1.2, 00:08:12 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
The task requires making configuration changes such that R4 chooses the path via R2 as primary. The task
requires the use of an access-list to achieve the same.
An access-list in conjunction with a distribute-list can be used to solve this task. First, an extended access-list
is defined on R4. The first deny statement of this access-list as seen below, identifies two key attributes.
First, the advertising router, meaning the source of the EIGRP update for the 200.1.1.0 prefix, is fed into the
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 381
access-list. For this task, the source of the update to be denied is R3’s IP address, 10.1.1.3, The second part
of this statement identifies the actual network from that source, which is the 200.1.1.0 network. Finally, the
second access-list statement configured explicitly permits everything else:
R4(config)#access-list 100 deny ip host 10.1.1.3 host 200.1.1.0
R4(config)#access-list 100 permit ip any any
The above access-list is then referenced in the distribute-list on R4 under the EIGRP router configuration
mode to perform EIGRP route filtering. The distribute-list is applied inbound on the G0/0 interface to apply
the policy on incoming EIGRP updates:
R4(config)#router eigrp 100
R4(config-router)#distribute-list 100 in g0/0
The result of this configuration is when R4 receives EIGRP updates for the 200.1.1.0 network that are
sourced by R3, they get denied. R4 is then only left with a single path through R2 for the 200.1.1.0/24
network:
R4#show ip route 200.1.1.0
Routing entry for 200.1.1.0/24
Known via "eigrp 100", distance 90, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.2 on GigabitEthernet0/0, 00:02:07 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 10.1.1.2, 00:02:07 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Task 4
Configure R4 such that it takes R3 to reach network 200.2.2.0 /24. R4 should only use R2 as
the next hop to reach network 200.2.2.0/24 when R3 is down. You should use a standard
access list to accomplish this task.
Observing R4’s routing table, we notice, similar to the previous task, R4 has two equal cost paths in its
routing table for the 200.2.2.0/24 network:
On R4:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 382
R4#show ip route 200.2.2.0
Routing entry for 200.2.2.0/24
Known via "eigrp 100", distance 90, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.2 on GigabitEthernet0/0, 00:03:12 ago
Routing Descriptor Blocks:
* 10.1.1.3, from 10.1.1.3, 00:03:12 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
10.1.1.2, from 10.1.1.2, 00:03:12 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
In the previous task, if the path for the 200.1.1.0/24 via R2 failed, R4 would not switch over to using the
path from R3 since the updates from R3 were being denied. This task however requires making
configuration changes such that R4 uses the path via R3 for the 200.2.2.0/24 network as primary and should
R3 fail, R4 should switch over to the backup path via R2. The task further requires the use of a standard
access-list to accomplish this.
This can be achieved by modifying the administrative distance of the route received from R3. If the AD for
the route to 200.2.2.0/24 received from R3 is set to something lower than the default of 90, the route from
R3 will automatically be preferred over the route from with AD of 90 from R2. To achieve this, first an
access-list is configured on R4. It is good practice to check what access-lists are currently configured on the
router with the show access-lists command to prevent modifying any of the existing access-lists. As seen, R4
only has a single extended access-list configured.
R4#show access-lists
Extended IP access list 100
10 deny ip host 10.1.1.3 200.1.1.0 0.0.0.255 (3 matches)
20 permit ip any any (24 matches)
A standard access-list 1 is then configured on R4. The permit statement of this access-list identifies the
network 200.2.2.0/24:
R4(config)#access-list 1 permit 200.2.2.0 0.0.0.255
Next, the distance command is configured under the EIGRP router configuration mode:
R4(config)#router eigrp 100
R4(config-router)#distance 89 10.1.1.3 0.0.0.0 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 383
The distance 89 10.1.1.3 0.0.0.0 1 command can be used to set the distance of the EIGRP route. The 89
specified in the command refers to the intended AD from the next hop 10.1.1.3. Access-list 1 is appended to
this command to indicate the routes for which the AD should be set to 89.
The above causes R4 to set the AD for the 200.2.2.0/24 network from R3 to 89. As a result, it becomes the
preferred route and gets installed into the routing table as seen below on R4:
To verify the configuration:
On R4:
R4#show ip route 200.2.2.0
Routing entry for 200.2.2.0/24
Known via "eigrp 100", distance 89, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.3 on GigabitEthernet0/0, 00:10:36 ago
Routing Descriptor Blocks:
* 10.1.1.3, from 10.1.1.3, 00:10:36 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
To test the failover situation, R3’s G0/0 interface is shut down. This causes the backup path via R2 with an
AD of 90 to be installed into routing table on R4:
On R3:
R3(config)#interface g0/0
R3(config-if)#shut
On R4:
R4#show ip route 200.2.2.0
Routing entry for 200.2.2.0/24
Known via "eigrp 100", distance 90, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.2 on GigabitEthernet0/0, 00:00:41 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 10.1.1.2, 00:00:41 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 384
Loading 1/255, Hops 1
R3’s G0/0 interface is brought back up again, resulting in R4 installing the path with the lower AD of 89 once
again in its routing table:
On R3:
R3(config-if)#interface g0/0
R3(config-if)#no shut
On R4:
R4#show ip route 200.2.2.0
Routing entry for 200.2.2.0/24
Known via "eigrp 100", distance 89, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.3 on GigabitEthernet0/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.1.1.3, from 10.1.1.3, 00:00:06 ago, via GigabitEthernet0/0
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Task 5
Filter network 2.0.0.0/8 on R4. Do not use distribute-list or route-map to accomplish this
task.
The routing table on R4 shows it learns the 2.0.0.0/8 network from R2:
On R4:
R4#show ip route 2.0.0.0
Routing entry for 2.0.0.0/8
Known via "eigrp 100", distance 90, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.2 on GigabitEthernet0/0, 00:18:00 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 10.1.1.2, 00:18:00 ago, via GigabitEthernet0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 385
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
The task requires filtering this network on R4 without the use of any distribute-list or route-maps. The
distance command can once again be used to solve this task. This time however, the distance of this route
from R2 is set 255. Setting the AD of a route to 255 causes the route to consider the route as unreachable
and unusable. As a result, the router does not install this route in its routing table.
The following sets the AD of the 2.0.0.0/8 network on R4 to 255. Similar to the earlier configuration, an
access-list identifying and permitting this network is first created. The access-list is then appended to the
distance command that sets the AD to 255 for the route in ACL 2 from R2’s address 10.1.1.2:
R4(config)#access-list 2 permit 2.0.0.0 0.255.255.255
R4(config)#router eigrp 100
R4(config-router)#distance 255 10.1.1.2 0.0.0.0 2
The routing table on R4 verifies it no longer has the route to the 2.0.0.0/8 network:
R4#show ip route 2.0.0.0
% Network not in table
Task 6
Configure R4 to filter network 3.0.0.0/8.
R4 learns the 3.0.0.0/8 network from R3 as seen below:
On R4:
R4#show ip route 3.0.0.0
Routing entry for 3.0.0.0/8
Known via "eigrp 100", distance 90, metric 130816, type internal
Redistributing via eigrp 100
Last update from 10.1.1.3 on GigabitEthernet0/0, 00:01:08 ago
Routing Descriptor Blocks:
* 10.1.1.3, from 10.1.1.3, 00:01:08 ago, via GigabitEthernet0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 386
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Since the task does not state any restriction on the tools that can be used to solve this task, the existing
access-list 100 can be used to filter the 3.0.0.0/8 network from R3. The following is the existing access-list
100 on R4:
R4#show access-lists 100
Extended IP access list 100
10 deny ip host 10.1.1.3 host 200.1.1.0 (7 matches)
20 permit ip any any (55 matches)
An additional deny statement with a sequence number 15 denying the 3.0.0.0 network from any IP can be
added to the extended access-list 100:
R4(config)#ip access-list extended 100
R4(config-ext-nacl)#15 deny ip any 3.0.0.0 0.255.255.255
To verify the configuration:
R4#show access-lists 100
Extended IP access list 100
10 deny ip host 10.1.1.3 host 200.1.1.0 (7 matches)
15 deny ip any 3.0.0.0 0.255.255.255
20 permit ip any any (55 matches)
As seen below, R4 no longer shows the 3.0.0.0/8 network in its routing table:
R4#show ip route 3.0.0.0
% Network not in table
Task 7
Erase the startup configuration and reload the routers before proceeding to the next task.
Lab 5
Advanced EIGRP Lab
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 387
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
EIGRP folder  Lab-5.
Task 1
Configure the G0/0 interfaces of R1, R2, and R3 in EIGRP AS 100. These routers should be
configured to advertise their Lo0 interfaces in this AS, using the following policy:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 388


These routers should be configured to reach each other’s loopback interface/s by
going through R1.
Do not use Policy-based Routing (PBR) or configure another AS to accomplish this
task.
On R1:
Following configuration first enables EIGRP on the G0/0 and Lo0 interfaces on R1, R2 and R3 for AS 100:
R1(config)#router eigrp 100
R1(config-router)#network 1.1.1.1 0.0.0.0
R1(config-router)#network 123.1.1.1 0.0.0.0
On R2:
R2(config)#router eigrp 100
R2(config-router)#network 2.2.2.2 0.0.0.0
R2(config-router)#network 123.1.1.2 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.1
(GigabitEthernet0/0) is up: new adjacency
On R3:
R3(config)#router eigrp 100
R3(config-router)#network 3.3.3.3 0.0.0.0
R3(config-router)#network 123.1.1.3 0.0.0.0
You should see the following two console messages stating that the local router has established two
neighbor adjacencies, one with R1 and the second one with R2:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.2
(GigabitEthernet0/0) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.1
(GigabitEthernet0/0) is up: new adjacency
RIPv2, EIGRP and BGP are classless routing protocols and by default they have a Classful nature/behavior,
meaning that they automatically summarize the networks that they advertise to their major network
boundary. This behavior can be disabled by using the “no auto-summary” router configuration command.
Starting in IOS 15 code, “auto-summary” is disabled by default in EIGRP.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 389
EIGRP neighborships is verified with the show ip eigrp neighbors command on R1. The show ip eigrp
interfaces command shows the interface that have EIGRP enabled on them:
To verify the configuration:
On R1:
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H
Address
Interface
1
0
123.1.1.3
123.1.1.2
Gi0/0
Gi0/0
Hold Uptime
SRTT
(sec)
(ms)
10 00:04:28
1
12 00:08:44
1
RTO
Q Seq
Cnt Num
100 0 6
100 0 5
To see the interfaces that have EIGRP enabled:
R1#show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue
Mean
Interface Peers Un/Reliable SRTT
Lo0
0
0/0
0
Gi0/0
2
0/0
7
Pacing Time
Un/Reliable
0/0
0/2
Multicast
Flow Timer
0
1
Pending
Routes
0
0
Following shows the EIGRP routes in R1, R2 and R3’s routing table:
R1#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [90/130816] via 123.1.1.2, 00:05:46, GigabitEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [90/130816] via 123.1.1.3, 00:03:17, GigabitEthernet0/0
On R2:
R2#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [90/130816] via 123.1.1.1, 00:06:15, GigabitEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [90/130816] via 123.1.1.3, 00:03:49, GigabitEthernet0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 390
On R3:
R3#sh ip route eigrp | b Gate
Gateway of last resort is not set
D
D
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [90/130816] via 123.1.1.1, 00:04:25, GigabitEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [90/130816] via 123.1.1.2, 00:04:23, GigabitEthernet0/0
Observing the routing table on R2 and R3 above, we notice the next hop ip address on R2 for the 3.3.3.3
prefix is 123.1.1.3. Similarly, the next hop ip address for the 2.2.2.2 prefix on R3 is R2’s address 123.1.1.2.
The task explicitly states that R2 and R3 should use R1 to reach each other's loopback addresses.
The reason the next hop addresses on R2 and R3 point to each other for their respective loopback addresses
is because of the neighbor adjacency between them. In order to ensure that they use R1’s address as the
next hop for each other's loopback addresses, R2 and R3 should be configured to only form EIGRP
neighborships with R1 and not each other.
This can be achieved by statically configuring neighborships between R1 - R2 and R1 - R3 using the neighbor
statement. In addition, the interface through which the neighbor adjacency will be established should be
referenced in the neighbor command. A neighbor statement should be entered for both R2 and R3 on R1.
Whenever EIGRP is configured with static neighbor statements on an interface, it cannot accept or send
both multicast and unicast packets. EIGRP MUST use either Multicast or Unicast on the interface as a means
to establish neighbor adjacencies. Since R2 and R3 are using static neighbor configuration, then R1 must
also use static neighbor configuration in order for the adjacency to come up. It cannot, for example, use
unicast with R2 and multicast with R3.
The following configures this static neighbor relationship on R1, R2, and R3.
On R1:
R1(config)#router eigrp 100
R1(config-router)#neighbor 123.1.1.2 g0/0
R1(config-router)#neighbor 123.1.1.3 g0/0
On R2 and R3:
Rx(config)#router eigrp 100
Rx(config-router)#neighbor 123.1.1.1 g0/0
You should see the following console message on R2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 391
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.1
(GigabitEthernet0/0) is up: new adjacency
You should see the following console message on R3:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.1
(GigabitEthernet0/0) is up: new adjacency
To verify the configuration:
On R1:
R1#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [90/130816] via 123.1.1.2, 00:02:02, GigabitEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [90/130816] via 123.1.1.3, 00:00:59, GigabitEthernet0/0
On R2:
R2#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [90/130816] via 123.1.1.1, 00:01:19, GigabitEthernet0/0
On R3:
R3#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [90/130816] via 123.1.1.1, 00:00:37, GigabitEthernet0/0
Notice in the output above, R1 has the routes to R2 and R3’s loopback 0 interfaces. These routes are missing
from R2 and R3’s routing table. The reason for this is the split-horizon behaviour in distance vector
protocols and EIGRP is a DV protocol. Split-horizon is a loop avoidance mechanism that prevents a router
from advertising a route out the interface it received on. Since R1 receives the route to 2.2.2.2 and 3.3.3.3
over its G0/0 interface, it will not advertise this route back to R2 and R3 out the same interface. This
behavior can be turned off on R1 by issuing the no ip split-horizon eigrp 100 command on R1’s G0/0
interface as seen below:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 392
On R1:
R1(config)#int g0/0
R1(config-if)#no ip split-horizon eigrp 100
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.3
(GigabitEthernet0/0) is resync: split horizon changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.2
(GigabitEthernet0/0) is resync: split horizon changed
With split-horizon now disabled, R2 and R3 both receive routes to each other's loopback 0 addresses from
R1. As required by the task, the next-hop IP addresses for these routes on R2 and R3 both point to R1’s G0/0
intergdace address 123.1.1.1:
On R2:
R2#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [90/130816] via 123.1.1.1, 00:02:22, GigabitEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [90/131072] via 123.1.1.1, 00:00:39, GigabitEthernet0/0
On R3:
R3#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [90/130816] via 123.1.1.1, 00:03:37, GigabitEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [90/131072] via 123.1.1.1, 00:01:54, GigabitEthernet0/0
Test Configuration
A traceroute to 3.3.3.3 from R2 verifies that the path it takes to reach the prefix is via R1:
R2#traceroute 3.3.3.3 numeric
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 393
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 123.1.1.1 1 msec 0 msec 1 msec
2 123.1.1.3 1 msec * 1 msec
Task 2
Configure R3’s G0/4, G0/5, and G0/6 in AS 300. Configure R4’s, R5’s, and R6’s G0/3 and
loopback 0 interfaces in this AS.
Configure R3 to summarize its Lo100–Lo107.
The summary route should be advertised to R4, R5, and R6 based on the following policy:




R4 should receive the summary only.
R5 should receive the summary plus network 100.1.3.0 /24.
R6 should receive the summary plus all the specific routes.
Configure the minimum number of ip summary-address commands possible to
accomplish this task.
One of the key requirements for a successful summary route announcement is the presence of a specific
route from the summary range in the routing table. Meaning, if R3 is to be configured to announce a
100.1.0.0/21 summary route, a specific route from this range must be present in its routing table. The show
run | include interface Loopback10[0-7]|ip address 100 command output below verifies that R3 has been
configured with specific routes from this range and as such will be announcing the 100.1.0.0/21 summary
route, if configured:
On R3:
R3#show run | include interface Loopback10[0-7]|ip address 100.
interface Loopback100
ip address 100.1.0.1 255.255.255.0
interface Loopback101
ip address 100.1.1.1 255.255.255.0
interface Loopback102
ip address 100.1.2.1 255.255.255.0
interface Loopback103
ip address 100.1.3.1 255.255.255.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 394
interface Loopback104
ip address 100.1.4.1 255.255.255.0
interface Loopback105
ip address 100.1.5.1 255.255.255.0
interface Loopback106
ip address 100.1.6.1 255.255.255.0
interface Loopback107
ip address 100.1.7.1 255.255.255.0
However, before configuring summarization, R3, R4, R5 and R6 are first configured for EIGRP in AS 300.
EIGRP is enabled on the interfaces specified in the task on these devices with the network command.
R3(config)#router eigrp 300
R3(config-router)#network 34.1.1.3 0.0.0.0
R3(config-router)#network 35.1.1.3 0.0.0.0
R3(config-router)#network 36.1.1.3 0.0.0.0
R3(config-router)#network 100.1.0.0 0.0.255.255
On R4:
R4(config)#router eigrp 300
R4(config-router)#network 4.4.4.4 0.0.0.0
R4(config-router)#network 34.1.1.4 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 300: Neighbor 34.1.1.3 (GigabitEthernet0/3)
is up: new adjacency
On R5:
R5(config)#router eigrp 300
R5(config-router)#network 5.5.5.5 0.0.0.0
R5(config-router)#network 35.1.1.5 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 300: Neighbor 35.1.1.3 (GigabitEthernet0/3)
is up: new adjacency
On R6:
R6(config)#router eigrp 300
R6(config-router)#network 6.6.6.6 0.0.0.0
R6(config-router)#network 36.1.1.6 0.0.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 395
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 300: Neighbor 36.1.1.3 (GigabitEthernet0/3)
is up: new adjacency
Next, summarization is configured on R3. The first policy states that R4 should only receive the summary
route 100.1.0.0/21 from R3. This can be achieved with the ip summary-address eigrp 300 100.1.0.0
255.255.248.0 command on the interface G0/4 that connects R3 to R4.
On R3:
R3(config)#interface g0/4
R3(config-if)#ip summary-address eigrp 300 100.1.0.0 255.255.248.0
Configuring this command will cause R3 to only announce the summary route and suppress all the specific
prefixes falling in this range. This can be verified by looking at the routing table on R4 that shows only the
summary route and no specific routes:
To verify the configuration:
On R4:
R4#show ip route eigrp 300 | b Gate
Gateway of last resort is not set
D
D
D
D
D
5.0.0.0/32 is subnetted, 1 subnets
5.5.5.5 [90/131072] via 34.1.1.3, 00:02:06, GigabitEthernet0/3
6.0.0.0/32 is subnetted, 1 subnets
6.6.6.6 [90/131072] via 34.1.1.3, 00:01:17, GigabitEthernet0/3
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [90/3072] via 34.1.1.3, 00:02:57, GigabitEthernet0/3
36.0.0.0/24 is subnetted, 1 subnets
36.1.1.0 [90/3072] via 34.1.1.3, 00:02:57, GigabitEthernet0/3
100.0.0.0/21 is subnetted, 1 subnets
100.1.0.0 [90/130816] via 34.1.1.3, 00:00:15, GigabitEthernet0/3
Next policy states that R5 should also receive the summary route and the specific route 100.1.3.0/24. This
can be with the use of a leak-map. Leak maps as the name suggest allow for leaking of routes that would be
suppressed as a result of the summary-address command. In this context, using the leak-map in
conjunction with the ip summary-address command will allow the router to leak the routes specified in the
leak-map. Leak-maps reference a route-map that in turn references an access-list. The access-list defines the
routes that need to be leaked in a permit statement.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 396
For this policy to R5, R3 will be first configured with standard access-list that permits the network that needs
to be leaked, which is the 100.1.3.0/24 network:
On R3:
R3(config)#access-list 1 permit 100.1.3.0 0.0.0.255
Next a route-map is created. Access-list 1 is then matched in this route-map with match ip address
command:
R3(config)#route-map TST3 permit 10
R3(config-route-map)#match ip address 1
R3’s interface G0/5 connecting to R5 is then configured to announce the summary route 100.1.0.0/21 with
the ip summary-address command. The leak-map keyword and the route-map name TST3 is appended to
this command to allow leaking of the 100.1.3.0/24 network:
R3(config)#interface g0/5
R3(config-if)#ip summary eigrp 300 100.1.0.0 255.255.248.0 leak-map TST3
The result of the above configuration can be verified by observing the routing table on R5. Notice how R5
receives the 100.1.0.0/21 summary route and the specific 100.1.3.0/24 route:
To verify the configuration:
On R5:
R5#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
D
D
D
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [90/131072] via 35.1.1.3, 00:05:16, GigabitEthernet0/3
6.0.0.0/32 is subnetted, 1 subnets
6.6.6.6 [90/131072] via 35.1.1.3, 00:04:22, GigabitEthernet0/3
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [90/3072] via 35.1.1.3, 00:05:16, GigabitEthernet0/3
36.0.0.0/24 is subnetted, 1 subnets
36.1.1.0 [90/3072] via 35.1.1.3, 00:05:16, GigabitEthernet0/3
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
100.1.0.0/21 [90/130816] via 35.1.1.3, 00:00:12, GigabitEthernet0/3
100.1.3.0/24 [90/130816] via 35.1.1.3, 00:05:16, GigabitEthernet0/3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 397
The final policy in this task states that R6 receive the summary 100.1.0.0/21 and all the specific routes as
well. As mentioned earlier, configuring a summary route will automatically suppress the specific routes.
Specific routes can however be leaked through a leak-map that references a route-map. The route-map
references an access-list that lists the networks that are to be leaked.
A way to solve this task would be configuring an access-list like in the earlier policy that lists and permits all
the 8 specific prefixes. The task however, states to make use of most minimal configuration possible. So one
other way of solving this with lesser configurations would be to create a route-map with a permit statement
and omitting any reference to an access-list. Let’s see this in action. R3 is configured with a route-map called
TST4. The only permit statement of this route-map is an empty permit statement. The route-map is then
referenced in the ip summary-address command with the leak-map:
On R3:
R3(config)#route-map TST4 permit 10
R3(config)#interface g0/6
R3(config-if)#ip summary eigrp 300 100.1.0.0 255.255.248.0 leak-map TST4
The result of this configuration can be seen below on R6’s routing table. R6 now has the summary route
100.1.0.0/21 and all the 8 specific prefixes:
To verify the configuration:
On R6:
R6#sh ip route eigrp | b Gate
Gateway of last resort is not set
D
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [90/131072] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
5.0.0.0/32 is subnetted, 1 subnets
5.5.5.5 [90/131072] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [90/3072] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [90/3072] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
D
D
D
D
D
D
D
100.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
100.1.0.0/21 [90/130816] via 36.1.1.3, 00:00:31, GigabitEthernet0/3
100.1.0.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
100.1.1.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
100.1.2.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
100.1.3.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
100.1.4.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
100.1.5.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
D
D
D
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 398
D
D
100.1.6.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
100.1.7.0/24 [90/130816] via 36.1.1.3, 00:06:59, GigabitEthernet0/3
Adding the route-map with only a permit statement that does not reference an ACL or a missing ACL makes
the route-leak mapping action to allow all routes. The reason is the leak-map is meant to identify routes
that should be leaked. When a route passes through the leak-map, the router checks the route-map to see if
the route should be allowed to be advertised. The route-map matches all prefixes (because there is no ACL
that would deny any routes). Thus, every prefix is allowed to be advertised. This logic is the same even if the
route-map matches an ACL that does not exist. Because the ACL does not exist, all routes pass based on the
route-map “permit” statement.
Task 3
Configure EIGRP 300 on R4’s Lo134 and Lo135 and advertise a single summary in AS 300.
The show ip interface brief | include Loopback13[4|5] shows the following IP addresses on these loopback
interfaces:
On R4:
R4#show ip interface brief | incclude Loopback13[4|5]
Loopback134
Loopback135
102.1.34.4
102.1.35.4
YES manual up
YES manual up
up
up
To configure the summary:
EIGRP is enabled on these interfaces with the network command on R4:
On R4:
R4(config)#router eigrp 300
R4(config-router)#network 102.1.35.4 0.0.0.0
R4(config-router)#network 102.1.34.4 0.0.0.0
When trying to determine the summary range that covers both loopback addresses above it is best to start
by examining the first octet where a difference is presented between the two addresses. In this case, the
third octet is where the difference is presented. Loopback134’s third octet is 34 while Loopback135’s third
octet is 35. This octet is expanded below and converted to binary:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 399
128
0
0
M
34
35
64
0
0
M
32
1
1
M
16
0
0
M
8
0
0
M
4
0
0
M
2
1
1
M
1
0
1
DM
M = Match
DM = Don’t Match
In the form above, it is easy to see that the first seven bits match between the two numbers. This means
there are 23 total consecutive bits matching bits between the two addresses (16 from the first two octets
and 7 from the third octet). All other non matching bits are set to 0 leading to the prefix 102.1.34.0/23. A
/23 prefix length is converted to the subnet mask 255.255.254.0 which provides the information to
configure the summary-address command in EIGRP.
The ip summary-address eigrp command is then configured on the interface G0/3 connected to R3 to
announce the 102.1.34.0 255.255.254.0 summary:
R4(config)#interface g0/3
R4(config-if)#ip summary-address eigrp 300 102.1.34.0 255.255.254.0
To verify the configuration:
R3’s routing table is then verified. As seen below, R3 now has the summary 102.1.34.0/23 from R4:
On R3:
R3#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [90/130816] via 34.1.1.4, 00:16:51, GigabitEthernet0/4
5.0.0.0/32 is subnetted, 1 subnets
5.5.5.5 [90/130816] via 35.1.1.5, 00:16:00, GigabitEthernet0/5
6.0.0.0/32 is subnetted, 1 subnets
6.6.6.6 [90/130816] via 36.1.1.6, 00:15:11, GigabitEthernet0/6
100.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
100.1.0.0/21 is a summary, 00:14:09, Null0
D
102.0.0.0/23 is subnetted, 1 subnets
102.1.34.0 [90/130816] via 34.1.1.4, 00:00:20, GigabitEthernet0/4
D
D
D
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 400
Task 4
Configure the G0/7 and Lo0 interfaces of R6 and the G0/6 and loopback 0 interfaces on R7
for EIGRP in AS 67.
R7 should be configured to advertise its Lo130, such that the command show ip route eigrp
67 on R6 produces the following output:
D EX 130.3.0.0/16 [170/130816] via 67.1.1.7, 00:00:16,
GigabitEthernet0/7
R7 should use redistribute static to accomplish this task. Do not configure a static route to
accomplish this task.
Following first configures EIGRP on R6 and R7. As required by the task, EIGRP for AS 67 is enabled on
interfaces specified in the task on R6 and R7 with the network command:
On R6:
R6(config)#router eigrp 67
R6(config-router)#network 67.1.1.6 0.0.0.0
R6(config-router)#network 6.6.6.6 0.0.0.0
On R7:
R7(config)#router eigrp 67
R7(config-router)#network 67.1.1.7 0.0.0.0
R7(config-router)#network 7.7.7.7 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 67: Neighbor 67.1.1.6 (GigabitEthernet0/6)
is up: new adjacency
The task then requires redistributing the loopback 130 network as a 130.3.0.0/16 route into EIGRP on R7
with the redistribute static command. Observing the routing table on R7, we see the the 130.3.3.0/24
network exists as a connected route:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 401
On R7:
R7#show ip route connected | begin Gate
Gateway of last resort is not set
C
C
L
C
L
7.0.0.0/32 is subnetted, 1 subnets
7.7.7.7 is directly connected, Loopback0
67.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
67.1.1.0/24 is directly connected, GigabitEthernet0/6
67.1.1.7/32 is directly connected, GigabitEthernet0/6
130.3.0.0/16 is variably subnetted, 2 subnets, 2 masks
130.3.3.0/24 is directly connected, Loopback130
130.3.3.3/32 is directly connected, Loopback130
The redistribute static under the EIGRP router configuration mode will cause the router to redistribute all
static routes into EIGRP. However, since no static route exists for this network, a static route pointing to
Null0 for the 130.3.0.0/16 network can be created on R7. The task however restricts configuring a static
route.
Another way to solve this task would be with the ip default-network. This command is a relic from the IGRP
days. IGRP is a classful protocol and could not advertise a default route. So the workaround was to flag a
classful network as the default network to which all of the other routers could recurse. However, support
for the command in EIGRP is inconsistent in a lot of ways. Using the command however causes the router to
automatically inject a static route for the 130.3.0.0/16 classful network in its routing table.
R7(config)#ip default-network 130.3.3.0
Notice the static route in the routing table on R7 below:
R7#show ip route static | begin Gate
Gateway of last resort is not set
S
130.3.0.0/16 is variably subnetted, 3 subnets, 3 masks
130.3.0.0/16 [1/0] via 130.3.3.0
With a static route now injected into the routing table, R7 can be configured with the redistribute static command that
results in it injecting the 130.3.0.0/16 network into EIGRP:
R7(config)#router eigrp 67
R7(config-router)#redistribute static
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 402
Observing the routing table on R6 verifies the above configuration. R6 now has an EIGRP external route
matching the output the task desires:
On R6:
R6#show ip route eigrp | include 130.3.
D EX 130.3.0.0/16 [170/130816] via 67.1.1.7, 00:01:17, GigabitEthernet0/7
Task 5
Configure the routers in AS 67 such that they log neighbor warning messages and repeat
the warning messages every 10 minutes. You should disable logging of neighbor changes for
this AS.
The show run all command output can be used to verify the default settings on the router. As seen below,
the eigrp log-neighbor-changes is enabled by default on IOS:
R7#show running-config all | in eigrp log
eigrp log-neighbor-changes
eigrp log-neighbor-warnings 10
This command records logs of neighbor changes. To turn this feature off, simply issue the no eigrp log-neighborchanges command under the EIGRP router configuration mode as seen below on R6 and R7:
On R6 and R7:
Rx(config)#router eigrp 67
Rx(config-router)#no eigrp log-neighbor-changes
Next the task requires that the EIGRP neighbor warning messages should appear every 10 minutes. By
default, the neighbor watching messages are logged every 10 seconds as seen in the output of the show
running-config all | in eigrp log above. To change the default value to 10 minutes, that is 600 seconds, the
eigrp log-neighbor-warnings 600 command is configured under the EIGRP router configuration mode as
seen below on R6 and R7:
On R6 and R7:
Rx(config)#router eigrp 67
Rx(config-router)#eigrp log-neighbor-warning 600
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 403
Task 6
Configure the routers in AS 67 such that a dead neighbor is detected within 3 seconds.
The task wording explicitly states that neighbors should be detected as down within 3 seconds. EIGRP keeps
track of neighbor states by sending hello messages at regular intervals. If hellos are not received within a
certain time, EIGRP declares that neighbor to be dead. This time period is known as the hold down timer in
EIGRP. By default the hold down timer is set to 15 seconds and EIGRP sends hellos every 5 seconds (called
the hello timer).These default value can be seen with the show ip eigrp interfaces detail example output
from R7 below:
On R7:
R7#show ip eigrp interfaces detail G0/6
EIGRP-IPv4 Interfaces for AS(67)
Xmit Queue
PeerQ
Mean
Time
Multicast
Pending
Interface
Peers Un/Reliable Un/Reliable SRTT
Un/Reliable
Flow Timer
Routes
Gi0/6
1
0/0
0/0
1
50
0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial <none>
Packetized sent/expedited: 8/2
Hello's sent/expedited: 17263/4
Un/reliable mcasts: 0/7 Un/reliable ucasts: 9/5
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 2 Out-of-sequence rcvd: 2
Topology-ids on interface - 0
Authentication mode is not set
Topologies advertised on this interface: base
Topologies not advertised on this interface:
Pacing
0/0
With default settings, after 3 hellos are missed the EIGRP neighbor will be declared down. To complete the
task, EIGRP needs to detect a down neighbor within 3 seconds. Thus, the hold down timer needs to be
lowered to 3 seconds. Before making that change, however, the EIGRP hello timer should be set to a value
lower than the hold timer. Failing to do so would result in the hold down timer expiring before a hello is
sent. The ip hello-interval eigrp 67 1 command is issued on R6 and R7 to set the hello interval timer to 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 404
second. Then the hold down timer is set to 3 seconds with the ip hold-time eigrp 67 3 command as seen
below:
On R6:
R6(config)#int g0/7
R6(config-if)#ip hello-interval eigrp 67 1
R6(config-if)#ip hold-time eigrp 67 3
On R7:
R7(config)#int g0/6
R7(config-if)#ip hello-interval eigrp 67 1
R7(config-if)#ip hold-time eigrp 67 3
To verify the configuration:
The show ip eigrp interfaces detail | i Hello|Hold command on both routers verify the above configuration
changes:
R6#show ip eigrp interfaces detail G0/6
Hello-interval is 1, Hold-time is 3
Split-horizon is enabled
Next xmit serial <none>
Packetized sent/expedited: 6/1
Hello's sent/expedited: 17398/4
Un/reliable mcasts: 0/7 Un/reliable ucasts: 8/6
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 3 Out-of-sequence rcvd: 1
Topology-ids on interface - 0
Authentication mode is not set
Topologies advertised on this interface: base
Topologies not advertised on this interface:
R7#show ip eigrp interfaces detail G0/7
Hello-interval is 1, Hold-time is 3
Split-horizon is enabled
Next xmit serial <none>
Packetized sent/expedited: 8/2
Hello's sent/expedited: 17373/4
Un/reliable mcasts: 0/7 Un/reliable ucasts: 9/5
Task 7
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 405
Routers in AS 100 should be configured to use Bandwidth and not Bandwidth + DLY when
calculating their composite metric.
EIGRPs composite metric uses five K values that are used to provide a multiplier to certain variables in
EIGRP’s metric calculation formula. These variables more closely correspond to the K values K1 and K3. The
default K value weighting for each EIGRP metric formula is: K1=1, K2=0, K3=1, K4=0, K5=0, K6=0 with an
example output from R1 showing the same below:
On R1:
R1#show ip protocols | include Metric
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
By default, the K values are modified such that bandwidth and delay are taken into account. This task
requires modifying the default EIGRP metric calculation formula through manipulation of the K values such
that only bandwidth is considered towards the calculation of the composite metric. This is achieved by
setting the K3 value that corresponds to delay to 0 with the metric weights 0 1 0 0 0 0 command under the
EIGRP router configuration mode on R1, R2 and R3:
On R1, R2 and R3:
Rx(config)#router eigrp 100
Rx(config-router)#metric weights 0 1 0 0 0 0
To verify the configuration:
The show ip protocol | in Metrics on the routers verify the configuration changes:
On R2:
R2#show ip protocol | include Metric
Metric weight K1=1, K2=0, K3=0, K4=0, K5=0
Task 8
Configure R2 such that EIGRP never uses more than 25% of its G0/0 link’s bandwidth.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 406
By default, EIGRP will ONLY consume 50 percent of its interface’s bandwidth for EIGRP control packets. This
default can be changed using the ip bandwidth-percent command in interface configuration mode for
EIGRP in classic mode. The following modifies the utilization to 25 percent as the task states on R2 under the
G0/0 interface:
On R2:
R2(config)#int g0/0
R2(config-if)#ip bandwidth-percent eigrp 100 25
To verify the configuration:
R2#show ip eigrp interface detail | i BW
Interface BW percentage is 25
Task 9
Configure the G0/8 interface of R5 and the G0/5 and the Lo0 interfaces of R8 in AS 500.
The following configures EIGRP for the adjacency between R5 and R8. EIGRP is enabled on the G0/8 and
G0/5 interfaces on R5 and R8 respectively. R8’s loopback 0 address is also advertised into EIGRP with the
network statement
On R5:
R5(config)#router eigrp 500
R5(config-router)#network 58.1.1.5 0.0.0.0
On R8:
R8(config)#router eigrp 500
R8(config-router)#network 8.8.8.8 0.0.0.0
R8(config-router)#network 58.1.1.8 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 500: Neighbor 58.1.1.5 (GigabitEthernet0/5)
is up: new adjacency
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 407
The show ip route eigrp command output on R5 verifies the EIGRP route it learns from R8:
On R5:
R5#show ip route eigrp | include 58.1.1.8
D
8.8.8.8 [90/130816] via 58.1.1.8, 00:54:34, GigabitEthernet0/8
Task 10
Configure R5 to inject a default route in AS 500 based on the following policy:

R5 should be configured to inject a default route plus networks 4.0.0.0/8 and
6.0.0.0/8 from AS 300.
R5 is first configured to advertise a default route to its neighbor R8 in AS 500. The default route is is injected
with the ip summary-address command under the G0/8 interface that connects R5 to R8:
On R5:
R5(config)#interface g0/8
R5(config-if)#ip summary-address eigrp 500 0.0.0.0 0.0.0.0
To verify the configuration:
The routing table on R8 verifies the EIGRP default route propagated to it by R5:
On R8:
R8#show ip route eigrp 500 | begin Gate
Gateway of last resort is 58.1.1.5 to network 0.0.0.0
D*
0.0.0.0/0 [90/3072] via 58.1.1.5, 00:00:08, GigabitEthernet0/5
The task also states that R5 should also advertise the 4.0.0.0/8 and 6.0.0.0/8 networks to R8 along with the
default route. However, on observing the routing table below we see that these two networks belong to the
EIGRP instance 300. R5 and R8 are however configured in EIGRP 500 for their adjacencies:
On R5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 408
R5#show ip route eigrp 300 | begin Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
D
D
D
D
D
D
D
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [90/131072] via 35.1.1.3, 1d01h, GigabitEthernet0/3
6.0.0.0/32 is subnetted, 1 subnets
6.6.6.6 [90/131072] via 35.1.1.3, 1d01h, GigabitEthernet0/3
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [90/3072] via 35.1.1.3, 1d01h, GigabitEthernet0/3
36.0.0.0/24 is subnetted, 1 subnets
36.1.1.0 [90/3072] via 35.1.1.3, 1d01h, GigabitEthernet0/3
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
100.1.0.0/21 [90/130816] via 35.1.1.3, 1d01h, GigabitEthernet0/3
100.1.3.0/24 [90/130816] via 35.1.1.3, 1d01h, GigabitEthernet0/3
102.0.0.0/23 is subnetted, 1 subnets
102.1.34.0 [90/131072] via 35.1.1.3, 1d00h, GigabitEthernet0/3
This simply means that the 4.0.0.0/8 and the 6.0.0.0/8 networks cannot be leaked using a leak-map as these
routes are not from the same AS 500. R5 can however be configured to redistribute these two networks into
EIGRP process 500. This configuration is shown below. First an access-list is defined that permits the
4.0.0.0/8 and 6.0.0.0/8 networks on R5:
On R5:
R5(config)#access-list 1 permit 4.0.0.0 0.255.255.255
R5(config)#access-list 1 permit 6.0.0.0 0.255.255.255
Next, a route-map called Task10 is created and the access-list 1 is matched with the match ip address
command:
R5(config)#route-map Task10
R5(config-route-map)#match ip address 1
Routes from EIGRP instance 300 are then redistributed into EIGRP 500. The route-map Task10 is appended
to the redistribute statement to ensure only the 4.0.0.0/8 and 6.0.0.0/8 networks are redistributed:
R5(config)#router eigrp 500
R5(config-router)#redistribute eigrp 300 route-map Task10
The result of the redistribution can be seen in the topology table for EIGRP 500. Notice the networks appear
as redistributes below:
R5#show ip eigrp 500 topology
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 409
EIGRP-IPv4 Topology Table for AS(500)/ID(5.5.5.5)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 4.4.4.4/32, 1 successors, FD is 131072
via Redistributed (131072/0)
P 8.8.8.8/32, 1 successors, FD is 130816
via 58.1.1.8 (130816/128256), GigabitEthernet0/8
P 0.0.0.0/0, 1 successors, FD is 2816
via Summary (2816/0), Null0
P 6.6.6.6/32, 1 successors, FD is 131072
via Redistributed (131072/0)
P 58.1.1.0/24, 1 successors, FD is 2816
via Connected, GigabitEthernet0/8
Since R5 is configured to send a default route to R8 using the ip summary-address command, the 4.0.0.0/8
and 6.0.0.0/8 networks will be suppressed. After the redistribution, R5 can now be configured to leak the
above two networks using a leak-map as done in the earlier tasks. The existing route-map Task10 can be
referenced with the leak-map as shown below:
R5(config-router)#interface g0/8
R5(config-if)#ip summary-address eigrp 500 0.0.0.0 0.0.0.0 leak-map
Task10
To verify the configuration:
The result of the above configuration can be seen on R8’s routing table below. R8 now receives both the
default route, the 4.4.4.4 and 6.6.6.6 addresses as EIGRP external routes:
On R8:
R8#show ip route eigrp 500 | begin Gate
Gateway of last resort is 58.1.1.5 to network 0.0.0.0
D*
D EX
D EX
0.0.0.0/0 [90/3072] via 58.1.1.5, 00:08:01, GigabitEthernet0/5
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [170/131328] via 58.1.1.5, 00:00:48, GigabitEthernet0/5
6.0.0.0/32 is subnetted, 1 subnets
6.6.6.6 [170/131328] via 58.1.1.5, 00:00:48, GigabitEthernet0/5
Task 11
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 410
Erase the startup configuration and reload the routers before proceeding to the next task.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 411
Lab 6
EIGRP Authentication
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
EIGRP folder  Lab-6.
Task 1
Configure EIGRP based on the previous diagram. If this configuration is successful, these
routers should be able to see and have reachability to all routes. You should use named
mode configuration style when configuring R2 and R3 and classic EIGRP configuration style
when configuring R1 to accomplish this task.
The following configures EIGRP on R1, R2 and R3. As stated in the task, EIGRP is configured on R1 using the
classic mode configuration whereas R2 and R3 are using the EIGRP named mode configuration. The network
command is used advertise the networks on all the interfaces that are shown in the diagram:
On R1:
R1(config)#router eigrp 100
R1(config-router)#network 1.1.1.1 0.0.0.0
R1(config-router)#network 12.1.1.1 0.0.0.0
On R2:
R2(config)#router eigrp TST
R2(config-router)#address-family ipv4 as 100
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 412
R2(config-router-af)#network 2.2.2.2 0.0.0.0
R2(config-router-af)#network 123.1.1.2 0.0.0.0
R2(config-router-af)#network 23.1.1.2 0.0.0.0
R2(config-router-af)#network 12.1.1.2 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 12.1.1.1 (GigabitEthernet0/1)
is up: new adjacency
On R3:
R3(config)#router eigrp TST
R3(config-router)#address-family ipv4 as 100
R3(config-router-af)#network 3.3.3.3 0.0.0.0
R3(config-router-af)#network 123.1.1.3 0.0.0.0
R3(config-router-af)#network 23.1.1.3 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.2
(GigabitEthernet0/2) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 23.1.1.2
(GigabitEthernet0/10) is up: new adjacency
To verify the configuration:
Routing tables on R1 and R3 verify the EIGRP routes they learn from R2:
On R3:
R3#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
1.0.0.0/8 [90/2575360] via 123.1.1.2, 00:00:47, GigabitEthernet0/2
[90/2575360] via 23.1.1.2, 00:00:47, GigabitEthernet0/0
2.0.0.0/8 [90/10880] via 123.1.1.2, 00:00:47, GigabitEthernet0/2
[90/10880] via 23.1.1.2, 00:00:47, GigabitEthernet0/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 123.1.1.2, 00:00:47, GigabitEthernet0/2
[90/15360] via 23.1.1.2, 00:00:47, GigabitEthernet0/0
On R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 413
R1#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
2.0.0.0/8 [90/2848] via 12.1.1.2, 00:07:41, GigabitEthernet0/2
3.0.0.0/8 [90/3104] via 12.1.1.2, 00:06:04, GigabitEthernet0/2
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/3072] via 12.1.1.2, 00:07:41, GigabitEthernet0/2
123.0.0.0/24 is subnetted, 1 subnets
123.1.1.0 [90/3072] via 12.1.1.2, 00:07:41, GigabitEthernet0/2
D
D
Task 2
Configure R2 to authenticate all existing and future directly connected interfaces using the
strongest authentication method available. Use the minimum number of commands and
CCIE as the password to accomplish this task.


R2 should authenticate R1 using MD5 and Cisco as the password.
In the future, R3 may have other neighbors that won’t need authentication.
Routing protocols by default operate under the assumption that if a neighboring router runs the same
protocol with the same parameters, the local router should accept routing information advertised to it
through that protocol. This behavior gives way to routing protocol exploits where an attack can masquerade
as a legitimate routing source to a router to inject false routing information or perform a reconnaissance
attack to discover all subnets within the network.
To prevent this, many routing protocols, including EIGRP, have the ability to authenticate hello and other
protocol packets sent by potential peers. EIGRP provides this authentication by performing a hash algorithm
against the packet using a pre-shared key. The key is used to generate the hash and the resulting hash value
is transmitted as a message digest in packets sent to neighbors.
EIGRP will only accept an EIGRP packet from a neighbor if the hash value produced by the local router
matches the value in the packet it receives. For such a match to occur, both routers would need to be
configured with the same hash algorithm and pre-shared key values. EIGRP supports two main hashing
algorithms:
-
MD5
HMAC-SHA-256
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 414
MD5 is the original hashing algorithm supported by EIGRP classic and named mode configurations. HMACSHA-256 is only supported in EIGRP named configuration mode. Of the two, HMAC-SHA-256 is considered
the stronger authentication method.
The task requires configuration of the specified hashing authentication method using the specified preshared. The authentication method used between each set of neighbors should be the strongest both
neighbors support. EIGRP authentication is configured on a per-interface basis. EIGRP allows configuring
hashing parameters such as algorithm and pre-shared key in interface configuration mode (for EIGRP classic
configurations) or af-interface configuration mode (for named EIGRP configurations).
To solve the task, R2 and R3 should be configured to perform HMAC-SHA-256 authentication between each
other and on their gigabit interfaces using pre-shared key “CCIE”. R1 and R2 should be configured with MD5
authentication on their interfaces because R1 is using classic EIGRP configuration which does not support
HMAC-SHA-256 authentication. The pre-shared key for R1 and R2’s authentication should be ‘“Cisco” as
indicated by the task.
First, configuration will be made on R2. Since R2 should use the same authentication method for all
interfaces except its interface towards R1, the af-interface default configuration mode can be used to
configure the default authentication used for all interfaces. The authentication mode hmca-sha-256 CCIE
command configures R2 to use HMAC-SHA-256 authentication with the pre-shared key “CCIE” by default for
all interfaces:
On R2:
R2(config)#router eigrp TST
R2(config-router)#address-family ipv4 as 100
R2(config-router-af)#af-interface default
R2(config-router-af-interface)#authentication mode hmac-sha-256 CCIE
Next, R2’s af-interface g0/1 is configured to use MD5 authentication between itself and R1. To configure
MD5 authentication, IOS requires configuring a keychain to hold the pre-shared key information. This
keychain is created using the key chain key-chain-name command in global configuration mode. Next, the
first key in the key chain is assigned the key-string “Cisco” as required by the task. Once the keychain has
been configured, the keychain is applied to the af-interface g0/1 configuration using the authentication
mode md5 command to specify MD5 authentication and the authentication key-chain TST command to
specify the pre-shared key:
R2(config)#key chain TST
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string Cisco
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 415
R2(config)#router eigrp TST
R2(config-router)#address-family ipv4 as 100
R2(config-router-af-interface)#af-interface g0/1
R2(config-router-af-interface)#authentication mode md5
R2(config-router-af-interface)#authentication key-chain TST
R1 is also configured to use MD5 authentication with R2 over its G0/2 interface in classic EIGRP mode. A
keychain is created using the key chain key-chain-name command in global configuration mode. The first
key in the key chain is assigned the key-string “Cisco”. Following this, the authentication mode is set to MD5
under the G0/2 interface with the ip authentication mode eigrp 100 md5 command. The key-chain TST is
then applied to this interface with the ip authentication key-chain eigrp 100 TST:
On R1:
R1(config)#key chain TST
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string Cisco
R1(config)#interface g0/2
R1(config-if)#ip authentication mode eigrp 100 md5
R1(config-if)#ip authentication key-chain eigrp 100 TST
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 12.1.1.2 (GigabitEthernet0/2)
is up: new adjacency
Finally, R3 is configured to use HMAC-SHA-256 authentication over its G0/0 and G0/2 interfaces with R2.
The configuration is similar to the named mode authentication configured on R2 with one minor change.
HMAC-SHA-256 was set as the authentication method for all the interfaces on R2 by configuring the
authentication settings under the af-interface default configuration mode. This task states that R3 won’t be
running any form of EIGRP authentication with future EIGRP neighbors that might connect to it. For this
reason, HMAC-SHA-256 authentication configuration settings on R3 will be made under the af-interfaces
configuration mode for interfaces that connect R2 and R3 only. This way, all future EIGRP neighbors won’t
be required to authenticate themselves to R3.
Note: An alternative approach could be to configure the authentication settings for interfaces under the afinterface default configuration mode. Following this, the no authentication mode command under
individual interfaces can then be used to turn off authentication on interfaces as required.
On R3:
R3(config)#router eigrp TST
R3(config-router)#address-family ipv4 as 100
R3(config-router-af)#af-interface g0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 416
R3(config-router-af-interface)#authentication mode hmac-sha-256 CCIE
R3(config-router-af)#af-interface g0/2
R3(config-router-af-interface)#authentication mode hmac-sha-256 CCIE
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 23.1.1.2 (GigabitEthernet0/0)
is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 123.1.1.2
(GigabitEthernet0/2) is up: new adjacency
After completing the above configuration, the routing tables on R1 and R3 shows that they each learn EIGRP
routes from R2, confirming successful authentication:
To verify the configuration:
On R1:
R1#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
D
2.0.0.0/8 [90/2848] via 12.1.1.2, 00:01:04, GigabitEthernet0/2
3.0.0.0/8 [90/3104] via 12.1.1.2, 00:01:04, GigabitEthernet0/2
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [90/3072] via 12.1.1.2, 00:01:04, GigabitEthernet0/2
123.0.0.0/24 is subnetted, 1 subnets
123.1.1.0 [90/3072] via 12.1.1.2, 00:01:04, GigabitEthernet0/2
On R3:
R8#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
1.0.0.0/8 [90/2575360] via 123.1.1.2, 00:01:31, GigabitEthernet0/2
[90/2575360] via 23.1.1.2, 00:01:31, GigabitEthernet0/10
2.0.0.0/8 [90/10880] via 123.1.1.2, 00:03:09, GigabitEthernet0/2
[90/10880] via 23.1.1.2, 00:03:09, GigabitEthernet0/10
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [90/15360] via 123.1.1.2, 00:03:09, GigabitEthernet0/2
[90/15360] via 23.1.1.2, 00:03:09, GigabitEthernet0/10
Task 3
Erase the startup configuration and reload the routers before proceeding to the next
lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 417
Lab 7
EIGRP Challenge Lab
\
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
EIGRP folder  Lab-7.
NOTE: DO NOT access R7 at all. You should ONLY fix the problem
identified in the ticket.
Ticket 1
R1 can’t reach R3’s Lo0. You must configure R1 to fix the problem.
A ping from R1 to the R3’s loopback 0 IP address 7.47.100.3 is issued to verify the problem. As seen the ping
fails:
On R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 418
R1#ping 7.47.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Observing the routing table on R1, we notice R1 has no route to the 7.47.100.3 address:
R1#show ip route 7.47.100.3
% Subnet not in table
The show ip eigrp neighbors command on R3 verifies it is configured for EIGRP, but does not have any
EIGRP neighbors:
R1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(10)
Next, we check if R3 is running EIGRP on its interface G0/1 that connects to R1 with the show ip eigrp
interfaces command. As seen in the output, EIGRP is enabled on the interface:
On R3:
R3#show ip eigrp interfaces
IGRP-IPv4 Interfaces for AS(1)
Interface
Gi0/1
Gi0/5
Gi0/6
Lo0
Gi0/7
Peers
0
1
1
0
1
Xmit Queue
Un/Reliable
0/0
0/0
0/0
0/0
0/0
PeerQ
Mean
Un/Reliable SRTT
0/0
0
0/0
816
0/0
1278
0/0
0
0/0
1
Pacing Time
Un/Reliable
0/0
0/24
0/24
0/0
0/24
Multicast
Flow Timer
0
4080
6392
0
50
Pending
Routes
0
0
0
0
0
Even though EIGRP is enabled on the G0/1 interface on R3, there is no EIGRP adjacency between them.
Turning on EIGRP debugging on R1 also does not produce any output:
On R1:
R1#debug ip eigrp
EIGRP-IPv4 Route Event debugging is on
Though the problem is obvious from the above outputs, let’s turn off EIGRP debugging and verify the EIGRP
configuration on R1 and R3:
R1#show run | section router eigrp
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 419
router eigrp 10
network 7.0.0.0
On R3:
R3#show run | section router eigrp
router eigrp 1
network 7.47.13.0 0.0.0.255
network 7.47.35.0 0.0.0.255
network 7.47.36.0 0.0.0.255
network 7.47.100.3 0.0.0.0
network 19.0.0.0
As seen above, R1 and R3 are configured with different EIGRP AS numbers. R1 is running EIGRP for AS 1, R3
is running EIGRP for AS 10. In order for routers to form EIGRP adjacencies with each other, they need to be
configured with the same AS number. Following fixes this by configuring R1 to run EIGRP for AS 1:
On R1:
R1(config)#no router eigrp 10
R1(config)#router eigrp 1
R1(config-router)#network 7.0.0.0
We should immediately see the following console messags:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.13.3 (GigabitEthernet0/3)
is up: new adjacency
A ping from R1 to the R3’s loopback 0 now succeeds:
On R1:
R1#ping 7.47.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Ticket 2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 420
R6 does not have a stable EIGRP adjacency with R4. Do not use an EIGRP command to fix
this ticket.
The show ip eigrp neighbors command reveals that R4 only has an EIGRP adjacency with R5:
On R4:
R4#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
Interface
0
7.47.45.5
Gi0/5
Hold Uptime
SRTT
(sec)
(ms)
11 00:08:51 1598
RTO
Q Seq
Cnt Num
5000 0 3
However, as seen below, EIGRP is enabled on the tunnel interface on R4 and R6:
On R4:
R4#show run | section router eigrp
router eigrp 1
metric maximum-hops 2
network 7.0.0.0
On R6:
R6#show run | section router eigrp
router eigrp 1
network 7.0.0.0
network 19.0.0.0
What we notice is that as stated in the ticket, EIGRP is unstable on R6 and the adjacency appears to be
flapping:
*Aug 13 12:27:55.858: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.46.4
(Tunnel64) is down: retry limit exceeded
*Aug 13 12:27:59.595: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.46.4
(Tunnel64) is up: new adjacency
*Aug 13 12:29:19.099: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.46.4
(Tunnel64) is down: retry limit exceeded
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 421
*Aug 13 12:29:22.966: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.46.4
(Tunnel64) is up: new adjacency
Following shows the tunnel configuration on R4 and R6:
On R4:
R4#show run interface tunnel 46 | begin interface
interface Tunnel46
bandwidth 1544
ip address 7.47.46.4 255.255.255.0
no ip redirects
ip nhrp map 7.47.46.6 192.1.6.6
ip nhrp map multicast 192.1.6.6
ip nhrp network-id 444
delay 2000
tunnel source GigabitEthernet0/9
tunnel mode gre multipoint
end
On R6:
R6#show run interface tunnel 64 | begin interface
interface Tunnel64
bandwidth 1544
ip address 7.47.46.6 255.255.255.0
no ip redirects
ip nhrp map 7.47.46.4 192.1.4.4
ip nhrp network-id 666
delay 2000
tunnel source GigabitEthernet0/9
tunnel mode gre multipoint
The tunnel configuration on R4 appears to be fine, however, there is a crucial command missing from R6’s
tunnel 64 configuration. This is the ip nhrp map multicast command on R6. Recall that a DMVPN is a nonbroadcast multi-access network. This means that there is no way for the routers that make up the DMVPN
to forward a single packet that can be routed to multiple destinations. This is because of the unicast nature
of the mGRE tunnels used to tunnel over the underlying network. This fact affects multicast routing protocol
hello messages.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 422
To overcome this limitation, DMVPN endpoints need to be explicitly configured with a unicast NBMA IP
address to which to forward all multicast or broadcast packets. These destinations are stored in the NHRP
multicast mapping table and are configured with the ip nhrp map multicast command.
In the output above, R4 is configured with a multicast mapping for R6 but R6 is not configured with a
multicast mapping for R4. The result is R4 multicasts hello packets to R6. R6, after receiving this multicast
packet, responds with a unicast update packet to which it expects a reply from R4. R4 ignores this packet
because it has not heard a unicast hello packet from R6.
The results of the above is shown in the show ip eigrp neighbors output below. Notice the Q count column
lists a “1” in the column. This is an indication that R6 is expecting a reply to a packet it sent to R4. This reply
will never come. Because the reply doesn’t come, R6 will continue to wait incrementing the RTO counter
each time it expires up to 5000. At a certain point R6 terminates the neighbor relationship with R4. This
process repeats each time R4 sends a hello to R6.
R6#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
Interface
2
1
0
7.47.46.4
19.48.216.21
7.47.36.3
Tu64
Gi0/7
Gi0/3
Hold Uptime
SRTT
(sec)
(ms)
11 00:00:03
1
13 01:07:13
1
12 01:07:25 1279
RTO
Q Seq
Cnt Num
3000 1 0
144 0 7
5000 0 18
The ticket restricts the use of any EIGRP command to fix the issue. The ticket is then fixed by enabling
multicast capability on R6 with the ip nhrp map multicast 192.1.4.4 command under its tunnel 64 interface:
R6(config)#interface tunnel 64
R6(config-if)#ip nhrp map multicast 192.1.4.4
You should see the following console message:
*Aug 13 13:34:03.156: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.46.4
(Tunnel64) is up: new adjacency
The above results in a stable EIGRP adjacency between R4 and R6. The show ip eigrp neighbors command
on R6 and R4 verify this. Additionally, the show ip eigrp route command on R6 verifies that it is learning
EIGRP routes from R4 over its tunnel 64 interface:
On R4:
R4#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
CCIE by Narbik Kocharians
Interface
Hold Uptime
(sec)
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
SRTT
(ms)
RTO
Q Seq
Cnt Num
Page 423
1
0
7.47.46.6
7.47.45.5
Tu46
Gi0/5
14 00:02:15
10 01:16:24
2
1
100
144
Hold Uptime
SRTT
(sec)
(ms)
10 00:03:35
1
12 01:16:18
1
11 01:16:30 1023
RTO
0
0
62
4
On R6:
R6#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
Interface
2
1
0
7.47.46.4
19.48.216.21
7.47.36.3
Tu64
Gi0/7
Gi0/3
Q Seq
Cnt Num
100 0 7
144 0 10
5000 0 23
R6#show ip route eigrp | include 7.47.46.4
D
D
7.47.45.0/24 [90/3328000] via 7.47.46.4, 00:03:26, Tunnel64
7.47.100.4/32 [90/2297856] via 7.47.46.4, 00:03:26, Tunnel64
Ticket 3
When R3’s G0/1, G0/7, and G0/6 are down, R3 can’t reach R4’s Lo0. Do not remove any
commands to fix this ticket.
Before shutting down R3’s G0/1,G0/7 and G0/6 interfaces, a ping is issued from R3 to R4’s loopback address
to verify rechability. As seen below, the ping succeeds:
On R3:
R3#ping 7.47.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
The routing table on R3 shows that it currently uses the path via R6 to reach the loopback address on R4:
R3#show ip route 7.47.100.4
Routing entry for 7.47.100.4/32
Known via "eigrp 1", distance 90, metric 3456000, type internal
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 424
Redistributing via eigrp 1
Last update from 7.47.36.6 on GigabitEthernet0/6, 00:25:05 ago
Routing Descriptor Blocks:
* 7.47.36.6, from 7.47.36.6, 00:25:05 ago, via GigabitEthernet0/6
Route metric is 3456000, traffic share count is 1
Total delay is 35000 microseconds, minimum bandwidth is 1000 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 2
Next, the interfaces specified in the ticket on R3 are shutdown:
R3(config)# interface range g0/1,g0/6-7
R3(config-if-range)#shut
On shutting down the above interfaces, as stated in the ticket, R3 can longer ping R4’s address:
R3#ping 7.47.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Observing the routing table on R3 we notice EIGRP routes to R5’s loopback address and the network
connecting R4 and R5, however, R3 no longer has a route to the 7.47.100.4 network that exists on R4:
R3#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
7.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
7.47.45.0/24 [90/3072000] via 7.47.35.5, 00:22:55, GigabitEthernet0/5
7.47.100.5/32
[90/2944000] via 7.47.35.5, 00:22:55, GigabitEthernet0/5
R5 however does have an EIGRP route to R4’s loopback address:
On R5:
R5#show ip route 7.47.100.4
Routing entry for 7.47.100.4/32
Known via "eigrp 1", distance 90, metric 2944000, type internal
Redistributing via eigrp 1
Last update from 7.47.45.4 on GigabitEthernet0/4, 00:00:52 ago
Routing Descriptor Blocks:
* 7.47.45.4, from 7.47.45.4, 00:00:52 ago, via GigabitEthernet0/4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 425
Route metric is 2944000, traffic share count is 1
Total delay is 15000 microseconds, minimum bandwidth is 1000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
With this we can conclude that some configuration on R5 is preventing R5 from advertising the EIGRP route
to R4’s loopback address to R3. The show ip protocol | sectopn eigrp 1 command output can shed some
light on this:
R5#show ip protocol | section eigrp 1
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 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
Soft SIA disabled
NSF-aware route hold timer is 240
Router-ID: 7.47.100.5
Stub, connected, summary
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
What the above output shows is that though no sort of route filtering is configured on R5, R5 is an EIGRP
stub router where the stub routing configuration on it, allows it to only advertise connected and summary
routes to its EIGRP neighbors. This simply means, R5 will not advertise EIGRP routes it learns from R4 over to
R3 as these are not connected or summary route. And this is the reason why R3’s routing table does not
show the 7.47.100.4 prefix in its routing table.
To fix the issue we need to configure R5 such that it advertises R4’s loopback 0 address to R5. One of the
ways to solve this would be to remove the EIGRP stub configuration on R5. The ticket however has
restricted removing any configurations.
Another alternative would be to use a leak-map. Leak-maps in EIGRP allow an EIGRP router to leak specified
prefixes. For this first an access list is configured that permits the network that needs to be advertised. In
this case, the standard access-list R4lo0 below is configured to permit any. The access-list is then referenced
in a route-map with the match ip address command. The leak-map keyword is then appended to the eigrp
stub connected summary command that references the route-map:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 426
R5(config)#ip access-list standard R4lo0
R5(config-std-nacl)#permit any
R5(config)#route-map tst permit 10
R5(config-route-map)#match ip address R4lo0
R5(config)#router eigrp 1
R5(config-router)#eigrp stub conn summ leak-map tst
To test the configuration:
The result of the above leaking can be seen on R3’s routing table. R3 now has a route to R4’s loopback
address from R5:
On R3:
R3#show ip route eigrp | begin Gate
Gateway of last resort is not set
D
D
D
D
D
D
D
7.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
7.47.36.0/24 [90/3840000] via 7.47.35.5, 00:00:19, GigabitEthernet0/5
7.47.45.0/24 [90/3072000] via 7.47.35.5, 00:00:19, GigabitEthernet0/5
7.47.46.0/24 [90/3584000] via 7.47.35.5, 00:00:19, GigabitEthernet0/5
7.47.100.4/32
[90/3200000] via 7.47.35.5, 00:00:19, GigabitEthernet0/5
7.47.100.5/32
[90/2944000] via 7.47.35.5, 00:00:19, GigabitEthernet0/5
7.47.100.6/32
[90/3712000] via 7.47.35.5, 00:00:19, GigabitEthernet0/5
19.0.0.0/24 is subnetted, 1 subnets
19.48.216.0 [90/3840000] via 7.47.35.5, 00:00:19, GigabitEthernet0/5
A ping from R3 to the 7.47.100.4 address verifies end to end rechability:
R3#ping 7.47.100.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R3(config)#interface range g0/1,g0/7,g0/6
R3(config-if-range)#no shut
You should see the adjacency before proceeding to the next ticket, you should see the following console
messages:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 427
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.13.1 (GigabitEthernet0/1)
is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 19.48.213.21
(GigabitEthernet0/7) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.36.6 (GigabitEthernet0/6)
is up: new adjacency
Ticket 4
R1’s Lo0 should always have reachability to R4’s Lo0 and G0/5 interfaces, but it does not.
You should fix this problem without configuring R1 or R4. You should not remove any
commands to resolve this ticket.
First connectivity to R4’s loopback address is verified from R1. Two pings are issued, one from R1’s G0/3
interface and another from it’s Lo0 interface:
On R1:
R1#ping 7.47.100.4 source g0/3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.4, timeout is 2 seconds:
Packet sent with a source address of 7.47.13.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R1#ping 7.47.100.4 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.4, timeout is 2 seconds:
Packet sent with a source address of 7.47.100.1
.....
Success rate is 0 percent (0/5)
As seen above, the pings sourced from the G0/3 interface on R1 succeeds. This confirms that R1 does have a
route to R4’s loopback address, 7.47.100.4. Since R4 is able to return the ping traffic, it is confirmed that R4
has a route back to the 7.47.13.0/24 network.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 428
However, the pings soured from the loopback on R1, fails. R4’s routing table is checked to verify if it has a
route back to the 7.47.100.1/32 address. The output confirms, R4 does not have a route to R1’s loopback
address in its routing table:
On R4:
R4#show ip route 7.47.100.1
% Subnet not in table
Next, R5’s routing table is checked for the same route and as seen belo. R5 does have a route to the
network. A ping from R5 to R1’s loopback also succeeds:
On R5:
R5#show ip route 7.47.100.1
Routing entry for 7.47.100.1/32
Known via "eigrp 1", distance 90, metric 3200000, type internal
Redistributing via eigrp 1
Last update from 7.47.35.3 on GigabitEthernet0/3, 00:04:51 ago
Routing Descriptor Blocks:
* 7.47.35.3, from 7.47.35.3, 00:04:51 ago, via GigabitEthernet0/3
Route metric is 3200000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
R5#ping 7.47.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
The earlier task configured R5 to leak all prefixes using a leak-map. This means, R5 is advertising R1’s
loopback address to R4. So the problem could be R4 is performing some form of filtering of this network.
The show ip protocol | section eigrp output is observed to investigate further:
On R4:
R4#show ip protocol | include eigrp 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 429
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 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
Soft SIA disabled
NSF-aware route hold timer is 240
Router-ID: 7.47.100.4
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 2
Maximum metric variance 1
As seen in the output above, no form of explicit filtering is configured on R4. However, something does
stand out, the maximum hop count value. Hop count is the number of router traversals to a destination.
R4 has been configured for a maximum hop count value of 2. This means, when it receives an EIGRP update
for the 7.47.100.1/32 from its EIGRP neighbor, since this update has a hop count value greater than 2, R4 is
rejecting the update. As a result, it does not inject a route to R1’s loopback.
One of the ways to solve this task would be modifying the hop count value on R4. The task however restricts
making any configuration changes on R1 or R4. So an alternative way to ensure R4 has a route back to R1’s
loopback address is to perform summarization on R5. Since the summary route in this case is generated at
R5, the hop count value in the EIGRP update for this route will be lower than 2 at R4 resulting in R4’s
installing a summary route.
Following configuration implements the above on R5. The ip summary-address eigrp 1 7.47.0.0 255.255.0.0
is configured on the G0/4 interface that connects R5 to R4:
On R5:
R5(config)#interface g0/4
R5(config-if)#ip summary-address eigrp 1 7.47.0.0 255.255.0.0
The result of the above configuration can be seen in R4’s routing table below where the summary route
7.47.0.0/16 is now present. R4 does not have a specific route for the 7.47.100.1/32 address, so it will use
the summary route to reach this address:
On R4:
R4#show ip route eigrp
| begin Gate
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 430
Gateway of last resort is not set
D
D
D
D
D
D
D
D
7.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
7.47.0.0/16 [90/2944000] via 7.47.45.5, 00:06:02, GigabitEthernet0/5
7.47.13.0/24 [90/3584000] via 7.47.46.6, 00:06:02, Tunnel46
7.47.35.0/24 [90/3584000] via 7.47.46.6, 00:06:02, Tunnel46
7.47.36.0/24 [90/3328000] via 7.47.46.6, 00:06:02, Tunnel46
7.47.100.3/32 [90/3456000] via 7.47.46.6, 00:06:02, Tunnel46
7.47.100.6/32 [90/2297856] via 7.47.46.6, 23:35:29, Tunnel46
19.0.0.0/24 is subnetted, 2 subnets
19.48.213.0 [90/3328000] via 7.47.45.5, 22:40:35, GigabitEthernet0/5
19.48.216.0 [90/3328000] via 7.47.46.6, 23:35:29, Tunnel46
A ping sourced from R1’s loopback 0 to R4’s loopback 0 address is once again issued to verify rechability and
as seen below, the ping succeeds.
On R1:
R1#ping 7.47.100.4 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.47.100.4, timeout is 2 seconds:
Packet sent with a source address of 7.47.100.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
Ticket 5
R3 is configured to use multiple paths to R4’s Lo0. However, it’s using only one of the paths.
The show ip route 7.47.100.4 command output from R3 below verifies the claim. R3 has a single path
installed to reach R4’s loopback address learned from R5:
On R3:
R3#show ip route 7.47.100.4
Routing entry for 7.47.100.4/32
Known via "eigrp 1", distance 90, metric 3200000, type internal
Redistributing via eigrp 1
Last update from 7.47.35.5 on GigabitEthernet0/5, 00:00:11 ago
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 431
Routing Descriptor Blocks:
* 7.47.35.5, from 7.47.35.5, 00:00:11 ago, via GigabitEthernet0/5
Route metric is 3200000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
To examine the cause, the show ip eigrp topology 7.47.100.4/32 command output is displayed below:
R3#show ip eigrp topology 7.47.100.4/32
EIGRP-IPv4 Topology Entry for AS(1)/ID(7.47.100.3) for 7.47.100.4/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3200000
Descriptor Blocks:
7.47.35.5 (GigabitEthernet0/5), from 7.47.35.5, Send flag is 0x0
Composite metric is (3200000/2944000), route is Internal
Vector metric:
Minimum bandwidth is 1000 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 7.47.100.4
7.47.36.6 (GigabitEthernet0/6), from 7.47.36.6, Send flag is 0x0
Composite metric is (3456000/2297856), route is Internal
Vector metric:
Minimum bandwidth is 1000 Kbit
Total delay is 35000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1476
Hop count is 2
Originating router is 7.47.100.4
R3’s EIGRP topology table shows two routes to reach R4’s loopback address, one via R5 and the other via R6.
R3 chooses the route through R5 as its successor route because it has a lower calculated distance (3200000)
compared to the route through R6 (3456000). R6’s path is kept as a feasible successor.
By default, routing protocols will only install equal paths into the same prefix into the routing table. Because
the routes from R5 and R6 are not equal, only one path is installed into the routing table. EIGRP, however,
possesses the ability to install unequal-cost paths into the routing table. EIGRP does this by evaluating
feasible successor routes that are only a certain degree worse than its current successor route to install into
the routing table. This is controlled with the variance command. For example, if configured with variance 2
command, EIGRP will install feasible successors with a calculated distance that is at most 2 times worse
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 432
(higher) than the current successor route. Applied to R3’s output above, EIGRP would allow a route with a
calculated distance equal to or less than 6400000 (3200000 x 2).
By default, the variance is set to 1 meaning feasible successors must have an equal calculated distance
compared to the successor route essentially enabling equal-cost multipath routing. To complete the task R3
needs to be configured with the variance 2 command in EIGRP router configuration mode as shown below:
On R3:
R3(config)#router eigrp 1
R3(config-router)#variance 2
The result of the above configuration can be seen in the routing table on R3. Notice R3 two unequal cost
paths to installed for R4’s loopback address:
R3#show ip route 7.47.100.4
Routing entry for 7.47.100.4/32
Known via "eigrp 1", distance 90, metric 3200000, type internal
Redistributing via eigrp 1
Last update from 7.47.35.5 on GigabitEthernet0/5, 00:01:45 ago
Routing Descriptor Blocks:
7.47.36.6, from 7.47.36.6, 00:01:45 ago, via GigabitEthernet0/6
Route metric is 3456000, traffic share count is 37
Total delay is 35000 microseconds, minimum bandwidth is 1000 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 2
* 7.47.35.5, from 7.47.35.5, 00:01:45 ago, via GigabitEthernet0/5
Route metric is 3200000, traffic share count is 40
Total delay is 25000 microseconds, minimum bandwidth is 1000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
Ticket 6
R6 can’t reach R7’s Lo101.
A ping to R7’a loopback address 57.73.21.21 is issued from R6. As the ticket states, the ping fails:
On R6:
R6#ping 57.73.21.21
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 433
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 57.73.21.21, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R6’s routing table below shows that is has no route to this address:
R6#show ip route 57.73.21.21
% Network not in table
R3 however does have rechability to the 57.73.21.21 address. This confirms that R7 is advertising its
loopback101 into EIGRP:
On R3:
R3#ping 57.73.21.21
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 57.73.21.21, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
The show ip protocol | include filter command on R6 is observed to check for any filtering. As seen, R6 is
not configured to perform any route filtering:
On R6:
R6#show ip protocol | include filter
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Since the lab restricts the checking of any configuration on R7, R3’s routing and EIGRP topology table
combined gives us some information about the 57.73.21.21 prefix. As seen below, R3 learns the 57.73.21.21
prefix from R7 as EIGRP external route. This means, R7 is redistributing this prefix into EIGRP:
On R3:
R3#show ip route 57.73.21.21
Routing entry for 57.73.0.0/16
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 434
Known via "eigrp 1", distance 170, metric 2560256256, type external
Redistributing via eigrp 1
Last update from 19.48.213.21 on GigabitEthernet0/7, 00:05:11 ago
Routing Descriptor Blocks:
* 19.48.213.21, from 19.48.213.21, 00:05:11 ago, via GigabitEthernet0/7
Route metric is 2560256256, traffic share count is 1
Total delay is 10010 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
Let’s check the topology table:
R3#show ip eigrp topology 57.73.0.0/16
EIGRP-IPv4 Topology Entry for AS(1)/ID(7.47.100.3) for 57.73.0.0/16
State is Passive, Query origin flag is 1, 0 Successor(s), FD is
Infinity
Descriptor Blocks:
19.48.213.21 (GigabitEthernet0/7), from 19.48.213.21, Send flag is 0x0
Composite metric is (2560256256/2560000256), route is External
Vector metric:
Minimum bandwidth is 1 Kbit
Total delay is 10010 microseconds
Reliability is 1/255
Load is 1/255
Minimum MTU is 1
Hop count is 1
Originating router is 7.47.100.6
External data:
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)
A key point however in the output above is the originating router ID of 7.47.100.6 for the prefix learned
from R7. This address exists on R6 and since the loopback interface is selected as the router ID, R6’s EIGRP
RID as seen below, is also 7.47.100.6:
On R6:
R6#show ip protocols | section eigrp
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
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 435
EIGRP-IPv4 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
Soft SIA disabled
NSF-aware route hold timer is 240
Router-ID: 7.47.100.6
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Duplicate RID can cause a problem with EIGRP external routes. An EIGRP router that receives an external
route where the RID of the originating router matches it’s own, it will not accept the route. Cisco logs
duplicate router IDs events and this can be seen with the show ip eigrp events command output below on
R6. R6 rejects the EIGRP updates for the 57.73.21.21 prefix since it sees its own RID in the originating router
field:
NOTE: Starting IOS 15 code, duplicate router-id will not only affect external routes, it will also affect internal
routes.
R6#show ip eigrp events | include 7.47.100.6
162
228
235
237
238
239
241
244
245
18:27:32.071 Ignored route, dup routerid int: 7.47.100.6
18:20:20.439 Ignored route, dup routerid int: 7.47.100.6
18:20:20.075 Ignored route, dup routerid int: 7.47.100.6
18:20:20.075 Ignored route, dup routerid int: 7.47.100.6
18:20:20.075 Poison squashed: 7.47.100.6/32 reverse
18:20:20.075 Ignored route, dup routerid int: 7.47.100.6
18:20:20.075 Ignored route, dup routerid int: 7.47.100.6
18:20:20.075 Ignored route, dup routerid ext: 7.47.100.6
18:20:20.075 Ignored route, dup routerid int: 7.47.100.6
The fix to this problem is easy. R6’s RID is changed to 6.6.6.6 with the eigrp router-id command as seen
below:
On R6:
R6(config)#router eigrp 1
R6(config-router)#eigrp router-id 6.6.6.6
You should see the following console messages:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.36.3 (GigabitEthernet0/3)
is down: route configuration changed
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 436
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.46.4 (Tunnel64) is down:
route configuration changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 19.48.216.21
(GigabitEthernet0/7) is down: route configuration changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.46.4 (Tunnel64) is up: new
adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 7.47.36.3 (GigabitEthernet0/3)
is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 19.48.216.21
(GigabitEthernet0/7) is up: new adjacency
The result of the above configuration changes can be seen on R6. R6 now has a route to R7’s lo101 address
and a ping to this address, verifies rechability:
On R6:
R6#show ip route 57.73.21.21
Routing entry for 57.73.0.0/16
Known via "eigrp 1", distance 170, metric 2560256256, type external
Redistributing via eigrp 1
Last update from 19.48.216.21 on GigabitEthernet0/7, 00:01:44 ago
Routing Descriptor Blocks:
* 19.48.216.21, from 19.48.216.21, 00:01:44 ago, via GigabitEthernet0/7
Route metric is 2560256256, traffic share count is 1
Total delay is 10010 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
R6#ping 57.73.21.21
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 57.73.21.21, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Ticket 7
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 437
R3 should establish a EIGRP adjacency with R8 over its G0/8 interface. You should make
configuration changes on R3 only.
In order to complete this ticket there needs to be an EIGRP neighbor adjacency between R3 and R8. For
EIGRP-speaking routers to become neighbors, the two routers must be in the same AS and have the same K
values. The only issue is the current configuration on R8 is unknown so it cannot be matched in R3’s
configuration. One way to discover the AS number and K value settings is to examine the EIGRP hello packet
that R8 is multicasting onto the link. IOS routers can print out a packet dump using a hidden keyword in the
debug ip packet command: the dump keyword.
Before configuring the debug, R3 is configured to run EIGRP AS 100 with R8. If R8 forms an adjacency, then
the task can be concluded here. If no adjacency is created then the process to use the debug command will
be continued.
On R3:
R3(config-router)#router eigrp 100
R3(config-router)#network 38.1.1.3 0.0.0.0
After configuring R3 to run EIGRP, no adjacency has been established with R8. This means there is a
mismatch with either the AS number or K values between R3 and R8. To continue the debug process, an
access-list will be created. This access-list’s goal is to filter the debug ip packet detail to only capture EIGRP
packets multicast by R8. The access-list matches EIGRP packets (IP protocol 88), using the eigrp keyword,
sent to the destination 224.0.0.10 from the host 38.1.1.8 (R8). The following is the access-list configuration:
R3(config)#access-list 100 permit eigrp host 38.1.1.8 host 224.0.0.10
Finally, the debug ip packet detail 100 dump command is issued to start the debugging process. Notice the
“100” in the command. This is a reference to access-list 100 created above that limits the debugged packets
to only those that match the ACL. The dump keyword prints the actual hex-dump of the IP packet. The
following debug output and commands used are detailed in the below:
R3#debug ip packet detail 100 dump
IP packet debugging is on (detailed) (dump) for access list 100
IP: s=38.1.1.8 (GigabitEthernet0/8), d=224.0.0.10, len 60, rcvd 0,
proto=88
08DFB980:
0100 5E00000A
..^...
08DFB990: 50000008 00030800 45C0003C 01090000 P.......E@.<....
08DFB9A0: 0158B08E 26010108 E000000A 0205E6AC .X0.&...`.....f,
08DFB9B0: 00000000 00000000 00000000 00000026 ...............&
08DFB9C0: 0001000C 01000000 0000000F 00040008 ................
08DFB9D0: 14000200
....
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 438
To disable the debug:
R3#undebug all
All possible debugging has been turned off
The debug output above may look intimidating at first, but with a little explanation it can be deciphered. The
first step to understanding the dump is how it’s represented. The debug output first lists the basic details of
the IP header of the packet that was received. This isn’t the raw packet information, but only an
interpretation of what the raw bits of the packet equals. The actual packet dump begins on the first line
underneath the IP header. Keep in mind the term “octet” here refers to 8 bits of binary digits. A binary octet
is equal to two hexadecimal digits. This is because a single hexadecimal digit represents 4 binary digits.
Interpreting this output requires an in-depth understanding of the basic packet format for an ethernet
header, IP header, and EIGRP hello packet. The following provides a basic guide to reading the output.
In the first line after the IP header the “08DFB980:” is a counter for the number of octets of bits represented
in each line of output. This number is a hexadecimal number. In this case, the router is printing 16 octets
worth of bits in each line (128 bits in total). Everything to the right of the colon (:) is the actual raw packet
data written in hex and organized into 4-octet chunks.
In this case, the actual packet captured begins in the last 10 octets of the first line. This is the raw packet
output for the ethernet header of the packet. Without going into too much detail, the ethernet header of
this packet is 14 octets in total, highlighted below:
IP: s=38.1.1.8 (GigabitEthernet0/8), d=224.0.0.10, len 60, rcvd 0,
proto=88
08DFB980:
0100 5E00000A
..^...
08DFB990: 50000008 00030800 45C0003C 01090000 P.......E@.<....
08DFB9A0: 0158B08E 26010108 E000000A 0205E6AC .X0.&...`.....f,
08DFB9B0: 00000000 00000000 00000000 00000026 ...............&
08DFB9C0: 0001000C 01000000 0000000F 00040008 ................
08DFB9D0: 14000200
....
The 14 bits highlighted above include the destination and source MAC address, and the Type field. The type
field can be easily identified as the “0800” value highlighted in red above. This is an indication that the next
string of bits indicates an IP packet.
Knowing an IP packet is represented by the next set of bits allows us to cheat a bit. All we need to know is
how long the IP header length is going to be. Every IP packet contains a header length field that indicates
just this information. It is located as the last 4 bits of the first octet of the IP packet. In this case it is listed as
“5” as highlighted below:
IP: s=38.1.1.8 (GigabitEthernet0/8), d=224.0.0.10, len 60, rcvd 0,
proto=88
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 439
08DFB980:
0100 5E00000A
08DFB990: 50000008 00030800 45C0003C 01090000
08DFB9A0: 0158B08E 26010108 E000000A 0205E6AC
08DFB9B0: 00000000 00000000 00000000 00000026
08DFB9C0: 0001000C 01000000 0000000F 00040008
08DFB9D0: 14000200
..^...
P.......E@.<....
.X0.&...`.....f,
...............&
................
....
This five indicates that the IP header will be five 32-byte words long. A 32-byte word is equal to 4 octets (8
divided by 32 equals 4). This means the entire IP header will be 5 x 4 octets long or 20 octets in total. If we
count 20 octets from the beginning of the IP header (starting at hex value 4) we can find where the next
header in the dump exists as highlighted below:
IP: s=38.1.1.8 (GigabitEthernet0/8), d=224.0.0.10, len 60, rcvd 0,
proto=88
08DFB980:
0100 5E00000A
..^...
08DFB990: 50000008 00030800 45C0003C 01090000 P.......E@.<....
08DFB9A0: 0158B08E 26010108 E000000A 0205E6AC .X0.&...`.....f,
08DFB9B0: 00000000 00000000 00000000 00000026 ...............&
08DFB9C0: 0001000C 01000000 0000000F 00040008 ................
08DFB9D0: 14000200
We have successfully bypassed both the ethernet and IP headers. The next header would be the transport
header. Since we know we have been capturing only EIGRP packets (based on the access-list configured
previously), we know the next packet is an EIGRP packet. This is because EIGRP does not use a transport
protocol such as UDP or TCP to transmit its protocol packets. It provides its own transport mechanism for
delivery. All that is needed now is an understanding of an EIGRP packet. The EIGRP packet contents are
highlighted below:
IP: s=38.1.1.8 (GigabitEthernet0/8), d=224.0.0.10, len 60, rcvd 0,
proto=88
08DFB980:
0100 5E00000A
..^...
08DFB990: 50000008 00030800 45C0003C 01090000 P.......E@.<....
08DFB9A0: 0158B08E 26010108 E000000A 0205E6AC .X0.&...`.....f,
08DFB9B0: 00000000 00000000 00000000 00000026 ...............&
08DFB9C0: 0001000C 01000000 0000000F 00040008 ................
08DFB9D0: 14000200
The 4 and a half octets in red above represent the EIGRP version, Opcode, Checksum, Flags, Sequence
Number, Acknowledgement Number, and virtual router ID (address family). The yellow highlighted part of
the dump indicates the EIGRP AS number. value of “0026”. Converting this number from hexadecimal into
binary gives the value of 38. This is the AS number R8 is configured to use. Proceeding through the blue
(which indicates a type of parameters and length of 12 of the EIGRP K value TLV) leads to the actual K value
settings. Each K-value is represented by a 1 octet number. In this case K1 = 1, K2 = 0, K3 = 0, K4 = 0, K5 = 0.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 440
This is an indication that all metric values are disabled except the first K value.
Now we have all of the information we need to fix the neighborship between R3 and R8.
First, EIGRP AS 100 is removed from R3. Then, EIGRP 38 is configured. The metric weights are then modified
using the metric weight 0 1 0 0 0 0 command in router EIGRP configuration mode. Finally, EIGRP is activated
on the R3/R8 link using the network 38.1.1.3 0.0.0.0 command. The console message verifies the EIGRP
neighborship has successfully come up.
R3(config)#no router eigrp 100
R3(config)#router eigrp 38
R3(config-router)#metric weight 0 1 0 0 0 0
R3(config-router)#netw 38.1.1.3 0.0.0.0
You should see the following console message:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 38: Neighbor 38.1.1.8 (GigabitEthernet0/8)
is up: new adjacency
Ticket 8
Erase the startup configuration and reload the devices before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2020 Narbik Kocharians. All rights reserved
Page 441
Chapter 5
CCIE
Enterprise Infrastructure
Foundation
v1.0
www.MicronicsTraining.com
Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP
OSPF
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 442
Lab 1
Running OSPF on the Interfaces
This lab should be conducted on the Enterprise POD.
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
OSPF folder  Lab-1.
Task 1
Configure OSPF Area 0 on all directly connected interfaces in the previous topology,
including the secondary IP addresses.




Do not use the network command to accomplish this task.
The loopback interfaces should be advertised with their correct mask.
If this configuration is performed successfully, each router will have reachability to
all routes within the previous topology.
The OSPF RID should be configured based on the Lo0 interface of these three routers.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 443
This task focuses on basic OSPF neighbor configuration and how OSPF advertises prefixes attached to
interfaces.
The task first specifies that all routers participate in OSPF and belong to area 0. They should be configured
to advertise their directly connected interface IP addresses into OSPF, including the secondary IP addresses
configured on R2 and R3.
OSPF can be enabled on an interface using one of the two methods:
1. Using the network ip-address wildcard-mask area area-id command under the OSPF router
configuration. The command also includes assigning the interfaces covered with the network range
to a specified area, with the area keyword
2. Directly on the interface with the ip ospf process-id area area-id [ secondaries none ] command
The first configuration style utilizes the familiar network address wildcard area area-number command. It uses an address/wildcard-mask
configuration to specify a range of IP addresses OSPF should advertise. Any interface that falls within the range specified by the network
command will be enabled to run the configured OSPF process and the IP prefix assigned to that interface will be advertised into OSPF. The
command also specifies to what area the matching IP address and interface is associated. OSPF design utilizes the concept of areas to
define regions of the network where topology information is synchronized.
The second configuration style directly configures the interface to participate in a specific OSPF process number and area. This
configuration style will automatically create the indicated OSPF process and assign the interface to the indicated area. It also automatically
advertises all IP addresses associated with the interface into the configured OSPF process and area.
When configuring OSPF using either of the two methods above some things need to be noted:
1. When configured using the interface-level configuration style, secondary addresses are
automatically advertised into OSPF.
2. When configured using the network command configuration style, secondary addresses must be
matched by a network command statement that includes the secondary IP address of the interface
in its address/wildcard mask combination. Also, if an interface is only matched by a network
command matching its secondary IP address, OSPF will not be enabled on that interface.
Breaking down the two points above, when configured using interface-level configuration, the router pretty
much takes care of everything. It creates the OSPF process and adds all IP addresses, including secondary
addresses, to be advertised into OSPF in the indicated area. OSPF is enabled on the interface and will begin
discovering OSPF neighbors, if any exist, connected to that interface.
The network command is more selective. It will only advertise the networks explicitly matched into OSPF. If
the goal is to advertise both the primary and secondary interfaces into OSPF then the network statement
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 444
utilized should include both addresses or separate network command statements for each address is
required. In addition, if only an interface’s secondary IP address is matched by a network command, that
interface is not added into the OSPF process nor is the secondary IP address advertised into the OSPF
domain.
To complete the first requirement of the task, OSPF needs to be enabled on all routers. Every interface on
the router should be configured to be in area 0 and all secondary addresses should be advertised as well.
The task explicitly forbids the use of the network command, leaving the interface-level configuration style
as the only other option. The following configuration enables OSPF for all directly connected and loopback 0
interfaces on R1, R2, and R3:
On R1:
R1(config)#interface g0/2
R1(config-if)#ip ospf 1 area 0
R1(config)#interface lo0
R1(config-if)#ip ospf 1 area 0
On R2:
R2(config)#interface lo0
R2(config-if)#ip ospf network point-to-point
R2(config-if)#ip ospf 1 area 0
R2(config)#interface g0/1
R2(config-if)#ip ospf 1 area 0
R2(config)#interface g0/3
R2(config-if)#ip ospf 1 area 0
R2(config)#router ospf 1
R2(config-router)#router-id 2.2.2.2
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/1
LOADING to FULL, Loading Done
from
On R3:
R3(config)#interface lo0
R3(config-if)#ip ospf 1 area 0
R3(config-if)#ip ospf network point-to-point
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 445
R3(config)#interface g0/2
R3(config-if)#ip ospf 1 area 0
R3(config)#router ospf 1
R3(config-router)#router-id 3.3.3.3
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/2
LOADING to FULL, Loading Done
from
NOTE: It may take around 40 seconds for the UP notification to be displayed.
To verify the configuration:
The show ip ospf interface brief command output can then be used to verify the interfaces enabled for OSPF:
On R1:
R1#show ip ospf interface brief
Interface
Lo0
Gi0/2
PID
1
1
Area
0
0
IP Address/Mask
1.1.1.1/8
12.1.1.1/24
Cost
1
1
State Nbrs F/C
P2P
0/0
DR
0/0
IP Address/Mask
2.2.2.2/8
23.1.1.2/24
12.1.1.2/24
Cost
1
1
1
State Nbrs F/C
LOOP 0/0
DR
0/0
BDR
1/1
IP Address/Mask
3.3.3.3/8
23.1.1.3/24
Cost
1
1
State Nbrs F/C
LOOP 0/0
BDR
1/1
On R2:
R2#show ip ospf interface brief
Interface
Lo0
Gi0/3
Gi0/1
PID
1
1
1
Area
0
0
0
On R3:
R3#show ip ospf interface brief
Interface
Lo0
Gi0/2
PID
1
1
Area
0
0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 446
The show ip route ospf | begin Gate command on R1, R2 and R3 confirms which OSPF routes the routers
have installed into their routing tables:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
O
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [110/2] via 12.1.1.2, 00:05:28, GigabitEthernet0/2
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [110/3] via 12.1.1.2, 00:02:01, GigabitEthernet0/2
10.0.0.0/24 is subnetted, 2 subnets
10.2.2.0 [110/2] via 12.1.1.2, 00:05:38, GigabitEthernet0/2
10.3.3.0 [110/3] via 12.1.1.2, 00:02:01, GigabitEthernet0/2
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/2] via 12.1.1.2, 00:05:38, GigabitEthernet0/2
On R2:
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [110/2] via 12.1.1.1, 00:13:17, GigabitEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [110/2] via 23.1.1.3, 00:09:35, GigabitEthernet0/3
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
10.3.3.0/24 [110/2] via 23.1.1.3, 00:09:35, GigabitEthernet0/3
On R3:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [110/3] via 23.1.1.2, 02:34:05, GigabitEthernet0/2
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [110/2] via 23.1.1.2, 02:34:05, GigabitEthernet0/2
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
10.2.2.0/24 [110/2] via 23.1.1.2, 02:34:05, GigabitEthernet0/2
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/2] via 23.1.1.2, 02:34:05, GigabitEthernet0/2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 447
Observing the routing tables above, we notice that secondary IP addresses configured on R2’s G0/3
interface and the G0/2 interface on R3 are also advertised into OSPF. This is a direct result of the interfacelevel ip ospf process area area-id command configuration as mentioned earlier.
The show ip ospf database router self-originate command output can be used to check the router LSAs
generated by a router. This command lists the Type-1 router LSA that describes an individual router and its
attached interfaces that are enabled for OSPF. Each interface is described as a link in the OSPF database and
is given a metric value. These links are identified as being connected to one of the following type of
networks:
1. Point-to-point
2. Transit
3. Stub
Point-to-point networks indicate a link that is connected to a single OSPF-speaking device. Transit networks
are networks that can carry traffic that was not locally generated or destined and contain many OSPFspeaking devices. Finally, a stub network indicates a network where there are no other OSPF-speaking
devices and only traffic destined to or from the network will flow over the link to that network.
The metric value in OSPF can be manually set on a per-interface basis or precalculated by IOS. By default,
IOS will use a reference bandwidth value that defaults as 100,000Kbps which equals a 100Mbps
FastEthernet connection. Interface cost values are reported as ratios of this bandwidth using the following
formula:
reference-bandwidth/interface-bandwidth.
The following is an example of the router LSA generated by R2 and R3:
On R2:
R2#show ip ospf database router self-originate
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 0)
LS age: 1283
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 8000000A
Checksum: 0x4735
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 448
Length: 72
Number of Links: 4
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.2.2.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 23.1.1.2
(Link Data) Router Interface address: 23.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.2.2.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 12.1.1.1
(Link Data) Router Interface address: 12.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1
On R3:
R3#show ip ospf database router self-originate
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
LS age: 1460
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: 80000007
Checksum: 0x3A65
Length: 60
Number of Links: 3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 449
Link connected to: a Stub Network
(Link ID) Network/subnet number: 3.3.3.3
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 23.1.1.2
(Link Data) Router Interface address: 23.1.1.3
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.3.3.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
The output above lists an array of links connecting to different types of networks. Most notably, highlighted
ingreen, is OSPF’s interpretation of the link connecting to the secondary IP address of R2’s G0/3 interface. It
is described as being connected to a stub interface. In OSPF, stub networks are typically used to describe IP
addresses assigned to point-to-point and loopback interfaces. This allows OSPF to solve the SPF algorithm
required to reach the network.
Next, highlighted is the metric assigned to each link. This number was automatically assigned to the link
based on the IOS default OSPF bandwidth calculation. The calculation takes the reference bandwidth of
100,000Kbps (100Mbps) and divides it by the interface bandwidth of, for example, R2’s G0/3 interface,
which is 1,000,000 Kbps (1,000Mbps or 1Gbps) as seen below:
On R2:
R2#show interface g0/3 | include BW
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
The result is 100,000/1,000,000 which equals 0.1. OSPF rounds this fraction to 1 which is the value seen as
the metric value for the links.
Also, highlighted is the OSPF router ID configured on R2 and R3. Router IDs are a 32-bit number that
uniquely identify the device running OSPF. By default, router-ID on a device is selected in the following
manner:
1. Manually configured router-id with the router-id command.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 450
2. If no manual configuration exists, then, select the highest IP address of an active loopback interface.
3. If no loopback exists, then, select the highest IP address of an active physical interface
This task requires that R1, R2 and R3 use the IP address assigned to their loopback 0 interfaces as the OSPF
router IDs. As seen in the output above, these loopback interfaces are already being used as the OSPF router
IDs, since they are the only loopbacks configured on these devices. However, should another loopback
interface be configured with a higher IP address followed by a restart of the OSPF process, the router ID
would change to a different loopback address. To ensure the IP assigned to the loopback 0 address is always
used as the router-id, the router-id command under the OSPF router configuration mode is used to
manually assign the router IDs. The configuration for this is seen below on R1, R2 and R3:
On R1:
R1(config)#router ospf 1
R1(config-router)#router-id 1.1.1.1
On R2:
R2(config)#router ospf 1
R2(config-router)#router-id 2.2.2.2
On R3:
R3(config)#router ospf 1
R3(config-router)#router-id 3.3.3.3
Note: Since the manually set router IDs above match the existing router ID on the routers, IOS does not
require the OSPF process to be restarted. If the manually set router ID did not match the existing router
ID, IOS would prompt to restart the OSPF process for the new router ID to take effect.
On the subject of loopback interfaces, the task makes special mention that all loopbacks enabled for OSPF
should be advertised with their actual masks. The show run interface loopback 0 command output shows a
/8 mask used for the loopback 0 addresses on R1, R2 and R3
On R1:
R1#show run interface lo0 | begin interface
interface Loopback0
ip address 1.1.1.1 255.0.0.0
ip ospf 1 area 0
On R2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 451
R2#show run interface lo0 | begin interface
interface Loopback0
ip address 2.2.2.2 255.0.0.0
ip ospf 1 area 0
On R3:
R3#show run int lo0 | begin interface
interface Loopback0
ip address 3.3.3.3 255.0.0.0
ip ospf 1 area 0
The router LSAs on each router tell a different story as shown in the below:
On R1:
R1#show ip ospf database router self-originate | section Stub
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
On R2:
R2#show ip ospf database router self-originate | section Stub
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.2.2.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
(The rest of the output is omitted for brevity)
On R3:
R3#show ip ospf database router self-originate | section Stub
Link connected to: a Stub Network
(Link ID) Network/subnet number: 3.3.3.3
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 452
TOS 0 Metrics: 1
(The rest of the output is omitted for brevity)
The highlighted portion of the output points out the fact that each router is advertising its loopback 0
interface into OSPF with /32 mask. The reason for this is the OSPF network type assigned by default to the
loopback interfaces is loopback. According to the OSPF RFC (2328) loopback interfaces should be advertised
as /32 host routes because they represent addresses attached to interfaces that are physically looped back
to the device in hardware or logically looped back to the device in software. Since the interface is looped
back, traffic will not be transited to such addresses but reachability to the address may be needed to
perform testing. Because of this, these interfaces are considered to be stub interfaces much like the
secondary addresses described above and are advertised as /32 host routes.
Following excerpt from RFC 2328, section 9.1 highlights the above:
In this state, the router's interface to the network is looped back.
back in hardware or software.
The interface may be looped
The interface will be unavailable for data traffic.
However, it
may still be desirable to gain information on the quality of this interface, either through
sending ICMP pings to the interface or through something like a bit error test.
IP packets may still be addressed to an interface in Loopback state.
For this reason,
To facilitate this, such
interfaces are advertised in router-LSAs as single host routes, whose destination is the IP
interface address.[4]
The default behavior can be changed. To allow OSPF to advertise the IP addresses on the loopback interface
with their actual mask, the network type on the loopback interface needs to be changed to be point-topoint with the ip ospf network point-to-point command under the loopback interface. The following
configures this on R1, R2 and R3:
On R1, R2, and R3:
Rx(config)#interface lo0
Rx(config-if)#ip ospf network point-to-point
The self generated router LSA is observed again on each router.. Notice the difference from the earlier
output. The router LSAs on each device now show the loopback interfaces with the true network mask of /8:
On R1:
R1#show ip ospf database router self-originate | section Stub
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.0.0.0
(Link Data) Network Mask: 255.0.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 453
Number of MTID metrics: 0
TOS 0 Metrics: 1
On R2:
R2#show ip ospf database router self-originate | section Stub
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
(The rest of the output is omitted for brevity)
On R3:
R3#show ip ospf database router self-originate | section Stub
Link connected to: a Stub Network
(Link ID) Network/subnet number: 3.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
(The rest of the output is omitted for brevity)
The show ip route ospf command on R1, R2 and R3 also verify the above configuration changes. All
routers install routes to each others loopback 0 interfaces with a mask of /8:
On R1:
R1#show ip route ospf | include /8
O
O
2.0.0.0/8 [110/2] via 12.1.1.2, 00:00:21, GigabitEthernet0/2
3.0.0.0/8 [110/3] via 12.1.1.2, 00:00:04, GigabitEthernet0/2
On R2:
R2#show ip route ospf | include /8
O
O
1.0.0.0/8 [110/2] via 12.1.1.1, 00:01:35, GigabitEthernet0/1
3.0.0.0/8 [110/2] via 23.1.1.3, 00:01:06, GigabitEthernet0/3
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
On R3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 454
R3#show ip route ospf | include /8
O
O
1.0.0.0/8 [110/3] via 23.1.1.2, 00:02:35, GigabitEthernet0/2
2.0.0.0/8 [110/2] via 23.1.1.2, 00:02:23, GigabitEthernet0/2
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
A hidden command in IOS shows what is known as the OSPF private routing table containing all routes
calculated by OSPF. This command is the show ip ospf route. Below is output of this command from R1’s
perspective:
On R1:
R1#show ip ospf route
OSPF Router with ID (1.1.1.1) (Process ID 1)
Base Topology (MTID 0)
Area BACKBONE(0)
Intra-area Route List
*
*>
*
*>
*>
*>
*>
12.1.1.0/24, Intra, cost 1, area 0, Connected
via 12.1.1.1, GigabitEthernet0/2
23.1.1.0/24, Intra, cost 2, area 0
via 12.1.1.2, GigabitEthernet0/2
1.0.0.0/8, Intra, cost 1, area 0, Connected
via 1.1.1.1, Loopback0
2.0.0.0/8, Intra, cost 2, area 0
via 12.1.1.2, GigabitEthernet0/2
3.0.0.0/8, Intra, cost 3, area 0
via 12.1.1.2, GigabitEthernet0/2
10.2.2.0/24, Intra, cost 2, area 0
via 12.1.1.2, GigabitEthernet0/2
10.3.3.0/24, Intra, cost 3, area 0
via 12.1.1.2, GigabitEthernet0/2
First Hop Forwarding Gateway Tree
12.1.1.1 on GigabitEthernet0/2, count 1
12.1.1.2 on GigabitEthernet0/2, count 5
1.1.1.1 on Loopback0, count 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 455
The output lists a concise view of all routes calculated by OSPF that will be submitted to the routing table as
OSPF-learned routes. It provides information of the area in which the route was calculated, the OSPF cost to
the route, and whether the route is an intra-area, inter-area, or external route. The output uses a BGP-like
identification system where “*” indicates the best route and a “>” indicates that route has been
installed into the global RIB on the router.. In R1’s case, the directly-connected routes calculated by OSPF
have not been added to its global RIB. This is because the global RIB on R1 will hold them as directly
connected routes and OSPF learned routes.
The show ip ospf route output is helpful when determining if a synchronization problem exists between the
global RIB and the OSPF process’ calculated routes.
Task 2
Configure R2 and R3 such that the secondary IP addresses are not advertised into OSPF.



Do not use filtering, a route map, an access list, or a prefix list.
Do not remove any commands.
Use a minimum number of commands to accomplish this task.
As mentioned in task 1, enabling OSPF on an interface with the interface-level command ip ospf process-id
area area-id command will cause the router to automatically advertise the primary IP address and any
secondary IP address configured on that interface into OSPF.
The task amends the previous task where secondary addresses were allowed to be advertised. Instead, R2
and R3 should not advertise the secondary addresses assigned to their G0/3 and G0/2 interfaces
respectively, into OSPF. These networks are the 10.2.2.0/24 and 10.3.3.0/24 addresses configured on each
interface.
There are two ways this task can be completed:
1. Remove the interface-level command and only match the primary IP address of each interface on R2
and R3 with a network command in OSPF router configuration mode
2. Modify the existing interface-level command to exclude secondary IP addresses from being
advertised by default.
The task explicitly forbids removing commands from the configuration, this rules out the first option of
configuration. What remains is to modify the existing interface-level command to exclude the secondary
addresses from being advertised into OSPF. This is achieved by using the secondaries none keyword option
with the ip ospf command under the interface as seen below:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 456
On R2:
R2(config)#interface g0/3
R2(config-if)#ip ospf 1 area 0 secondaries none
On R3:
R3(config)#interface g0/2
R3(config-if)#ip ospf 1 area 0 secondaries none
Once configured, the R2 and R3 will no longer advertise the secondary networks into OSPF. Observing the
router LSAs on R2 and R3 confirms the two routers are no longer advertising those secondary addresses as
directly connected links:
On R2:
R2#show ip ospf database router self-originate
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 0)
LS age: 1017
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 8000000D
Checksum: 0x3945
Length: 72
Number of Links: 4
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 23.1.1.2
(Link Data) Router Interface address: 23.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 457
Link connected to: a Transit Network
(Link ID) Designated Router address: 12.1.1.2
(Link Data) Router Interface address: 12.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1
On R3:
R3#show ip ospf database router self-originate
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
LS age: 115
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: 8000002D
Checksum: 0xE3BF
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 3.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 23.1.1.2
(Link Data) Router Interface address: 23.1.1.3
Number of MTID metrics: 0
TOS 0 Metrics: 1
In contrast to the same output from task 1, notice the missing entry for the secondary IP addresses in the
router LSAs on R2 and R3 above.
Note: The hidden command show ip ospf route can also be quickly referenced to verify the same
A final verification is done on R1 with the show ip route ospf command. Notice R1 has no entry in its routing
table for the secondary prefixes on R2 and R3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 458
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
2.0.0.0/8 [110/2] via 12.1.1.2, 00:22:07, GigabitEthernet0/2
3.0.0.0/8 [110/3] via 12.1.1.2, 00:19:06, GigabitEthernet0/2
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/2] via 12.1.1.2, 00:21:29, GigabitEthernet0/2
Task 3
R3 is getting flooded with LSA Type 6 packets. Ensure that R3 does not generate a syslog
message for this LSA type.
The original OSPFv2 specification in RFC 1583 was extended to include extensions for advertising
multicast information. These extensions were defined in RFC 1584 the Multicast Extensions to OSPF and
further elaborated upon in RFC 1585 MOSPF: Analysis and Experience. These two RFCs outlined a way
by which multicast destination information can be shared using a new LSA type for that time the Type 6
LSA.
Some networking vendors support the RFC 1584 Multicast Extensions to OSPF. Network devices
manufactured by these vendors can be configured to send and receive Type-6 LSAs. Cisco routers,
however, do not support these LSAs. As a result, whenever a router configured for OSPF receives Type 6
LSA packets, it generates a number of syslog messages indicating the LSA type was received and is not
supported. Depending on the size of the network and the number of active multicast groups, logging this
syslog message can be CPU intensive for the router. In such cases it is best if the router silently discards
the Type-6 LSA without logging a message.
This task deals with this very subject. Its goal is to prevent R3 from generating syslog messages whenever a
Type-6 LSA is received. The router can be configured to ignore the Type 6 LSAs, using the command ignore
lsa mospf under the OSPF router configuration mode as seen below on R3:
On R3:
R3(config)#router ospf 1
R3(config-router)#ignore lsa mospf
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 459
An interesting fact about this command. The context-sensitive help for the ignore command actually lists
the lsa keyword as having the effect of “do not complain upon receiving LSA of the specified type” as seen
below:
R3(config)#router ospf 1
R3(config-router)#ignore ?
lsa Do not complain upon receiving LSA of the specified type
This is a further indication of the router’s default behavior to alert (or complain) about receiving the
unsupported Type-6 LSA.
Task 4
To ensure fast detection of a neighbor being down, configure R2 and R3 to send their
hellos every 250 milliseconds with a hold time of 1 second for their Ethernet link.
OSPF hello packets are sent between routers to allow the routers to discover each other and form
adjacencies. Once the adjacencies have been formed, routers keep transmitting hello packets on the link
every hello interval time. These hellos work as a heartbeat that announces the operational status of a
router.
If an OSPF router does not receive a hello packet from one of its neighbors for a period of time, called the
dead interval timer, the router declares its neighbor dead and tears down the adjacency with that neighbor.
The default hello timer for broadcast and point-to-point links is 10 seconds (for NBMA, the default is 30
seconds). The dead timer on these same links is set to be four times the hello interval. Once a periodic hello
packet is received from the neighbor, the router resets the dead interval to its maximum value.
In order to ensure all routers comply by the same hello and dead interval settings, these timers must match
between two OSPF-speaking routers in order for them to become neighbors. The current hello and dead
timer values can be observed in the show ip ospf interface command output. The example output below
shows these default values on R2’s link G0/3 that connects to R3:
On R2:
R2#show ip ospf interface g0/3 | include Hello
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 460
The default dead interval means that the local router will tear down adjacencies with OSPF neighbors if it
does not receive four consecutive hello packets from that neighbor. The result of these settings equates to
a maximum dead timer of 40 seconds on broadcast and point-to-point links.
The hello and dead timers can be manually set on a per-interface basis using the ip ospf hello-interval and
ip ospf dead-interval interface-level commands. These commands are applied as follows:
● If the ip ospf hello-interval is set without manually setting a dead interval, the dead interval is
automatically set to 4 times the hello period
● Any interface-level configuration of ip ospf dead-interval command will take precedence even if the
hello interval is changed at a later time
● The dead interval can be reset to defaults (4 times the hello interval) using the no version of the
command.
The list above basically means that when configuring the OSPF hello interval on an interface using the ip
ospf hello-interval command, the dead-interval is automatically set to be 4 times this value. This automatic
change is only affected if no manual ip ospf dead-interval setting has been applied to the interface. If a
dead interval has been specified, that configuration will be applied to the interface. Using the no form of
the ip ospf dead-interval command on the interface returns the dead interval to the default settings.
The task lays out requirements for sending and receiving hello packets between R2 and R3. It specifies that
hellos should be sent every 250ms with a 1 second dead interval. Looking at the configuration options for
setting these timers reveals a bit of a problem:
R2(config-if)#ip ospf hello-interval ?
<1-65535> Seconds
R2(config-if)#ip ospf dead-interval ?
<1-65535> Seconds
minimal
Set to 1 second
Both hello and dead interval configurations are limited to 1 second defaults. It appears as though there is no
way to set a sub-second hello interval as the task desires.
The answer to solving the task lies in the OSPF fast hello feature. The fast hello feature allows the
administrator to set sub-second hello timers. When configured, the OSPF fast hello feature first sets the
dead interval to 1 second. The hello interval is then specified in how many hellos should be sent within that
one second period. This value is called a multiplier value. In other words, if the fast hello feature is
configured to send 2 hellos within one second, the hellos will be sent every 500ms. The math works as
follows.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 461
A second is made up of 1000ms. With a hello multiplier value of 2, the router should send 2 hello packets at
an even interval within that time period. The router divides 1000ms by 2 to reach a 500ms hello time
interval.
To solve the task, the hello interval should be set to 250ms. To figure out the proper multiplier value,
1000ms is divided by 250ms to equal a value of 4. This means the multiplier value used for the OSPF fast
hello feature should be 4.
Being able to perform that calculation is important as the configuration for OSPF fast hello is through the ip
ospf dead-interval minimal hello-multiplier multiplier command. In this command, the hello multiplier
value is used to calculate the resultant hello interval. In case of R2 and R3, the ip ospf dead-interval
minimal hello-multiplier 4 command should be configured the g0/3 and g0/2 on R2 and R3 respectively as
in the below:
R2(config)#interface g0/3
R2(config-if)#ip ospf dead-interval minimal hello-multiplier 4
On R3:
R3(config)#interface g0/2
R3(config-if)#ip ospf dead-interval minimal hello-multiplier 4
To verify the configuration:
Following the above configurations, the show ip ospf interface command output from R2 and R3 reflect the new
timers:
On R3:
R3#show ip ospf interface g0/2 | include Hello
Timer intervals configured, Hello 250 msec, Dead 1, Wait 1, Retransmit 5
Hello due in 18 msec
Task 5
Ensure that these routers look up DNS names for use in most of the OSPF show commands.
Test this task to ensure proper operation. Since there are no DNS servers in this
lab, you should use the local routers for DNS lookups.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 462
To understand this task, let’s first observe the show ip ospf database router command output from R1.
Output from this command has been truncated to remove R1’s self originated Type-1 router LSAs. The
output below shows the router LSAs advertised by R2 and R3 as indicated in the Advertising Router
field:
On R1:
R1#show ip ospf database router | include Advert
Advertising Router: 1.1.1.1
Advertising Router: 2.2.2.2
Advertising Router: 3.3.3.3
The advertising router field for the Type 1 router LSAs is the router ID of the router that generated that
router LSA. As seen above, the advertising router field for R2 and R3’s LSA shows their RID 2.2.2.2 and
3.3.3.3. OSPF can be configured to perform a DNS lookup to display a more easily identifiable name instead
of the router ID in OSPF show EXEC command outputs.
DNS lookup can be performed against a stand-alone DNS server, another IOS device that is acting as a DNS
server, or from the router’s own local name-to-IP mapping table configured using the ip host command in
global configuration mode. The task specifically states that the local router should be used to perform the
resolution. Thus, to complete the task, the ip host command is configured mapping the friendly name “Rx”
(where “x” is the router number) to the proper router-id. For example, R1’s name is mapped to 1.1.1.1 using
the command ip host R1 1.1.1.1. This configuration is repeated on all routers for all resolutions as follows:
On R1, R2 and R3:
Rx(config)#ip host R1 1.1.1.1
Rx(config)#ip host R2 2.2.2.2
Rx(config)#ip host R3 3.3.3.3
After configuring the manual lookup entries, the OSPF process is enabled to perform DNS lookup using the
ip ospf name-lookup command in global configuration mode:
Rx(config)#ip ospf name-lookup
To verify the configuration:
On R1:
R1#show ip ospf database router | include Advert
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 463
Advertising Router: R1
Advertising Router: R2
Advertising Router: R3
Note: The DNS lookup is performed for all OSPF show EXEC command output. As an example, the show ip
ospf neighbor command which will display the neighbor as R2 instead of its router ID. This may not work on
all IOSes.
R1#show ip ospf neighbor
Neighbor ID
R2
Pri
1
State
FULL/BDR
Dead Time
00:00:33
Address
12.1.1.2
Interface
GigabitEthernet0/2
Task 6
Configure R2 such that if it does not receive an acknowledgment from R3 for a given
LSA, it waits 10 seconds before it re-sends that given LSA.
OSPF performs reliable flooding of LSAs. This simply means, for every LS update packet a router sends, the
router expects to receive a LS Acknowledge packet from its neighbor. If the router does not receive an LS
Acknowledge packet from its neighbor acknowledging it received the LS Update, the router will retransmit
the LSA. This retransmission is controlled by a set interval dictated by the retransmit timer. The default
retransmit timer is set to 5 seconds as seen below for the G0/3 interface on R2:
On R2:
R2#show ip ospf interface g0/3 | include Timer
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
The task requires configuring R2 such that it waits 10 seconds before retransmitting the unacknowledged
LSA to R3. This is achieved by modifying the retransmit value for the G0/3 interface to 10 seconds with the
ip ospf retransmit-interval 10 command in interface configuration mode:
R2(config)#interface g0/3
R2(config-if)#ip ospf retransmit-interval 10
To verify the configuration:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 464
On completing the above, the show ip ospf interface g0/3 command output from R2 shows the modified retransmit
value of 10 seconds:
R2#show ip ospf interface g0/3 | include Timer
Timer intervals configured, Hello 10 msec, Dead 40, Wait 40, Retransmit
10
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 465
Task 7
Configure R1 and R2 such that when there is a topology change in Area 0 for LSA
Types 1 and 2, the entire SPT is not recomputed. This should only occur for the affected
part/s of the tree.
OSPF is a link-state routing protocol. That is to say, an OSPF-speaking router exchanges detailed routing
information about the state of its links in the form of a Type-1 router or Type-2 network Link State
Advertisement (LSA). These LSAs are advertised in Link State Update packets between all routers in the
topology and are stored in the Link State Database (LSDB). When two neighbors come online, they exchange
all LSAs contained in their LSDBs with each other. In this way the LSDB is kept synchronized between all
routers in a particular OSPF area.
Once the LSDB has been synchronized within an area, the router can construct a graph or map of the area
topology. This graph is made up of nodes and the links that connect to the nodes. After complete topology
information has been mapped or graphed out, OSPF performs a shortest-path computation to find the
shortest path to reach any node on the graph. OSPF uses the Dijkstra SPF algorithm to accomplish this. After
running the Dijkstra SPF algorithm against all nodes on the graph, the router has constructed a shortestpath tree from itself (as the root of the tree) to all other nodes on the graph. It is from this tree that the
router derives the routes it installs into the routing table.
Any changes to a router’s link-state information, such as removing or adding a link connected to this router,
results in a change to the graph of the area. The affected router advertises this change in an LS UPDATE
packet amending its LSAs. After receiving the update packet containing new Type-1 router or Type-2
network link state information for a particular router, the local router must recompute its own SPT to
ensure it is still using the most efficient path to reach all nodes within its area.
There are circumstances, however, where a change in the graph does not affect the local router’s resulting
SPT or may only affect a portion of the router’s SPT. In such cases, it is a waste of effort on the local router’s
side to recalculate the entire SPT from scratch. Doing so could become CPU intensive if the OSPF area is
very large, containing OSPF routers.
For example, in the lab topology, R3, from R1’s perspective, is a leaf-node router. That is to say, R3 doesn’t
connect to any other downstream routers. R2, on the other hand, connects R1 to R3 and as such R2 is a
branch router that allows R1 to transit traffic to R3. If R3’s link to R2 were to go down, it would not be
necessary for R1 to recalculate its entire SPT again only to remove R3 from the very edge of the network.
The example above, is the situation the task is looking to address. It states that if there is a change in Type-1
router and Type-2 network LSAs in Area 0, R1 and R2 should not run a full SPF. Only the affected portions of
the SPT should be recalculated. This means that rather than recomputing the entire SPT, R1 can simply
remove R3 from the edge of its SPT with minimal consequence, running only a partial SPF algorithm for only
the affected part of its SPT (the R2/R3 link). This is called an incremental SPF calculation.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 466
Incremental SPF calculations optimize SPF calculations by establishing two types of calculations:
1. Full SPF - Where SPF is run against the entirety of the LSDB
2. Incremental SPF - Where only the affected part of the local router’s SPT is recalculated
Full SPF calculations occur whenever a change is made to one of the routers own Type-1 or Type-2
LSAs. This is an indication that one of the router’s core links have undergone a change in some way. For
example, if R1 loses its connection with R2, it must run a full SPF to recompute its entire SPT.
Incremental SPF calculations occur in the following:
1. Whenever a leaf node router or link comes up or down
2. Whenever a non-SPT link comes up or down
3. Whenever a branch of the SPT fails
The first, is a direct reference to the R2/R3 link from R1’s perspective. If that link goes down, R1 only needs
to run an incremental SPF calculation to remove R3 from its SPT. The second references a link in the
topology that R1 does not use in its SPT to reach any other node. Running a full calculation in this case
would be a waste as there will effectively be no change in the resultant SPT from R1’s perspective. The last
references a situation where an indirectly-connected branch of the SPT goes down. For example, if R3 were
connected to another router, R4 in this case. If the R2/R3 link goes down, R1 still only needs to recalculate
that failure and does not need to run a full SPF calculation.
The incremental spf feature is enabled using the ispf command in OSPF router configuration mode. To
complete the task, this feature needs to be enabled on R1 and R2. As seen in the example output from R1
below, Incremental SPF is turned off by default:
On R1 and R2:
Rx#show ip ospf | include Increm
Incremental-SPF disabled
On R3:
Before configuring incremental SPF, let’s observe what happens on R1 whenever the R2/R3 link is shut down:
R3(config)#interface g0/2
R3(config-if)#shut
You should see the following messages:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 467
Process 1, Nbr 2.2.2.2 on GigabitEthernet0/2 from FULL to DOWN, Neighbor
Down: Interface down or detached
%LINK-5-CHANGED: Interface GigabitEthernet0/2, changed state to
administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2,
changed state to down
G0/2 is shut down on R3 in the above. In the output below interface G0/2 is brought back up on R3. The show ip ospf
statistics detail command is used on R1 to see what kind of computation R1 performed:
On R1:
R1#show ip ospf statistics detail
OSPF Router with ID (1.1.1.1) (Process ID 1)
Area 0: SPF algorithm executed 4 times
SPF 1 executed 00:43:35 ago, SPF type Full
SPF calculation time (in msec):
SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 01000001 LSIDs processed R:3 N:2 Stub:4
SN:0 SA:0 X7:0
Change record 0x0
LSIDs changed 5
Changed LSAs. Recorded is LS ID and LS type: 2.2.2.2(R) 3.3.3.3(R) 12.1.1.2(N)
23.1.1.2(N) 1.1.1.1(R)
SPF 2 executed 00:07:21 ago, SPF type Full
SPF calculation time (in msec):
SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 00100001 LSIDs processed R:2 N:1 Stub:3
SN:0 SA:0 X7:0
Change record 0x0
LSIDs changed 2
Changed LSAs. Recorded is LS ID and LS type:
2.2.2.2(R) 23.1.1.2(N)
SPF 3 executed 00:05:16 ago, SPF type Full
SPF calculation time (in msec):
SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 00000000 LSIDs processed R:2 N:2 Stub:2
SN:0 SA:0 X7:0
Change record 0x0
LSIDs changed 3
Changed LSAs. Recorded is LS ID and LS type: 3.3.3.3(R) 2.2.2.2(R) 23.1.1.3(N)
SPF 4 executed 00:05:06 ago, SPF type Full
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 468
SPF calculation time (in msec):
SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 00000000 LSIDs processed R:3 N:2 Stub:4
SN:0 SA:0 X7:0
Change record 0x0
LSIDs changed 1
Changed LSAs. Recorded is LS ID and LS type: 3.3.3.3(R)
The show ip ospf statistics detail output lists OSPF SPF calculation activity. It includes how long it took for a
particular SPF calculation, the total number of SPF calculations, what kind of SPF calculation was used, and
what LSAs triggered the SPF calculation. The output above reveals that R1 has run SPF 3 times. The most
recent runs are SPF 3 and SPF 4. In SPF 2, R1 performed a full SPF update because the Type-2 LSA from R2
changed. This was a result of the R2/R3 link failing. In SPF 3 and 4, R1 ran another full SPF calculation. This
was whenever the R2/R3 link was brought down and back up.
Next, incremental SPF will be configured using the ispf command under the OSPF router configuration
mode on R1 and R2:
On R1, and R2:
Rx(config)#router ospf 1
Rx(config-router)#ispf
To verify the configuration:
On R1:
The show ip ospf command output from R1 and R2 now reveal this feature is enabled:
R1#show ip ospf | include Incremental
Incremental-SPF enabled
On R3:
Once again, the R2/R3 link is brought down and back up:
R3(config)#interface g0/2
R3(config-if)#no shut
R3(config-if)#shut
On R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 469
The show ip ospf statistics detail command now lists the following:
R1#show ip ospf statistics detail
OSPF Router with ID (1.1.1.1) (Process ID 1)
Area 0: SPF algorithm executed 7 times
[--- omitted ---]
SPF 6 executed 00:01:26 ago, SPF type Incremental
SPF calculation time (in msec):
SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 00000000 LSIDs processed R:2 N:2 Stub:2 SN:0 SA:0
X7:0
Change record 0x0
LSIDs changed 4
Changed LSAs. Recorded is LS ID and LS type: 3.3.3.3(R) 23.1.1.3(N) 2.2.2.2(R) 23.1.1.2(N)
SPF 7 executed 00:01:16 ago, SPF type Incremental
SPF calculation time (in msec):
SPT Intra D-Intr Summ D-Summ Ext7 D-Ext7 Total 00000000 LSIDs processed R:3 N:2 Stub:4 SN:0 SA:0
X7:0
Change record 0x0
LSIDs changed 1
Changed LSAs. Recorded is LS ID and LS type: 3.3.3.3(R)
The truncated output above shows that R1 used incremental calculations for its last two SPF calculations as required
by the task.
Task 8
Erase the startup configuration and reload the routers before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 470
Lab 2
OSPF Broadcast Networks
This lab should be conducted on the Enterprise POD.
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
OSPF folder  Lab-2.
Task 1
Configure OSPF Area 0 on all routers and their directly connected interfaces. Ensure that
Loopback0 interfaces are advertised with their correct mask. You should configure the
OSPF router IDs to be 0.0.0.x, where x is the router number.
OSPF Network Types
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 471
One fact that is echoed throughout this section is that OSPF is a link-state routing protocol. It creates a graph
of connected link states for all routers in the OSPF area domain. To create this graph, OSPF exchanges what
are known as Link State Advertisements (LSAs) in the form of Link State Updates. These LSAs contain the
descriptions of the router’s links in the network and come in many types, each serving a specific purpose.
LSAs represent either a single link, a single network, or a single router.
Out of all the LSAs generated by the router, the most important is the Type-1 router LSA. This LSA is used to
describe the router itself and its connected links. The Type-1 router LSA contains an individual link
description for each physical or logical link that is enabled for OSPF on the local router. The way these links
are described depends on the OSPF network type.
There are five main OSPF network types:
1. Broadcast
2. Non-Broadcast
3. Point-to-point
4. Point-to-multipoint
5. Point-to-multipoint non-broadcast
Each network type is explored in the next four labs beginning with the broadcast network type.
To start this section off, OSPF needs to be configured to run on all of the ethernet and loopback interfaces on all of the routers.
The loopback interfaces, in particular, must advertise the proper subnet masks instead of the default OSPF /32 subnet mask used
for loopback interfaces. The configuration below configures the proper router IDs, enables OSPF on the router interfaces, and
ensures the loopbacks are advertised with proper subnet masks by changing the network type to point-to-point:
On R1:
R1(config)#router ospf 1
R1(config-router)#router-id 0.0.0.1
R1(config-router)#network 10.1.1.1 0.0.0.0 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R1(config-router)#interface lo0
R1(config-if)#ip ospf network point-to-point
On R2:
R2(config)#router ospf 1
R2(config-router)#router-id 0.0.0.2
R2(config-router)#network 10.1.1.2 0.0.0.0 area 0
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0
R2(config-router)#interface lo0
R2(config-if)#ip ospf network point-to-point
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 472
You should see the following console messages:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on GigabitEthernet0/0 from LOADING
to FULL, Loading Done
On R3:
R3(config)#router ospf 1
R3(config-router)#router-id 0.0.0.3
R3(config-router)#network 10.1.1.3 0.0.0.0 area 0
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
R3(config-router)#interface lo0
R3(config-if)#ip ospf netw point-to-point
You should see the following console messages:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on GigabitEthernet0/0 from LOADING
to FULL, Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.2 on GigabitEthernet0/0 from LOADING
to FULL, Loading Done
On R4:
R4(config)#router ospf 1
R4(config-router)#router-id 0.0.0.4
R4(config-router)#network 10.1.1.4 0.0.0.0 area 0
R4(config-router)#network 4.4.4.4 0.0.0.0 area 0
R4(config-router)#interface lo0
R4(config-if)#ip ospf network point-to-point
The show ip route ospf | begin Gateway command on all routers verifies the OSPF routes they learn:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
2.0.0.0/8 [110/2] via 10.1.1.2, 00:30:23, GigabitEthernet0/0
3.0.0.0/8 [110/2] via 10.1.1.3, 00:29:51, GigabitEthernet0/0
4.0.0.0/8 [110/2] via 10.1.1.4, 00:29:22, GigabitEthernet0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 473
On R2:
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/8 [110/2] via 10.1.1.1, 00:31:49, GigabitEthernet0/0
3.0.0.0/8 [110/2] via 10.1.1.3, 00:31:22, GigabitEthernet0/0
4.0.0.0/8 [110/2] via 10.1.1.4, 00:30:54, GigabitEthernet0/0
On R3:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/8 [110/2] via 10.1.1.1, 00:31:47, GigabitEthernet0/0
2.0.0.0/8 [110/2] via 10.1.1.2, 00:31:47, GigabitEthernet0/0
4.0.0.0/8 [110/2] via 10.1.1.4, 00:31:16, GigabitEthernet0/0
On R4:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/8 [110/2] via 10.1.1.1, 00:31:44, GigabitEthernet0/0
2.0.0.0/8 [110/2] via 10.1.1.2, 00:31:44, GigabitEthernet0/0
3.0.0.0/8 [110/2] via 10.1.1.3, 00:31:44, GigabitEthernet0/0
To produce the output above, OSPF has to do some housekeeping on the back end. First and foremost, each router needs to know
what kind of network to which its OSPF-enabled links are connected. With this information, it models the relationship between its
link and the neighbors that are connected to that link.
In this case, each router’s G0/0 interface is connected to a LAN segment. Such segments are called
multiaccess or transit networks in OSPF terminology. It represents a link that can carry traffic that is not
destined to a device on the link or connects to multiple other routers. Thus, the link is modeled as such in
each router’s Type-1 router LSA. Looking at the show ip ospf database command, reveals each router is
advertising two links in their Type-1 router LSA as seen on R1:
On R1:
R1#show ip ospf database
OSPF Router with ID (0.0.0.1) (Process ID 1)
Router Link States (Area 0)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 474
Link ID
0.0.0.1
0.0.0.2
0.0.0.3
0.0.0.4
ADV Router
0.0.0.1
0.0.0.2
0.0.0.3
0.0.0.4
Age
177
157
122
161
Seq#
Checksum Link count
0x8000000A 0x009862 2
0x80000009 0x00AB4C 2
0x80000007 0x00C035 2
0x80000005 0x00D51E 2
Net Link States (Area 0)
Link ID
10.1.1.2
ADV Router
0.0.0.2
Age
157
Seq#
Checksum
0x80000004 0x00A074
The show ip ospf database router self-originate command on R1 goes into the details of its Type-1 router
LSA. The LSA describes its link on the LAN segment as a “transit link” and the network connected to its
loopback interface as a stub network:
R1#show ip ospf database router self-originate
OSPF Router with ID (0.0.0.1) (Process ID 1)
Router Link States (Area 0)
LS age: 278
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.1
Advertising Router: 0.0.0.1
LS Seq Number: 8000000A
Checksum: 0x9862
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.2
(Link Data) Router Interface address: 10.1.1.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 475
The link description for the transit area may look odd. It mentions a “Designated Router address” and a
“Router Interface address”. Why does it do this? The simple answer is in an optimization OSPF performs for
LAN segments.
In OSPF, LAN segments can be of two types, broadcast or non-broadcast. This speaks to the LAN’s ability to
process broadcast/multicast packets. If the underlying LAN infrastructure can support broadcast traffic, then
the router can multicast OSPF hello packets to discover neighbors. This is the broadcast network type that is
the subject of this section.
On such LAN segments, it is possible to have multiple OSPF-speaking routers connected to the same
segment. In case of the lab topology, there are four OSPF-speaking routers connected to the same LAN
segment, the 10.1.1.0/24 LAN segment. ALL routers have full-mesh reachability to each other, meaning R1
can send a packet to R2, R3 and R4; R2 can send a packet to R1, R3 and, R4; and so on.
OSPF must model this full-mesh reachability in some way that makes sense and is efficient. One way, from R1’s perspective, is to
model 3 point-to-point link adjacencies in its Type-1 LSA, one for its adjacency with each router. Each router on the segment would
have to model the same 3 link adjacency leading to a grand total of 12 link adjacency descriptions in the OSPF database for a single
LAN segment. If another OSPF-speaking router were added to the segment, it would increase to 20 link adjacencies.
This model does not scale for large LAN or multi-access segments.
Instead, OSPF takes a different approach. It represents the LAN segment itself as a node on the graph and
attaches all connected routers to that central node. This network node is described in the Type-2 network
LSA. All routers connected to the LAN segment model a single link connected to the multiaccess segment as a
transit network node. The following output truncates the the show ip ospf database router self-originate
command on R1 and compares it to the show ip ospf database network output:
R1#show ip ospf database router self-originate | begin Transit
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.2
(Link Data) Router Interface address: 10.1.1.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
R1#show ip ospf database network
OSPF Router with ID (0.0.0.1) (Process ID 1)
Net Link States (Area 0)
LS age: 480
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.1.1.2 (address of Designated Router)
Advertising Router: 0.0.0.2
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 476
LS Seq Number: 80000004
Checksum: 0xA074
Length: 40
Network Mask: /24
Attached Router: 0.0.0.2
Attached Router: 0.0.0.1
Attached Router: 0.0.0.3
Attached Router: 0.0.0.4
R1’s Type-1 router LSA references what is known as a Designated Router address in its link description for
the LAN segment. This designated router address is used as the identifier for the resulting Type-2 LSA. The
Designated Router (DR) is used to solve another problem. Since all routers on the LAN segment must
maintain the same information in their LSDBs, they must exchange LSAs with each other to achieve this
synchronization. That can lead to repeated flooding of link-state information onto the LAN. Moreover, which
router on the LAN should be the router that creates the network node for the LAN segment? The answer to
this is the DR.
The DR is elected to help facilitate the LSA flooding and synchronization of Link-State information. All routers
exchange LSAs with the DR and become fully adjacent, exchanging LSAs with the DR using the special “AllOSPF-DR” multicast group 224.0.0.6. The DR also creates the network node Type-2 network LSA shown
above, adding the router IDs of all attached routers as well as the netmask for the LAN segment to the Type2 LSA. The Type-2 network LSA above represents the 10.1.1.0/24 network as indicated by the designated
router/network mask combination. It also indicates that routers 0.0.0.1, 0.0.0.2, 0.0.0.3, and 0.0.0.4 are all
connected to the 10.1.1.0/24 network node.
Organizing the LAN segment this way keeps link-state information flooding to a minimum. If a new router is
added to the LAN segment, it becomes fully adjacent with the DR. The DR synchronizes its LSDB with the new
router and updates the Type-2 LSA for the LAN segment with the new router’s router ID. In the output above,
the DR address is R2’s IP address on the LAN segment. The DR is elected on the LAN segment using the
following algorithm:
1. Highest priority (configured with the ip ospf priority command in interface configuration mode)
2. Highest OSPF router ID
This election is a one-time election. The DR is elected based on the exchange of hello packets during a given
period of time which is roughly 40 seconds. Before carrying out DR elections, the routers wait for 40 seconds
to see if there is a currently active DR on the segment. If not, the DR election is held. If the local router has
not received a hello from another router on the segment with a higher OSPF priority or router ID, it elects
itself as the DR and floods the Type-2 network LSA for the network segment.
If the DR fails, another router should take its place. However, to speed the convergence process, the router
with the second highest priority or router-ID is elected as a Backup Designated Router (BDR). All routers
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 477
including the DR become fully adjacent with the BDR and exchange LSAs with the BDR. This way, when the
DR fails, the BDR takes its place and floods a new Type-2 network LSA for the segment.
By default, all ethernet interfaces on Cisco IOS routers are designated as OSPF broadcast network types. This
is because ethernet interfaces typically lead to ethernet LAN segments where multiple routers can be
connected. The show ip ospf interfaces G0/0 command on R1 reveals some very useful information
regarding the broadcast network type:
R1#show ip ospf interface g0/0
GigabitEthernet0/0 is up, line protocol is up
Internet Address 10.1.1.1/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 0.0.0.1, Network Type BROADCAST, Cost: 1
Topology-MTID
Cost
Disabled
Shutdown
Topology Name
0
1
no
no
Base
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 0.0.0.2, Interface address 10.1.1.2
Backup Designated router (ID) 0.0.0.1, Interface address 10.1.1.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/2/2, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 3, Adjacent neighbor count is 3
Adjacent with neighbor 0.0.0.2 (Designated Router)
Adjacent with neighbor 0.0.0.3
Adjacent with neighbor 0.0.0.4
Suppress hello for 0 neighbor(s)
The output above verifies the network type is broadcast on R1’s G0/0. It also indicates the default hello and
dead interval timers configured on the interface. By default, OSPF broadcast network type uses a hello
interval of 10 seconds and a dead timer of 40 seconds. Throughout the next labs these settings will vary
based on the different network types.
Finally, the OSPF broadcast network type installs routes into the routing table with the router that advertised
the LSA on the LAN segment (to the DR first) as the next-hop as verified below:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 478
O
O
O
2.0.0.0/8 [110/2] via 10.1.1.2, 00:43:17, GigabitEthernet0/0
3.0.0.0/8 [110/2] via 10.1.1.3, 00:42:45, GigabitEthernet0/0
4.0.0.0/8 [110/2] via 10.1.1.4, 00:42:16, GigabitEthernet0/0
R1 installs the loopback 0 interface IP addresses of all routers with those routers as the next hop. This fact is
very important for specialty partial-mesh cases such as DMVPN which is explained in the next section.
To review, the broadcast network type has the following characteristics:
1. Default network type on Ethernet interfaces
2. Hellos can be multicast to the 224.0.0.5 OSPF multicast address.
3. Hello and Dead timers are set to 10s and 40s respectively.
4. The next hop is the router that has the link to the route in the LSDB.
5. DR and BDR are elected to organize LSA exchange and generate the Type-2 LSA linking
all routers on the segment together.
6. Routers exchange Link-State information with the DR/BDR using the 224.0.0.6
“All-OSPF-DR/BDR” multicast group.
Task 2
Lab Setup:
Erase the configuration of all routers and SW1. To copy and paste the initial
configurations, go to the Initial-config folder  OSPF folder  Lab-2-Task-2.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 479
Configure OSPF on the tunnel and Loopback0 interfaces of all routers, based on the
following policy:






R1 is the hub, and R2, R3, and R4 are configured as spokes. Do not change the
topology.
Configure the tunnel interfaces of all routers to be OSPF broadcast network type.
The loopback interfaces should be advertised with their correct mask.
Configure the router IDs of R1, R2, R3, and R4 to be 0.0.0.1, 0.0.0.2, 0.0.0.3, and
0.0.0.4, respectively.
You should use static maps on the DMVPN network.
Spokes should traverse the hub to reach all networks.
This lab examines some of the subtleties of the broadcast network type. Specifically, with how it behaves on
partial-mesh NBMA networks such as DMVPN. To begin, OSPF should be configured according to the policy
above. The following configures the tunnel and loopback0 interfaces for OSPF on each router. The router ID
is set according to the task specifications using the router-id command in OSPF router configuration mode.
OSPF is configured to advertise the actual mask on loopback interfaces by changing the network type on the
loopback interfaces to point-to-point:
On All Routers:
Rx(config-router)#interface lo0
Rx(config-if)#ip ospf network point-to-point
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 480
On R1:
R1(config)#router ospf 1
R1(config-router)#router-id 0.0.0.1
R1(config-router)#network 10.1.1.1 0.0.0.0 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R1(config)#interface tunnel 1234
R1(config-if)#ip ospf network broadcast
On R2:
R2(config)#router ospf 1
R2(config-router)#router-id 0.0.0.2
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0
R2(config-router)#network 10.1.1.2 0.0.0.0 area 0
R2(config)#interface tunnel 1234
R2(config-if)#ip ospf network broadcast
On R3:
R3(config)#router ospf 1
R3(config-router)#router-id 0.0.0.3
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
R3(config-router)#network 10.1.1.3 0.0.0.0 area 0
R3(config)#interface tunnel 1234
R3(config-if)#ip ospf network broadcast
On R4:
R4(config)#router ospf 1
R4(config-router)#router-id 0.0.0.4
R4(config-router)#network 4.4.4.4 0.0.0.0 area 0
R4(config-router)#network 10.1.1.4 0.0.0.0 area 0
R4(config)#interface tunnel 1234
R4(config-if)#ip ospf network broadcast
After configuring all of the routers, there are no OSPF adjacency notifications on the routers. Furthermore,
the show ip ospf neighbor command does not list any neighbors on any router:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 481
On R1:
R1#show ip ospf neighbor
R1#
On R2:
R2#show ip ospf neighbor
R2#
On R3:
R3#show ip ospf neighbor
R3#
On R4:
R4#show ip ospf neighbor
R4#
Recall from the previous task that OSPF broadcast network type still uses multicast hello messages to
discover neighbor adjacencies. However, on non-broadcast mediums such as DMVPN, these hello messages
cannot be transmitted to all potential neighbors as multicast. To facilitate OSPF broadcast network type’s
multicast hello, the medium needs to support a form of pseudo-broadcasting. DMVPN supports this in the
form of static NHRP multicast mappings. These mappings tell the router to which NBMA addresses multicast
packets it originates should be forwarded.
The output of the show ip nhrp multicast command shows the current multicast mappings that exist on
each router:
On R1:
R1#show ip nhrp multicast
I/F
NBMA address
On R2:
R2#show ip nhrp multicast
I/F
NBMA address
On R3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 482
R3#show ip nhrp multicast
I/F
NBMA address
On R4:
R4#show ip nhrp multicast
I/F
NBMA address
The output shows no multicast mappings exist on the routers. The cause of this can be seen using the show
run interface Tunnel1234 | begin interface output:
On R1:
R1#show run interface tunnel 1234 | begin interface
interface Tunnel1234
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip nhrp map 10.1.1.2 192.1.2.2
ip nhrp map 10.1.1.3 192.1.3.3
ip nhrp map 10.1.1.4 192.1.4.4
ip nhrp network-id 111
ip ospf network broadcast
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
end
On R2:
R2#show run interface tunnel 1234 | begin interface
interface Tunnel1234
ip address 10.1.1.2 255.255.255.0
no ip redirects
ip nhrp map 10.1.1.1 192.1.1.1
ip nhrp network-id 222
ip ospf network broadcast
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
end
On R3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 483
R3#show run interface tunnel 1234 | begin interface
interface Tunnel1234
ip address 10.1.1.3 255.255.255.0
no ip redirects
ip nhrp map 10.1.1.1 192.1.1.1
ip nhrp network-id 333
ip ospf network broadcast
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
end
On R4:
R4#show run interface tunnel 1234 | begin interface
interface Tunnel1234
ip address 10.1.1.4 255.255.255.0
no ip redirects
ip nhrp map 10.1.1.1 192.1.1.1
ip nhrp network-id 444
ip ospf network broadcast
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
end
The output contains no static or dynamic NHRP multicast mapping commands. To fix this, the static NHRP
multicast mapping command ip nhrp map multicast NBMA-address should be added. R1 should have
mappings for all four spoke NBMA addresses while the spokes require only a single mapping for R1’s NBMA
address. These mappings must be statically assigned out of compliance with the task requirements that only
static mappings be configured. First the configuration is tested on R1 and R2:
On R1:
R1(config)#interface tunnnel 1234
R1(config-if)#ip nhrp map multicast 192.1.2.2
On R2:
R2(config)#interface tunnel 1234
R2(config-if)#ip nhrp map multicast 192.1.1.1
If both ends are not configured to map Multicast for each other’s NBMA addresses, the OSPF adjacency will
be established and torn down and you will get the following console message:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 484
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Tunnel1234 from LOADING to
FULL, Loading Done
Let’s verify the adjacency and see if these two routers are exchanging routes. As seen below, R1 learns the
R2’s loopback address via OSPF over the tunnel 1234 interface and the ping to the 2.2.2.2 address succeeds:
On R1:
R1#show ip ospf neighbor
Neighbor ID
0.0.0.2
Pri
1
State
FULL/DR
Dead Time
00:00:35
Address
10.1.1.2
Interface
Tunnel1234
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
2.0.0.0/8 [110/1001] via 10.1.1.2, 00:03:26, Tunnel1234
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/6 ms
Since the configuration was successful above it is repeated and applied to R3 and R4 as well:
R1(config)#interface tunnel 1234
R1(config-if)#ip nhrp map multicast 192.1.3.3
R1(config-if)#ip nhrp map multicast 192.1.4.4
On R3 & R4:
R3(config)#interface tunnel 1234
R3(config-if)#ip nhrp map multicast 192.1.1.1
Now the show ip ospf neighbor command on all routers verifies the OSPF adjacencies are up:
On R1:
R1#show ip ospf neighbor
Neighbor ID
0.0.0.2
0.0.0.3
Pri
1
1
State
FULL/DROTHER
FULL/DROTHER
CCIE by Narbik Kocharians
Dead Time
00:00:38
00:00:37
Address
10.1.1.2
10.1.1.3
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Interface
Tunnel1234
Tunnel1234
Page 485
0.0.0.4
1
FULL/DR
00:00:32
10.1.1.4
Tunnel1234
R2#show ip ospf neighbor
Neighbor ID
Pri
State
0.0.0.1
1
FULL/BDR
Dead Time
00:00:30
Address
10.1.1.1
Interface
Tunnel1234
Dead Time
00:00:30
Address
10.1.1.1
Interface
Tunnel1234
Dead Time
00:00:30
Address
10.1.1.1
Interface
Tunnel1234
On R2:
On R3:
R3#show ip ospf neighbor
Neighbor ID
Pri
State
0.0.0.1
1
FULL/BDR
On R4:
R4#show ip ospf neighbor
Neighbor ID
Pri
State
0.0.0.1
1
FULL/BDR
The routing tables on each router, however, tell a different story:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
4.0.0.0/8 [110/1001] via 10.1.1.4, 00:05:19, Tunnel1234
On R2:
R2#show ip route ospf | begin Gate Gateway of last resort is not set
On R3:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
On R4:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
1.0.0.0/8 [110/1001] via 10.1.1.1, 00:05:29, Tunnel1234
Only R1 and R4 have routes in their routing tables and not even complete routing information. R2 and R3 have no
OSPF-learned routes in their routing tables. What can be the cause of this? The answer is in the DR election process.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 486
Recall from the previous task that OSPF broadcast network types elect a DR and BDR on each LAN segment.
The DR creates a Type-2 network LSA to represent the LAN segment and advertises it to all its OSPF
neighbors with the router IDs of all routers attached to the LSA. The routers only become fully adjacent with
the DR and BDR and rely on these routers for their LSA exchange process.
The show ip ospf interfaces brief command output on each router reveals what role each router believes its
tunnel interface to play on the LAN segment:
On R1:
R1#show ip ospf interface brief
Interface
Lo0
Tu1234
PID
1
1
Area
0
0
IP Address/Mask
1.1.1.1/8
10.1.1.1/24
Cost
1
1000
State Nbrs F/C
P2P
0/0
BDR
3/3
IP Address/Mask
2.2.2.2/8
10.1.1.2/24
Cost
1
1000
State Nbrs F/C
P2P
0/0
DR
1/1
IP Address/Mask
3.3.3.3/8
10.1.1.3/24
Cost
1
1000
State Nbrs F/C
P2P
0/0
DR
1/1
IP Address/Mask
4.4.4.4/8
10.1.1.4/24
Cost
1
1000
State Nbrs F/C
P2P
0/0
DR
1/1
On R2:
R2#show ip ospf interface brief
Interface
Lo0
Tu1234
PID
1
1
Area
0
0
On R3:
R3#show ip ospf interface brief
Interface
Lo0
Tu1234
PID
1
1
Area
0
0
On R4:
R4#show ip ospf interface brief
Interface
Lo0
Tu1234
PID
1
1
Area
0
0
In the above, R2, R3, and R4 all believe they are the DR on the LAN segment. This confusion results in three
Type 2 LSAs being generated for the LAN segment as shown on R1:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 487
On R1:
R1#show ip ospf database network
OSPF Router with ID (0.0.0.1) (Process ID 1)
Net Link States (Area 0)
LS age: 1099
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.1.1.2 (address of Designated Router)
Advertising Router: 0.0.0.2
LS Seq Number: 80000001
Checksum: 0x81F
Length: 32
Network Mask: /24
Attached Router: 0.0.0.2
Attached Router: 0.0.0.1
LS age: 868
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.1.1.3 (address of Designated Router)
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0x222
Length: 32
Network Mask: /24
Attached Router: 0.0.0.3
Attached Router: 0.0.0.1
LS age: 869
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.1.1.4 (address of Designated Router)
Advertising Router: 0.0.0.4
LS Seq Number: 80000001
Checksum: 0xFB25
Length: 32
Network Mask: /24
Attached Router: 0.0.0.4
Attached Router: 0.0.0.1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 488
This confusion in the LSDB causes the problems observed. The reason this confusion occurs is because R2,
R3, and R4 cannot see each other’s hello messages. The result is, they do not know that each other exists on
the same network. Each is acting as if they are on an isolated network with R1 as the only other attached
router on that network.
R1, on the other hand, only recognizes R4 as a DR as shown in the show ip ospf neighbor output below:
R1#show ip ospf neighbor
Neighbor ID
0.0.0.2
0.0.0.3
0.0.0.4
Pri
1
1
1
State
FULL/DROTHER
FULL/DROTHER
FULL/DR
Dead Time
00:00:34
00:00:35
00:00:34
Address
10.1.1.2
10.1.1.3
10.1.1.4
Interface
Tunnel1234
Tunnel1234
Tunnel1234
Because R1 believes R4 is the DR on the segment, it models its own link in its Type-1 LSA to the Type-2 network LSA
generated by the DR R4, 10.1.1.4. as shown below:
R1#show ip ospf database router self-originate
OSPF Router with ID (0.0.0.1) (Process ID 1)
Router Link States (Area 0)
LS age: 1629
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.1
Advertising Router: 0.0.0.1
LS Seq Number: 80000003
Checksum: 0x57BD
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.4
(Link Data) Router Interface address: 10.1.1.1
Number of MTID metrics: 0
TOS 0 Metrics: 1000
The consequence of this configuration is that even though R2 and R3 generate Type-2 network LSAs that
list R1 as being connected to those network LSAs, R2 and R3 cannot install routes through R1 because R1
does not model a link to those network nodes in its Type-1 LSA. In OSPF, for a link to be valid, the Type-1
router LSA and the Type-2 LSA must model links to each other.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 489
This is why R1’s and R4’s routes do not appear in R2’s and R3’s routing tables. Similarly, R2 and R3 do not
model a link to R4’s Type-2 network LSA, as R1 and R4 do. This is why R1 and R4 only have each other’s
routes in their routing tables. This point is proven by the output from R2, R3, and R4 below:
On R2:
R2#show ip ospf database router self-originate | begin Transit
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.2
(Link Data) Router Interface address: 10.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1000
On R3:
R3#show ip ospf database router self-originate | begin Transit
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.3
(Link Data) Router Interface address: 10.1.1.3
Number of MTID metrics: 0
TOS 0 Metrics: 1000
On R4:
R4#show ip ospf database router self-originate | begin Transit
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.4
(Link Data) Router Interface address: 10.1.1.4
Number of MTID metrics: 0
TOS 0 Metrics: 1000
In the above, R2 and R3 model links to their own Type-2 LSA while R4 models a link to its own Type-2 LSA
just like R1.
When configuring OSPF broadcast network types on an NBMA network such as DMVPN with
partial mesh peerings as seen in this situation, it is important to consider the DR placement.
The DR should be a router to which all routers connected to the NMBA network can exchange
hellos with and form a full adjacency. All routers having only partial mesh neighborships should
not be allowed to become the DR.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 490
To prevent a router from becoming a DR, simply set its OSPF priority for that interface to zero. This setting
disqualifies the router from ever becoming a DR or BDR. This configuration is applied using the ip ospf
priority 0 command in interface configuration mode and is performed on R2, R3, and R4 below:
On R2, R3, and R4:
Rx(config)#interface tunnel 1234
Rx(config-if)#ip ospf priority 0
On All Routers:
Rx#clear ip ospf process
Reset ALL OSPF processes? [no]: Yes
After configuration, all routers now agree that R1 should be the DR since it is the only router with a nonzero OSPF priority:
On R1:
R1#show ip ospf neighbor
Neighbor ID
0.0.0.2
0.0.0.3
0.0.0.4
Pri
0
0
0
State
FULL/DROTHER
FULL/DROTHER
FULL/DROTHER
Dead Time
00:00:39
00:00:39
00:00:38
Address
10.1.1.2
10.1.1.3
10.1.1.4
Interface
Tunnel1234
Tunnel1234
Tunnel1234
Dead Time
00:00:32
Address
10.1.1.1
Interface
Tunnel1234
Dead Time
00:00:34
Address
10.1.1.1
Interface
Tunnel1234
On R2:
R2#show ip ospf neighbor
Neighbor ID
0.0.0.1
Pri
1
State
FULL/DR
On R3:
R3#show ip ospf neighbor
Neighbor ID
0.0.0.1
Pri
1
State
FULL/DR
On R4:
R4#show ip ospf neighbor
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 491
Neighbor ID
0.0.0.1
Pri
1
State
FULL/DR
Dead Time
00:00:31
Address
10.1.1.1
Interface
Tunnel1234
The output on R1 confirms that R2, R3, and R4 are not acting as DR or BDR by the designation
FULL/DROTHER. A router that is considered a DROTHER is neither a BDR nor DR on a LAN segment. The
output from R2, R3, and R4 confirms that R1 is the DR on the segment. R1 floods the Type-2 LSA that all
other routers point to in their Type-1 LSA:
On R1:
R1#show ip ospf database network | begin LS
LS age: 277
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.1.1.1 (address of Designated Router)
Advertising Router: 0.0.0.1
LS Seq Number: 80000001
Checksum: 0xBA5F
Length: 40
Network Mask: /24
Attached Router: 0.0.0.1
Attached Router: 0.0.0.2
Attached Router: 0.0.0.3
Attached Router: 0.0.0.4
On R2:
R2#show ip ospf database router self-originate | begin Transit
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.1
(Link Data) Router Interface address: 10.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1000
On R3:
R3#show ip ospf database router self-originate | begin Transit
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.1
(Link Data) Router Interface address: 10.1.1.3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 492
Number of MTID metrics: 0
TOS 0 Metrics: 1000
On R4:
R4#show ip ospf database router self-originate | begin Transit
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.1.1
(Link Data) Router Interface address: 10.1.1.4
Number of MTID metrics: 0
TOS 0 Metrics: 1000
Now that the LSDB is in agreement on all routers, they have the proper routes in their routing table to reach all
attached networks over the DMVPN:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
2.0.0.0/8 [110/1001] via 10.1.1.2, 00:11:35, Tunnel1234
3.0.0.0/8 [110/1001] via 10.1.1.3, 00:11:35, Tunnel1234
4.0.0.0/8 [110/1001] via 10.1.1.4, 00:11:35, Tunnel1234
On R2:
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/8 [110/1001] via 10.1.1.1, 00:12:51, Tunnel1234
3.0.0.0/8 [110/1001] via 10.1.1.3, 00:12:41, Tunnel1234
4.0.0.0/8 [110/1001] via 10.1.1.4, 00:12:41, Tunnel1234
On R3:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/8 [110/1001] via 10.1.1.1, 00:13:18, Tunnel1234
2.0.0.0/8 [110/1001] via 10.1.1.2, 00:13:18, Tunnel1234
4.0.0.0/8 [110/1001] via 10.1.1.4, 00:13:08, Tunnel1234
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 493
On R4:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/8 [110/1001] via 10.1.1.1, 00:13:53, Tunnel1234
2.0.0.0/8 [110/1001] via 10.1.1.2, 00:13:53, Tunnel1234
3.0.0.0/8 [110/1001] via 10.1.1.3, 00:13:53, Tunnel1234
Even though all routers possess all routes to networks reachable over the DMVPN, it doesn’t necessarily
mean they have the full reachability to those routes. Take R2 for example:
On R2:
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2 cannot reach R3 and R4’s loopback interfaces. The reason behind this is a result of another aspect of the
broadcast network type. Broadcast network type assumes all routers can reach all routers over the multiaccess network. As such, when routers install routes to reach networks through the broadcast network, the
next-hop installed is the next-hop of the router that owns the prefix. In this case, the next-hop for 1.1.1.1 is
R1, for 2.2.2.2 is R2, for 3.3.3.3 is R3, and for 4.4.4.4 is R4.
R2 does not have reachability to the overlay addresses of R3 and R4 because there is no underlying DMVPN
mapping made proven by the above ping output on R2.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 494
Without this underlying mapping, R2 cannot reach those networks. To fix this, static NHRP mappings need
to be made on R2 to achieve reachability. This mapping maps R3’s overlay address 10.1.1.3 to R1’s NBMA
address 192.1.1.1 to maintain hub-and-spoke traffic flow on R2 in compliance with the task objectives.
The configuration is performed using the ip nhrp map 10.1.1.3 192.168.1.1 command in interface
configuration mode for the DMVPN tunnel interface on R2. R3 also needs a mapping command for
R2’s overlay address using the ip nhrp map 10.1.1.2 192.168.1.1 command in interface
configuration mode for the DMVPN tunnel interface.
On R2:
R2(config)#interface tunnel 1234
R2(config-if)#ip nhrp map 10.1.1.3 192.1.1.1
On R3:
R3(config)#interface tunnel 1234
R3(config-if)#ip nhrp map 10.1.1.2 192.1.1.1
A ping between R2 and R3’s overlay addresses confirms the mapping is working properly:
R2#ping 10.1.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Since the configuration was a success, it is applied to the remaining spokes to create full-mesh hub-andspoke logical mappings between the spoke routers.
On R2:
R2(config)#interface tunnel 1234
R2(config-if)#ip nhrp map 10.1.1.4 192.1.1.1
On R3:
R3(config)#interface tunnel 1234
R3(config-if)#ip nhrp map 10.1.1.4 192.1.1.1
On R4:
R4(config)#interface tunnel 1234
R4(config-if)#ip nhrp map 10.1.1.2 192.1.1.1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 495
R4(config-if)#ip nhrp map 10.1.1.3 192.1.1.1
To confirm the mappings the show ip nhrp command is used to verify the addresses are mapped properly:
On R2:
R2#show ip nhrp
10.1.1.1/32 via 10.1.1.1
Tunnel1234 created 01:14:54, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
10.1.1.3/32 via 10.1.1.3
Tunnel1234 created 00:11:10, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
10.1.1.4/32 via 10.1.1.4
Tunnel1234 created 00:06:19, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
On R3:
R3#show ip nhrp
10.1.1.1/32 via 10.1.1.1
Tunnel1234 created 01:15:27, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
10.1.1.2/32 via 10.1.1.2
Tunnel1234 created 00:11:06, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
10.1.1.4/32 via 10.1.1.4
Tunnel1234 created 00:06:22, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
On R4:
R4#show ip nhrp
10.1.1.1/32 via 10.1.1.1
Tunnel1234 created 01:15:46, never expire
Type: static, Flags: used
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 496
NBMA address: 192.1.1.1
10.1.1.2/32 via 10.1.1.2
Tunnel1234 created 00:06:18, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
10.1.1.3/32 via 10.1.1.3
Tunnel1234 created 00:06:10, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
Using R2 as a test subject, pings are executed to the networks behind the spokes R3 and R4. A trace route to
3.3.3.3 also confirms traffic is flowing to the R1 the hub first and then to R3:
On R2:
R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 ms
R2#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms
R2#traceroute 3.3.3.3 numeric
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.1 2 msec 1 msec 1 msec
2 10.1.1.3 2 msec * 2 msec
This section covered the subtleties of the broadcast network type through its operation over NBMA
networks such as DMVPN. The following summarizes these subtleties:
1. Multicast capability needs to be provided in some form by the NBMA network configuration
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 497
2. The DR of the NBMA network needs to be a router that has full-mesh OSPF adjacencies with all
routers in the topology. Any router lacking this should be configured to be ineligible to be a DR using
the ip ospf priority 0 interface-level command.
3. In partial-mesh hub-and-spoke NBMA networks, the spokes must have mappings to reach remote
spoke next-hop addresses.
Task 3
Erase the startup configuration of the routers, the config.text and the VLAN.dat of the
switches and reload them before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 498
Lab 3
OSPF Non-broadcast Networks
This lab should be conducted on the Enterprise POD.
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
OSPF folder  Lab-3.
Task 1
Configure OSPF Area 0 on all routers and their directly connected interfaces. You should
configure the tunnel interfaces as the OSPF non-broadcast network type. Configure the
OSPF router IDs to be 0.0.0.x, where x is the router number.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 499
The previous lab examined OSPF broadcast network type over both ethernet LAN segments and NBMA
networks such as DMVPN. This lab examines the OSPF non-broadcast network type. The non-broadcast
network type in OSPF is designed for those multi-access segments that do not support broadcast or multicast
transmission. In this situation, multicast hello packets cannot be transmitted between potential OSPF
neighbors and, instead, unicast transmission is required.
The OSPF non-broadcast network type behaves very similarly to the OSPF broadcast network type. To
demonstrate the similarities and contrast the differences the task opens up with basic configuration of the
OSPF environment. All routers should have OSPF enabled on their tunnel and loopback 0 interfaces. The
OSPF router ID is set to be “0.0.0.x” based on the task requirements in the below configurations. Most
importantly, the OSPF network type on the tunnel interfaces is set to non-broadcast:
On R1:
R1(config)#router ospf 1
R1(config-router)#router-id 10.0.0.1
R1(config-router)#network 10.1.1.1 0.0.0.0 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
On R2:
R2(config)#router ospf 1
R2(config-router)#router-id 0.0.0.2
R2(config-router)#network 10.1.1.2 0.0.0.0 area 0
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0
On R3:
R3(config)#router ospf 1
R3(config-router)#router-id 0.0.0.3
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
R3(config-router)#network 10.1.1.3 0.0.0.0 area 0
On R4:
R4(config)#router ospf 1
R4(config-router)#router-id 0.0.0.4
R4(config-router)#network 4.4.4.4 0.0.0.0 area 0
R4(config-router)#network 10.1.1.4 0.0.0.0 area 0
On All Routers:
Rx(config)#interface tunnel 1234
Rx(config-if)#ip ospf network non-broadcast
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 500
To verify the configuration:
On R1:
R1#show ip ospf neighbor
R1#
R1#show ip ospf interface brief
Interface
Lo0
Tu1234
PID
1
1
Area
0
0
IP Address/Mask
1.1.1.1/8
10.1.1.1/24
Cost
1
1000
State Nbrs F/C
LOOP 0/0
DR
0/0
IP Address/Mask
2.2.2.2/8
10.1.1.2/24
Cost
1
1000
State Nbrs F/C
LOOP 0/0
WAIT 0/0
IP Address/Mask
3.3.3.3/8
10.1.1.3/24
Cost
1
1000
State Nbrs F/C
LOOP 0/0
DR
0/0
On R2:
R2#show ip ospf neighbor
R2#
R2#sh ip ospf int br
Interface
PID
Area
Lo0
1
0
Tu1234
1
0
On R3:
R3#show ip ospf neighbor
R3#
R3#show ip ospf interface brief
Interface
PID
Area
Lo0
1
0
Tu1234
1
0
On R4:
R4#show ip ospf neighbor
R4#
R4#show ip ospf interface brief
Interface
PID
Area
IP Address/Mask
Cost
State Nbrs F/C
Lo0
Tu1234
1
1
0
0
4.4.4.4/8
10.1.1.4/24
1
1000
LOOP
DR
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
0/0
0/0
Page 501
Just as in Task 2 of the previous lab, no OSPF neighbor adjacencies have been formed by any of the routers at
this point. The reason this time is not because of the multicast capability of the DMVPN but due to the
network type configured on the tunnel interface.
Because the network type is set to non-broadcast, the routers will not even attempt to multicast OSPF hello
packets to discover neighbors. Instead, static neighbor commands should be configured for every router that
should become OSPF neighbors with each other. Doing so, enables unicast OSPF hello exchange between the
routers. The following executes this configuration:
On R1:
R1(config)#router ospf 1
R1(config-router)#neighbor 10.1.1.2
R1(config-router)#neighbor 10.1.1.3
R1(config-router)#neighbor 10.1.1.4
On R2, R3, and R4:
Rx(config)#router ospf 1
Rx(config-router)#neighbor 10.1.1.1
After performing the configuration above, the following output should be seen on R1 as the OSPF
adjacencies come up to all the spokes:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Tunnel1234 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.3 on Tunnel1234 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.4 on Tunnel1234 from LOADING to FULL,
Loading Done
The show ip ospf neighbor output verifies that all of the routers have establish the required neighbor
adjacencies:
On R1:
R1#show ip ospf neighbor
Neighbor ID
0.0.0.2
0.0.0.3
Pri
1
1
State
FULL/DROTHER
FULL/DROTHER
CCIE by Narbik Kocharians
Dead Time
00:01:51
00:01:57
Address
10.1.1.2
10.1.1.3
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Interface
Tunnel1234
Tunnel1234
Page 502
0.0.0.4
1
FULL/DR
00:01:44
10.1.1.4
Tunnel1234
Dead Time
00:01:50
Address
10.1.1.1
Interface
Tunnel1234
Dead Time
00:01:50
Address
10.1.1.1
Interface
Tunnel1234
Dead Time
00:01:50
Address
10.1.1.1
Interface
Tunnel1234
On R2:
R2#show ip ospf neighbor
Neighbor ID
0.0.0.1
Pri
1
State
FULL/BDR
On R3:
R3#show ip ospf neighbor
Neighbor ID
0.0.0.1
Pri
1
State
FULL/BDR
On R4:
R4#show ip ospf neighbor
Neighbor ID
0.0.0.1
Pri
1
State
FULL/BDR
All neighbors are up as expected. However, looking at the details of this command reveals a problem.
Looking at the output it is apparent that the non-broadcast network type still elects a DR/BDR on the
segment. Notice, R2, R3, and R4 all consider R1 to be the BDR on the LAN segment. If R1 is the BDR from
their perspectives and it is the only router to which they have an adjacency, that means R2, R3, and R4
believe themselves to be the DR. This fact is verified using show ip ospf interfaces | include DR command on
those routers:
On R2:
R2#show ip ospf interface | include DR
Transmit Delay is 1 sec, State DR, Priority 1
On R3:
R3#show ip ospf interface | include DR
Transmit Delay is 1 sec, State DR, Priority 1
On R4:
R4#show ip ospf interface | include DR
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 503
Transmit Delay is 1 sec, State DR, Priority 1
Since R2, R3, and R4 believe themselves to be DRs on the segment, they all flood a Type-2 network LSA just
like in Task 2 of the previous Lab. For the same reason as that previous task, R2, R3, and R4 need to be
disqualified from becoming DR or BDR using the ip ospf priority 0 command on their tunnel interfaces as
shown below:
On R2, R3, and R4:
Rx(config)#interface tunnel 1234
Rx(config-if)#ip ospf priority 0
To speed up the convergence process, the clear ip ospf process command is issued on all routers:
Rx#clear ip ospf process
Reset ALL OSPF processes? [no]: y
It may take some time for the adjacencies to come back up. In fact, it may take up to 120 seconds for OSPF
adjacencies to come up between routers. This is because of the default hello and dead interval configured on
the interfaces. OSPF non-broadcast network type has a default hello interval of 40 seconds and a dead
interval of 120 seconds. This means, when an interface configured as OSPF non-broadcast type first comes up
it waits 120 seconds for the DR/BDR election before proceeding with attempting to bring up a neighbor
adjacency.
Once the adjacencies come back up, the show ip route ospf | begin Gate command reveals everything is
working as intended:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [110/1001] via 10.1.1.2, 00:00:43, Tunnel1234
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [110/1001] via 10.1.1.3, 00:00:43, Tunnel1234
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [110/1001] via 10.1.1.4, 00:00:24, Tunnel1234
On R2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 504
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [110/1001] via 10.1.1.1, 00:01:08, Tunnel1234
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [110/1001] via 10.1.1.3, 00:01:08, Tunnel1234
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [110/1001] via 10.1.1.4, 00:00:45, Tunnel1234
On R3:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [110/1001] via 10.1.1.1, 00:01:37, Tunnel1234
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [110/1001] via 10.1.1.2, 00:01:27, Tunnel1234
4.0.0.0/32 is subnetted, 1 subnets
4.4.4.4 [110/1001] via 10.1.1.4, 00:01:02, Tunnel1234
On R4:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/32 is subnetted, 1 subnets
1.1.1.1 [110/1001] via 10.1.1.1, 00:01:26, Tunnel1234
2.0.0.0/32 is subnetted, 1 subnets
2.2.2.2 [110/1001] via 10.1.1.2, 00:01:26, Tunnel1234
3.0.0.0/32 is subnetted, 1 subnets
3.3.3.3 [110/1001] via 10.1.1.3, 00:01:26, Tunnel1234
The above output confirms all routes have been properly learned on all routers. It also reveals another
important facet of OSPF non-broadcast network type. Just like broadcast network type, OSPF non-broadcast
network type adds OSPF routes in the routing table with the router that has the link to the network in the
LSDB as the next hop. For example, In this case, R1’s router LSA has the network node 1.0.0.0/8. Since R1 is
directly connected to the 10.1.1.0/24 network segment (according to the network and router LSA flooded by
R1) all routers on that segment will use R1 as the next-hop to reach the network 1.0.0.0/8. The same is true
of R2 for the 2.0.0.0/8, R3 for the 3.0.0.0/8 and R4 for the 4.0.0.0/8 networks.
This behavior of setting the next hop to the router that owns the network node also carries the same
consequence as in the broadcast network type. In order to forward packets based on those routes, all routers
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 505
need to have full-mesh reachability to the next-hop IP overlay addresses. Using R4 as an example, pings are
issued to R1, R2, and R3 to verify reachability to their DMVPN tunnel IP addresses:
R4#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R4#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R4#ping 10.1.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R4 is unable to reach R2 or R3. This is because a static NHRP mapping does not exist on R4 for those DMVPN
tunnel IP addresses. R2 and R3 will have the same problem. They do not have reachability to each other or
R4 because there are no NHRP mappings for those routers. The answer to this problem is to once again
configure static NHRP mappings pointing to R1’s NBMA address to establish full-mesh connectivity between
the routers while maintaining spoke-hub-spoke traffic patterns:
On R4:
R4(config)#interface tunnel 1234
R4(config-if)#ip nhrp map 10.1.1.2 192.1.1.1
R4(config-if)#ip nhrp map 10.1.1.3 192.1.1.1
On R3:
R3(config)#interface tunnel 1234
R3(config-if)#ip nhrp map 10.1.1.2 192.1.1.1
R3(config-if)#ip nhrp map 10.1.1.4 192.1.1.1
On R2:
R2(config)#interface tunnel 1234
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 506
R2(config-if)#ip nhrp map 10.1.1.3 192.1.1.1
R2(config-if)#ip nhrp map 10.1.1.4 192.1.1.1
To verify the configuration:
The show ip nhrp command on the spokes below verifies the static NHRP mapping entries:
On R4:
R4#show ip nhrp
10.1.1.1/32 via 10.1.1.1
Tunnel1234 created 20:06:58, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
10.1.1.2/32 via 10.1.1.2
Tunnel1234 created 00:05:03, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
10.1.1.3/32 via 10.1.1.3
Tunnel1234 created 00:04:51, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
On R3:
R3#show ip nhrp
10.1.1.1/32 via 10.1.1.1
Tunnel1234 created 01:09:26, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
10.1.1.2/32 via 10.1.1.2
Tunnel1234 created 00:01:06, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
10.1.1.4/32 via 10.1.1.4
Tunnel1234 created 00:00:56, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
On R2:
R2#show ip nhrp
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 507
10.1.1.1/32 via 10.1.1.1
Tunnel1234 created 01:09:58, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
10.1.1.3/32 via 10.1.1.3
Tunnel1234 created 00:00:31, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
10.1.1.4/32 via 10.1.1.4
Tunnel1234 created 00:00:26, never expire
Type: static, Flags:
NBMA address: 192.1.1.1
After adding the appropriate mapping commands, connectivity is established between the routers by issuing
pings to the loopback interfaces:
On R2:
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms
R2#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
On R3:
R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 508
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
R3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
On R4:
R4#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R4#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R4#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
This section introduced the non-broadcast network type with the following characteristics:
1. All communication is unicast because broadcast communication is assumed not possible over the
NBMA
2. Disables multicast hellos for dynamic neighbor discovery. Instead, static neighbor commands should
be used to manually configure OSPF neighbor adjacencies
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 509
3. Next-hop IP address is set to the router that owns the LSA on the LAN segment
4. Hello interval is 30 seconds with a 120 second dead interval
5. Full-mesh unicast connectivity between routers is assumed
6. DR/BDR election is carried out. Routers that do not have full-mesh unicast connectivity to each other
should be disqualified from becoming DR/BDR by setting the OSPF priority to 0. This is achieved with
the ip ospf priority 0 command in interface configuration mode.
Task 2
Erase the startup configuration of the routers, the config.text file, and the VLAN.dat file
of each switch and reload the devices before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 510
Lab 4
OSPF point-to-point Networks
This lab should be conducted on the Enterprise POD.
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
OSPF folder  Lab-4.
Task 1
Configure OSPF on all routers and run their directly connected interfaces in Area 0,
based on the following policy:




The Loopback0 interfaces of these routers should be advertised with their correct
mask.
Use 0.0.0.1, 0.0.0.2, and 0.0.0.3 as the router IDs of R1, R2, and R3, respectively.
There should not be any DR/BDR election on any of the links.
Do not configure point-to-multipoint or point-to-multipoint non-broadcast on any of
the links.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 511
The previous two labs examined the OSPF broadcast and non-broadcast network types. This lab focuses
on the OSPF point-to-point network type. The task requirements above directly point out one important
difference between the point-to-point and broadcast/non-broadcast network types. Point three mentions
that no DR/BDR election should be held on any of the links. This is a direct reference to the DR/BDR
election that takes place on broadcast/non-broadcast network types.
Recall the reason DR/BDR elections occur in broadcast/non-broadcast network types is to optimize LSA
flooding and to designate which router is going to generate and flood the Type-2 network LSA that
represents the multi-access segment. For point-to-point network type, the assumption is that only two
routers are connected by a single link. In fact, an interface that has a network type of point-to-point can
only have a single OSPF neighbor connected to it. With only two routers directly connected by a link, there
is no need to create an entire node in the OSPF graph for that particular relationship. The two routers
simply model links to each other through their Type-1 router LSA.
This can be better seen through an example. The following is the configuration details to enable
OSPF on all routers. The router ID is set using the router-id command in OSPF router
configuration mode and OSPF is enabled on the ethernet and loopback 0 interfaces on the
routers. Also, to allow the loopback interfaces to be advertised with the proper subnet mask,
the network type is changed to point-to-point. Finally, the ethernet interfaces on each router
are switched from the default network type of broadcast to the point-to-point network type
using the command ip ospf network point-to-point:
On R1:
R1(config-if)#router ospf 1
R1(config-router)#router-id 0.0.0.1
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R1(config-router)#network 12.1.1.1 0.0.0.0 area 0
R1(config)#interface lo0
R1(config-if)#ip ospf network point-to-point
R1(config)#interface g0/2
R1(config-if)#ip ospf network point-to-point
On R2:
R2(config)#router ospf 1
R2(config-router)#router-id 0.0.0.2
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0
R2(config-router)#network 12.1.1.2 0.0.0.0 area 0
R2(config-router)#network 23.1.1.2 0.0.0.0 area 0
R2(config-router)#interface lo0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 512
R2(config-if)#ip ospf network point-to-point
R2(config)#interface g0/1
R2(config-if)#ip ospf network point-to-point
R2(config)#interface g0/3
R2(config-if)#ip ospf network point-to-point
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on GigabitEthernet0/1
LOADING to FULL, Loading Done
from
On R3:
R3(config)#router ospf 1
R3(config-router)#router-id 0.0.0.3
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
R3(config-router)#network 23.1.1.3 0.0.0.0 area 0
R3(config-router)#interface lo0
R3(config-if)#ip ospf network point-to-point
R3(config)#interface g0/2
R3(config-if)#ip ospf network point-to-point
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.2 on GigabitEthernet0/2
LOADING to FULL, Loading Done
from
The neighbor adjacencies come up after configuration because OSPF point-to-point uses multicast hello
for dynamic neighbor discovery. After configuring the above, the configuration is verified using the show
ip route and show ip ospf neighbor output on all routers:
On R1:
R1#show ip ospf neighbor
Neighbor ID
0.0.0.2
Pri
0
State
FULL/
-
Dead Time
00:00:33
Address
12.1.1.2
Interface
GigabitEthernet0/2
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 513
O
2.0.0.0/8 [110/2] via 12.1.1.2, 00:03:29, GigabitEthernet0/2
O
3.0.0.0/8 [110/3] via 12.1.1.2, 00:01:13, GigabitEthernet0/2
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/2] via 12.1.1.2, 00:03:29, GigabitEthernet0/2
O
On R2:
R2#show ip ospf neighbor
Neighbor ID
0.0.0.3
0.0.0.1
Pri
0
0
State
FULL/
FULL/
-
Dead Time
00:00:35
00:00:35
Address
23.1.1.3
12.1.1.1
Interface
GigabitEthernet0/3
GigabitEthernet0/1
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
1.0.0.0/8 [110/2] via 12.1.1.1, 00:05:19, GigabitEthernet0/1
3.0.0.0/8 [110/2] via 23.1.1.3, 00:03:17, GigabitEthernet0/3
On R3:
R3#show ip ospf neighbor
Neighbor ID
0.0.0.2
Pri
0
State
FULL/
-
Dead Time
00:00:37
Address
23.1.1.2
Interface
GigabitEthernet0/2
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
1.0.0.0/8 [110/3] via 23.1.1.2, 00:04:35, GigabitEthernet0/2
2.0.0.0/8 [110/2] via 23.1.1.2, 00:04:35, GigabitEthernet0/2
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/2] via 23.1.1.2, 00:04:35, GigabitEthernet0/2
The output above verifies the configuration is working as intended and also highlights some important
aspects of OSPF operation over point-to-point network types. First, the show ip route ospf | begin Gate
output reveals that the next-hop for OSPF routes reachable over a point-to-point interface is the remote
router’s IP address on the link. In case of R1, to reach the 3.0.0.0 network on R3, its next hop is R2 and not
R3. This is different from the broadcast/non-broadcast where the router that owned the LSA’s IP address
was the next hop.
Another difference between point-to-point and broadcast/non-broadcast network types in the outputs
above is in the show ip ospf neighbor output. The “State” column for each neighbor lists the state as
“FULL/ -”. This is further proof that a DR/BDR election was not held on the interface because it is a pointCCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 514
to-point interface. Otherwise, the state would’ve been “FULL/DR”, “FULL/BDR” or “FULL/DROTHER” in
accordance with what that neighbor has assumed on the LAN segment.
Because the links have been designated as point-to-point links, OSPF does not take the extra effort to
model a separate node for each ethernet segment. Instead, OSPF relies on mutual link descriptions in the
Type-1 router LSAs between the two neighbors. In the R1/R2 peering, for example, R1’s describes a link
connected to router ID 0.0.0.2 while R2 describes a link connected to router ID 0.0.0.1:
R1#show ip ospf database router 0.0.0.1
OSPF Router with ID (0.0.0.1) (Process ID 1)
Router Link States (Area 0)
LS age: 65
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.1
Advertising Router: 0.0.0.1
LS Seq Number: 80000004
Checksum: 0xCE0C
Length: 60
Number of Links: 3
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 0.0.0.2
(Link Data) Router Interface address: 12.1.1.1
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 12.1.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 10
R1# show ip ospf database router 0.0.0.2
OSPF Router with ID (0.0.0.1) (Process ID 1)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 515
Router Link States (Area 0)
LS age: 49
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.2
Advertising Router: 0.0.0.2
LS Seq Number: 80000006
Checksum: 0x5A12
Length: 84
Number of Links: 5
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.0.0.0
(Link Data) Network Mask: 255.0.0.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 0.0.0.3
(Link Data) Router Interface address: 23.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 23.1.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 0.0.0.1
(Link Data) Router Interface address: 12.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 12.1.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 10
Another special note is that the above output was retrieved from R1 alone. In OSPF, LSA information is
synchronized between routers in the same OSPF area. Because of this, it is not required to view
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 516
information about R1’s or R2’s Type-1 LSA from those routers directly. Any router in the area can look up
the LSA in their LSDB for verification and troubleshooting purposes. The highlighted section points out the
way R1 and R2 advertise their link to each other in the LSDB.
Since both routers are advertising a link to each other, the OSPF database implies a bidirectional link
adjacency between the two devices. This is all that is required to model the relationship between the two
routers in the LSDB. Also, point-to-point network types advertise the IP address assigned to each link as a
separate stub network. This way of modeling the link places the IP address as a node connected to the
router itself to act as a destination for SPF calculations.
The show ip ospf interface g0/2 | include Network|Hello command reveals some additional parameters
for the point-to-point network type:
On R1:
R1#show ip ospf interface g0/2 | include Network|Hello
Internet Address 12.1.1.1/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 0.0.0.1, Network Type POINT_TO_POINT, Cost: 1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:05
The output above indicates the default configuration on point-to-point interfaces. The hello interval
is 10 seconds with a 40 second dead interval.
The following summarizes the point-to-point
adjacency type:
1. Establishes adjacencies using multicast hello messages.
2. Hello/Dead timer of 10/30 by default
3. No DR/BDR election.
4. Next-hop points to the remote router on the Point-to-point link.
5. IP address assigned to the link is modeled as a separate IP address node attached to the
advertising router.
Task 2
Erase the startup configuration of the routers, the config.text file, and the VLAN.dat file
of each switch and reload the devices before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 517
Lab 5
OSPF Point-to-Multipoint and Point-toMultipoint Non-broadcast Networks
This lab should be conducted on the Enterprise POD.
Lab Setup:
To copy and paste the initial configurations, go to the Initial-config folder 
OSPF folder  Lab-5.
Task 1
Configure OSPF Area 0 on all links in the previous topology. The OSPF router IDs of all
routers should be 0.0.0.x, where x is the router number. If this configuration is performed
successfully, the routers in this topology should have full NLRI to every network in this
topology. The tunnel interface of these routers should not perform DR/BDR election.
This task presents a similar topology as in some of the previous labs. Here R1, R2, and R3 form a DMVPN. The
goal is for all routers to be able to reach all prefixes using OSPF. The first step towards this is to configure
OSPF peerings between the routers on their tunnel interfaces. The configuration, however, is more
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 518
complicated than just enabling OSPF on the interfaces using the network command. The task explicitly states
that no DR/BDR election should be performed.
The point-to-point network type was introduced in the last lab. In that lab, it was introduced that the pointto-point network type does not elect a DR/BDR when forming an adjacency. Since the task explicitly states
this election should not appear on the routers, it makes sense to configure this network type on the tunnel
interfaces.
The configuration below first enables OSPF point-to-point network type on the tunnel interface on all the
routers. Then it configures OSPF with the proper router-id and network statements:
On All routers:
Rx(config)#interface tunnel 123
Rx(config-if)#ip ospf netw point-to-point
On R1:
R1(config)#router ospf 1
R1(config-router)#router-id 0.0.0.1
R1(config-router)#network 10.1.1.1 0.0.0.0 area 0
On R2:
R2(config)#router ospf 1
R2(config-router)#router-id 0.0.0.2
R2(config-router)#network 10.1.1.2 0.0.0.0 area 0
R2(config-router)#network 23.1.1.2 0.0.0.0 area 0
On R3:
R3(config)#router ospf 1
R3(config-router)#router-id 0.0.0.3
R3(config-router)#network 10.1.1.3 0.0.0.0 area 0
R3(config-router)#network 23.1.1.3 0.0.0.0 area 0
To verify the configuration:
After performing the above, the show ip ospf neighbor command is used to verify the OSPF adjacencies:
On R1:
R1#show ip ospf neighbor
R1#
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 519
On R2:
R2#show ip ospf neighbor
Neighbor ID
0.0.0.3
Pri
1
State
FULL/DR
Dead Time
Address
00:00:31
23.1.1.3
Interface
GigabitEthernet0/3
On R3:
R3#show ip ospf neighbor
Neighbor ID
0.0.0.2
Pri
1
State
FULL/BDR
Dead Time
00:00:31
Address
23.1.1.3
Interface
GigabitEthernet0/2
The output on each router shows R2 and R3 have established an OSPF neighbor adjacency with each other
over their G0/3 and G0/2 interfaces respectively. This link is a broadcast network type and elects a DR/BDR.
There is no mention of a neighbor adjacency with R1 and R1 does not have a neighbor adjacency with R2 or
R3. This is because the DMVPN does not use dynamic NHRP multicast mappings as shown in the previous lab.
Without these NHRP multicast mappings, the routers cannot send the OSPF hello packets to each other. To
fix this, static multicast NHRP mappings are created on each router:
On R1:
R1(config)#interface tunnel 123
R1(config-if)#ip nhrp map multicast 192.1.2.2
R1(config-if)#ip nhrp map multicast 192.1.3.3
On R2 and R3:
Rx(config)#interface tunnel 123
Rx(config-if)#ip nhrp map multicast 192.1.1.1
After making this configuration change, the following log messages can be observed on the routers:
On R1:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.3 on Tunnel123 from EXCHANGE to DOWN,
Neighbor Down: Adjacency forced to reset
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Tunnel123 from EXCHANGE to DOWN,
Neighbor Down: Adjacency forced to reset
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.3 on Tunnel123 from EXCHANGE to DOWN,
Neighbor Down: Adjacency forced to reset
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 520
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Tunnel123 from EXCHANGE to DOWN,
Neighbor Down: Adjacency forced to reset
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.3 on Tunnel123 from EXCHANGE to DOWN,
Neighbor Down: Adjacency forced to reset
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Tunnel123 from EXCHANGE to DOWN,
Neighbor Down: Adjacency forced to reset
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.3 on Tunnel123 from EXCHANGE to DOWN,
Neighbor Down: Adjacency forced to reset
On R2 and R3:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
The outputs above may seem confusing at first. Basically, the OSPF adjacency between R1, R2, and R3 is
flapping. R1 is flapping between bringing up a neighbor adjacency with R2 and R3 on its Tunnel123 interface.
The reason this is a problem is because of the point-to-point network type. In point-to-point network types,
only a single OSPF neighbor can be connected to a single link. When R1 receives an OSPF hello from R2, R2
becomes its neighbor on that link and it models its Type-1 router LSA accordingly. Whenever R1 receives an
OSPF hello from R3 on the same link, it replaces the neighbor adjacency to R2 with a new adjacency to R3.
Then shortly after, R1 receives another OSPF hello from R2 and the process repeats itself.
For this hub-and-spoke DMVPN setup, R1 needs to be able to establish neighbor adjacencies with both R2
and R3 on the same Tunnel123 interface. This is where the point-to-multipoint network type becomes
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 521
useful. With point-to-multipoint network type, the R1 can model a neighbor relationship to both R2 and R3
over the same link. The following changes R1 to use point-to-multipoint network type on its Tunnel123
interface:
On R1:
R1(config)#interface tunnel 123
R1(config-if)#ip ospf network point-to-multipoint
After making the configuration change, the log messages stop but the show ip ospf neighbor output on R1
still does not list R2 and R3 as neighbors:
R1#show ip ospf neighbor
R1#
Multicast hellos are still being sent and received as normal evidenced by the show ip ospf traffic interface
tunnel123 command on R1 below:
R1#show ip ospf traffic tunnel 123
Interface Tunnel123
Last clearing of interface traffic counters never
OSPF packets received/sent
Type
Packets
RX Invalid
0
RX Hello
22823
RX DB des
27659
RX LS req
15
RX LS upd
31
RX LS ack
17
Bytes
0
1095432
995088
540
2604
768
RX Total
50545
TX Failed
0
TX Hello
22828
TX DB des
46672
TX LS req
113
TX LS upd
29
TX LS ack
25
TX Total
69667
(The rest of the output is omitted for brevity)
CCIE by Narbik Kocharians
2094432
0
1826064
4729268
6352
2604
1680
6565968
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 522
The output above shows the number of different types of OSPF packets that have been sent or received on
the interface. Observe the “RX Hello” and “TX Hello” counts above. When the counters are cleared using the
clear ip ospf traffic tunnel 123 command and then the counters are viewed again, it proves that the interface
is still receiving and sending hello packets:
R1#clear ip ospf traffic tunn 123
R1#show ip ospf traffic tunnel 123 | include clear|TX Hello|RX Hello
Last clearing of interface traffic counters 00:00:56
RX Hello
12
528
TX Hello
2
152
The debug ip ospf hello output on R1 can help decipher what is going on:
R1#debug ip ospf hello
OSPF hello debugging is on
OSPF-1 HELLO Tu123: Rcv hello from 0.0.0.2 area 0 10.1.1.2
OSPF-1 HELLO Tu123: Mismatched hello parameters from 10.1.1.2
OSPF-1 HELLO Tu123: Dead R 40 C 120, Hello R 10 C 30
OSPF-1 HELLO Tu123: Rcv hello from 0.0.0.3 area 0 10.1.1.3
OSPF-1 HELLO Tu123: Mismatched hello parameters from 10.1.1.3
OSPF-1 HELLO Tu123: Dead R 40 C 120, Hello R 10 C 30
According to the debug above, R1 is rejecting the hellos received from R2 and R3 because of a mismatched
hello and dead interval timers. R2 and R3 appear to be advertising hello and dead timers of 10/120 while R1
is advertising a hello and dead timer of 30/120. This is confirmed using the show ip ospf interface tunnel 123
| include Network Type|Timer output below:
On R1:
R1#show ip ospf interface tunnel 123 | include Network Type|Timer
Process ID 1, Router ID 0.0.0.1, Network Type POINT_TO_MULTIPOINT, Cost:
1000
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
On R2:
R2#show ip ospf interface tunnel 123 | include Network Type|Timer
Process ID 1, Router ID 0.0.0.2, Network Type POINT_TO_POINT, Cost: 1000
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 523
On R3:
R3#show ip ospf interface tunnel 123 | include Network Type|Timer
Process ID 1, Router ID 0.0.0.3, Network Type POINT_TO_POINT, Cost: 1000
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
The output above shows that for point-to-multipoint network type, the default hello/dead timer is 30/120
while for point-to-point network types the default hello/dead timer is 10/40. In order for two OSPF routers
to become neighbors, the hello and dead timers must match. To remedy this, the hello/dead interval can be
modified on R1 or R2/R3. This lab adjusts the Hello/Dead intervals on R2/R3 to 30/120 to match the point-tomultipoint network type on R1 defaults:
On R2 and R3:
Rx(config)#interface tunnel 123
Rx(config-if)#ip ospf hello-interval 30
! Setting the hello-interval automatically adjusts the dead interval to four time the hello
interval
On R1:
R1#show ip ospf neighbor
Neighbor ID
0.0.0.3
0.0.0.2
Pri
0
0
State
FULL/
FULL/
-
Dead Time
00:01:41
00:01:36
Address
10.1.1.3
10.1.1.2
Interface
Tunnel123
Tunnel123
State
FULL/DR
FULL/ -
Dead Time
00:00:39
00:01:50
Address
23.1.1.3
10.1.1.1
Interface
GigabitEthernet0/3
Tunnel123
Dead Time
00:00:38
00:01:46
Address
23.1.1.2
10.1.1.1
Interface
GigabitEthernet0/2
Tunnel123
On R2:
R2#show ip ospf neighbor
Neighbor ID
0.0.0.3
0.0.0.1
Pri
1
0
On R3:
R3#show ip ospf neighbor
Neighbor ID
0.0.0.2
0.0.0.1
Pri
1
0
State
FULL/BDR
FULL/ -
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 524
The show ip route ospf | begin Gate command reveals all routes are learned by all routers. It also reveals
another interesting feature:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/1001] via 10.1.1.3, 00:02:43, Tunnel123
[110/1001] via 10.1.1.2, 00:03:13, Tunnel123
On R2:
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
10.1.1.1/32 [110/1000] via 10.1.1.1, 00:03:44, Tunnel123
On R3:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
10.1.1.1/32 [110/1000] via 10.1.1.1, 00:03:35, Tunnel123
In the above, the next-hop address for all prefixes learned over the DMVPN have the next-hop of the
neighbor from which the router that owns the route. In addition, R2 and R3 install a host route to R1’s tunnel
IP address. This is installed as a side-effect of the point-to-multipoint network type configured on R1. This is
better seen through the show ip ospf database router self-originate command on R1:
On R1:
R1#show ip ospf database router self-originate
OSPF Router with ID (0.0.0.1) (Process ID 1)
Router Link States (Area 0)
LS age: 970
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 525
Advertising Router: 0.0.0.1
LS Seq Number: 80000022
Checksum: 0x28C7
Length: 60
Number of Links: 3
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 0.0.0.3
(Link Data) Router Interface address: 10.1.1.1
Number of MTID metrics: 0
TOS 0 Metrics: 1000
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 0.0.0.2
(Link Data) Router Interface address: 10.1.1.1
Number of MTID metrics: 0
TOS 0 Metrics: 1000
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 0
R1 models two point-to-point links in its Type-1 Router LSA it sends to R2 and R3. This describes that it has a
link to the two other routers over the same interface Tunnel 123. In addition, R1 models a link to a point-topoint stub network with the IP address/mask of 10.1.1.1 255.255.255.255. This is R1’s tunnel interface IP
address. Let’s contrast this with R2’s point-to-point description:
On R2:
R2#show ip ospf database router self-originate | begin another Router
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 0.0.0.1
(Link Data) Router Interface address: 10.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1000
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.1.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1000
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 526
R2 models the same point-to-point link to R1, but instead of a /32 host route, it models a link to the entire
network 10.1.1.0/24. The reason for this difference is because of the assumptions made about the network
in a point-to-multipoint network.
In Point-to-multipoint, there is no DR/BDR that creates a network node for the segment as with broadcast or
non-broadcast network types. Instead, each router models an individual link to each router with which it has
direct connectivity over the multi-access network. This connectivity is verified by multicast hello exchange
over the multi-access segment. This contrasts the broadcast and non-broadcast network types where all
devices connected to the multi-access segment were assumed to have direct connectivity with each other
and were modeled as all being connected to the network node.
Point-to-multipoint makes no assumptions about connectivity between routers on the multi-access segment.
To account for those routers that do not have direct connectivity, the local router also advertises its IP
address on the multiaccess segment as a /32 host route. This allows routers lacking direct connectivity with
it, to solve a path through another router to reach the local router. For this reason, Point-to-multipoint
network types are great for partial-mesh hub-and-spoke topologies like DMVPN. The /32 host route allows
spoke-hub-spoke network traffic over the DMVPN without manually configuring a static NHRP map. This
requires point-to-multipoint to be configured on all routers in the DMVPN.
To comply with this, the DMVPN tunnel interface on R2 and R3 are also configure for point-to-multipoint
network type:
On R2 and R3:
R2(config)#interface tunnel 123
R2(config-if)#ip ospf network point-to-multipoint
You should see the following console messages:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from FULL to DOWN,
Neighbor Down: Interface down or detached
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Tunnel123 from LOADING to FULL,
Loading Done
After configuring point-to-multipoint on R2 and R3, the following shows the resulting routing tables on all the
routers:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 527
O
O
10.1.1.2/32 [110/1000] via 10.1.1.2, 00:02:20, Tunnel123
10.1.1.3/32 [110/1000] via 10.1.1.3, 00:01:21, Tunnel123
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/1001] via 10.1.1.3, 03:08:09, Tunnel123
[110/1001] via 10.1.1.2, 03:08:39, Tunnel123
O
On R2:
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
10.1.1.1/32 [110/1000] via 10.1.1.1, 03:09:58, Tunnel123
10.1.1.3/32 [110/1] via 23.1.1.3, 00:02:41, GigabitEthernet0/3
O
O
On R3:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
10.1.1.1/32 [110/1000] via 10.1.1.1, 03:10:01, Tunnel123
10.1.1.2/32 [110/1] via 23.1.1.2, 00:04:12, GigabitEthernet0/2
The highlighted output above confirms that host routes are installed for the other routers attached to
the DMVPN. The following summarizes point-to-multipoint network types:
-
Establishes adjacencies using multicast hello messages.
Hello/Dead timer of 30/120 by default.
No DR/BDR election. Instead, models actual underlying connectivity instead of assuming all
routers can reach each other like in broadcast or non-broadcast network types.
Next-hop points to the remote neighbor used to reach the prefix.
The IP address assigned to the link is modeled as a /32 host route.
Task 2
Since R2’s connection to the cloud is 10 Mbps and R3’s connection is 100 Mbps, R1
should not perform equal-cost load sharing. R1 should go through R3 to reach network
23.1.1.0/24. Do not configure PBR or the IP ospf cost command to accomplish this task.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 528
This task makes mention to a very common scenario when it comes to hub-and-spoke topologies especially
over WAN connections. That is that some spoke routers may have slower connection speeds across the WAN
link. In this scenario, the hub router needs to be able to choose the faster connection when trying to reach
networks shared by two spoke routers.
In this task, R2 and R3 both have connection to the 23.1.1.0/24 network. The only difference is R2’s
connection is 10 Mbps while R3’s connection is 100Mbps. R1 should choose R3 to reach this network and
NOT perform equal cost load sharing as it is currently doing. This is evidenced by the show ip route ospf |
begin Gate command below:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
10.1.1.2/32 [110/1000] via 10.1.1.2, 00:06:46, Tunnel123
10.1.1.3/32 [110/1000] via 10.1.1.3, 00:05:47, Tunnel123
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/1001] via 10.1.1.3, 03:12:35, Tunnel123
[110/1001] via 10.1.1.2, 03:13:05, Tunnel123
The task forbids configuring ip ospf cost commands or using PBR to complete the task. Another option is to
take advantage of the OSPF neighbor command. The neighbor command can configure manual costs values
to add to LSAs learned from a specific neighbor using the cost parameter. If R1 is configured with static
neighbor commands for R2 and R3 where the cost parameter to R2 is higher than R3, it will automatically
prefer R3’s route to 23.1.1.0/24. Unfortunately, this command only works on non-broadcast network types.
There is another operating mode for Point-to-multipoint connections. Since Point-to-multipoint was designed
to work on various multi-access network types, it also has a non-broadcast variant called point-to-multipoint
non-broadcast. In this mode, OSPF does not multicast hellos or any other OSPF packets out of the point-tomultipoint non-broadcast interface. This means neighbor commands become essential to establishing proper
OSPF adjacencies, allowing the use of the cost manipulation as described in the previous paragraph.
To implement this configuration, the following changes are made on all routers:
● Network type on the DMVPN tunnel interface is changed to point-to-multipoint non-broadcast
● Static neighbor commands are used for the R1/R2 and R1/R3 neighbor adjacencies.
● On R1, the cost assigned to the neighbor R2 is set to 20 while the cost set to neighbor R3 is 1
On All Routers:
Rx(config)#interface tunnel 123
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 529
Rx(config-if)#ip ospf network point-to-multipoint non-broadcast
On R1:
R1(config)#router ospf 1
R1(config-router)#neighbor 10.1.1.2 cost 20
R1(config-router)#neighbor 10.1.1.3 cost 1
After configuration the routing table on R1 confirms that R3 is being used to reach that network:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
10.1.1.2/32 [110/2] via 10.1.1.3, 00:00:49, Tunnel123
10.1.1.3/32 [110/1] via 10.1.1.3, 00:00:49, Tunnel123
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/2] via 10.1.1.3, 00:00:49, Tunnel123
The point-to-multipoint non-broadcast network type follows the same procedures as the regular point-tomultipoint network type except for the following:
1. Does not unicast hello or other protocol packets
2. Requires static neighbor commands to establish OSPF adjacencies
Task 3
Erase the startup configuration of the routers, the config.text file, and the VLAN.dat file
of each switch and reload the devices before proceeding to the next lab.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 530
Lab 6
OSPF Area Types
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 531
This lab should be conducted on the Enterprise POD.
Lab Setup:
Save the startup configuration on SW3 and reload before proceeding with this lab.
To copy and paste the initial configurations, go to the Initial-config folder 
OSPF folder  Lab-6.
Lab rules:


All loopback interfaces are configured with ip ospf network point-to-point.
Configure the OSPF router IDs of the routers based on the following chart:
R1: 0.0.0.1
R4: 0.0.0.4
R7: 0.0.0.7
SW2: 0.0.0.22
SW5: 0.0.0.55
R2: 0.0.0.2
R5: 0.0.0.5
R8: 0.0.0.8
SW3: 0.0.0.33
R3: 0.0.0.3
R6: 0.0.0.6
SW1: 0.0.0.11
SW4: 0.0.0.44
Task 1
Configure the Lo0 and G0/4 interfaces of R5 and G0/5 and the Lo0 interface of R4 in
Area 1.
This lab focuses on introducing the concept of OSPF areas. Up to this point, OSPF has been demonstrated in
single-area designs. As the network grows, routers and networks are added to the OSPF topology database.
Each additional router and network create a new entry in the LSDB and adds another router to which LSDB
information needs to be synchronized. At a certain point, the size of the LSDB makes it difficult to calculate
shortest-path trees efficiently and the maintenance required via periodic flooding of LSAs and creation of
new LSAs causes significant burden on the OSPF routers.
For this reason, OSPF allows the topology to be broken up into different areas. An OSPF area is composed of
a set of router links that are logically grouped into the same subdomain. All routers with links within an area
maintain an area specific LSDB. Each area LSDB contains the intra-area links within the area. These links are
described in Type-1 router and Type-2 network LSAs. If a change occurs in the intra-area links, only the area
where the change occurred is involved with the flooding of new link-state information. Routers that do not
have interfaces within the affected area are not bothered with the change. Areas are identified using 32-bit
numbers.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 532
With this area paradigm, a router can exist in one of two states in the overall OSPF domain. It either has all of
its links in one area or it has multiple links in different areas. The former is called an internal router because
all of the router links exist in a single area. The latter is called an area border router or ABR. This is because
the router sits on the border between two or more areas. The ABR distinction in this sense is a literal
distinction rather than a logical one, the difference between which will be made clear in later tasks.
So, the design of the OSPF domain is such that internal routers connect to area border routers that provide
connection between different OSPF areas, linking the domain together. ABRs maintain an LSDB for each area
in which they have an active link adjacency. Thus, ABRs should be more capable routers that have better
processing and memory to store the different LSDBs.
In order to make OSPF more loop-resistant, it imposes a very specific design requirement. All areas
must be connected to routers that are connected to a special area known as the backbone area or
Area 0. This design forces a hub-and-spoke hierarchy in the OSPF domain. If two areas need to
transit traffic to each other, the traffic is pulled from one area (a spoke area) through the backbone
area (the hub) before reaching the destination area (the other spoke). It is from this backbone area
that inter-area routing information is flooded between other connected areas by functional ABRs.
There are many special types of areas in OSPF that can be employed depending on what type of connectivity
is required. The following lab tasks set up and explore the functions and qualifications of each area type.
In this case, the network command configuration style is utilized. The network commands configured below
in OSPF router configuration mode enables OSPF for Area 1 on the G0/5 and G0/4 interfaces on R4 and R5
respectively. As required by the task the network command on these routers is also configured to advertise
their loopback 0 interfaces into OSPF area 1. Lastly, the OSPF router ID is manually set as indicated with the
router-id command:
On R4:
R4(config)#router ospf 1
R4(config-router)#router-id 0.0.0.4
R4(config-router)#network 40.4.0.4 0.0.0.0 area 1
R4(config-router)#network 45.1.1.4 0.0.0.0 area 1
On R5:
R5(config)#router ospf 1
R5(config-router)#router-id 0.0.0.5
R5(config-router)#network 50.5.0.5 0.0.0.0 area 1
R5(config-router)#network 45.1.1.5 0.0.0.0 area 1
You should see the following console message:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 533
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.4 on GigabitEthernet0/4 from LOADING
to FULL, Loading Done
To verify the configuration:
The show ip route ospf command on both routers verify the OSPF routes they
learn from each other:
On R4:
R4#show ip route ospf | begin Gate
Gateway of last resort is not set
O
50.0.0.0/32 is subnetted, 1 subnets
50.5.0.5 [110/2] via 45.1.1.5, 00:00:43, GigabitEthernet0/5
On R5:
R5#show ip route ospf | begin Gate
Gateway of last resort is not set
O
40.0.0.0/24 is subnetted, 1 subnets
40.4.0.0 [110/2] via 45.1.1.4, 00:01:14, GigabitEthernet0/4
Task 2
Configure the G0/0 and Lo0 interfaces of R8 and the VLAN58 interface of SW5 in Area 2.
The following configures OSPF adjacency for Area 2 between R8 and SW5. First, the router-ID on both
devices is manually set with the router-id command. The network command under the OSPF router
configuration mode enables OSPF on the G0/0 and VLAN 58 interface on R8 and SW5 respectively. The
network command is also used to advertise the loopback 0 interface on R8 into OSPF area 2:
On R8:
R8(config)#router ospf 1
R8(config-router)#router-id 0.0.0.8
R8(config-router)#network 58.1.1.8 0.0.0.0 area 2
R8(config-router)#network 8.8.8.8 0.0.0.0 area 2
On SW5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 534
SW5(config)#router ospf 1
SW5(config-router)#router-id 0.0.0.55
SW5(config-router)#network 58.1.1.55 0.0.0.0 area 2
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.8 on Vlan58 from LOADING to FULL,
Loading Done
To verify the configuration:
The show ip route ospf command from SW5 below verifies the OSPF routes it learns from
R8:
On SW5:
SW5#show ip route ospf | begin Gate
Gateway of last resort is not set
O
8.0.0.0/24 is subnetted, 1 subnets
8.8.8.8 [110/2] via 58.1.1.8, 00:00:56, Vlan58
Task 3
Configure the following interfaces for OSPF Area 3:



E6/0 interface on SW4
E6/0, E5/0, and Loopback0 interfaces on SW3
E5/0 interface on SW5
Ensure that SW4 is configured to redistribute its Loopback0 through Loopback9 interfaces
into this routing domain.
SW4 is first configured for OSPF. The router-id is manually set to 0.0.0.44 as indicated in the task. The
network command is then issued to enable OSPF on the E6/0 interface for Area 3.
NOTE: The switches being used in this lab have ip routing turned on by default. However, on certain Layer
3 switching platforms, this feature is disabled by default. In such a case, ip routing would need to be
enabled with the ip routing command to allow the Layer 3 switch to perform IP routing functions.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 535
On SW4:
SW4(config)#router ospf 1
SW4(config-router)#router-id 0.0.0.44
SW4(config-router)#network 34.1.1.44 0.0.0.0 area 3
The next part of the task involves redistribution of the directly connected loopback interface networks
into OSPF on R8. These loopback interfaces are not matched by a network command in the OSPF router
configuration. As such, their networks need to be imported into OSPF. Networks imported in this way are
referred to as external routes in OSPF and are imported using the redistribute command in router OSPF
configuration mode. This process of distributing networks that are not explicitly enabled for a particular
routing protocol is called route redistribution. When performing route redistribution OSPF uses a Type-5
External LSA to advertise the external networks as nodes connected to the router performing the
redistribution. The redistributing router becomes what is known as an Autonomous System Boundary
Router (ASBR). More about ASBRs is explained in later tasks.
For this task, to redistribute the loopback 0 through 9 interfaces into OSPF on SW4, a route-map TST is
first created on SW4. The match interface command under the route-map configuration mode is then
issued to identify the loopback interfaces:
SW4(config)#route-map TST
SW4(config-route-map)#match interface lo0 lo1 lo2 lo3 lo4 lo5 lo6 lo7 lo8 lo9
Following the above, the redistribute connected route-map TST subnets command under the OSPF router
configuration mode can be now issued on SW4. This ensures that only the interfaces specified in the
route-map TST are redistributed into the OSPF domain.
SW4(config)#router ospf 1
SW4(config-router)#redistribute connected route-map TST subnets
NOTE: In some IOS versions, the subnets keyword must be added to the end of redistribute statements in
OSPF. Without this command, the router will only redistribute connected networks that are not subnetted
into OSPF. In other words, only connected networks that fall on classful boundaries. Applied to the subnets
in this lab, with those IOS versions, this behavior would result in no loopbacks being redistributed into
OSPF. This lab uses IOS 15.6(2)T that automatically adds the subnets keyword to the redistribute
statement. The lab configurations include the subnets keyword for consistency and ease of understanding.
The show ip ospf database command output on SW4 can be used to verify the redistribution. Notice the
Type-5 LSAs created by SW4 for the loopbacks 0 through 9:
SW4#show ip ospf database
OSPF Router with ID (0.0.0.44) (Process ID 1)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 536
Router Link States (Area 3)
Link ID
ADV Router
Age
Seq#
Checksum Link count
0.0.0.44
0.0.0.44
9
0x80000002 0x00DECA 1
Type-5 AS External Link States
Link ID
104.104.0.0
104.104.1.0
104.104.2.0
104.104.3.0
104.104.4.0
104.104.5.0
104.104.6.0
104.104.7.0
104.104.8.0
104.104.9.0
ADV Router
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
Age
8
8
8
8
8
8
8
8
8
8
Seq#
Checksum Tag
0x80000001 0x00ACF6 0
0x80000001 0x00A101 0
0x80000001 0x00960B 0
0x80000001 0x008B15 0
0x80000001 0x00801F 0
0x80000001 0x007529 0
0x80000001 0x006A33 0
0x80000001 0x005F3D 0
0x80000001 0x005447 0
0x80000001 0x004951 0
Next part of the task involves enabling OSPF on SW3. As stated in the task, the E6/0, E5/0 and the
loopback 0 interfaces on SW3 are enabled for OSPF Area 3 with the network command. The OSPF router
ID is also manually set to 0.0.0.33 with the router-id command:
On SW3:
SW3(config)#router ospf 1
SW3(config-router)#router-id 0.0.0.33
SW3(config-router)#network 33.33.33.33 0.0.0.0 area 3
SW3(config-router)#network 34.1.1.33 0.0.0.0 area 3
SW3(config-router)#network 35.1.1.33 0.0.0.0 area 3
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.44 on Ethernet6/0 from LOADING to
FULL, Loading Done
Finally, OSPF is enabled on SW5. The network command enables OSPF for Area 3 on SW5’s E5/0 interface:
On SW5:
SW5(config)#router ospf 1
SW5(config-router)#network 35.1.1.55 0.0.0.0 area 3
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 537
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.33 on Ethernet5/0 from LOADING to
FULL, Loading Done
A show ip route ospf command is issued on SW5. The output verifies the OSPF routes it learns from SW3
including the external routes redistributed by SW4 into OSPF:
To verify the configuration:
SW5#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
8.0.0.0/24 is subnetted, 1 subnets
8.8.8.0 [110/2] via 58.1.1.8, 00:12:47, Vlan58
33.0.0.0/24 is subnetted, 1 subnets
33.33.33.0 [110/11] via 35.1.1.33, 00:01:15, Ethernet5/0
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.0.0.0/24 is subnetted, 10 subnets
104.104.0.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.1.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.2.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.3.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.4.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.5.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.6.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.7.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.8.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
104.104.9.0 [110/20] via 35.1.1.33, 00:01:15, Ethernet5/0
Task 4
Configure the following interfaces in Area 4:
1. R7’s G0/9 interface
2. SW2’s Lo0, E1/3, and E0/3 interfaces
3. R3’s G0/9 interface
Ensure that R7 is configured to redistribute the networks on its Loopback0 through
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 538
Loopback9 interfaces into this routing domain.
Similar to Task 3, to perform the redistribution on R7, a route-map called TST is first created. The match
interface command under the route-map identifies the loopbacks that should be redistributed into OSPF.
These are the loopback 0 - 9 interfaces:
On R7:
R7(config)#route-map TST
R7(config-route-map)#match interface Lo0 lo1 lo2 lo3 lo4 lo5 lo6 lo7 lo8 lo9
Next, R7 is configured for OSPF. The router ID is manually set to 0.0.0.7 with the router-id command. The
network statement under the OSPF router configuration mode enables OSPF for Area 4 on it’s G0/9 interface.
The redistribute connected route-map TST subnets command ensures the redistribution of the prefixes
identified in the route-map into the OSPF domain:
R7(config)#router ospf 1
R7(config-router)#router-id 0.0.0.7
R7(config-router)#network 27.1.1.7 0.0.0.0 area 4
R7(config-router)#redistribute connected route-map TST subnets
The show ip ospf database output on R7 verifies the new external routes have been added to the LSDB
R7#show ip ospf database
OSPF Router with ID (0.0.0.7) (Process ID 1)
Router Link States (Area 4)
Link ID
0.0.0.7
ADV Router
0.0.0.7
Age
6
Seq#
Checksum Link count
0x80000002 0x005DA6 1
Type-5 AS External Link States
Link ID
111.111.0.0
111.111.1.0
111.111.2.0
111.111.3.0
111.111.4.0
111.111.5.0
111.111.6.0
111.111.7.0
ADV Router
0.0.0.7
0.0.0.7
0.0.0.7
0.0.0.7
0.0.0.7
0.0.0.7
0.0.0.7
0.0.0.7
CCIE by Narbik Kocharians
Age
5
5
5
5
5
5
5
5
Seq#
Checksum Tag
0x80000001 0x00DBDE 0
0x80000001 0x00D0E8 0
0x80000001 0x00C5F2 0
0x80000001 0x00BAFC 0
0x80000001 0x00AF07 0
0x80000001 0x00A411 0
0x80000001 0x00991B 0
0x80000001 0x008E25 0
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 539
111.111.8.0
111.111.9.0
0.0.0.7
0.0.0.7
5
5
0x80000001 0x00832F 0
0x80000001 0x007839 0
Next, OSPF is configured on SW2. As stated in the lab rules, the OSPF router ID is manually set to 0.0.0.22. The
network command enables and runs OSPF on the interfaces specified:
On SW2:
SW2(config)#router ospf 1
SW2(config-router)#router-id 0.0.0.22
SW2(config-router)#network 22.22.22.22 0.0.0.0 area 4
SW2(config-router)#network 27.1.1.22 0.0.0.0 area 4
SW2(config-router)#network 23.1.1.22 0.0.0.0 area 4
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.7 on Ethernet1/3 from LOADING to
FULL, Loading Done
Lastly, OSPF for Area 4 is enabled on R3’s G0/9 interface with the network command. The router ID is
manually set to 0.0.0.3:
On R3:
R3(config)#router ospf 1
R3(config-router)#router-id 0.0.0.3
R3(config-router)#network 23.1.1.3 0.0.0.0 area 4
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.22 on GigabitEthernet0/9 from LOADING
to FULL, Loading Done
After completing the above, the show ip route ospf output on R3 verifies the OSPF routes it learns from SW2
including the routes redistributed at R7 into OSPF. These appear as OSPF external routes as highlighted on R3
below:
R3#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
22.0.0.0/24 is subnetted, 1 subnets
22.22.22.0 [110/2] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
27.0.0.0/24 is subnetted, 1 subnets
27.1.1.0 [110/11] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 540
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
111.0.0.0/24 is subnetted, 10 subnets
111.111.0.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.1.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.2.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.3.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.4.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.5.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.6.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.7.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.8.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
111.111.9.0 [110/20] via 23.1.1.22, 00:01:21, GigabitEthernet0/9
Task 5
Configure the following interfaces in Area 5:



R6’s G0/0 interface
SW1’s Lo0, E1/2, and E0/2 interfaces
R2’s Loopback0 through Loopback2 and G0/0 interfaces
Ensure that R6 is configured to redistribute its Loopback0 through Loopback9 interfaces
into this routing domain.
Once again, first a route-map named TST is created on R6 where the match interface command identifies the
loopbacks that are to be redistributed into OSPF:
On R6:
R6(config)#route-map TST
R6(config-route-map)#match interface lo0 lo1 lo2 lo3 lo4 lo5 lo6 lo7 lo8
lo9
Next, OSPF is enabled on R6’s G0/0 interface for Area 5 with the network command. The router ID is also
manually set to 0.0.0.6 with the router-id command. Finally, the redistribute connected route-map TST
subnets command is configured to redistribute the loopback interfaces identified in the route-map into
OSPF:
R6(config)#router ospf 1
R6(config-router)#router-id 0.0.0.6
R6(config-router)#network 16.1.1.6 0.0.0.0 area 5
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 541
R6(config-router)#redistribute connected route-map TST subnets
The show ip ospf database output verifies the external routes have been added to the LSDB on R6:
R6#show ip ospf database
OSPF Router with ID (0.0.0.6) (Process ID 1)
Router Link States (Area 5)
Link ID
0.0.0.6
ADV Router
0.0.0.6
Age
25
Seq#
Checksum Link count
0x80000002 0x0020F0 1
Type-5 AS External Link States
Link ID
60.1.0.0
60.1.1.0
60.1.2.0
60.1.3.0
60.1.4.0
60.1.5.0
60.1.6.0
60.1.7.0
60.1.8.0
60.1.9.0
ADV Router
0.0.0.6
0.0.0.6
0.0.0.6
0.0.0.6
0.0.0.6
0.0.0.6
0.0.0.6
0.0.0.6
0.0.0.6
0.0.0.6
Age
22
22
22
22
22
22
22
22
22
22
Seq#
Checksum Tag
0x80000001 0x00A8B4 0
0x80000001 0x009DBE 0
0x80000001 0x0092C8 0
0x80000001 0x0087D2 0
0x80000001 0x007CDC 0
0x80000001 0x0071E6 0
0x80000001 0x0066F0 0
0x80000001 0x005BFA 0
0x80000001 0x005005 0
0x80000001 0x00450F 0
The next part of this configuration enables OSPF on SW1. As stated in the task, OSPF for Area 5 is enabled on
E1/2, E0/2 and loopback 0 interfaces. The OSPF router ID on SW1 is manually set to 0.0.0.11:
On SW1:
SW1(config)#router ospf 1
SW1(config-router)#router-id 0.0.0.11
SW1(config-router)#network 11.11.11.11 0.0.0.0 area 5
SW1(config-router)#network 112.1.1.11 0.0.0.0 area 5
SW1(config-router)#network 16.1.1.11 0.0.0.0 area 5
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.6 on Ethernet1/2 from LOADING to
FULL, Loading Done
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 542
Finally, R2 is configured for OSPF. The network command enables OSPF on the interfaces specified in the
task. The router ID is also manually set to 0.0.0.2 as stated:
On R2:
R2(config)#router ospf 1
R2(config-router)#router-id 0.0.0.2
R2(config-router)#network 20.2.0.2 0.0.0.0 area 5
R2(config-router)#network 20.2.1.2 0.0.0.0 area 5
R2(config-router)#network 20.2.2.2 0.0.0.0 area 5
R2(config-router)#network 112.1.1.2 0.0.0.0 area 5
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.11 on GigabitEthernet0/0 from LOADING
to FULL, Loading Done
The show ip route ospf command output on R2 verifies the learned OSPF internal and external routes:
R2#show ip route ospf | begin Gate
Gateway of last resort is not set
O
O
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/2] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
16.0.0.0/24 is subnetted, 1 subnets
16.1.1.0 [110/11] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.0.0.0/24 is subnetted, 10 subnets
60.1.0.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.1.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.2.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.3.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.4.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.5.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.6.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.7.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.8.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
60.1.9.0 [110/20] via 112.1.1.11, 00:01:08, GigabitEthernet0/0
Task 6
Configure the following interfaces in Area 0:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 543





R1’s Loopback0 through Loopback9, G0/0, G0/3, and G0/2 interfaces
 R1 must be configured to redistribute its Lo10–Lo19 in this routing domain.
R4’s G0/0 interface
SW5’s VLAN145 and Loopback0 interfaces
R3’s G0/1 and Loopback 0 interfaces
R2’s G0/1 interface
Restrictions:



R4 should not use a network command to run its G0/0 interface in Area 0.
This router should not advertise any secondary IP address/es configured under its
G0/0 interface.
Do not configure any kind of filtering to accomplish this task.
Similar to earlier tasks, a route-map called TST is first created on R1. Loopback interfaces 10 - 19 are matched
in this route-map with the match interface command:
On R1
R1(config)#route-map TST
R1(config-route-map)#match interface lo10 lo11 lo12 lo13 lo14 lo15 lo16
lo17 lo18 lo19
OSPF is then configured on R1. The network command is used to enable OSPF for Area 0 on it’s G0/0, G0/3
and G0/2 interfaces. The network command is also used to advertise loopback 0 through 9 into OSPF. The
OSPF router ID is manually set to 0.0.0.1 with the router-id command. Finally, the loopback interfaces
matched in the route-map TST are redistributed into OSPF with the redistribute connected route-map TST
subnets command:
R1(config)#router ospf 1
R1(config-router)#router-id 0.0.0.1
R1(config-router)#network 145.1.1.1 0.0.0.0 area 0
R1(config-router)#network 13.1.1.1 0.0.0.0 area 0
R1(config-router)#network 12.1.1.1 0.0.0.0 area 0
R1(config-router)#network 10.1.0.1 0.0.0.0 area 0
R1(config-router)#network 10.1.1.1 0.0.0.0 area 0
R1(config-router)#network 10.1.2.1 0.0.0.0 area 0
R1(config-router)#network 10.1.3.1 0.0.0.0 area 0
R1(config-router)#network 10.1.4.1 0.0.0.0 area 0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 544
R1(config-router)#network 10.1.5.1 0.0.0.0 area 0
R1(config-router)#network 10.1.6.1 0.0.0.0 area 0
R1(config-router)#network 10.1.7.1 0.0.0.0 area 0
R1(config-router)#network 10.1.8.1 0.0.0.0 area 0
R1(config-router)#network 10.1.9.1 0.0.0.0 area 0
R1(config-router)#redistribute connected route-map TST subnets
The show ip ospf database output verifies the redistribution on R1:
R1#show ip ospf database
OSPF Router with ID (0.0.0.1) (Process ID 1)
Router Link States (Area 0)
Link ID
0.0.0.1
ADV Router
0.0.0.1
Age
54
Seq#
Checksum Link count
0x8000000D 0x007D8B 13
Type-5 AS External Link States
Link ID
101.1.0.0
101.1.1.0
101.1.2.0
101.1.3.0
101.1.4.0
101.1.5.0
101.1.6.0
101.1.7.0
101.1.9.0
ADV Router
0.0.0.1
0.0.0.1
0.0.0.1
0.0.0.1
0.0.0.1
0.0.0.1
0.0.0.1
0.0.0.1
0.0.0.1
Age
54
54
54
54
54
54
54
54
54
Seq#
Checksum Tag
0x80000001 0x00AF89 0
0x80000001 0x00A493 0
0x80000001 0x00999D 0
0x80000001 0x008EA7 0
0x80000001 0x0083B1 0
0x80000001 0x0078BB 0
0x80000001 0x006DC5 0
0x80000001 0x0062CF 0
0x80000001 0x004CE3 0
Next, the task requires enabling OSPF and assigning the G0/0 interface on R4 to Area 0.
The task restricts the use of the network command to achieve this. This means, OSPF’s interface-level
configuration method should be used to enable OSPF for Area 0 on the G0/0 interface. Additionally, the task
also further states that R4 should be prevented from advertising any secondary addresses configured on this
interface into OSPF. A show run on the G0/0 interface on R4 reveals a secondary IP address 200.4.4.4/24,
configured:
On R4:
R4#show run interface g0/0 | begin interface
interface GigabitEthernet0/0
ip address 200.4.4.4 255.255.255.0 secondary
ip address 145.1.1.4 255.255.255.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 545
duplex auto
speed auto
media-type rj45
end
When OSPF is configured with the interface-level configuration style, the secondary addresses are
automatically advertised into OSPF. This default behaviour can be modified by changing the existing
interface-level command to exclude the secondary addressee. This is achieved by using the secondaries none
keyword option with the ip ospf command under the interface as seen below on R4:
On R4:
R4(config)#interface g0/0
R4(config-if)#ip ospf 1 area 0 secondaries none
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on GigabitEthernet0/0 from LOADING
to FULL, Loading Done
R1’s routing table can be observed to verify the OSPF routes it learns from R4. Notice, as a result of the above
configuration, the secondary address 200.4.4.4 does not appear in the routing table:
On R1:
R1#show ip route ospf | begin Gate
Gateway of last resort is not set
O IA
O IA
O IA
40.0.0.0/32 is subnetted, 1 subnets
40.4.0.4 [110/2] via 145.1.1.4, 00:00:58, GigabitEthernet0/0
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [110/2] via 145.1.1.4, 00:00:58, GigabitEthernet0/0
50.0.0.0/32 is subnetted, 1 subnets
50.5.0.5 [110/3] via 145.1.1.4, 00:00:58, GigabitEthernet0/0
OSPF is next configured on SW5’s VLAN 145 and Loopback 0 interface:
On SW5:
SW5(config)#router ospf 1
SW5(config-router)#network 145.1.1.55 0.0.0.0 area 0
SW5(config-router)#network 5.5.5.5 0.0.0.0 a 0
You should see the following console messages:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 546
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on Vlan145 from LOADING to FULL,
Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.4 on Vlan145 from LOADING to FULL,
Loading Done
Finally, OSPF for Area 0 is configured on the G0/1 interface on R2 and R3 with the network command. A
network command is also issued to advertise R3’s loopback 0 interface into OSPF Area 0:
On R2:
R2(config)#router ospf 1
R2(config-router)#network 12.1.1.2 0.0.0.0 area 0
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on GigabitEthernet0/1
to FULL, Loading Done
from LOADING
On R3:
R3(config)#router ospf 1
R3(config-router)#network 13.1.1.3 0.0.0.0 area 0
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
You should see the following console message:
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.1 on GigabitEthernet0/1
to FULL, Loading Done
from LOADING
The show ip ospf neighbor command on R2, R3, and R4 verify the OSPF adjacencies:
To verify the configuration:
On R2:
R2#show ip ospf neighbor
Neighbor ID
0.0.0.1
0.0.0.11
Pri
1
1
State
FULL/DR
FULL/DR
Dead Time
00:00:33
00:00:35
Address
12.1.1.1
112.1.1.11
Interface
GigabitEthernet0/1
GigabitEthernet0/0
On R3:
R3#show ip ospf neighbor
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 547
Neighbor ID
0.0.0.1
0.0.0.22
Pri
1
1
State
FULL/DR
FULL/BDR
Dead Time
00:00:36
00:00:32
Address
13.1.1.1
23.1.1.22
Interface
GigabitEthernet0/1
GigabitEthernet0/9
State
Dead Time
FULL/DR
00:00:32
FULL/DROTHER 00:00:30
FULL/DR
00:00:35
Address
145.1.1.1
145.1.1.55
45.1.1.5
Interface
GigabitEthernet0/0
GigabitEthernet0/0
GigabitEthernet0/5
On R4:
R4#show ip ospf neighbor
Neighbor ID
0.0.0.1
0.0.0.55
0.0.0.5
Pri
1
1
1
Task 7
Ensure that the routers in Area 1 do not have any OSPF external routes in their routing
table; these routers should not have LSA Types 4 or 5 in their LSDB.
As mentioned in the beginning of this lab, OSPF allows splitting of its domain into what are known as OSPF
areas. Each area comprises a set of router links that are grouped together. The LSDB on routers within the
same area is identical, however, the LSDB on routers in different areas will be different. In other words,
when crossing over areas, certain information specific within an area will be hidden to routers in other
areas. This is to isolate topology changes to only specific areas that experience those interruptions. For
example, a link down in Area 1 does not necessarily affect the links in Area 2.
The task asserts that external prefixes should not be flooded into OSPF Area 1 in the topology. To
understand how to implement this requirement, a basic understanding of LSA flooding scope is required.
LSAs that describe links internal to a specific area have what is known as area-wide flooding scope. These
LSAs are never advertised between two adjacent areas and include the Type-1 Router LSA and the Type-2
Network LSA.
While it is true that OSPF areas allow isolated control of LSA flooding, there are still some LSAs that are
flooded to all areas and not just in the area in which they originate. These LSAs are said to have a domainwide flooding scope. Such LSAs are the Type-5 External LSAs that carry external routing information into
the OSPF domain.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 548
Recall from earlier tasks that external prefixes are prefixes that originate from outside the OSPF domain as a
whole. Such prefixes don’t belong to an individual area. They belong to the entire OSPF domain and as such
they have a domain-wide flooding scope.
Depending on the network topology, these external LSAs can make up a significant portion of the LSDB,
forcing the LSDB to consume a lot of memory on routers in all areas. This is because for every external prefix
redistributed into the OSPF domain, a single Type-5 LSA is generated. If there are 100 external prefixes,
there will be 100 Type-5 LSAs flooded into OSPF.
Some areas only have a single exit point to reach the backbone of the OSPF domain. Such areas really do not
require granular external routing information as only a single router can be used to exit the topology. Thus,
to save memory on external prefixes, these areas can be configured to prevent Type-5 LSAs from both being
sent into the area or being originated inside the area.
These areas are called stub areas. Routers wishing to participate in a stub area signal this by unsetting what
is known as the external bit or E bit in their OSPF hello messages sent within that area. When the E-bit is set
in the hello packet, it signifies the willingness of the router to accept external routing information. When it
is unset, the router does not wish to receive external routing information. In order for an area to function as
a stub area, all router link hellos in the area must agree that external information should not be flooded. In
other words, all hellos received on router links in the area must have the E-bit unset. In fact, two routers will
not become neighbors on their directly attached link if they do not agree on the E-bit setting.
Stub areas carry with them a specific set of rules governing where they can be placed and
what they can contain:
1. The backbone area cannot be configured as a stub area
2. Virtual links cannot be configured through stub areas
3. Stub areas do not allow external routing information to be flooded into them or originate from them.
In OSPF, the ABR becomes the gatekeeper for what LSAs are and are not flooded into the area. For stub
areas, this means it is the ABR’s job to keep external LSAs flooded through the backbone from entering the
stub area. As stated, the ABR does so based on the setting of its own E-Bit in its hello messages as seen
below:
On the ABR:
Internet Protocol Version 4, Src: 34.1.1.4, Dst: 224.0.0.5
Open Shortest Path First
OSPF Header
Version: 2
Message Type: Hello Packet (1)
Packet Length: 48
Source OSPF Router: 34.1.1.4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 549
Area ID: 0.0.0.3
Checksum: 0xb18e [correct]
Auth Type: Null (0)
Auth Data (none): 0000000000000000
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval [sec]: 10
Options: 0x12, (L) LLS Data block, (E) External Routing
0... .... = DN: Not set
.0.. .... = O: Not set
..0. .... = (DC) Demand Circuits: Not supported
...1 .... = (L) LLS Data block: Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..1. = (E) External Routing: Capable
.... ...0 = (MT) Multi-Topology Routing: No
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
Active Neighbor: 23.1.1.3
OSPF LLS Data Block
In the above, the ABR’s E-Bit is set to 1 which means it will flood external routing LSAs into the area on this
link. This behavior however can be modified by declaring an area as a stub area. In this case, the E-bit is
turned off, or set to 0 as in the following hello packet:
On the ABR:
Internet Protocol Version 4, Src: 34.1.1.4, Dst: 224.0.0.5
Open Shortest Path First
OSPF Header
Version: 2
Message Type: Hello Packet (1)
Packet Length: 48
Source OSPF Router: 34.1.1.4
Area ID: 0.0.0.3
Checksum: 0xb38e [correct]
Auth Type: Null (0)
Auth Data (none): 0000000000000000
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval [sec]: 10
Options: 0x10, (L) LLS Data block
0... .... = DN: Not set
.0.. .... = O: Not set
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 550
..0. .... = (DC) Demand Circuits: Not supported
...1 .... = (L) LLS Data block: Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..0. = (E) External Routing: Not capable
.... ...0 = (MT) Multi-Topology Routing: No
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
Active Neighbor: 23.1.1.3
OSPF LLS Data Block
In the above, with the E-Bit unset (having a value of 0), external Type-5 LSAs are not flooded into the area.
RFC 2328, the OSPFv2 RFC, confirms this configuration:
ExternalRoutingCapability
Entire OSPF areas can be configured as "stubs" (see Section
3.6). AS-external-LSAs will not be flooded into stub areas.
This capability is represented by the E-bit in the OSPF
Options field
It has been established that stub areas will not carry external routing information. This begs the question:
How will those routers reach those external routes?
Reachability to the external prefixes within the stub area is achieved using a Type-3 Summary default route.
The ABR connected to the stub area will flood the Type-3 summary default route throughout the stub area,
allowing routers to follow that route to reach any external destinations.
It seems configuring Area 1 as a stub area solves the task’s requirement that no external routes should
appear in the routing table of the routers internal to Area 1. Stub configuration blocks the generation and
flooding of Type-5 external LSAs. But what about the Type-4 LSAs the task mentions should also not be
allowed to be flooded into Area 1?
Stub areas take care of this requirement as well. To understand how, the purpose of Type-4 LSAs needs to
be explained. The Type-4 LSA is called the ASBR Summary LSA. It works like this: Whenever an OSPF router
redistributes external prefixes into the OSPF domain, it becomes an Autonomous System Boundary Router
or ASBR. This is because it sits between two autonomous routing domains (OSPF and another routing
source). These ASBRs originate a Type-5 external LSA for every external prefix it redistributes into OSPF.
These Type-5 external LSAs list the originating ASBR itself as the next-hop to reach the prefix.
As the Type-5 external LSAs propagate through the Area the ASBR is a member of, no problems exist. All
routers within that area know how to reach the ASBR because they have full routing information in the form
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 551
of Type-1 router and Type-2 network LSAs. Type-5 external LSAs however, have a domain-wide flooding
scope. This means the ABR for the area in which the redistributing router (the ASBR) resides will flood the
Type-5 external LSA, unmodified with the original next-hop, into the backbone area. Now, routers in the
backbone receive routing information pointing to a next-hop for which they have no reachability
information.
This is where the Type-4 ASBR summary LSA comes into play. The ABR that floods the Type-5 external LSA
into another area other than the area in which it originated will also flood a Type-4 ASBR summary LSA that
provides summary routing information for reaching the ASBR that originated the Type-5 external LSA. This
Type-4 ASBR summary LSA is regenerated by other ABRs as they too flood the same Type-5 external LSAs
into their attached areas.
If an ABR is not flooding Type-5 external LSAs into its attached area, there is no need for it to flood a Type-4
ASBR summary LSA into that area. Also, if no Type-5 external LSAs are being generated by a router in its
attached stub area, it will not generate any Type-4 ASBR summary LSAs. In other words, the fact that Type-5
external LSAs are not permitted inside the stub area prevents the existence of an ASBR AND any Type-4
ASBR summary LSA flooding or generation by an ABR.
The task requires that Area 1 be configured as a stub area. Prior to any stub related configuration, let’s
observe the routing table on R5 that belongs to area 1. As seen below, R5 learns of various OSPF routes
from R4. Among these are the OSPF intra-area, inter-area and external routes:
On R5:
R5#show ip route ospf | begin Gate
Gateway of last resort is not set
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
5.0.0.0/24 is subnetted, 1 subnets
5.5.5.0 [110/3] via 45.1.1.4, 00:14:59, GigabitEthernet0/4
8.0.0.0/24 is subnetted, 1 subnets
8.8.8.0 [110/4] via 45.1.1.4, 00:15:09, GigabitEthernet0/4
10.0.0.0/24 is subnetted, 10 subnets
10.1.0.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.1.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.2.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.3.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.4.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.5.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.6.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.7.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.8.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
10.1.9.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/5] via 45.1.1.4, 00:11:59, GigabitEthernet0/4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 552
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O
O IA
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [110/3] via 45.1.1.4, 00:18:36, GigabitEthernet0/4
16.0.0.0/24 is subnetted, 1 subnets
16.1.1.0 [110/14] via 45.1.1.4, 00:11:59, GigabitEthernet0/4
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/4] via 45.1.1.4, 00:11:59, GigabitEthernet0/4
20.2.1.0 [110/4] via 45.1.1.4, 00:11:59, GigabitEthernet0/4
20.2.2.0 [110/4] via 45.1.1.4, 00:11:59, GigabitEthernet0/4
22.0.0.0/24 is subnetted, 1 subnets
22.22.22.0 [110/5] via 45.1.1.4, 00:11:30, GigabitEthernet0/4
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/4] via 45.1.1.4, 00:11:30, GigabitEthernet0/4
27.0.0.0/24 is subnetted, 1 subnets
27.1.1.0 [110/14] via 45.1.1.4, 00:11:30, GigabitEthernet0/4
33.0.0.0/24 is subnetted, 1 subnets
33.33.33.0 [110/13] via 45.1.1.4, 00:15:09, GigabitEthernet0/4
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [110/22] via 45.1.1.4, 00:15:09, GigabitEthernet0/4
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [110/12] via 45.1.1.4, 00:15:09, GigabitEthernet0/4
40.0.0.0/24 is subnetted, 1 subnets
40.4.0.0 [110/2] via 45.1.1.4, 01:25:43, GigabitEthernet0/4
58.0.0.0/24 is subnetted, 1 subnets
58.1.1.0 [110/3] via 45.1.1.4, 00:15:09, GigabitEthernet0/4
60.0.0.0/24 is subnetted, 10 subnets
60.1.0.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.1.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.2.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.3.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.4.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.5.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.6.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.7.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.8.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
60.1.9.0 [110/20] via 45.1.1.4, 00:11:54, GigabitEthernet0/4
101.0.0.0/24 is subnetted, 9 subnets
101.1.0.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
101.1.1.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
101.1.2.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
101.1.3.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
101.1.4.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
101.1.5.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
101.1.6.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 553
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O IA
O IA
101.1.7.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
101.1.9.0 [110/20] via 45.1.1.4, 00:18:31, GigabitEthernet0/4
104.0.0.0/24 is subnetted, 10 subnets
104.104.0.0 [110/20] via 45.1.1.4, 00:15:03, GigabitEthernet0/4
104.104.1.0 [110/20] via 45.1.1.4, 00:15:03, GigabitEthernet0/4
104.104.2.0 [110/20] via 45.1.1.4, 00:15:03, GigabitEthernet0/4
104.104.3.0 [110/20] via 45.1.1.4, 00:15:03, GigabitEthernet0/4
104.104.4.0 [110/20] via 45.1.1.4, 00:15:04, GigabitEthernet0/4
104.104.5.0 [110/20] via 45.1.1.4, 00:15:04, GigabitEthernet0/4
104.104.6.0 [110/20] via 45.1.1.4, 00:15:04, GigabitEthernet0/4
104.104.7.0 [110/20] via 45.1.1.4, 00:15:04, GigabitEthernet0/4
104.104.8.0 [110/20] via 45.1.1.4, 00:15:04, GigabitEthernet0/4
104.104.9.0 [110/20] via 45.1.1.4, 00:15:04, GigabitEthernet0/4
111.0.0.0/24 is subnetted, 10 subnets
111.111.0.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.1.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.2.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.3.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.4.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.5.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.6.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.7.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.8.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
111.111.9.0 [110/20] via 45.1.1.4, 00:11:25, GigabitEthernet0/4
112.0.0.0/24 is subnetted, 1 subnets
112.1.1.0 [110/4] via 45.1.1.4, 00:11:59, GigabitEthernet0/4
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [110/2] via 45.1.1.4, 00:18:46, GigabitEthernet0/4
The show ip route summary command is a hidden command issued to check the memory allocated to
routes. As seen, the total number of bytes allocated to remaining routes is 20772 bytes.
R5#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source
Networks
Subnets
Replicates Overhead
connected
0
4
0
272
static
0
0
0
0
application
0
0
0
0
ospf 1
0
68
0
4624
Intra-area: 1 Inter-area: 28 External-1: 0 External-2: 39
NSSA External-1: 0 NSSA External-2: 0
internal
24
Total
24
72
0
4896
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Memory (bytes)
720
0
0
12512
7540
20772
Page 554
An area can be declared as a stub area with the area area-number stub command. This command should be
issued on all the routers within that area, including the ABR. To configure Area 1 as a stub area, R4 and R5
are both configured with the area 1 stub command under the OSPF router configuration mode:
On R4:
R4(config)#router ospf 1
R4(config-router)#area 1 stub
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.5 on GigabitEthernet0/5 from FULL
to DOWN, neighbor Down: Adjacency forced to reset
On R5:
R5(config)#router ospf 1
R5(config-router)#area 1 stub
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.4 on GigabitEthernet0/4 from
LOADING to FULL, Loading Done
The show ip ospf command output on R4 and R5 verify that area 1 is now a stub area:
R5#show ip ospf | include It is
R4#show ip ospf
[ -- omitted -- ]
Area 1
Number of interfaces in this area is 2
It is a stub area
On R4:
R4#show ip ospf | include It is
[ -- omitted -- ]
Area 1
Number of interfaces in this area is 2
It is a stub area
After completing the above, the routing table on R5 looks different from the earlier output. Notice, the E2
routes no longer exist in the routing table. As mentioned, the ABR originates a default summary route into
the stub area. The external routes are now replaced by a Type-3 summary LSA:
On R5:
R5#show ip route ospf | begin Gate
Gateway of last resort is 45.1.1.4 to network 0.0.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 555
O*IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O
O IA
0.0.0.0/0 [110/2] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
5.0.0.0/24 is subnetted, 1 subnets
5.5.5.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
8.0.0.0/24 is subnetted, 1 subnets
8.8.8.0 [110/4] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.0.0.0/24 is subnetted, 10 subnets
10.1.0.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.1.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.2.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.3.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.4.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.5.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.6.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.7.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.8.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
10.1.9.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/5] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
16.0.0.0/24 is subnetted, 1 subnets
16.1.1.0 [110/14] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/4] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
20.2.1.0 [110/4] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
20.2.2.0 [110/4] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
22.0.0.0/24 is subnetted, 1 subnets
22.22.22.0 [110/5] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/4] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
27.0.0.0/24 is subnetted, 1 subnets
27.1.1.0 [110/14] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
33.0.0.0/24 is subnetted, 1 subnets
33.33.33.0 [110/13] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [110/22] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [110/12] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
40.0.0.0/24 is subnetted, 1 subnets
40.4.0.0 [110/2] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
58.0.0.0/24 is subnetted, 1 subnets
58.1.1.0 [110/3] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
112.0.0.0/24 is subnetted, 1 subnets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 556
O IA
O IA
112.1.1.0 [110/4] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [110/2] via 45.1.1.4, 00:04:32, GigabitEthernet0/4
R5#show ip ospf database summary 0.0.0.0 adv-router 0.0.0.4
OSPF Router with ID (0.0.0.5) (Process ID 1)
Summary Net Link States (Area 1)
LS age: 611
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 0.0.0.0 (summary Network Number)
Advertising Router: 0.0.0.4
LS Seq Number: 80000001
Checksum: 0x99A0
Length: 28
Network Mask: /0
MTID: 0
Metric: 1
The show ip route summary from R5 also shows a decrease of 9,272 in the memory allocated to routes:
R5#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source
Networks
Subnets
Replicates Overhead
connected
0
4
0
272
static
0
0
0
0
application
0
0
0
0
ospf 1
1
29
0
2040
Intra-area: 1 Inter-area: 29 External-1: 0 External-2: 0
NSSA External-1: 0 NSSA External-2: 0
internal
20
Total
21
33
0
2312
Memory (bytes)
720
0
0
5520
5260
11500
To recap Stub areas:
1. Stub areas do not allow Type-5 external or any other external type LSAs to be flooded into them
2. Since there are no Type-5 external LSAs, no Type-4 ASBR summary LSAs are generated
3. All router links within the area must agree the area should be a stub area. This is signified by
the E-Bit setting in their OSPF hello packets
4. The ABR is tasked with preventing the Type-5 LSAs from flooding into the stub area
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 557
5. The ABR floods a Type-3 default summary route into the area to provide external reachability to the
routers internal to the area
6. Virtual links cannot be formed through Stub areas.
Task 8
Configure Area 2 such that existing and future external and inter-area routes are never
seen in the routing tables of these routers. These routers should not have LSA Types 3,
4, or 5 in their LSDB, but these routers should have full reachability to the inter-area and
external networks redistributed in this routing domain.
Restriction:

Do not use an ACL or a prefix list to accomplish this task.
The previous task targeted external prefixes flooded with Type-5 LSAs. This task targets a different set of
prefixes known as Inter Area prefixes. These prefixes are described in Type-3 Summary LSAs that are
flooded into an area. The routing table on R8 demonstrates a number of these such routes:
On R8:
R8#show ip route ospf | begin Gate
Gateway of last resort is not set
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
5.0.0.0/24 is subnetted, 1 subnets
5.5.5.0 [110/2] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.0.0.0/24 is subnetted, 10 subnets
10.1.0.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.1.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.2.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.3.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.4.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.5.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.6.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.7.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.8.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
10.1.9.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/5] via 58.1.1.55, 00:36:44, GigabitEthernet0/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 558
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
13.1.1.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
16.0.0.0/24 is subnetted, 1 subnets
16.1.1.0 [110/14] via 58.1.1.55, 00:36:44, GigabitEthernet0/0
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/4] via 58.1.1.55, 00:36:44, GigabitEthernet0/0
20.2.1.0 [110/4] via 58.1.1.55, 00:36:44, GigabitEthernet0/0
20.2.2.0 [110/4] via 58.1.1.55, 00:36:44, GigabitEthernet0/0
22.0.0.0/24 is subnetted, 1 subnets
22.22.22.0 [110/5] via 58.1.1.55, 00:36:15, GigabitEthernet0/0
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/4] via 58.1.1.55, 00:36:15, GigabitEthernet0/0
27.0.0.0/24 is subnetted, 1 subnets
27.1.1.0 [110/14] via 58.1.1.55, 00:36:15, GigabitEthernet0/0
33.0.0.0/24 is subnetted, 1 subnets
33.33.33.0 [110/12] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [110/21] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [110/11] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
40.0.0.0/24 is subnetted, 1 subnets
40.4.0.0 [110/3] via 58.1.1.55, 00:39:49, GigabitEthernet0/0
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [110/3] via 58.1.1.55, 00:14:35, GigabitEthernet0/0
50.0.0.0/24 is subnetted, 1 subnets
50.5.0.0 [110/4] via 58.1.1.55, 00:14:35, GigabitEthernet0/0
60.0.0.0/24 is subnetted, 10 subnets
60.1.0.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.1.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.2.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.3.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.4.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.5.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.6.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.7.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.8.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
60.1.9.0 [110/20] via 58.1.1.55, 00:36:39, GigabitEthernet0/0
101.0.0.0/24 is subnetted, 9 subnets
101.1.0.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
101.1.1.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
101.1.2.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
101.1.3.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
101.1.4.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
101.1.5.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
101.1.6.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
101.1.7.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 559
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O IA
O IA
101.1.9.0 [110/20] via 58.1.1.55, 00:39:44, GigabitEthernet0/0
104.0.0.0/24 is subnetted, 10 subnets
104.104.0.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.1.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.2.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.3.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.4.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.5.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.6.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.7.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.8.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
104.104.9.0 [110/20] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
111.0.0.0/24 is subnetted, 10 subnets
111.111.0.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.1.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.2.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.3.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.4.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.5.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.6.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.7.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.8.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
111.111.9.0 [110/20] via 58.1.1.55, 00:36:10, GigabitEthernet0/0
112.0.0.0/24 is subnetted, 1 subnets
112.1.1.0 [110/4] via 58.1.1.55, 00:36:44, GigabitEthernet0/0
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [110/2] via 58.1.1.55, 00:39:59, GigabitEthernet0/0
In the above output, interarea prefixes are identified by the “O IA” designation. All of these prefixes were
derived from Type-3 Summary LSAs that were flooded into the Area. They represent prefixes that belong to
another OSPF area. The routes produced from the Type-3 Summary LSAs are used by internal routers to
reach networks in other areas. These LSAs are flooded by the ABR sitting between the backbone and nonbackbone areas. When flooded in this manner, the routers consider the interarea prefixes as if they were
networks connected to the ABR that flooded them.
An ABR will automatically generate a Type-3 Summary LSA for every intra-area and inter-area prefix that
exists in its routing table. It floods these Type-3 Summary LSAs into its attached Areas. For example, SW5,
the ABR in area 2, will generate a Type-3 LSA for all intra-area prefixes in its routing table from Area 2 and
flood them into the backbone area. It will also take all inter-area and intra-area prefixes installed in its
routing table from the backbone and flood them into Area 2. This can be evidenced by the show ip ospf 1 0
database summary and show ip ospf 1 2 database summary commands on SW5:
On SW5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 560
SW5#show ip ospf 1 0 database
(The begining of the output is omitted for brevity)
Summary Net Link States (Area 0)
Link ID
8.8.8.0
11.11.11.0
16.1.1.0
20.2.0.0
20.2.1.0
20.2.2.0
22.22.22.0
23.1.1.0
27.1.1.0
33.33.33.0
34.1.1.0
35.1.1.0
40.4.0.0
45.1.1.0
50.5.0.0
58.1.1.0
112.1.1.0
ADV Router
0.0.0.55
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.4
0.0.0.4
0.0.0.4
0.0.0.55
0.0.0.2
Age
799
611
611
611
611
611
560
560
560
799
799
799
1172
1280
1280
799
611
Seq#
Checksum
0x80000002 0x002FBB
0x80000002 0x000215
0x80000002 0x00021B
0x80000002 0x0068BA
0x80000002 0x005DC4
0x80000002 0x0052CE
0x80000002 0x006E86
0x80000002 0x003CE2
0x80000002 0x006CA4
0x80000002 0x000294
0x80000002 0x00329A
0x80000002 0x00C015
0x80000002 0x003FCB
0x80000001 0x0019EF
0x80000001 0x00BC43
0x80000002 0x003A8D
0x80000002 0x00B80E
(The rest of the output is omitted for brevity)
The output above shows the Type-3 Summary LSAs flooded into the backbone area. The yellow highlighted
LSAs are the Type-3 Summary LSAs SW5 flooded into the backbone to represent the intra-area prefixes from
Area 2. The green highlighted prefixes are Type-3 Summary LSAs that SW5 flooded into the backbone
representing the intra-area routes from its attached Area 3.
The output below shows all the Type-3 summary LSAs SW5 floods from the backbone area into Area 2:
SW5#show ip ospf 1 2 database
(The begining of the output is omitted for brevity)
Summary Net Link States (Area 2)
Link ID
5.5.5.0
10.1.0.0
10.1.1.0
ADV Router
0.0.0.55
0.0.0.55
0.0.0.55
CCIE by Narbik Kocharians
Age
996
996
996
Seq#
Checksum
0x80000002 0x009163
0x80000002 0x00C136
0x80000002 0x00B640
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 561
10.1.2.0
10.1.3.0
10.1.4.0
10.1.5.0
10.1.6.0
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
996
996
996
996
996
0x80000002 0x00AB4A
0x80000002 0x00A054
0x80000002 0x00955E
0x80000002 0x008A68
0x80000002 0x007F72
10.1.7.0
10.1.8.0
10.1.9.0
11.11.11.0
12.1.1.0
13.1.1.0
16.1.1.0
20.2.0.0
20.2.1.0
20.2.2.0
22.22.22.0
23.1.1.0
27.1.1.0
33.33.33.0
34.1.1.0
35.1.1.0
40.4.0.0
45.1.1.0
50.5.0.0
112.1.1.0
145.1.1.0
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
996
996
996
996
996
996
996
996
996
996
738
738
738
996
996
996
996
1476
1476
996
996
0x80000002 0x00747C
0x80000002 0x006986
0x80000002 0x005E90
0x80000002 0x00D609
0x80000002 0x009C58
0x80000002 0x008F64
0x80000002 0x00D60F
0x80000002 0x003DAE
0x80000002 0x0032B8
0x80000002 0x0027C2
0x80000002 0x004975
0x80000002 0x0017D1
0x80000002 0x004793
0x80000002 0x000294
0x80000002 0x00329A
0x80000002 0x00C015
0x80000002 0x0016C0
0x80000001 0x00EFE4
0x80000001 0x009338
0x80000002 0x008D02
0x80000002 0x00CAA5
(The rest of the output is omitted for brevity)
The wording is very important. ABRs will not flood inter-area routes from non-backbone areas into other
non-backbone areas. In this case, SW5 is connected to both Area 2 and Area 3. It will not flood intra-area
routes from Area 2 into Area 3. It only floods inter-area routes from the backbone into Area 2 and Area 3.
This distinction is important as performing the former can lead to routing loops and violates OSPF’s
enforced hub-and-spoke hierarchy.
Now that there is a little background on the Type-3 LSA and how it is formed, the focus can shift to the
task’s requirements. In the earlier task, Area 1 was configured to be a stub area. The result was that Type-5
LSAs were not flooded into this area. Routers in stub area 1 had reachability to external routes via a default
route generated from the Type-3 summary LSA that was originated by the ABR R4.
This task requires a similar functionality to be implemented for Area 2 with an additional enhancement. In
addition to no external routing information, routers in Area 2 should also not have any specific inter-area
routes. As can be seen in the routing table from R8 above, R8 has installed various specific interarea Type-3
Summary O IA and Type-5 external E2 routes from SW5.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 562
Configuring Area 2 as a stub area prevents the Type-5 external prefixes from entering the area. R8 would
install a default route from the ABR SW5. This way, R8 can follow the default route to the ABR for all
external routes. This behavior is expected. Examining the output a bit closely reveals that the exit point for
the inter-area routes in R8’s routing table is also SW5 the ABR. This means, there is really only one exit
point for all external and inter-area prefixes in Area 2. That is SW5. Forcing R8 to store the extra Type-3
LSAs to ultimately lead to the same exit point is a waste of resources on R8. This is the reason the task
specifies these Type-3 prefixes should not exist within the area. The ABR could flood only a default route
into the Area and provide the same level of reachability for less expense on Area 2 routers.
Enabling such behavior would change the Stub area into what is known as a Totally Stubby Area. Similar to
the stub areas described in task 7, Type-5 and Type-4 LSAs are not injected into a totally stub area. At the
same time, specific Type-3 LSAs are also prevented from entering this area. Remember, a Type-5 LSA is
created for every external network redistributed into the OSPF domain. The same stands true for Type-3
LSAs. Each network that belongs to another area of the same OSPF domain has a Type-3 LSA generated for
it. Overall, every individual Type-5 and Type-3 LSA increases the size of the LSDB. Blocking these LSAs at
ABRs prevents the expense on internal Area routers.
Totally stubby areas prevent the ABR from generating Type-3 LSAs from the interarea (O IA) and intra-area
(O) routes from other areas in its routing table. When configured, the ABR will only inject a default summary
LSA into the stub area to represent both external and inter-area routes. Internal routers follow this
summary LSA for all prefixes that do not originate inside the local area.
To define an area as a totally stub, routers within the area will still be configured with the command area
area-number stub. The change in configuration from a stub area to a totally stubby area occurs on the ABR.
The area area-number stub no-summary command under the OSPF router configuration mode instructs the
ABR not to inject Type-3 LSAs into the area and instead flood only a single default summary Type-3 LSA into
the totally stub area. This is the configuration required to complete the task.
To show the difference before and after making Area 2 into a totally stubby area, the output of the show ip
route summary command from R8 that shows the total route memory allocation as 20772 bytes:
On R8:
R8#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source
Networks
Subnets
(bytes)
connected
0
4
static
0
0
application
0
0
ospf 1
0
68
CCIE by Narbik Kocharians
Replicates
Overhead
Memory
0
0
0
0
272
0
0
4624
720
0
0
12512
CCIE Enterprise Infrastructure Foundation v1.0
Page 563
© 2021 Narbik Kocharians. All rights reserved
Intra-area: 0 Inter-area: 29 External-1: 0 External-2: 39
NSSA External-1: 0 NSSA External-2: 0
internal
24
Total
24
72
0
4896
7540
20772
Following configurations are then made on SW3 and R8 to define Area 2 as totally stub:
On SW5 (ABR):
SW5(config)#router ospf 111
SW5(config-router)#area 2 stub no-summary
On R8:
R8(config)#router ospf 1
R8(config-router)#area 2 stub
Note, there is no explicit flag setting in the hello packets to indicate a totally stub area. The hello’s sent will
still have the external routing capability bit turned off as seen below. It is the no-summary keyword
appended to the area 2 stub command on the ABR that causes the ABR to suppress specific Type-3
summary LSAs to R8 and instead, replace it with default Type-3 summary LSA:
Ethernet II, Src: 50:00:00:08:00:00 (50:00:00:08:00:00), Dst:
IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 58.1.1.8, Dst: 224.0.0.5
Open Shortest Path First
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval [sec]: 10
Options: 0x10, (L) LLS Data block
0... .... = DN: Not set
.0.. .... = O: Not set
..0. .... = (DC) Demand Circuits: Not supported
...1 .... = (L) LLS Data block: Present
.... 0... = (N) NSSA: Not supported
.... .0.. = (MC) Multicast: Not capable
.... ..0. = (E) External Routing: Not capable
.... ...0 = (MT) Multi-Topology Routing: No
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 58.1.1.55
Backup Designated Router: 58.1.1.8
Active Neighbor: 0.0.0.55
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 564
OSPF LLS Data Block
The result of the above configuration can now be seen in R8’s routing table. In contrast to the same
command output shown earlier, notice the routing table on R8 now has just an inter-area summary default
route from SW3:
On R8:
R8#show ip route ospf | begin Gate
Gateway of last resort is 10.1.89.9 to netw 0.0.0.0
O*IA
0.0.0.0/0 [110/2] via 58.1.1.55, 00:00:10, GigabitEthernet0/0
Following shows the Type-3 summary LSA generated by the ABR SW5:
R8#show ip ospf database summary
OSPF Router with ID (0.0.0.8) (Process ID 1)
Summary Net Link States (Area 2)
LS age: 189
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 0.0.0.0 (summary Network Number)
Advertising Router: 0.0.0.55
LS Seq Number: 80000001
Checksum: 0x66A0
Length: 28
Network Mask: /0
MTID: 0
Metric: 1
Also, note the result of the command show ip ospf 1 2 database self-originate from the ABR SW5 below.
Notice it is only generating a single Type-3 summary LSA for Area 2:
On SW5:
SW5#show ip ospf 1 2 database self-originate
OSPF Router with ID (0.0.0.55) (Process ID 1)
Router Link States (Area 2)
Link ID
count
0.0.0.55
ADV Router
Age
Seq#
0.0.0.55
249
0x80000008 0x00FADC 1
CCIE by Narbik Kocharians
Checksum Link
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 565
Net Link States (Area 2)
Link ID
58.1.1.55
ADV Router
0.0.0.55
Age
249
Seq#
Checksum
0x80000001 0x00D67B
Summary Net Link States (Area 2)
Link ID
0.0.0.0
ADV Router
0.0.0.55
Age
280
Seq#
Checksum
0x80000001 0x0066A0
Finally, the show ip route summary command output from R8 now shows a new much lower amount of
memory allocated to routes:
On R8:
R8#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source
Networks
Subnets
Replicates Overhead
(bytes)
connected
0
4
0
272
static
0
0
0
0
application
0
0
0
0
ospf 1
1
0
0
68
Intra-area: 0 Inter-area: 1 External-1: 0 External-2: 0
NSSA External-1: 0 NSSA External-2: 0
internal
2
Total
3
4
0
340
Memory
720
0
0
184
880
1784
This memory use optimization comes at no expense to routing functionality as there is still only a single exit
in Area 2 to reach all non-Area 2 prefixes. In review, totally stubby areas have the following characteristics:
1. They do not allow flooding of Type-5 or specific Type-3 LSAs into the area
2. Because there are no Type-5 LSAs no Type-4 LSAs are flooded as well
3. They are converted from stub areas by configuring the area x stub no-summary command on the
stub area ABR
4. The ABR simply does not inject Type-3 LSAs for its intra-area and inter-area prefixes in its routing
table from other areas. Instead, it floods only a default Type-3 summary LSA into the area
5. The backbone cannot be a totally stubby area
6. Virtual links cannot flow over a totally stubby area
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 566
Task 9
Configure the routers in Area 3 based on the following policy:




The routers must maintain existing and future inter-area routes in their routing tables.
The routers should not have LSA Types 4 or 5 in their OSPF link state database.
The routers should not have reachability to the routes redistributed in the other
areas of this routing domain.
The routers should have reachability to the routes redistributed in their own area.
One of the topological differences between normal areas and the stub and totally stub areas was that Type5 LSAs representing external routes were forbidden from entering a stub area. While this serves as an
advantage, in certain cases, this could present itself as a limitation. A router within a stub area is not
allowed to redistribute prefixes into the area. In some topologies, this functionality may be necessary as
routers are added to areas that connect to other routing domains. In such a situation, the only option would
be to change the area back into a normal area and incur the cost of receiving all external prefixes from other
areas, again. In this case, an alternative that allows external prefixes to be originated in the area but
prevents external prefixes from being flooded into the area is needed. In such cases, an area can be defined
as a not-so-stubby-area otherwise known as an NSSA.
An NSSA is another stub area version. Type-5 external LSAs are still prohibited from entering an NSSA,
however, redistribution of external prefixes can be performed within the NSSA. The router performing the
redistribution of external information is called the NSSA ASBR. Since Type-5 external LSAs are not allowed in
an NSSA, the NSSA ASBR redistributes external routes into the NSSA as Type-7 NSSA external LSAs. The NSSA
ABR, the ABR connected to the NSSA and the backbone area, translates these Type-7 NSSA external LSAs
into Type-5 external LSAs. The resultant Type-5 external LSAs are flooded to the rest of the OSPF domain.
The NSSA functionality is an extension to the original stub area. Earlier it was mentioned that devices within
a stub area clear the E-bit in their hello packets. The E-bit is the external routing capability bit. For NSSA,
another bit is introduced to signify NSSA capability. This is the N-bit which is also present in the option field
of the hello packet. All routers that have interfaces in an NSSA should have this bit set to 1. Together, the Ebit prevents the flooding of Type-5 external LSAs into the NSSA, and the N-bit enables flooding external
information as Type-7 NSSA external LSAs. The following is an example packet capture of a hello packet
between routers with interfaces in an NSSA:
Internet Protocol Version 4, Src: 34.1.1.44, Dst: 224.0.0.5
Open Shortest Path First
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 567
OSPF Header
OSPF Hello Packet
Network Mask: 255.255.255.0
Hello Interval [sec]: 10
Options: 0x18, (L) LLS Data block, (N) NSSA
0... .... = DN: Not set
.0.. .... = O: Not set
..0. .... = (DC) Demand Circuits: Not supported
...1 .... = (L) LLS Data block: Present
.... 1... = (N) NSSA: Supported
.... .0.. = (MC) Multicast: Not capable
.... ..0. = (E) External Routing: Not capable
.... ...0 = (MT) Multi-Topology Routing: No
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 34.1.1.33
Backup Designated Router: 34.1.1.44
Active Neighbor: 0.0.0.33
OSPF LLS Data Block
By defining Area 3 as an NSSA, all of requirements of the task will be met:
1. Type-3 summary LSAs for inter-area routes are allowed
2. NSSAs are stub areas, meaning all Type-4 ASBR summary and Type-5 external LSAs will not be
flooded into an NSSA
3. NSSA ABRs do not inject a summary default route into an NSSA. Without Type-5 external LSAs and
Type-3 default summary LSAs, routers within an NSSA will not have reachability to external routes
inject into the OSPF domain in an external area
4. NSSA allows redistribution on an NSSA ASBR. These routes will be injected into the NSSA as Type-7
NSSA external LSAs. NSSA ABRs will translate them into Type-5 external LSAs and flood them to the
OSPF domain to provide reachability to all other routers in the OSPF domain
An area is defined as an NSSA with the area area-number nssa command. This command should be issued
on all the ABRs connected to the NSSA and all routers internal to the NSSA. To solve this task, the command
will be issued on the ABR SW5, SW3 and SW4. However, prior to declaring Area 3 as an NSSA, following is
the current view of SW4’s routing table. Notice the presence of the E2 routes:
On SW4:
SW4#show ip route ospf | begin Gate
Gateway of last resort is not set
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 568
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O
O
O IA
O IA
O IA
O IA
5.0.0.0/24 is subnetted, 1 subnets
5.5.5.0 [110/21] via 34.1.1.33, 01:07:15, Ethernet6/0
8.0.0.0/24 is subnetted, 1 subnets
8.8.8.0 [110/22] via 34.1.1.33, 00:10:48, Ethernet6/0
10.0.0.0/24 is subnetted, 10 subnets
10.1.0.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.1.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.2.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.3.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.4.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.5.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.6.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.7.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.8.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
10.1.9.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/24] via 34.1.1.33, 01:04:10, Ethernet6/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
16.0.0.0/24 is subnetted, 1 subnets
16.1.1.0 [110/33] via 34.1.1.33, 01:04:10, Ethernet6/0
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/23] via 34.1.1.33, 01:04:10, Ethernet6/0
20.2.1.0 [110/23] via 34.1.1.33, 01:04:10, Ethernet6/0
20.2.2.0 [110/23] via 34.1.1.33, 01:04:10, Ethernet6/0
22.0.0.0/24 is subnetted, 1 subnets
22.22.22.0 [110/24] via 34.1.1.33, 01:03:41, Ethernet6/0
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/23] via 34.1.1.33, 01:03:41, Ethernet6/0
27.0.0.0/24 is subnetted, 1 subnets
27.1.1.0 [110/33] via 34.1.1.33, 01:03:41, Ethernet6/0
33.0.0.0/24 is subnetted, 1 subnets
33.33.33.0 [110/11] via 34.1.1.33, 02:03:36, Ethernet6/0
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [110/20] via 34.1.1.33, 02:03:26, Ethernet6/0
40.0.0.0/24 is subnetted, 1 subnets
40.4.0.0 [110/22] via 34.1.1.33, 01:07:15, Ethernet6/0
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [110/22] via 34.1.1.33, 00:42:01, Ethernet6/0
50.0.0.0/24 is subnetted, 1 subnets
50.5.0.0 [110/23] via 34.1.1.33, 00:42:01, Ethernet6/0
58.0.0.0/24 is subnetted, 1 subnets
58.1.1.0 [110/21] via 34.1.1.33, 01:07:24, Ethernet6/0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 569
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O IA
O IA
60.0.0.0/24 is subnetted, 10 subnets
60.1.0.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.1.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.2.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.3.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.4.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.5.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.6.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.7.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.8.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
60.1.9.0 [110/20] via 34.1.1.33, 01:04:05, Ethernet6/0
101.0.0.0/24 is subnetted, 9 subnets
101.1.0.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.1.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.2.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.3.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.4.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.5.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.6.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.7.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
101.1.9.0 [110/20] via 34.1.1.33, 01:07:10, Ethernet6/0
111.0.0.0/24 is subnetted, 10 subnets
111.111.0.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.1.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.2.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.3.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.4.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.5.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.6.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.7.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.8.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
111.111.9.0 [110/20] via 34.1.1.33, 01:03:36, Ethernet6/0
112.0.0.0/24 is subnetted, 1 subnets
112.1.1.0 [110/23] via 34.1.1.33, 01:04:10, Ethernet6/0
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [110/21] via 34.1.1.33, 01:07:24, Ethernet6/0
Area 3 is defined as an NSSA on SW5, SW3 and SW4 below:
On SW5:
SW5(config)#router ospf 1
SW5(config-router)#area 3 nssa
On SW3:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 570
SW3(config)#router ospf 1
SW3(config-router)#area 3 nssa
On SW4:
SW4(config)#router ospf 1
SW4(config-router)#area 3 nssa
The show ip ospf command output verifies the above configuration:
On SW5:
SW5#show ip ospf | include It is
It is an area border and autonomous system boundary router
It is a stub area, no summary LSA in this area
It is a NSSA area
On SW3:
SW3#show ip ospf | include It is
It is a NSSA area
On SW4:
SW4#show ip ospf | include It is
It is an autonomous system boundary router
It is a NSSA area
The following is the routing table on SW4 after declaring Area 3 an NSSA. As the task desires, SW4 has
retained the inter-area routes and no longer has reachability to any external routes redistributed into OSPF
from another area:
SW4#show ip route ospf | begin Gate
Gateway of last resort is not set
O IA
O IA
5.0.0.0/24 is subnetted, 1 subnets
5.5.5.0 [110/21] via 34.1.1.33, 00:03:43, Ethernet6/0
8.0.0.0/24 is subnetted, 1 subnets
8.8.8.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.0.0.0/24 is subnetted, 10 subnets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 571
O IA
O IA
O IA
10.1.0.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.1.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.2.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
O IA
O IA
O IA
O IA
O IA
O IA
O IA
10.1.3.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.4.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.5.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.6.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.7.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.8.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
10.1.9.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/24] via 34.1.1.33, 00:03:43, Ethernet6/0
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
16.0.0.0/24 is subnetted, 1 subnets
16.1.1.0 [110/33] via 34.1.1.33, 00:03:43, Ethernet6/0
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/23] via 34.1.1.33, 00:03:43, Ethernet6/0
20.2.1.0 [110/23] via 34.1.1.33, 00:03:43, Ethernet6/0
20.2.2.0 [110/23] via 34.1.1.33, 00:03:43, Ethernet6/0
22.0.0.0/24 is subnetted, 1 subnets
22.22.22.0 [110/24] via 34.1.1.33, 00:03:43, Ethernet6/0
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/23] via 34.1.1.33, 00:03:43, Ethernet6/0
27.0.0.0/24 is subnetted, 1 subnets
27.1.1.0 [110/33] via 34.1.1.33, 00:03:43, Ethernet6/0
33.0.0.0/24 is subnetted, 1 subnets
33.33.33.0 [110/11] via 34.1.1.33, 00:03:43, Ethernet6/0
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [110/20] via 34.1.1.33, 00:03:43, Ethernet6/0
40.0.0.0/24 is subnetted, 1 subnets
40.4.0.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [110/22] via 34.1.1.33, 00:03:43, Ethernet6/0
50.0.0.0/24 is subnetted, 1 subnets
50.5.0.0 [110/23] via 34.1.1.33, 00:03:43, Ethernet6/0
58.0.0.0/24 is subnetted, 1 subnets
58.1.1.0 [110/21] via 34.1.1.33, 00:03:43, Ethernet6/0
112.0.0.0/24 is subnetted, 1 subnets
112.1.1.0 [110/23] via 34.1.1.33, 00:03:43, Ethernet6/0
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [110/21] via 34.1.1.33, 00:03:43, Ethernet6/0
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O
O
O IA
O IA
O IA
O IA
O IA
O IA
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 572
The task also requires that internal devices in Area 3 should not have any Type-5 external or Type-4 NSSA
external LSAs present in their LSDB. The example output from SW4 verifies this:
SW4#show ip ospf database external
OSPF Router with ID (0.0.0.44) (Process ID 1)
SW4#show ip ospf database asbr-summary
OSPF Router with ID (0.0.0.44) (Process ID 1)
The prefixes redistributed on the NSSA ASBR SW4 present themselves as O N2 routes on SW3 and SW5. The
LSDB on these devices show these prefixes represented with Type-7 NSSA external LSAs:
On SW5:
SW5#show ip route ospf | include N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
104.104.0.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.1.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.2.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.3.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.4.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.5.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.6.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.7.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.8.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
104.104.9.0 [110/20] via 35.1.1.33, 00:08:16, Ethernet5/0
SW5#show ip ospf database | begin Type-7
Type-7 AS External Link States (Area 3)
Link ID
104.104.0.0
104.104.1.0
104.104.2.0
104.104.3.0
104.104.4.0
104.104.5.0
104.104.6.0
104.104.7.0
104.104.8.0
104.104.9.0
ADV Router
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
CCIE by Narbik Kocharians
Age
690
690
690
690
690
690
690
690
690
690
Seq#
Checksum Tag
0x80000001 0x001336 0
0x80000001 0x000840 0
0x80000001 0x00FC4A 0
0x80000001 0x00F154 0
0x80000001 0x00E65E 0
0x80000001 0x00DB68 0
0x80000001 0x00D072 0
0x80000001 0x00C57C 0
0x80000001 0x00BA86 0
0x80000001 0x00AF90 0
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 573
(The rest of the output is omitted for brevity)
On SW3:
SW3#show ip route ospf | include N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
104.104.0.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.1.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.2.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.3.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.4.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.5.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.6.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.7.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.8.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
104.104.9.0 [110/20] via 34.1.1.44, 00:12:48, Ethernet6/0
SW3#show ip ospf database | begin Type-7
Type-7 AS External Link States (Area 3)
Link ID
104.104.0.0
104.104.1.0
104.104.2.0
104.104.3.0
104.104.4.0
104.104.5.0
104.104.6.0
104.104.7.0
104.104.8.0
104.104.9.0
ADV Router
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
0.0.0.44
Age
860
860
860
860
860
860
860
860
860
860
Seq#
Checksum Tag
0x80000001 0x001336 0
0x80000001 0x000840 0
0x80000001 0x00FC4A 0
0x80000001 0x00F154 0
0x80000001 0x00E65E 0
0x80000001 0x00DB68 0
0x80000001 0x00D072 0
0x80000001 0x00C57C 0
0x80000001 0x00BA86 0
0x80000001 0x00AF90 0
To review the not-so-stubby-area type:
1. They behave like stub areas, blocking Type-5 external LSAs
2. They allow external prefixes into the NSSA by flooding them as Type-7 NSSA external LSAs
from the NSSA ASBR
3. These Type-7 NSSA external LSAs are translated into Type-5 external LSAs by the NSSA
4. ABR to be flooded to the rest of the OSPF domain
5. The backbone area cannot be an NSSA
6. Virtual Links cannot flow through an NSSA
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 574
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 575
Task 10
Configure the routers in Area 4 based on the following policy:




The routers of this area should have LSA Type 3 in their OSPF link state database.
The routers of this area should not have LSA Types 4 or 5 in their OSPF link state
database.
The routers must have reachability to the existing and future routes redistributed in
the other areas of this routing domain, except for the external networks redistributed
in Area 3.
The routers should have reachability to the networks redistributed in their own area.
In case of stub and totally stub areas, while prohibiting the Type-5 external LSAs, the ABR generates a Type3 summary LSA to provide reachability to external routes in other areas. However, from Task 9 it was shown
that an NSSA ABR does not flood Type-5 external LSA or a Type-3 summary LSA into the NSSA. This leaves
routers that are internal to the NSSA with no information about how to reach external routes.
This task requires defining Area 4 as an NSSA, but this time ensuring the routers within the NSSA have
reachability to external routes injected into OSPF in other areas. To provide reachability to external routes
to routers within an NSSA, the NSSA ABR can be configured to inject a default route with the area areanumber nssa default-information-originate command. This way, routers that do not have specific
information, can follow the default route to reach external destinations.By providing the default route, the
NSSA ABR is telling the other routers that it can be used to reach external prefixes. This is because the NSSA
ABR itself will be the only router within the NSSA that will have external prefixes. It has these prefixes
because, by definition of it being an ABR, it is connected to Area 0 and is able to receive them. In other
words, the NSSA ABR will filter out the external LSAs from the NSSA just like the ABR filters out the external
LSAs for regular stub areas.
The LSA for the default route is injected as a Type-7 NSSA external default route LSA originated by the NSSA
ABR. This default route can be generated on the NSSA ABR even if a default route does not exist in the NSSA
ABR’s own routing table, a requirement that exists in order for an NSSA ASBR to flood a default route into
the NSSA.
Following defines area 4 as an NSSA on all routers in Area 4. The NSSA ABR R3 is configured to inject a
default route with the area 4 nssa default-information-originate command:
On R7:
R7(config)#router ospf 1
R7(config-router)#area 4 nssa
On SW2:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 576
SW2(config)#router ospf 1
SW2(config-router)#area 4 nssa
On R3:
R3(config)#router ospf 1
R3(config-router)#area 4 nssa default-information-originate
With the above, R3 now generates a default route as Type-7 NSSA external LSA:
R3#show ip ospf database nssa-external self-originate
OSPF Router with ID (0.0.0.3) (Process ID 1)
Type-7 AS External Link States (Area 4)
LS age: 10
Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0xFAB3
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 0
R7’s routing table shows the N2 default route:
R7#show ip route ospf | begin Gate
Gateway of last resort is 27.1.1.22 to network 0.0.0.0
O*N2
O IA
O IA
O IA
O IA
O IA
0.0.0.0/0 [110/1] via 27.1.1.22, 00:01:30, GigabitEthernet0/9
5.0.0.0/24 is subnetted, 1 subnets
5.5.5.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
8.0.0.0/24 is subnetted, 1 subnets
8.8.8.0 [110/15] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.0.0.0/24 is subnetted, 10 subnets
10.1.0.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.1.1.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.1.2.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 577
O IA
O IA
O IA
O IA
O IA
10.1.3.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.1.4.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.1.5.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.1.6.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.1.7.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
O IA
O IA
10.1.8.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
10.1.9.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/15] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
12.0.0.0/24 is subnetted, 1 subnets
12.1.1.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
13.0.0.0/24 is subnetted, 1 subnets
13.1.1.0 [110/12] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
16.0.0.0/24 is subnetted, 1 subnets
16.1.1.0 [110/24] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
20.2.1.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
20.2.2.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
22.0.0.0/24 is subnetted, 1 subnets
22.22.22.0 [110/2] via 27.1.1.22, 00:06:38, GigabitEthernet0/9
23.0.0.0/24 is subnetted, 1 subnets
23.1.1.0 [110/11] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
33.0.0.0/24 is subnetted, 1 subnets
33.33.33.0 [110/24] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
34.0.0.0/24 is subnetted, 1 subnets
34.1.1.0 [110/33] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
35.0.0.0/24 is subnetted, 1 subnets
35.1.1.0 [110/23] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
40.0.0.0/24 is subnetted, 1 subnets
40.4.0.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
45.0.0.0/24 is subnetted, 1 subnets
45.1.1.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
50.0.0.0/24 is subnetted, 1 subnets
50.5.0.0 [110/15] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
58.0.0.0/24 is subnetted, 1 subnets
58.1.1.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
112.0.0.0/24 is subnetted, 1 subnets
112.1.1.0 [110/14] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
145.1.0.0/24 is subnetted, 1 subnets
145.1.1.0 [110/13] via 27.1.1.22, 00:06:11, GigabitEthernet0/9
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O
O
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
O IA
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 578
Task 11
Implement the following policy for the routers in Area 5:



The routers must have reachability to the routes redistributed in this routing domain.
The routers should not maintain LSA Type 3 in the OSPF link state database.
The routers should not maintain LSA Types 4 or 5 in their OSPF link state database.
This task is a variant on the previous task. This time not only are external prefixes not allowed, but interarea prefixes are also disallowed within the area. Just like with stub areas, NSSAs can be converted to become
totally not-so-stubby-areas or totally NSSAs. Type-5 external LSAs are prohibited in totally NSSA along with
specific Type-3 summary LSAs. Similar to the previously discussed totally stub areas, reachability to both the
external and inter-area routes is provided by a default Type-3 summary LSA.
Whether an NSSA is a totally NSSA or not depends on the configuration of the NSSA ABR just as was seen
with the totally stub vs stub areas previously. An NSSA becomes a totally NSSA by configuring the area areanumber nssa no-summary command on the NSSA ABR. The no-summary keyword instructs the NSSA ABR
to inject a default Type-3 summary LSA into the area and suppress the generation of the specific Type-3
LSAs. Routers within the NSSA are configured with the same area area-number nssa command seen
previously. The following configures these commands on the devices in Area 5:
On R2:
R2(config)#router ospf 1
R2(config-router)#area 5 nssa no-summary
On SW1:
SW1(config)#router ospf 1
SW1(config-router)#area 5 nssa
On R6:
R6(config)#router ospf 1
R6(config-router)#area 5 nssa
The show ip route ospf command output on SW1 and SW6 shows the inter-area default route generated by
the NSSA ABR R2. In addition, the routes redistributed into OSPF by R6 appear as N2 routes on SW1:
R6#show ip route ospf | begin Gate
Gateway of last resort is 16.1.1.11 to network 0.0.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 579
O*IA
O
O
O
O
0.0.0.0/0 [110/12] via 16.1.1.11, 00:00:44, GigabitEthernet0/0
11.0.0.0/24 is subnetted, 1 subnets
11.11.11.0 [110/2] via 16.1.1.11, 00:00:44, GigabitEthernet0/0
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/12] via 16.1.1.11, 00:00:44, GigabitEthernet0/0
20.2.1.0 [110/12] via 16.1.1.11, 00:00:44, GigabitEthernet0/0
20.2.2.0 [110/12] via 16.1.1.11, 00:00:44, GigabitEthernet0/0
112.0.0.0/24 is subnetted, 1 subnets
112.1.1.0 [110/11] via 16.1.1.11, 00:00:44, GigabitEthernet0/0
O
On SW1:
SW1#show ip route ospf | begin Gate
Gateway of last resort is 112.1.1.2 to network 0.0.0.0
O*IA
O
O
O
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
0.0.0.0/0 [110/11] via 112.1.1.2, 00:02:08, Ethernet0/2
20.0.0.0/24 is subnetted, 3 subnets
20.2.0.0 [110/11] via 112.1.1.2, 00:02:08, Ethernet0/2
20.2.1.0 [110/11] via 112.1.1.2, 00:02:08, Ethernet0/2
20.2.2.0 [110/11] via 112.1.1.2, 00:02:08, Ethernet0/2
60.0.0.0/24 is subnetted, 10 subnets
60.1.0.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.1.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.2.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.3.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.4.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.5.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.6.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.7.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.8.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
60.1.9.0 [110/20] via 16.1.1.6, 00:02:08, Ethernet1/2
To review the Totally NSSA:
1.
2.
3.
4.
Does not allow Type 3 summary or Type-5 external LSAs
Allows external information to be flooded into the Area as Type-7 NSSA external LSAs
Is converted from a NSSA by issuing the area x nssa no-summary command on the NSSA ABR.
The NSSA ABR controls whether or not the NSSA is a totally NSSA by being configured not to flood
Type-3 summary LSAs into the area.
5. Once configured with the area x nssa no-summary command the NSSA ABR, will flood a Type-3
default summary LSA into the area to provide internal routers in the NSSA reachability to the rest of
the domain.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 580
6. The backbone area cannot be configured as an NSSA
7. Virtual links cannot flow through an NSSA
Task 12
Determine whether the routers in Area 0 maintain LSA Type 4 in their OSPF link state
database.
This section of the lab is not really a task but more of a thought exercise. At this point in the lab, the topology
is configured in the following manner:
1. OSPF process 1 is configured on all routers
2. The OSPF domain is divided into 6 areas:
a. Area 0 is the backbone area (default and unchangeable in OSPF)
i. Redistribution is being performed on R1
b. Area 1 is a stub area
c. Area 2 is totally stub area
d. Area 3 is an NSSA
i. Redistribution is being performed on the NSSA ASBR SW-4
e. Area 4 is an NSSA
f. Area 5 is a Totally Not So Stubby Area
i. Redistribution is being performed on the NSSA ASBR R6
With the above understanding of the topology, this task poses the question “Do the routers in Area 0
maintain Type-4 LSAs in their LSDBs?” Answering this question requires some foundational understanding of
the following aspects of OSPF:
1. What do Type-4 ASBR summary LSAs do?
2. When are Type-4 ASBR summary LSAs generated?
For the first aspect, an understanding of what Type-4 ASBR summary LSAs do for the OSPF domain and why
they are needed is in order. In Task 7 of this lab, the Type-4 ASBR summary LSA was briefly introduced. Here
a more thorough understanding of their purpose will be explained. To do so, the stub configuration is
removed from Area 1 in the topology using the no area 1 stub OSPF router configuration command on R4
and R5:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 581
On R4 and R5:
Rx(config)#router ospf 1
Rx(config-router)#no area 1 stub
The results are all of the external prefixes return to the routing table on R5:
On R5:
R5#show ip route ospf | include E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
O E2
60.1.0.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.1.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.2.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.3.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.4.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.5.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.6.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.7.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.8.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
60.1.9.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.0.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.1.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.2.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.3.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.4.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.5.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.6.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.7.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
101.1.9.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.0.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.1.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.2.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.3.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.4.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.5.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.6.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.7.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.8.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
104.104.9.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.0.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.1.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.2.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.3.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 582
O E2
O E2
O E2
O E2
O E2
O E2
111.111.4.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.5.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.6.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.7.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.8.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
111.111.9.0 [110/20] via 45.1.1.4, 00:01:11, GigabitEthernet0/4
These are the external prefixes redistributed by the ASBRs R1, SW4, R7, and R6. The important interaction
here occurs in the LSDB of the routers within Area 1, specifically R5. Remember that the LSDB is the database
that holds the graph of the topology. Prefixes to destinations internal to an area are described in Type-1
Router and Type-2 Network LSAs and become intra-area (O) OSPF routes in the routing table. Prefixes to
destinations from other areas are held in Type-3 Summary LSAs and become inter-area (O IA) OSPF routes in
the routing table. Routes to destinations outside of the entire OSPF domain are described in Type-5 external
and Type-7 NSSA external LSAs and are called external type 1 (O E/N1) or external type 2 (O E/N2) routes.
For this discussion, the LSDB for Area 1 is examined, specifically from R5’s perspective. The output is taken
from R5 directly, but it is important to understand that this output is the same on any router in Area 1. The
same output can be viewed on R4. This feature is important to OSPF in order to make sure all routes share
the same view of the network and do not form loops when running SPF.
If R5 needs to reach an intra-area prefix, such as R4’s loopback 40.4.0.4, it performs an intra-area lookup in
its LSDB. By examining R4’s Type-1 Router LSA, it knows that 40.4.0.4 is a stub network connected to R4
highlighted below:
R5#show ip ospf database router 0.0.0.4
OSPF Router with ID (0.0.0.5) (Process ID 1)
Router Link States (Area 1)
LS age: 312
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.4
Advertising Router: 0.0.0.4
LS Seq Number: 8000000D
Checksum: 0xEB8D
Length: 48
Area Border Router
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 40.4.0.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 583
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 45.1.1.5
(Link Data) Router Interface address: 45.1.1.4
Number of MTID metrics: 0
TOS 0 Metrics: 1
With this information, R5 knows that it just needs to be able to reach R4 to reach R4’s loopback. R5 can also
see that R4 is connected to a transit network node 45.1.1.5, highlighted in green above. This is a link to a
Type-2 network LSA shown below:
R5#show ip ospf database network 45.1.1.5
OSPF Router with ID (0.0.0.5) (Process ID 1)
Net Link States (Area 1)
LS age: 417
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 45.1.1.5 (address of Designated Router)
Advertising Router: 0.0.0.5
LS Seq Number: 80000009
Checksum: 0x47A8
Length: 32
Network Mask: /24
Attached Router: 0.0.0.5
Attached Router: 0.0.0.4
By examining the Type-2 LSA for the 45.1.1.5 network, R5 sees that it, too, is attached to the same network
node. R5 goes through this exercise to find the shortest path to reach that 40.4.0.0 network. Since it found a
viable path, it adds this route to its routing table with R4 as the next-hop as shown below:
R5#show ip route 40.4.0.4
Routing entry for 40.4.0.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 45.1.1.4 on GigabitEthernet0/4, 00:08:01 ago
Routing Descriptor Blocks:
* 45.1.1.4, from 0.0.0.4, 00:08:01 ago, via GigabitEthernet0/4
Route metric is 2, traffic share count is 1
This is a simple intra-area route calculation done by R5. Let’s change the focus to an inter-area route,
specifically, SW3’s loopback 0 interface IP address 33.33.33.33. R5 can see that the network is described in
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 584
the Type-3 Summary LSA shown below:
R5#show ip ospf database summary 33.33.33.0
OSPF Router with ID (0.0.0.5) (Process ID 1)
Summary Net Link States (Area 1)
LS age: 584
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 33.33.33.0 (summary Network Number)
Advertising Router: 0.0.0.4
LS Seq Number: 80000003
Checksum: 0x3D8A
Length: 28
Network Mask: /24
MTID: 0
Metric: 12
The Type-3 summary LSA contains 3 important pieces of information for R5: the network number, the
advertising router, and the netmask for the prefix. The network number and netmask are combined to form
the inter-area prefix 33.33.33.0/24. The advertising router tells R5 to which router this network is attached.
This brings in a very important point about how ABRs advertise inter-area prefixes. Notice in the above, R4’s
router ID 0.0.0.4 is listed as the advertising router. This means R4 is advertising that it is directly connected
to the network 33.33.33.0/24. In reality, it is not directly connected to that network, SW3 is directly
connected. However, R4, having a leg in Area 0, has proper reachability information to route packets to that
network.
ABRs advertise summary inter-area network information as if they themselves were directly connected to
the network. By doing so, the ABR is summarizing the Area 0 topology to all other routers in its nonbackbone area. In this case, the complexity of the inner workings of Area 0 and Area 3 are hidden from Area
1 when R4 advertises a direct connection to 33.33.33.0/24 to the routers in Area 1.
Because R5 sees R4 is directly connected to the network through the Type-3 LSA, it just needs to know how
to reach R4 to reach that network. From the previous exercise, R5 knows it can reach R4 through its transit
network connection. So R5 installs an inter-area route to 33.33.33.0/24 with R4 as the next hop:
R5#show ip route 33.33.33.0
Routing entry for 33.33.33.0/24
Known via "ospf 1", distance 110, metric 13, type inter area
Last update from 45.1.1.4 on GigabitEthernet0/4, 00:10:43 ago
Routing Descriptor Blocks:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 585
* 45.1.1.4, from 0.0.0.4, 00:10:43 ago, via GigabitEthernet0/4
Route metric is 13, traffic share count is 1
The above demonstrated how the LSDB is used to prove connectivity between different networks and serves
as a guide. Let’s apply the same logic to one of the external prefixes R5 has learned specifically the
101.1.0.0/24 network. This is an external prefix R5 learns through a Type-5 external LSA:
R5#show ip ospf database external 101.1.0.0
OSPF Router with ID (0.0.0.5) (Process ID 1)
Type-5 AS External Link States
LS age: 657
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 101.1.0.0 (External Network Number )
Advertising Router: 0.0.0.1
LS Seq Number: 80000005
Checksum: 0xA78D
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
From this Type-5 external LSA, R5 again knows three pieces of information: the network number, the
advertising router, the netmask. The prefix for this external network is 101.1.0.0/24. The router that is
advertising a direct connection to this prefix is a router with router ID 0.0.0.1. Similar to the other prefixes,
R5 simply needs to look in its LSDB for either an intra-area or inter-area path to reach 101.1.0.0/24. The
output below shows the fruits of this labor on R5:
R5#show ip ospf database router 0.0.0.1
OSPF Router with ID (0.0.0.5) (Process ID 1)
R5#show ip ospf database summary 0.0.0.1
OSPF Router with ID (0.0.0.5) (Process ID 1)
The output above was not cut off. R5 simply does not have any information about router 0.0.0.1 in its LSDB.
In the OSPF world, that means R5 isn’t aware that such a router even exists. As a result, R5 cannot calculate a
path to reach the network 101.1.0.0/24 as described by that Type-5 External LSA.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 586
R5 doesn’t know router 0.0.0.1 exists because that router is not in the same area as R5. In OSPF, a router
only knows about routers that are also in the same area in which that router resides. This is how they solve
intra-area paths to reach all other networks or devices in the OSPF domain. No matter where a device or
network is located in the OSPF domain, the local router MUST find an intra-area path to reach that device or
network node. If there is no such path, then the router ignores the LSA and doesn’t install a route to the
network or device.
The Type-5 external LSA always lists the ASBR that originated the LSA as the advertising router. External LSAs
have domain-wide flooding scope and as a result reach every other OSPF router in the domain that isn’t in a
stub area. An important point that needs to be stressed here is that in OSPF, routers are not allowed to
modify LSAs originated by other routers in the domain. This means R4, the ABR in Area 1, cannot change the
advertising router to itself for any Type-5 LSAs it floods into Area 1 that it didn’t originate.
The fact that R5 doesn’t have reachability information in its LSDB for router 0.0.0.1, and R4, its ABR, cannot
change the advertising router field in the Type-5 external LSA makes it seem like R5 will never be able to
reach the 101.1.0.0 network without some kind of default route. This is where the Type-4 ASBR Summary
LSA comes in to fill in the missing link. R4 cannot modify the original Type-5 external LSA, but it can create its
own LSA to fill in the missing reachability information.
In the topology, R1 is router 0.0.0.1. It is the only router that is an internal router to Area 0, meaning it only
has interfaces in Area 0. R4, as an ABR, is directly connected to Area 0 and thus has reachability information
for R1 in its LSDB as shown below:
On R4:
R4#show ip ospf database router 0.0.0.1
OSPF Router with ID (0.0.0.4) (Process ID 1)
Router Link States (Area 0)
LS age: 39
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.1
Advertising Router: 0.0.0.1
LS Seq Number: 80000014
Checksum: 0x1638
Length: 180
AS Boundary Router
Number of Links: 13
(The rest of the output is omitted for brevity)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 587
Since R4 knows how to reach R1, it can advertise this information to all routers in Area 1 using the Type-4
ASBR Summary LSA. The process is simple. R4 sees that R1 is an ASBR based on the contents of the Type-1
LSA received from R1.. R4 knows the advertising router is 0.0.0.1 in Area 0. When R4 advertises this Type-5
External LSA into Area 1, R4 also knows that 0.0.0.1 is not located inside Area 1. In response, R4 crafts a
Type-4 ASBR Summary LSA to artificially inject this reachability information into Area 1. Now when R5 tries to
lookup how to reach router 0.0.0.1 it finds the following LSA:
On R5:
R5#show ip ospf database asbr-summary 0.0.0.1
OSPF Router with ID (0.0.0.5) (Process ID 1)
Summary ASB Link States (Area 1)
LS age: 978
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 0.0.0.1 (AS Boundary Router address)
Advertising Router: 0.0.0.4
LS Seq Number: 80000001
Checksum: 0x63D2
Length: 28
Network Mask: /0
MTID: 0
Metric: 1
The LSA above tells R5 exactly what it needs. ASBR 0.0.0.1 is reachable through router 0.0.0.4. From the
previous examples, R5 fully knows how to reach 0.0.0.4 because it can find the Type-1 Router LSA 0.0.0.4
flooded. This is how the Type-4 ASBR summary LSA fills in the missing reachability information for external
prefixes.
From the above exercise, the need for Type-4 ASBR summary LSAs is established. They exist to provide
reachability information within the LSDB for ASBRs that are not in the same area as the router performing
the route calculation. It is called summary information because R4 is summarizing the Area 0 topology by
advertising a direct connection to the ASBR.
The next piece of the puzzle is when Type-4 LSAs are required. As stated in the above exercise, Type-4 LSAs
are only required whenever the ASBR is not located in the area in which the external information is being
advertised. Because R1 is not located in Area 1, R4 needed to flood Type-4 ASBR summary information into
Area 1 so the routers could reach the ASBR R1.
To continue with the original thought exercise, the configuration on R4 and R5 is reverted by configuring
Area 1 as a stub area again:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 588
On R4 and R5:
Rx(config)#router ospf 1
Rx(config-router)#area 1 stub
Going back to the original question: Do the routers in Area 0 maintain Type-4 LSAs in their LSDBs? The
answer is based on the following criteria:
1. Is there any redistribution happening in the OSPF domain?
2. Are the redistributing routers in Area 0?
From the summary earlier, it is clear that redistribution is being performed on R1 from area 0; SW4, R6, and
R7 that belong to their respective NSSAs. The routes redistributed by SW4, R6 and R7 appear as N2 routes on
their respective NSSA ABRs, SW5, R2 and R3:
On R2:
R2#show ip route ospf | include N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
60.1.0.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.1.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.2.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.3.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.4.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.5.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.6.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.7.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.8.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
60.1.9.0 [110/20] via 112.1.1.11, 00:29:25, GigabitEthernet0/0
On R3:
R3#show ip route ospf | include N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
111.111.0.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.1.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.2.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.3.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.4.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.5.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.6.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.7.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 589
O N2
O N2
111.111.8.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
111.111.9.0 [110/20] via 23.1.1.22, 00:38:32, GigabitEthernet0/9
On SW5:
SW5#show ip route ospf | include N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
O N2
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
104.104.0.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.1.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.2.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.3.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.4.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.5.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.6.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.7.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.8.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
104.104.9.0 [110/20] via 35.1.1.33, 01:08:09, Ethernet5/0
This means that, for all intents and purposes, SW4, R6 and R7 are ASBRs in the OSPF domain. These ASBRs
also do not exist in Area 0. Which means, the NSSA ABRs in those areas (SW5, R3, R2) should advertise a
Type-4 ASBR summary LSA for these prefixes correct?
There’s a problem with that theory. Type-7 NSSA summary LSAs cannot be propagated to normal areas. They
are intended to exist only in NSSAs because Type-5 external LSAs are not able to exist in NSSAs. Thus, some
device needs to translate the Type-7 NSSA external LSAs into an LSA the rest of the OSPF domain can
consume. This would be a Type-5 external LSA. This job falls on the NSSA ABR. In this case, SW5, R2 and R3
are responsible for translating the Type-7 NSSA external LSAs to Type-5 external LSAs, and flooding them into
Area 0. Let’s confirm this on R2 and R3. Truncated output from the show ip ospf database self-originate
command shows that SW5, R2 and R3 have converted the Type-7 NSSA external LSAs to Type-5 external
LSAs.
SW5#show ip ospf database self-originate | begin Type-5
Type-5 AS External Link States
Link ID
104.104.0.0
104.104.1.0
104.104.2.0
104.104.3.0
104.104.4.0
104.104.5.0
104.104.6.0
104.104.7.0
104.104.8.0
ADV Router
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
0.0.0.55
CCIE by Narbik Kocharians
Age
168
168
168
168
168
168
168
168
168
Seq#
Checksum Tag
0x80000003 0x0061E4 0
0x80000003 0x0056EE 0
0x80000003 0x004BF8 0
0x80000003 0x004003 0
0x80000003 0x00350D 0
0x80000003 0x002A17 0
0x80000003 0x001F21 0
0x80000003 0x00142B 0
0x80000003 0x000935 0
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 590
104.104.9.0
0.0.0.55
168
0x80000003 0x00FD3F 0
On R2:
R2#show ip ospf database self-originate | begin Type-5
Type-5 AS External Link States
Link ID
60.1.0.0
60.1.1.0
60.1.2.0
60.1.3.0
60.1.4.0
60.1.5.0
60.1.6.0
60.1.7.0
60.1.8.0
60.1.9.0
ADV Router
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
0.0.0.2
Age
58
58
58
58
58
58
58
58
58
58
Seq#
Checksum Tag
0x80000002 0x00DC6B 0
0x80000002 0x00D175 0
0x80000002 0x00C67F 0
0x80000002 0x00BB89 0
0x80000002 0x00B093 0
0x80000002 0x00A59D 0
0x80000002 0x009AA7 0
0x80000002 0x008FB1 0
0x80000002 0x0084BB 0
0x80000002 0x0079C5 0
On R3:
R3#show ip ospf database self-originate | begin Type-5
Type-5 AS External Link States
Link ID
111.111.0.0
111.111.1.0
111.111.2.0
111.111.3.0
111.111.4.0
111.111.5.0
111.111.6.0
111.111.7.0
111.111.8.0
111.111.9.0
ADV Router
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.3
0.0.0.3
Age
1081
1081
1081
1081
1081
1081
1081
1081
1081
1081
Seq#
Checksum Tag
0x80000002 0x009702 0
0x80000002 0x008C0C 0
0x80000002 0x008116 0
0x80000002 0x007620 0
0x80000002 0x006B2A 0
0x80000002 0x006034 0
0x80000002 0x00553E 0
0x80000002 0x004A48 0
0x80000002 0x003F52 0
0x80000002 0x00345C 0
Let’s expand and observe one of the translated Type-5 LSAs on R1:
On R1:
R1#show ip ospf database external 60.1.0.0
OSPF Router with ID (0.0.0.1) (Process ID 1)
Type-5 AS External Link States
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 591
LS age: 223
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 60.1.0.0 (External Network Number )
Advertising Router: 0.0.0.2
LS Seq Number: 80000002
Checksum: 0xDC6B
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 16.1.1.6
External Route Tag: 0
The translated Type-5 external LSA above was advertised by router 0.0.0.2, which is R2 in the topology.
According to the previous exercise, the advertising router of a Type-5 external LSA is the ASBR that
originated that LSA. Even though R6 is the real ASBR that originated the LSA, because R2 is generating the
Type-5 LSA, it assumes the role of the ASBR. It is referred to as a pseudo ASBR.
R2 isn’t just acting as a pseudo ASBR in this instance. It is also the NSSA ABR, meaning it sits on the edge
between two Areas, the backbone Area 0 and the NSSA 5. It, too, performs the same sanity check that R4
performed when advertising the Type-5 LSA into Area 0. That check basically amounts to “Am I receiving a
Type-1 LSA from an ASBR from another area?” The answer is going to be “no” in this case since R6 is an NSSA
ASBR and not a normal ASBR. Thus, R2 doesn’t flood a Type-4 ASBR Summary LSA for that router. It also will
not flood a Type-4 ASBR Summary LSA for itself because it has already done so using its own router LSA as
shown below:
R1#show ip ospf database router 0.0.0.2
OSPF Router with ID (0.0.0.1) (Process ID 1)
Router Link States (Area 0)
LS age: 554
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 0.0.0.2
Advertising Router: 0.0.0.2
LS Seq Number: 80000007
Checksum: 0xF115
Length: 36
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 592
Area Border Router
AS Boundary Router
Number of Links: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 12.1.1.1
(Link Data) Router Interface address: 12.1.1.2
Number of MTID metrics: 0
TOS 0 Metrics: 1
Once again, the output above will be consistent for every router attached to Area 0, not just R1. The output
confirms that if R1 had to send packets to the 60.1.0.0, it knows it has to send the packets to R2 because of
the advertising router field in the Type-5 external LSA. R1 knows how to reach the advertising router because
of the router LSA shown above. These facts negate the need for R2 to flood a Type-4 ASBR summary LSA into
Area 0. The pseudo ASBR that originated the Type-5 external LSA, R2 itself, exists in Area 0. The show ip ospf
border-routers command output from R1 confirms that 0.0.0.2 (R2) is indeed listed as an ABR/ASBR in Area
0:
R1#show ip ospf border-routers | begin Router Routing Table
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 0.0.0.3 [1] via 13.1.1.3, GigabitEthernet0/3, ABR/ASBR, Area 0, SPF 16
i 0.0.0.2 [1] via 12.1.1.2, GigabitEthernet0/2, ABR/ASBR, Area 0, SPF 16
i 0.0.0.4 [1] via 145.1.1.4, GigabitEthernet0/0, ABR, Area 0, SPF 16
i 0.0.0.55 [1] via 145.1.1.55, GigabitEthernet0/0, ABR/ASBR, Area 0, SPF 16
This concept applies to R1, R3 and SW5 as well. The implication is that because all ASBRs, be they actual
ASBRs (R1) or pseudo ASBRS (SW5, R2 and R3), in the topology exist in Area 0, the ABRs will not flood a Type4 ASBR summary LSA into Area 0. Thus, no Type-4 ASBR summary LSA is maintained in Area 0.
This section went into detail on how and why Type-4 ASBR summary LSAs are injected into an area in an
OSPF domain. The following is a quick recap of the important points:
1. Type-4 ASBR summary LSAs describe reachability information for ASBRs in the OSPF domain
2. Type-4 ASBR summary LSAs are flooded by ABRs whenever a Type-5 external LSA is flooded that
wasn’t advertised by a router in the Area in which the Type-5 external LSA is being flooded.
3. Type-7 NSSA external LSAs are not allowed in areas that are not configured as NSSAs. As a result, the
NSSA ABRs must translate these LSAs into Type-5 external LSAs if reachability from other OSPF
domains is desired.
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 593
4. NSSA ABRs become pseudo ASBRs when translating Type-7 NSSA external LSAs to Type-5 external
LSAs.
5. Type-4 ASBR summary LSAs are not needed in the area in which the ASBR resides.
Task 13
Configure R3 to redistribute its Lo1 interface such that existing and future redistributed
routes by this router are only injected into Area 0 and not into Area 4. Do not configure
an ACL or a prefix list to accomplish this task.
This task seems relatively straightforward. The directive is to redistribute R3’s Lo1 interface into the OSPF
domain without injecting an external prefix into Area 4. This requirement may seem a bit odd. Area 4 is an
NSSA. Logically speaking, it should never have an external prefix within it that wasn’t originated within Area
4 itself.
This concept is explored in this task. First, the show run int loopback 1 command output from R3 reveals
the IP address assigned to this loopback is 33.3.3.3/24:
On R3:
R3#show run interface lo1 | begin interface
interface Loopback1
ip address 33.3.3.3 255.255.255.0
ip ospf network point-to-point
end
Since the task ultimately requires redistributing this 33.3.3.0/24 loopback interface IP into OSPF,
redistribution of the above loopback is configured on R3. The configuration begins by creating a route-map
named “TST” that matches the loopback 1 interface on R3 as shown below:
R3(config)#route-map TST
R3(config-route-map)#match interface lo1
With this route-map created, the redistribute connected route-map TST subnets command under OSPF
router configuration mode is then issued. The route-map “TST” ensures only the loopback 1 interface’s IP is
redistributed into OSPF:
R3(config)#router ospf 1
R3(config-router)#redistribute connected route-map TST subnets
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 594
As seen with previous redistribution tasks, after configuring redistribution on R3, R3 generates a Type-5
external LSA for the 33.3.3.0/24 network. This LSA is flooded into all areas that accept Type-5 external LSAs,
specifically Area 0 where it is received by R1, R2, R4, and SW5. The output below confirms that R1 installs
the external prefix as an OSPF E2 route in its routing table with R3 (the ASBR) as its next hop.
On R1:
R1#show ip route 33.3.3.3
Routing entry for 33.3.3.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
Last update from 13.1.1.3 on GigabitEthernet0/3, 00:03:37 ago
Routing Descriptor Blocks:
* 13.1.1.3, from 0.0.0.3, 00:03:37 ago, via GigabitEthernet0/3
Route metric is 20, traffic share count is 1
On R3:
R3 originates a Type-5 LSA for the 33.3.3.0 network in Area 0:
R3#show ip ospf database external 33.3.3.0
OSPF Router with ID (0.0.0.3) (Process ID 1)
Type-5 AS External Link States
LS age: 356
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 33.3.3.0 (External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0xE194
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
With the above configuration, the first part of the task is completed. The next step is to verify the conditions
of the second part of the task have been met. The task states that the loopback 1 address on R3 should NOT
be redistributed into Area 4. To verify this is the case, the show ip route 33.3.3.0 command is used on SW2
and R7 in Area 4:
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 595
On SW2:
SW2#show ip route 33.3.3.0
Routing entry for 33.3.3.0/24
Known via "ospf 1", distance 110, metric 20, type NSSA extern 2,
forward metric 10
Last update from 23.1.1.3 on Ethernet0/3, 00:08:32 ago
Routing Descriptor Blocks:
* 23.1.1.3, from 0.0.0.3, 00:08:32 ago, via Ethernet0/3
Route metric is 20, traffic share count is 1
On R7:
R7#show ip route 33.3.3.0
Routing entry for 33.3.3.0/24
Known via "ospf 1", distance 110, metric 20, type NSSA extern 2,
forward metric 11
Last update from 27.1.1.22 on GigabitEthernet0/9, 00:09:36 ago
Routing Descriptor Blocks:
* 27.1.1.22, from 0.0.0.3, 00:09:36 ago, via GigabitEthernet0/9
Route metric is 20, traffic share count is 1
Both SW2 and R7 have installed the external prefix 33.3.3.0/24 even though they exist in an NSSA. The show
ip route output above indicates the route the two devices installed is an OSPF NSSA external 2 route. NSSA
external 2 routes are derived from OSPF Type-7 NSSA external LSAs. This means some router in Area 4 has
originated the 33.3.3.0/24 prefix into Area 4.
The culprit here is R3. When R3 is configured to redistribute the network into OSPF, it will redistribute it for
all areas to which it is attached. In normal cases, this is as simple as generating a single Type-5 external LSA.
Type-5 external LSAs have a domain-wide flooding scope, meaning the router can flood the same LSA in all
non-sub areas. In R3’s case, however, it has an interface in the backbone area and the NSSA 4. In order to
redistribute the prefix for all areas to which it is attached, R3 must create two LSAs. A Type-5 external LSA
for the backbone and all other areas and a Type-7 NSSA external LSA for the NSSA 4. As a result, the Type-7
LSA gets flooded into Area 4:
On R3:
R3#show ip ospf database external 33.3.3.0
OSPF Router with ID (0.0.0.3) (Process ID 1)
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 596
Type-5 AS External Link States
LS age: 688
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 33.3.3.0 (External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0xE194
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
R3#show ip ospf database nssa-external 33.3.3.0
OSPF Router with ID (0.0.0.3) (Process ID 1)
Type-7 AS External Link States (Area 4)
LS age: 729
Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 33.3.3.0 (External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0xC5AE
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
It is important to understand what’s happening. R3 is redistributing two separate external LSAs. A Type-5
external LSA and a Type-7 NSSA external LSA. What R3 is not doing is translating its Type-5 external LSA into
a Type-7 NSSA external LSA. Such translation does not exist in OSPF. If it did, it would negate the advantages
of configuring an area to be an NSSA. If such a translation existed, the external LSAs which the NSSA aims to
prevent from coming into the area would be simply re-flooded as Type-7 LSAs.
R3 can be prevented from flooding both Type-5 external LSAs and Type-7 NSSA external LSAs with the area
4 nssa default-information-originate no-redistribution command on the NSSA ABR R3. Adding the noCCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 597
redistribution parameter to the command instructs R3 to only generate a Type-7 NSSA external default into
the NSSA and to not redistribute other external prefixes into the NSSA. The configuration for this is shown
below:
R3(config)#router ospf 1
R3(config-router)#area 4 nssa default-information-originate noredistribution
After completing the above configuration, notice the outputs below. R3 no longer generates a Type-7 LSA
for the 33.3.3.0/24 network. Both SW2 and R7 do not have a route to this redistributed network:
On R3:
R3#show ip ospf database nssa-external 33.3.3.0
OSPF Router with ID (0.0.0.3) (Process ID 1)
On SW2:
SW2#show ip route 33.3.3.0
% Subnet not in table
SW2#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 1", distance 110, metric 1, candidate default path,
type NSSA extern 2, forward metric 10
Last update from 23.1.1.3 on Ethernet0/3, 01:16:44 ago
Routing Descriptor Blocks:
* 23.1.1.3, from 0.0.0.3, 01:16:44 ago, via Ethernet0/3
Route metric is 1, traffic share count is 1
On R7:
R7#show ip route 33.3.3.0
% Subnet not in table
R7#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 1", distance 110, metric 1, candidate default path,
type NSSA extern 2, forward metric 11
Last update from 27.1.1.22 on GigabitEthernet0/9, 01:18:03 ago
Routing Descriptor Blocks:
* 27.1.1.22, from 0.0.0.3, 01:18:03 ago, via GigabitEthernet0/9
Route metric is 1, traffic share count is 1
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 598
This configuration causes no reachability problems in Area 4. Because R3 is still flooding a default-route into
the NSSA, SW2 and R7 still have a way to reach prefixes for which they do not have specific routes for in
their routing tables. As long as that default route exists, there is no reason for R3 to redistribute external
prefixes into the NSSA.
Reachability is confirmed through pings from SW2 and R7 as shown below:
On SW2:
SW2#ping 33.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 33.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
On R7:
R7#ping 33.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 33.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Task 14
Configure the following ABRs so that the default route that they inject has an OSPF cost
based on the following table:
ABR/Area
R4/Area 1
R9/Area 2
R3/Area 4
R2/Area 5
OSPF Cost of the Injected Default Route
40
133
30
20
R4, SW5, R3 and R2 are the ABRs for Area 1, Area 2, Area 4 and Area 5 respectively. These ABRs are flooding
a default route into their respective stub areas. A default route acts as a least-specific match in the router’s
routing table. It matches all destinations as a last resort whenever the router has no more-specific prefixes
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 599
in its routing table. Acting as such, it is used to replace external routes and, in some cases, inter-area routes
for devices in stub areas.
When the ABRs flood these default routes, they are flooded by default with an OSPF cost of 1. This can be
seen with the show ip ospf | begin Area 1 command output from R4, the ABR for Area 1:
On R4:
R4#show ip ospf | begin Area 1
Area 1
Number of interfaces in this area is 2
It is a stub area
Generates stub default route with cost 1
Area has no authentication
SPF algorithm last executed 00:58:55.008 ago
SPF algorithm executed 16 times
Area ranges are
Number of LSA 32. Checksum Sum 0x114D3B
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
The highlighted text above indicates that R4 is actively flooding a default stub route with a cost of 1 for Area
1. R4 advertises this route as a Type-3 default summary LSA. Other routers in Area 1 will take the cost
advertised in the LSA and add their own cost used to reach the advertising router of the LSA which in this
case is R4 itself. R5 for example, has a cost of 1 to reach the ABR R4 over itse G0/4 interface as shown
below:
On R5:
R5#show ip ospf interface g0/4 | include Cost
Process ID 1, Router ID 0.0.0.5, Network Type BROADCAST, Cost: 1
Topology-MTID
Cost
Disabled
Shutdown
Topology Name
To determine the total cost of the default route, R5 adds its own interface cost of 1 to the cost of the
default route advertised by R4 in the Type-3 default summary LSA. The resultant cumulative cost is 2. R5’s
routing table entry for the default route verifies the cost of 2 for the 0.0.0.0 route:
R5#show ip route 0.0.0.0
CCIE by Narbik Kocharians
CCIE Enterprise Infrastructure Foundation v1.0
© 2021 Narbik Kocharians. All rights reserved
Page 600
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 1", distance 110, metric 2, candidate default path,
type inter area
Last update from 45.1.1.4 on GigabitEthernet0/4, 01:04:42 ago
Routing Descriptor Blocks:
* 45.1.1.4, from 0.0.0.4, 01:04:42 ago, via GigabitEthernet0/4
Route metric is 2, traffic share count is 1
The goal of the task is to modify this default behavior based on the table shown in the beginning of the task.
In this case, R4 should redistribute its default summary route with a cost of 40 instead of the default of 1.
The area area-number default-cost value command in OSPF router configuration mode can be used to
affect this change. The area area-number default-cost value command modifies OSPF’s default cost for
advertising default routes into OSPF stub area and NSSAs.
For R4, the area 1 default-cost 40 command is entered below to change R4’s default cost to 40 for its
default summary LSA:
On R4:
R4(config)#router ospf 1
R4(config-router)#area 1 default-cost 40
The modified cost value is now reflected in