Troubleshooting IP Routing

Protocols
Zaheer Aziz, CCIE #4127
Johnson Liu, CCIE #2637
Abe Martey, CCIE #2373
Faraz Shamim, CCIE #4131

Cisco Press

Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA
ii

Troubleshooting IP Routing Protocols

Zaheer Aziz, Johnson Liu, Abe Martey, Faraz Shamim
Copyright 2002 Cisco Systems, Inc.
Published by:
Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic
or mechanical, including photocopying, recording, or by any information storage and retrieval system, without
written permission from the publisher, except for the inclusion of brief quotations in a review.
Printed in the United States of America 3 4 5 6 7 8 9 0
Third Printing January 2004
Library of Congress Cataloging-in-Publication Number: 2001086619
ISBN: 1-58705-019-6

Warning and Disclaimer

This book is designed to provide information about troubleshooting IP routing protocols, including RIP, IGRP,
EIGRP, OSPF, IS-IS, PIM, and BGP. 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 and 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.

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 e-mail at
[email protected]. Please be sure to include the book title and ISBN in your message.
We greatly appreciate your assistance.
 iii

Publisher John Wait

Editor-in-Chief John Kane
Cisco Systems Management Michael Hakkert
Tom Geitner
William Warren
Production Manager Patrick Kanouse
Executive Editor Brett Bartow
Acquisitions Editor Amy Lewis
Development Editor Christopher Cleveland
Project Editor San Dee Phillips
Copy Editor Krista Hansing
Technical Editors Brian Morgan, Harold Ritter, John Tiso
Team Coordinator Tammi Barnett
Book Designer Gina Rexrode
Cover Designer Louisa Adair
Composition Publication Services, Inc.
Indexer Tim Wright
iv

About the Authors

Zaheer Aziz, CCIE #4127, is a network consulting engineer in the Internet Infrastructure Services group for Cisco
Systems, Inc. Zaheer provides consulting services to major ISPs in the MPLS and IP routing protocols area. In his
last five years at Cisco, Zaheer has been actively involved in speaking at Cisco Networkers conferences and at several
Cisco events. Zaheer occasionally writes for Cisco Packet magazine and for Spider Internet magazine, Pakistan on
topics of MPLS and BGP. He holds a master’s degree in electrical engineering from Wichita State University, Wich-
ita, KS and enjoys reading and playing cricket and Ping-Pong. Zaheer is married and has a loving five-year-old boy,
Taha Aziz.
Johnson Liu, CCIE #2637, is a senior customer network engineer with the Advance Network Services Team for
the enterprise in Cisco Systems. He obtained his MSEE degrees at the University of Southern California and has been
with Cisco Systems for more than five years. He is the technical editor for other Cisco Press books, including Internet
Routing Architectures and Large-Scale IP Network Solutions. Johnson has been involved in many large-scale IP net-
work design projects involving EIGRP, OSPF, and BGP for large enterprise and service provider customers. Johnson
is also a regular speaker for deploying and troubleshooting EIGRP at the Networkers conference.
Abe Martey, CCIE #2373, is a product manager of the Cisco 12000 Internet Router Series. Abe specializes in
high-speed IP routing technologies and systems. Prior to this position, Abe worked as a support engineer in the
Cisco Technical Assistance Center (TAC), specializing in IP routing protocols and later on the ISP Team (now
Infrastructure Engineering Services Team), where he worked closely with tier one Internet service providers.
Abe holds a master’s degree in electrical engineering and has been with Cisco Systems for over six years. Abe
is also the author of IS-IS Design Solutions from Cisco Press.
Faraz Shamim, CCIE #4131, is a network consulting engineer with the Advance Network Services Team for the
Service Provider (ANS-SP) for Cisco Systems, Inc. He provides consulting services to his dedicated Internet service
providers. Faraz wrote several documents, white papers, and technical tips for ODR, OSPF, RIP, IGRP, EIGRP, and
BGP on Cisco Connection Online (CCO), (www.cisco.com). Faraz has also been engaged in developing and teach-
ing the Cisco Internetworking Basic and Advance Bootcamp Training for Cisco new-hire engineers. He has also
taught the Cisco Internetworking Bootcamp Course to MS students at the University of Colorado at Boulder (BU)
and Sir Syed University of Engineering & Technology (SSUET), Karachi, Pakistan. Faraz has been a visiting faculty
member for SSUET and also gave a lecture on OSPF to Lahore University of Management & Sciences (LUMS),
Lahore, Pakistan. Faraz has been engaged in developing CCIE lab tests and proctoring the CCIE lab. Faraz actively
speaks at the Networkers conference on the subject of OSPF. Like other authors of this book, he also started his
career at the Cisco Technical Assistant Center (TAC) providing support for customers in IP routing protocols. Faraz
has been with Cisco Systems for five years.

About the Technical Reviewers

Brian Morgan, CCIE #4865 , CCSI, is the Director of Data Network Engineering at Allegiance Telecom, Inc. He
has been in the networking industry for more than 12 years. Before going to Allegiance, Morgan was an instructor/
consultant teaching ICND, BSCN, BSCI, CATM, CVOICE, and BCRAN. He is a co-author of the Cisco CCNP
Remote Access Exam Certification Guide and a technical editor of numerous Cisco Press titles.
Harold Ritter, CCIE # 4168 , is a network consulting engineer for Cisco Advanced Network Services. He is res-
ponsible for helping Cisco top-tier customers to design, implement, and troubleshoot routing protocols in their
environment. He has been working as a network engineer for more than eight years.
John Tiso, CCIE #5162, is one of the senior technologists of NIS, a Cisco Systems Silver partner. He has a bachelor
of science degree from Adelphi University. Tiso also holds the CCDP certification, Cisco Security and Voice Access
Specializations, and Sun Microsystems, Microsoft, and Novell certifications. He has been published in several indus-
try publications. He can be reached through e-mail at [email protected].
 v

Dedications
Zaheer Aziz:
I would like to dedicate this book to my late father (may God bless his soul) for his struggling life for betterment of
our life, to a person whose self-made, hardworking, and not-so-easy life history became a catalyst for the relatively
little hard work I have put in my life. Undoubtedly, he would have tremendously enjoyed seeing this book, but he is
not here. Truly, his Air Force blood would have rushed fast seeing this book, but he is not here. Verily, he would
have immensely applauded me in seeing this book, but he is not here. Therefore, I want my mother, who has put in
equal hard work in our life, to enjoy this accomplishment and success. She deserves equal credit in the success of
our family, and I wish her a very long and happy life.
Johnson Liu:
I dedicate this book with my deepest love and affection to my wife, Cisco Liu, who has given me the inspiration and
support to write this book.
Abe Martey:
I’d like to dedicate this book to all previous and current engineers of the Cisco Worldwide TAC for their remarkable
enthusiasm, dedication, and excellence in providing technical and troubleshooting assistance to network operators
in every corner of our planet and in space.
Faraz Shamim:
I would like to dedicate this book to my parents, whose favors I can never return and whose prayers I will always
need. To my wife, who encouraged me when I felt too lazy to write, and to my sons, Ayaan and Ameel, who waited
patiently for my attention on many occasions.
vi

Acknowledgments
Faraz Shamim:
Alhamdulillah! I thank God for giving me the opportunity to write this book, which I hope will help many people in
resolving their routing issues.
I would like to thank my manager, Srinivas Vegesna, and my previous manager and mentor, Andrew Maximov, for
supporting me in this book project. Special thanks goes to Bob Vigil, who let me use some of his presentation mate-
rial in the RIP and IGRP chapter. I would also like to thank Alex Zinin for clearing some of my OSPF concepts that
I used in this book. I would like to thank my co-authors, Zaheer Aziz, Abe Martey, and Johnson Liu, who put up
with my habit of reminding them of their chapter deadlines. I would also like to thank Chris Cleveland and Amy
Lewis of Cisco Press for their understanding whenever we were late in submitting our chapters.
Zaheer Aziz:
All thanks to God for giving me strength to work on this book. I heartily thank my wife for her support, patience,
and understanding that helped me put in many hours on this book. I appreciate the flexibility of my employer, Cisco
Systems, Inc. (in particular, my manager, Srinivas Vegesna) for allowing me to work on this book while keeping my
day job. Many thanks to Syed Faraz Shamim (lead author of this book), who invited me through a cell-phone call
from San Jose to Washington, D.C., where I was attending IETF 46 in 1999, to co-author this book. Thanks to Moiz
Moizuddin for independently reviewing the technical content of my chapters. I would like to credit my mentor,
Syed Khalid Raza, for his continuous guidance and for showing me the world of BGP. Finally, I wish to thank Cisco
Press, who made this book possible—in particular, Christopher Cleveland and Brian Morgan, whose suggestions
greatly improved the quality of this book and made this process go smoothly.
Johnson Liu:
I would like to thank my friends and colleagues at Cisco Systems, with whom I spent many late hours with trying to
troubleshoot P1 routing protocol problems. Their professionalism and knowledge are simply unparalleled. Special
thanks to my managers, Andrew Maximow and Raja Sundaram, who have given me all their support throughout my
career at Cisco Systems. Finally, I would like to thank my technical editors for their invaluable input and sugges-
tions to improve this book.
Abe Martey:
First of all, I’d like to express sincere thanks to the co-authors and colleagues at work, Faraz, Johnson, and Zaheer
for dreaming up this title and inviting me to participate in its materialization. We all worked on the Cisco Technical
Assistance Center (TAC) Routing Protocol Team, giving us quite a bit of experience troubleshooting IP routing
problems. This work is our attempt to generously share that experience with a larger audience beyond the Cisco
Systems work environment.
I received a lot of support, mentorship, and training from many Cisco TAC and development engineers, as well
as many direct and nondirect managers as a TAC Engineer. Hats off to this unique breed of talented individuals,
women and men, who have committed their lives to keep the Internet running. I’d also like to thank these folks (too
many of them to name here) for every bit of knowledge and wisdom that they’ve shared with me over the years.
Over time, I’ve developed great personal relationships with various networking professionals worldwide, all of
whom I met as customers or through IETF, NANOG, IEEE, and other professional conferences and meetings. I’d
like to sincerely thank them for sharing with me their knowledge and expertise, as well as their professional insights
and visions into the future of networking technology.
I’d also like to express my sincerest gratitude to Amy Lewis and Chris Cleveland, both of Cisco Press, and the tech-
nical editors for their roles in helping bring this book to fruition. Many thanks to several close relatives for their
support and encouragement all through this project.
 vii

Contents at a Glance
Preface xxxiii
Introduction xxxiv
Chapter 1 Understanding IP Routing 3
Chapter 2 Understanding Routing Information Protocol (RIP) 29
Chapter 3 Troubleshooting RIP 47
Chapter 4 Understanding Interior Gateway Routing Protocol (IGRP) 127
Chapter 5 Troubleshooting IGRP 137
Chapter 6 Understanding Enhanced Interior Gateway Routing Protocol (EIGRP) 207
Chapter 7 Troubleshooting EIGRP 227
Chapter 8 Understanding Open Shortest Path First (OSPF) 295
Chapter 9 Troubleshooting OSPF 341
Chapter 10 Understanding Intermediate System-to-Intermediate System (IS-IS) 533
Chapter 11 Troubleshooting IS-IS 585
Chapter 12 Understanding Protocol Independent Multicast (PIM) 625
Chapter 13 Troubleshooting PIM 643
Chapter 14 Understanding Border Gateway Protocol Version 4 (BGP-4) 659
Chapter 15 Troubleshooting BGP 719
Appendix Answers to Review Questions 839
Index 849
viii

Table of Contents
Preface xxxiii
Introduction xxxiv
Chapter 1 Understanding IP Routing 3
IP Addressing Concepts 5
IPv4 Address Classes 5
IPv4 Private Address Space 7
Subnetting and Variable-Length Subnet Masks 8
Classless Interdomain Routing 10
Static and Dynamic Routes 11
Dynamic Routing 11
Unicast Versus Multicast IP Routing 12
Classless Versus Classful IP Routing Protocols 15
Interior Gateway Protocols Versus Exterior Gateway Protocols 15
Distance Vector Versus Link-State Protocols 18
Distance Vector Routing Concepts 18
Link-State Protocols 23
Routing Protocol Administrative Distance 24
Fast Forwarding in Routers 25
Summary 26
Review Questions 26
References 27
Chapter 2 Understanding Routing Information Protocol (RIP) 29
Metric 29
Timers 30
Split Horizon 30
Split Horizon with Poison Reverse 30
RIP-1 Packet Format 31
RIP Behavior 31
RIP Rules for Sending Updates 31
RIP Rules for Receiving Updates 33
Example of Sending Updates 33
Example of Receiving Updates 35
Why RIP Doesn’t Support Discontiguous Networks 36
 ix

Why RIP Doesn’t Support Variable-Length Subnet Masking 37

Default Routes and RIP 39
Protocol Extension to RIP 40
Route Tag 40
Subnet Mask 41
Next Hop 41
Multicast Capability 42
Authentication 42
Compatibility Issues 43
Summary 44
Review Questions 44
Further Reading 45
Chapter 3 Troubleshooting RIP 47
Flowcharts to Solve Common RIP Problems 48
Troubleshooting RIP Routes Installation 52
Problem: RIP Routes Not in the Routing Table 52
RIP Routes Not in the Routing Table—Cause: Missing or Incorrect network
Statement 53
Debugs and Verification 54
Solution 55
RIP Routes Not in the Routing Table—Cause: Layer 1/2 Is Down 56
Debugs and Verification 57
Solution 58
RIP Routes Not in the Routing Table—Cause: distribute-list in Is Blocking the
Route 58
Debugs and Verification 58
Solution 59
RIP Routes Not in the Routing Table—Cause: Access List Blocking RIP Source
Address 60
Debugs and Verification 60
Solution 62
RIP Routes Not in the Routing Table—Cause: Access List Blocking RIP Broadcast
or Multicast (in Case of RIP-2) 63
Debugs and Verification 63
Solution 64
RIP Routes Not in the Routing Table—Cause: Incompatible RIP Version Type 65
Debugs and Verification 65
Solution 67
x

RIP Routes Not in the Routing Table—Cause: Mismatch Authentication Key

(RIP-2) 68
Debugs and Verification 69
Solution 70
RIP Routes Not in the Routing Table—Cause: Discontiguous Network 71
Debugs and Verification 72
Solution 73
RIP Routes Not in the Routing Table—Cause: Invalid Source 74
Debugs and Verification 74
Solution 76
RIP Routes Not in the Routing Table—Cause: Layer 2 Problem (Switch, Frame
Relay, Other Layer 2 Media) 76
Debugs and Verification 77
Solution 78
RIP Routes Not in the Routing Table—Cause: Offset List Has a Large Metric
Defined 79
Debugs and Verification 80
Solution 81
RIP Routes Not in the Routing Table—Cause: Routes Reached RIP Hop Count
Limit 81
Debugs and Verification 82
Solution 83
Problem: RIP Is Not Installing All Possible Equal-Cost Paths—Cause: maximum-path
Command Restricts RIP from Installing More Than One Path 83
Debugs and Verification 85
Solution 85
Troubleshooting RIP Routes Advertisement 86
Problem: Sender Is Not Advertising RIP Routes 86
Sender Is Not Advertising RIP Routes—Cause: Missing or Incorrect network
Statement 87
Debugs and Verifications 88
Solution 88
Sender Is Not Advertising RIP Routes—Cause: Outgoing Interface Is Down 89
Debugs and Verification 90
Solution 91
Sender Is Not Advertising RIP Routes—Cause: distribute-list out Is Blocking the
Route 91
Debugs and Verification 91
Solution 92
Sender Is Not Advertising RIP Routes—Cause: Advertised Network Interface Is
Down 93
Debugs and Verification 94
Solution 94
 xi

Sender Is Not Advertising RIP Routes—Cause: Outgoing Interface Is Defined

Passive 95
Debugs and Verification 95
Solution 96
Sender Is Not Advertising RIP Routes—Cause: Broken Multicast Capability
(Frame Relay) 96
Debugs and Verification 97
Solution 98
Sender Is Not Advertising RIP Routes—Cause: Misconfigured neighbor
Statement 99
Debugs and Verification 99
Solution 100
Sender Is Not Advertising RIP Routes—Cause: Advertised Subnet Is VLSM 100
Debugs and Verification 101
Solution 101
Sender Is Not Advertising RIP Routes—Cause: Split Horizon Is Enabled 102
Debugs and Verification 104
Solution 105
Problem: Subnetted Routes Missing from the Routing Table of R2—Cause:
Autosummarization Feature Is Enabled 106
Debugs and Verification 108
Solution 108
Troubleshooting Routes Summarization in RIP 109
Problem: RIP-2 Routing Table Is Huge—Cause: Autosummarization Is Off 109
Debugs and Verification 110
Solution 111
Problem: RIP-2 Routing Table Is Huge—Cause: ip summary-address Is Not Used 111
Debugs and Verification 112
Solution 112
Troubleshooting RIP Redistribution Problems 113
Debugs and Verification 115
Solution 115
Troubleshooting Dial-on-Demand Routing Issues in RIP 116
Problem: RIP Broadcast Is Keeping the ISDN Link Up—Cause: RIP Broadcasts Have
Not Been Denied in the Interesting Traffic Definition 117
Debugs and Verification 118
Solution 119
Problem: RIP Updates Are Not Going Across the Dialer Interface—Cause: Missing
broadcast Keyword in a dialer map Statement 120
Debugs and Verification 121
Solution 122
xii

Troubleshooting Routes Flapping Problem in RIP 122

Debugs and Verification 122
Solution 124
Chapter 4 Understanding Interior Gateway Routing Protocol (IGRP) 127
Metrics 127
Timers 129
Split Horizon 130
Split Horizon with Poison Reverse 130
IGRP Packet Format 131
IGRP Behavior 131
Default Route and IGRP 132
Unequal-Cost Load Balancing in IGRP 133
Summary 135
Review Questions 135
Chapter 5 Troubleshooting IGRP 137
Flowcharts to Solve Common IGRP Problems 138
Troubleshooting IGRP Route Installation 142
Problem: IGRP Routes Not in the Routing Table 142
IGRP Routes Not in the Routing Table—Cause: Missing or Incorrect network
Statement 143
Debugs and Verification 144
Solution 145
IGRP Routes Not in the Routing Table—Cause: Layer 1/2 Is Down 147
Debugs and Verification 147
Solution 148
IGRP Routes Not in the Routing Table—Cause: distribute-list in Is Blocking the
Route 149
Debugs and Verification 150
Solution 150
IGRP Routes Not in the Routing Table—Cause: Access List Blocking IGRP Source
Address 151
Debugs and Verification 151
Solution 152
IGRP Routes Not in the Routing Table—Cause: Access List Blocking IGRP
Broadcast 153
Debugs and Verification 154
Solution 155
 xiii

IGRP Routes Not in the Routing Table—Cause: Discontiguous Network 155

Debugs and Verification 156
Solution 157
IGRP Routes Not in the Routing Table—Cause: Invalid Source 159
Debugs and Verification 160
Solution 160
IGRP Routes Not in the Routing Table—Cause: Layer 2 Problem (Switch, Frame
Relay, Other Layer 2 Media) 161
Debugs and Verification 162
Solution 162
IGRP Routes Not in the Routing Table—Cause: Sender’s AS Mismatch 163
Debugs and Verification 164
Solution 165
Problem: IGRP Is Not Installing All Possible Equal-Cost Paths—Cause: maximum-
paths Restricts IGRP to a Maximum of Four Paths by Default 166
Debugs and Verification 167
Solution 168
Troubleshooting IGRP Routes Advertisement 168
Problem: Sender Is Not Advertising IGRP Routes 169
Sender Is Not Advertising IGRP Routes—Cause: Missing or Incorrect network
Statement 169
Debugs and Verification 170
Solution 170
Sender Is Not Advertising IGRP Routes—Cause: Outgoing Interface Is
Down 171
Debugs and Verification 172
Solution 172
Sender Is Not Advertising IGRP Routes—Cause: distribute-list out Is Blocking the
Route 173
Debugs and Verification 174
Solution 174
Sender Is Not Advertising IGRP Routes—Cause: Advertised Network Interface Is
Down 175
Debugs and Verification 175
Solution 176
Sender Is Not Advertising IGRP Routes—Cause: Outgoing Interface Is Defined as
Passive 176
Debugs and Verification 177
Solution 178
Sender Is Not Advertising IGRP Routes—Cause: Broken Broadcast Capability
(Encapsulation Failure in Layer 2) 178
Debugs and Verification 179
Solution 180
xiv

Sender Is Not Advertising IGRP Routes—Cause: Misconfigured neighbor

Statement 180
Debugs and Verification 181
Solution 181
Sender Is Not Advertising IGRP Routes—Cause: Advertised Subnet Is
VLSM 182
Debugs and Verification 183
Solution 183
Sender Is Not Advertising IGRP Routes—Cause: Split Horizon Is Enabled 184
Debugs and Verification 186
Solution 187
Problem: Candidate Default Is Not Being Advertised—Cause: ip default-network
Command Is Missing 188
Debugs and Verification 189
Solution 190
Troubleshooting IGRP Redistribution Problems 191
Problem: Redistributed Routes Are Not Getting Installed in the Routing Table—Cause:
Metric Is Not Defined During Redistribution into IGRP 191
Debugs and Verification 192
Solution 193
Troubleshooting Dial-on-Demand Routing (DDR) Issues in IGRP 194
Problem: IGRP Broadcast Is Keeping the ISDN Link Up—Cause: IGRP Broadcasts
Have Not Been Denied in the Interesting Traffic Definition 194
Debugs and Verification 195
Solution 196
Problem: IGRP Updates Are Not Going Across the Dialer Interface—Cause: Missing
Broadcast Keyword in a dialer map Statement 197
Debugs and Verification 197
Solution 198
Troubleshooting Route Flapping Problem in IGRP 198
Problem: IGRP Routes Are Flapping—Cause: Packet Drops on Sender’s or Receiver’s
Interface 199
Debugs and Verification 200
Solution 201
Troubleshooting Variance Problem 201
Problem: IGRP Not Using Unequal-Cost Path for Load Balancing—Cause: variance
Command Is Missing or Misconfigured 202
Debugs and Verification 203
Solution 204
 xv

Chapter 6 Understanding Enhanced Interior Gateway Routing Protocol (EIGRP) 207

Metrics 208
EIGRP Neighbor Relationships 209
The Diffusing Update Algorithm 211
DUAL Finite-State Machine 213
EIGRP Reliable Transport Protocol 214
EIGRP Packet Format 215
EIGRP Behavior 218
EIGRP Summarization 219
EIGRP Query Process 220
Default Routes and EIGRP 221
Unequal-Cost Load Balancing in EIGRP 221
Summary 223
Review Questions 224
Chapter 7 Troubleshooting EIGRP 227
Troubleshooting EIGRP Neighbor Relationships 227
Consulting the EIGRP Log for Neighbor Changes 228
EIGRP Neighbor Problem—Cause: Unidirectional Link 230
EIGRP Neighbor Problem—Cause: Uncommon Subnet 233
Misconfiguration of the IP Address on the Interfaces 234
Primary and Secondary IP Addresses of the Neighboring Interface Don’t
Match 234
Switch or Hub Between EIGRP Neighbor Connection Is Misconfigured or Is
Leaking Multicast Packets to Other Ports 235
EIGRP Neighbor Problem—Cause: Mismatched Masks 235
EIGRP Neighbor Problem—Cause: Mismatched K Values 237
EIGRP Neighbor Problem—Cause: Mismatched AS Number 239
EIGRP Neighbor Problem—Cause: Stuck in Active 240
Reviewing the EIGRP DUAL Process 240
Determining Active/Stuck in Active Routes with show ip eigrp topology
active 242
Methodology for Troubleshooting the Stuck in Active Problem 244
Troubleshooting EIGRP Route Advertisement 250
EIGRP Is Not Advertising Routes to Neighbors When the Network Administrators
Think That It Should 251
EIGRP Is Not Advertising Routes to Its Neighbors—Cause: Distribute
List 251
xvi

EIGRP Is Not Advertising Routes to Its Neighbors—Cause: Discontiguous

Networks 252
EIGRP Is Not Advertising Routes to Neighbors—Cause: Split-Horizon
Issues 253
EIGRP Is Advertising Routes to Neighbors When the Network Administrators
Think That It Shouldn’t 257
EIGRP Is Advertising Routes with Unexpected Metric 259
Troubleshooting EIGRP Route Installation 264
EIGRP Is Not Installing Routes—Cause: Auto or Manual Summarization 265
EIGRP Is Not Installing Routes—Cause: Higher Administrative Distance 267
EIGRP Is Not Installing Routes—Cause: Duplicate Router IDs 268
Troubleshooting EIGRP Route Flapping 271
Troubleshooting EIGRP Route Summarization 276
EIGRP Summarization Route Problem—Cause: Subnetworks of Summary Route
Don’t Exist in Routing Table 276
EIGRP Summarization Route Problem—Cause: Too Much Summarization 278
Troubleshooting EIGRP Redistribution Problems 280
Troubleshooting EIGRP Dial Backup Problem 286
EIGRP Error Messages 291
Summary 292
Chapter 8 Understanding Open Shortest Path First (OSPF) 295
OSPF Packet Details 295
Hello Packets 297
Database Description Packets 299
Link-State Request Packets 300
Link-State Update Packets 301
Link-State Acknowledgment Packet 301
OSPF LSA Details 302
Router LSA 304
Router LSA Example 305
Network LSA 307
Network LSA Example 308
Summary LSA 309
Summary LSA Example 310
External LSA 313
External LSA Example 314
OSPF Areas 315
Normal Areas 319
 xvii

Stub Areas 319

Totally Stubby Areas 321
Not-So-Stubby Areas 321
Type 7 LSAs 322
NSSA LSA Example 322
NSSA Configuration Example 324
Totally Not-So-Stubby Areas 324
Filtering in NSSA 325
Default Routes in NSSA 326
OSPF Media Types 327
Multiaccess Media 327
Point-to-Point Media 328
Nonbroadcast Multiaccess Media 329
Broadcast Model 329
Point-to-Point Model 330
Point-to-Multipoint Model 331
Demand Circuits 331
OSPF Media Type Summary 334
OSPF Adjacencies 334
OSPF Down State 335
OSPF Attempt State 336
OSPF Init State 336
OSPF 2-Way State 336
OSPF Exstart State 336
OSPF Exchange State 337
OSPF Loading State 338
OSPF Full State 338
Summary 338
Review Questions 339
Chapter 9 Troubleshooting OSPF 341
Flowcharts to Solve Common OSPF Problems 342
Troubleshooting OSPF Neighbor Relationships 351
Problem: OSPF Neighbor List Is Empty 351
OSPF Neighbor List Is Empty—Cause: OSPF Not Enabled on the Interface 352
Debugs and Verification 353
Solution 354
OSPF Neighbor List Is Empty—Cause: Layer 1/2 Is Down 354
Debugs and Verification 355
Solution 355
xviii

OSPF Neighbor List Is Empty—Cause: Interface Is Defined as Passive Under

OSPF 356
Debugs and Verification 357
Solution 358
OSPF Neighbor List Is Empty—Cause: Access List Blocking OSPF Hellos on Both
Sides 358
Debugs and Verification 359
Solution 360
OSPF Neighbor List Is Empty—Cause: Mismatched Subnet Number/Mask over a
Broadcast Link 361
Debugs and Verification 361
Solution 362
OSPF Neighbor List Is Empty—Cause: Mismatched Hello/Dead Intervals 362
Debugs and Verification 363
Solution 364
OSPF Neighbor List Is Empty—Cause: Mismatched Authentication Type 364
Debugs and Verification 365
Solution 366
OSPF Neighbor List Is Empty—Cause: Mismatched Authentication Key 366
Debugs and Verification 367
Solution 368
OSPF Neighbor List Is Empty—Cause: Mismatched Area ID 368
Debugs and Verification 368
Solution 369
OSPF Neighbor List Is Empty—Cause: Mismatched Stub/Transit/NSSA Area
Options 370
Debugs and Verification 371
Solution 371
OSPF Neighbor List Is Empty—Cause: OSPF Adjacency Over Secondary IP
Address 372
Debugs and Verification 373
Solution 374
OSPF Neighbor List Is Empty—Cause: OSPF Adjacency over Asynchronous
Interface 375
Debugs and Verification 376
Solution 377
OSPF Neighbor List Is Empty—Cause: No Network Type or Neighbor Defined
over NBMA 377
Debugs and Verification 378
Solution 379
OSPF Neighbor List Is Empty—Cause: Frame Relay/Dialer Interface Missing the
broadcast Keyword on Both Sides 380
Debugs and Verification 381
Solution 382
Problem: OSPF Neighbor Stuck in ATTEMPT 383
 xix

OSPF Neighbor Stuck in ATTEMPT—Cause: Misconfigured neighbor

Statement 384
Debugs and Verification 384
Solution 385
OSPF Neighbor Stuck in ATTEMPT—Cause: Unicast Connectivity Is Broken on
NBMA 385
Debugs and Verification 386
Solution 386
Problem: OSPF Neighbor Stuck in INIT 387
OSPF Neighbor Stuck in INIT—Cause: Access List on One Side Is Blocking OSPF
Hellos 387
Debugs and Verification 388
Solution 389
OSPF Neighbor Stuck in INIT—Cause: Multicast Capabilities Are Broken on One
Side (6500 Switch Problem) 389
Debugs and Verification 390
Solution 390
OSPF Neighbor Stuck in INIT—Cause: Cause: Authentication Is Enabled Only on
One Side 391
Debugs and Verification 391
Solution 392
OSPF Neighbor Stuck in INIT—Cause: The frame-relay map/dialer-map Statement
on One Side Is Missing the broadcast Keyword 393
Debugs and Verification 394
Solution 395
OSPF Neighbor Stuck in INIT—Cause: Hellos Are Getting Lost on One Side at
Layer 2 396
Debugs and Verification 396
Solution 397
Problem: OSPF Neighbor Stuck in 2-WAY—Cause: Priority 0 Is Configured on All
Routers 398
Debugs and Verification 400
Solution 400
Problem: OSPF Neighbor Stuck in EXSTART/EXCHANGE 401
OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Mismatched Interface
MTU 401
Debugs and Verification 402
Solutions 403
OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Duplicate Router IDs
on Neighbors 404
Debugs and Verification 405
Solution 406
xx

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Can’t Ping Across

with More Than Certain MTU Size 406
Debugs and Verification 408
Solution 408
OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Unicast Connectivity
Is Broken 409
Debugs and Verification 410
Solutions 410
OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Network Type Is
Point-to-Point Between PRI and BRI/Dialer 414
Debugs and Verification 415
Solution 416
Problem: OSPF Neighbor Stuck in LOADING 417
OSPF Neighbor Stuck in LOADING—Cause: Mismatched MTU Size 418
Debugs and Verification 418
Solution 419
OSPF Neighbor Stuck in LOADING—Cause: Link-State Request Packet Is
Corrupted 420
Debugs and Verification 421
Solution 422
Troubleshooting OSPF Route Advertisement 422
Problem: OSPF Neighbor Is Not Advertising Routes 422
OSPF Neighbor Is Not Advertising Routes—Cause: OSPF Not Enabled on the
Interface That Is Supposed to Be Advertised 423
Debugs and Verification 424
Solution 425
OSPF Neighbor Is Not Advertising Routes—Cause: Advertising Interface Is
Down 426
Debugs and Verification 427
Solution 428
OSPF Neighbor Is Not Advertising Routes—Cause: Secondary Interface Is in a
Different Area Than the Primary Interface 429
Debugs and Verification 430
Solution 431
Problem: OSPF Neighbor (ABR) Not Advertising the Summary Route 432
OSPF Neighbor (ABR) Not Advertising the Summary Route—Cause: Area Is
Configured as Totally Stubby Area 432
Debugs and Verification 433
Solution 434
OSPF Neighbor (ABR) Not Advertising the Summary Route—Cause: ABR Is Not
Connected to Area 0 434
Debugs and Verification 435
Solution 436
 xxi

OSPF Neighbor (ABR) Not Advertising the Summary Route—Cause:

Discontiguous Area 0 437
Debugs and Verification 438
Solution 439
Problem: OSPF Neighbor Is Not Advertising External Routes 441
OSPF Neighbor Is Not Advertising External Routes—Cause: Area Is Configured as
a Stub Area or NSSA 441
Debugs and Verification 442
Solution 442
OSPF Neighbor Is Not Advertising External Routes—Cause: NSSA ABR Not
Translating Type 7 LSAs into Type 5 LSAs 444
Debugs and Verification 445
Solution 449
Problem: OSPF Neighbor Not Advertising Default Routes 450
OSPF Neighbor Not Advertising Default Routes—Cause: Missing default-
information originate Commands 451
Debugs and Verification 452
Solution 454
OSPF Neighbor Not Advertising Default Routes—Cause: Default Route Missing
from the Neighbor’s Routing Table 455
Debugs and Verification 455
Solution 456
OSPF Neighbor Not Advertising Default Routes—Cause: Neighbor Trying to
Inject a Default into a Stub Area 458
Debugs and Verification 459
Solution 459
OSPF Neighbor Not Advertising Default Routes—Cause: NSSA ABR/ASBR Not
Originating Type 7 Default 460
Debugs and Verification 462
Solution 462
Troubleshooting OSPF Route Installation 463
Problem: OSPF Not Installing Any Routes in the Routing Table 463
OSPF Not Installing Any Routes in the Routing Table—Cause: Network Type
Mismatch 464
Debugs and Verification 464
Solution 466
OSPF Not Installing Any Routes in the Routing Table—Cause: IP Addresses Are
Flipped in Dual Serial-Connected Routers 467
Debugs and Verification 468
Solution 469
xxii

OSPF Not Installing Any Routes in the Routing Table—Cause: One Side Is a
Numbered and the Other Side Is an Unnumbered Point-to-Point Link 469
Debugs and Verification 471
Solution 472
OSPF Not Installing Any Routes in the Routing Table—Cause: Distribute List Is
Blocking the Route Installation 473
Debugs and Verification 474
Solution 474
OSPF Not Installing Any Routes in the Routing Table—Cause: Broken PVC in a
Fully Meshed Frame Relay Network with Broadcast Network Type 475
Debugs and Verification 476
Solution 478
Problem: OSPF Not Installing External Routes in the Routing Table 479
OSPF Not Installing External Routes in the Routing Table—Cause: Forwarding
Address Is Not Known Through the Intra-Area or Interarea Route 480
Debugs and Verification 481
Solution 483
OSPF Not Installing External Routes in the Routing Table—Cause: ABR Not
Generating Type 4 Summary LSA 484
Debugs and Verification 486
Solution 486
Troubleshooting Redistribution Problems in OSPF 488
Problem: OSPF Neighbor Is Not Advertising External Routes 488
OSPF Neighbor Is Not Advertising External Routes—Cause: Subnets Keyword
Missing from the ASBR Configuration 489
Debugs and Verification 490
Solution 490
OSPF Neighbor Is Not Advertising External Routes—Cause: distribute-list out Is
Blocking the Routes 491
Debugs and Verification 492
Solution 493
Troubleshooting Route Summarization in OSPF 494
Problem: Router Is Not Summarizing Interarea Routes—Cause: area range Command
Is Not Configured on ABR 495
Debugs and Verification 496
Solution 496
Problem: Router Is Not Summarizing External Routes—Cause: summary-address
Command Is Not Configured on ASBR 497
Debugs and Verification 498
Solution 499
 xxiii

Troubleshooting CPUHOG Problems 499

Problem: CPUHOG Messages During Adjacency Formation—Cause: Router Is Not
Running Packet-Pacing Code 500
Debugs and Verification 501
Solution 501
Problem: CPUHOG Messages During LSA Refresh Period—Cause: Router Is Not
Running LSA Group-Pacing Code 501
Debugs and Verification 502
Solution 502
Troubleshooting Dial-on-Demand Routing Issues in OSPF 503
Problem: OSPF Hellos Are Bringing Up the Link—Cause: OSPF Hellos Are Permitted
as Interesting Traffic 503
Debugs and Verification 504
Solution 505
Problem: Demand Circuit Keeps Bringing Up the Link 505
Demand Circuit Keeps Bringing Up the Link—Cause: A Link Flap in the
Network 506
Debugs and Verification 507
Solution 508
Demand Circuit Keeps Bringing Up the Link—Cause: Network Type Defined as
Broadcast 508
Debugs and Verification 509
Solution 510
Demand Circuit Keeps Bringing Up the Link—Cause: PPP Host Routes Are
Getting Redistributed into the OSPF Database 511
Debugs and Verification 512
Solution 513
Demand Circuit Keeps Bringing Up the Link—Cause: One of the Routers Is Not
Demand Circuit–Capable 514
Debugs and Verification 515
Solution 516
Troubleshooting SPF Calculation and Route Flapping 517
SPF Running Constantly—Cause: Interface Flap Within the Network 518
Debugs and Verification 519
Solution 520
SPF Running Constantly—Cause: Neighbor Flap Within the Network 520
Debugs and Verification 522
Solution 523
xxiv

SPF Running Constantly—Cause: Duplicate Router ID 524

Debugs and Verification 525
Solution 527
Common OSPF Error Messages 528
“Unknown routing protocol” Error Message 528
OSPF: “Could not allocate router id” Error Message 529
“%OSPF-4-BADLSATYPE: Invalid lsa: Bad LSA type” Type 6 Error Message 529
“OSPF-4-ERRRCV” Error Message 529
Mismatched Area ID 529
Bad Checksum 530
OSPF Not Enabled on the Receiving Interface 531
Chapter 10 Understanding Intermediate System-to-Intermediate System (IS-IS) 533
IS-IS Protocol Overview 533
IS-IS Routing Protocol 535
IS-IS Protocol Concepts 535
IS-IS Nodes, Links, and Areas 536
Adjacencies 537
ES-IS Adjacencies 538
IS-IS Adjacencies 538
Hierarchical Routing 541
IS-IS Packets 542
Generic IS-IS Packet Format 543
IS-IS Metrics 545
IS-IS Authentication 548
ISO CLNP Addressing 548
NSAP Format 549
NSAP Examples 550
Guidelines for Defining NSAP Addresses 551
IS-IS Link-State Database 552
Overview of the IS-IS Link-State Database 552
Flooding and Database Synchronization 555
Shortest Path First (SPF) Algorithm and IS-IS Route Calculation 558
Configuring IS-IS for IP Routing 559
Configuring IS-IS on Point-to-Point Serial Links 559
show clns protocol Command 562
show clns neighbors detail Command 563
show clns interface Command 564
show isis topology Command 565
show isis database Command 565
 xxv

ATM Configuration Examples 566

IP Default Route Advertisement 569
Route Redistribution 570
IP Route Summarization 573
Summary 574
Additional IS-IS Packet Information 575
IS-IS Packet Fields (Alphabetical Order) 576
Hello Packets 577
Link-State Packets 578
Sequence Number Packets 579
Review Questions 581
Further Reading 582
Chapter 11 Troubleshooting IS-IS 585
Troubleshooting IS-IS Adjacency Problems 587
Problem 1: Some or All of the Adjacencies Are Not Coming Up 590
Step 1: Checking for Link Failures 591
Step 2: Verifying Basic Configuration 593
Step 3: Checking for Mismatched Level 1 and Level 2 Interfaces 593
Step 4: Checking for Area Misconfiguration 594
Step 5: Checking for Misconfigured IP Subnets 595
Step 6: Check for Duplicate System IDs 596
Problem 2: Adjacency in INIT State 596
Mismatched MTU 600
IS-IS Hello Padding 602
Misconfigured Authentication 604
Problem 3: Only ES-IS Adjacency Instead of IS-IS Adjacency Formed 605
Troubleshooting IS-IS Routing Update Problems 606
Route Advertisement Problems 607
Local Routes Not Being Advertised to Remote 609
Solution Summary 611
Route Redistribution and Level 2–to–Level 1 Route-Leaking Problems 611
Route-Flapping Problem 612
Solution Summary 616
IS-IS Errors 616
CLNS ping and traceroute 617
Case Study: ISDN Configuration Problem 619
IS-IS Troubleshooting Command Summary 622
Summary 623
xxvi

Chapter 12 Understanding Protocol Independent Multicast (PIM) 625

Fundamentals of IGMP Version 1, IGMP Version 2, and Reverse Path
Forwarding 626
IGMP Version 1 626
IGMP Version 2 627
Multicast Forwarding (Reverse Path Forwarding) 628
PIM Dense Mode 630
PIM Sparse Mode 632
IGMP and PIM Packet Format 635
IGMP Packet Format 635
PIM Packet/Message Formats 636
Summary 640
Review Questions 641
Chapter 13 Troubleshooting PIM 643
Troubleshooting IGMP Joins 643
Solution to IGMP Join Problem 645
Troubleshooting PIM Dense Mode 646
Solution to PIM Dense Mode Problem 650
Troubleshooting PIM Sparse Mode 651
Solution to PIM Sparse Mode Problem 656
Summary 656
Chapter 14 Understanding Border Gateway Protocol Version 4 (BGP-4) 659
BGP-4 Protocol Specification and Functionality 662
Neighbor Relationships 663
External BGP Neighbor Relationships 665
Internal BGP Neighbor Relationships 667
Advertising Routes 668
Synchronization Rule 671
Receiving Routes 672
Policy Control 672
Policy Control Using BGP Attributes 674
LOCAL_PREF Attribute 675
MULTI_EXIT_DISC (MED) Attribute 677
AS_PATH Attribute 682
NEXT_HOP Attribute 685
ORIGIN Attribute 685
 xxvii

WEIGHT: Cisco Systems, Inc. Proprietary Attribute 686

Reading BGP Attributes from Cisco IOS Software Output 688
Use of Route Maps in Policy Control 690
Using the match ip address Command in a Route Map 691
Using the match community Command in a Route Map 691
Using the match as-path Command in a Route Map 692
Using the set as-path prepend Command in a Route Map 693
Using the set community Command in a Route Map 693
Using the set local-preference Command in a Route Map 694
Using the set metric Command in a Route Map 694
Using the set weight Command in a Route Map 694
Policy Control Using filter-list, distribute-list, prefix-list, Communities, and
Outbound Route Filtering (ORF) 694
Use of Filter Lists in Policy Control 695
Use of Distribute Lists in Policy Control 695
Use of Prefix Lists in Policy Control 696
Use of Communities in Policy Control 697
Use of Outbound Route Filtering in Policy Control 700
Route Dampening 702
Scaling IBGP in Large Networks—Route Reflectors and Confederations 706
Route Reflection 707
AS Confederations 711
Best-Path Calculation 713
Summary 716
Review Questions 717
Chapter 15 Troubleshooting BGP 719
Flowcharts to Solve Common BGP Problems 720
show and debug Commands for BGP-Related Troubleshooting 726
show ip bgp prefix Command 726
show ip bgp summary Command 726
show ip bgp neighbor [address] Command 726
show ip bgp neighbors [address] [advertised-routes] Command 726
show ip bgp neighbors [routes] Command 727
debug ip bgp update [access-list] Command 727
Standard Access List Usage 727
Extended Access List Usage 727
debug ip bgp neighbor-ip-address updates [access-list] Command 727
Troubleshooting BGP Neighbor Relationships 727
Problem: Directly Connected External BGP Neighbors Not Initializing 728
xxviii

Directly Connected External BGP Neighbors Not Coming Up—Cause: Layer 2 Is

Down, Preventing Communication with Directly Connected BGP Neighbor 729
Debugs and Verification 729
Solution 730
Directly Connected External BGP Neighbors Not Coming Up—Cause: Incorrect
Neighbor IP Address in BGP Configuration 731
Debugs and Verification 731
Solution 732
Problem: Nondirectly Connected External BGP Neighbors Not Coming Up 732
Nondirectly Connected External BGP Neighbors Not Coming Up—Cause: Route to
the Nondirectly Connected Peer Address Is Missing from the Routing Table 733
Debugs and Verification 734
Solution 736
Nondirectly Connected External BGP Neighbors Not Coming Up—Cause: ebgp-
multihop Command Is Missing in BGP Configuration 736
Debugs and Verification 737
Solution 738
Nondirectly Connected External BGP Neighbors Not Coming Up—Cause: update-
source interface Command Is Missing 738
Debugs and Verification 739
Solution 741
Problem: Internal BGP Neighbors Not Coming Up 741
Problem: BGP Neighbors (External and Internal) Not Coming Up—Cause: Interface
Access List Blocking BGP Packets 741
Debugs and Verification 742
Solution 742
Troubleshooting BGP Route Advertisement/Origination and Receiving 743
Problem: BGP Route Not Getting Originated 743
BGP Route Not Getting Originated—Cause: IP Routing Table Does Not Have a
Matching Route 744
Debugs and Verification 744
Solution 746
BGP Route Not Getting Originated—Cause: Configuration Error 746
Debugs and Verification 746
Solution 749
BGP Route Not Getting Originated—Cause: BGP Is Autosummarizing to Classful/
Network Boundary 749
Debugs and Verification 750
Solution 751
 xxix

Problem in Propagating/Originating BGP Route to IBGP/EBGP Neighbors—Cause:

Misconfigured Filters 752
Debugs and Verification 753
Solution 754
Problem in Propagating BGP Route to IBGP Neighbor but Not to EBGP Neighbor—
Cause: BGP Route Was from Another IBGP Speaker 754
Debugs and Verification 755
Solution 757
IBGP Full Mesh 757
Designing a Route-Reflector Model 757
Designing a Confederation Model 758
Problem in Propagating IBGP Route to IBGP/EBGP Neighbor—Cause: IBGP Route
Was Not Synchronized 761
Debugs and Verification 762
Solution 762
Troubleshooting BGP Route Not Installing in Routing Table 762
Problem: IBGP-Learned Route Not Getting Installed in IP Routing Table 763
IBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: IBGP
Routes Are Not Synchronized 763
Debugs and Verification 764
Solution 765
IBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: IBGP Next
Hop Not Reachable 766
Debugs and Verification 768
Solution 769
Announce the EBGP Next Hop Through an IGP Using a Static Route or
Redistribution 769
Change the Next Hop to an Internal Peering Address 770
Problem: EBGP-Learned Route Not Getting Installed in IP Routing Table 771
EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP
Routes Are Dampened 771
Debugs and Verification 772
Solution 774
EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP
Next Hop Not Reachable in Case of Multihop EBGP 774
Debugs and Verification 775
Solution 777
EBGP-Learned Route Not Getting Installed in the Routing Table—Cause:
Multiexit Discriminator (MED) Value Is Infinite 777
Debugs and Verification 778
xxx

Troubleshooting BGP Route-Reflection Issues 778

Problem: Configuration Mistakes—Cause: Failed to Configure IBGP Neighbor as a
Route-Reflector Client 779
Debugs and Verification 779
Solution 780
Problem: Route-Reflector Client Stores an Extra BGP Update—Cause: Client-to-Client
Reflection 780
Debugs and Verification 782
Solution 782
Problem: Convergence Time Improvement for RR and Clients—Cause: Use of Peer
Groups 783
Debugs and Verification 784
Solution 785
Problem: Loss of Redundancy Between Route Reflectors and Route-Reflector Client
—Cause: Cluster List Check in RR Drops Redundant Route from Other RR 785
Debugs and Verification 787
Solution 788
Troubleshooting Outbound IP Traffic Flow Issues Because of BGP Policies 790
Problem: Multiple Exit Points Exist but Traffic Goes Out Through One or Few Exit
Routers—Cause: BGP Policy Definition Causes Traffic to Exit from One Place 791
Solution 793
Problem: Traffic Takes a Different Interface from What Shows in Routing Table—
Cause: Next Hop of the Route Is Reachable Through Another Path 795
Debugs and Verification 797
Solution 798
Problem: Multiple BGP Connections to the Same BGP Neighbor AS, but Traffic Goes
Out Through Only One Connection—Cause: BGP Neighbor Is Influencing Outbound
Traffic by Sending MED or Prepended AS_PATH 798
Solution 800
Request AS 110 to Send the Proper MED for Each Prefix 800
Don’t Accept MED from AS 110 801
Manually Change LOCAL_PREFERENCE for P1, P2, and P3 at All the Exit
Points X, Y, and Z 801
Problem: Asymmetrical Routing Occurs and Causes a Problem Especially When NAT
and Time-Sensitive Applications Are Used—Cause: Outbound and Inbound
Advertisement 802
Debugs and Verification 803
Solution 804
Troubleshooting Load-Balancing Scenarios in Small BGP Networks 806
 xxxi

Problem: Load Balancing and Managing Outbound Traffic from a Single Router When
Dualhomed to Same ISP—Cause: BGP Installs Only One Best Path in the Routing
Table 806
Debugs Verification 807
Solution 808
Problem: Load Balancing and Managing Outbound Traffic in an IBGP Network—
Cause: By Default, IBGP in Cisco IOS Software Allows Only a Single Path to Get
Installed in the Routing Table Even Though Multiple Equal BGP Paths Exist 809
Debugs and Verification 810
Solution 811
Troubleshooting Inbound IP Traffic Flow Issues Because of BGP Policies 812
Problem: Multiple Connections Exist to an AS, but All the Traffic Comes in Through
One BGP Neighbor, X, in the same AS—Cause: Either BGP Neighbor at X Has a BGP
Policy Configured to Make Itself Preferred over the Other Peering Points, or the
Networks Are Advertised to Attract Traffic from Only X 813
Debugs and Verification 815
Case 1 815
Case 2 816
Solution 818
Problem: Multiple Connections Exist to Several BGP Neighbors, but Most of the
Traffic from Internet to 100.100.100.0/24 Always Comes in Through One BGP
Neighbor from AS 110—Cause: Route Advertisements for 100.100.100.0/24 in
AS 109 Attract Internet Traffic Through That BGP Neighbor in AS 110 819
Solution 819
Troubleshooting BGP Best-Path Calculation Issues 820
Problem: Path with Lowest RID Is Not Chosen as Best 821
Debugs and Verification 821
Solution 823
Problem: Lowest MED Not Selected as Best Path 824
Debugs and Verification 826
Solution 826
Troubleshooting BGP Filtering 828
Problem: Standard Access List Fails to Capture Subnets 828
Debugs and Verification 829
Solution 830
Problem: Extended Access Lists Fails to Capture the Correct Masked Route 831
Debugs and Verification 832
Solution 833
Extended Access List Solution 833
xxxii

Problem: AS_PATH Filtering Using Regular Expressions 835

Summary 835
Appendix Answers to Review Questions 839
Index 849
 xxxiii

Preface
Sitting in my office at Cisco on the third floor of building K, I read an e-mail from Kathy Trace from Cisco Press
asking if I was interested in writing a book. She had read my technical tips that I had written for Cisco Connection
Online and said that she wanted me as an author for Cisco Press. I was very enthusiastic about it and said to myself,
“Yeah! It’s a great idea! Let’s write a book!” But on what subject?
One of the topics that I had in mind was OSPF. Johnson used to sit right in front of my office at that time. I asked
him, “Hey, Johnson! You want to write a book with me?” He screamed, “A book!” I said, “Yeah, a book! What do
you think?” He thought for a minute and said, “Well, what is left for us to write a book on? Cisco Press authors have
written books on almost every routing topic. . . . But there is one subject that has not been covered in one
single book—troubleshooting IP routing protocols.”
Apparently, Johnson got the idea to write a troubleshooting book from his wife. Whenever Johnson’s wife calls him
at work, he has to put her on hold because he is busy troubleshooting a customer’s problem. His wife, whose name
is also Cisco, then gave him the idea of writing a troubleshooting book so that customers would have a trouble-
shooting guide on routing protocols that they can refer to so that they can successfully solve their problems before
opening a case.
The idea was indeed great. No books had been written on this particular subject before. I then called Zaheer, who
was attending IETF 46 in Washington, D.C., and told him about this; he also agreed that the idea was a good one.
So now we had a team of three TAC engineers who had spent the last three to four years in TAC dealing with
routing problems—and each one of us was an expert in one or two protocols. Our manager, Raja Sundaram, used
to say, “I want you to pick up a protocol and become an expert in it.” My area of expertise was OSPF, Johnson
was a guru of EIGRP and multicasting, and Zaheer shone with his BGP knowledge. Very soon, we realized that
we were missing one important protocol, IS-IS. Our exposure with IS-IS was not at a level that we could write a
whole chapter on troubleshooting IS-IS, so Zaheer suggested Abe Martey for this job. Abe was already engaged
in writing a book on IS-IS with Cisco Press, but after seeing our enthusiasm about this book, he agreed to
become a member of our author team.
When we started working on these chapters, we realized that we were working on something that a routing network
administrator had always dreamed of—a troubleshooting book that contains solutions for all the IP routing protocol
problems. The data that we collected for this book came from the actual problems we have seen in customer net-
works in our combined 20 years of experience in troubleshooting IP networks. We wanted to make it a one-stop
shop for troubleshooting guidance and reference. So, we provided the “understanding protocols” chapters along
with troubleshooting to help you, the reader, go back to a specific protocol and refresh your memory. This book is
also an excellent resource for preparation for the CCIE certification. This book should teach you how to tackle any
IP routing problem that pops up in your network. All possible cases might not be discussed, but general guidelines
and techniques teach a logical approach for solving typical problems that you might face.

Syed Faraz Shamim

xxxiv

Introduction
As the Internet continues to grow exponentially, the need for network engineers to build, maintain, and
troubleshoot the growing number of component networks also has increased significantly. Because net-
work troubleshooting is a practical skill that requires on-the-job experience, it has become critical that the
learning curve necessary to gain expertise in internetworking technologies be reduced to quickly
fill the void of skilled network engineers needed to support the fast-growing Internet. IP routing is at
the core of Internet technology, and expedient troubleshooting of IP routing failures is key to reducing
network downtime. Reducing network downtime is crucial as the level of mission-critical applications
carried over the Internet increases. This book gives you the detailed knowledge to troubleshoot network
failures and maintain the integrity of their networks.
Troubleshooting IP Routing Protocols provides a unique approach to troubleshooting IP routing
protocols by focusing on step-by-step guidelines for solving a particular routing failure scenario. The
culmination of years of experience with Cisco’s TAC group, this book offers sound methodology and
solutions for resolving routing problems related to BGP, OSPF, IGRP, EIGRP, IS-IS, RIP, and PIM by
first providing an overview to routing and then concentrating on the troubleshooting steps that an
engineer would take in resolving various routing protocol issues that arise in a network. This book
offers you a full understanding of troubleshooting techniques and real-world examples to help you
hone the skills needed to successfully complete the CCIE exam, as well as perform the duties
expected of a CCIE-level candidate.

Who Should Read This Book?

This is an intermediate-level book that assumes that you have a general understanding of IP routing
technologies and other related protocols and technologies used in building IP networks.
The primary audience for this book consists of network administrators and network operation engineers
responsible for the high availability of their networks, or those who plan to become Cisco Certified
Internetwork Experts.

How This Book Is Organized

Although this book could be read cover to cover, it is designed to be flexible and to allow you to easily
move between chapters and sections of chapters to cover just the material that you need more work with.
• Chapter 1, “Understanding IP Routing”—This chapter provides an overview of IP routing
protocols with focus on the following topics:
—IP addressing concepts
—Static and dynamic routes
—Dynamic routing
—Routing protocol administrative distance
—Fast forwarding in routers
 xxxv

The remaining chapters alternate between chapters that provides coverage of key aspects of a specific
routing protocol and chapters devoted to practical, real-world troubleshooting methods for that routing
protocol. The list that follows provides more detailed information:
• Chapter 2, “Understanding Routing Information Protocol (RIP)”—This chapter focuses on the
key aspects of RIP needed to confidently troubleshoot RIP problems. Topics include the following:
—Metrics
—Timers
—Split horizon
—Split horizon with poison reverse
—RIP-1 packet format
—RIP behavior
—Why RIP doesn’t support discontiguous networks
—Why RIP doesn’t support variable-length subnet masking (VLSM)
—Default routes and RIP
—Protocol extension to RIP
—Compatibility issues
• Chapter 3, “Troubleshooting RIP”—This chapter provides a methodical approach to resolving
common RIP problems, which include the following:
—Troubleshooting RIP route installation
—Troubleshooting RIP route advertisement
—Troubleshooting routes summarization in RIP
—Troubleshooting RIP redistribution problems
—Troubleshooting dial-on-demand routing (DDR) issues in RIP
—Troubleshooting the route-flapping problem in RIP
• Chapter 4, “Understanding Interior Gateway Routing Protocol (IGRP)”—This chapter
focuses on the key aspects of IGRP needed to confidently troubleshoot IGRP problems. Topics
include the following:
—Metrics
—Timers
—Split horizon
—Split horizon and poison reverse
—IGRP packet format
—IGRP behavior
—Default route and IGRP
—Unequal-cost load balancing in IGRP
xxxvi

• Chapter 5, “Troubleshooting IGRP”—This chapter provides a methodical approach to

resolving common IGRP problems, which include the following:
—Troubleshooting IGRP route installation
—Troubleshooting IGRP route advertisement
—Troubleshooting IGRP redistribution problems
—Troubleshooting dial-on-demand routing (DDR) issues in IGRP
—Troubleshooting route flapping in IGRP
—Troubleshooting variance problem
• Chapter 6, “Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)”—This
chapter focuses on the key aspects of EIGRP needed to confidently troubleshoot EIGRP problems.
Topics include the following:
—Metrics
—EIGRP neighbor relationships
—The Diffusing Update Algorithm (DUAL)
—DUAL finite state machine
—EIGRP reliable transport protocol
—EIGRP packet format
—EIGRP behavior
—EIGRP summarization
—EIGRP query process
—Default route and EIGRP
—Unequal-cost load balancing in EIGRP
• Chapter 7, “Troubleshooting EIGRP”—This chapter provides a methodical approach to
resolving common EIGRP problems, which include the following:
—Troubleshooting EIGRP neighbor relationships
—Troubleshooting EIGRP route advertisement
—Troubleshooting EIGRP route installation
—Troubleshooting EIGRP route flapping
—Troubleshooting EIGRP route summarization
—Troubleshooting EIGRP route redistribution
—Troubleshooting EIGRP dial backup
—EIGRP error messages
 xxxvii

• Chapter 8, “Understanding Open Shortest Path First (OSPF)”—This chapter focuses

on the key aspects of OSPF needed to confidently troubleshoot OSPF problems. Topics
include the following:
—OSPF packet details
—OSPF LSA details
—OSPF areas
—OSPF media types
—OSPF adjacencies
• Chapter 9, “Troubleshooting OSPF”—This chapter provides a methodical approach to
resolving common OSPF problems, which include the following:
—Troubleshooting OSPF neighbor relationships
—Troubleshooting OSPF route advertisement
—Troubleshooting OSPF route installation
—Troubleshooting redistribution problems in OSPF
—Troubleshooting route summarization in OSPF
—Troubleshooting CPUHOG problems
—Troubleshooting dial-on-demand routing (DDR) issues in OSPF
—Troubleshooting SPF calculation and route flapping
—Common OSPF error messages
• Chapter 10, “Understanding Intermediate System-to-Intermediate System (IS-IS)”—This
chapter focuses on the key aspects of IS-IS needed to confidently troubleshoot IS-IS problems.
Topics include the following:
—IS-IS protocol overview
—IS-IS protocol concepts
—IS-IS link-state database
—Configuring IS-IS for IP routing
• Chapter 11, “Troubleshooting IS-IS”—This chapter provides a methodical approach to
resolving common IS-IS problems, which include the following:
—Troubleshooting IS-IS adjacency problems
—Troubleshooting IS-IS routing update problems
—IS-IS errors
—CLNS ping and traceroute
—Case study: ISDN configuration problem
xxxviii

• Chapter 12, “Understanding Protocol Independent Multicast (PIM)”—This chapter

focuses on the key aspects of PIM needed to confidently troubleshoot PIM problems. Topics
include the following:
— Fundamentals of IGMP Version 1, IGMP Version 2, and reverse path forwarding (RPF)
—PIM dense mode
—PIM sparse mode
—IGMP and PIM packet format
• Chapter 13, “Troubleshooting PIM”—This chapter provides a methodical approach to
resolving common PIM problems, which include the following:
—IGMP joins issues
—PIM dense mode issues
—PIM sparse mode issues
• Chapter 14, “Understanding Border Gateway Protocol Version 4 (BGP-4)”—This chapter
focuses on the key aspects of BGP needed to confidently troubleshoot BGP problems. Topics
include the following:
—BGP-4 protocol specification and functionality
—Neighbor relationships
—Advertising routes
—Synchronization
—Receiving routes
—Policy control
—Scaling IBGP networks (route reflectors and confederations)
—Best-path calculation
• Chapter 15, “Troubleshooting BGP”—This chapter provides a methodical approach to
resolving common BGP problems, which include the following:
—Troubleshooting BGP neighbor relationships
—Troubleshooting BGP route advertisement/origination and receiving
—Troubleshooting a BGP route not installing in a routing table
—Troubleshooting BGP when route reflectors are used
—Troubleshooting outbound traffic flow issues because of BGP policies
—Troubleshooting load-balancing scenarios in small BGP networks
—Troubleshooting inbound traffic flow issues because of BGP policies
—Troubleshooting BGP best-path calculation issues
—Troubleshooting BGP filtering
 xxxix

Icons Used in This Book

DSU/CSU

Router DSU/CSU Catalyst

Bridge Hub Switch Multilayer Switch ATM Switch

ISDN /Frame Relay Communication Access Server Sun

Gateway PC Workstation
Switch Server PC with
Software

Mac Terminal File Server Web CiscoWorks

Workstation Printer Laptop
Server

Front End Line: Ethernet Line: Serial

Cluster Controller Line: Circuit-Switched
IBM Processor
Mainframe

Token
Ring
Frame Relay Virtual Circuit Network Cloud
Token FDDI Ring
Ring

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:
• Vertical bars (|) separate alternative, mutually exclusive elements.
• Square brackets [ ] indicate optional elements.
• Braces { } indicate a required choice.
• Braces within brackets [{ }] indicate a required choice within an optional element.
• Boldface indicates commands and keywords that are entered literally as shown. In actual con-
figuration examples and output (not general command syntax), boldface indicates commands
that are manually input by the user (such as a show command).
• Italics indicate arguments for which you supply actual values.
The primary objective of this book is to provide elaborate guidance for troubleshooting
Internet Protocol (IP) routing problems on Cisco routers. In this regard, the subsequent text
covers well-known routing protocols such as the following:
• Open Shortest Path First Protocol (OSPF)
• Integrated Intermediate System-to-Intermediate System Protocol (IS-IS)
• Border Gateway Protocol (BGP)
• Protocol Independent Multicast (PIM) for multicast routing
 CHAPTER
1

Understanding IP Routing
This chapter presents an introduction to IP routing and provides insights to related con-
cepts, such as IP addressing and various classifications of IP routing protocols. The chapter
also provides a high-level overview of implementation and configuration concepts, such as
route filtering and redistribution.
The Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols is the
underlying technology for information exchange on the Internet. TCP/IP uses a layering
approach for computer communications similar to the Open System Interconnection (OSI)
reference model, but with fewer than seven layers. Figure 1-1 shows the OSI reference
model and the TCP/IP stack side by side. Related layers between the two stacks are
indicated in the figure.

Figure 1-1 OSI Reference Model and TCP/IP Stack

OSI Reference Model TCP/IP Conceptual Layers

7 Application

6 Presentation Application 6

5 Session 5

4 Transport Transport 4

3 Network Internet 3

2 DataLink Ethernet, 802.3,

Network 802.5, FDDI, and
Interface so on.
1 Physical

IP operates at the Internet layer of the TCP/IP suite, which corresponds to the network layer
of the OSI reference model. IP provides connectionless data-delivery services, which
involve transmission of information from one part of a network to another in units of data
known as packets or datagrams. The essence of the datagram delivery service model is that
a permanent pre-established end-to-end path is not required for data transfer between two
4 Chapter 1: Understanding IP Routing

points in a network. In a packet-based network, each router in the transmission path makes
independent local decisions regarding the optimal forwarding path toward the destination
for any transit packet. The decision-making is based on forwarding intelligence gathered
either dynamically by means of a routing protocol or manually programmed static routes.
Addressing is an important aspect of the data-forwarding process. For any directed com-
munication, there is a source and a destination. Addressing allows the target destination
to be specified by the source and allows the destination node to also identify the source.
Addressing is even more important in the datagram delivery mode of operation because, as
in IP forwarding, the data path for any transmission is not nailed through the intermediate
nodes between the source and destination.
As mentioned previously, within the IP datagram services infrastructure, information that
is to be transmitted from one device to another first is broken down into packets. Each
packet has an IP header, a transport layer (TCP or UDP) header, and a payload, which is a
piece of the original information. Each IP packet is self-contained and independently is
forwarded to the destination through the chain of intermediate devices that might be along
the path of transmission.
The routers in the network depend on a routing protocol or static configuration to forward the
datagrams in a stream to their intended destination. For any destination address, each node in
the data path worries about only the outgoing interface or link along a locally determined
optimal path to the destination (or as specified by a special forwarding policy). The IP for-
warding process frequently is described as a hop-by-hop destination-based forwarding
mechanism. This means that routers at each hop along the data path normally forward packets
based on the destination address. However, modern routers also can use policy-based criteria,
such as the source address in a packet to direct the forwarding.
At the destination, packets belonging to the same stream are reassembled into the original
information. IP addressing is discussed in the next section, “IP Addressing Concepts.”
This process of forwarding a packet from one node to the other in a connectionless network
based on the Layer 3 address (IP address, in this case) also is referred to as routing. Routers
are specialized network devices with acquired routing intelligence.
So how do routers really decide where and how to forward packets traversing the inter-
network? Well, this is done in a couple of ways. As alluded to previously, routers can be
manually preprogrammed with predetermined path information known as static routes, or
they can run applications that facilitate the learning and sharing of routing information
automatically. Obtaining and propagating routing information by the latter method is re-
ferred to as dynamic routing.
 IP Addressing Concepts 5

IP Addressing Concepts
IP addressing is central to the operation of the IP protocol. The TCP/IP stack shown in
Figure 1-1 features a network interface to the underlying physical and data-link layers, which
allow the IP protocol to be media independent. Media independence is probably one of the
critical advantages of the IP protocol that has promoted its wide acceptance and ubiquity.
IP uses a native addressing scheme, in line with its media-independent architecture, that has
no bearing on the underlying local-area network (LAN) or wide-area network (WAN) media
interconnect IP devices. Therefore, IP successfully operates over heterogeneous network
infrastructures consisting of several kinds of different media technology. This flexibility,
together with a simple protocol stack, is the most critical instigator of its popularity.
IP addressing assigns addresses to individual network interfaces of a device (link-based
approach) instead of using a single address for the whole device (host-based approach).
The various interfaces of a device are connected to network links that are designated as
subnetworks (or subnets) and are assigned subnet addresses. An interface’s IP address is
assigned from the subnet address space of the connecting link. The advantage of this link-
based addressing approach is that it allows routers to summarize routing information by
keeping track of only IP subnets in the routing tables instead of every host on the network.
This is advantageous especially for broadcast links such as Ethernet that might have many
devices connected at the same time. The Address Resolution Protocol (ARP) is used in IP
networking for resolving the IP addresses of directly connected hosts to the corresponding
data-link addresses.
Currently, two types of IP addresses exist: IP Version 4 addresses (IPv4) and IP Version
6 addresses (IPv6). IPv4 addressing, which was in place before IPv6 was adopted, uses
32 bits to represent each IP address. This 32-bit addressing scheme provides up to 232
(4,294,967,295) unique host addresses, mathematically speaking. With the ever increas-
ing size of the global Internet, the 32-bit IPv4 addressing scheme has turned out to be
insufficient for the foreseeable future, prompting the introduction of the 128-bit IPv6
addressing scheme. This book covers practical troubleshooting of IP routing protocols
deployed in IPv4 environments. Therefore, the ensuing text discusses only the IPv4
addressing structure and related concepts, most of which are applicable to IPv6. The
following IPv4 addressing topics are covered in the subsequent sections:
• IPv4 address classes
• Private IPv4 address space
• IPv4 subnetting and variable-length subnet masking
• Classless interdomain routing

IPv4 Address Classes

As explained in the previous section, the 32-bit IPv4 addressing scheme allows a large
number of host addresses to be defined. However, the link-based addressing scheme
6 Chapter 1: Understanding IP Routing

adopted by IP requires network links to be associated with groups of addresses from which
the connected hosts are assigned specific addresses. These address groups, described also
as address prefixes, are referred to in classical IP terminology as IP network numbers.
Originally, IP network numbers were defined with rigid boundaries and grouped into ad-
dress classes. The idea behind IP address classes was to enable efficient assignment of the
IP address space by creating address groups that would support a varying number of hosts.
Network links with fewer hosts then would be assigned an address from a class that sup-
ports an appropriate number of attached hosts. Another benefit of address classes was that
they helped streamline the address-allocation process, making it more manageable.
Five address classes—A, B, C, D, and E—were defined and distinguished by the setting of
the most significant bits of the most significant byte in the IP address. Each address class
embraced a set of IPv4 address subnets, each of which supported a certain number of hosts.
Table 1-1 shows the five IPv4 classes.
Table 1-1 IP Address Classes and Representation
Address Bit Pattern of First Byte Host Assignment Range in
Class First Byte Decimal Range Dotted Decimal
A 0xxxxxxx 1 to 127 1.0.0.1 to 126.255.255.254
B 10xxxxxx 128 to 191 128.0.0.1 to 191.255.255.255.254
C 110xxxxx 192 to 223 192.0.0.1 to 223.255.255.254
D 1110xxxx 224 to 239 224.0.0.1 to 239.255.255.254
E 11110xxx 240 to 255 240.0.0.1 to 255.255.255.255

As Table 1-1 shows, a specific bit pattern in the first byte of an IP address corresponds to a
range of addresses and maps to a specific address class.
Of the five address classes, three—Class A, B, and C—were designated for unicast single
source–to–single destination communication. Addresses in Class D were reserved for IP
Multicast applications, which allows one-to-many communication. Class E addresses were
reserved for experimental purposes.
To make the addresses in each of the unicast address classes (A, B, and C) support a specific
maximum number of hosts, the 32-bit address field was delineated into network identifier
(network ID) bits and host identifier bits (host ID) as follows:
• Class A—8-bit network ID, 24-bit host ID
• Class B—16-bit network ID, 16-bit host ID
• Class C—24-bit network ID, 8-bit host ID
Figure 1-2 shows the assignment of the 32 bits in a Class A address. The highest-order bit
has a fixed value of 0, and the whole of the first byte is the network ID. The last 3 bytes are
designated as host bits.
 IP Addressing Concepts 7

Figure 1-2 Assignment of Class A Address Bits

Bit 0 8 16 24 32

Network ID Host ID
0

This notion of categorizing IP addresses into classes with rigid boundaries is also known as
classful addressing. IP addresses use masks to delineate host bits from the network number
bits. IP address structuring has evolved through various innovations, all geared toward mak-
ing address allocation and actual assignment in real networks more efficient. You find out
more about this in the section “Subnetting and Variable-Length Subnet Masks.”
To make it easier for humans to work with IP addresses, these addresses are represented
in a format known as dotted-decimal notation. In the dotted-decimal representation, the
bits are grouped into octets and are separated by dots. Each octet of binary bits then is
converted into the decimal equivalent. The last column of Table 1-1 shows the dotted-
decimal notations for the range of addresses in each of the address classes.
Even though classful addressing was introduced to facilitate efficient use of the IPv4
address space, the rigid classful boundaries left a lot more to be desired. Because of its
rigidity and inefficiency, classful addressing has been abandoned for the more efficient
and flexible notion of classless addressing.
In classless addressing, any IP network number is interpreted as a prefix of a certain
length. This interpretation provides more flexibility and results in a more efficient use of
the IPv4 address space. A large classful block of addresses such as a Class A address can
be split into multiple smaller blocks for allocation to multiple organizations instead of
being allocated to a single organization under the classful notions. Conversely, classless
addressing allows multiple Class C addresses to be aggregated and advertised as a single
larger block instead of being treated as separate addresses. Aggregating addresses in this
manner for the purposes of conserving resource in routers connected to the Internet is
referred to as classless interdomain routing (CIDR), which is further discussed in a later
section, “Classless Interdomain Routing (CIDR).”

IPv4 Private Address Space

Some address blocks in the unicast space were set aside and designated as private
addresses. The private address space was intended for networks that are not connected to
the public Internet. The following addresses are specific in RFC 1918 as part of the IPv4
private address space:
• 10.0.0.0 to 10.255.255.255
• 172.16.0.0 to 172.31.255.255
• 192.168.0.0 to 192.168.255.255
8 Chapter 1: Understanding IP Routing

RFC 1700 provides general information on reserved or allocated parameters, including

reserved addresses. Private internets that have deployed addresses from the private IPv4
space still can connect to the public Internet by using address Network Address Translation
(NAT).

Subnetting and Variable-Length Subnet Masks

Before CIDR, each classful network number could be allocated for use in only a single
organization. However, within an organization, it was possible to use subnetting to break
up a classful address into multiple smaller address groups that could be applied to different
segments of the same network domain.
IP subnetting introduces another level of hierarchy into the structure of IP address classes
by moving some of the host bits in a classful network number into the network ID field. The
extended network ID is referred to as a subnetwork number or simply as an IP subnet. For
example, one octet of the 2 octet host bits of a Class B address can be used to create 255
subnets, each with only an octet of host bits. This is illustrated in Figure 1-3.

Figure 1-3 Class B Subnet Example

Bit 0 8 16 24 32

Network Host

Class B address format

Bit 0 8 16 24 32

Network Subnet Host

Subnetted Class B address format

When an IP address is subnetted, the address mask is adjusted to reflect the new demarcation
between the network and host bits. Figure 1-4 shows the new mask and the corresponding
subnets that are created from a Class B address. A string of ones in the mask represent the
network bits, and the zeros represent the host bits. A common way of representing an IP
address is to indicate its prefix length, which is the number of 1 bits in the mask. This also
represents the number of network bits in the address. For example, 172.16.1.0 255.255.255.0
can be represented as 172.16.1.0/24.
 IP Addressing Concepts 9

Figure 1-4 Subnet Mask Example

a) Subnetted Class B address

0 8 16 24 32

Network Subnet Host

b) Subnet mask
0 8 16 24 32

11111111 11111111 11111111 00000000

255 255 255 0

c) Class B subnets
Class B address 8-bit subnet address

172.16.0.0/16 172.16.0.0/24
172.16.2.0/24
172.16.3.0/24
:
:
172.16.255.0/24

Even though classful addressing allows subnetting for more efficient assignment of
addresses from a block, in a classful network environment only a consistent mask is
allowed. VLSM extends the notion of subnetting to allow different masks to be applied
to one network number, providing more flexibility in carving up an address into different
block sizes for application to different segments in a network domain. This allows more
efficient use of an allocated address block. For example, by using VLSM, the Class B
address, 172.16.0.0/16, can be carved into smaller subnets with 24-bit subnet masks
by using 8 host bits as subnet bits. You then can further subnet one of the first genera-
tion subnets—for example, 172.16.1.0/24—by using another 4 of the remaining host
bits. This will result in much smaller blocks such as 172.16.1.0/28, 172.16.1.16/28,
172.16.1.32/28, and so on. VLSM can be used only in classless network environments
in which the routing protocols and related routing software support classless addressing.
Figure 1-5 illustrates subnetting with VLSMs.

Figure 1-5 VLSM Example

Class B address 8-bit subnet address 4-bit VLSM

172.16.0.0/16 172.16.0.0/24 172.16.2.0/28

172.16.1.0/24 172.16.2.16/28
172.16.2.0/24 172.16.2.32/28
: :
: :
172.16.255.0/24
172.16.2.240/28
10 Chapter 1: Understanding IP Routing

Classless Interdomain Routing

VLSM helps improve the efficiency of IP address usage for an assigned address block;
however, it does not solve challenges with inefficient allocation of addresses to organiza-
tions. The imminent depletion of IP addresses as the result of inefficient use of classful
blocks and the growing number of classful addresses in the global Internet routing tables
as organizations were allocated multiples of a Class C address instead of a single Class B
address led to the introduction of classless interdomain routing (CIDR).
CIDR allows an IP network number to be any length, abandoning completely the fixed
boundaries associated with classful concepts. The two benefits of CIDR are illustrated in the
examples provided in Figure 1-6. By eliminating the notions of address classes, a block of
addresses such as 192.168.0.0 to 192.168.255.0 consisting of an individual Class C address
can be considered a uniform block that can be conveniently represented as 192.168.0.0/16.
This essentially implies aggregation of 256 “old notion” Class C addresses into a single
address block, referred to as a CIDR block or a supernet.

Figure 1-6 Examples of CIDR Aggregation and Subnetting

Classful address CIDR supernet

192.168.0.0/24
192.168.1.0/24
192.168.2.0/24 192.168.0.0/16
192.168.3.0/24
:
:
192.168.255.0/24

Classful address CIDR subnets

131.108.0.0/18
131.108.64.0/18
131.108.0.0/16 131.108.128.0/18
131.108.192.0/18

CIDR also allows network numbers to be flexibly subnetted and allocated to different
organizations for interdomain routing exchange. For example, 131.108.0.0/16 can be
divided into four subblocks (131.108.0.0/18, 131.108.64.0/18, 131.108.128.0/18, and
131.108.192.0/18) and allocated to four different organizations instead of one.
 Dynamic Routing 11

Static and Dynamic Routes

Static path information can be manually programmed into the router and simply force
the router to utilize a particular interface or next-hop IP address for forwarding packets
with matching destination addresses. Static routes potentially could match a broad range
of network addresses. Yet another way to obtain routing information is to use distributed
applications enabled on routers that allow automatic collection and sharing of routing infor-
mation. These routing applications frequently are referred to as dynamic routing protocols
because they are not only automated route-gathering tools; they also work in almost real
time, tracking the state of connectivity in the network to provide routing information that
is as current and as valid as possible.
Contrast this behavior with static routes, which are manual route entries and require manual
intervention to reprogram the network routers in case of any path changes. Obviously,
dynamic routing protocols provide more convenience to the network operator than static
routes in managing routing information. The price for this convenience, however, is con-
figuration and troubleshooting complexity. Operation of dynamic routing protocols also
can be resource-intensive, requiring large amounts of memory and processing resources.
Hence, working with dynamic routing protocols frequently requires advanced knowledge
and sophisticated expertise for handling related network design, router configuration,
tuning, and troubleshooting chores.
Even though static routing is less demanding on system resources and requires a lower level
of technical skill to configure and troubleshoot, the sheer effort of manually entering routes
for a sizeable network makes it a less attractive option. Obviously, static routing is not a
good candidate for today’s large enterprise and Internet service provider (ISP) IP-based
networks. Another drawback to static routing is that it is less flexible for implementation of
complicated routing policies. When it comes to routing policy implementation, there is no
better substitute for the intelligence and flexibility provided by dynamic routing protocols,
such as BGP, OSPF, and IS-IS. The next section further discusses dynamic routing
protocols.

Dynamic Routing
The last section discusses the essence of IP routing and indicates that dynamic automatic
routing is very necessary for large network deployments. This section discusses the charac-
teristics and classification of various IP routing protocols. Although all routing protocols
have a common goal of gathering routing information to support packet-forwarding deci-
sions, they can be classified into two broad categories, unicast and multicast, based on the
type of data traffic they are designed to provide forwarding information for.
The previous section indicates that IP provides an addressing scheme for identifying
various locations or subnets in the network. The destination IP address in an IP packet
12 Chapter 1: Understanding IP Routing

indicates the target address of the packet. The sender’s address is stored in the source
address field. An important concept to understand about IP addressing is IP subnetworks.
IP subnetworks—or subnets, for short—are mentioned earlier in the section on IP address-
ing concepts. Physically, an IP subnet is a collection of interconnected network devices
whose IP interface addresses share the same network ID and have a common mask.
The earlier section “IPv4 Address Classes” discusses unicast and multicast addresses. The
unicast address space is used for addressing network devices, whereas addresses from the
multicast space are used for specifying groups or users tuned in to receive information from
the same multicast application.
For any IP unicast subnet, the last address, such as in 192.168.1.255/24, is known as the
broadcast address. This address can be used to target all nodes on the subnet at the same
time in what is referred to as a directed broadcast.
A unicast routing protocol is optimized for processing unicast network information and
provides routing intelligence for forwarding IP packets to unicast destination addresses.
Multicast forwarding is conceptually different and requires special routing applications to
support forwarding of multicast packets.

Unicast Versus Multicast IP Routing

Two devices in an IP network normally communicate by sending unicast traffic to each
other’s IP address. An IP node might have many active interfaces, each of which needs to
be configured with an IP address from the unicast space. The address on an interface
uniquely defines the device on the subnet directly connected to that interface.
Cisco routers also support the concept of secondary logical subnets, many of which can
be configured on a router’s interface in addition to the primary address on that interface.
Additionally, you can enable tunnel and loopback interfaces on a Cisco router, both of
which provide it with unicast IP reachability. Packets with unicast addresses in their des-
tination field are forwarded based on information in the IP routing table. The IP routing
table on a Cisco router is displayed with the show ip route command.
If the address in the destination field of a packet is from the multicast address space
(Class D), the packet is directed to a multicast group with potentially many receivers.
Multicast forwarding uses special mechanisms that enable efficient utilization of network
resources. If an application is designed for multidestination delivery, using unicast
routing to forward packets of the application’s data stream would require unnecessary
replication at the source, resulting in a waste of network resources. This can be avoided
by using multicast propagation, which replicates multicast packets only when necessary
at branches in the network toward the location of receivers.
Figure 1-7 illustrates a situation in which a packet is forwarded from SRC1 to two separate
destinations, RCV1 and RCV2, by unicast forwarding.
 Dynamic Routing 13

Figure 1-7 Multidestination Unicast Forwarding

DST:10.1.1.1

RT3 RCV1
DST:10.1.1.1 DST:10.1.1.1
DST:10.1.1.2 DST:10.1.1.2

SRCI RT1 RT2

RCV2
RT4
DST:10.1.1.2

In this case, SRC1 generates two identical streams of packets with destination addresses
10.1.1.1 and 10.1.1.2, respectively. Packets belonging to each stream are handled indepen-
dently and are delivered through RT1 and RT2 to their respective destinations, consuming
network resources (bandwidth and processing time) along the paths that they traverse.
Contrast this scenario with that shown in Figure 1-8, where IP Multicast forwarding
mechanisms are employed.

Figure 1-8 Multicast Forwarding

224.1.0.100

RT3 RCV1

224.1.0.100
224.1.0.100

SRCI RT1 RT2

RCV2
RT4
224.1.0.100
14 Chapter 1: Understanding IP Routing

Multicast forwarding provides a more efficient way to deliver information by replicating

packets only at fork points of the network where paths to receivers follow divergent directions.
Therefore, as shown in the Figure 1-8, SRC1 originates only a single stream, and packets in
this stream are forwarded through RT1 to RT2. They are then replicated at RT2 and fanned out
to RCV1 and RCV2.
Multicast routing protocols are functionally different from unicast routing protocols, in that
they build multicast forwarding state in the multicast-enabled routers by using a concept
known as reverse path forwarding (RPF). RPF is used to ensure that a multicast packet is
received from the interface leading to the expected location of the multicast source, as
dictated by the routing table in place.
RPF is discussed further in Chapter 12, “Understanding Protocol Independent Multicast
(PIM),” which covers IP Multicast routing.
Table 1-2 shows a table of popular multicast and unicast routing protocols.
Table 1-2 Unicast and Multicast Routing Protocols
Unicast Multicast
RIP (V1/V2) DVMRP
IGRP PIM
EIGRP MOSPF
OSPF MBGP
IS-IS MSDP
BGP

All the listed unicast routing protocols are supported in Cisco IOS Software; however, from
the listed multicast routing protocols, only Protocol Independent Multicast (PIM) sparse
mode/dense mode (SM/DM), Multicast Source Discovery Protocol (MSDP), and
Multiprotocol BGP are supported.
Multicast routing environments also need an additional protocol called the Internet
Gateway Multicast Protocol (IGMP). Multicast OSPR (MOSPF) is not supported at all,
but IOS provides special capabilities for interoperability with the Distance Vector
Multicast Routing Protocol (DVMRP).
As of this writing, multicast routing protocols are not widely deployed on the Internet.
However, this situation obviously will change in the near future as more multicast-oriented
applications, such as radio broadcasting, video streaming, remote training, videoconfer-
encing, and gaming, become more popular on the Internet.
 Dynamic Routing 15

Classless Versus Classful IP Routing Protocols

The concepts of classless and classful IP routing protocols have roots in the manner in
which IP addresses originally were defined.
Under classful addressing rules, a network number was assumed to retain its natural mask
unless explicitly specified when subnetted into smaller blocks. However, earlier-generation
routing protocols, such as the Routing Information Protocol (RIP), could handle only a
single mask for any address throughout a network domain—the natural mask or a single
consistent subnet mask. Routing protocols such as RIP that cannot handle more than one
type of mask, as in the case of VLSMs, are referred to as classful protocols (see Table 1-3).
The reason that classful protocols do not support VLSMs is that, by design, they do not
advertise or carry the associated subnet mask with routes and, therefore, use simple
intuitive mechanisms to determine the mask associated with a learned route.
The significant growth of the Internet to global dimensions called for more efficient use of
the limited IPv4 address space. Available addresses in the IP address space therefore attained
the status of a scarce commodity. The classless notions of VLSM and CIDR, discussed earlier,
were invented to make address allocation and use more efficient. Routing protocols also were
enhanced to support classless addressing environments. Routing protocols that are designed
for operation in classless environments and that can handle VLSM address and CIDR are
referred to as classless routing protocols.
Table 1-3 features a list of routing protocols categorized as classful and classless. RIP-1 and
IGRP are grouped under classful protocols, whereas the more recently developed RIP-2,
EIGRP, OSPF, IS-IS, and BGP fall in the classless category. The Exterior Gateway Protocol
(EGP), the predecessor of the Border Gateway Protocol (BGP), which currently is considered
obsolete, is also a classful protocol.
Table 1-3 Classful and Classless IP Routing Protocols
Classful Classless
RIP-1 RIP-2
IGRP EIGRP
EGP OSPF
Integrated IS-IS
BGP

Interior Gateway Protocols Versus Exterior Gateway Protocols

Even though many unicast routing protocols were developed in the early days of the
ARPANET (the predecessor to the Internet), Routing Information Protocol (RIP)
emerged as the most popular. Many independent networks that were created at govern-
ment research institutions and universities as a result of the remarkable success of
16 Chapter 1: Understanding IP Routing

the ARPANET also adopted RIP for dynamic routing operations. The evolution of the
ARPANET into the Internet required the numerous island networks to be interconnected
using a more robust routing protocol. The Exterior Gateway Protocol (EGP) was selected
for this purpose. EGP provided an efficient mechanism for routing among the various RIP
domains. Therefore, RIP and EGP were optimized for distinct functions in the network
based on their capabilities. RIP was used for intradomain routing, and EGP was used for
interdomain routing. EGP later morphed into the Border Gateway Protocol (BGP), and
other more robust protocols optimized for intradomain routing emerged in place of RIP.
In particular, the Open Shortest Path First (OSPF) Protocol was developed in the Internet
Engineering Task Force to provide capabilities that RIP lacked, such as more intelligent
routing metrics, faster convergence, and operation in classless environments. So, here we
are again with yet another classification of routing protocols: interior gateway routing
protocols (for intradomain routing) and exterior gateway protocols (for interdomain
routing).
Figure 1-9 shows two routing domains, AS 65001 and AS 65002, and an overlapping
(shaded) region depicting the interconnection between border routers from each domain.
In more current routing terminology, a routing domain also is referred to as an autono-
mous system. An autonomous system is an independent routing domain under the control
of a single administrative authority.

Figure 1-9 Intradomain and Interdomain Routing

AS 65001
AS 65002

Intradomain Intradomain
Routing Interdomain Routing
Routing

As noted before, an exterior gateway protocol provides the capability for sharing routing
information between the two domains. Currently at version 4, BGP is the only IP inter-
domain protocol that is used for interconnecting the numerous autonomous systems in
the global Internet. An interior gateway protocol provides routing intelligence within an
autonomous system. Each of the autonomous systems in the Internet can run any suitable
IGP. With the exception of EGP (the obsolete routing protocol) and BGP, all the other unicast
protocols mentioned so far—IGRP, EIGRP, RIP, OSPF, and IS-IS—are IGPs (see Table 1-4).
 Dynamic Routing 17

Table 1-4 IGP and EGP Classification

Exterior
Interior Gateway Protocols Gateway Protocols
Advanced
Distance Vector Distance Vector Link-State Path Vector
RIP-1 EIGRP OSPF BGP
RIP-2 Integrated IS-IS
IGRP

The Interior Gateway Routing Protocol (IGRP) was invented by Cisco Systems to offer
better metrics than the simple hop count supported by RIP. IGRP introduced a composite
metric that consists of several parameters:
• Bandwidth
• Delay
• Reliability
• Load
• Maximum transmission unit (MTU)
Cisco evolved IGRP into the Enhanced Interior Gateway Routing Protocol (EIGRP).
EIGRP provides faster convergence relative to IGRP by using backup routes, referred to as
feasible successor routes, that are readily installed in the routing table when a preferred
route is lost. Unlike IGRP, EIGRP supports VLSM.
OSPF and IS-IS are both popular IGPs used in very large IP networks. IS-IS originally was
designed as a routing protocol for the Connectionless Network Protocol (CLNP) but later
was adapted to route IP about the same time that the Open Shortest Path First (OSPF) proto-
col was being standardized in the Internet Engineering Task Force (IETF). OSPF and IS-IS
are both link-state protocols, whereas RIP, IGRP, and EIGRP are distance vector protocols.
Also, OSPF and IS-IS are link-state protocols that use the shortest path first (SPF) algorithm
(named after Dijkstra) for route computation, making them converge relatively fast in re-
sponse to network changes.
Both protocols also support a two-level hierarchical routing architecture. OSPF and IS-IS are
very similar protocols with almost identical capabilities. However, they have some
architectural differences that are beyond the scope of this book.
An interesting point to note, however, is that OSPF was designed entirely for IP only, and
OSPF packets are encapsulated in IP packets. In contrast, IS-IS was designed for CLNP and
was adapted to support IP additionally. IS-IS packets are not encapsulated in IP packets but
rather directly by the data link protocol.
18 Chapter 1: Understanding IP Routing

The next section of this chapter looks at yet another routing protocol classification: distance
vector and link-state protocols.

Distance Vector Versus Link-State Protocols

This section takes a look at routing protocol from a different perspective. In the previous
sections, we considered general classification such as classful versus classless and also
IGP versus EGP. This section discusses classification based on design and operation. The
second row in Table 1-4 places the protocols discussed so far into four different categories,
two of which stand out—distance vector and link-state. These two broad categories
actually apply to IGP as shown in the table.
EIGRP is essentially a distance vector protocol just like IGRP, except that it is rightfully
considered in its own class as an advanced distance vector protocol because it has more
modern characteristics, such as support of classless routing and fast convergence. BGP is
also in its own category, path vector protocol because, as an interdomain routing protocol,
it uses the AS path attribute, which is made up of the list of autonomous systems that a route
has traversed as a key measure for route comparison and selection.
Versions 1 and 2 of RIP (RIP-1 and RIP-2) and IGRP are classified as distance vector
protocols because they use route-computation algorithms based on the Bellman-Ford
algorithm. The Bellman-Ford algorithm is used in graph theory for calculating the
shortest distance between two vertices in a directed graph. A directed graph is a collec-
tion of points, interconnected with directional links, such as the nodes and links in an
internetwork. Routers running distance vector routing protocols use the Bellman-Ford
algorithm for determining the shortest paths to all known locations in the network.
OSPF and Integrated IS-IS are both link-state protocols and use the shortest path first
algorithm (Dijkstra) for route computation. Just like the Bellman-Ford algorithm, the
Dijkstra algorithm provides an alternate method for computing the shortest distance
between two points in a directed graph.
EIGRP uses a Cisco Systems–patented algorithm known as the Diffusing Update Algorithm
(DUAL) to optimize route calculation, breaking away from its predecessor, IGRP, which is
based on the Bellman-Ford algorithm.
The type of algorithm used by a protocol for route computation goes a long way toward
affecting the efficiency of the protocol and how fast it converges. The following sections
examine the concepts and operational principles behind distance vector protocols and link-
state protocols.

Distance Vector Routing Concepts

This section reviews key concepts that underlie the operation of distance vector routing
protocols, such as metrics, count to infinity, split horizon, holddowns, and triggered
 Dynamic Routing 19

updates. These concepts are evaluated in terms of general routing functionality, such as
stability and speed of convergence and loop avoidance.

Distance Vector Metrics

In the Bellman-Ford algorithm, each router advertises the best paths to all known des-
tinations, from its perspective, to all neighbors. The links between routers are assigned a
measure known as cost or metric. The metric can be determined from characteristics of
the links, such as hop count, bandwidth, delay, reliability, monetary value, and so on. The
hop count associated with a link between two directly connected nodes is usually 1, even
though arbitrary values can be administratively assigned. The metric associated with a
specific path to a known destination from any router is the sum of all the metrics of links
along that path. Usually, the path with the lowest metric is the best. A router might have
many neighbors and, therefore, might receive multiple paths for the same destination. It
then computes the metric associated with each of these paths and selects the best path by
a criterion such as the lowest metric.
RIP uses hop count for metric, with the maximum possible number of hops to any reachable
destinations being 15. A metric of 16 hops or more is considered to be infinity. Hence, a hop
count of 15 defines the maximum width of reachability in a RIP network. This imposes a
limit on the size of RIP-based networks, which also implies that RIP is suitable for only
small, flat networks. Hop count actually pertains to the node count from a specific source
to a destination and has no consideration for actual network characteristics, such as
bandwidth, delay, or monetary costs.
IGRP, which is also a distance vector protocol, uses a metric system that takes into consider-
ation relevant characteristics of the network, such as bandwidth, associated maximum trans-
mission unit, reliability of links, and also path delay. The metric assigned to each link in the
outgoing direction is calculated from a formula that takes into consideration all these char-
acteristics. This sort of multifaceted metric is called a composite metric.
The Bellman-Ford algorithm uses a vector (distance vector), consisting of cost (metric) and
next-hop information for each known route to determine best paths in the network from any
standpoint. An iterative procedure calculates the cost of all paths for any received route and
selects the vector with the best cost for each route. Hence, routing protocols that are based
on the Bellman-Ford algorithm commonly are referred to as distance vector protocols (see
Table 1-4).

Routing Convergence
When there is a topology change, a router might invalidate some of the previously known best
paths. The router then uses new or existing information to determine an alternate best path for
each affected destination. Recalculating routes to rediscover alternate routes as a result of
network topology changes is referred to as routing convergence. Routing convergence may be
20 Chapter 1: Understanding IP Routing

triggered by events such as router failures, link failures, or even administrative metric adjust-
ments.
Distance vector protocols such as RIP and IGRP are relatively simple compared to their
link-state counterparts. However, this simplicity comes with a price. Because each router
bases its best-path determination on the best paths advertised by neighbors, such protocols
are very prone to routing loops. A routing loop occurs when two nodes point to each other
as the next hop along the path to the same destination. The most obvious effect of routing
loops is that they prolong the time it takes for a router to determine a route is no longer
available or to select an alternate path. Routing loops adversely impact convergence times.
Therefore, it is desirable that unusable routes be removed from the network as soon as
possible. The following sections discuss various methods employed by distance vector
protocols to prevent or limit the effect of routing loops and improve convergence. The
following is discussed:
• Counting to infinity
• Using holddown
• Using split horizon and poison reverse
• Using triggered updates

Loop Avoidance
Routers running distance vector protocols determine best paths for routes relative to neigh-
bors that have advertised those routes to them. The mechanics of operation of distance
vector protocols, specifically the way routes are advertised by distance vector protocols,
makes such environments very susceptible to routing loops—for example, when a router
running a distance vector protocol broadcasts routing updates over all interfaces activated
for the protocol. When a router broadcasts all known routes in this manner, it may advertise
a route back to the source it was heard from. Consequently, when there is a failure, it is
possible for two neighboring nodes to think that the other is the next hop along the best path
to a specific destination. This situation, which results in a routing loop, is elaborated in
Figure 1-10.

Figure 1-10 Routing Loops in Distance Vector Environments

Destination
(Dest3)

Routing
loop

RT1 RT2 RT3

 Dynamic Routing 21

In Figure 1-10, RT1, RT2, RT3 are connected serially, and hop count is used as the measure
for metric. A route associated with the destination link (Dest3) is advertised by RT3 to RT2,
with a hop count of 1. RT2 assigns Dest3 a hop count of 2 and then advertises it to RT1. RT1
stores Dest3 with a hop count of 3 and with RT2 as the next hop. RT1 then might advertise
Dest3 back to RT2. This route is not used by RT2 because it has a worse metric (four hops)
than the original that came from RT3 (two hops). However, if the connection between RT2
and RT3 is broken, RT2 will remove the original route and install an alternate route to Dest3
with a metric of 4 and RT1 as the next hop. Meanwhile, RT1 has the same route pointing
back to RT2 as the next hop. Thus, a loop situation is created and any packets from RT1 or
RT2 to Dest3 will be caught up in a “ping pong” between the two routers for some time until
their Time To Live (TTL) counters in the packets expire. Routing loops disrupt routing, and
it is desirable to curtail them as quickly as they appear. To limit the effect of routing loops,
distance vector protocols use a method known as counting to infinity. This principle is
elaborated in the next section.

Counting to Infinity
To prevent routing loops of indefinite duration, distance vector protocols enforce limits on
route metrics that allows routers to declare routes as unreachable after the associated
metrics reach a certain value. In the loop situation described in Figure 1-10, RT1 and RT4
might advertise Dest3 to each other, each time increasing the associated hop count received
from the other by 1 and before readvertising the route. Consequently, the metric associated
with Dest3 will continue to increase. Counting to infinity places an upper bound on the
metric beyond which it is considered infinity and the route is declared unusable. For RIP,
this upper bound is 15.

Holddown
Holddown is used to dampen a route’s response action to finding an alternate route when a
primary route is no longer usable. When a router determines that a route is no longer avail-
able, it places the route in holddown state for a duration called the holddown time, during
which it doesn’t select an alternate route, even if available. The route in holddown state
is advertised with a metric or value of infinity in an attempt to purge it from the network.
Purging unusable routes helps reduce the incidence of routing loops.
To illustrate this using Figure 1-10, RT2 places Dest3 in holddown when it invalidates
routes heard from RT3 because of the failure of the connection between them. With Dest3
in holddown state, RT2 does not use the alternate route from RT1; instead, it advertises
Dest3 to RT1 again with a metric. This allows RT1 to withdraw Dest3 from its tables. By
the expiration of the holddown time, both RT1 and RT2 are expected to have removed
Dest3 from their routing tables, thus avoiding a potential routing loop.
22 Chapter 1: Understanding IP Routing

Another benefit to using holddowns is that it prevents unnecessary reactions to equipment-

related glitches that cause the link to flap. The downside is that it contributes significantly to
the higher convergence times associated with distance vector routing protocols.

Split Horizon and Poison Reverse

Routing loops are primarily the result of routes being leaked back to their sources. For
example, in Figure 1-10, the loop between RT1 and RT2 is caused by feedback of Dest3
back to RT2 by RT1, misleading RT2 to think that RT1 is the next hop on an alternate path
to Dest3.
Split horizon prevents a router from advertising a route back out the interface through
which it was received. With split horizon in effect, RT1 cannot advertise Dest3 back to RT3
over the link between them (see Figure 1-10).
Poison reverse is similar in principle to split horizon, except that it allows routes to be
advertised back out the interfaces on which they were received as unreachable (metric of
infinity assigned). That is, routes are “poisoned” in the reverse direction. Referring to
Figure 1-10, with poison reverse enabled, RT1 advertises Dest3 back to RT2, but with a
metric value of infinity (16 hops, in the case of RIP).
The approach adopted by poison reverse can result in undue waste of bandwidth if many
poisoned routers must be advertised back out. However, this approach speeds up route
convergence by eliminating the need for holddowns. In this case, the alternate route would
have an obvious infinite metric when fed back to the source, hence simplifying the search
for an alternative path, when the primary route is lost.

Periodic and Triggered Updates

Routers running distance vector routing protocols, such as RIP and IGRP, advertise all the
contents of their routing tables at regular intervals. Periodic broadcasts of large routing
tables are a major concern in large networks. For example, RIP broadcasts all known routes
out of every active interface every 30 seconds, by default, even if there are no changes.
IGRP uses a default update interval of 90 seconds.
If updates are advertised only periodically, changes in the network might not be communi-
cated fast enough, impacting convergence times. Also, the holddown time typically is tied
to the update interval. So a larger interval might result in less bandwidth consumption by
routing updates yet might introduce higher convergence times.
Triggered (or flash) updates remove delays in convergence caused by periodic updates by
sending updates immediately following a network change instead of waiting for the periodic
update timer. Flash updates trickle through the network from one node to the other, resulting
in an overall time gain in network-wide convergence, even if not very significant. Complicity
 Dynamic Routing 23

between periodically scheduled updates and triggered changes can result in unpredictable
behavior.

Link-State Protocols
Link-state protocols are relatively more modern and, therefore, incorporate capabilities into
their design to overcome some of the shortcomings of distance vector protocols discussed
previously. Hence, they are more sophisticated and require more memory and processing
resources to operate effectively. By virtue of characteristics such as faster convergence,
incremental updates, and a hierarchical architecture, link-state protocols are more suitable
for deployment in large internetworks. Two popular link-state protocols used in IP networks
are OSPF and IS-IS.
Unlike distance vector protocols, which share best-known routing information, link-state
protocols allow routers to exchange topology (link-state) information that allows them
to draw out the layout of the internetwork’s topology. Routers in a link-state network
converge relatively faster than their distance vector counterparts by responding immediately
to changes in the topology, without the need for loop avoiding or limiting holddowns and
counting to infinity. For example, RIP and IGRP typically feature convergence times in
minutes, whereas OSPF and IS-IS converge in the order of seconds for comparable network
changes.
Link-state protocols support hierarchy for scaling purposes by carving out a network into
areas (see Figure 1-11). Routing within areas fall in the first level of the routing hierarchy.
The areas are interconnected over a backbone area, and routing within the backbone consti-
tutes the second level of the hierarchy.

Figure 1-11 Areas and Hierarchy in Link-State Protocols

Area Area
Backbone
RT1 RT6
RT3 RT4
RT5

RT2 RT7

Routers in the same area or the backbone share link-state information that is assembled
into a link-state database. The topology of the area or the backbone is discerned by
running the shortest path first algorithm over the respective databases. This procedure
24 Chapter 1: Understanding IP Routing

also generates the best routes that are used in the IP routing and forwarding tables.
Chapter 8, “Understanding Open Shortest Path First (OSPF),” and Chapter 10, “Under-
standing Intermediate System-to-Intermediate System (IS-IS),” describe the operation
of the link-state routing protocols and their respective protocols in more detail.

Metrics in Link-State Protocols

Both OSPF and IS-IS use metrics, which are measures of link bandwidth. OSPF goes a step
further, to provide autoconversion of the bandwidth on interface to a link cost. IS-IS metrics
are 10, by default, on all interfaces. In both cases, the metric or cost associated with a link
can be manually configured. The metric associated with a route is the sum of all the metrics
on the outgoing links to the associated destination.
Chapters 8 and 10 provide more information on metrics in OSPF and IS-IS, respectively.

Routing Protocol Administrative Distance

The previous sections in this chapter provide a high-level overview of IP routing protocols
from the perspectives of design, architecture, and operation. The section discusses briefly
generic implementation-related issues that impact operation of these protocols on Cisco
routers. Details of operation and configuration of each protocol are covered in the protocol-
specific chapters.
Cisco IOS Software provides common command resources for configuring and enabling
the capabilities of IP routing protocols. Commands such as distance, distribute-list,
redistribute, route-map, policy-map, access-list, prefix-list, offset-list, and so forth
frequently are referred to as protocol-independent commands because they can be used in
diverse ways to enable many features in Cisco IOS Software, including routing protocol
capabilities. In their application to routing protocols, protocol-independent commands are
used for filtering routes, enabling redistribution, configuring default routes, and imple-
menting various routing policies. You can find more detail on these commands online at
www.cisco.com; however, this section discusses the distance command and the feature that
it supports—administrative distance.
All the IP routing protocols discussed so far can operate concurrently and yet independently
on Cisco routers if enabled together. Usually, only one IGP (OSPF or IS-IS) is required to
run alongside BGP in an IP network. However, depending on the situation and the history
of a network, more than one IGP might be operation to support routing requirements.
Administrative distance is a Cisco-specific method of distinguishing between routes
obtained from different routing sources in the same network. It provides a simple mech-
anism to differentiate believability of routing information sources. Cisco IOS Software
assigns numeric values to routing sources that allow routes from one routing source to be
preferred over similar routes from another source. Sources with lower administrative dis-
 Fast Forwarding in Routers 25

tance values are preferred. When multiple protocols supply the same route, only the route
from the source with the lower administrative distance will make it into the routing table.
Table 1-5 lists the default administrative distances of IP routing sources. The distance
command can be used to modify any of the defaults.
Table 1-5 Administrative Distances of IP Routing Protocols
Route Source Administrative Distance
Connected interface 0
Static route out an interface 1
Static route to a next hop 1
EIGRP summary route 5
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP-1/RIP-2 120
EGP 140
External EIGRP 170
Internal BGP 200
Unknown 255

Fast Forwarding in Routers

Even though this book is about routing protocols and how to troubleshoot routing-related
problems, we would like to briefly mention in this introductory chapter that the high-speed
forwarding requirements in today’s networks have led to ingenious ways of packet pro-
cessing on routers that extend beyond basic decision-making based on the IP routing table.
The routing table remains critical for routing guidance, but instead of using the contents
of the routing table directly, routers transform the routing information in the routing table
for storage in data structures, optimized for high-speed packet forwarding. Cisco provides
various high-speed forwarding mechanisms, such as fast switching, optimum switching,
and Cisco Express Forwarding (CEF).
Frequently, troubleshooting routing problems requires investigation into the fast-forwarding
tables, such as the CEF Forwarding Information Base (FIB) and the Adjacency Database.
Detailed discussions of these fast-forwarding mechanisms are outside the scope of this book.
More information on this subject matter is available at the Cisco site, www.cisco.com.
26 Chapter 1: Understanding IP Routing

Summary
This introductory chapter reviews the concepts underlying IP routing and explains why
routing is relevant for information transfer in a connectionless networking environment.
You learned that protocols such as IP, which provide connectionless delivery of information,
allow data to be transmitted in chunks of information, known as datagrams. IP datagrams
also are referred to as packets. Packets consist of a payload and a header. The headers in
IP packets contain target addresses that allow them to be independently routed over optimal
paths in the network toward their destinations. IP is a network layer protocol; routers, which
process and forward packets, run routing protocols that automate the gathering of routing
information in internetworks.
Classful and classless notions of IP addressing are covered, leading to a discussion on
VLSMs and CIDR. The relevance of CIDR and VLSMs as vehicles for efficient address
allocation and use is covered as well.
The subsequent text of the chapter discusses various classifications of dynamic routing
protocols, categorizing them into unicast versus multicast, classless versus classful, IGP
versus EGP, and, finally, distance vector versus link-state. Key characteristics of distance
vector and link-state protocols are discussed and compared.
Brief coverage of Cisco IOS Software protocol-independent commands led to the discus-
sion of administrative distances associated with routing protocols. Administrative distance
is defined as a mechanism for distinguishing between routing protocol sources and asso-
ciating an IOS default trust factor with various routing protocols.
The final section briefly touches on how the routing information gathered by routing
protocols actually is used in forwarding. It is pointed out that Cisco routers convert the
information in a routing table into optimized data structures for high-speed packet
forwarding.

Review Questions
1 What is connectionless data networking?
2 Why is routing needed in a connectionless networking environment? List two means
by which routers obtain information for routing packets toward their destinations.
3 What is the difference between functionalities of Interior Gateway Protocols (IGPs)
versus exterior gateway protocols (EGPs)?
4 List the two main groups of IP routing protocols based on the method of operation and
routing algorithm. Also, list two examples of each type.
5 Briefly describe the operation of link-state routing protocols.
 References 27

6 What is the key difference between classless and classful routing protocols? Give an
example of each.
7 What is the use of routing protocol administrative distances on Cisco routers?

8 What are the values of administrative distance of IS-IS and OSPF, respectively?
9 If a router is running both OSPF and IS-IS protocols and has the same route from each
of them, which protocol's information will be used in the IP routing table?

References
Bates, T., R. Chandra, Y. Rekhter, and D. Katz. “Multi-Protocol Extensions for
BGP4.” RFC 2858, 2000.
Bennett, Geoff. Designing TCP/IP Internetworks. New York, NY: John Wiley & Sons;
1997.
Callon, R. “Use of OSI IS-IS for Routing in TCP/IP and Dual Environments.” RFC
1195. IETF 1990.
Fuller, V., T. Li, J. Yu, and K. Varadhan. “Classless Interdomain Routing (CIDR): An
Address Assignment and Aggregation Strategy.” RFC 1519. IETF 1992.
Hall, Eric A. Internet Core Protocols: The Definitive Guide. Sebastopol, CA: O’Reilly
and Associates, 2000.
Hedrick, C. “Routing Information Protocol.” STD 34, RFC 1058, 1988.
http://www.6bone.net/
http://www.cisco.com/warp/customer/701/3.html. “Understanding IP Addresses.”
http://www.cisco.com/warp/public/103/index.shtml
Huitema, Christian. Routing in the Internet, 2nd Edition. Upper Saddle River, NJ:
Prentice Hall, 2000.
ISO 10589. “Intermediate System-to-Intermediate System Intradomain Routing
Information Exchange Protocol for Use in Conjunction with the Protocol for
Providing the Connectionless-mode Network Service.” (ISO 8473.)
Li, Rekhter. “Border Gateway Protocol Version 4 (BGP 4).” RFC 1771, 1995.
Maufer, Thomas. Deploying IP Multicast in the Internet. Upper Saddle River, NJ:
Prentice Hall, 1997.
Miller, Philip. TCP/IP Explained. Woburn, MA: Digital Press, 1997.
Naugle, Mathew. Network Protocol Handbook. New York, NY: McGraw Hill, 1994.
Perlman, Radia. Interconnections 2nd Edition. Reading, MA: Addison Wesley, 1999.
Reynolds, J. and Postel, J. “Assigned Numbers.” RFC 1700. IETF 1994.
Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear. “Address
Allocation for Private Internets.” RFC 1918. IETF 1996.
This chapter covers the following key topics about Routing Information Protocol (RIP):
• Metric
• Timers
• Split horizon
• Split horizon with poison reverse
• RIP-1 packet format
• RIP behavior
• Why RIP doesn’t support discontiguous networks
• Why RIP doesn’t support variable-length subnet masking (VLSM)
• Default routes and RIP
• Protocol extension to RIP
• Compatibility issues
 CHAPTER
2
Understanding Routing
Information Protocol (RIP)
RIP is a distance vector protocol that uses hop count as its metric. This protocol is very
simple and was intended for small networks. RIP is similar to gated, which was distributed
by the FreeBSD version of UNIX. Before the RFC for RIP Version 1 (RIP-1) was written,
several versions of RIP were floating around.

NOTE Hop count refers to the number of routers being traversed. For example, a hop count of 2
means that the destination is two routers away.

RIP is a classful protocol, which means that it doesn’t carry subnet mask information in its
routing update. Because it doesn’t carry any subnet mask information, it is incapable of
supporting variable-length subnet masking (VLSM) and discontiguous networks. RIP
enables devices to exchange information about networks that they are directly connected
to, as well as any other networks that they have learned from other RIP devices.
RIP sends its routing information every 30 seconds, which is the default update timer. This
timer is configurable. The hold-down timer determines how long a router should wait
before flushing the information from the routing table.
RFC 1058 was written to provide a standard for RIP, which uses the Bellman-Ford algo-
rithm to compute its metric.

Metric
The RIP metric is based on hop count and can be between 1 and 15. The metric 16 is used
for infinity, which means that if the route is unreachable, a metric of 16 is displayed. The
question is, why was the metric chosen as 16? Why not 17 or 18? The metric filed in RIP-1
packet format clearly shows that it is 32 bits long. This means that, theoretically, RIP can
support 232 hops. Although this is a large number, the metric of 15 was chosen to avoid a
count to infinity problem. (This is also referred to as a routing loop.) In a large network with
a few hundred routers, a routing loop results in a long time for convergence if the metric for
infinity has a large value. The number 16 was chosen to get a shorter convergence time.
30 Chapter 2: Understanding Routing Information Protocol (RIP)

The 15-hop limit was chosen also because RIP was intentionally designed for small networks.
It was not intended for the large networks that potentially can have more than 15 hops.

Timers
Like any distance vector protocol, RIP periodically sends an update every 30 seconds. This
update consists of a broadcast of the entire routing table. The update timer controls this
30-second period. RIP uses the following timers:
• Update—The time between each update interval. This value is set to 30 seconds, by
default, and is configurable.
• Invalid—The time after which a suspect route becomes invalid. This is set to 180
seconds, by default.
• Hold-down—The time used to suppress the possibility of defective routes being
installed in the routing table. The default time is 180 seconds.
• Flush—The time after which a route is removed from the routing table. This is set to
240 seconds, by default.

Split Horizon
Split horizon is a technique used to avoid routing loops. With split horizon, when a route is
learned on an interface, that route is not advertised back out on the same interface. For ex-
ample, in Figure 2-1, Router 1 receives an update about Network X with a metric of 1 from
the neighboring Router 2. Router 1 will not advertise Network X back to Router 2 if split
horizon is enabled. If split horizon is disabled, however, Router 1 will advertise Network X
with a metric of 2 to Router 2. If Network X fails, Router 2 will think that Router 1 has a
better way to get to X, so it will send the packet destined to Network X toward Router 1,
creating a black hole.

Figure 2-1 An Example of Split Horizon

Network X

Router 1 Router 2

Split Horizon with Poison Reverse

Another technique used to avoid routing loops is split horizon with poison reverse. With this
technique, routes learned on an interface are advertised back on the same interface, but they are
poisoned, which means that they have a metric of 16 (unreachable). In Figure 2-1, Router 1
 RIP Behavior 31

receives an update about Network X with a metric of 1 from neighboring Router 2. In the case
of split horizon with poison reverse, Router 1 will advertise Network X back to Router 2, but
with a metric of 16, which indicates infinity.
Split horizon with poison reverse is used only when a link failure occurs. It also can be used
in a normal situation, but it is discouraged because it can potentially increase the size of the
routing table.

RIP-1 Packet Format

The maximum datagram size in RIP is 512 octets. The first byte is used for commands such
as rip update request and rip update response. The next byte is used for the Version field,
which is set to 1 for RIP-1. The next 2 bytes must be 0. The 2-byte field after this is used
for the address family identifier; the next 14 bytes are allocated for the network address, as
shown in Figure 2-2. In the case of IP, only 4 bytes of those 14 are used for the IP address.
The remaining 10 bytes are unused in RIP-1, although they are used in the RIP Version 2
(RIP-2) packet format. The next 4 bytes are used for the RIP metric, which can be up to 16.
The portion from the address family identifier up to the Metric field can be repeated 25
times, to yield the maximum RIP packet size of 512 bytes.

Figure 2-2 RIP-1 Packet Format

0 8 16 31
Command Version Must be zero

Address family identifier Must be zero

IP address

Must be zero

Must be zero

Metric

RIP Behavior
RIP follows certain rules when it sends and receives updates. This section covers the rules
for sending and receiving updates.

RIP Rules for Sending Updates

When RIP sends an update, it performs several checks. In Figure 2-3, two routers are running
RIP together. Router 1 is connected to two majornets, 131.108.0.0/16 and 137.99.0.0/16.
32 Chapter 2: Understanding Routing Information Protocol (RIP)

The majornet 131.108.0.0 is further divided into two subnets: 131.108.5.0/24 and
131.108.2.0/24, which is actually connected to Router 2.

Figure 2-3 Example of RIP Behavior

131.108.5.0/24
137.99.88.0/24
131.108.3.0/24

.2 131.108.2.0/24
.2 .1
.2 .1
S0
S0
Router 1 Router 2

Before Router 1 sends a RIP update to Router 2, it performs the check as shown in Figure 2-4.

Figure 2-4 Flowchart That Explains RIP Rules When Sending Updates

RIP rules for sending updates

Is the network or subnet that

Router 1 is announcing to Router 2 Does this network and the Router 1
Yes sourcing interface have Yes
part of the same major network as advertises
the source interface? the same subnetmask? the
network.

No

No

Router 1 drops the network

unless it’s a host route and
Router 1 autosummarizes the router supports
the network or subnet at the host routes. (Cisco routers support
major network boundary and host routes.)
advertises the network.
 RIP Behavior 33

When RIP sends the update, it checks to see whether the advertised network or subnet is on the
same major network as the interface that is sourcing the RIP packet. If the advertised network
or subnet is on a different major network from the interface sourcing the RIP packet, the net-
work is autosummarized. In other words, RIP sends only the majornet information in its routing
update. For example, in Figure 2-3, when Router 1 sends the RIP update to Router 2, it auto-
summarizes the subnet 137.99.88.0 into 137.99.0.0. If the advertised network or subnet is on the
same major network as the router’s interface sourcing the RIP packet, RIP determines whether
the advertised subnet has the same mask as the interface that is sourcing the RIP update. If it
has the same mask, RIP advertises that network; otherwise, RIP drops that network.

RIP Rules for Receiving Updates

When the receiving side gets an update from RIP, the update can contain either a subnet
number, a host address, a network number, or all 0s (indicating the default route):
• Subnet number (such as 131.108.1.0)
• Host address (such as 131.108.1.1)
• Network number (such as 131.108.0.0)
• Default route (such as 0.0.0.0)
Figure 2-5 illustrates the checks performed by RIP on the receiving side.
When RIP receives the update, it determines whether the subnet received in the update
belongs to the same major network as the receiving interface. If so, Router 2 applies the
mask of the receiving interface. If the host bits are set in the host portion of the RIP update,
the receiving router applies the host mask.
If that subnet belongs to a different major network, RIP checks whether any subnets of this
major network already exist in the routing table and determines whether they are known
from interfaces other than the one that received the update. Note that the network in this
update should be a major network. If the answer is “yes,” Router 2 ignores the update. If
the answer is “no,” Router 2 applies a classful mask.
If the update came across an unnumbered link, it might contain subnet information (bits in
the subnet portion of the network address are set). Router 2 then applies a host mask. If the
update carries subnet broadcast—for example, 131.108.5.127/25 or Class D or E—the RIP
update must be ignored.

Example of Sending Updates

This section shows an example explaining RIP behavior when it sends an update. In Figure 2-6,
two routers are running RIP. The link between Router 1 and Router 2 is in 131.108.0.0. The
Ethernet interface on Router 1 is in 131.108.0.0 as well. Router 1 is also connected to another
major network, which is 137.99.0.0.
34 Chapter 2: Understanding Routing Information Protocol (RIP)

Figure 2-5 Flowchart That Explains RIP Rules When Receiving Updates

RIP rules for receiving updates

Do any subnets of this major

Does the subnet received in the Router 2
network already exist in the
update belong to the same major No Yes ignores the
routing table, known from
network as the receiving interface? update.
interfaces other than the one
that received the update?

Yes No

Router 2 applies the mask of the

receiving interface. If the host bit Router 2 applies a classful mask. If the
is set in the host portion of the update came across an unnumbered
RIP update, the receiving router link and contains subnet information
applies the host mask. (bits in thesubnet portion of the
network are set), Router 2 applies
a host mask.

Figure 2-6 An Example of RIP Behavior When Sending and Receiving Updates

131.108.5.0/24
137.99.88.0/24
131.108.3.0/24

.2 131.108.2.0/24
.2 .1
.2 .1
S0
S0
Router 1 Router 2

In Figure 2-6, when Router 1 sends an update to Router 2, it performs these checks:
1 Is 131.108.5.0/24 part of the same major network as 131.108.2.0/24, which is
sourcing the update?
 RIP Behavior 35

2 Yes. Does 131.108.5.0/24 have the same subnet mask 131.108.2.0/24, which is
sourcing the update?
3 Yes. Router 1 advertises the network.

4 Is 137.99.88.0/24 part of the same major network as 131.108.2.0/24, which is

sourcing the update?
5 No. Router 1 summarizes 137.99.88.0/24 at the major network boundary and
advertises the route as 137.99.0.0.
This process results in Router 1 including 131.108.5.0 and 137.99.0.0 in its update
to Router 2. You can see this in the output displayed using the debug ip rip command
on Router 1, as demonstrated in Example 2-1.
Example 2-1 debug ip rip Command Output Reveals RIP Update Information Sent
Router1#debug ip rip
RIP: sending v1 update to 255.255.255.255 via Serial0 (131.108.2.2)
subnet 131.108.5.0, metric 1
network 137.99.0.0, metric 1

Example of Receiving Updates

Example 2-2 provides output from the debug ip rip command to display the routing update
received on Router 2 from Router 1.
Example 2-2 debug ip rip Command Output Reveals RIP Update Information Received
Router2#debug ip rip
RIP: received v1 update from 131.108.2.2 on Serial0
131.108.5.0 in 1 hops
137.99.0.0 in 1 hops

Router 2 in Figure 2-6 performs the following checks to determine what mask to apply on
a received network:
1 Is the received major network 137.99.0.0 the same as 131.108.2.0, which is the
address assigned to the interface that received the update?
2 No. Do any subnets of this major network already exist in the routing table known
from other interfaces?
3 No. Router 2 applies the natural mask (/16) because 137.99.0.0 is a Class B address.
4 Does subnet 131.108.5.0 belong to the same major network as subnet 131.108.2.0,
which is the interface that received the update?
5 Yes. Router 2 applies the mask /24, which is the mask of the interface that received
the update.
36 Chapter 2: Understanding Routing Information Protocol (RIP)

This process results in the networks and masks in Router 2’s routing table, displayed using
the show ip route command (see Example 2-3).
Example 2-3 show ip route Command Output Reveals the Networks and Masks in Router 2’s Routing Table
Router2#show ip route
R 137.99.0.0/16 [120/1] via 131.108.2.2, 00:00:07, Serial0
131.108.0.0/24 is subnetted, 3 subnets
R 131.108.5.0 [120/1] via 131.108.2.2, 00:00:08, Serial0
C 131.108.2.0 is directly connected, Serial0
C 131.108.3.0 is directly connected, Ethernet0

Why RIP Doesn’t Support Discontiguous Networks

A discontiguous network is comprised of a major network separated by another major
network. In Figure 2-7, network 131.108.0.0 is separated by a subnet of network
137.99.0.0; here, 131.108.0.0 is a discontiguous network.
RIP is a classful protocol. Whenever RIP advertises a network across a different major
network boundary, RIP summarizes the advertised network at the major network boundary.
In Figure 2-7, when Router 1 sends an update containing 131.108.5.0 to Router 2 across
137.99.88.0, it converts 131.108.5.0/24 into 131.108.0.0/16. This process is called auto-
summarization.

Figure 2-7 An Example of a Discontiguous Network

131.108.2.0/24
131.108.5.0/24
137.99.88.0/24
.2
.2 .1 .1

Router 1 Router 2

Router 1 takes the following steps before sending an update to Router 2:

1 Is 131.108.5.0/24 part of the same major network as 137.99.88.0/24, which is the
subnet assigned to the interface that’s sourcing the update?
2 No. Router 1 summarizes 131.108.5.0/24 and advertises the route 131.108.0.0/16.
The debug ip rip command output on Router 1 shows the update sent by Router 1, as
demonstrated in Example 2-4.
Example 2-4 debug ip rip Command Output Reveals RIP Update Information Sent by Router 1 in Figure 2-7
Router1#debug ip rip
RIP: sending v1 update to 255.255.255.255 via Serial0 (137.99.88.2)
network 131.108.0.0, metric 1
 Why RIP Doesn’t Support Variable-Length Subnet Masking 37

Router 2 goes through the following steps before accepting the update from Router 1:
1 Is the major network received (131.108.0.0) the same as the major network of
137.99.88.0/24, which is the subnet assigned to the interface that received the update?
2 No. Do any subnets of this major network already exist in the routing table known
from interfaces other than that which received the update?
3 Yes. Router 2 ignores the update.
Again, debug ip rip command output on Router 2 shows the update received by Router 2,
as demonstrated in Example 2-5.
Example 2-5 debug ip rip Command Output Reveals RIP Update Information Received by Router 2 in Figure 2-7
Router2#debug ip rip
RIP: received v1 update from 137.99.88.1 on Serial0
131.108.0.0 in 1 hops

The routing table of Router 2, as demonstrated in the show ip route command output in
Example 2-6, shows that the update was ignored. The only entry for any subnetwork or
network on 131.108.0.0 is the one directly connected to Ethernet0.
Example 2-6 show ip route Command Output Reveals That the Routing Table for Router 2 in Figure 2-7 Does Not
Reflect the Advertised Route Sent by Router 1
137.99.0.0/24 is subnetted, 1 subnets
C 137.99.88.0 is directly connected, Serial0
131.108.0.0/24 is subnetted, 3 subnets
C 131.108.2.0 is directly connected, Ethernet0

To avoid having updates ignored, configure a static route on both routers that points toward
the specific subnets. For example, on Router 1, configure the following:
Router1(config)#ip route 131.108.2.0 255.255.255.0 137.99.88.1

On Router 2, configure the following:

Router2(config)#ip route 131.108.5.0 255.255.255.0 137.99.88.2

Why RIP Doesn’t Support Variable-Length Subnet

Masking
The capability to specify a different subnet mask for the same network number is called
variable-length subnet masking (VLSM). RIP and IGRP are classful protocols and are
incapable of carrying subnet mask information in their updates. Before RIP or IGRP sends
an update, it performs a check against the subnet mask of the network that is about to be
advertised, with the subnet mask of the interface sourcing the update. If the two subnet
masks don’t match, the update gets dropped.
38 Chapter 2: Understanding Routing Information Protocol (RIP)

The following example demonstrates this concept. In Figure 2-8, Router 1 has three subnets
with two different masks (/24 and /30).

Figure 2-8 An Example of a VLSM Network

131.108.7.0/30
131.108.5.0/24
131.108.2.0/30

.2 131.108.6.0/30
.2 .1
.2 .1
S0
S0
Router 1 Router 2

Router 1 goes through the following steps before sending an update to Router 2:
1 Router 1 checks to see if 131.108.5.0/24 is part of the same major network as
131.108.6.0/30, which is the network assigned to the interface that is sourcing the
update.
2 It is part of the same major network, so Router 1 determines whether 131.108.5.0/24
has the same subnet mask as 131.108.6.0/30.
3 Because the subnet masks are not the same, Router 1 drops the network and doesn’t
advertise the route.
4 Router 1 now determines whether 131.108.7.0/30 is part of the same major network
as 131.108.6.0/30, which is the network assigned to the interface that is sourcing the
update.
5 It is part of the same major network, so Router 1 next determines whether
131.108.7.0/30 has the same subnet mask as 131.108.6.0/30.
6 Because the two subnet masks are the same, Router 1 advertises the network.
The preceding procedure determined that Router 1 includes only 131.108.7.0 in its update
that is sent to Router 2. The debug ip rip command in Example 2-7 actually shows the
update sent by Router 1.
Example 2-7 debug ip rip Command Output Reveals RIP Update Information Sent by Router 1 to Router 2, as
Illustrated in Figure 2-8
RIP: sending v1 update to 255.255.255.255 via Serial0 (131.108.6.2)
subnet 131.108.7.0, metric 1

Notice in the output in Example 2-7 that the only subnet included in the update is
131.108.7.0. The subnet 131.108.5.0 is not included because it has a different subnet mask.
 Default Routes and RIP 39

This results in the following entry in Router 2’s routing table displayed by the show ip
route command (see Example 2-8).
Example 2-8 show ip route Command Output Reveals That the Subnet 131.108.5.0/25 Is Missing from Router 2’s
Routing Table
Router2#show ip route
131.108.0.0/30 is subnetted, 3 subnets
R 131.108.7.0 [120/1] via 131.108.2.2, 00:00:08, Serial0
C 131.108.6.0 is directly connected, Serial0
C 131.108.2.0 is directly connected, Ethernet0

To avoid eliminating subnets from routing updates, either use the same subnet mask over
the entire RIP network or use static routes for networks with different subnet masks.

Default Routes and RIP

Cisco’s RIP implementation supports the propagation of a default route, also known as
0.0.0.0/0. When RIP finds a default route in its routing table, it automatically advertises this
in the RIP update.
One important thing to remember here is that the default route must have a valid metric.
For example, if the default route is learned through OSPF and the metric is 20, RIP will
advertise this router with a metric of infinity (16). So, for this situation, the default-metric
command must be used under the router rip command to ensure that the proper metric is
assigned to the update.
Classless and classful IP routing concepts play an important role, especially with default
routes. With classful IP routing, if the router receives a packet destined for a subnet that it
does not recognize and the network default route is missing in the routing table, the router
discards the packet. Figure 2-9 explains this behavior.

Figure 2-9 Classful IP Routing

131.108.1.0/24
R1 will drop packets for
131.108.3.0/24.

0.0.0.0/0

X
131.108.3.0/24

131.108.2.0/24
40 Chapter 2: Understanding Routing Information Protocol (RIP)

Here, Host X is sending traffic to the 131.108.3.0/24 subnet. Router R1 will discard these
packets because it does not have a route for 131.108.3.0/24. Traffic will not be send to the
default route because of the classful nature of routing.
If R1 enables IP classless routing, R1 will forward traffic to the default route.
Enabling IP classless routing is recommended when default network or default routes are used.

Protocol Extension to RIP

RIP Version 2 (RIP-2) made some improvements and enhancements to RIP-1. RIP-2
supports VLSM and discontiguous networks, and it offers the following enhancements:
• Route tag
• Subnet mask
• Next-hop metric
• Multicast capability
• Authentication
Figure 2-10 shows the RIP-2 packet format. The sections that follow discuss each of the
enhancements and new packet fields in greater detail.

Figure 2-10 RIP-2 Packet Format

0 8 16 31
Command Version Route tag

Address family identifier Must be zero

IP address

Subnet mask

Next hop

Metric

Route Tag
The Route Tag field is a 2-byte field that allows RIP routes to be assigned with a unique
integer value. The routing table display shows the route tag for each RIP route, if assigned.
This route tag plays an important role during redistribution with RIP. Any route that is
redistributed into RIP gets tagged, to distinguish between internal RIP information and
external RIP information.
 Protocol Extension to RIP 41

When redistributed routes in RIP are assigned with route tags, it becomes easier to control
redistribution of tagged routes into other protocols. Instead of matching against each route
when redistributing into other protocols, RIP routes can simply be matched against the tag
that they were assigned.
For example, consider that 10 static routes in a router are redistributed in RIP and are
assigned a tag of 20. These static routes will be advertised in RIP as external routes with a
tag of 20. If in some other router RIP is being redistributed into OSPF and OSPF wants only
those 10 static routes to be redistributed, OSPF can simply match the tag information
instead of listing each static route in its redistribution commands. In addition, if OSPF is
being redistributed back into RIP at some other router, RIP should deny any routes that are
tagged with 20. Matching against tags thus avoids IP routing loops as well.

Subnet Mask
Unlike RIP-1, RIP-2 carries subnet mask information along with the IP network number. If
an IP network is variably subnetted, RIP-2 picks the subnet mask of each subnet and adver-
tises to RIP-2 neighbors. RIP-2 routers in the network install routes with their respective
subnets though a variable length of, say, /8, /15/, /24, and so on.
Support of VLSM also enables RIP-2 to understand discontiguous networks. In a discon-
tiguous network, the IP supernet is divided by another IP block. Because RIP-2 can carry
subnet mask information, each RIP-2 router has a route with the actual mask and routers
can forward traffic properly.

Next Hop
The Next Hop field was added to avoid an extra hop during packet forwarding. For those
familiar with OSPF, the Next Hop field holds nearly the same role as the forwarding address
for OSPF external routes.
In Figure 2-11, OSPF is enabled between Router 2 and Router 5. RIP is enabled on Router 2,
Router 3, and all the other routers behind Router 2 and Router 3. Router 2 is doing redis-
tribution between OSPF and RIP. Now when a packet from Router 1 is destined for OSPF
networks and arrives at Router 2, it is forwarded to Router 5.
When a packet from Router 4 destined to the OSPF network arrives at Router 3, if there is
no next-hop information (in case of RIP-1), Router 3 forwards the packet to the originator,
Router 2. Then Router 2 forwards it to Router 5. This is an extra hop that Router 3 must
take to get to the OSPF network. With the Next Hop field in the RIP packet, when a packet
destined to the OSPF network arrives at Router 3, the RIP route for the destination network
has its next hop set to Router 5 instead of Router 2. As a result, Router 3 does not forward
the packet to Router 2—instead, it forwards the packet straight to Router 5.
42 Chapter 2: Understanding Routing Information Protocol (RIP)

Figure 2-11 RIP-2 Packet Format

router rip
version 2
redistribute ospf metric 1
OSPF

Router 2
Router 1
OSPF

Router 5

Router 3
Router 4

Multicast Capability
RIP-2 uses multicast when sending an update to all its neighbors. This reduces unnecessary
broadcast flooding on the wire. The multicast address that RIP-2 uses is 224.0.0.9.
All devices on the wire running RIP-2 listen for RIP-2 multicast packets on 224.0.0.9 at a
multicast MAC address (01-00-5E-00-00-09). Devices not running RIP-2 simply discard
RIP-2 messages on the wire, reducing unnecessary load.

Authentication
RIP-2 supports simple password authentication, to validate trusted RIP-2 neighbors. RIP-2
speakers determine whether authentication is used by looking at the address family identi-
fier (AFI) in RIP-2 packet. AFI in RIP-2 header indicates what kind of addresses are present
in the rest of the packet.
If the AFI value is 0xFFFF, this means that the remainder of the entire RIP packet contains
authentication information.
Figure 2-12 shows the packet format when authentication is used.
 Compatibility Issues 43

Figure 2-12 RIP-2 Packet Format for Authentication

0 8 16 31
Command Version Unused

0xFFFF Authentication type

Authentication

Authentication

Authentication

Authentication

Compatibility Issues
RIP-1 and RIP-2 can be run together in a network. You should be aware of a few things
when running both protocols in your network:
• Autosummarization—RIP-1 and RIP-2 can be run together in a network. RFC 1723
for RIP-2 recommends disabling the autosummarization feature when using both
RIP-1 and RIP-2.
• Subnet advertisement—If a more specific subnet is advertised to a RIP-1 router, the
router might mistakenly take it as a host route update.
• Queries—When a RIP-2 router receives a query request from a RIP-1 router, it
responds with a RIP-1 message. If the router is configured to send only RIP-2
messages, such a query request must be ignored.
• Version field—The Version field in the RIP packet determines how to handle RIP-1
and RIP-2 packets:
— If version = 0 in the RIP packet, the packet is discarded, regardless of what
version the receiving router is running.
— If version = 1 in the RIP packet, all the “must be zero fields” are checked
(refer to Figure 2-9). If the version is nonzero, the packet is discarded,
regardless of what version the receiving router is running.
— If version = 2 in the RIP packet and the receiving router is running RIP-1,
the receiving router should look at only the related information in the
packet. All the “must be zero fields” are ignored.
44 Chapter 2: Understanding Routing Information Protocol (RIP)

Summary
RIP is a distance vector protocol that uses the Bellman-Ford algorithm to compute IP routes
dynamically. RIP is suitable to run in small IP networks because of its hop count limit of 15.
RIP was designed as a simple IP routing protocol that exchanges a complete routing table at
a fixed interval (30 seconds) with other routers running RIP. In larger networks with a large
number of IP routes, sending a complete routing table every 30 seconds is not practical. This
results in extra work for the sender and receiver, and it consumes unnecessary bandwidth and
processing time. Therefore, RIP is used in smaller networks with a hop count of less than 15
and a small number of routes as well.
RIP offers a descent algorithm for loop avoidance by using split horizon and poison reverse.
Split horizon takes care of the loops by not advertising any routes back to the interface
where it learned the routes. Poison reverse causes routes to be advertised with the infinite
RIP metric (16), thus removing RIP routes that might be looped or down.
Because any change in the network takes at least 30 seconds to propagate, the concept of
holddown causes the RIP routing table to wait for three times the advertisement interval.
This implementation is designed for when a RIP route is not advertised because it might
have been down for a little over 30 seconds. The receiving routers should wait for 90
seconds to remove the route from the routing table. If a routes comes back before 90
seconds, it is reinstalled and is advertised throughout the network.
In the early days of IP networking, RIP was the protocol of choice in smaller IP networks.
Since then, a lot of new IP protocols have been developed to be more robust and dynamic
than RIP; they can scale up to a much larger number of routers than 15. The advent of these
new protocols, such as OSPF, IS-IS, and EIGRP, resulted in almost complete phaseout of
RIP from larger networks today. These new protocols have improved upon the limitations
of RIP in terms of convergence and scalability, and they offer the support for VLSM and
discontiguous networks that RIP-1 lacked.
Although RIP-2 improved RIP with new features, such as route tags, queries, subnet masks,
next hops, multicasting, and authentication, larger networks still prefer OSPF, IS-IS, and
EIGRP as IP routing protocols.

Review Questions
1 What is the maximum metric in RIP?
2 Why doesn’t RIP support discontiguous networks?

3 Why doesn’t RIP support VLSM?

4 What is the default update interval for RIP?

5 What transport protocol and port number do RIP use for sending updates?
 Further Reading 45

6 What is the purpose of the split-horizon technique?

7 Does RIP Version 2 solve the discontiguous network problem by default?
8 Does RIP Version 2 also use broadcast for sending updates?
9 Does RIP support authentication?

Further Reading
Refer to the following RFCs for more information about RIP. You can access all RFCs
online at www.isi.edu/in-notes/rfcxxxx.txt, where xxxx is the number of the RFC that you
want to read.
RFC 1058, “Routing Information Protocol”
RFC 1723, “RIP Version 2”
RFC 2453, “RIP Version 2”
RFC 1582, “Extensions to RIP to Support Demand Circuits”
RFC 2091, “Triggered Extensions to RIP to Support Demand Circuits”
RFC 2082, “RIP-2 MD5 Authentication”
This chapter covers the following key topics:
• Troubleshooting RIP routes installation
• Troubleshooting RIP routes advertisement
• Troubleshooting routes summarization in RIP
• Troubleshooting RIP redistribution problems
• Troubleshooting dial-on-demand (DDR) routing issues in RIP
• Troubleshooting route flapping problem in RIP
 CHAPTER
3

Troubleshooting RIP
This chapter discusses some of the common problems in RIP and tells how to resolve those
problems. At this time, no RIP error messages will help troubleshooting RIP problems. As
a result, you will need to rely on debugs, configurations, and useful show commands, which
we’ll provide where necessary in this chapter. The flowcharts that follow document how to
address common problems with RIP with the methodology used in this chapter.
Debugs sometimes can be very CPU-intensive and can cause congestion on your network.
Therefore, we do not recommend turning on these debugs if you have a large network
(that is, more than 100 networks or subnets in RIP). Sometimes, there could be multiple
causes for the same problem—for example, Layer 2 is down, the network statement is
wrong, and the sender is missing the network statement. Bringing up Layer 2 and fixing
the network statement might not fix the network problem because the sender is still
missing the network statement. Therefore, if one scenario doesn’t fix the network prob-
lem, check into other scenarios. The word RIP, in general, refers to both RIP Version 1
(RIP-1) and RIP Version 2 (RIP-2). The problems discussed in this chapter are mostly
related to RIP-1, unless specified as RIP-2.
48 Chapter 3: Troubleshooting RIP

Flowcharts to Solve Common RIP Problems

Troubleshooting RIP Routes Installation

RIP Routes Not in the Routing Table

Not sure
Is RIP enabled on the interface? Go to page 53.

Yes

Is the interface of the receiving Not sure

Go to page 56.
router up/up?

Yes

Is the distribute-list in Not sure

Go to page 58.
blocking the routes?

No

Is the access list blocking the RIP source Not sure

Go to page 60.
address?

No

Is the access list blocking the RIP broadcast? Not sure

Go to page 63.

No

Is the RIP version compatible with the sender? Not sure Go to page 65.

Yes

Is there an authentication mismatch between Not sure

Go to page 68.
sender and receiver?

No

Not sure
Is this a discontiguous subnet? Go to page 71.

No

Not sure
Is the RIP update coming from a valid source?
Go to page 74.

Yes

Is Layer 2 media propagating RIP broadcast/ Not sure

Go to page 76.
multicast?

Yes

Is an offset list configured on the sender or Not sure

Go to page 79.
receiver?

No

Not sure
Is the network more than 15 hops away? Go to page 81.

No

Go to next problem flowchart. TN01

 Flowcharts to Solve Common RIP Problems 49

Troubleshooting RIP Routes Installation

RIP Is Not Installing All Possible Equal Paths

Not sure
Are there more than four possible paths? Go to page 83.

No

Go to next problem flowchart.

Troubleshooting RIP Route Advertisement

Sender Is Not Advertising RIP Routes

Is RIP enabled on the interface? Not sure Go to page 87.

Yes

Not sure
Is the outgoing interface up/up? Go to page 89.

Yes

Is distribute-list out blocking the routes? Not sure

Go to page 91.

No

Not sure
Is the advertised network interface up/up? Go to page 93.

Yes

Not sure
Is the outgoing interface defined as passive? Go to page 95.

No

Not sure
Is the multicast capability broken? Go to page 96.

No

Is the neighbor statement configured Not sure

Go to page 99.
properly?

Yes

Not sure
Is the advertised subnet using VLSM? Go to page 100.

No

Is split horizon enabled on the interface? Not sure

Go to page 102.

No

Go to next problem flowchart.

50 Chapter 3: Troubleshooting RIP

Troubleshooting RIP Route Advertisement

Subnetted Routes Missing from the Routing Table

Not sure
Is the autosummarization feature enabled? Go to page 106.

No

Go to next problem flowchart.

Troubleshooting Route Summarization in RIP

RIP-2 Routing Table Is Huge

Not sure
Is autosummarization turned off? Go to page 109.

No

Is the ip summary-address command Not sure

Go to page 111.
configured?

Yes

Go to next problem flowchart.

Troubleshooting RIP Redistribution Problems

Redistributed RIP Routes Are Not in the
Routing Table of R2

Is the default metric defined on the Not sure

redistribution router? Go to page 113.

No

Go to next problem flowchart.

 Flowcharts to Solve Common RIP Problems 51

Troubleshooting Dial-on-Demand Routing Issues in RIP

RIP Updates Are Keeping the ISDN Link Up

Are RIP broadcasts permitted as interesting Not sure Go to page 117.

traffic?

No

Go to next problem flowchart.

RIP Updates Are Not Going Across the Dialer Interface

Is the broadcast keyword missing from the Not sure

Go to page 120.
dialer map statement?

No

Go to next problem flowchart.

Troubleshooting Route Flapping Problems in RIP

RIP Routes Are Flapping

Are there a large number of packet drops

Not sure
being reported by router interfaces in the Go to page 122.
network?

No

End of chapter problems.

52 Chapter 3: Troubleshooting RIP

Troubleshooting RIP Routes Installation

This section discusses several possible scenarios that can prevent RIP routes from getting
installed in the routing table. This section is selected first in the troubleshooting list because
the most common problem in RIP is that routes are not installed in the routing table.
If the routes are not installed in the routing table, the router will not forward the packets to
destinations that are not in the routing table. When this happens, it creates reachability
problems. Users start complaining that they cannot reach a server or a printer. When you
investigate this problem, the first thing to ask is, “Do I have a route for this destination that
users are complaining about?”
Three possibilities exist for routes not getting installed in the routing table:
• Receiver’s problem—The router is receiving RIP updates but is not installing the
RIP routes.
• Intermediate media problem (Layer 2)—Mostly related to Layer 2, the sender has
sent the RIP updates, but they got lost in the middle and the receiver didn’t receive
them.
• Sender’s problem—The sender is not even advertising RIP routes, so the receiving
side is not seeing any RIP routes in the routing table.
The sender’s problem will be discussed in the section “Troubleshooting RIP Route
Advertisement.” Two problems are related to RIP installation:
• RIP routes are not in the routing table.
• RIP is not installing all equal-cost path routes.
In the first problem, RIP is not installing any path to a specific network. In the second
problem, RIP is not installing all paths to the network. Note that, in the second problem, the
destination device is still reachable, but it’s not listing all possible paths.

Problem: RIP Routes Not in the Routing Table

The routing table must have a network entry to send the packets to the desired destination.
If there is no entry for the specific destination, the router will discard all the packets for this
destination.
Example 3-1 shows that the routing table of R2 doesn’t hold an entry for network
131.108.2.0.
Example 3-1 Routing Table for R2 Shows No RIP Routes for Subnet 131.108.2.0
R2#show ip route 131.108.2.0
% Subnet not in table
R2#
 Problem: RIP Routes Not in the Routing Table 53

The possible causes for this problem are as follows:

• Missing or incorrect network statement
• Layer 2 down
• Distribute list blocking the route
• Access list blocking RIP source address
• Access list blocking RIP broadcast/multicast
• Incompatible version type
• Mismatch authentication key (RIP-2)
• Discontiguous network
• Invalid source
• Layer 2 problem (switch, Frame Relay, other Layer 2 media)
• Offset list with a large metric defined
• Routes that reached RIP hop-count limit
• Sender problem (discussed in the next chapter)
Figure 3-1 provides a network scenario that will be used as the basis for troubleshooting a
majority of the aforementioned causes of the problem of RIP routes not in the routing table.
The sections that follow carefully dissect how to troubleshoot this problem based on
specific causes.
Figure 3-1 shows a setup in which Router 1 and Router 2 are running RIP between them.
Figure 3-1 Example Topology for the Problem of RIP Routes Not in the Routing Table

131.108.2.0/24 .1 131.108.1.0/24 131.108.3.0/24

.2
E0 E0
Router 1 Router 2

RIP Routes Not in the Routing Table—Cause: Missing or Incorrect

network Statement
When you confirm that the route is missing from the routing table, the next step is to find out
why. A route can be missing from the routing table for many reasons. The flowcharts at the
beginning of this chapter can help isolate the cause that seems to fit most in your situation.
The obvious thing to check after discovering that the routes are not in the routing table is
the router’s configurations. Also check to see whether the network statement under router
rip is properly configured.
54 Chapter 3: Troubleshooting RIP

When the network statement is configured, it does two things:

• Enables RIP on the interface and activates the capability to send and receive RIP
updates
• Advertises that network in a RIP update packet
If the network statement under router rip command is not configured or misconfigured, it
can cause this problem.
Figure 3-2 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-2 Problem Resolution Flowchart

RIP routes are not in the routing table of R2.

RIP must be enabled on

the interface to send and
receive RIP updates. Go
Is RIP enabled on the Not sure to “Debugs and Verification”
interface?
section.

Yes

Go to
next
cause.

Debugs and Verification

Example 3-2 shows the configuration for Router R2 (as illustrated in Figure 3-1). The loop-
back interface is used in this example and many other examples throughout the chapter. If
the loopback interface is replaced with any other interface, it will not change the meaning.
We suggest that you treat the loopback as any interface that is up and functional and that
has a valid IP address.
Example 3-2 Configuration for Router R2 from Figure 3-1
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router rip
network 131.107.0.0
!

Refer back to Figure 3-1 and compare it to the configuration for R2 in Example 3-2. You
notice that network 131.108.0.0 is missing from R2’s configurations.
 Problem: RIP Routes Not in the Routing Table 55

Example 3-3 shows the output of the show ip protocols command on R2. This output shows
that the routing information source is also not displaying 131.108.1.1 as a gateway.
Example 3-3 show ip protocols Missing Gateway Information for Routing Information Source
R2#show ip protocols

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 11 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Automatic network summarization is in effect
Routing for Networks:
131.107.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)

Debug Commands
Example 3-4 shows the debug ip rip output. In this debug, R2 is ignoring the RIP updates
coming from R1 because RIP is not enabled on Ethernet 0. This is because of the lack of a
network statement for 131.108.0.0 under router rip in the router configuration mode.
Example 3-4 debug ip rip Command Output Displays That RIP Updates from Router R1 Are Being Ignored
R2#debug ip rip
RIP protocol debugging is on
R2#
RIP: ignored v1 packet from 131.108.1.1 (not enabled on Ethernet0)
R2#

Solution
Because the network statement is missing on Router 2, as shown in Example 3-2, it ignores
RIP updates arriving on its Ethernet 0 interface, as seen in the debug output in Example 3-4.
This problem can also happen if incorrect network statements are configured. Take a Class C
address, for example. Instead of configuring 209.1.1.0, you configure 209.1.0.0, assuming that
0 will cover anything in the third octet. RIP-1 is a classful protocol, and it assumes the classful
network statements. If a cidr statement is configured instead, RIP will not function properly.
To correct this problem, you must add the network statement in the configurations.
Example 3-5 shows the new configuration for Router R2 that solves this problem.
Example 3-5 New Configuration of R2 That Solves the Problem
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
continues
56 Chapter 3: Troubleshooting RIP

Example 3-5 New Configuration of R2 That Solves the Problem (Continued)

!
router rip
network 131.107.0.0
network 131.108.0.0

Example 3-6 shows the output of show ip protocols on R2. This output displays the
gateway information now.
Example 3-6 show ip protocols Showing Gateway Set to the R1’s Interface IP Address
R2#show ip protocols

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 12 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0 1 1 2
Loopback0 1 1 2
Automatic network summarization is in effect
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
131.108.1.1 120 00:00:09
Distance: (default is 120)

Example 3-7 shows the output of show ip route, which shows that Router R2 is learning
the RIP route after the configuration change.
Example 3-7 show ip route Displays the Route Being Learned After Fixing the Problem
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:11 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:11 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Layer 1/2 Is Down

One cause for routes not in the routing table is Layers 1 or 2 being down. If Layers 1
or 2 are down, it’s not a RIP problem. The following is a list of the most common things
to check if the interface or line protocol is down:
• Unplugged cable
• Loose cable
 Problem: RIP Routes Not in the Routing Table 57

• Bad cable
• Bad transceiver
• Bad port
• Bad interface card
• Layer 2 problem at telco, in case of a WAN link
• Missing clock statement, in case of back-to-back serial connection
Figure 3-3 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-3 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

RIP will not receive any

Is the interface of the receiving Not sure routing updates if Layer1/ 2
router up/up? is down. Go to “Debugs and
Verification” section.

Yes

Go to
next
cause.

Debugs and Verification

Example 3-8 shows that the Ethernet interface’s line protocol is down, indicating that
something is wrong at Layer 1 or Layer 2.
Example 3-8 show interface output Displays That the Line Protocol Is Down
R2#show interface ethernet 0
Ethernet0 is up, line protocol is down
Hardware is Lance, address is 0000.0c70.d41e (bia 0000.0c70.d41e)
Internet address is 131.108.1.2/24

Debugs
Example 3-9 shows the output of debug ip rip. In this debug, R2 is not sending or receiving
any RIP updates because Layer 2 is down.
Example 3-9 debug ip rip Command Output Shows Nothing Is Being Sent
R2#debug ip rip
RIP protocol debugging is on
R2#
58 Chapter 3: Troubleshooting RIP

Solution
RIP runs above Layer 2. RIP cannot send or receive any routes if Layer 2 is down.
The Layer 2 problem must be fixed. Sometimes, the problem could be as simple as loose cables,
or it could be as complex as bad hardware; in which case, the hardware must be replaced.
Example 3-10 shows the output of show interface Ethernet 0 on R2 after the Layer 2
problem is fixed. The output shows that the line protocol is now up.
Example 3-10 show interface Output After Fixing the Layer 1/2 Problem Shows the Interface Ethernet0 Is Now Up
R2#show interface Ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c70.d41e (bia 0000.0c70.d41e)
Internet address is 131.108.1.2/24

Example 3-11 shows the output of show ip route, which illustrates that the RIP route is
being learned after fixing the Layer 1/2 problem.
Example 3-11 Routing Table Entry After Fixing the Layer 1/2 Problem
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: distribute-list in Is

Blocking the Route
A distribute list is a filtering mechanism for routing updates. The distribute list calls an
access list and checks to see which networks are supposed to be permitted. If the access list
doesn’t contain any network, the routing update will be automatically denied. A distribute
list can be applied on either incoming routing updates or outgoing routing updates.
In this example, the distribute-list in is configured; however, the access list doesn’t contain
the permit statement for 131.108.0.0, so R2 is not installing these routes in the routing table.
Figure 3-4 shows the flowchart to follow to solve this problem based on this cause.

Debugs and Verification

Example 3-12 shows the current configuration of Router R2. In this configuration,
access-list 1 is used to permit network 131.107.0.0; however, there is an implicit deny at
the end of every access list, so 131.108.0.0 will also be denied. In the access list
configuration, network 131.108.0.0 is not permitted, so the router is not installing any
subnets of the 131.108.0.0 network.
 Problem: RIP Routes Not in the Routing Table 59

Figure 3-4 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

Make sure the distribute-

Is the distribute-list in list in permits the network
Not sure you want to receive an RIP
blocking the routes?
update. Go to “Debugs and
Verification” section.
No

Go to
next
cause.

Example 3-12 R2’s Configuration Shows That Network 131.108.0.0 Is Being Blocked with an Implicit deny Under
access-list 1
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router rip
network 131.108.0.0
distribute-list 1 in
!
access-list 1 permit 131.107.0.0 0.0.255.255

Solution
When a distribute list is used, you should always double-check your access list to make sure
that the networks that are supposed to be permitted actually are permitted in the access list.
The access list in Example 3-12 permits only 131.107.0.0 and denies everything else
because there is an implicit deny at the end of each access list. To fix this problem, permit
131.108.0.0 in access-list 1.
Example 3-13 shows the new configuration of Router R2 with the access list to permit
131.108.0.0.
Example 3-13 Correcting the Configuration on R2 to Fix the Problem
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
continues
60 Chapter 3: Troubleshooting RIP

Example 3-13 Correcting the Configuration on R2 to Fix the Problem (Continued)

ip address 131.108.1.2 255.255.255.0
!
router rip
network 131.108.0.0
distribute-list 1 in
!
access-list 1 permit 131.107.0.0 0.0.255.255
access-list 1 permit 131.108.0.0 0.0.255.255

Example 3-14 shows that Router R2 is learning RIP routes after the configuration change.
Example 3-14 R2 Routing Table Is Learning the RIP Routes After the Correction
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Access List Blocking

RIP Source Address
Access lists are used to filter the traffic based on the source address. Extended access lists
are used to filter the traffic based on the source or destination address, T-2. To filter the
incoming and outgoing traffic, these access lists may be applied on the interface with this
interface-level command:
ip access-group access-list number {in | out}

When the access list is applied in a RIP environment, always make sure that it doesn’t
block the source address of the RIP update. In this example, R2 is not installing RIP
routes in the routing table because access-list 1 is not permitting the source address of
RIP updates from R1.
Figure 3-5 shows the flowchart to follow to solve the problem based on this cause.

Debugs and Verification

Example 3-15 shows the current configuration of router R2. The access list in R2 is
not permitting the source address of RIP updates, that is, 131.108.1.1. In Figure 3-1,
131.108.1.1 is the source address of R1 RIP updates. Because there is an implicit deny
at the end of each access list, 131.108.1.1 will be automatically denied.
 Problem: RIP Routes Not in the Routing Table 61

Figure 3-5 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

If the source address is not

permitted in the input access
Is the access list blocking the Not sure list, RIP will not install any
RIP source address? routes. Go to “Debugs and
Verification” section.

No

Go to
next
cause.

Example 3-15 access-list 1 Is Not Permitting the Source Address

R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 1 in
!
router rip
network 131.108.0.0
!
access-list 1 permit 131.107.0.0 0.0.255.255

Debugs
The output of debug ip rip in Example 3-16 shows that RIP is only sending the updates,
not receiving anything, because the source address 131.108.1.1 is not permitted in the input
access list of R2.
Example 3-16 debug ip rip Output Reveals That R2 Is Not Receiving Any RIP Updates
R2#debug ip rip
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.2)
RIP: build update entries
subnet 131.108.3.0 metric 1
RIP: sending v1 update to 255.255.255.255 via Loopback0 (131.108.3.1)
RIP: build update entries
subnet 131.108.1.0 metric 1RIP: sending v1 update to 255.255.255.255 via
Ethernet0 (131.108.1.2)
RIP: build update entries
subnet 131.108.3.0 metric 1
continues
62 Chapter 3: Troubleshooting RIP

Example 3-16 debug ip rip Output Reveals That R2 Is Not Receiving Any RIP Updates (Continued)
RIP: sending v1 update to 255.255.255.255 via Loopback0 (131.108.3.1)
RIP: build update entries
subnet 131.108.1.0 metric 1
R2#

Solution
The standard access list specifies the source address. In this case, the source address is
131.108.1.1, which is the sending interface address of R1. This source address is not
permitted in the standard access list of R2, so RIP routes will not get installed in the routing
table of R2. To solve this problem, permit the source address in access list 1.
Example 3-17 shows the new configuration change to fix this problem.
Example 3-17 The Modified Access List Permits the Source Address
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 1 in
!
router rip
network 131.108.0.0
!
access-list 1 permit 131.107.0.0 0.0.255.255
access-list 1 permit 131.108.1.1 0.0.0.0

This problem can also happen when using extended access lists if the RIP source address
is not permitted in the access list. This solution also can be used in the case of an extended
access list. The idea here is to permit the source address of RIP update.
Example 3-18 shows the configuration with an extended access list.
Example 3-18 The Correct Extended Access List Configuration, if Used
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 100 in
!
router rip
network 131.108.0.0
!
access-list 100 permit ip 131.107.0.0 0.0.255.255 any
access-list 100 permit ip host 131.108.1.1 any

Example 3-19 shows the routing table of Router R2, which shows that it has learning RIP
routes after the configuration change.
 Problem: RIP Routes Not in the Routing Table 63

Example 3-19 R2 Is Receiving RIP Routes After Fixing the Access List Configuration
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Access List Blocking

RIP Broadcast or Multicast (in Case of RIP-2)
Access lists are used to filter certain types of packets. When using access lists on the interface
inbound, always make sure that they are not blocking the RIP broadcast or UDP port 520,
which is used by RIP-1 and RIP-2 (or the RIP multicast address, in cases of RIP-2).
If these addresses are not permitted in the access list that is applied on the interface inbound,
RIP will not install any routes in the routing table learned on that interface.
Figure 3-6 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-6 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

RIP sends the update on

the broadcast address of
255.255.255.255. In the
case of RIP-2, the update
Is the access list blocking Not sure is sent on 224.0.0.9. These
the RIP broadcast? destination addresses must
be permitted in the input
access list. Go to “Debugs
and Verification” section.
No

Go to
next
cause.

Debugs and Verification

Example 3-20 shows the current configuration of R2. In this configuration, RIP’s des-
tination address of 255.255.255.255 is not being permitted. This will result in no RIP
routes being installed in R2’s routing table. The RIP updates sent from R1 to the destination
of 255.255.255.255 will be blocked by R2.
64 Chapter 3: Troubleshooting RIP

Example 3-20 R2 Configuration Does Not Permit RIP-1 Broadcast Addresses

R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 100 in
!
router rip
network 131.108.0.0
!
access-list 100 permit ip 131.107.0.0 0.0.255.255 any
access-list 100 permit ip host 131.108.1.1 host 131.108.1.2

Solution
RIP-1 broadcasts its routing updates on 255.255.255.255. This address must be permitted
in the input access list of the receiving router so that it can receive the RIP updates.
Example 3-21 shows the new configuration for Router R2. access-list 100 is modified so
that it can permit the RIP broadcast address that was being blocked before.
Example 3-21 Configuring Router R2’s Input Access List to Accept RIP-1 Broadcasts
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 100 in
!
router rip
network 131.108.0.0
!
access-list 100 permit ip 131.107.0.0 0.0.255.255 any
access-list 100 permit ip host 131.108.1.1 host 131.108.1.2
access-list 100 permit ip host 131.108.1.1 host 255.255.255.255

In cases of RIP-2, the configuration will change slightly. The multicast address needs to be
permitted instead of the broadcast address, as shown in Example 3-22.
Example 3-22 Configuring Router R2’s Input Access List to Accept RIP-2 Multicast
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 100 in
!
router rip
version 2
network 131.108.0.0
!
access-list 100 permit ip 131.107.0.0 0.0.255.255 any
access-list 100 permit ip host 131.108.1.1 host 131.108.1.2
access-list 100 permit ip host 131.108.1.1 host 224.0.0.9
 Problem: RIP Routes Not in the Routing Table 65

Example 3-23 shows the routing table of R2 after correcting the problem.
Example 3-23 R2 Routing Table After Correcting the Access List Shows That the RIP Routes Are Being Learned
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Incompatible RIP

Version Type
When RIP is configured on a router, it is run by default as Version 1, which means that all
its interfaces will send and receive RIP-1 packets only. To run Version 2 of RIP, you must
add the version 2 line under router rip. When a router running Version 1 receives a RIP
update from a router running Version 2, it ignores the updates and does not install any routes
in the routing table. For a router to accept a Version 2 packet, the interface must be con-
figured to accept the RIP-2 updates.
Figure 3-7 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-7 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

RIP-1 can understand only

Version 1 packets. If the
router running RIP-1
Is the RIP version compatible Not sure receives Version 2 packets,
with the sender? it will ignore the update.
Go to “Debugs and
Verification” section.
Yes

Go to
next
cause.

Debugs and Verification

Example 3-24 shows the configuration of Router R2. In this configuration, RIP is
configured to send and receive Version 1 packets only.
66 Chapter 3: Troubleshooting RIP

Example 3-24 R2 Configuration Shows That It Is Configured for RIP-1, Which Is the Default
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router rip
network 131.108.0.0
!

Example 3-25 shows the output of the debug ip rip command. This command reveals that
R2 is receiving a RIP packet from R1, which is configured to send Version 2 updates.
Example 3-25 debug ip rip Command Output Shows the Version Incompatible Message on R2
R2#debug ip rip
RIP protocol debugging is on
RIP: ignored v2 packet from 131.108.1.1 (illegal version)

Example 3-26 shows the output of the show ip protocols command, which indicates that
the Ethernet0 interface is sending and receiving RIP-1 packets. This means that if a
Version 2 packet is received on Ethernet 0 of R2, it will be ignored because the interface
can send and receive only Version 1 packets.
Example 3-26 show ip protocols Command Output Reveals the RIP Sends Out and Receives Only RIP
Version 1 Packets on Ethernet0
R2#show ip protocols

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 9 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive version 1
Interface Send Recv Key-chain
Ethernet0 1 1
Loopback0 1 1
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
131.108.1.1 120 00:01:34
Distance: (default is 120)
R2#

Example 3-27 shows the configuration of R1. This shows that sender R1 is configured to
send Version 2 packets. The command version 2 enables a router to send and accept only
RIP-2 packets.
 Problem: RIP Routes Not in the Routing Table 67

Example 3-27 R1’s Configuration Reveals That It Is Configured for RIP Version 2 Packets
R1#
router rip
version 2
network 131.108.0.0

Example 3-28 shows the output of the show ip protocols command, which shows that the
sender R1 is sending and receiving only Version 2 packets. This is because of the version 2
command that is configured under router rip.
Example 3-28 show ip protocols Command Output Reveals That R1 Is Sending and Receiving Only RIP Version
2 Packets
R1#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 13 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Key-chain
Ethernet0/1 2 2
Loopback1 2 2
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
131.108.1.2 120 00:04:09
Distance: (default is 120)

Solution
If the receiver R2 is configured to receive only RIP Version 1 packets, it will ignore the RIP
Version 2 updates. You must configure Router R1 on the sender’s side so that it will send
both Version 1 and Version 2 packets. When R2 receives the Version 1 packet, it will install the
routes in the routing table. R2 will ignore RIP-2 packets because it is configured for RIP-1.
Example 3-29 shows the new configuration for R1. In this configuration, the sender (R1’s
Ethernet interface) is configured to send and receive both RIP-1 and RIP-2 packets.
Example 3-29 New Configuration of R1 to Send and Receive Version 1 and Version 2 Packets
R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
ip rip send version 1 2
ip rip receive version 1 2
continues
68 Chapter 3: Troubleshooting RIP

Example 3-29 New Configuration of R1 to Send and Receive Version 1 and Version 2 Packets (Continued)
!
router rip
version 2
network 131.108.0.0

Example 3-30 shows the output of show ip protocols, which indicates that the Ethernet0
interface is sending and receiving Version 1 and Version 2 packets. The advantage of send-
ing both Version 1 and Version 2 updates is that, if any devices on this Ethernet segment are
running Version 1 only or Version 2 only, those devices will be capable of communicating
with R1 on Ethernet.
Example 3-30 show ip protocols Command Output Reveals the RIP Version 1 and 2 Packets Being Sent and
Received by R1’s Ethernet0 Interface
R1#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 4 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Key-chain
Ethernet0 1 2 1 2
Loopback0 2 2
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
131.108.1.2 120 00:00:07
Distance: (default is 120)
R1#

Example 3-31 shows R2’s routing table after the configuration change.
Example 3-31 R2 Routing Table After R1 Is Configured to Send and Receive RIP-1 and RIP-2 Packets
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Mismatch

Authentication Key (RIP-2)
One of the options in RIP-2 is that the RIP-2 updates can be authenticated for increased
security. When authentication is used, a password must be configured on both sides. This
 Problem: RIP Routes Not in the Routing Table 69

password is called the authentication key. If this key does not match with the key on the
other side, the RIP-2 updates will be ignored on both sides.
Figure 3-8 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-8 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

If the authentication is
configured, make sure that
Is there an authentication the same key is configured
mismatch between sender Not sure
on both the sender and
and receiver? the receiver. Go to “Debugs
and Verification” section.

No

Go to
next
cause.

Debugs and Verification

Example 3-32 shows the configurations of routers R1 and R2 when this problem happens.
In this configuration, a different RIP authentication key is configured on R1 and R2. The
R2 Ethernet interface is configured with the key cisco1, whereas R1 is configured with
the key Cisco. These two keys do not match, so they ignore each other’s update and routes
will not be installed in the routing table.
Example 3-32 Configurations for R1 and R2 Show That Different Authentication Keys Are Configured
on Each Side
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip rip authentication key-chain cisco1
!
router rip
version 2
network 131.108.0.0
!

continues
70 Chapter 3: Troubleshooting RIP

Example 3-32 Configurations for R1 and R2 Show That Different Authentication Keys Are Configured
on Each Side (Continued)

R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
ip rip authentication key-chain cisco
!
router rip
version 2
network 131.108.0.0
!

Example 3-33 shows the output from the debug ip rip command on R2 that indicates that
R2 is receiving a RIP packet that has invalid authentication. This means that the authen-
tication key between sender and receiver doesn’t match.
Example 3-33 debug ip rip Command Output Reveals Invalid Authentication for a RIP-2 Packet Received on R2
R2#debug ip rip
RIP protocol debugging is on
RIP: ignored v2 packet from 131.108.1.1 (invalid authentication)

Solution
When using authentication in RIP, make sure that the sender and the receiver are configured
with the same authentication key. Sometimes, adding a space at the end of the key can cause
the invalid authentication problem because a space will be taken as a literal key entry. As
a result, this causes a problem that cannot be corrected just by looking at the configurations.
Debugs will show that there is a problem with the authentication key. To solve this problem,
configure the same keys on both sender and receiver, or retype the authentication key,
making sure that no space is being added at the end.
Example 3-34 shows the new configuration to correct this problem. The authentication key
is reconfigured on Router R2 to match Router the key on R1.
Example 3-34 R2 Configuration with the Corrected Authentication Key
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip rip authentication key-chain cisco

!
router rip
version 2
network 131.108.0.0
!
 Problem: RIP Routes Not in the Routing Table 71

Example 3-35 shows the routing table of R2 after the configuration change.
Example 3-35 R2 Routing Table After Reconfiguring the Authentication Key on R2
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Discontiguous Network

When a major network is separated by another major network in the middle, this is called
a discontiguous network. Chapter 2, “Understanding Routing Information Protocol (RIP),”
provides a detailed explanation of why RIP does not support discontiguous networks.
Enabling RIP with this topology causes problems.
Figure 3-9 shows an example of a discontiguous network that exists when a major network
is separated by another major network.
Figure 3-9 An Example of a Discontiguous Network

137.99.2.0/24 .1 131.108.1.0/24 137.99.3.0/24

.2
E0 E0
Router 1 Router 2

Figure 3-10 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-10 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

If RIP receives a
summarized route for a
discontiguous network,
Is this a discontiguous subnet? Not sure it will not install it in the
routing table. Go to
“Debugs and Verification”
section.

No

Go to
next
cause.
72 Chapter 3: Troubleshooting RIP

Debugs and Verification

Example 3-36 shows the configuration of Router R1 and Router R2. RIP is enabled on the
Ethernet interfaces of R1 and R2 with the correct network statement.
Example 3-36 Configuration of R1 and R2 in a Discontiguous Network Environment
R2#
interface Loopback0
ip address 137.99.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router rip
network 131.108.0.0
network 137.99.0.0
!

R1#
interface Loopback0
ip address 137.99.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router rip
network 131.108.0.0
network 137.99.0.0
!

Example 3-37 shows the debug ip rip output for routers R1 and R2. Both debugs shows
that the network 137.99.0.0 is being sent across.
Example 3-37 debug ip rip Output Showing That Both Routers Are Sending Summarized Major Network
Addresses Across
R2#debug ip rip
RIP protocol debugging is on
RIP: received v1 update from 131.108.1.1 on Ethernet0
137.99.0.0 in 1 hops
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.2)
RIP: build update entries
network 137.99.0.0 metric 1
R2#

R1#debug ip rip
RIP protocol debugging is on
R1#
RIP: received v1 update from 131.108.1.2 on Ethernet0
137.99.0.0 in 1 hops
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.1)
RIP: build update entries
network 137.99.0.0 metric 1

As a result, both routers will ignore the 137.99.0.0 update from each other. Because R1 and
R2 are already connected to this major network, they will ignore the update.
 Problem: RIP Routes Not in the Routing Table 73

Solution
RIP is not installing the route 137.99.0.0 in the routing table because RIP doesn’t support
discontiguous networks, as discussed in the beginning of the chapter. Several solutions to
this problem exist. The quick solution is to configure a static route to the more specific
subnets of 137.99.0.0 on each router. The second solution is to enable Version 2 of RIP.
Another solution is to replace RIP with another IP routing protocol, such as OSPF, IS-IS,
EIGRP, and so on, that supports discontiguous networks.
Example 3-38 shows the configuration change that is required for both Router R1 and
Router R2 to fix the problem. This configuration adds the static route for the discontiguous
subnets. Because you cannot pass the subnet information across in case of discontiguous
networks in RIP-1, the only solution is to patch it with static routes.
Example 3-38 Static Route Configuration Should Solve This Problem
R1#
interface Loopback0
ip address 137.99.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router rip
network 131.108.0.0
network 137.99.0.0
!
ip route 137.99.3.0 255.255.255.0 131.108.1.2

R2#
interface Loopback0
ip address 137.99.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router rip
network 131.108.0.0
network 137.99.0.0
!
ip route 137.99.2.0 255.255.255.0 131.108.1.1

Example 3-39 shows the alternate solution to fix this problem, in the case of RIP-2. The
solution is to run RIP-2 with no auto-summary configured. With the no-auto summary
command added, RIP-2 will not autosummarize when crossing a major network boundary.
The specific subnet information will be sent across.
Example 3-39 Configuration That Works Under RIP-2 in a Discontiguous Network Environment
router rip
version 2
network 131.108.0.0
network 137.99.0.0
no auto-summary
74 Chapter 3: Troubleshooting RIP

Example 3-40 shows the routing table of R2 after fixing this problem.
Example 3-40 R2 Routing Table Shows That 137.99.2.0/24 Is Learned Through RIP-2 After Configuring the no-
auto summary Command
R2#show ip route 137.99.2.0
Routing entry for 13799.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Invalid Source

When RIP tells the routing table to install the route, it performs a source-validity
check. If the source is not on the same subnet as the local interface, RIP ignores
the update and does not install routes in the routing table coming from this source
address.
Figure 3-11 shows the network diagram for invalid source problem.
Figure 3-11 Network Diagram for Invalid Route Source

137.99.2.0/24 unnumbered loop 0 131.108.1.2/24 137.99.3.0/24

S0
Router 1 Router 2

In Figure 3-11, Router 1’s Serial 0 interface is unnumbered to Loopback 0. Router 2’s serial
interface is numbered. When Router 2 receives a RIP update from Router 1, it complains
about the source validity because the source address is not on the same subnet as Router 2’s
Serial 0 interface.
Figure 3-12 shows the flowchart to follow to solve this problem based on this cause.

Debugs and Verification

Example 3-41 shows the configuration of both Router R2 and Router R1. In this config-
uration, R1’s Serial 0 interface is unnumbered to Loopback 0. R2’s Serial 0 interface is
numbered.
 Problem: RIP Routes Not in the Routing Table 75

Figure 3-12 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

RIP performs a source

validity check before route
installation. In the case
where one side is
Is the RIP update coming from Not sure numbered and the other
a valid source? side is unnumbered, the
source validity check must
be turned off. Go to
“Debugs and Verification”
Yes section.

Go to
next
cause.

Example 3-41 Configuration of R2 and R1 Showing That R1’s Serial 0 Interface Is Unnumbered and R2’s Isn’t
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Serial0
ip address 131.108.1.2 255.255.255.0
!
router rip
network 131.108.0.0
!

R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Serial0
ip unnumbered Loopback0
!
router rip
network 131.108.0.0
!

The debug ip rip output in Example 3-42 shows that R2 is ignoring the RIP update
from R1 because of a source validity check. The RIP update coming from R1 is not on
the same subnet, so R2 will not install any routes in the routing table.
Example 3-42 debug ip rip Message Shows That R2 Is Receiving RIP Updates from a Different Source Address
Than Its Own Interface
R2#debug ip rip
RIP protocol debugging is on
RIP: ignored v1 update from bad source 131.108.2.1 on Serial0
R2#
76 Chapter 3: Troubleshooting RIP

Solution
When one side is numbered and the other side is unnumbered, this check must be turned
off. This is usually the case in a dialup situation when remotes are dialing into an access
router. The access router’s dialup interface is unnumbered, and all remote routers get an IP
address assigned on their dialup interfaces.
Example 3-43 shows the new configuration change on Router R2 to fix this problem.
Example 3-43 Configuration of R2 to Turn Off the Source Validity Check
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Serial0
ip address 131.108.1.2 255.255.255.0
!
router rip
no validate-update-source
network 131.108.0.0
!

Example 3-44 shows that after changing the configurations of R2, the route gets installed
in the routing table.
Example 3-44 R2 Routing Table After Turning Off Source Validity Check
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 00:00:01 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago
Route metric is 1, traffic share count is 1

RIP Routes Not in the Routing Table—Cause: Layer 2 Problem

(Switch, Frame Relay, Other Layer 2 Media)
Sometimes, multicast/broadcast capability is broken at Layer 2, which further affects
Layer 3 multicast. As a result, RIP fails to work properly. The Layer 3 broadcast/multicast
is further converted into Layer 2 broadcast/multicast. If Layer 2 has problems in handling
Layer 2 multicast/broadcast, the RIP updates will not be propagated. The debugs show that
broadcast or multicast is being originated at one end but is not getting across.
Figure 3-13 shows the network diagram for Frame Relay problems while running RIP.
In Figure 3-13, Router 1 and Router 2 are connected through any Layer 2 media—for
example, Frame Relay, X.25, Ethernet, FDDI, and so on.
Figure 3-14 shows the flowchart to follow to solve this problem based on this cause.
 Problem: RIP Routes Not in the Routing Table 77

Figure 3-13 Two Routers Running RIP in a Frame Relay Environment

131.108.1.0/24

131.108.2.0/24 .1 131.108.3.0/24
.2

Router 1 Router 2

Figure 3-14 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

RIP-1 sends an update on

broadcast address
Is Layer 2 media 255.255.255.255, and RIP-2
propagating RIP Not sure sends an update on multicast
broadcast/multicast? address 224.0.0.9. These two
addresses must be permitted
through Layer 2 media. Go to
“Debugs and Verification”
Yes section.

Go to
next
cause.

Debugs and Verification

Example 3-45 shows the output of the debug ip rip command, which shows that R1 is
sending and receiving RIP updates without any problem. On R2, RIP updates are being sent
but not received. This means that the RIP update is being lost at Layer 2.
Example 3-45 debug ip packet Against access-list 100 Shows That R1 Is Sending RIP Updates on the Wire, and
R2 Is Not Receiving It
R1#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100
R1#
IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 132, sending broadcast/
multicast
UDP src=520, dst=520
IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 132, rcvd 2
UDP src=520, dst=520

continues
78 Chapter 3: Troubleshooting RIP

Example 3-45 debug ip packet Against access-list 100 Shows That R1 Is Sending RIP Updates on the Wire, and
R2 Is Not Receiving It (Continued)

R2#debug ip packet 100 detail

IP packet debugging is on (detailed) for access list 100
R2#
IP: s=131.108.1.2 (Ethernet0), d=255.255.255.255, len 132, sending broadcast/
multicast
UDP src=520, dst=520
IP: s=131.108.1.2 (Ethernet0), d=255.255.255.255, len 132, sending broadcast/
multicast
UDP src=520, dst=520

Example 3-46 shows access-list 100, which is used against the debug to look at the RIP
broadcast/multicast specifically.
Example 3-46 access-list 100 Is Used Against the Debugs to Minimize the Traffic
access-list 100 permit ip any host 255.255.255.255
access-list 100 permit ip any host 224.0.0.9

Example 3-47 shows a way to find out if this is the problem when running RIP-2. Ping the
multicast address of 224.0.0.9—if the neighbor doesn’t reply, this can mean that multicast
is broken at Layer 2.
Example 3-47 Multicast Pings Are Failing, Which Means That R2’s Multicast Is Getting Lost at Layer 2
R2#ping 224.0.0.9

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 224.0.0.9, timeout is 2 seconds:
.....
R2#

Solution
RIP-1 sends an update on a broadcast address of 255.255.255.255. In the case of RIP-2, the
update is sent on a multicast address of 224.0.0.9. If these two addresses get blocked at
Layer 2 or are not being propagated at Layer 2, RIP will not function properly. Layer 2
could be a simple Ethernet switch, a Frame Relay cloud, a bridging cloud, and so on. Fixing
the Layer 2 problem is beyond the scope of this book.
Example 3-48 shows that after fixing the Layer 2 problem, RIP routes get installed in the
routing table.
Example 3-48 R2 Is Installing RIP Routes After Fixing the Layer 2 Problems
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 00:00:01 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago
Route metric is 1, traffic share count is 1
 Problem: RIP Routes Not in the Routing Table 79

RIP Routes Not in the Routing Table—Cause: Offset List Has a Large
Metric Defined
Offset lists are used to increase the metric value of RIP updates coming in or going out.
The use of an offset list can directly influence the routing table. This list can be applied
on selected networks that can be defined in an access list. If the offset value is a large
number, such as 14 or 15, the RIP metric will reach infinity when it crosses a couple of
routers. That’s why the offset list value should be kept to a minimum value.
Figure 3-15 shows a network setup that can produce a problem in the case of a
misconfigured offset list.
Figure 3-15 Network Topology Used for Misconfigured Offset Lists Problem Reproduction

131.108.6.0/24
131.108.1.0/24

Router 3 Router 1 Router 2

Example 3-49 shows that the specific router 131.108.6.0 is not in the routing table of R2.
Example 3-49 R2’s Routing Table Missing the Subnet That Is Off R3
R2#show ip route 131.108.6.0
% Subnet not in table

Figure 3-16 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-16 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

When an offset list is

applied, the metric should
Is an offset list be kept low; otherwise, it
configured on the sender or Not sure can reach the limit of 16
receiver? and the route will not get
installed. Go to “Debugs
and Verification” section.
No

Go to
next
cause.
80 Chapter 3: Troubleshooting RIP

Debugs and Verification

Troubleshooting should be done to investigate RIP’s normal behavior.
Example 3-50 shows that R2 is receiving other RIP routes, but not 131.108.6.0/24.
Example 3-50 R2 Is Missing 131.108.6.0/24 from Its Routing Table
R2#show ip route RIP

131.108.0.0/24 is subnetted, 4 subnets

R 131.108.5.0 [120/1] via 131.108.1.1, 00:00:06, Ethernet1
R 131.108.3.0 [120/1] via 131.108.1.1, 00:00:06, Ethernet1

This shows that problem is with 131.108.6.0/24, not with RIP in general. The reason is that
R3 is receiving other RIP routes from R1, so the RIP update that is coming from R1 is
working fine.
Example 3-51 shows the routing table of R1, where 131.108.6.0/24 is present in the routing table.
Example 3-51 R1 Sees 131.108.6.0/24 in Its Routing Table
R1#show ip route 131.108.6.0
Routing entry for 131.108.6.0/24
Known via "rip", distance 120, metric 1

So why is R2 not installing 131.108.6.0/24? This could be because of one of the following
reasons:
• R1 is not advertising to R2.
• R1 is advertising, but R2 is not receiving.
• R2 is receiving but is discarding it because of an infinite metric.
The simplest way to troubleshoot such problems is quick configuration examination.
Example 3-52 shows the configuration of Router R1.
Example 3-52 The Offset List Has a Large Value Configured on R1 for 131.108.6.0/24
R1#
router rip
version 2
offset-list 1 out 15 Ethernet0/1
network 131.108.0.0
!
access-list 1 permit 131.108.6.0

The administrator has configured an offset list with a very large metric. The offset list is
used to change the metric of RIP update.
From the configuration, you can surmise that any update that passes access-list 1 will have 15
added in the metric. In Example 3-52, access-list 1 permits 131.108.6.0. This means that the
metric of 131.108.6.0 is 16, which, to RIP, is an infinite metric; upon receiving it, R2 will reject it.
To verify this, run the debug ip rip command, as demonstrated in Example 3-53.
 Problem: RIP Routes Not in the Routing Table 81

Example 3-53 debug ip rip on R2 Shows That 131.108.6.0 Is Received with an Infinite Metric
R2#debug ip RIP

RIP: received v2 update from 131.108.1.1 on Ethernet1

131.108.6.0/24 -> 0.0.0.0 in 16 hops (inaccessible)

Because 16 is the infinite metric for RIP, R2 will reject 131.108.6.0/24 from going in the
routing table.

Solution
Typically, offset lists are not used in RIP networks. When the network has redundant equal-
hop (cost) paths and the administrator wants one route preferred over another, an offset list
can be used.
For example, suppose that two links exist between R1 and R2. One of the links could be
either congested or experiencing delay.
The administrator might want to shift the IP traffic for certain destination subnets to a
noncongested link for a short time, to get better throughput and to alleviate some of the
congestion. An offset list is an easy way to achieve this by making the RIP metric higher
for the subnets on the congested interface.
Example 3-54 shows the new configuration of Router R1.
To fix the problem, configure an offset value so that the hop count won’t reach its limit.
Example 3-54 New Configuration on R1 with Appropriate Offset List Value
R1#
router rip
version 2
offset-list 1 out 1 Ethernet0/1
network 131.108.0.0
!
access-list 1 permit 131.108.6.0

Example 3-55 shows the routing table of Router R2 after fixing the problem.
Example 3-55 R2’s Routing Table Shows the Entry for 131.108.6.0/24 After Configuring the Proper Offset List
R2#show ip route 131.108.6.0
Routing entry for 131.108.6.0/24
Known via "rip", distance 120, metric 1

RIP Routes Not in the Routing Table—Cause: Routes Reached RIP

Hop Count Limit
The RIP metric can go up to a maximum of 15 hops. If a network has more than 15 hops,
RIP is not a suitable protocol for it.
82 Chapter 3: Troubleshooting RIP

Figure 3-17 shows a network setup that produces a RIP hop-count limit problem.
Figure 3-17 Network Setup That Can Produce a RIP Hop-Count Limit Problem

131.108.1.0/24

Router 1 Router 2
131.108.6.0/24

R2 is receiving an update for a RIP route, which is several (more than 15) hops away. R2
doesn’t install that route in the routing table, as demonstrated in the output in Example 3-56.
Example 3-56 R2’s Routing Table Is Missing the Route for 131.108.6.0
R2#show ip route 131.108.6.0
% Subnet not in table

Figure 3-18 shows the flowchart to solve this problem.

Figure 3-18 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP routes are not in the routing table of R2.

RIP has a hop count of 15.

When RIP receives a route
Is the network more with a metric of 16, it
Not sure
than 15 hops away? ignores the route. Go to
“Debugs and Verification”
section.

No

Go to
next
cause.

Debugs and Verification

The most logical way to start troubleshooting this problem is to look at R1 and determine
whether R1 is receiving 131.108.6.0/24.
Example 3-57 shows that Router R1 is receiving RIP routes for 131.108.6.0/24.
 Problem: RIP Is Not Installing All Possible Equal-Cost Paths 83

Example 3-57 R1’s Routing Table Has 131.108.6.0/24 with a Metric of 15 (Maximum RIP Metric)
R1#show ip route 131.108.6.0
Routing entry for 131.108.6.0/24
Known via "rip", distance 120, metric 15

R1 is receiving the route in question, but with a metric of 15. R1 will add 1 more to 15 when
advertised to R2, which will result in an infinite metric, consequently preventing the route
from being placed in the routing table.
To prove this, in R1, you can run the debug ip rip command to view the process in
real time.
Example 3-58 shows the output of debug ip rip on Router R1.
Example 3-58 debug ip rip Output Shows That R1 Is Advertising 131.108.6.0 with a Metric of 16 (Infinity)
R1#debug ip rip
RIP protocol debugging is on
RIP: sending v2 update to 224.0.0.9 via Ethernet1 (131.108.1.1)
131.108.6.0/24 -> 0.0.0.0, metric 16, tag 0

Example 3-59 shows the output of debug ip rip on Router R2. Router R2 receives this
update and discards it because the metric shows that this network is infinitely far away and,
therefore, unreachable.
Example 3-59 debug ip rip Output on R2 Shows That R2 Is Receiving Routes with an Infinite Metric
R2#debug ip rip
RIP protocol debugging is on
RIP: received v2 update from 131.108.1.1 on Ethernet1
131.108.6.0/24 -> 0.0.0.0 in 16 hops (inaccessible)

Solution
This is a classical RIP problem in which a route passes through more than 15 devices. IP
networks these days usually have more than 15 routers. There is no way to overcome this
behavior other than to pick a routing protocol that does not have a 15-hop limitation. You
should use OSPF, EIGRP, or IS-IS instead.

Problem: RIP Is Not Installing All Possible Equal-Cost

Paths—Cause: maximum-path Command Restricts RIP
from Installing More Than One Path
By default, Cisco routers support only four equal paths for the purpose of load balancing.
The maximum-path command can be used for up to six equal-cost paths. If the command
84 Chapter 3: Troubleshooting RIP

is not configured properly, it can cause a problem, as discussed in this section. When con-
figured improperly, the maximum-path command allows only one path to the destination,
even though more than one path exists. Configuring the command as maximum-path 1
should be done only when load balancing is not desired.
Figure 3-19 and Example 3-60 provide a network scenario that will be used as the basis for
troubleshooting when the maximum-path command restricts RIP from installing more
than one path, resulting in the omission of all possible equal-cost paths. The sections that
follow carefully dissect how to troubleshoot this problem.
Figure 3-19 shows the network setup that produces the problem of RIP not installing all
possible equal-cost paths.
Figure 3-19 RIP Network Vulnerable to an Equal-Cost Path Problem

Router 1

E1 E2

131.108.1.0/24 131.108.5.0/24

131.108.2.0/24
Router 2 Router 3

Example 3-60 shows the routing table of Router R1. Only one route is being installed in
the routing table. By default, any routing protocol supports equal-cost multipaths (load
balancing). If more than one equal path exists, it must be installed in the routing table.
Example 3-60 R1 Installs Only One Path for 131.108.2.0/24
R1#show ip route rip
131.108.0.0/24 is subnetted, 1 subnets
R 131.108.2.0 [120/1] via 131.108.5.3, 00:00:09, Ethernet2

Figure 3-20 shows the flowchart to follow to solve this problem based on this cause.
 Problem: RIP Is Not Installing All Possible Equal-Cost Paths 85

Figure 3-20 Flowchart to Solve Why RIP Routes Don’t Show Up in a Routing Table

RIP is not installing all possible equal paths.

Cisco routers, by default,

allow only four equal cost
Are there more than four Not sure paths to be installed in the
possible paths? routing table. Go to
“Debugs and Verification”
section.

No

Go to
next
problem.

Debugs and Verification

Example 3-61 shows the output of debug ip rip on Router R1. The output shows that
Router R1 is receiving two equal-cost routes.
Example 3-61 debug ip rip Output on R1 Shows R1 Receiving Two Updates for the 131.108.2.0 Network
R1#debug ip rip
RIP protocol debugging is on
R1#
RIP: received v2 update from 131.108.5.3 on Ethernet2
131.108.2.0/24 -> 0.0.0.0 in 1 hops
RIP: received v2 update from 131.108.1.2 on Ethernet1
131.108.2.0/24 -> 0.0.0.0 in 1 hops

Only one route is installed in the routing table. You see only one route in the routing table
instead of two because operator has configured maximum-paths 1 in the configuration.
Example 3-62 shows the current configuration for Router R1.
Example 3-62 R1 Is Configured with maximum-path 1
R1#
router rip
version 2
network 131.108.0.0
maximum-paths 1

Solution
By default, Cisco IOS Software allows up to four equal-cost routes to be installed in the
routing table. This could be increased up to six routes if configured as in Example 3-63.
86 Chapter 3: Troubleshooting RIP

Example 3-63 shows the configuration that installs six equal-cost path routes in the routing
table.
Example 3-63 Allowing the Maximum of Six Paths in the Routing Table
R1#
router rip
maximum-paths 6

This example makes more sense when you have more than four paths and only four
are getting installed in the routing table. Because four equal-cost routes is a default,
maximum-paths needs to be increased to accommodate the fifth and possibly sixth
route.

Troubleshooting RIP Routes Advertisement

All the problems discussed so far deal with the problem on the receiving end or the problem
in the middle (Layer 2).
A third possible cause exists when routes are not being installed in the routing table.
The sender could be having a problem sending RIP updates for some reason. As a
result, the receiver cannot install the RIP routes in the routing table. This section talks
about the things that can go wrong on the sender’s side.
This section discusses some of the possible scenarios that can prevent RIP routes from
being advertised. Some cases overlap with router installation problems—for example,
missing network statement(s) or an interface that is down. This section assumes that, after
troubleshooting the problems previously addressed in the “Troubleshooting RIP Routes
Installation” section, the problems persist. This section presents recommendations on
where to go next to resolve those issues.
Two of the most prevalent problems that can go wrong on the sender’s end deal with RIP
route advertisement:
• The sender is not advertising RIP routes.
• Subnetted routes are missing.

Problem: Sender Is Not Advertising RIP Routes

Typically, an IP network running RIP has routers that have a consistent view of the routing
table. In other words, all routers have routing tables that contain reachability information
for all the IP subnets of the network. This might differ in cases when filtering of certain
subnets is done at some routers and not at others. Ideally, all RIP routers have routes of the
complete network.
 Problem: Sender Is Not Advertising RIP Routes 87

When the routing information differs from one router to the other, one of two possibilities
could exist:
• Some routers are not advertising the RIP routes.
• Some routers are not receiving the RIP routes.
This section deals with problems in sending RIP routes.
Figure 3-21 provides a network scenario that will be used as the basis for troubleshooting
a majority of following causes of the problem of the sender not advertising RIP routes:
• Missing or incorrect network statement
• Outgoing interface that is down
• distribute-list out blocking the routes
• Advertised network interface that is down
• Outgoing interface defined as passive
• Broken multicast capability (encapsulation failure in Frame Relay)
• Misconfigured neighbor statement
• Advertised subnet is VLSM
• Split horizon enabled
Figure 3-21 shows the network setup in which Router R1 is not sending RIP routes toward R2.
Figure 3-21 Network Setup in Which Router R1 Is Not Sending RIP Routes Toward R2

131.108.2.0/24 .1 131.108.1.0/24 131.108.3.0/24

.2
E0 E0
Router 1 Router 2

The sections that follow carefully dissect how to troubleshoot this problem based on
specific causes.

Sender Is Not Advertising RIP Routes—Cause: Missing or Incorrect

network Statement
One of the requirements for enabling RIP on a router’s interface is to add the network
statement under the router rip command. The network statement decides which interface
RIP should be enabled on. If the network statement is misconfigured or not configured, RIP
will not be enabled on that interface and RIP routes will not be advertised out that interface.
Figure 3-22 shows the flowchart to follow to fix this problem.
88 Chapter 3: Troubleshooting RIP

Figure 3-22 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

RIP must be enabled on

the interface to send and
Is RIP enabled on the Not sure receive RIP updates. Go to
interface? “Debugs and Verification”
section.

Yes

Go to
next
cause.

Debugs and Verifications

Example 3-64 shows the current configuration for R1.
Example 3-64 R1 Configuration Shows the Misconfigured network Statement
R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router rip
network 131.107.0.0

The network statement is incorrectly configured under router rip in Example 3-64.
Instead of 131.108.0.0, 131.107.0.0 is configured. This will not enable RIP on the interface,
and no updates will be sent.

Solution
Sometimes, a classless statement is configured under router rip, assuming that it will cover
all the networks—for example:
router rip
network 131.0.0.0

The network statement will not cover 131.0.0.0 through 131.255.255.255 because
131.0.0.0 is a classless network and RIP is a classful protocol. Similarly, if you have
multiple Class C addresses, you cannot use one network statement to cover all the
 Problem: Sender Is Not Advertising RIP Routes 89

addresses that you own. For example, suppose that you own 200.1.1.0 through 200.1.4.0.
This doesn’t mean that you can use the following command syntax:
router rip
network 200.1.0.0

The network statement here is meaningless for RIP-1 because RIP-1 is a classful
protocol. The correct way to advertise all four networks in RIP is as follows:
router rip
network 200.1.1.0
network 200.1.2.0
network 200.1.3.0
network 200.1.4.0

Example 3-65 shows the corrected configuration for R1.

Example 3-65 Correcting the network Statement in the R1 Configuration
R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router rip
network 131.108.0.0

Example 3-66 shows the routing table of Router R2, showing the learned RIP route.
Example 3-66 R2 Routing Table Shows That the RIP Routes Are Learned After Correcting the network Statement
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:11 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:11 ago, via Ethernet0
Route metric is 1, traffic share count is 1

Sender Is Not Advertising RIP Routes—Cause: Outgoing Interface

Is Down
RIP is the routing protocol that runs on Layer 3. RIP cannot send updates across an inter-
face if the outgoing interface is down. There can be a variety of possible causes for the
outgoing interface being down:
• Interface is up, line protocol is down
• Interface is down, line protocol is down
• Interface is administratively down, line protocol is down
90 Chapter 3: Troubleshooting RIP

If the outgoing interface shows any of these symptoms, RIP will not be capable of sending
any updates across the network. The main thing to note here is that, with any of these potential
causes, the line protocol will always show down. This is the most important information to
determine Layer 2 connectivity.
Figure 3-23 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-23 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

If the outgoing interface is

down, RIP will not advertise
Is the outgoing interface Not sure any routes out on that
up/up? interface. Go to “Debugs
and Verification” section.

Yes

Go to
next
cause.

Debugs and Verification

Example 3-67 shows that the interface Ethernet 0 is down.
Example 3-67 Outgoing Interface Ethernet 0 of R1 Shows That the Line Protocol Is Down
R1#show interface ethernet 0
Ethernet0 is up, line protocol is down
Hardware is Lance, address is 0000.0c70.d31e (bia 0000.0c70.d31e)
Internet address is 131.108.1.1/24

Example 3-68 shows the debug ip rip output. In this debug, R1 is not sending or receiving
any RIP updates because Layer 2 is down.
Example 3-68 debug ip rip Output Reveals That Nothing Is Being Sent or Received on R1’s Ethernet0 Interface
R1#debug ip rip
RIP protocol debugging is on
R1#

In the debug, there are no outputs because of this problem.

 Problem: Sender Is Not Advertising RIP Routes 91

Solution
RIP runs above Layer 2. RIP cannot send or receive any routes if Layer 2 is down.
To correct this problem, Layer 2 or Layer 1 must be corrected. Sometimes, the problem
could be as simple as loose cables or a bad cable that must be replaced, or it could be as
complex as bad hardware, in which case hardware must be replaced.
Example 3-69 shows the interface Ethernet 0 after fixing the Layer 2 problem.
Example 3-69 R1’s Outgoing Interface Ethernet0 Is Up After Fixing the Layer 2 Issue
R1#
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c70.d31e (bia 0000.0c70.d31e)
Internet address is 131.108.1.1/24

Example 3-70 shows the routing table of R2.

Example 3-70 1’s Ethernet0 Interface Is Up, So RIP Is Sending Updates and R2 Has RIP Routes in Its Routing
Table
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

Sender Is Not Advertising RIP Routes—Cause: distribute-list out Is

Blocking the Route
distribute-list out is used to filter any routes that will be sent out an interface. If a
receiver is complaining about missing routes that should be received, make sure that the
routes are not being filtered through distribute-list out. If this is the case, you must
modify the access list.
Figure 3-24 shows the flowchart to follow to fix this problem.

Debugs and Verification

Example 3-71 shows the configuration of Router R1. In this configuration, access-list 1
does not explicitly permit the 131.108.0.0 network, so R1 will not be allowed to advertise
any 131.108.X.X network, including 131.108.2.0/24.
92 Chapter 3: Troubleshooting RIP

Figure 3-24 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

Make sure that the distribute-

list out permits the
Is distribute-list out network that you want to
Not sure
blocking the routes? advertise out via RIP. Go
to “Debugs and Verification”
section.

No

Go to
next
cause.

Example 3-71 access-list 1 Does Not Permit the 131.108.0.0 Network

R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router rip
network 131.108.0.0
distribute-list 1 out
!
access-list 1 permit 131.107.0.0 0.0.255.255

Solution
When using a distribute list, you should always double-check your access list to make
sure that the networks that are supposed to be permitted are explicitly permitted in the
access list. If not, they will be denied. In the configuration example in Example 3-72,
the access list is permitting only 131.107.0.0. An implicit deny any at the end of each
access list causes the 131.108.0.0 network to be denied. To fix this problem, permit
131.108.0.0 in access-list 1, as shown in Example 3-72.
Example 3-72 Reconfiguring access-list 1 to Permit Network 131.108.0.0
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
 Problem: Sender Is Not Advertising RIP Routes 93

Example 3-72 Reconfiguring access-list 1 to Permit Network 131.108.0.0 (Continued)

router rip
network 131.108.0.0
distribute-list 1 out
!
access-list 1 permit 131.108.0.0 0.0.255.255

Example 3-73 shows the routing table of Router R2.

Example 3-73 R2 Routing Table Shows the Entry for the 131.108.2.0 Network After Permitting It in access-list 1
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

Sender Is Not Advertising RIP Routes—Cause: Advertised Network

Interface Is Down
The network that is being advertised might be down, and the connected route has been
removed from the routing table. In this situation, RIP will start advertising that network with
an infinite metric of 16; after the hold-down timer has expired, it will no longer advertise this
network. As soon as the advertised network comes up, RIP will start advertising it again in
its updates.
Figure 3-25 shows the flowchart to follow to fix this problem.
Figure 3-25 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

The interface’s network

number will not be
Is the advertised network advertised if the interface
Not sure
interface up/up? that represents the network
is down. Go to “Debugs
and Verification” section.

No

Go to
next
cause.
94 Chapter 3: Troubleshooting RIP

Debugs and Verification

Example 3-74 shows that the line protocol of R1’s Ethernet 1 interface is down, indicating
that there is something wrong at Layer 2. This is the interface that is directly attached to the
network that needs to be advertised. Therefore, that network cannot be advertised to neigh-
boring routers.
Example 3-74 show interface Output Displays That the Line Protocol of the Advertised Network Is Down
R1#show interface Ethernet 1
Ethernet1 is up, line protocol is down
Hardware is Lance, address is 0000.0c70.d51e (bia 0000.0c70.d51e)
Internet address is 131.108.2.1/24

When the advertised network’s interface goes down, RIP will detect the down condition.
RIP will no longer advertise that network in the RIP update. In Example 3-74, interface
Ethernet 1 is down, so RIP will no longer advertise 131.108.2.0/24 in its update.

Solution
You must correct this problem at Layer 2 or Layer 1. Sometimes, the problem could be as
simple as loose cables, or it could be as complex as bad hardware, in which case the hardware
must be replaced. After fixing the Layer 2 problem, reissue the show interface command to
view the current status, to verify that it has changed state to up.
Example 3-75 shows that the advertised network interface line protocol is up.
Example 3-75 show interface Output Displays That the Line Protocol of Ethernet1 Is Up After Fixing
the Layer 2 Issue
R1#show interface Ethernet 1
Ethernet1 is up, line protocol is up
Hardware is Lance, address is 0000.0c70.d51e (bia 0000.0c70.d51e)
Internet address is 131.108.2.1/24

When the interface is active again, RIP will begin to advertise that network in its
periodic updates. Example 3-76 shows that the route that was down is back in the
routing table of R2.
Example 3-76 show ip route Output Displays That R2’s Routing Table Indicates the Network Again After the Layer
2 Issue Is Resolved
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1
 Problem: Sender Is Not Advertising RIP Routes 95

Sender Is Not Advertising RIP Routes—Cause: Outgoing Interface

Is Defined Passive
A situation might arise in which a router has a complete RIP routing table, but it is not ad-
vertising to other routers running RIP. This occurs when not all routers in a RIP network
have complete routing tables, resulting in lacking IP connectivity from one part of the net-
work to the other. If the outgoing interface is defined as passive, it will not advertise any
RIP updates on that interface.
Figure 3-26 shows the flowchart to follow to fix this problem.
Figure 3-26 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

Passive interfaces are

incapable of sending any
Is the outgoing interface Not sure RIP updates. Go to
defined as passive?
“Debugs and Verification”
section.

No

Go to
next
cause.

Debugs and Verification

Example 3-77 shows the output of show ip protocols, which shows that the outgoing
interface is defined as a passive interface.
Example 3-77 show ip protocols Output Reveals That the Outgoing Interface on R1 Is Passive
R1#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 26 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Key-chain
Loopback0 1 1 2
Routing for Networks:
131.108.0.0
Passive Interface(s) Ethernet0
continues
96 Chapter 3: Troubleshooting RIP

Example 3-77 show ip protocols Output Reveals That the Outgoing Interface on R1 Is Passive (Continued)
Routing Information Sources:
Gateway Distance Last Update
131.108.1.2 120 00:00:26
Distance: (default is 120)

Example 3-78 shows the configuration of Router R1, which shows that the outgoing inter-
face is defined as passive.
Example 3-78 Configuring the passive interface Command in RIP
router rip
passive-interface Ethernet0
network 131.108.0.0

Solution
When an interface is defined as a passive interface under RIP, RIP will receive updates on
that interface but will not send any updates.
In Example 3-78, the interface Ethernet 0 is defined as passive, so R1 is not sending any
updates on Ethernet 0. Sometimes, some networks should be advertised and others should
be filtered. In this type of situation, passive interfaces should not be used. Distribute lists,
used to selectively filter updates, are a better solution in that case.
Assume that passive-interface was configured by mistake. Take this command out of the
configuration to solve this problem using the no form of the command.
Example 3-79 shows the new configuration to solve this problem.
Example 3-79 Correcting the passive-interface Problem
router rip
network 131.108.0.0

Example 3-80 shows the routing table of R2 after fixing the problem.
Example 3-80 R2 Routing Table After Removing the passive-interface Command
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Serial0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Serial0
Route metric is 1, traffic share count is 1

Sender Is Not Advertising RIP Routes—Cause: Broken Multicast

Capability (Frame Relay)
In some networking scenarios, router interfaces do not automatically propagate multicast
and broadcast traffic unless configured to do so. This could be a major problem because
 Problem: Sender Is Not Advertising RIP Routes 97

RIP-1 updates are sent at a broadcast address and RIP-2 uses multicast to exchange routes.
No routing information will propagate across the network unless broadcast and multicast
features are enabled on such interfaces. Nonbroadcast multiaccess (NBMA) Frame Relay
is a prime example of a networking environment in which interfaces exhibit this behavior.
Figure 3-27 shows a network setup that is deliberately configured with broken multicast to
illustrate the example of how Frame Relay RIP updates will not go across R1.
In Figure 3-27, Router 1 and Router 2 are connected through Frame Relay. Router 1 is not
advertising RIP routes toward Router 2.
Figure 3-27 NBMA Frame Relay Network Vulnerable to Broken Multicast Capability Problems

131.108.1.0/24

131.108.2.0/24 .1 131.108.3.0/24
.2
Frame Relay

Router 1 Router 2

Figure 3-28 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-28 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

If a Layer 2 NBMA
network such as Frame
Relay or ISDN is
configured with static
Is the multicast capability Not sure mapping, make sure that
broken? the broadcast keyword is
added in the map
statement. Go to “Debugs
and Verification” section.
No

Go to
next
cause.

Debugs and Verification

Example 3-81 shows the configuration of Router R1. In this example, Frame Relay pro-
vides the Layer 2 encapsulation. In this configuration, the frame-relay map statement
doesn’t have the keyword broadcast at the end. As a result, all broadcast/multicast traffic
will be prohibited from crossing the NBMA network. The broadcast keyword tells the
router to replicate the necessary broadcasts and send them across the specified circuits.
98 Chapter 3: Troubleshooting RIP

Example 3-81 R1’s frame-relay map Statement Lacks the broadcast Keyword
R1#
interface Serial3
ip address 131.108.1.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 131.108.1.2 16
!

Example 3-83 shows output from debug ip packet. This debug includes only the broadcast
traffic source from R1. As shown in Example 3-82, R1 is configured with access-list 100.
Example 3-82 Configuration in R1 of access-list 100 to Limit debug Output
R1#:
access-list 100 permit ip host 131.108.1.1 host 255.255.255.255

R1 is configured with access-list 100, which permits all packets from source 131.108.1.1
destined to the broadcast address of 255.255.255.255. In Example 3-83, R1 runs debug ip
packet detail with access-list 100 to limit traffic destined to 255.255.255.255 with R1 as
the source. The debug output in Example 3-83 shows that there are encapsulation failures,
indicating that they cannot be placed in the appropriate Layer 2 frame.
Example 3-83 debug ip packet Output on R1 Reveals Encapsulation Failure for RIP Updates
R1#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100
R1#
IP: s=131.108.1.1 (local), d=255.255.255.255 (Serial3), len 112, sending broad/
multicast
UDP src=520, dst=520
IP: s=131.108.1.1 (local), d=255.255.255.255 (Serial3), len 112, encapsulation
failed
UDP src=520, dst=520

Solution
When RIP is running in a Frame Relay (NBMA) environment, Layer 2 must be configured to
support broadcast traffic; otherwise, RIP updates will not get across. When static map-ping is
used, make sure to add the broadcast keyword at the end of a frame-relay map statement.
Example 3-84 shows the new configuration of Router R1 with the corrected frame-relay
map statement.
Example 3-84 Corrected Configuration to Enable Broadcast Traffic to Go Across an NBMA Environment
R1#:
interface Serial3
ip address 131.108.1.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 131.108.1.2 16 broadcast
!

Example 3-85 shows the routing table of R2 with RIP routes.

 Problem: Sender Is Not Advertising RIP Routes 99

Example 3-85 R2 Routing Table with RIP Routes After the Corrected frame-relay map Statement for Router R1
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Serial0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Serial0
Route metric is 1, traffic share count is 1

Sender Is Not Advertising RIP Routes—Cause: Misconfigured

neighbor Statement
In a nonbroadcast environment, RIP utilizes a unicast method to send RIP updates. To send
unicast RIP updates, neighbor statements must be configured carefully. If the neighbor
address is configured incorrectly in the neighbor statement, RIP will not send the unicast
update to the neighbor.
Figure 3-29 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-29 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

In a nonbroadcast
environment, neighbor
statements might be
necessary. They are
Is the neighbor statement configured under the
Not sure
configured properly? router rip configuration
mode and force the router
to unicast RIP updates. Go
to “Debugs and Verification”
Yes section.

Go to
next
cause.

Debugs and Verification

Example 3-86 shows the RIP configuration in Router R1. The configuration shows that
the neighbor statement is configured incorrectly. Instead of 131.108.1.2, it’s pointing to
131.108.1.3, which doesn’t exist.
Example 3-86 Router R1 RIP Configuration with Incorrectly Configured neighbor Statement
router rip
network 131.108.0.0
neighbor 131.108.1.3
100 Chapter 3: Troubleshooting RIP

Solution
In Example 3-86, RIP is sending a unicast update to a neighbor address of 131.108.1.3,
which doesn’t exist.
To solve the problem, the neighbor statement must be configured properly.
Example 3-87 shows the corrected configuration of Router R1.
Example 3-87 Router R1 Configuration with the Correct neighbor Statement
R1# router rip
network 131.108.0.0
neighbor 131.108.1.2

Example 3-88 shows the RIP routes installed in R2’s routing table.
Example 3-88 R2 Routing Table Shows the RIP Entry After Correcting the RIP neighbor Statement
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Serial0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Serial0
Route metric is 1, traffic share count is 1

Sender Is Not Advertising RIP Routes—Cause: Advertised Subnet

Is VLSM
In almost all IP networks, IP addresses are efficiently utilized by doing variable-length
subnet masking (VLSM) of the original IP block. Because RIP-1 does not support VLSM
routing, routing VLSM routes becomes a common issue with RIP running networks.
Figure 3-30 shows the network setup, which produces problems because of the existence
of a VLSM. The figure shows that Router 1 has an interface whose mask is /25. Note that
131.108.0.0 is variably subnetted to two different masks, 131.108.1.0/24 and 131.108.2.0/25.
Figure 3-30 VLSM Network Example Producing Problems with RIP

131.108.2.0/25 .1 131.108.1.0/24 131.108.3.0/24

.2

Router 1 Router 2

RIP-1 cannot advertise the mask of a subnet, so it cannot support VLSM and cannot
advertise /25 to an RIP interface whose mask is /24.
Figure 3-31 shows the flowchart to follow to correct this problem.
 Problem: Sender Is Not Advertising RIP Routes 101

Figure 3-31 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

RIP doesn’t support

variable-length subnet
masks. Any subnet that
Is the advertised subnet varies the subnet mask
Not sure
using VLSM? has the potential to be left
out of RIP updates. Go to
“Debugs and Verification”
section.
No

Go to
next
cause.

Debugs and Verification

Example 3-89 shows that a loopback interface on R1 is configured for a /25
(255.255.255.128) subnet mask; the interface that will be sourcing RIP update has
a /24 (255.255.255.0) mask.
Example 3-89 Configuration to Show VLSM Subnets
R1#:
interface Loopback0
ip address 131.108.2.1 255.255.255.128
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router rip
network 131.108.0.0

Solution
RIP-1 is not designed to carry subnet mask information. Therefore, any subnet that is using
a different mask than the interface that will be sourcing the RIP update will not be adver-
tised by RIP. RIP actually performs a check before sending an update, to make sure that the
subnet that will be advertised by RIP has the same subnet mask as the interface that will be
sourcing the RIP update. If the mask is different, RIP actually drops the update and will not
advertise it.
To solve the problem, either change the subnet mask so that it matches the interface that will
be sourcing the RIP update or change the protocol to RIP-2, which does support VLSM.
102 Chapter 3: Troubleshooting RIP

Example 3-90 shows the configuration changes that correct the problem.
Example 3-90 Configuring RIP to Advertise VLSM Routes
R1#:
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!

router rip
version 2
network 131.108.0.0

Example 3-91 shows the routing table of Router R2 after correcting the problem.
Example 3-91 Router R2 Routing Table After Resolving the VLMS Support Problem
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/25
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0
Route metric is 1, traffic share count is 1

Sender Is Not Advertising RIP Routes—Cause: Split Horizon Is

Enabled
Split horizon is a feature in RIP to control routing loops. In some situations, it is necessary
to enable split horizon to avoid loops. For example, split horizon is necessary in a normal
situation when a RIP update is received on an interface and is not sent out on the same
interface. Split horizon must be disabled in other environments, such as a hub-and-spoke
Frame Relay environment in which spokes have no circuit between them and they go
through the hub router, as shown in Figure 3-32.
Another unique situation worth mentioning is one in which a router has an external route
that has a next-hop address also known through some interface where other RIP routers
are sitting. When those external routes are redistributed into RIP, the router doesn’t
advertise that route out the same interface because split horizon is enabled. Also, if a
secondary address is configured under an interface, split horizon must be turned off on
that interface; otherwise, that secondary address will not be advertised out that interface
to other routers.
Figure 3-33 shows the network setup that produces problems when split horizon is enabled.
Router 1 is not advertising all RIP routes to Router 3.
 Problem: Sender Is Not Advertising RIP Routes 103

Figure 3-32 Hub-and-Spoke Frame Relay Network Requiring Disabling Split Horizon

Hub

Frame Relay
131.108.1.0/24

131.108.2.0/24 131.108.3.0/24

Spoke 1 Spoke 2

Figure 3-33 Split Horizon–Enabled Network Vulnerable to RIP Problems

166.166.166.0/24
.3
Router 3

155.155.155.0/24
.1
131.108.1.0/24
Router 1

.2
Router 2
104 Chapter 3: Troubleshooting RIP

Figure 3-34 shows the flowchart to follow to fix this problem.

Figure 3-34 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP routes are not being advertised by Router R1.

Split-horizon might need

to be turned off when
advertising secondary
Is split horizon enabled on Not sure addresses or redistributed
the interface? routes known via the same
interface. Go to “Debugs
and Verification” section.
No

Go to
next
cause.

Debugs and Verification

Example 3-92 shows the current configuration of R1.
Example 3-92 166.166.166.0/24 Is Being Redistributed into RIP on R1
R1#
router rip
redistribute static
network 131.108.0.0
!
ip route 155.155.0.0 255.255.0.0 10.10.10.4
ip route 166.166.166.0 255.255.255.0 131.108.1.3

Example 3-93 shows that the route 166.166.166.0/24 is not in the routing table of Router
R2; however, 155.155.155.0/24 does show up in the routing table.
Example 3-93 R2 Routing Table Does Not Show Route 166.166.166.0/24
R2#show ip route rip
R 155.155.0.0/16 [120/1] via 131.108.1.1, 00:00:07, Ethernet0

Example 3-94 shows the debug ip rip output on Router R1. R1 is advertising only 155.155.0.0/
16, not 166.166.166.0/24. In R2’s routing table, no route exists for 166.166.166.0/24.
Example 3-94 debug ip rip Output Displays 166.166.166.0 Is Not Being Advertised by R1
R1#debug ip rip
RIP protocol debugging is on

RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.1)

RIP: build update entries
network 155.155.0.0 metric 1
 Problem: Sender Is Not Advertising RIP Routes 105

Solution
This problem occurs because the next hop of 166.166.166.0/24 is 131.108.1.2. With split
horizon, RIP will suppress this update from going out the same interface that 166.166.166.0/24
is learned. Notice that the route 155.155.155.0/24 was advertised by R1 because the next-hop
address of that route was 10.10.10.4, which is a different interface on R1.
The solution lies in turning off split horizon on the Ethernet 0 interface of R1.
A similar situation would arise if 166.166.166.0/24 was defined as a secondary interface
address on R1, which will not advertise this secondary interface address in its RIP update
unless split horizon is turned off.
Example 3-95 shows the new configuration on Router R1 to solve this problem.
Example 3-95 Disabling Split-Horizon on R1’s Ethernet 0 Interface
R1#
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
no ip split-horizon

Example 3-96 shows that after making the configuration changes, R2 is receiving
166.166.166.0/24 in the RIP updates.
Example 3-96 R2 Routing Table After Split Horizon Has Been Disabled Confirms That RIP Updates Reflect the
166.166.166.0/24 Route
R2#show ip route rip
R 155.155.0.0/16 [120/1] via 131.108.1.1, 00:00:08, Ethernet0
R 166.166.0.0/16 [120/1] via 131.108.1.1, 00:00:08, Ethernet0

This problem can also be seen when interfaces are configured with secondary IP addresses.
Example 3-97 shows the interface configuration with secondary IP address.
Example 3-97 Interface Configuration with Secondary Addresses
R1#
interface Ethernet0
ip address 131.108.2.1 255.255.255.0 secondary
ip address 131.108.1.1 255.255.255.0

If split horizon is enabled, this secondary address will not be advertised on Ethernet0.
Similarly, imagine a situation in which there are three routers—R1, R2, and R3—on the
same Ethernet, as shown in Figure 3-35.
R1 and R3 are running OSPF. R1 and R2 are running RIP, as in the preceding example.
Now, R3 advertises certain routes through OSPF to R1 that R1 must redistribute in RIP.
R1 will not advertise those OSPF routes to R2 because of split horizon. The solution is
again to disable split horizon.
106 Chapter 3: Troubleshooting RIP

Figure 3-35 Another Split Horizon–Enabled Network Vulnerable to RIP Problems

166.166.166.0/24 OSPF
.3
Router 3
router rip
redistribute ospf 1 metric 1
OSPF
RIP
.1
131.108.1.0/24
Router 1

RIP
.2
Router 2

Basically, these are the three main reasons for turning off split horizon. Any other situation
might create a routing loop if split horizon is turned off.

Problem: Subnetted Routes Missing from the Routing

Table of R2—Cause: Autosummarization Feature Is
Enabled
In some situations, subnetted routes are not advertised in RIP. Whenever RIP sends an
update across a major network boundary, the update will be autosummarized. This is not
really a problem; this is done to reduce the size of the routing table.
Figure 3-36 shows a network setup in which R1 has subnets of 155.155.0.0, but R2 shows
none of these subnets in its routing table. Either R1 is not advertising them to R2, or R2 is
not receiving them. The chances of R1 not advertising more specific subnets of
155.155.0.0/16 is more favorable.
Example 3-98 shows that the subnetted route of 155.155.0.0/16 is missing from the routing
table of R2, but the major network route is present. This means that R1 is advertising the
routes but is somehow summarizing the subnets to go as 15.155.0.0/16.
 Problem: Subnetted Routes Missing from the Routing Table of R2 107

Figure 3-36 RIP Network Vulnerable to Autosummarization Problems

155.155.155.1/24

155.155.0.0/16
131.108.2.0/24 .1 131.108.1.0/24 131.108.3.0/24
.2
E0 E0
Router 1 Router 2

Example 3-98 R2’s Routing Table Reflects That the Subnetted Route Is Missing
R2#show ip route 155.155.155.0 255.255.255.0
% Subnet not in table

R2#show ip route 155.155.0.0

Routing entry for 155.155.0.0/16
Known via "rip", distance 120, metric 1
Redistributing via rip
Advertised by rip (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:01 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:01 ago, via Ethernet0
Route metric is 1, traffic share count is 1

Figure 3-37 shows the flowchart to fix this problem based on the autosummarization feature
being enabled.
Figure 3-37 Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

RIP-2 routes are not being advertised by Router R1.

When RIP crosses a major

network border, it auto-
Is the autosummarization Not sure matically summarizes to
feature enabled? classful boundaries. Go to
“Debugs and Verification”
section.

No

Go to
next
cause.
108 Chapter 3: Troubleshooting RIP

Debugs and Verification

Example 3-99 shows the configuration of R1 in the case of RIP-1. RIP-1 is a classful protocol
and always summarizes to classful boundaries for nondirectly connected major networks.
Example 3-99 R1 Configuration with RIP Version 1
R1#
interface Loopback1
ip address 131.108.2.1 255.255.255.0
!
interface Loopback3
ip address 155.155.155.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router rip
network 131.108.0.0
network 155.155.0.0

Example 3-100 shows the routing table in Router R2. Notice that R2 is receiving 155.155.0.0/16,
not 155.155.155.0/24, as configured on R1. Also note that R2 is receiving a /24 route of
131.108.2.0, the route of the same major network as that of interface Ethernet 0, which connects
R1 to R2.
Example 3-100 R2 Routing Display to Show How Subnetted Routes Are Summarized to Classful Boundaries
R2#show ip route RIP
R 155.155.0.0/16 [120/1] via 131.108.1.1, 00:00:22, Ethernet0
131.108.0.0/24 is subnetted, 3 subnets
R 131.108.2.0 [120/1] via 131.108.1.1, 00:00:22, Ethernet0

Solution
In RIP-1, there is no workaround for this problem because RIP-1 is a classful routing
protocol. RIP-1 automatically summarizes any update to a natural class boundary when that
update goes over an interface configured with a different major network.
As indicated by R2’s routing table in Example 3-100, 155.155.155.0/24 is advertised over
an interface configured with 131.108.0.0. This summarizes 155.155.155.0/24 to a Class B
boundary as 155.155.0.0/16.
In RIP-1, this is not a problem because RIP-1 is a classful protocol and the network should
be designed with this understanding. With RIP-2, however, Cisco routers can be configured
to stop the autosummarization process.
For example, R1’s configurations can be changed to run a RIP-2 process rather than a
RIP-1 process.
Example 3-101 shows the configuration that solves this problem for RIP-2.
 Problem: RIP-2 Routing Table Is Huge— Cause: Autosummarization Is Off 109

Example 3-101 Disabling Autosummarization in RIP-2

router rip
version 2
network 131.108.0.0
network 155.155.0.0
no auto-summary

Example 3-102 shows the routing table of Router R2, which indicates that it is now
receiving desired subnetted route 155.155.155.0/24.
Example 3-102 Router R2’s Routing Table Shows That It Is Receiving the Subnetted Route 155.155.155.0/24
R2#show ip route 155.155.0.0
155.155.0.0/24 is subnetted, 1 subnets
R 155.155.155.0 [120/1] via 131.108.1.1, 00:00:21, Ethernet0
131.108.0.0/24 is subnetted, 3 subnets
R 131.108.2.0 [120/1] via 131.108.1.1, 00:00:21, Ethernet0

Troubleshooting Routes Summarization in RIP

Route summarization refers to summarizing or reducing the number of routes in a routing
table. For example, 131.108.1.0/24, 131.108.2.0/24 and 131.108.3.0/24 can be reduced to one
route entry (that is, 131.108.0.0/16 or 131.108.0.0/22), the latter of which will cover only these
three subnets. Route summarization (autosummarization and manual summarization, both of
which are addressed in this section) is used to reduce the size of the routing table. This section
discusses the most significant problem related to the route summarization—the RIP-2 routing
table is huge. Two of the most common causes for this are as follows:
• Autosummarization is off.
• ip summary-address is not used.
Figure 3-38 shows a network setup that could produce a large routing table.
Figure 3-38 Network Setup That Could Generate a Large Routing Table

131.108.1.0/24
131.108.2.0/24
.1 131.108.1.0/24 131.108.3.0/24
.2

Router 1 Router 2

Problem: RIP-2 Routing Table Is Huge—

Cause: Autosummarization Is Off
When a RIP update crosses a major network, it summarizes to the classful boundary. For
example, 131.108.1.0, 131.108.2.0, and 131.108.3.0 will be autosummarized to 131.108.0.0/16
110 Chapter 3: Troubleshooting RIP

when advertised to a router with no 131.108.X.X addresses on its inter-faces. Disabling the
autosummarization feature increases the size of the routing table. In some situations, this feature
must be turned off (for example, if discontiguous networks exist, as discussed earlier).
Figure 3-39 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-39 Flowchart to Resolve a Large RIP-2 Routing Table

RIP-2 routing table is huge.

Auto-summarization can
be disabled in RIP-2 if
desired for routing table
entry granularity. This
Is autosummarization Not sure produces more routing
turned off?
table entries. Go to
“Debugs and Verification”
section.
No

Go to
next
cause.

Debugs and Verification

Example 3-103 shows the configuration on R2 that produces this problem. In this config-
uration, R2 has autosummary turned off.
Example 3-103 Disabling Autosummarization Under RIP for R2
R2#
router rip
version 2
network 132.108.0.0
network 131.108.0.0
no auto-summary

Example 3-104 shows R1’s routing table. This routing table has only four routes, but in a
real network with the configuration in Example 3-103, there could be several hundred
routes. R1 is receiving every subnet of 131.108.0.0/16. In this example, these are only three,
but it can be much, much worse.
Example 3-104 Router R1 Routing Table Shows Subnetted Routes in the Routing Table
R1#show ip route rip
131.108.0.0/24 is subnetted, 3 subnets
R 131.108.3.0 [120/1] via 132.108.1.2, 00:00:24, Serial3
R 131.108.2.0 [120/1] via 132.108.1.2, 00:00:24, Serial3
R 131.108.1.0 [120/1] via 132.108.1.2, 00:00:24, Serial3
R1#
 Problem: RIP-2 Routing Table Is Huge— Cause: ip summary-address Is Not Used 111

Solution
Because the autosummarization feature is disabled under the RIP configuration of R2, R1
sees the subnetted routes in the routing table. When this feature is enabled, all the subnetted
routes will go away.
Example 3-105 shows the altered configuration of R2. In this configuration, autosummarization
is on, to reduce the size of the routing table. Because this is the default, you will not see it in the
configuration. The command to enable autosummarization is auto-summary under router rip.
Example 3-105 R2 Uses Autosummarization to Reduce Routing Table Size
R2#
router rip
version 2
network 132.108.0.0
network 131.108.0.0

Example 3-106 shows the reduced size of the routing table.

Example 3-106 Autosummary Reduces the Routing Table Size for Router R1
R1#show ip route rip
R 131.108.0.0/16 [120/1] via 132.108.1.2, 00:00:01, Serial3
R1#

Problem: RIP-2 Routing Table Is Huge—

Cause: ip summary-address Is Not Used
Figure 3-40 shows the network setup that could produce a large routing table.
Figure 3-40 Network Setup That Could Generate a Large Routing Table

131.108.1.0/24
131.108.2.0/24
.1 131.108.4.0/24 131.108.3.0/24
.2

Router 1 Router 2

Figure 3-40 shows that R2 is announcing several subnets of 131.108.0.0 network. Notice
that the link between R1 and R2 is also part of the 131.108.0.0 network, so autosummar-
ization cannot play any role to solve the problem of receiving a subnet route that could be
summarized. The autosummarization feature could have worked only if the R1, R2 link was
in a different major network.
Figure 3-41 shows the flowchart to follow to solve this problem based on this cause.
112 Chapter 3: Troubleshooting RIP

Figure 3-41 Flowchart to Resolve a Large RIP-2 Routing Table

RIP-2 routing table is huge.

When only one major
network is in use
throughout the
internetwork in RIP-2,
autosummary does not
reduce the number of
Is the ip summary-address route entries in the table.
Not sure
command configured? Manual summarization
(via the ip summary-
address command) is
necessary to control the
Yes size of the routing table.
Go to “Debugs and
Verification” section.
Go to
next
problem.

Debugs and Verification

Example 3-107 shows that in the configuration of R2, the ip summary-address command
is not used under the Serial 1 interface to summarize the routes.
Example 3-107 R2’s Serial Interface Is Not Configured to Summarize Routes
R2#
interface Serial1
ip address 131.108.4.2 255.255.255.0
!
router rip
version 2
network 131.108.0.0

Example 3-108 shows the routing table of R1. In this example, there are only three routes.
In a real network, however, the number could be worse based on the configuration in
Example 3-107.
Example 3-108 R1 Routing Table Shows Subnetted Routes
R1#show ip route rip
131.108.0.0/24 is subnetted, 3 subnets
R 131.108.3.0 [120/1] via 131.108.4.2, 00:00:04, Serial3
R 131.108.2.0 [120/1] via 131.108.4.2, 00:00:04, Serial3
R 131.108.1.0 [120/1] via 131.108.4.2, 00:00:04, Serial3

R1#

Solution
In the situation described in the preceding section, autosummary is on but is not helpful
because the whole network is within one major network. Imagine a network with Class B
address space with thousands of subnets. Autosummary cannot play any role here because
 Troubleshooting RIP Redistribution Problems 113

no major network boundary is crossed. A new feature of summarization was introduced in

RIP starting with Cisco IOS Software Release 12.0.7T. This feature is similar to EIGRP
manual summarization.
Example 3-109 shows the new configuration that solves this problem. This configuration
reduces the size of the routing table. This command can be used with different masks so that,
if a network has contiguous blocks of a subnet, the router could be configured to summarize
subnets into smaller blocks. This then would reduce the routes advertised to the RIP network.
Example 3-109 Manual Summarization with RIP
R2#:
interface Serial1
ip address 131.108.4.2 255.255.255.0
ip summary-address rip 131.108.0.0 255.255.252.0
!
router rip
version 2
network 131.108.0.0

Based on the preceding configuration, R2 will summarize the RIP route on the Serial 1 interface.
Any network subnet that falls in the 131.108.0.0 network will be summarized to one 131.108.0.0
major network, and its mask will be 255.255.252.0. This means that R2 will announce only a
single summarize route of 131.108.0.0/22 and will suppress the subnets of 131.108.0.0.
Example 3-110 shows the routing table of Router R1 with a reduced number of entries as
a result of summarization.
Example 3-110 R1’s Routing Table Is Reduced as a Result of Summarization
R1#show ip route rip
R 131.108.0.0/22 [120/1] via 131.108.4.2, 00:00:01, Serial3
R1#

Troubleshooting RIP Redistribution Problems

This section talks about problems that can happen during redistribution in RIP. Redistribution
refers to the case when another routing protocol or a static route or connected route is being
injected into RIP. Special care is required during this process to avoid any routing loops. In
addition, metric (hop count) should be defined during this process, to avoid problems.
The most prevalent problem encountered with RIP redistribution is that redistributed routes
are not being installed in the routing table of the RIP routers receiving these routes. When
destination routes are not present in a routing table, no data can reach those destinations. The
most common cause of this is a metric that is not defined during redistribution into RIP.
In RIP, the metric for a route is treated as a hop count that shows the number of routers that
exist along this route. As discussed in Chapter 2, 15 is the maximum hop count that RIP
supports; anything greater than 15 is treated as the infinite metric and, upon receipt, is dropped.
114 Chapter 3: Troubleshooting RIP

Figure 3-42 shows the network setup that could produce the problem in which redistributed
routes do not get installed in the routing table of the receiver.
Figure 3-42 Network Vulnerable to Redistributed Route Problems

131.108.6.0/24
Router 3

OSPF 131.108.5.0/24

131.108.1.0/24

RIP
Router 1 Router 2

R1 and R3 are running OSPF in Area 0, whereas R1 and R2 are running RIP. R3 is
announcing 131.108.6.0/24 through OSPF to R1. In R1, OSPF routes are being redis-
tributed into RIP, but R2 is not receiving 131.108.6.0/24 through RIP.
Figure 3-43 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-43 Flowchart to Resolve Redistributed Route Problems

Redistributed RIP routes are not on the routing table of R2.

When redistributing into

RIP, the metric must be
defined between 1 and 15;
Is the default metric defined on otherwise, RIP advertises
Not sure
the redistribution router? the redistributed route with
a metric of 16 (infinity).
Go to “Debugs and
Verification” section.
No

Go to
next
problem.
 Troubleshooting RIP Redistribution Problems 115

Debugs and Verification

To troubleshoot this problem, you need to investigate whether R1 is receiving 131.108.6.0/24.
Example 3-111 shows that R3 is advertising 131.108.6.0/24 through OSPF to R1.
Example 3-111 show ip route Output Confirms That OSPF Is Working Fine and That R1 Is Receiving 131.108.6.0/
24
R1#show ip route 131.108.6.0
Routing entry for 131.108.6.0/24
Known via "ospf 1", distance 110, metric 20, type intra area

R1 must be configured to redistribute OSPF routes in RIP. Example 3-112 shows that R1 is
redistributing OSPF in RIP.
Example 3-112 Configuring R1 So That OSPF Is Redistributed in RIP
R1#
router rip
version 2
redistribute ospf 1
network 131.108.0.0

Now, you must first investigate R2 whether 131.108.6.0/24 is coming.

Example 3-113 shows that, in R2, 131.108.6.0/24 is not present in the RIP routing table.
Example 3-113 R2 Routing Table Does Not Reflect That 131.108.6.0/24 Is Present
R2#show ip route 131.108.6.0
% Subnet not in table

There are two basic ways to view this issue. The first is a simple show run on R1. The
second is to run the debug ip rip on R2 command to watch the process.
Example 3-114 shows the output of debug ip rip.
Example 3-114 debug ip rip Output Shows That 131.108.6.0/24 Is Inaccessible
R2#debug ip rip

RIP: received v2 update from 131.108.1.1 on Ethernet1

131.108.6.0/24 -> 0.0.0.0 in 16 hops (inaccessible)

Solution
In RIP-1 or RIP-2, 16 is considered to be an infinite metric. Any update with a metric
greater than 15 will not be considered for entry into the routing table.
In this example, the OSPF route in R1 for 131.108.6.0/24 has a metric of 20. When OSPF
is redistributed into RIP in R1, OSPF advertised 131.108.6.0/24 with a metric of 20, which
exceeds the maximum metric allowed in RIP. OSPF knows only cost as a metric, whereas
116 Chapter 3: Troubleshooting RIP

RIP utilizes hop count. No metric translation facility exists, so the administrator must
configure a metric to be assigned to redistributed routes.
Without the default metric configuration in R1, R2, upon receiving this update, complains
about the excessive metric and marks it as (inaccessible), as shown in Example 3-114.
To correct this problem, R1 needs to assign a valid metric through configuration when
doing the redistribution, as done for R1 in Example 3-115.
Example 3-115 Assigning a Valid Metric for Successful Redistribution
R1#
router rip
version 2
redistribute ospf 1 metric 1
network 131.108.0.0

In the configuration of Example 3-155, all redistributed routes from OSPF in RIP get a
metric of 1. This metric is treated as hop count by R2.
Example 3-116 shows that R2 is receiving the correct route with a metric of 1.
Example 3-116 debug ip rip Reveals That the New Configuration for R1 Works and That R2 Is Receiving the
Correct Route
R2#debug ip rip

RIP: received v2 update from 131.108.1.1 on Ethernet1

131.108.6.0/24 -> 0.0.0.0 in 1 hops

Example 3-117 shows that the route gets installed in the routing table of R2.
Example 3-117 R2 Routing Table Reflects That the Redistribution for Route 131.108.6.0/24 Is Successful
R2#show ip route 131.108.6.0
Routing entry for 131.108.6.0/24
Known via "rip", distance 120, metric 1

Troubleshooting Dial-on-Demand Routing

Issues in RIP
Dial-on-demand routing (DDR) is common in scenarios in which the ISDN or similar dialup
links are used as a backup link. When the primary link goes down, this backup link comes up.
RIP begins sending and receiving updates on this link as long as the primary link is down.
The dialup links can be used as a backup for the primary link in two ways:
• Use the backup interface command.
• Use a floating static route with a dialer list that defines interesting traffic.
 Problem: RIP Broadcast Is Keeping the ISDN Link Up 117

The first method is very simple: The command is typed under the dial interface, indicating
that it’s a backup for a primary interface.
The second method requires a floating static route with a higher administrative distance
than RIP (for example, 130 or above). It also requires defining interesting traffic that should
bring up the link. The RIP broadcast address of 255.255.255.255 must be denied in the
dialer list, so it shouldn’t bring up the link unnecessarily.
When running RIP under DDR situations, there are a number of issues to consider. Some
problems are related to the ISDN line or an async line in which RIP updates keep bouncing.
Some problems are related to the configuration. This section talks about the two most
common dialup problems:
• A RIP broadcast is keeping the link up.
• RIP updates are not going across the dialer interface.

Problem: RIP Broadcast Is Keeping the ISDN Link Up—

Cause: RIP Broadcasts Have Not Been Denied in the
Interesting Traffic Definition
ISDN links are typically used as backup links when primary links go down. Cisco IOS
Software requires that a router be instructed on which kind of traffic can bring up the ISDN
link and keep it up. Such traffic is referred to as interesting traffic. Network operators
typically want data traffic to be considered as interesting traffic to bring and keep the ISDN
link up. RIP or other routing protocol updates should not be defined as interesting traffic. If
this is not done, when the ISDN link comes up, it stays up as long as routing updates (RIP,
in this case) are sent on a regular basis. That is not be the desired behavior because ISDN
provides low-speed connectivity, and some data actually might go over the slow link even
though the primary faster link is available.
Figure 3-44 shows the network setup that produces these particular DDR issues.
Figure 3-44 Network Setup Vulnerable to DDR Problems

.13 .14
ISDN
BRI 3/0 BRI 3/0
Router 1 Router 2
192.168.254.12/30
118 Chapter 3: Troubleshooting RIP

Figure 3-45 shows the flowchart to follow to fix this problem.

Figure 3-45 Flowchart to Solve the RIP Broadcast Keeping the ISDN Link Up Problem

RIP updates are keeping the ISDN link up.

When RIP is run with

DDR, RIP broadcasts
need to be denied in the
Are RIP broadcasts permitted Not sure interesting traffic
as interesting traffic? definition to avoid keeping
the link up unnecessarily.
Go to ÒDebugs and
VeriÞcationÓ section.
No

Go to
next
problem.

Debugs and Verification

Example 3-118 shows the configuration on Router R1 that produces this problem. In this
configuration, only TCP traffic is denied. In other words, TCP traffic will not bring up and
sustain the link. RIP broadcasts utilize UDP port 520. Because the permit ip any any
command allows UDP port 520 to go through, RIP traffic is considered interesting traffic.
In Example 3-118, interface BRI 3/0 is configured to dial via the dialer-map command to
the router with an IP address of 192.168.254.14 (R2). The number of dial is 57654. The
dialer-group command defines dialer-list 1, which relies on access-list 100 to define the
interesting traffic. In this example, access-list 100 denies all TCP traffic and permits all IP
traffic. In other words, TCP traffic will not bring up and keep up the ISDN link, whereas
other traffic, including RIP, can do so.
Example 3-118 Configuring the ISDN Interface with dialer-group to Define Interesting Traffic
R1#
interface BRI3/0
ip address 192.168.254.13 255.255.255.252
encapsulation ppp
dialer map ip 192.168.254.14 name R2 broadcast 57654
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap

access-list 100 deny tcp any any

access-list 100 permit ip any any
dialer-list 1 protocol ip list 100
 Problem: RIP Broadcast Is Keeping the ISDN Link Up 119

Example 3-119 shows the output of show dialer, which shows that the reason for the link
coming up is a RIP broadcast.
Example 3-119 show dialer Output Reveals That a RIP Broadcast Is Keeping the ISDN Link Up
R1#show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=255.255.255.255)
Current call connected 00:00:08
Connected to 57654 (R2)

In Example 3-119, Dial reason section 255.255.255.255 is the destination IP address, which
is the address where RIP-1 advertisements will go on BRI1/1:1. Dial reason indicates that
the interesting traffic is RIP, which has caused this ISDN to dial in the first place.

Solution
When running RIP and DDR, define an access list for interesting traffic. In Example 3-118, the
access list is denying only the TCP traffic and permitting all the IP traffic. RIP uses an IP broadcast
address of 255.255.255.255 to send the routing updates. This address must be denied in the access
list so that RIP doesn’t bring up the link every 30 seconds. Denying 255.255.255.255 as a desti-
nation will block all broadcast traffic from bringing up the link. Blocking UDP port 520 will block
RIP-1 and RIP-2 updates specifically. When the link is up, RIP can flow freely across the link.
However, it will not keep the link up because it’s not part of the interesting traffic definition.
Example 3-120 shows the correct configuration change in Router R1. In this configuration,
all traffic destined to 255.255.255.255 address is denied. This covers all broadcast traffic,
so RIP-1 will not bring up the link after this configuration change.
Example 3-120 Correct Configuration for Router R1 in access -list 100 to Deny Traffic from the RIP-1 Broadcast
IP Address
R1#
access-list 100 deny ip any 255.255.255.255
access-list 100 permit ip any any
dialer-list 1 protocol ip list 100

One important thing to know here is that RIP-1 uses the 255.255.255.255 address for
sending RIP updates. RIP-2, on the other hand, uses 224.0.0.9. So, when dealing with
RIP-2, you need to deny traffic from the multicast address of 224.0.0.9 as interesting traffic,
as demonstrated in Example 1-21.
Example 3-121 Configuration for Router R1 in access-list 100 to Deny Traffic from the RIP-2 Broadcast IP Address
R1#
access-list 100 deny ip any 224.0.0.9
access-list 100 permit ip any any
120 Chapter 3: Troubleshooting RIP

Also, in a situation in which both RIP-1 and RIP-2 are running, both of these broadcast
addresses should be denied in the access list, as demonstrated in Example 3-122.
Example 3-122 Configuration for Router R1 in access-list 100 to Deny Traffic from the RIP-1 and RIP-2 Broadcast
IP Addresses
access-list 100 deny ip any 255.255.255.255
access-list 100 deny ip any 224.0.0.9
access-list 100 permit ip any any

Because both RIP-1 and RIP-2 use UDP port 520, it would be most efficient to deny this
port if RIP-1 and RIP-2 are not considered interesting traffic. Example 3-123 demon-
strates this.
Example 3-123 Configuring access-list 100 for R1 to Deny Traffic from the RIP-1 and RIP-2 UDP Port
R1#
access-list 100 deny udp any any eq 520
access-list 100 permit ip any any

The final configuration of R1 would like Example 3-124.

Example 3-124 Efficient Configuration of R1 when RIP-1 and RIP-2 Are Both Denied as Interesting Traffic
R1#
interface BRI3/0
ip address 192.168.254.13 255.255.255.252
encapsulation ppp
dialer map ip 192.168.254.14 name R2 broadcast 57654
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap
!
access-list 100 deny udp any any eq 520
access-list 100 permit ip any any
!
dialer-list 1 protocol ip list 100

Problem: RIP Updates Are Not Going Across the Dialer

Interface—Cause: Missing broadcast Keyword in a
dialer map Statement
When a dialer interface (ISDN, for example) comes up, you might want to run a routing
protocol over this link. Static routes might do the job, but in networks with a large number
of routes, static routes might not scale. Therefore, running a dynamic routing protocol such
as RIP is necessary. In some situations, the ISDN link might be up, but no routing informa-
tion is going across. Without a routing protocol, no destination addresses can be learned and
no traffic can be sent to those destinations. This problem must be fixed because the ISDN
interface is of no use when it is not carrying any traffic.
 Problem: RIP Updates Are Not Going Across the Dialer Interface 121

Figure 3-46 shows the flowchart to follow to solve this problem based on this cause.
Figure 3-46 Flowchart to Solve the RIP Updates Not Going Across the Dialer Interface Problem

RIP updates are not going across the dialer interface.

RIP uses broadcasts to

propagate its updates.
Is the broadcast keyword
When using DDR, add the
Not sure broadcast keyword to the
missing from the dialer map
statement? dialer map statements. Go
to “Debugs and Verification”
section.
No

Go to
next
problem.

Debugs and Verification

Example 3-125 shows the configuration on R1 that produces this problem.
Example 3-125 Configuring R1 When No Routing Updates Will Go on the ISDN Link
R1#
interface BRI3/0
ip address 192.168.254.13 255.255.255.252
encapsulation ppp
dialer map ip 192.168.254.14 name R2 57654
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap

Example 3-126 shows that RIP is sending the broadcast update toward R2. You can see that it’s
failing because of the encapsulation failed message. Also in Example 3-126, R1 is running
a debug ip packet command with access-list 100 to display only the UDP port 520 output.
RIP-1 and RIP-2 use UDP port 520 to exchange updates with other RIP running routers.
Example 3-126 Discovering Why RIP Routes Are Not Going Across an ISDN Interface
R1#
access-list 100 permit udp any any eq 520
access-list 100 deny ip any any

R1#debug ip packet 100 detail

IP: s=192.168.254.13 (local), d=255.255.255.255 (BRI3/0), len 46, sending
broad/multicast
UDP src=520, dst=520
IP: s=192.168.254.13 (local), d=255.255.255.255 (BRI3/0), len 72, encapsulation
failed
UDP src=520, dst=520
122 Chapter 3: Troubleshooting RIP

Solution
The root of the issue is RIP’s use of broadcasts to send its routing updates. In DDR, dialer
map statements are necessary to associate the next-hop protocol address to the phone
number dialed to get to the destination. The broadcast keyword must be used in the dialer
map statements; otherwise, the broadcast will encounter the encapsulation failure message
demonstrated by Example 3-126. To correct this problem, add the broadcast keyword in
the dialer map statement, as demonstrated in Example 3-127 for Router R1.
Example 3-127 Corrected Configuration of R1 to Enable RIP Updates to Go Across the ISDN Interface
interface BRI3/0
ip address 192.168.254.13 255.255.255.252
encapsulation ppp
dialer map ip 192.168.254.14 name R2 broadcast 57654
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap

Troubleshooting Routes Flapping Problem

in RIP
Running RIP in a complex environment can sometimes cause flapping of routes. Route
flapping refers to routes coming into and going out of the routing table. To check whether the
routes are indeed flapping, check the routing table and look at the age of the routes. If the ages
are constantly getting reset to 00:00:00, this means that the routes are flapping. Several
reasons exist for this condition. This section discusses one of the common reasons—packet
loss because the packet is dropping on the sender’s or receiver’s interface. The example in this
section considers Frame Relay because it is the most common medium in which this problem
occurs. The packet loss can be verified through the interface statistics by looking at the
number of packet drops and determining whether that number is constantly incrementing.
Figure 3-47 shows the network setup that can produce RIP route flapping.
Figure 3-48 shows the flowchart to follow to solve this problem.

Debugs and Verification

In a large RIP network, especially, in a Frame Relay environment, there is a high possibility
that RIP updates are lost in the Frame Relay cloud or that the RIP interface dropped the
update. Again, the symptoms can be present in any Layer 2 media, but Frame Relay is the
focus here. This situation causes RIP to lose a route for a while. If RIP does not receive a
route for 180 seconds, the route is put in a holddown for 240 seconds and then is purged.
This situation is corrected by itself (and time), but, in some cases, configuration changes
can be required. For example, consider the output in Example 3-128, where no RIP update
has been received for 2 minutes and 8 seconds. This means that four RIP updates have been
missed, and we are 8 seconds into the fifth update.
 Troubleshooting Routes Flapping Problem in RIP 123

Figure 3-47 Network Vulnerable to RIP Route Flapping

Hub

Frame Relay

Router 1 Router 2

Figure 3-48 Flowchart to Solving the RIP Route Flapping Problem

RIP routes are flapping.

When RIP does not

receive updates, or
receives updates showing
a network in a constant
Are there a large number of state of change from up to
Not sure down or vice versa, RIP
packet drops being reported by
router interfaces in the routes flap. Go to “Debugs
network? and Verification” section.

No

This is the end of

all the problems in
this chapter.

Example 3-128 Routing Table of the Hub Router Showing That the Last RIP Update Was Received 2:08
Minutes Ago
Hub#show ip route rip
R 155.155.0.0/16 [120/1] via 131.108.1.1, 00:02:08, Serial0
R 166.166.0.0/16 [120/1] via 131.108.1.1, 00:02:08, Serial0
124 Chapter 3: Troubleshooting RIP

Example 3-129 shows that there are a large number of broadcast drops on the interface.
Example 3-129 show interfaces serial 0 Output Reveals a Large Number of Broadcast Drops
Hub#show interfaces serial 0
Serial0 is up, line protocol is up
Hardware is MK5025
Description: Charlotte Frame Relay Port DLCI 100
MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 64/64, broadcasts sent/dropped 1769202/1849660, interface
broadcasts 3579215

Solution
The show interfaces serial 0 command further proves that there is some problem at the
interface level. Too many drops are occurring at the interface level. This is the cause of the
route flapping. In the case of Frame Relay, the Frame Relay broadcast queue must be tuned.
Tuning the Frame Relay broadcast queue is out of the scope of this book; several papers at
Cisco’s Web site discuss how to tune the Frame Relay broadcast queue.
In a non-Frame Relay situation, the input or output hold queue might need to be increased.
Example 3-130 shows that after fixing the interface drop problem, route flapping
disappears.
Example 3-130 Serial Interface Output After Adjusting the Broadcast Queue
Hub#show interfaces serial 0
Serial0 is up, line protocol is up
Hardware is MK5025
Description: Charlotte Frame Relay Port DLCI 100
MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/256, broadcasts sent/dropped 1769202/0, interface broadcasts
3579215

In Example 3-131, the show ip routes output displays that the routes are stable in the
routing table and that the timers are at a value lower than 30 seconds.
Example 3-131 show ip routes Output Reveals Stable RIP Routes
Hub#show ip route rip
R 155.155.0.0/16 [120/1] via 131.108.1.1, 00:00:07, Serial0
R 166.166.0.0/16 [120/1] via 131.108.1.1, 00:00:07, Serial0
This page intentionally left blank
This chapter covers the following key topics about Interior Gateway Routing Protocol (IGRP):
• Metrics
• Timers
• Split horizon
• Split horizon with poison reverse
• IGRP packet format
• IGRP behavior
• Default route and IGRP
• Unequal-cost load balancing in IGRP
 CHAPTER
4
Understanding Interior Gateway
Routing Protocol (IGRP)
In the mid-1980s, Cisco developed its own proprietary routing protocol, Interior Gateway
Routing Protocol (IGRP), as a solution to some of the shortcomings of RIP, such as the hop-
count limitation of 15.
Like RIP, IGRP is a distance vector protocol. However, IGRP calculates its composite metric
from a variety of variables, such as bandwidth and delay, and hop count is not considered in
the routing decision. IGRP uses variables such as interface bandwidth and delay, which reflect
a better picture of the network topology. This results in a more efficient method of routing
packets. Other advantages of IGRP over RIP include unequal-cost load sharing; a longer up-
date period than RIP, for better bandwidth usage; and a more efficient packet-update format.

Metrics
IGRP uses an equation to calculate its metrics. Metrics then are used by the router to favor a
particular route. In IGRP, the lower the value of the metric is, the more favorable the route is.
The IGRP metric equation takes into consideration the variables of bandwidth, delay, load, and
reliability of the link to calculate its metric. Equation 4-1 shows the IGRP metric equation.
Equation 4-132 IGRP Metric Equation
( K2 * BW ) K5
IGRP Metric = K1 * BW + -------------------------------- + K3 * Delay * ----------------------------
( 256 – Load ) ( Reli + K4 )

K1, K2, K3, K4, K5 = Constants

Default values: K1 = K3 = 1, K2 = K4 = K5 = 0
BW = 10 7 ⁄ ( min bandwidth along paths in kilobits per second )
Delay = ( Sum of delays along paths in milliseconds ) ⁄ 10
Load = Load of interface
Reli = Reliability of the interface

From the equation, the load variable is a value from 1 to 255, in which 255 indicates
100 percent saturation of the link and 1 indicates virtually no traffic. The reli variable
is also a value from 1 to 255, in which 1 indicates an unreliable link and 255 indicates
a 100 percent reliable link.
128 Chapter 4: Understanding Interior Gateway Routing Protocol (IGRP)

Referring to Equation 4-1, the term K5 /(Reli + K4) is used only if K5 is not equal to 0.
If K5 is equal to 0 (as the default), the term K5 /(Reli + K4) is ignored in the equation.
Variables K1 through K5 are constant numbers used in the equation. The default value of the
K values are: K1 = K3 = 1, K2 = K4 = K5 = 0. The IGRP metric equation then reduces to this:

IGRP ,Metric = BW + Delay

Therefore, by default, IGRP considers only the bandwidth and the delay of the link to
calculate its metrics. The network administrator can change the default K value to other
numbers so that other components of the metric equation, such as load and reliability, can
be used. For example, if the network administrator wants to consider interface reliability as
one factor in routing the packet, the value of K5 would have to be a nonzero number;
however, such a change is highly not recommended.
The bandwidth variable is the minimum bandwidth along the path from the local router to
the destination, in kilobits per second, scaled by 107. The bandwidth associated with an
interface is a static value assigned by the router or a network administrator; it is not a
dynamic value that changes with throughput. The minimum bandwidth is obtained by
comparing the interfaces along the paths to the destination network. For example, a network
that needs to traverse a T1 link and an Ethernet link will have a minimum bandwidth of
1544 kbps. Notice that the bandwidth on a regular serial interface is assumed to be T1 with
a speed of 1544 kbps.
The delay variable is the sum of all delays along the interfaces crossed in the path to the des-
tination, in microseconds, divided by 10. Therefore, the delay variable used in IGRP metric
equation has the unit of tens of microseconds. Like the bandwidth variable, the delay asso-
ciated with each interface is a static value assigned by the router or a network administrator;
it is not a dynamic value that changes with different traffic pattern. Table 4-1 lists router
default bandwidth and delay values for some common interfaces.

Table 4-1 Router Default Bandwidth and Delay Values for Common Interfaces
Media Bandwidth Delay

Ethernet 10,000 kbps 1000 microseconds

Fast Ethernet 100,000 kbps 100 microseconds

Gigabit Ethernet 1,000,000 kbps 10 microseconds

FDDI 100,000 kbps 100 microseconds

Token Ring (16 M) 16,000 kbps 630 microseconds

T1 1544 kbps 20,000 microseconds

 Timers 129

IGRP metric calculation is illustrated in the following example. Consider the network in
Figure 4-1.

Figure 4-1 IGRP Metric Calculation Example

BW = 100,000 kbps BW = 10,000 kbps

Delay = 100 microseconds Delay = 1000 microseconds

BW = 1544 kbps Router 3

Delay = 20,000 microseconds

Network X
T1 link
Router 1 Router 2

Fast Ethernet Ethernet

Now calculate the IGRP metric to Network X from Router 3’s perspective. The lowest
bandwidth to Network X is the T1 link with a total delay of 21,100 microseconds
(100 micro-seconds + 20,000 microseconds + 1000 microseconds). Assume that all the
K constant values are default values. Therefore, only the bandwidth and delay values
are considered in calculating the IGRP metric. BW = 107/1544 = 6476 and Delay =
21,100/10 = 2110. This yields IGRP metric = BW + Delay = 6476 + 2110 = 8586.
Therefore, from Router 3’s perspective, the IGRP metric to Network X is 8586.

Timers
Because IGRP is a distance vector protocol in which routing updates are sent periodically,
the different timers are especially important because they control how fast the routes are
learned and deleted. Ultimately, these timers determine the network convergence time,
which is the time that it takes for all the routers in the network to realize that a certain
network has been added or deleted. The IGRP timers are the same as RIP; they are
discussed in this list:
• Update—IGRP sends updates over the broadcast address of 255.255.255.255, with
IP protocol number 9. The update timer is the periodic timer in which routing updates
are sent; it is the time between each routing update interval. This value is set to 90
seconds, by default, and is configurable. In other words, the router sends its entire
routing updates every 90 seconds, by default.
• Invalid—When the router stops receiving routing updates within the invalid timer, the
routes become invalid. This is set to 270 seconds, by default.
130 Chapter 4: Understanding Interior Gateway Routing Protocol (IGRP)

• Hold-down—This is the time used to suppress the defective routes to be installed in

the routing table. The default time is 280 seconds.
• Flush—This is the time when the route is removed from the routing table. This is set
to 630 seconds, by default.
The default value for the IGRP update timer is 90 seconds, compared to the default of 30
seconds for the RIP update timer. This allows IGRP to use less bandwidth for periodic
updates; however, the trade-off is that IGRP has a slower convergence time than RIP. All
the timers mentioned here are configurable. The command to change the timer is timers
basic update invalid holddown flush. However, changing the timer on only one router in the
network could result in a network convergence problem. Changing the timers is not
recommended.
If the network changes, such as after deleting or adding a network, IGRP and RIP use Flash
updates. In other words, IGRP and RIP send instant updates to all their neighbors as soon
as a network change is detected. For example, if a router’s Ethernet interface goes down,
the router immediately sends a Flash update to its neighbors that its Ethernet network is no
longer available. After receiving the Flash update, the neighbors immediately put the
Ethernet network into hold-down state.

Split Horizon
Split horizon is a technique used to avoid routing loops. With split horizon, the router does
not advertise a route over the interface in which the route is learned from. For example, in
Figure 4-1, Router 1 receives an update about Network X from Router 2 over the serial
interface. If split horizon is enabled, Router 2 will not advertise the Network X route back
to Router 1 over the same serial interface. If split horizon is disabled, Router 2 will advertise
Network X back to Router 1. When Network X becomes unavailable in Router 2, Router 2
believes that Router 1 still has a valid route to Network X and sends the packet destined to
Network X toward Router 1, which will be dropped.

Figure 4-2 An Example of the Split Horizon Technique

Network X

Router 1 Router 2

Split Horizon with Poison Reverse

Another technique to avoid routing loop is split horizon with poison reverse. Using this
technique, routes learned on an interface are advertised back on the same interface with an
IGRP metric of infinity. This is called poison update. When the router receives the poison
 IGRP Behavior 131

update, it considers the route as invalid. For example, in Figure 4-2, Router 1 receives
an update for Network X from Router 2. With poison reverse, this specific route is ad-
vertised back to Router 2, but with an IGRP metric of 4,294,967,295, which indicates
infinity. Because Router 2 receives the poison update from Router 1, Router 2 does not
consider Router 1 as a valid path to reach Network X, thus preventing the possibility of
a routing loop.

IGRP Packet Format

Figure 4-3 shows the IGRP packet format. In this figure, you can see that IGRP updates
provide more information than RIP and, at the same time, are more efficient. None of the
fields in an IGRP packet is left unused; after the 12-octet header, each routing entry is filled
one after another. Therefore, IGRP does not pad the update packet to force a 32-bit word
boundary. With this efficient design, IGRP can carry a maximum of 104 fourteen-octet
entries. Therefore, with its MTU size of 1500 bytes, IGRP can carry more routes per packet
than RIP can.

Figure 4-3 IGRP Packet Format

0 8 16 24 31
Version OPCode Edition Autonomous system number

Number of interior routes Number of system routes

Number of exterior routes Checksum

Destination Delay

Delay Bandwidth

Bandwidth MTU Reliability

Load Hop count Destination

Destination Delay

Bandwidth MTU

MTU Reliability Load Hop count

IGRP Behavior
Distance vector protocols are protocols that solely depend on neighbor routing
advertisements to determine the best path to a destination. The advantage of the
distance vector protocols is their simplicity to implement. However, because of the
long convergence time, IGRP is not suitable for large networks. IGRP and RIP are
132 Chapter 4: Understanding Interior Gateway Routing Protocol (IGRP)

both classical distance vector protocols. Although IGRP and RIP differ in metric
calculation update timers, they exhibit the same behavior when it comes to sending
and receiving updates.
IGRP sends its entire routing update over the broadcast address of 255.255.255.255, with the
IP Protocol field set to 9. IGRP handles discontiguous network and variable-length subnet
masking (VLSM) in exactly the same way that RIP does. IGRP does not support discon-
tiguous networks; in these networks, IGRP autosummarizes over a major network boundary.
Therefore, the subnet information is not advertised to the remote site, causing routing
problems. Because IGRP does not send subnet mask information as part of the routing update,
IGRP does not support VLSM.

Default Route and IGRP

In Cisco routers, IGRP does not recognize the 0.0.0.0/0 route as the default route. It uses
its own method of propagating default route with the ip default-network command.
The ip default-network command specifies a major network address and flags it as a
default network. This major network could be directly connected, defined by a static route,
or discovered by a dynamic routing protocol. The network specified by the ip default-
network command must be in the routing table before the command takes effect. If the
route specified is not in the routing table, no default route will be propagated. Figure 4-4
demonstrates how the ip default-network command works.

Figure 4-4 Propagating a Default Route for IGRP

192.168.1.x

10.x.x.x
Remote site network
DS3 link
Router 1 Router 2

In Figure 4-4, Router 1 is connected to the remote site through a DS-3 link. Router 1 now
wants to send a default route to Router 2 and to all the routers in the remote site network.
In IGRP, the route to 0.0.0.0 is not recognized as a default route; instead, Router 1 must
configure ip default-network 192.168.1.0 to flag the route 192.168.1.0 as the default route.
Router 1 will send a routing update of 192.168.1.0 and will flag it as a default route. When
 Unequal-Cost Load Balancing in IGRP 133

the routers in the remote site network receive the update for 192.168.1.0, they will mark
it as default route and will install the route to 192.168.1.0 as the gateway of last resort.

Unequal-Cost Load Balancing in IGRP

IGRP and RIP provide the capability to install up to six parallel equal-cost paths for load
balancing. IGRP has an added feature that RIP does not have—the capability to do unequal-
cost load balancing, the capability to load-balance traffic over multiple paths that do not
have the same metric to the destination. The advantage of this feature is that it offers the
flexibility of load balancing, thus making more efficient use of the link. IGRP uses the
variance command to perform unequal-cost load balancing.
Before unequal-cost load balancing can take place, however, two rules must apply:
10 The neighboring router utilized as an alternate pathway must be closer to the
destination. (That is, the neighboring router’s metric to the destination must be a
smaller metric than that of the local router for a given destination.)
11 The metric advertised by the neighboring router must be less than the variance of
the local router’s metric to the destination.

Variance = ,,Variance ,Factor × Local Metric

Consider the network in Figure 4-5.

Figure 4-5 Unequal-Cost Load Balancing Example

Router 3
S0 1544 kbps
S0

S1
Router 1 256 kbps S1 Router 2
133.33.0.0

When Router 1 calculates its IGRP metrics to Router 3, the metric going through the
1544 kbps link is as follows:

IGRP ,metric = 6476 + 2100 = 8576

The metric going through the 256 kbps link is as follows:

IGRP ,metric = 3902 ( 3902 ) + 2100 = 41,162

134 Chapter 4: Understanding Interior Gateway Routing Protocol (IGRP)

Without unequal-cost load balancing, IGRP will simply select the 1544 kbps link to
forward packets to Router 3, as shown in the output in Example 4-1.
Example 4-1 Output of Routing Table in Router 1 Without Unequal-Cost Load Balancing
Router_1#show ip route 133.33.0.0
Routing entry for 133.33.0.0/16
Known via "igrp 1", distance 100, metric 8576
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 192.168.6.2 on Serial0, 00:00:20 ago
Routing Descriptor Blocks:
* 192.168.6.2, from 192.168.6.2, 00:00:20 ago, via Serial0
Route metric is 8576, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

To use the unequal-cost load balancing feature of IGRP, you use the variance command.
Variance is a multiplier in which a metric might be different from the lowest metric to a
route. The variance value must be of integer value; the default variance value is 1, meaning
that the metrics of multiple routes must be equal to load-balance.
In Example 4-1, the metric through the 256 kbps link is 4.8 times larger than the metric
through the 1544 kbps link. Therefore, for the 256 kbps link to be considered in the routing
table, a variance of 5 must be configured in Router 1. The configuration in Router 1 is
simply variance 5 under the igrp command. The output from the show ip route command
in Example 4-2 displays that Router 1 is installing both links in its routing table.
Example 4-2 Output of show ip route in Router 1 After Implementing Unequal-Cost Load Balancing by Adding
the variance Command
Router_1#show ip route 133.33.0.0
Routing entry for 133.33.0.0/16
Known via "igrp 1", distance 100, metric 8576
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 10.1.1.2 on Serial1, 00:01:02 ago
Routing Descriptor Blocks:
* 192.168.6.2, from 192.168.6.2, 00:01:02 ago, via Serial0
Route metric is 8576, traffic share count is 5
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
10.1.1.2, from 10.1.1.2, 00:01:02 ago, via Serial1
Route metric is 41162, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 256Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Notice in Example 4-2 that the route through Serial 0 has a traffic share count of 5, com-
pared to a traffic share count of 1 through Serial 1. This indicates that the router will send
five packets over Serial 0 for every packet sent over Serial 1.
 Review Questions 135

Summary
IGRP is a distance vector routing protocol, like RIP. It was developed as a solution to some
of the disadvantages of RIP, such as its hop-count limitation and frequent update timer.
Unlike RIP, IGRP uses bandwidth and delay as the primary variables in calculating its
metrics. Because IGRP and RIP are considered classical distance vector routing protocols,
some of their behavior is exactly the same. As a result, neither IGRP nor RIP can support
discontiguous networks and VLSM. However, one of the biggest advantages of IGRP over
RIP is the capability to do unequal-cost load balancing.

Review Questions
1 What is the default update timer period for IGRP?
2 What variables does IGRP use to calculate its metrics by default?
3 What are the K values in the IGRP metric equation?

4 What command is used in IGRP to perform unequal-cost load balancing?

5 What is split horizon? Does IGRP support this feature?

6 Does IGRP support VLSM?

This chapter covers the following key topics:
• Troubleshooting IGRP route installation
• Troubleshooting IGRP route advertisement
• Troubleshooting IGRP redistribution problems
• Troubleshooting dial-on-demand (DDR) routing issues in IGRP
• Troubleshooting route flapping in IGRP
• Troubleshooting variance problem
 CHAPTER
5

Troubleshooting IGRP
This chapter discusses common problems in IGRP networks and how to solve those
problems. IGRP is a Cisco proprietary protocol. IGRP fixes some of the problems with RIP,
but still it has similar characteristics as RIP. IGRP also does not support discontiguous
networks or VLSM; however, it does have good features, such as variance, and its metric is
based on bandwidth and delay instead of hop count.
Most of the issues in IGRP are very similar to RIP, so those issues are repeated here again
in this chapter from an IGRP perspective. As mentioned in Chapter 3, “Troubleshooting
RIP,” you must be careful with the debugs when dealing with large networks (for example,
more than 100 subnets in a network) because debugging sometimes can have an adversarial
effect on a router. The flowcharts that follow document how to address common problems
with IGRP with the methodology used in this chapter.
138 Chapter 5: Troubleshooting IGRP

Flowcharts to Solve Common IGRP Problems

Troubleshooting IGRP Route Installation

IGRP Routes Are Not in the Routing Table

Not sure
Is IGRP enabled on the interface? Go to page 143.

Yes
Not sure
Is the interface of the receiving router up/up? Go to page 147.

Yes
Not sure
Is the distribute-list in blocking the routes? Go to page 149.

No
Not sure
Is the access list blocking the IGRP source Go to page 151.
address?
No
Is the access list blocking the IGRP Not sure
broadcast? Go to page 153.

No
Not sure
Is this a discontiguous subnet? Go to page 155.

No

Is the IGRP update coming from a valid Not sure

Go to page 159.
source?
No
Is Layer 2 media propagating IGRP Not sure
broadcast? Go to page 161.

No

Is senderÕs AS number the same as the local Not sure

Go to page 163.
AS number?
No

Go to next problem flowchart.

Troubleshooting IGRP Route Installation

IGRP Is Not Installing All Possible Equal-Cost Paths

Are there more than four possible equal-cost Not sure

Go to page 166.
paths?
No

Go to next problem flowchart.

 Flowcharts to Solve Common IGRP Problems 139

Troubleshooting IGRP Route Advertisement

Sender Is Not Advertising IGRP Routes

Not sure
Is IGRP enabled on the interface? Go to page 169.

Yes
Not sure
Is the outgoing interface up/up? Go to page 171.

Yes
Not sure
Is the distribute-list out blocking the routes? Go to page 173.

No
Not sure
Is the advertised network interface up/up? Go to page 175.

Yes
Not sure
Is the outgoing interface defined as passive? Go to page 176.

No
Not sure
Is the broadcast capability broken? Go to page 178.

No

Is the neighbor statement configured Not sure

Go to page 180.
properly?
Yes
Not sure
Is the advertised subnet VLSM? Go to page 182.

No
Not sure
Is split horizon enabled on the interface? Go to page 184.

No

Go to next problem flowchart.

Candidate Default Is Not Being Advertised

Is default-network statement enabled? Not sure Go to page 188.

Yes

Go to next problem flowchart.

140 Chapter 5: Troubleshooting IGRP

Troubleshooting IGRP Redistribution Problems

Redistributed Routes Are Not Getting Installed in the
Routing Table

Is the default metric defined on the Not sure

redistributing router? Go to page 191.

Yes
Go to next problem
flowchart.

Troubleshooting Dial-on-Demand Routing (DDR)

Issues in IGRP
IGRP Broadcast Is Keeping the ISDN Link Up

Is IGRP broadcast permitted as interesting Not sure

Go to page 194.
traffic?
No
Go to next problem
flowchart.

IGRP Updates Are Not Going Across the Dialer

Interface

Is the broadcast keyword missing from the Not sure

dialer map statement? Go to page 197.
No
Go to next problem
flowchart.
 Flowcharts to Solve Common IGRP Problems 141

Troubleshooting Route Flapping Problem in

IGRP
IGRP Routes Are Flapping

Are there any large packet drops on the Not sure

senderÕs or receiverÕs interface? Go to page 199.

No

Go to next problem
flowchart.

Troubleshooting Variance Problem

IGRP Not Using Unequal-Cost Path for Load Balancing

Is the variance command configured with the Not sure

correct multiplier? Go to page 202.

Yes

End of chapter problems.

142 Chapter 5: Troubleshooting IGRP

Troubleshooting IGRP Route Installation

This section discusses the most common scenarios that can prevent IGRP routes from
getting installed in the routing table. This is the most useful section in this chapter because
the most common problem in IGRP is that routes are not in the routing table. If a specific
destination is not in the routing table, the packet destined for that address will be dropped.
The easiest way to find out whether a specific route is in the routing table is with the show
ip route x.x.x.x command, where x.x.x.x is the specific destination (that is, an IP address of
a host or a server).
Three possible sources exist for problems when routes do not to get installed in the routing table:
• Receiver problem
• Intermediate media problem (Layer 2)
• Sender problem
Receiver problems refer to when the routing update was sent by the sender. Because of
some problems at the receiver’s end, the receiving router cannot install the routes in the
routing table.
Intermediate media problems actually refer to any medium that is in the middle of two routers
exchanging routing updates. In this case, the sender already has sent the routing update, but the
receiving router never received it because the medium in the middle is experiencing some kind
of problem. There could be various forms of media, from a simple hub to a complex switch.
The sender’s problem refers to an instance in which the routing updates are never sent by the
sender, so the receiving router never receives the routing updates. The sender’s problem is
discussed in the section “Troubleshooting IGRP Routes Advertisement.” Two problems exist
in IGRP routes installation:
• IGRP routes are not in the routing table.
• IGRP is not installing all equal-cost-path routes.
In the first case, IGRP is not installing a particular route or is not installing any routes in the
routing table. However, in the second case, there are some routes in the routing table for a
particular destination, but some of the routes are not being installed. These two problems
are discussed in detail in the sections that follow.

Problem: IGRP Routes Not in the Routing Table

For a router to send the packets to a particular destination, the router must have a routing entry
for that destination subnet in the routing table. If there are no entries in the routing table, the
packet will be dropped.
 Problem: IGRP Routes Not in the Routing Table 143

Example 5-1 shows that the routing table entry of R2 does not produce any IGRP routes for
a particular destination of 131.108.2.0.
Example 5-1 R2 Routing Table Shows No IGRP Route for 131.108.2.0
R2#show ip route 131.108.2.0
% Subnet not in table
R2#

The most common possible causes of this problem are as follows:

• network statement is missing or incorrect.
• Layer 2 is down.
• The distribute list is blocking the route.
• The access list is blocking the IGRP source address.
• The access list is blocking the IGRP broadcast.
• This is a discontiguous network.
• The source is invalid.
• A Layer 2 problem (switch, Frame Relay, or other Layer 2 medium) has occurred.
• A sender AS mismatch has occurred.
• A sender’s problem has occurred (discussed in the “Troubleshooting IGRP Routes
Advertisement” section).
Figure 5-1 shows the setup in which Router 1 and Router 2 are running IGRP in between.

Figure 5-1 Example Topology for the “IGRP Routes Not in the Routing Table” Problem

131.108.2.0/24 .1 131.108.1.0/24 131.108.3.0/24

.2
E0 E0
Router 1 Router 2

IGRP Routes Not in the Routing Table—Cause: Missing or Incorrect

network Statement
Several reasons exist for IGRP routes not being in the routing table. The one discussed here
is a missing or incorrect network statement in the router’s configuration. Other causes are
mentioned at the beginning of this section. Just glancing through the flowchart might tell
you the cause that fits your problem the most.
In the case of a wrong or missing network statement, IGRP will not be capable of receiving
any updates on a particular interface. Recall from Chapter 3 that a network statement has
two purposes:
• To enable IGRP on the interface for sending and receiving IGRP routes
• To advertise that network in IGRP updates
144 Chapter 5: Troubleshooting IGRP

Figure 5-2 shows the flowchart to follow to solve this problem.

Figure 5-2 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

IGRP must be enabled on

the interface to send and
Is IGRP enabled on the Not sure receive IGRP updates. Go
interface? to Debugs and Verification
section.
Yes

Go to
next
cause.

Debugs and Verification

Example 5-2 shows the configuration for Router R2. Please note that the loopback interface
is used in this example and many other examples throughout this chapter. If the loopback
interface is replaced with any other interface, it will not change the meaning. You should
treat the loopback as any interface that is up and functional and that has a valid IP address.
Example 5-2 R2 Configuration
interface Loopback0
ip address 131.108.3.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router IGRP 1
network 131.107.0.0

The network 131.108.0.0 statement is missing from R2’s configuration.

Example 5-3 shows the output of the show ip protocols command, which indicates that the
routing information source also is not displaying 131.108.1.1 as a gateway. A gateway is a
next-hop address from which routing updates are received. If there is no entry under the
gateway, either nothing is being received or nothing is being installed from that neighbor.
Example 5-3 show ip protocols Command Output on R2
R2#show ip protocol
Routing Protocol is "IGRP 1"
Sending updates every 30 seconds, next due in 82 seconds
 Problem: IGRP Routes Not in the Routing Table 145

Example 5-3 show ip protocols Command Output on R2 (Continued)

Invalid after 270 seconds, hold down 280, flushed after 630
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
IGRP maximum hopcount 100
IGRP maximum metric variance 1
Redistributing: igrp 1
Routing for Networks:
131.107.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 100)

Example 5-4 shows the debug ip packet 100 detail output. In this debug, R2 is receiving
the IGRP packets but is ignoring them because IGRP is not enabled on E0 interface. Note
that protocol 9 is reserved for IGRP. This is because no network statement for 131.108.0.0
exists under router igrp 1.
Example 5-4 debug ip packet 100 detail Command Output on R2
R2# debug ip packet 100 detail
IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 32, rcvd 2, proto=9

R2#show debug
Generic IP:
IP packet debugging is on (detailed) for access list 100
IP routing:
IGRP protocol debugging is on
IGRP event debugging is on

R2#show access-list 100

Extended IP access list 100
permit ip any host 255.255.255.255 (3 matches)

Solution
When configured, the network statement does two things:
• Enables IGRP on the interface to send and receive IGRP updates
• Advertises that network in IGRP update packets
Because the network statement is missing on Router 2, the router ignores IGRP updates
arriving on the Ethernet0 interface, as seen in the debug output. This problem also can
happen if you incorrectly configure the network statement. For example, instead of con-
figuring 209.1.1.0, you configure 209.1.0.0 assuming that 0 will cover anything in the third
octet. IGRP is a classful protocol and assumes that the network statements are classful as
well. If a classless statement is configured instead, IGRP will not function properly.
To correct this problem, you must add a properly configured network statement in the
configuration.
146 Chapter 5: Troubleshooting IGRP

Example 5-5 shows the new configuration for Router R2 that solves this problem.
Example 5-5 Adding a network Statement to R2 to Populate the Routing Table with IGRP Routes
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router igrp 1
no network 131.107.0.0
network 131.108.0.0

Example 5-6 shows the output of show ip protocols on R2, which displays the gateway
information after inserting the proper network statement.
Example 5-6 show ip protocols Command Output on R2 After Corrected network Statement
R2#show ip protocols
Routing Protocol is "IGRP 1"
Sending updates every 30 seconds, next due in 82 seconds
Invalid after 270 seconds, hold down 280, flushed after 630
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
IGRP maximum hopcount 100
IGRP maximum metric variance 1
Redistributing: igrp 1
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
131.108.1.1 100 00:00:09
Distance: (default is 100)

Example 5-7 shows the output of show ip route, which shows that Router R2 is learning
the IGRP route after the configuration change.
Example 5-7 show ip route Command Output Confirms That R2 Is Learning the IGRP Route
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
 Problem: IGRP Routes Not in the Routing Table 147

IGRP Routes Not in the Routing Table—Cause: Layer 1/2 Is Down

One of the causes for routes not being installed in the routing table is that Layer 1 or Layer 2 is
down. If this is the case, it is not a RIP problem. Layer 1 or 2 could be down for several reasons.
The following is the list of most common thing to check if an interface or line protocol is down:
• Unplugged cable
• Loose cable
• Bad cable
• Bad transceiver
• Bad port
• Bad interface card
• Layer 2 problem at the telco in case of a WAN link
• Missing clock statement in case of back-to-back serial connection
Figure 5-3 shows the flowchart to follow to solve this problem.

Figure 5-3 Problem Resolution Flowchart

IGRP routes are not in the routing table of R2.

IGRP will not receive any

Is the interface of the routing updates if Layer 2
receiving Not sure
is down. Go to Debugs and
router up/up? Verification section.

Yes

Go to
next
cause.

Debugs and Verification

The output in Example 5-8 indicates that the Ethernet interface’s line protocol is down,
which is a sign that there is something wrong at Layer 2.
Example 5-8 show interfaces Command Output Reveals That the Line Protocol Is Down
R2#show interfaces ethernet 0
Ethernet0 is up, line protocol is down
Hardware is Lance, address is
0000.0c70.d41e (bia 0000.0c70.d41e)
Internet address is 131.108.1.2/24
148 Chapter 5: Troubleshooting IGRP

Example 5-9 shows the output of debug ip igrp events and debug ip igrp transaction. The
output shows that R2 is not sending or receiving any IGRP updates because Layer 2 is down.
Example 5-9 debug ip igrp events and debug ip igrp transaction Command Output Reveals That R2 Is Not
Sending or Receiving IGRP Updates
R2#debug ip igrp events
IGRP event debugging is on
R2#debug ip igrp transaction
IGRP protocol debugging is on

R2#show debug
IP routing:
IGRP protocol debugging is on
IGRP event debugging is on

Solution
IGRP runs above Layer 2. IGRP cannot send or receive any routes if Layer 2 is down.
To correct this problem, you must fix the Layer 2 problem. The problem could be as simple
as loose cables, or it could be as complex as bad hardware, in which case the hardware must
be replaced.
Example 5-10 shows the output of show interfaces ethernet 0 after fixing the Layer 2 problem.
Example 5-10 show interfaces ethernet 0 Command Output After Restoring Layer 2 Connectivity
R2#show interfaces ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c70.d41e (bia 0000.0c70.d41e)
Internet address is 131.108.1.2/24

Example 5-11 shows the output of show ip protocols, which also shows that the problem is fixed.
Example 5-11 show ip protocols Command Output Verifies That the Gateway Is Restored After Fixing Layer 2
Connectivity
R2#show ip protocols
Routing Protocol is "IGRP 1"
Sending updates every 30 seconds, next due in 82 seconds
Invalid after 270 seconds, hold down 280, flushed after 630
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
IGRP maximum hopcount 100
IGRP maximum metric variance 1
Redistributing: igrp 1
Routing for Networks:
131.108.0.0
Routing Information Sources:
Gateway Distance Last Update
131.108.1.1 100 00:00:09
Distance: (default is 100)
 Problem: IGRP Routes Not in the Routing Table 149

Example 5-12 shows the output of show ip route, which shows that the IGRP route is being
learned.
Example 5-12 show ip route Command Output Verifies That the IGRP Route Is Being Learned
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

IGRP Routes Not in the Routing Table—Cause: distribute-list in Is

Blocking the Route
A distribute list is a filtering mechanism for routing updates. A distribute list calls an access
list and checks which networks are supposed to be permitted. If the access list does not
contain any network, it will be automatically denied. A distribute list can be applied on
incoming routing updates or outgoing routing updates.
In this example, distribute-list in is configured, but because the access list does not
contain the permit statement for 131.108.0.0, R2 is not installing this route in the routing
table.
Figure 5-4 shows the flowchart to follow to solve this problem.

Figure 5-4 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

Make sure the distribute-

list in permits the network
Is the distribute-list in you want to receive the
Not sure IGRP update. Go to
blocking the routes?
Debugs and Verification
section.

No

Go to
next
cause.
150 Chapter 5: Troubleshooting IGRP

Debugs and Verification

Example 5-13 shows the current configuration of Router R2. In the access list configuration,
the network 131.108.0.0 is not explicitly permitted (and, therefore, is denied), so the router is
not installing any subnets of the 131.108.0.0 network.
Example 5-13 R2 Access List Configuration Does Not Permit Routes from the 131.108.0.0 Network
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router igrp 1
network 131.108.0.0
distribute-list 1 in
!
access-list 1 permit 131.107.0.0 0.0.255.255

Solution
When using a distribute list, you should always double-check your access list to make sure
that the networks that are supposed to be permitted actually are permitted in the access list
definition. In Example 5-13, the access list is permitting only routes from 131.107.0.0. All
other routes are denied by the implicit deny at the end of each access list. To fix this prob-
lem, explicitly permit 131.108.0.0 in access-list 1.
Example 5-14 shows the new configuration of Router R2 with the correct access list.
Example 5-14 Reconfiguring access-list 1 to Permit Routes from Network 131.108.0.0
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router igrp 1
network 131.108.0.0
distribute-list 1 in
!
no access-list 1 permit 131.107.0.0 0.0.255.255
access-list 1 permit 131.108.0.0 0.0.255.255

Example 5-15 shows that Router R2 is learning IGRP routes after the configuration change.
Example 5-15 show ip route Command Output Reveals That the Change to access-list 1 Was Successful
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
 Problem: IGRP Routes Not in the Routing Table 151

Example 5-15 show ip route Command Output Reveals That the Change to access-list 1 Was Successful
Routing Descriptor Blocks:
131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

IGRP Routes Not in the Routing Table—Cause: Access List Blocking

IGRP Source Address
Access lists are used to filter the traffic based on the source address. Extended access lists
are used to filter the traffic based on source or destination address. These access lists can be
applied on the interface with the interface-level command ip access-group {access-list
number} {in | out} to filter the incoming and outgoing traffic.
When the access list is applied in an IGRP environment, always make sure that it does not
block the source address of the IGRP update. In this example, R2 is not installing IGRP
routes in the routing table because access-list 1 is not permitting the source address of
IGRP updates from R1.
Figure 5-5 shows the flowchart to follow to solve this problem.

Figure 5-5 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

If the source address is not

permitted in the input
Is the access list access list, IGRP will not
blocking the IGRP Not sure install any route in the
source address? routing table. Go to
Debugs and Verification
section.
No

Go to
next
cause.

Debugs and Verification

Example 5-16 shows the current configuration of Router R2. The source address of
131.108.1.1 is not being permitted in the access list. Because the only permit statement
152 Chapter 5: Troubleshooting IGRP

in the access list is 131.107.0.0, the source address of RIP, 131.108.0.0, will be implicitly
denied.
Example 5-16 Current Configuration of Router R2
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 1 in
!
router igrp 1
network 131.108.0.0
!
access-list 1 permit 131.107.0.0 0.0.255.255

Example 5-17 shows the output of debug ip igrp events and debug ip igrp transaction.
In this debug, IGRP is only sending the updates and is not receiving anything because the
source address, 131.108.1.1, is not permitted in the input access list of R2. This is also
shown in the debug ip packet 100 detail output, where access-list 100 specifically looks
at the source address of 131.108.1.1
Example 5-17 debug Command Output Showing That IGRP Updates Are Sent and Not Received
R2#debug ip packet 100 detail
IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 46, access denied, proto=9
R2#

R2#show debug
Generic IP:
IP packet debugging is on (detailed) for access list
100
IP routing:
IGRP protocol debugging is on
IGRP event debugging is on

IGRP: sending update to 255.255.255.255 via Ethernet0

(131.108.1.2)
subnet 131.108.3.0, metric=501
IGRP: Update contains 1 interior, 0 system, and 0
exterior routes.
IGRP: Total routes in update: 1
R2#show access-list 100
Extended IP access list 100
permit ip host 131.108.1.1 host 255.255.255.255
R2#

Solution
The standard access list specifies the source address. In this case, the source address is
131.108.1.1. This source address is not permitted in the standard access list, so IGRP routes
will not get installed in the routing table of R2. To solve this problem, permit the source
address in access-list 1.
 Problem: IGRP Routes Not in the Routing Table 153

Example 5-18 shows the necessary configuration changes to fix this problem.

Example 5-18 Fixing the Access List to Permit the IGRP Update Source Address
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 1 in
!
router igrp 1
network 131.108.0.0
!
no access-list 1 permit 131.107.0.0 0.0.255.255
access-list 1 permit 131.108.1.1

Example 5-19 shows the configurations in case of an extended access list.

This problem also can happen when using extended access lists and when the IGRP source
address is not permitted in the access list. This solution also can be used in case of extended
access list. The idea here is to permit the source address of the IGRP update.
Example 5-19 Fixing the Extended Access List to Permit the IGRP Update Source Address
access-list 100 permit ip 131.107.0.0 0.0.255.255 any
access-list 100 permit ip host 131.108.1.1 any

After changing the access list, standard or extended, and permitting the source address of
the neighbor that is sending the IGRP routing updates, R2 will start accepting and installing
the IGRP updates.
Example 5-20 shows the routing table entry of Router R2, which shows that it is learning
IGRP routes after the configuration change of the access list.
Example 5-20 R2’s Routing Table Verifies That R2 Receives IGRP Routes After Fixing the Access Lists
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

IGRP Routes Not in the Routing Table—Cause: Access List

Blocking IGRP Broadcast
Access lists are used for the filtering purpose. When used on the inbound interface, always
make sure that it is not blocking IGRP broadcast, which is used for IGRP routing updates.
154 Chapter 5: Troubleshooting IGRP

If this broadcast address is not permitted in the access list that is applied on the interface
inbound, IGRP will not install any routes in the routing table learned on that interface.
Figure 5-6 shows the flowchart to follow to solve this problem.

Figure 5-6 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

IGRP sends the update on

the broadcast address of
Is the access list 255.255.255.255. This
blocking the Not sure destination address must
IGRP broadcast? be permitted in the input
access list. Go to Debugs
and Verification section.
No

Go to
next
cause.

Debugs and Verification

Example 5-21 shows the current configuration of R2. In this configuration, the IGRP des-
tination address of 255.255.255.255 is not being permitted; as a result, no IGRP routes
are being installed in R2. The access-group 100 in command is configured under the
Ethernet 0 interface of R2. This filter actually is calling access-list 100. If you look at
access-list 100, it is actually denying the incoming broadcast access on Ethernet 0 inter-
face because there is an implicit deny at the end of each access list. This blocks the IGRP
updates, and R2 will not install any IGRP routes.
Example 5-21 R2’s Configuration Does Not Permit the IGRP Broadcast Address of 255.255.255.255
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 100 in
!
router igrp 1
network 131.108.0.0
!
access-list 100 permit ip 131.107.0.0 0.0.255.255 any
access-list 100 permit ip host 131.108.1.1 host 131.108.1.2
 Problem: IGRP Routes Not in the Routing Table 155

Solution
IGRP broadcasts its routing updates on 255.255.255.255. This address must be permitted
in the input access list of the receiving router.
Example 5-22 shows the new configuration for Router R2.
Example 5-22 Reconfiguring Router R2 to Permit the IGRP Broadcast Address
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 1 in
!
router igrp 1
network 131.108.0.0
!
access-list 100 permit ip 131.107.0.0 0.0.255.255 any
access-list 100 permit ip host 131.108.1.1 host 131.108.1.2
access-list 100 permit ip host 131.108.1.1 host 255.255.255.255

Example 5-23 shows the routing table entry of R2 after correcting the problem.
Example 5-23 R2’s Routing Table Shows That the IGRP Broadcast Address Is Now Permitted
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

IGRP Routes Not in the Routing Table—Cause: Discontiguous

Network
The definition of a discontiguous network is one in which two subnets belonging to the
same major network are separated by a network or a subnetwork belonging to another
major network. Chapter 4, “Understanding Interior Gateway Routing Protocol
(IGRP),” provides a detailed description of why discontiguous networks are not
supported in IGRP.
Figure 5-7 shows an example of a discontiguous network in which 137.99.0.0 is a major
network. The subnets of this major network are separated by another major network,
131.108.0.0. This situation produces a discontiguous network problem.
156 Chapter 5: Troubleshooting IGRP

Figure 5-7 Sample Discontiguous Network

137.99.2.0/24 .1 131.108.1.0/24 137.99.3.0/24

.2
E0 E0
Router 1 Router 2

Figure 5-8 shows the flowchart to follow to solve this problem.

Figure 5-8 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

If IGRP receives a
summarized route for a
discontiguous network, it
Is the a discontiguous subnet? Not sure will not install it in the
routing table. Go to
Debugs and Verification
section.
No

Go to
next
cause.

Debugs and Verification

Example 5-24 shows the configuration of Routers R1 and R2. IGRP is enabled on the
Ethernet interfaces of R1 and R2 with the correct network statements.
Example 5-24 R1 and R2 Configurations Indicate That IGRP Is Enabled on the Ethernet Interfaces
R2#
interface Loopback0
ip address 137.99.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router igrp 1
network 131.108.0.0
network 137.99.0.0
!

R1#
interface Loopback0
ip address 137.99.2.1 255.255.255.0
!
 Problem: IGRP Routes Not in the Routing Table 157

Example 5-24 R1 and R2 Configurations Indicate That IGRP Is Enabled on the Ethernet Interfaces (Continued)
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0
network 137.99.0.0
!

Example 5-25 shows the debug ip igrp transaction output for Routers R1 and R2. Both
debugs show that the network 137.99.0.0 is being sent across.
Example 5-25 debug ip igrp transaction Command Output for R1 and R2 Indicates That Updates for Network
137.99.0.0 Are Being Sent
R2#debug ip igrp transaction
IGRP protocol debugging is on
R2#
IGRP: sending update to 255.255.255.255 via Loopback0 (137.99.3.2)
network 131.108.0.0, metric=8476
IGRP: sending update to 255.255.255.255 via Ethernet0 (131.108.1.2)
network 137.99.0.0, metric=501
IGRP: received update from 131.108.1.1 on Ethernet0
network 137.99.0.0, metric 8976 (neighbor 501)
R2#

R1#debug ip igrp transaction

IGRP protocol debugging is on
R1#
IGRP: sending update to 255.255.255.255 via Loopback0 (137.99.2.1)
network 131.108.0.0, metric=8476
IGRP: sending update to 255.255.255.255 via Ethernet0 (131.108.1.1)
network 137.99.0.0, metric=501
R1#
IGRP: received update from 131.108.1.2 on Ethernet0
network 137.99.0.0, metric 8976 (neighbor 501)
R1#

Solution
IGRP is not installing the route 137.99.0.0 in the routing table because IGRP does not support
discontiguous networks. As discussed in Chapter 4, there are several solutions to this problem.
The quick solution is to configure a static route to the more specific subnets of 137.99.0.0 on
each router. This provides each router the routes about the specific subnets of a discontiguous
majornet. Other solutions are as follows:
• Change the address on the link between R1 and R2 to be a part of 137.99.0.0. In other
words, assign another subnet on this link, which is a part of 137.99.0.0.
• If the address cannot be changed, run a GRE tunnel between R1 and R2, and put a separate
subnet address with the same mask on the tunnel interface, as demonstrated:
158 Chapter 5: Troubleshooting IGRP

R1#
interface tunnel 0
ip address 137.99.1.1 255.255.255.0
tunnel source Ethernet 0
tunnel destination 131.108.1.2

R2#
interface tunnel 0
ip address 137.99.1.2 255.255.255.0
tunnel source Ethernet 0
tunnel destination 131.108.1.1

• Replace IGRP with any other IP routing protocol that supports discontiguous
networks—for example OSPF, ISIS, EIGRP, RIP-2, and so on.
Discontiguous subnets are discouraged and should be avoided even if a protocol supports
it. They destroy the summarization capabilities.
Example 5-26 shows the configuration change that is required for both Routers R1 and R2 to fix
the problem. In the configurations, a static route has been added for the discontiguous subnets.
Example 5-26 Adding a Static Route as a Solution for Discontiguous Subnets
R1#
interface Loopback0
ip address 137.99.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0
network 137.99.0.0
!
ip route 137.99.3.0 255.255.255.0 131.108.1.2

R2#
interface Loopback0
ip address 137.99.3.2 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.2 255.255.255.0
!
router igrp 1
network 131.108.0.0
network 137.99.0.0
!
ip route 137.99.2.0 255.255.255.0 131.108.1.1

Example 5-27 shows the routing table entry of R2 after fixing this problem.
Example 5-27 Verifying That the IGRP Routing Update Problem Caused by Discontiguous Networks Has Been
Resolved
R2#show ip route 137.99.2.0
Routing entry for 137.99.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
 Problem: IGRP Routes Not in the Routing Table 159

Example 5-27 Verifying That the IGRP Routing Update Problem Caused by Discontiguous Networks Has Been
Resolved (Continued)
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

IGRP Routes Not in the Routing Table—Cause: Invalid Source

When IGRP tells the routing table to install the route, it performs a source validity check. This
check makes sure that the source where the update is coming from is also on the same subnet of
the local receiving interface. If the source is not on the same subnet as the local interface, IGRP
ignores the update and will not install routes in the routing table coming from this source address.
Figure 5-9 shows the network diagram for the invalid source problem.

Figure 5-9 Network with an Invalid Source

131.108.2.0/24 131.108.3.0/24
unnumbered loop 0
131.108.1.2/24
S0

Router 1 Router 2

As Figure 5-9 illustrates, Router 1’s Serial0 interface is unnumbered to Loopback0. Router 2’s
serial interface is numbered. When Router 2 receives an IGRP update from Router 1, it
complains about the source validity.
Figure 5-10 shows the flowchart to follow to solve this problem.

Figure 5-10 Problem-Resolution Flowchart

Subnetted routes are missing from the routing table of R2.

IGRP performs a source

validity check before route
installation. If one side is
numbered and the other
Is the IGRP update coming Not sure side is unnumbered, the
from a valid source? source validity check must
be turned off. Go to
Debugs and Verification
Yes section.

Go to
next
cause.
160 Chapter 5: Troubleshooting IGRP

Debugs and Verification

Example 5-28 shows the configuration of both Routers R2 and R1, where R1’s Serial0
interface is unnumbered to Loopback0 and R2’s Serial0 interface is numbered.
Example 5-28 R1/R2 Configuration with Mismatched Numbered/Unnumbered Serial Interfaces
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Serial0
ip address 131.108.1.2 255.255.255.0
!
router igrp 1
network 131.108.0.0
!

R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Serial0
ip unnumbered Loopback0
!
router igrp 1
network 131.108.0.0
!

Example 5-29 shows the debug ip igrp transaction output, which reveals that R2 is
ignoring IGRP updates from R1 because of the source validity check failure.
Example 5-29 debug ip igrp transaction Command Output Reveals That R2 Is Ignoring IGRP Update from R1
R2#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: received update from invalid source 131.108.2.1 on Serial0
R2#

Solution
When IGRP tells the routing table to install the route, it performs a source validity check.
If the source is not on the same subnet on which it received the update, it ignores the update.
In cases when one side is numbered and the other side is unnumbered, this check must be
turned off. This is usually the case in dial backup situations in which remote routers dial
into an access router. The access router’s dialup interface is unnumbered, and all remote
routers get an IP address assigned on their dialup interfaces.
Example 5-30 shows the new configuration change on Router R2 to fix this problem.
Example 5-30 Disabling the Source Validity Check on R2
R2#interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
 Problem: IGRP Routes Not in the Routing Table 161

Example 5-30 Disabling the Source Validity Check on R2 (Continued)

interface Serial0
ip address 131.108.1.2 255.255.255.0
!
router igrp 1
no validate-update-source
network 131.108.0.0
!

Example 5-31 shows that after changing the configurations of R2, the route gets installed
in the routing table.
Example 5-31 show ip route Command Output Verifies That R2 Is Now Receiving the IGRP Update from R1’s
Unnumbered Interface
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

IGRP Routes Not in the Routing Table—Cause: Layer 2 Problem

(Switch, Frame Relay, Other Layer 2 Media)
Sometimes, broadcast capability is broken at Layer 2, which further affects Layer 3 broadcast,
and IGRP fails to work properly. The Layer 3 broadcast is further converted into a Layer 2
broadcast. If Layer 2 has problems in handling Layer 2 broadcasts, the IGRP updates will not
be propagated across. The debug shows that the broadcast is being originated at one end but is
not getting across.
Figure 5-11 shows the network diagram for a Frame Relay problem while running IGRP.

Figure 5-11 Two Routers Running IGRP in a Frame Relay Network

131.108.1.0/24
131.108.2.0/24 .1 131.108.3.0/24
.2

Router 1 Router 2

In Figure 5-11, Router 1 and Router 2 are connected by Frame Relay. (Although, this could
be any Layer 2 medium—X.25, Ethernet, FDDI, and so forth.)
162 Chapter 5: Troubleshooting IGRP

Figure 5-12 shows the flowchart to follow to solve this problem.

Figure 5-12 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

IGRP sends updates on

255.255.255.255. This
Is Layer 2 media propogating broadcast address must be
Not sure
IGRP broadcast? permitted through Layer 2
media. Go to Debugs and
Verification section.
Yes

Go to
next
cause.

Debugs and Verification

Example 5-32 shows the output of debug ip packet detail 100, which verifies that R1 is
sending and receiving IGRP updates without any problem. On R2, updates are being sent
but are not received. This means that the IGRP update is being lost at Layer 2.
Example 5-32 debug ip packet detail 100 Command Output Shows That R1 Is Successfully Sending IGRP
Updates
R1#show access-list 100
access-list 100 permit ip any host 255.255.255.255

R1#debug ip packet 100 detail

IP packet debugging is on (detailed) for access list 100
R1#
IP: s=131.108.1.1 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9
IP: s=131.108.1.2 (Ethernet), d=255.255.255.255, len 46, rcvd 2, proto=9

R2#debug ip packet 100 detail

IP packet debugging is on (detailed) for access list 100
R2#
IP: s=131.108.1.2 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9
IP: s=131.108.1.2 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9

Solution
IGRP sends updates on a broadcast address of 255.255.255.255. If this address gets blocked
at Layer 2, IGRP will not function properly. The root of the Layer 2 problem could result
 Problem: IGRP Routes Not in the Routing Table 163

from a simple Ethernet switch, Frame Relay cloud, bridging cloud, and so on. Fixing the
Layer 2 problem is beyond the scope of this book. We will leave this up to you, but here are
some tips:
• In cases of Frame Relay
— Check for the broadcast keyword missing in the frame-relay map
statement.
— Call your telco and make sure that it is propagating broadcast traffic
across.
• In cases of a bridging cloud
— Make sure that any bridge in the middle is not dropping the broadcast
packets.
— If the middle medium is Token Ring to Ethernet, make sure that the
translational bridging is working properly.
Example 5-33 shows that after fixing the Layer 2 problem, IGRP routes get installed in the
routing table.
Example 5-33 Verifying IGRP Routes Show Up in the Routing Table After Resolving the Layer 2 Problem
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

IGRP Routes Not in the Routing Table—Cause: Sender’s AS

Mismatch
IGRP updates carry the AS number. When a receiver receives an IGRP update and the
AS number of the sender does not match with its own AS number, IGRP ignores that
update. As a result, no IGRP routes are installed in the routing table. Multiple IGRP
processes can be run under different AS numbers. These processes are independent of
each other.
Figure 5-13 shows the flowchart to follow to solve this problem.
164 Chapter 5: Troubleshooting IGRP

Figure 5-13 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

IGRP routes will be

Is sender’s AS ignored if the sender’s AS
number the same as the number is different than
Not sure
local AS number? the local AS number. Go
to Debugs and Verification
section.
Yes

Go to
next
cause.

Debugs and Verification

Example 5-34 shows the configuration of both R1 and R2. R1 is running IGRP AS 1, and
R2 is running IGRP AS 2.
Example 5-34 R1 and R2 Configurations Show That They Are in Different Autonomous Systems
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Serial0
ip address 131.108.1.2 255.255.255.0
!
router igrp 2
network 131.108.0.0
!

R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Serial0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0
!

Example 5-35 shows the output of debug ip igrp transaction and debug ip packet 100
detail on R1 and R2. Both routers are sending the IGRP update, but the update never
reaches the other side. Both routers show that the IGRP packets are being received, but
 Problem: IGRP Routes Not in the Routing Table 165

IGRP is ignoring these updates because of the AS number mismatch. Unfortunately, the
debug does not show the mismatch message; however, it does show that IGRP is not
displaying the update received message in the debugs.
Example 5-35 debug ip igrp transaction Command Output on R1 and R2 Reveals the Status of IGRP Updates
R1#show debug
Generic IP:
IP packet debugging is on (detailed)
IP routing:
IGRP protocol debugging is on
IGRP event debugging is on
R1#
R1#show access-list 100
access-list 100 permit ip any host 255.255.255.255

R1#debug ip packet 100 detail

IP packet debugging is on (detailed) for access list 100
R1#
R1#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: sending update to 255.255.255.255 via Serial0 (131.108.1.1)
subnet 131.108.3.0, metric=501
IP: s=131.108.1.2 (Serial0), d=255.255.255.255, len 64, rcvd 2, proto=9

R2#debug ip packet 100 detail

IP packet debugging is on (detailed) for access list 100
R2#
R2#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: sending update to 255.255.255.255 via Serial0 (131.108.1.2)
subnet 131.108.2.0, metric=501
IP: s=131.108.1.1 (Serial0), d=255.255.255.255, len 64, rcvd 2, proto=9

Solution
In this example, the sender is sending AS 1 in the update. When R2 receives it, it ignores
this update because R2 is running IGRP under AS 2.
To fix this problem, change the IGRP configurations so that R1 and R2 both agree on one
AS number.
Example 5-36 shows the new configuration on R2 that fixes this problem.
Example 5-36 Configuring R2 to Have the Same AS Number as R1
R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Serial0
ip address 131.108.1.2 255.255.255.0
!
no router igrp 2
!
router igrp 1
network 131.108.0.0
!
166 Chapter 5: Troubleshooting IGRP

Example 5-37 shows that after fixing the AS problem, IGRP routes get installed in the
routing table.
Example 5-37 show ip route Command Output Reveals That the AS Problem Preventing IGRP Route Installation
Is Resolved
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Problem: IGRP Is Not Installing All Possible Equal-Cost

Paths—Cause: maximum-paths Restricts IGRP to a
Maximum of Four Paths by Default
By default, Cisco routers support only four equal paths, for load-balancing purposes. The
com-mand maximum-path can be used for up to six equal-cost paths. If the command is
not configured properly, it can cause problems, as discussed in this section. The command
maximum-path is incorrectly used, so it allows only one path to the destination even
though more than one path exists. The maximum-path 1 command should be used only
when load balancing is not desired.
Figure 5-14 shows the network setup that produces the problem of IGRP not installing all
possible equal-cost paths.

Figure 5-14 Network Setup Vulnerable to Equal-Cost-Path Routes Not Being Installed by IGRP

Router 1

E1 E2

131.108.1.0/24 131.108.5.0/24

131.108.2.0/24
Router 2 Router 3
 Problem: IGRP Is Not Installing All Possible Equal-Cost Paths 167

Example 5-38 shows the routing table entry of Router R1. Only one route is being installed
in the routing table.
Example 5-38 Routing Table for R1 in Figure 5-14
R1#show ip route igrp
131.108.0.0/24 is subnetted, 1 subnets
I 131.108.2.0 [100/8976] via 131.108.5.3, 00:00:09, Ethernet2

Figure 5-15 shows the flowchart to follow to solve this problem.

Figure 5-15 Problem-Resolution Flowchart

IGRP is not installing all possible equal-cost paths.

Cisco routers by default

allow only four equal-cost
Are there more
paths to be installed in the
than four possible equal- Not sure
routing table. Go to
cost paths?
Debugs and Verification
section.
No

Go to
next
cause.

Debugs and Verification

Example 5-39 shows the output of the debug ip igrp transaction command on Router R1,
revealing that Router R1 is receiving two equal-cost route paths.
Example 5-39 debug ip igrp transaction Command Output Reveals the Number of Equal-Cost Paths Received
R1#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: received update from 131.108.5.3 on Ethernet2
network 131.108.2.0, metric 8976 (neighbor 501)
IGRP: received update from 131.108.1.2 on Ethernet1
network 131.108.2.0, metric 8976 (neighbor 501)

Only one route is installed in the routing table. You see only one route in the routing table
instead of two because the operator has configured maximum-paths 1 in the configuration.
168 Chapter 5: Troubleshooting IGRP

Example 5-40 shows the current configuration for Router R1. The maximum-path setting
is set to 1, which prevents IGRP from installing more than one path in the routing table. By
default, maximum-path is set to 4.
Example 5-40 Current R1 Configuration
router igrp 1
network 131.108.0.0
maximum-paths 1

Solution
By default, Cisco IOS Software allows up to four equal-cost routes to be installed into the
routing table. This can be increased up to six routes if configured properly. If there is a
desire to do a load balancing over six links, use this command.
Example 5-41 shows the configuration that installs six equal-cost route paths in the routing table.
Example 5-41 Configuring R1 to Accept Up to Six Equal-Cost Route Paths in the Routing Table
R1#router igrp 1
maximum-paths 6

This example makes more sense when you have more than four paths and only four are
getting installed in the routing table. Because four equal-cost routes is a default, you must
configure maximum-paths to accommodate the fifth and (possibly sixth) route.

Troubleshooting IGRP Routes Advertisement

All these problems discussed so far deal with a problem on the receiving end or a problem
in the middle (Layer 2).
There is a third possibility for why the route is not being installed in the routing table—the
problem is occurring on the sender’s end. The sender might be having a problem sending
IGRP updates, so the receiver is not installing the IGRP routes in the routing table. This
next section talks about the things that can go wrong on the sender’s side.
This section discusses the most common scenarios that can prevent IGRP routes from being
advertised out. Some cases overlap with IGRP route installation problems—for example,
missing network statements and downed interfaces. This section assumes that you did
troubleshoot all the possible scenarios discussed in the previous section and that the prob-
lems still exist. In this case, the last place to look at is the sender.
This chapter covers two problems related to IGRP route advertisement originating from the
sender’s side:
• The sender is not advertising IGRP routes.
• The candidate default is not being advertised.
 Problem: Sender Is Not Advertising IGRP Routes 169

Problem: Sender Is Not Advertising IGRP Routes

Typically, an IP network running IGRP has routers that have a consistent view of the routing
table. In other words, all routers have routing tables that contain reachability information for
all the IP subnets of the network. This might differ when filtering of certain subnets is done
at some routers and not at others. Ideally, all IGRP routers are aware of all routes of the
complete network.
When the routing information differs from one router to the other, one of two possibilities
could exist:
• Some router(s) is not advertising the IGRP routes.
• Some router(s) is not receiving the IGRP routes.
This section deals with a router not advertising IGRP routes.
Figure 5-16 provides a network scenario that will be used as the basis for troubleshooting
a majority of the following causes of the “sender is not advertising IGRP routes” problem:
• network statement is missing or incorrect.
• The outgoing interface is down.
• distribute-list out is blocking the routes.
• The advertised network interface is down.
• The outgoing interface is defined as passive.
• Broadcast capability has been broken (encapsulation failure in Frame Relay).
• neighbor statement is misconfigured.
• The advertised subnet is VLSM.
• Split horizon is enabled.

Figure 5-16 Network Setup to Illustrate IGRP Routes Not Being Advertised

131.108.2.0/24 .1 131.108.1.0/24 131.108.3.0/24

.2
E0 E0
Router 1 Router 2

In Figure 5-16, Router 1 (the sender) is not advertising routes to Router 2. If a network
statement is missing from Router 1’s configurations, it will not advertise any IGRP routes.

Sender Is Not Advertising IGRP Routes—Cause: Missing or

Incorrect network Statement
One of the requirements for enabling IGRP on a router’s interface is to mention the
network statement under the router igrp command. The network statement decides which
170 Chapter 5: Troubleshooting IGRP

interface upon which IGRP should be enabled. If the network statement is misconfigured
or is not configured, IGRP will not be enabled on that interface and IGRP routes will not
be advertised out on that interface.
Figure 5-17 shows the flowchart to follow to fix this problem.

Figure 5-17 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

IGRP must be enabled on

the interface to send and
Is IGRP enabled receive IGRP updates. Go
Not sure
on the interface? to Debugs and Verification
section.

Yes

Go to
next
cause.

Debugs and Verification

Example 5-42 shows the current configuration for R1.
Example 5-42 Current Configuration for R1 in Figure 5-16
R1#interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.107.0.0

Solution
The network statement is incorrectly configured under router igrp 1. Instead of
131.108.0.0, 131.107.0.0 is configured. This will not enable IGRP on the interface, and
no updates will be sent.
Sometimes, a classless network statement is configured under router IGRP, assuming that
it will cover all the networks—for example:
router igrp 1
network 131.0.0.0
 Problem: Sender Is Not Advertising IGRP Routes 171

This network statement will not cover 131.0.0.0–131.255.255.255 because 131.0.0.0 is a

classless network and IGRP is a classful routing protocol. Similarly, if you have multiple
Class C addresses, you cannot use one Class C address to cover all the Class C addresses
that you own, such as 200.1.1.0–200.1.4.0. This does not mean you can do this:
router igrp 1
network 200.1.0.0

This network statement is meaningless for IGRP because IGRP is a classful protocol. The
correct way to advertise all four networks in IGRP is this:
router igrp 1
network 200.1.1.0
network 200.1.2.0
network 200.1.3.0
network 200.1.4.0

Example 5-43 shows the correct configuration for R1.

Example 5-43 R1 Configuration with the Correct network Statement
R1#interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
no network 131.107.0.0
network 131.108.0.0

Example 5-44 shows the routing table entry of Router R2, with the learned IGRP route.
Example 5-44 R1 Routing Table Shows That Routes Were Properly Advertised by R2 After Correcting the
Configuration
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: Outgoing Interface

Is Down
IGRP is the routing protocol that runs on Layer 3. IGRP cannot send updates across the
interface if the outgoing interface is down. A variety of possible causes exists for the
outgoing interface being down:
172 Chapter 5: Troubleshooting IGRP

• Interface is up, line protocol is down.

• Interface is down, line protocol is down.
• Interface is administratively down, line protocol is down.
If the outgoing interface shows any of these symptoms, IGRP will not be capable of sending
any updates across. The main thing to note here is that in all of these possibilities, the line
protocol will always appear to be down. This is the most important information in
determining the Layer 2 connectivity.
Figure 5-18 shows the flowchart to follow to solve this problem.

Figure 5-18 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

If the outgoing interface

is down, IGRP will not
Is the outgoing interface advertise any routes out
Not sure
up/up? on that interface. Go to
Debugs and Verification
section.
Yes

Go to
next
cause.

Debugs and Verification

Example 5-45 verifies that the interface Ethernet 0 is down.
Example 5-45 show interface Command Output Reveals That the Interface Is Down
R1#show interface ethernet 0
Ethernet0 is up, line protocol is down
Hardware is Lance, address is 0000.0c70.d31e (bia 0000.0c70.d31e)
Internet address is 131.108.1.1/24

Solution
IGRP runs above Layer 2. IGRP cannot send or receive any routes if Layer 2 is down.
To correct this problem, you must fix the Layer 2 problem. The problem might be as simple
as loose cables or a bad cable; in which case, the cable must be replaced. Alter-natively, the
problem could be as complex as bad hardware; in which case, the hardware must be replaced.
Some of the tips on resolving the Layer 2 issue already were addressed in the “Trouble-
shooting IGRP Route Installation” section, where the cause is Layer 1/2 being down.
 Problem: Sender Is Not Advertising IGRP Routes 173

Example 5-46 shows the interface Ethernet 0 after fixing the Layer 2 problem.
Example 5-46 Verifying That the Layer 2 Problem Has Been Resolved
R1#show interface ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c70.d31e (bia 0000.0c70.d31e)
Internet address is 131.108.1.1/24

Example 5-47 shows the routing table entry of R2 after fixing the problem.
Example 5-47 Verifying That R2 Is Receiving the Routes After Fixing the Layer 2 Problem
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: distribute-list out

Is Blocking the Route
distribute-list out is used to filter any routes that are going to be sent out on an interface.
If a receiver is complaining about a missing route that should have been received, make sure
that it is not being filtered through distribute-list out. If it is, the associated access list must
be modified.
Figure 5-19 shows the flowchart to follow to fix this problem.

Figure 5-19 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

Make sure the distribute-

list out permits the
Is the distribute-list out network you want to
Not sure
blocking the routes? advertise out through
IGRP. Go to Debugs and
Verification section.
Yes

Go to
next
cause.
174 Chapter 5: Troubleshooting IGRP

Debugs and Verification

Example 5-48 shows the configuration of Router R1. In this configuration, the access list
does not permit the 131.108.0.0 network, so R1 will not advertise any 131.108 network,
including 131.108.2.0/24.
Example 5-48 Access List Configuration on R1 Does Not Permit the 131.108.0.0 Network
R1#interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0
distribute-list 1 out
!
access-list 1 permit 131.107.0.0 0.0.255.255

Solution
When using a distribute list, you should always double-check your access list to make sure
that the networks that are supposed to be permitted actually are explicitly permitted in the
access list. The access list configuration in Example 5-48 is permitting only 131.107.0.0
and is denying everything else because there is an implicit deny at the end of each access
list. To fix this problem, add a permit statement allowing 131.108.0.0 in access-list 1.
Example 5-49 shows the new configuration change on Router R1.
Example 5-49 Access List Configuration on R1 to Permit the 131.108.0.0 Network
R1#interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0
distribute-list 1 out
!
no access-list 1 permit 131.107.0.0 0.0.255.255
access-list 1 permit 131.108.0.0 0.0.255.255

Example 5-50 shows the routing table entry of Router R2 after fixing the problem.
Example 5-50 R2 Routing Table Verifies That R2 Receives IGRP Routes After Fixing the Access List in R2
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
 Problem: Sender Is Not Advertising IGRP Routes 175

Example 5-50 R2 Routing Table Verifies That R2 Receives IGRP Routes After Fixing the Access List in R2
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: Advertised

Network Interface Is Down
A situation could arise in which the network that is being advertised is down and the
connected route has been removed from the routing table. In this situation, IGRP will start
advertising that network with an infinite metric and after the hold-down timer expires,
it will no longer advertise this network. As soon as the advertised network comes up, IGRP
will start advertising it again in its updates.
Figure 5-20 shows the flowchart to follow to fix this problem.

Figure 5-20 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

The network inteded to

be advertised will not be
Is the advertised network advertised if the interface
Not sure
interface up/up? that represents that
network is down. Go to
Debugs and Verification
section.
Yes

Go to
next
cause.

Debugs and Verification

Example 5-51 shows that the line protocol of the advertised network interface is down,
indicating that something is wrong at Layer 2. For tips on fixing Layer 1/2, refer to the
“Troubleshooting IGRP Route Installation” section.
Example 5-51 show interface Command Output Reveals That the Advertised Network Interface Is Down
R1#show interface Ethernet 1
Ethernet1 is up, line protocol is down
Hardware is Lance, address is 0000.0c70.d51e (bia 0000.0c70.d51e)
Internet address is 131.108.2.1/24
176 Chapter 5: Troubleshooting IGRP

Solution
When the advertised network’s interface goes down, IGRP will detect that because Layer 2
notifies the upper layer that the interface or the subnet is down. IGRP will no longer adver-
tise that network in the IGRP updates. As Example 5-52 shows, Ethernet 1 is down, so
IGRP no longer advertise 131.108.2.0/24 in its update.
To correct this problem, you must fix the Layer 1/2 problem. The problem could be as
simple as loose cables, or it could be as complex as bad hardware, in which case the
hardware must be replaced. Refer back to the “Troubleshooting IGRP Route Installation”
section for tips on fixing Layer 1/2 issues.
Example 5-52 shows that the advertised network interface is up after fixing the Layer 2
problem.
Example 5-52 Verifying That the Advertised Network Interface Is Up
Ethernet1 is up, line protocol is up
Hardware is Lance, address is 0000.0c70.d51e (bia 0000.0c70.d51e)
Internet address is 131.108.2.1/24

Example 5-53 shows that the route that was down is back in the routing table of R2.
Example 5-53 R2 Routing Table Verifies That R2 Starts Receiving IGRP Routes After Fixing the Layer 1/2 Issue
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: Outgoing Interface

Is Defined as Passive
When an interface is defined as passive under IGRP, IGRP will receive updates on that
interface but will not send any updates. The passive-interface command is used to avoid
sending unnecessary updates to a neighbor that does not need to receive any IGRP updates,
such as a small route that is at the edge. A simple default gateway is enough information
for that router to talk to the outside world. Be sure to use the passive-interface command
where needed; otherwise, undesired results might occur.
Figure 5-21 shows the flowchart to follow to fix this problem.
 Problem: Sender Is Not Advertising IGRP Routes 177

Figure 5-21 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

A passive interface is
Is the outgoing interface incapable of sending any
Not sure IGRP updates. Go to
defined as passive?
Debugs and Verification
section.

No

Go to
next
cause.

Debugs and Verification

Example 5-54 shows the output of show ip protocols, which shows that the outgoing
interface is defined as passive.
Example 5-54 Verifying That the Outgoing Interface Is Passive
R1#show ip protocols
Routing Protocol is "IGRP 1"
Sending updates every 30 seconds, next due in 82 seconds
Invalid after 270 seconds, hold down 280, flushed after 630
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
IGRP maximum hopcount 100
IGRP maximum metric variance 1
Redistributing: igrp 1
Routing for Networks:
131.108.0.0
Passive Interface(s):
Ethernet0
Routing Information Sources:
Gateway Distance Last Update
131.108.1.2 100 00:00:09
Distance: (default is 100)

Example 5-55 shows the configuration of Router R1, which shows that the outgoing
interface is defined as passive.
Example 5-55 R1 Configuration Shows a Passive Interface
R1#router igrp 1
passive-interface Ethernet 0
network 131.108.0.0
178 Chapter 5: Troubleshooting IGRP

Solution
Example 5-54 and 5-55 confirm that the interface Ethernet 0 is defined as passive, so R1 is
not sending any updates on Ethernet 0. Sometimes, it is desirable for some networks to be
advertised out and others to be filtered. In this situation, you should not use passive
interfaces—distribute-list out is a better solution.
Assuming that passive-interface was configured by mistake, take this command out of the
configuration to solve this problem.
Example 5-56 shows the new configuration to solve this problem.
Example 5-56 Removing the Passive Interface
R1#router igrp 1
network 131.108.0.0
no passive-interface Ethernet 0

Example 5-57 shows the routing table entry of R2 after fixing the problem.
Example 5-57 R2’s Routing Table Verifies That Removal of the Passive Interface Fixed Routes Advertisement
Problem on R1
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: Broken Broadcast

Capability (Encapsulation Failure in Layer 2)
When IGRP is running in a Frame Relay environment, Layer 2 must support broadcast;
otherwise, IGRP updates will not get across. When using static mapping, be sure to add the
broadcast keyword at the end of a map statement. This problem also can be seen with
X.25, ISDN, and other Layer 2 media. Whenever there is a static mapping, the broadcast
keyword must be included in the configuration.
Figure 5-22 shows the network setup that is used to produce a broken broadcast capability
in Frame Relay.
Figure 5-22 shows that Router 1 and Router 2 are connected by Frame Relay. Router 1 is
not advertising IGRP routes toward Router 2.
 Problem: Sender Is Not Advertising IGRP Routes 179

Figure 5-22 Network Setup Incompatible with Frame Relay Broadcasting Without broadcast Keyword in map
Statement
131.108.1.0/24
131.108.2.0/24 .1 131.108.3.0/24
.2
Frame Relay

Router 1 Router 2

Figure 5-23 shows the flowchart to follow to solve this problem.

Figure 5-23 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

If the Layer 2 media is

Frame Relay or ISDN with
static mapping, make sure
Is the broadcast capability that the broadcast
Not sure
broken? keyword is added in the
map statement. Go to
Debugs and Verification
section.
No

Go to
next
cause.

Debugs and Verification

Example 5-58 shows the configuration of Router R1. In this configuration, the frame-relay
map statement does not include the broadcast keyword.
Example 5-58 R1 Configuration Lacks the broadcast Keyword
R1#interface Serial3
ip address 131.108.1.1 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
no keepalive

frame-relay map ip 131.108.1.2 16

!

Example 5-59 shows output from the debug ip packet command, which includes the
broadcast traffic source from R1. The debug shows that there are encapsulation failures.
Example 5-59 debug ip packet Command Output Indicates Encapsulation Failures
R1#show access-list 100
Extended IP access list 100
permit ip host 131.108.1.1 host 255.255.255.255 (8 matches)
continues
180 Chapter 5: Troubleshooting IGRP

Example 5-59 debug ip packet Command Output Indicates Encapsulation Failures (Continued)
R1#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100
R1#
IP: s=131.108.1.1 (local), d=255.255.255.255 (Serial3), len 88, sending broad/
multicast, proto=9
IP: s=131.108.1.1 (local), d=255.255.255.255 (Serial3), len 88, encapsulation failed,
proto=9

Solution
To solve this problem, add the broadcast keyword in the frame-relay map statement.
Example 5-60 shows the new configuration of Router R1 with the correct frame-relay map
statement.
Example 5-60 Configuring R1 with the frame-relay map Statement, Including the broadcast Keyword
interface Serial3
ip address 131.108.1.1 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
no keepalive
frame-relay map ip 131.108.1.2 16 broadcast
!

Example 5-61 shows the routing table entry of R2 with IGRP routes.
Example 5-61 R2 Routing Table Verifies That R2 Is Receiving IGRP Routes After Broadcasting Is Enabled on R2’s
frame-relay map Statement
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: Misconfigured

neighbor Statement
In a nonbroadcast environment, IGRP provides a unicast method of sending IGRP updates.
To send unicast IGRP updates, you must configure the neighbor statement carefully. If the
neighbor address is misconfigured in the neighbor statement, IGRP will not send the uni-
cast update to the wrong neighbor or a nonexistent neighbor.
Figure 5-24 shows the flowchart to follow to solve this problem.
 Problem: Sender Is Not Advertising IGRP Routes 181

Figure 5-24 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

If an NBMA environment,
neighbor statements must
be configured under the
Is the neighbor statement Not sure router igrp configuration
configured properly? to unicast IGRP updates.
Go to Debugs and
Verification section.
Yes

Go to
next
cause.

Debugs and Verification

Example 5-62 shows the IGRP configuration for Router R1. The configuration shows
that the neighbor statement is configured wrong. Instead of 131.108.1.2, as shown in
Figure 5-22, the neighbor statement points to 131.108.1.3, which does not exist.
Example 5-62 Misconfigured neighbor Statement Preventing Unicast IGRP Updates
R1#router igrp 1
network 131.108.0.0
neighbor 131.108.1.3

Solution
In Example 5-62, IGRP is sending a unicast update to 131.108.1.3, a bogus neighbor that
does not exist.
To resolve this problem, you must properly configure the neighbor statement.
Example 5-63 shows the correct configuration of Router R1.
Example 5-63 Configuring R1 with the Proper neighbor Statement
R1#router igrp 1
network 131.108.0.0
no neighbor 131.108.1.3
neighbor 131.108.1.2

Example 5-64 shows the IGRP routes installed in R2’s routing table.
182 Chapter 5: Troubleshooting IGRP

Example 5-64 R2’s Routing Table Verifies That the neighbor Statement Has Been Properly Configured on R1, so
R2 Starts Receiving IGRP Routes
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: Advertised Subnet

Is VLSM
IGRP is not designed to carry subnet mask information; therefore, any subnet that is
using a different mask other than the interface that will be sourcing the IGRP update
will not be advertised by IGRP, which actually performs a check before sending an
update. This check makes sure that the subnet that will be advertised by IGRP has the
same subnet mask as the interface that will be sourcing the IGRP update. If the mask
is different, IGRP actually drops the update and will not advertise it. Therefore, in
IGRP, the subnet mask should be consistent; otherwise, it can cause this problem. This
is also explained in detail in Chapter 4.
Figure 5-25 shows a network setup that produces problems because of VLSM. The figure
shows that Router 1 has a VLSM subnet that is 131.108.2.0/25. This subnet will not go
across toward Router 2.

Figure 5-25 Network Setup Conducive to Advertised Subnet Problems Because of VLSM

131.108.2.0/25 .1 131.108.1.0/24 131.108.3.0/24

.2

Router 1 Router 2

Figure 5-26 shows the flowchart to follow to fix this problem.

 Problem: Sender Is Not Advertising IGRP Routes 183

Figure 5-26 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

IGRP does not support

variable-length subnet
masking. Any subnet that
has a different mask than
Is the advertised subnet Not sure the interface that is the
VLSM? source of the IGRP update
will not be advertised by
IGRP. Go to Debugs and
No Verification section.

Go to
next
cause.

Debugs and Verification

Example 5-65 shows that the loopback interface of R1 is configured for a /25 subnet mask
and also shows that the interface that will be sourcing the IGRP update has a /24 mask.
Example 5-65 R1’s Loopback Interface Configured with a Subnet Mask Incompatible with the Interface Sourcing
the IGRP Update
R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.128
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0

Solution
To solve the problem, you need to either change the subnet mask so that it matches the
interface that will be sourcing the IGRP update or change the protocol to EIGRP that does
support VLSM. Changing the protocol to EIGRP means that every router in the network
must be changed to EIGRP, so this is a long-term solution.
184 Chapter 5: Troubleshooting IGRP

Example 5-66 shows the configuration changes that correct the problem.
Example 5-66 Correcting the Mismatched Subnet Mask Problem
R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0

Example 5-67 shows the routing table entry of Router R2 after correcting the problem.
Example 5-67 R2’s Routing Table Verifies That the Mismatched Subnet Mask Problem Has Been Resolved
R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Sender Is Not Advertising IGRP Routes—Cause: Split Horizon Is

Enabled
Split horizon is a feature in IGRP that controls the routing loops. In some situations, it is
necessary to enable split horizon to avoid loops—for example, in a normal situation, an
IGRP update is received on an interface and is not sent out on the same interface. In other
situations, it must be disabled, such as in a hub-and-spoke Frame Relay situation when
spokes have no circuit between them and they go through the hub router (see Figure 5-27).
Another unique situation in this example is a router with an external route that has a next-
hop address also known through the same interface where other IGRP routers are sitting
(see Figure 5-28). When those external routes are redistributed into IGRP, the router does
not advertise that route out the same interface because split horizon is enabled. Also, if a
secondary address is configured under an interface, split horizon must be turned off on that
interface; otherwise, that secondary address will not be advertised out that interface to other
routers. In Figure 5-28, some secondary addresses are defined under R1’s Ethernet. For this
reason, you must configure no ip split-horizon under R1’s Ethernet interface.
Figure 5-28 shows the network setup that produces problems when split horizon is enabled.
Router 1 is not advertising all IGRP routes to Router 2.
 Problem: Sender Is Not Advertising IGRP Routes 185

Figure 5-27 Hub-and-Spoke Topology in Which Spokes Do Not Have Any Circuits Between Them

Hub

Frame Relay
131.108.1.0/24

131.108.2.0/24 131.108.3.0/24

Spoke 1 Spoke 2

Figure 5-28 Network Setup Conducive to Route Advertisement Problems Because of Split Horizon

166.166.166.0/24
.3
Router 3

155.155.155.0/24

.1
131.108.1.0/24
Router 1

.2
Router 2
186 Chapter 5: Troubleshooting IGRP

Figure 5-29 shows the flowchart to follow to fix this problem.

Figure 5-29 Problem-Resolution Flowchart

IGRP is not being advertised by Router R1.

Split horizon may need to

be disabled when
advertising secondary
Is split horizon enabled addresses or redistributed
Not sure
on the interface? routes known through the
same interface. Go to
Debugs and Verification
section.
No

Go to
next
problem.

Debugs and Verification

Example 5-68 shows the current configuration of R1. Note that 166.166.166.0/24 is known
through 131.108.1.3. R2 also resides on this subnet, so R1 will not send out any update on
this interface because of split horizon.
Example 5-68 R1 Configuration in Which a Static Route’s Next-Hop Address Falls Under Its Connected Subnet
Where RIP Is Enabled
R1#
router igrp 1
redistribute static
network 131.108.0.0
!
ip route 155.155.0.0 255.255.0.0 Null0
ip route 166.166.166.0 255.255.255.0 131.108.1.3

Example 5-69 shows that the route 166.166.166.0/24 is not in the routing table of Router R2.
Example 5-69 R2’s Route Table Indicates That the 166.166.166.0/24 Route Is Missing
R2#show ip route igrp
I 155.155.0.0/16 [100/8496] via 131.108.1.1, 00:00:07, Ethernet0

Example 5-70 shows the debug ip igrp transaction output on Router R1, which is advertising
155.155.0.0/16 but not 166.166.166.0/24. In R2’s routing table, no route exists for
166.166.166.0/24.
 Problem: Sender Is Not Advertising IGRP Routes 187

Example 5-70 debug ip igrp transaction Command Output Shows That 166.166.166.0/24 Is Not Being Advertised
R1#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: sending update to 255.255.255.255 via Ethernet0 (131.108.1.1)
network 155.155.0.0, metric=501

Solution
This problem happens because the next hop of 166.166.166.0/24 is 131.108.1.3. Under split
horizon, IGRP will suppress this update on the interface where 166.166.166.0/24 is learned.
Because of this, IGRP will not advertise 166.166.166/24 out the same interface where it is
learned.
The solution lies in turning off split horizon on R1’s Ethernet 0 interface.
Example 5-71 shows the corrected configuration on Router R1 to solve this problem.
Example 5-71 Disabling Split Horizon on R1 Ethernet 0 Interface
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
no ip split-horizon

Example 5-72 shows that, after making the configuration changes, R2 is receiving
166.166.0.0/16 in the IGRP updates. Note that, because it is crossing the major network
boundary, R1 will autosummarize it and send 166.166.0.0. This is why the routing table
shows 166.166.0.0 instead of 166.166.166.0.
Example 5-72 R2’s Routing Table Indicates That Disabling Split Horizon on R1 Has Enabled the Advertisement of
166.166.166.0/24
R2#show ip route igrp
I 155.155.0.0/16 [100/8496] via 131.108.1.1, 00:00:08, Ethernet0
I 166.166.0.0/16 [100/8496] via 131.108.1.1, 00:00:08, Ethernet0

This problem also can occur when interfaces are configured with secondary IP addresses.
Example 5-73 shows the interface configuration with a secondary IP address.
Example 5-73 R1’s Ethernet 0 Interface Configured with a Secondary IP Address
R1#
interface Ethernet0
ip address 131.108.2.1 255.255.255.0 secondary
ip address 131.108.1.1 255.255.255.0

If split horizon is enabled, this secondary address will not be advertised on Ethernet 0.
Similarly, imagine a situation in which there are three routers—R1, R2, and R3—on the
same Ethernet, as shown in Figure 5-30.
188 Chapter 5: Troubleshooting IGRP

Figure 5-30 Network with Three Routers on the Same Ethernet Network

OSPF
166.166.166.0/24
.3
Router 3
router igrp1
redistribute ospf2
OSPF
IGRP
.1
131.108.1.0/24
Router 1

IGRP
.2
Router 2

R1 and R3 are running OSPF. R1 and R2 are running IGRP. Now R3 advertises certain
routes through OSPF to R1 that R1 has to redistribute into IGRP. R1 will not advertise those
OSPF routes to R2 because of split horizon. Again, the solution is to disable split horizon.
Basically, these are the three main reasons for turning off the split horizon. Any other
situation might create a routing loop if split horizon is turned off.

Problem: Candidate Default Is Not Being Advertised—

Cause: ip default-network Command Is Missing
In a classless environment, when a router needs to send a packet to a particular destination,
it performs the following check in this order:
1 Is the destination address one of my connected interface addresses? If yes, use ARP
for the address and then encapsulate the packet in an Ethernet frame and send it to the
destination.
2 If no, do I have a route in my routing table for this destination address? If yes, use that
route from the routing table and send the packet.
3 If no, check whether the gateway of last resort is set. If it is set, send the packet to the
address mentioned in the gateway of last resort. (In Example 5-74, the packets will be
sent to 131.108.1.1. If there is no gateway of last resort, the packet is dropped.)
Example 5-74 shows that the gateway of last resort is set to 131.108.1.1. This means that if
a router does not have an entry in the routing table, it will send the packet to 131.108.1.1.
 Problem: Candidate Default Is Not Being Advertised 189

Example 5-74 Verifying That a Gateway of Last Resort Is Set

R1# show ip route
Gateway of last resort is 131.108.1.1 to network 0.0.0.0

In any routing protocol except IGRP, the way to set the gateway of last resort is to define a
static route 0.0.0.0 with the mask of 0.0.0.0 and a next-hop address, as shown in Example
5-75; however, IGRP cannot understand 0.0.0.0, so there is a separate way to set the gate-
way of last resort in IGRP.
Example 5-75 Configuring a Default Route to Set the Gateway of Last Resort
R1(config-term)#ip route 0.0.0.0 0 0.0.0.0 131.108.1.1

Figure 5-31 shows the flowchart to follow to fix this problem.

Figure 5-31 Problem-Resolution Flowchart

Candidate default is not being advertised by R1.

IGRP uses the ip default-

network command to
advertise a candidate
Is default-network statement Not sure default route. Go to
enabled? Debugs and Verification
section.

Yes

Go to
next
problem.

Debugs and Verification

Example 5-76 shows the configuration of R1. No default-network statement is configured.
Example 5-76 R1’s Configuration Reveals That a Candidate Default Route Has Not Been Configured
R1#interface Loopback1
ip address 131.108.2.1 255.255.255.0
!
interface Loopback3
ip address 155.155.155.1 255.255.255.0
!
continues
190 Chapter 5: Troubleshooting IGRP

Example 5-76 R1’s Configuration Reveals That a Candidate Default Route Has Not Been Configured (Continued)
interface Ethernet0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0
network 155.155.0.0

Example 5-77 shows the routing table in Router R2, which R2 is receiving 155.155.0.0/16,
but it is not a candidate for default because it is not configured as a candidate for default route.
Example 5-77 R2’s Routing Table
R2#show ip route igrp
I 155.155.0.0/24 [100/8976] via 131.108.1.1, 00:00:22, Serial0
131.108.0.0/24 is subnetted, 3 subnets
I 131.108.2.0 [100/8976] via 131.108.1.1, 00:00:22, Serial0

Solution
IGRP is incapable of carrying the 0.0.0.0/0 (also known as default route), as explained in
the problem section. Instead, it follows the default-network command to mark a network
as a candidate for default.
In this example, R1 is sending 155.155.0.0/16, and it is desirable to make R1 a candidate
for default. To do that, change the configuration on R1 and establish the 155.155.0.0
network as the default network. Upon doing this, IGRP automatically starts treating
155.155.0.0/16 as the candidate for default and will set the gateway of last resort on R2.
Example 5-78 shows the configuration for default-network on R1. This default-network
statement must always point toward a major network, not a subnet; otherwise, it will not set
the gateway of last resort.
Example 5-78 Configuring 155.155.0.0 as the Default Network
R1(config-term)#ip default-network 155.155.0.0

Example 5-79 illustrates that after the configuration change on R1, the debug ip igrp
transaction output shows IGRP treating 155.155.0.0/16 route as an exterior route because
it is marked as a candidate for default route.
Example 5-79 IGRP Treats 155.155.0.0 as an Exterior Route
IGRP: received update from 131.108.1.1 on Serial1
subnet 131.108.3.0, metric 8976 (neighbor 501)
subnet 131.108.1.0, metric 10476 (neighbor 8476)
exterior network 155.155.0.0, metric 8976 (neighbor 501)
 Problem: Redistributed Routes Are Not Getting Installed in the Routing Table 191

Example 5-80 now shows that the gateway of last resort is set and that 155.155.0.0/16 is
marked as a candidate for default. Also, the * next to the I in the routing table entry means
that this entry is a candidate for a default route.
Example 5-80 R2’s Routing Table Indicates the Candidate for Default and Shows That the Gateway of Last Resort
Is Set to 155.155.0.0
R2#show ip route

Gateway of last resort is 131.108.1.1 to network 155.155.0.0

137.99.0.0/24 is subnetted, 1 subnets

C 137.99.3.0 is directly connected, Loopback0
I* 155.155.0.0/16 [100/8976] via 131.108.1.1, 00:01:17, Serial1

Troubleshooting IGRP Redistribution Problems

This section covers a common problem that can happen during redistribution in IGRP.
Redistribution occurs when another routing protocol, static route, or connected route is
being injected into IGRP. Special care is required during this process to avoid any routing
loops. Metrics also should be defined during this process, to avoid problems.
The most prevalent problem encountered with IGRP redistribution is that redistributed routes
are not getting installed in the routing table of the IGRP routers receiving these routes. When
destination routes are not present in the routing table, no data can reach those destinations.

Problem: Redistributed Routes Are Not Getting

Installed in the Routing Table—Cause: Metric Is Not
Defined During Redistribution into IGRP
IGRP has a composite metric made up of bandwidth, delay, reliability, load, and MTU;
however, by default, it utilizes only bandwidth and delay. OSPF’s metric is based on interface
cost. Cost is derived from the bandwidth of the link. Cisco uses 100,000,000/bandwidth to
get the cost. IGRP does not understand the metrics of other protocols (except EIGRP) so it is
necessary to input a default metric when doing redistribution.
Figure 5-32 shows the network setup susceptible to the problem in which redistributed
routes do not get installed in the routing table.
OSPF is redistributed into IGRP at R1, but R2 is not receiving IGRP routes that are OSPF
routes in R1.
Figure 5-33 shows the flowchart to follow to solve this problem.
192 Chapter 5: Troubleshooting IGRP

Figure 5-32 Network Setup Conducive to Redistributed Routes Not Being Installed in the Routing Table

131.108.6.0/24
Router 3

OSPF 131.108.5.0/24

131.108.1.0/24

IGRP
Router 1
Router 2

Figure 5-33 Problem-Resolution Flowchart

IGRP routes are not in the routing table of R2.

When redistributing into

IGRP, you must define a
default metric for
Is the default redistributed routes or
metric defined on the Not sure those routes will not be
redistributing router? understood by the IGRP
routing process. Go to
Debugs and Verification
Yes section.

Go to
next
problem.

Debugs and Verification

Example 5-81 shows that R3 is advertising 131.108.6.0/24 through OSPF to R1.
Example 5-81 R1’s Routing Table Shows That R3 Is Advertising 131.108.6.0/24 Through OSPF
R1#show ip route 131.108.6.0
Routing entry for 131.108.6.0/24
Known via "ospf 1", distance 110, metric 20, type intra area
 Problem: Redistributed Routes Are Not Getting Installed in the Routing Table 193

Example 5-82 shows that R1 is redistributing OSPF in IGRP.

Example 5-82 R1 Configuration to Redistribute OSPF into IGRP
R1#
router igrp
redistribute ospf 1
network 131.108.0.0

Example 5-83 shows that in R2, 131.108.6.0/24 is not present in the IGRP routing table.
Example 5-83 R2’s Routing Table Is Missing the Redistributed Route
R2#show ip route 131.108.6.0
% Subnet not in table

Solution
To solve this problem, R1 needs to put a metric command under the router igrp statement
so that it can calculate the OSPF metric properly.
Example 5-84 shows the new configuration for R1. OSPF is redistributed into IGRP with
metric values of bandwidth, delay, load, reliability, and MTU. Setting low bandwidth and
high delay yields to a high metric for redistributed routes.
Example 5-84 Configuring R1 to Calculate OSPF Metrics
R1#router igrp 1
redistribute ospf 1 metric 1 10000 255 1 1500
network 131.108.0.0

Another way to fix this problem is to define a default metric under the router igrp state-
ment. The difference between using a default metric and defining a metric as shown in
Example 5-84 is that a default metric will be used for all the redistribution. For example,
if the router igrp statement has multiple redistribution commands, all the redistributed
routes will have a default metric value defined under the router igrp command.
Example 5-85 shows the syntax for default-metric command under the router igrp state-
ment when redistributing into IGRP. The metric values are based on bandwidth, delay, load,
reliability, and MTU. So, in this case, all the static and OSPF routes will be redistributed
with the default metric configured here.
Example 5-85 Configuring a Default Metric
R1#router igrp 1
redistribute ospf 1
redistribute static
default-metric 1 10000 255 1 1500
network 131.108.0.0
194 Chapter 5: Troubleshooting IGRP

Example 5-86 shows that the route gets installed in the routing table.
Example 5-86 R2’s Routing Table Verifies That the New Configuration for R1 Has Corrected the Problem
R2#show ip route 131.108.6.0
Routing entry for 131.108.6.0/24
Known via "igrp", distance 100, metric 8976

Troubleshooting Dial-on-Demand Routing

(DDR) Issues in IGRP
Dial-on-demand routing is very common when the ISDN or similar dialup links are used as
a backup link. When the primary link goes down, this backup link comes up. IGRP starts
sending and receiving updates on this link as long as the primary link is down.
Two ways exist for using the dialup links as a backup for the primary link:
• Using the backup interface command
• Using floating static routes with a dialer list that defines interesting traffic
The first method is simple: The command is typed under the dial interface indicating that it
is a backup for a primary interface.
The second method requires a floating static route with a higher administrative distance
than IGRP—for example, 110 or above. It also requires defining interesting traffic that
should bring up the link. The IGRP broadcast address of 255.255.255.255 must be denied
in the dialer list, so it should not bring up the link unnecessarily.
When running IGRP under dial backup situations, a lot of issues must be considered. Some
problems are related to the ISDN line or async line that keeps coming up. Some problems
are related to the configuration. This section talks about the two most common dial backup
problems:
• IGRP broadcast is keeping the link up.
• IGRP updates are not going across dialer interface.

Problem: IGRP Broadcast Is Keeping the ISDN Link

Up—Cause: IGRP Broadcasts Have Not Been Denied in
the Interesting Traffic Definition
ISDN links typically are used as backup links when primary links go down. Cisco IOS
Software requires that routers are instructed on the kind of traffic that can bring up the
ISDN link and keep it up. Such traffic is called interesting traffic. Network operators
 Problem: IGRP Broadcast Is Keeping the ISDN Link Up 195

typically want data traffic to be considered as interesting traffic, to bring up and keep up the
ISDN link. IGRP or other routing protocol updates should not be defined as interesting
traffic. If this is not done, the ISDN link comes up and stays up as long as routing updates
(IGRP, in this case) are taking place on a regular basis. That is not the desired behavior
because ISDN provides low-speed connectivity and because some data actually could go
over the slow link even though the primary faster link is available.
Figure 5-34 shows the network setup susceptible to dial backup issues.

Figure 5-34 Network Setup Conducive to Dial Backup Problems

.13 .14
ISDN
BRI 3/0 BRI 3/0
Router 1 Router 2
192.168.254.12/30

Figure 5-35 shows the flowchart to follow to fix this problem.

Figure 5-35 Problem-Resolution Flowchart

IGRP updates are keeping the link up.

When IGRP is run in

DDR, IGRP broadcasts
Is IGRP broadcast should not be permitted in
permitted as interesting Not sure the interesting traffic
traffic? definition. Go to Debugs
and Verification section.

No

Go to
next
problem.

Debugs and Verification

Example 5-87 shows the configuration on Router R1 that produces this problem. In this
configuration, only TCP traffic is denied. In other words, TCP traffic will not bring up and
keep up the link. IGRP broadcasts are IP packets; because the permit ip any any command
196 Chapter 5: Troubleshooting IGRP

allows any IP traffic to go through besides TCP, IGRP broadcast traffic will be considered
interesting traffic.
Example 5-87 R1 Configuration in Which IGRP Broadcasts Are Not Denied
R1#
interface BRI3/0
ip address 192.168.254.13 255.255.255.252
encapsulation ppp
dialer map ip 192.168.254.14 name R2 broadcast 57654
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap

access-list 100 deny tcp any any

access-list 100 permit ip any any
dialer-list 1 protocol ip list 100

Example 5-88 shows the output of show dialer, which indicates that the reason for the link
coming up is IGRP broadcast.
Example 5-88 show dialer Output Indicates the Last Time the Link Was Up Was Because of IGRP Broadcast
R1#show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=255.255.255.255)
Current call connected 00:00:08
Connected to 57654 (R2)

Solution
When running IGRP and DDR, define the access list to define the interesting traffic. In
Example 5-87, the access list is denying only the TCP traffic and is permitting all the IP
traffic. IGRP uses an IP broadcast address of 255.255.255.255 to send the routing updates.
This address must be denied in the access list so that IGRP does not bring up the link every
90 seconds.
Example 5-89 shows the correct configuration change in Router R1. In this configuration,
all traffic destined to the 255.255.255.255 address is denied. This covers IGRP broadcast,
so IGRP will not bring up the link after this configuration change.
Example 5-89 Configuring R1’s Access List to Deny IGRP Broadcast Traffic
R1#
access-list 100 deny tcp any any
access-list 100 deny ip any 255.255.255.255
access-list 100 permit ip any any
dialer-list 1 protocol ip list 100
 Problem: IGRP Updates Are Not Going Across the Dialer Interface 197

Problem: IGRP Updates Are Not Going Across the

Dialer Interface—Cause: Missing Broadcast Keyword
in a dialer map Statement
When a dialer interface—say, ISDN—comes up, it could be desirable to run a routing
protocol over this link. Static routes might do the job, but in networks with a large number
of routes, static routes might not scale well. Therefore, running a dynamic routing protocol
is necessary. In some situations, the ISDN link is up but no routing information is going
across. Without a routing protocol, no destination addresses can be learned and no traffic
can be sent to those destinations. This problem needs to be fixed because ISDN interfaces
are of no use when not carrying any traffic.
Figure 5-36 shows the flowchart to follow to solve this problem.

Figure 5-36 Problem-Resolution Flowchart

IGRP updates are not going across the dialer interface.

IGRP uses a broadcast for

routing updates. When
using IGRP over ISDN
Is the broadcast keyword implementations, be
Not sure certain to include the
missing from the dialer map
statement? broadcast keyword in
dialer map statements. Go
to Debugs and Verification
section.
No

Go to
next
problem.

Debugs and Verification

Example 5-90 shows the configuration on R1 that produces this problem. The dialer map is
used to map the neighbor IP address with a string, which is normally an ISDN number. This
is called a static mapping for dialer. When using static mapping, the keyword broadcast must
be included at the end; otherwise, it will not propagate the broadcast traffic across the link.
Example 5-90 R1 Configuration Preventing IGRP Updates Across Dialer Interface
R1#
interface BRI3/0
ip address 192.168.254.13 255.255.255.252
encapsulation ppp
continues
198 Chapter 5: Troubleshooting IGRP

Example 5-90 R1 Configuration Preventing IGRP Updates Across Dialer Interface (Continued)
dialer map ip 192.168.254.14 name R2 57654
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap

Example 5-91 shows that IGRP is sending the broadcast update toward R2, but because of
an encapsulation failure, it is not getting on the other side.
Example 5-91 Confirming an Encapsulation Failure
R1#show access-list 100
access-list 100 permit ip any host 255.255.255.255
R1#debug ip packet 100 detail
IP: s=192.168.254.13 (local), d=255.255.255.255 (BRI3/0), len 46, sending broad/
multicast, proto=9
IP: s=192.168.254.13 (local), d=255.255.255.255 (BRI3/0), len 72, encapsulation
failed, proto=9

Solution
This problem occurs because IGRP uses broadcasts to send its routing updates. When using
dialer map statements, you must include the broadcast keyword; otherwise, the broadcast
will not be allowed to cross the circuit and the encapsulation failures occur. To correct this
problem, add the broadcast keyword in the dialer map statement.
Example 5-92 shows the new configuration change on Router R1.
Example 5-92 Configuring R1 to Allow Broadcasts Across the Dialer Interface
interface BRI3/0
ip address 192.168.254.13 255.255.255.252
encapsulation ppp
dialer map ip 192.168.254.14 name R2 broadcast 57654
dialer-group 1
isdn switch-type basic-net3
ppp authentication chap

Troubleshooting Route Flapping Problem

in IGRP
Running IGRP in a complex environment sometimes can cause flapping of routes. Route
flapping means that the routes keep coming and going from the routing table. To see
whether the routes are indeed flapping, check the routing table and look at the age of the
routes. If the ages are constantly getting reset to 00:00:00, the routes are flapping. There
could be several reasons for this. This section discusses one of the most common reasons—
packet loss. Packet loss prevents an IGRP update from reaching the other side.
 Problem: IGRP Routes Are Flapping 199

The example in this section considers Frame Relay because it is the most common
medium in which this problem occurs. The packet loss can be verified through the
interface statistics by looking at the number of packet drops and seeing if it is con-
stantly incrementing.

Problem: IGRP Routes Are Flapping—Cause: Packet

Drops on Sender’s or Receiver’s Interface
When IGRP is used in a large Frame Relay environment where there are several neigh-
bors on one Frame Relay interface, there is a possibility of a packet loss. The packet loss
in IGRP means that the whole update is lost. If a sender or receiver drops an IGRP update,
it has to wait for another update because the IGRP updates are not retransmitted after it
is lost.
The most common reason for packet drops on Frame Relay interfaces is a result of broad-
cast drops in the broadcast queue of Frame Relay. Broadcast queues in Frame Relay are
designed to carry all the broadcast traffic. If there is a lot of broadcast traffic, the broadcast
queue needs to be tuned.
Figure 5-37 shows the network setup susceptible to a IGRP route-flapping problem.

Figure 5-37 Network Setup Conducive to Route Flapping

Hub

Frame Relay

Router 1 Router 2

Figure 5-38 shows the flowchart to follow to solve this problem.

200 Chapter 5: Troubleshooting IGRP

Figure 5-38 Problem-Resolution Flowchart

IGRP routes are flapping.

When IGRP sends or

receives the update and
there are packet drops in
Are there any large packet the broadcast queue, it can
drops on the sender’s or Not sure cause IGRP routes to flap.
receiver’s interface? In this case, the broadcast
queue needs to be tuned.
Go to Debugs and
Verification section.
No

Go to
next
problem.

Debugs and Verification

The show ip route output in Example 5-93 shows that the routes are 3:08 old, so it has
missed two updates. If IGRP does not receive a route for 270 seconds, the route will be put
into holddown. This situation gets corrected by itself, but, in some cases, changes to the
configuration are required. For example, consider the output in Example 5-93.
Example 5-93 show ip route igrp Command Output Indicates That IGRP Did Not Receive Updates for 3 Minutes
and 8 Seconds
Hub#show ip route igrp
I 155.155.0.0/16 [100/8242] via 131.108.1.1, 00:03:08 , Serial0
I 166.166.0.0/16 [100/8242] via 131.108.1.1, 00:03:08 , Serial0

The output in Example 5-93 shows that no IGRP update has been received since 3 minutes
and 8 seconds. This means that two IGRP updates have been missed.
Example 5-94 shows that there are a large number of broadcast drops on the interface. The
broadcast queue size also is 64, which is the default, and it must be increased.
Example 5-94 Serial Interface Shows That the Broadcast Queue Is Dropping a Large Number of Packets
Hub#show interface serial 0
Serial0 is up, line protocol is up
Hardware is MK5025
Description: Charlotte Frame Relay Port DLCI 100
MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
 Troubleshooting Variance Problem 201

Example 5-94 Serial Interface Shows That the Broadcast Queue Is Dropping a Large Number of Packets (Continued)
LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE
LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE

Broadcast queue 64/64, broadcasts sent/dropped 1769202/1849660, interface

broadcasts 3579215

Solution
The output in Example 5-94 further proves that there is some problem at the interface level.
Too many drops are occurring at the interface level. This is causing the route flapping. To
correct this problem, you must tune the Frame Relay broadcast queue accordingly. Tuning
the Frame Relay broadcast queue is beyond the scope of this book. Several papers on the
Cisco web site discuss how to tune the Frame Relay broadcast queue:
www.cisco.com/warp/partner/synchronicd/cc/techno/media/wan/
frame/prodlit/256_pb.htm
www.cisco.com/warp/public/125/20.html
Example 5-95 shows that after fixing the interface drop problem, route flapping disappears.
The broadcast queue size is changed from 64 to 256. The correct number can be determined
after reading the URL mentioned earlier for tuning the broadcast queue.
Example 5-95 Verifying That the Serial Interface Is Not Dropping Any Broadcast Traffic in the Broadcast Queue
Hub#show interface serial 0
Serial0 is up, line protocol is up
Hardware is MK5025
Description: Charlotte Frame Relay Port DLCI 100
MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/256, broadcasts sent/dropped 1769202/0, interface broadcasts
3579215

Example 5-96 shows that the show ip routes output verifies that the routes are stable in the
routing table.
Example 5-96 Verifying Stable Routes
Hub#show ip route igrp
I 155.155.0.0/16 [100/8242] via 131.108.1.1, 00:00:07, Serial0
I 166.166.0.0/16 [100/8242] via 131.108.1.1, 00:00:07, Serial0

Troubleshooting Variance Problem

Variance is a unique feature of IGRP (and EIGRP) that distinguishes it from RIP. Variance
is basically a way to load-balance the traffic on unequal-cost paths.
202 Chapter 5: Troubleshooting IGRP

All routing protocols support equal-cost-path load balancing, but only IGRP and EIGRP
support unequal-cost-path load balancing, which is configured using a variance command.
Configuration of variance is easy, as long as you know the concept behind it.
The variance command instructs the router to include routes with a metric smaller than
n times the minimum metric route for that destination, where n is the number specified
by the variance command.

Problem: IGRP Not Using Unequal-Cost Path for Load

Balancing—Cause: variance Command Is Missing or
Misconfigured
To use the variance feature (unequal-cost-path load balancing), it must be configured under
the router igrp command. By default, IGRP does not do unequal-cost-path load balancing.
Also, when the variance factor is multiplied by the current best metric, the resulting number
is compared with other available path metrics. Any available path metric that is under this
resulting number will be used for unequal-path load balancing.
Figure 5-39 shows the network setup susceptible to this problem. The network 155.155.0.0/16
is known through two paths, but only one is in the routing table.

Figure 5-39 Network Setup Conducive to Load-Balancing Problems

Delay 20000
155.155.0.0/16
Delay 40000
Router 1 Router 2

Figure 5-40 shows the flowchart to follow to solve this problem.

Figure 5-40 Problem-Resolution Flowchart

IGRP is not using unequal-cost path for load balancing.

Without the variance

command, IGRP will not
Is the variance command
Not sure do unequal-cost-path load
configured with the correct
balancing. Go to Debugs
multiplier?
and Verification section.

Yes
 Problem: IGRP Not Using Unequal-Cost Path for Load Balancing 203

Debugs and Verification

Example 5-97 shows the routing table entry on R1 showing that R1 is using only one path
to reach 155.155.0.0/16.
Example 5-97 R1 Routing Table Entry Shows That Only a Single Path Is Used to Reach the Destination Network
R1#show ip route 155.155.0.0
Routing entry for 155.155.0.0/16
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.6.2 on Serial2, 00:00:03 ago
Routing Descriptor Blocks:
* 131.108.6.2, from 131.108.6.2, 00:00:03 ago, via Serial2
Route metric is 8976, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

Example 5-98 shows the interface configuration on both Serial2 and Serial3. Band-
widths are equal in this example, but they could have different values in different
scenarios.
Example 5-98 R1’s Serial2 and Serial3 Interface Configurations
R1#show interface serial2
Serial2 is up, line protocol is up
Hardware is HD64570
Internet address is 131.108.6.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 400000 usec, rely 255/255, load 1/255

R1#show interface serial3

Serial3 is up, line protocol is up
Hardware is HD64570
Internet address is 131.108.7.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec , rely 255/255, load 1/255

Example 5-99 shows the IGRP configuration on R1. The variance command is configured,
but the multiplier has the wrong value. The metric from Serial3 is more than five times
larger, which is why the variance is not working. If you multiply the metric value of Serial2
(which is 8976) by 5, you get 44,880, which is still not enough because the metric for
Serial3 is 46,976.
Example 5-99 Improperly Configured Variance Value
R1#
!
router igrp 1
variance 5
network 131.108.0.0
204 Chapter 5: Troubleshooting IGRP

Solution
To solve this problem, choose a variance factor that yields a metric that is higher then the
one being used by another unequal-cost path. For example, when you multiply the current
metric of 8796 by 6 instead of 5, you get a value of 52,776. So, any link that has a metric
value of less than 52,776 will be used in this unequal-cost-path load balancing. In this
example, Serial3 has a metric value of 46,976. Because this number is less than 52,776, it
is used for load balancing.
In Example 5-99, the second link metric is more than five times larger than the current
metric. Example 5-100 shows that by changing the variance value to 6, IGRP starts
including the second path.
Example 5-100 Correcting the Variance So That IGRP Uses Both Paths
R1#!
router igrp 1
variance 6
network 131.108.0.0

Example 5-101 shows that R1 is installing both paths in the routing table, but with the
traffic share count ratio equal to 5.
Example 5-101 R1 Routing Table Shows the Traffic Share Count Ratio
R1#show ip route 155.155.0.0
Routing entry for 155.155.0.0/16
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.7.2 on Serial3, 00:00:07 ago
Routing Descriptor Blocks:
* 131.108.6.2, from 131.108.6.2, 00:00:07 ago, via Serial2
Route metric is 8976, traffic share count is 5
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
131.108.7.2, from 131.108.7.2, 00:00:07 ago, via Serial3
Route metric is 46976, traffic share count is 1
Total delay is 405000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

The traffic share count ratio is calculated by dividing the worst metric by the metric of a
path. In this case, the path from Serial3 is worse and has a value of 46,976.
46,976/46,976 = 1 for Serial3
46,976/8976 = 5 for Serial2 (The result is always rounded off to the lowest integer.)
So, in this example, the ratio is 5:1. After every five packets forwarded on Serial2, Serial3
will be used for one packet.
This page intentionally left blank
This chapter covers the following key topics about Enhanced IGRP (EIGRP):
• Metrics
• EIGRP neighbor relationships
• The Diffusing Update Algorithm (DUAL)
• DUAL finite-state machine
• EIGRP reliable transport protocol
• EIGRP packet format
• EIGRP behavior
• EIGRP summarization
• EIGRP query process
• Default routes and EIGRP
• Unequal-cost load balancing in EIGRP
 CHAPTER
6
Understanding Enhanced
Interior Gateway Routing
Protocol (EIGRP)
As the size of network grows larger, you can see that the classical distance vector routing
protocols such as IGRP and RIP won’t scale to the needs of the network. Some of the
biggest scalability problems of IGRP and RIP are as follows:
• Full periodic routing updates that consume bandwidth—RIP sends out its
entire routing table every 30 seconds; IGRP sends out its entire routing table every
90 seconds. This consumes significant bandwidth.
• RIP hop-count limitation of 15 hops—This limitation makes RIP protocol a non-
scalable routing protocol in today’s networks because most medium-sized networks
have more than 15 routers.
• No support of VLSM and discontiguous networks—This also hinders the capability
to scale large networks for RIP and IGRP. Because of this factor, router summarization
is not supported.
• Slow convergence time—Because RIP and IGRP send periodic routing updates, a
network that is not available in one part of the network could take minutes for the
other part of the network to discover that it’s no longer available.
• Not 100 percent loop-free—RIP and IGRP do not keep topology tables, so there is
no mechanism for them to ensure a 100 percent loop-free routing table.
Because of these shortcomings of IGRP and RIP, Cisco developed an enhanced version of
IGRP that not only fixed all the problems of IGRP and RIP but also developed a routing
protocol robust enough to scale to today’s network growth. This enhanced version is called
Enhanced Interior Gateway Routing Protocol (EIGRP).
EIGRP is neither a classic distance vector routing protocol nor a link-state protocol—it is
a hybrid of these two classes of routing protocol. Like a distance vector protocol, EIGRP
gets its update from its neighbors. Like a link-state protocol, it keeps a topology table of the
advertised routes and uses the Diffusing Update Algorithm (DUAL) to select a loop-free
path. The convergence time in a network is the time that it takes for all the routers in the
network to agree on a network change. The shorter the convergence time is, the quicker a
router can adapt to a network topology change. Unlike a traditional distance vector protocol,
EIGRP has fast convergence time and does not send full periodic routing updates. Unlike a
link-state protocol, EIGRP does not know what the entire network looks like; it depends
only on its neighbor’s advertisement. Because EIGRP has characteristics of both distance
208 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

vector and link-state protocols, Cisco has classified EIGRP as an advanced distance vector
routing protocol.
Advantages of EIGRP include the following:
• 100% loop-free—EIGRP is guaranteed to have a 100 percent loop-free forwarding
table if all the networks are contained within one autonomous system.
• Easy configuration—Configuration of EIGRP is extremely easy and is the same as
IGRP and RIP at the basic level.
• Fast convergence—Convergence time for EIGRP is much faster than that for RIP and
IGRP.
• Incremental update—In an EIGRP network, no routing update is exchanged except
for a network change. Also, only the change is updated, not the entire routing table.
This saves CPU power and is more efficient.
• Use of multicast address—IGRP and RIP use the broadcast address of
255.255.255.255 to send their packets. This means that every device on the same
network segment receives the updates. EIGRP sends its packet over the multicast
address of 224.0.0.10, which ensures that only the EIGRP-enabled devices receive the
EIGRP packets.
• Better utilization of bandwidth—EIGRP obtains the bandwidth parameter from the
interface in which EIGRP packets will be sent out. It is a parameter in which its values
are assigned to a particular interface. For example, by default, all serial interfaces have
a bandwidth of 1544 kbps; however, this bandwidth parameter is configurable. EIGRP
can use up to 50 percent of the interface bandwidth to carry EIGRP packets. This
ensures that EIGRP packets will not starve the routed data packet during a major
network convergence event. RIP and IGRP do not have this feature, so potentially
large amounts of RIP or IGRP updates would prevent regular data packets from going
through.
• Support for VLSM and discontiguous networks—Unlike RIP and IGRP, EIGRP
supports VLSM and discontiguous networks. This enables EIGRP to be implemented
in the modern network and lends itself to better network scalability.

Metrics
EIGRP and IGRP use the same equation to calculate their metrics; however, the EIGRP
metric is obtained by multiplying the IGRP metric by 256. In other words:

EIGRP ,Metric = IGRP ,Metric × 256

where the IGRP metric is shown in Equation 6-1.

 EIGRP Neighbor Relationships 209

By default, the K values of K1 and K3 are 0; therefore, the EIGRP metric simplifies to this:

EIGRP Metric = [ ( 10 7 ⁄ lesser bandwidth on path ) + ( sum of all delays ) ] × 256

Equation 6-1 IGRP Metric

( K2 × BW ) K5
IGRP Metric = K1 × BW + -------------------------------- + K3 × Delay × ----------------------------
( 256 – Load ) ( Reli + K4 )

K1, K2, K3, K4, K5 = Constants

Default values: K1 = K3 = 1, K2 = K4 = K5 = 0
7
BW = 10 ⁄ ( min bandwidth along paths in kilobits per second )
Delay = ( Sum of delays along paths in milliseconds ) ⁄ 10
Load = Load of interface
Reli = Reliability of the interface

EIGRP is different than IGRP metric by a factor of 256 because of the Metric field: IGRP
uses only 24 bits in its update packet for the Metric field, whereas EIGRP uses 32 bits in its
update packet for the Metric field. The difference of 8 bits requires the IGRP metric to be
multiplied by 256 to obtain the EIGRP metric. For example, if the IGRP metric to a desti-
nation network is 8586, the EIGRP metric would be 8586 ⫻ 256 = 2,198,016.

EIGRP Neighbor Relationships

Unlike IGRP, EIGRP must establish neighbor relationships before updates are sent out.
When an EIGRP process is configured on the router, the router begins to exchange EIGRP
hello packets over the multicast address of 224.0.0.10. Neighbor relationships form be-
tween routers when they receive each other’s hello packet. Over LAN broadcast media such
as Ethernet, Token Ring, or FDDI, the hello packets are sent every 5 seconds. Over WAN
multipoint interfaces with a bandwidth greater than T1, and over point-to-point sub-
interfaces, the hello packets are also sent out every 5 seconds. WAN multipoint interfaces
with a bandwidth of T1 or lower are considered to be low-bandwidth interfaces, and the
hello packets are sent out every 60 seconds.
Aside from the hello time, there is also a notion of a hold time. The hold time tells the router
the maximum time that it will wait to reset a neighbor if hello packets are not received. In
other words, if the hold time expires before a hello packet is received, the neighbor rela-
tionship will be reset. The default value of the hold time is three times the hello time. This
means that in the LAN broadcast media where the hello time is 5 seconds, the hold time
will be 15 seconds, and the slow WAN interfaces with a hello time of 60 seconds will have
a default hold time of 180 seconds. Keep in mind that you can configure the hello and hold
210 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

times. Certain conditions must be met before EIGRP routers consider establishing a
neighbor relationship:
• The receiving router compares the source address of the hello packet with the IP
address of the interface where the packet was received, to ensure that they belong to
the same subnet.
• The receiving router compares the K constant values of the source router to its own,
to make sure that they match.
• The receiving router must be within the same autonomous system number as the
source router.
Example 6-1 shows the output of the show ip eigrp neighbor command when the neighbor
relationship is fully established.
Example 6-1 show ip eigrp neighbor Command Output
Router_1#show ip eigrp neighbor
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 5.5.5.4 Et0 11 00:00:22 1 4500 0 3
0 192.168.9.5 Et1 10 00:00:23 372 2232 0 2

The explanations of the heading of the output are as follows:

• H—The list of the neighbors in the order in which they are learned.
• Address—The IP address of the neighbors.
• Interface—The interface from which the neighbors are learned.
• Hold—The hold timer for the neighbor. If this timer reaches 0, the neighbor relation-
ship is torn down.
• Uptime—The timer that tracks how long this neighbor has been established.
• SRTT (Smooth Round Trip Time)—The average time in which a reliable EIGRP
packet is sent and received.
• RTO (Round Trip Timeout)—How long the router will wait to retransmit the EIGRP
reliable packet if acknowledgment is not received.
• Q Count—The number of EIGRP packets waiting to be sent to the neighbor.
• Sequence Number—The sequence number of the last EIGRP reliable packets being
received from the neighbor. This is to ensure that packets received from the neighbor
are in order.
 The Diffusing Update Algorithm 211

The Diffusing Update Algorithm

The Diffusing Update Algorithm (DUAL) is the brain behind the operation of EIGRP. It is
an algorithm that tracks all the routes advertised from a neighbor and then selects a loop-
free path to the destination. Before discussing the details of DUAL, you must understand
several terms and concepts:
• Feasible distance (FD)—Feasible distance is the minimum metric along the path to
a destination. Figure 6-1 shows the feasible distance calculation to reach Network 7
for each of Router A’s neighbors, from Router A’s perspective.
Figure 6-1 Feasible Distance Calculation

Network 7
(20) (10)
(100) H G
(1)

B FDDI C
A (100)

(100) (10)
D E F
(100) (20)

Destination Feasible Distance (FD) Neighbor

Topology 100+20+10=130
7 H
Table
7 100+1+10+10=121 B
7 100+100+20+10+10=240 D

• Reported distance (RD)—Reported distance, sometimes also known as advertised

distance, is the metric toward the destination, as advertised by the upstream neighbor.
In other words, the reported distance is the neighbor’s metric going to the destination.
Figure 6-2 shows the reported distance calculation to reach Network 7 for each of
Router A’s neighbors.
• Feasibility condition (FC)—The feasibility condition (FC) is a condition in which
the reported distance (RD) is less than the feasible distance (FD). In other words, the
feasibility condition is met when the neighbor’s metric to a destination is less than
the local router’s metric. This condition is important to ensure a loop-free path.
• EIGRP successor—A successor is a neighbor that met the feasibility condition (FC)
and has the lowest metric toward the destination. A successor is used as the next hop
to forward the packet going to the destination network.
212 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

Figure 6-2 Reported Distance Calculation

Network 7
(20) (10)
(100) H G
(1)

B FDDI C
A (100)

(100) (10)
D E F
(100) (20)

Destination Reported Distance (RD) Neighbor

Topology 20+10=30
7 H
Table
7 1+10+10=21 B
7 100+20+10+10=140 D

• Feasible successor—A feasible successor is a neighbor that satisfies the feasibility

condition (FC) but is not selected as the successor. The feasible successor can be
thought of as a potential backup route when the primary route goes away.
Figure 6-3 illustrates the concepts of successor and feasible successor.
Figure 6-3 Explanation of Successor and Feasible Successor

Network 7
(20) (10)
(100) H G
(1)

B FDDI C
A (100)

(100) (10)
D E F
(100) (20) Router A’s
Routing table
Destination FD RD Neighbor
Topology 7 130 30 H 7 121 B
Table
7 121 21 B
7 240 140 D

• B is the current successor (FD = 121).

• H is the feasible successor (30 < 121).
 DUAL Finite-State Machine 213

Router B is chosen as the successor because Router B has the lowest feasible distance
(metric = 121) to Network 7 among all of Router A’s neighbors. To select a feasible
successor, Router A sees which neighbor has a reported distance (RD) that is less than
the feasible distance of its successor. In this case, Router H has a reported distance of
30, which is less than the feasible distance of its successor, which is 121. Therefore,
Router H is chosen as the feasible successor. Router D is neither a successor nor a
feasible successor because its reported distance is 140, which is larger than 121 and
thus does not satisfies the feasibility condition.
• Passive route—A passive route in EIGRP indicates that the router has a valid
successor to a destination and EIGRP has no complaints.
• Active route—An active route in EIGRP indicates that the router has lost its succes-
sor, it doesn’t have any feasible successor available, and the router is currently actively
searching for alternate routes to converge.

DUAL Finite-State Machine

When EIGRP loses its successor or primary route, EIGRP immediately tries to reconverge
by looking at its topology table to see if any feasible successors are available. If a feasible
successor is available, EIGRP immediately promotes the feasible successor to a successor
and informs its neighbors about the change. The feasible successor then becomes the next
hop for EIGRP to forward the packets to the destination. The process by which EIGRP
converges locally and does not involve other routers in the convergence process is called
local computation. This also saves CPU power because all the feasible successors are
already chosen before the primary route failures. (Refer to Figure 6-3.) If the primary route
(Router D) is not available for some reason, the preselected feasible successor Router H
immediately takes over as the primary route.
Now, if the primary route goes away and no feasible successors are available, the router
goes into diffused computation. In diffused computation, the router sends query packets to
all its neighbors asking for the lost route, and the router goes into Active state. If neighbor-
ing routers have information about the lost route, they reply to the querying router. If
neighboring routers do not have information about the lost route, they send queries to all
their neighbors. If the neighboring router does not have an alternate route and doesn’t have
any other neighbors, it sends a reply packet back to the router with a metric set to infinity,
indicating that it, too, doesn’t have an alternate route available. The querying router waits
for all the replies from all its neighbors and then chooses the neighbor with the best metric
in its replies as the next hop to forward packets.
Referring to Figure 6-3, if the primary successor Router B is not available and its feasible
successor Router H is also not available, Router A sends a query to Router D asking for
Network 7. In this case, Router D simply replies to the query with a valid metric to Network
7. Router A then converges using Router D as its next hop to Network 7.
214 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

To sum up the operation of DUAL, DUAL selects a successor as the primary path and also
selects a feasible successor as its backup path based on the feasibility condition. If the
successor becomes unavailable, the feasible successor is used as the primary route. If
the feasible successor is not present, the router queries all its neighbors and computes a new
successor based on the replies to the queries. Therefore, in an EIGRP network, the query
mechanism is the only means to achieve fast convergence.
Chapter 8 of the Cisco Press book Routing TCP/IP, Volume 1, by Jeff Doyle, provides an
excellent, detailed description of the operation of the EIGRP DUAL algorithm.

EIGRP Reliable Transport Protocol

Five types of EIGRP packets exist, further categorized as reliable packets and unreliable
packets. The reliable EIGRP packets are as follows:
• Update—Update packets contain EIGRP routing updates sent to an EIGRP neighbor.
• Query—Queries are sent to neighbors when a route is not available and the router
needs to ask the status of the route for fast convergence.
• Reply—Reply packets to the queries contain the status of the route being queried for.
The unreliable EIGRP packets are as follows:
• Hello—Hello packets are used to establish EIGRP neighbor relationships across a link.
• Acknowledgment—Acknowledgment packets ensure reliable delivery of EIGRP
packets.
All the EIGRP packets are sent through EIGRP multicast address 224.0.0.10. Every EIGRP-
enabled device automatically listens to the 224.0.0.10 address. Because this is a multicast
address and multiple devices receive the EIGRP packets at once, EIGRP needs its own
transport protocol to ensure reliable delivery of EIGRP packets. This protocol is the EIGRP
Reliable Transport Protocol (RTP). The router keeps a transmission list for every neighbor.
When a reliable EIGRP packet is sent to the neighbor, the sending router expects an acknowl-
edgment to be sent back from the neighbor indicating that the reliable EIGRP packet has been
received. EIGRP RTP maintains the transport window size of only one unacknowledged
packet. Therefore, every single reliable packet must be acknowledged before the next reliable
EIGRP packet can be sent out. The router retransmits the unacknowledged packet until an
acknowledgment is received. If no acknowledgment is received, EIGRP RTP retransmits the
same packet up to 16 times. If no acknowledgment is received after 16 retransmissions,
EIGRP resets the neighbor relationship.
In a multiaccess LAN network, sending a multicast update could pose a problem if the
transport window size is 1. As discussed previously, with reliable multicast traffic, the next
reliable multicast packet is not transmitted until all peers have acknowledged the previous
 EIGRP Packet Format 215

multicast packet. If one or more EIGRP neighbors in a multiaccess LAN network are slow
or fail to acknowledge the EIGRP packet, all the other neighbors will suffer from this.
For example, if there are three routers on an Ethernet segment and Router 1 sends a
multicast EIGRP update, it won’t send another multicast EIGRP packet on the Ethernet
until it receives an acknowledgment from the other two routers. Now assume that
Router 2 successfully sends an acknowledgment packet to Router 1, but Router 3 has a
problem sending the acknowledgment packet. Router 1 could potentially stop sending
any more EIGRP packets, and Router 2 would be affected even though the problem lies
on Router 3. EIGRP RTP avoids this problem by retransmitting the unacknowledged
EIGRP packet as a unicast packet to the neighbor that has not acknowledged the pre-
vious EIGRP packet, and it continues to send EIGRP multicast packets to the neigh-
bor that has already acknowledged the EIGRP packet. The router retransmits the
unacknowledged EIGRP packet as a unicast 16 times to a neighbor. If the neighbor still
has not acknowledged the EIGRP packet after 16 retries, EIGRP resets the neighbor
relationship and the whole process starts over. The 16-retry timeout period usually runs
from 50 to 80 seconds.

EIGRP Packet Format

Figure 6-4 shows the EIGRP packet header. Notice that following the autonomous systems
number are the Type/Length/Value (TLV) triplets. The TLV triplets carry route entries, as
well as provide the fields for DUAL process management. Some common TLVs are the
EIGRP parameter TLV, the IP internal route TLV, and the IP external route TLV.
Figure 6-4 EIGRP Packet Header

0 8 16 24 31
Version OPCode Checksum

Flags

Sequence

Acknowledgment

Autonomous System Number

TLVs
216 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

The EIGRP packet parameters are described as follows:

• Version—Specifies different versions of EIGRP. Version 2 of EIGRP was imple-
mented beginning with Cisco IOS Software Releases 10.3(11), 11.0(8), and 11.1(3).
EIGRP Version 2 is the most recent version that contains many enhancements to
improve the stability and scalability of EIGRP.
• Opcode—Specifies the types of EIGRP packet contained. Opcode 1 is the update
packet, opcode 3 is the Query, opcode 4 is the reply, and opcode 5 is the EIGRP hello
packet.
• Checksum—Used as the regular IP checksum, calculated based on the entire EIGRP
packet, excluding the IP header.
• Flags—Involves only two flags now. The flag indicates either an init for new neighbor
relationship or the conditional receive for EIGRP RTP.
• Sequence—Specifies the sequence number used by the EIGRP RTP.
• Acknowledgment—Used to acknowledge the receipt of an EIGRP reliable packet.
• Autonomous System Number—Specifies the number for the identification of
EIGRP network range.
One of the most common EIGRP TLVs is the EIGRP parameter TLV, as shown in Figure 6-5,
which contains the parameter needed to establish a neighbor relationship. The constant K
values are included in this TLV, as well as the hold time. The K values between two routers
must agree before they can establish a neighbor relationship.
Figure 6-5 EIGRP Parameters TLV

0 8 16 24 31
Type = 0x0001 Length

K1 K2 K3 K4

K5 Reserved Hold Time

Figure 6-6 and Figure 6-7 show two other common EIGRP TLVs—the IP internal route
TLV and the IP external route TLV, respectively. The EIGRP internal routes are routes
originated from the same EIGRP autonomous system number as the receiving router. The
EIGRP external routes are routes that are being redistributed into the EIGRP autonomous
systems.
The EIGRP IP internal route TLV contains this information:
• Next hop—IP address of the next hop to which packets should be forwarded.
• Delay—Delay parameter of the route metric. The delay value is the sum of all the
delay parameters on the interface across the path to the destination network.
 EIGRP Packet Format 217

Figure 6-6 EIGRP IP Internal Route TLV

0 8 16 24 31
Type = 0x0102 Length

Next Hop

Delay

Bandwidth

MTU Hop Count

Reliability Load Reserved

TLVs

Prefix Length Destination

• Bandwidth—Bandwidth parameter of the route metric. The bandwidth is obtained

from the interface, and it is the lowest bandwidth on the interface across the path to
the destination network.
• MTU—The interface MTU parameter of the route metric.
• Hop count—Number of hops to the destination network.
• Reliability—The reliability of the interface, out of a possible range of 1 to 255. A
reliability of 1 indicates that the reliability is 1/255, whereas a reliability of 255
indicates that the interface is 100 percent reliable.
• Load—The load of the interface, out of a possible range of 1 to 255. A load value of
1 indicates that the interface has a very light load, while a load value of 255 indicates
that the interface is highly saturated.
• Prefix length—The subnet mask of the destination network.
In EIGRP IP external route TLV, more information of the route is included:
• Originating router—The router ID of the router that originates the external EIGRP
routes.
• Originating autonomous system number—The EIGRP autonomous system number
of the routes before getting redistributed into this EIGRP autonomous number.
• External protocol metric—The metric of the routes before getting redistributed into
EIGRP.
• External protocol ID—The type of routing protocol that originates the routes that
were redistributed into EIGRP. The routing protocol type can be BGP, OSPF, RIP,
IGRP, and so forth.
218 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

Figure 6-7 EIGRP IP External Route TLV

0 8 16 24 31
Type = 0x0103 Length

Next Hop
Originating Router

Originating Autonomous System Number

Arbitrary Tag

External Protocol Metric

Reserved Ext Prot ID Flags

Delay

Bandwidth

MTU Hop Count

Reliability Load Reserved

Prefix Length Destination

EIGRP Behavior
Unlike IGRP, EIGRP is an advanced distance vector protocol that carries the subnet mask
information when an update is sent out. Therefore, EIGRP supports discontiguous network
and variable-length subnet masking (VLSM). For more explanation about discontiguous
networks and VLSM, refer to Chapter 2, “Understanding Routing Information Protocol
(RIP).” Figure 6-8 shows the network diagram that illustrates EIGRP’s support for
discontiguous networks.
Figure 6-8 Example of EIGRP Support for Discontiguous Networks

.1 10.1.1.0/24 .2

Router A Router B

192.168.8.1/25 192.168.8.129/25

Figure 6-8 shows two routers connected through a serial port. Router B has the network
192.168.8.128/25 that needs to advertise to Router A across the network 10.1.1.0/24. By
default, EIGRP is a classful routing protocol; Router B will autosummarize the route
 EIGRP Summarization 219

across the major network boundary. Therefore, Router B will advertise 192.168.8.0/24 to
Router A, which will ignore this route advertisement. To make EIGRP support discontig-
uous networks, you must configure the no auto-summary command under the command
router eigrp. With the no auto-summary command in place in Router B, Router B will
advertise the 192.168.8.128/25 route to Router A, and Router A will have a routing entry
for the route. The problem with discontiguous network then will be solved.

EIGRP Summarization
Two types of summarization take place in EIGRP—autosummarization and manual sum-
marization. Autosummarization is the default behavior for EIGRP, just as it is for RIP and
IGRP. Basically, when the router sends out a routing update, it automatically summarizes
the route to its natural major network when the route is advertised across a major network
boundary. Figure 6-9 shows an example of autosummarization. In Figure 6-9, Router R1
needs to send an update about the network 132.168.1.0 to R2 across a major network of
192.168.2.0. R1 then autosummarizes the update to its classful network of 132.168.0.0 and
sends it to R2. The problem of autosummarization is that the design of the network cannot
be discontiguous.
Figure 6-9 Example of Autosummarization

132.168.1.0 192.168.2.0

R1 R2
132.168.0.0

Manual summarization in EIGRP is configurable on a per-interface basis in any router

within the network. The command for EIGRP manual summarization is ip summary-
address eigrp autonomous-system-number address mask. With EIGRP, summarization
can be done on any interface and any router in the network, compared to OSPF, which can
summarize only on an area border router (ABR) and an autonomous system border router
(ASBR). When manual summarization is configured on the interface, the router will
immediately create a route to null 0 with an administrative distance of 5. This is to prevent
routing loops of summary address. Finally, when the last specific route of the summary goes
away, the summary route is deleted. Example 6-2 shows the configuration for EIGRP
manual summarization for the network in Figure 6-10.
Example 6-2 Configuring EIGRP Manual Summarization
interface s0
ip address 192.168.11.1 255.255.255.252
ip summary-address eigrp 1 192.168.8.0 255.255.252.0
220 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

Figure 6-10 EIGRP Manual Summarization Example

192.168.9.X AS 1
192.168.8.0/22

192.168.8.X
S0
R1
192.168.10.X

Example 6-2 demonstrates how R1 in Figure 6-10 is summarizing addresses of

192.168.8.0/24, 192.168.9.0/24, and 192.168.10.0/24 into one update of 192.168.8.0/22.
Summarization in EIGRP reduces the size of the routing table and the number of updates.
It also limits the query range, which is crucial in terms of making a large EIGRP network
more stable and more scalable.

EIGRP Query Process

Although EIGRP is an advanced distance vector routing protocol and convergence time is
low, an EIGRP router still relies on its neighbor to advertise routing information. To achieve
fast convergence, EIGRP can’t rely on a flush timer like IGRP. EIGRP needs to actively
search for the lost routes for fast convergence. This process is called the query process, and
it was briefly discussed in the previous few sections. In the query process, queries are sent
when the primary route is lost and no feasible successors are available. At this stage, the
route is said to be in the Active state.
Queries are sent out to all the neighbors and on all interfaces except for the interface to the
successor. If the neighboring routers do not have the lost route information, more queries
are sent to the neighboring routers’ neighbors until the query boundary is reached. Query
boundary consists of either the end of the network, the distribute list boundary, or the
summarization boundary. The distribute list and summarization boundaries are defined by
the router that has the distribute list or summarization configured. When the queries are
sent, the router must wait for all the replies from the neighbors before the router calculates
the successor information. If any neighbor fails to reply in three minutes, the route is said
to be stuck in active (SIA), and the neighbor relationship of the router that didn’t reply to
the query is reset. Chapter 7, “Troubleshooting EIGRP,” addresses the SIA problem and
tells how to troubleshoot it in greater detail.
 Unequal-Cost Load Balancing in EIGRP 221

Default Routes and EIGRP

Unlike IGRP, EIGRP recognizes the 0.0.0.0/0 route as the default route and allows it to be
redistributed into EIGRP domain as the default route. EIGRP also uses its own method of
propagating the default route with the ip default-network command, just as in IGRP.
The ip default-network command works exactly the same as it does in IGRP.
The ip default-network command specifies a major network address and flags it as a
default network. This major network could be directly connected, defined by a static route,
or discovered by a dynamic routing protocol. Figure 6-11 demonstrates how the ip default-
network command works.
Figure 6-11 Propagating a Default Route for IGRP

10.x.x.x

Remote site network

DS-3 link
Router 1 Router 2

In Figure 6-11, Router 1 is connected to the remote site through a DS-3 link. Router 1 now
wants to send a default route to Router 2 and to all the routers in the remote site network.
In IGRP, the route to 0.0.0.0 is not recognized as a default route; instead, Router 1 must
configure ip default-network 192.168.1.0 to flag the route 192.168.1.0 as the default route.
Router 1 will send out routing update of 192.168.1.0 and will flag it as a default route. When
the routers in the remote site network receive the update for 192.168.1.0, they will mark it
as default route and will install the route to 192.168.1.0 as the gateway of last resort.

Unequal-Cost Load Balancing in EIGRP

EIGRP and IGRP use the same equation to calculate their metrics, and they share the same
behavior when it comes to unequal-cost load balancing. EIGRP also can install up to six
parallel equal-cost paths for load balancing, like IGRP can, and EIGRP also uses the same
variance command as IGRP to do unequal-cost path load balancing.
222 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

Consider the network in Figure 6-12.

Figure 6-12 Unequal-Cost Load Balancing Example

S0 1544 kbps
S0 Router 3

S1 S1 Router 2
Router 1 256 kbps 133.33.0.0

Remember the rules for multipath operation:

• The neighboring router utilized as an alternate pathway must be closer to the
destination (that is, it must be advertising a smaller metric than that of the local
router for a given destination). It’s not possible to go back to go forward.
• The metric advertised by the neighbor must be less than the variance of the local
router’s metric. Variance = Variance Factor ⫻ Local Metric.
When Router 1 calculates its EIGRP metrics to Router 3, the metric going through the
1544 kbps link is as follows:

EIGRP metric = 256 ( 6476 + 2100 ) = 2,195,456

The metric going through the 256 kbps link is as follows:

EIGRP metric = 256 ( 39,062 + 2100 ) = 10,537,472

Without unequal-cost load balancing, EIGRP will simply select the 1544 kbps link to
forward packets to Router 3, as shown in the output in Example 6-3.
Example 6-3 show ip route Output Shows Router 1 Choosing a Suboptimal Route Without Unequal-Cost Load
Balancing
Router_1#show ip route 133.33.0.0
Routing entry for 133.33.0.0/16
Known via "eigrp 1", distance 90, metric 2195456
Redistributing via eigrp 1
Advertised by eigrp 1 (self originated)
Last update from 192.168.6.2 on Serial0, 00:00:20 ago
Routing Descriptor Blocks:
* 192.168.6.2, from 192.168.6.2, 00:00:20 ago, via Serial0
Route metric is2195456, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
 Summary 223

To use the unequal-cost load-balancing feature of EIGRP, you use the variance com-
mand. Variance is a multiplier in which a metric may be different from the lowest metric
to a route. The variance value must be of integer value; the default variance value is 1,
meaning that the metrics of multiple routes must be equal to load-balance.
In Example 6-3, the metric through the 256 kbps link is 4.8 times larger than the metric
through the 1544 kbps link. Therefore, for the 256 kbps link to be considered in the
routing table, a variance of 5 must be configured in Router 1. The configuration in
Router 1 is simply variance 5 under the router eigrp command. The output from the
show ip route command in Example 6-4 displays that Router 1 is installing both links
in its routing table.
Example 6-4 Example Output of Unequal-Cost Load Balancing in EIGRP
Router_1#show ip route 133.33.0.0
Routing entry for 133.33.0.0/16
Known via "eigrp 1", distance90, metric 2195456
Redistributing via eigrp 1
Advertised by eigrp 1 (self originated)
Last update from 10.1.1.2 on Serial1, 00:01:02 ago
Routing Descriptor Blocks:
* 192.168.6.2, from 192.168.6.2, 00:01:02 ago, via Serial0
Route metric is2195456, traffic share count is 5
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
10.1.1.2, from 10.1.1.2, 00:01:02 ago, via Serial1
Route metric is10537472, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 256Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

In Example 6-4, the route through Serial 0 has a traffic share count of 5, compared to a
traffic share count of 1 through Serial 1. This indicates that the router will send five packets
over Serial 0 for every packet sent over Serial 1.

Summary
EIGRP and IGRP are similar in some ways, but they differ in other ways. EIGRP and IGRP
use the same equation to calculate metrics to the destination network. EIGRP and IGRP also
use the same technique in doing unequal-cost load balancing. However, EIGRP keeps a topol-
ogy table of the network and uses the DUAL algorithm to select a loop-free path. EIGRP uses
the notions of successor and feasible successor and the query process to achieve fast conver-
gence. EIGRP also carries the subnet mask information when sending out routing update.
This enables EIGRP to support discontiguous networks and VLSM, which makes EIGRP a
scalable routing protocol capable of fitting today’s network requirements. Table 6-1 shows the
summary comparison between IGRP versus EIGRP.
224 Chapter 6: Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

Table 6-1 Comparison Table of IGRP Versus EIGRP

IGRP EIGRP

Metric calculated as follows: Metric calculated as follows:

IGRP Metric= IGRP Metric ⫻ 256
[K1 * BW + (K2 * BW) + K3 * Delay] * K5

(256 — Load) (Relia + K4)

Does not support VLSM and discontiguous networks Supports VLSM and discontiguous networks

Does not keep neighbor relationships Keeps neighbor relationships in a neighbor

table

Is vulnerable to routing loops Keeps a topology table of the network and

uses the DUAL algorithm to select a loop-
free path

Has slow convergence time Has fast convergence time because of

feasible successor and query process

Does not retransmit lost IGRP update packets Has a reliable transport mechanism to
retransmit lost EIGRP packets

Does not support manual summarization and classless route Supports manual summarization and
aggregation classless route aggregation

Does not understand 0.0.0.0/0 as default route Understands 0.0.0.0/0 as default route

Review Questions
1 What is the difference between metric calculations in IGRP versus EIGRP?
2 What is an EIGRP query, and what is it used for?

3 What is the meaning of the term active route?

4 What is a feasible successor?
5 What is EIGRP’s multicast address?

6 What is the feasible condition?

7 What is stuck in active?
This page intentionally left blank
This chapter covers the following EIGRP troubleshooting topics:
• Troubleshooting EIGRP neighbor relationships
• Troubleshooting EIGRP route advertisement
• Troubleshooting EIGRP route installation
• Troubleshooting EIGRP route flap
• Troubleshooting EIGRP route summarization
• Troubleshooting EIGRP route redistribution
• Troubleshooting EIGRP dial backup
• EIGRP error messages
 CHAPTER
7

Troubleshooting EIGRP
This chapter discusses some of the common problems in EIGRP and how to resolve those
problems. Debugs, configurations, and useful show commands are also given where
necessary.

NOTE Debugs can be CPU-intensive and can adversely affect your network. Therefore, debugs are
not recommended on a production network unless being instructed by Cisco’s Technical
Assistance Center (TAC).

Sometimes, there might be multiple causes for the same problem. Therefore, if one scenario
doesn’t fix the network problem, always check into other scenarios.

Troubleshooting EIGRP Neighbor Relationships

This section discusses methods of troubleshooting issues regarding EIGRP neighbor
relationships. The following are the most common causes of problems with EIGRP
neighbor relationships:
• Unidirectional link
• Uncommon subnet, primary, and secondary address mismatch
• Mismatched masks
• K value mismatches
• Mismatched AS numbers
• Stuck in active
• Layer 2 problem
• Access list denying multicast packets
• Manual change (summary router, metric change, route filter)
228 Chapter 7: Troubleshooting EIGRP

Figure 7-1 illustrates a general troubleshooting flowchart on EIGRP neighbor relationships.

Figure 7-1 General Flowchart on Troubleshooting EIGRP Neighbor Relationships

EIGRP neighbor relationship problem.

Possible causes:
-Layer 2 problem
-Unidirectional link
Perform show ip eigrp -Access list
neighbor. Is the neighbor up? No -Uncommon subnet
-K value mismatch
-AS number mismatch
Refer to the appropriate
Yes book section for further
explanation.

Is the neighbor resetting No Go to other side of

after a while? neighbor. Repeat first
step.
Yes

Look at the log. Note the reason for the neighbor reset.
Refer to book section for explanation of the reason.

Consulting the EIGRP Log for Neighbor Changes

Whenever EIGRP resets its neighbor relationship, it is noted in the log with the reason for
the reset. In the earlier Cisco IOS Software releases, configuration to enable this feature is
required. The command eigrp log-neighbor-change is configured under router EIGRP. In
Cisco IOS Software Release 12.1.3 and later, the eigrp log-neighbor-change command
becomes the default setting for the router. An example of the EIGRP neighbor log looks
something like this:
%DUAL-5-NBRCHANGE: IP-EIGRP EIGRP AS number: Neighbor neighbor IP address is down:
reason for neighbor down.

Table 7-1 documents the neighbor changes that you can find in the EIGRP log, along with
the meaning and required action to fix the problem based on the log message.
 Troubleshooting EIGRP Neighbor Relationships 229

Table 7-1 Neighbor Changes Documented in the EIGRP Log

Log Message Meaning Action for Troubleshooting
NEW Indicates that a new neighbor has No action is required.
ADJACENCY been established.
PEER Indicates that the other neighbor No action is required on the router
RESTARTED initiates the reset of the neighbor that is getting the message. Gather
relationship. The router getting the EIGRP neighbor log information on
message is not the one resetting the the other neighbor.
neighbor.
HOLD TIME Indicates that the router has not Because this is a packet-loss problem,
EXPIRED heard any EIGRP packets from the check for a Layer 2 problem. Trouble-
neighbor within the hold-time limit. shoot by using the flowchart shown in
Figure 7-2.
RETRY LIMIT Indicates that EIGRP did not receive Troubleshoot using the flowchart
EXCEEDED the acknowledgement from the shown in Figure 7-3.
neighbor for EIGRP reliable packets
and that EIGRP already has tried to
retransmit the reliable packet 16
times without any success.
ROUTE Indicates that the EIGRP neighbor is No action is needed. This is normal
FILTER resetting because there is a change in behavior in EIGRP, which needs to
CHANGED the route filter (distribute-list reset the neighbor when the route filter
command under router EIGRP). is changed, and to resynchronize the
EIGRP topology table between
neighbors.
INTERFACE Indicates that the EIGRP neighbor is No action is needed. This is normal
DELAY resetting because there is a manual behavior in EIGRP, which needs to
CHANGED configuration change in the delay reset the neighbor when the delay
parameter on the interface. parameter is changed.
INTERFACE Indicates that the EIGRP neighbor is No action is needed. This is normal
BANDWIDTH resetting because there is a manual behavior in EIGRP, which needs to
CHANGED configuration change in the interface reset the neighbor when the band-
bandwidth on the interface. width parameter is changed.
STUCK IN Indicates that the EIGRP neighbor is Troubleshoot from the stuck in active
ACTIVE resetting because EIGRP is stuck in point of view. Refer to the section
active state. The neighbor getting “EIGRP Neighbor Problem—Cause:
reset is the result of stuck in active. Stuck in Active.”
230 Chapter 7: Troubleshooting EIGRP

Figure 7-2 Flowchart for Troubleshooting EIGRP Neighbor Relationship When Getting Neighbor Log Message
HOLD TIME EXPIRED

Getting EIGRP neighbor log “Hold Time

Expired.”

Yes

Perform “Debug EIGRP Check EIGRP configuration. Make

Packet Hello.” Is the router sending or No sure that passive-interface or
receiving hello packet? access list is not configured.

Yes
High CPU utilization on router
Check incorrect interface access list
or
Ping interface with small Layer 1, Layer 2 problem:
(100 byte) packets and then with large -Check switch between the link.
No -Check interface errors.
(1400-1500 byte) packet. Success?
-Check with WAN connection
provider.
-Bad Interface, change
hardware.
Yes

Ping to address 224.0.0.10

from neighbor. Response? No

Yes

Repeat troubleshooting steps from neighbor router.

or
Cause could be because of network congestion.
Increase the neighbor hold time and monitor.

EIGRP Neighbor Problem—Cause: Unidirectional Link

Sometimes, a problem with a WAN connection causes EIGRP to have a one-way neighbor
relationship. A one-way neighbor relationship usually is caused by a unidirectional
connection between the neighbors. The cause for unidirectional connection is usually a
Layer 2 problem. For example, a link might be experiencing many CRC errors, a switch
problem, or a ping test failure with large or small packets. In this case, you need a call to
the group that is responsible for the link to check the integrity of the link. Sometimes, a
simple misconfigured access list causes EIGRP to form a one-way neighbor relationship.
Figure 7-4 illustrates an example of an EIGRP problem as a result of a unidirectional link.
 Troubleshooting EIGRP Neighbor Relationships 231

Figure 7-3 Flowchart for Troubleshooting EIGRP Neighbor Relationship When Getting Neighbor Log RETRY
LIMIT EXCEEDED

Getting EIGRP neighbor log “Retry Limit

Exceeded.”
Yes

High CPU utilization on router.

Check incorrect interface access list
or
Ping neighbor interface with small Layer 1, Layer 2 problem:
(100 byte) packets and then with large No -Check switch between the link.
-Check interface errors.
(1400-1500 byte) packet. Success? -Check with WAN connection
provider.
-Bad Interface, change
hardware.

Yes

Routing problem. The next hop IP

Check routing table entry address of the EIGRP neighbor does
for neighbor interface IP not correspond to the actual physical
address. Neighbor IP address No
connection. Check for miscon-
with correct next hop address in figuration on the router. Troubleshoot
routing table? from a routing perspective.

Yes

Repeat test from neighbor router.

Figure 7-4 Network Topology Vulnerable to an EIGRP Neighbor Problem Because of a Unidirectional Link

WAN Cloud
RTR A RTR B
X

In Figure 7-4, Routers RTR A and RTR B are connected by a WAN connection. The circuit
from RTR A to RTR B is fine, but the circuit from RTR B to RTR A is broken. The results from
the show ip eigrp neighbor command on RTR A will not show anything because RTR B’s
EIGRP hello packet can’t make it to RTR A. Example 7-1 shows the output from show ip eigrp
neighbor on RTR B.
232 Chapter 7: Troubleshooting EIGRP

Example 7-1 show ip eigrp neighbors Command Output on RTR B

RtrB#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.88.18.2 S0 14 00:00:15 0 5000 4 0

RTR B shows RTR A as a neighbor because RTR A’s EIGRP hello packet has no problem
reaching RTR B. From the output of the show command, the SRTT is at 0 ms, the
retransmission timeout (RTO) timer is at 5000 ms, and the Q count is at 4 and is not
decrementing. These three numbers give the biggest clue that this is a unidirectional link
problem. The following is the meaning of SRTT, RTO, and Q count:
• Smooth round-trip time (SRTT)—The number of milliseconds it takes for an
EIGRP packet to be sent to this neighbor and for the local router to receive an
acknowledgment of that packet
• Retransmission timeout (RTO), in milliseconds—The amount of time that the
software waits before retransmitting a packet from the retransmission queue to a
neighbor
• Q count—The number of EIGRP packets (Update, Query, and Reply) that the
software is waiting to send
Referring to Example 7-1, the fact that the SRTT timer is 0 indicates that no acknowledge-
ment packets are being received. The Q count is not decrementing, which indicates that the
router is trying to send EIGRP packets but no acknowledgement is being received. RTR B will
retry 16 times to resend the packet; eventually, RTR B will reset the neighbor relationship
with the log indicating RETRY LIMIT EXCEEDED, and the process starts again. Also, keep
in mind that the 16 times retransmission of the same packet is done using unicast, not
multicast. Therefore, the RETRY LIMIT EXCEEDED message indicates a problem with
transmitting unicast packets over the link, and this is most likely a Layer 1 or Layer 2 problem.
The solution to this problem is to troubleshoot from a Layer 2 perspective. In this example,
a call to the WAN provider is needed to find out why the circuit from RTR B to RTR A is
broken. After the link between RTR B to RTR A is fixed, the problem will be resolved.
Output from show ip eigrp neighbors in Example 7-2 shows that the neighbor relationship
after the WAN link has been fixed.
Example 7-2 show ip eigrp neighbors Command Output Confirms Problem Resolution
RtrB#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.88.18.2 S0 14 01:26:30 149 894 0 291

Notice that the Q count column is 0 and that the SRTT and RTO have valid values now.
 Troubleshooting EIGRP Neighbor Relationships 233

EIGRP Neighbor Problem—Cause: Uncommon Subnet

Many times, EIGRP won’t establish neighbor relationships because the neighbors are not
in the same subnet. Usually, the cause of this problem is router misconfiguration. When
EIGRP has problems establishing neighbor relationships because of an uncommon subnet,
the following error message appears:
IP-EIGRP: Neighbor ip address not on common subnet for interface

Figure 7-5 shows the flowchart for troubleshooting the problem when the “Neighbor not on
common subnet” error appears on the router.

Figure 7-5 Problem-Resolution Flowchart

Getting EIGRP error “EIGRP

neighbor not on common
subnet.”

Double-check interface
configuration. Misconfigured IP Correct the IP address
Yes
address on interface on local configuration on interface.
and neighboring router?

No

Change IP address of interface so the

Is primary address of interface in the primary address of the neighboring
same subnet as the primary address No
router is in the same subnet as the
of neighboring router? local router.

Yes

LAN hub will pass broadcast and multicast packets

to other ports between logical segments. Break up
Connection between EIGRP broadcast domain by using separate hub for each
neighbor done through a LAN hub? Yes
logical LAN segment or configure “no EIGRP log-
neighbor-warnings” to stop seeing error message.

No

If connection between EIGRP neighbor is

made on switch, make sure that the switch
configuration is correct. Make sure two
different LAN segments are not configured to
be in the same VLAN sharing the same
broadcast domain.
234 Chapter 7: Troubleshooting EIGRP

According to the troubleshooting flowchart in Figure 7-5, the three causes of getting the
“EIGRP neighbor not on common subnet” error message are the following:
• The IP address has been misconfigured on interfaces.
• The primary and secondary IP addresses of the neighboring interface don’t match.
• A switch or hub between the EIGRP neighbor connection is misconfigured or is
leaking multicast packet to other ports.

Misconfiguration of the IP Address on the Interfaces

Sometimes, an EIGRP neighbor that is not on a common subnet with other EIGRP neigh-
bors is simply the result of misconfiguring the IP address on the interfaces. For example,
the network administrator might mistype IP address 192.168.3.1 255.255.255.252 as
192.168.3.11 255.255.255.252, which causes EIGRP to complain about the neighbor not
being on a common subnet.

Primary and Secondary IP Addresses of the Neighboring Interface Don’t Match

As mentioned in Chapter 6, “Understanding Enhanced Interior Gateway Routing Protocol
(EIGRP),” EIGRP sources the hello packet from the primary address of the interface. If the
primary network address on one router is used as a secondary network address on the
second router, and vice versa, no neighbor relationship will be formed and the routers will
complain about the neighbor not being on a common subnet. Figure 7-6 illustrates such a
scenario.

Figure 7-6 Network Topology Vulnerable to EIGRP Neighbor Problems Because of Primary and Secondary
IP Address Mismatch

Router A Router B
Primary: 10.1.1.1/24
Primary: 10.1.1.2/24
Secondary: 50.1.1.1/24 Secondary: 50.1.1.2/24

Only Address - 50.1.1.3/24

Router C
 Troubleshooting EIGRP Neighbor Relationships 235

In Figure 7-6, Router A and Router B have a primary address in the 10.1.1.0/24 network
range, while Router C has an address range of 50.1.1.0/24 configured. When Router A or
Router B sends out the EIGRP hello packet, the source of the hello packet will be either
10.1.1.1 or 10.1.1.2, depending on which router sends out the hello. When Router C
receives the hello packet from Router A or Router B, it notices that the source is from the
10.1.1.0 network. Because Router C has an IP address of 50.1.1.3 configured on the
interface, Router C will not process the hello packet from Router A or Router B because
they are from a different network. Therefore, no neighbor relationship is formed from
Router C to either Router A or Router B.
The solution for this example is to match all the IP addresses on the segment to the
primary address space. For the network in Figure 7-6, you need to configure Router C to
be in the primary address space of 10.1.1.0/24.

Switch or Hub Between EIGRP Neighbor Connection Is Misconfigured or Is Leaking

Multicast Packets to Other Ports
If the IP address configuration is correct on the interface between EIGRP neighbors, you
might want to check the configuration on the switch or the hub that connects the EIGRP
neighbors. If a single LAN hub connects the EIGRP neighbors for different LAN segment,
the hub passes broadcast and multicast packets to other ports between two logical LAN seg-
ments. So, the multicast EIGRP hello from LAN segment 1 will be seen on the neighbor
located in LAN segment 2 if a single hub connects all the LAN devices on different LAN
segments. The solution is to break up the broadcast domain by using a separate hub for each
LAN segment or simply configuring no eigrp log-neighbor-warnings under EIGRP con-
figuration to stop seeing the error message.
If a LAN switch connects the LAN devices, you might want to check the configuration of
the switch. Make sure that the switch is not configured so that different LAN segments
reside within the same VLAN. Make sure that the switch is configured so that each LAN
segment has its own broadcast domain and does not share its broadcast domain with other
LAN segments.

EIGRP Neighbor Problem—Cause: Mismatched Masks

Sometimes, a simple misconfiguration on the interface subnet mask causes an EIGRP
neighbor problem. Figure 7-7 illustrates a network diagram for such a scenario.
236 Chapter 7: Troubleshooting EIGRP

Figure 7-7 Network Topology Vulnerable to EIGRP Neighbor Problems Because of Mismatched Masks

Router A
10.1.1.2/25 10.1.3.1/24

10.1.1.1/24 10.1.3.2/24

Router B Router C
10.1.2.1/24 10.1.2.2/24

Example 7-3 shows the configuration for Routers A, B, and C.

Example 7-3 Router A, B, and C Configurations for the Network in Figure 7-7
Router A#interface serial 0
ip address 10.1.1.2 255.255.255.128
interface serial 1
ip address 10.1.3.1 255.255.255.0

Router B#interface serial 0

ip address 10.1.1.1 255.255.255.0
interface ethernet 0
ip address 10.1.2.1 255.255.255.0

Router C#interface ethernet 0

ip address 10.1.2.2 255.255.255.0
interface serial 0
ip address 10.1.3.2 255.255.255.0

Notice the mismatched mask on the serial interface of Router A and Router B. Router A has
a mask of 255.255.255.128, while Router B has a mask of 255.255.255.0 on Serial 0.
Initially, EIGRP has no problem forming the neighbor between Router A and Router B
because 10.1.1.1 and 10.1.1.2 are in the same subnet. The problem occurs when a neighbor
relationship is established and Router A and Router B begin to exchange EIGRP topology
tables and install routes based on the EIGRP topology table, as demonstrated in Example 7-4.
 Troubleshooting EIGRP Neighbor Relationships 237

Example 7-4 Routing Tables from Router B and Router C

Router B#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

C 10.1.1.0/24 Serial 0
D 10.1.1.0/25 10.1.2.2

Router c#show ip route eigrp

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

D 10.1.1.0/24 10.1.2.1
D 10.1.1.0/25 10.1.3.1

When Router B sends Router A an EIGRP update, Router A responds to the update with an
EIGRP acknowledgement packet with a destination address of 10.1.1.1 to Router B. When
Router B receives the packet, it forwards the ACK packet to Router C instead of processing
it because Router B has a more specific route from Router C. Router B has a more specific
route of 10.1.1.0/25 with the next hop to 10.1.2.2. This /25 route overrides the /24 route
because /25 is more specific than /24. When Router C receives the ACK packet from Router
B, it looks at its routing table for the 10.1.1.1 entry, and the routing table points to Router
A. Router C then forwards the ACK