Вы находитесь на странице: 1из 158

Routing TCP/IP, Volume II

CCIE Professional Development, Second Edition

Jeff Doyle

Cisco Press
800 East 96th Street

Indianapolis, IN 46240
ii Routing TCP/IP, Volume II

Routing TCP/IP, Volume II


CCIE Professional Development, Second Edition
Jeff Doyle

Copyright 2017 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 stor-
age and retrieval system, without written permission from the publisher, except for the inclusion of
brief quotations in a review.

Printed in the United States of America

First Printing August 2016

Library of Congress Control Number: 2016936742

ISBN-13: 978-1-58705-470-9
ISBN-10: 1-58705-470-1

Warning and Disclaimer


This book is designed to provide information about routing TCP/IP. 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 dam-
ages arising from the information contained in this book or from the use of the discs or programs
that may accompany it.

The opinions expressed in this book belong to the author and are not necessarily those of Cisco
Systems, Inc.

Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been
appropriately capitalized. Cisco Press or Cisco Systems, Inc., cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the validity of any
trademark or service mark.

Special Sales
For information about buying this title in bulk quantities, or for special sales opportunities (which
may include electronic versions; custom cover designs; and content particular to your business,
training goals, marketing focus, or branding interests), please contact our corporate sales depart-
ment at corpsales@pearsoned.com or (800) 382-3419.

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

For questions about sales outside the U.S., please contact intlcs@pearson.com.
iii

Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each
book is crafted with care and precision, undergoing rigorous development that involves the unique
expertise of members from the professional technical community.

Readers feedback is a natural continuation of this process. If you have any comments regarding
how we could improve the quality of this book, or otherwise alter it to better suit your needs, you
can contact us through email at feedback@ciscopress.com. Please make sure to include the book
title and ISBN in your message.

We greatly appreciate your assistance.


Editor-in-Chief: Mark Taub
Product Line Manager: Brett Bartow
Alliances Manager, Cisco Press: Ron Fligge
Managing Editor: Sandra Schroeder
Development Editor: Christopher Cleveland
Project Editor: Deadline Driven Publishing
Copy Editor: Deadline Driven Publishing
Technical Editors: Darien Hirotsu, Pete Moyer
Editorial Assistant: Vanessa Evans
Cover Designer: Chuti Prasertsith
Composition: Patricia Ratcliff
Indexer: Angie Martin
Proofreader: Deadline Driven Publishing
iv Routing TCP/IP, Volume II

About the Author


Jeff Doyle, CCIE No. 1919, is vice president of research at Fishtech Labs. Specializing
in IP routing protocols, SDN/NFV, data center fabrics, MPLS, and IPv6, Jeff has
designed or assisted in the design of large-scale IP service provider and enterprise net-
works in 26 countries over 6 continents. He worked with early IPv6 adopters in Japan,
China, and South Korea, and has advised service providers, government agencies, mili-
tary contractors, equipment manufacturers, and large enterprises on best-practice IPv6
deployment. He now advises large enterprises on evolving data center infrastructures,
SDN, and SD-WAN.

Jeff is the author of CCIE Professional Development: Routing TCP/IP, Volumes I and
II and OSPF and IS-IS: Choosing an IGP for Large-Scale Networks; a co-author of
Software Defined Networking: Anatomy of OpenFlow; and an editor and contribut-
ing author of Juniper Networks Routers: The Complete Reference. He also writes for
Forbes and blogs for both Network World and Network Computing. Jeff is one of the
founders of the Rocky Mountain IPv6 Task Force, is an IPv6 Forum Fellow, and serves
on the executive board of the Colorado chapter of the Internet Society (ISOC).

Jeff lives in Westminster, Colorado, with his wife Sara and a Sheltie named Max, the
Forrest Gump of the dog world. Jeff and Sara count themselves especially fortunate that
their four grown children and a growing herd of grandchildren all live within a few miles.

About the Contributing Authors


Khaled W. Abuelenain, CCIE No. 27401, is currently the consulting director for
Acuative, a Cisco Certified Managed Services Master Partner, at the companys EMEA
office in Saudi Arabia. He is a certified double CCIE (R&S, SP), holds a B.Sc. degree in
electronics and communication engineering from Ain Shams University, Egypt, and is
an IEEE member since 1997. Khaled has been designing, operating, or optimizing large-
scale networks for more than 14 years throughout the Middle East, typically for service
providers and mobile operators with multinational presence, banks, and government
agencies. He has extensive experience in routing, BGP, MPLS, and IPv6. Khaled is also an
expert on data center technologies and network programmability, with a special interest
in Python programming for SDN solutions. He is an active member of both the Cloud
Computing and SDN IEEE societies.

Nicolas Michel, dual CCIE No. 29410 R/S and DC, is a network architect with 10 years
of experience in several fields: routing switching, data center, and unified communica-
tions. Nicolas is a former Sergeant in the French Air Force and started to work as a net-
work engineer during the time he was serving. He has worked on several NATO-related
projects.

He decided to move to Switzerland in 2011, to work for the local leading networking
consulting company.

He was the principal UC architect for the UEFA EURO 2016 football tournament.
v

Nicolas is also an eager reader about emerging network technologies (SDN, Automation/
Network programmability). He blogs at http://vpackets.net and is also a president for a
nongovernmental organization that helps children with autism.

He participates in an open source network simulation project: http://www.unetlab.com/.

Nicolas is actually trying to relocate to the United States.

From Nicolas: I would like to dedicate the work I have done on this book to my won-
derful wife who has supported me throughout my career and helps me become a better
engineer and a better man. I wouldnt be the same man without her.

Also I would like to dedicate this work to my kids and my parents, who taught me to
never give up and to enjoy every moment.

Finally, I would express my heartfelt thanks to Jeff Doyle for giving me the opportunity
to work on this project. I learned so many things and I still cant believe how lucky I was.

About the Technical Reviewers


Darien Hirotsu is a networking professional who has been in the industry for nearly a
decade working on service provider, data center, and enterprise networks. He earned a
masters degree in network engineering from UC Santa Cruz and a bachelors degree in
electrical engineering from Cal Poly San Luis Obispo. He also holds multiple expert level
certifications, and is equally passionate about both the software and networking parts
of SDN.

Darien would like to send extra special thanks to his fianc Rebecca Nguyen. Editing this
book was both rewarding and time consuming. During the whole process and through
the long weekends, Rebeccas love, support, and patience never wavered, and for that, he
will always be grateful. Thank you for everything you do, Rebecca!

Pete Moyer is an old-timer IP/MPLS consulting engineer who has turned his focus
toward SDN in recent years. He has multivendor experience in IP networking, having
earned the first awarded JNCIE in the early 2000s and his CCIE in the late 1990s. He
is a co-author and technical editor of several networking books on IP and SDN and
has authored many articles and blogs on various networking topics. His current focus
is on large-scale data center and service provider networks, including the Research
& Education Network (REN) market. He also holds a B.S. degree in CMIS from the
University of Maryland.
vi Routing TCP/IP, Volume II

Dedications
This book is dedicated to my wife Sara; my children, Anna, Carol, James, and
Katherine; and my grandchildren, Claire, Caroline, and Sam. They are my refuge, and
they keep me sane, humble, and happy.
vii

Acknowledgments
An author of a technical book is just a front for a small army of brilliant, dedicated
people. This book is no exception. At the risk of sounding like Im making an Academy
Award acceptance speech, I would like to thank a number of those people.

I would like to thank Khaled Abu El Enian and Nicolas Michel, who contributed many
new end-of-chapter configuration and troubleshooting exercises. Khaled also helped me
out in a time crunch and wrote most sections in Scaling BGP Functions in Chapter 5,
Scaling BGP. I hope we can collaborate even closer on a future book or two.

I would also like to thank Pete Moyer, my longtime friend and associate, who has been a
technical reviewer for every book Ive written alone and has been a co-author on several
other books. Pete has had a profound influence on my life beyond this and other book
projects, and I will always be indebted to him.

Darien Hirotsu is the other technical reviewer on this book, and its the first time we
have worked together on a book project, although we have been associates across mul-
tiple companies and engineering projects. Darien is astoundingly detail-oriented and
caught countless tiny errors throughout my manuscript.

My gratitude goes to Chris Cleveland for his expert guidance as development editor.
We have collaborated on multiple books, and he has made each one a better book and
me a better writer.

Thanks to Brett Bartow and all the folks at Cisco Press. Brett has shown superhuman
patience with me as the book schedule constantly fell victim to day job priorities. He
has continued to show me great kindness throughout the project when Im sure he would
have preferred to bash me on the head with a copy of Volume I.

I would like to thank my wife Sara, who has lived with me juggling multiple writing proj-
ects over many years. She long ago learned what it means when she notices me staring
blankly at nothing, and says, Youre writing in your head again, arent you?

Finally, I would like to thank you, good reader, for making the two volumes of Routing
TCP/IP such a success and for waiting so patiently for me to finish this new edition. I
hope the book proves to be worth your wait.
viii Routing TCP/IP, Volume II

Contents at a Glance
Introduction xxi

Chapter 1 Inter-Domain Routing Concepts 1

Chapter 2 Introduction to BGP 71

Chapter 3 BGP and NLRI 155

Chapter 4 BGP and Routing Policies 237

Chapter 5 Scaling BGP 401

Chapter 6 Multiprotocol BGP 615

Chapter 7 Introduction to IP Multicast Routing 713

Chapter 8 Protocol Independent Multicast 771

Chapter 9 Scaling IP Multicast Routing 881

Chapter 10 IPv4 to IPv4 Network Address Translation (NAT44) 931

Chapter 11 IPv6 to IPv4 Network Address Translation (NAT64) 995

Appendix A Answers to Review Questions 1047

Index 1079

Appendix B (online) Answers to Configuration Exercises

Appendix C (online) Answers to Troubleshooting Exercises


ix

Contents
Introduction xxi

Chapter 1 Inter-Domain Routing Concepts 1


Early Inter-Domain Routing: The Exterior Gateway Protocol (EGP) 1
Origins of EGP 2
Operation of EGP 3
EGP Topology Issues 3
EGP Functions 5
Neighbor Acquisition Protocol 6
Neighbor Reachability Protocol 8
Network Reachability Protocol 10
Shortcomings of EGP 15
The Advent of BGP 16
BGP Basics 17
Autonomous System Types 21
External and Internal BGP 22
Multihoming 29
Transit AS Multihoming 30
Stub AS Multihoming 31
Multihoming and Routing Policies 36
Multihoming Issues: Load Sharing and Load Balancing 36
Multihoming Issues: Traffic Control 37
Multihoming Issues: Provider-Assigned Addressing 40
Classless Inter-Domain Routing 41
A Summarization Summary 41
Classless Routing 43
Summarization: The Good, the Bad, and the Asymmetric 47
CIDR: Reducing Class B Address Space Depletion 50
CIDR: Reducing Routing Table Explosion 50
Managing and Assigning IPv4 Address Blocks 54
CIDR Issues: Multihoming and Provider-Assigned Addresses 56
CIDR Issues: Address Portability 58
CIDR Issues: Provider-Independent Addresses 59
CIDR Issues: Traffic Engineering 60
CIDR Approaches Its Limits 62
x Routing TCP/IP, Volume II

IPv6 Comes of Age 66


Routing Table Explosion, Again 66
Looking Ahead 68
Review Questions 69

Chapter 2 Introduction to BGP 71


Who Needs BGP? 71
Connecting to Untrusted Domains 71
Connecting to Multiple External Neighbors 74
Setting Routing Policy 79
BGP Hazards 82
Operation of BGP 84
BGP Message Types 85
Open Message 85
Keepalive Message 86
Update Message 86
Notification Message 87
BGP Finite State Machine 87
Idle State 88
Connect State 89
Active State 89
OpenSent State 89
OpenConfirm State 90
Established State 90
Path Attributes 90
ORIGIN Attribute 92
AS_PATH Attribute 92
NEXT_HOP Attribute 97
Weight 100
BGP Decision Process 100
BGP Message Formats 103
Open Message 104
Update Message 105
Keepalive Message 108
Notification Message 108
xi

Configuring and Troubleshooting BGP Peering 110


Case Study: EBGP Peering 110
Case Study: EBGP Peering over IPv6 114
Case Study: IBGP Peering 118
Case Study: Connected Check and EBGP Multihop 127
Case Study: Managing and Securing BGP Connections 136
Looking Ahead 142
Review Questions 143
Configuration Exercises 144
Troubleshooting Exercises 145

Chapter 3 BGP and NLRI 155


Configuring and Troubleshooting NLRI in BGP 155
Injecting Prefixes with the network Statement 156
Using the network mask Statement 160
Injecting Prefixes with Redistribution 162
NLRI and IBGP 167
Managing Prefixes in an IBGP Topology 168
IBGP and IGP Synchronization 179
Advertising BGP NLRI into the Local AS 182
Redistributing BGP NLRI into the IGP 182
Case Study: Distributing NLRI in a Stub AS with IBGP 184
Distributing NLRI in a Stub AS with Static Routes 193
Advertising a Default Route to a Neighboring AS 196
Advertising Aggregate Routes with BGP 198
Case Study: Aggregation Using Static Routes 199
Aggregation Using the aggregate-address Statement 201
ATOMIC_AGGREGATE and AGGREGATOR Attributes 207
Using AS_SET with Aggregates 210
Looking Ahead 218
Review Questions 218
Configuration Exercises 219
Troubleshooting Exercises 223

Chapter 4 BGP and Routing Policies 237


Policy and the BGP Database 238
IOS BGP Implementation 249
InQ and OutQ 249
xii Routing TCP/IP, Volume II

IOS BGP Processes 251


NHT, Event, and the Open Processes 256
Table Versions 258
Managing Policy Changes 267
Clearing BGP Sessions 268
Soft Reconfiguraton 269
Route Refresh 274
Route Filtering Techniques 279
Filtering Routes by NLRI 280
Case Study: Using Distribute Lists 280
Route Filtering with Extended ACLs 292
Case Study: Using Prefix Lists 293
Filtering Routes by AS_PATH 304
Regular Expressions 304
Literals and Metacharacters 305
Delineation: Matching the Start and End of Lines 306
Bracketing: Matching a Set of Characters 306
Negating: Matching Everything Except a Set of Characters 306
Wildcard: Matching Any Single Character 307
Alternation: Matching One of a Set of Characters 307
Optional Characters: Matching a Character That May or
May Not Be There 307
Repetition: Matching a Number of Repeating Characters 307
Boundaries: Delineating Literals 308
Putting It All Together: A Complex Example 308
Case Study: Using AS-Path Filters 309
Case Study: Setting Policy with Route Maps 314
Filter Processing 322
Influencing the BGP Decision Process 323
Case Study: Administrative Weights 325
Case Study: Using the LOCAL_PREF Attribute 334
Case Study: Using the MULTI_EXIT_DISC Attribute 343
Case Study: Prepending the AS_PATH 366
Case Study: Administrative Distances and Backdoor Routes 372
Controlling Complex Route Maps 379
Continue Clauses 380
Policy Lists 383
xiii

Looking Ahead 386


Review Questions 386
Configuration Exercises 388
Troubleshooting Exercises 392

Chapter 5 Scaling BGP 401


Scaling the Configuration 402
Peer Groups 403
Peer Templates 413
Session Templates 414
Policy Templates 419
Communities 425
Well-Known Communities 426
Arbitrary Communities 434
Using the AA:NN Format 443
Expanded Community Lists 445
Adding and Deleting Communities 460
Extended Community Lists 472
Scaling BGP Functions 478
Route Flap Dampening 479
Outbound Route Filters (ORF) 486
Next-Hop Tracking 496
Fast External Fallover 509
Bidirectional Forwarding Detection (BFD) 512
BGP Prefix Independent Convergence (PIC) 523
ADD-PATHS Capability 528
Graceful Restart 538
Maximum Prefixes 540
Tuning BGP CPU 552
Tuning BGP Memory 556
BGP Transport Optimization 563
Optimizing TCP 563
Optimizing BGP Update Generation 568
Optimizing TCP ACK Message Receipt 568
Scaling the BGP Network 569
Private AS Numbers 569
4-Byte AS Numbers 574
xiv Routing TCP/IP, Volume II

IBGP and the N-Squared Problem 575


Confederations 576
Route Reflectors 592
Looking Ahead 606
Review Questions 607
Configuration Exercises 608
Troubleshooting Exercises 612

Chapter 6 Multiprotocol BGP 615


Multiprotocol Extensions to BGP 616
MBGP Support for the IPv6 Address Family 618
Configuring MBGP for IPv6 619
IPv4 and IPv6 Prefixes over an IPv4 TCP Session 620
Upgrading IPv4 BGP Configurations to the Address Family Format 629
IPv4 and IPv6 over an IPv6 TCP Connection 631
Dual Stack MBGP Connection 642
Multihop Dual Stack MBGP Connection 647
Mixed IPv4 and IPv6 Sessions 650
Multiprotocol IBGP 654
Case Study: Multiprotocol Policy Configuration 666
Looking Ahead 705
Review Questions 705
Configuration Exercises 706
Question 1: 707
Troubleshooting Exercises 709

Chapter 7 Introduction to IP Multicast Routing 713


Requirements for IP Multicast 716
IPv4 Multicast Addresses 717
IPv6 Multicast Addresses 721
Group Membership Concepts 724
Joining and Leaving a Group 726
Join Latency 726
Leave Latency 727
Group Maintenance 728
Multiple Routers on a Network 728
xv

Internet Group Management Protocol (IGMP) 729


IGMPv2 Host Functions 730
IGMPv2 Router Functions 731
IGMPv1 733
IGMPv3 735
IGMP Message Format 736
Multicast Listener Discovery (MLD) 742
IGMP/MLD Snooping 745
Cisco Group Management Protocol (CGMP) 749
Multicast Routing Issues 753
Multicast Forwarding 754
Multicast Routing 756
Sparse Versus Dense Topologies 757
Implicit Joins Versus Explicit Joins 758
Source-Based Trees Versus Shared Trees 760
Source-Specific Multicast (SSM) 761
Multicast Scoping 763
TTL Scoping 763
Administrative Scoping 765
Looking Ahead 766
Recommended Reading 766
Review Questions 766
Configuration Exercises 768

Chapter 8 Protocol Independent Multicast 771


Introduction to Protocol Independent Multicast (PIM) 771
Operation of Protocol Independent Multicast-Dense Mode (PIM-DM) 773
PIM-DM Basics 773
Prune Overrides 779
Unicast Route Changes 782
PIM-DM Designated Routers 782
PIM Forwarder Election 782
Operation of Protocol Independent Multicast-Sparse Mode (PIM-SM) 785
PIM-SM Basics 786
xvi Routing TCP/IP, Volume II

Finding the Rendezvous Point 787


Bootstrap Protocol 787
Auto-RP Protocol 789
Embedded RP Addresses 790
PIM-SM and Shared Trees 793
Source Registration 796
PIM-SM and Shortest Path Trees 803
PIMv2 Message Formats 808
PIMv2 Message Header Format 809
PIMv2 Hello Message Format 810
PIMv2 Register Message Format 811
PIMv2 Register Stop Message Format 812
PIMv2 Join/Prune Message Format 812
PIMv2 Bootstrap Message Format 814
PIMv2 Assert Message Format 815
PIMv2 Graft Message Format 816
PIMv2 Graft-Ack Message Format 816
Candidate-RP-Advertisement Message Format 817
Configuring IP Multicast Routing 817
Case Study: Configuring Protocol Independent Multicast-Dense
Mode (PIM-DM) 819
Configuring Protocol Independent Multicast-Sparse Mode (PIM-SM) 828
Case Study: Statically Configuring the RP 829
Case Study: Configuring Auto-RP 837
Case Study: Configuring Sparse-Dense Mode 845
Case Study: Configuring the Bootstrap Protocol 849
Case Study: Multicast Load Sharing 856
Troubleshooting IP Multicast Routing 863
Using mrinfo 865
Using mtrace and mstat 867
Looking Ahead 872
Recommended Reading 872
Review Questions 873
Configuration Exercises 873
Troubleshooting Exercises 876
xvii

Chapter 9 Scaling IP Multicast Routing 881


Multicast Scoping 881
Case Study: Multicasting Across Non-Multicast Domains 885
Connecting to DVMRP Networks 888
Inter-AS Multicasting 891
Multiprotocol Extensions for BGP (MBGP) 894
Operation of Multicast Source Discovery Protocol (MSDP) 896
MSDP Message Formats 898
Source Active TLV 898
Source Active Request TLV 899
Source Active Response TLV 900
Keepalive TLV 900
Notification TLV 900
Case Study: Configuring MBGP 902
Case Study: Configuring MSDP 908
Case Study: MSDP Mesh Groups 913
Case Study: Anycast RP 917
Case Study: MSDP Default Peers 923
Looking Ahead 926
Review Questions 926
Configuration Exercise 927

Chapter 10 IPv4 to IPv4 Network Address Translation (NAT44) 931


Operation of NAT44 932
Basic NAT Concepts 932
NAT and IP Address Conservation 934
NAT and ISP Migration 937
NAT and Multihomed Autonomous Systems 938
Port Address Translation (PAT) 940
NAT and TCP Load Distribution 942
NAT and Virtual Servers 944
NAT Issues 944
Header Checksums 945
Fragmentation 945
Encryption 945
Security 946
xviii Routing TCP/IP, Volume II

Protocol-Specific Issues 946


ICMP 947
DNS 948
FTP 951
SMTP 953
SNMP 953
Routing Protocols 953
Traceroute 953
Configuring NAT44 955
Case Study: Static NAT 955
NAT44 and DNS 962
Case Study: Dynamic NAT 964
Case Study: A Network Merger 969
Case Study: ISP Multihoming with NAT 975
Port Address Translation 980
Case Study: TCP Load Balancing 982
Case Study: Service Distribution 984
Troubleshooting NAT44 986
Looking Ahead 988
Review Questions 989
Configuration Exercises 989
Troubleshooting Exercises 991

Chapter 11 IPv6 to IPv4 Network Address Translation (NAT64) 995


Stateless IP/ICMP Translation (SIIT) 997
IPv4/IPv6 Header Translation 999
ICMP/ICMPv6 Translation 1002
Fragmentation and PMTU 1005
Upper-Layer Header Translation 1006
Network Address Translation with Port Translation (NAT-PT) 1007
Operation of NAT-PT 1008
Configuring NAT-PT 1010
Why Is NAT-PT Obsolete? 1029
Stateless NAT64 1031
Operation of Stateless NAT64 1031
Configuration of Stateless NAT64 1036
Limitations of NAT64 1038
xix

Stateful NAT64 1038


Operation of Stateful NAT64 1038
Configuration of Stateful NAT64 1041
Limitations of Stateful NAT64 1043
Looking Ahead 1043
Review Questions 1044
Configuration Exercise 1044
Configuration Exercise Premise 1045

Appendix A Answers to Review Questions 1047

Index 1079

Appendix B (online) Answers to Configuration Exercises

Appendix C (online) Answers to Troubleshooting Exercises


xx Routing TCP/IP, Volume II

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 conven-
tions as follows:

Boldface indicates commands and keywords that are entered literally as shown. In
actual configuration examples and output (not general command syntax), boldface
indicates commands that are manually input by the user (such as a show command).

Italic indicates arguments for which you supply actual values.

Vertical bars (|) separate alternative, mutually exclusive elements.


Square brackets ([ ]) indicate an optional element.

Braces ({ }) indicate a required choice.

Braces within brackets ([{ }]) indicate a required choice within an optional element.
xxi

Introduction
Since the publication of Volume I of Routing TCP/IP, many volumes have been added
to the Cisco Press CCIE Professional Development series. And the CCIE program has
expanded to include various areas of specialization. Yet the IP routing protocols remain
the essential foundation on which CCIE candidates must build their expertise. If the
foundation is weak, the house will tumble.

I stated in the introduction to Volume I that as internetworks grow in size and com-
plexity, routing issues can become at once both large and subtle. Scalability and man-
agement of growth continues to be a central theme in this second volume, as we move
beyond the interior gateway protocols to examine both inter-autonomous system rout-
ing and more exotic routing issues such as multicasting and IPv6.

My objective in this book is not only to help you walk away from the CCIE lab exam
with one of those valued and valuable numbers after your name, but also to help you
develop the knowledge and skills to live up to the CCIE title. As with the first volume, I
want to make CCIEs, not people who can pass the CCIE lab. In this vein, you can find in
this book more information than you need to pass the lab, but certainly all the material
is important in your career as a recognized internetworking expert.

When I earned my CCIE, the lab still consisted mostly of AGS+ routers. Certainly, the
lab and the nature of the exam has changed substantially since that ancient time. If any-
thing, the lab is more difficult now. Another addition to the CCIE program has been
the recertification requirement. Even before I took the recertification exam for the first
time, people told me how much Volume I helped them prepare for the testparticularly
for IS-IS, a protocol that few outside of service provider environments are exposed to.
I have therefore written this second volume with not only CCIE candidates in mind, but
also existing CCIEs who need to review for their recertification. The chapters on multi-
casting and IPv6 are directed to this audience.

I have endeavored to follow the same structure that I followed in Volume I, in which a
protocol is introduced in generic terms, followed by examples of configuring the proto-
col using Cisco IOS, and finally by examples of IOS tools for troubleshooting the pro-
tocol. For BGP and IP multicast, this structure is far too lengthy for a single chapter and
therefore spans multiple chapters.

I hope you learn as much from reading this book as I have writing it.

Introduction to the Second Edition


Almost from the moment the first edition of this volume went to print in 2001, Ive
wanted to add to it and, in some cases, change it. Some of that motivation came from
my growing experience. Between 1998 and 2010, I worked almost exclusively with ser-
vice providers and carriers, and I learned something new with almost every design proj-
ect, technical discussion, and seminar I led or participated in. Certainly, some of this new
knowledge just filled gaps in my own experience, but not all of it. I also learned along
xxii Routing TCP/IP, Volume II

with the rest of the networking industry as BGP and multicast networks became more
sophisticated, as new capabilities were added, and as best practices evolved.

Whats Changed in the Industry?


The following sections outline what has changed in the industry since the first edition of
this book was published.

BGP
All the core concepts of BGP were already around when the first edition of this book
was released in 2001. It was the external gateway protocolor inter-autonomous sys-
tem routing protocol used throughout the Internet. It had multiprotocol capabilities.
Version 4 was the accepted version. Although a number of useful new features and capa-
bilities have been added since then, the protocol itself actually hasnt changed that much.

What has changed is the industry experience with BGP. This has enhanced the way poli-
cies are used and has enhanced and in some cases changed accepted best practices. And
multiprotocol BGP has become the workhorse of multiservice core networks, with quite
a few new address families defined so that you can run a multitude of different services
over a single shared core. I dont cover the other essential element of multiservice net-
works in this bookMultiprotocol Label Switching (MPLS)because the subject can
easily fill one or two volumes by itself. But you can learn enough about multiprotocol
BGP here to understand how it supports the various MPLS-based address families. And
you see plenty of examples in this book of multiprotocol BGP support for both unicast
and multicast address families under both IPv4 and IPv6.

The first edition of this book had a chapter on EGP, the predecessor to BGP. Although
obsolete even then, the protocol still existed in some obscure government networks.
So I covered it both for that reason and just in case some devious lab proctor decided
to throw a few EGP problems at you on the CCIE exam. The protocol is now most
sincerely dead and is covered in this edition only from a historical context to
introduce BGP.

Reflecting the expanded industry experience of BGP and many new features Cisco
added to its support, the two chapters on BGP in the first edition is now six chapters in
this edition.

IP Multicast
IP multicast networking has probably changed more than BGP networking has. Multicast
and the associated routing protocols were complicated, and the networks were difficult
to manage in 2001. To some degree that is still true, but also some changes make it not
quite so difficult.

In 2001, the most common multicast routing protocols were DVMRP, PIM-DM,
and PIM-SM. But I suspected that Core-Based Trees (CBT) and Multiprotocol OSPF
xxiii

(MOSPF) might become mainstream, so I covered those protocols. However, CBT and
MOSPF never found acceptance, and DVMRP has become the RIP of multicast rout-
ing protocolobsolete but still encountered on rare occasions. As a result, CBT and
MOSPF are dropped from this edition in all but passing mention, and DVMRP is cov-
ered in much less detail than it was in the first edition.

PIM is now the accepted multicast routing protocol for both IPv4 and IPv6, so PIM-DM
and PIM-SM, along with PIM-SSM, are covered in more depth than they were in the
first edition.

IPv6
I have been advocating IPv6 since the late 1990s; although by 2001, most interest in this
new version of IP was limited to Japan, the Peoples Republic of China, and the Republic
of Korea. Little interest was shown in the United States or Europe outside of a few mili-
tary circles. IPv6 was for the most part out in the unforeseen future. Anyone predicting
that the public IPv4 address pools would begin being depleted as soon as 2012 was con-
sidered a Chicken Little and probably more than a little ridiculous. So the first edition
included a standalone chapter on IPv6 with little relation to the other topics in the book.

What a difference 15 years have made. IPv6 is now a mainstream protocol, and I predict
that in not too many more years it will displace the now depleted IPv4. Reflecting this
new reality, there is no standalone IPv6 chapter in this edition. Instead, IPv6 support is
discussed in the context of BGP and IP multicast.

Network address translation in 2001 meant NAT-PT and always translation only between
different IPv4 addresses. The technology has expanded since then, so now two chapters
are included on NAT: one on IPv4-to-IPv4 translation and one on IPv6-to-IPv4 transla-
tion (NAT64).

Whats Changed in This Edition?


The last chapter difference youll find in this second edition is the elimination of the
first-edition chapter on router management (Chapter 9 in the first edition). The subject
of managing Cisco routers has expanded greatly since 2001, as have the number of
routing platforms Cisco offers, and doing the topic justice would take more room than
appropriate for this book. In addition, the book is titled Routing TCP/IP after all, not
Managing Cisco Routers.

Following are other changes in this edition:

IOS: IOS was the only Cisco router operating system in 2001. Now, in addition
to IOS, we have IOS-XR, IOS-XE, and NX-OS. Trying to cover configuration
examples and exercises under all these different systems would be confusing and
complex, and would distract from the primary goal of the two volumes of Routing
TCP/IP, which is to teach the protocols. So youll find only IOS in this book. If
xxiv Routing TCP/IP, Volume II

you understand the topics covered here, you can easily make the jump to any of the
other Cisco operating systems.

Cisco versus IOS: Related to the previous bullet, in the first edition, I usually
referred to Cisco commands. Because of the multiple operating systems Cisco
now offers, I try to be more specific in this edition and say IOS commands.

Commands versus statements: Again related to the previous bullet, I have endeav-
ored in this edition to differentiate between an IOS command and an IOS state-
ment. A command, in this edition, means something you enter and expect to get an
immediate result, such as a show command. A statement, however, is a part of an
IOS configuration that influences the routers operational state.

Command Reference: The first edition included a tabular listing at the end of each
chapter of the commands (and statements) covered in the chapter in their full syntax
with a description of each. So many commands (and statements) are covered now,
and in some cases with so many variations among different IOS versions, that the
table became long and unwieldy. So there is no end-of-chapter Command Reference
here. If you want the full syntax of a command (orahemstatement) you can eas-
ily look it up in the online Cisco Command Reference Guide for the IOS version
you use. And speaking of versions.

IOS versions: I used IOS 11.4 for most of the examples in the first edition. As you
surely know, there have been many IOS releases since then. In a few cases, I have
reused some outputs from the first edition, but in most cases I have used more
recent 12.4 or 15.0. In all cases, I have ensured that the captured configurations or
outputs include the information discussed; however, your outputs might look dif-
ferent in some cases depending on the version you use. You should focus on finding
the relevant information in an output, not on whether it looks exactly the same as
what I show you.

Integrated troubleshooting: In Volume I of Routing TCP/IP, each chapter fol-


lowed a set format of providing a generic technical overview of the chapter subject,
a section on how to configure it in IOS, and then a section on troubleshooting it.
The BGP and IP multicast chapters in this second volume are each complicated
enough and cover so much ground that the better approach is to integrate trouble-
shooting examples into the general configuration examples.

Network versus internetwork: This is a trivial change. In 2001, I tried to be precise


in my definitions, so a network meant a common communications media such as
Ethernet, whereas an internetwork was any number of networks connected by rout-
ers. Thats now old-fashioned usage. Hardly anyone says internetwork any more,
except in a few precise cases. As a result, Ive tried to kill the word off in this edi-
tion. Subnet has a more logical and address-related meaning than shared commu-
nications medium, and network is understood from the context in which the word
is used. So network might mean anything from two routers connected by a serial
or Ethernet link to a massive inter-AS system such as the Internet. It might be less
xxv

precise, but its what people use in everyday router-nerd conversations. Speaking of
trivial changes.

Those weird zig-zag serial link icons: Serial links have been represented with a
zig-zag or lightning-shaped line since before I was teaching Cisco classes in the
early 1990s. There was a reason for the distinction because serial links behaved dif-
ferently than LAN links. But in the examples throughout this volume, the link type
is irrelevant to the example. And Ive found that the zig-zag icon often clutters an
illustration. So Ive tried to eliminate those icons throughout this book and just use a
straight link for a connection between interfaces, regardless of what kind of connec-
tion it is.

Answers to Configuration and Troubleshooting


Exercises
There are two appendixes you will need to download to review the answers to the
configuration and troubleshooting exercises: Appendix B, Answers to Configuration
Exercises, and Appendix C, Answers to Troubleshooting Exercises.

You can find these appendixes online by registering your book at www.ciscopress.com/
register. Simply log in to the site, enter the book ISBN on this page (9781587054709),
and answer the security question presented to register the book. Once the book is regis-
tered, you will be able to download the files by going to your account page, opening the
Registered Products tab, and selecting the Access Bonus Content link.
This page intentionally left blank
Chapter 2

Introduction to BGP

Now that you have a rm understanding of the key issues surrounding inter-domain
routing from Chapter 1, Inter-Domain Routing Concepts, it is time to begin tackling
BGP. This chapter covers the basic operation of BGP, including its message types, how
the messages are used, and the format of the messages. You also learn about the various
basic attributes BGP can associate with a route and how it uses these attributes to
choose a best path. Finally, this chapter shows you how to congure and troubleshoot
BGP peering sessions.

Who Needs BGP?


If you answer yes to all four of the following questions, you need BGP:

Are you connecting to another routing domain?

Are you connecting to a domain under a separate administrative authority?

Is your domain multihomed?

Is a routing policy required?

The answer to the first questionare you connecting to another routing domain?
is obvious; BGP is an inter-domain routing protocol. But as the subsequent sections
explain, BGP is not the only means of routing between separate domains.

Connecting to Untrusted Domains


An underlying assumption of an IGP is that, by definition, its neighbors are all under the
same administrative authority, and therefore the neighbors can be trusted: Trusted to not
be malicious, trusted to be correctly configured, and trusted to not send bad route infor-
mation. All these things can still happen occasionally within an IGP domain, but they are
72 Chapter 2: Introduction to BGP

rare. An IGP is designed to freely exchange route information, focusing more on perfor-
mance and easy configuration than on tight control of the information.

BGP, however, is designed to connect to neighbors in domains out of the control of


its own administration. Those neighbors cannot be trusted, and the information you
exchange with those neighbors is (if BGP is configured properly) carefully controlled
with route policies.

But if connection to an external domain is your only requirementparticularly if there


is only one connectionBGP is probably not called for. Static routes serve you better in
this case; you dont have to worry about false information being exchanged because no
information at all is being exchanged. Static routes are the ultimate means of controlling
what packets are routed into and out of your network.

Figure 2-1 shows a subscriber attached by a single connection to an ISP. BGP, or any
other type of routing protocol, is unnecessary in this topology. If the single link fails, no
routing decision needs to be made because no alternative route exists. A routing proto-
col accomplishes nothing. In this topology, the subscriber adds a static default route to
the border router and redistributes the route into his AS.

ISP

205.110.32.0/20

0.0.0.0/0

Subscriber
205.110.32.0/20

Figure 2-1 Static Routes Are All That Is Needed in This Single-Homed Topology

The ISP similarly adds a static route pointing to the subscribers address range and adver-
tises that route into its AS. Of course, if the subscribers address space is a part of the
ISPs larger address space, the route advertised by the ISPs router goes no farther than
the ISPs own AS. The rest of the world can reach the subscriber by routing to the ISPs
advertised address space, and the more-specific route to the subscriber can be picked up
only within the ISPs AS.
Who Needs BGP? 73

An important principle to remember when working with inter-AS traffic is that each
physical link actually represents two logical links: one for incoming traffic, and one for
outgoing traffic, as shown in Figure 2-2.

ISP
traf ing

traf ing
om
fic

tgo
fic
Inc

Ou

Subscriber

Figure 2-2 Each Physical Link Between Autonomous Systems Represents Two Logical
Links, Carrying Incoming and Outgoing Packets

The routes you advertise in each direction influence the traffic separately. Avi Freedman,
who has written many excellent articles on ISP issues, calls a route advertisement a
promise to carry packets to the address space represented in the route. In Figure 2-1, the
subscribers router is advertising a default route into the local ASa promise to deliver
packets to any destination. And the ISPs router, advertising a route to 205.110.32.0/20,
promises to deliver traffic to the subscribers AS. The outgoing traffic from the sub-
scribers AS is the result of the default route, and the incoming traffic to the subscribers
AS is the result of the route advertised by the ISPs router. This concept may seem trivial
and obvious at this point, but it is important to keep in mind as more complex topolo-
gies are examined and as we begin establishing policies for advertised and accepted
routes.

The vulnerability of the topology in Figure 2-1 is that the entire connection consists of
single points of failure. If the single data link fails, if a router or one of its interfaces
fails, if the configuration of one of the routers fails, if a process within the router fails,
or if one of the routers all-too-human administrators makes a mistake, the subscribers
entire Internet connectivity can be lost. What is lacking in this picture is redundancy.
74 Chapter 2: Introduction to BGP

Connecting to Multiple External Neighbors


Figure 2-3 shows an improved topology, with redundant links to the same provider. How
the incoming and outgoing traffic is manipulated across these links depends upon how
the two links are used. For example, a frequent setup when multihoming to a single pro-
vider is for one of the links to be a primary, dedicated Internet access link and for the
other link to be used only for backup.

Figure 2-3 When Multihoming You Must Consider the Incoming and Outgoing
Advertisements and Resulting Traffic on Each Link

When the redundant link is used only for backup, there is again no call for BGP. The
routes can be advertised just as they were in the single-homed scenario, except that the
routes associated with the backup link have the metrics set high so that they can be used
only if the primary link fails.

Example 2-1 shows what the configurations of the routers carrying the primary and sec-
ondary links might look like.

Example 2-1 Primary and Secondary Link Configurations for Multihoming to a Single
Autonomous System

Primary Router:
router ospf 100
network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 10
!
Who Needs BGP? 75

ip route 0.0.0.0 0.0.0.0 205.110.168.108


____________________________________________
Backup Router:
router ospf 100
network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 100
!
ip route 0.0.0.0 0.0.0.0 205.110.168.113 150

In this configuration, the backup router has a default route whose administrative dis-
tance is set to 150 so that it will be only in the routing table if the default route from the
primary router is unavailable. Also, the backup default is advertised with a higher metric
than the primary default route to ensure that the other routers in the OSPF domain pre-
fer the primary default route. The OSPF metric type of both routes is E2, so the adver-
tised metrics remain the same throughout the OSPF domain. This ensures that the metric
of the primary default route remains lower than the metric of the backup default route
in every router, regardless of the internal cost to each border router. Example 2-2 shows
the default routes in a router internal to the subscribers OPSF domain.

Example 2-2 The First Display Shows the Primary External Route; the Second Display
Shows the Backup Route Being Used After the Primary Route Has Failed

Phoenix#show ip route 0.0.0.0


Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "ospf 1", distance 110, metric 10, candidate default path
Tag 1, type extern 2, forward metric 64
Redistributing via ospf 1
Last update from 205.110.36.1 on Serial0, 00:01:24 ago
Routing Descriptor Blocks:
* 205.110.36.1, from 205.110.36.1, 00:01:24 ago, via Serial0
Route metric is 10, traffic share count is 1
______________________________________________________________________
Phoenix#show ip route 0.0.0.0
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "ospf 1", distance 110, metric 100, candidate default path
Tag 1, type extern 2, forward metric 64
Redistributing via ospf 1
Last update from 205.110.38.1 on Serial1, 00:00:15 ago
Routing Descriptor Blocks:
* 205.110.38.1, from 205.110.38.1, 00:00:15 ago, via Serial1
Route metric is 100, traffic share count is 1
76 Chapter 2: Introduction to BGP

Although a primary/backup design satisfies the need for redundancy, it does not effi-
ciently use the available bandwidth. A better design would be to use both paths, with
each providing backup for the other if a link or router failure occurs. In this case, the
configuration used in both routers is indicated in Example 2-3.

Example 2-3 When Load Sharing to the Same AS, the Configuration of Both Routers
Can Be the Same

router ospf 100


network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 10 metric-type 1
!
ip route 0.0.0.0 0.0.0.0 205.110.168.108

Note A key difference between building the simple peering of Figure 2-3 as a primary/
backup configuration and as a load-sharing configuration is the consideration of band-
width. If one link is a primary and one is a backup, the bandwidth of both links should be
equal; if the primary fails, the load can be fully rerouted to the backup with no conges-
tion. In some configurations, the backup link has considerably lower bandwidth, under the
assumption that if the primary fails, the backup provides only enough bandwidth for criti-
cal applications to survive rather than full network functionality.

When a load-sharing configuration is used, the bandwidth of each of the two links
should carry the total traffic load normally carried over both links. If one of the links
fails, the other can then carry the full traffic load without packet loss.

The static routes in both routers have equal administrative distances, and the default
routes are advertised with equal metrics (10). The default routes are now advertised
with an OSPF metric type of E1. With this metric type, each of the routers in the OSPF
domain takes into account the internal cost of the route to the border routers in addition
to the cost of the default routes. As a result, every router chooses the closest exit point
when choosing a default route, as shown by Figure 2-4.

In most cases advertising default routes into the AS from multiple exit points, and sum-
marizing address space out of the AS at the same exit points, is sufficient for good inter-
network performance. The one consideration is whether asymmetric traffic patterns will
become a concern, as discussed in Chapter 1. If the geographical separation between the
two (or more) exit points is large enough for delay variations to become significant, you
might have a need for better control of the routing. BGP may now be a consideration.

For example, suppose the two exit routers in Figure 2-3 are located in Los Angeles and
London. You might want all your exit traffic destined for the Eastern Hemisphere to
use the London router, and all your exit traffic for the Western Hemisphere to use the
Los Angeles router. Remember that the incoming route advertisements influence your
Who Needs BGP? 77

outgoing traffic. If the provider advertises routes into your AS via BGP, your internal
routers has more accurate information about external destinations.

0.0.0.0/0 0.0.0.0/0
Cost = 10 Cost = 10
Type = E1 Type = E1

10 10

20 10

10 20
64

10

20 64

Preferred Route

Figure 2-4 The OSPF Border Routers Advertise a Default Route with a Metric of 10 and
an OPSF Metric Type of E1

Similarly, outgoing route advertisements influence your incoming traffic. If internal


routes are advertised to the provider via BGP, you have influence over what routes are
advertised at what exit point, and also tools for influencing (to some degree) the choices
the provider makes when sending traffic into your AS.

When considering whether to use BGP, weigh the benefits gained against the cost of
added routing complexity. BGP should be preferred over static routes only when an
advantage in traffic control can be realized. Consider the incoming and outgoing traffic
separately. If it is only important to control your incoming traffic, use BGP to advertise
routes to your provider while still advertising only a default route into your AS.

However, if it is only important to control your outgoing traffic, use BGP just to receive
routes from your provider. Consider the ramifications of accepting routes from your
provider. Taking full BGP routes means that your provider advertises to you the entire
Internet routing table. As of this writing, that is more than 500,000 IPv4 route entries,
78 Chapter 2: Introduction to BGP

as shown in Example 2-4. The IPv6 Internet table is growing rapidly. You need a reason-
ably powerful router CPU to process the routes and enough router memory to store
the entries. You also need sufficient TCAM or other forwarding plane memory to hold
forwarding information. Example 2-4 shows that just the BGP routes require almost
155.7MB; the memory that BGP requires to process these routes, as shown in Example
2-5, is approximately 4.1GB. A simple default-routing scheme, however, can be imple-
mented easily with a low-end router and a moderate amount of memory.

Example 2-4 This Summary of the Full Internet Routing Table Shows 540,809
BGP Entries 1

route-views>show ip route summary


IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source Networks Subnets Replicates Overhead Memory (bytes)
connected 0 2 0 192 576
static 1 57 0 5568 16704
application 0 0 0 0 0
bgp 6447 174172 366637 0 51917664 155752992
External: 540809 Internal: 0 Local: 0
internal 7847 42922856
Total 182020 366696 0 51923424 198693128
route-views>

Example 2-5 BGP Requires Approximately 4.1GB of Memory to Process the Routes
Shown in Example 2-4

route-views> show processes memory | include BGP


117 0 0 232 41864 644 644 BGP Scheduler
176 0 1505234352 262528 370120 14362638 14362638 BGP I/O
299 0 0 10068312 41864 0 0 BGP Scanner
314 0 0 0 29864 0 0 BGP HA SSO
338 0 27589889144 2170064712 4102896864 3946 3946 BGP Router
350 0 0 0 29864 0 0 XC BGP SIG RIB H
383 0 0 0 41864 0 0 BGP Consistency
415 0 0 0 41864 0 0 BGP Event
445 0 0 0 29864 0 0 BGP VA
450 0 3224 0 33160 1 0 BGP Open
562 0 328104 262528 107440 0 0 BGP Task
574 0 3248 0 33160 1 0 BGP Open

1
This display was taken in 2014 from the public route server at University of Oregon (AS6447).
The corresponding example in the first edition of this book, taken from an AT&T route server in
1999, showed 88,269 BGP entries.
Who Needs BGP? 79

575 0 3120 0 33088 1 0 BGP Open


577 0 3120 0 33040 1 0 BGP Open
578 0 3120 0 33072 1 0 BGP Open
route-views>

Note The routing table summary in Example 2-4 and the related processes shown in
Example 2-5 are taken from a route server at route-views.oregon-ix.net. By the time you
read this chapter, the numbers shown in these two examples will have changed; telnet
to the server, and see what they are now. There are a number of such publicly accessible
route servers; for a good list, go to www.netdigix.com/servers.html.

Another consideration is that when running BGP, a subscribers routing domain must be
identified with an autonomous system (AS) number. Like IPv4 addresses, AS numbers
are limited and are assigned only by the regional address registries when there is a justifi-
able need. And like IPv4 addresses, a range of AS numbers is reserved for private use:
the AS numbers 64512 to 65534. As with private IPv4 addresses (RFC 1918), these AS
numbers are not globally unique and must not be included in the AS_PATH of any route
advertised into the public Internet. With few exceptions, subscribers that are connected
to a single service provider (either single or multihomed) use an AS number out of the
reserved range. The service provider filters the private AS number out of the advertised
BGP path. Configuring and filtering private AS numbers is covered in Chapter 5, Scaling
BGP.

Although the topology in Figure 2-3 is an improvement over the topology in Figure 2-2
because redundant routers and data links have been added, it still entails a single point
of failure. That point of failure is the ISP. If the ISP loses connectivity to the rest of
the Internet, so does the subscriber. And if the ISP suffers a major internal outage, the
single-homed subscriber also suffers.

Setting Routing Policy


Figure 2-5 shows a topology in which a subscriber has homed to more than one service
provider. In addition to the advantages of multihoming already described, this subscriber
is protected from losing Internet connectivity as the result of a single ISP failure. And
with this topology BGP begins to become a better choice, in most cases, than static
routes.

The subscriber in Figure 2-5 could still forego BGP. One option is to use one ISP as a
primary Internet connection and the other as a backup only; another option is to default
route to both providers and let the routing chips fall where they may. But if a subscriber
has gone to the expense of multihoming and contracting with multiple providers, neither
of these solutions is likely to be acceptable. BGP is the preferred option in this scenario.
80 Chapter 2: Introduction to BGP

Internet

ISP1
ISP2
Incom

Outgo

tra ing

tra oing
traffic

traffic

om
ffic

ffic
tg
ing

Inc
ing

Ou
Subscriber

Figure 2-5 Multihoming to Multiple Autonomous Systems

Again, incoming and outgoing traffic should be considered separately. For incoming
traffic, the most reliability is realized if all internal routes are advertised to both pro-
viders. This setup ensures that all destinations within the subscribers AS are completely
reachable via either ISP. Even though both providers are advertising the same routes,
there are cases in which incoming traffic should prefer one path over another; such situa-
tions are discussed in the multihoming sections of Chapter 1. BGP provides the tools for
communicating these preferences.

For outgoing traffic, the routes accepted from the providers should be carefully consid-
ered. If full routes are accepted from both providers, the best route for every Internet
destination is chosen. In some cases, however, one provider might be preferred for full
Internet connectivity, whereas the other provider is preferred for only some destina-
tions. In this case, full routes can be taken from the preferred provider and partial routes
can be taken from the other provider. For example, you might want to use the second-
ary provider only to reach its other subscribers and for backup to your primary Internet
provider (see Figure 2-6). The secondary provider sends its customer routes, and the
subscriber configures a default route to the secondary ISP to be used if the connection
to the primary ISP fails.

The full routes sent by ISP1 probably include the customer routes of ISP2, learned from
the Internet or perhaps from a direct peering connection. Because the same routes are
received from ISP2, however, the subscribers routers normally prefer the shorter path
through ISP2. If the link to ISP2 fails, the subscriber uses the longer paths through ISP1
and the rest of the Internet to reach ISP2s customers.
Who Needs BGP? 81

Internet
ISP2
customer

ISP1 ISP2 ISP2


customer

Full ISP2
routes ISP2
routes
+ customer
Default

ISP2
Subscriber
customer

Figure 2-6 ISP1 Is the Preferred Provider for Most Internet Connectivity; ISP2 Is Used
Only to Reach Its Other Customers Networks and for Backup Internet Connectivity

Similarly, the subscriber normally uses ISP1 to reach all destinations other than ISP2s
customers. If some or all of those more-specific routes from ISP1 are lost, however, the
subscriber uses the default route through ISP2.

If router CPU and memory limitations prohibit taking full routes,2 partial routes from
both providers are an option. Each provider might send its own customer routes, and the
subscriber points default routes to both providers. In this scenario, some routing accu-
racy is traded for a savings in router resources.

In yet another partial-routes scenario, each ISP might send its customer routes and also
the customer routes of its upstream provider (which typically is a national or global
backbone carrier such as Level 3 Communications, Sprint, NTT, or Deutsche Telekom).
In Figure 2-7, for example, ISP1 is connected to Carrier1, and ISP2 is connected to
Carrier2. The partial routes sent to the subscriber by ISP1 consist of all ISP1s customer
routes and all Carrier1s customer routes. The partial routes sent by ISP2 consist of
all ISP2s customer routes and all Carrier2s customer routes. The subscriber points to
default routes at both providers. Because of the size of the two backbone carrier provid-
ers, the subscriber has enough routes to make efficient routing decisions on a large num-
ber of destinations. At the same time, the partial routes are still significantly smaller than
a full Internet routing table.

2
Taking full BGP routes from two sources doubles the number of BGP entries in all routers and
consequently doubles the memory demand.
82 Chapter 2: Introduction to BGP

Internet

Carrier 1 Carrier 2

IXP

ISP 1 Routes ISP 2 Routes


+ +
Carrier 1 Routes Carrier 2 Routes
+ +
ISP 1 Default Default ISP 2

Subscriber

Figure 2-7 The Subscriber Is Taking Partial Routes from Both ISPs, Consisting of
All ISPs Customer Routes and the Customer Routes from Their Respective Upstream
Providers

All the examples here have shown a stub AS connected to one or more ISPs. Figures 2-5
through 2-7 begin introducing enough complexity that BGP and routing policy are prob-
ably called for. As the complexity of multihoming and its related policy issues grow, as
illustrated in the transit AS examples in the previous chapter, the need for BGP becomes
increasingly sure.

BGP Hazards
Creating a BGP peering relationship involves an interesting combination of trust and
mistrust. The BGP peer is in another AS, so you must trust the network administrator
on that end to know what she is doing. At the same time, if you are smart, you will take
every practical measure to protect yourself if a mistake is made on the other end. When
you implement a BGP peering connection, paranoia is your friend.

At the same time, you should be a good neighbor by taking practical measures to ensure
that a mistake in your AS does not affect your BGP peers.

Recall the earlier description of a route advertisement as a promise to deliver packets to


the advertised destination. The routes you advertise directly influence the packets you
receive, and the routes you receive directly influence the packets you transmit. In a good
Who Needs BGP? 83

BGP peering arrangement, both parties should have a complete understanding of what
routes are to be advertised in each direction. Again, incoming and outgoing traffic must
be considered separately. Each peer should ensure that he is transmitting only the cor-
rect routes and should use route filters or other policy tools such as AS_PATH filters,
described in Chapter 4, BGP and Routing Policies, to ensure that he receives only the
correct routes.

Your ISP might show little patience with you if you make mistakes in your BGP configu-
ration, but the worst problems can be attributed to a failure on both sides of the peering
arrangement. Suppose, for example, that through some misconfiguration you advertise
207.46.0.0/16 to your ISP. On the receiving side, the ISP does not filter out this incor-
rect route, allowing it to be advertised to the rest of the Internet. This particular CIDR
block belongs to Microsoft, and you have just claimed to have a route to that destina-
tion. A significant portion of the Internet community could decide that the best path to
Microsoft is through your domain. You will receive a flood of unwanted packets across
your Internet connection and, more important, you will have black-holed traffic that
should have gone to Microsoft. It will be neither amused nor understanding.

This kind of thing happens frequently: Not long ago, Yahoo experienced a brief outage
due to a company in Seoul mistakenly advertising a /14 prefix that included addresses
belonging to Yahoo.

Figure 2-8 shows another example of a BGP routing mistake. This same internetwork was
shown in Figure 2-6, but here the customer routes that the subscriber learned from ISP2
have been inadvertently advertised to ISP1.

Internet
ISP2
customer

ISP1 ISP2 ISP2


customer

Full ISP2 ISP2


routes ISP2
routes routes
+ customer
Default

ISP2
Subscriber
customer

Figure 2-8 This Subscriber Is Advertising Routes Learned from ISP2 into ISP1, Inviting
Packets Destined for ISP2 and Its Customers to Transit His Domain
84 Chapter 2: Introduction to BGP

Unless ISP1 and ISP2 have a direct peering connection, ISP1 and its customers prob-
ably see the subscribers domain as the best path to ISP2 and its customers. In this case,
the traffic is not black-holed because the subscriber does indeed have a route to ISP2.
The subscriber has become a transit domain for packets from ISP1 to ISP2, to the detri-
ment of its own traffic. And because the routes from ISP2 to ISP1 still point through the
Internet, the subscriber has caused asymmetric routing for ISP2.

The point of this section is that BGP, by its nature, is designed to allow communica-
tion between autonomously controlled systems. A successful and reliable BGP peering
arrangement requires an in-depth understanding of not only the routes to be advertised
in each direction, but also the routing policies of each of the involved parties.

The remainder of this chapter introduces the technical basics of BGP and demonstrates
how to configure and troubleshoot simple BGP sessions. With that foundation experi-
ence, you then get a good taste of configuring and troubleshooting policies in Chapter 4.

Operation of BGP
The section BGP Basics in Chapter 1 introduced you to the fundamental facts about
BGP. To recap

Unique among the common IP routing protocols, BGP sends only unicast messages
and forms a separate point-to-point connection with each of its peers.

BGP is an application layer protocol using TCP (port 179) for this point-to-point
connection and relies on the inherent properties of TCP for session maintenance
functions such as acknowledgment, retransmission, and sequencing.

BGP is a vector protocol, although called a path vector rather than distance vector
because it sees the route to a destination as a path through a series of autonomous
systems rather than as a series of routers hops.

A BGP route describes the path vector using a route attribute called the AS_PATH,
which sequentially lists the autonomous system numbers comprising the path to the
destination.

The AS_PATH attribute is a shortest path determinant. Given multiple routes to


the same destination, the route with an AS_PATH listing the fewest AS numbers is
assumed to be the shortest path.

The AS numbers on the AS_PATH list are used for loop detection; a router receiv-
ing a BGP route with its own AS number in the AS_PATH assumes a loop and dis-
cards the route.

If a router has a BGP session to a neighbor with a different AS number, the ses-
sion is called external BGP (EBGP); if the neighbor has the same AS number as the
router, the session is called internal BGP (IBGP). The neighbors are called, respec-
tively, external or internal neighbors.

This chapter builds on these basic facts to describe the operation of BGP.
Operation of BGP 85

BGP Message Types


Before establishing a BGP peer connection, the two neighbors must perform the stan-
dard TCP three-way handshake and open a TCP connection to port 179. TCP provides
the fragmentation, retransmission, acknowledgment, and sequencing functions necessary
for a reliable connection, relieving BGP of those duties. All BGP messages are unicast to
the one neighbor over the TCP connection.

BGP uses four basic message types:

Open
Keepalive

Update

Notification

Note There is a fifth BGP message type: Route Refresh. But unlike the four presented
here, this fifth message type is not a part of basic BGP functionality and might not be
supported by all BGP routers. The Route Refresh message and its use are described in
Chapter 4.

This section describes how these messages are used; for a complete description of the
message formats and the variables of each message field, see the section BGP Message
Formats.

Open Message
After the TCP session is established, both neighbors send Open messages. Each neighbor
uses this message to identify itself and to specify its BGP operational parameters. The
Open message includes the following information:

BGP version number: This specifies the version (2, 3, or 4) of BGP that the origina-
tor is running; the IOS default is BGP-4. Prior to IOS 12.0(6)T, IOS would autone-
gotiate the version: If a neighbor is running an earlier version of BGP, it rejects the
Open message specifying version 4; the BGP-4 router then changes to BGP-3 and
sends another Open message specifying this version. If the neighbor rejects that
message, an Open specifying version 2 is sent. BGP-4 has now become so prevalent
that as of 12.0(6)T IOS no longer autonegotiates, but you can still configure a ses-
sion to speak to a neighbor running version 2 or 3 with neighbor version.

Autonomous system number: This is the AS number of the originating router. It


determines whether the BGP session is EBGP (if the AS numbers of the neighbors
differ) or IBGP (if the AS numbers are the same).
86 Chapter 2: Introduction to BGP

Hold time: This is the maximum number of seconds that can elapse before the
router must receive either a Keepalive or an Update message. The hold time must be
either 0 seconds (in which case, keepalives must not be sent) or at least 3 seconds;
the default IOS hold time is 180 seconds. If the neighbors hold times differ, the
smaller of the two times becomes the accepted hold time. The default hold time can
be changed for the entire BGP process with the configuration statement timers bgp
or for a specific neighbor or peer group with neighbor timers.

BGP identifier: This is an IPv4 address that identifies the neighbor. IOS determines
the BGP Identifier in exactly the same way as it determines the OSPF router ID: The
numerically highest loopback address is used; if no loopback interface is configured
with an IP address, the numerically highest IP address on a physical interface is
selected. Or you can manually specify the BGP identifier with bgp router-id.

Optional parameters: This field is used to advertise support for such optional capa-
bilities as authentication, multiprotocol support, and route refresh.

Keepalive Message
If a router accepts the parameters specified in its neighbors Open message, it responds
with a Keepalive. Subsequent Keepalives are sent every 60 seconds by IOS default, or
a period equal to one-third the agreed-upon holdtime. Like the holdtime, the keepalive
interval can be changed for the entire BGP process with timers bgp or on a per-neighbor
or per-peer-group basis with neighbor timers.

Note that although BGP offloads several reliability functions to the underlying TCP ses-
sion, it does use its own keepalive rather than using the TCP keepalive.

Update Message
The Update message advertises feasible routes, withdrawn routes, or both. The Update
message includes the following information:

Network Layer Reachability Information (NLRI): This is one or more


(Length, Prefix) tuples that advertise destination prefixes and their lengths. If
206.193.160.0/19 were advertised, for example, the Length portion would specify
the /19 and the Prefix portion would specify 206.193.160. However, as discussed
at the beginning of Chapter 3, BGP and NLRI, and covered more extensively in
Chapter 6, Multiprotocol BGP, the NLRI can be more than just a unicast IPv4
prefix.

Path attributes: The path attributes, described in a later section of the same name,
are characteristics of the advertised NLRI. The attributes provide the information
that allows BGP to choose a shortest path, detect routing loops, and determine rout-
ing policy.

Withdrawn routes: These are (Length, Prefix) tuples describing destinations that
have become unreachable and are being withdrawn from service.
Operation of BGP 87

Although multiple prefixes might be included in the NLRI field, each Update message
describes only a single BGP path (because the path attributes describe only a single path,
but that path might lead to multiple destinations). This, again, emphasizes that BGP takes
a higher view of an internetwork than an IGP, whose routes always lead to a single desti-
nation IP address.

Notification Message
The Notification message is sent whenever an error is detected and always causes the
BGP connection to close. The section BGP Message Formats includes a list of possible
errors that can cause a Notification message to be sent.

An example of the use of a Notification message is the negotiation of a BGP version


between neighbors. If, after establishing a TCP connection, a BGP-4 speaker receives
an Open message specifying version 3, the router responds with a Notification message
stating that the version is not supported, and the session is closed.

BGP Finite State Machine


The stages of a BGP neighbor connection establishment and maintenance can be
described in terms of a finite state machine. Figure 2-9 and Table 2-1 show the complete
BGP finite state machine and the input events that can cause a state transition.

IE 1,7 IE 1,5

IE 7
Active
Connect IE 5
13
8-

IE
6,

4
4,

IE

-13 IE
2,

,6,8
3
1

3
IE

2,4
IE

IE 1
IE

IE 2,3,5-13 Open Sent


Idle
IE 2-
10

8,10
IE

IE 2-13 ,12,1
IE
2-

3
8,10
,12
,13

Open Confirm
IE 11
Established

IE 1,9

IE 1,9,11,12

Figure 2-9 BGP Finite State Machine


88 Chapter 2: Introduction to BGP

Table 2-1 Input Events (IE) of Figure 2-9


IE Description
1 BGP Start
2 BGP Stop
3 BGP Transport connection open
4 BGP Transport connection closed
5 BGP Transport connection open failed
6 BGP Transport fatal error
7 ConnectRetry timer expired
8 Hold timer expired
9 Keepalive timer expired
10 Receive Open message
11 Receive Keepalive message
12 Receive Update message
13 Receive Notification message

The following sections provide a brief description of each of the six neighbor states, as
shown in Figure 2-9.

Idle State
BGP always begins in the Idle state, in which it refuses all incoming connections. When
a Start event (IE 1) occurs, the BGP process initializes all BGP resources, starts the
ConnectRetry timer, initializes a TCP connection to the neighbor, listens for a TCP ini-
tialization from the neighbor, and changes its state to Connect. The Start event is caused
by an operator configuring a BGP process or resetting an existing process, or by the
router software resetting the BGP process.

An error causes the BGP process to transition to the Idle state. From there, the router
may automatically try to issue another Start event. However, limitations should be
imposed on how the router does thisconstantly trying to restart in the event of persis-
tent error conditions causes flapping. Therefore, after the first transition back to the Idle
state, the router sets the ConnectRetry timer and cannot attempt to restart BGP until
the timer expires. IOSs initial ConnectRetry time is 120 seconds; this value cannot be
changed. The ConnectRetry time for each subsequent attempt is twice the previous time,
meaning that consecutive wait times increase exponentially.
Operation of BGP 89

Connect State
In this state, the BGP process is waiting for the TCP connection to the neighbor
to be completed. If the TCP connection is successful, the BGP process clears the
ConnectRetry timer, completes initialization, sends an Open message to the neighbor,
and transitions to the OpenSent state. If the TCP connection is unsuccessful, the BGP
process continues to listen for a connection to be initiated by the neighbor, resets the
ConnectRetry timer, and transitions to the Active state.

If the ConnectRetry timer expires while in the Connect state, the timer is reset, another
attempt is made to establish a TCP connection with the neighbor, and the process stays
in the Connect state. Any other input event causes a transition to Idle.

Active State
In this state, the BGP process tries to initiate a TCP connection with the neighbor. If the
TCP connection is successful, the BGP process clears the ConnectRetry timer, completes
initialization, sends an Open message to the neighbor, and transitions to OpenSent. The
IOS default Hold time is 180 seconds (3 minutes) and can be changed with the timers
bgp statement.

If the ConnectRetry timer expires while BGP is in the Active state, the process transi-
tions back to the Connect state and resets the ConnectRetry timer. It also initiates a
TCP connection to the peer and continues to listen for connections from the peer. If
the neighbor attempts to establish a TCP session with an unexpected IP address, the
ConnectRetry timer is reset, the connection is refused, and the local process stays in the
Active state. Any other input event (except a Start event, which is ignored in the Active
state) causes a transition to Idle.

OpenSent State
In this state, an Open message has been sent, and BGP is waiting to hear an Open from
its neighbor. When an Open message is received, all its fields are checked. If errors exist,
a Notification message is sent and the state transitions to Idle.

If no errors exist in the received Open message, a Keepalive message is sent and the
Keepalive timer is set. The Hold time is negotiated, and the smaller value is agreed upon.
If the negotiated Hold time is zero, the Hold and Keepalive timers are not started. The
peer connection is determined to be either internal or external, based on the peers AS
number, and the state is changed to OpenConfirm.

If a TCP disconnect is received, the local process closes the BGP connection, resets
the ConnectRetry timer, begins listening for a new connection to be initiated by the
neighbor, and transitions to Active. Any other input event (except a start event, which is
ignored) causes a transition to Idle.
90 Chapter 2: Introduction to BGP

OpenConfirm State
In this state, the BGP process waits for a Keepalive or Notification message. If a
Keepalive is received, the state transitions to Established. If a Notification is received, or
a TCP disconnect is received, the state transitions to Idle.

If the Hold timer expires, an error is detected, or a Stop event occurs, a Notification is
sent to the neighbor and the BGP connection is closed, changing the state to Idle.

Established State
In this state, the BGP peer connection is fully established and the peers can exchange
Update, Keepalive, and Notification messages. If an Update or Keepalive message
is received, the Hold timer is restarted (if the negotiated hold time is nonzero). If a
Notification message is received, the state transitions to Idle. Any other event (again,
except for the Start event, which is ignored) causes a Notification to be sent and the
state to transition to Idle.

Path Attributes
A path attribute is a characteristic of an advertised BGP route. Although the term is spe-
cific to BGP, the concept is not unfamiliar to you: Every route advertisement, no matter
what the originating routing protocol, has attributes. For example, every route adver-
tisement has information (an address prefix) representing some destination, some quan-
tification (metric) of the destination enabling comparison to other routes to the same
destination, and some directional information about the destination, such as a next-hop
address. BGP routes have the same attributes you are familiar with from other protocols
but can also include a number of other attributes that are designed to be manipulated for
the creation and communication of routing policies.

Each path attribute falls into one of four categories:

Well-known mandatory

Well-known discretionary

Optional transitive

Optional nontransitive

First, an attribute is either well known, meaning that it must be recognized by all BGP
implementations, or it is optional, meaning that the BGP implementation is not required
to support the attribute.

Well-known attributes are either mandatory, meaning that they must be included in all
BGP Update messages, or they are discretionary, meaning that they may or may not be
sent in a specific Update message.

An optional attribute is either transitive, meaning that a BGP process should accept the
Update in which it is includedeven if the process doesnt support the attributeand
Operation of BGP 91

should pass the attribute on to its peers, or it is nontransitive, meaning that a BGP
process that does not recognize the attribute can quietly ignore the Update in which it
is included and not advertise the path to its other peers. In simple terms, the attribute
either can or cannot transit a router.

Table 2-2 lists the BGP path attributes. The three well-known mandatory attributes,
because they are required to be in every BGP Update, are described in the following
subsections. A Cisco-specific attribute called weight is also covered in this section. The
other attributes are described within the context of their primary use as policy enablers
(Chapter 4), for scaling (Chapter 5), or for carrying multiple NLRI types (Chapter 6).

Note If you are already familiar with the Communities and Extended Community
attribute, you might wonder why Table 2-2 lists them as scaling features rather than
policy enablers. A policy enabler can directly influence the BGP decision process.
Communities make it easier to apply policies to a group of routes but do not influence
the BGP decision process.

Table 2-2 BGP Path Attributes


Attribute Class RFC Application
ORIGIN Well-known mandatory 4271 Policy
AS_PATH Well-known mandatory 4271 Policy, loop
detection
NEXT_HOP Well-known mandatory 4271 Policy
LOCAL_PREF Well-known discretionary 4271 Policy
ATOMIC_AGGREGATE Well-known discretionary 4271 Address
aggregation
AGGREGATOR Optional transitive 4271 Address
aggregation
COMMUNITIES Optional transitive 1997 Scaling
EXTENDED Optional transitive 4360 Scaling
COMMUNITY
MULTI_EXIT_DISC (MED) Optional nontransitive 4271 Policy
ORIGINATOR_ID Optional nontransitive 4456 Scaling, loop
detection,
policy
CLUSTER_LIST Optional nontransitive 4456 Scaling, loop
detection,
policy
AS4_PATH Optional transitive 6793 Scaling, policy
92 Chapter 2: Introduction to BGP

Attribute Class RFC Application


AS4_AGGREGATOR Optional transitive 6793 Scaling,
address aggre-
gation
Multiprotocol Reachable Optional nontransitive 4760 Multiprotocol
NLRI BGP
Multiprotocol Unreachable Optional nontransitive 4760 Multiprotocol
NLRI BGP

ORIGIN Attribute
ORIGIN is a well-known mandatory attribute that specifies the origin of the routing
update. When BGP has multiple routes to the same destination, it uses the ORIGIN as
one factor in determining the preferred route. It specifies one of the following origins:

IGP: The Network Layer Reachability Information (NLRI) was learned from a pro-
tocol internal to the originating AS. An IGP origin gets the highest preference of the
ORIGIN values. IOS gives BGP routes an origin of IGP if they are learned from an
IGP routing table via the BGP network statement, as described in Chapter 3.

EGP: The NLRI was learned from the Exterior Gateway Protocol. EGP is preferred
second to IGP. Because EGP is obsolete, you should never encounter this origin
type; its an artifact of the days when we transitioned from EGP to BGP.

Incomplete: The NLRI was learned by some other means. Incomplete is the lowest-
preferred ORIGIN value. Incomplete does not imply that the route is in any way
faulty, only that the information for determining the origin of the route is incom-
plete. Routes that BGP learns through redistribution carry the incomplete origin
attribute because there is no way to determine the original source of the route.

Although ORIGIN is still a mandatory part of the BGP standard, it was created to help
as the second of the three possible origins indicateswith the transition from EGP to
BGP. It might have some limited use in a few corner case policy configurations but for
the most part should be considered a legacy attribute.

AS_PATH Attribute
AS_PATH is a well-known mandatory attribute that uses a sequence of AS numbers to
describe the inter-AS path, or AS-level route, to the destination specified by the NLRI.
When an AS originates a routewhen it advertises NLRI about a destination within its
own AS to an external neighborit adds its AS number to the AS_PATH. As subsequent
BGP speakers advertise the route to external peers, they prepend their own AS num-
bers to the AS_PATH (see Figure 210). The result is that the AS_PATH describes all the
autonomous systems it has passed through, beginning with the most recent AS and end-
ing with the originating AS.
Operation of BGP 93

AS500

207.126.0.0/16 207.126.0.0/16
[400,200,100] [300,100]

AS400 AS300

207.126.0.0/16
[200,100]

AS200 207.126.0.0/16
[100]

207.126.0.0/16 AS100
[100] 207.126.0.0/16

Figure 2-10 AS Numbers Are Prepended (Added to the Front of) the AS_PATH List

Note that a BGP router adds its AS number to the AS_PATH only when an Update is
sent to a neighbor in another AS. That is, an AS number is prepended to the AS_PATH
only when the route is advertised between EBGP peers. If the route is advertised
between IBGP peerspeers within the same autonomous systemno AS number is
added.

Usually, having multiple instances of the same AS number on the list would make no
sense and would defeat the purpose of the AS_PATH attribute. In one case, however,
adding multiple instances of a particular AS number to the AS_PATH proves use-
ful. Remember that outgoing route advertisements directly influence incoming traf-
fic. Normally, the route from AS500 to AS100 in Figure 2-10 passes through AS300
because the AS_PATH of that route is shorter (that is, lists fewer AS numbers). But what
if the link to AS200 is AS100s preferred path for incoming traffic? The links along the
(400,200,100) path might all be 10G, for example, whereas the links along the (300,100)
path are only 1G. Or perhaps AS200 is the primary provider, and AS300 is only the
backup provider. Outgoing traffic is sent to AS200, so it is desired that incoming traffic
follow the same path.

AS100 can influence its incoming traffic by changing the AS_PATH of its advertised
route (Figure 2-11). By adding multiple instances of its own AS number to the list sent
to AS300, AS100 can make routers at AS500 think that the (400,200,100) path is the
shorter path. This procedure of adding extra AS numbers to the AS_PATH is called
AS path prepending.
94 Chapter 2: Introduction to BGP

AS500

207.126.0.0/16 207.126.0.0/16
[400,200,100] [300,100,100,100]

AS400 AS300

207.126.0.0/16
[200,100]

AS200 207.126.0.0/16
[100,100,100]

207.126.0.0/16 AS100
[100] 207.126.0.0/16

Figure 2-11 AS100 Has Prepended Two Extra Instances of Its AS Number to the AS_
PATH Advertised to AS300, to Influence the Path Choice Made at AS500

The AS_PATH attribute has been presented so far as consisting of an ordered sequence
of AS numbers that describes the path to a particular destination. There are actually two
types of AS_PATH:

AS_SEQUENCE: This is the ordered list of AS numbers, as previously described.

AS_SET: This is an unordered list of the AS numbers along a path to a destination.

These two types are distinguished in the AS_PATH attribute with a type code, as
described in the section BGP Message Formats.

Note The AS_SEQUENCE and AS_SET types each have a modified version: AS_
CONFED_SEQUENCE and AS_CONFED_SET, respectively. They each perform the
same functions as the AS_SEQUENCE and AS_SET but within the context of BGP
Confederations (explained in Chapter 5).

Recall that the second function of the AS_PATH is loop prevention. If a BGP speaker
sees its own AS number in a received route from an external peer, it knows that a loop
has occurred and ignores the route. When aggregation is performed, however, some
AS_PATH detail is lost. For example, AS3113 in Figure 2-12 is aggregating the prefixes
advertised by AS225, AS237, and AS810. Because AS3113 originates the aggregate
Operation of BGP 95

prefix, the AS_PATH associated with it contains only that AS number. As a result, the
potential for a loop increases.

Figure 2-12 The Aggregation at AS3113 Causes a Loss of the AS_PATH Information of
the Aggregates Constituent Prefixes

Suppose, for example, AS810 has an alternative connection to another AS, as shown in
Figure 2-13. The aggregate from AS3113 is advertised to AS6571 and from there back to
AS810.

Because the AS numbers behind the aggregation point are not included in the
AS_PATH, AS810 does not detect the potential loop. Next, suppose a network within
AS810, such as 206.25.225.0/24, fails. The routers within that AS match the aggregate
route from AS6571, and a loop occurs.

If you think about it, the loop-prevention function of the AS_PATH does not require
that the AS numbers be included in any particular order. All that is necessary is that
a receiving router recognize whether its AS number is a part of the AS_PATH. This is
where AS_SET comes in.

When a BGP speaker creates an aggregate from NLRI learned from other autonomous
systems, it can include all those AS numbers in the AS_PATH as an AS_SET. For exam-
ple, Figure 2-14 shows the network of Figure 2-12 with an AS_SET added to the aggre-
gate route.

The aggregating router still begins an AS_SEQUENCE, so receiving routers can trace the
path back to the aggregator, but an AS_SET is included to prevent routing loops. In this
example, you also can see why the AS_SET is an unordered list. Behind the aggregator in
96 Chapter 2: Introduction to BGP

AS3113 are branching paths to the autonomous systems in which the aggregated routes
reside. There is no way for an ordered list to describe these separate paths.

Figure 2-13 The Loss of AS_PATH Information at Aggregation Points Weakens the
AS_PATH Loop Avoidance Function

206.25.128.0/17
AS_SEQUENCE = (3113)
AS_SET = (237,810,225)

AS3113
206.25.128.0/19

206.25.192.0/19
(237,225)
206.25.160.0/19
(237) 206.25.224.0/19
(810)

AS237
206.25.192.0/19
206.25.160.0/19
(225)

AS810
AS225 206.25.224.0/19
206.25.192.0/19

Figure 2-14 Including an AS_SET in the AS_PATH of an Aggregate Route Restores the
Loop Avoidance That Was Lost in the Aggregation
Operation of BGP 97

AS_SET involves a trade-off. You already understand that one of the advantages of
route summarization is route stability. If a network that belongs to the aggregate
fails, the failure is not advertised beyond the aggregation point. But if an AS_SET is
included with the aggregates AS_PATH, this stability is reduced. If the link to AS225
in Figure 2-14 fails, for example, the AS_SET changes; this change must be advertised
beyond the aggregation point. However, the visibility of constituent AS numbers associ-
ated with an aggregate route is much less of a concern that the visibility of many pre-
fixes behind an aggregate.

As it turns out, AS_SET is seldom used in the public Internet at aggregation points.
Given the potential instability discussed in the previous paragraph, plus the potential
for accidentally including private AS numbers in the AS_SET, and other complexities,
RFC 6472 recommends that AS_SET not be used except where a few corner cases
might justify it. Although AS_SET is still supported by most Internet-grade BGP imple-
mentations, including Cisco IOS, RFC 6472 suggests that a future update of BGP might
remove AS_SET support.

NEXT_HOP Attribute
As the name implies, this well-known mandatory attribute describes the IP address of the
next-hop router on the path to the advertised destination. Unlike typical IGPs, however,
the IP address described by the BGP NEXT_HOP attribute is not always the address of a
neighboring router. The following rules apply:

If the advertising router and receiving router are in different autonomous sys-
tems (external peers), the NEXT_HOP is the IP address of the advertising routers
interface.

If the advertising router and the receiving router are in the same AS (internal peers),
and the Updates NLRI refers to a destination within the same AS, the NEXT_HOP
is an IP address belonging to the neighbor that advertised the route.

If the advertising router and the receiving router are internal peers and the Updates
NLRI refers to a destination in a different AS, the NEXT_HOP is the IP address of
the external peer from which the route was learned.

Figure 2-15 illustrates the first rule. Here, the advertising router and receiving router are
in different autonomous systems. The NEXT_HOP is the interface address of the exter-
nal peer. So far, this behavior is the same as would be expected of any routing protocol.

Figure 2-16 illustrates the second rule. This time, the advertising router and the receiving
router are in the same AS, and the destination advertised is also in the AS. The
NEXT_HOP associated with the NLRI is the IP address of the originating router.
98 Chapter 2: Introduction to BGP

Figure 2-15 If a BGP Update Is Advertised via EBGP, the NEXT_HOP Attribute Is the
IP Address of the External Peer

Figure 2-16 If a BGP Update Is Advertised via IBGP and the Advertised Destination Is
in the Same AS, the NEXT_HOP Attribute Is the IP Address of the Originating Router

The advertising router and the receiving router do not share a common data link, but the
IBGP TCP connection is passed through an IGP-speaking router. The receiving router
must perform a recursive route lookup (recursive lookups are discussed in Routing
TCP/IP, Volume I) to send a packet to the advertised destination. For example, sup-
pose the router at 172.16.101.2 in Figure 2-16 must forward a packet with a destination
address of 172.16.5.30. It looks up the destination and matches the prefix 172.16.5.0/24;
Operation of BGP 99

that route indicates a next hop of 172.16.83.2. Because that IP address does not belong
to one of the routers directly connected subnets, the router must then look up the route
to 172.16.83.2. That route, learned via the IGP, indicates a next hop of 172.16.101.1.
The packet can now be forwarded. This example is important for understanding the
dependency of IBGP on the IGP.

Figure 2-17 illustrates the third rule. Here, a route has been learned via EBGP and is then
passed to an internal peer. Because the destination is in a different AS, the NEXT_HOP
of the route passed across the IBGP connection is the interface of the external router
from which the route was learned.

Figure 2-17 If a BGP Update Is Advertised via IBGP and the Advertised Destination Is
in a Different AS, the NEXT_HOP Attribute Is the IP Address of the External Peer from
Which the Route Was Learned

In Figure 2-17, the IBGP peer must perform a recursive route lookup to forward a
packet to 207.135.64.0/19. However, a potential problem exists. The subnet 192.168.5.0,
to which the next-hop address belongs, is not part of AS509. Unless the AS border
router advertises it into AS509, the IGPand hence the internal peerswill not know
about this subnet. And if the subnet is not in the routing tables, the next-hop address for
207.135.64.0/19 is unreachable, and packets for that destination are dropped. Actually,
although the route to 207.135.64.0/19 is installed in the internal peers BGP table, it is
not installed in the routing table because the next-hop address is invalid for that router.

One solution to the problem is, of course, to ensure that the external subnet linking the
two autonomous systems is known to the internal routers. Although you could use static
100 Chapter 2: Introduction to BGP

routes, the practical method is to run the IGP in passive mode on the external interfaces.
In some cases, this might be undesirable. An alternative solutionand the solution that
is considered best practiceis to use a configuration option called next-hop-self to
cause the AS border router in AS509 to set its own IP address in the NEXT_HOP attri-
bute, in place of the IP address of the external peer. The internal peers would then have
a next-hop router address of 172.16.83.2, which is known to the IGP. The configuration
of next-hop-self is covered in Chapter 3.

Weight
Weight3 is a Cisco-specific BGP path attribute that applies only to routes within an indi-
vidual router. It is not communicated to other routers. The weight is a number between
0 and 65,535 that can be assigned to a route; the higher the weight, the more preferable
the route. When choosing a best path, the BGP decision process considers weight above
all other route characteristics except specificity. By default, all routes learned from a
peer have a weight of 0, and all routes generated by the local router have a weight
of 32,768.

Weights can be set for individual routes, or for routes learned from a specific neighbor.
For example, peer A and peer B might be advertising the same routes to a BGP speaker.
By assigning a higher weight to the routes received from peer A, the BGP speaker pre-
fers the routes through that peer. This preference is entirely local to the single router;
weights are not included in the BGP updates or in any other way communicated to the
BGP speakers peers. Accordingly, weights are valuable for influencing the routing deci-
sions of a single router without changing the routing decisions of any other router.

Weights are useful when you want one BGP router in an AS to treat some prefixes dif-
ferently than the way other routers in the AS treat the same prefixes. But this can also
be dangerous. Because weight affects only the BGP decision process in a single router,
this tells you to carefully consider the implications of using it. Misuse can easily lead to
unexpected or inconsistent routing results such as loops.

BGP Decision Process


The BGP Routing Information Base (RIB) consists of three parts:

Adj-RIBs-In: Stores unprocessed routing information that has been learned from
BGP Updates received from peers. The routes contained in Adj-RIBs-In are consid-
ered feasible routes.

Loc-RIB: Contains the routes that the BGP speaker has selected by applying the
decision process to the routes contained in Adj-RIBs-In. These routes populate the
routing table (RIB) along with routes discovered by other routing protocols.

3
Older IOS documentation calls this parameter Administrative Weight, but more recent documen-
tation has moved away from that term in favor of just Weight. This is probably to avoid confusing
it with Administrative Distance, an entirely different and protocol-independent parameter.
Operation of BGP 101

Adj-RIBs-Out: Contains the routes that the BGP speaker advertises to its peers in
BGP Updates. The outgoing routing policies determine what routes are placed in
Adj-RIBs-Out.

These three parts of the RIB may be three distinct databases, or the RIB may be a single
database with pointers to distinguish the three parts.

The BGP decision process selects routes by applying incoming routing policies to the
routes in the Adj-RIBs-In and by entering the selected or modified routes into the Loc-
RIB. The decision process entails three phases:

Phase 1 calculates the degree of preference for each feasible route in the Adj-
RIBs-In. It is invoked whenever a router receives a BGP Update from a peer in a
neighboring AS containing a new route, a changed route, or a withdrawn route. Each
route is considered separately, and a nonnegative integer is derived that indicates
the degree of preference for that route.

Phase 2 chooses the best route out of all the available routes to a particular destina-
tion and installs the route in the Loc-RIB. It is invoked only after phase 1 has been
completed. Loops are also detected in Phase 2 by examining the AS_PATH. Any
routes with the local AS number in the AS_PATH are dropped.

Phase 3 adds the appropriate routes to the Adj-RIBs-Out for advertisement to peers.
It is invoked after the Loc-RIB has changed, and only after phase 2 has been com-
pleted. Route aggregation, if it is to be performed, happens during this phase.

Barring a routing policy that dictates otherwise, phase 2 always selects the most specific
route to a particular destination out of all feasible routes to that destination. It is impor-
tant to note that if the address specified by the routes NEXT_HOP attribute is unreach-
able, the route is not selected. This has particular ramifications for IBGP: A route cannot
be selected if it is not synchronized with the IGP (refer to Chapter 3).

You should have an appreciation by now of the multiple attributes that can be assigned
to a BGP route to enforce routing policy within a single router, to internal peers, to adja-
cent autonomous systems, and beyond. A sequential set of rules is needed for consider-
ing these attributes as tie-breakers when a router must select among multiple, equally
specific routes to the same destination. This set of rules is the BGP decision process. The
decision process used by IOS is as follows:4

1. Prefer the route with the highest weight. This is an IOS-specific function, as
described in the previous section.

2. If the weights are equal, prefer the route with the highest LOCAL_PREF value.

4
The BGP decision processes can vary slightly among different vendors, so if you run a multiven-
dor BGP network, you must understand the sequence of decision steps each of your vendors
uses. Because the decision process is refined as newer features are added, it can even vary slightly
between older and newer versions of IOS.
102 Chapter 2: Introduction to BGP

3. If the LOCAL_PREF values are the same, prefer the route that was originated
locally on the router and injected into BGP with the network or aggregate state-
ment or through redistribution. That is, prefer a route that was learned from an
IGP or from a direct connection on the same router. Note that a route injected
into BGP via the network statement or redistribution is preferred over a local
aggregate injected by the aggregate-address statement. All these means of inject-
ing prefixes are covered in Chapter 4.

4. If the LOCAL_PREF is the same and no route was locally originated, prefer the
route with the shortest AS_PATH.

5. If the AS_PATH length is the same, prefer the path with the lowest ORIGIN code.
IGP is lower than EGP, which is lower than Incomplete.

6. If the ORIGIN codes are the same, prefer the route with the lowest MED
(MULTI_EXIT_DISC) value. By default, this comparison is done only if the AS
number is the same for all the routes being considered.5

7. If the MED is the same, prefer EBGP routes over Confederation EBGP routes, and
prefer Confederation EBGP routes over IBGP routes.

8. If the routes are still equal, prefer the route with the shortest path to the BGP
NEXT_HOP. This is the route with the lowest IGP metric to the next-hop address.

9. If the routes are still equal, they are from the same neighboring AS, and BGP
multipath is enabled with the maximum-paths statement; install all the equal-cost
routes in the Loc-RIB.

10. If the routes are still equal and are external, prefer the path that was received first.
This helps reduce flapping by allowing a newer route to take precedence over an
older one. If the bgp best path compare-routerid statement is enabled, this step is
skipped.

11. If multipath is not enabled, prefer the route with the lowest BGP router ID,
or if route reflection (Chapter 5) is used, prefer the route with the lowest
ORIGINATOR_ID.

12. If the routes are still equal and route reflection is used, prefer the route with the
shortest CLUSTER_LIST.

13. If the routes are still equal, prefer the route advertised from the neighbor with the
lowest IP address.

5
IOS offers two alternatives to the default MED behavior, bgp deterministic-med and bgp always-
compare-med; these alternatives are explained in Chapter 4.
Operation of BGP 103

Note Knowing the BGP decision process and the correct order of each step is essential
to working with BGP. Its worth memorizing not only for that reason, but also because
you can count on being questioned on it on exams such as CCIE and in job technical
interviews. I usually ask a few questions about it when I conduct interviews, and Ive had
to answer questions about it (sadly, not always correctly) when Ive been the interviewee.

BGP Message Formats


BGP messages are carried within TCP segments using TCP port 179. The maximum mes-
sage size is 4096 octets, and the minimum size is 19 octets. All BGP messages have a
common header (Figure 2-18). Depending on the message type, a data portion might or
might not follow the header.

32 Bits

32 Bits

Figure 2-18 BGP Message Header

Marker is a 16-octet field that was intended to detect loss of synchronization between
BGP peers and to authenticate messages when authentication is supported. However,
its use is deprecated in RFC 4271, and modern BGP implementations set the field to all
ones in all cases; it continues to exist in the message header for backward compatibility
with older implementations.

Length is a 2-octet field that indicates the total length of the message, including the
header, in octets.

Type is a 1-octet field specifying the message type. Table 2-3 indicates the possible type
codes.
104 Chapter 2: Introduction to BGP

Table 2-3 BGP Type Codes


Code Type
1 Open
2 Update
3 Notification
4 Keepalive
5 Route Refresh (covered in Chapter 4)

Open Message
The Open message, whose format is shown in Figure 2-19, is the first message sent after
a TCP connection has been established. If a received Open message is acceptable, a
Keepalive message is sent to confirm the Open. After the Open has been confirmed, the
BGP connection is in the Established state and Update, Keepalive, and Notification mes-
sages can be sent.

32 Bits

8 8 8 8

Version

My Autonomous System Hold Time

BGP Identifier

Opt Param Len


Optional Parameters

Figure 2-19 BGP Open Message Format

The minimum length of the Open message including the BGP message header is
29 octets.

The BGP Open message contains the following fields:

Version: A 1-octet field specifying the BGP version running on the originator.

My Autonomous System: A 2-octet field specifying the AS number of the


originator.
Operation of BGP 105

Hold Time: A 2-octet number indicating the number of seconds the sender pro-
poses for the hold time. A receiver compares the value of the Hold Time field and
the value of its configured hold time and accepts the smaller value or rejects the
connection. The hold time must be either 0 or at least 3 seconds.

BGP Identifier: The BGP router ID of the originator. Unless a router ID is specified
in the BGP configuration, IOS sets its router ID as either the highest IP address of
any of its loopback interfaces, or if no loopback interface is configured, the highest
IP address of any of its physical interfaces.

Optional Parameters Length: A 1-octet field indicating the total length of the fol-
lowing Optional Parameters field, in octets. If the value of this field is zero, no
Optional Parameters field is included in the message.

Optional Parameters: A variable-length field containing a list of optional param-


eters. Each parameter is specified by a 1-octet type field, a 1-octet length field, and
a variable-length field containing the parameter value.

Update Message
The Update message, whose format is shown in Figure 2-20, advertises a single feasible
route to a peer, or to withdraw multiple unfeasible routes, or both.

Withdrawn Routes Length


(2 Octets)

Withdrawn Routes
(Variable)

Total Path Attribute Length


(2 Octets)

Path Attributes
(Variable)

Network Layer Reachability Information


(Variable)

Figure 2-20 BGP Update Message Format


106 Chapter 2: Introduction to BGP

The BGP Update message contains the following fields:

Withdrawn Routes Length6: A 2-octet field indicating the total length of the fol-
lowing Withdrawn Routes field, in octets. A value of zero indicates that no routes
are being withdrawn and that no Withdrawn Routes field is included in the message.

Withdrawn Routes: A variable-length field containing a list of routes to be with-


drawn from service. Each route in the list is described with a (Length, Prefix) tuple
in which the Length is the length of the prefix and the Prefix is the IP address prefix
of the withdrawn route. If the Length part of the tuple is zero, the Prefix matches all
routes.

Total Path Attribute Length: A 2-octet field indicating the total length of the fol-
lowing Path Attribute field, in octets. A value of zero indicates that attributes and
NLRI are not included in this message.

Path Attributes: A variable-length field listing the attributes associated with


the NLRI in the following field. Each path attribute is a variable-length triple of
(Attribute Type, Attribute Length, Attribute Value). The Attribute Type part of the
triple is a 2octet field consisting of four flag bits, four unused bits, and an Attribute
Type code (see Figure 2-21). Table 2-4 shows the most common Attribute Type
codes and the possible Attribute Values for each Attribute Type.

O T P E U U U U Attribute Type Code

Flag Bits
O: Optional Bit
0 = Well-Known
1 = Optional
T: Transitive Bit
0 = Non-Transitive
1 = Transitive
P: Partial Bit
0 = Optional transitive attribute is complete.
1 = Optional transitive attribute is partial.
E: Extended Length Bit
0 = Attribute length is one octet.
1 = Attribute length is two octets.
U: Unused

Figure 2-21 Attribute Type Part of the Path Attributes Field in the Update Message

6
This field was called Unfeasible Routes Length in RFC 1771 and before. Although renamed
Withdrawn Routes Length in RFC 4271, there is no difference in function.
Operation of BGP 107

Network Layer Reachability Information: A variable-length field containing a list


of (Length, Prefix) tuples. The Length indicates the length in bits of the following
prefix, and the Prefix is the IP address prefix of the NLRI. A Length value of zero
indicates a prefix that matches all IP addresses.

Table 2-4 Attribute Types and Associated Attribute Values7


Attribute Attribute
Type Value
Code Attribute Type Code Attribute Value
1 ORIGIN 0 IGP
1 EGP
2 Incomplete

2 AS_PATH 1 AS_SET
2 AS_SEQUENCE
3 AS_CONFED_SET
4 AS_CONFED_
SEQUENCE
3 NEXT_HOP 0 Next-hop IP address
4 MULTI_EXIT_DISC 0 4-octet MED
5 LOCAL_PREF 0 4-octet LOCAL_PREF
6 ATOMIC_AGGREGATE 0 None
7 AGGREGATOR 0 AS number and IP address
of aggregator
8 COMMUNITY 0 4-octet community
identifier
9 ORIGINATOR_ID 0 4-octet router ID of
originator
10 CLUSTER_LIST 0 Variable-length list of
cluster IDs
14 MP_REACH_NLRI 0 Variable-length
Multiprotocol BGP NLRI
15 MP_UNREACH_NLRI 0 Variable-length
Multiprotocol BGP NLRI

7
Attributes are often added to BGP, so this list may not be complete.
108 Chapter 2: Introduction to BGP

Attribute Attribute
Type Value
Code Attribute Type Code Attribute Value
16 EXTENDED 0 16-octet extended
COMMUNITIES community identifier
17 AS4_PATH 0 AS path with 4-octet AS
numbers
18 AS4_AGGREGATOR 0 4-octet AS number and IP
address of aggregator

Keepalive Message
Keepalive messages are exchanged on a period one-third the hold time but not less than
1 second. If the negotiated hold time is 0, Keepalives are not sent.

The Keepalive message consists of only the 19-octet BGP message header, with no addi-
tional data.

Notification Message
Notification messages, whose format is shown in Figure 2-22, are sent when an error
condition is detected. The BGP connection is closed immediately after the message
is sent.

32 bits
8 8 8 8

Error Code Error Subcode

Data

Figure 2-22 BGP Notification Message Format

The BGP Notification message contains the following fields:

Error Code: A 1-octet field indicating the type of error.

Error Subcode: A 1-octet field providing more-specific information about the error.
Table 2-5 shows the possible error codes and associated error subcodes.

Data: A variable-length field used to diagnose the reason for the error. The contents
of the Data field depend on the error code and subcode.
Operation of BGP 109

Table 2-5 BGP Notification Message Error Codes and Error Subcodes
Error Error
Code Error Subcode Subcode Detail
1 Message Header Error 1 Connection not synchro-
nized
2 Bad message length
3 Bad message type
2 Open Message Error 1 Unsupported version number
2 Bad peer AS
3 Bad BGP identifier
4 Unsupported optional
parameter
5 Authentication failure
(deprecated in RFC 4271)
6 Unacceptable hold time
3 Update Message Error 1 Malformed attribute list
2 Unrecognized well-known
attribute
3 Missing well-known attribute
4 Attribute flags error
5 Attribute length error
6 Invalid ORIGIN attribute
7 AS routing loop (deprecated
in RFC 4271)
8 Invalid NEXT_HOP attribute
9 Optional attribute error
10 Invalid network field
11 Malformed AS_PATH
4 Hold Timer Expired 0
5 Finite State Machine Error 0
6 Cease 0
110 Chapter 2: Introduction to BGP

Configuring and Troubleshooting BGP Peering


Many newcomers to BGP approach the protocol with trepidation. The source of this
sentiment is that BGP implementations are rarer than IGP implementations. Outside of
ISPs, most network administrators deal with BGP far less than with IGPs, if at all. And
even when BGP is used, the configurations in small ISPs and non-ISP subscribers are usu-
ally quite basic. Because most networking professionals lack in-depth experience with
the protocol, it is often viewed as intimidating.

BGP configurations can unarguably be complex. But most of the complexity around
BGP involves policy. BGP peering configuration, although still a little more involved
than most IGP configurations, is not at all difficult. This section takes you step-by-step
through the configuration of BGP peering, from the most basic elements to more refined
setups.

Case Study: EBGP Peering


A BGP session between routers is configured in two steps:

Step 1. Establish the BGP process and specify the local AS number with router bgp.

Step 2. Specify a neighbor and the neighbors AS number with neighbor remote-as.

Figure 2-23 shows two routers in different autonomous systems, and Example 2-6 shows
their EBGP configurations.

Example 2-6 EBGP Configurations for the Routers in Figure 2-23

Taos
router bgp 200
neighbor 192.168.1.226 remote-as 100
______________________________________
Vail
router bgp 100
neighbor 192.168.1.225 remote-as 200

The BGP state changes at Vail can be seen, in Example 2-7, using debug ip bgp.8 In the
first few lines, Vail is attempting to open a connection to Taos (192.168.1.225); BGP is
not yet enabled at Taos, so the attempts fail and Vail shows Taos in Active state. Then as
BGP comes up at Taos, a TCP connection is accepted; its state transitions from Active to
OpenSent as Vail sends an Open message to begin the BGP session. The two routers then

8
Timestamps are turned off for the debug examples throughout this book unless time deltas are
important to the example to simplify the output. However, in production networks timestamps
are an important part of debug or any other logging function and should be enabled.
Configuring and Troubleshooting BGP Peering 111

negotiate capabilities. (The multiprotocol and route refresh capabilities negotiated in this
example are discussed in Chapters 6 and 4, respectively.) With capabilities agreed upon,
Vail changes Taos state from OpenSent to OpenConfirm and then to Established.

AS100

Vail

192.168.1.226/30
EBGP 192.168.1.225/30

Taos

AS200

Figure 2-23 An EBGP Session Is Established Between Taos and Vail

Example 2-7 debug Is Used to Observe Vails BGP State Changes for Taos as the BGP
Session Comes Up

Vail#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
Vail#
BGP: 192.168.1.225 open active, local address 192.168.1.226
BGP: 192.168.1.225 open failed: Connection refused by remote host, open active d
elayed 34034ms (35000ms max, 28% jitter)
BGP: 192.168.1.225 open active, local address 192.168.1.226
BGP: 192.168.1.225 went from Active to OpenSent
BGP: 192.168.1.225 sending OPEN, version 4, my as: 100, holdtime 180 seconds
BGP: 192.168.1.225 send message type 1, length (incl. header) 45
BGP: 192.168.1.225 rcv message type 1, length (excl. header) 26
BGP: 192.168.1.225 rcv OPEN, version 4, holdtime 180 seconds
BGP: 192.168.1.225 rcv OPEN w/ OPTION parameter len: 16
BGP: 192.168.1.225 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 192.168.1.225 OPEN has CAPABILITY code: 1, length 4
BGP: 192.168.1.225 OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 192.168.1.225 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 192.168.1.225 OPEN has CAPABILITY code: 128, length 0
BGP: 192.168.1.225 OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 192.168.1.225 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 192.168.1.225 OPEN has CAPABILITY code: 2, length 0
112 Chapter 2: Introduction to BGP

BGP: 192.168.1.225 OPEN has ROUTE-REFRESH capability(new) for all address-families


BGP: 192.168.1.225 rcvd OPEN w/ remote AS 200
BGP: 192.168.1.225 went from OpenSent to OpenConfirm
BGP: 192.168.1.225 went from OpenConfirm to Established

When you create a neighbor with the neighbor remote-as statement, an entry is cre-
ated in the BGP neighbor database for the specified neighbor. The command show ip
bgp neighbor9 displays either the entire BGP neighbor database or a specified neighbor
entry. In Example 2-8, the information Vail has recorded about Taos displays. The infor-
mation in this display is particularly useful for troubleshooting.
The first line of output in Example 2-8 shows the address of Taos (192.168.1.225), its AS
number (200), and the type of BGP connection to the router (external). The second line
displays the BGP version used between Vail and Taos, and Taos router ID. The third line
begins by showing the state of the BGP finite state machine and then the time since the
present peer connection was established. In this example, Taos has been peered continu-
ously for 23 minutes and 25 seconds.

Also of interest are the details of the underlying TCP connection, the second set of high-
lighted lines in Example 2-8. They show that the TCP connection state is Established,
that Vail is originating BGP messages from TCP port 13828, and that the destination
port at Taos is 179. The source port can be especially important to note when you cap-
ture packets on a link carrying more than one BGP session.

Example 2-8 show ip bgp neighbors Command Output Contains Essential Details
About the Peer Connection to a Neighbor

Vail#show ip bgp neighbors

BGP neighbor is 192.168.1.225, remote AS 200, external link


BGP version 4, remote router ID 192.168.1.225
BGP state = Established, up for 00:23:25
Last read 00:00:25, last write 00:00:25, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0

9
You can also use show bgp neighbors to display the same information; although, it is not docu-
mented in the IOS manuals and might not work with all IOS releases. The output of the show
ip bgp neighbors command also varies depending on the IOS release you use.
Configuring and Troubleshooting BGP Peering 113

OutQ depth is 0
Sent Rcvd
Opens: 5 5
Notifications: 0 0
Updates: 0 0
Keepalives: 51 52
Route Refresh: 0 0
Total: 56 57
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast


BGP table version 1, neighbor version 1/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 5; dropped 4


Last reset 00:26:11, due to Peer closed the session
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 192.168.1.226, Local port: 13828
Foreign host: 192.168.1.225, Foreign port: 179
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0xA9F664):


Timer Starts Wakeups Next
Retrans 26 0 0x0
TimeWait 0 0 0x0
114 Chapter 2: Introduction to BGP

AckHold 25 2 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0

iss: 842497347 snduna: 842497887 sndnxt: 842497887 sndwnd: 15845


irs: 2329656545 rcvnxt: 2329657085 rcvwnd: 15845 delrcvwnd: 539

SRTT: 435 ms, RTTO: 1159 ms, RTV: 724 ms, KRTT: 0 ms
minRTT: 212 ms, maxRTT: 992 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):


Rcvd: 50 (out of order: 0), with data: 25, total data bytes: 539
Sent: 31 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0)
, with data: 26, total data bytes: 539
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
Vail#

Case Study: EBGP Peering over IPv6


The TCP connection between BGP routers can run over either IPv4 or IPv6. Keep
in mind that the endpoint addresses of the TCP session have nothing to do with the
address families supported by the BGP session running over the TCP connection or the
types of prefixes exchanged by BGP. BGP peers can exchange both IPv4 and IPv6 pre-
fixes regardless of whether the TCP session is between IPv4 addresses or IPv6 addresses.

Figure 2-24 shows the same two routers of Figure 2-23, except that in this case, the
interfaces have IPv6 addresses. Example 2-9 shows the EBGP configurations for these
two routers, and you can readily see that they are the same as the configurations in the
previous case study except that the neighbor addresses are IPv6.
Configuring and Troubleshooting BGP Peering 115

AS100

Vail

2001:db8:0:224::2/64

EBGP

2001:db8:0:224::1/64

Taos

AS200

Figure 2-24 An EBGP Session Is Established Between Taos and Vail, This Time with
IPv6 Endpoints

Example 2-9 EBGP Configurations for the Routers in Figure 2-24

Taos
router bgp 200
neighbor 2001:db8:0:224::1 remote-as 100
__________________________________________
Vail
router bgp 100
neighbor 2001:db8:0:224::2 remote-as 200

Example 2-10 shows another output from show ip bgp neighbors at Vail, after the con-
figurations of Example 2-9 have been implemented. The neighbor information looks
almost identical to that of Example 2-8 (the same fields are highlighted) except the
addresses are now IPv6 addresses. Notice, however, that Vails BGP router ID remains
192.168.1.225; the BGP router ID is a 32-bit number so cannot be taken from an IPv6
address.
116 Chapter 2: Introduction to BGP

Example 2-10 The Neighbor Database Looks Almost Identical to the One in Example
2-8, Except the Neighbor Addresses Are IPv6

Vail#show ip bgp neighbors

BGP neighbor is 2001:DB8:0:224::1, remote AS 200, external link


BGP version 4, remote router ID 192.168.1.225
BGP state = Established, up for 00:00:18
Last read 00:00:18, last write 00:00:18, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 6 6
Notifications: 0 0
Updates: 0 0
Keepalives: 240 280
Route Refresh: 0 0
Total: 246 286
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast


BGP table version 1, neighbor version 1/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Configuring and Troubleshooting BGP Peering 117

Connections established 6; dropped 5


Last reset 00:00:39, due to Peer closed the session
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 2001:DB8:0:224::2, Local port: 179
Foreign host: 2001:DB8:0:224::1, Foreign port: 59051
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x285A1B0):


Timer Starts Wakeups Next
Retrans 3 0 0x0
TimeWait 0 0 0x0
AckHold 2 0 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0

iss: 1579724289 snduna: 1579724392 sndnxt: 1579724392 sndwnd: 16282


irs: 4090406841 rcvnxt: 4090406944 rcvwnd: 16282 delrcvwnd: 102

SRTT: 253 ms, RTTO: 2915 ms, RTV: 2662 ms, KRTT: 0 ms
minRTT: 40 ms, maxRTT: 1484 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6

Datagrams (max data segment is 1440 bytes):


Rcvd: 6 (out of order: 0), with data: 3, total data bytes: 102
Sent: 3 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0),
with data: 3, total data bytes: 230
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0

Also highlighted in this neighbor data are the fields showing that the session supports
only IPv4 unicast prefix advertisements; the routers BGP sessions have not been config-
ured to carry any other address families (as demonstrated in Chapter 6). So this EBGP
session, although running between IPv6 endpoints, can carry only IPv4 prefixesthe
default address family.
118 Chapter 2: Introduction to BGP

There is one small difference between the TCP sessions in Examples 2-8 and 2-10; it
has nothing to do with IPv4 or IPv6 but is nevertheless worth noting. In Example 2-8,
the local (Vails) TCP port is ephemeral whereas the remote (Taos) TCP port is 179.
Example 2-10 is just the opposite: Vails local TCP port is 179 and the remote TCP port
at Taos is ephemeral. What this indicates is that in the first case, Vail initiated the TCP
connection (the TCP initiation is always directed at port 179 for BGP), whereas in the
second case Taos initiated the TCP connection. This is consistent with the historical facts
of the connections: In configuring the first example, Vails BGP was configured before
Taos (and you can observe in Example 2-7 Vail trying to connect to Taos before Taos
is ready); in the second example, Taos BGP was configured before Vail. Noticing small
details such as this one can be useful when you troubleshoot or just try to fully under-
stand a particular BGP session. Such details can also be important if you run an access list
on a BGP interface. The ACL might be configured to permit TCP port 179, but depend-
ing on the direction of the session might inadvertently block the ephemeral port.

Case Study: IBGP Peering


Figure 2-25 shows another AS, AS400, connected to AS100. (The interfaces connect-
ing Vail and Taos are again IPv4, for simplicitys sake.) Two more routers, Aspen and
Telluride, are added within AS100 and Telluride connects to Alta, in AS400, via EBGP.

AS100

Aspen
192.168.1.222/30 192.168.1.198/30

IBGP IBGP

192.168.1.197/30
192.168.1.221/30
Vail Telluride
IBGP
192.168.1.226/30 192.168.1.206/30

EBGP EBGP

192.168.1.225/30 192.168.1.205/30

Taos Alta

AS200 AS400

Figure 2-25 Two Routers Are Added to AS100 and Are Peering via IBGP So That
AS200 and AS400 Can Communicate Across AS100
Configuring and Troubleshooting BGP Peering 119

Each of the three routers in AS100 has an IBGP peering session with the other two rout-
ers in the same AS. Recall from the section External and Internal BGP in Chapter 1 that
a full IBGP mesha direct IBGP connection between every BGP router within the same
ASis required for two reasons:

The AS_PATH attribute is meaningless within a single AS, so IBGP has no loop
avoidance mechanism. A full IBGP mesh means every BGP router directly adver-
tises its prefixes to every other BGP router in the same AS, removing any need for
a router to advertise prefixes learned from one internal peer to another internal
peer, which could lead to routing loops. A default BGP rule reinforces the full mesh
requirement: BGP cannot advertise routes learned from an internal neighbor to
another internal neighbor.10

Every BGP router along a forwarding path must know the BGP routes used at the
routers with external peers so that packets forwarded to a purely internal BGP
router on their way to an external next hop are not dropped by the internal router.
For instance, in Figure 2-25 a packet traveling from AS400 to AS200 would be
received by Telluride; Tellurides BGP route to the AS200 destination would have
a next-hop address of 192.168.1.225 (Taos external interface). Telluride would
forward the packet to Aspen to get to that next hop, assuming Vail is advertising
the subnet internally. But if Aspen does not also know the BGP route to the AS200
destination, it drops the packet. Therefore, in addition to the IBGP session between
Vail and Telluride, each of those externally connected routers must tell Aspen
about its external routes.

At a basic level, IBGP peering is configured exactly the same as EBGP peering; it is
IBGP rather than EBGP only in that the AS number referenced by neighbor remote-as
is the same as the local AS number referenced by router bgp. Example 2-11 shows the
configurations for Vail, Aspen, and Telluride. The router bgp statements in all three con-
figurations show that the routers are all in AS100; you can then easily see what neighbor
remote-as statements in each configuration point to AS100, and from that you know
that those sessions are IBGP.

Example 2-11 Configurations for the Routers of AS100 in Figure 2-25

Vail
router bgp 100
neighbor 192.168.1.197 remote-as 100
neighbor 192.168.1.222 remote-as 100
neighbor 192.168.1.225 remote-as 200
______________________________________

10
This rule is modified when route reflectors, examined in Chapter 5, are implemented.
120 Chapter 2: Introduction to BGP

Aspen
router bgp 100
neighbor 192.168.1.197 remote-as 100
neighbor 192.168.1.221 remote-as 100
______________________________________
Telluride
router bgp 100
neighbor 192.168.1.198 remote-as 100
neighbor 192.168.1.205 remote-as 400
neighbor 192.168.1.221 remote-as 100

Example 2-12 introduces another command you can use regularly when maintaining and
troubleshooting BGP networks: show ip bgp summary.11 This command gives you an
overview of the BGP peerings configured on the router and the state of each of those
peerings. The output from this command first shows you the local routers BGP router
ID and AS number, and the current version of the BGP table. (The table version is incre-
mented when policies or other activities change the contents of the table.) After this
information a table lists the following for each configured neighbor:

The address configured in the neighbor remote-as statement

The BGP version used for that neighbor

The neighbors AS number

The number of BGP messages received from and sent to the neighbor

The last version of the local BGP table sent to the neighbor

The number of messages in queue from and to the neighbor

The length of time the BGP session has been Established with the neighbor, or the
status of the neighbor if not in Established state

The state of the neighbor if not Established; or if the state is Established, the num-
ber of prefixes received from the neighbor

11
You can also use show bgp summary to display the same information; although, it is not docu-
mented in the IOS manuals and might not work with all IOS releases. The output of the show ip
bgp summary command also varies depending on the IOS release you use.
Configuring and Troubleshooting BGP Peering 121

Example 2-12 Although the Other BGP Sessions Are Established, the IBGP Peering
Between Vail and Telluride Is Not; Its State Is Active

! Vail
Vail#show ip bgp summary

BGP router identifier 192.168.1.226, local AS number 100


BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.1.197 4 100 0 0 0 0 0 never Active
192.168.1.222 4 100 29 22 1 0 0 00:18:59 0
192.168.1.225 4 200 43 43 1 0 0 00:00:12 0
_________________________________________________________________________________
! Aspen
Aspen#show ip bgp summary
BGP router identifier 192.168.1.222, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.197 4 100 12 20 1 0 0 00:15:43 0
192.168.1.221 4 100 23 30 1 0 0 00:26:14 0
_________________________________________________________________________________
! Telluride
Telluride#show ip bgp summary
BGP router identifier 192.168.1.206, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.1.198 4 100 21 13 1 0 0 00:10:06 0
192.168.1.205 4 400 4 5 1 0 0 00:01:06 0
192.168.1.221 4 100 0 0 0 0 0 never Active

The three displays in Example 2-12 show that all the EBGP and IBGP sessions are
Established except for the IBGP session between Vail (192.168.1.221) and Telluride
(192.168.1.197); Vail and Telluride each show the other in Active state. A quick look at
Vails routing table (Example 2-13) reveals the problem: Vail has no route to Tellurides
interface 192.168.1.197. Although its routing table is not shown here, Telluride does not
have a route to Vails interface 192.168.1.221 either.
122 Chapter 2: Introduction to BGP

Example 2-13 Vail Does Not Have a Route to 192.168.1.197 and Cannot Establish an
IBGP Session with Telluride

Vail#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP


D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

192.168.1.0/30 is subnetted, 2 subnets


C 192.168.1.224 is directly connected, Serial1/0
C 192.168.1.220 is directly connected, FastEthernet0/0
Vail#

This simple example demonstrates a problem commonly encountered when working


with IBGP. Unlike IGPs, IBGP sessions often span multiple router hops; a router cannot
establish an IBGP session unless it knows how to reach its peer. Therefore, one of the
first steps in troubleshooting an IBGP session that stays in Active state (listening for a
configured neighbor) is to look in the routing tables of both neighbors and see if they
know how to find each other.

The problem with the IBGP session between Vail and Telluride is resolved by config-
uring an IGP within AS100in this example, OSPF is used, but anything that gives
the neighbors the reachability information they need in their routing tables can work.
Example 2-14 shows that Vails routing table now has a route to subnet 192.168.1.196
and to the neighbor address 192.168.1.197 configured for Telluride. Example 2-15
shows that with the three routers in AS100 now exchanging internal reachability infor-
mation via OSPF, all IBGP sessions are Established.

Example 2-14 After an IGP (OSPF in This Case) Is Configured, Vail Has a Route to
Telluride

Vail#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP


D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
Configuring and Troubleshooting BGP Peering 123

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

192.168.1.0/30 is subnetted, 3 subnets


C 192.168.1.224 is directly connected, Serial1/0
O 192.168.1.196 [110/2] via 192.168.1.222, 00:00:07, FastEthernet0/0
C 192.168.1.220 is directly connected, FastEthernet0/0
Vail#

Example 2-15 Vail and Telluride Now Know How to Find Each Other and Their IBGP
Session Is Established

Vail#show ip bgp summary


BGP router identifier 192.168.1.226, local AS number 100

BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.1.197 4 100 4 4 1 0 0 00:00:05 0
192.168.1.222 4 100 93 56 1 0 0 00:00:56 0
192.168.1.225 4 200 131 142 1 0 0 00:00:05 0
_______________________________________________________________________________
Aspen#show ip bgp summary
BGP router identifier 192.168.1.222, local AS number 100

BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.1.197 4 100 47 81 1 0 0 00:02:53 0
192.168.1.221 4 100 57 95 1 0 0 00:03:31 0
_______________________________________________________________________________
Telluride#show ip bgp summary
BGP router identifier 192.168.1.206, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.1.198 4 100 82 47 1 0 0 00:02:09 0
192.168.1.205 4 400 84 73 1 0 0 00:01:03 0
192.168.1.221 4 100 5 5 1 0 0 00:01:37 0
124 Chapter 2: Introduction to BGP

The IBGP configurations are now sufficient for the topology in Figure 2-25; however,
the topology has a problem: If the link between Telluride and Aspen or the link between
Aspen and Vail fails, AS100 and AS400 can no longer communicate. AS100 needs a
more resilient topology both for packet forwarding and for BGP information exchange.
A link added between Telluride and Vail, as shown in Figure 2-26, gives AS100 the
redundancy to survive the failure of a single internal link.

AS100

Aspen
192.168.1.222/30 192.168.1.198/30

IBGP IBGP

192.168.1.221/30 192.168.1.197/30
192.168.1.193/30 192.168.1.194/30
Vail Telluride
192.168.1.226/30 IBGP 192.168.1.206/30

EBGP EBGP

192.168.1.225/30 192.168.1.205/30

Taos Alta

AS200 AS400

Figure 2-26 A Link Between Vail and Telluride Gives AS100 Some Redundancy

Although the added link does provide some redundancy, it raises a question about the
IBGP configuration for AS100. If a link fails, you want the IBGP sessions that were
using the link to be rerouted across the alternative path. With the IBGP sessions run-
ning between physical interfaces, you cannot be sure that this will happen. One remedy
might be to configure redundant IBGP sessions. For example, Vail and Telluride might
be configured for peering both between 192.168.1.193 and 192.168.1.194 and between
192.168.1.221 and 192.168.1.197. However, as the topology of an AS grows in com-
plexity, this approach (configuring all routers with redundant IBGP connections to all
physical interfaces) quickly escalates to undesirably long BGP configurations and to an
undesirable number of IBGP sessions.

A better approach is to peer not between physical interfaces but between loopback
interfaces, as shown in Figure 2-27. Note that the physical links have been removed from
the drawing; when you peer between loopback addresses, you remove physical interface
dependencies from the IBGP topology. Only a single IBGP session between each router
Configuring and Troubleshooting BGP Peering 125

within the AS is required, and that session is routed over the best available path. Should
a link on that path fail, the session is reroutedin most cases rerouted fast enough that
the BGP session does not failover the next best path.

AS100

Aspen Loopback0
192.168.100.2/32

IBGP IBGP
Loopback0 Loopback0
192.168.100.1/32 192.168.100.3/32

Vail Telluride
IBGP
192.168.1.226/30 192.168.1.206/30

EBGP EBGP

192.168.1.225/30 192.168.1.205/30

Taos Alta

AS200 AS400

Figure 2-27 Using Loopback Interfaces as the IBGP Endpoints Eliminates Any
Dependencies on Physical Interfaces

Configuring IBGP peering between loopback interfaces requires an extra configuration


statement. You not only specify the neighbors loopback address instead of a physical
address for the remote end of the session, you must also specify the local routers loop-
back interface as the originating end of the session.
Example 2-16 shows an improved configuration for Vail. The EBGP configuration
remains the same, but the neighbor remote-as statements for Aspen and Telluride now
point to those routers loopback interface addresses rather than physical interfaces as in
the previous configuration examples. The IBGP configurations of Aspen and Telluride
also now point to loopback interfaces instead of physical interfaces.

But that is not enough. By default, an outgoing TCP session is sourced from its outgoing
physical interface address. If every router in Figure 2-27 tried to originate its IBGP TCP
session from a physical interface and going to a loopback interface, although its peer
also originates at a physical interface and terminates at the local routers loopback, the
endpoints of the attempted TCP sessions never match and the sessions do not come up.
126 Chapter 2: Introduction to BGP

So neighbor update-source tells the router to originate the TCP session going to the
specified neighbor from the specified local loopback interface.

Example 2-16 Peering Between Loopback Addresses Requires the neighbor update-
source Statement to Indicate That the Local End of the Session Should Be Sourced from the
Local Loopback Interface, as Shown in Vails Modified Configuration

router bgp 100

neighbor 192.168.1.225 remote-as 200


neighbor 192.168.100.2 remote-as 100
neighbor 192.168.100.2 update-source Loopback0
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 update-source Loopback0

Example 2-17 shows the results of the three routers of AS100 in Figure 2-27. The IBGP
sessions are all up (because of OSPF advertising the loopback addresses). You can also
observe another difference from the earlier observed sessions. Recall from the discus-
sion in the section on the Open message than BGP chooses its router ID the same way
OSPF does: It prefers the loopback address and chooses the numerically highest physical
interface address if the loopback is not available. With the new configuration we have
made loopback addresses available, and you can see that the BGP router IDs in each of
Example 2-17s three displays are the loopback address of that router. Because the same
loopback address is probably used to identify the router in several other ways, such as
the OSPF router ID and even as a DNS entry for telnetting to the router by name, using
the loopback for the BGP router ID enforces consistency and makes the BGP ID easily
recognizable.

The Case Study Managing and Securing BGP Sessions shows you an even better way to
configure a predictable and consistent BGP router ID.

Example 2-17 The IBGP Sessions Now Run Between Loopback Interfaces Instead of
Physical Interfaces

Vail#show ip bgp summary


BGP router identifier 192.168.100.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.1.225 4 200 5 5 1 0 0 00:01:09 0
192.168.100.2 4 100 15 14 1 0 0 00:11:26 0
192.168.100.3 4 100 12 13 1 0 0 00:09:00 0
______________________________________________________________________________
Configuring and Troubleshooting BGP Peering 127

Aspen#show ip bgp summary


BGP router identifier 192.168.100.2, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.100.1 4 100 14 14 1 0 0 00:11:42 0
192.168.100.3 4 100 11 13 1 0 0 00:08:59 0
______________________________________________________________________________
Telluride#show ip bgp summary
BGP router identifier 192.168.100.3, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


192.168.1.205 4 400 8 7 1 0 0 00:03:02 0
192.168.100.1 4 100 20 20 1 0 0 00:17:09 0
192.168.100.2 4 100 21 19 1 0 0 00:16:51 0

Case Study: Connected Check and EBGP Multihop


Only the IBGP sessions in the previous example run between loopback addresses. The
EBGP sessions still run between directly connected physical interfaces, and that is stan-
dard practice for the great majority of EBGP sessions. The IOS default settings ensure
that external BGP peers are directly connected by two means:

Setting a TTL value of 1 in packets containing BGP messages to external neighbors


so that if the packet crosses a router hop the TTL is decremented to 0 and the
packet is dropped

Checking the IP address of the configured neighbor to ensure that it belongs to a


directly connected subnet

However, there are cases in which running EBGP between loopback interfaces is use-
ful. Consider Figure 2-28, in which Telluride and Alta are connected by four equal-cost
links. Configuring four separate EBGP sessions, one for each link, is undesirable because
you do not want the added configuration complexity. More important, such a configura-
tion causes BGP to advertise four identical sets of prefixes between the routers, reducing
network scalability.

At the same time, you do not want to choose just one of the four links to carry the
EBGP session. If that link was to fail, EBGP would fail even though there are still three
good links between the routers. You want to take advantage of the redundancy and
load-sharing capabilities of the four parallel links. A solution for this case12 is to run
EBGP between the routers loopback interfaces, as shown in Figure 2-29.

12
Another solution is to bundle the links using a link aggregation protocol, which does not
require you to configure EBGP Multihop or disable the connect check.
128 Chapter 2: Introduction to BGP

AS 100
7HOOXULGHV([WHUQDO,QWHUIDFHV
Telluride
S1/0: 192.168.1.206/30
S1/1: 192.168.1.210/30
S1/2: 192.168.1.214/30
S1/3: 192.168.1.218/30

Alta

AS 400

Figure 2-28 Four Equal-Cost Links Connect Telluride and Alta

AS100

Telluride

Loopback0
192.168.100.3/32

EBGP

Loopback0
192.168.200.1/32

Alta

AS400

Figure 2-29 Using Loopback Interfaces for the EBGP Endpoints Takes Advantage of the
Redundancy and Load Sharing of Multiple Physical Links
Configuring and Troubleshooting BGP Peering 129

The configuration is similar to the configurations in the preceding IBGP example: You
specify the neighbors loopback address as the neighbor address, use the neighbor
update-source statement to source the session from the local loopback interface, and
give the routers on each side a means of finding the remote peering address. By defini-
tion an IGP is not run between routers in different autonomous systems, so in this case,
static routes are used; for each physical link, a static route is configured pointing to the
remote loopback address and specifying the address of the far end of the link as the
next hop. Example 2-18 shows Altas EBGP configuration; Tellurides configuration is
similar.

Example 2-18 Altas EBGP Configuration Specifies That EBGP Messages It Originates
to Neighbor 192.168.100.3 (Telluride) Are Originated from Its Loopback0 Interface,
and Static Routes Are Configured to Find the Neighbor Address Across All Four of the
Physical Links

router bgp 400


no synchronization
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 disable-connected-check
neighbor 192.168.100.3 update-source Loopback0
no auto-summary
!
ip route 192.168.100.3 255.255.255.255 192.168.1.206
ip route 192.168.100.3 255.255.255.255 192.168.1.210
ip route 192.168.100.3 255.255.255.255 192.168.1.214
ip route 192.168.100.3 255.255.255.255 192.168.1.218

Example 2-19 shows that Altas neighbor state to Telluride is Idle. A closer look shows,
near the bottom of the display, that there is no active TCP session because the neighbor
address 192.168.100.3 is not directly connected. This is the connected check that IOS
does by default for EBGP neighbors.

Example 2-19 The Neighbor State to Telluride Is Idle Because the IOS Default
Connected Check Shows That the Address Is Not Directly Connected to a Local Subnet

Alta#show ip bgp neighbor 192.168.100.3


BGP neighbor is 192.168.100.3, remote AS 100, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Idle
Last read 00:00:00, last write 00:00:00, hold time is 180, keepalive interval is
60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
130 Chapter 2: Introduction to BGP

Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast


BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 0; dropped 0


Last reset never
External BGP neighbor not directly connected.
No active TCP connection
Alta#

For situations in which an external BGP neighbor is directly connected but the neighbor
address is not a part of a local subnetthe most common instance of which is EBGP
peering between loopback interfacesyou can disable the IOS connected check with
the statement neighbor disable-connected-check. Example 2-20 shows Altas configura-
tion with this statement added. The statement is also added to Tellurides configuration.
Example 2-21 shows that the BGP session between the two loopback addresses is now
established.
Configuring and Troubleshooting BGP Peering 131

Example 2-20 Altas EBGP Configuration Now Includes the neighbor disable-
connected-check Statement

router bgp 400


no synchronization
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 disable-connected-check
neighbor 192.168.100.3 update-source Loopback0
no auto-summary
!
ip route 192.168.100.3 255.255.255.255 192.168.1.206
ip route 192.168.100.3 255.255.255.255 192.168.1.210
ip route 192.168.100.3 255.255.255.255 192.168.1.214
ip route 192.168.100.3 255.255.255.255 192.168.1.218

Example 2-21 With the Connected Check Disabled, the EBGP Session Between Alta and
Telluride Is Now Established

Alta#show ip bgp neighbor 192.168.100.3


BGP neighbor is 192.168.100.3, remote AS 100, external link
BGP version 4, remote router ID 192.168.100.3
BGP state = Established, up for 00:10:06
Last read 00:00:05, last write 00:00:05, hold time is 180, keepalive interval is
60 seconds
Neighbor capabilities:

[Remaining output deleted]

Figure 2-30 depicts another EBGP peering scenario that is frequently encountered. An
EBGP session is again running between the loopback interfaces of Alta and Telluride,
but now the two routers are not directly connected. The session must pass through the
router Copper, which is not running BGP at all. Copper might be a filtering router or
some other security device that examines packets before theyre allowed to enter AS100,
or it might be one of many edge routers that aggregate EBGP sessions to one or a few
routers interior to AS100. The point is that just disabling the IOS connected check is not
sufficient to make this scenario work because by default EBGP messages are sent with a
TTL of 1. Packets passing from Alta to Copper to Telluride must have a TTL of at least 2
to account for the TTL being decremented by 1 as it passes through Copper.

The neighbor ebgp-multihop statement changes the default TTL in EBGP messages
to specified neighbors. Example 2-22 shows the configurations of the three routers in
Figure 2-30. Simple reachability is configured with OSPF between Telluride and Copper,
a static route at Copper for Altas loopback address, and a static default route pointing
to Copper at Alta. Most important, notice that there is no BGP running at Copper. The
132 Chapter 2: Introduction to BGP

neighbor ebgp-multihop statement is used at Telluride and Alta to change the default
TTL of their EBGP messages to 2; when the messages transit Copper the TTL is dec-
remented to 1, and the messages safely arrive at their destination. If the messages had
retained their default TTL of 1 upon transmission, the TTL would be decremented to 0
at Copper, and the packets would be dropped.

AS100

Telluride

Loopback0
192.168.100.3/32
Copper
(No BGP)
192.168.1.221/30

EBGP

Loopback0
192.168.200.1/32

Alta

AS400

Figure 2-30 EBGP Peering Scenario for Two Routers Not Directly Connected

Example 2-22 Routers Telluride and Alta in Figure 2-30 Are Configured to Establish
an EBGP Session Across Two Router Hops

Telluride
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 192.168.200.1 remote-as 400
neighbor 192.168.200.1 ebgp-multihop 2
Configuring and Troubleshooting BGP Peering 133

neighbor 192.168.200.1 update-source Loopback0


no auto-summary
!
__________________________________________________
Copper
router ospf 1
log-adjacency-changes
redistribute static
network 0.0.0.0 255.255.255.255 area 0
!
ip route 192.168.200.0 255.255.255.0 192.168.1.222
!
__________________________________________________
Alta
router bgp 400
no synchronization
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 ebgp-multihop 2
neighbor 192.168.100.3 update-source Loopback0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 192.168.1.221

Example 2-23 shows that Altas neighbor state for Telluride is Established. Looking fur-
ther down the display, you can also see that the outgoing TTL is 2, changed from the
default outgoing TTL of 1.

Example 2-23 Altas Neighbor State to Telluride (192.168.100.3) Is Established

Alta#show ip bgp neighbor 192.168.100.3


BGP neighbor is 192.168.100.3, remote AS 100, external link
BGP version 4, remote router ID 192.168.100.3
BGP state = Established, up for 00:26:41
Last read 00:00:41, last write 00:00:41, hold time is 180, keepalive interval is
60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
134 Chapter 2: Introduction to BGP

Updates: 0 0
Keepalives: 28 28
Route Refresh: 0 0
Total: 29 29
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast


BGP table version 1, neighbor version 1/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 1; dropped 0


Last reset never
External BGP neighbor may be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 192.168.200.1, Local port: 179
Foreign host: 192.168.100.3, Foreign port: 29761
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x22885C):


Timer Starts Wakeups Next
Retrans 29 0 0x0
TimeWait 0 0 0x0
AckHold 29 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
Configuring and Troubleshooting BGP Peering 135

PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0

iss: 3118002936 snduna: 3118003514 sndnxt: 3118003514 sndwnd: 16346


irs: 3626178200 rcvnxt: 3626178778 rcvwnd: 16346 delrcvwnd: 38

SRTT: 294 ms, RTTO: 345 ms, RTV: 51 ms, KRTT: 0 ms


minRTT: 36 ms, maxRTT: 312 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6

Datagrams (max data segment is 536 bytes):


Rcvd: 58 (out of order: 0), with data: 29, total data bytes: 577
Sent: 31 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0),
with data: 28, total data bytes: 577
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
Alta#

You might ask why the neighbor disable-connected-check statement is not needed
in this configuration. Alta and Telluride are obviously not directly connected, and the
loopback addresses do not belong to the same subnet, yet just as obviously in Example
2-23 the EBGP session between their loopback interfaces works. The answer is that the
connected check is automatically disabled when the neighbor ebgp-multihop statement
increases the TTL

Using the neighbor ebgp multihop statement to change the TTL to 2 or more would
make the scenario in Figure 2-29 work just as well as using the neighbor disable-
connected-check statement did. This leads to a commonly held misconception that the
TTL is decremented when a packet is sent to an IP address on a neighboring router when
the destination address is not a part of a locally connected subnet. This is not the case.
The TTL of any IP packet is decremented only when the packet leaves a routera true
router hop.
So if you want to establish an EBGP session to an IP address on a directly connected
router that does not belong to a directly connected subnet, as shown in Figure 2-29,
use the neighbor disable-connected-check statement. This enables you to establish the
connection without sacrificing the default TTL behavior. If you must establish a EBGP
session with a neighbor that is truly more than one router hop away, use the neighbor
ebgp-multihop statement, but allow only the number of router hops necessary to reach
the neighbor.
136 Chapter 2: Introduction to BGP

Case Study: Managing and Securing BGP Connections


The examples up to this point have given you everything you need to configure fully
functional BGP sessions, and have given you an overview of the tools for observing
and troubleshooting the sessions. But there are a few more configuration features that,
although not necessary for getting a session up and running, are useful for making the
session more manageable and that are essential for making the session secure.

Note In addition to the features demonstrated in this case study, BGP peer groups
and peer templates make large BGP configurations more manageable. Peer groups and
peer templates are covered in Chapter 5 as scaling features because as configuration
complexity grows, these grouping tools become not just convenient but also almost
essential for configuration control.

Example 2-24 shows the BGP configuration for Vail in Figure 2-27, with some added
management and security features.

Example 2-24 A Number of Management and Security Features Have Been Added to
Vails (Figure 2-27) BGP Configuration

router bgp 100


bgp router-id 192.168.100.1
bgp log-neighbor-changes
neighbor 192.168.1.225 remote-as 200
neighbor 192.168.1.225 description Taos
neighbor 192.168.1.225 password N0rdic
neighbor 192.168.1.225 ttl-security hops 1
neighbor 192.168.100.2 remote-as 100
neighbor 192.168.100.2 description Aspen
neighbor 192.168.100.2 password aLpine
neighbor 192.168.100.2 update-source Loopback0
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 description Telluride
neighbor 192.168.100.3 password aLpine
neighbor 192.168.100.3 update-source Loopback0
neighbor 192.168.100.10 remote-as 100
neighbor 192.168.100.10 description Whistler
neighbor 192.168.100.10 password aLpine
neighbor 192.168.100.10 shutdown
neighbor 192.168.100.10 update-source Loopback0
!

The first new statement in Vails configuration is bgp router-id. As previously discussed,
IOS uses the same procedure to acquire a BGP router ID as it does for the OSPF router
Configuring and Troubleshooting BGP Peering 137

ID: It uses a loopback interface address if one exists, and if not it uses the numerically
highest physical interface address. The bgp router-id statement overrides this automatic
procedure and manually assigns a BGP router ID. You can use this statement if you
want the BGP router ID to be something different from a loopback interface address,
oras in the example hereyou can use the command to ensure that the BGP router
ID remains stable and predictable even if the loopback address is added, changed, or
deleted.

The next new statement shown in Example 2-24 is bgp log-neighbor-changes. In all
recent IOS releases, this feature is enabled by default, so when you create a BGP con-
figuration the statement is automatically entered. But it is worthwhile to check your
configuration to ensure that the statement is there because it provides another key
troubleshooting tool. When the status of a neighbor changes, this feature records the
change and the cause of the change either in the routers logging buffer or, if syslog is
configured, to an external syslog server.

The entries in the logging buffer display with the show logging command, as shown in
Example 2-25. The log entries in this example (after some information about the log-
ging buffer) reveal several neighbor events at Vail. The first entry records an adjacency
establishment with neighbor 192.168.100.3 (Telluride in Figure 2-27). The second entry
shows that a little less than 4 minutes later, the adjacency went down. The entry, also
important, indicates the reason the adjacency went down: Telluride closed the session.
You know from this information that the session was closed gracefully by BGP rather
than suffering a hard failure. A minute later, according to the third entry, the adjacency
to Telluride is re-established.

Example 2-25 bgp log-neighbor-changes Statement Enables Logging of Changes in BGP


Neighbor Status, Which Can Then Be Observed with the show logging Command

Vail#show logging

Syslog logging: enabled (10 messages dropped, 0 messages rate-limited,


0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: level debugging, 505 messages logged, xml disabled,


filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 505 messages logged, xml disabled,
138 Chapter 2: Introduction to BGP

filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled

No active filter modules.

ESM: 0 messages dropped

Trap logging: level informational, 509 message lines logged

Log Buffer (8192 bytes):

*Aug 21 07:11:38: %BGP-5-ADJCHANGE: neighbor 192.168.100.3 Up


*Aug 21 07:15:16: %BGP-5-ADJCHANGE: neighbor 192.168.100.3 Down Peer closed the
session
*Aug 21 07:16:17: %BGP-5-ADJCHANGE: neighbor 192.168.100.3 Up
*Aug 21 07:19:35: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed
state to up
*Aug 21 07:21:03: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:04: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:04: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:06: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:09: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:14: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
Vail#

The fourth entry shows that the state of interface S1/0the interface connecting to
Taos (192.168.1.225) referred to in Figure 2-27has changed to Up. After the interface
is up, the remaining entries show that Vail is making repeated attempts to open a TCP
connection with Taos on port 179. The attempts are failing, according to the entries,
because of an authentication problem.

The authentication problem leads to the next new feature in Vails configuration: The
neighbor password statement enables MD5 authentication and specifies a password for
the neighbor.13 The log entries in Example 2-25 tell you that while Vail is configured
for MD5 authentication, Taos is not. If Taos were configured for authentication but its

13
Normally, the passwords in the displayed configuration, like all other passwords, would be and
should be encrypted. In this example, service password-encryption is disabled so that you can
read the password.
Configuring and Troubleshooting BGP Peering 139

password did not match Vails, the entries would state Invalid MD5 digest rather than
No MD5 digest.

Each of Vails neighbors in Example 2-24 is configured for authentication. As with any
IGP, you must authenticate all your IBGP sessions; however, authenticating EBGP ses-
sions is not merely important; it is also essential to the security of your network. The
great majority of attempted attacks against routing protocols are against EBGP because
that is the protocol exposed to the outside world and therefore the most accessible.
Never run EBGP without authentication.

Example 2-24 shows that all the IBGP neighbors are configured with the same password
(aLpine), whereas Taos, an external neighbor, has a different password (N0rdic). As
with your IGP, it is acceptable and administratively easier to use the same password for
all IBGP sessions; however, each EBGP session should have a unique password. Some
network operators use the same password for multiple EBGP sessions to the same neigh-
boring administrative domain, differing the passwords only for different domains, but
the safest practice is to use a unique password for all EBGP sessions regardless of the
domain.

Another EBGP security feature shown in Vails configuration to Taos is neighbor


ttl-security. To understand the effects of this statement, compare the highlighted lines
in Example 2-26, taken with neighbor ttl-security enabled, with the corresponding
lines in Example 2-8, taken for the same neighbor without the feature enabled. Vails
neighbor database for Taos in Example 2-8 shows the IOS default TTL behavior as dis-
cussed in the EBGP multihop case study: The TTL of incoming BGP message packets
can be 0 or higher (this is after the local router has decremented the TTL value of the
received packet), and the router sets the TTL of BGP message packets it originates to
1. Specifying neighbor 192.168.1.225 ttl-security hops 1 in Vails BGP configuration
makes two changes to the default behavior, as shown in Example 2-26:

The TTL of BGP message packets received from Taos must be 254 or higher (again,
as measured after Vail has decremented the TTL value of the received packet) by
subtracting the specified allowable hops from 255.

The TTL of BGP message packets Vail sends to Taos is set to 255.

Example 2-26 neighbor ttl-security Feature Changes the Acceptable TTL Value of
Received EBGP Message Packets and the TTL Value of Transmitted BGP Message Packets

Vail#show ip bgp neighbor 192.168.1.225

BGP neighbor is 192.168.1.225, remote AS 200, external link


BGP version 4, remote router ID 192.168.1.225
BGP state = Established, up for 00:00:31
Last read 00:00:30, last write 00:00:00, hold time is 180, keepalive interval
is 60 seconds
140 Chapter 2: Introduction to BGP

Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 6 6
Notifications: 0 0
Updates: 0 0
Keepalives: 75 77
Route Refresh: 0 0
Total: 81 83
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast


BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 2, Offset 0, Mask 0x4
2 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 6; dropped 5


Last reset 00:00:34, due to User reset
External BGP neighbor may be up to 1 hop away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 254, Outgoing TTL 255
Local host: 192.168.1.226, Local port: 13408
Foreign host: 192.168.1.225, Foreign port: 179
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)


Configuring and Troubleshooting BGP Peering 141

Event Timers (current time is 0x3D55F8):


Timer Starts Wakeups Next
Retrans 4 0 0x0
TimeWait 0 0 0x0
AckHold 2 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0

iss: 379206806 snduna: 379206890 sndnxt: 379206890 sndwnd: 16301


irs: 3498356006 rcvnxt: 3498356109 rcvwnd: 16282 delrcvwnd: 102

SRTT: 206 ms, RTTO: 1891 ms, RTV: 1685 ms, KRTT: 0 ms
minRTT: 400 ms, maxRTT: 608 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, md5
IP Precedence value : 6

Datagrams (max data segment is 1440 bytes):


Rcvd: 4 (out of order: 0), with data: 2, total data bytes: 102
Sent: 6 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0)
with data: 3, total data bytes: 83
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
Vail#

The default behavior of setting the TTL value to 1 in originated packets ensures that
the packets cannot travel beyond a directly connected router. But the default behavior
of accepting packets with a TTL of 0 or higher means that a number of attacks can be
launched remotely against EBGP; as long as the TTL of originated attack packets is high
enough, the packets can traverse many routers and still be accepted by the local router.
Authentication prevents BGP from accepting the packets internally, but a flood of
invalid packets causing many authentication failures over short periods can break
the EBGP session or spike the routers CPU, causing BGP to fail or even causing a
router crash.

By setting the TTL of outbound packets to 255 and accepting only packets with a TTL
of 254 or higher, packets cannot be sent to the local BGP process from routers that
142 Chapter 2: Introduction to BGP

are not directly connected.14 A maximum TTL of 255 is decremented to 254 when the
packet transits a single router; arriving at the local router it is decremented to 253, which
is below the acceptable minimum, and the packet is quietly discarded (that is, discarded
without sending an ICMP error message) before reaching the local BGP process.

Of course, if you enable a minimum TTL value of 254 with neighbor ttl-security, the
neighbor must send BGP message packets with a TTL of 255. So both neighbors must
be configured with the feature, or if one of the neighbors is not an IOS router, it must
support an equivalent feature. Another caveat is that neighbor ttl-security is incompat-
ible with neighbor ebgp-multihop. But you can achieve the same results by adjusting the
hops specification of the neighbor ttl-security statement.

Table 2-6 compares the use of EBGP-Multihop with that of TTL-Security.

Table 2-6 Comparison of EBGP-Multihop and TTL-Security


Minimum Acceptable TTL of TTL of Outgoing
BGP Message Option Incoming BGP Messages BGP Messages
Default 0 or higher 1
neighbor ebgp-multihop 0 or higher Specified TTL value
neighbor ttl-security hops 255 (Specified hops value) 255

Another new statement in the configuration of Example 2-24 is neighbor description.


This statement has no functional effect on BGP and merely provides a means of adding a
textual description of up to 80 characters to the neighbor address, making the neighbor
easier to identify in the configuration.

Finally, Example 2-24 includes a configuration for a new neighbor, Whistler, at


192.168.100.10. But Whistler has not yet been installed, so neighbor shutdown prevents
Vail from attempting to connect to the non-existent neighbor. The neighbor shutdown
statement is useful anytime you want to disable a neighbor connection
without deleting its configuration.

Looking Ahead
This chapter provided you with a thorough grounding in the configuration and trouble-
shooting of BGP peering sessions and their underlying TCP sessions. But you surely
have noticed that throughout the chapter, no routing information was actually passed
over these sessions. The next chapter introduces you to the basic techniques of sending
and receiving routing information over BGP sessions and the application of policies to
change how the routing information is used.

14
Securing against remote attacks by manipulating TTL values is called Generalized TTL Security
Mechanism (GTSM) and is defined in RFC 3682.
Review Questions 143

Review Questions
1. What is an untrusted administrative domain, and why is it untrusted?

2. In what way does BGP require you to think differently about peering than an
IGP does?

3. What AS numbers are reserved for private use?

4. What are the four BGP message types, and how is each one used?

5. What happens if two BGP neighbors advertise different hold times in their
Open messages?

6. What does a negotiated hold time of 0 indicate?

7. What is the IOS default period for sending BGP Keepalive messages?

8. What is the BGP identier, and how is it selected?

9. In what state or states can BGP peers exchange Update messages?

10. What is NLRI?

11. What is a path attribute?

12. What is a Withdrawn route?

13. What happens when a BGP Notication message is received?

14. What is the difference between the Connect state and the Active state?

15. What causes a transition to the OpenConrm state, and what are the next steps
when the BGP process shows a neighbor in this state?

16. What are the four categories of BGP path attributes?

17. What does well-known mandatory mean, and what are the three well-known
mandatory path attributes?

18. What is the purpose of the ORIGIN attribute?

19. What is the purpose of the AS_PATH attribute?

20. When does a router add its AS number to the AS_PATH list of an Update?

21. What is AS path prepending?

22. What are AS_SEQUENCE and AS_SET, and what is the difference between
them?

23. What is the purpose of the NEXT_HOP attribute?

24. What is a recursive route lookup, and why is it important to BGP?

25. What happens if a router receives a BGP route with a NEXT_HOP address that
is unknown to the router?
144 Chapter 2: Introduction to BGP

26. What are the three parts of a BGP routing information database (RIB), and what is the
function of each?

27. What do all the NLRI in a BGP Update message have in common?

28. Does BGP require a TCP connection between IPv6 addresses to advertise IPv6
prexes?

29. What is the IOS default TTL value of BGP message packets sent to external peers?

Configuration Exercises
Table 2-7 lists the autonomous systems, routers, interfaces, and addresses used in
Exercises 1 through 4. All interfaces of the routers are shown; physical interfaces may be
changed for your solutions to fit your available resources. For each exercise, if the table
indicates that the router has a loopback interface, that interface should be the source of
all IBGP connections. EBGP connections should always be between physical interface
addresses, unless otherwise specified in an exercise. Neighbor descriptions will always be
configured to be the router names.

Table 2-7 Details for Configuration Exercises 14

AS Router Interface IP Address/Mask


G2/0 10.0.0.1/30
G3/0 10.0.0.5/30
1 R1
S1/0 172.16.0.1/30
Lo0 192.168.0.1/32
G2/0 10.0.0.2/30
G3/0 10.0.0.9/30
R2 S1/0 172.16.0.5/30
S1/1 172.16.0.9/30
Lo0 192.168.0.2/32
G2/0 172.16.0.10/30
R3 G3/0 172.16.0.6/30
S1/0 fc00::1/64
Lo0 192.168.0.3/32
2 R4 S1/0 172.16.0.2/30
Lo0 192.168.0.4/32
Lo1 192.168.0.41/32
3 R5
S1/0 fc00::2/64
Troubleshooting Exercises 145

AS Router Interface IP Address/Mask


Lo0 192.168.0.5/32
S1/0 172.16.0.6/30
4 R6
S1/1 172.16.0.10/30
Lo0 192.168.0.6/32

1. Congure OSPF as the IGP for AS1. OSPF area 0 spans the whole AS. AS1
internal routes should not be advertised outside the AS. All point-to-point links
over which EBGP is run should not be advertised into the AS. Then congure
the IBGP full mesh for AS1. All IBGP connections will be MD5 authenticated
using password Ch2_ExcerSizE1.

2. Congure an EBGP peering between R1 in AS1 and R4 in AS2. Authenticate the


EBGP peering using password Ch2_ExcerSizE2. Set the router-id of R4 manually
to be the IP address of Loopback 1. In addition, make sure both routers are secured
against remote attacks that are based on manipulating TTL values.

3. Congure EBGP peering between R3 in AS1 and R5 in AS3 using the IPv6 point-to-
point physical addresses congured on the routers. Make sure you congure both
routers to log all neighbor state changes.

4. Congure EBGP peering between R2 in AS1 and R6 in AS4 such that load balancing
is achieved over both physical links. Do not use link aggregation. Use static routing
on R2 and R6.

Troubleshooting Exercises
1. Routers R1 and R3 in Figure 2-31 can ping each others loopback 0 interfaces.
The network operator congures an IBGP peering between both routers, as
shown in Example 2-27. However, the IBGP session is not getting established.
The command bgp log-neighbor-changes was congured on both routers, and
the output from the show logging and the show ip bgp neighbors commands is
shown in Example 2-28. What is likely to be preventing the IBGP peering from
coming up?

R1 S1/0 S1/0 R2 S1/1 S1/1 R3

Figure 2-31 Topology for Troubleshooting Exercise 1


146 Chapter 2: Introduction to BGP

Example 2-27 Configuring an IBGP Peering Between R1 and R3

! R1
!
router bgp 1
bgp log-neighbor-changes
neighbor 192.168.0.3 remote-as 1
neighbor 192.168.0.3 update-source loopback 0
neighbor 192.168.0.3 description R3
neighbor 192.168.0.3 password Ch2_Troublesh00ting_ExcerSizE
!
_____________________________________________________________
! R3
!
router bgp 1
bgp log-neighbor-changes
neighbor 192.168.0.1 remote-as 1
neighbor 192.168.0.1 update-source loopback 0
neighbor 192.168.0.1 description R1
neighbor 192.168.0.1 password Ch2_Troublesh00ting_ExcerSizE
!

Example 2-28 show logging and show ip bgp neighbors Output

R1
R1#show logging
Syslog logging: enabled (12 messages dropped, 9 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: level debugging, 117 messages logged, xml disabled,


filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 126 messages logged, xml disabled,
filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
Troubleshooting Exercises 147

Persistent logging: disabled

No active filter modules.

ESM: 0 messages dropped

Trap logging: level informational, 59 message lines logged

Log Buffer (8192 bytes):

*Sep 4 01:21:00.311: %SYS-5-CONFIG_I: Configured from console by console


*Sep 4 01:21:20.835: BGP: 192.168.0.3 went from Idle to Active
*Sep 4 01:21:20.843: BGP: 192.168.0.3 open active delayed 30866ms (35000ms max, 28%
jitter)
*Sep 4 01:21:51.711: BGP: 192.168.0.3 open active, local address 192.168.0.1
*Sep 4 01:21:51.891: BGP: 192.168.0.3 open failed: Destination unreachable; gateway
or host down, open active delayed 31701ms (35000ms max, 28% jitter)
*Sep 4 01:22:23.595: BGP: 192.168.0.3 open active, local address 192.168.0.1

R1#show ip bgp neighbors


BGP neighbor is 192.168.0.3, remote AS 1, internal link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:03:33, last write 00:03:33, hold time is 180, keepalive interval is
60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 0 seconds

For address family: IPv4 Unicast


BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
148 Chapter 2: Introduction to BGP

Prefix activity: ---- ----


Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 0; dropped 0


Last reset never
No active TCP connection
_______________________________________________________________________
R3
R3#show logging
Syslog logging: enabled (12 messages dropped, 9 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: level debugging, 115 messages logged, xml disabled,


filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 124 messages logged, xml disabled,
filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled

No active filter modules.

ESM: 0 messages dropped

Trap logging: level informational, 55 message lines logged


Troubleshooting Exercises 149

Log Buffer (8192 bytes):

*Sep 4 01:20:55.003: %SYS-5-CONFIG_I: Configured from console by console


*Sep 4 01:21:28.723: BGP: 192.168.0.1 went from Idle to Active
*Sep 4 01:21:28.731: BGP: 192.168.0.1 open active delayed 34023ms (35000ms max, 28%
jitter)
*Sep 4 01:22:02.755: BGP: 192.168.0.1 open active, local address 192.168.0.3
*Sep 4 01:22:02.811: BGP: 192.168.0.1 open failed: Destination unreachable; gateway
or host down, open active delayed 25843ms (35000ms max, 28% jitter)
*Sep 4 01:22:28.655: BGP: 192.168.0.1 open active, local address 192.168.0.3
*Sep 4 01:22:28.831: BGP: 192.168.0.1 open failed: Destination unreachable; gateway
or host down, open active delayed 27833ms (35000ms max, 28% jitter)
*Sep 4 01:22:56.667: BGP: 192.168.0.1 open active, local address 192.168.0.3
*Sep 4 01:22:56.859: BGP: 192.168.0.1 open failed: Destination unreachable; gateway
or host down, open active delayed 33383ms (35000ms max, 28% jitter)

R3#show ip bgp neighbors


BGP neighbor is 192.168.0.1, remote AS 1, internal link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:03:57, last write 00:03:57, hold time is 180, keepalive interval is
60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 0 seconds

For address family: IPv4 Unicast


BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
150 Chapter 2: Introduction to BGP

Used as bestpath: n/a 0


Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 0; dropped 0


Last reset never
No active TCP connection

2. Refer to Figure 2-32. R1 and R2 have been congured to establish an IBGP


connection, but the connection is not coming up. Upon inspecting the logging
buffer, the logs in Example 2-29 were found. Why is the IBGP session not com-
ing up?

R1 S1/0 S1/0 R2

Figure 2-32 Topology for Troubleshooting Exercise 2

Example 2-29 Logs Lack an IBGP Session

R1#
*Sep 4 02:49:20.575: BGP: 192.168.0.2 open failed: Connection timed out; remote
host not responding, open active delayed 457ms (1000ms max, 87% jitter)
*Sep 4 02:49:21.035: BGP: 192.168.0.2 open active, local address 192.168.0.1
R1#
*Sep 4 02:49:21.287: %TCP-6-BADAUTH: No MD5 digest from 192.168.0.2(179) to
192.168.0.1(43661)

3. In an attempt to rectify the problem in Exercise 2, the network operator


changed the BGP conguration on one of the routers. Now he receives the log
messages shown in Example 2-30. Why is the IBGP session not coming up,
and what is the difference between the log messages in this exercise and
Exercise 2?

Example 2-30 Logs Still Missing an IBGP Session

R1#
*Sep 4 02:51:16.003: BGP: 192.168.0.2 open active, local address 192.168.0.1
R1#
Troubleshooting Exercises 151

*Sep 4 02:51:21.007: BGP: 192.168.0.2 open failed: Connection timed out; remote
host not responding, open active delayed 30634ms (35000ms max, 28% jitter)
R1#
*Sep 4 02:51:21.739: %TCP-6-BADAUTH: Invalid MD5 digest from 192.168.0.2(28677) to
192.168.0.1(179)

4. In Figure 2-33, routers R1 and R2 are in AS1. R3 is in AS2. OSPF is the IGP for
AS1 and area 0 spans the whole AS. Routers R1 and R2 have been congured
to peer over their loopback addresses. R1 peers with R3 over the physical link
addresses. The congurations for all three routers are listed in Example 2-31.
Interface Loopback0 of R3 (192.168.0.3) is shown in the output of show ip bgp
on router R2, but the route is not being installed in the IP routing table. What is
the reason for this? And what are two ways to x this issue, and which method
is considered to be best practice conguration?

ASN 1

S1/1 S1/0 S1/0


R1 R2

ASN 2

S1/1

R3

Figure 2-33 Topology for Troubleshooting Exercise 4

Example 2-31 Router Configurations for Troubleshooting Exercise 4

! R1
!
interface Serial1/0
ip address 10.0.0.1 255.255.255.252
!
interface Serial1/1
ip address 172.16.0.1 255.255.255.252
!
interface Loopback 0
ip address 192.168.0.1 255.255.255.255
152 Chapter 2: Introduction to BGP

!
router ospf 1
log-adjacency-changes
network 10.0.0.1 0.0.0.0 area 0
network 192.168.0.1 0.0.0.0 area 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 192.168.0.2 remote-as 1
neighbor 192.168.0.2 update-source Loopback0
neighbor 172.16.0.2 remote-as 2
no auto-summary
!
_______________________________________________
! R2
!
interface Serial1/0
ip address 10.0.0.2 255.255.255.252
!
interface Loopback 0
ip address 192.168.0.2 255.255.255.255
!
router ospf 1
log-adjacency-changes
network 10.0.0.2 0.0.0.0 area 0
network 192.168.0.2 0.0.0.0 area 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 192.168.0.1 remote-as 1
neighbor 192.168.0.1 update-source Loopback0
no auto-summary
!
_______________________________________________
! R3
!
interface Serial1/1
ip address 172.16.0.2 255.255.255.252
!
interface Loopback 0
ip address 192.168.0.3 255.255.255.255
!
Troubleshooting Exercises 153

router bgp 2
no synchronization
bgp log-neighbor-changes
network 192.168.0.3 mask 255.255.255.255
neighbor 172.16.0.1 remote-as 1
no auto-summary
!

5. Reference Figure 2-33 in Exercise 4. The network operator xed the problem
that was stopping the bgp route from being installed in the IP routing table on
R2. Now the route is in both the BGP table and the IP routing table. However,
the ping from R2 to R3 is still not successful. What may be the reason for this
and how would you x it?
This page intentionally left blank
Index

Address (A) records, 949


Symbols address families, IPv6, 22
configuration, 524
4-byte AS numbers, scaling BGP network,
574-575 MBGP support, 618-619
16-bit AS numbers, 2 Address Family Identifier (AFI), 616, 895
Address Family Information, 895
address-family ipv4 multicast
A command, 904
address-family ipv4 unicast
AA:NN Format, scaling BGP, 443-445
command, 904
A (Address) records, 949
address-family ipv6 statement, 623
acceptable use policies (AUP), 36
address migration, NAT44 operation,
accept-route-policy-rt statement, 419 937-938
access loss, redundancy schemes, 34 address overloading, 940-942
Acquire state (EGP neighbors), 6 address portability, CIDR and, 58-59
Acquisition Confirm message, 6 address prefixes, 43
Acquisition Request message, 6 address translation tables, NAT44, 934
active EGP neighbors, 8 Adjacency tables, 539
Active state (BGP finite state Adj-RIBs-In, 100
machine), 89
Adj-RIBs-Out, 101
adding communities (scaling BGP),
administrative domains, autonomous
460-471
systems (AS), 1
additional-paths statement, 419
administrative scoping, 765-766,
Additional section, DNS message 881-882
format, 950
advertise-map option, aggregate-address
additive keyword, 463 statement, 217-218
ADD-PATHS capability, PIC, 528-538 advertise-map statement, 419
1080 advertisement-interval statement

advertisement-interval statement, 419 APNIC (Asia-Pacific Network Information


advertise statement, 419 Centre), 54
advertising arbitrary communities, scaling BGP,
BGP NLRI 434-443
local AS, 182 ARIN (American Registry for Internet
Numbers), 54
redistributing BGP NLRI into the
IGP, 182 ARPANET, 1
route aggregation with BGP, 198 AS (autonomous system) numbers, scaling
BGP network, 2
aggregate-address statement,
201-206 4-byte AS numbers, 574-575
AS_SET attribute, 210-218 confederations, 576-592
ATOMIC_AGGREGATE and IBGP and the n-squared problem, 575-576
AGGREGATOR attributes, prepended, 93
207-209 private AS numbers, 569-574
static routes, 199-200 route reflectors, 592-606
AFI (Address Family Identifier), 616, 895 AS (autonomous systems), 1
African Network Information Centre BGP (Border Gateway Protocol), 1
(AfriNIC), 54
configuring and troubleshooting
AfriNIC (African Network Information peering, 110-142
Centre), 54
connecting to multiple external
aggregate-address command, 581 neighbors, 77-79
aggregate-address statement, 102, decision process, 100-103
199-206
finite state machine, 87-90
aggregation, 199, 558
message formats, 103-108
AGGREGATOR attribute, 207-209
message types, 85-87
ALG (DNS Application Level
path attributes, 90-100
Gateway), 964
setting routing policy, 79-82
All-Nodes multicast group, IPv6 multicast
addresses, 722 trust issues, 82-84
allowas-in statement, 414, 419 configuring NAT44, 975-980
ALLOW_NEW_SOURCES (Type 5) multihomed systems, 29
source-list-record change format, 741 load sharing and load balancing,
allow-policy statement, 419 36-37
American Registry for Internet Numbers multiple systems, 79
(ARIN), 54 NAT44 operation, 938-939
Announce messages, RP, 790 provider-assigned (PA) addressing,
Answers section, DNS message 40
format, 950 routing policies, 36
Anycast RP, 917-923 stub AS, 31-36
Any-Source Multicast (ASM) service traffic control, 37
model, 761 transit AS, 30-31
stub versus transit, 21-22
autonomous systems (AS) 1081

AS_CONFED_SEQUENCE attribute, memory utilization, 558


94, 577 MULTI_EXIT_DISC (MED), 159
AS_CONFED_SET attribute, 94, 577 route aggregation
Asia-Pacific Network Information Centre AS_SET, 210-218
(APNIC), 54
ATOMIC_AGGREGATE
ASM (Any-Source Multicast) service AGGREGATOR, 207-209
model, 761
Attribute Type codes, 106
as-override statement, 419
Attribute Values, 106
AS_PATH access lists, MBGP policy
AUP (acceptable use policies), 36
configuration
authentication keychain command, 522
identifying prefixes, 672
authoritative servers (DNS), 949
policy and session templates,
677-685, 701 Authority section, DNS message
format, 950
AS_PATH attributes, 17-20
automatic summarization, 163-166
AS_CONFED_SEQUENCE, 577
autonomous system (AS) numbers, scaling
AS_CONFED_SET, 577
BGP network, 2
AS_PATHLIMIT BGP route attribute, 68
confederations, 576-592
AS_PATH path attribute (BGP), 92-97
IBGP and the n-squared problem, 575-576
AS_SEQUENCE (AS_PATH attribute), 94
prepended, 93
Assert messages
private AS numbers, 569-574
PIMv2 format, 815
route reflectors, 592-606
PIMv2 routers
autonomous systems (AS), 1
Encoded Group Address field, 816
BGP (Border Gateway Protocol), 1
Encoded Unicast Source Address
configuring and troubleshooting
field, 816
peering, 110-142
Metric field, 816
connecting to multiple external
Metric Preference field, 816 neighbors, 77-79
AS_SET attribute, route aggregation, 94, decision process, 100-103
210-218
finite state machine, 87-90
as-set keyword, 214, 581
message formats, 103-108
assigning IPv4 address blocks, CIDR,
message types, 85-87
54-56
path attributes, 90-100
asymmetric traffic, 38
setting routing policy, 79-82
Asynchronous mode (BFD), 513
trust issues, 82-84
ATOMIC_AGGREGATE attribute, route
aggregation, 207-209 configuring NAT44, 975-980
attributes multihomed systems, 29
communities, 425-428 load sharing and load balancing,
36-37
COMMUNITY path, NO_EXPORT
option, 203 multiple systems, 79
MBGP (Multiprotocol BGP), 616-618 NAT44 operation, 938-939
MED, 177, 585 provider-assigned (PA)
addressing, 40
1082 autonomous systems (AS)

routing policies, 36 bgp additional-paths select group-best


stub AS, 31-36 statement, 534
traffic control, 37 bgp additional-paths statement, 534
transit AS, 30-31 bgp always-compare-med statement, 591
stub versus transit, 21-22 bgp best path compare-routerid
statement, 102
Auto-RP protocol, 789-790, 837-845
bgp bestpath med confed statement, 592
Auxiliary Data field (IGMPv3 Group
Record), 741 BGP (Border Gateway Protocol), 1, 16
Auxiliary Data Length field (IGMPv3 advertising BGP NLRI into the local
Group Record), 741 AS, 182
advertising a default route to a
neighboring AS
B distributing NLRI in a stub AS with
IBGP, 184-192
backward compatibility, IPv6 to IPv4, 996 distributing NLRI in a stub AS with
bandwidth, multihoming benefits, 36 static routes, 193-198
B (Border bit) field, PIMv2 Register redistributing BGP NLRI into the
messages, 811 IGP, 182
BFD (Bidirectional Forwarding Detection), AS_PATH attribute, 17-20
512-523 configuring and troubleshooting peering,
bfd echo command, 514 110
bfd interval min_rx multiplier BGP connection security case study,
command, 514 136-142
bfd map ipv4 command, 523 EBGP multihop case study, 127-135
bfd slow-timers command, 514 EBGP peering case study, 110-118
bfd template command, 523 IBGP peering case study, 118-127
bfd-template multi-hop command, 523 configuring NLRI, 155
BFD templates, 522-523 injecting prefixes with
bfd-template single-hop command, 522 redistribution, 162-167
BG identifiers, Open messages, 86 injecting prefixes with the network
BGMP (Border Gateway Multicast mask statement, 160-161
Protocol), 717 injecting prefixes with the network
BGP-1, 16 statement, 156-160
BGP-2, 16 connecting to multiple external
neighbors, 77-79
BGP-3, 16
decision process, 100-103
BGP-4, 16
external versus internal BGP, 22-29
bgp additional-paths install command, 524
finite state machine, 87
bgp additional-paths select all
statement, 534 Active state, 89
bgp additional-paths select best Connect state, 89
statement, 534 Established state, 90
Bootstrap messages 1083

Idle state, 88 vector protocol, 17


input events, 88 versions, 16-17
OpenConfirm state, 90 bgp cluster-id command, 602
OpenSent state, 89 bgp confederation identifier
IBGP (Internal Border Gateway Protocol), command, 579
NLRI and, 167-182 bgp confederation peers command, 580
MBGP (Multiprotocol BGP), 615 BGP Confederations, 94
attributes, 616-618 BGP convergence PIC (Prefix Independent
configuring for IPv6, 619-705 Convergence), 523-538
support for IPv6 address family, bgp dampening command, 480
618-619 bgp deterministic-med statement, 591
message formats, 103 bgp graceful-restart command, 540
Keepalive messages, 108 BGP Identifier field, BGP Open
Notification messages, 108 messages, 105
Open messages, 104 bgp log-neighbor-changes statement, 137
Update messages, 105-106 BGP NEXT_HOP behavior, 177
message types, 85 bgp nexthop trigger delay 0
command, 506
Keepalive messages, 86
bgp nexthop trigger delay statement, 498
Notification messages, 87
bgp recursion host command, 526
Open messages, 85-86
bgp router-id statement, 136
Route Refresh messages, 85
bgp router mode command, 498
Update messages, 86-87
BGP Selection Process, 484
path attributes, 90
bgp suppress-inactive statement, 166
AS_PATH, 92-97
bgp upgrade-cli command, 629-631
NEXT_HOP, 97-100
BGP version number, Open messages, 85
ORIGIN, 92
Bidirectional Forwarding Detection (BFD),
Weight, 100
512-523
route aggregation, 198
Bidirectional PIM (Bidir-PIM), 754, 771
aggregate-address statement,
bidirectional trees, 796
201-206
Bidir-PM (Bidirectional PIM), 754, 771
AS_SET attribute, 210-218
bilateral peering agreements, 30
ATOMIC_AGGREGATE and
AGGREGATOR attributes, BLOCK_OLD_SOURCES (Type 6)
207-209 source-list- record change format, 741
static routes, 199-200 bmp-activate statement, 414
scaling, 401-402 Bootstrap messages, 788
BGP network, 569-606 PIMv2 format, 814-815
configuration scaling tools, 402-478 PIMv2 routers
functions, 478-569 BSR Priority field, 814
setting routing policy, 79-82 Encoded Multicast Group Address
field, 814
trust issues, 82-84
1084 Bootstrap messages

Encoded Unicast BSR Address external versus internal BGP, 22-29


field, 814 finite state machine, 87
Encoded Unicast RP Address field, Active state, 89
815
Connect state, 89
Fragment RP Count field, 815
Established state, 90
Fragment Tag field, 814
Idle state, 88
Hash Mask Length field, 814
input events, 88
RP Count field, 814
OpenConfirm state, 90
RP Holdtime field, 815
OpenSent state, 89
RP Priority field, 815
IBGP (Internal Border Gateway Protocol),
bootstrap protocol, 787-789, 849-855 NLRI and, 167-182
bootstrap router (BSR), 788 MBGP (Multiprotocol BGP), 615
Border Gateway Multicast Protocol attributes, 616-618
(BGMP), 717
configuring for IPv6, 619-705
Border Gateway Protocol (BGP), 1, 16
support for IPv6 address family,
advertising BGP NLRI into the local 618-619
AS, 182
message formats, 103
advertising a default route to a
Keepalive messages, 108
neighboring AS
Notification messages, 108
distributing NLRI in a stub AS with
IBGP, 184-192 Open messages, 104
distributing NLRI in a stub AS with Update messages, 105-106
static routes, 193-198 message types, 85
redistributing BGP NLRI into the Keepalive messages, 86
IGP, 182 Notification messages, 87
AS_PATH attribute, 17-20 Open messages, 85-86
configuring and troubleshooting Route Refresh messages, 85
peering, 110 Update messages, 86-87
BGP connection security case study, path attributes, 90
136-142
AS_PATH, 92-97
EBGP multihop case study, 127-135
NEXT_HOP, 97-100
EBGP peering case study, 110-118
ORIGIN, 92
IBGP peering case study, 118-127
Weight, 100
configuring NLRI, 155
route aggregation, 198
injecting prefixes with
aggregate-address statement,
redistribution, 162-167
201-206
injecting prefixes with the network
AS_SET attribute, 210-218
mask statement, 160-161
ATOMIC_AGGREGATE and
injecting prefixes with the network
AGGREGATOR attributes,
statement, 156-160
207-209
connecting to multiple external
static routes, 199-200
neighbors, 77-79
decision process, 100-103
classful routing 1085

scaling, 401-402 CGMP (Cisco Group Management


BGP network, 569-606 Protocol) messages, 819
configuration scaling tools, 402-478 CGMP packets, 749-752
functions, 478-569 CHANGE_TO_EXCLUDE_MODE
(Type 4) filter-mode-change record
setting routing policy, 79-82
format, 741
trust issues, 82-84
CHANGE_TO_INCLUDE_MODE
vector protocol, 17 (Type 3) filter-mode-change record
versions, 16-17 format, 741
broadcast-and-prune protocols, 758 Checksum field
broadcasting, 713 IGMPv2 message format, 737
BSR (bootstrap router), 788 MLDv1 messages, 743
BSR Priority field, PIMv2 Bootstrap PIMv2 message header, 810
messages, 814 PIMv2 Register messages, 811
buffer small permanent statement, 569 checksums, NAT44 operation, 945
BUM frames, 746 CIDR blocks, 40, 53
CIDR (classless inter-domain routing),
C 16, 41
address portability, 58-59
candidate bootstrap routers (C-BSRs), assigning IPv4 address blocks, 54-56
788, 849 classless routing, 43-47
Candidate-RP-Advertisement messages limitations, 62-66
PIMv2 format, 817 multihoming and provider-assigned
PIMv2 routers addresses, 56-58
Encoded Group Address field, 817 NAT resolution for multihomed
Encoded Unicast RP Address field, environments, 939
817 provider-independent addresses, 59-60
Holdtime field, 817 reducing Class B address space
Prefix Count field, 817 depletion, 50
Priority field, 817 reducing routing table explosion, 50-53
Candidate RPs (C-RPs), 788, 838 summarization, 41-50
Canonical Name (CNAME) records, 949 traffic engineering, 60-62
Capability field (ORF), 495 CIDR Report, 198
capability orf prefix-list statement, 419 Cisco Group Management Protocol
(CGMP), 749-753
capability statement, 419
Cisco Group Management Protocol
Catalysts CAM table, 750
(CGMP) messages, 819
C-BSRs (candidate bootstrap routers),
Class B addresses, reducing depletion
788, 849
(CIDR), 50
CBT (Core-Based Trees), 754, 771-772
Class D IPv4 addresses, multicast routing,
CGMP (Cisco Group Management 717-721
Protocol), 749-753
classful routing, 43
1086 classless inter-domain routing (CIDR)

classless inter-domain routing (CIDR), commands. See also statements


16, 41 address-family ipv4 multicast, 904
address portability, 58-59 address-family ipv4 unicast, 904
assigning IPv4 address blocks, 54-56 aggregate-address, 581
classless routing, 43-47 authentication {authentication-type}
limitations, 62-66 keychain {keychain-name}, 522
multihoming and provider-assigned bfd echo, 514
addresses, 56-58 bfd interval {milliseconds} min_rx
NAT resolution for multihomed {milliseconds} multiplier
environments, 939 {multiplier-value}, 514
provider-independent addresses, 59-60 bfd map ipv4, 523
reducing Class B address space bfd slow-timers, 514
depletion, 50 bfd template, 523
reducing routing table explosion, 50-53 bfd-template multi-hop, 523
summarization, 41-50 bfd-template single-hop, 522
traffic engineering, 60-62 bgp additional-paths install, 524
clear ip bgp 10.0.0.2 in prefix-filter bgp cluster-id, 602
command, 490
bgp confederation identifier, 579
clear ip bgp dampening command, 483
bgp confederation peers, 580
clear ip bgp flap-statistics command, 483
bgp dampening, 480
clear ip bgp {ip-address} command, 542
bgp graceful-restart, 540
clear ip nat translations command, 988
bgp nexthop trigger delay 0, 506
clear ipv6 nat translation command, 1017
bgp recursion host, 526
clients (IBGP), route reflection
bgp router mode, 498
clusters, 593
bgp upgrade-cli, 629-631
cluster-id attribute, 561
clear ip bgp 10.0.0.2 in prefix-filter, 490
cluster-id statement, 414
clear ip bgp dampening, 483
CLUSTER_LIST attribute, route reflection
clusters, 596 clear ip bgp flap-statistics, 483
clusters, route reflection, 593 clear ip bgp {ip-address}, 542
CLUSTER_LIST attribute, 596 clear ip nat translations, 988
configuration, 600-605 clear ipv6 nat translation, 1017
fully meshed clusters, 596 dampening, 522
interconnecting links, 606 debug, 864
nested clusters, 595 debug bgp ipv6 unicast updates in, 624
ORIGINATOR_ID attribute, 595 debug ip bgp, 110
peering relationship, 594 debug ip bgp rib-filter, 503
redundancy, 596-603 debug ip bgp updates, 488, 546
CNAME (Canonical Name) records, 949 debug ip egp transactions, 7-8
Code field, MLDv1 messages, 743 debug ip packet detail, 774
codes (ICMP), IPv4 to IPv6 debug ip pim auto-rp, 840
translation, 1002 debug ipv6 nat detail, 1014
commands 1087

echo, 522 ip pim sparse-dense-mode, 847


exit-address-family, 904 ip pim sparse-mode, 829
ha-mode graceful-restart, 540 ip pim spt-threshold, 806, 835
IGMP (Internet Group Management ip pim version, 809
Protocol), 818-819 ip routing, 818
interval min-tx {milliseconds} match interface, 978
min-rx {milliseconds} multiplier
match ip next-hop, 978
{multiplier-value}, 522
maximm-paths, 20
ip cgmp, 819
mrinfo, 865-867
ip cgmp proxy, 819
mstat, 869-872
ip default-gateway, 961
mtrace, 867-869
ip igmp version, 730, 818
neighbor 192.168.1.253 route-map
ip mroute, 861
COMMUNITY out, 203
ip msdp cache-sa-state, 897, 911
neighbor {IP_Address} capability orf
ip msdp default-peer, 923 prefix-list, 489
ip msdp filter-sa-request, 912 neighbor {IP-Address} fall-over bfd, 523
ip msdp mesh-group, 915 neighbor {IP-Address} ha-mode
ip msdp originator-id, 918 graceful-restart, 540
ip msdp peer, 908 neighbor next-hop-self, 581
ip msdp redistribute, 912 no address-family ipv4, 652
ip msdp sa-filter in, 912 no bgp client-to-client reflection, 606
ip msdp sa-filter out, 912 no bgp fast-external-fallover, 510
ip msdp sa-request, 898 no bgp nexthop trigger enable, 498
ip msdp ttl-threshold, 912 no ip default ipv4-unicast, 906
ip multicast boundary, 882 no ip mroute-cache, 819
ip multicast-routing, 818 no ip routing, 961
ip multicast ttl-threshold, 881 ow ip bgp rib-failure, 165
ip nat inside, 956 PASV, 952
ip nat inside source static, 957 PORT, 952
ip nat outside, 956 redistribute connected, 175
ip nat outside source static, 958 show, 864
ip nat translation max-entries, 987 show bfd neighbors [details], 515
ip nat translation timeout, 936, 968, 987 show bgp, 634
ip pim bsr-candidate, 814, 850, 854 show bgp all, 645
ip pim dense-mode, 819-821 show bgp all community, 672
ip pim message-interval, 795 show bgp all summary, 644
ip pim query-interval, 773 show bgp ipv4 unicast, 635
ip pim rp-address 10.224.1.1, 830 show bgp ipv4 unicast update-group, 556
ip pim rp-candidate, 850 show bgp ipv6 unicast, 634, 672
ip pim send-rp-announce, 838-841 show bgp summary, 120
ip pim send-rp-announce group-list, 849 show buffers, 569
1088 commands

show interfaces, 569 show ip route, 821, 864


show ip bgp, 19-20, 158, 434, 467, show ip route bgp, 653
506, 526 show ip route repair-paths, 526
show ip bgp 10.4.2.0, 467 show ip route summary, 556
show ip bgp 192.168.255.1 neighbor show ip spd, 569
advertised-routes, 530
show ipv6 interface, 647
show ip bgp community, 436-440, 467
show ipv6 nat translations, 1013
show ip bgp community-list, 441-443
show ipv6 route, 624, 634
show ip bgp community no-export,
show ipv6 route bgp, 653
204, 217
show logging, 137
show ip bgp dampened-paths, 482-483
show processes cpu, 552-556
show ip bgp flap-statistics, 482-483
show processes memory, 556
show ip bgp ipv4, 905
timers bgp, 20
show ip bgp ipv6 unicast community, 687
timers egp, 8
show ip bgp neighbor, 112, 490
w ip pim interface, 832
show ip bgp neighbors {IP-Address}, 543
communities
show ip bgp peer-groups, 407
MBGP policy configuration, identifying
show ip bgp replication, 556
prefixes, 667-672
show ip bgp rib-failures, 190
scaling BGP, 425
show ip bgp summary, 120, 506, 556
AA(colon)NN Format, 443-445
show ip bgp template peer-policy,
adding/deleting communities,
422-424
460-471
show ip bgp template peer-session,
arbitrary communities, 434-443
416-417
expanded community lists, 445-460
show ip bgp update-group, 172, 410-411
extended community lists, 472-478
show ip bgp update-group summary,
411-413 well-known communities, 426-433
show ip cef {ip-address}{mask} detail, 526 community lists, 438, 445-460, 472-478
show ip dvmrp route, 888 COMMUNITY path attribute,
NO_EXPORT option, 203
show ip igmp group, 777
concepts, NAT44 operation, 932-934
show ip igmp interface, 827
confederation EBGP, 576
show ip mroute, 776, 821, 864
confederation IDs, 576
show ip msdp peer, 910
confederations, scaling BGP network,
show ip nat statistics, 988
576-592
show ip nat translations verbose, 968
configuration scaling tools (BGP), 402
show ip pim bsr-router, 851
communities, 425
show ip pim neighbor, 775
adding/deleting communities,
show ip pim rp, 837, 841 460-471
show ip pim rp-hash, 844, 855 arbitrary communities, 434-445
show ip pim rp mapping, 793, 843 expanded community lists, 445-460
show ip pim rp mapping in-use, 844
Count field, CGMP packet format 1089

extended community lists, 472-478 MSDP, 908-913


well-known communities, 426-433 NAT44, 955
peer groups, 403-413 dynamic NAT case study, 964-969
peer templates, 413 ISP multihoming case study,
policy templates, 419-425 975-980
session templates, 414-418 network merger case study, 969-975
configuring PAT (Port Address Translation)
case study, 980-982
BFD slow timers, 514, 519-520
service distribution case study,
BGP peering, 110
984-986
BGP connection security case study,
static NAT case study, 955-962
136-142
TCP load balancing case study,
EBGP multihop case study, 127-135
982-984
EBGP peering case study, 110-114
NAT-PT (Network Address Translation
EBGP peering over IPv6 case study, with Port Translation), 1010-1028
114-118
NLRI in BGP, 155
IBGP peering case study, 118-127
injecting prefixes with
communities, 425 redistribution, 162-167
IP multicast routing, 817 injecting prefixes with the network
multicast load sharing, 856-862 mask statement, 160-161
PIM-DM (Protocol Independent injecting prefixes with the network
Multicast-Dense Mode), 819-828 statement, 156-160
PIM-SM (Protocol Independent route reflection clusters, 600-605
Multicast-Sparse Mode), stateful NAT64, 1041
828-855
stateless NAT64, 1036
MBGP, 902-908
connections (BGP), multiple externa
MBGP for IPv6, 619 neighbors, 77-79
case study, 666-705 ConnectRetry timer, 88
dual stack MBGP connection, Connect state (BGP finite state
642-647 machine), 89
IPv4 and IPv6 over an IPv6 TCP conservation of IP addresses, NAT44
connection, 631-641 operation, 934-937
Ipv4 and IPv6 prefixes over an IPv4 continue clauses, BGP policy
TCP session, 620-628 configuration, 403
mixed IPv4 and IPv6 sessions, convergence of BGP, PIC (Prefix
650-653 Independent Convergence), 523-538
multihop dual stack MBGP Core-Based Trees (CBTs), 754, 771-772
connection, 647-650
core gateways, 4
Multiprotocol IBGP, 654-666
core (shared router), 760
upgrading IPv4 BGP configurations
Cornell ISIS Project, IPv4 multicast
to the address family format,
address, 719
629-631
Count field, CGMP packet format, 753
1090 CPU utilization, scaling BGP

CPU utilization, scaling BGP, 552-556 destination addresses, reports, 728


C-RPs (Candidate RPs), 788, 838 detecting failures
Current-State Record field, IGMPv3 BFD (Bidirectional Forwarding
Group Record, 741 Detection). See BFD
Fast External Fallover. See Fast External
Fallover
D DF (Dont Fragment) bit set, 564
dampening command, 522 disable-connected-check statement, 414
Data field;BGP Notification messages, 108 discontiguous range of addresses,
configuring NAT, 980
dCEF (distributed CEF), 539
Discovery messages, RP, 790
dead neighbors (EGP), 10
Distance Vector Multicast Routing
de-aggregation, 57 Protocol (DVMRP), 754, 771-772
debug bgp ipv6 unicast updates in distance vector protocols, 17
command, 624
distributed CEF (dCEF), 539
debug capture, PIM messages, 773
distribute-list statement, 419
debug commands, 864
dmzlink-bw statement, 419
debug ip bgp command, 110
DNS Application Level Gateway
debug ip bgp rib-filter command, 503 (ALG), 964
debug ip bgp updates command, 488, 546 DNS (Domain Name System), NAT44
debug ip egp transactions command, 7-8 operation, 948-951
debug ip packet detail command, 774 DNS message format, 950-951
debug ip pim auto-rp command, 840 Domain Name System (DNS), NAT44
debug ipv6 nat detail command, 1014 operation, 948-951
decision process, BGP (Border Gateway domains, sparsely populated, 716
Protocol), 100-103 Dont Fragment (DF) bit set, 564
default-metric statement, 159 Down state (EGP neighbors), 6
default-originate statement, 419, 702 downstream interface, 755-756
default peers, MSDP (Multicast Source DR (designated routers), PIM-DM
Discovery Protocol), 923-925 (Protocol Independent Multicast-Dense
default routes, 182, 196-198 Mode), 782
default statement, 414, 419 dual Route Processors (RP), 539
deleting communities, scaling dual-stacked interfaces, 997
BGP, 460-471 dual stack MBGP connection, 642-647
Demand mode (BFD), 513 DVMRP (Distance Vector Multicast
dense topologies, multicast routing, 757 Routing Protocol), 754, 771-772
depletion of Class B addresses, reducing Graft messages, 888
with CIDR, 50 networks, multicast routing, 888-891
description statement, 414 Probe messages, 888-889
designated router (Querier), 728-729 Prune messages, 889-890
designated routers (DR), PIM-DM Report messages, 888
(Protocol Independent Multicast-Dense dynamic entries, NAT44, 934
Mode), 782
exterior EGP neighbors 1091

dynamic NAT, 964-969 Encoded Unicast RP Address field


dynamic one-to-one mapping, 1041 PIMv2 Bootstrap messages, 815
dynamic port mapping, 1041 PIMv2 Candidate-RP-Advertisement
dynamic update peer groups, 407-413 messages, 817
Encoded Unicast Source Address field
PIMv2 Assert messages, 816
E PIMv2 Register Stop messages, 812
EBGP (external Border Gateway Encoded Unicast Upstream Neighbor
Protocol), 22-29 Address field, PIMv2 Join/Prune
messages, 813
peering case study, 110-114, 127-135
encryption, NAT44 operation, 945
peering over IPv6 case study, 114-118
Enhanced IGRP (EIGRP), 3
ebgp-multihop statement, 414
Entry-Count field, MSDP Source Active
echo command, 522 TLV format, 898
Echo function (BFD), 513-514 Error Code field, BGP Notification
EGP (Exterior Gateway Protocol), 1 messages, 108
functions, 5 error codes, 108
Neighbor Acquisition Protocol, 6-8 Error Subcode field, BGP Notification
Neighbor Reachability Protocol, messages, 108
8-10 error subcodes, 108
Network Reachability Protocol, established keyword, 952
10-15 Established state (BGP finite state
limitations, 15-16 machine), 90
neighbors (peers), 3-4 Ethernet networks, multicast
origins, 2-3 addresses, 720
topology, 3-5 Ethernet switches, 31
EIGRP (Enhanced IGRP), 3 event-driven validation (NHT), 498
Embedded RP, 787-793 Exclude filters, Membership Report
Encoded Group Address field messages, 736
PIMv2 Assert messages, 816 exit-address-family command, 904
PIMv2 Candidate-RP-Advertisement exit-address-family statement, 623
messages, 817 exit-peer-policy statement, 419
PIMv2 Register Stop messages, 812 exit-peer-session statement, 415
Encoded Joined Source Address field, expanded community lists, scaling BGP,
PIMv2 Join/Prune messages, 813 445-460
Encoded Multicast Group Address field expanded keyword, 445
PIMv2 Bootstrap messages, 814 explicit joins, multicast routing, 758-759
PIMv2 Join/Prune messages, 813 extendable keyword, 979, 985
Encoded Pruned Source Address field, extended community lists, scaling BGP,
PIMv2 Join/Prune messages, 814 472-478
Encoded Unicast BSR Address field, extended NAT entries, 980
PIMv2 Bootstrap messages, 814 exterior EGP neighbors, 3
1092 Exterior Gateway Protocol (EGP)

Exterior Gateway Protocol (EGP), 1 MSDP Source Active TLV format, 898
functions, 5 PIMv2 Assert messages
Neighbor Acquisition Protocol, 6-8 Encoded Group Address, 816
Neighbor Reachability Protocol, Encoded Unicast Source Address,
8-10 816
Network Reachability Protocol, Metric, 816
10-15 Metric Preference, 816
limitations, 15-16 PIMv2 Bootstrap messages
neighbors (peers), 3-4 BSR Priority, 814
origins, 2-3 Encoded Multicast Group Address,
topology, 3-5 814
exterior gateways, 13 Encoded Unicast BSR Address, 814
exterior routing protocols, 1 Encoded Unicast RP Address, 815
external BGP (EBGP), 22-29 Fragment RP Count, 815
external Border Gateway Protocol (EBGP) Fragment Tag, 814
peering case study, 110-114, 127-135 Hash Mask Length, 814
peering over IPv6 case study, 114-118 RP Count, 814
external neighbors, BGP connections, RP Holdtime, 815
77-79 RP Priority, 815
PIMv2 Candidate-RP-Advertisement
F messages
Encoded Group Address, 817
failure detection Encoded Unicast RP Address, 817
BFD (Bidirectional Forwarding Holdtime, 817
Detection). See BFD Prefix Count, 817
Fast External Fallover. See Fast External Priority, 817
Fallover PIMv2 Hello messages
fall-over statement, 414 Option Length, 811
Fast External Fallover, 509-512 Option Type, 810
Fast Session Deactivation. See Fast Option Value, 811
External Fallover
PIMv2 Join/Prune messages
FC 904, 8
Encoded Joined Source
FIB (Forwarding Information Base), 539 Address, 813
fields Encoded Multicast Group
CGMP packets, 753 Address, 813
IGMPv2 message format, 737 Encoded Pruned Source
IGMPv3 Membership Query messages, Address, 814
739-740 Encoded Unicast Upstream
IGMPv3 Membership Report messages, Neighbor Address, 813
740 Number of Groups, 813
MSDP Source Active Request TLV Number of Joined Sources, 813
format, 899 Number of Pruned Sources, 813
functions 1093

PIMv2 message header MP_REACH_NLRI (type 14) attribute


Checksum, 810 AFI (Address Family
Type, 809 Identifier), 616
Version, 809 Next Hop Address, 617
PIMv2 Register messages Next Hop Address Length, 617
B (Border bit), 811 NLRI (Network Layer Reachability
Information), 617
Checksum, 811
SAFI (Subsequent Address Family
Multicast Data Packet, 812
Identifier), 616
N (Null-Register bit), 812
forwarder election, PIM-DM (Protocol
PIMv2 Register Stop messages Independent Multicast-Dense Mode),
Encoded Group Address, 812 782-784
Encoded Unicast Source Forwarding Information Base (FIB), 539
Address, 812 forward state, 758
File Transfer Protocol (FTP), NAT44 Four-Octet AS-Specific extended
operation, 951-953 communities, 477
filtering, mitigating adverse effects on fragmentation, 945, 1005-1007
memory utilization, 558
Fragment RP Count field, PIMv2
filter-list statement, 419 Bootstrap messages, 815
Filter-Mode-Change field, IGMPv3 Group Fragment Tag field, PIMv2 Bootstrap
Record, 741 messages, 814
finite state machine (BGP), 87 FTP (File Transfer Protocol), NAT44
Active state, 89 operation, 951-953
Connect state, 89 full IBGP mesh, 119
Established state, 90 fully meshed route reflection clusters, 596
Idle state, 88 functions
input events, 88 EGP (Exterior Gateway Protocol), 5
OpenConfirm state, 90 Neighbor Acquisition Protocol, 6-8
OpenSent state, 89 Neighbor Reachability Protocol,
flags, mroute, 808 8-10
flapping routes, 47 Network Reachability Protocol,
flood-and-prune protocols, 758 10-15
formats scaling BGP, 478
BGP messages, 103 BFD (Bidirectional Forwarding
Detection), 512-523
Keepalive messages, 108
CPU utilization, 552-556
Notification messages, 108
Fast External Fallover, 509-512
Open messages, 104
GR (Graceful Restart), 538-540
Update messages, 105-106
Maximum Prefixes, 540-552
CGMP packets, 753
NHT (Next-Hop Tracking), 496-509
DNS messages, 950-951
ORF (Outbound Route Filters),
extended communities, 477 486-496
IPv6 multicast addresses, 722
1094 functions

PIC (Prefix Independent group-list keyword, 842


Convergence), 523-538 group maintenance, multicast routing, 728
RFD (Route Flap Dampening), group membership, multicast routing, 724
479-486
group maintenance, 728
transport optimization, 563-569
joining and leaving groups, 726
tuning BGP memory, 556-563
join latency, 726-727
leave latency, 727
G multiple routers on a network, 728-729
Group Record field, IGMPv3 Membership
gateways (routers), 2 Report messages, 741
GDA field, CGMP packet format, 753 groups, multicast routing
GDA (Group Destination Address), 750 group maintenance, 728
ge keyword, BGP policy configuration, IGMP (Internet Group Management
403 Protocol), 729-741
General Query message, IGMv2, 732 joining and leaving groups, 726
General Query variant, IGMPv3 join latency, 726-727
Membership Query message, 738 leave latency, 727
global addresses, NAT44, 933 multiple routers on a network, 728-729
Graceful Restart (GR), 538-540 Group-Specific Query message,
Graft Ack messages IGMPv2, 733
PIMv2 format, 816 Group-Specific Query variant, IGMPv3
PIMv2 routers, 779 Membership Query message, 738
Graft messages, 759
DVMRP, 888
PIMv2 format, 816
H
PIMv2 routers, 779 half-life (RFD, accumulated penalties), 479
GR-aware routers, 539 ha-mode graceful-restart command, 540
GR-capable routers, 539 hash function, 789
GR (Graceful Restart), 538-540 Hash Mask Length field, PIMv2 Bootstrap
Group Address field messages, 814
IGMPv2 message format, 737 header checksums, NAT44 operation, 945
MLDv1 messages, 744 header translation, IPv4/IPv6, 999-1000
MSDP Source Active TLV format, 899 Hello interval, 6
Group address Prefix field, MSDP Source Hello keyword, 773
Active Request TLV format, 899 Hello messages, 8
Group-and-Source-Specific Query, PIMv2 format, 810-811
IGMPv3, 735 PIMv2 routers, 773
Group-and-Source-Specific Query variant, Option Length field, 811
IGMPv3 Membership Query
Option Type field, 810
message, 738
Option Value field, 811
Group Destination Address (GDA), 750
indirect EGP neighbors 1095

Hello protocols, BFD (Bidirectional IG (inside global) addresses, NAT44, 933


Forwarding Detection), 512-523 IGMP (Internet Group Management
hold-queue in statement, 568 Protocol), 729
holdtime IGMPv2 host functions, 730-731
Hello and Query messages, 773 IGMPv2 router functions, 731-735
Open messages, 86 IGMPv3, 735-736
Holdtime field interface commands, 818-819
BGP Open messages, 105 message formats, 736-739
PIMv2 Candidate-RP-Advertisement IGMPv1, 737-738
messages, 817 IGMPv2, 737
Host Membership Query (Type 1) IGMPv3, 738-739
messages, IGMPv1, 738
IGMPv3 Membership Query,
Host Membership Report (Type 2) 738-739
messages, IGMPv1, 738
IGMPv3 Membership Report,
hosts, multicast routing, 726-731 740-741
initiating the join, 726-727 IGMP Membership Report, 793
leave notifications, 727 IGMP/MLD Snooping, 745-749
reports, destination addresses, 728 IGMPv1, 730-738
hot-potato routing, 182 IGMPv2, 730
host functions, 730-731
I message format, 737
router functions, 731-733
IANA (Internet Assigned Numbers IGMPv3, 730, 735-736
Authority), 54, 476 Membership Query message format,
IBGP (internal Border Gateway 738-739
Protocol), 22-29 Membership Report message format,
clients and route reflection clusters, 593 740-741
NLRI and, 167 message format, 738-739
IGP synchronization, 179-182 IGP (interior gateway protocols), 3
managing prefixes, 168-179 synchronization, IBGP and, 179-182
peering case study, 118-127 I-H-U (I Hear You) messages, 8
scaling BGP network, 575-576 IL (inside local) addresses, NAT44, 933
ICANN (Internet Corporation of Assigned IMAP (Internet Message Access
Names and Numbers), 54 Protocol), 953
ICMP, NAT44 operation, 947 implicit joins, multicast routing, 758-759
ICMP/ICMPv6 translation, 1002-1004 implicit withdrawal, 534, 568
ICMP messages, IPv4 to IPv6 translation, inbound route filters (ORF), 489
1002 Include filters, Membership Report
identifier function (IP addresses), 67 messages, 736
Idle state (BGP finite state machine), 88 indexes, peer templates, 417
Idle state (EGP neighbors), 6 indirect EGP neighbors, 12
1096 infinity keyword

infinity keyword, 806 setting routing policy, 79-82


inheritance trust issues, 82-84
peer templates, 413 vector protocol, 17
policy templates, 419-422 versions, 16-17
session templates, 417-418 CIDR (classless inter-domain routing), 41
inherit peer-session statement, 415 address portability, 58-59
injecting prefixes, configuring NLRI assigning IPv4 address blocks,
in BGP 54-56
network mask statement, 160-161 classless routing, 43-47
network statement, 156-160 limitations, 62-66
redistribution, 162-167 multihoming and provider-assigned
in keyword, 197 addresses, 56-58
input events, BGP finite state machine, 88 provider-independent addresses,
59-60
input hold queue, 568
reducing Class B address space
inside global (IG) addresses, NAT44, 933
depletion, 50
inside local (IL) addresses, NAT44, 933
reducing routing table explosion,
Integrated Intermediate 50-53
System-to-Intermediate System
summarization, 41-42
(IS-IS), 3
summarization, 47-50
inter-as-hybrid statement, 419
traffic engineering, 60-62
inter-AS multicasting, 891-894
Exterior Gateway Protocol (EGP), 1
interconnecting links, route reflection
clusters, 606 functions, 5-15
inter-domain routing limitations, 15-16
BGP (Border Gateway Protocol), 16 origins, 2-3
advertising BGP NLRI into the local topology, 3-5
AS, 182-198 Interface E0, 883
AS_PATH attribute, 17-20 interface-level BFD configuration, 516
configuring and troubleshooting interior EGP neighbors, 3
peering, 110-142 interior gateway protocols (IGP), 3
configuring NLRI, 155-167 interior gateways, 13
connecting to multiple external internal Border Gateway Protocol (IBGP)
neighbors, 77-79
clients and route reflection clusters, 593
decision process, 100-103
NLRI and, 167
external versus internal BGP, 22-29
IGP synchronization, 179-182
finite state machine, 87-90
managing prefixes, 168-179
message formats, 103-108
peering case study, 118-127
message types, 85-87
scaling BGP network, 575-576
NLRI and IBGP, 167-182
Internet Assigned Numbers Authority
path attributes, 90-100 (IANA), 54
route aggregation, 198-218
IP multicast routing 1097

Internet Corporation of Assigned Names ip igmp query-interval statement, 732


and Numbers (ICANN), 54 ip igmp query-max-response-time
Internet exchange points (IXP), public statement, 732
peering, 30 ip igmp version 1 statement, 735
Internet Group Management Protocol ip igmp version command, 730, 818
(IGMP), 729
IP masquerading, 940-942
IGMPv2 host functions, 730-731
ip mroute command, 861
IGMPv2 router functions, 731-735
ip msdp cache-sa-state command,
IGMPv3, 735-736 897, 911
interface commands, 818-819 ip msdp default-peer command, 923
message formats, 736-739 ip msdp filter-sa-request command, 912
IGMPv1, 737-738 ip msdp mesh-group command, 915
IGMPv2, 737 ip msdp originator-id command, 918
IGMPv3, 738-739 ip msdp peer command, 908
IGMPv3 Membership Query, ip msdp redistribute command, 912
738-739
ip msdp redistribute statement, 912
IGMPv3 Membership Report,
ip msdp sa-filter in command, 912
740-741
ip msdp sa-filter out command, 912
Internet Message Access Protocol
(IMAP), 953 ip msdp sa-request command, 898
Internet routing table, 78 ip msdp sa-request statement, 912
internetwork, 2 ip msdp ttl-threshold command, 912
interval keyword, 841 ip multicast boundary command, 882
interval min-tx min-rx multiplier IP multicast routing, 713
command, 522 Anycast RP, 917-923
interval-vpn-client statement, 419 configuring MBGP, 902-908
intra-AS IP multicast routing configuring MSDP, 908-913
protocols, 754 implicit joins versus explicit joins,
in-use keyword, 844 758-759
I/O process (BGP), 554 intra-AS IP multicast routing protocols,
IP address conservation, NAT44 754
operation, 934-937 MSDP default peers, 923-925
ip bgp community command, 451 MSDP mesh groups, 913-915
ip bgp-community new-format multicast forwarding, 754-756
statement, 426 multicast route discovery, 756-757
ip bgp fast-external-fallover [permit | deny multicast scoping, 762
statement, 512 administrative scoping, 765-766
ip bgp new-format statement, 444-447 TTL scoping, 763-765
ip cgmp command, 819 requirements, 716-717
ip cgmp proxy command, 819 CGMP (Cisco Group Management
ip default-gateway command, 961 Protocol), 749-753
ip igmp querier-timeout statement, 733 group membership, 724-729
1098 IP multicast routing

IGMP (Internet Group Management source registration, 796-802


Protocol), 729-741 SPTs (shortest path trees), 803-808
IGMP/MLD Snooping, 745-749 troubleshooting, 863
IPv4 multicast addresses, 717-721 mrinfo command, 865-867
IPv6 multicast addresses, 721-724 mstat command, 869-872
MLD (Multicast Listener mtrace command, 867-869
Discovery), 742-746
ip multicast-routing statement, 903
scaling, 881
ip multicast ttl-threshold command, 881
connecting to DVMRP networks,
ip nat inside command, 956
888-891
ip nat inside source list statement, 965
inter-AS multicasting, 891-894
ip nat inside source statement, 977
multicasting across nonmulticast
domains, 885-887 ip nat inside source static commands, 957
scope, 881-884 ip nat outside command, 956
source-based trees versus shared trees, ip nat outside source static command, 958
759-761 ip nat pool statement, 965
sparse versus dense topologies, 757 ip nat translation command, 987
SSM (Source-Specific-Multicast), 761-762 ip nat translation max-entries
ip multicast-routing command, 818 command, 987
IP multicast routing protocols ip nat translation max-entries
statement, 968
configuring, 817
ip nat translation timeout command,
multicast load sharing, 856-862
936, 968, 987
PIM-DM (Protocol Independent
ip nat translation timeout statement, 968
Multicast-Dense Mode), 819-828
IP Next Generation (IPng), 41
PIM-SM (Protocol Independent
Multicast-Sparse Mode), IPng (IP Next Generation), 41
828-855 ip pim bsr-candidate command, 814,
PIM-DM (Protocol Independent 850, 854
Multicast-Dense Mode), 773 ip pim dense-mode command, 819-821
designated routers, 782 ip pim message-interval command, 795
forwarder election, 782-784 ip pim query-interval command, 773
PIMv2 messages, 773-779 ip pim rp-address 10.224.1.1
prune overrides, 779-781 command, 830
unicast route changes, 782 ip pim rp-candidate command, 850
PIM (Protocol Independent Multicast), ip pim send-rp-announce command, 838
771-773 ip pim send-rp-announce group-list
PIM-SM (Protocol Independent command, 849
Multicast-Sparse Mode), 785 ip pim sparse-dense-mode command, 847
PIMv2 messages, 786, 808-817 ip pim sparse-mode command, 829
RP (Rendezvous Point), 787-793 ip pim spt-threshold command, 806, 835
shared trees, 793-796 ip pim version command, 809
ip routing command, 818
Join/Prune messages 1099

ip spd headroom {value} statement, 569 IPv6-Address-Specific extended


IP subnets, 577 communities, 477
IPv4 IPv6 extended community attribute, 476
address blocks (CIDR), 54-56 ipv6 multicast boundary block source
statement, 885
multicast addresses, 717-721
ipv6 multicast boundary scope
IPv4-Address-Specific extended
statement, 884
communities, 477-478
ipv6 nat prefix statement, 1011
IPv4-embedded IPv6 addresses, stateless
NAT64, 1031 ipv6 nat statement, 1011
IPv4 extended community attribute, 476 ipv6 nat v4v6 source list statement, 1021
IPv4-Mapped IPv6 Address, 625 ipv6 nat v4v6 source statement, 1018
IPv4-to-IPv4 translation. See NAT44 ipv6 nat v6v4 pool v4Pool
statement, 1021
IPv4-to-IPv6 address translation.
See NAT64 ipv6 pim rp embedded statement, 793
IPv6, 66 IPv6 prefix list, 625
address family, MBGP support, 618-619 ipv6 route statement, 1036
challenges, 996 IPv6-to-IPv4 address translation.
See NAT64
configuring MBGP for, 619
ipv6 unicast-routing statement, 620, 632
case study, 666-705
ip virtual-reassembly statement, 956
dual stack MBGP connection,
642-647 IS-IS (Integrated Intermediate
System-to-Intermediate System), 3
IPv4 and IPv6 over an IPv6 TCP
connection, 631-641 ISP migration, NAT44 operation, 937-938
Ipv4 and IPv6 prefixes over an IPv4 IXP (Internet exchange peering), public
TCP session, 620-628 peering, 30
mixed IPv4 and IPv6 sessions,
650-653
multihop dual stack MBGP
J
connection, 647-650 joining groups, multicast routing, 726
Multiprotocol IBGP, 654-666 join latency, multicast routing, 726-727
upgrading IPv4 BGP configurations Join messages, PIMv2 routers, 775
to the address family format,
629-631 join packets (CGMP), 749
link-local address scope, 619 Join/Prune messages
multicast addresses, 721-724 PIMv2 format, 812-814
multicast networks, administrative PIMv2 routers, 775
scoping, 883 Encoded Joined Source Address
multicast scope values, 884 field, 813
peering case study, 114-118 Encoded Multicast Group Address
field, 813
site-local scope, 618
Encoded Pruned Source Address
IPv6 Address (AAAA) records, 949 field, 814
1100 Join/Prune messages

Encoded Unicast Upstream


Neighbor Address field, 813 L
Number of Groups field, 813
Label Switched Paths (LSPs), 474
Number of Joined Sources field, 813
LACNIC (Latin American and Caribbean
Number of Pruned Sources
Network Information Centre), 55
field, 813
Last Member Query interval, queries, 733
Latin American and Caribbean Network
K Information Centre (LACNIC), 55
leaf networks, 756
keepalive interval, 86 Leave Group (0x17) messages,
Keepalive messages (BGP), 20, 86, 108 IGMPv2, 737
Keepalive TLV (MSDP message), 900 Leave Group messages, IGMPv2, 731
keywords leave latency, multicast routing, 727
additive, 463 Leave messages, IGMP, 826
as-set, 214, 581 leave packets (CGMP), 749
expanded, 445 leaving groups, multicast routing, 726
extendable, 979, 985 le keyword, BGP policy configuration, 403
ge, 403 length field (BGP messages), 103
group-list, 842 limitations
Hello, 773 CIDR (classless inter-domain routing),
in, 197 62-66
infinity, 806 EGP (Exterior Gateway Protocol), 15-16
interval, 841 stateful NAT64, 1043
in-use, 844 stateless NAT64, 1038
le, 403 linear inheritance, session templates,
netmask, 966 417-418
never, 968 link-local address scope, IPv6, 619
out, 197 LIRs (Local Internet Registries), 55, 995
overload, 982 load balancing
prefix-length, 966 configuring NAT44, 982-984
rotary, 967 multihoming and, 36-37
Router-Query, 773 load distribution, NAT44 operation,
942-943
standard, 445
load sharing
summary-only, 203
multicast routing, 856-862
type match-host, 967
multihoming and, 36-37
type rotary, 984
local addresses, NAT44, 933
v4-mapped, 1021
local AS, advertising BGP NLRI, 182
warning-only, 542
local-as statement, 415
Membership Report message format, IGMPv3 1101

local connectivity, multihoming, 35 MBGP (Multiprotocol BGP), 615, 717


Local Internet Registries (LIRs), 55, 995 attributes, 616-618
Local-Node scope, multicast addresses, configuring for IPv6, 488, 619
723 case study, 666-705
LOCAL_PREF attributes, confederation dual stack MBGP connection,
EBGP, 581 642-647
LOCAL_PREF value, 101 IPv4 and IPv6 over an IPv6 TCP
locator function (IP addresses), 67 connection, 631-641
Loc-RIB, 100 Ipv4 and IPv6 prefixes over an IPv4
loop-free route exchange, 23-26 TCP session, 620-628
loop-free topology, 585 mixed IPv4 and IPv6 sessions,
650-653
LSPs (Label Switched Paths), 474
multihop dual stack MBGP
connection, 647-650
M Multiprotocol IBGP, 654-666
upgrading IPv4 BGP configurations
Mail Exchange (MX) records, 949 to the address family format,
Management Information Bases 629-631
(MIB), 953 PIM-SM inter-AS multicasting, 893-895
many-to-many applications, 716 support for IPv6 address family, 618-619
mapping agents, RP, 789 MBone (Multicast Backbone), 717
marker field (BGP messages), 103 TTL scopng thresholds, 763
match interface command, 978 TTL thresholds, 882
match ip next-hop command, 978 mechanisms, EGP (Exterior Gateway
maximum argument, Maximum Prefixes Protocol), 5
feature, 542 Neighbor Acquisition Protocol, 6-8
maximum-paths command, 20 Neighbor Reachability Protocol, 8-10
maximum-paths statement, 102, 605 Network Reachability Protocol, 10-15
Maximum Prefixes feature, scaling BGP, MED attribute, 177, 585
540-552 MED (MULTI_EXIT_DISC) value, 102
maximum-prefix statement, 419 member autonomous systems, 576
Maximum Response Delay field, MLDv1 member discovery, multicast groups, 726
messages, 743
Membership Queries, IGMP/MLD
Maximum Segment Size (MSS), 563 Snooping, 748
maximum suppress limit (RFD), 479 Membership Query (0x11) messages,
Max Response Code field, IGMPv3 IGMPv2, 737
messages, 739 Membership Query message format,
Max Response Time field, IGMPv2 IGMPv3, 738-739
message format, 737 Membership Query (type 130) messages
Max Response Time, queries, 731 (MLDv2), 744
MBGP (Multicast BGP), configuring, Membership Report message format,
902-908 IGMPv3, 740-741
1102 Membership Report messages, IGMPv2

Membership Report messages, IGMPv2, PIMv2, 773-809


730-731 Assert, 815
Membership Reports, IGMP/MLD Bootstrap, 814-815
Snooping, 748
Candidate-RP-Advertisement, 817
Membership Report (type 143) messages
Graft-Ack, 816
(MLDv2), 745-746
Graft, 816
memory, tuning BGP usage, 556-563
Hello, 810-811
merged networks, configuring NAT44,
969-975 Join/Prune, 812-814
mesh groups (MSDP), 913-915 PIMv2 message header format,
809-810
message cache, BGP update groups, 568
Register, 811
message formats
Register Stop, 812
BGP, 85, 103
message headers (BGP), 103
Keepalive, 108
messages
Notification, 108
BGP, 85, 103
Open, 104
Keepalive message format, 108
Update, 105-106
Notification message format, 108
IGMP (Internet Group Management
Protocol), 736 Open message format, 104
IGMPv1, 737-738 Update message format, 105-106
IGMPv2, 737 PIMv2, 773-809
IGMPv3, 738-739 Assert message format, 815
IGMP (Internet Group Management Bootstrap message format, 814-815
Protocol) Candidate-RP-Advertisement
IGMPv3 Membership Query message format, 817
message format, 738-739 Graft-Ack message format, 816
IGMPv3 Membership Report Graft message format, 816
message format, 740-741 Hello message format, 810-811
MLD (Multicast Listener Discovery), 743 Join/Prune message format,
MLDv1, 743-744 812-814
MLDv2 Membership Query PIMv2 message header format,
(type 130), 744 809-810
MLDv2 Membership Report Register message format, 811
(type 143), 745-746 Register Stop message format, 812
MSDP (Multicast Source Discovery Keepalive, 86
Protocol), 898 Notification, 87
Keepalive TLV, 900 Open, 85-86
Notification TLV, 900 Route Refresh, 85
Source Active Request TLV, 899 Update, 86-87
Source Active Response TLV, 900 message types (EGP), 5-6
Source Active TLV, 898-899 Metric field, PIMv2 Assert messages, 816
PIM, 773
multicasting 1103

Metric Preference field, PIMv2 Assert MP_REACH_NLRI (type 15)


messages, 816 (Multiprotocol Reachable NLRI)
MIB (Management Information attribute, 894
Bases), 953 MP_UNREACH_NLRI (type 15)
migration, ISP NAT44 operation, 937-938 (Multiprotocol Unreachable NLRI)
attribute, 616, 894
Minimum Route Advertisement Intervals
(MRAI), 485 MRAI (Minimum Route Advertisement
Intervals), 485
MLD (Multicast Listener Discovery), 742
mrinfo command, 865-867
message format, 743
mroute flags, 808
MLDv1 message format, 743-744
MSDP-based Anycast RP, 790
MLDv2 Membership Query (type 130)
message format, 744 MSDP (Multicast Source Discovery
Protocol)
MLDv2 Membership Report (type 143)
message format, 745-746 configuring, 908-913, 923-925
MLDv1 mesh groups, 913-915
message format, 743-744 message formats, 898
RFC 2710, 742 Keepalive TLV, 900
MLDv2 Notification TLV, 900
message format Source Active Request TLV, 899
Membership Query (type 130), 744 Source Active Response TLV, 900
Membership Report (type 143), Source Active TLV, 898-899
745-746 PIM-SM inter-AS multicasting, 894-898
RFC 3810, 742 MSS (Maximum Segment Size), 563
MODE_IS_EXCLUDE (Type 2) mstat command, 869-872
current-state record format, 741 mtrace command, 867-869
MODE_IS_INCLUDE (Type 1) multiaccess networks
current-state record format, 741
forwarder election, 782-784
MOSPF (Multicast OSPF), 754, 771-772
Prune Override mechanism, 796
mpackets (multicast packets), 834
Multicast Address field, IGMPv3 Group
MP-BGP (multi-protocol BGP), 22 Record, 741
MPLS (Multi-Protocol Label Switching), Multicast Backbone (MBone), 717
472-474
TTL scoping thresholds, 763
MP_REACH_NLRI (type 14)
TTL thresholds, 882
(Multiprotocol Reachable NLRI)
attribute, 616 Multicast BGP (MBGP), configuring,
902-908
AFI (Address Family Identifier), 616
multicast channels, 762
Next Hop Address, 617
Multicast Data Packet field, PIMv2
Next Hop Address Length, 617
Register messages, 812
NLRI (Network Layer Reachability
multicast forwarding, 754-756
Information), 617
multicasting, 713
SAFI (Subsequent Address Family
Identifier), 616 Anycast RP, 917-923
configuring MBGP, 902-908
1104 multicasting

configuring MSDP, 908-913 IGMP (Internet Group Management


MSDP default peers, 923-925 Protocol), 729-741
MSDP mesh groups, 913-915 IGMP/MLD Snooping, 745-749
scaling IPv4 multicast addresses, 717-721
connecting to DVMRP networks, IPv6 multicast addresses, 721-724
888-891 MLD (Multicast Listener
inter-AS multicasting, 891-894 Discovery), 742-746
IP multicast routing, 881 scaling, 881
multicasting across nonmulticast connecting to DVMRP networks,
domains, 885-887 888-891
scope, 881-884 inter-AS multicasting, 891-894
Multicast Listener Discovery (MLD), 742 multicasting across nonmulticast
domains, 885-887
message format, 743
scope, 881-884
MLDv1 message format, 743-744
source-based trees versus shared trees,
MLDv2 Membership Query (type 130)
759-761
message format, 744
sparse versus dense topologies, 757
MLDv2 Membership Report (type 143)
message format, 745-746 SSM (Source-Specific-Multicast), 761-762
multicast load sharing, 856-862 multicast routing protocols
Multicast OSPF (MOSPF), 754, 771-772 configuring, 817
multicast packets (mpackets), 834 multicast load sharing, 856-862
Multicast Reverse Path Forwarding, 757 PIM-DM (Protocol Independent
Multicast-Dense Mode), 819-828
multicast route discovery, 756-757
PIM-SM (Protocol Independent
multicast routing, 713
Multicast-Sparse Mode),
Anycast RP, 917-923 828-855
configuring MBGP, 902-908 PIM-DM (Protocol Independent
configuring MSDP, 908-913 Multicast-Dense Mode), 773
implicit joins versus explicit joins, designated routers, 782
758-759 forwarder election, 782-784
intra-AS IP multicast routing protocols, PIMv2 messages, 773-779
754
prune overrides, 779-781
MSDP default peers, 923-925
unicast route changes, 782
MSDP mesh groups, 913-915
PIM (Protocol Independent Multicast),
multicast forwarding, 754-756 771-773
multicast route discovery, 756-757 PIM-SM (Protocol Independent
multicast scoping, 762 Multicast-Sparse Mode), 785
administrative scoping, 765-766 PIMv2 messages, 786, 808-817
TTL scoping, 763-765 RP (Rendezvous Point), 787-793
requirements, 716 shared trees, 793-796
CGMP (Cisco Group Management source registration, 796-802
Protocol), 749-753 SPTs (shortest path trees), 803-808
group membership, 724-729
My Autonomous System field, BGP Open messages 1105

troubleshooting, 863-864 Multikit, 725


mrinfo command, 865-867 multilateral peering agreements, 30
mstat command, 869-872 Multiprotocol BGP (MBGP), 615, 717
mtrace command, 867-869 attributes, 616-618
multicast scoping, 762 configuring for IPv6, 488, 619
administrative scoping, 765-766 case study, 666-705
TTL scoping, 763-765 dual stack MBGP connection,
Multicast Source Discovery Protocol 642-647
(MSDP) IPv4 and IPv6 over an IPv6 TCP
configuring, 908-913 connection, 631-641
default peers, 923-925 Ipv4 and IPv6 prefixes over an IPv4
TCP session, 620-628
mesh groups, 913-915
mixed IPv4 and IPv6 sessions,
message formats, 898
650-653
Keepalive TLV, 900
multihop dual stack MBGP
Notification TLV, 900 connection, 647-650
Source Active Request TLV, 899 Multiprotocol IBGP, 654-666
Source Active Response TLV, 900 upgrading IPv4 BGP configurations
Source Active TLV, 898-899 to the address family format,
PIM-SM inter-AS multicasting, 894-898 629-631
multicast storm, 755 PIM-SM inter-AS multicasting, 893-895
multicast trees, 757-761 support for IPv6 address family, 618-619
MULTI_EXIT_DISC attributes, Multiprotocol IBGP, configuring MBGP,
confederation EBGP, 581 654-666
MULTI_EXIT_DISC (MED) attribute, 159 Multi-Protocol Label Switching (MPLS),
multihomed autonomous systems 472-474
configuring NAT44, 975-980 Multiprotocol Reachable NLRI MP_
REACH_NLRI (type 14) attribute, 616
NAT44 operation, 938-939
AFI (Address Family Identifier), 616
multihoming, 29
Next Hop Address, 617
BGP connections, 77-79
Next Hop Address Length, 617
CIDR and, 56-58
NLRI (Network Layer Reachability
load sharing and load balancing, 36-37
Information), 617
multiple AS (autonomous systems), 79
SAFI (Subsequent Address Family
provider-assigned (PA) addressing, 40 Identifier), 616
routing policies, 36 Multiprotocol Reachable NLRI (MP_
stub AS (autonomous systems), 31-36 REACH_NLRI (type15) attribute, 894
traffic control, 37 Multiprotocol Unreachable NLRI (MP_
transit AS (autonomous systems), 30-31 UNREACH_NLRI (type 15)) attribute,
616, 894
multihop BFD templates, configuring, 523
MX (Mail Exchange) records, 949
multihop dual stack MBGP connection,
647-650 My Autonomous System field, BGP Open
messages, 104
1106 name servers (DNS)

NAT64 (Network Address Translation


N IPv6/IPv4), 931
NAT-PT (Network Address Translation
name servers (DNS), 949 with Port Translation), 1007
NAPT (Network Address and Port configuring, 1010-1028
Translation), 940-942
obsoletion, 1029-1031
NAPT-PT (Network Address and Port
operation, 1008
Translation with Protocol Translation),
1010 SIIT (Stateless IP/ICMP Translation), 997
NAT44 (Network Address Translation fragmentation and PMTU,
IPv4/IPv4), 931 1005-1007
configuring, 955 header translation, 999-1000
dynamic NAT case study, 964-969 ICMP/ICMPv6 translation,
1002-1004
ISP multihoming case study,
975-980 Transport Layer header translation,
1006
network merger case study, 969-975
stateful NAT64, 1038
PAT (Port Address Translation)
case study, 980-982 configuring, 1041
service distribution case study, limitations, 1043
984-986 operation, 1038-1040
static NAT case study, 955-962 stateless NAT64, 1031
TCP load balancing case study, configuring, 1036
982-984 limitations, 1038
operation, 932 operation, 1031-1035
basic concepts, 932-934 nat64 enable statement, 1036, 1041
encryption, 945 nat64 prefix stateful statement, 1041
fragmentation issue, 945 nat64 prefix stateless statement, 1036
header checksums, 945 nat64 v4 pool statement, 1041
IP address conservation, 934-937 nat64 v6v4 list statement, 1041
ISP migration, 937-938 NAT (Network Address Translation), 41,
multihomed autonomous systems, 931
938-939 NAT44. See NAT44
PAT (Port Address Translation), NAT64. See NAT64
940-942
NAT (network address translator), 931
protocol-specific issues, 946-954
NAT-PT (Network Address Translation
security issues, 946 with Port Translation), 1007
TCP load distribution, 942-943 configuring, 1010-1028
virtual servers, 944 obsoletion, 1029-1031
troubleshooting, 986-988 operation, 1008
NAT-T (NAT Traversal) technique, 946
Network Interface Card (NIC), multicast-awareness 1107

NAT Traversal (NAT-T) technique, 946 neighbor {IP-Address} maximum-prefix


NDP (Neighbor Discovery Protocol), 723 statement, 542
neighbor 192.168.1.253 route-map neighbor {ip-address} transport
COMMUNITY out command, 203 path-mtu-discovery {enable|disable}
statement, 564
neighbor 192.168.1.253 send-community
statement, 203 neighbor next-hop-self command, 581
Neighbor Acquisition Confirm message, 6 neighbor next-hop-self statement, 177,
185, 403, 657-659, 672
Neighbor Acquisition Protocol, 6-8
neighbor password statement, 138, 403,
Neighbor Acquisition Refuse message, 7
657, 661
Neighbor Acquisition Request message, 6
Neighbor Reachability Protocol, 8-10
neighbor activate statement, 623
neighbor remote-as statement, 110-112,
neighbor AS, advertising a default route, 403, 621-623, 657
196-198
neighbor route-reflector-client
Neighbor Cease Acknowledgment, 7 statement, 601
Neighbor Cease message, 7 neighbor send-community statement, 425,
neighbor CLIENTS peer-group 435, 463-465
statement, 404 neighbor shutdown statement, 142
neighbor default-originate statement, neighbor timers, 86
196-197
neighbor ttl-security statement, 139
neighbor disable-connected-check
neighbor update-source statement, 126,
statement, 130, 135
185, 403, 649, 657
Neighbor Discovery Protocol (NDP), 723
neighbor version (BGP), 85
neighbor distribute-list statement,
nested route reflection clusters, 595
197, 211
netmask keyword, 966
neighbor ebgp multihop statement, 627
Network Address and Port Translation
neighbor ebgp-multihop statement,
(NAPT), 940-942
131, 649
Network Address and Port Translation
neighbor ebgp multi-hop statements, 403
with Protocol Translation (NAPT-PT),
neighbor inherit peer-session 1010
statement, 415
Network Address Translation (NAT), 41,
neighbor {ip-address} additional-paths 931
statement, 534
NAT44. See NAT44
neighbor {IP_Address} capability orf
NAT64. See NAT64
prefix-list command, 489
Network Address Translation with Port
neighbor {IP-Address} fall-over bfd
Translation (NAT-PT), 1007
command, 523
configuring, 1010-1028
neighbor {ip-address} fall-over bfd
statement, 514 obsoletion, 1029-1031
neighbor {ip-address} fall-over operation, 1008
statement, 512 network address translator (NAT), 931
neighbor {IP-Address} ha-mode Network Interface Card (NIC),
graceful-restart command, 540 multicast-awareness, 720
1108 Network Layer Reachability Information field, BGP Update messages

Network Layer Reachability Information Next Hop Address Length field,


field, BGP Update messages, 107 MP_REACH_NLRI (type 14)
Network Layer Reachability Information attribute, 617
(NLRI), 895 NEXT_HOP attribute
advertising BGP NLRI into the local BGP, 97, 100
AS, 182 confederation EBGP, 580
advertising a default route to a next-hop-self configuration, 100
neighboring AS, 196-198
next-hop-self statement, 419
distributing NLRI in a stub AS with
Next-Hop Tracking (NHT), 496-509
IBGP, 184-192
next-hop-unchanged statement, 419
distributing NLRI in a stub AS with
static routes, 193-195 NHT (Next-Hop Tracking), 496-509
redistributing BGP NLRI into the NIC (Network Interface Card),
IGP, 182 multicast-awareness, 720
configuring in BGP, 155 NLRI (Network Layer Reachability
Information), 895
injecting prefixes with
redistribution, 162-167 advertising BGP NLRI into the local
AS, 182
injecting prefixes with the network
mask statement, 160-161 advertising a default route to a
neighboring AS, 196-198
injecting prefixes with the network
statement, 156-160 distributing NLRI in a stub AS with
IBGP, 184-192
IBGP and, 167
distributing NLRI in a stub AS with
IGP synchronization, 179-182
static routes, 193-195
managing prefixes, 168-179
redistributing BGP NLRI into the
NLRI field, MP_REACH_NLRI (type 14) IGP, 182
attribute, 617
configuring in BGP, 155
Update messages, 86
injecting prefixes with
network mask statement, configuring redistribution, 162-167
NLRI in BGP, 160-161
injecting prefixes with the network
network merger (case study), configuring mask statement, 160-161
NAT44, 969-975
injecting prefixes with the network
Network Reachability Protocol, 10-15 statement, 156-160
network statement, 102 IBGP and, 167
creating an aggregate address under IGP synchronization, 179-182
BGP, 199
managing prefixes, 168-179
injecting prefixes, configuring NLRI in
NLRI field, MP_REACH_NLRI (type 14)
BGP, 156-160
attribute, 617
Network Time Protocol (NTP), IPv4
Update messages, 86
multicast address, 719
N (Null-Register bit) field, PIMv2 Register
never keyword, 968
messages, 812
Next Hop Address field, MP_REACH_
no address-family ipv4 command, 652
NLRI (type 14) attribute, 617
NO_ADVERTISE attribute, well-known
communities, 432-433
operation 1109

no bgp client-to-client reflection Number of Pruned Sources field, PIMv2


command, 606 Join/Prune messages, 813
no bgp fast-external-fallover Number of Sources field
command, 510 IGMPv3 Group Record, 741
no bgp nexthop trigger enable IGMPv3 Membership Query
command, 498 messages, 740
no bgp recursion host statement, 526
no bgp transport path-mtu-discovery
statement, 564 O
NO_EXPORT attribute
OG (outside global) addresses,
COMMUNITY path attribute, 203 NAT44, 934
well-known communities, 428-430 Old Host Present Timer, 734
no ip default ipv4-unicast command, 906 OL (outside local) addresses, NAT44, 934
no ip mroute-cache command, 819 one-to-many applications, 716
no ip nat service alg tcp dns online TV Guides, advertising multicast
statement, 964 groups, 724
no ip nat service alg udp dns Opaque extended communities, 477-478
statement, 964
OpenConfirm state (BGP finite state
no ip routing command, 961 machine), 90
no neighbor activate statement, 642 Open messages (BGP), 85-86, 104
nonmulticast domains, multicasting across, Open process (BGP), 554
885-887
OpenSent state (BGP finite state
Non-Stop Forwarding (NSF), 538 machine), 89
Non-Stop Routing (NSR), 540 Open Shortest Path First (OSPF), 3
no synchronization statement, 179 operation
Notification messages (BGP), 87, 108 NAT44, 932
Notification TLV (MSDP message), 900 basic concepts, 932-934
NSFnet, 15 encryption, 945
NSF (Non-Stop Forwarding), 538 fragmentation issue, 945
n-squared problem (IBGP), scaling BGP, header checksums, 945
575-576
IP address conservation, 934-937
NSR (Non-Stop Routing), 540
ISP migration, 937-938
NTP (Network Time Protocol), IPv4
multicast address, 719 multihomed autonomous systems,
938-939
Null-Register bit (Register messages), 798
PAT (Port Address Translation),
Number of Group Records field, IGMPv3 940-942
Membership Report messages, 740
protocol-specific issues, 946-954
Number of Groups field, PIMv2 Join/
Prune messages, 813 security issues, 946
Number of Joined Sources field, PIMv2 TCP load distribution, 942-943
Join/Prune messages, 813 virtual servers, 944
NAT-PT (Network Address Translation
with Port Translation), 1008
1110 operation

stateful NAT64, 1038-1040 path attributes, 17, 21, 36


stateless NAT64, 1031-1035 BGP (Border Gateway Protocol), 90-91
optional capabilities (BGP), Open AS_PATH, 17-20, 92-97
messages, 86 NEXT_HOP, 97, 100
optional nontransitive path attributes, 91 ORIGIN, 92
Optional Parameters field, BGP Open Weight, 100
messages, 105
Update messages, 86
Optional Parameters Length field, BGP
Path Attributes field, BGP Update
Open messages, 105
messages, 106
optional transitive path attributes, 90
path-attribute statement, 415
Option Length field, PIMv2 Hello
path diversity, multihoming and, 36
messages, 811
Path Identifier (Path ID), 534
Option Type field, PIMv2 Hello
messages, 810 Path ID (Path Identifier), 534
Option Value field, PIMv2 Hello Path MTU Discovery (PMTUD) feature,
messages, 811 564-567, 998, 1005-1007
ORF (Outbound Route Filters), 486-496 paths (BGP), Memory utilization, 558
ORIGINATOR_ID attribute, 561, 595 path vector routing protocol, 17
ORIGIN path attribute (BGP), 92 PAT (Port Address Translation)
OSPF (Open Shortest Path First), 3 configuring NAT44, 980-982
OSPFv3, configuring IPv4 and IPv6 NAT44 operation, 940-942
address families, 655 peer groups
outbound route filters (ORF), 489 creating, 404-407
Outbound Route Filters (ORF), 486-496 scaling BGP, 403-413
out keyword, 197 peering (BGP)
outside global (OG) addresses, agreements, 30
NAT44, 934 configuring and troubleshooting, 110
outside local (OL) addresses, NAT44, 934 BGP connection security case study,
overlapping routes, 208 136-142
overload keyword, 982 EBGP multihop case study, 127-135
ow ip bgp rib-failure command, 165 EBGP peering case study, 110-114
EBGP peering over IPv6 case study,
114-118
P IBGP peering case study, 118-127
peering points, 35
PA (provider-assigned addressing),
multihoming and, 40 route reflection clusters, 594
passive EGP neighbors, 8 peer RPF flooding, 896
password statement, 415 peers (EGP neighbors), 3-4
PASV command, 952 peer templates, scaling BGP, 413
policy templates, 419-425
session templates, 414-418
Pointer (PTR) records 1111

penalties, BGP process configuration, PIMv2 message header format,


479-486 809-810
permanent groups (multicast), 719 Register message format, 811
permit statement, 166 Register Stop message format, 812
phases, BGP decision process, 101 RP (Rendezvous Point), 787
PIC (Prefix Independent Convergence), Auto-RP protocol, 789-790
523-538 bootstrap protocol, 787-789
PIM-DM (Protocol Independent Embedded RP addresses, 790-793
Multicast-Dense Mode), 754, 771
shared trees, 793-796
configuring, 819-828
source registration, 796-802
designated routers, 782
SPTs (shortest path trees), 803-808
forwarder election, 782-784
PIM Source Specific Multicast
PIMv2 messages, 773-779 (PIM-SSM), 771
prune overrides, 779-781 PIM-SSM (Protocol Independent
unicast route changes, 782 Multicast, Source-Specific
PIM Multicast Border Router Multicast), 754
(PMBR), 892 PIMv2 (Protocol Independent Multicast
PIM (Protocol Independent Multicast), Version 2) messages, 773-786,
message formats, 773 808-809
PIM-SM Internet Draft, 892 Assert message format, 815
PIM-SM (Protocol Independent Bootstrap message format, 814-815
Multicast-Sparse Mode), 754, 771, 785 Candidate-RP-Advertisement message
configuring, 828-855 format, 817
inter-AS multicasting, 892 Graft-Ack message format, 816
MBGP (Multiprotocol BGP), Graft message format, 816
893-895 Hello message format, 810-811
MSDP (Multicast Source Discovery Join/Prune message format, 812-814
Protocol), 894-900 PIMv2 message header format, 809-810
RPF interfaces, 893 Register message format, 811
PIMv2 messages, 786, 808-809 Register Stop message format, 812
Assert message format, 815 PMBR (PIM Multicast Border
Bootstrap message format, 814-815 Router), 892
Candidate-RP-Advertisement PMI-SSM (PIM Source Specific
message format, 817 Multicast), 771
Graft-Ack message format, 816 PMTUD (Path MTU Discovery) feature,
Graft message format, 816 564-567, 998, 1005-1007
Hello message format, 810-811 Pointer (PTR) records, 949
Join/Prune message format,
812-814
1112 policy configuration

policy configuration Prefix Independent Convergence (PIC),


MBGP (Multiprotocol BGP), 666-705 523-538
identifying prefixes, 667-672 prefix leaking, 57
policy and session templates, Prefix Length field
677-685, 701 MSDP Source Active Request TLV
policy configuration statements, 660 format, 899
policy lists, 403 MSDP Source Active TLV format, 899
policy templates prefix-length keyword, 966
configuring BGP scalability, 419-425 prefix-length-size statement, 419
configuring MBGP, 677-685, 701 prefix lists
Poll interval, 6 BGP policy configuration, 403
Poll messages, 10 prefix-list statement, 419
POP (Post Office Protocol), 953 prepended AS numbers, 93
Port Address Translation (PAT) prerequisites, BFD operations, 513
configuring NAT44, 980-982 primary servers (DNS), 949
NAT44 operation, 940-942 Priority field, PIMv2
Candidate-RP-Advertisement
PORT command, 952
messages, 817
Postel, Jon, 54
private AS numbers, scaling BGP network,
Post Office Protocol (POP), 953 569-574
Prefix Count field, PIMv2 private peering, 30
Candidate-RP-Advertisement
private-use addresses, 618
messages, 817
Probe messages (DVMRP), 888-889
prefixes
Protocol Independent Multicast-Dense
identifying, MBGP policy configuration
Mode (PIM-DM), 754, 771
AS_PATH access lists, 672
configuring, 819-828
communities, 667-672
designated routers, 782
configuring NLRI in BGP
forwarder election, 782-784
injecting with network mask
PIMv2 messages, 773-779
statement, 160-161
prune overrides, 779-781
injecting with network statement,
156-160 unicast route changes, 782
injecting with redistribution, Protocol Independent Multicast (PIM),
162-167 message formats, 773
IPv6 multicast addresses, 721 Protocol Independent Multicast,
Source-Specific Multicast
managing in an IBGP topology, 168-179
(PIM-SSM), 754
memory utilization, 558
Protocol Independent Multicast-Sparse
prefix leaking, 57 Mode (PIM-SM), 754, 785
prefix lists configuring, 828-855
BGP policy configuration, 403 inter-AS multicasting, 892
prefix-list statement, 419 MBGP (Multiprotocol BGP),
893-895
queries 1113

MSDP (Multicast Source Discovery protocol-specific NAT44 operation,


Protocol), 894-900 946-947
RPF interfaces, 893 DNS, 948-951
PIMv2 messages, 786, 808-809 FTP, 951-953
Assert message format, 815 ICMP, 947
Bootstrap message format, 814-815 routing protocols, 953
Candidate-RP-Advertisement SMTP, 953
message format, 817 Traceroute, 953-954
Graft-Ack message format, 816 provider-assigned (PA) addressing
Graft message format, 816 CIDR and, 56-58
Hello message format, 810-811 multihoming and, 40
Join/Prune message format, provider-independent addresses, CIDR
812-814 and, 59-60
PIMv2 message header format, Prune messages, 758
809-810
DVMRP, 889-890
Register message format, 811
PIMv2 routers, 775
Register Stop message format, 812
Prune Override mechanism
RP (Rendezvous Point), 787
multiaccess networks, 796
Auto-RP protocol, 789-790
PIM-DM (Protocol Independent
bootstrap protocol, 787-789 Multicast Version 2), 779-781
Embedded RP addresses, 790-793 prune state, 758
shared trees, 793-796 PTR (Pointer) records, 949
source registration, 796-802 public IP addresses, mapping to private
SPTs (shortest path trees), 803-808 addresses. See NAT44
Protocol Independent Multicast Version 2 public peering, 30
(PIMv2), messages, 773-786, 808-809
Assert message format, 815
Bootstrap message format, 814-815
Q
Candidate-RP-Advertisement message QQIC (Queriers Query Interval Code)
format, 817 field, IGMPv3 Membership Query
Graft-Ack message format, 816 messages, 740
Graft message format, 816 QRV (Queriers Robustness Variable)
Hello message format, 810-811 field, IGMPv3 Membership Query
Join/Prune message format, 812-814 messages, 739
PIMv2 message header format, 809-810 Querier, 728-729
Register message format, 811 queries
Register Stop message format, 812 IGMPv2 messages, 731
protocols General Query, 732
intra-AS IP multicast routing Group-Specific Query, 733
protocols, 754 member discovery, multicast
addresses, 726
1114 query messages, PIMv2 routers

query messages, PIMv2 routers, 773 Register-Suppression timer, 798


Questions section, DNS message regular expressions, BGP policy
format, 950 configuration, 402
queue types, TCP messages, 568 remote-as statement, 415
remove-private-as statement, 419

R Rendezvous Point address, 722


Rendezvous Point (RP), 760
RD (route distinguisher), 474-476 Auto-RP protocol, 789-790
Reachability Information. See NLRI bootstrap protocol, 787-789
(Network Layer Reachability configuring Auto-RP, 837-845
Information) configuring sparse-dense mode, 845-849
Record Type field, IGMPv3 Group configuring the bootstrap protocol,
Record, 741 849-855
recursive lookup, 26 Embedded RP addresses, 790-793
redistribute bgp statement, 182 static configuration, 829-837
redistribute connected command, 175 rendezvous point trees (RPTs), 776
redistribution Report messages (DVMRP), 888
BGP NLRI into the IGP, 182 reports, destination addresses, 728
configuring NLRI in BGP, 162-167 requirements
redundancy IP multicast routing, 716
multihoming and, 36 CGMP (Cisco Group Management
route reflection clusters, 596-603 Protocol), 749-753
redundancy schemes, reducing risk of group membership, 724-729
access loss, 34 IGMP (Internet Group Management
Referral WHOIS Server (RWHOIS), 56 Protocol), 729-741
Refuse message, 7 IGMP/MLD Snooping, 745-749
Regional Internet Registries (RIR), 54, 995 IPv4 multicast addresses, 717-721
Register messages IPv6 multicast addresses, 721-724
PIMv2 format, 811 MLD (Multicast Listener
PIMv2 routers, 797 Discovery), 742-746
B (Border bit) field, 811 Rseaux IP Europens Network
Checksum field, 811 Coordination Centre (RIPE NCC), 55
Multicast Data Packet field, 812 reserved Class D multicast addresses, 719
N (Null-Register bit) field, 812 Reserved field
Register Stop messages CGMP packet format, 753
PIMv2 format, 812 MSDP Source Active TLV format, 898
PIMv2 routers, 798 Reserved (Resv) field
Encoded Group Address field, 812 IGMPv3 Membership Query
messages, 739
Encoded Unicast Source Address
field, 812 IGMPv3 Membership Report
messages, 740
router bgp statement 1115

Resource Records (RR), 949 6791, 1002


restart-interval argument, Maximum 6793, 3
Prefixes feature, 542 6996, 3
restrictions, configuring ORF feature, 495 7020, 54
reuse limit (RFD), 479 7346, 766, 883
Reverse Path Broadcasting (RPB), 756 7606, 893
Reverse Path Forwarding (RPF), 756, 821 7761, 806
RFCs RFD (Route Flap Dampening), 479-486
827, 2-3 RIB-failure, 190
888, 3 RIB (Routing Information Base), 19-20,
904, 3, 6 100-101, 539
1092, 15 RIID (RP Interface Identifier), 791-792
1105, 16 RIP-2, 3
1112, 730 RIPE NCC (Rseaux IP Europens
1163, 16 Network Coordination Centre), 55
1191, 564 RIPE recommendations, RFD (Route Flap
Dampening), 486
1267, 16
RIPng, 3
1631, 932
RIP (Routing Information Protocol), 3
1700, 720
RIR (Regional Internet Registries), 54, 995
1918, 618
Robustness Variable, query messages, 736
2236, 730-734
Rosen, Eric, 2
2283, 894-895
rotary keyword, 967
2365, 765, 882
route aggregation, 41-42, 198
2439, 479
aggregate-address statement, 201-206
2710, 742
AS_SET attribute, 210-218
2765, 998, 1038
ATOMIC_AGGREGATE and
3376, 730
AGGREGATOR attributes, 207-209
3810, 742
static routes, 199-200
3973, 773
route distinguisher (RD), 474-476
4456, 593
route filters, redistributing IGP routes into
4541, 748 BGP, 162
4601, 786 Route Flap Dampening (RFD), 479-486
4604, 736 route maps
4610, 790 BGP policy configuration, 403
4724, 538 MBGP policy configuration, 690, 696
4893, 3 route-map statement, 419
5059, 787 route policies, 21
5291, 486 Route Processors (RP), 539
5880, 512 router bgp hierarchy, 623
5881, 512 router bgp statement, 110
6145, 998, 1002, 1038
1116 route reflection cluster

route reflection cluster, 593 routing protocols, 1


CLUSTER_LIST attribute, 596 BGP (Border Gateway Protocol), 1
configuration, 600-605 advertising BGP NLRI into the local
fully meshed clusters, 596 AS, 182-198
interconnecting links, 606 AS_PATH attribute, 17-20
nested clusters, 595 configuring and troubleshooting
peering, 110-142
ORIGINATOR_ID attribute, 595
configuring NLRI, 155-167
peering relationship, 594
connecting to multiple external
redundancy, 596-603
neighbors, 77-79
route-reflector-client statement, 419
decision process, 100-103
route reflectors (RR)
external versus interior BGP, 22-29
effect on memory consumption, 559-563
finite state machine, 87-90
scaling BGP network, 592-606
MBGP (Multiprotocol BGP),
Route Refresh, 559 615-705
ROUTE-REFRESH messages message formats, 103-108
BGP, 85 message types, 85-87
ORF (Outbound Route Filters), 495 NLRI and IBGP, 167-182
router-id statement, 923 path attributes, 90-100
Router processes (BGP), 554 route aggregation, 198-218
Router-Query keyword, 773 scalability, 401-606
routers (gateways), 2 setting routing policy, 79-82
multicast routing trust issues, 82-84
IGMPv2, 731-733 vector protocol, 17
multicast forwarding, 754-756 versions, 16-17
multicast route discovery, 756-757 CIDR (classless inter-domain routing), 41
Non-Querier, 733 address portability, 58-59
Querier, 728-729 assigning IPv4 address blocks,
queries, 726-728 54-56
shared trees, 787-796 classless routing, 43-47
routes, BGP process configuration limitations, 62-66
ORF (Outbound Route Filters), 486-495 multihoming and provider-assigned
RFD (Route Flap Dampening), 479-486 addresses, 56-58
route servers, 12 provider-independent addresses,
Route Target (RT), 476 59-60
Routing Information Base (RIB), 19-20, reducing Class B address space
100-101, 539 depletion, 50
Routing Information Protocol (RIP), 3 reducing routing table explosion,
50-53
routing loops, 15
summarization, 41-50
traffic engineering, 60-62
scaling BGP 1117

configuring IP multicast routing, 817 RPF interfaces, PIM-SM inter-AS


multicast load sharing, 856-862 multicasting, 893-895
PIM-DM (Protocol Independent RPF (Reverse Path Forwarding), 756, 821
Multicast-Dense Mode), 819-828 RP Holdtime field, PIMv2 Bootstrap
PIM-SM (Protocol Independent messages, 815
Multicast-Sparse Mode), RP Interface Identifier (RIID), 791-792
828-855 RP mapping agents, 789
Exterior Gateway Protocol (EGP), 1 RP Priority field, PIMv2 Bootstrap
functions, 5-15 messages, 815
limitations, 15-16 RP (Rendezvous Point), 760
origins, 2-3 Auto-RP protocol, 789-790
topology, 3-5 bootstrap protocol, 787-789
NAT44 operation, 953 configuring Auto-RP, 837-845
PIM-DM (Protocol Independent configuring sparse-dense mode, 845-849
Multicast-Dense Mode), 773 configuring the bootstrap protocol,
designated routers, 782 849-855
forwarder election, 782-784 Embedded RP addresses, 790-793
PIMv2 messages, 773-779 static configuration, 829-837
prune overrides, 779-781 RP (Route Processors), GR feature, 539
unicast route changes, 782 RP-Set, 788
PIM (Protocol Independent Multicast), RPT (rendezvous point trees), 776
771-773 RR (Resource Records), 949
PIM-SM (Protocol Independent RR (route reflectors), effect on memory
Multicast-Sparse Mode), 785 consumption, 559-563
PIMv2 messages, 786, 808-817 RT (Route Target), 476
RP (Rendezvous Point), 787-793 rule of synchronization, 180-181
shared trees, 793-796 RWHOIS (Referral WHOIS Server), 56
source registration, 796-802
SPTs (shortest path trees), 803-808
troubleshooting IP multicast routing,
S
863-864
SAFI (Subsequent Address Family
mrinfo command, 865-867 Identifier), 616
mstat command, 869-872 SAP (Session Advertisement Protocol),
mtrace command, 867-869 725
routing tables, 14, 50-53, 66-68 SA (Source Active) messages, 896-898
RP Address field, MSDP Source Active scalability, defined, 402
TLV format, 898 scaling
RP-Announce messages, 790 scaling BGP, 401-402
RPB (Reverse Path Broadcasting), 756 BGP network, 569
RP Count field, PIMv2 Bootstrap 4-byte AS numbers, 574-575
messages, 814
confederations, 576-592
RP-Discovery messages, 790
1118 scaling BGP

IBGP and the n-squared problem, service distribution, configuring NAT44,


575-576 984-986
private AS numbers, 569-574 service-level agreements (SLAs), 31
route reflectors, 592-606 Session Advertisement Protocol (SAP),
configuration scaling tools, 402 725
communities, 425-478 session configuration statements, 660
peer groups, 403-413 Session Description Protocol (SDR), 725
peer templates, 413-425 session templates
functions, 478 BGP configuration, 661
BFD (Bidirectional Forwarding configuring BGP scalability, 414-418
Detection), 512-523 configuring MBGP, 677-685, 701
CPU utilization, 552-556 inheritance, 417-418
Fast External Fallover, 509-512 set comm-list delete statement, 465-467
GR (Graceful Restart), 538-540 set community none statement, 203,
Maximum Prefixes, 540-552 430-431, 468
NHT (Next-Hop Tracking), 496-509 set community statement, 425, 434,
460-462
ORF (Outbound Route Filters),
486-496 settlement-free peering, 30
PIC (Prefix Independent S field, IGMPv3 Membership Query
Convergence), 523-538 messages, 739
RFD (Route Flap Dampening), shared trees
479-486 routers, 787-796
transport optimization, 563-569 source-based trees versus, 759-761
tuning BGP memory, 556-563 source registration, 796-802
IP multicast routing, 881 Shared WHOIS Project (SWIP), 56
Scanner processes (BGP), 554 shortest path trees (SPTs), 776, 803-808
scoping (multicast scoping), 762 show bfd neighbors [details]
administrative scoping, 765-766 command, 515
IP multicast routing, 881-884 show bgp all command, 645
multicast addresses, 723 show bgp all community command, 672
TTL scoping, 763-765 show bgp all summary command, 644
SDR (Session Description Protocol), 725 show bgp command, 634
secondary servers (DNS), 949 show bgp ipv4 unicast command, 635
second-level domains (DNS), 949 show bgp ipv4 unicast update-group
command, 556
security, NAT44 operation, 946
show bgp ipv6 unicast command,
Selective RIB download, 563
634, 672
send-community statement, 419-429, 672
show bgp summary command, 120
send-label statement, 419
show buffers command, 569
sequence numbers
show commands, 864
BGP policy configuration, 403
show interfaces command, 569
inheritance statements, 422
show ip bgp 10.4.2.0 command, 467
SMTP (Simple Mail Transfer Protocol), NAT44 operationt 1119

show ip bgp 192.168.255.1 neighbor show ip pim bsr-router command, 851


advertised-routes command, 530 show ip pim neighbor commands, 775
show ip bgp command, 19, 20, 158, 207, show ip pim rp command, 837, 841
434, 467, 506, 526
show ip pim rp-hash command, 844, 855
show ip bgp community command,
show ip pim rp mapping command,
436-440, 467, 687
793, 843
show ip bgp community-list command,
show ip pim rp mapping in-use
441-443
command, 844
show ip bgp community no-export
show ip route bgp command, 653
command, 204, 217
show ip route command, 821, 864
show ip bgp dampened-paths command,
482-483 show ip route repair-paths command, 526
show ip bgp flap-statistics command, show ip route summary command, 556
482-483 show ip spd command, 569
show ip bgp ipv4 command, 905 show ipv6 interface command, 647
show ip bgp ipv6 unicast community show ipv6 nat translations command,
command, 687 1013
show ip bgp neighbor command, 112, 490 show ipv6 route bgp command, 653
show ip bgp neighbors {IP-Address} show ipv6 route command, 624, 634
command, 543 show logging command, 137
show ip bgp peer-groups command, 407 show processes cpu command, 552-556
show ip bgp replication command, 556 show processes memory command, 556
show ip bgp rib-failures command, 190 shutdown statement, 415
show ip bgp summary command, 120, SIIT (Stateless IP/ICMP Translation),
506, 556 997-999
show ip bgp template peer-policy fragmentation and PMTU, 1005-1007
command, 422-424 header translation, 999, 1000
show ip bgp template peer-session ICMP/ICMPv6 translation, 1002-1004
command, 416-417
Transport Layer header translation, 1006
show ip bgp update-group command, 172,
Simple Mail Transfer Protocol (SMTP),
410-411
NAT44 operation, 953
show ip bgp update-group summary
Simple Network Management Protocol
command, 411-413
(SNMP), NAT44 operation, 953
show ip cef {ip-address}{mask} detail
single-hop BFD templates, configuring,
command, 526
522
show ip dvmrp route command, 888
site-local scope, private-use
show ip igmp group command, 777 addresses, 618
show ip igmp interface command, 827 SLAs (service-level agreements), 31
show ip mroute command, 776, 821, 864 slow-peer statement, 419
show ip msdp peer command, 910 slow start policy, RIRs, 55
show ip nat statistics command, 988 slow timers (BFD), configuring, 514-520
show ip nat translations verbose SMTP (Simple Mail Transfer Protocol),
command, 968 NAT44 operation, 953
1120 SNMP (Simple Network Management Protocol)

SNMP (Simple Network Management stateful NAT64, 1038


Protocol), NAT44 operation, 953 configuring, 1041
snooping, IGMP/MLD Snooping, 745-749 limitations, 1043
SOA (Start-of-Authority) records, 949 operation, 1038-1040
soft-reconfiguration statement, 419 Stateless IP/ICMP Translation (SIIT), 997
Solicited-Node multicast addresses, fragmentation and PMTU, 1005-1007
723-724
header translation, 999-1000
sorted argument, show processes cpu
ICMP/ICMPv6 translation, 1002-1004
command, 552
Transport Layer header translation, 1006
Source Active Request TLV (MSDP
message), 899 stateless NAT64
Source Active Response TLV (MSDP configuring, 1036
message), 900 limitations, 1038
Source Active (SA) messages, 896-898 operation, 1031-1035
Source Active TLV (MSDP message), statements. See also commands
898-899 accept-route-policy-rt, 419
source Address field, MSDP Source Active additional-paths, 419
TLV format, 899 address-family ipv6, 623
Source Address field advertise, 419
IGMPv3 Group Record, 741 advertise-map, 419
IGMPv3 Membership Query advertisement-interval, 419
messages, 740
aggregate-address, 199, 201
source-based trees, shared trees versus,
allowas-in, 414, 419
759-761
allow-policy, 419
source filtering, IGMPv2 versus IGMPv3,
735-736 as-override, 419
Source-List-Change Record field, IGMPv3 bgp addditional-paths select best
Group Record, 741 {number}, 534
source networks, 12 bgp additional-paths, 534
source registration, PIM-SM, 796-802 bgp additional-paths select all, 534
Source-Specific Multicast (SSM), 736 bgp additional-paths select group-best,
534
Source-Specific-Multicast (SSM), 761-762
bgp always-compare-med, 591
sparse-dense mode (PIM), 845-849
bgp bestpath med confed, 592
sparsely-populated domains, 716
bgp deterministic-med, 591
sparse topologies, multicast routing, 757
bgp nexthop trigger delay, 498
SPTs (shortest path trees), PIM-SM, 776,
803-808 bgp suppress-inactive, 166
SSM (Source-Specific-Multicast), bmp-activate, 414
736, 761-762 buffer small permanent {value}, 569
standard community lists, 438-440 capability, 419
standard keyword, 445 capability orf prefix-list, 419
Start-of-Authority (SOA) records, 949 cluster-id, 414
default, 414, 419
statements 1121

default-metric, 159 ipv6 nat v6v4 pool v4Pool, 1021


default-originate, 419, 702 ipv6 pim rp embedded, 793
description, 414 ipv6 route, 1036
disable-connected-check, 414 ipv6 unicast-routing, 620, 632
distribute-list, 419 ip virtual-reassembly, 956
dmzlink-bw, 419 local-as, 415
ebgp-multihop, 414 maximum-paths, 605
ess-family ipv4, 629 maximum-prefix, 419
exit-address-family, 623 nat64 enable, 1036
exit-peer policy, 419 nat64 prefix stateful, 1041
exit-peer-session, 415 nat64 prefix stateless, 1036
fall-over, 414 nat64 v4 pool, 1041
filter-list, 419 nat64 v6v4 list, 1041
hold-queue {value} in, 568 neighbor 192.168.1.253 send-community,
inherit peer-session, 415 203
inter-as-hybrid, 419 neighbor activate, 623
interval-vpn-client, 419 neighbor CLIENTS peer-group, 404
ip bgp-community new-format, 426 neighbor default-originate, 196-197
ip bgp fast-external-fallover [permit | neighbor distribute-list, 197, 211
deny, 512 neighbor ebgp multi-hop, 403
ip bgp new-format, 444-447 neighbor ebgp multihop, 627
ip igmp querier-timeout, 733 neighbor ebgp-multihop, 649
ip igmp query-interval, 732 neighbor inherit peer-session, 415
ip igmp query-max-response-time, 732 neighbor {ip-address} additional-paths,
ip igmp version 1, 735 534
ip msdp redistribute, 912 neighbor {ip-address} fall-over, 512
ip msdp sa-request, 912 neighbor {ip-address} fall-over bfd, 514
ip multicast-routing, 903 neighbor {IP-Address} fall-over bfd, 516
ip nat inside source, 977 neighbor {IP-Address} maximum-prefix
{maximum}, 542
ip nat inside source list, 965
neighbor {ip-address} transport
ip nat pool, 965
path-mtu-discovery {enable|disable},
ip nat translation max-entries, 968 564
ip nat translation timeout, 968 neighbor next-hop-self, 177, 185, 403,
ip spd headroom {value}, 569 657-659, 672
ipv6 multicast boundary block neighbor password, 403, 657, 661
source, 885 neighbor remote-as, 403, 621-623, 657
ipv6 multicast boundary scope, 884 neighbor route-reflector-client, 601
ipv6 nat, 1011 neighbor send-community, 425, 435,
ipv6 nat prefix, 1011 463-465
ipv6 nat v4v6 source, 1018 neighbor update-source, 185, 403,
ipv6 nat v4v6 source list, 1021 649, 657
1122 statements

network, 156-160, 199 unsuppress-map, 419


network mask, 160-161 update-source, 415
next-hop-self, 419 validation, 419
next-hop-unchanged, 419 version, 415
no bgp recursion host, 526 weight, 419
no bgp transport path-mtu-discovery, 564 static entries (NAT44), 934, 955-962
no ip nat service alg tcp dns, 964 static one-to-one mapping, 1041
no ip nat service alg udp dns, 964 static routes
no neighbor activate, 642 configuring MBGP for IPv6, 622
no synchronization, 179 distributing NLRI in a stub AS, 193-195
password, 415 route aggregation, 199-200
path-attribute, 415 single-homed AS, 31
permit, 166 stub AS (autonomous systems), 21-22
policy configuration, 660 distributing NLRI in a stub AS with IBGP,
prefix-length-size, 419 184-192
prefix-list, 419 distributing NLRI in a stub AS with static
routes, 193-195
redistribute bgp, 182
multihoming, 31-36
remote-as, 415
stub gateways, 4
remove-private-as, 419
Sub-AFI (Subsequent AFI), 895
route-map, 419
subautonomous systems, 576
route-reflector-client, 419
subcodes (error subcodes), 108
router-id, 923
subdelegation, 57
send-community, 419, 425-429, 672
Subsequent Address Family Identifier
send-label, 419
(SAFI), 616
session configuration, 660
Subsequent AFI (Sub-AFI), 895
set comm-list delete, 465-467
Subtype field, extended communities, 476
set community, 425, 434, 460-462
summarization, 41-50, 199
set community none, 203, 430-431, 468
summary-only keyword, 203
shutdown, 415
summary-only option, aggregate-address
slow-peer, 419 statement, 202
soft-reconfiguration, 419 SUN NIS+, IPv4 multicast address, 719
template peer-policy, 419 suppress limit (RFD), 479
template peer-session, 414-415 SWIP (Shared WHOIS Project), 56
timers, 415 switched networks, multicast routing,
translate-update, 415 746-749
transltate-topology, 419 synchronization rule, 180-181
transport, 415 system buffers, TCP messages, 569
ttl-security, 415
transport statement 1123

traceroute, NAT44 operation, 953-954


T traffic control, multihoming and, 37
traffic engineering, CIDR and, 60-62
TCP ACK message receipt, optimization,
568-569 transient groups (multicast), 719
TCP load balancing, configuring NAT44, transit AS (autonomous systems),
982-984 21-22, 30-31
TCP load distribution, NAT44 operation, Transitive (T) flag, 476
942-943 translate-update statement, 415
TCP optimization, 563-568 translation (IPv4 to IPv6)
TCP peering, MSDP and, 896 NAT-PT (Network Address Translation
TCP (port 179), BGP and, 17 with Port Translation), 1007
TCP Window Size, 563, 567 configuration, 1010-1028
template peer-policy statement, 419 obsoletion, 1029-1031
template peer-session statement, 414-415 operation, 1008
templates, BFD RFCs, 999
configuring multihop BFD templates, 523 SIIT (Stateless IP/ICMP Translation),
997-998
configuring single-hop BFD templates,
522 header translation, 999-1000
text descriptions (prefix lists), BGP policy ICMP/ICMPv6 translation,
configuration, 403 1002-1004
third-party EGP neighbors, 12 stateful NAT64, 1038
threshold, Maximum Prefixes feature, 541 configuration, 1041
timeouts, troubleshooting NAT44, 987 limitations, 1043
timers bgp command, 20 operation, 1038-1040
timers bgp configurtion statement, 86 stateless NAT64, 1031
timers egp command, 8 configuration, 1036
timers statement, 415 limitations, 1038
timestamps, 110 operation, 1031-1035
TLV (Type/Length/Value) format, MSDP translation timeout, NAT44, 936
messages, 898 translators, 997
Keepalive TLV, 900 translate-topology statement, 419
Notification TLV, 900 Transport Layer header translation, 1006
Source Active Request TLV, 899 transport optimization, scaling BGP, 563
Source Active Response TLV, 900 optimizing BGP UPDATE messages, 568
Source Active TLV, 898-899 optimizing TCP, 563-568
top-level domains (DNS), 949 optimizing TCP ACK message receipt,
topology, EGP (Exterior Gateway 568-569
Protocol), 3-5 transport statement, 415
Total Path Attribute Length field, BGP
Update messages, 106
1124 troubleshooting

troubleshooting Notification TLV, 900


BGP peering, 110 Source Active Request TLV, 899
BGP connection security case study, Source Active Response TLV, 900
136-142 Source Active TLV, 898-899
EBGP multihop case study, 127-135 type match-host keywords, 967
EBGP peering case study, 110-114 type rotary keywords, 984
EBGP peering over IPv6 case study,
114-118
IBGP peering case study, 118-127 U
IP multicast routing, 863
ULA (Unique Local Address) format, 619
mrinfo command, 865-867
unicasting, 713-715
mstat command, 869-872
unicast messages, 4
mtrace command, 867-869
Unicast Reverse Path Forwarding
NAT44, 986-988 (uRPF), 757
TRPB (Truncated Reverse Path unicast routing tables, PIM-DM (Protocol
Broadcast), 756 Independent Multicast-Dense
trust issues, BGP routing policies, 82-84 Mode), 782
TTL scoping, 763-765, 881 Unicast Source Address (USA), 750
ttl-security statement, 415 unidirectional trees, 797
TTL thresholds, MBone, 882 Unique Local Address (ULA) format, 619
T (Transitive) flag, 476 unsolicited updates, 12
tuning BGP memory, 556-563 unsuppress-map statement, 419
tunnel connectivity update churn, 47
DVMRP networks, 888-890 update groups, 407
multicasting across nonmulticast domains, message cache, 568
885-887 tuning CPU utilization og BGP
tunnels, 997 processes, 556
Two-Octet AS-Specific extended Update messages (BGP), 86-87
communities, 477-478 format, 105-106
Type field, 103 optimization, 568
CGMP packet format, 753 update-source statement, 415
extended communities, 476 upper-layer header support, IPv4 to IPv6
IGMPv1 message format, 738 translation, 1006
IGMPv2 message format, 737 upstream interface, 755-756
MLDv1 messages, 743 uRPF (Unicast Reverse Path
PIMv2 message header, 809 Forwarding), 757
Type/Length/Value (TLV) format, MSDP USA field, CGMP packet format, 753
messages, 898
Keepalive TLV, 900
zone transfer (DNS) 1125

USA (Unicast Source Address), 750


user (customer) peering, 30
W
warning-only keyword, 542
V web-based schedules, advertising multicast
groups, 724
v4-mapped keyword, 1021 Weight path attribute (BGP), 100
v6-Routes (IPv6 prefix list), 625 weight statement, 419
validation statement, 419 well-known communities, scaling BGP,
Value field, extended communities, 476 426-433
vector protocols, BGP (Border Gateway well-known discretionary path
Protocol), 17 attributes, 90
Version 1 Membership Report (0x12) well-known mandatory path attributes, 90
messages, IGMPv2, 737 w ip pim interface command, 832
Version 2 Membership Report (0x16) withdrawn routes, Update messages, 86
messages, IGMPv2, 737 Withdrawn Routes field, BGP Update
Version field messages, 106
BGP Open messages, 104 Withdrawn Routes Length field, BGP
CGMP packet format, 753 Update messages, 106
IGMPv1 message format, 738
PIMv2 message header, 809
version statement, 415
XZ
Virtual Private LAN Service (VPLS), 31 zones (DNS name servers), 949
Virtual Private Networks (VPNs), MPLS zone transfer (DNS), 949
and, 474
Virtual Routing and Forwarding tables
(VRFs), 474
virtual servers, NAT44 operation, 944
VPLS (Virtual Private LAN Service), 31
VPNs (Virtual Private Networks), MPLS
and, 474
VRFs (Virtual Routing and Forwarding
tables), 474

Оценить