Configuring BGP On Cisco Routers

BGP
Configuring BGP on
Cisco Routers
Volumes 1 & 2
Version 3.2
Student Guide
CLS Production Servies: 12.29.05
Copyright
2005, Cisco Systems, Inc. All rights reserved.
Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax
numbers are listed on the Cisco Website at www.cisco.com/go/offices.
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica
Croatia Cyprus Czech Republic Denmark Dubai, UAE Finland France Germany Greece
Hong Kong SAR Hungary India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia
Mexico The Netherlands New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania
Russia Saudi Arabia Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland
Taiwan Thailand Turkey Ukraine United Kingdom United States Venezuela Vietnam Zimbabwe
Copyright 2005 Cisco Systems, Inc. All rights reserved. CCSP, the Cisco Square Bridge logo, Follow
Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live,
Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST,
BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering
the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive,
GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard,
LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar,
Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView
Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are
registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0501R)
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED AS IS. CISCO MAKES AND YOU RECEIVE NO
WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY
OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO
SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING,
USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be
accurate, it falls subject to the disclaimer above.
Table of Contents
Volume 1
Course Introduction
Overview
Learner Skills and Knowledge
Course Goal and Objectives
Course Flow
Additional References
Cisco Glossary of Terms
Your Training Curriculum
BGP Overview
Overview
Module Objectives
Introducing BGP
Overview
Objectives
Interdomain Routing
Example: Why External Routing Protocols?
BGP Characteristics
Single-Homed Customers
Multihomed Customers
Transit Autonomous Systems
BGP Limitations
Summary
Understanding BGP Path Attributes

Overview
Objectives
BGP Path Attributes
Well-Known BGP Attributes
Optional BGP Attributes
AS-Path Attribute
Example: AS-Path Attribute
Next-Hop Attribute
Example: Next-Hop Attribute
Summary
Establishing BGP Sessions

Overview
Objectives
BGP Neighbor Discovery
Example: BGP Neighbor Discovery
Establishing a BGP Session
BGP Keepalives
Example: Keepalive Value
MD5 Authentication
Summary
Processing BGP Routes

Overview
Objectives
Receiving Routing Updates
Building the BGP Table
BGP Route Selection Criteria
Example: BGP Route Selection Criteria
BGP Route Propagation
1
1
2
3
4
5
5
6
1-1
1-1
1-1
1-3
1-3
1-3
1-4
1-6
1-8
1-12
1-14
1-16
1-17
1-18
1-19
1-19
1-19
1-20
1-21
1-24
1-26
1-27
1-28
1-29
1-32
1-33
1-33
1-33
1-34
1-35
1-37
1-40
1-41
1-42
1-43
1-45
1-45
1-45
1-46
1-48
1-49
1-51
1-52
Building the IP Routing Table

Advertising Local Networks
Example: Advertising Local Networks
Automatic Summarization
Example: Automatic Summarization
Summary
Configuring Basic BGP

Overview
Objectives
BGP Routing Process
router bgp
Configuring External Neighbors
neighbor remote-as
neighbor description
neighbor shutdown
Configuring BGP Timers
timers bgp
neighbor timers
Configuring MD5 Authentication
neighbor password
Announcing Networks in BGP
Example: Announcing Networks in BGP
Redistributing Routes into BGP
redistribute (IP)
distribute-list out (IP)
Configuring Classless BGP
network (BGP)
Example: Configuring Classless BGP
Aggregating BGP Networks
aggregate-address
Example: Aggregation
BGP Conditional Route Injection
bgp inject-map exist-map
BGP Support for TTL Security Check
neighbor ttl-security
Multihomed Customer Problem
Summary
Monitoring and Troubleshooting BGP

Overview
Objectives
Monitoring Overall BGP Routing
show ip bgp summary
Monitoring BGP Neighbors
show ip bgp neighbors
Monitoring the BGP Table
show ip bgp
Debugging BGP
BGP Session Startup Problems
BGP Neighbor Not Reachable
Example: BGP Neighbor Not Reachable
BGP Neighbor Not Configured
Example: BGP Neighbor Not Configured
BGP AS Number Mismatch
Example: BGP AS Number Mismatch
Summary
ii
Configuring BGP on Cisco Routers (BGP) v3.2
1-53
1-54
1-55
1-57
1-58
1-60
1-61
1-61
1-61
1-62
1-62
1-63
1-63
1-64
1-65
1-66
1-66
1-67
1-68
1-68
1-69
1-72
1-73
1-74
1-76
1-78
1-79
1-80
1-81
1-82
1-84
1-87
1-88
1-89
1-90
1-91
1-93
1-95
1-95
1-95
1-96
1-97
1-98
1-98
1-100
1-100
1-103
1-106
1-107
1-109
1-110
1-111
1-112
1-113
1-114
2005, Cisco Systems, Inc.
Module Summary
References
Module Self-Check
Module Self-Check Answer Key
1-115
1-116
1-117
1-126
BGP Transit Autonomous Systems
2-1
Overview
Module Objectives
2-1
2-1
Working with a Transit AS
2-3
Overview
Objectives
Transit AS Tasks
External Route Propagation
Internal Route Propagation
Packet Forwarding in an AS
Core Router IBGP Requirements in a Transit AS
Summary
2-3
2-3
2-4
2-5
2-6
2-7
2-8
2-9
Interacting with IBGP and EBGP in a Transit AS
2-11
Overview
Objectives
AS-Path Processing in IBGP
Multipath Load Sharing in BGP
maximum-paths ibgp
BGP Split Horizon
IBGP Full Mesh
Example: IBGP Full Mesh
IBGP Neighbors
IBGP Next-Hop Processing
Transit Network Using External Next Hops
Transit Network Using Edge Routers as Next Hops
neighbor next-hop-self
Example: Transit Network Using Edge Routers as Next Hops
Differences Between EBGP and IBGP Sessions
Example: Differences Between EBGP and IBGP Sessions
Summary
Forwarding Packets in a Transit AS
2-33
Overview
Objectives
Packet Forwarding in a Transit AS
Recursive Lookup in Cisco IOS Software
Routing Protocols in a Transit AS
BGP and IGP Interaction
Problems with BGP and IGP Interaction
Summary
2-33
2-33
2-34
2-36
2-38
2-40
2-42
2-43
Configuring a Transit AS
2-45
Overview
Objectives
Configuring IBGP Neighbors
neighbor remote-as
Configuring IBGP Sessions Between Loopback Interfaces
neighbor update-source
Configuring BGP Synchronization
synchronization
2-11
2-11
2-12
2-13
2-14
2-16
2-17
2-18
2-19
2-21
2-23
2-25
2-26
2-27
2-28
2-29
2-30
2-45
2-45
2-46
2-46
2-47
2-48
2-49
2-50
2-50
iii
Changing the Administrative Distance of BGP Routes

distance bgp
Scalability Limitations of IBGP-Based Transit Backbones
Summary
Monitoring and Troubleshooting IBGP in a Transit AS

Overview
Objectives
Monitoring IBGP
show ip bgp
Example: Monitoring IBGP
Common IBGP Problems
Troubleshooting IBGP Session Startup Issues
Troubleshooting IBGP Route Selection Issues
Troubleshooting IBGP Synchronization Issues
Summary
Module Summary
References
Module Self-Check
Route Selection Using Policy Controls

Overview
Module Objectives
Using Multihomed BGP Networks

Overview
Objectives
Business Requirements for Multihomed BGP Networks
Technical Requirements for Multihomed BGP Networks
BGP Route Selection Without BGP Policies
Example: BGP Route Selection Without BGP Policies
Multihomed Customer Routing Policies
Influencing BGP Route Selection
BGP Filters
Summary
Employing AS-Path Filters

Overview
Objectives
AS-Path Filtering Scenarios
AS-Path Regular Expressions
String Matching
Example: String Matching
Applying AS-Path Filters
Configuring BGP AS-Path Filters
ip as-path access-list
neighbor filter-list
Monitoring AS-Path Filters
show ip bgp regexp
show ip bgp filter-list
Summary
iv
2-51
2-51
2-53
2-54
2-55
2-55
2-55
2-56
2-56
2-57
2-58
2-60
2-61
2-64
2-65
2-66
2-67
2-68
2-69
2-75
3-1
3-1
3-2
3-3
3-3
3-3
3-4
3-5
3-6
3-7
3-8
3-9
3-11
3-14
3-15
3-15
3-15
3-16
3-18
3-19
3-26
3-29
3-30
3-30
3-31
3-33
3-35
3-36
3-37
Filtering with Prefix-Lists
3-39
Overview
Objectives
Requirements for Prefix-Based Filters
Prefix-Lists vs. IP Access-Lists
Configuring Prefix-Lists
ip prefix-list
Example: Configuring Prefix-Lists
BGP Filters Implementation
Implementing Prefix-Lists in the BGP Process
neighbor prefix-list
distribute-list out
Example: Filtering Customer Prefixes
Example: Filtering Peer Prefixes
Modifying Prefix-Lists
Monitoring Prefix-Lists
show ip prefix-list
Summary
3-39
3-39
3-40
3-41
3-44
3-44
3-48
3-49
3-50
3-51
3-52
3-53
3-54
3-55
3-56
3-56
3-60
Using Outbound Route Filtering
3-61
Overview
Objectives
Outbound Route Filtering
Example: Inbound vs. Outbound Filtering
BGP Prefix-Based Outbound Route Filtering
Example: BGP Prefix-Based Outbound Route Filtering
Outbound Route Filter Message
Configuring Outbound Route Filtering
neighbor orf prefix-list
Monitoring Outbound Route Filtering
Summary
Applying Route-Maps as BGP Filters
3-75
Overview
Objectives
Route-Map Overview
BGP Route-Map Policy List Support
ip policy-list
match policy-list
show ip policy-list
Configuring Policy-List Examples
Configuring Route-Maps to Reference Policy-List Examples
Verifying BGP Route-Map Policy List Support
BGP Route-Map Continue
Route-Map Operation Without Continue Clauses
Route-Map Operation with Continue Clauses
continue
show route-map
BGP Route-Map Continue Clause Example Configuration
BGP Route-Map Continue Clause Verification Example
Prefix-List Use in Route-Maps
match ip address
match ip next-hop
match ip route-source
BGP Filters
Using Route-Maps as BGP Filters
Monitoring Route-Maps
Summary
3-61
3-61
3-62
3-63
3-64
3-65
3-66
3-69
3-69
3-72
3-73
3-74
3-75
3-75
3-76
3-80
3-81
3-81
3-82
3-82
3-83
3-83
3-85
3-85
3-86
3-87
3-87
3-88
3-89
3-90
3-90
3-91
3-91
3-93
3-94
3-96
3-100
v
Implementing Changes in BGP Policy

Overview
Objectives
Traditional Filtering Limitations
BGP Soft Reconfiguration
Example: Soft Reconfiguration and Memory Use
Cisco IOS Commands for Soft Reconfiguration
neighbor soft-reconfiguration
clear ip bgp
Monitoring Soft Reconfiguration
BGP Soft Reset Enhancement
Route Refresh
Example: Route Refresh
Using Route Refresh
clear ip bgp
Monitoring Route Refresh
Why Use Route-Maps as BGP Filters?
Summary
Module Summary
References
Module Self-Check
3-101
3-101
3-102
3-103
3-105
3-106
3-107
3-107
3-108
3-110
3-111
3-113
3-116
3-117
3-117
3-118
3-121
3-122
3-125
3-126
3-127
3-135
Volume 2
Route Selection Using Attributes
Overview
Module Objectives
Influencing BGP Route Selection with Weights

Overview
Objectives
Configuring Per-Neighbor Weights
neighbor weight
Example: Configuring Per-Neighbor Weights
Changing Weights with Route-Maps
Example: Changing Weights with Route-Maps
Monitoring BGP Route Selection and Weights
show ip bgp
Example: Monitoring BGP Route Selection and Weights
BGP Route Selection and Filtering Tools Summary
Summary
Setting BGP Local Preference

Overview
Objectives
Consistent Route Selection Within the AS
Example: Consistent Route Selection Within the AS
BGP Local Preference
Configuring Default Local Preference
Example: Configuring Default Local Preference
Configuring Local Preference with Route-Maps
Example: Configuring Local Preference with Route-Maps
Monitoring Local Preference
Example: Monitoring Local Preference
Summary
Using AS-Path Prepending

vi
4-1
4-1
4-1
4-3
4-3
4-3
4-4
4-5
4-7
4-7
4-9
4-11
4-12
4-13
4-13
4-14
4-16
4-17
4-19
4-19
4-19
4-20
4-23
4-24
4-27
4-28
4-29
4-30
4-31
4-32
4-36
4-37
Overview
Objectives
Return Path Selection in a Multihomed AS
AS-Path Prepending
Example: AS-Path Prepending
AS-Path Prepending Design Considerations
Configuring AS-Path Prepending
set as-path
Example: Configuring AS-Path Prepending
Monitoring AS-Path Prepending
AS-Path Filtering Concerns with AS-Path Prepending
BGP Hide Local-Autonomous System
neighbor local-as
Summary
4-37
4-37
4-38
4-42
4-43
4-45
4-47
4-47
4-49
4-50
4-52
4-55
4-55
4-57
Understanding BGP Multi-Exit Discriminators
4-59
Overview
Objectives
Selecting the Proper Return Path
MED Propagation in a BGP Network
Changing the Default MED
default-metric (BGP)
Changing the MED with Route-Maps
Example: Changing the MED with Route-Maps
Advanced MED Configuration
Example: Advanced MED Configuration
Monitoring the MED
Example: Monitoring the MED
Troubleshooting the MED
Summary
4-59
4-59
4-60
4-62
4-63
4-63
4-64
4-65
4-66
4-68
4-69
4-70
4-73
4-76
Addressing BGP Communities
4-77
Overview
Objectives
BGP Communities Overview
Using Communities
Example: Using Communities
Configuring BGP Communities
Configuring Route Tagging with BGP Communities
Example: Configuring Route Tagging with BGP Communities
Configuring Community Propagation
Example: Configuring Community Propagation
Defining BGP Community-Lists
Example: Defining BGP Community-Lists
BGP Named Community-Lists
ip-community-list
match community
set comm-list delete
Named Community List Examples
BGP Cost Community
set extcommunity cost
BGP Cost Community Configuration Example
BGP Link Bandwidth
bgp dmzlink-bw
neighbor dmzlink-bw
Example: BGP Link Bandwidth Configuration
BGP Support for Sequenced Entries in Extended Community Lists
ip extcommunity-list
4-77
4-77
4-79
4-80
4-83
4-84
4-85
4-86
4-88
4-89
4-90
4-91
4-93
4-94
4-94
4-95
4-96
4-97
4-98
4-98
4-100
4-101
4-102
4-102
4-103
4-104
4-106
4-107
vii
Sequenced Extended Community-List Entry Configuration: Example

Resequenced Extended Community-List Entry Configuration: Example
Sequenced Extended Community-List Entry Verification: Example
Matching BGP Communities with Route-Maps
Example: Matching BGP Communities with Route-Maps
Monitoring Communities
Summary
Module Summary
References
Module Self-Check
Customer-to-Provider Connectivity with BGP

Overview
Module Objectives
Understanding Customer-to-Provider Connectivity Requirements

Overview
Objectives
Customer Connectivity Types
Redundancy in Customer Connections
Customer-to-Provider Routing Schemes
Customer Routing
Addressing Requirements
Example: Addressing Requirements
AS Number Allocation
Summary
Implementing Customer Connectivity Using Static Routing
4-108
4-108
4-109
4-110
4-112
4-113
4-117
4-119
4-120
4-121
4-130
5-1
5-1
5-1
5-3
5-3
5-3
5-5
5-6
5-10
5-11
5-14
5-16
5-17
5-19
5-21
Overview
Objectives
Why Use Static Routing?
Characteristics of Static Routing
Example: Characteristics of Static Routing
Designing Static Route Propagation in a Service Provider Network
Example: Static Route Propagation
BGP Backup with Static Routes
Floating Static Routes with BGP
Load Sharing with Static Routes
Example: Load Sharing with Static Routes
Summary
5-21
5-21
5-23
5-24
5-26
5-27
5-29
5-33
5-38
5-41
5-44
5-45
Connecting a Multihomed Customer to a Single Service Provider
5-47
Overview
Objectives
Configuring BGP on Multihomed Customer Routers
Example: Configuring BGP on Multihomed Customer
Conditional Advertising in Multihomed Customer Networks
Example: Conditional Advertising in Multihomed Customer Networks
Configuring BGP on Service Provider Routers
Example: Configuring BGP on Service Provider Routers
Removing Private AS Numbers
neighbor remove-private-as
Example: Removing Private AS Numbers
BGP Support for Dual AS Configuration for Network AS Migrations
neighbor local-as
Dual-AS Configuration: Example
Dual-AS Confederation Configuration: Example
Replace-AS Configuration: Example
viii
5-47
5-48
5-49
5-51
5-52
5-53
5-54
5-56
5-57
5-58
5-59
5-60
5-61
5-62
5-63
5-63
Backup Solutions with BGP

Example: Primary/Backup Link Selection
Load Sharing with the Multihomed Customer
Load Sharing with BGP Multipath
maximum-paths
Load Sharing with EBGP Multihop
Example: Load Sharing with EBGP Multihop
Summary
5-64
5-65
5-66
5-67
5-67
5-69
5-71
5-72
Connecting a Multihomed Customer to Multiple Service Providers

Overview
Objectives
Configuring BGP for Multihomed Customers
Multihomed Customer Address Space Selection
Multihomed Customer AS Number Selection
AS Number Translation
Primary/Backup Link Selection
BGP Incoming Link Selection
Load Sharing with Multiple Providers
Summary
Module Summary
References
Module Self-Check
5-73
5-73
5-74
5-75
5-78
5-79
5-81
5-83
5-84
5-88
5-89
5-90
5-91
5-92
5-100
Scaling Service Provider Networks
6-1
Overview
Module Objectives
6-1
6-2
Scaling IGP and BGP in Service Provider Networks

Overview
Objectives
Common Service Provider Network
Route Propagation in Service Provider Networks
Scaling Service Provider Routing Protocols
Scaling Service Provider Addressing
Example: Scaling Service Provider Addressing
BGP Policy Accounting
bgp-policy
set traffic-index
Specifying the Match Criteria for BGP Policy Accounting: Example
Classifying the IP Traffic and Enabling BGP Policy Accounting: Example
Summary
Introducing Route Reflectors
6-3
6-3
6-3
6-4
6-8
6-12
6-15
6-16
6-17
6-18
6-18
6-19
6-19
6-20
6-21
Overview
Objectives
IBGP Scalability Issues in a Transit AS
Route Reflector Split-Horizon Rules
Redundant Route Reflectors
Route Reflector Clusters
Example: Route Reflector Clusters
Additional Route Reflector Loop-Prevention Mechanisms
Summary
6-21
6-21
6-22
6-24
6-27
6-29
6-31
6-32
6-33
Designing Networks with Route Reflectors
6-35
Overview
Objectives
Network Design with Route Reflectors
6-35
6-35
6-36
ix
Example: Network Design with Route Reflectors

Potential Network Issues
Hierarchical Route Reflectors
Example: Hierarchical Route Reflectors
Summary
6-38
6-39
6-40
6-41
6-42
Configuring and Monitoring Route Reflectors
6-43
Overview
Objectives
Route Reflector Backbone Migration
Configuring Route Reflectors
bgp cluster-id
neighbor route-reflector-client
Example: Configuring Route Reflectors
Monitoring Route Reflectors
show ip bgp
Summary
6-43
6-43
6-44
6-45
6-46
6-47
6-48
6-49
6-49
6-49
6-52
Introducing Confederations
Overview
Objectives
IBGP Transit AS Problems
Example: IBGP Transit AS Problems
Splitting a Transit AS with BGP Confederations
AS-Path Propagation Within the BGP Confederation
Example: AS-Path Propagation Within the BGP Confederation
AS-Path Processing in BGP Confederations
Intra-Confederation EBGP Session Properties
Summary
Configuring and Monitoring Confederations

Overview
Objectives
BGP Confederation Design Rules
Planning BGP Confederations
Configuring BGP Confederations
router bgp
bgp confederation identifier
bgp confederation peers
Example: Configuring BGP Confederations
Monitoring BGP Confederations
show ip bgp
Summary
Module Summary
References
Module Self-Check
Optimizing BGP Scalability
6-53
6-53
6-53
6-54
6-55
6-56
6-57
6-58
6-60
6-61
6-63
6-65
6-65
6-65
6-66
6-68
6-69
6-70
6-70
6-71
6-72
6-73
6-73
6-74
6-77
6-79
6-80
6-81
6-87
7-1
Overview
Module Objectives
7-1
7-1
Improving BGP Convergence
7-3
Overview
Objectives
BGP Convergence
BGP Processes
x
7-3
7-3
7-4
7-5
CPU Effects of BGP Processes

Example: CPU Effects of BGP Processes
PMTU Discovery
ip tcp path-mtu-discovery
Increasing Input Queue Depth
hold-queue
BGP Scan Time
bgp scan-time
BGP Advertisement Interval
neighbor advertisement-interval
BGP Nonstop Forwarding Awareness
timers nsf route-hold
Summary
7-6
7-7
7-8
7-11
7-11
7-14
7-14
7-17
7-17
7-20
7-21
7-23
7-25
7-26
Limiting the Number of Prefixes Received from a BGP Neighbor

Overview
Objectives
Limiting the Number of Routes Received from a Neighbor
Configuring the BGP Maximum-Prefix Function
neighbor maximum-prefix
Monitoring the BGP Maximum-Prefix Function
Example: Monitoring the BGP
Summary
Implementing BGP Peer Groups
7-27
7-27
7-28
7-29
7-29
7-31
7-32
7-34
7-35
Overview
Objectives
Peer Group Requirements
Example: Peer Group RequirementsCustomer Connections
Example: Peer Group RequirementsBGP Route Reflector
Example: Peer Group Requirements Edge Router at a Peering Point
Peer Groups as a BGP Performance Tool
BGP Peer Group Limitations
BGP Peer Groups in Cisco IOS Software
BGP Dynamic Update Peer-Groups Feature
clear ip bgp update-group
debug ip bgp groups
show ip bgp replication
show ip bgp update-group
BGP Configuration Using Peer Templates
Peer Session Commands
template peer-session
inherit peer-session
neighbor inherit peer-session
show ip bgp template peer-session
Peer Policy Commands
inherit peer-policy
neighbor inherit peer-policy
show ip bgp template peer-policy
Configuring Peer Groups
neighbor peer-group (Creating)
neighbor peer-group (Assigning Members)
Example: BGP Peer GroupCustomer Connections
Example: BGP Peer GroupBGP Route Reflector
Example: BGP Peer GroupEdge Router at a Peering Point
Monitoring Peer Groups
show ip bgp peer-group
clear ip bgp
Summary
7-27
7-35
7-35
7-36
7-37
7-38
7-39
7-40
7-41
7-42
7-43
7-44
7-44
7-45
7-46
7-48
7-50
7-50
7-50
7-51
7-51
7-52
7-52
7-53
7-53
7-54
7-54
7-55
7-56
7-57
7-58
7-59
7-59
7-59
7-64
xi
Using BGP Route Dampening

Overview
Objectives
BGP Route Dampening
Route-Dampening Operation
Configuring BGP Route Dampening
Releasing Dampened Routes
clear ip bgp flap-statistics
clear ip bgp dampening
Monitoring Route Dampening
Example: Monitoring Route Dampening
Summary
Module Summary
References
Module Self-Check
xii
7-65
7-65
7-65
7-66
7-68
7-70
7-73
7-73
7-74
7-75
7-76
7-83
7-84
7-85
7-86
7-92
BGP
Course Introduction
Overview
Configuring BGP on Cisco Routers (BGP) v3.2 provides students with in-depth knowledge of
Border Gateway Protocol (BGP), the routing protocol that is one of the underlying foundations
of the Internet and New World technologies such as Multiprotocol Label Switching (MPLS).
This curriculum covers the theory of BGP, configuration of BGP on Cisco IOS routers, detailed
troubleshooting information, and hands-on exercises that provide learners with the skills that
they need to configure and troubleshoot BGP networks in customer environments. Different
service solutions in the curriculum cover BGP network design issues and usage rules for
various BGP features, preparing learners to design and implement efficient, optimal, and
trouble-free BGP networks.

This subtopic lists the skills and knowledge that learners must possess to benefit fully from the
course. The subtopic also includes recommended Cisco learning offerings that learners should
complete in order to benefit fully from this course.

Building Scalable Cisco Internetworks (BSCI) course or
equivalent
2005 Cisco Systems, Inc. All rights reserved.
BGP v3.23
Course Goal and Objectives

This topic describes the course goal and objectives.
Course Goal
To provide learners with in-depth

knowledge of BGP
BGP v3.24
Upon completing this course, you will be able to meet these objectives:
Configure, monitor, and troubleshoot basic BGP to enable interdomain routing in a network
scenario with multiple domains
Use BGP policy controls to influence the route selection process with minimal impact on
BGP route processing in a network scenario where you must support connections to
multiple ISPs
Use BGP attributes to influence the route selection process in a network scenario where
you must support multiple connections
Implement the correct BGP configuration to successfully connect the customer network to
the Internet in a network scenario where you must support multiple connections
Enable the provider network to behave as a transit AS in a typical service provider network
with multiple BGP connections to other autonomous systems
Identify common BGP scaling issues and enable route reflection and confederations as
possible solutions to these issues in a typical service provider network with multiple BGP
connections to other autonomous systems
Use available BGP tools and features to optimize the scalability of the BGP routing
protocol in a typical BGP network
Course Introduction
Course Flow
This topic presents the suggested flow of the course materials.
Course Flow
A
M
Day 1
Day 2
Course
Introduction
Module 2: BGP
Transit
Autonomous
Systems
Module 1:
BGP Overview
Module 2:
BGP Transit
Autonomous
Systems Lab
Day 3
Module 3:
Route Selection
Using Policy
Controls Labs
Day 4
Day 5
Module 4:
Route Selection
Using Attributes
Labs
Module 6:
Scaling Service
Provider
Networks Labs
Module 5:
Customer-toProvider
Connectivity
with BGP
Module 7:
Optimizing
BGP Scalability
Module 5:
Customer-toProvider
Connectivity
with BGP (Cont.)
Module 7:
Optimizing
BGP Scalability
Labs
Lunch
P
M
Module 1:
BGP Overview
(Cont.)
Module 1:
BGP Overview
Labs
Module 3:
Route Selection
Using Policy
Controls
Module 4:
Route Selection
Using Attributes
Module 6:
Scaling Service
Provider
Networks
BGP v3.25
The schedule reflects the recommended structure for this course. This structure allows enough
time for the instructor to present the course information and for you to work through the lab
activities. The exact timing of the subject materials and labs depends on the pace of your
specific class.
Additional References
This topic presents the Cisco icons and symbols used in this course, as well as information on
where to find additional technical references.
Cisco Icons and Symbols
Router
PIX Firewall
Network
Cloud,
White
Workgroup
Switch:
Color/Subdued
100BASE-TX
Hub
Network
Cloud,
Standard
Color
Terminal
Server
PC
BGP v3.26
Cisco Glossary of Terms

For additional information on Cisco terminology, refer to the Cisco Internetworking Terms and
Acronyms glossary of terms at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.
Course Introduction
Your Training Curriculum

This topic presents the training curriculum for this course.
Cisco Certifications
BGP v3.27
You are encouraged to join the Cisco Certification Community, a discussion forum open to
anyone holding a valid Cisco Career Certification (such as Cisco CCIE, CCNA, CCDA,
CCNP, CCDP, CCIP, or CCSP). It provides a gathering place for Cisco-certified
professionals to share questions, suggestions, and information about Cisco Career Certification
programs and other certification-related topics. For more information, visit
http://www.cisco.com/web/learning/le3/le2/le37/le8/learning_certification_type_home.html
Cisco Career Certifications: Service

Provider Internetworking
Expand Your Professional Options
and Advance Your Career
Professional-level recognition in service provider internetworking
Expert
CCIE
Professional
CCIP
Associate
CCNA
Service Provider
Internetworking
Required
Exam
Recommended Training Through

Cisco Learning Partners
BSCI
Building Scalable Cisco

Internetworks (BSCI)
BGP
Configuring BGP on
Cisco Routers (BGP)
QOS
Implementing Cisco
Quality of Service (QoS)
MPLS
Implementing Cisco
MPLS (MPLS)
http://www.cisco.com/go/certifications
BGP v3.28
Cisco Career Certifications: Service

Provider Internetworking (Cont.)
Expand Your Professional Options
and Advance Your Career
Professional-level recognition in service provider internetworking
Another option:
Expert
CCIE
Professional
CCIP
Associate
Required
Exam
Recommended Training Through

Cisco Learning Partners
Composite
Building Scalable Cisco Internetworks (BSCI)

and Building Cisco Multilayer Switched
Networks (BCMSN)
QOS
Implementing Cisco Quality of Service (QoS)
BGP + MPLS
Configuring BGP on Cisco Routers (BGP) and

Implementing Cisco MPLS (MPLS)
CCNA
Service Provider
Internetworking
http://www.cisco.com/go/certifications
BGP v3.29
Course Introduction
Module 1
BGP Overview
Overview
Border Gateway Protocol (BGP) is an interdomain (interautonomous system) routing protocol
that is used to exchange routing information for the Internet. BGP, by design, is a very robust
and scalable routing protocol. Because BGP is deployed as an interdomain routing protocol, it
has many rich features that allow administrators to implement a variety of routing policies. This
module covers basic BGP technology, details BGP session establishment and routing
information exchange, and describes basic Cisco IOS configuration and troubleshooting tasks.
Module Objectives
Upon completing this module, you will be able to configure, monitor, and troubleshoot basic
BGP to enable interdomain routing in a network scenario with multiple domains. This ability
includes being able to meet these objectives:
Identify appropriate BGP usage and limitations
List BGP path attributes and the functionality of each attribute
Describe the concept of BGP neighbors and neighbor session establishment procedures
Describe BGP route processing
Configure a router for BGP
Perform the steps to correct basic BGP configuration and session errors
1-2
Lesson 1
Introducing BGP
Overview
The Border Gateway Protocol (BGP) is a very robust and scalable routing protocol, which is
demonstrated by the fact that it is the routing protocol that is used on the Internet. Service
providers and customer networks, such as universities and corporations, usually use an Interior
Gateway Protocol (IGP) such as Routing Information Protocol (RIP), Enhanced Interior
Gateway Routing Protocol (EIGRP), or Open Shortest Path First (OSPF) for the exchange of
routing information within their networks. Any communication between these IGPs and the
Internet or between service providers will be accomplished through BGP. This lesson
introduces basic BGP characteristics and features.
Objectives
Upon completing this lesson, you will be able to identify appropriate BGP use and limitations.
This ability includes being able to meet these objectives:
Describe interdomain routing in relation to the design goals of interdomain routing
protocols
List the basic characteristics of BGP
Identify when a single-homed customer should use BGP as an interdomain routing protocol
Describe when BGP is appropriate for the multihomed customer
Describe the use of BGP in a transit autonomous backbone
List some of the limitations of BGP
Interdomain Routing
This topic describes interdomain routing in relation to the design goals of interdomain routing
protocols.
Interdomain Routing
An AS is a collection of networks under a single technical

administration.
An IGP is run inside an AS, resulting in optimum intra-AS
routing.
An EGP is run between autonomous systems to enable
routing policies and improve security.
BGP v3.21-3
When talking to people who are involved with Internet routing, network administrators
commonly use the terms autonomous system, interdomain routing, interior routing
protocol, and exterior routing protocol. These terms, which may be confusing for a novice,
are defined as follows:
An autonomous system (AS) is a collection of networks under a single technical
administration. Other definitions refer to a collection of routers or IP prefixes, but in the
end they are all essentially the same thing. The important principle is the technical
administration, which means sharing the same routing protocol and routing policy. Legal
and administrative ownership of the routers does not matter with autonomous systems.
Autonomous systems are identified by AS numbers. AS numbers are 16-bit, unsigned
integers ranging from 1 to 65535. Public AS numbers (1 to 64511) are assigned and
managed by an Internet registry. A range of private AS numbers (64512 to 65535) has been
reserved for customers that need an AS number to run BGP in their private networks.
Interdomain routing is routing between autonomous systems. It is usually based on a set of
policies, not just the technical characteristics of the underlying infrastructure.
Exterior routing protocols (BGP being the only exterior routing protocol that is used today)
are protocols that have the right set of functions to support various interdomain routing
policies. Such protocols are contrary to interior routing protocols (for example, OSPF, RIP,
or EIGRP), which focus only on finding the optimum (usually fastest) route between two
points, without respect to routing policies.
1-4
Design Goals for Interdomain Routing

Scalability
The Internet has more than 140,000 routes and is still
growing.
Secure routing information exchange

Routers from another AS cannot be trusted.
Tight filters are required; authentication is desirable.
Support for routing policies

Routing between autonomous systems might not always
follow the optimum path.
BGP v3.21-4
The design goals for any interdomain routing protocol include the following:
Scalability: An interdomain routing protocol has to be able to support Internet routing,
which consists of more than 140,000 routes.
Secure information exchange: Because the routers from other autonomous systems
cannot be trusted, tight filters on routing updates and router authentication are desirable
features.
Support for routing policies: Routing between autonomous systems might not always
follow the optimum path, and exterior routing protocols have to support a wide range of
customer requirements.
BGP Overview
1-5
Example: Why External Routing Protocols?

The example illustrates the need for an interdomain routing protocol. It depicts two companies
that are connected to the Internet via leased lines of differing speeds.
Why External Routing Protocols?
Q: Assuming standard IGP route selection rules, how will the

traffic between AS 1 and AS 20 flow?
Q: Will AS 2 allow this traffic?
Q: How would you solve this problem with OSPF or EIGRP?
BGP v3.21-5
In routing protocols other than BGP, routing decisions are normally made to take advantage of
the highest bandwidth available. Doing so would make traffic between AS 1 and AS 20 flow
via AS 2. This situation is not desirable for AS 2, because it would allow the users in Company
A to generate traffic on the Internet access line that was purchased and paid for by Company B.
Company B is unlikely to allow traffic from Company A to reach the Internet using the
Company B access line. Company B, in fact, could create an access-list blocking all IP packets
from AS 1 from being transmitted on the 2-Mbps serial line from Company B to the Internet.
That action would create a black hole because Company A would send its packets to Company
B and then Company B would drop them.
To avoid this situation, Company B must make sure that the packets from Company A that are
destined for the Internet are never sent to Company B. Also, Company B must make sure that
packets from the Internet that are destined for Company A are never sent using the Internet
access line to Company B. Company B could implement a routing policy that indicates that
AS 2 will receive reachability information from AS 1 for its own use but that AS 2 will not
forward that particular information to the Internet. Also, AS 2 will receive reachability
information about the Internet from its Internet service provider (ISP) but will never forward
that information to AS 1. Only networks local to AS 2 will be sent to AS 1.
The result of this routing policy would be that AS 1 sees all networks within AS 2 as reachable
over the 2-Mbps link that directly connects AS 1 with AS 2. The routers in AS 1 will not see
the rest of the Internet as reachable through AS 2. Therefore, AS 1 forwards packets toward the
Internet directly over the 64-kbps link.
1-6
Also, the IP networks in AS 1 will appear reachable by AS 2 over the 2-Mbps link, which
directly connects AS 1 with AS 2. However, the ISP will not receive that reachability
information from AS 2; it will receive it only from AS 1. Therefore, traffic from the Internet to
Company A will be transmitted over the 64-kbps link.
This routing policy is easy to implement when network administrators are using BGP but
impossible to implement with any other routing protocol. EIGRP, for example, can do route
filtering only on individual IP subnets, not on all prefixes belonging to an AS. Link-state
protocols, such as OSPF, cannot do powerful route filtering at all. BGP can do this routing
based on AS numbers, which makes it possible to scale BGP over the Internet.
BGP Overview
1-7
BGP Characteristics
This topic lists the basic characteristics of BGP.
BGP Characteristics
BGP is a distance vector protocol with
enhancements:
Reliable updates
Triggered updates only
Rich metrics (called path attributes)
Designed to scale to huge internetworks
BGP v3.21-6
BGP is a distance vector protocol. This means that BGP will announce to its neighbors those IP
networks that it can reach itself. The receivers of that information will say, If that AS can
reach those networks, then I can reach them via the AS.
If two different paths are available to reach the same IP subnet, then the shortest path is used.
This determination requires a mechanism capable of measuring the distance. All distance vector
protocols have such mechanisms, called metrics. BGP contains a very sophisticated method
of computing the shortest path by using attributes that are attached to the reachable IP subnet.
BGP sends routing updates to its neighbors by using a reliable transport. This technique means
that the sender of the information always knows that the receiver has actually received the
information. As a result, there is no need for periodic updates or routing information refreshes.
In BGP, only information that has changed is transmitted.
The reliable information exchange, combined with the batching of routing updates that is also
performed by BGP, allows BGP to scale to large, Internet-sized networks.
1-8
BGP Characteristics (Cont.)

Reliable updates
TCP used as transport protocol

No periodic updates
Periodic keepalives to verify TCP connectivity
Triggered updates batched and rate-limited
Every 5 seconds for internal peer
Every 30 seconds for external peer
BGP v3.21-7
The reliable transport mechanism that is used by BGP is standard TCP. BGP is an application
protocol that uses both the TCP and IP protocols for reliable connections.
Because BGP uses a reliable transport, the sender knows that the receiver has actually received
the transmitted information. This capability makes periodic updates unnecessary.
A router that has received reachability information from a BGP peer must be sure that the peer
router is still there. Otherwise, the router could route traffic toward a next-hop router that is no
longer available, causing the IP packets to be lost in a black hole. TCP does not provide the
service to signal that the TCP peer has been lost, unless some application data is actually
transmitted between the peers. In an idle state, where there is no need for BGP to update its
peer, the peer could be unreachable without TCP detecting it. Therefore, BGP takes care of
detecting the presence of neighbors by periodically sending small BGP keepalive packets to
them. These packets are considered application data by TCP and therefore must be transmitted
reliably. According to the BGP specification, the peer router also must reply with a BGP
keepalive packet.
When BGP was created, a key design goal was to be able to handle enormous amounts of
routing information in very large and complex networks. In this environment, many links could
go up and down (flapping), causing topology changes, which must be considered by the routing
protocol. But low convergence time and quick responses to topology changes require fast
updates and high CPU power to process both incoming and outgoing updates. The larger the
network, the more updates per second can be expected if immediate response is required. The
presence of too many updates in large networks can jeopardize network scalability.
The designers of BGP decided that scalability was a more important issue than low
convergence time, so BGP was designed to batch updates. Any changes that are received within
the batch interval time are saved. At the end of the interval, only the remaining result is
forwarded in an outgoing update. If a network flaps several times during the batch interval,
only the state at the end of the interval is sent in an update. The batching feature avoids an
uncontrolled flood of updates all over the Internet because the number of updates is limited by
the batching procedure.
BGP Overview
1-9

Protocol development considerations
BGP was designed to perform well in the following areas:
Interdomain routing applications
Huge internetworks with large routing tables
Environments that require complex routing policies
Some design tradeoffs were made:

BGP uses TCP for reliable transport
CPU-intensive
Scalability is the top priorityslower convergence
BGP v3.21-8
The designers of the BGP protocol have succeeded in creating a highly scalable routing
protocol, which can forward reachability information between autonomous systems (also
known as routing domains). The designers had to consider an environment with an enormous
number of reachable networks and complex routing policies that were driven by commercial
rather than technical considerations.
TCP, a well-known and widely proven protocol, was chosen as the transport mechanism. That
decision kept BGP simple, but it increased the CPU resource requirements for routers running
BGP. The point-to-point nature of TCP also introduces a slight increase in network traffic,
because any update that should be sent to many receivers has to be multiplied into several
copies, which are then transmitted on individual TCP sessions to the receivers.
Whenever there was a design choice between fast convergence and scalability, scalability was
the top priority. The batching of updates and the relatively low frequency of keepalive packets
are examples of designers placing convergence time second to scalability.
Note
1-10
BGP convergence times can be modified with the configuration of nondefault values for BGP
scan and advertisement timers. Refer to the Optimizing BGP Scalability module for more
information on tuning BGP convergence.

Common BGP uses
Customers connected to more than one service provider
Service provider networks (transit autonomous systems)
Service providers exchanging traffic at an exchange point
(CIX, GIX, NAP, )
Network cores of large-enterprise customers
BGP v3.21-9
The figure shows typical scenarios in which BGP is usable. These scenarios include the
following:
Customers connected to more than one service provider.
ISP networks themselves acting as transit systems and forwarding external traffic.
Exchange points, which can be defined by the network access point (NAP) between region
and core. International exchange points can be defined by either Commercial Internet
eXchange (CIX) or Global Internet eXchange (GIX) points.
Very large enterprises using BGP as their core routing protocol.
BGP Overview
1-11
This topic identifies when a single-homed customer should use BGP as an interdomain routing
protocol.
Large customer or small ISP connecting to the Internet
BGP v3.21-10
The figure shows a customer network connected to the Internet using a single ISP, but such a
scenario is generally not the case when BGP is used. Normal Internet access to a single ISP
does not require BGP; static routes are more commonly used to handle this situation. Small
ISPs buying Internet connectivity from other ISPs use this type of connectivity more often,
especially if they want to start their business the proper wayby using their own AS number
and having their own address space.
1-12
Use Guidelines? Single-Homed Customers

Use BGP between the customer and the service
provider in these situations:
Customers multihomed to the same service provider
Customers that need dynamic routing protocol with the
service provider to detect failures
Hint: Use private AS number for these customers.
Smaller ISPs that need to originate their routes in the Internet
Use static routes in all other cases:

Static routes always simpler than BGP
BGP v3.21-11
Under certain conditions, BGP must be configured between the customer and the service
provider. For example, BGP is needed when customers are multihomed to the same service
provider (that is, the customer networks have multiple links connecting them with the service
provider network) and require dynamic routing protocol interaction with the service provider to
detect link failures. Private AS numbers (AS numbers above 64512) are usually implemented in
BGP configurations for these customers.
Customers that plan to connect to more than one ISP, and small ISPs that plan to have multiple
Internet connections in the future, usually use BGP with their service provider. They use this
option even when they have a single link with the service provider in order to be prepared for
future upgrades.
In all other cases, using static routes from the service provider toward the customer and using a
default static route from the customer toward the service provider is the preferred method of
provider-to-customer routing in the Internet.
BGP Overview
1-13
This topic describes when BGP is appropriate for the multihomed customer. BGP use
guidelines for multihoming are also discussed.
Customer connecting to more than one service provider
BGP v3.21-12
The figure illustrates a customer network that is connected to two different ISPs, requiring the
use of BGP for full redundancy.
The customer must have its own officially assigned AS number. The customer is also
responsible for announcing its own IP networks to both ISPs. Both ISPs forward all routes
received from the Internet to the customer network. The customer should avoid forwarding any
routing information received from one ISP to the other. Otherwise, the customer becomes a
transit provider between the two ISPs. This is a situation that most customers like to avoid
because it creates a resource drain on routers and network links.
Full redundancy is achieved in this setup. If either of the two access links fails, the reachability
information that was previously transmitted on the now-failed link is withdrawn. But BGP
reachability information is still announced by the customer router over the remaining link.
Thus, the ISP still sees all networks within the customer AS as reachable but only over the
remaining path. Also, received routes from the Internet are withdrawn when the link fails, but
routes received over the remaining link are not affected. Thus, the Internet, including the ISP to
which the direct connection has failed, is still reachable over the remaining link.
This design can also handle other problems. A case where both access links are available, but
the connection between one of the ISPs and the rest of the Internet is lost, works as follows:
The ISP that has a problem reaching the rest of the Internet withdraws all those routes and tells
the customer AS that it can no longer reach the Internet. But the networks local to the ISP with
the Internet reachability problem are still reachable by the customer, so those routes are not
withdrawn. The networks in the customer AS are still reachable by the ISP in trouble, but that
ISP can no longer forward the announcement to the rest of the Internet. The rest of the Internet
will, however, see the customer networks as reachable over the path to the other ISP, which is
fully functional.
1-14
User Guidelines? Multihomed Customers

BGP is almost mandatory for multihomed customers.
Multihomed customers have to use public AS numbers.
Multihomed customers should use a provider-independent
address space.
BGP v3.21-13
The following use guidelines apply to multihomed customers:

Although there are designs where BGP could be avoided, most multihomed customers need
to use BGP with their service providers.
Multihomed customers must have their own AS numbers, and it is recommended to use a
public AS number.
Multihomed customers should use a provider-independent address space, which is allocated
to them directly by an Internet registry.
BGP Overview
1-15

This topic describes the use of BGP in a transit autonomous backbone.

Using BGP to exchange routes is mandatory for transit
autonomous systems (provider networks carrying customer
traffic).
BGP v3.21-14
BGP is most commonly implemented in service provider networks to ensure connectivity

between customers and the rest of the Internet. An ISP might exchange BGP updates with the
customers or use static routing toward them. That ISP also connects to other ISPs and is
required to forward the routes that are received from customers to the rest of the Internet, as
well as in the other direction. As a result, user data traffic starts to flow between the customers
and the rest of the Internet. Such a network, providing transit services to traffic that is
originated in other networks, is called a transit autonomous system, or transit AS. A transit
AS is an AS that exchanges BGP routing information with other autonomous systems and
forwards information received from one AS to another AS.
When routing information is forwarded, the receiver will see an available path to a destination
and start transmitting user data toward the destination using that path. The transit AS must be
prepared to relay the user data, as explained later in this course.
ISP networks can sometimes have dedicated peer-to-peer connections, using, for example,
packet over SONET (POS). These connections are sometimes called private peering. ISPs also
interconnect at exchange points. Technically, an exchange point is just a multiaccess subnet: a
LAN (for example, a Gigabit Ethernet or Fast Ethernet switch), a Dynamic Packet Transport
(DPT) ring, or an ATM switch. Many ISPs can connect to an exchange point and establish BGP
sessions.
The benefit of an exchange point is that it is highly scalable. There is no need for additional
physical interfaces in the ISP border router when a new ISP is launched. If the already
established ISPs want to, they can open a BGP session with the new ISP. When this session is
opened, they start to exchange routing information and then user data traffic over the exchange
point.
1-16
BGP Limitations
This topic lists some of the limitations of BGP.
BGP Limitations
BGP and associated tools cannot express all routing
policies.
You cannot influence the routing policies of downstream
autonomous systems.
BGP does not enable one AS to send traffic

to a neighbor AS intending that the traffic
take a different route from that taken by traffic
originating in the neighbor AS.
RFC 1771
BGP v3.21-15
BGP-enabled routers make forwarding decisions based on the destination IP address only; the
source IP address does not affect the decision. If an AS acts as a transit AS for other
autonomous systems, the IP packets that are created and transmitted from the other autonomous
systems are not treated differently from the IP packets that are created and transmitted from the
local AS. If the local AS has decided that the best path to reach a certain destination is via a
specific next-hop router, then it will route all user data traffic toward the final destination via
that specific next-hop router. The local AS makes its decision based on destination address
only, regardless of which IP host has sourced the IP packets.
BGP Overview
1-17
Summary
This topic summarizes the key points discussed in this lesson.
Summary
BGP has the right set of functions to support the various
interdomain routing policies. Contrary to BGP, interior
routing protocols focus only on finding the optimum (usually
fastest) route between two points, without respect to routing
policies.
BGP is an enhanced distance vector protocol with reliable
transport provided by TCP, a rich set of metrics called BGP
path attributes, and scalability features such as batched
updates that make it suitable for very large networks.
Customers that plan to connect to more than one ISP, and
small ISPs that plan to have multiple Internet connections in
the future, usually use BGP with their service provider.
BGP v3.21-16
Summary (Cont.)
Although there are designs where BGP could be avoided,
most multihomed customers use BGP with their service
providers.
A transit AS is an AS that exchanges BGP routing
information with other autonomous systems and forwards
information received from one AS to another AS.
BGP is bound by IP hop-by-hop, destination-only routing.
Routing policies that deviate from this model cannot be
implemented with BGP.
1-18
BGP v3.21-17
Lesson 2
Understanding BGP Path

Attributes
Overview
To aid routers in calculating the best route to select when multiple paths to a particular
destination exist, routes that are learned via Border Gateway Protocol ( BGP) have properties
that are associated with them. These properties are referred to as BGP path attributes. An
understanding of how BGP path attributes influence route selection is required to design robust
BGP networks.
This lesson introduces BGP path attributes and their purpose. The lesson also discusses
classifications that are used to describe attributes and the properties of each classification. The
functionality of the autonomous system (AS) path and next-hop attributes are also explained in
detail in this lesson.
Objectives
Upon completing this lesson, you will be able to list BGP path attributes and the functionality
of each attribute. This ability includes being able to meet these objectives:
Describe the concept of BGP path attributes
Explain the difference between mandatory and discretionary well-known BGP attributes
Explain the difference between nontransitive and transitive optional BGP attributes
Describe the functionality of the AS-path attribute
Describe the functionality of the next-hop attribute
BGP Path Attributes

This topic describes the concept of BGP path attributes.
BGP Path Attributes

BGP metrics are called path attributes.
BGP attributes are categorized as well-known and
optional.
Well-known attributes must be recognized by all
compliant implementations.
Optional attributes are recognized only by some
implementations (could be private); expected not to be
recognized by all.
BGP v3.21-3
Each BGP update consists of one or more IP subnets and a set of attributes that are attached to
them. Some of the attributes are required to be recognized by all BGP implementations. Those
attributes are called well-known BGP attributes.
Attributes that are not well-known are called optional. These could be attributes that are
specified in a later extension of BGP or even in private vendor extensions that are not
documented in a standard document.
1-20

This topic describes the differences between mandatory and discretionary well-known BGP
attributes.

Well-known attributes are divided into mandatory and
discretionary.
Mandatory well-known attributes must be present in all
update messages.
Discretionary well-known attributes are optional; they could
be present in update messages.
All well-known attributes are propagated to other neighbors.
BGP v3.21-4
There is a small set of three specific well-known attributes that are required to be present on
every update. These are the next-hop, AS-path, and origin attributes and are referred to as
mandatory well-known attributes.
Other well-known attributes may or may not be present, depending on the circumstances under
which the updates are sent and the desired routing policy. The well-known attributes that could
be present, but are not required, are called discretionary well-known attributes.
When a router receives a BGP update, it analyzes the attached attributes and compares them
with the attributes that were attached to the same IP subnet when it was received from a
different source. The router then makes a decision about which source indicates the best path to
the particular IP subnet. The best route is propagated, along with its well-known attributes, to
other BGP-speaking neighbors.
BGP Overview
1-21
Mandatory Well-Known BGP Attributes

Origin
The origin of a BGP route
i
Route originated in an IGP
Route originated in EGP
Route was redistributed into BGP
AS-path
Sequence of AS numbers through which the network is
accessible
Next-hop
IP address of the next-hop router
BGP v3.21-5
The three mandatory well-known attributes are origin, AS-path, and next-hop:
Origin: When a router first originates a route in BGP, it sets the origin attribute. If
information about an IP subnet is injected using the network command or via aggregation
(route summarization within BGP), the origin attribute is set to i for Interior Gateway
Protocol (IGP). If information about an IP subnet is injected using redistribution, the origin
attribute is set to ? for unknown or incomplete information (these two words have the
same meaning). The origin code e was used when the Internet was migrating from
exterior gateway protocol (EGP) to BGP and is now obsolete.
AS-path: The egress router modifies the AS-path attribute every time information about a
particular IP subnet passes over an AS border. When a router first originates a route in
BGP, the AS-path attribute is empty. Each time that the route crosses an AS boundary, the
transmitting AS prepends its own AS number to appear first in the AS path. You can track
the sequence of autonomous systems through which the route has passed by using the
AS-path attribute.
Next-hop: The router also modifies the next-hop attribute as the route passes through the
network. This attribute indicates the IP address of the next-hop routerthe router to which
the receiving router should forward the IP packets toward to reach the destination that is
advertised in the routing update.
1-22
Discretionary Well-Known BGP Attributes

Local preference
Used for consistent routing policy within AS
Atomic aggregate
Informs the neighbor AS that the originating router
aggregated routes
BGP v3.21-6
Discretionary well-known attributes must be supported by all BGP implementations but do not
have to be present in all BGP updates. Routers use discretionary well-known attributes only
when those functions are required. The following are descriptions of these two attributes:
Local preference: Local preference is used in the route selection process. This attribute is
carried within an AS only. The router prefers a route with a high local preference value to a
route with a low value. By default, routes that are received from a peer AS are tagged with
the local preference set to a value of 100 before they are entered into the local AS. If this
value is changed through BGP configuration, the BGP selection process is influenced.
Because all routers within the AS get the attribute along with the route, a consistent routing
decision is made throughout the AS.
Atomic aggregate: The atomic aggregate attribute is attached to a route that is created as a
result of route summarization (called aggregation in BGP). This attribute signals that
information that was present in the original routing updates may have been lost when the
updates were summarized into a single entry.
BGP Overview
1-23

This topic explains the difference between nontransitive and transitive optional BGP attributes.

Optional BGP attributes are transitive or nontransitive.
Transitive optional attributes
Propagated to other neighbors if not recognized; partial bit set to
indicate that the attribute was not recognized
Nontransitive optional attributes

Discarded if not recognized
Recognized optional attributes are propagated to

other neighbors based on their meaning (not
constrained by transitive bit).
BGP v3.21-7
When a router receives an update that contains an optional attribute, the router checks to see
whether its implementation recognizes the particular attribute. If it does, then the router should
know how to handle it and whether to propagate it.
If the router does not recognize the attribute, the BGP implementation should look for the
transitive bit in the attribute code. Some attributes, although not recognized by the router, might
still be helpful to upstream routers and should be propagated. These attributes (called
transitive optional attributes) are propagated even when they are not recognized. If a router
propagates an unknown transitive optional attribute, it sets an additional bit in the attribute
header, called the partial bit, to indicate that at least one of the routers in the path did not
recognize the meaning of a transitive optional attribute.
Other attributes, called nontransitive optional attributes, might be of no value to upstream
routers if a router earlier in the path does not recognize them. Routers that do not recognize
these attributes drop them.
1-24
Optional BGP Attributes (Cont.)

Nontransitive attributes
Multi-exit discriminator
Used to discriminate between multiple entry points to a single
AS
Transitive attributes
Aggregator
Specifies IP address and AS number of the router that performed
route aggregation
Community
Used for route tagging
BGP v3.21-8
One of the nontransitive optional attributes is the multi-exit discriminator (MED) attribute,
which also influences the BGP route selection process. Whenever there are several links
between two adjacent autonomous systems, one AS can use the MED attribute to tell another
AS to prefer one of the links for specific destinations.
Transitive optional attributes include the following:
Aggregator: Identifies the AS and the router within that AS that created a route
summarization, or aggregate.
Community: A numerical value that can be attached to certain routes as they pass a
specific point in the network. The community value can later be examined by other routers
at different points in the network for filtering or route selection purposes. BGP
configuration may cause routes with a specific community value to be treated differently
than others.
BGP Overview
1-25
AS-Path Attribute
This topic describes the functionality of the BGP AS-path attribute.
AS-Path Attribute
The AS-path attribute is empty when a local route is
inserted in the BGP table.
The AS number of the sender is prepended to the ASpath attribute when the routing update crosses AS
boundary.
The receiver of BGP routing information can use the
AS-path attribute to determine through which AS the
information has passed.
An AS that receives routing information with its own
AS number in the AS path silently ignores the
information.
BGP v3.21-9
The AS-path attribute is modified by an edge router every time information about a particular
IP subnet passes over an AS border. When a router first originates a route in BGP, the AS-path
attribute is empty. The local AS number is prepended to the AS path each time that the route
crosses an AS boundary. There are several consequences of this behavior:
When you examine BGP routes, the AS path can be interpreted as the sequence of
autonomous systems that must be passed through to reach the indicated network. The AS
that originally injected the route into BGP is always found at the rightmost end of the AS
path.
It is easy to distinguish local routes from routes that have been received from other
autonomous systemsBGP routes with an empty AS path were injected into BGP from
within the local AS.
The AS-path attribute is also used to avoid routing loops. When a router receives a BGP
update, it checks the AS-path attribute and looks for its own AS number. If that number is
found in the AS path, then the route has already crossed the local AS and the router is now
faced with a routing information loop. To avoid this situation, the route is silently ignored.
1-26
Example: AS-Path Attribute

The figure shows how BGP loop prevention works.
AS-Path Attribute Example
BGP v3.21-12
The network 10.0.0.0/8 is local to AS 123. The router in AS 123 injects the route 10.0.0.0/8
into BGP with an empty AS-path attribute.
When the routing update about network 10.0.0.0/8 is sent by the edge router in AS 123 to
AS 21, the AS number 123 is prepended to the empty AS path, resulting in an AS path
consisting of only 123. The sending router does the prepending as part of the outgoing BGP
update processing. While the route is still within AS 123, the AS-path entry for AS 123 does
not appear in the AS path.
The router in AS 21 propagates the information about the network 10.0.0.0/8 to AS 37. Because
it is sending the BGP update to AS 37, it prepends its own AS number to the AS path, resulting
in an AS path consisting of the sequence of 21 123.
AS 37 also propagates the received route to AS 123. To avoid a routing loop, where AS 123
might try to reach its own network (10.0.0.0/8) via AS 37, BGP has a built-in mechanism that
causes the router in AS 123 to drop the incoming update as soon as it finds its own AS (123), in
the AS path. No error will be signaled, because nothing is really wrong. It is merely the
procedure that is used by BGP to avoid a routing information loop.
BGP Overview
1-27
Next-Hop Attribute
This topic describes the functionality of the next-hop attribute in BGP.
Next-Hop Attribute
Indicates the next-hop IP address used for packet
forwarding
Usually set to the IP address of the sending External
Border Gateway Protocol (EBGP) router
Can be set to a third-party IP address to optimize
routing
BGP v3.21-13
The BGP next-hop attribute identifies the IP address that a router should use to forward packets
toward the destination that is announced in a BGP routing update. In most cases, the sending
router sets the next-hop attribute to its own IP address. There are cases, however, where the
next-hop IP address points to a third router.
1-28
Example: Next-Hop Attribute

The figure shows the usual next-hop processing.
Next-Hop Attribute Example

Next-Hop Processing
Next-hop attribute is usually set to the IP address of the sending router.

BGP v3.21-15
The processing is as follows:

1. RTR-B announces network 21.0.0.0/8 to RTR-A. The outgoing IP address of RTR-B (the
address that is used to establish the BGP TCP session) is used as the BGP next hop.
2. RTR-A receives the routing update and installs it in its BGP table and routing table. Should
RTR-A need to forward packets toward network 21.0.0.0/8, it would send those packets
toward the IP address 10.0.0.1 (RTR-B).
3. When RTR-A propagates the information about 21.0.0.0/8 to RTR-C, it sets the BGP
next-hop attribute to its own IP address.
BGP Overview
1-29

Next-Hop Processing
on Shared Media
If the receiving BGP router is in the same subnet as the current next-hop address,
the next-hop address remains unchanged to optimize packet forwarding.
BGP v3.21-17
The next-hop processing changes if the BGP routers connect to a shared subnet. In the figure
here, if RTR-A announces the network 21.0.0.0/8 to RTR-C with the BGP next-hop address set
to RTR-A, the packets from AS 37 toward network 21.0.0.0/8 will have to cross the shared
LAN twice. RTR-A thus sends the routing update toward RTR-C with the BGP next-hop
address unchanged (still pointing toward RTR-B), allowing optimal data transfer across the
shared LAN.
Note
1-30
More formally, the BGP next-hop rule states that if the current BGP next hop is in the same
IP subnet as the receiving router, the next-hop address is not changed; otherwise, the
next-hop attribute is changed to the IP address of the sending router.

Next-Hop Processing
on NBMA Network
BGP next-hop processing can break connectivity with improper network

designs over partially meshed WAN networks.
BGP v3.21-19
BGP next-hop processing results in optimum data transfer over shared media (for example, a
LAN subnet). In partially meshed networks (such as Frame Relay), BGP next-hop processing
can break IP connectivity. Consider, for example, the network diagram in the figure: RTR-A
sends a routing update about network 21.0.0.0/8 to RTR-C with RTR-B set to the next-hop
address (as they are all in the same subnet). Because there is no direct connection (virtual
circuit) between RTR-C and RTR-B but RTR-C still tries to send packets directly toward
RTR-B, the connectivity between AS 37 and AS 21 is broken.
There are two ways to solve the connectivity loss that is introduced by this design:
Use the subinterfaces on RTR-A to make sure that RTR-B and RTR-C are in different
subnets (and BGP next-hop processing would ensure that RTR-A is the BGP next hop in
the outgoing BGP updates).
Disable the BGP next-hop processing on RTR-A in an existing multipoint Frame Relay
design that shares a common subnet. (This option is strongly discouraged in normal BGP
design because routing problems should be solved with a proper network design of pointto-point subinterfaces.)
BGP Overview
1-31
Summary
Summary
BGP metrics attached to a BGP route are called path
attributes.
Some path attributes are well-known and should be recognized
by every BGP implementation. Some of the well-known
attributes are mandatory and have to be present in every BGP
update. These are the AS-path, next-hop, and origin attributes.
Other well-known attributes are discretionary.
Attributes that are not required to be recognized by every BGP
implementation are called optional. These attributes could be
transitive (propagated if not recognized) or nontransitive
(dropped).
BGP v3.21-20
Summary (Cont.)
The AS-path attribute lists the autonomous systems that the
routing update has already crossed. This attribute is used for
BGP loop detection and BGP route selection.
The next-hop attribute specifies the IP address that is to be
used for packet forwarding. The next hop is usually set to the
IP address of the BGP router sending the update.
1-32
BGP v3.21-21
Lesson 3
Establishing BGP Sessions

Overview
Understanding the Border Gateway Protocol (BGP) neighbor session establishment process is a
key component to understanding the fundamental operation of the BGP protocol. It also forms a
knowledge base for later lessons, including configuring basic BGP.
BGP is an exterior gateway protocol (EGP) that has been designed for scalability and policy
control. As a result, BGP requires neighboring routers to be explicitly configured before BGP
routing updates can be sent between them. This situation differs from Interior Gateway
Protocols (IGPs) such as Enhanced Interior Gateway Routing Protocol (EIGRP) and Open
Shortest Path First (OSPF), that discover neighbors through the use of a broadcast packet or a
hello protocol. In this lesson, BGP neighbor session establishment procedures are discussed.
Objectives
Upon completing this lesson, you will be able to describe the concept of BGP neighbors and
neighbor session establishment procedures. This ability includes being able to meet these
objectives:
Explain how BGP discovers neighbors
Describe the BGP session establishment process
Describe the role of the BGP keepalive in session establishment and maintenance
Explain how optional MD5 authentication can protect sessions between BGP peers

This topic explains how the BGP routing protocol discovers neighbors.

BGP neighbors are not discovered; they must be configured
manually.
Configuration must be done on both sides of the connection.
Both routers will attempt to connect to the other with a TCP
session on port number 179.
Only the session with the higher router-ID remains after the
connection attempt.
The source IP address of incoming connection attempts is
verified against a list of configured neighbors.
BGP v3.21-3
Unlike other routing protocols, BGP has no means of automatically detecting neighbors. The
BGP protocol is carried in a TCP session, which must be opened from one router to the other.
To do so, the router attempting to open the session must be manually configured with neighbor
information indicating to which IP address to direct its connection attempts.
The router that receives the incoming connection attempts does not answer them if the attempts
are not from one of the configured neighbors. The IP source address of the connection attempt
packet (TCP SYN packet) is verified against the list of IP addresses that the router itself would
direct its connection attempts to.
To succeed in the connection attempts, both routers must be configured to reach each other. A
side effect of this situation is that they will both attempt to connect. This side effect adds
robustness to the session establishment process, but it also introduces the risk that two BGP
sessions will be established between a pair of BGP routers.
Two routers should have only a single BGP session between them. The router-ID values that
are exchanged when the BGP session is established allow the BGP routers to detect when two
parallel sessions exist. Only the session that was initiated by the router with the numerically
higher router-ID will be retained. The other session is dropped.
A router may not open a BGP session to itself. If the configured neighbor IP address is, in fact,
an IP address of the local router, the router recognizes the problem and tears down the session.
The router-ID is also used for this verification.
1-34
Example: BGP Neighbor Discovery

This example illustrates a small BGP network.
BGP Neighbor Discovery (Cont.)

Small BGP Network
BGP v3.21-4
The network displayed in the figure serves as the sample network to generate printouts in the
following examples.
BGP Overview
1-35
BGP Neighbor Discovery (Cont.)

Initially, all BGP sessions to the neighbors are idle.
BGP v3.21-5
The show ip bgp summary command gives an overview of the BGP status. Each configured
neighbor is listed in the output of the command. The IP address to which the connection
attempts are directed is also displayed, along with the BGP version number, the remote AS
number, some counter values, the status of the session, and how long ago the session changed
state.
The Idle state indicates that the router is currently not attempting any connection
establishments.
The various states for a BGP connection are Idle, Active, OpenSent, OpenConfirm, and
Established.
1-36

This topic describes the BGP session establishment process.

A TCP session is established when the neighbor becomes
reachable.
BGP Open messages are exchanged.
BGP v3.21-6
Before any connection attempt is made, the BGP peer relation must have left the Idle state and
entered the Active state. For a BGP session between two routers in different autonomous
systems, this status results when the IP address of the remote router becomes reachable on a
directly connected interface.
The debug output shows how the router creates a socket data structure and binds it to its local
IP address 2.3.4.6 and a high port number 11003. Then the router sends a TCP SYN packet to
the configured peer router IP address of 2.3.4.5 and the well-known destination port 179. The
connection attempt succeeds, and the TCP session is then ready to transfer the BGP
information.
The first BGP information sent is the BGP Open message. The BGP session then goes from the
Active state to the OpenSent state while waiting for the other router to respond. If the peer
router accepts the parameters in the Open message, it responds with its own Open message.
When the local router receives this message, the state goes from OpenSent to OpenConfirm.
The local router then verifies the peer router parameters in its Open message. If they are
accepted, a keepalive packet is sent to signal this acceptance. The state is then Established.
BGP Overview
1-37
Establishing a BGP Session (Cont.)

The BGP Open message contains the following:
BGP version number
AS number of the local router
Holdtime
BGP router identifier
Optional parameters
BGP v3.21-7
The parameters in the BGP Open message are as follows:

Version number: The suggested version number. The highest common version that both
routers support is used. Most BGP implementations today use BGP version 4 (BGP4).
AS number: The AS number of the local router. The peer router verifies this information.
If it is not the AS number that is expected, the BGP session is torn down.
Holdtime: The number of seconds that may elapse between reception of successive BGP
messages. If the time is exceeded, the peer is considered dead. The two routers agree to use
the lowest suggested value. When the session is established, both routers use keepalive
messages to make sure that the hold timer does not expire. A suggested hold-timer value of
0 indicates that the timer never expires and no keepalives should be sent.
BGP identifier: A number uniquely identifying the router. The Cisco router uses one of its
IP addresses for this number, the router-ID. The router-ID is selected as the numerically
highest IP address of any loopback interface. If there is no loopback interface, the router
uses the highest IP address of any interface that is up at the time of the start of the BGP
process.
Optional parameters: Type, length, value (TLV) encoded. An example of optional
parameters is session authentication.
1-38
Establishing a BGP Session (Cont.)
BGP neighbors? steady state
All neighbors shall be up (no state information).
BGP v3.21-8
When the BGP sessions are in the Established state, routing information exchange can take
place. The show ip bgp summary command output here indicates that a session is established
by not displaying any information at all in the State column.
The counter values show how many messages have been received and sent in the session.
InQ shows how many messages have been received but not yet processed. A high InQ
number indicates lack of CPU resources to process the input. OutQ shows how many
outgoing messages are queued. A high OutQ number indicates lack of bandwidth to transmit
the outgoing messages or CPU overload of the other router.
TblVer (table version) is used by the BGP router to track the changes that need to be sent to
the neighbors. There is a major table version number for the local BGP table. The table version
number is displayed on the first line of output from this show command. There is also one table
version number maintained for each of the neighbors of the BGP router; this number is
displayed on the information line of the neighbors.
Whenever a BGP router enters a change into its BGP table, the major table version number is
incremented and the changed route is tagged with this number. When the time comes to update
a specific neighbor, the router scans the BGP table, and all changes that it finds where the
version number is between the neighbor version and the current table version are sent to the
BGP neighbor in a single BGP routing update. After the entire table is scanned and all changes
have been sent to the neighbor, the table version number of the neighbor is set to the highest
value of the routes being sent.
A table version of a neighbor that is lower than the major table version indicates that the
neighbor is not yet fully updated. The update interval for a neighbor in another AS is normally
30 seconds (the default value of the BGP advertisement timer).
In addition to the information about all sessions to all neighbors, the output also shows the
amount of memory that is being used for the BGP data structures.
BGP Overview
1-39
BGP Keepalives
This topic describes the role of the BGP keepalive in session establishment and maintenance.
BGP Keepalives
A TCP-based BGP session does not provide any
means of verifying BGP neighbor presence:
Except when sending BGP traffic
BGP needs an additional mechanism:

Keepalive BGP messages provide verification of neighbor
existence.
Keepalive messages are sent every 60 seconds.
BGP v3.21-9
TCP-based BGP sessions do not provide any means of verifying the presence of a BGP
neighbor. After BGP has established the TCP session, the only method of verifying neighbor
presence is to actually send BGP traffic. BGP traffic is sent over the TCP session with
acknowledgments (ACKs), and is therefore reliable. Successfully sending BGP traffic confirms
the existence of a BGP neighbor.
However, there are often long periods of time when no BGP traffic is sent between neighbors.
During those periods, TCP implements no mechanism to check for the existence of the
configured neighbor. BGP neighbors could therefore easily be disconnected during times of
session inactivity. This situation would lead to incorrect routing information on the other side
of the BGP session.
To avoid routing packets to a router that is no longer there, BGP needs an additional
mechanism to make sure that a neighbor exists. BGP sends special keepalive messages during
every keepalive interval to inform its peer of its presence. By default, this interval is every 60
seconds. If no BGP traffic is received within the selected holdtime interval, the BGP router
sends a BGP notification message to the inactive peer and tears down the BGP session between
them. The default BGP holdtime value is 180 seconds.
When changing the default values of keepalive and holdtime intervals, you must take care not
to configure too big a keepalive interval in comparison to the holdtime. Too big a difference
could result in resetting of the BGP session after only one keepalive message has been missed,
making a network unstable. The suggested ratio of keepalive-to-holdtime interval is 1:3.
1-40
BGP Keepalives (Cont.)

Keepalive interval value is not communicated in
the BGP Open message.
Keepalive value is selected as follows:
Configured value, if local holdtime is used
Configured value, if holdtime of neighbor is used and
keepalive < (holdtime / 3)
Smaller integer in relation to (holdtime / 3), if holdtime of
neighbor is used and keepalive > (holdtime / 3)
BGP v3.21-10
As opposed to the holdtime interval, BGP peers do not communicate the keepalive interval in
the Open message. The selection of a keepalive interval is therefore based on the selected
holdtime value. The selected holdtime value that is used by both peers is the smaller of both
configured values.
The BGP process selects the keepalive interval value using the following steps:
Step 1
If the locally configured value of holdtime is selected (being the lower of two), the
peers use the locally used keepalive interval.
Step 2
If the holdtime interval of the neighbor is selected, and the locally configured
keepalive interval is less than a third of the holdtime interval, the peers use the
locally configured keepalive.
Step 3
If the holdtime interval of the neighbor is selected, and the locally configured
keepalive interval is more than a third of the holdtime interval, the peers use the
smaller integer value in relation to (holdtime / 3).
Example: Keepalive Value

If the selected holdtime equals 17 seconds and the configured keepalive equals 10 seconds, the
(holdtime / 3) rule will be used to select the keepalive value. Therefore, (17 / 3) = 5.67, and the
keepalive value used by BGP will equal 5 seconds.
BGP Overview
1-41
MD5 Authentication
This topic explains how Message Digest 5 (MD5) authentication protects a BGP neighbor
session.
MD5 Authentication
BGP peers may optionally use MD5 TCP
authentication using a shared secret.
Both routers must be configured with the same
password (MD5 shared secret).
Each TCP segment is verified.
BGP v3.21-11
Authentication between BGP neighbors can be negotiated between BGP-speaking routers using
optional parameters in the Open message. If you are using MD5 authentication, every TCP
segment on the BGP session will be transmitted to the configured neighbor along with a
checksum. The checksum is calculated together with a secret known by the two routers using
the MD5 algorithm. The common secret is never transmitted on the network. If the receiver,
which is using the same common secret, calculates the same checksum from the TCP segment,
then the receiver can be pretty sure that the information is transmitted from the correct source
and the information has not been altered.
Authentication of BGP sessions is a vital tool to avoid denial-of-service (DoS) attacks.
1-42
Summary
Summary
With interior routing protocols, adjacent routers are
usually discovered through a dedicated hello protocol. In
BGP, neighbors must be manually configured to increase
routing protocol security.
BGP neighbors, once configured, establish a TCP session
and exchange the BGP Open message, which contains the
parameters that each BGP router proposes to use.
BGP keepalives are used by the router to provide
verification of the existence of a configured BGP neighbor.
MD5 authentication can be configured on a BGP
session to help prevent spoofing, DoS attacks, or
man-in-the-middle attacks.
BGP v3.21-12
BGP Overview
1-43
1-44
Lesson 4
Processing BGP Routes

Overview
Route processing is fundamental to the operation of Border Gateway Protocol (BGP).
Knowledge of the BGP route selection process, route propagation, and how the BGP and IP
routing tables are built is key to properly configuring BGP and troubleshooting BGP routing
issues.
This lesson explains the details of processing IP routing information in BGP. It describes how a
router builds the BGP routing table, how BGP selects the best route, and how BGP routes are
propagated to other BGP neighbors. The lesson also discusses how a router builds the IP
routing table when it is using BGP.
Objectives
Upon completing this lesson, you will be able to describe BGP route processing. This ability
Describe BGP routing updates
Explain how a router builds BGP tables
Describe the route selection process in BGP
Explain how a router propagates BGP routes to other BGP neighbors
Explain how a router builds an IP routing table when it is using BGP
Explain how BGP advertises local networks
Describe the role of automatic summarization in BGP route processing

This topic describes BGP routing updates.

Small BGP Network
BGP v3.21-3
The network displayed in the figure serves as the sample network for generating printouts in the
following examples.
1-46
Receiving Routing Updates (Cont.)

Information from the BGP tables is exchanged after adjacency
establishment.
BGP v3.21-4
After a BGP session is established, routing updates start to arrive. Each BGP routing update
consists of one or more entries (routes). Each route is described according to the IP address and
subnet mask, along with any number of attributes. The next-hop, autonomous system (AS)path, and origin attributes must always be present. Other BGP attributes are optionally present.
The debug output shows how information about network 37.0.0.0/8 is received from neighbor
2.3.4.5. The neighbor indicates that IP packets to destination IP addresses in network 37.0.0.0/8
can be forwarded to the next-hop address 2.3.4.5. The AS path 21 37 indicates that the final
destination is in AS 37 but the packets have to pass through AS 21 to get there. The metric is
the multi-exit discriminator (MED) value.
Network 21.0.0.0/8 also has the next-hop address of 2.3.4.5, but the AS path of 21 indicates
that that network is inside the directly connected AS 21.
Network 1.0.0.0/8 is denied. The reason is not obvious from the debug output, but the network
topology information indicates that network 1.0.0.0 is local to (inside) AS 123. AS 123 has
advertised the network to AS 37, which propagates to AS 21 and returns to AS 123. This
information loop is detected by the content in the AS-path attribute. The receiving router
detects its own AS number in the AS path and silently discards (denies) the route.
BGP Overview
1-47

This topic explains how a router that is enabled for BGP builds a BGP routing table.

All inbound updates are placed into the BGP table.
BGP v3.21-5
All routes that are received from a neighbor are saved in the router memory. Therefore, there is
no need to retransmit or refresh any unchanged information.
When there is more than one way to reach a particular network, the local router selects one of
those as the best. If that alternative is later lost because the neighboring router withdraws the
route (or the neighboring router is no longer reachable), the remaining alternatives are still
stored in memory and a new alternative is selected as the best without involving other BGP
routers.
The show ip bgp router command gives an overview of all routing information received from
all neighbors. The command displays basic information about each route on a single line. The
output is sortedalternatives to reach the same network are displayed on consecutive lines.
The network number is displayed only on the first lines indicating the same network. The
network column is left blank on the consecutive lines indicating alternatives to reach the same
network.
The router selects only one of the alternatives as the best path toward the destination. This
alternative is indicated with the > sign.
1-48

This topic describes the route selection process in BGP.
Exclude routes with inaccessible next hop

Prefer highest weight (local to router)
Prefer highest local preference (global within AS)
Prefer routes that the router originated
Prefer shortest AS path (only length is compared)
Prefer lowest origin code (IGP < EGP < Incomplete)
Prefer lowest MED
Prefer external (EBGP) paths over internal (IBGP)
For IBGP paths, prefer path through closest IGP neighbor
For EBGP paths, prefer oldest (most stable) path
Prefer paths from router with the lowest BGP router-ID
BGP v3.21-6
When a router has more than one alternative route to reach the same IP subnet (network and
mask), the router has to select one of the routes as best in its default mode of operation. To
make this selection, the router uses the BGP attributes that are attached to the various updates.
The selection criteria are checked in the order that is indicated in the following steps. The first
of the checks that indicates a difference is used, and no further testing is done.
Step 1
The router checks whether the next-hop attribute indicates an IP address that is
reachable according to the current routing table. It is not necessary to have a direct
connection to the next hop. It can very well be several router hops away and the
route to it learned by the Interior Gateway Protocol (IGP). If the next hop is not
reachable, the router does not consider the BGP route as a candidate to become
selected as the best.
Step 2
The router prefers the route with the higher weight. The weight is not carried with
the updates; it is a value that is assigned to the route by the local router and
considered only within the router itself.
Step 3
If the local preference attributes are different, the route with the highest value is
selected as best.
Step 4
If one of the routes is injected into the BGP table by the local router, the local router
prefers it to any routes that it receives from other BGP routers.
Step 5
At this point, the lengths of the AS paths are compared (the content is not checked;
only the number of autonomous systems in each AS path is counted). The route with
the shortest length is selected.
BGP Overview
1-49
Step 6
If the AS-path lengths are the same, the origin code is checked. BGP will prefer the
path with the lowest origin type: IGP is lower than exterior gateway protocol (EGP),
and EGP is lower than Incomplete.
Step 7
The router next compares MED values but only if it receives the updates from the
same neighboring AS. Routes with a lower MED are preferred.
Step 8
At this point it is clear that the destination network is outside the local AS and that
there is not much difference among the alternatives. Because the IP packets to the
destination network must leave the AS, it is better that they do so as quickly as
possible. If any of the alternatives are received from a BGP peer in another AS, that
alternative is preferred.
Step 9
If the router receives all alternatives from peer routers in the local AS, each of them
will indicate an exit point, and the closest exit is used. Distance to the exit point is
calculated by comparing the IGP costs against the BGP next hops, as indicated in the
routing table.
Step 10
If the router receives all alternatives from External Border Gateway Protocol
(EBGP) neighbors, the most stable path (the oldest path) is preferred.
Step 11
If the router still cannot differentiate among the routes, it nevertheless has to make a
decision and select the best route. It checks the BGP sessions on which it received
the updates and chooses the route that was received on the session for which the peer
router has the lowest BGP router-ID.
The router makes the final test only after it has made all other checks and determined that all
alternative routes are equally good.
1-50
Example: BGP Route Selection Criteria

In this example, the router in AS 123 can reach network 21.0.0.0/8 via two paths.
BGP Route Selection Criteria (Cont.)

The best routes to the destination networks are selected
from the BGP table.
BGP v3.21-7
The first path is via neighbor 3.4.5.6 in AS 37 and then to AS 21, and the second path is
straight to AS 21 through neighbor 2.3.4.5. In this example, the weight is set to 100 for the path
via AS 37, and the other alternative path does not have a weight set. Thus, when checked
against BGP path selection rules, the route via AS 37 is selected as the best because it has a
higher weight attribute.
Likewise, network 37.0.0.0/8 is reached via AS 37 because the weight indicates that it is the
best route.
BGP Overview
1-51

This topic explains how a router propagates BGP routes to other BGP neighbors.

The best BGP routes are propagated to BGP
neighbors.
BGP v3.21-8
A local router propagates only the route that it selected as best to the neighbors. However, the
router never sends a route back on the same BGP session upon which it was received. On the
contrary, when it selects a neighbor as the best next hop, the router makes sure that the
neighbor is not pointing back to the local router; it accomplishes this task by poisoning the
route (marking the route unreachable) and sending a withdraw message to that neighbor.
The router conducts route poisoning to avoid a potential routing loop problem in which a
neighbor router selected as the best next hop might rely on the local router as the best next hop.
The process of preventing routing information from being sent back to the source of
information is called split horizon.
1-52

This topic describes the process of building an IP routing table from the BGP table and from
other sources of routing information, such as IGPs.

The best BGP routes are copied into the IP routing
table based on administrative distance.
BGP v3.21-9
The route in the BGP table that BGP selects as the best is a candidate for installation in the IP
forwarding, or routing, table.
Before a route can be installed, the router has to check whether there is any other routing
protocol that has information about the same subnet (network and mask). If the subnet is known
via different sources, the router uses the administrative distance (AD) to determine which
source to use. AD is a rating of the trustworthiness of a routing information source. AD is often
expressed as a numerical value between 0 and 255. The higher the value, the lower the
trustworthiness rating. In this case, the router will install the route with the lowest AD.
The output from the show ip route command indicates which routes in the routing table were
installed using the BGP information. Those routes are denoted with the letter B. The AD is
shown in the command output as the first number within the brackets.
In this example, networks 21.0.0.0/8 and 37.0.0.0/8 are both reachable via 3.4.5.6. After the
router has installed the routes in the routing table, user data traffic starts to be forwarded.
BGP Overview
1-53

This topic explains how BGP advertises local networks.

The BGP router process keeps a list of local networks
(defined with the network command or through
redistribution).
The BGP process periodically scans the IP routing table and
inserts or revokes routes from the BGP routing table based
on their presence in the IP routing table.
BGP v3.21-10
The BGP routing process can inject new routes into the BGP table. A router will propagate
newly injected routes to neighboring BGP peers if it selects them as best, giving neighboring
autonomous systems information about networks that are reachable in the local AS. This
process is called advertising, originating, or announcing local routes.
The BGP process can inject local routes in two different ways:
A list of networks is configured on the router under the BGP router process using the
network configuration command. The networks listed are candidates for being injected.
Networks are injected only if they appear in the routing table. In the case where the IGP
that is used within the AS finds a valid path to them, the routes will be in the routing table.
Routes that are learned by another routing protocol are redistributed. The IGP that is used
with the AS can also act as a source of routing information about local networks.
1-54
Example: Advertising Local Networks

In this example, network 1.0.0.0/8 is directly connected to interface Loopback0.
Advertising Local Networks (Cont.)

The BGP route is revoked after the network is
removed from the routing table.
BGP v3.21-11
The route to 1.0.0.0/8 was previously installed in the BGP table because it was listed with a
network statement and it was in the routing table as directly connected. When the Loopback0
interface goes down, the router removes the directly connected route from its routing table.
Because the route no longer exists in the routing table, it must also be removed from the BGP
table.
Because there has been a change in the BGP table, the BGP neighbors must be informed. The
router sends a BGP update message to both neighbors indicating that network 1.0.0.0/8 is now
unreachable.
BGP Overview
1-55
Advertising Local Networks (Cont.)

The BGP route is advertised after the network
appears in the routing table.
BGP v3.21-12
In this example, network 1.0.0.0/8 is listed with a network statement in the BGP process.
However, the network was not in the routing table of the router, so the network was not injected
into its BGP table.
Later, the Loopback0 interface comes back up again. This reappearance means that the network
1.0.0.0/8 is now in the routing table as a directly connected route. As a result, the router once
again injects the 1.0.0.0/8 network into its BGP table and subsequently updates its configured
neighbors.
1-56
This topic describes the role of automatic summarization in BGP route processing.
Automatic summarization is enabled by default.
Enable automatic summarization when:
Summarization of IGP-to-BGP redistributed routes to
major network boundary required
Using classful network command to summarize subnets to
a major network boundary
Disable automatic summarization when:
Summarization on IGP-to-BGP redistribution not desired
Using classless variant of the network command
BGP v3.21-13
When a BGP router is configured to locally announce routes into BGP, the behavior of the
network command varies depending on whether automatic summarization is enabled or
disabled. When automatic summarization is enabled, BGP summarizes the locally originated
BGP networks (network x.x.x.x) to their classful boundaries. Automatic summarization is
enabled by default in BGP.
When a subnet exists in the routing table and the following three conditions are satisfied, then
any subnet (component route) of that classful network in the local routing table will prompt
BGP to install the classful network into the BGP table:
A classful network statement for that network exists in the routing table.
A classful mask has been configured on that network statement.
Automatic summarization is enabled.
When automatic summarization is disabled, the routes that are introduced locally into the BGP
table are not summarized to their classful boundaries.
The behavior of the redistribution procedure in BGP is also influenced by the configuration of
automatic summarization on the router. When enabled, all redistributed subnets will be
summarized to their classful boundaries in the BGP table. When disabled, all redistributed
subnets will be present in their original form in the BGP table.
Enable automatic summarization in BGP when the summarization of subnets to their classful
boundaries will not introduce flawed information into the BGP table. In other words, leave
automatic summarization enabled only when you are using a fully assigned classful network
matching the network that was summarized in BGP.
BGP Overview
1-57
Whenever possible, use the classless variant of the network command, specifying the subnet
mask length of the network. When you are redistributing networks into BGP, the preferred
method is to disable automatic summarization. Disabling automatic summarization ensures that
correct information is inserted into the BGP table of the router.
Example: Automatic Summarization

In this example, one subnet and one host route of the major class C network 197.1.1.0/24
(197.1.1.64/27 and 197.1.1.49/32) exist in the routing table.
Automatic Summarization (Cont.)
One subnet and one host route for 197.1.1.0 exist in the routing table.
Automatic summarization is enabled for BGP.
BGP has been configured to locally announce 197.1.1.0.
Classful network summary is inserted into BGP table.

BGP v3.21-14
When you are inserting networks into the BGP table with the classful network command and
automatic summarization is disabled, no insertion into the BGP table will occur unless an exact
match exists in the IP routing table (meaning that a classful network has to be present in the IP
routing table).
When automatic summarization is enabled, the major network command will summarize all
subnets in the IP routing table to their major network boundary.
There is a classful network command, and automatic summarization is enabled for BGP. This
setup results in the insertion of a classful network summary into the BGP table, instead of
separate subnets.
Subnet 197.1.1.64/27 and host route 197.1.1.49/32 were summarized during insertion into the
BGP table to the classful network 197.1.1.0/24. This action occurred because a classful
network command and automatic summarization were configured on the router. If automatic
summarization were disabled, no insertion into the BGP table would occur at all.
The locally sourced summary has all the attributes of a locally sourced BGP route (next hop =
0.0.0.0, weight = 32768, empty AS-path list), and is marked as having an IGP origin (being
sourced with the network command).
1-58
Automatic Summarization (Cont.)
One subnet and two host routes for 172.16.0.0 exist in the routing table.
Automatic summarization is enabled for BGP.
BGP has been configured to redistribute Open Shortest Path First
(OSPF) into BGP.
Classful network summary is inserted into BGP table.

BGP v3.21-15
In this example, automatic summarization is enabled, resulting in the summarization of

redistributed subnets to their classful boundaries. Subnet 172.16.1.0/30 and the two host routes
172.16.0.2/32 and 172.16.0.3/32 will be summarized into the single class B network
172.16.0.0/16. The network 172.16.0.0/16 is a locally sourced summary with all the attributes
of a locally sourced BGP route (next hop = 0.0.0.0, weight = 32768, empty AS-path list). The
origin of the route is marked as incomplete because the route is sourced through redistribution.
If automatic summarization were disabled, more specific routes would be present in the BGP
table instead of the summary prefix 172.16.0.0/16.
BGP Overview
1-59
Summary
Summary
After BGP sessions are established between BGP routers,
they can start exchanging routing updates.
All updates that are received from BGP neighbors are stored
in the BGP table, regardless of whether they are used.
The route selection process takes into account various BGP
attributes that are attached to the route, as well as local
decisions (indicated with weights).
Only the best BGP routes are propagated to other BGP
routers.
BGP v3.21-16
Summary (Cont.)
Only the best BGP routes are installed in the local IP routing
table.
Every BGP router can also originate the routes in BGP. The
routes to be originated are entered manually in the BGP
routing process or redistributed into BGP from an IGP.
Automatic summarization is enabled by default in BGP.
1-60
BGP v3.21-17
Lesson 5

Overview
Basic Border Gateway Protocol (BGP) configuration is critical to any successful BGP
implementation. Network administrators use the Cisco IOS commands that are included in this
lesson in all BGP implementations. Thorough knowledge of the commands in this lesson is
therefore crucial to ensuring a successful implementation using BGP.
This lesson introduces the Cisco IOS commands that are required to configure a router for basic
BGP operation. Included are the commands that are used to enable the BGP routing protocol
process, establish neighbors, and advertise local routes. This lesson concludes with basic
commands that network administrators can use to monitor the BGP configuration.
Objectives
Upon completing this lesson, you will be able to configure a router for BGP. This ability
Identify the Cisco IOS command that is required to configure the BGP routing process
Identify the Cisco IOS commands that are required to configure external BGP neighbors
Identify the Cisco IOS commands that are required to configure the basic timers that are
used in BGP
Identify the Cisco IOS command that is required to configure MD5 authentication for BGP
Identify the commands that are required to announce local networks in BGP
Describe BGP route redistribution, including the commands that are required to configure
BGP route redistribution
Describe the classless behavior of BGP and identify the Cisco IOS command that is
required to configure BGP for classless operation
Describe BGP route aggregation, including the Cisco IOS commands that are required to
configure basic BGP route aggregation
Describe the BGP Conditional Route Injection feature
Describe the BGP Support for TTL Security Check feature
Determine when BGP route aggregation is not appropriate in multihomed topologies
BGP Routing Process

This topic describes the command that is required to initially configure the BGP routing
process on a Cisco IOS router.
BGP Routing Process

Starts BGP routing.
Get your AS number from American Registry for Internet
Numbers (www.arin.net) or Rseaux IP Europens
(www.ripe.net).
Use private AS numbers (6451265535) if you run BGP in a
private network.
Only one BGP routing process per router is allowed.
BGP v3.21-3
router bgp
To configure the BGP routing process, use the router bgp global configuration command.
router bgp as-number
To remove a routing process, use the no form of this command.
no router bgp as-number
Syntax Description
Parameter
Description
Number of an autonomous system (AS) that identifies the router

to other BGP routers and tags the routing information that is
passed along
This command starts the BGP routing process in the router. There can be, at most, one BGP
process in a router. It must be assigned the local AS number.
The AS number is a 16-bit unsigned integer. It must uniquely identify the AS among all routers
that are exchanging BGP routing information, either directly or indirectly. This requirement
means that the AS numbers must be unique when BGP information is exchanged with the
Internet.
The AS number can be a public AS number (ranging from 1 to 64511) that is assigned by an
Internet registry (American Registry for Internet Numbers [ARIN]: www.arin.net or Rseaux
IP Europens [RIPE]: www.ripe.net), or a private AS number (ranging from 64512 to 65535).
Private AS numbers are never propagated onto the public Internet.
1-62

This topic describes the commands that are required to configure external BGP neighbors on a
Cisco router.

Defines an external neighbor.
External neighbor has to be reachable over directly connected
subnet.

Assigns a description to an external neighbor.
BGP v3.21-4
BGP does not automatically discover neighbors. They have to be explicitly configured. The
local router will try to connect to the indicated IP address and also accept incoming connection
attempts from the indicated IP address.
The first attribute that you must configure with a new neighbor is the remote AS number in
which the neighbor is taking part. When the TCP session is established between BGP routers,
the configured remote AS number is verified by each router with the exchange of BGP Open
messages.
You may optionally configure other attributes with the neighbor. Do this on successive
configuration lines, referring to the same neighbor IP address but indicating different attributes.
With the neighbor description command, a description (text string) can be entered that
describes the neighbor.
neighbor remote-as
To add an entry to the BGP neighbor table, use the neighbor remote-as router configuration
command.
neighbor {ip-address | peer-group-name} remote-as number
To remove an entry from the table, use the no form of this command.
no neighbor {ip-address | peer-group-name} remote-as number
BGP Overview
1-63
Syntax Description
Parameter
Description
IP address of neighbor
Name of a BGP peer group
AS to which the neighbor belongs
To associate a description with a neighbor, use the neighbor description router configuration
command.
neighbor {ip-address | peer-group-name} description text
To remove the description, use the no form of this command.
no neighbor {ip-address | peer-group-name} description text
Syntax Description
1-64
Parameter
Description
Text (up to 80 characters) that describes the neighbor
Configuring External Neighbors (Cont.)

To temporarily disable a BGP neighbor:

Disables communication with a BGP neighbor
Use scenarios:
Debugging and troubleshooting
Shutdown of the neighbor during extensive modification
of routing policies to prevent inconsistent routing data
BGP v3.21-5
neighbor shutdown
To disable a neighbor, use the neighbor shutdown router configuration command.
neighbor {ip-address | peer-group-name} shutdown
To re-enable the neighbor or peer group, use the no form of this command.
no neighbor {ip-address | peer-group-name} shutdown
Syntax Description
Parameter
Description
BGP Overview
1-65

This topic describes the commands that are required to modify the default keepalive and
holdtime timers in BGP for the BGP process or for the TCP session between BGP neighbors.

Changes the default values of BGP timers per BGP process.
Only the holdtime value is communicated in the BGP Open
message.
Smallest configured holdtime value on BGP peers is used by
both peers.
Changes the default values of BGP timers per specific neighbor

or peer group.
Overrides the bgp settings of the timers.
BGP v3.21-6
Changing the BGP default holdtime and keepalive timers is usually not recommended. The
defaults (keepalive: 60 seconds; holdtime: 180 seconds) should work fine in most situations. If
for any reason a faster BGP response to a peer down event is needed (for example, in scenarios
where multiple paths toward destinations are available), the neighbor timers on the router can
be reduced. This reduction will result in a faster detection of a lost peer and faster switching to
the alternate path in the BGP table, thus improving convergence.
A BGP router with an expired holdtime (no BGP traffic was received within the holdtime
interval) sends a notification to its BGP peer, notifying it as to the reason for closing the
session. The BGP router on which the holdtime has expired moves the inactive peer into the
Idle state. After a certain time interval, determined by auto-enable and connection timers, a
BGP router again tries to reconnect to the previously disconnected BGP peer and will also
accept connection attempts from that peer.
timers bgp
To adjust BGP network timers, use the timers bgp router configuration command.
timers bgp keepalive holdtime
To reset the BGP timing defaults, use the no form of this command.
no timers bgp keepalive holdtime
1-66
Syntax Description
Parameter
Description
Frequency (in seconds) with which the Cisco IOS software sends
keepalive messages to its peer.
The default is 60 seconds.
Interval (in seconds) after not receiving a keepalive message that

the software declares a peer dead.
neighbor timers
To set the timers for a specific BGP peer or peer group, use the neighbor timers router
configuration command. This command overrides the values that have been set by the timers
bgp command.
neighbor [ip-address | peer-group-name] timers keepalive holdtime
To clear the timers for a specific BGP peer or peer group, use the no form of this command.
no neighbor [ip-address | peer-group-name] timers keepalive holdtime
Syntax Description
Parameter
Description
IP address of neighbor.
Name of a BGP peer group.
Frequency (in seconds) with which the Cisco IOS software sends
keepalive messages to its peer.
Interval (in seconds) after not receiving a keepalive message that

the software declares a peer dead.
BGP Overview
1-67

This topic describes the command that is required to configure Message Digest 5 (MD5)
authentication on a session between BGP neighbors.

Enables MD5 authentication on a specific BGP session.
Password string on both routers must match.
BGP v3.21-7
neighbor password
To enable MD5 authentication on a TCP connection between two BGP peers, use the neighbor
password router configuration command.
neighbor {ip-address | peer-group-name} password string
To disable this function, use the no form of this command.
no neighbor {ip-address | peer-group-name} password
Syntax Description
Parameter
Description
Case-sensitive password of up to 80 characters.

The first character cannot be a number. The string can contain
any alphanumeric characters, including spaces. You cannot
specify a password in the format number-space-anything. The
space after the number causes problems.
1-68

This topic describes the Cisco IOS commands that are required to announce local networks to
other BGP neighbors.

Only administratively defined networks are
announced in BGP.
Manually configure networks to be announced.
Use redistribution from IGP.
Use aggregation to announce summary prefixes.
BGP v3.21-8
Before any local routing information can be injected by a router into its BGP table for
advertising to other BGP routers, some basic configuration is required.
There are two ways to do this configuration:
List the network numbers that are candidates to be advertised using the network
configuration command. If any of the listed networks are reachable by the local router,
according to its routing table, then the network is injected as a route into the BGP table.
Redistribute routing information that has been learned by other routing protocols into the
BGP table. You can use the Interior Gateway Protocol (IGP) that is used within the AS.
Any route that is known by the local IGP can be injected into the BGP table using route
redistribution between the IGP and BGP on the local router.
A router can also introduce new routing information into the BGP table by summarizing routes
already there. This activity is called route aggregation and also requires configuration.
Any route that is introduced by the router into the BGP table will appear as a new route. The
AS-path attribute for such a route will be empty, indicating a local route. The AS path changes
later as the route passes AS boundaries.
BGP Overview
1-69
Announcing Networks in BGP (Cont.)

Enables or disables summarization of networks prior to
insertion into the BGP table:
Locally inserted networks (using the network command)
Redistributed routes
Enabled by default
BGP v3.21-9
When the router is configured to locally announce routes into BGP, the behavior of the
network command varies depending on whether automatic summarization is enabled or
disabled. When automatic summarization is enabled, the command summarizes locally
originated BGP networks to their classful boundaries. By default, automatic summarization is
enabled for BGP.
When a subnet exists in the routing table and the following three conditions are satisfied, then
any subnet (component route) of that classful network in the local routing table will prompt
BGP to install the classful network into the BGP table:
A classful network statement for that network exists in the routing table.
When automatic summarization is disabled, the routes that are introduced locally into the BGP
table are not summarized to their classful boundaries.
The BGP auto-summary command is also responsible for the behavior of the redistribution
procedure in BGP. When the command is enabled, all redistributed subnets will be summarized
to their classful boundaries in the BGP table. When it is disabled, all redistributed subnets will
be present in their original form in the BGP table.
1-70

To manually define a major network:

Allows advertising of major networks into BGP.
At least one of the subnets must be present in the routing table.
Behavior is dependent on the presence of the
auto-summary command.
The meaning of the network command in BGP is completely
different from any other routing protocol.
BGP v3.21-10
To specify the networks to be advertised by the BGP routing process, use the network router
configuration command. To remove an entry, use the no form of this command.
Note
The meaning of the network command in BGP is radically different from the meaning of the
command in other routing protocols. In all other routing protocols, the network command
indicates interfaces over which the routing protocol will be run. In BGP, it indicates only
which routes should be injected into the BGP table on the local router. Also, BGP never runs
over individual interfaces; it is run over TCP sessions with manually configured neighbors.
The network command with no mask option uses the classful approach to insert a major
network into the BGP table. At least one subnet of the specified major network needs to be
present in the IP routing table to allow BGP to start announcing the major network as a BGP
route. If automatic summarization is disabled, an exact match is required.
BGP Overview
1-71

The addition of the route-map option allows network parameters
to be modified before you enter them into the BGP table.
The route-map option can be used for the following:
Changing the weight value of a locally sourced route
Tagging sourced routes with BGP communities
Setting the local preference for a specific network
Changing the value of the MED for a specific network
BGP v3.21-11
When the router is configured to insert routes into the BGP table, the default attributes of
locally sourced routes can be modified with the inclusion of the route-map option in the basic
network command.
The attached route-map can change the following attributes of locally sourced networks with
the network command:
Weight (default value = 32768): The weight attribute is a special Cisco attribute that is
used in the path selection process when there is more than one route to the same
destination. Because weight is considered before local preference in BGP route selection,
locally sourced routes are always preferred, unless the weight value is modified.
Community (default value = nonexistent): Used for tagging routes at their source.
Local preference (default value = 100): Used for AS-wide BGP best-path selection.
Multi-exit discriminator (MED) (default value = 0): Used for return-path selection in
topologies where multiple exit points to the same neighbor AS exist.
Example: Announcing Networks in BGP

If a subnet existing in the routing table is 75.75.75.0/24, and network 75.0.0.0 is configured
under the router bgp command (assuming that automatic summarization is enabled), BGP will
introduce the classful network 75.0.0.0/8 in the BGP table. If the following three conditions are
not all met, then BGP will not install any entry in the BGP table unless there is an exact match
in the IP routing table:
A classful network statement for the network exists in the routing table.
1-72

This topic describes route redistribution in BGP and identifies the Cisco IOS commands that
are required to configure BGP route redistribution.

Easier than listing networks in BGP process in large
networks.
Redistributed routes carry origin attribute incomplete.
Always filter redistributed routes to prevent route leaking.
Avoid in service provider environments.
BGP v3.21-12
There are two alternatives for injecting local routes into the BGP table: list them using the
network command or redistribute them. Listing the routes gives you total control over
networks that could possibly be advertised by BGP. This option is very desirable for
multihomed customers or Internet service providers (ISPs). On the other hand, this approach
requires a lot of configuration commands that could be hard to maintain.
If there are a lot of networks to be advertised, and BGP is used primarily to achieve scalability,
not routing security (for example, in enterprise networks), it could be easier to let the local IGP
find the routes and then redistribute them into BGP. However, this approach introduces the risk
that the IGP may find some networks that are not supposed to be advertised. Private network
numbers, such as network 10.0.0.0/8, are often used within an AS for various reasons but must
never be advertised out to the Internet. Careful filtering must be done to prevent unintentional
advertising.
When the router injects a route that is listed with a network command into its BGP table, the
origin code is set to IGP. If the route is injected into the BGP table through redistribution, the
origin code is set to unknown/incomplete.
BGP Overview
1-73
Redistributing Routes into BGP (Cont.)

Simple IGP-to-BGP redistribution
Configure redistribution in BGP process.
Configure route-filter using distribute-list.
Caveat:
BGP routes originated through redistribution have
incomplete origin.
BGP v3.21-13
Routes redistributed into BGP will carry the origin attribute incomplete. In most cases this
situation does not jeopardize BGP functionality. It could pose a problem if the route selection
process has to decide on the best route toward a particular destination based on the MED
attribute. In the case of receiving two routes, one with the IGP origin (inserted with the
network command), and another one with the incomplete origin, the first route would always
be selected, no matter what value the MED attribute is set to (according to the BGP route
selection rules).
redistribute (IP)
To redistribute routes from one routing process into another routing process, use the
redistribute router configuration command.
redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [metric metric-value]
[match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [weight
weight] [subnets]
To disable redistribution, use the no form of this command.
no redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [metric metric-value]
[match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [weight
weight] [subnets]
1-74
Syntax Description
Parameter
Description
Source protocol from which routes are being redistributed.

It can be one of the following keywords: bgp, isis, ospf, eigrp,
rip.
(Optional) For bgp, egp, or eigrp, this is an AS number, which is

a 16-bit decimal number.
For isis, this is an optional tag that defines a meaningful name for
a routing process. You can specify only one Intermediate
System-to-Intermediate System (IS-IS) process per router.
Creating a name for a routing process means that you use names
when configuring routing.
For ospf, this is an appropriate Open Shortest Path First (OSPF)
process ID from which routes are to be redistributed. This ID
identifies the routing process. This value takes the form of a
nonzero decimal number.
For rip, no process ID value is needed.
For IS.
For IS.
For IS.
(Optional) Metric that is used for the redistributed route.

If a value is not specified for this option, and no value is specified,
the default metric is used.
(Optional) For OSPF, the criterion by which OSPF routes are

redistributed into other routing processes.
It can be one of the following:
internal: Routes that are internal to a specific AS.
external 1: Routes that are external to the AS but are
imported into OSPF as a type 1 external route.
external 2: Routes that are external to the AS but are
imported into OSPF as a type 2 external route.
(Optional) The route-map should be interrogated to filter the

importation of routes from this source routing protocol to the
current routing protocol. If not specified, all routes are
redistributed. If this keyword is specified, but no route-map tags
are listed, no routes will be imported.
(Optional) Identifier of a configured route-map.
(Optional) Network weight when you are redistributing into BGP.

An integer from 0 to 65535.
Indicates that not only networks with a natural mask should be

redistributed but also subnets.
BGP Overview
1-75
distribute-list out (IP)

To suppress networks from being advertised in updates, use the distribute-list out router
configuration command with routing-process specified.
distribute-list {access-list-number | access-list-name} out [interface-name | routingprocess | autonomous-system-number]
To cancel this function, use the no form of this command.
no distribute-list {access-list-number | access-list-name} out [interface-name | routingprocess | autonomous-system-number]
The access-list referred to by the distribute-list command permits the routes that should be
redistributed.
1-76
Redistributing Routes into BGP (Cont.)

Redistribution using route-maps
Origin can be set to IGP with a route-map.
Other BGP path attributes can also be set:
Metric
Next-hop
Community
BGP v3.21-14
Route-maps can be configured on the router to filter updates and modify various attributes. A
configured route-map can be applied to routes being redistributed from the IGP.
Only the routes permitted by the route-map will be redistributed. Using the set command in the
route-map, you can modify specific path attributes that are attached to the redistributed routes.
Thus, only selected routes will be advertised, and they will have the desired attribute values.
The route-map must be given a name. This name is a case-sensitive string, which is used when
you are referring to the route-map. Any string could be used, but a meaningful name is
suggested.
Use the route-map global configuration command and the match and set route-map
configuration commands to define the conditions for redistributing routes. Each repetition of
the route-map command has a list of match and set commands that are associated with it. The
match commands specify the match criteriathe conditions under which redistribution is
allowed for the current route-map command. The set commands specify the set actionsthe
particular redistribution actions to perform if the criteria enforced by the match commands are
met.
When you are passing routes through a route-map, it can have several parts. Any route that
does not match at least one match clause relating to a route-map command will be ignored;
that is, the route will not be advertised. If you want to modify only some data, you must
configure a second route-map section with an explicit match specified.
BGP Overview
1-77

This topic describes the classless behavior of BGP and the command that is required to
advertise a classless BGP supernet prefix.

BGP4 supports CIDR.
Any BGP router can advertise individual networks or
supernets (prefixes).
Prefix notation is used with BGP instead of subnet masks.
192.168.0.0/16 = 192.168.0.0 255.255.0.0
BGP v3.21-15
BGP version 4 (BGP4) is a classless protocol, meaning that its routing updates include the IP
address and the subnet mask. The combination of the IP address and the subnet mask is called
an IP prefix. An IP prefix can be a subnet, a major network, or a supernet.
BGP uses prefix notation (address/number of bits) to display IP prefixes. The number following
the slash (/) in the 192.168.0.0/16 notation in the figure refers to the number of bits in the
subnet mask being set to 1. The subnet mask 255.255.0.0 starts with 16 consecutive bits set to
1, and the rest of the bits set to 0.
As another example, the subnet 172.16.1.0 with mask 255.255.255.0 can be written using the
prefix notation as 172.16.1.0/24.
When classless prefix notation is used, an old class A network, for example, 10.0.0.0, with the
natural mask, is written as 10.0.0.0/8. A class B network, 172.17.0.0 with natural mask, is
written as 172.17.0.0/16, and a class C network, 192.168.1.0 with natural mask, is written as
192.168.1.0/24.
1-78
Configuring Classless BGP (Cont.)
To manually announce a classless prefix in BGP:

Configures a classless prefix to be advertised
into BGP.
The prefix must exactly match an entry in the IP routing table.
Use a static route to null 0 to create a matching prefix in the IP
routing table.
BGP v3.21-16
To advertise classless networks into BGP (a subnet or a supernet), you can use the network
command with the mask keyword and the subnet mask specified. When an exact match is not
found in the IP routing table (for example, when you are creating a summary or when you are
advertising only a part of your address space), a matching prefix has to be manually configured
on the router in the form of a static route pointing to the null 0 interface; otherwise, the
advertisement will not succeed.
network (BGP)
To specify the networks to be advertised by the BGP routing process, use the network router
configuration command.
network network-number [mask network-mask]
To remove an entry, use the no form of this command.
no network network-number [mask network-mask]
Syntax Description
Parameter
Description
Network that BGP will advertise
(Optional)
(Optional) Network mask address
If the keyword mask and the subnet mask are omitted, the network is assumed to have its
natural mask according to the network class. In this case, the route will still be injected into the
BGP table on the router if there is any subnet of the major network that is reachable according
to the routing table.
BGP Overview
1-79
If the network mask is specified, the behavior changes slightly, and it is required that an exact
match of network number and subnet mask appear in the routing table before the route is
injected into the BGP table.
Example: Configuring Classless BGP

In this example, the IP address space 192.168.0.0/16 is assigned to a service provider, and the
service provider would like that address space to be constantly advertised by BGP.
Configuring Classless BGP (Cont.)
To advertise a supernet prefix:

Advertise prefix 192.168.0.0/16 assigned to the Internet service
provider.
BGP v3.21-17
The network command with the mask option tells BGP that 192.168.0.0/16 is a candidate for
being advertised. The mask keyword and the mask 255.255.0.0 are required because the mask
is not the natural one. However, before the candidate route is actually advertised, the router
checks the routing table for an exact match (both network number and mask). It will always be
found because there is a static route for it. This static route points to the null interface, which is
always available.
The conclusion is that 192.168.0.0/16 will always be advertised by this router. All other BGP
routers will use this information and forward any IP packets with the destination IP address in
the interval 192.168.0.0 to 192.168.255.255 (inclusive) in the direction of this router. When
those packets arrive, the router, in this example, must have more explicit routes to the different
parts of the 192.168.0.0/16 address range. This need could be answered by the IGP, which is
not shown in the configuration example.
If, however, an IP packet arrives with a destination address to which this router does not have a
more explicit route, the static route will route the packet to the null interface, where it is
dropped. This routing is a safety precaution that will prevent a routing loop, which might occur
when route summaries are used in combination with default routing. If, for example, a packet
arrives from the Internet to a subnet of 192.168.0.0/16, which is currently not reachable, the
packet might otherwise follow the default route toward the Internet because there is no more
explicit route. Of course, the packet would immediately be routed back again, and a routing
loop would occur.
1-80

This topic describes route summarization in BGP. It also lists the configuration commands that
are required to configure summary routes in BGP.

Summarization is called aggregation
in BGP.
Aggregation creates summary routes (called aggregates)
from networks already in BGP table.
Individual networks can be announced or suppressed.
BGP v3.21-18
When the BGP table is already populated with routes that should be summarized, you must
configure a router to do so. The summarization of BGP routes is called aggregation.
Use aggregation when a group of more specific routes has been injected into the BGP table at
one stage but can be summarized at a later stage. The routes to be summarized could be IGP
routes that have been redistributed into BGP. Before BGP advertises these routes to the rest of
the network, an aggregation of the subnets into a larger announcement would be appropriate.
In some networks, more specific routes are injected into the BGP table by some routers, and
aggregation is done in another router or even in another AS. This is called proxy aggregation.
When a router is configured to do aggregation, you must configure the route summary. If any
route that is already in the BGP table is within the range that is indicated by the summary, then
the summary route is also injected into the BGP table on the route and advertised to other
routers. This action creates more information in the BGP table. To get any benefits from the
aggregation, you must suppress the more specific routes that are covered by the route summary.
This suppression is an option to the aggregate configuration command.
When you suppress the more specific routes through configuration, they are still present in the
BGP table of the router doing the aggregation. However, because the routes are marked as
suppressed, they are never advertised to any other router.
BGP Overview
1-81
Aggregating BGP Networks (Cont.)

Specify aggregation range in BGP routing process.
The aggregate will be announced if there is at least one network
in the specified range in the BGP table.
Individual networks will still be announced in outgoing BGP
updates.
BGP v3.21-19
In this configuration command syntax, where the keyword summary-only is not used, both the
route summary and the more specific routes will be advertised. This approach is generally not
desirable. Therefore, suppression of individual routes, described next, is used in most cases.
aggregate-address
To create an aggregate entry in a BGP routing table, use the aggregate-address router
aggregate-address address mask [as-set] [summary-only] [suppress-map mapname][advertise-map map-name] [attribute-map map-name]
no aggregate-address address mask [as-set] [summary-only] [suppress-map mapname][advertise-map map-name] [attribute-map map-name]
Syntax Description
1-82
Parameter
Description
Aggregate address
Aggregate mask
(Optional) Suppresses more specific routes
Aggregating BGP Networks (Cont.)

An alternative method to configure aggregation:

Configure aggregation of BGP routes.
Advertise only the aggregate and not the individual networks.
Benefits:
Smaller BGP routing tables
More stable internetworks (less route flapping)
Drawback:
Problems with multihomed customers
BGP v3.21-20
When the summary-only option is used, only the route summary will be advertised, not the
more specific routes.
One of the benefits of this approach is that the rest of the routers will receive only one route
instead of many more specific routes. It eases the burden on the other routers by reducing the
amount of memory that is required to hold the BGP table.
Another benefit is that route flapping is reduced. The router doing the aggregation continues
advertising the aggregate as long as there is at least one specific route within the range still
available. If one of the more specific routes is lost but at least one remains, the aggregate itself
is not lost. The flap of the more specific route is not visible to the rest of the network. This
approach reduces the number of updates necessary and the CPU power that is required to
process them.
However, all route summarization in any routing protocol causes a loss of granularity (that is,
lack of more detailed network or subnet visibility). Suboptimal routing could be introduced
when redundant paths are available to reach a group of networks that are advertised by a single
route summary. Some of the networks could be more reachable via one of the paths, while
others may be more reachable another way. From outside the immediate network, multiple
paths may not be visible because only summary routes are advertised. Therefore, there is a risk
that the least optimal path will be chosen.
BGP Overview
1-83
Example: Aggregation
This example illustrates a classless BGP sample configuration.
Aggregation Example
Classless BGP sample configuration
Advertise prefix 192.168.0.0/20.
Aggregate networks in 192.168.16.0/20 and announce individual
networks.
Aggregate networks in 192.168.32.0/20 and suppress individual
network announcements.
BGP v3.21-21
The configuration example in the figure shows three different ways of advertising a route
summary:
The prefix 192.168.0.0/20 is always advertised. It is injected into the BGP table as a
summary. The network statement makes it a candidate for being advertised. Because the
mask is specified, an exact match in the routing table is a required condition before the
route is injected into the BGP table. The matching route is inserted in the IP routing table
by the static IP route statement to the null 0 interface.
The prefix 192.168.16.0/20 is conditionally advertised. It is injected into the BGP table
whenever there is a more specific route within the route summary range that is already in
the BGP table. However, the more specific route is still advertised.
The prefix 192.168.32.0/20 is also conditionally advertised. It is injected into the BGP table
whenever there is a more specific route within the route summary range that is already in
the BGP table. However, any more specific routes are suppressed and not advertised to any
neighbors.
1-84
Aggregation Example (Cont.)

Viewing the BGP table
BGP v3.21-22
The show ip bgp command prints the BGP table. As shown in the figure, all three prefixes are
injected:
The prefix 192.168.0.0/20 is always injected.
The prefix 192.168.16.0/20 is injected because there is at least one more specific route
within the summary range. In this case, both 192.168.16.0/24 and 192.168.17.0/24 are
within the range. Nothing is changed with the more specific routes, so they are still
advertised.
The prefix 192.168.32.0/20 is injected because there is at least one more specific route
within the summary range. In this case, both 192.168.32.0/24 and 192.168.33.0/24 are
within the range. The more specific routes are marked as suppressed using the lowercase
letter s. The s means that they are still present and available in the BGP table of the
router, but they are not advertised on any BGP session.
Note
Because the prefixes 192.168.16.0/24, 192.168.17.0/24, 192.168.32.0/24, and

192.168.33.0/24 all have natural masks as applied to class C networks, the prefix length is
not displayed in the show ip bgp printout. The network mask is, however, stored in the BGP
table and sent on any BGP update.
BGP Overview
1-85
Aggregation Example (Cont.)

Debugging BGP updates
BGP v3.21-23
The debug output shows the BGP updates that have been sent to a neighbor. All three route
summary prefixes, 192.168.0.0/20, 192.168.16.0/20, and 192.168.32.0/20, are included in the
updates. Also, the nonsuppressed more explicit routes, 192.168.16.0/24 and 192.168.17.0/24,
are included in the update. However, the suppressed more explicit routes, 192.168.32.0/24 and
192.168.33.0/24, are never sent as updates on the BGP session.
1-86

This topic describes the BGP Conditional Route Injection feature.

Provides means to originate a prefix into a BGP routing table
without the corresponding match
Allows more specific routes to be generated based on
administrative policy or traffic engineering information to
provide more specific control over the forwarding of packets
to these more specific routes, which are injected into the
BGP routing table only if the configured conditions
are met
Improves accuracy of common route aggregation by
conditionally injecting or replacing less specific prefixes with
more specific prefixes
BGP v3.21-24
Routes that are advertised through the BGP are commonly aggregated to minimize the number
of routes that are used and reduce the size of global routing tables. However, common route
aggregation can obscure more specific routing information that is more accurate but not
necessary to forward packets to their destinations. Routing accuracy is obscured by common
route aggregation because a prefix that represents multiple addresses or hosts over a large
topological area cannot be accurately reflected in a single route. Cisco IOS software provides
several methods by which you can originate a prefix into BGP. The methods include
redistribution and using the network or aggregate-address command. These methods assume
the existence of more specific routing information (matching the route to be originated) in
either the routing table or the BGP table.
The BGP Conditional Route Injection feature allows you to originate a prefix into a BGP
routing table without the corresponding match. This feature allows more specific routes to be
generated based on administrative policy or traffic engineering information to provide more
specific control over the forwarding of packets to these more specific routes, which are injected
into the BGP routing table only if the configured conditions are met. Enabling this feature
allows you to improve the accuracy of common route aggregation by conditionally injecting or
replacing less specific prefixes with more specific prefixes. Only prefixes that are equal to or
more specific than the original prefix may be injected.
The BGP Conditional Route Injection feature is enabled with the bgp inject-map exist-map
command. This command uses two route maps (inject-map and exist-map) to install one (or
more than one) more specific prefix into a BGP routing table. The exist-map specifies the
prefixes that the BGP speaker will track. The inject-map defines the prefixes that will be
created and installed into the local BGP table.
BGP Overview
1-87
bgp inject-map exist-map

To inject a more specific route into a BGP routing table, use the bgp inject-map exist-map
command in address family or router configuration mode.
bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes]
No bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes]
Syntax Description
Parameter
Description
Defines the prefixes that will be created and installed into the
local BGP table
Specifies the prefix that the BGP speaker will track
(Optional) Configures the injected route to inherit the attributes of

the aggregate route
This configuration example configures conditional route injection for the inject-map named
ORIGINATE and the exist-map named LEARNED_PATH:

1-88

This topic describes the BGP Support for TTL Security Check feature.

Lightweight security mechanism to protect EBGP peering
sessions from CPU utilization-based attacks
Protects the EBGP peering session by comparing the value
in the TTL field of received IP packets against a hop count
that is configured locally for each EBGP peering session
Supports both directly connected peering sessions and
multihop EBGP peering sessions
BGP v3.21-25
The BGP Support for TTL Security Check feature introduces a lightweight security mechanism
to protect External Border Gateway Protocol (EBGP) peering sessions from CPU utilizationbased attacks. These types of attacks are typically brute-force denial of service (DoS) attacks
that attempt to disable the network by flooding the network with IP packets that contain forged
source and destination IP addresses. This feature protects the EBGP peering session by
comparing the value in the Time to Live (TTL) field of received IP packets against a hop count
that is configured locally for each EBGP peering session. If the value in the TTL field of the
incoming IP packet is greater than or equal to the locally configured value, the IP packet is
accepted and processed normally. If the TTL value in the IP packet is less than the locally
configured value, the packet is silently discarded and no Internet Control Message Protocol
(ICMP) message is generated. This is designed behavior; a response to a forged packet is
unnecessary.
Accurately forging the TTL count in an IP packet is generally considered to be impossible. It is
possible to forge the TTL field in an IP packet header. However, accurately forging a packet to
match the TTL count from a trusted peer is not possible unless the network to which the trusted
peer belongs has been compromised.
This feature supports both directly connected peering sessions and multihop EBGP peering
sessions. The BGP peering session is not affected by incoming packets that contain invalid TTL
values. The BGP peering session remains open, and the router silently discards the invalid
packet. The BGP session, however, can still expire if keepalive packets are not received before
the session timer expires.
The BGP Support for TTL Security Check feature should be configured on each participating
router. It provides an effective and easy-to-deploy solution to protect EBGP peering sessions
BGP Overview
1-89
from CPU utilization-based attacks. When this feature is enabled, a host cannot attack a BGP
session if the host is not a member of the local or remote BGP network or if the host is not
directly connected to a network segment between the local and remote BGP networks. This
solution greatly reduces the effectiveness of DoS attacks against a BGP AS.
neighbor ttl-security
To secure a BGP peering session and to configure the maximum number of hops that separate
two EBGP peers, use the neighbor ttl-security command in address-family or router
configuration mode.
neighbor neighbor-address ttl-security hops hop-count
no neighbor neighbor-address ttl-security hops hop-count
Syntax Description
Parameter
Description
IP address of the neighbor.
Maximum number of hops that can separate the EBGP peer from
the local router.
The value for the hop-count argument is a number from 1 to 254.
1-90

This topic describes a situation in which route aggregation in BGP is not appropriate.
Customer prefers primary provider, using alternate only as

backup.
Primary provider advertises the aggregate.
Alternate provider advertises individual network.
BGP v3.21-26
In this example, the primary provider is doing aggregation of 192.1.0.0/16 before sending it to
the rest of the network. This situation means that the primary provider is also doing proxy
aggregation for the route 192.1.1.0/24 that is advertised by the multihomed customer. The rest
of the Internet will not see the route 192.1.1.0/24 via the primary provider.
The multihomed customer also advertises 192.1.1.0/24 to the alternate provider. In this case,
the provider does not do any aggregation of any routes starting with 192.1 (and should not do
so). This situation means that the alternate provider will propagate 192.1.1.0/24 to the rest of
the Internet.
BGP Overview
1-91
Multihomed Customer Problem (Cont.)
Customer prefers primary provider, using alternate only as

backup.
Primary provider advertises the aggregate.
Alternate provider advertises individual network.
BGP v3.21-27
The rest of the Internet now sees overlapping routes. It sees 192.1.1.0/24 as reachable via the
alternate provider and 192.1.0.0/16 as reachable via the primary provider. These two routes are
treated as different routes. They are not compared with each other in a route selection process
because they indicate different destinations. Because the router views them as different
destinations, both routes will be injected into the routing table.
If a packet arrives with a destination address in the 192.1.1.0/24 network, the rest of the
Internet will follow the longest matching prefix rule and forward the packet to the alternate
provider.
To avoid this issue, the primary provider must turn off aggregation. If the primary provider
does so, the rest of the Internet will see 192.1.1.0/24 both ways. And, because exactly the same
route (network and mask) is reachable in two ways, route selection processing starts.
Depending on the attribute values, the rest of the Internet could be advised to use the primary
provider instead of the alternate one.
However, turning off aggregation will also cause the primary provider to advertise all routes
within the aggregate, and all benefits of aggregation will be lost.
1-92
Summary
Summary
The BGP process in a Cisco router is started with the
router bgp command.
The neighbor remote-as router configuration command adds an
entry to the BGP neighbor table, the neighbor description router
configuration command associates a description with a
neighbor, and the neighbor shutdown router configuration
command disables a neighbor.
The BGP keepalive and holdtime timers can be changed for the
BGP process (using the timers bgp router configuration
command) or on a per-neighbor basis (using the neighbor timers
router configuration command).
MD5 authentication can be used to secure a connection
between two BGP neighbors. The neighbor password router
configuration command enables MD5 authentication on a TCP
connection between two BGP peers.
BGP v3.21-30
Summary (Cont.)
Local networks are announced in BGP by listing them with
the network command or by redistributing them with the
redistribute command. The network command can be used to
announce any IP prefix. If you use the classless version of the
network command, a matching route has to reside in the IP
routing table.
If there are a lot of networks to be advertised, and BGP is
used primarily to achieve scalability, it may be easier to let
the local IGP find the routes and then redistribute them into
BGP. To redistribute routes from one routing process into
another routing process, use the redistribute router
BGP4 supports CIDR, and any BGP router can advertise
individual networks or supernets (prefixes). To specify the
networks to be advertised by the BGP routing process, use
the network router configuration command.
BGP v3.21-31
BGP Overview
1-93
Summary (Cont.)
There are cases where routes that are already in the BGP table have to
be summarized. This process is called aggregation in BGP and is
configured with the aggregate-address command.
The BGP conditional route injection feature provides a means to
originate a prefix into a BGP routing table without the corresponding
match, allowing more specific routes to be generated based on
administrative policy or traffic engineering information to provide
more specific control over the forwarding of packets to these more
specific routes.
The BGP Support for TTL Security Check feature introduces a
lightweight security mechanism to protect EBGP peering sessions
from CPU utilization-based attacks; a host cannot attack a BGP
session if the host is not a member of the local or remote BGP network
or if the host is not directly connected to a network segment between
the local and remote BGP networks.
BGP route aggregation is not appropriate in multihomed topologies.
1-94
BGP v3.21-32
Lesson 6
Monitoring and
Troubleshooting BGP
Overview
Border Gateway Protocol (BGP) monitoring commands are important to ensuring that basic
BGP configurations are operating correctly. If basic BGP configurations are not functioning as
expected, BGP troubleshooting skills are critical to successful problem resolution.
This lesson introduces the Cisco IOS commands that are available for monitoring and
troubleshooting basic BGP configurations. The commands that are required to monitor the
status of BGP, neighbor connections, and the BGP table are discussed. The lesson also
discusses techniques for troubleshooting the most common BGP session startup issues.
Objectives
Upon completing this lesson, you will be able to perform the steps to correct basic BGP
configuration and session errors. This ability includes being able to meet these objectives:
Identify the Cisco IOS command that is required to monitor the overall status of the BGP
routing process
Identify the Cisco IOS command that is required to monitor BGP neighbors
Identify the Cisco IOS commands that are required to monitor the BGP table
Identify the Cisco IOS commands that are required to perform basic BGP debugging
List common BGP session startup problems
Troubleshoot basic BGP session startup problems when the neighbor is not reachable
Troubleshoot basic BGP session startup problems when the neighbor is not configured
Troubleshoot basic BGP session startup problems when an AS number mismatch exists

This topic describes the command that is used to monitor the overall status of the BGP routing
protocol process.

Displays BGP memory use, and displays BGP neighbors and the
state of communication with them
BGP v3.21-3
This command is very useful when you are troubleshooting BGP. The output in the figure
provides a short summary of the status of the BGP process in the router.
The first section of the output describes the BGP table and its content:
The BGP table version is the version number of the local BGP table. This number is
increased every time that the table is changed.
The main routing table version shows the last version of the BGP database that was
injected into the main routing table.
The subsequent lines of text indicate the amount of memory that has been allocated to hold
the table. These lines of text display how many networks are known and how many
different paths and attribute values are associated with them.
1-96
The second section of the output is a table in which the current neighbor statuses are shown.
There is one line of text for each neighbor that has been configured. The columns are as
follows:
IP address of the neighbor as configured in the local router
BGP version number that is used by the router when communicating with the neighbor
Autonomous system (AS) number of the remote neighbor
Number of messages and updates that have been received from the neighbor since the
session was established
Number of messages and updates that have been sent to the neighbor since the session was
established
Version number of the local BGP table that has been included in the most recent update to
the neighbor
Number of messages that are waiting to be processed in the incoming queue from this
neighbor
Number of messages that are waiting in the outgoing queue for transmission to the
neighbor
How long the neighbor has been in the current state and the name of the current state (the
state Established is not printed out, so no state name indicates Established)
You can use this information to verify that BGP sessions are up and established. If they are not,
you will have to further investigate the BGP configuration to locate the problem. You can also
verify the IP address and AS number of the configured BGP neighbor with the show ip bgp
summary command.
If the session state is Established, the number of messages that have been sent and received,
as displayed in the output of the show ip bgp summary command, can indicate BGP stability.
Use the command a few times, with a time interval between the printouts, and calculate how
many messages have been exchanged during that period.
A large number of messages in the incoming queue indicates a lack of CPU resources in the
local router. A large number of messages in the outgoing queue indicates a lack of bandwidth to
the remote router or a lack of CPU resources in the remote router.
show ip bgp summary

To display the status of all BGP connections, use the show ip bgp summary EXEC command.
show ip bgp summary
This command has no arguments or keywords.
BGP Overview
1-97

This topic describes the Cisco IOS command that is used to monitor BGP neighbors.

Displays detailed neighbor information
BGP v3.21-4
You can use this command for two different purposes. The general purpose, as shown in the
figure, is to get information about the TCP session and the BGP parameters of the session. All
BGP session parameters are displayed. In addition, TCP timers and counters are also displayed.
The other use is not shown in this example. If any of the optional qualifiers referring to routes
or paths are given, the BGP routing information that was sent or received on this session is
displayed. This feature is useful when you are troubleshooting path selection.

To display information about the TCP and BGP connections to neighbors, use the show ip bgp
neighbors EXEC command.
show ip bgp neighbors [address] [received-routes | routes | advertised-routes | {paths
regular-expression} | dampened-routes]
1-98
Syntax Description
Parameter
Description
(Optional) Address of the neighbor whose routes you have

learned from.
If you omit this argument, all neighbors are displayed.
(Optional) Displays all received routes (both accepted and

rejected) from the specified neighbor.
(Optional) Displays all routes that are received and accepted.

This is a subset of the output from the received-routes keyword.
(Optional) Displays all the routes that the router has advertised to
the neighbor.
(Optional) Regular expression that is used to match the paths

received.
(Optional) Displays the dampened routes to the neighbor at the

IP address specified.
BGP Overview
1-99

This topic describes the Cisco IOS commands that are used to monitor the BGP routing table.

Displays all routes in the BGP table in summary format
BGP v3.21-5
In most cases, when the show ip bgp command is given without optional qualifiers, the entire
BGP table is displayed. An abbreviated list of information about each route is displayed, one
line per prefix. The output is sorted in network number order. Therefore, if the BGP table
contains more than one route to the same network, the routes are displayed on successive lines.
The network number is printed on the first of these lines only. The following lines, which refer
to the same network, have the network number field left blank.
Some, but not all, of the BGP attributes that are associated with the route are displayed on the
line. Next-hop, multi-exit discriminator (MED) (displayed as Metric), local preference, and
weight each have their own columns. The AS-path attribute is displayed as the sequence of AS
numbers in the Path column. Immediately following the AS path, but not part of the AS-path
attribute, the origin attribute is displayed. The lowercase letter i means Interior Gateway
Protocol (IGP), e means exterior gateway protocol (EGP), and ? means incomplete or
unknown.
The BGP path selection process selects one of the available routes to each of the networks as
the best. This route are pointed out by the character > in the left column.
show ip bgp
To display entries in the BGP routing table, use the show ip bgp EXEC command.
show ip bgp [network] [network-mask] [longer-prefixes]
1-100
Syntax Description
Parameter
Description
(Optional) Network number, which is entered to display a

particular network in the BGP routing table
(Optional) Displays all BGP routes matching the address and

mask pair
(Optional) Displays the network and its more specific networks or

prefixes.
BGP Overview
1-101
Monitoring the BGP Table (Cont.)

Displays detailed information about all paths for a single prefix
BGP v3.21-6
If more information and the complete set of BGP attributes are required, the show ip bgp
command should be entered with the network number on the command line. This command
displays all relevant BGP information about that specific network.
In this example, the information about network 11.0.0.0 is displayed. There are two routes to
11.0.0.0. One is received from neighbor 1.2.0.1 and the other from 1.1.0.1.
The BGP route selection process has selected the route via 1.2.0.1 as the best. This is thus the
route that BGP will try to install in the routing table. Installation of routes in the routing table is
made based on the administrative distance (AD).
1-102
Debugging BGP
This topic describes the Cisco IOS commands that are used to perform debugging of basic BGP
configurations.
Debugging BGP
Displays all TCP transactions (start of session, session errors,

etc.)
Displays significant BGP events (neighbor state transitions,

update runs)
BGP v3.21-7
If a BGP session stays in the Active state, where it is actively sending connection attempts to
the neighbor, debug ip tcp transactions can provide valuable information about failed
connection attempts. All TCP transactions in the router are displayed on the console as they
happen. The network administrator can then determine whether the TCP session is being
established, and, if not, what the probable cause of the problem might be.
If the TCP session succeeds but is torn down within a short period of time, you might find the
reason if you use debug ip bgp events. All BGP events will be displayed on the console as
they happen if this debug command is enabled.
BGP Overview
1-103
Debugging BGP (Cont.)
Debugs BGP keepalive packets
Displays all incoming or outgoing BGP updates

Use with caution
BGP v3.21-8
In a stable state with no network topology changes, no BGP updates are sent between
neighboring routers. When a BGP session has been idle for some time, the BGP protocol will
exchange keepalive packets between BGP neighbors. The keepalive timer has a default value of
60 seconds.
Use the debug ip bgp keepalives command to get a printout on the console for every keepalive
packet that is sent or received. Successful keepalive exchanges indicate that the session is
working and is in a stable state.
If no keepalives have been sent or received, the session might still be working. The reason for
not seeing any keepalives would be that the session is never idle long enough.
Use the debug ip bgp updates command to get a printout on the console for every update
message that is sent or received. The successful exchange of updates indicates that the session
is working and is not in the Idle state.
In a large network, updates are sent and received in large volumes. Starting the debug ip bgp
updates command might cause extensive output on the console. In some cases, the CPU
resources that are used to generate those outputs are so great that few CPU resources remain to
actually forward traffic. In a case with very busy BGP sessions, it is actually possible to set the
router in a condition where all CPU resources are consumed with the debugging printouts.
1-104
Debugging BGP (Cont.)
Displays all incoming or outgoing BGP updates for routes

matching an IP access-list
Displays all BGP updates received from or sent to a BGP

neighbor (optionally matching an IP access-list)
BGP v3.21-9
To avoid debug printouts for every update that is sent or received, you can create and associate
an access-list with the debug command. When you use this command, the console displays
only the updates that refer to a network number that is permitted by the access-list. The
command is extremely useful in a live network with busy BGP sessions where the
troubleshooter is interested only in updates for specific networks.
Indicating a specific neighbor can even further restrict the debugging. The console displays
only the updates on the session with the indicated neighbor. Optionally, you can combine this
debug command with an access-list.
BGP Overview
1-105

This topic describes the most common session startup issues that you can experience when
configuring basic BGP.

Common BGP session startup symptoms:
BGP neighbors do not become active.
BGP neighbor is active, but the session is never established.
BGP neighbor oscillates between idle and active.
BGP v3.21-10
There are a number of common BGP session startup symptoms:

A BGP neighbor never becomes active.
A BGP neighbor is active, but the BGP session is not established.
The BGP neighbor state oscillates between Idle and Active.
1-106

This topic describes basic BGP troubleshooting for BGP session startup problems where the
neighbor is not reachable.

Symptom:
show ip bgp neighbors displays the neighbor state as Idle
for several minutes.
Diagnosis:
Neighbor is not directly connected.
Verification:
Verify with show ip route.
BGP v3.21-11
BGP sessions to a router in another AS should normally run across directly connected
interfaces (routers that share a common IP subnet). You must configure neighboring routers to
reach each other using the IP address belonging to this shared subnet so that no other routing
protocol is required to set up the BGP session.
If a router is configured with a BGP neighbor that is in another AS but not directly connected,
the session will stay in the Idle state. The router will not even attempt to set up the session.
The normal way to fix this problem is to change the neighbor reference so that it is referred by
an IP address that is directly connected. However, in some odd cases, the neighbor is
intentionally reachable using an interface that is not directly connected. In that rare case, the
local router must have routing information on how to reach that address. Also, you must
configure the BGP session with the ebgp-multihop option.
If the session goes into the Active state, the router will attempt to establish the session. If
session establishment is unsuccessful, you will have to troubleshoot the problem. The debug ip
tcp transactions command will display the connect attempts.
BGP Overview
1-107
BGP Neighbor Not Reachable (Cont.)

Symptom:
BGP neighbor is active; session is not established.
debug ip tcp transactions display shows that
the TCP SYN packet is not answered with a
SYN-ACK packet.
Diagnosis:
Neighbor is not reachable.
Verification:
Verify connectivity with ping.
Check for the presence of an access-list.
BGP v3.21-12
TCP session establishment starts with the router sending a TCP SYN packet. If the TCP SYN
packet is never answered, the remote router might be dead or not reachable. Try to use the ping
command and verify the existence of the remote router and the IP packet exchange between the
local and remote router.
1-108
Example: BGP Neighbor Not Reachable

In this example, the remote BGP router is not available.
BGP Neighbor Not Reachable (Cont.)
BGP v3.21-13
The sending router never receives the reply to the SYN packet and aborts the TCP session in
approximately 45 seconds (changing the state from synsent to closed).
BGP Overview
1-109

This topic describes basic BGP troubleshooting for BGP session startup problems where the
neighbor is not configured.

Symptom:
BGP neighbor is active; session is not established.
debug ip tcp transactions display shows that the
TCP SYN packet is answered with an RST packet.
Diagnosis:
This router is not configured as the BGP neighbor on the
neighboring router.
Verification:
Check IP addresses of BGP neighbors with show ip bgp
summary on the neighboring router.
BGP v3.21-14
If the TCP SYN packet is answered with a TCP RST packet, the remote router is alive and
reachable but is not willing to grant the connection attempt. The reason for this refusal may be
that BGP has not been fully configured on the remote router or that the source IP address that is
used by the local router in the connection attempt is not in the list of valid neighbors for the
remote router.
1-110
Example: BGP Neighbor Not Configured

In this example, the remote router is not configured for BGP or there was a mismatch in the
neighbor IP addresses.
BGP Neighbor Not Configured (Cont.)
BGP v3.21-15
The remote router responds with an RST packet as soon as it receives the initial SYN packet,
terminating the BGP session.
BGP Overview
1-111

This topic describes basic BGP troubleshooting for BGP session startup problems where the AS
numbers are not properly configured.

Symptom:
BGP neighbor oscillates between Active and Idle.
debug ip tcp transactions displays the TCP session being
established and torn down immediately.
Diagnosis:
There is an AS number mismatch between BGP neighbors.
Verification:
Verify the AS numbers configured for neighboring routers
using the show ip bgp summary on both routers.
BGP v3.21-16
If the TCP session is established using the specified three-way handshake of SYN, SYN-ACK,
and ACK, but the router drops the session after a short packet exchange, the BGP parameters
are mismatched. Make sure that the remote AS that is configured on the router matches the
local AS that is configured on the neighbor. If the AS numbers do not match, the router drops
the session after exchanging BGP Open messages.
1-112
Example: BGP AS Number Mismatch

This example illustrates a mismatch in an AS number.
BGP AS Number Mismatch (Cont.)
BGP v3.21-17
Whenever there is a mismatch in AS numbers (or any other BGP parameters that are necessary
for proper BGP operation), the BGP session is terminated with a BGP notification, and the TCP
session is terminated as well.
BGP Overview
1-113
Summary
Summary
The show ip bgp summary command displays the overall
status of BGP and shows configured neighbors and their
state.
You can use the show ip bgp neighbors command to get more
in-depth information about a specific BGP neighbor.
All entries in the BGP table can be displayed with the show ip
bgp command. You can also use show ip bgp to display an
extended printout about a specific route in the BGP table.
You can use the debug ip tcp transactions command to
troubleshoot BGP session establishment problems. The
command debug ip bgp events displays significant BGP
events, while debug ip bgp updates displays the routing
information being exchanged between BGP neighbors.
BGP v3.21-18
Summary (Cont.)
Three common BGP session startup symptoms are that BGP
neighbors never become active, that the BGP neighbor is
active but the BGP session is not established, and that the
BGP neighbor state oscillates between idle and active.
If a router is configured with a BGP neighbor that is in
another AS but not directly connected, the session stays in
the Idle state.
If a BGP neighbor is unreachable, no reply is sent for the TCP
SYN packet, causing the session to time out.
If the TCP session is established using the three-way
handshake (SYN, SYN-ACK, ACK), but the session is
dropped after a short packet exchange, BGP parameters are
mismatched.
1-114
BGP v3.21-19
Module Summary
This topic summarizes the key points discussed in this module.
Module Summary
BGP has reliable transport provided by TCP, a rich set of
metrics called BGP path attributes, and scalability features
such as batched updates that make it suitable for very large
networks.
Configured BGP neighbors establish a TCP session and
exchange the BGP Open message, which contains the
parameters that each BGP router proposes to use.
Some path attributes are well-known and should be
recognized by every BGP implementation. Some of the
well-known attributes, such as AS-path, next-hop, and
origin, are mandatory and have to be present in every BGP
update.
BGP v3.21-1
Module Summary (Cont.)

The route selection process takes into account various
BGP attributes that are attached to the route, as well as
local decisions.
When you are configuring BGP neighbors, you will
enable the BGP routing protocol process, establish
neighbors, and advertise local routes.
To ensure that basic BGP configurations are operating
correctly, there are a number of Cisco IOS commands to
monitor the status of BGP, neighbor connections, and
the BGP table, as well as to troubleshoot the most
common BGP session startup issues.
BGP v3.21-2
BGP Overview
1-115
This module presented an overview of BGP, a very robust and scalable routing protocol. The
first lesson covered the uses of BGP and its limitations. The second lesson moved to describing
the concept of BGP neighbors and the procedures for establishing neighbor sessions. Then, the
third lesson listed BGP path attributes and their functionality. The fourth lesson described
interdomain route processing. When you had the foundation of a general understanding of
BGP, the fifth lesson explained how to configure it. The module ended with a lesson that
identified the steps to monitor the operation of BGP and correct basic configuration errors.
References
For additional information, refer to these resources:
Cisco Systems, Inc. Border Gateway Protocol.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm.
Cisco Systems, Inc. Configuring BGP.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1c
dbgp.htm.
Cisco Systems, Inc. Using the Border Gateway Protocol for Interdomain Routing.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm.
1-116
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1)
Which three items are BGP enhancements to traditional distance vector routing
protocols? (Choose three.) (Source: Introducing BGP)
A)
B)
C)
D)
E)
F)
Q2)
Which protocol facilitates reliable update capabilities in BGP? (Source: Introducing

BGP)
A)
B)
C)
D)
Q3)
uses IGPs for intradomain routing

uses EGPs for interdomain routing
is a collection of networks under a common administrative authority
consists of a group of network domains
automatically summarizes addresses
regulated by the IETF
Which three scenarios are common scenarios where BGP is used? (Choose three.)
(Source: Introducing BGP)
A)
B)
C)
D)
E)
F)
Q5)
TCP
UDP
HSRP
ICMP
What are three characteristics of an AS? (Choose three.) (Source: Introducing BGP)
A)
B)
C)
D)
E)
F)
Q4)
reliable updates
use of triggered updates only
enhanced security
rich metrics
route summarization
snapshot updates
a customer with a connection to multiple service providers

service provider networks acting as transit systems and forwarding external
traffic through their network
a single-site customer intranet with complex administrative policies between
departments
as the core routing protocol in very large enterprise networks
as the routing protocol in an IS-IS backbone area
as the core routing protocol in an SNA network
What are three recommended BGP use guidelines for multihomed customer networks?
(Choose three.) (Source: Introducing BGP)
A)
B)
C)
D)
E)
F)
Most multihomed customers should use BGP with their service providers.
Most multihomed customers should forward routing information that is
received from one provider to the other provider.
The multihomed customer must have its own public AS number.
Multihomed customers should use a provider-independent, public address
space.
The multihomed customer may use and advertise RFC 1918 addresses.
Multihomed customers should use the AS number of their primary ISP.
BGP Overview
1-117
Q6)
What is a limitation of the BGP routing protocol? (Source: Introducing BGP)

A)
B)
C)
D)
Q7)
Which three statements are true of BGP mandatory well-known attributes?

(Choose three.) (Source: Understanding BGP Path Attributes)
A)
B)
C)
D)
E)
Q8)
next-hop
local preference
MED
AS-path
In which two ways can the BGP next-hop attribute be modified? (Choose two.)
(Source: Understanding BGP Path Attributes)
A)
B)
C)
D)
1-118
IGP
EGP
unknown
internal
external
MED
Which nontransitive optional BGP attribute is useful in assisting with the route
selection process when multiple links to another AS exist? (Source: Understanding
BGP Path Attributes)
A)
B)
C)
D)
Q11)
next-hop
weight
AS-path
origin
MED
local preference
Which three possible values are assigned to the BGP origin attribute? (Choose three.)
A)
B)
C)
D)
E)
F)
Q10)
They must be present in all BGP updates.

All BGP-compliant implementations must recognize them.
All BGP-compliant routers must adhere to policies specified in mandatory
attributes.
All well-known attributes are propagated to other neighbors.
They must be present in some BGP updates.
Which three attributes are BGP mandatory well-known attributes? (Choose three.)
A)
B)
C)
D)
E)
F)
Q9)
You cannot use BGP to implement hop-by-hop routing policy controls.

You cannot use BGP to influence the routing policy in a downstream AS.
BGP cannot control forwarding of packets based on their destination address.
BGP cannot scale to very large networks with more than 110,000 routes.
If the next-hop attribute is in the same IP subnet as the receiving router, the
attribute is unchanged; otherwise, it is set to the IP address of the sending
router.
The next-hop attribute is always set to the IP address of the sending router.
The next-hop attribute is modified only when BGP packets exit an AS.
The BGP next-hop attribute is modified only when BGP packets traverse pointto-point links.
Q12)
Which three statements regarding the BGP AS-path attribute are true? (Choose three.)
A)
B)
C)
D)
E)
F)
Q13)
What is indicated by a state of Idle in the output of the show ip bgp summary
command? (Source: Establishing BGP Sessions)
A)
B)
C)
D)
Q14)
The router is currently not attempting to establish a connection with a

neighbor.
The connection to the configured neighbor has timed out.
The connection to a BGP neighbor has been established, and no errors have
been received on the connection.
The connection to a BGP neighbor has been established, and no packets have
been sent.
What happens if two TCP connection attempts between configured BGP neighbors
succeed? (Source: Establishing BGP Sessions)
A)
B)
C)
D)
Q15)
The local AS number is prepended to the AS path each time that the route
crosses an AS boundary.
The AS that originally injected the route into BGP is always found at the
rightmost end of the AS path.
The AS-path attribute can be used to avoid routing loops.
BGP routes with an empty AS path were injected into BGP from outside the
local AS.
The local AS number is appended to the end of the AS path each time that the
route crosses an AS boundary.
The AS that originally injected the route into BGP is always found at the
leftmost end of the AS path.
Both connections will be terminated, and the neighbors will re-establish a

neighbor relationship.
One connection will be maintained as primary and the other as backup.
One of the two connections will be torn down.
The router with the lower router-ID will determine if the second connection is
torn down or used as a backup TCP connection.
Given the following BGP session states:

1.
2.
3.
4.
5.
OpenConfirm
Established
Idle
OpenSent
Active
What is their order of progression during the creation of a successful neighbor session?
(Source: Establishing BGP Sessions)
A)
B)
C)
D)
5, 1, 4, 2, 3
3, 4, 1, 5, 2
5, 4, 1, 3, 2
3, 5, 4, 1, 2
BGP Overview
1-119
Q16)
What does the field TblVer indicate in the output of the show ip bgp summary
command? (Source: Establishing BGP Sessions)
A)
B)
C)
D)
Q17)
What occurs when you use MD5 between two BGP neighbors? (Source: Establishing
BGP Sessions)
A)
B)
C)
D)
Q18)
B)
C)
D)
The router checks to see whether the information that is contained in the update
is better than its current information. If it is, it will update its BGP table.
The router accepts the route update.
The router silently discards (denies) the route.
The router returns an error to the router that sent the update.
How many alternate paths to a single destination will a BGP router maintain in the
BGP table? (Source: Processing BGP Routes)
A)
B)
C)
D)
1-120
Every packet is encrypted with MD5.

The IP header is encrypted using MD5.
An MD5 checksum is calculated and sent with each packet so that its source
can be verified.
A username and password are embedded in an IP datagram that is matched to a
username and password on the remote neighbor.
What does a router that is running BGP do with a BGP update that contains its own AS
path? (Source: Processing BGP Routes)
A)
Q19)
the current version of BGP in use by the router

the number of route prefixes that are contained in the BGP update of the router
BGP messages that have been received from that neighbor
the last version of the BGP database that was sent to that neighbor
The router will maintain only the best path to the destination.
The router will maintain two paths, the best path and a backup route.
The BGP table will hold up to four routes by default and a maximum of six
configurable routes.
The BGP table will store all valid, advertised routes to the destination in the
BGP table.
Q20)
When a router has more than one alternative route to reach the same IP subnet (network
and mask), the router has to select one of them as best in its default mode of operation
Match the following steps to the correct step in the process. (Source: Processing BGP
Routes)
A)
The router compares MED values, but only if it receives the updates from the
same neighboring AS. Routes with a lower MED are preferred.
B)
The router checks whether the next-hop attribute indicates an IP address that is
reachable according to the current routing table. If the next hop is not
reachable, the router does not consider the BGP route as a candidate to become
selected as the best. (Source: Processing BGP Routes)
C)
D)
The router prefers the route with the higher weight.

If the local preference attributes are different, the route with the highest value
is selected as best.
The lengths of the AS paths are compared (the content is not checked; only the
number of autonomous systems in each AS path is counted). The route with the
shortest length is selected.
If one of the routes is injected into the BGP table by the local router, the local
router prefers it to any routes that it receives from other BGP routers.
If the AS-path lengths are the same, the origin code is checked. BGP prefers
the path with the lowest origin type: IGP is lower than EGP, and EGP is lower
than Incomplete.
E)
F)
G)
Q21)
_____ 1.
Step 1
_____ 2.
Step 2
_____ 3.
Step 3
_____ 4.
Step 4
_____ 5.
Step 5
_____ 6.
Step 6
_____ 7.
Step 7
What are two ways in which local networks are advertised into the BGP routing
protocol process? (Choose two.) (Source: Processing BGP Routes)
A)
B)
C)
D)
Q22)
automatically, after a BGP neighbor session is established

manually, with the network command
through redistribution into the BGP process
by advertising them to the BGP table on the router after Cisco Discovery
Protocol discovers connected networks
What are two situations when is it appropriate to disable automatic summarization in

BGP? (Choose two.) (Source: Processing BGP Routes)
A)
B)
C)
D)
when BGP neighbors are not configured to advertise aggregate routes to

upstream providers
when the classless variant of the network command is used
when you are using a classless IGP in the AS
when the effects of automatic summarization of IGP-to-BGP redistribution are
not desired
BGP Overview
1-121
Q23)
What is the AD of BGP routes in the IP routing table that were learned from BGP
neighbors in a different AS? (Source: Processing BGP Routes)
A)
B)
C)
D)
Q24)
Which three BGP attributes are displayed for each route in the BGP table when you are
using the show ip bgp command? (Choose three.) (Source: Processing BGP Routes)
A)
B)
C)
D)
Q25)
remove the neighbor command from the BGP router process

remove the BGP router process from the configuration
terminate the neighbor connection with the neighbor shutdown command
disconnect the neighbor by initiating a router reload
Which two of the following statements about configuring BGP timers are accurate?
(Choose two.) (Source: Configuring Basic BGP)
A)
B)
C)
D)
1-122
neighbor IP address
subnet mask of the IP network
remote AS number
local AS number
description of the neighbor
What is the best method to temporarily disable a BGP neighbor session? (Source:
Configuring Basic BGP)
A)
B)
C)
D)
Q28)
1 to 256
1 to 32768
1 to 65535
1 to 131072
Which two parameters must you configure with the neighbor command to establish a
BGP session with an external neighbor? (Choose two.) (Source: Configuring Basic
BGP)
A)
B)
C)
D)
E)
Q27)
weight
communities
origin
AS-path
What is the valid AS number range for a BGP process on a Cisco router? (Source:
A)
B)
C)
D)
Q26)
1
20
90
120
Changing the BGP default holdtime and keepalive timers is usually not
recommended.
The neighbor timers command sets the timers for a specific BGP peer or peer
group.
The timers bgp command sets the timers for a specific BGP peer or peer
group.
Holdtime indicates the frequency (in seconds) with which the Cisco IOS
software sends messages to its peer.
Q29)
Which two of the following are characteristics of the string component of the neighbor
{ip-address | peer-group-name} password string command? (Choose two.) (Source:
A)
B)
C)
D)
Q30)
Which three steps must you complete to advertise a classless prefix into BGP?
(Choose three.) (Source: Configuring Basic BGP)
A)
B)
C)
D)
Q31)
B)
C)
D)
When an exact match is not found in the IP routing table a matching prefix is
automatically configured on the router.
In the network ip-prefix-address mask subnet-mask command, the prefix
does not have to match an entry in the IP routing table
To advertise classless networks into BGP (a subnet or a supernet), you can use
the network command with the mask keyword and the subnet mask specified.
If the keyword mask and the subnet mask are omitted, the network is assumed
to have its natural mask according to the network class.
What are two benefits of using route aggregation in BGP? (Choose two.) (Source:
A)
B)
C)
D)
Q34)
internal
external
unknown
incomplete
Which two of the following statements about the classless behavior of BGP are
correct? (Choose two.) (Source: Configuring Basic BGP)
A)
Q33)
configure the prefix with the network command

specify the mask keyword with the locally advertised route
configure the redistribute connected command under the BGP router process
use a static route pointing to null 0 that matches the prefix
Which origin code is carried with routes that are redistributed into BGP? (Source:
A)
B)
C)
D)
Q32)
can contain any alphanumeric characters, including spaces

case-sensitive password of up to 100 characters
first character can be a number
cannot specify a password in the format number-space-anything
It ensures that even if aggregate networks are down, the aggregate is

advertised, which eliminates black holes.
It reduces the amount of memory that is used in the router to store the BGP
table.
It reduces route flapping and its effects on router CPU resources.
BGP attribute granularity is maintained, which ensures optimal path selection.
Which two of the following are characteristics of the BGP Conditional Route Injection
feature? (Choose two.) (Source: Configuring Basic BGP)
A)
B)
C)
D)
allows you to originate a prefix into a BGP routing table without the
corresponding match
enabled with the bgp inject-map exist-map command
allows conditional injecting or replacing more specific prefixes with less
specific prefixes
allows origination of a prefix into a BGP routing table only with the
corresponding match
BGP Overview
1-123
Q35)
Which two of the following are characteristics of the BGP Support for TTL Security
Check feature? (Choose two.) (Source: Configuring Basic BGP)
A)
B)
C)
D)
Q36)
Which two of the following are functions of the show ip bgp summary command?
(Choose two.) (Source: Monitoring and Troubleshooting BGP)
A)
B)
C)
D)
Q37)
B)
C)
D)
The show ip bgp command shows an abbreviated list of information about

each route, displaying one line per prefix.
The show ip bgp command shows a full list of information about each route,
displaying one line per prefix.
All of the BGP attributes that are associated with the route are displayed on the
line.
If the BGP table contains more than one route to the same network, the routes
are displayed on successive lines of the command output.
Which debug command should you enable to troubleshoot BGP session startup issues
where the TCP connection never succeeds? (Source: Monitoring and Troubleshooting
BGP)
A)
B)
C)
D)
1-124
show ip bgp summary

show ip bgp
show ip bgp neighbors address
show ip bgp detail
Which two of the following statements about the show ip bgp command that is used to
monitor the BGP routing table are accurate? (Choose two.) (Source: Monitoring and
Troubleshooting BGP)
A)
Q39)
displays BGP memory use

displays BGP neighbors and status of communication with them
locates problems in BGP sessions that are up and established
displays the BGP routing table
Which command do you use to display detailed BGP neighbor information? (Source:
Monitoring and Troubleshooting BGP)
A)
B)
C)
D)
Q38)
should be configured on only one participating router

prevents BGP sessions from expiring even if keepalive packets are not received
before the session timer expires
protects the EBGP peering session by comparing the value in the TTL field of
received IP packets against a hop count that is configured locally for each
EBGP peering session.
supports both directly connected peering sessions and multihop EBGP peering
sessions
ip bgp updates
ip packets
ip bgp keepalives
ip tcp transactions
Q40)
What are the three most common session startup issues that you can experience when
configuring basic BGP? (Choose three.) (Source: Monitoring and Troubleshooting
BGP)
A)
B)
C)
D)
E)
F)
Q41)
What is the most common reason for a BGP session not leaving the Idle state? (Source:
Monitoring and Troubleshooting BGP)
A)
B)
C)
D)
Q42)
The TCP port for the connection is not configured.

The external neighbor is not directly connected.
The TCP SYN packet is answered with an RST packet.
The neighbors have been configured with the same AS number.
What will result from attempting to open a BGP connection with a neighbor that has
not been properly configured for BGP? (Source: Monitoring and Troubleshooting
BGP)
A)
B)
C)
D)
Q43)

BGP routing loops cause black holes.
A BGP neighbor is active, but the BGP session is not established.
The BGP neighbor state oscillates between Idle and Active.
The BGP session is active, but the neighbor cannot be reached.
BGP keepalives experience intermittent failures.
The BGP session will remain in the Idle state.

The neighbor session will be established, and the session startup parameters
will be negotiated over the TCP session.
The BGP session will be immediately terminated with a TCP RST packet.
The BGP session will become stuck in Active state.
When a BGP neighbor oscillates between Active and Idle, what is the likely diagnosis?
(Source: Monitoring and Troubleshooting BGP)
A)
B)
C)
D)
There are mismatched keepalive intervals.

There is an AS number mismatch between BGP neighbors.
One router is not configured as the BGP neighbor on the neighboring router.
The BGP neighbor is not reachable.
BGP Overview
1-125
1-126
Q1)
A, B, D
Q2)
Q3)
A, B, C
Q4)
A, B, D
Q5)
A, C, D
Q6)
Q7)
A, B, D
Q8)
A, C, D
Q9)
A, B, C
Q10)
Q11)
A, B
Q12)
A, B, C
Q13)
Q14)
Q15)
Q16)
Q17)
Q18)
Q19)
Q20)
A-7, B-1, C-2, D-3, E-5, F-4, G-6
Q21)
B, C
Q22)
B, D
Q23)
Q24)
A, C, D
Q25)
Q26)
A, C
Q27)
Q28)
A, B
Q29)
A, D
Q30)
A, B, D
Q31)
Q32)
C, D
Q33)
B, C
Q34)
A, B
Q35)
C, D
Q36)
A, B
Q37)
Q38)
B, D
Q39)
Q40)
A, C, D
Q41)
Q42)
Q43)
Module 2
BGP Transit Autonomous

Systems
Overview
This module is one of the focal points of the Border Gateway Protocol (BGP) curriculum: a
discussion of BGP issues in a transit autonomous system (AS). The module covers basic BGP
transit AS issues, ranging from synchronization between an Interior Gateway Protocol (IGP)
and BGP to Internal Border Gateway Protocol (IBGP) full-mesh and next-hop requirements.
Module Objectives
Upon completing this module, you will be able to use BGP policy controls to influence the
BGP route selection process in a network scenario in which you must support connections to
multiple ISPs. This ability includes being able to meet these objectives:
Describe the function of a transit AS and the need for IBGP
Describe the interaction in a transit AS between EBGP and IBGP in relation to relevant
attributes
Describe the function of an IGP in forwarding packets through an AS
Configure an AS to act as a transit backbone in a BGP network
Verify proper operation of a configured BGP transit network by performing the steps
necessary to correct basic IBGP configuration errors
2-2
Lesson 1
Working with a Transit AS

Overview
All transit autonomous systems are required to carry traffic originating from or destined for
locations outside of that autonomous system (AS). For the transit AS to meet this requirement,
a degree of interaction and coordination between Border Gateway Protocol (BGP) and the
Interior Gateway Protocol (IGP) that is used by that particular AS is necessary. Such a
configuration requires special care to ensure consistency of routing information throughout the
AS.
The topology of the Internet can be viewed as a series of connections between stub networks,
multihomed networks, and transit autonomous systems. A multihomed AS containing more
than one connection to the outside world and allowing traffic not originating in that AS to
travel through it is a transit AS. This lesson introduces the concept of the multihomed transit
AS and how BGP exchanges routing information inside the AS and between neighboring
autonomous systems. It also explains the requirement for Internal Border Gateway Protocol
(IBGP) within the multihomed transit AS.
Objectives
Upon completing this lesson, you will be able to describe the function of a transit AS and the
need for IBGP. This ability includes being able to meet these objectives:
List the functions of a transit AS
Describe external route propagation between autonomous systems in a BGP network
Describe internal route propagation within a BGP AS
Explain how transiting packets are forwarded inside a transit AS
Explain the need for deploying IBGP on all core routers
Transit AS Tasks
This topic describes the functions of a transit AS.
Transit AS Tasks
Propagate routes between remote autonomous systems

Route packets between remote networks
BGP v3.22-3
Routers in a transit AS have to perform two tasks:

Receive routing information updates about reachable networks from neighboring
autonomous systems, propagate the information through their own AS, and send it to other
neighboring autonomous systems.
Forward IP packets that they have received from a neighboring AS through their own AS to
a downstream neighboring AS. The routers in the transit AS perform this task using the
routing information that they have received as part of the first task.
2-4

This topic describes external route propagation between autonomous systems in a BGP
network.
BGP v3.22-4
Two autonomous systems usually exchange routing information about reachable networks
using BGP. There is currently no alternative routing protocol that has the scalability and
security characteristics of BGP.
In the figure, the BGP session between R-12 and RTR-A is called an External Border Gateway
Protocol (EBGP) session because R-12 and RTR-A are in different autonomous systems.
BGP routing information updates consist of the network address, subnet mask, and any number
of BGP attributes. No other routing protocol provides the same richness of route attributes as
BGP. Translating BGP route attribute information into any other protocol would likely cause a
loss of information. Therefore, the EBGP information that RTR-A receives is not translated; it
is just forwarded to other BGP-speaking routers (RTR-D in the figure) within the AS.
Likewise, RTR-D has BGP information and can propagate it to R-14 in AS 14 over the EBGP
session.
EBGP sessions are, in general, established between directly connected neighbors. BGPspeaking routers, therefore, need no additional routing information to establish a session.
2-5

This topic describes internal route propagation within a BGP AS.
BGP v3.22-5
In this example, the BGP session between RTR-A and RTR-D, which are both in the same AS,
is an IBGP session.
IBGP sessions are, in general, established between distant routers in the same AS. These
routers need additional routing information to establish the session, because there is no
requirement that IBGP neighbors be directly connected. This information typically comes from
the IGP, which is running within the AS independently of BGP.
2-6
This topic describes how transiting packets are forwarded inside a transit AS.
BGP v3.22-6
In this example, after AS 14 has received the routing information about reachable networks
inside AS 12, IP packets can start to flow (in the figure, from AS 14 toward AS 12). R-14, the
egress router in AS 14, forwards IP packets with destinations in AS 12 toward RTR-D,
according to information received through EBGP.
RTR-D now uses the IBGP information that it received from RTR-A and forwards the packets
in the direction of RTR-A, which in this case means via RTR-C.
When the IP packets reach RTR-C, the router checks its routing table for a matching entry, but
it fails to find one. The packet is dropped because the destination network is unreachable from
the perspective of RTR-C.
This situation is, of course, unacceptable. To prevent dropped packets resulting from
unreachable networks, RTR-C must also have routing information about the networks
reachable inside AS 12. The same information that RTR-D received from RTR-A over the
IBGP session must be propagated to RTR-C.
Note
RTR-B has the same network reachability requirements as RTR-C, because RTR-D could
forward the packets via RTR-B as well as via RTR-C.
2-7
Core Router IBGP Requirements in a Transit AS

This topic describes the need for deploying IBGP on all core routers.
Core Router IBGP Requirements in a

Transit AS
All core routers must have all external routes.
Core routers must receive BGP routes.
Redistribution of BGP routes into IGP is not scalable.
Default routing is not applicable in transit
AS core.
BGP v3.22-7
Within a transit AS, all routers that are in a theoretical transit path between external
destinations should have information about all external routes that are received from any
neighboring AS. If a single router on a transit path does not have this information, there is
always a possibility that an IP packet that is received from a neighboring AS will not be able to
be forwarded by that router through the transit AS. The router lacking routing information
about the final destination of the IP packet drops it into what effectively becomes a black hole.
The only feasible way for the router to distribute all external routing information is by using
IBGP. Redistribution of the EBGP routes into an IGP is not viable because no IGP can carry
the volume of information that BGP currently carries in the Internet.
Note
The risk of losing information during redistribution of EBGP routes into an IGP is not the
reason why BGP is used to update intermediate routers in the transit path instead of an IGP.
Redistribution into an IGP is not used because of the scalability issues that would arise from
doing so.
Default routing or a gateway of last resort cannot be used by routers within the transit path
when transit services are provided to other autonomous systems. If some routes were to be
filtered out and the default route used instead, full routing flexibility would be lost. The transit
AS would not be able to forward packets to all destinations at all times. In fact, routing loops
and black holes might be easily introduced.
2-8
Summary
Summary
Routers in a transit AS receive routing information updates
from neighboring autonomous systems, propagate the
information through their own AS, and send it to other
neighboring autonomous systems.
Two autonomous systems usually exchange routing
information over an EBGP session.
A BGP session between two routers in the same AS is called
an IBGP session.
For packets to be properly forwarded in a transit AS, all
routers must have external routing information.
The only feasible method of distributing external routing
information to all routers in the transit AS is through IBGP.
BGP v3.22-8
2-9
2-10
Lesson 2
Interacting with IBGP and

EBGP in a Transit AS
Overview
Configuring a Border Gateway Protocol (BGP) network in a transit services configuration
requires special care to ensure consistency of routing information throughout the autonomous
system (AS). Understanding the interaction between External Border Gateway Protocol
(EBGP) and Internal Border Gateway Protocol (IBGP) is crucial to successfully configuring
and troubleshooting the transit autonomous network.
This lesson introduces the requirements of IBGP and describes how routers residing in the
transit AS process the next-hop attribute. Changes to the normal processing of the next-hop
attribute are also described in this lesson. The lesson concludes with a comparison between
EBGP and IBGP.
Objectives
Upon completing this lesson, you will be able to describe the interaction in a transit AS
between EBGP and IBGP in relation to relevant attributes. This ability includes being able to
meet these objectives:
Describe AS-path processing in IBGP
Describe BGP multipath load sharing
Explain the need for BGP split horizon
Explain the need for a full-mesh topology between IBGP routers and the implications of
that need
List the benefits of establishing IBGP neighbor sessions using loopback interfaces
Describe next-hop processing in IBGP
Explain why all EBGP peers must be reachable by all BGP-speaking routers within the AS
Describe how to configure edge routers to announce themselves as the next hop in IBGP
updates
Describe the differences between EBGP and IBGP sessions

This topic describes AS-path processing in IBGP.
BGP v3.22-3
All BGP routing updates carry the mandatory well-known attribute AS-path, which lists the
autonomous systems that the routing update has already crossed.
When a router originates a BGP prefix (network X in this example), the AS path is empty.
Whenever a BGP prefix is announced over an EBGP session, the AS number of the router that
is sending the information is prepended to the AS path. In the example, R-12 inserts 12 in the
AS path before forwarding the routing update to RTR-A.
The AS path is not changed when the BGP prefix is propagated across IBGP sessions because
the routing update has not crossed an AS boundary. In the figure, RTR-A forwards the
information over an IBGP session to RTR-D with the AS path unchanged. The AS-path
information about network X will be the same in all routers within AS 42, because all the
routers are updated using IBGP sessions from RTR-A.
When RTR-D forwards the information about network X to R-14, RTR-D prepends its own AS
number (42) to the AS path. Thus, R-14 receives the routing information about network X with
an AS-path attribute of 42 12.
2-12

This topic describes multipath load sharing in BGP.
BGP v3.22-4
When a BGP-speaking router with no local policy configured receives Network Layer
Reachability Information (NLRI) from multiple IBGP sources for the same destination, the
router chooses one IBGP path as the best path. The best path is then installed in the IP routing
table of the router. For example, the figure illustrates that with three paths to AS 200, router 2
determines that one of the paths to AS 200 is the best path and uses only this path to reach AS
200.
The IBGP multipath load-sharing feature enables the BGP-speaking router to select multiple
IBGP paths as the best paths to a destination. The best paths, or multipaths, are then installed in
the IP routing table of the router.
2-13
Multipath Load Sharing in BGP (Cont.)
BGP v3.22-5
For example, on router 2 in the figure, the paths to routers 3, 4, and 5 are configured as
multipaths and can be used to reach AS 200, equally sharing the load to AS 200.
For multiple paths to the same destination to be considered as multipaths, the following criteria
must be met:
All attributes must be the same. The attributes include weight, local preference, AS path
(entire attribute and not just length), origin code, multi-exit discriminator (MED), and IGP
distance.
The next hop router for each multipath must be different.
Even if the criteria are met and multiple paths are considered multipaths, the BGP-speaking
router still designates one of the multipaths as the best path and advertises this best path to its
neighbors.
Configuring multiple IBGP best paths enables a router to evenly share the traffic destined for a
particular site.
maximum-paths ibgp
To control the maximum number of parallel internal BGP routes that can be installed in a
routing table, use the maximum-paths ibgp command in router configuration mode.
maximum-paths ibgp maximum-number
To disable this feature, use the no form of this command.
no maximum-paths ibgp
2-14
Syntax Description
Parameter
Description
A number from 1 to 6.
The maximum number of parallel routes that an IP routing
protocol installs in a routing table.
2-15
BGP Split Horizon

This topic explains the need for BGP split horizon as a mechanism to prevent routing loops.
BGP Split Horizon
Result: Full mesh of IBGP sessions is required for proper

IBGP update propagation.
BGP v3.22-6
All routers within an AS must make routing decisions in a consistent way. They must have
access to the same routing information with the same attributes in order to come to the same
conclusion about which exit point of the AS to use. In other words, the BGP attributes should
not be changed within the AS.
The AS-path attribute is not changed over an IBGP session, because the BGP update has not
crossed the AS boundary. However, the AS-path attribute is the primary means of detecting
routing information loopsa BGP router that encounters its own AS in the AS path of an
incoming BGP update silently ignores the information. Because the AS path is modified by
BGP-speaking routers only on EBGP sessions, this loop-preventing mechanism is useful
between autonomous systems only, not within them.
Routing information loops within the AS are prevented by IBGP split horizonrouting
information that is received through an IBGP session is never forwarded to another IBGP
neighbor, only toward EBGP neighbors. Because of BGP split horizon, no router can relay
IBGP information within the ASall routers must be directly updated from the border router
that received the EBGP update.
2-16
IBGP Full Mesh

This topic describes the need for a full-mesh topology between IBGP routers and the
implications of this need.
IBGP Full Mesh
Full mesh of IBGP sessions has to be established between all BGP-speaking

routers in the AS for proper IBGP route propagation.
The IBGP full mesh is a logical mesh of TCP sessions only; physical full mesh
is not required.
BGP v3.22-7
Because every router on the transit path within the AS must have routing information about all
external networks that are received by any of the border routers, RTR-B and RTR-C must lave
IBGP sessions to all border routers. This level of communication is not enough, though,
because any of the internal routers could also create new BGP routing information (for
example, originate a customer network). These updates must also reach all the routers within
the AS. The conclusion is that all BGP routers within an AS must have IBGP sessions with
every other BGP router in the AS, resulting in a full mesh of BGP sessions between BGPspeaking routers in an AS.
In the network shown in the figure, RTR-A must have IBGP sessions with RTR-B, RTR-C, and
RTR-D to propagate routes that are received from AS 12 to all routers within AS 42. Similarly,
RTR-D must have IBGP sessions with RTR-A, RTR-B, and RTR-C to be able to propagate
routes that are received from AS 14 to all routers within AS 42.
Note
The IBGP session between RTR-B and RTR-C is not strictly necessary for proper forwarding
of IP packets between external destinations. It does become mandatory if RTR-B or RTR-C
starts to originate BGP networks. To prevent potential future connectivity issues, it is a good
practice to establish a full mesh of IBGP sessions regardless of whether they are needed at
the time of network deployment or not.
The IGP that runs within AS 42 provides enough information to any BGP router within AS 42
to send IP packets to any other router in the AS. Having enough router reachability information
makes it possible to establish IBGP sessions between routers even though they are not
physically connected. The IBGP full mesh is a logical full mesh of TCP sessions and will run
on an arbitrary physical topology.
2-17
Example: IBGP Full Mesh

The figure illustrates IBGP split-horizon and IBGP full-mesh principles in a sample network.
IBGP Full Mesh Example
BGP v3.22-8
R-12 is sending an update to RTR-A over an EBGP session. Updates that are received on an
EBGP session should be forwarded on all other IBGP sessions, so RTR-A updates RTR-B,
RTR-C, and RTR-D. All routers within AS 42 are updated directly by RTR-A.
RTR-B and RTR-C are prevented from forwarding the update that they received from RTR-A
because of BGP split horizon.
RTR-D, which received the information on an IBGP session, is prevented from updating
RTR-B and RTR-C because of the same split-horizon rule. But RTR-D will update R-14 over
an EBGP session.
2-18
IBGP Neighbors
This topic lists the benefits of establishing IBGP neighbor sessions using loopback interfaces.
IBGP Neighbors
Because of IBGP full-mesh requirements, IBGP neighbors are

usually not directly connected.
Which interfaces should be chosen as the source and
destination addresses of IBGP TCP sessions?
BGP v3.22-9
In the figure, the transit AS 42 has a redundant physical topology. The IGP provides
reachability information for all routers and networks within AS 42, allowing all routers in the
AS to establish IBGP sessions to all other routers, even if the routers are not directly connected.
If the IBGP session between RTR-A and RTR-D was established using IP addresses that
belong to the physical WAN interfaces, the IBGP session would go down if either of the WAN
interfaces went down. As a result, the router would tear down the TCP session that is used for
BGP between the routers because the IP address of an interface that is in the down state is
invalid. Subsequently, all IP packets that are received with a destination address pointing to that
interface will also be dropped.
Network designers must be careful during the network design and implementation phase that
those IBGP sessions remain established for as long as the two BGP routers have any usable
path between them.
2-19
IBGP Neighbors (Cont.)

Always run IBGP sessions between loopback
interfaces.
IBGP sessions can always be established, even if some
physical interfaces are down.
IBGP sessions are stablephysical interface failure will not
tear down IBGP sessions.
There is no BGP recovery after a failure inside the transit AS.
The configured IGP will re-establish the path between
loopback interfaces.
IBGP sessions are not affected.
BGP v3.22-10
The best choice when you are configuring IBGP sessions is to establish each session between
loopback interfaces on each BGP router.
To establish BGP connectivity between the loopback interfaces, the IP addresses of these
interfaces have to be reachable by both routers. It is important that the IGP carry information
about the subnets that are assigned to each loopback interface so that the interfaces are
reachable by all BGP routers in the AS.
The IBGP sessions that are established between loopback interfaces have increased stability.
These sessions will not go down if a single physical interface goes down. As long as the IGP
can find any path between the two routers, the IBGP session will remain up. BGP will not
notice that the IGP has changed the traffic path between the two routers.
Note
2-20
Because BGP sessions run over TCP, they can survive even a short loss of connectivity
between BGP routers with no impact to the BGP routing protocol. The only requirement
placed on the IGP is that the network must converge before the BGP keepalive timer
expires.

This topic describes how the next-hop attribute is processed in IBGP.
BGP v3.22-11
Every BGP update carries the mandatory well-known attribute next-hop, which specifies the IP
address that should be used by the router as the forwarding next hop for packets sent toward the
announced destination address. In most cases, the next hop is set to the IP address that the
sending router is using as its source IP address for EBGP sessions. The receiving BGP router
will use the information and route IP packets toward the announced destination via the
indicated next hop, which is normally directly connected.
The next-hop attribute is not changed on IBGP updates, meaning that when the border router
forwards the BGP update on IBGP sessions, the next-hop address is still set to the IP address of
the far end of the EBGP session. Therefore, the receiver of IBGP updates will see the next-hop
information indicating a destination that is not directly connected. To resolve this problem, the
router will check its routing table and see if and how it can reach the next-hop address. The
router can then route IP packets with destination addresses matching the network in the BGP
update in the same direction as it would have routed an IP packet with a destination address
equal to the IP address stated in the next-hop attribute. This process is known as recursive
routing.
In the figure, R-12 sends a BGP update about network X. Because it is sending this update over
an EBGP session to RTR-A, the next-hop attribute is set to the IP address that is used at the
R-12 side of the EBGP session, 1.0.0.1.
RTR-A can use this information and route packets to network X by forwarding them to R-12.
RTR-A also forwards the BGP update over all its IBGP sessions. It does not change the nexthop attribute, so RTR-B, RTR-C, and RTR-D get information that they can reach network X by
forwarding packets to 1.0.0.1. But that IP address is not directly connected, so the routers must
2-21
look in their routing tables to see if and how they can reach 1.0.0.1. If the recursive route
lookup is successful, each router can then route packets to network X in the same direction as it
would route packets to 1.0.0.1.
RTR-D also forwards the BGP update about network X to R-14. The connection between these
routers is an EBGP session, meaning that RTR-D sets the next-hop attribute to its own IP
address, 3.0.0.2, which is used by RTR-D on the EBGP session toward R-14.
2-22
Transit Network Using External Next Hops

This topic describes why all EBGP peers must be reachable by all BGP-speaking routers within
the transit AS.
Transit Network Using

External Next Hops
All EBGP peers must be reachable by all
BGP-speaking routers within the AS.
EBGP next hops shall be announced using
the IGP.
Redistribute connected interfaces into the IGP at the edge
routers.
or
Include links to EBGP neighbors into the IGP and
configure them as passive interfaces.
BGP v3.22-12
All BGP-speaking routers within the AS get information about external networks with the nexthop attribute, which is set to the far end of the EBGP sessions reaching the border routers of the
AS.
Routers use a recursive routing mechanism when they determine how to forward IP packets
toward external destinations. When BGP routes are used in the routing table, the router checks
how it would have reached the next-hop address, and it installs the BGP route with the same
forwarding indication as for the route that is used to reach the next-hop IP address.
To get the recursive routing to work, the router must resolve all possible next-hop references
that use information in the routing table, which is already there. The IGP that is used within the
AS must carry this information.
One way of making the IGP carry the information that is necessary to resolve the BGP nexthop addresses is to make sure that all the border routers, which contain the EBGP sessions,
redistribute connected subnets into the IGP using the redistribute connected routing protocol
configuration command. Because EBGP sessions are established between routers using a
directly connected interface, the far end of the EBGP sessions is an IP address within the
directly connected subnet. By redistributing the connected interfaces into the IGP, the border
routers allow next-hop references to be resolvable by all routers within the AS.
External subnets that are redistributed into the IGP might appear as external IGP routes,
depending on what IGP is configured within the AS. There are several scalability issues that are
associated with external routes in some routing protocols. For example, Open Shortest Path
First (OSPF) carries each external subnet in a separate link-state advertisement (LSA) object. If
2-23
route redistribution is not desirable for any reason, an alternative method is to include the
subnet on which the EBGP session is running in the IGP configuration using the network
command. To prevent the border router from exchanging IGP routing with the border router of
the other AS, you must configure the interface as a passive interface. Failure to do so could
cause the two autonomous systems to exchange routes using the IGP. In that case, all benefits
of having separate autonomous systems would be lost.
2-24
Transit Network Using Edge Routers as Next

Hops
This topic describes how to configure edge routers to announce themselves as the next hop in
IBGP updates.
Transit Network Using Edge

Routers as Next Hops
Alternate design: Next-hop processing is modified at the edge
routers.
Edge routers announce themselves as the next hop in IBGP
updates.
No redistribution of external subnets is necessary.
This design might result in suboptimal routing if multiple paths
to a neighboring AS exist.
Use default next-hop processing if at all possible.
BGP v3.22-13
The next-hop attribute is usually not modified by an IBGP peer when the BGP update is
propagated across IBGP sessions. However, you could configure the BGP router to have a
different behavior and set its IP address as the next-hop address even when the BGP updates
are sent across IBGP sessions (emulating behavior on EBGP sessions). If you do configure an
IBGP router to emulate the behavior of EBGP sessions on the IBGP sessions of the border
routers, the BGP updates that are received on the EBGP sessions will be forwarded on the
IBGP sessions and the next-hop attribute will be set to the IP address that is used on the local
side of the IBGP session. The original next hop, set by the far end of the EBGP session, will be
lost.
The receiver of the IBGP information will do recursive routing in the normal way. But the nexthop address that is used will be the IP address of the far end of the IBGP session, because the
border router has changed it. The IP address of the far-end IBGP peer is always known in the
routing table; otherwise, the IBGP session would not have been established. There is no need
for the receiver of the IBGP information to have knowledge of how to reach the far end of the
EBGP session, because that IP address is no longer set as the next hop.
2-25

Routers as Next Hops (Cont.)

Changes next-hop processing at edge routers
Bypasses the BGP next-hop processing and announces the
local IP address as the BGP next hop in outgoing updates sent
to the specified neighbor
Has to be set on all IBGP neighbors to fully bypass IBGP nexthop processing
BGP v3.22-14
neighbor next-hop-self
To configure the router as the next hop for a BGP-speaking neighbor or peer group, use the
neighbor next-hop-self router configuration command.
neighbor {ip-address | peer-group-name} next-hop-self
To disable this feature, use the no form of this command.
no neighbor {ip-address | peer-group-name} next-hop-self
Syntax Description
2-26
Parameter
Description
IP address of the BGP-speaking neighbor
Example: Transit Network Using Edge Routers as Next Hops

In the figure, the next-hop-self configuration has been used on all IBGP sessions.

Routers as Next Hops Example
BGP v3.22-15
The next-hop attribute is normally not changed on IBGP updates. When the border router
forwards the incoming EBGP update over an outgoing IBGP session, the border router changes
the next-hop address to the IP address that is used as the source address of the IBGP session.
The receiver of IBGP updates will see next-hop information that indicates a destination, which
might not be directly connected. To resolve this problem, it will check its routing table and see
if and how the next-hop address can be reached. Then it will route IP packets with destination
addresses that match the network in the BGP update in the same direction as it would have
routed an IP packet with the destination address equal to the IP address in the next-hop
attribute. In this case, it is obvious that the next-hop address can be reached, because the IBGP
session would not have been established otherwise.
In the figure, R-12 sends a BGP update about network X. Because it is sending a BGP update
over an EBGP session to RTR-A, the next-hop attribute is set to the IP address that is used at
the R-12 side of the EBGP session, 1.0.0.1. RTR-A can use this information and route packets
to network X by forwarding them to R-12.
RTR-A also forwards the BGP update on all its IBGP sessions. It changes the next-hop
attribute to the IP address of its own loopback interface, so RTR-B, RTR-C, and RTR-D will
get information that they can reach network X by forwarding packets to 2.0.0.7. But that
address is not directly connected. The routers will inspect the routing table to see if and how
they can reach 2.0.0.7. They can then route packets to network X in the same direction that they
would use to route packets to 2.0.0.7.
RTR-D also forwards the BGP update about network X to R-14. This is an EBGP session,
which means that RTR-D will set the next-hop attribute to its own IP address that is used on
that EBGP session, 3.0.0.2.
2-27
Differences Between EBGP and IBGP Sessions

This topic describes the differences between EBGP and IBGP sessions.
Differences Between EBGP and

IBGP Sessions
No BGP attributes are changed in IBGP updates.
Because of BGP split horizon, routes learned from an IBGP
peer are not advertised to other IBGP peers.
Local preference is propagated only over IBGP sessions.
EBGP peers are directly connected; IBGP peers are usually
distant.
Route selection rules slightly prefer EBGP routes.
BGP v3.22-16
Both EBGP and IBGP sessions forward BGP updates; however, they do it in slightly different
ways:
The router does not change BGP attributes when an update is sent across an IBGP session,
unless next-hop-self is configured. When a BGP-speaking router sends an update across an
EBGP session, the next-hop attribute is always set and the AS number of the router is
prepended to the AS-path attribute.
IBGP uses split horizon to prevent routing information loops. EBGP does not use split
horizon and instead uses the AS path to detect loops. In both cases, a router forwards only
the best route and never sends a route back on the session from which it was received. But
IBGP split-horizon rules also prohibit a router from forwarding any information that is
received on an IBGP session to another IBGP session.
IBGP border routers remove the local preference attribute from a BGP route before the
BGP update is sent over an EBGP session. This difference means that the local preference
attribute is distributed on IBGP sessions only.
Two routers with an EBGP session between them normally establish the session using the
IP addresses from a common, shared subnet. Using the shared subnet to establish the
session guarantees that the two routers can exchange IP packets without any IGP running
between them. Also, recursive routing will always succeed because the next-hop address is
reachable using a directly connected route.
IBGP sessions are normally established between all routers in the AS in a full mesh. But all
routers in an AS might not have physical connections to every other router within the AS.
Because IBGP sessions are established between routers using IP addresses of different
subnets, an IGP must be running within the AS in order to establish IBGP sessions.
BGP route selection rules slightly favor EBGP routes over equivalent IBGP routes.
2-28
Example: Differences Between EBGP and IBGP Sessions

This example illustrates the preference of the EBGP route.
Differences Between EBGP and

IBGP Sessions Example
Whenever identical routes are received from IBGP and EBGP peers,
the route from the EBGP peer is preferred.
BGP v3.22-17
One of the default goals of transit packet forwarding is to propagate the transit packet toward
the downstream AS as soon as possible. A border router that receives otherwise equivalent
routes to the same destination over both an EBGP session and an IBGP session will prefer the
information that is received through the EBGP session.
Note
Equivalent routes are routes that have equal BGP path attributes used in the BGP route
selection rules (weight, local preference, AS-path length, origin, MED).
In the figure, the upper router in AS 42 receives BGP updates about network 10.0.0.0/8 over
two different paths. One update is received over the EBGP session to AS 12. The other update
is received over the IBGP session to the lower router in AS 42. All essential attributes are the
same, so route selection cannot be made easily.
The upper router in AS 42 realizes that IP packets with destination addresses within network
10.0.0.0/8 should sooner rather than later leave AS 42. It is better to make them leave the AS
right away. So the update that was received on the EBGP session is preferred over the update
that was received on the IBGP session.
2-29
Summary
Summary
All BGP routing updates carry the mandatory well-known attribute
AS-path, which lists the autonomous systems that the routing
update has already crossed. The AS-path attribute is not changed
when the BGP prefix is propagated across IBGP sessions.
The IBGP multipath load sharing feature enables the BGP speaking
router to select multiple IBGP paths as the best paths to a
destination. The best paths, or multipaths, are then installed in the
IP routing table of the router.
Routing information loops within the AS are prevented by IBGP split
horizonrouting information that is received through an IBGP
session is never forwarded to another IBGP neighbor, only toward
EBGP neighbors.
All BGP routers within an AS must have IBGP sessions with every
other BGP router in the AS, resulting in a full mesh of BGP
sessions.
BGP v3.22-18
Summary (Cont.)
For recursive routing to work, a router must resolve all
possible next-hop references that use information in the
routing table. The IGP that is used in the AS must carry this
information.
For stability, the best choice when you are configuring IBGP
sessions is to establish the session between loopback
interfaces of BGP routers.
The next-hop attribute is typically set to the IP address that
the sending router is using as its source IP address for an
EBGP session. Recursive routing is done to resolve the next
hop inside an AS because the next-hop attribute is not
changed on IBGP updates.
2-30
BGP v3.22-19
Summary (Cont.)
You can configure an edge router to set its IP address as the
next-hop address even when the BGP updates are sent
across IBGP sessions. As a result, there is no need for the
receiver of the IBGP information to know how to reach the far
end of the EBGP session, because that IP address is no
longer set as the next hop.
Both EBGP and IBGP sessions forward BGP updates but in
slightly different ways. BGP attributes are not changed when
an update is sent across an IBGP session unless next-hop-self
is configured.
BGP v3.22-20
2-31
2-32
Lesson 3
Forwarding Packets in a
Transit AS
Overview
A transit autonomous system (AS) requires interaction between External Border Gateway
Protocol (EBGP) and Internal Border Gateway Protocol (IBGP) and between IBGP and an
Interior Gateway Protocol (IGP) in the transit AS. This lesson describes packet forwarding
through a transit AS and discusses the requirements for successful packet forwarding, such as
recursive route lookup and an IGP in the transit AS. This lesson concludes with a discussion of
the interaction between IBGP and an IGP running within the transit AS.
Objectives
Upon completing this lesson, you will be able to describe the function of an IGP in forwarding
packets through an AS. This ability includes being able to meet these objectives:
Describe packet forwarding in a transit AS
Explain how recursive lookup functions in Cisco IOS software
Explain the need for an IGP in a transit backbone that is running BGP on all routers
Describe interactions between BGP and IGP in a transit AS
Explain the potential problems that might arise from BGP and IGP interaction

This topic describes packet forwarding in a transit AS.
All core routers need external routers for proper packet

forwarding.
Redistributing can overload IGP resources.
IBGP is preferred for scalability.
BGP v3.22-3
When Border Gateway Protocol (BGP) updates have propagated through the transit AS to all
neighboring autonomous systems, the IP traffic can start to flow.
In the figure, Router R-14 forwards to RTR-D IP packets with the destination address matching
a network in AS 12. RTR-D checks its routing table and finds that there is a BGP route for that
destination. The BGP route has a next-hop reference, which points to the far end of the EBGP
session between R-12 and RTR-A. So RTR-D once again checks the routing table and finds
that it should forward the packet to RTR-C in this case.
Thus, RTR-C receives the IP packet with a destination address indicating a host within AS 12.
To be able to forward this packet, RTR-C must have a matching route in its routing table. A
default route or gateway of last resort is not appropriate because in the next instant RTR-C
could receive another packet, coming from the other direction and destined for AS 14.
The conclusion is that both RTR-C and RTR-B, to handle all possible cases, must have routing
information to all the external networks that RTR-A and RTR-D have. The only scalable way
of providing routers with this information is to update RTR-C and RTR-B with IBGP from both
RTR-A and RTR-D.
In theory, the external information that is received by RTR-A and RTR-D could be
redistributed by these ingress routers into the IGP in use within the transit AS. However, no
IGP can handle the volume of information that BGP can. So there would always be a risk that
the IGP would break because of information overload, causing a total network meltdown in the
AS. The volume of routing information that is carried by BGP in the contemporary Internet
long ago passed the limits of what it is possible to carry in any IGP.
2-34
Packet Forwarding in a Transit AS (Cont.)

Routes learned via BGP do not have an outgoing interface associated
with them in the routing table.
Recursive lookup is performed to forward IP packets toward external
destinations.
BGP v3.22-4
A BGP route is installed in the IP routing table of a router only if the IP address in the next-hop
attribute is reachable according to the information already in the routing table. The installed
BGP route contains a reference to that next-hop address. So, the network will be reachable via
an IP address, which may or may not be directly connected. Because there is no clear reference
to a physical interface, the BGP route is installed in the IP routing table without any
information about outgoing interface.
The router must evaluate the recursive reference to the BGP next hop sooner or later in order to
allow packet forwarding toward external destinations. The point in time when the recursive
reference is resolved depends on the IP switching mechanism that is used by the router. At the
latest, the router performs the recursive route lookup when an IP packet with a destination
address that matches the BGP route should be forwarded. The router determines which
outgoing interface should be used and which Layer 2 address to assign (if applicable). The
router creates a cache entry so that successive IP packets to the same destination can be routed
using the same outgoing interface and Layer 2 address.
2-35

This topic describes how recursive lookup functions in Cisco IOS software.
BGP v3.22-5
The figure presents the steps in the recursive lookup process in Cisco IOS software. The router
has received a BGP update about network 10.0.0.0/8. It was associated with an AS-path
attribute set to 42 13, a next-hop attribute set to the IP address 1.2.3.4, and a community value
37:12. Some other attributes were also carried with the update.
Because the next-hop address 1.2.3.4 is reachable according to the routing table, the BGP route
is also installed in the routing table. Network number, subnet mask, and next-hop attributes are
inherited from the BGP table. No outgoing interface is assigned.
When an IP packet with a destination in network 10.0.0.0 is received, the router searches the
routing table and finds the installed BGP route. The router takes the indicated next-hop address
1.2.3.4 and searches the routing table again. It now finds a match with the Open Shortest Path
First (OSPF) route to subnet 1.2.3.0/24. The 1.2.3.0/24 route has an outgoing interface set to
interface Ethernet 0 and a next hop set to 1.5.4.1, meaning that packets that are destined for
network 10.0.0.0 should be forwarded via 1.5.4.1, which is directly reachable over Ethernet 0.
The Address Resolution Protocol (ARP) table is used to find the MAC address for IP address
1.5.4.1. The MAC address is used to forward the IP packet to network 10.0.0.0 out the Ethernet
0 interface. The MAC header is stored in the cache for successive packets to network 10.0.0.0.
Note
2-36
The example illustrates the recursive lookup performed when the router uses cache-based
IP switching mechanisms (for example, fast switching or optimum switching).
Recursive Lookup in Cisco IOS

Software (Cont.)
Traditional Cisco IOS software switching mechanisms
perform recursive lookup when forwarding the first packet.
Fast switching, optimum switching.
CEF precomputes the routing table.
All recursive lookups are performed while the routing
table is built.
BGP v3.22-6
Traditional Cisco IOS switching mechanisms used the traffic-driven, cache-based switching
approach. Both fast switching and optimum switching populate the IP switching cache on
demand, meaning that before any IP packets are forwarded, the cache is empty. After the first
packet to a specific destination arrives, all routing table lookups are done, including recursive
lookup in the case of a BGP route. The result of the lookup is cached for later use when
successive packets for the same destination arrive. The process is repeated for every specific
destination.
Cisco Express Forwarding (CEF) prebuilds a complete IP forwarding table, called the
Forwarding Information Base (FIB), that is based on the IP routing table. After the router
installs a routing entry into its routing table, incoming routing information updates trigger the
recursive lookup, and the outgoing interface and the actual physical next hop of the route are
determined. MAC address resolution and MAC header generation are still traffic-driven and
stored in the cache.
2-37

This topic describes the need for an IGP in a transit backbone that is running BGP on all
routers.
With IBGP running on all core routers, is an IGP still needed in the
core?
An IGP is needed to resolve BGP next hops and perform

fast convergence after a failure in the core network.
BGP v3.22-7
Some network designers base their network design on the wrong assumption that an internal
routing protocol is not needed in a transit AS where all routers run BGP. However, the internal
routing protocol is still needed inside an AS for two reasons:
To provide routing information that is needed to establish the IBGP sessions
To resolve next-hop references (recursive routing)
For example, when RTR-D in the figure receives an IP packet with the destination in AS 12, it
does a recursive lookup to find the outgoing interface to be used for packet forwarding. It
performs the recursive lookup based on IGP information. If there is suddenly an internal
problem within AS 42, and the next-hop address is reachable a different way, the IGP
determines this fact. The IGP route to the next-hop network is changed by the router because of
newly received IGP route information, and all cache entries that rely on the old information are
invalidated. The next recursive lookup that RTR-D performs will indicate a different outgoing
interface than before the problem occurred.
During the IGP convergence process, the BGP routing is not affected. The only routing updates
that are exchanged during the transit AS convergence are IGP updates describing how to reach
internal destinations (including the far ends of the EBGP sessions).
The packet forwarding to external destinations thus benefits from the high-speed convergence
that is offered by the IGP. The faster the IGP determines that it should use an alternate path
within the AS to reach the next-hop address, the faster it will re-establish IP connectivity
toward external destinations.
The conclusion is that an IGP is still needed inside a transit AS, and the network will work
better if it is an IGP with fast convergence.
2-38
Routing Protocols in a Transit AS (Cont.)

Core routers need to run BGP and an IGP.
BGP carries all external routes.
The IGP propagates BGP next hops and other core
subnets only.
All customer routes are also carried in BGP.
Reduces IGP topology database
Removes customer-caused route flaps from IGP; IGP
becomes more stable
BGP v3.22-8
Both BGP and the configured IGP should be configured on all core routers inside the transit
AS. The IGP should carry as little information as possibleideally only the links within the
core network, the loopback interfaces, and the external subnets that are used in EBGP sessions
with neighboring autonomous systems. This information is enough to establish IBGP sessions
and resolve next-hop addresses. The IGP will also work better if it carries less routing
information.
No routes external to the transit AS should ever be redistributed by any router from BGP into
the IGP. All external routes should be in BGP only.
In autonomous systems that provide customer connectivity (not only transit service), it is also
highly recommended that the customer networks be carried in BGP to reduce the amount of
information in the IGP and increase IGP stability.
2-39

This topic describes the interaction between BGP and IGP in a transit AS.

Ideally, there will be no interaction between BGP and
the IGP.
BGP carries external and customer routes.
The IGP carries only core subnets.
The IGP is not affected by external route flaps.
BGP is not affected by failures internal to the network as
long as the BGP next hop remains reachable.
The only link between BGP and the IGP should be the
recursive lookup.
BGP v3.22-9
Ideally, BGP and the IGP carry two different sets of routing information. BGP carries the
routes that are received from other autonomous systems and the routes that belong to the local
AS and should be announced to other autonomous systems. The IGP carries only enough
information to establish IBGP sessions and resolve the EBGP next-hop addresses via the IGP
routing tables.
The IGP will provide reachability toward the BGP next-hop addresses only if it is not disturbed
by external updates from other autonomous systems.
BGP should take care of the external information. As long as the IGP finds a usable way to the
BGP next hops, the BGP does not need to do any recalculation because of internal problems
within the AS.
2-40
BGP and IGP Interaction (Cont.)

Sometimes, BGP and the IGP will propagate the same
route.
Usually stems from bad network design.
In this case, routes are determined in EBGP/IGP/IBGP order
based on administrative distances of the routes.
Routing Protocol Default Administrative

Distance
EBGP
20
IGP
90 170
IBGP
200
BGP v3.22-10
Sometimes the interaction between BGP and the IGP is not ideal, for a number of reasons,
including bad network design. In the worst case, the same networks might be carried in both the
IGP and BGP. For example, the subnets connecting the AS with neighboring autonomous
systems have to be announced via the IGP to enable next-hop resolution but may also be
announced via BGP by the remote AS or the local AS. In any case, information about the same
IP prefix will appear in both the IGP and the BGP data structures.
When the router installs routing information into the routing table, it checks to see whether
there are several sources of information for a particular IP prefix. If so, the router installs the
information that it determines is most reliable. The administrative distance (AD) determines
which source to use.
BGP considers both EBGP and IBGP routes in the BGP selection process. BGP will therefore
never try to install both an EBGP route and an IBGP route for the same destination.
Comparison between ADs will thus occur only when two different protocols carry the same
destination network.
If BGP selects an EBGP route as the best route for a given destination network, it will try to
install that route with a very low AD, meaning that routes that are learned via EBGP have a
high likelihood of being installed in the routing table.
If BGP selects an IBGP route as the best, it will try to install it with a high AD, meaning that
routes that are learned via IBGP have a low likelihood of being installed in the routing table.
All IGPs, such as Enhanced Interior Gateway Routing Protocol (EIGRP), OSPF, Intermediate
System-to-Intermediate System (IS-IS), and so on, have a medium likelihood of being installed.
The ADs for IGPs fall between the ADs of EBGP and IBGP.
Note
The reason for giving EBGP a low default AD is because EBGP indicates routes external to
the local AS. IP packets with destination addresses to those networks should leave the AS
sooner rather than later. It is, in most cases, better that they leave the AS right away.
2-41

This topic describes the potential problems that might arise from BGP and IGP interaction.

If an IGP route is learned through EBGP, the EBGP
route will take precedence.
Potential causes include bad network design, routing
problems, or denial-of-service attack.
Protect IGP routes with inbound prefix-list filters at AS
edges.
Routers should never accept information about local subnets
from an external source.
BGP v3.22-11
If routing information about the same IP prefix is learned via both EBGP and an IGP, the router
will use the EBGP information. If an external AS is feeding the local AS with EBGP routes that
actually should be local, routers within the AS will erroneously forward IP packets that are
destined to those local networks out of the local AS.
There are several potential reasons for this behavior; the most common is that the remote AS is
improperly configured or there is a denial-of-service (DoS) attack. To protect a local AS from
this undesired behavior, network administrators should install inbound filters on all EBGP
sessions to filter incoming routes and reject routing information about networks that are
actually local to the AS.
2-42
Summary
Summary
All core routers need external routers for proper packet
forwarding.
A recursive lookup is performed in BGP to resolve the
forwarding path reference of the next-hop attribute.
Packet forwarding to external destinations benefits from the
high-speed convergence offered by an IGP; therefore, an IGP
is still needed inside a transit AS.
The IGP should provide reachability toward BGP next-hop
addresses only if they are not disturbed by external updates
from other autonomous systems (those are handled by BGP).
IP packets could be erroneously forwarded out of the local
AS if an external AS accidentally (or by intent: DoS) feeds the
local AS with EBGP routes that should be local.
BGP v3.22-12
2-43
2-44
Lesson 4
Overview
Specifying an autonomous system (AS) as a transit backbone introduces specific requirements
in the design, scaling, and configuration of Border Gateway Protocol (BGP). This lesson
introduces the configuration requirements of Internal Border Gateway Protocol (IBGP) to
implement a transit AS. Configuration details of IBGP are discussed in this lesson, including
IBGP neighbor configuration, using loopback interfaces for IBGP neighbors, disabling BGP
synchronization, and modifying the default administrative distances (ADs) of BGP. This lesson
concludes with a discussion of the scalability concerns of BGP in the transit backbone.
Objectives
Upon completing this lesson, you will be able to configure an AS to act as a transit backbone in
a BGP network. This ability includes being able to meet these objectives:
Identify the Cisco IOS commands that are required to configure IBGP neighbors in an AS
Identify the Cisco IOS command that is required to configure IBGP sessions between
loopback interfaces in a common AS
Identify the Cisco IOS command that is required to configure BGP synchronization to
ensure successful IBGP operation of the transit AS
Identify the Cisco IOS command that is required to change the AD of BGP routes
List the scalability limitations of IBGP-based backbones

This topic describes the Cisco IOS commands that are required to configure IBGP neighbors in
an AS.
This command configures a BGP neighbor.

The AS number configured determines whether the session is
an EBGP session (neighbor AS is different from local AS) or
IBGP session (same AS number).
Attaches optional description to a neighbor
BGP v3.22-3
Configuring an IBGP neighbor involves two simple steps:

Configure a BGP neighbor, specifying the same AS number.
Attach a description to the neighbor to help in documentation and troubleshooting efforts
(optional).
neighbor remote-as
To add an entry to the BGP neighbor table, use the neighbor remote-as router configuration
command.
neighbor [ip-address | peer-group-name] remote-as as-number
To remove an entry from the table, use the no form of this command.
no neighbor [ip-address | peer-group-name] remote-as as-number
Syntax Description
2-46
Parameter
Description
Neighbor IP address
AS to which the neighbor belongs
To associate a description with a neighbor, use the neighbor description router configuration
command.
neighbor [ip-address | peer-group-name]description text
To remove the description, use the no form of this command.
no neighbor [ip-address | peer-group-name] description text
Syntax Description
Parameter
Description
Neighbor IP address
Text (up to 80 characters) that describes the neighbor
2-47
Configuring IBGP Sessions Between Loopback

Interfaces
This topic describes the Cisco IOS command that is required to configure IBGP sessions
between loopback interfaces on routers in a common AS.
Configuring IBGP Sessions Between

Loopback Interfaces
This command configures the source interface for the TCP

session that carries BGP traffic.
For IBGP sessions, the source interface is a loopback address.
The source address configured on one peering router must
match the destination address configured on the othera BGP
session will not start otherwise.
Make sure that your loopback interfaces are announced in the
backbone IGP.
BGP v3.22-4
When a BGP session is established between two routers, both routers attempt to set up the TCP
connection by sending TCP SYN packets to each other. If both succeed, one of the sessions is
brought down so that only one remains. The TCP packets have a destination IP address that is
configured with the neighbor command. But they must also have a source IP address assigned.
If no update source is configured, the router sets the source IP address of the outgoing TCP
session to the IP address of the outgoing physical interface.
When a TCP SYN packet with the BGP well-known port number arrives at the peer router, the
receiver checks to determine if the connection attempt is coming from one of the configured
peers. If the source IP address is not in the list of configured neighbors, the receiver denies the
connection attempt.
As a general rule, IBGP sessions should be established between loopback interfaces of BGPspeaking routers. The destination IP address that is configured in the neighbor statement should
therefore be the IP address of the loopback interface of the peer router. But the local router
must also make sure that the source address of the outgoing TCP connection attempt is the IP
address that the peer router has listed. Configuring BGP neighbors using neighbor updatesource ensures that the source address of the outgoing TCP connection is correct by referring to
the interface that has the correct IP address. Normally, this interface is the loopback interface of
the local router.
2-48
neighbor update-source
To instruct Cisco IOS software to allow IBGP sessions to use any operational interface for TCP
connections, use the neighbor update-source router configuration command.
neighbor [ip-address | peer-group-name] update-source interface
To restore the interface assignment to the closest interface, which is called the best local
address, use the no form of this command.
no neighbor [ip-address | peer-group-name] update-source interface
Syntax Description
Parameter
Description
Neighbor IP address
Loopback interface
2-49

This topic describes the Cisco IOS command that is required to configure BGP synchronization
to ensure successful IBGP operation of a transit AS.
This command disables synchronization between BGP and an

IGP.
Modern transit autonomous systems do not need
synchronization because they do not rely on redistribution of
BGP routes into an IGP.
BGP synchronization has to be disabled in modern transit AS
designs on all BGP routers.
BGP v3.22-5
The BGP synchronization rule states that if an AS provides transit service to another AS, BGP
should not advertise a route until all of the routers within the AS have learned about the route
via an Interior Gateway Protocol (IGP). Network designers used synchronization in older
transit AS designs that relied on BGP route redistribution into the IGP. Modern AS designs do
not rely on this feature anymore because the number of routes carried in the Internet exceeds
the scalability range of any known IGP. Redistribution into the IGP is thus no longer
applicable, and you must disable the synchronization feature for your transit AS to work.
synchronization
To enable the Cisco IOS software to advertise a network route without waiting for the IGP (that
is, to disable synchronization between BGP and your IGP), use the no form of the
synchronization command. Note that in Cisco IOS Software Release 12.2(8)T and later, the
default changed to disable synchronization.
no synchronization
This command has no arguments or keywords.
2-50
Changing the Administrative Distance of BGP

Routes
This topic describes the Cisco IOS command that is required to change the AD of BGP routes.
Changing the Administrative

Distance of BGP Routes
This command sets the AD for EBGP, IBGP, and local routes.
This change applies only to routes received after the command
has been entered (similar to filters).
Defaults: EBGP routes have a distance of 20; IBGP and local
routes have a distance of 200.
The defaults are usually correct; do not change them.
BGP v3.22-6
distance bgp
To allow the use of external, internal, and local ADs that could be a better route to a node, use
the distance bgp router configuration command.
distance bgp external-distance internal-distance local-distance
To return to the default values, use the no form of this command.
no distance bgp external-distance internal-distance local-distance
2-51
Syntax Description
Parameter
Description
AD for BGP external routes.

External routes are routes for which the best path is learned from
a neighbor external to the AS. Acceptable values are from 1 to
255. The default is 20. Routes with a distance of 255 are not
installed in the routing table.
AD for BGP internal routes.

Internal routes are routes that are learned from another BGP
entity within the same AS. Acceptable values are from 1 to 255.
The default is 200. Routes with a distance of 255 are not installed
in the routing table.
AD for BGP local routes.

Local routes are the networks that are listed with a network
router configuration command, often as back doors (BGP back
door makes the IGP route the preferred route) for that router or
for networks that are being redistributed from another protocol.
Acceptable values are from 1 to 255. The default is 200. Routes
with a distance of 255 are not installed in the routing table.
2-52
Scalability Limitations of IBGP-Based Transit

Backbones
This topic describes the scalability limitations of IBGP-based backbones.
Scalability Limitations of IBGP-Based

Transit Backbones
Transit backbone requires IBGP full mesh between
all core routers.
Large number of TCP sessions
Unnecessary, duplicate routing traffic
There are two scalability solutions:

Route reflectors
BGP confederations
BGP v3.22-7
IBGP split-horizon rules, as documented in previous lessons, mandate an IBGP connection

between every border router and every other BGP router in an AS.
The general design rule in IBGP design is to have a full mesh of IBGP sessions. But, a full
mesh of IBGP sessions among n number of routers would require (n * (n 1)) / 2 IBGP
sessions. For example, a full mesh between 10 routers would require (10 * 9) / 2 = 45 IBGP
sessions.
Because every IBGP session on a router uses a separate TCP session, an update that must be
sent by the router to all IBGP peers must be sent on each of the TCP sessions. If a router is
attached to the rest of the network over just a single link, this single link has to carry all TCP/IP
packets for all IBGP sessions. This situation results in duplication of the update over the single
link.
Two solutions are available:
The route reflector solution modifies the IBGP split-horizon rules and allows a particular
router to forward (under certain conditions) incoming IBGP updates to a select group of
IBGP neighbors. The router performing this function is the route reflector.
The BGP confederations solution introduces the concept of a number of smaller
autonomous systems within the original AS. These smaller autonomous systems exchange
BGP updates among themselves using intraconfederation EBGP sessions.
2-53
Summary
Summary
To configure an IBGP neighbor, use the neighbor command, specifying a
remote AS number matching the AS number of the local router.
When you configure IBGP sessions between loopback interfaces, the
interfaces must be announced in the backbone IGP. Configuring BGP
neighbors using the neighbor update-source command ensures that the
source address of the outgoing TCP connection is correct by referring
to the interface that has the correct IP address.
You should disable BGP synchronization in all modern transit AS
designs on all BGP routers by using the no form of the synchronization
command.
Although you can change the administrative distances of BGP routes
by using the distance bgp router configuration command, you typically
should not change the default settings for EBGP (20) and IBGP (200).
The full-mesh IBGP requirement in the transit AS creates scalability
issues in the number of TCP sessions and unnecessary, duplicate
routing traffic. IBGP scalability solutions to these issues exist.
2-54
BGP v3.22-8
Lesson 5
Monitoring and
Troubleshooting IBGP in a
Transit AS
Overview
Introduction of a transit backbone into a Border Gateway Protocol (BGP) network can create
unique troubleshooting challenges. This lesson introduces Internal Border Gateway Protocol
(IBGP) monitoring commands and troubleshooting techniques for solving the most common
IBGP problems that you might encounter in a transit backbone. Common problems with IBGP,
as discussed in this lesson, occur when IBGP sessions do not reach the Established state, when
routing information that is received via IBGP is never selected, and when the best BGP route is
never installed in the routing table.
Objectives
Upon completing this lesson, you will be able to verify proper operation of a configured BGP
transit network by performing the steps necessary to correct basic IBGP configuration errors.
Identify the Cisco IOS commands that are required to monitor IBGP operation
Describe common IBGP configuration problems
Explain how to troubleshoot IBGP session startup issues
Explain how to troubleshoot IBGP route selection issues
Explain how to troubleshoot IBGP synchronization issues
Monitoring IBGP
This topic describes the Cisco IOS commands that are required to monitor IBGP operation.
Monitoring IBGP
Displays whether a neighbor is an IBGP neighbor
Uses a special marker (i) for IBGP routes
Displays whether the prefix is an IBGP route
BGP v3.22-3

show ip bgp neighbors [ip-address] [received-routes | routes | advertised-routes | {paths
2-56
Syntax Description
Parameter
Description
(Optional) Address of the neighbor to display neighbor

information about.
(Optional) Displays all received routes (both accepted and

rejected) from the specified neighbor.
(Optional) Displays all routes that are received and accepted.

The display output when you are using this keyword is a subset
of the output from the received-routes keyword.
(Optional) Displays all the routes that the router has advertised to
the neighbor.
(Optional) Regular expression that the router uses to match the

paths that are received.
(Optional) Displays the dampened routes to the neighbor at the

IP address that is specified.
show ip bgp
Syntax Description
Parameter
Description
(Optional) Network number that is entered to display a particular

network in the BGP routing table
(Optional) Displays all BGP routes that match the address-mask

pair
(Optional) Displays the route and more specific routes
2-57
Example: Monitoring IBGP

This example shows the commands to monitor IBGP.
Monitoring IBGP (Cont.)
BGP v3.22-4
The show ip bgp neighbors command displays whether a router is running an IBGP (internal)
or External Border Gateway Protocol (EBGP) (external) session with a BGP neighbor. The
indication is given by the internal link phrase (highlighted in the second line of the figure).
2-58
Monitoring IBGP (Cont.)
BGP v3.22-5
The show ip bgp prefix command displays whether a BGP route was received from an IBGP
(internal) or EBGP (external) neighbor. The indication is given by the word internal that is
displayed in the last line of the printout (highlighted in the last line of the figure).
2-59

This topic describes configuration problems that are common to IBGP implementations.

IBGP sessions will not start.
IBGP route is in the BGP table but is not selected.
IBGP route is selected but is not entered in the routing
table.
BGP v3.22-6
Troubleshooting the BGP configuration of a transit AS can be cumbersome, because there are a
number of common pitfalls that you might encounter. Three of the most common problems are
the following:
IBGP sessions do not reach the Established state.
Routing information that is received via IBGP is never selected.
The best BGP route is never installed in the routing table.
2-60
Troubleshooting IBGP Session Startup Issues

This topic describes how to troubleshoot IBGP session startup issues.
Troubleshooting IBGP Session Startup

Issues
Symptom:
IBGP session does not start.
Diagnosis:
IBGP session is run between loopbacks, and update-source
keyword is missing.
Verification:
Use debug ip tcp transactions. You should see BGP sessions
coming from unexpected IP addresses.
BGP v3.22-7
A common mistake when you are configuring IBGP sessions is to forget the neighbor updatesource loopback 0 configuration command.
When you are configuring IBGP neighbors on the router, it is easy to remember to make a
correct reference to the loopback interface of the remote router. But it is equally important to
make sure that the correct source IP address of the outgoing TCP session is set. The peer router
will not accept the session if the incoming source address does not match the peer router list of
IBGP neighbors.
To verify that this issue is causing the problem, use the debug ip tcp transactions command.
The output of the debug ip tcp transactions command should display TCP SYN packets
coming from unexpected IP addresses on the receiving router and TCP sessions being reset
with TCP RST packets on the sending (misconfigured) router.
2-61

Issues (Cont.)
Symptom:
Diagnosis:
Loopback interfaces are not reachable.
Verification:
Do extended ping between loopback addresses to verify
reachability.
BGP v3.22-8
An IBGP session between two routers can be established from the loopback interface of one
router to the loopback interface of the other router only if the two routers can exchange IP
packets using those addresses as source and destination. This exchange is possible only if the
Interior Gateway Protocol (IGP) carries the subnets that are assigned to each of the loopback
interfaces.
When you are verifying reachability with the ping command, make sure that the ping packets
are sourced from the loopback interface. Use an extended ping and explicitly refer to the IP
address of the loopback interface to ensure that packets are sourced from the loopback
interface.
2-62

Issues (Cont.)
Symptom:
Diagnosis:
Packet filters prevent establishment of BGP sessions.
Verification:
Use debug ip tcp transactions and debug ip icmp to see whether
the initial TCP SYN packets are rejected.
BGP v3.22-9
Packet filters can stop the BGP sessions. The path between the two BGP peer routers must be
free from filters blocking the BGP traffic.
BGP runs on the well-known TCP port 179. Both routers will make connection attempts to that
destination port. They will use a high-numbered TCP port as source. It is enough that one of the
connection attempts succeeds. But for better performance during recovery from network
failure, both attempts should have the possibility of succeeding. If both attempts do succeed,
one of the connections will be brought down.
2-63
Troubleshooting IBGP Route Selection Issues

This topic describes how to troubleshoot IBGP route selection issues.
Troubleshooting IBGP Route Selection

Issues
Symptom:
An IBGP route is in the BGP table but is never selected as the
best route.
Diagnosis:
The BGP next hop is not reachable.
Verification:
Use show ip bgp prefix to find the BGP next hop.
Use show ip route to verify next-hop reachability.
BGP v3.22-10
A BGP update can be used by the router to reach network destinations only if the next-hop
address specified in the BGP update is reachable. A BGP update that refers to a next hop that is
currently not reachable according to the routing table will be saved in the BGP table, but it
cannot be installed by the router into its routing table. If the next-hop address later becomes
reachable, the BGP route will become a candidate route that could be used by that router for
packet forwarding to that destination.
To verify the next-hop reachability, check the BGP route in the BGP table by using the show ip
bgp prefix command. The next hop is referred to as inaccessible if it is not currently
reachable according to the routing table.
A common mistake is to forget to let the IGP announce the reachability of subnets that
physically connect the local autonomous system (AS) with a neighboring AS. These subnets
are used by the router to establish the EBGP session, and the next hop that is received in an
incoming BGP update will be the far end of the EBGP session. If all routers in the local AS do
not have a path to that subnet, the next-hop address will be inaccessible.
You can prevent this problem by including the subnet that links the transit AS to neighboring
autonomous systems in the IGP by using either the redistribute connected command or the
network and passive-interface configuration commands.
2-64
Troubleshooting IBGP Synchronization Issues

This topic describes how to troubleshoot IBGP synchronization issues.
Troubleshooting IBGP Synchronization

Issues
Symptom:
An IBGP route is selected as the best route but not entered
into the IP routing table.
Diagnosis:
BGP synchronization is not disabled.
Verification:
Disable BGP synchronization, clear the BGP sessions, and
re-examine the IP routing table after the BGP table becomes
stable.
BGP v3.22-11
In old BGP designs, redistribution between BGP and an IGP was common practice, and these
protocols had to be synchronized to ensure proper packet forwarding. In modern designs,
redistribution is no longer used and synchronization has to be turned off. However, the default
value is to have synchronization enabled.
Routers with BGP synchronization enabled will not be able to install IBGP routes in the routing
table or propagate them to other EBGP neighbors.
You can fix this problem by configuring no synchronization in the router BGP configuration.
2-65
Summary
Summary
You can use the show ip bgp neighbors and show ip bgp prefix
commands to monitor IBGP operation.
Common IBGP configuration problems include IBGP
sessions that do not reach the Established state, routing
information that is received via IBGP that is never selected,
and the best BGP route never being installed in the routing
table.
There are a number of problems that can occur during IGBP
session startup. You can use debug ip tcp transactions to see
BGP sessions coming from unexpected IP addresses, use an
extended ping and explicitly refer to the IP address of the
loopback interface to ensure that packets are sourced from
the loopback interface, or use debug ip tcp transactions and
debug ip icmp to see whether the initial TCP SYN packets are
rejected.
BGP v3.22-12
Summary (Cont.)
It is important to include the subnet linking the transit AS to
an external AS in the IGP to prevent the BGP next hop from
being unreachable. To verify next-hop reachability, check the
BGP route in the BGP table by using the show ip bgp prefix
command.
Routers with BGP synchronization enabled will not be able to
install IBGP routes in the routing table or propagate them to
other EBGP neighbors. Configure no synchronization in the
router BGP configuration to solve this problem.
2-66
BGP v3.22-13
Module Summary
Module Summary
Because all transit autonomous systems are required to carry traffic
originating from or destined to locations outside of that AS, a
degree of interaction and coordination between BGP and the IGP is
necessary, and special care should be taken to ensure consistency
of routing information throughout the AS.
Both EBGP and IBGP sessions forward BGP updates, but they do it
in slightly different ways.
An IGP is still needed inside a transit AS. The high-speed
convergence offered by an IGP helps in the packet forwarding to
external destinations.
Configuring in a transit AS involves configuring IBGP neighbors,
BGP synchronization, and IBGP sessions between loopback
interfaces.
The three common IBGP configuration problems concern session
startup, route selection, and synchronization, and there are specific
commands and procedures that can be used to solve those
problems.
BGP v3.22-1
This module discussed BGP issues in a transit AS. The first lesson introduced the requirements
of IBGP and described processing the next-hop attribute with the routers that reside in the
transit AS. The next lesson explained the interaction between EBGP and IBGP. The following
lesson described the function of an IGP in forwarding packets through an AS. Configuring the
AS as a transit backbone was discussed in the next lesson. The final lesson presented IBGP
monitoring commands and troubleshooting techniques to solve the most common IGBP
problems in a transit backbone.
2-67
References
Cisco Systems, Inc. BGP Case Studies.
http://www.cisco.com/warp/public/459/bgp-toc.html.
Cisco Systems, Inc. Troubleshooting TCP/IP. Troubleshooting IP Connectivity and
Routing Problems.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1907.htm#xtocid27.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1
cfbgp.htm.
Cisco Systems, Inc. Cisco IOS IP Routing Configuration Guide, Release 12.2
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1835/products_configuration_
guide_book09186a0080087fa9.html.
2-68
Module Self-Check
Q1)
Why is IBGP a mandatory component of a transit AS? (Source: Working with a Transit
AS)
A)
B)
C)
D)
Q2)
How is EBGP used in a transit AS? (Source: Working with a Transit AS)
A)
B)
C)
D)
Q3)
B)
C)
D)
to filter out routes that do not belong to customers of the service provider
to provide Internet connectivity to customers of the service provider
to propagate routes between remote autonomous systems
to route packets between remote networks
How are BGP routes sent across the transit backbone? (Source: Working with a Transit
AS)
A)
B)
C)
D)
Q6)
Redistribution removes all BGP attributes that are needed to ensure optimal
routing within the transit AS.
An IGP cannot enforce complex administrative policies and route selection
rules.
IGPs cannot scale to the demands that are presented by the number of routes on
the Internet.
IGPs are not stable when faced with a flapping network.
What are the two key functions of a transit AS? (Choose two.) (Source: Working with a
Transit AS)
A)
B)
C)
D)
Q5)
as a means of transporting customer routes across the transit backbone

to exchange routes between different autonomous systems and the transit AS
to enhance scalability by transporting IGP routes for the transit AS
as a means of injecting local routes into the transit backbone
Why is redistributing BGP routes into an IGP for use in a transit backbone NOT
recommended? (Source: Working with a Transit AS)
A)
Q4)
It is the only feasible way to ensure that all routers in the AS have consistent
external routing information.
It eliminates the scalability issues of running an IGP within the transit AS.
Running IBGP on all routers is the only way to satisfy the filtering
requirements of the transit AS.
An IGP is not capable of handling the potential routing loops in the transit AS.
by redistributing BGP into an IGP and then back into BGP

through the use of IBGP
by establishing EBGP sessions between all routers in the transit backbone
by redistributing connected routes at the edge of the transit backbone
Which two statements are true regarding the AS-path attribute as it relates to IBGP?
(Choose two.) (Source: Interacting with IBGP and EBGP in a Transit AS)
A)
B)
C)
D)
Each router in the AS appends its AS number to the AS path on outgoing BGP
updates.
The AS path inside an AS will be empty for routes originating inside a
neighboring AS.
The AS-path attribute is not used to detect routing loops inside an AS.
The AS-path attribute is not modified within the AS.
2-69
Q7)
What is the primary function of the IBGP multipath load-sharing feature? (Source:
Interacting with IBGP and EBGP in a Transit AS)
A)
B)
C)
D)
Q8)
Which of the following statements about a BGP split horizon is accurate? (Source:
A)
B)
C)
D)
Q9)
D)
The IBGP mesh must be a logical full mesh.

A physical full mesh must be maintained within the IBGP AS.
Because of BGP split horizon, no router can relay IBGP information within the
AS.
All routers within the AS must be directly connected to ensure correct delivery
of BGP routing information.
Which three statements regarding the next-hop-self configuration in BGP are true?
(Choose three.) (Source: Interacting with IBGP and EBGP in a Transit AS)
A)
B)
C)
D)
2-70
The next-hop address is set to the address of the receiving router.

The next-hop address is not modified over the IBGP session.
The next-hop address is set to the IP address of the nearest EBGP peer.
The next-hop attribute is set to the IP address of the nearest EBGP peer; if no
external AS connection has been configured, the next hop is set to the default
gateway that is configured on the router.
Which two statements are true of the full-mesh requirement in IBGP? (Choose two.)
(Source: Interacting with IBGP and EBGP in a Transit AS)
A)
B)
C)
Q12)
reduces router memory resource requirements

reduces router CPU resource requirements
ensures IBGP session stability
is more secure than using the physical interface
How is the BGP next-hop attribute processed over an IBGP connection? (Source:
A)
B)
C)
D)
Q11)
Because of the BGP split horizon, any router can relay IBGP information
within the AS.
BGP split horizon is useful only within autonomous systems.
Routing information loops within the AS are prevented by an IBGP split
horizon.
With a BGP split horizon, routing information that is received through an
IBGP session is forwarded to another IBGP neighbor.
Why is it recommended that loopback interfaces be used to form IBGP neighbor

sessions? (Source: Interacting with IBGP and EBGP in a Transit AS)
A)
B)
C)
D)
Q10)
to choose one IBGP path as the best path to a destination

to choose multiple IBGP paths as the best paths to a destination
to designate one path as the best path and advertise this best path to its
neighbors.
to enable a router to handle all the traffic destined for a particular site
Changing the next-hop attribute might cause suboptimal routing.

The configuration changes how the next-hop attribute is processed at edge
routers.
The configuration announces the local IP address as the BGP next hop in
outgoing updates that are sent to the specified neighbor.
The configuration removes the requirement for the IGP to carry reachability
information for intra-AS destinations.
Q13)
Why must all EBGP peers be reachable by all BGP-speaking routers within the transit
AS? (Source: Interacting with IBGP and EBGP in a Transit AS)
A)
B)
C)
D)
Q14)
Which command is used to configure the router as the next hop for a BGP-speaking
neighbor or peer group? (Source: Interacting with IBGP and EBGP in a Transit AS)
A)
B)
C)
D)
Q15)
C)
D)
so routers can properly forward packets toward all external destinations

to ensure that a full mesh exists among all routers in the AS
to allow routers to properly process the BGP next-hop attribute
because IGPs cannot scale large enough to handle redistribution of BGP routes
If a transit backbone has IBGP running on all routers, what are two reasons why it is
still necessary to use an IGP? (Choose two.) (Source: Forwarding Packets in a Transit
AS)
A)
B)
C)
D)
Q18)
Route selection rules slightly prefer IBGP routes.

Routes that are learned from IBGP peers are not advertised to other IBGP
peers.
EBGP peers are directly connected, and IBGP peers are usually distant.
By default, no BGP attributes are changed in IBGP updates.
What are two reasons why you must run IBGP on all routers within a transit backbone?
(Choose two.) (Source: Forwarding Packets in a Transit AS)
A)
B)
C)
D)
Q17)
neighbor remote as
maximum-paths ibgp
neighbor next-hop-sf
What are three differences between IBGP and EBGP sessions? (Choose three.)
(Source: Interacting with IBGP and EBGP in a Transit AS)
A)
B)
Q16)
BGP-speaking routers in a transit AS use the next-hop-self attribute to find

their EBGP neighbors.
EBGP peers in a transit AS use the length of the AS path to decide which BGP
route to install in the routing table.
When BGP routes are used in the routing table, the router checks how it would
have reached the next-hop address, and it installs the BGP route with the same
forwarding indication as for the route that is used to reach the next-hop IP
address.
All BGP peers do not need to speak to each other within a transit AS.
to provide routing information that is needed to establish the IBGP sessions

to resolve next-hop references that are used in recursive routing
so that BGP routes can be properly transported through the AS
to provide user workstations with a network default gateway
What is the AD of the following protocols? (Fill in the blanks.) (Source: Forwarding
Packets in a Transit AS)
A)
B)
C)
D)
E)
IBGP
EBGP
OSPF
IS-IS
RIP
_______
_______
_______
_______
_______
2-71
Q19)
What are two reasons why the AD is an important consideration for BGP network
design? (Choose two.) (Source: Forwarding Packets in a Transit AS)
A)
B)
C)
D)
Q20)
With regard to recursive route lookups, what are two ways in which CEF is different
from traditional Cisco IOS switching mechanisms such as route caching?
(Choose two.) (Source: Forwarding Packets in a Transit AS)
A)
B)
C)
D)
Q21)
D)
Ensure that the loopback interfaces are reachable through an IGP.

Ensure that the two neighbors are directly attached.
Verify that each router has multiple physically redundant paths.
Configure a neighbor statement with the update-source command.
Why is it important to disable BGP synchronization in a transit backbone? (Source:

Configuring a Transit AS)
A)
B)
C)
D)
2-72
The keyword internal is at the end of the neighbor command.

IBGP neighbors will have the same AS number specified.
A description for the internal or external neighbor must be attached with the
neighbor description command.
Directly connected neighbors will automatically form an EBGP session.
Which two steps are required when you use a loopback interface for IBGP peering
sessions? (Choose two.) (Source: Configuring a Transit AS)
A)
B)
C)
D)
Q23)
Traditional Cisco IOS switching mechanisms wait for the first packet to arrive
before recursive lookup can take place.
New entries in the IP routing table will trigger a recursive lookup in traditional
Cisco IOS switching mechanisms.
CEF prebuilds a complete IP forwarding table based on the IP routing table.
CEF will build a FIB directly from the entries in the BGP table before any
BGP packets arrive at the router.
When you are configuring the BGP neighbor session, what differentiates an EBGP
neighbor from an IBGP neighbor? (Source: Configuring a Transit AS)
A)
B)
C)
Q22)
The AD affects how routes are selected for use in the IP routing table.
The AD controls how routing information is entered into the BGP table.
If a route is advertised by both an IGP and through EBGP, the router will
prefer the external route.
The AD is not a large concern to BGP design, because the router will always
choose the route that is advertised by the protocol that is best suited to reach
the destination.
IGPs can support the routing requirements of full Internet routing, and hence
synchronization is no longer necessary.
Because BGP redistribution into an IGP is no longer practical, enabling the
synchronization feature is no longer applicable.
Synchronization requires all BGP transit routes to be explicitly mapped to an
exit point, creating too much administrative overhead.
Synchronization requires BGP attributes to be properly mapped to IGP metrics
for BGP routing across the transit backbone to function properly, creating too
much overhead.
Q24)
What are two negative ramifications of the full-mesh requirement that is imposed by
IBGP? (Choose two.) (Source: Configuring a Transit AS)
A)
B)
C)
D)
Q25)
What are two scalability tools that you can use to overcome the full-mesh requirement
for IBGP sessions? (Choose two.) (Source: Configuring a Transit AS)
A)
B)
C)
D)
Q26)
IBGP sessions do not reach the Established state.

TCP window size is set incorrectly.
Routing information that is received via IBGP is never selected.
The best BGP route is never installed in the routing table.
What are three common situations that prevent IBGP sessions from starting? (Choose
three.) (Source: Monitoring and Troubleshooting IBGP in a Transit AS)
A)
B)
C)
D)
Q29)
show ip route
show ip route bgp
show ip bgp
show ip bgp internal
Which three of the following are the most common BGP implementation problems?
(Choose three.) (Source: Monitoring and Troubleshooting IBGP in a Transit AS)
A)
B)
C)
D)
Q28)
confederations
floating static routes
route reflectors
disabling BGP synchronization
Which Cisco IOS show command indicates that a BGP route is an IBGP route?
(Source: Monitoring and Troubleshooting IBGP in a Transit AS)
A)
B)
C)
D)
Q27)
administrative difficulty of applying an AS-wide routing policy

requirement to use next-hop-self for proper routing to external destinations
large number of TCP sessions
unnecessary duplication of routing traffic
The IBGP session has been configured to peer to a loopback interface, but
update-source has not been configured on the neighbor.
An access-list filter is blocking access to TCP port 179.
The IBGP session has been configured to peer to a loopback interface, but the
loopback interface has not been administratively enabled with the no
shutdown command.
The IBGP session has been configured to peer to a loopback interface, but the
interfaces are not reachable via the IGP.
Which common issue could prevent IBGP best routes from being inserted into the IP
routing table? (Source: Monitoring and Troubleshooting IBGP in a Transit AS)
A)
B)
C)
D)
failure to disable BGP synchronization

failure to disable BGP split horizon
lack of a route to the BGP next hop for the IGP
failure to inject a default route into the IGP
2-73
Q30)
Which two of the following statements about solving IBGP synchronization problems
are accurate? (Choose two.) (Source: Monitoring and Troubleshooting IBGP in a
Transit AS)
A)
B)
C)
D)
2-74
Routers with BGP synchronization enabled will be able to install IBGP routes
in the routing table and propagate them to other EBGP neighbors.
Routers with BGP synchronization enabled will not be able to install IBGP
routes in the routing table or propagate them to other EBGP neighbors.
The default value is to have synchronization enabled.
The default value is to have synchronization disabled.

Q1)
Q2)
Q3)
Q4)
C, D
Q5)
Q6)
C, D
Q7)
Q8)
Q9)
Q10)
Q11)
A, C
Q12)
A, B, C
Q13)
Q14)
Q15)
B, C, D
Q16)
A, D
Q17)
A, B
Q18)
A-200
B -20
C- 110
D -115
E -120
Q19)
A, C
Q20)
A, C
Q21)
Q22)
A, D
Q23)
Q24)
C, D
Q25)
A, C
Q26)
Q27)
A, C, D
Q28)
A, B, D
Q29)
Q30)
B, C
2-75
2-76
Module 3
Route Selection Using Policy

Controls
Overview
Border Gateway Protocol (BGP) enables traffic in Internet backbones to determine an optimal
path to its destination across networks comprising more than one autonomous system (AS).
Routes that are learned via BGP have properties that are associated with them that aid BGP in
determining the best route to a particular destination. There are many instances in which the
default BGP route selection does not match administrative or business policies. Likewise,
redundant network designs often require enterprises to run BGP when they are connected to
more than one Internet service provider (ISP). In these situations, full BGP routing tables and
default BGP route selection are not desirable.
This module provides information on how to connect Internet customers to multiple service
providers. It introduces the need for filtering BGP updates and changing BGP route selection
policies. In addition, this module describes different Cisco IOS mechanisms (AS-path filters,
prefix-lists, route-maps) available for BGP route filtering.
Module Objectives
Upon completing this module, you will be able to use BGP attributes to influence the route
selection process in a network scenario where you must support multiple connections. This
ability includes being able to meet these objectives:
Describe the need for influencing BGP route selection in a customer scenario where
connections to multiple ISPs must be supported
Successfully configure BGP to influence route selection using AS-path filters in a customer
scenario where connections to multiple ISPs must be supported
Successfully configure BGP to influence route selection using prefix-list filters in a
customer scenario where connections to multiple ISPs must be supported
Use outbound route filtering to minimize the impact of BGP routing updates on router
resources in an operational BGP network
Correctly configure BGP to influence route selection using route-maps in a typical BGP
network
Configure the soft reconfiguration feature to minimize the impact of expediting BGP policy
updates in a typical BGP network
3-2
Lesson 1
Using Multihomed BGP

Networks
Overview
In some circumstances, it is important to have multiple paths to an Internet service provider
(ISP). There are business and technical reasons to configure a Border Gateway Protocol (BGP)
network in a multihomed configuration. Mission-critical applications often call for redundant
network designs. When access to applications is provided over the Internet, enterprises
typically use multihomed BGP networks to achieve their goals of high availability.
Full BGP routing tables and default BGP route selection might ordinarily be considered as
desirable characteristics for a network. However, the overhead of full BGP routing tables is not
warranted in these situations. Furthermore, the default route selection in BGP often does not
match the business and technical requirements for multihomed enterprise networks that use
BGP. This lesson discusses these business and technical issues and the requirement to use
filters to influence route selection and to apply a routing policy.
Objectives
Upon completing this lesson, you will be able to describe the need for influencing BGP route
selection in a customer scenario where connections to multiple ISPs must be supported. This
List the business requirements for multihomed BGP networks in service provider
environments
Describe the technical requirements for multihomed BGP networks in service provider
environments
Explain the need for BGP policies that influence route selection in a multihomed BGP
network
Describe typical routing policies for multihomed BGP customers
Explain the need to influence BGP route selection in a service provider environment
Explain the need for BGP filters in a service provider environment
Business Requirements for Multihomed BGP

Networks
This topic describes the business requirements for multihomed BGP networks in service
provider environments.
Business Requirements for Multihomed

BGP Networks
Some customers need redundant Internet access for their

mission-critical applications.
Full redundancy is achieved only by connecting to two
independent service providers.
BGP v3.23-3
Companies with web servers (or similar servers) offering mission-critical business services
over the Internet often like to have their networks redundantly connected to the Internet. When
the companies calculate the expected loss of business because of an unexpected disconnection
from the Internet, they may conclude that having two connections to the Internet is profitable.
In such cases the company may consider being a customer to two different ISPs or having two
separate connections to one ISP.
With two connections to one single ISP, BGP is usually not required. This solution provides
backup for link failure and router failure. However, this solution does not provide backup for
problems in the network of the ISP or the connection of the ISP to the rest of the Internet.
Full redundancy is achieved only by connecting to two independent ISPs. If one of the ISP
networks loses its connection to the rest of the Internet, the customer will still reach the rest of
the Internet via the other service provider. At the same time, the customer will still reach those
users directly connected to the failing ISP via its direct connection.
3-4
Technical Requirements for Multihomed BGP

Networks
This topic describes the technical requirements for multihomed BGP networks in service
provider environments.
Technical Requirements for Multihomed

BGP Networks
Multihomed customers have to run BGP with their ISPs.

Multihomed customers usually need a public AS number and
provider-independent address space.
BGP v3.23-4
The multihomed customer network must exchange BGP information with both ISP networks.
Dynamic routing is required for full redundancy, and BGP is the only protocol available that
can be used in this scenario.
The customer must, in most cases, have its own public autonomous system (AS) number and
announce its own IP networks to both ISPs. The ISPs will propagate customer announcements
to the rest of the Internet, and the customer will be seen as reachable via both ISP networks.
The customer network also receives full Internet routing from both ISPs. This capability gives
the customer network the opportunity to choose the best connection at that time to reach any
destination on the Internet.
Most customers are not multihomed. They do not exchange BGP with their ISP. Instead, they
use default routing to the ISP, and the ISP does static routing to the customer. ISPs use this fact
to optimize the number of prefixes that they announce into the Internet. IP network numbers are
usually assigned to customers from a range of IP networks that are delegated to the ISP. This
situation means, in the ideal case, that all customers that are connected to one single ISP can
have their IP networks summarized in a few BGP updates.
In the multihomed scenario, however, the ISP cannot benefit from IP network number
assignment from the delegated range. The customer is connected to two different ISPs, and it is
not obvious from which provider-assigned address space it should get the IP addresses. The
best solution is to do the assignment from a range completely independent of the providers, a
provider-independent address space.
3-5

This topic describes the need for BGP policies that influence route selection in a multihomed
BGP network.
Customer configures two BGP sessions and announces its

address space.
BGP v3.23-5
The simple approach illustrated in the figure may be the source of many problems. By simply
starting BGP sessions with both ISPs, and announcing the customers networks to both ISPs,
that customer could experience difficulties as a result of the default behaviors of BGP. The
following example illustrates problems that may occur in this environment.
3-6
Example: BGP Route Selection Without BGP Policies

This is an example of a multihomed customer with AS 123.
BGP Route Selection Without BGP

Policies (Cont.)
The BGP routes are selected based on AS-path length.
The default BGP route selection does not always result in
optimum routing.
BGP v3.23-6
The multihomed customer is connected to two ISPs: AS 37 and AS 21. The two ISPs are
interconnected, and both are also connected to AS 40.
The customer receives all routes from both service providers, giving redundancy. The default
BGP route selection prefers the shortest AS path. If the AS-path lengths are equal, BGP prefers
the most stable route, or the route that is received from the peer with the lower router-ID.
In many cases, however, this route is not the most optimal way to reach all destinations. For
example, the bandwidth that is available to reach the ISPs has not been taken into
consideration. To change the route selection behavior, some BGP parameters must be
configured to support more complex routing policies.
3-7

This topic lists typical routing policies for multihomed BGP customers.

Multihomed customers could require a number of
routing policies, for example:
One provider is primary; the other is backup.
Traffic to direct customers of the ISPs goes direct; all other
traffic goes through the primary provider.
All traffic to a particular part of the world goes through one ISP.
Traffic toward a specific destination goes through only one of
the ISPs.
BGP v3.23-7
Depending on the circumstances, here are the different polices that a multihomed customer
might require:
One of the two ISPs can be considered the primary connection. This distinction can be the
result of available bandwidth or commercial agreements. However, although one of the
ISPs is considered the primary connection, some users may have direct connections to the
secondary ISP. Therefore, going via the primary ISP to reach users that are connected to
the secondary ISP may be suboptimal.
Destinations in one part of the world may be reached more optimally via one of the ISPs,
rather than via the other, because the two ISPs may have different infrastructures and
peering agreements with other ISPs.
It is virtually impossible to establish a routing policy that gives optimal routing to every
destination on the Internet. Optimization can be done only with the most common destinations
in mind. This situation can result in specific rules on how to reach specific destination networks
or the AS.
3-8

This topic describes the need to influence BGP route selection in a service provider
environment.
Internet traffic always flows over primary ISP.

Routes received from primary ISP should be preferred over
routes received from backup ISP.
A route selection tool is needed in BGP weights or local
preference.
BGP v3.23-8
When one of the two ISPs is designated as a primary ISP and the other as a backup, BGP
attributes must be configured as a means of influencing BGP route selection rules. If both ISP
connections terminate in one single customer router, all routes that are received from the
primary ISP can be assigned a BGP weight. A higher weight indicates a more preferred path.
However, the weight value is local to one router. The weight value is not shared between
routers. If one ISP connection terminates in one of the customer routers and the other ISP
connection terminates in another, the two customer routers must agree on which link to use.
Using local preference instead of weight can do this. All routes that are received from the
primary ISP over the primary link are assigned a local preference value, which is higher than
the default value of 100. The customer router that receives the routes from the primary ISP
completes the assignment and communicates the information to the other routers within the AS
of the customer.
The result of using either weight or local preference is that the AS of the customer reaches all
its destinations on the Internet via the primary link as long as it is available and reaches those
destinations within the AS of the secondary ISP. In the case of link failure or failures within the
network of the primary ISP, some of the routes, or all of the routes, will no longer be received
over the primary link. In that case, the AS of the customer no longer sees those destinations as
reachable over the primary link. The only remaining choice is the backup link. Therefore, the
backup link is used by the customer network only to reach destinations that are not reachable
over the primary link.
3-9
Influencing BGP Route Selection (Cont.)
Internet traffic flows over primary ISP; traffic to

customers of backup ISP goes direct.
Route selection has to be performed based on AS
numbers in the AS path.
BGP v3.23-9
In most cases, it is optimal to reach other customers connected to the backup ISP via the
backup link, compared with reaching them via the primary link.
The routing policy described previously, where routes are blindly preferred if they are received
on the primary link, can easily be modified to use the backup link for destinations in the AS of
the backup ISP. On the router, filtering tools can be configured to select routing information
that is based on the content in the AS-path attribute. Those routes, with an AS-path attribute
matching specific selection criteria, can be assigned an even higher weight or local preference.
This approach results in a routing policy that gives precedence to reaching destinations within
the AS of the primary ISP and within all autonomous systems upstream of the primary ISP over
the primary link. Destinations within the AS of the backup ISP receive precedence over the
backup link.
3-10
BGP Filters
This topic describes the need for BGP filters in a service provider environment.
BGP Filters? Transit Traffic Issue
Customers could become a transit AS for the service providers.

Requirement: Do not propagate provider routes to other
providers.
BGP v3.23-10
When BGP has selected the best path, the information is advertised by the router to all
neighboring autonomous systems, except for the session that it was received on (called BGP
split-horizon functionality, which prevents near-range routing loops). This situation causes the
customer AS to become a transit AS between the two ISPs, and should be avoided.
Most customers do not intend to create transit traffic between ISP networks. The access lines to
the ISPs are not suited to carry this volume of traffic, and the customer certainly does not want
to have its bandwidth consumed by transit traffic.
The solution to this problem is to filter outgoing information to both ISPs. Filtering of routing
information is performed based on the content of the AS-path attribute that is assigned to every
BGP route. Only routes having an AS-path attribute that indicates that they are sourced by the
AS of the customer are allowed to be sent to either of the two ISPs.
3-11
BGP Filters? Routing Update Reliability

Issue
Customers running BGP could announce any route to the

service providers.
Requirement: Service providers have to filter IP prefixes in
incoming updates.
BGP v3.23-11
Without some sort of filtering, BGP routing information that is created by the AS of the
customer can potentially be propagated all over the Internet. In this way, the customer can
inject erroneous information into the Internet routing tables.
Customers are much less experienced in avoiding these kinds of problems than are service
providers. There is much more risk of errors being introduced when a customer is assigned its
own AS and uses BGP with the ISP, as compared with the single-homed scenario in which the
ISP has sole responsibility to announce BGP routes to the rest of the Internet.
Almost all of the Internet problems that a customer can cause by improperly configuring its
BGP can be stopped by the ISP. The ISP should filter all incoming information from the
customer and accept only what is supposed to arrive. The ISP should discard anything outside
strict limits. In this way, the ISP prevents the propagation of erroneous information to the rest
of the Internet.
The ISP can maintain a list of the IP network numbers that the customer is announcing and
filter out any other route. If this approach is not possible because of the volume of those lists,
the ISP should at least be able to filter out the most obvious erroneous announcements.
Note
3-12
Private addresses, according to RFC 1918, should never be announced to the Internet.
BGP Filters? Return Traffic Issue
Customers can influence only their outgoing traffic, not the

return traffic.
Return traffic can take any pathbackup ISP
must also perform proper route selection.
BGP v3.23-12
The customer can easily define a policy about how to send outgoing IP packets on the correct
link. It is much harder to influence the neighboring AS about how to direct the IP packets
coming into the customer network.
A customer that creates a routing policy in which one of the two ISPs is always preferred may
see that the return traffic is arriving on what the customer thought was the backup link. This
situation means that the customer has configured the weight or local preference to make sure
that all outgoing traffic is leaving the customer AS over the primary link, but the backup ISP
does not have any such configuration. Therefore, return traffic enters the customer AS by using
the shortest AS path as its selection criterion.
The best way to solve this problem is for the customer to ask the backup ISP to change its
routing policy. The change should cause the backup ISP to prefer reaching the customer AS via
the AS of the primary ISP. The backup ISP must implement this change in its own AS.
Note
Sometimes the backup ISP administrator might be reluctant to change the configuration for
a single customer. In this case, the customer should use another BGP feature, the AS-path
prepending tool, to influence the selection of the primary or backup link by lengthening the
AS path of routes that are sent to the backup provider.
3-13
Summary
Summary
Some customers need redundant Internet access for their
mission-critical applications and address this need by having
two separate connections to one ISP or implementing a
multihomed configuration (connecting to two different Internet
service providers).
The multihomed customer network must exchange BGP
information with both ISP networks. Dynamic routing is
required for full redundancy, and BGP is the only protocol
available that can be used in this scenario.
An approach to multihoming that is too simple can be a source
of problems. Starting BGP sessions and announcing customer
networks to multiple ISPs by using the default behavior of BGP
may not result in optimal routing.
BGP v3.23-13
Summary (Cont.)
Depending on the circumstances, a multihomed customer
may require different polices, such as one of the two ISPs
being considered the primary connection or reaching
destinations in one part of the world more optimally via one
of the ISPs. Optimization should be done with the most
common destinations in mind, resulting in specific rules on
how to reach specific destination networks or the AS.
In BGP route selection, a routing policy may be created that
gives precedence to reaching destinations within the AS of
the primary ISP and all upstream autonomous systems over
the primary link and reaching destinations within the AS of
the backup ISP over the backup link.
When BGP has selected the best path and the information
has been propagated to all neighboring autonomous
systems, the customer AS may become a transit AS between
the two ISPs. The customer must avoid this situation by using
BGP filters.
3-14
BGP v3.23-14
Lesson 2

Overview
In network implementations that require connections to multiple Internet service providers
(ISPs), network operators typically use autonomous system (AS)-path filters to influence
Border Gateway Protocol (BGP) route selection. It is important for a network administrator to
understand the syntax of an AS-path regular expression and how string-matching operators
function when they are using AS-path regular expressions to match BGP routes.
BGP allows connectivity between multiple ISPs for redundancy and scalability. Service
providers employ AS-path filters to remedy the problems that are associated with the various
connectivity methods that are used within BGP. This lesson explains the methods that are used
to implement BGP AS-path filters.
Objectives
Upon completing this lesson, you will be able to successfully configure BGP to influence route
selection using AS-path filters in a customer scenario in which connections to multiple ISPs
must be supported. This ability includes being able to meet these objectives:
Identify network scenarios in which you must support connections to multiple ISPs and in
which AS-path filters can be used to influence route selection
Describe the function of an AS-path regular expression
Explain how string-matching operators function when you are using AS-path regular
expressions to match BGP routes
Identify where you can apply an AS-path filter when configuring a router to influence route
selection
Identify the Cisco IOS commands that are required to configure AS-path filters to influence
route selection
Identify the Cisco IOS commands that are required to monitor the operation of configured
AS-path filters

This topic identifies network scenarios that require connections to multiple ISPs where route
selection must be influenced with AS-path filters.

Several scenarios require BGP route filtering based on AS
path.
Announce only local routes to the ISPAS path needs to be
empty
Select routes based on a specific AS number in the AS path
Accept routes for specific AS only from some BGP neighbors
AS-path filters use regular expressions.
BGP v3.23-3
Several scenarios require filtering and selection of routing information, based on the content of
the AS-path attribute. Each BGP route must have an AS-path attribute. It is a well-known
mandatory attribute and must therefore be present in each BGP update.
Using selection criteria that are based on the AS-path attribute, a router can identify a set of
specific routes from the total set of routes that it receives. Those routes where the AS-path
contents match the criteria are selected. Routes that do not match the criteria are not selected.
The AS path is a sequence of numbers. Each number indicates an AS. When a route is sourced
by means of a network command in a BGP process or redistribution into a BGP process, the
AS-path attribute is created and left empty. Each time the route is advertised by an egress router
to another AS, the AS-path attribute is modified by the egress router, which prepends its AS
number to the AS-path attribute.
While a newly sourced route is still within the AS in which it was created, the AS path is
empty. When the AS has a requirement to filter out all but the routes that are local to itself
before sending them to a neighboring AS, the AS will permit sending of the routes with the
empty AS path and will deny all others.
Routers can also filter incoming routes based on their AS-path attributes. Some destination
autonomous systems should not be received from a certain neighbor. Therefore, the routes
matching that AS in the AS path can be filtered on the receiving router in case they are
accidentally sent.
3-16
Selection based on the AS path is also a tool that you can use when changing the weight or
local preference attributes for some destination autonomous systems but not for others.
When routers filter BGP updates based on the content of the AS-path attribute, they use regular
expressions. Regular expressions are commonly found in the UNIX environment and also in
some Microsoft Windows-based applications. Regular expressions are a string-matching tool.
A regular expression consists of a string of characters. Some of these characters have special
meanings, such as functioning as wildcards and operators, and some of these characters simply
mean themselves, for example, A to Z, a to z, or 0 to 9. A regular expression is said to match a
string if the ordinary characters and the applied meaning of the special operator characters can
be translated into the matched string. When a regular expression matches, the selection test is
said to be true. If it does not match, the test is false.
3-17

This topic describes the function of an AS-path regular expression.

27
31
23
317
223
AS-path converted to string
|27 31 23 317 223|

String matched with regexp
ip as-path access-list 1 permit 31
BGP v3.23-4
The AS-path attribute carried with all BGP routes in a BGP update is a very compact binary
encoding of a sequence of integer numbers; it is not a sequence that can be tested by using a
regular expression.
Cisco IOS software internally translates the binary encoding into a character string. Each AS
number in the sequence is converted into a string using decimal representation. The space
character separates each AS number in the AS-path attribute. The router applies the regular
expression test to this internally created character string.
Characters in a regular expression that are not assigned a specific operation match themselves.
The regular expression 31 matches all occurrences of the character 3 followed by the
character 1 in the AS path. In this example, 31 matches at two occurrences. One
occurrence is sufficient to make the test true. No occurrence means that the test failed.
3-18
String Matching
This topic describes how string matching functions when you are using AS-path regular
expressions to match BGP routes.
String Matching? Regular Expressions

A string of characters in a regular expression matches any
equivalent substring in the AS path.
How many times does 31 match?

Answer:
BGP v3.23-5
The regular expression 31 will match any occurrence of 3 followed by 1 regardless of the
characters immediately preceding the 3 and immediately following the 1. Therefore, 31
will match an occurrence of 3 and 1 in the middle of an AS number.
The regular expression 31 matches the AS-path string 213 317 2316 31 three times,
because 31 matches a part of 317, 2316, and 31.
3-19
String Matching? Alternatives

Expression expr1|expr2 matches the string if either
subexpression matches the string.
How many times does 21|31 match?

Answer:
BGP v3.23-6
The character | (vertical bar) has a special meaning. It is an operator that means or. The
regular expression 21|31 matches the sequence of 2 followed by 1 or the sequence of 3
followed by 1. Therefore, this sample regular expression will match a two-character
sequence: the 21 or the 31.
The regular expression 21|31 matches the AS-path string 213 317 2316 31 four times,
because 21 matches a part of 213 and 31 matches a part of both 317 and 2316 and
also 31.
3-20
String Matching? Ranges and Wildcard

Characters
A range of characters matches any single character in the
range.
Examples: [1234] or [1-4]
Dot (.) matches any single character
How many times does [1-3].[34] match?

Answer:

BGP v3.23-7
The pair of brackets [ and ] has a special meaning. Brackets surround a set of characters of
which any one matches. The set of characters is either expressed as the list of the matches (for
example, [1234]) or the sequence with the starting character, a hyphen, and the ending
character (for example, [1-4]). Both examples match one single character, which must be any
one in the set of the four characters 1, 2, 3, and 4.
The character . (a dot) matches any single character. Small regular expressions can be
combined into a larger expression. Such a combination is matching if all of the parts match one
after the other. The sample regular expression [1-3].[34] matches a sequence of three
characters, of which the first must be either 1, 2, or 3, the second character can be any
character, and the third must be either 3 or 4.
Note
The space character delimiting two AS numbers is just a character. The dot (.) for example,
matches this character.
The regular expression [1-3].[34] matches the AS-path string 213 317 2316 31 twice.
Initially, it matches 213. The leading [1-3] matches the leading 2. The dot, which
matches any character, matches the 1, and [34] matches the trailing 3. Secondly, the
regular expression also matches in 213 317 2316 31. This is a little harder to see, because the
dot (.) matches the space character between 213 and 317.
3-21
String Matching? Matching Delimiters

^
$
_
Matches beginning of string

Matches end of string
Matches any delimiter (beginning, end, white
space, tab, comma)
How many times does ^21, 31$, _31_ match?

Answer:
BGP v3.23-8
A character string must have a start and an end. The character with the special meaning ^
matches the beginning of a string. Because all strings have a beginning, the ^ character
matches all strings. However, the ^ character is used to position the part of the regular
expression that follows. The character following the ^ character must be the first character of
the string; otherwise, that character would not match the beginning of the string.
The special character $ is used analogously, but it means the end of the string. The character
preceding the $ must be the last character in the string; otherwise, the $ does not match the
end of the string.
The underscore (_) matches any delimiter. The space character between two AS numbers is
an example of a delimiter. The beginning of the string and the end of the string are also
considered delimiters. Other delimiters are the tab and the comma (,). The underscore (_) is
used to ensure that the desired AS number is found in an AS-path string but not as part of some
other AS number. For example, the regular expression 31 will match the AS number string
317, but the regular expression _31_ will not. Both 31 and _31_ will match the AS
number string 31.
The regular expression ^21 can match the AS-path string 213 317 218 31 731 only one
time because there is only one beginning of the string. The regular expression ^21 matches
only if the string starts with the sequence 21, which it does.
The regular expression 31$ can match the AS-path string 213 317 218 31 731 only one
time because there is only one end of the string. The regular expression 31$ matches only if
the string ends with the sequence 31, which it does.
The regular expression _31_ can, in theory, match an AS-path string several times. However,
in this case, when matched against the string 213 317 218 31 731, the regular expression
_31_ matches only the AS number 31 in the AS path.
3-22
String Matching? Grouping

Parentheses can be used to group smaller regular
expressions into larger expressions.
How many times does (213|218)_31 match?

Answer:
BGP v3.23-9
Complicated expressions must sometimes be grouped with parentheses, (and). This feature
can be useful when you are searching for a sequence of two or more AS numbers of which the
first can match any of the specific autonomous systems (in this example, 213 or 218), but
the last must be a specific AS (31 in this example). If the parentheses were not used here, the
expression would match either the single AS 213 or the sequence of the two (218 31).
The regular expression (213|218)_31 matches the AS-path string 213 317 1218 316 31
twice. The first match is 213 317 1218 316 31; the second match is 213 317 1218 316 31.
3-23
String Matching? Special Characters

\
To use the special characters as single-character

patterns, remove the special meaning by preceding each
character with a backslash (\).
How do you match AS 213 in the beginning of the

string?
Answer:
BGP v3.23-10
Sometimes the target string that you are trying to match with a regular expression contains
some of the characters that also have special meanings in the regular expression. To match
these characters in the target string, use the backslash (\) together with the character in the
regular expression.
Note
3-24
This type of regular expression syntax is used for matching AS-path strings inside a BGP
confederation. A confederation is used to eliminate the scaling problem of full-mesh Internal
Border Gateway Protocol (IBGP) by splitting the AS into smaller regional autonomous
systems. The example shows that 213 and 317 were part of a confederation by its use of (
and ). Confederations are explained further in the Scaling Service Provider Networks
module.
String Matching? Repeating Operators

*
?
+
Matches zero or more atoms

Matches zero or one atom
Matches one or more atoms
An atom is a single character or a grouping.
How do you match AS sequences 23 45 and

23 78 45 in a single regular expression?
Answer:
BGP v3.23-11
The special characters, star (asterisk), *, question mark, ?, and plus, +, all apply
repetition of the expression that immediately precedes them.
The star (asterisk), *, means that the expression that immediately precedes it is repeated zero
or more times. This means that the expression may not be there, but it may also be there any
number of times. The expression 1* will match a sequence of no characters or a sequence of
any number of the character 1.
A question mark (?) means that the expression that immediately precedes it is repeated zero
or one time. This means that the expression may not be there, but it may also be there once. The
expression 1? will match a sequence of no characters or the single character 1.
The plus sign (+) means that the expression that immediately precedes it is repeated one or
more times. This means that the expression must be there at least once. The expression 1+
will match a sequence of one or more of the character 1.
3-25
Example: String Matching

This example shows a sample of regular expressions.
String Matching? Sample Regular

Expressions
_100_
Going through AS 100
^100$
Directly connected to AS 100
_100$
Originated in AS 100
^100_.
Networks behind AS 100
^ [0-9]+$
AS paths one AS long
^([0-9]+)(_\1)*$
Prepending performed in neighboring

originating AS
^$
Networks originated in local AS
.*
Matches everything
BGP v3.23-12
Regular expressions can be arbitrarily complex. However, most searching is accomplished

using regular expressions similar to those in these examples:
If you are searching for all routes that have AS 100 in their AS paths, the regular
expression to use is _100_.
If you are searching for all routes that are sourced in your directly connected neighboring
AS 100, the regular expression to use is ^100$. Use an expression with both a carat (^)
and dollar sign ($) present when you are searching for an exact match.
If you are searching for all routes that are sourced in AS 100, but that AS is not necessarily
a directly connected neighboring AS, the regular expression to use is _100$. The dollar
sign ($) indicates that the AS path must end with AS 100. This is an indication that the
route was sourced in AS 100. The underscore (_) is used to make sure that it is AS 100 at
the end of the string and not, for example, AS 2100.
If you are searching for all the routes that are reachable behind AS 100, the regular
expression to use is ^100_.. The carat (^) indicates that the AS path must start with AS
100. The underscore (_) is used to make sure that this number is not matching with, for
example, AS 1001. The dot (.) is used to indicate that the AS path does not end with AS
100, and that there must be something following AS 100.
If you are searching for all routes that are sourced in any AS directly neighboring your AS,
the regular expression to use is ^[0-9]+$. The [0-9] part means any digit. The plus sign
(+) repetition character means one or more times. Therefore, the combination [0-9]+
means a sequence of one or more of digits. The carat (^) and dollar sign ($) mean the
beginning and the end of the string. Therefore, the string may consist only of a sequence of
one or more digits.
3-26
If you are searching for all routes that are sourced in any AS directly neighboring your AS,
and possibly performing AS-path prepending (multiplication of a directly connected AS
number), the regular expression to use is ^([0-9]+)(_\1)*$. The expression in the first set
of parentheses matches any AS number. The parentheses store the value of the matched
AS, and this value is then recalled by the second part of the regular expression, including a
variable. The variable \1 is put into parentheses for the purpose of the multiplier operator
*, meaning that this part can match any number of successive occurrences of the same
AS number that was matched by the [0-9]+ expression. For example, this regular
expression matches AS paths 99 99 99, 200, 101 101, or 5 5 5 5 5, but it does not
match the AS path 101 99.
The combination ^$ means an empty string and is used when you are searching for all
routes that are sourced in the local AS.
Sometimes a search is made to select a few specific routes and do something special with
them, while the rest of the routes will be handled in a different way. To search for all
routes, regardless of the content of their AS-path attribute, use the regular expression .*.
The dot (.) matches any single character. The repetition character, star (asterisk), *,
means that the match should be repeated zero or more times. Thus, the combination (.*)
matches any string.
3-27
Commonly Used Characters in Expressions

.
Any single character, including a space
Zero or more sequence of pattern
One or more sequence of pattern
Zero or one occurrence of pattern
Beginning of string
End of string
Match any delimiter (including beginning, end, space,

tab, comma)
Remove special meaning of character that follows
[]
Match one character in a range
Logical OR
BGP v3.23-13
The figure lists the most commonly used characters in expressions.
3-28

This topic identifies where you can apply an AS-path filter when configuring a router to
influence route selection.
BGP v3.23-14
AS-path filters that are configured on a router select those routes that are allowed. Routes that
are selected behave as described here:
The selected routes enter the local BGP table when the selection is applied on the incoming
routes from a neighbor; routes that are not selected are silently dropped.
The selected routes are transmitted to the neighbor when the selection is applied on the
outgoing routes to the neighbor; routes that are not selected are used locally but are never
sent to the neighbor.
3-29

This topic identifies the commands that you can use to configure AS-path filters to influence
route selection.
Configures AS-path access-list
Configures inbound or outbound AS-path filter for specified

BGP neighbor
BGP v3.23-15
An AS-path filter is created by an AS-path access-list. This access-list is applied to a set of

routes from which to select a subset. Routes that are permitted by the access-list are included in
the subset, and those that are denied are not included. As in all access-lists, the candidate to be
permitted or denied membership in the subset is tested against all the lines in the access-list, in
the order in which the list is configured. The first match indicates permit or deny, as
specified. If the end of the access-list is reached without any explicit match, the candidate is
implicitly denied.
The test by the AS-path access-list is performed by using regular expressions that are applied
on the AS-path attribute of the route.
The access-list can, for example, be applied on the routes received from, or those sent to, a
specific BGP neighbor.
ip as-path access-list
To define a BGP AS-path access-list, use the ip as-path access-list global configuration
command.
ip as-path access-list access-list-number {permit | deny} as-regular-expression
To disable use of the access-list, use the no form of this command.
no ip as-path access-list access-list-number {permit | deny} as-regular-expression
3-30
Syntax Description
Parameter
Description
Integer from 1 to 199 that indicates the regular expression

access-list number.
Permits access for matching conditions.
Denies access to matching conditions.
AS in the access-list using a regular expression (See the

Regular Expressions appendix in the Cisco IOS Dial Services
Command Reference for information about forming regular
expressions.)
neighbor filter-list
To set up a BGP filter, use the neighbor filter-list router configuration command.
neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}
no neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}
Syntax Description
Parameter
Description
Number of an AS path access-list. Define this access-list with the

ip as-path access-list command.
Access-list to incoming routes.
Access-list to outgoing routes.
3-31
Configuring BGP AS-Path Filters (Cont.)
BGP v3.23-16
Multihomed customers do not want to act as a transit AS between their service providers. The
customer avoids this situation by not transmitting all its routes to its service providers. The
service providers send IP packets to the customer only if the IP packets have destination
addresses that match one of the routes that the customer has sent by BGP to the service
provider. By making sure that only locally sourced routes are sent, the customer avoids
receiving IP packets for destinations outside its own AS.
Within the customer AS, the locally sourced routes have empty AS paths. The empty string is
matched by the regular expression ^$. The command ip as-path access-list 1 permits only
the routes that are locally sourced and implicitly denies the rest. By applying this filter-list on
outgoing information to all neighbors, the customer will announce local routes only.
3-32

This topic identifies the Cisco IOS commands that are required to monitor the operation of
configured AS-path filters.
Displays one or all filter-lists
Displays all routes in the BGP table permitted by the

specified AS-path access-list
Displays all routes in the BGP table matching regularexpression in one or all filter-lists
BGP v3.23-17
The Cisco IOS commands that are most frequently used to monitor the operation of configured
AS-path filters include show ip as-path-access-list, show ip bgp regexp, and show ip bgp
filter-list.
3-33
The show ip as-path-access-list Command

Displaying configured filters:
BGP v3.23-18
The show ip as-path-access-list command displays a specific access-list or all AS-path accesslists in the router.
3-34
The show ip bgp regexp Command

Routes matched by an expression:
BGP v3.23-19
Because regular expressions sometimes get complex, thorough testing of them is required. The
show ip bgp regexp command displays all routes currently in the BGP table that have an
AS-path attribute that matches the typed-in regular expression. Use the show ip bgp regexp
command to test a regular expression that is typed in on the command line. The result is a
printout on the screen of all those routes currently in the BGP table that had an AS-path
attribute matching the typed-in regular expression.
In the example figure (which shows BGP confederations, a scalability feature), you wish to find
all BGP confederation routes from AS number 65002. To search for this character in the
beginning of the string, use the character \, the backslash. The regular expression ^\(65002
matches all the routes that are received from the intra-confederation AS number 65002.
show ip bgp regexp

To display routes that match an AS-path regular expression, use the show ip bgp regexp
privileged EXEC command.
show ip bgp regexp regular-expression
Syntax Description
Parameter
Description
Regular expression to match the BGP AS paths
3-35
The show ip bgp filter-list Command

Routes matched by a filter-list:
BGP v3.23-20
An AS-path access-list is even more complex because it is a combination of several regular

expressions. There is one expression on each access-list line. Use the show ip bgp filter-list
command to test the entire AS-path access-list. The result is a printout on the screen of all the
routes currently in the BGP table that had an AS-path attribute permitted by the access-list.
The AS-path access-list number 25 in the example figure consists of one single line. It permits
the routes that have an AS-path attribute containing the AS number 42 somewhere in their AS
paths. All other routes are implicitly denied. The show ip bgp filter-list command displays all
the routes currently in the BGP table that are permitted by AS-path access-list 25. As a result of
configuring BGP confederations, the AS path contains some AS numbers enclosed in
parentheses. BGP confederations and their usage are explained in the Scaling Service Provider
Networks module.
show ip bgp filter-list

To display routes that conform to a specified filter-list, use the show ip bgp filter-list
privileged EXEC command.
show ip bgp filter-list access-list-number
Syntax Description
3-36
Parameter
Description
Integer from 1 to 199 that indicates the regular expression

access-list number
Summary
Summary
Several scenarios require BGP route filtering based on AS
path, including announcing only local routes to the ISP (AS
path needs to be empty), selecting routes based on a specific
AS number in the AS path, and accepting routes for a
specific AS only from some BGP neighbors. By applying
specific selection criteria to the contents of the AS-path
attribute, routers can select a subset of routes from the total
set of routes that are received.
Cisco IOS software internally translates the AS-path
encoding, which is carried with all BGP routes into a
character string. This string is then tested against the regular
expression.
String matching operates when you are using AS-path
regular expressions to match BGP routes.
BGP v3.23-21
Summary (Cont.)
You can use AS-path filters to select those routes that will be
allowed.
An AS-path filter is created by an AS-path access-list, which
is applied to a set of routes from which to select a subset.
The ip as-path access-list global configuration command
defines a BGP AS-path access-list, and the neighbor filter-list
router configuration command sets up a BGP filter.
There are a number of Cisco IOS commands that are required
to monitor the operation of configured AS-path filters,
including show ip as-path-access-list, show ip bgp regexp, and
show ip bgp filter-list.
BGP v3.23-22
3-37
3-38
Lesson 3

Overview
Where multiple paths between a customer and an Internet service provider (ISP) exist, there is a
requirement to filter certain information during Border Gateway Protocol (BGP) updates to
influence route selection or to enforce an administrative policy. To meet this requirement, you
must use filters. Using prefix-lists is typically easier than using standard IP access-lists and
provides performance benefits. It is important to understand the commands to apply filtering of
inbound or outbound updates with prefix-lists and where they should be applied.
This lesson discusses the requirement for using prefix-based filters in customer
implementations where connections to multiple ISPs must be supported and describes the
advantages of prefix-lists over IP access-lists. The commands to apply filtering of inbound or
outbound updates with prefix-lists and to configure prefix-list filters are discussed, and also
where network administrators should apply them.
Objectives
selection using prefix-list filters in a customer scenario in which connections to multiple ISPs
must be supported. This ability includes being able to meet these objectives:
Identify the requirement for prefix-based filters in network implementations where multiple
connections between a customer and ISPs exist
List the advantages of prefix-lists versus IP access-lists
Identify the Cisco IOS command that is required to configure prefix-list filters
Describe where you can implement prefix-lists in a BGP network
Identify the Cisco IOS commands that are required to apply filtering of inbound or
outbound updates with prefix-lists
Identify the Cisco IOS commands that are required to modify configured prefix-list filters
Identify the Cisco IOS commands that are required to monitor the operation of configured
prefix-list filters

This topic identifies the requirement for prefix-based filters in network implementations where
multiple connections between a customer and ISPs exist.
Service providers have to filter customer updates to ensure that

the customers announce only their assigned address space.
BGP v3.23-3
Customers with multihomed networks are responsible for announcing their own networks using
BGP. Typically, customers are not as experienced with BGP as service providers, and therefore
problems are more likely to occur. A service provider with a multihomed customer must take
precautions not to accept, use, or forward any erroneous routing information that is received
from the customer.
The customer is assigned a set of IP network numbers that it should announce. If the customer
announces any additional networks, something is wrong. The customer may have forgotten not
to act as a transit autonomous system (AS) and may have started propagating routes that it has
received from the other service provider. Or, the customer may have accidentally started to
announce its private address space, which the customer may use for address links, loopback
interfaces, or other devices that should never access the Internet.
To avoid problems, the service provider can apply an IP prefix filter on the incoming
information from the customer. The service provider will accept only network numbers
permitted by an access-list or prefix-list.
3-40

This topic lists the advantages of prefix-lists versus IP access-lists.

Traditional prefix filters
Traditional IP prefix filters were implemented with IP accesslists configured with the distribute-list command.
IP access-lists used as route filters have several drawbacks:
Subnet mask cannot be easily matched.
Access-lists are evaluated sequentially for every IP prefix in the
routing update.
Access-lists are hard to edit.
Extended access-lists can be cumbersome to configure.
BGP v3.23-4
Traditionally, the filtering of IP network numbers has been accomplished using an access-list.
The access-list is then bound to either the incoming or outgoing information of a neighbor by
the neighbor distribute-list command. A BGP update about a network number that is
permitted by the access-list will be accepted, and those denied will be dropped.
However, standard access-lists do not support the testing of the subnet masks. If the access-list
permits 10.0.0.0/16, it would also permit 10.0.0.0/8.
Extended access-lists can do testing on both an IP network number and a subnet mask, but the
syntax is cumbersome.
Finally, access-lists are difficult to edit. The router automatically adds new access-list entries to
the end of the list. Because the router evaluates the list sequentially, and the first match results
in a permit or deny statement, the order of the lines in the access-list is of utmost
importance. The inability to add a line in the middle of a list has been an administrative burden.
3-41
Prefix-Lists vs. IP Access-Lists (Cont.)

Prefix-lists
New route-filtering mechanism
Significant performance improvement on long filters
Inside Cisco IOS software, the prefix-list is a tree structure and is
not scanned sequentially.
Support for incremental updates

Individual entries in prefix-lists can be inserted or deleted.
More user-friendly CLI

The CLI for using access-lists to filter BGP updates is difficult to
understand and use, because it uses the packet-filtering format.
Greater flexibility; can match on subnet masks
BGP v3.23-5
The ip prefix-list configuration command has several benefits compared to using the accesslist command. The intended use of prefix-lists is limited to route filtering, whereas access-lists
were initially intended for packet filtering, which was then extended to filter routes.
The prefix-list is internally transformed into a tree structure, with each branching of the tree
serving as a test. Cisco IOS software determines a verdict of either permit or deny much
faster this way, compared to sequentially interpreting an access-list.
The configuration command-line interface (CLI) that you use when configuring the ip prefixlist command provides the ability to assign a line number to each line of the prefix-list. The
router uses this number to sort the entries in the prefix-list. If the lines are initially assigned line
numbers, with some spacing in between them, administrators can insert additional lines at a
later time. Individual lines can also be removed without removing the entire list.
Routers match network numbers in a routing update against the prefix-list, using as many bits
as indicated. For example, a prefix-list can be specified to be 10.0.0.0/16, which will match
10.0.0.0 routes but not 10.1.0.0 routes.
Optionally, the prefix-list can also specify the size of the subnet mask. In addition, the prefixlist can indicate that the subnet mask must be in a specified range.
3-42
Prefix-Lists vs. IP Access-Lists (Cont.)

Key access-list features are preserved.
Filtering using permit or deny
Order dependency (first match wins)
Security-focused: no match means deny
The matching mechanism has changed.

Matches routes in a part of address space with subnet
mask longer or shorter than a set number
BGP v3.23-6
The prefix-list shares several similarities with the access-list. It can consist of any number of
lines, each of which indicates a test and a result. The router can interpret the lines in the
specified order, although this process is optimized in the Cisco IOS software. When a router
evaluates a route against the prefix-list, the first line that matches results in either a permit or
deny. If none of the lines in the list match, the result is implicitly deny.
Testing is done using prefixes. The indicated number of bits in the prefix is compared with the
same number of bits in the network number in the update. If the bits match, testing continues
with an examination of the number of bits set in the subnet mask. The prefix-list line can
indicate a range within which the number must fall to pass the test. If no range is indicated, the
subnet mask must match the prefix size.
3-43
This topic identifies the Cisco IOS command that is required to configure prefix-list filters.
Prefix-lists have names and sequence numbers (like routemaps).

An entry with no le or ge parameter matches exactly the
specified prefix.
An entry with an le or ge parameter matches any route within the
address space of address/prefix with prefix longer or equal to ge
value and shorter than or equal to le value.
BGP v3.23-7
ip prefix-list
To create an entry in a prefix-list, use the ip prefix-list global configuration command.
ip prefix-list list-name [seq seq-value] {permit | deny} network/len [ge ge-value] [le levalue]
To delete the entry, use the no form of this command.
no ip prefix-list list-name [seq seq-value] {permit | deny} network/len [ge ge-value] [le
le-value]
3-44
Syntax Description
Parameter
Description
Name of a prefix
(Optional) Applies the sequence number to the prefix
(Optional) Specifies the sequence number for the prefix
Permits access for matching conditions
Denies access to matching conditions
(Mandatory) The network number and length (in bits) of the

subnet mask
(Optional) Applies the ge-value to the range specified
(Optional) Specifies the lesser value of a range (the "from" portion

of the range description)
(Optional) Applies the le-value to the range specified
(Optional) Specifies the greater value of a range (the "to" portion

of the range description)
When multiple entries of a prefix-list match a given prefix, the sequence number of a prefix-list
entry identifies the entry with the lowest sequence number. In this case, the entry with the
smallest sequence number is considered to be the real match.
Note
You can specify sequence values for prefix-list entries in any increments that you want (the
automatically generated numbers are increased in units of 5). If you specify the sequence
values in increments of 1, you will not be able to insert additional entries into the prefix-list. If
you choose very large increments, you could run out of sequence values.
You can use the parameters ge and le to specify the range of the prefix length to be matched for
prefixes that are more specific than network/len. The exact match is assumed when neither ge
nor le is specified. The range is assumed to be from ge-value to 32 only if the ge attribute is
specified. The range is assumed to be from len to le-value only if the le attribute is specified.
3-45
Configuring Prefix-Lists (Cont.)

Prefix-list matching rules
Prefix-list entries with no ge or le option match only the
specified route.
Similar to IP access-lists with no wildcard bits
Matching also considers subnet mask
Which of the following routes will be matched by:

X X
BGP v3.23-8
Prefix-list entries without the ge or le option match only the route with the specified IP address
and subnet mask. In the example here, the prefix-list entry permit 192.168.0.0/16 will not
match the route 192.168.2.0/24 because of the mismatch in the IP address. It will also not
match the route 192.168.0.0/20 because of the mismatch in the subnet mask.
3-46

A prefix-list entry with ge or le option matches any prefix within
specified address space where the subnet mask falls within
specified limits.
Which of the following routes will be matched by:

X
BGP v3.23-9
Prefix-list entries with the ge or le option specified match any prefix within the address space
that is specified by the network/len parameter, as long as the subnet mask length of the route
falls within the range that is specified by the le and ge parameters.
In the first example in the figure, the route 192.168.2.0/24 is not matched by prefix-list entry
permit 192.168.0.0/16 even though the IP address falls within the specified address range,
because the subnet mask is too long.
In the second example, the route 192.168.0.0/16 is not matched by prefix-list entry permit
192.168.0.0/18 because the subnet mask is too short.
3-47
Example: Configuring Prefix-Lists

The figure contains some commonly used prefix-list examples.

What will be matched by:
a)
b)
c)
d)
e)
ip prefix-list A permit 0.0.0.0/0 ge 32

ip prefix-list B permit 128.0.0.0/2 ge 17
ip prefix-list C permit 0.0.0.0/0 le 32
ip prefix-list D permit 0.0.0.0/0
ip prefix-list E permit 0.0.0.0/1 le 24
a)
b)
c)
d)
e)
All host routes

Any subnet in class B address space
All routes
Just the default route
Any prefix in class A address space covering at least 256
addresses
BGP v3.23-10
In the figure, all host routes will be matched by prefix-list A permit 0.0.0./0 ge 32, while any
subnet in a class B address space will be matched by prefix-list B permit 128.0.0.0/2 ge 17.
Prefix-list C permit 0.0.0.0/0 le 32 will match all routes, but only the default route will be
matched by prefix-list D permit 0.0.0.0/0. Finally, any prefix in a class A address space that
covers at least 256 addresses will be matched to prefix-list E permit 0.0.0.0/1 le 24.
3-48

This topic describes where you can implement prefix-lists in a BGP network.
BGP v3.23-11
You can optionally apply filter-lists and prefix-lists on either incoming or outgoing neighbors
in any combination. Both the incoming prefix-list and the incoming filter-list must permit the
routes that are received from a neighbor before they are accepted into the BGP table. Outgoing
routes must pass both the outgoing filter-list and the outgoing prefix-list before being
transmitted to the neighbor.
When a router is configured to redistribute routing information from an Interior Gateway
Protocol (IGP) into BGP, the routes must successfully pass any prefix-list or access-list that is
applied to the redistribution before a route is injected into the BGP table.
3-49
Implementing Prefix-Lists in the BGP Process

This topic identifies the Cisco IOS commands that are required to apply prefix-lists for filtering
inbound or outbound updates.
Implementing Prefix-Lists in the

BGP Process
Filters inbound or outbound BGP routing updates for a

configured neighbor session
Filters routes redistributed from specified routing process into

BGP
BGP v3.23-12
You can use prefix-lists to filter incoming or outgoing BGP updates to neighbors. You can also
use prefix-lists to filter routes that are being redistributed into the BGP process from other
routing protocols.
3-50
neighbor prefix-list
To distribute BGP neighbor information as specified in a prefix-list, use the neighbor prefixlist router configuration command.
neighbor {ip-address | peer-group-name} prefix-list prefix-listname {in | out}
no neighbor {ip-address | peer-group-name} prefix-list prefix-listname {in | out}
Syntax Description
Parameter
Description
Name of a prefix-list
Access-list is applied to incoming advertisements to that neighbor
Access-list is applied to outgoing advertisements from that

neighbor
Note
A BGP peer group is a group of BGP neighbors with the same update policies. Route-maps,
distribute-lists, filter-lists, and so on usually set update policies. Instead of defining the same
policies for each separate neighbor, a peer group name is configured on the router, and
these policies are assigned to the peer group. BGP peer groups are discussed in a later
module.
3-51
distribute-list out
To suppress networks from being advertised in updates, use the distribute-list out router
distribute-list {access-list-number | name | prefix-list prefix-listname} out [interfacename | routing-process | autonomous-system-number]
no distribute-list {access-list-number | name | prefix-list prefix-listname} out [interfacename | routing-process | autonomous-system-number]
Syntax Description
Parameter
Description
Standard IP access-list number or name.
Name of a prefix-list.
The list defines which networks are to be received and which are
to be suppressed in routing updates.
The list defines which networks are to be received and which are
to be suppressed in routing updates, based upon matching of the
network prefix to the prefixes in the list.
Applies the access-list to outgoing routing updates.
(Optional) Name of a particular interface.
(Optional) Name of a particular routing process, or the keyword

static or connected.
(Optional) AS number.
Note
3-52
Although you can use the neighbor prefix-list router configuration command as an
alternative to the neighbor distribute-list command, do not use both the neighbor prefixlist and neighbor distribute-list command filtering for the same neighbor in any given
direction. These two commands are mutually exclusive, and only one command (neighbor
prefix-list or neighbor distribute-list) can be applied for each inbound or outbound
direction.
Example: Filtering Customer Prefixes

The figure illustrates filtering customer prefixes.
Prefix-List Example:
Filtering Customer Prefixes
Requirement: The customer will announce
prefixes only from assigned address space
(172.16.0.0/16), with subnet masks no longer
than /24.
BGP v3.23-13
In this example, a multihomed customer has been assigned the address space 172.16.0.0/16.
The customer may subnet this address space but may not announce subnets smaller than a
subnet mask of 255.255.255.0. Larger subnets are accepted. If the customer has subnetted the
network into smaller subnets, it must summarize the routing information about those subnets
into at least /24 prefixes before announcing them.
The primary ISP implements a prefix-list named Cust-A to perform the filtering of incoming
information from the multihomed customer. The prefix-list permits all routes that are received
from the customer that have 172.16 in the first 16 bits and have a subnet mask of 24 bits or less.
Any other routes from the customer are denied and silently ignored.
3-53
Example: Filtering Peer Prefixes

The figure illustrates filtering peer prefixes.
Prefix-List Example:
Filtering Peer Prefixes
Requirement: The ISP will not accept routes
with subnet masks longer than /24; subnet
masks from class B address space will be no
longer than /20.
BGP v3.23-14
In this example, the primary ISP will not accept any route from the customer that indicates a
subnet smaller than a 255.255.255.0 subnet mask. The class B network, however, must not be
subnetted into subnets smaller than a 255.255.240.0 subnet mask.
The primary ISP implements this route by using a prefix-list named Peer. The first line in the
prefix-list checks whether it is a class B network. Remember that a class B address always has
the binary sequence 10 as the first 2 bits in the first byte. The second line matches any prefix.
When the primary ISP receives a route from the customer, it compares the route with both
lines. If the route is a class B network, both lines match. Testing continues with checking the
subnet mask. An upper bound is explicitly indicated, giving a maximum prefix length of 20
bits.
If the received route is not a class B network, only the second line matches. In this case, the
subnet mask length must be greater than or equal to 0 and less than or equal to 24, providing a
route less explicit than a /24 prefix.
3-54
This topic identifies the Cisco IOS commands that are required to modify configured prefix-list
filters.
Displays the prefix-list and the sequence numbers
Erases the line with the specified sequence number from the
prefix-list
Inserts the line into the prefix-list at the specified point
BGP v3.23-15
Lines in a prefix-list are assigned sequence numbers. These assignments significantly improve
the manageability of the list. These sequence number assignments provide the opportunity to
remove a specific line, and, if spacing between the sequence numbers allows, they provide the
ability to insert a line between two existing lines.
To display a currently configured prefix-list and its sequence numbers, use the show ip prefixlist command with the detail keyword.
You can specify sequence values for prefix-list entries in any increments that you want (the
automatically generated numbers are increased in units of 5). If you specify the sequence values
in increments of 1, you will not be able to insert additional entries into the prefix-list. If you
choose very large increments, you could run out of sequence values.
3-55
This topic lists the Cisco IOS commands that are required to monitor the operation of
configured prefix-list filters.
To display information about a prefix-list or prefix-list entries
Displays all routes in the BGP table matching the prefix-list

Used for easier monitoring of a desired network prefix group in
the BGP table
BGP v3.23-16
show ip prefix-list
To display information about a prefix-list or prefix-list entries, use the show ip prefix-list
EXEC command.
show ip prefix-list [detail | summary] name [network/len] [seq seq-num] [longer] [firstmatch]
Syntax Description
3-56
Parameter
Description
(Optional) Displays detailed or summarized information about all

prefix-lists
(Optional) The name of a specific prefix-list
(Optional) The network number and length (in bits) of the network
mask
(Optional) Applies the sequence number to the prefix-list entry
The sequence number of the prefix
Displays all entries of a prefix that are more specific than the
given network/len
Displays the entry of a prefix that matches the given network/len
The show ip bgp prefix-list command displays selected routes from a BGP routing table based
on the contents of a prefix-list. Use this command for selective filtering of BGP table output on
Cisco IOS devices on the basis of network prefix groups.
To perform prefix-list-based BGP table filtering, follow these steps:
Step 1
Configure a prefix-list that permits ranges of networks meant to be displayed in the

BGP table output.
Step 2
Include a reference to a configured prefix-list in the show ip bgp prefix-list

command.
Note
The support for prefix-list BGP table filtering was added in Cisco IOS Software Release
12.2(11)T and 12.0(14)ST.
3-57
Monitoring Prefix-Lists (Cont.)
BGP v3.23-17
In this example, the show ip prefix-list command has been issued with the detail keyword. The
output of the command displays detailed information about configured prefix-lists, including
sequence numbers, the prefix-list entries, and the number of times that each entry has been
matched by a corresponding prefix.
3-58
Monitoring Prefix-Lists (Cont.)
BGP v3.23-18
This example shows a simple prefix-list-based filtering of the BGP table. The prefix-list filter
permits all networks with the first octet equal to 10 and any length of a subnet mask (le 32). In
the show ip bgp prefix-list command output, only the networks permitted by the prefix-list
filter are displayed.
3-59
Summary
Summary
Customers with multihomed networks are responsible for
announcing their own networks using BGP, and service
providers with multihomed customers must take precautions
not to accept, use, or forward any erroneous routing
information that is received from their customers.
Prefix-lists have a number of advantages over access-lists,
including faster permit or deny determinations and
easier CLI editing.
Prefix-lists are configured using the ip prefix-list global
Filter-lists and prefix-lists can be optionally applied on either
incoming or outgoing neighbors in any combination.
BGP v3.23-19
Summary (Cont.)
Prefix-lists can filter incoming or outgoing BGP updates to
neighbors and filter routes that are being redistributed into
the BGP process from other routing protocols. Use the
neighbor prefix-list router configuration command to distribute
BGP neighbor information as specified in a prefix-list.
Certain Cisco IOS commands (such as the show ip prefix-list
command) are used to modify configured prefix-list filters.
To display or monitor statistics about a prefix-list or prefixlist entries, you can use the show ip prefix-list EXEC
command.
3-60
BGP v3.23-20
Lesson 4
Using Outbound Route

Filtering
Overview
An outbound route filter (ORF) is an additional mechanism that is used to minimize the number
of updates that are requested from a neighbor, which reduces link bandwidth consumption and
CPU use when a router requests a route refresh. An ORF also allows filtering of information
that external networks should not receive (such as RFC 1918 information). Understanding how
to monitor outbound route filtering capabilities is also important because a Border Gateway
Protocol (BGP) neighbor that supports specific ORF capabilities will report those capabilities
to a monitoring neighbor and can then send a filter of the supported type to the neighbor.
This lesson discusses the function of outbound route filtering in a BGP network. The format
and function of ORF messages are discussed, as well as the commands that enable ORF
negotiations and the activation of an ORF prefix-list. The commands that are used to trigger a
route refresh are also detailed. Finally, there is a discussion on how to monitor the operations of
a configured ORF in a BGP network.
Objectives
Upon completing this lesson, you will be able to use outbound route filtering to minimize the
impact of BGP routing updates on router resources in an operational BGP network. This ability
Describe the function of outbound route filtering in a BGP network
Describe the function of prefix-based outbound route filtering
Describe the format and function of an ORF message
Identify the Cisco IOS command that is required to enable ORF negotiations and activate
an ORF prefix-list
Identify the Cisco IOS command that is used to trigger a route refresh
Identify the Cisco IOS command that is required to monitor the operation of a configured
ORF

This topic describes the function of outbound route filtering in a BGP network.

The purpose of outbound route filtering is to reduce the
amount of BGP traffic and CPU use needed to process
routing updates.
Routers exchange inbound filter configurations, which are
used as outbound filters on neighboring routers.
Filters are described in ORF entries.
ORF entries are part of the route refresh message.
BGP v3.23-3
Outbound route filtering is a prefix-based BGP feature that is enabled through the
advertisement of ORF capabilities to peer routers integrated in Cisco IOS Software Release
12.2(4)T. The advertisement of the ORF capability indicates that a BGP-speaking router will
accept a prefix-list from a neighbor and apply the prefix-list to locally configured ORFs (if any
exist). When this capability is enabled, the BGP speaker can install an inbound prefix-list filter
to the remote peer as an outbound filter, which reduces unwanted routing updates.
The standard route refresh message contains the Address Family Information (AFI) for which
the refresh is needed. Outbound route filtering is an additional mechanism that is used to
minimize the number of updates that are requested from a neighbor.
This mechanism reduces link bandwidth consumption and CPU use when a router requests a
route refresh. Filters that should be used by routers with the route refresh are described in ORF
entries that are part of the route refresh message.
You can configure the ORF feature with send, receive, or send and receive capabilities. The
local peer advertises the ORF capability in send mode. The remote peer receives the ORF
capability in receive mode and applies the filter as outbound policy. The local and remote peers
exchange updates to maintain the ORF for each router. Peer routers exchange updates
depending on the ORF prefix-list capability that is advertised. The remote peer starts sending
updates to the local peer after it receives a route refresh request or an ORF prefix-list with an
immediate status.
3-62
Example: Inbound vs. Outbound Filtering

The figure illustrates the comparison between standard inbound filtering and outbound route
filtering.
Inbound vs. Outbound Filtering
BGP v3.23-4
Outbound route filtering can limit the number of unwanted routing updates, which will reduce
the amount of resources that are required for routing update generation and processing. This
feature also reduces the amount of resources that are required to receive and discard routes that
would otherwise be filtered out by the receiving router if the ORF feature were not available.
The example shows two scenarios:
The first example shows that 100,000 routes are sent to a neighbor, and the input filter
permits only 100 of these routes.
The second example shows how a route refresh with a filter is sent to the neighbor. The
neighbor then uses the filter before sending the updates. This way, only 100 updates are
sent.
3-63
BGP Prefix-Based Outbound Route Filtering

This topic describes the function of BGP prefix-based outbound route filtering.
BGP Prefix-Based Outbound

Route Filtering
Uses BGP ORF send and receive capabilities to minimize the
number of BGP updates that are sent between BGP peers
Helps to reduce the amount of system resources required for
generating and processing routing updates by filtering out
unwanted routing updates at the source
Limits the number of unwanted routing updates, which will
reduce the amount of resources required for routing update
generation and processing
Reduces the amount of resources required to receive and
discard routes that would otherwise be filtered out
BGP v3.23-5
The BGP prefix-based outbound route filtering feature uses BGP ORF send and receive
capabilities to minimize the number of BGP updates that are sent between BGP peers.
Configuring this feature can help reduce the amount of system resources required for
generating and processing routing updates by filtering out unwanted routing updates at the
source.
The BGP prefix-based outbound route filtering feature is enabled through the advertisement of
ORF capabilities to peer routers. The advertisement of the ORF capability indicates that a BGP
speaker will accept a prefix-list from a neighbor and apply the prefix-list to locally configured
ORFs (if any exist). When this capability is enabled, the BGP speaker can install the inbound
prefix-list filter to the remote peer as an outbound filter, which reduces unwanted routing
updates.
The BGP prefix-based outbound route filtering feature can be configured with send, receive, or
send and receive ORF capabilities. The local peer advertises the ORF capability in send mode.
The remote peer receives the ORF capability in receive mode and applies the filter as an
outbound policy. The local and remote peers exchange updates to maintain the ORF on each
router. Updates are exchanged between peer routers by address family depending on the ORF
prefix-list capability that is advertised. The remote peer starts sending updates to the local peer
after a route refresh has been configured with the clear ip bgp command or after an ORF
prefix-list with immediate status is processed. The BGP speaker will continue to apply the
inbound prefix-list to received updates after the speaker pushes the inbound prefix-list to the
remote peer.
3-64
Example: BGP Prefix-Based Outbound Route Filtering

The figure provides an example of the function of BGP prefix-based outbound route filtering.
Sample: BGP Prefix-Based

Router-A Configuration (Sender)

Router-B Configuration (Receiver)

BGP v3.23-6
In the example, an ORF has been configured on Router-A (10.1.1.1) to advertise the filter to
Router-B (172.16.1.2). An IP prefix-list named FILTER is created to specify the
192.168.1.0/24 subnet for outbound route filtering. The ORF send capability is configured on
Router-A so that Router-A can advertise the ORF to Router-B.
Router-B is configured to advertise the ORF receive capability to Router-A. Router-B will
install the ORF, defined in the FILTER prefix-list, after the ORF capabilities have been
exchanged. An inbound soft reset is initiated on Router-B at the end of this configuration to
activate the ORF.
3-65

This topic describes the format and function of the ORF message.

ORF format
An ORF message consists of the following fields:
AFI/SAFI
ORF type
When to refresh
List of ORF entries
ORF entries depend on the ORF type.

The ORF capability needs to be negotiated for every
supported ORF type.
BGP v3.23-7
An ORF message contains the following information:

AFI and Subsequent Address Family Information (SAFI) for which the filter should be
used
ORF type, which identifies the type of filter
When to refresh (immediate or deferred refresh)
List of ORF entries where the actual filter is defined
You can use the AFI/SAFI component of the ORF message to provide a coarse level of
granular control by limiting the ORF to only the routes whose Network Layer Reachability
Information (NLRI) matches the configured AFI/SAFI component.
The ORF capability has to be negotiated by the router for each ORF type that is supported in
the ORF message.
3-66
Outbound Route Filter Message (Cont.)

ORF types:
NLRI (ORF type = 1)
Filters based on the prefix
Communities (ORF type = 2)
Filters based on standard BGP community attributes
Extended communities (ORF type = 3)
Filters based on extended BGP community attributes
Prefix-list (ORF type = 128)
Filters based on Cisco implementation of prefix filtering
BGP v3.23-8
The value contained in the ORF type determines the content that is contained in the ORF
message.
Currently, ORF type 0 is reserved, ORF types 1 to 127 are assigned by the Internet Assigned
Numbers Authority (IANA), and ORF types 128 to 255 are vendor-specific (and not assigned
by the IANA). Commonly used ORF types are as follows:
ORF type 1 is used to filter based on the NLRI.
ORF type 2 is used to filter based on standard BGP community attributes.
ORF type 3 is used to filter based on extended BGP community attributes.
ORF type 128 is used to filter based on the Cisco proprietary implementation of prefix
filtering (prefix-lists).
3-67
Outbound Route Filter Message (Cont.)

AFI/SAFI is IPv4 unicast.
ORF type is NLRI:
Action:
Match:
Scope:
NLRI:
When:
ADD, DELETE, or DELETE ALL

PERMIT or DENY
EXACT or REFINE
Prefix
IMMEDIATE or DEFER
BGP v3.23-9
The content of the ORF value is determined by the ORF-type setting. An ORF type of NLRIbased filtering (type 1) uses the following actions:
ADD: Adds a line to a prefix-list filter on the remote peer
DELETE: Removes a line from a filter that was previously installed on a remote peer
DELETE ALL: Removes all previously installed filters on the remote peer
For each filter entry, there is a match component that specifies either PERMIT or DENY. A
PERMIT asks the peer to send updates with routes that match the set of entries as specified in
the ORF. DENY specifies that the remote peer should not send updates for the entries matching
those specified in the ORF.
For prefixes specified with a match component of PERMIT, the remote peer is asked to pass a
prefix with a scope of EXACT (an exact match) or REFINE (its subnets).
Also contained within the ORF message is the when-to-refresh field. A router can set this field
to IMMEDIATE (asking the remote peer to refresh as soon as it has finished processing the
ORF message) or DEFER (asking the remote peer to wait until it receives a subsequent route
refresh message with the same AFI/SAFI).
3-68

This topic identifies the Cisco IOS command that is required to enable ORF negotiations and
activate an ORF prefix-list.
This command enables negotiation of prefix-list ORF

capability during session setup.
The ORF-capable BGP speaker will install ORFs per
neighbor.
Option:
- Both allows sending and receiving of
prefix-lists.
- Send allows only sending of prefix-lists.
- Receive allows only receiving of prefix-lists.
BGP v3.23-10
Cisco routers support the uploading of their prefix-lists to a neighbor. You need to use the
neighbor ip-address capability orf prefix-list receive command to advertise this capability,
and you need to use neighbor ip-address capability orf prefix-list send command to upload
the inbound prefix filter to the neighbor. The uploaded filter is then used on the neighboring
router after a statically configured outbound prefix-list (if it exists) is applied.
The neighbor ip-address capability orf prefix-list command enables the negotiation of the
prefix-list ORF capability during BGP session setup. The prefix-list-based ORF (ORF type =
128) is the only ORF type that Cisco IOS software supports.
neighbor orf prefix-list

To advertise ORF capabilities to a peer router, use the neighbor orf prefix-list command in
address family or router configuration mode.
neighbor {ip-address} [capability] orf prefix-list [receive | send | both]
To disable ORF capabilities, use the no form of this command.
no neighbor {ip-address} [capability] orf prefix-list [receive | send | both]
3-69
Syntax Description
3-70
Parameter
Description
The IP address of the neighbor router
(Optional) Informs the specified neighbor that this router has ORF
capabilities
(Optional) Enables the ORF prefix-list capability in receive mode
(Optional) Enables the ORF prefix-list capability in send mode
(Optional) Enables the ORF prefix-list capability in both receive

and send modes

(Cont.)
The command capability orf prefix-list send on one router requires

capability orf prefix-list receive on a neighboring router.
BGP v3.23-11
The example shows the configuration of two routers where one router has uploaded an input
prefix-list to the neighbor to be used as an output filter.
The following configuration steps are necessary to enable outbound route filtering:
Step 1
Enable negotiation of outbound filtering based on prefix-lists.
Step 2
Attach an input prefix-list to a neighbor.
Step 3
Enable sending of input prefix-list to the neighbor.
3-71

This topic identifies the Cisco IOS command that is used to trigger a route refresh message.
This command triggers a route refresh message.

This command includes a prefix-list in the route refresh
message if configured and supported on both ends.
The prefix-list is sent at session setup.
Use the prefix-filter option to refresh the remote filter.
BGP v3.23-12
Use the clear ip bgp neighbor command with the prefix-filter keyword to push out the
existing ORF prefix-list so that a new route refresh will be received from a neighbor. The
neighbor will use the ORF prefix-list that was previously negotiated.
You need to use the clear ip bgp neighbor command only when the filter has been modified
because the neighbor will store the filter for subsequent route refresh requests. The neighbor
will then use the filter on all updates toward the router that originated the filter.
Note
You should enter the in keyword when you are using the clear ip bgp neighbor command
because inbound route refresh is desired; only the inbound prefix-list filter is pushed to the
neighbor and used by the neighbor in the outbound direction.
The router will ignore the prefix-filter keyword if ORF capability has not been received or the
send capability has not been enabled.
When the clear ip bgp neighbor command is used without the prefix-filter keyword, a normal
route refresh is performed. You should always use the prefix-filter keyword when ORF
inbound routing policy changes occur.
3-72

This topic identifies the Cisco IOS command that is required to monitor the operation of an
ORF that you have configured and activated.
Verifies the supported capabilities
BGP v3.23-13
Use the show ip bgp neighbors neighbor command to display the supported capabilities.
If the neighbor supports a certain ORF capability, it is shown as advertised, received and a
filter of the supported type can be sent by that router to its neighbor.
The example output from the show ip bgp neighbors command shows that neighbor 5.0.0.1 is
configured with the prefix-based ORF feature in both send and receive modes. ORF capabilities
negotiation has been completed and is displayed per address family. The ORF type that has
been negotiated by this router with its peer is 128 (Cisco proprietary, prefix-list-based).
3-73
Summary
Summary
Outbound route filtering is a mechanism that is used to
minimize the number of updates that are requested from a
neighbor.
The BGP prefix-based outbound route filtering feature uses BGP
ORF send and receive capabilities to minimize the number of
BGP updates that are sent between BGP peers. Configuring this
feature can help reduce the amount of system resources
required for generating and processing routing updates by
filtering out unwanted routing updates at the source.
The ORF message contains the information that is used to
determine which updates will be passed. The format of an ORF
message includes AFI and SAFI for which the filter should be
used; ORF type, which identifies the type of filter; when to
refresh (immediate or deferred refresh); and a list of ORF entries
where the actual filter is defined.
BGP v3.23-14
Summary (Cont.)
The neighbor ip-address capability orf prefix-list command with
the send and receive keywords enables ORF negotiations
and activates an ORF prefix-list.
Use the clear ip bgp neighbor command to trigger a BGP route
refresh.
With the show ip bgp neighbors command, neighborsupported ORF capabilities are displayed as advertised,
received, and a filter of the supported type can be sent to
the neighbor.
3-74
BGP v3.23-15
Lesson 5
Applying Route-Maps as BGP

Filters
Overview
Border Gateway Protocol (BGP) is a powerful routing protocol that supports a wide variety of
administrative policy controls and route selection features. Many complex filtering goals and
administrative policies cannot be achieved by using only single-purpose filtering methods or by
compounding multiple filtering methods together. Route-maps provide a method to perform a
variety of compound, complex filtering operations within a single tool. Understanding the
operation and use of route-maps is a critical component in the successful implementation of any
large-scale BGP deployment.
This lesson describes route-maps and how you can use them for BGP filtering. Included in this
lesson are the commands that are required to use route-maps with prefix-lists and discussion of
how to use them as BGP filters and how to monitor previously configured route-maps.
Objectives
Upon completing this lesson, you will be able to use outbound route filtering to minimize the
impact of BGP routing updates on router resources in an operational BGP network. This ability
Describe the high-level function of a route-map
Describe the function of the BGP Route-Map Policy List Support feature
Describe the function of the BGP Route-Map Continue feature
Identify the Cisco IOS commands that are required to configure a route-map to match
against a prefix-list
Identify where you can apply route-maps as route filters in a BGP network
Identify the Cisco IOS command that is required to enable a route-map as a BGP route
filter
Identify the Cisco IOS commands that are required to monitor the operation of a configured
route-map that is used as a BGP filter
Route-Map Overview
This topic describes the high-level function of a route-map.
Route-Map Overview
Route-maps are very complex access-lists:
Access-lists have lines.
Route-maps contain statements.
Access-lists use addresses and masks.
Route-maps use match conditions.
With access-lists, there is an access-list number.
With route-maps, there is a route-map name.
Statements in route-maps are numbered.
You can insert and delete statements in a route-map.
You can edit match conditions in a statement.
Route-map statements can modify matched routes with set
options.
BGP v3.23-3
A route-map is a filter, and what is denied by the route-map is dropped. Additionally, you can
use the route-map to modify attributes of the permitted routes.
Route-maps are similar to access-lists. Both have a set of tests to be performed, and several
tests can be done in sequence. The first match produces the result of either permit or deny.
An access-list has a number of lines, each indicating a testing condition. The route-map is more
complex than the access-list. The route-map consists of several groups of configuration lines;
each group is called a statement. The statement has a sequence number that provides the
opportunity to remove or modify an explicit statement without removing the entire route-map.
There is also an opportunity to add a new statement between two existing statements.
Each route-map statement starts with a configuration line indicating the name of the route-map,
the sequence number, and whether the result should be permitted or denied if the testing
matches. The statement then continues, following configuration lines with the match clauses.
Matching can be done in several ways: testing on the prefix, the autonomous system (AS) path,
or some other attribute. The statement concludes with optional set statements, where
attributes may be modified or set.
3-76
Route-Map Overview (Cont.)
The default statement action is permit.

A route not matched by any statement is dropped.
Permit all is achieved by specifying permit without a
match clause.
Match conditions in one statement are ANDed together.
The first matching statement permits or denies the route.
BGP v3.23-4
A route-map consists of several statements. Each statement starts with the route-map
configuration line, on which the name of the route-map must be indicated. A good practice is to
always indicate the permit or deny keyword followed by a sequence number.
The matching clauses for the statements are listed on the match lines following the route-map
line. There may be several match lines, each referring to a different test to be performed. All
tests must be passed for the statement to be matched. If any of the match line tests fails, the
next route-map statement is tried. Statements are tried in sequence number order. If there are no
more statements in the route-map, the result is, implicitly, deny.
If all of the match clauses succeed, there is a match for the statement and the indicated result is
used. If the result is to deny, the route is then silently ignored. If the result is to permit, the
route is accepted and the set clauses are applied. The set clauses allow one or more attributes to
be changed or set to specific values before the route is accepted.
3-77

Route-map conditions are specified in the match statement.
Route-maps can match on:
Network number and subnet mask matched with an IP prefix-list

Route originator
BGP next-hop address
BGP origin
Tag attached to IGP route
AS-path
BGP community attached to BGP route
IGP route type (internal/external )
BGP v3.23-5
Each route-map statement can have several match clauses, and each match clause is given its
own configuration line. The match clause refers to the tests to be made on the candidate route.
Tests of the candidate route can be based on the following criteria:
IP network numbers and subnet masks, by referring to a prefix-list or access-list that will be
applied on the route
Route originator, by referring to a prefix-list or access-list that will be applied on the value
of the originator BGP attribute
Next hop, by referring to a prefix-list or access-list that will be applied on the value of the
next-hop BGP attribute
Origin code, by testing the value of the origin BGP attribute
Tag value that is attached to an Interior Gateway Protocol (IGP) routeused only when
redistribution from an IGP into BGP occurs
AS path, by referring to an AS-path access-list that will be applied on the value of the ASpath BGP attribute
Community, by referring to a community-list that will be applied on the value of the
Community BGP attribute
IGP route type, by testing if the IGP route is internal or externalused only when
redistribution from an IGP to BGP occurs
3-78

Route-maps can also change the attributes of BGP routes.
Route-maps can set:
Origin
BGP next-hop
Weight
BGP community
Local preference
MED
BGP v3.23-6
Each route-map statement may have several set clauses. Each set clause is applied to the route
when the route-map statement permits the route. With a route-map, the following can be set:
Origin BGP attribute
Next-hop BGP attribute
Weight
Community BGP attribute
Local preference BGP attribute
Multi-exit discriminator (MED) BGP attribute, by setting the metric
3-79

This topic describes the function of the BGP Route-Map Policy List Support feature.

Adds the capability for a network operator to group
route-map match clauses into named lists called policy-lists
Simplifies the configuration of BGP routing policy in
medium-size and large networksnetwork operator can
preconfigure policy lists with groups of match clauses and
then reference these policy lists within different route maps
Eliminates need to manually reconfigure each recurring
group of match clauses that occur in multiple route-map
entries
BGP v3.23-7
The BGP Route-Map Policy List Support feature introduces new functionality to BGP route
maps, allowing a network operator to group route-map match clauses into named lists called
policy-lists. A policy-list functions like a macro.
When a policy-list is referenced in a route-map, all of the match clauses are evaluated and
processed as if they had been configured directly in the route-map. The BGP Route-Map Policy
List Support feature simplifies the configuration of BGP routing policy in medium-size and
large networks because a network operator can preconfigure policy-lists with groups of match
clauses and then reference these policy-lists within different route-maps. The network operator
no longer needs to manually reconfigure each recurring group of match clauses in multiple
route-map entries.
A policy-list is like a route-map that contains only match clauses. The policy-list is created and
then referenced within a route-map. There are no changes to match clause semantics and routemap functions. Match clauses are configured in policy-lists with permit and deny statements.
The route-map evaluates and processes each match clause and permits or denies routes based
on the configuration. AND and OR semantics in the route-map function the same way for
policy-lists that they do for match and set clauses. There are some commands that are related to
the BGP Route-Map Policy List Support feature: the ip policy-list command, the match
policy-list command, and the show ip policy-list command.
3-80
BGP Route-Map Policy List Support (Cont.)
Creates a BGP policy-list
Configures a route map to evaluate and process a BGP

policy-list in a route map
Displays one or all filter lists

BGP v3.23-8
ip policy-list
To create a BGP policy-list, use the ip policy-list command in policy-map configuration mode.
ip policy-list policy-list-name {permit | deny}
To remove a policy-list, use the no form of this command
no ip policy-list policy-list-name
Syntax Description
Parameter
Description
Name of the configured policy-list
Permits access for matching conditions
Denies access to matching conditions
match policy-list
To configure a route-map to evaluate and process a BGP policy-list in a route-map, use the
match policy-list command in route-map configuration mode.
match policy-list policy-list-name
To remove a path list entry, use the no form of this command.
no match policy-list policy-list-name
3-81
Syntax Description
Parameter
Description
show ip policy-list
To display information about a configured policy-list and policy-list entries, use the show ip
policy-list command in user EXEC mode.
show ip policy-list policy-list-name
Syntax Description
Parameter
Description
Configuring Policy-List Examples

The following configuration example creates a BGP policy-list that permits matches on the AS
path and multi-exit discriminator (MED) of a router:

The following configuration example creates a BGP policy-list that permits matches on the
specified BGP community and the next hop of a router:

The following configuration example creates a BGP policy-list that denies matches on the
specified BGP community and the next hop of a router:

3-82
Configuring Route-Maps to Reference Policy-List Examples

The configuration examples in this section create BGP route-maps that reference BGP policylists with the route-map route-map configuration command.
The following configuration example creates a route-map that references policy-lists and
separate match and set clauses in the same configuration. This example uses AND semantics
between POLICY-LIST-NAME-1 and POLICY-LIST-NAME-2.

The following configuration example creates a route-map that references policy-lists and
separate match and set clauses in the same configuration. This example uses OR semantics
between POLICY-LIST-NAME-3 and POLICY-LIST-NAME-4.

Verifying BGP Route-Map Policy List Support

To verify that a policy-list has been created, use the show ip policy-list command. The output
of this command displays the policy-list name and configured match clauses. The following
sample output is similar to the output that will be displayed:

Note
A policy-list name can be specified when the show ip policy-list command is entered. This
option can be useful for filtering the output of this command and verifying a single policy-list.
3-83
To verify that a route-map has been created and a policy-list is referenced, use the show routemap command. The output of this command displays the route-map name and policy-lists that
are referenced by the configured route-maps. The following sample output is similar to the
output that will be displayed:

3-84

This topic describes the continue clause used in BGP route-map configuration.

Introduces the continue clause to BGP route-map
configuration, providing more programmable policy
configuration and route filtering
Provides the ability to execute additional entries in a routemap after an entry is executed with successful match and set
clauses
Allows configuration and organization of more modular
policy definitions to reduce the number of policy
configurations that are repeated within the same route-map
Allows modularization of network policy configuration so
that repeated policy definitions can be reduced within the
same route-map
BGP v3.23-9
The BGP Route-Map Continue feature introduces the continue clause to BGP route-map
configuration. The continue clause provides more programmable policy configuration and route
filtering. It introduces the ability to execute additional entries in a route-map after an entry is
executed with successful match and set clauses. Continue clauses allow you to configure and
organize more modular policy definitions to reduce the number of policy configurations that are
repeated within the same route-map.
Continue clauses provide a programmable method to organize and control the flow of a routemap. Route-map configuration was linear before this feature was introduced. Continue clauses
also allow you to modularize network policy configuration so that repeated policy definitions
can be reduced within the same route-map.
Route-Map Operation Without Continue Clauses

A route-map evaluates match clauses until a successful match occurs. After the match occurs,
the route-map stops evaluating match clauses and starts executing set clauses, in the order in
which they were configured. If a successful match does not occur, the route-map falls
through and evaluates the next sequence number of the route-map until all configured routemap entries have been evaluated or a successful match occurs. Each route-map sequence is
tagged with a sequence number to identify the entry. Route-map entries are evaluated in order,
starting with the lowest sequence number and ending with the highest sequence number. If the
route-map contains only set clauses, the set clauses are executed automatically, and the routemap does not evaluate any other route-map entries.
3-85
Route-Map Operation with Continue Clauses

When a continue clause is configured, the route-map continues to evaluate and execute match
clauses in the specified route-map entry after a successful match occurs. The continue clause
can be configured to go to (or jump to) a specific route-map entry by specifying the sequence
number, or if a sequence number is not specified, to go to the next sequence number. This
behavior is called an implied continue. If a match clause exists, the continue clause is
executed only if a match occurs. If no successful matches occur, the continue clause is ignored.
If a match clause does not exist in the route-map entry but a continue clause does, the continue
clause is automatically executed and goes to the specified route-map entry. If a match clause
exists in a route-map entry, the continue clause is executed only when a successful match
occurs. When a successful match occurs and a continue clause exists, the route-map executes
the set clauses and then goes to the specified route-map entry. If the next route-map contains a
continue clause, the route-map executes the continue clause if a successful match occurs. If a
continue clause does not exist in the next route-map, the route-map is evaluated normally. If a
continue clause exists in the next route-map but a match does not occur, the route-map does not
continue and falls through to the next sequence number, if one exists.
Note
3-86
A continue clause can be executed, without a successful match, if a route-map entry does
not contain a match clause.
BGP Route-Map Continue (Cont.)
Configures a route-map to go to a route-map entry with a

higher sequence number
Displays configured route-maps
BGP v3.23-10
You will use two commands with the BGP Route-Map Continue feature, the continue
command and the show route-map command.
continue
To configure a route-map to go to a route-map entry with a higher sequence number, use the
continue command in route-map configuration mode.
continue sequence-number
To remove a continue clause from a route-map, use the no form of this command.
no continue
Syntax Description
Parameter
Description
(Optional) Route-map sequence number.

If a route-map sequence number is not specified when configuring a continue
clause, the continue clause continues to the route-map entry with the next
sequence number. This behavior is referred to as an "implied continue."
show route-map
To display configured route-maps, use the show route-map command in EXEC mode.
show route-map [map-name]
3-87
Syntax Description
Parameter
Description
(Optional) Name of a specific route-map
BGP Route-Map Continue Clause Example Configuration

The following example shows continue clause configuration in a route-map sequence.
The first continue clause in route-map entry 10 indicates that the route map will go to routemap entry 30 if a successful match occurs. If a match does not occur, the route map will fall
through to route-map entry 20. If a successful match occurs in route-map entry 20, the set
action will be executed and the route map will not evaluate any additional route-map entries.
If a successful match does not occur in route-map entry 20, the route map will fall through to
route-map entry 30. This sequence does not contain a match clause, so the set clause will be
automatically executed and the continue clause will go to the next route-map entry because a
sequence number is not specified.
If there are no successful matches, the route-map will fall through to route-map entry 30 and
execute the set clause, and route-map entry 40 will not be evaluated.

3-88
BGP Route-Map Continue Clause Verification Example

To verify the configuration of continue clauses, use the show route-map command. The output
of this command displays configured route-maps, match, set, and continue clauses. The
following sample output is similar to the output that will be displayed:

3-89

This topic identifies the Cisco IOS commands that are required to configure a route-map to
match against a prefix-list.
Uses prefix-list to match routes in route-map match condition
Matches routes where the next hop matches the conditions in

the prefix-list

Matches routes received from BGP peer that matches the

prefix-list
BGP v3.23-11
match ip address
To distribute any routes that have a destination network number address that is permitted by a
standard access-list, an extended access-list, or a prefix-list, or to perform policy routing on
packets, use the match ip address command in route-map configuration mode.
match ip address {access-list-number [access-list-number... | access-list-name...] | accesslist-name [access-list-number...| access-list-name] | prefix-list prefix-list-name [prefix-listname...]}
To remove the match ip address entry, use the no form of this command.
no match ip address {access-list-number [access-list-number... | access-list-name...] |
access-list-name [access-list-number...| access-list-name] | prefix-list prefix-list-name
[prefix-list-name...]}
3-90
Syntax Description
Parameter
Description
Number of a standard or extended access-list.

It can be an integer from 1 to 199. The ellipsis indicates that
multiple values can be entered.
Name of a standard or extended access-list.

It can be an integer from 1 to 199. The ellipsis indicates that
multiple values can be entered.
Distributes routes based on a prefix-list.
Name of a specific prefix-list.

The ellipsis indicates that multiple values can be entered.
match ip next-hop
To redistribute any routes that have a next-hop router address passed by one of the access-lists
specified, use the match ip next-hop command in route-map configuration mode.
match ip next-hop {access-list-number | access-list-name}[...access-list-number |
...access-list-name]
To remove the next hop entry, use the no form of this command.
no match ip next-hop {access-list-number | access-list-name}[...access-list-number |
Syntax Description
Parameter
Description

It can be an integer from 1 to 199.

To redistribute routes that have been advertised by routers and access servers at the address
specified by the access-lists, use the match ip route-source command in route-map
configuration mode.
match ip route-source {access-list-number | access-list-name}[...access-list-number |
To remove the route-source entry, use the no form of this command.
no match ip route-source {access-list-number | access-list-name}[...access-list-number |
3-91
Syntax Description
Parameter
Description


3-92
BGP Filters
This topic identifies where you can apply route-maps as route filters in a BGP network.
BGP Filters
BGP v3.23-12
You can optionally apply filter-lists, prefix-lists, and route-maps to either incoming or outgoing
information or any combination of the two. The incoming prefix-list, the incoming filter-list,
and the incoming route-map must all permit the routes that are received from a neighbor before
being accepted into the BGP table. Outgoing routes must pass the outgoing filter-list, the
outgoing prefix-list, and the outgoing route-map before being transmitted to the neighbor.
When a router is configured to redistribute routing information from an IGP into BGP, the
routes must successfully pass any prefix-list or route-map that is applied to the redistribution
before a route is injected into the BGP table.
3-93

This topic identifies the Cisco IOS command that is required to enable a route-map as a BGP
route filter.

This command applies a route-map to incoming or outgoing
BGP updates.
Prefixes not permitted by the route-map are discarded.
Route-maps can also change BGP attributes in incoming or
outgoing updates.
Route-maps, filter-lists, and prefix-lists are evaluated in
sequence (effectively ANDed together).
BGP v3.23-13
You can apply a route-map on incoming or outgoing routing information for a neighbor. The
routing information must be permitted by the route-map in order to be accepted. If there is no
statement in the route-map explicitly permitting a route, then the route will be implicitly denied
and dropped.
The permitted routes may have their attributes set or changed by the set clauses in the routemap. Setting attributes on routes is useful when you are influencing route selection. Some
routes can be permitted by one of the statements in the route-map and have their attributes
changed. Another statement in the route-map could permit other routes and not have their
attributes altered. When route selection is performed, the attribute values indicate that one route
is preferred over the other.
3-94
Using Route-Maps as BGP Filters (Cont.)

Requirement: The customer will accept
only a default route and use the primary
link for outbound traffic.
BGP v3.23-14
In this example, the customer will accept only a default route and use the primary link that is
connected to AS 387 for outbound traffic.
3-95
This topic identifies the Cisco IOS commands that are required to monitor the operation of a
configured route-map that is used as a BGP filter.
BGP v3.23-15
Use the show ip bgp command to display the configured route-map characteristics.
The example shows that only default routes are entered into the BGP table. The default route
from the primary link has been selected by BGP as the best route. The BGP route selection
rules have been modified based on the configuration of the BGP weight attribute in the routemap. As part of that configuration, the weight of the primary link has been set to 150 and the
weight of the backup link has been set to 100.
Because BGP path selection prefers the highest weight, the router uses the primary link as the
outgoing path.
3-96
Monitoring Route-Maps (Cont.)
BGP v3.23-16
Here you see that all routes except for the default route are being filtered out of the BGP update
(denied). The default route is installed in the route table.
3-97

Displays all routes in BGP table matching the route-map
Used for filtering the show ip bgp output on basis of BGP path
attributes:
Community
Local preference
Weight
Origin
Next-hop
Can also filter based on prefixes

Allows powerful combined filtering
BGP v3.23-17
You can also use route-maps for selective and powerful filtering of the BGP table. The show ip
bgp route-map command displays selected routes from a BGP routing table based on the
contents of a route-map.
A route-map can match the routes on the basis of BGP path attributes (local preference,
community, weight, origin, next-hop) or prefix-lists and access-lists (matching IP prefixes).
The power of route-map filtering lies in the possibility of combining different filters (for
example, filtering on community, prefix, and next-hop values).
Note
3-98
Support for route-map filtering was added in Cisco IOS Software Release 12.2(11)T and
12.0(14)ST.
Networks matched by the route-map are displayed.
BGP v3.23-18
In this example, a customer is using a simple route-map to filter the BGP table. By using the
show ip bgp route-map command, the customer can display the filtered BGP table. The
customer router configuration from which this output is collected is shown here for reference:

The route-map filter matches incoming networks from two service providers. For all routes
that are sent by the primary provider (AS 387), the local router accepts the default route only,
and it is marked as the preferred route with a weight of 150. Only a default route is accepted
from the backup provider, and its weight metric has been set to 100.
The customer then applies the route-map to the output of the show ip bgp route-map
command, and only the networks that conform to the AS-path and prefix-list filters are
displayed (network 0.0.0.0/0 in the example).
3-99
Summary
Summary
A route-map is a filter that has the ability to drop denied
routes as well as modify attributes of the permitted routes.
The BGP Route-Map Policy List Support feature introduces
new functionality to BGP route-maps, adding the ability for a
network operator to group route-map match clauses into
named lists called policy-lists.
The BGP Route-Map Continue feature introduces the
continue clause to BGP route-map configuration. Continue
clauses provide a programmable method to organize and
control the flow of a route-map.
BGP v3.23-19
Summary (Cont.)
You can configure a route-map to match against a prefix-list
by using the match ip address, match ip next-hop, and match ip
route-source commands.
Filter-lists, prefix-lists, and route-maps can optionally all be
applied on either incoming or outgoing information in any
combination.
A route-map can be applied on incoming or outgoing routing
information to or from a neighbor, but the routing information
must be permitted by the route-map in order to be accepted.
Monitoring route-maps is possible using the show ip bgp and
debug ip bgp update commands.
3-100
BGP v3.23-20
Lesson 6
Implementing Changes in BGP

Policy
Overview
Because of the huge volumes of routing information that Border Gateway Protocol (BGP) is
capable of handling, traditional routing update methods are not feasible. Routing policies for a
BGP neighbor may include filtering mechanisms such as route-maps, distribute-lists, prefixlists, and autonomous system (AS)-path filter-lists. Each of these filters may impact inbound or
outbound routing table updates.
Whenever there is an administrative change in routing policy, the BGP session must be reset
before the new policy can take effect. To accomplish this task, there are two types of reset: hard
reset and soft reset. Clearing a BGP session using a hard reset invalidates the cache and results
in a negative impact on the operation of networks, because the information in the cache
becomes unavailable. A soft reset is recommended because it allows routing tables to be
reconfigured and activated without clearing the BGP session.
This lesson discusses routing updates in a BGP environment and the traditional methods of
forcing BGP route updates after changes in a filter policy. The function and benefits of soft
reconfiguration and route refresh are also discussed. The lesson also presents the commands
that are required to perform a soft reconfiguration and route refresh and explains how to
monitor and troubleshoot these features.
Objectives
Upon completing this lesson, you will be able to configure the soft reconfiguration feature to
minimize the impact of expediting BGP policy updates in a typical BGP network. This ability
Identify the limitations of the traditional methods of forcing BGP route updates after
changing a filter policy
Describe the function of the soft reconfiguration feature
Identify the Cisco IOS commands that are required to configure and perform a soft
reconfiguration
Identify the Cisco IOS tools that are available to monitor the operation of a soft
reconfiguration
Describe the function of the BGP Soft Reset Enhancement feature
Describe the function and benefits of the route refresh function
Identify the Cisco IOS command that is required to trigger a route refresh
Identify the Cisco IOS commands that are required to monitor route refresh operation
Explain the benefit of using route-maps as BGP filters
3-102

This topic identifies the limitations of traditional methods when you are forcing BGP route
updates after changing filter policies.

All filters apply only to new incoming and outgoing
updates.
To change outbound routing policy, you have to
resend BGP updates to your neighbors.
To change inbound routing policy, you have to force
your neighbor to resend the updates to you.
The traditional mechanism is to clear BGP sessions.
BGP v3.23-3
BGP can potentially handle huge volumes of routing information. But when network
administrators change configuration lines in filters or route-maps, the router cannot go through
the huge table of BGP information and calculate which entry is no longer valid in the local
table. Nor can the router determine which route or routes, already advertised, should be
withdrawn from a neighbor. There is an obvious risk that the first configuration change will be
immediately followed by a second, which would cause the whole process to start all over again.
To avoid such a problem, Cisco IOS software applies changes only on the updates that are
received or transmitted after the configuration change has been performed. This approach
means that the new routing policy, enforced by the new filters, is applied only on routes that are
received or sent after the change. If network administrators would like to apply the policy
change on all routes, they have to force the router to let all routes pass through the new filter.
If the filter is applied to outgoing information, the router has to resend the entire BGP table
through the new filter. If the filter is applied to incoming information, the router needs its
neighbor to resend its entire BGP table so that it passes through the new filters.
Traditionally, to accomplish these goals, network administrators have torn down the affected
BGP sessions after completing a configuration change. After the sessions are down, all
information that is received on those sessions is invalidated and removed from the BGP table.
Also, the remote neighbor will detect a session down state, and it likewise will invalidate the
routes that are received on the session. After a period of 30 to 60 seconds, the sessions are
re-established automatically and the entire BGP table is exchanged again, but through the new
filters. This process, however, disrupts packet forwarding.
3-103
Traditional Limitations of Clearing

the BGP Session

This command tears down the BGP session with all neighbors, a
specific neighbor, or all neighbors in a peer group.
All BGP routes are lost after the session is torn down;
connectivity through the BGP neighbor is lost.
A new session is re-established within 30 to 60 seconds.
A full routing update is exchanged once the session is reestablished, resulting in enforcement of new routing policy.
Processing the full Internet routing table can take a long time.
Clearing the BGP session is a very disruptive way to implement
routing policies.
BGP v3.23-4
The EXEC command clear ip bgp tears down one or several BGP sessions. The BGP sessions
are terminated, and the TCP connections closed. The neighbors go into the Idle state and stay
there for approximately 30 seconds. Next, the neighbor session goes into the Active state, and
the sessions are re-established.
You can implement the clear ip bgp command with the * (asterisk) argument, which applies to
all sessions, or you can make a reference to a specific session or group of sessions to tear down.
When the session is down, all routes that are received over the session by both routers are
invalidated. When the session is once again in the Established state, all BGP routes have to be
resent by both peers and pass through the new filters, which enforces the new policy.
Exchanging the complete Internet routing table takes time, bandwidth, and CPU resources. IP
packet forwarding to and from the neighbor is down for several minutes. Also, revoking and
reannouncing the routes will be registered by the rest of the Internet as a flap for each route.
3-104

This topic describes the function of the soft reconfiguration feature.

Soft reconfiguration was introduced in Cisco IOS Software
Release 11.2 to facilitate nondisruptive changes in BGP
routing policies.
Outbound soft reconfiguration resends the complete BGP
table.
Always enabled, not configurable
Inbound soft reconfiguration stores the complete BGP table

of your neighbor in router memory.
BGP v3.23-5
With Cisco IOS Software Release 11.2 came the introduction of the soft reconfiguration
feature. Soft reconfiguration provides the ability to run all routes through the filters without
tearing down the sessions. Outbound soft reconfiguration was easy to implement because it is a
simple resending of all routes in the local BGP table. Inbound soft reconfiguration was more
complicated because a copy of all the routes that are received from a neighbor is required. The
copy of the routes that are received from the neighbor is saved independently of the BGP table,
before any filters are applied. Whenever the incoming filters are changed, a replay of
everything that has been received from the neighbor takes place without involving the
neighbor. The major drawback of this approach is the amount of memory that is required to
hold the copy.
3-105
Example: Soft Reconfiguration and Memory Use

This example shows the impact of soft reconfiguration on an Internet service provider (ISP)
router with three upstream neighbors sending full Internet routing information.
Soft Reconfiguration and Memory Use
BGP v3.23-6
Each neighbor is sending 100,000 prefixes. The router stores each set in a dedicated perneighbor BGP table. All 300,000 paths will then appear in the main BGP table if there is no
filtering. The router will then choose the best path for each prefix and put it into the routing
table. If Cisco Express Forwarding (CEF) switching is enabled, the router will store another
copy in the Forwarding Information Base (FIB) table.
This solution obviously does not scale in terms of the number of neighbors and prefixes.
3-106
Cisco IOS Commands for Soft Reconfiguration

This topic identifies the Cisco IOS commands that are required to configure and perform a soft
reconfiguration.
Inbound Soft Reconfiguration

Cisco IOS Commands
BGP v3.23-7
When you configure the soft-reconfiguration inbound command for a neighbor, the router
stores all routes that are received from that neighbor as an extra copy in memory. This copy is
taken before any filtering is applied by the router to routes that it receives.
This process is not enabled by default because it may consume large volumes of memory.
neighbor soft-reconfiguration
To configure Cisco IOS software to start storing updates, use the neighbor softreconfiguration router configuration command.
neighbor {ip-address | peer-group-name} soft-reconfiguration inbound
To not store received updates, use the no form of this command.
no neighbor {ip-address | peer-group-name} soft-reconfiguration inbound
Syntax Description
Parameter
Description
(Optional) Keyword that indicates that the update to be stored is

an incoming update
3-107
Inbound Soft Reconfiguration

Cisco IOS Commands (Cont.)
BGP v3.23-8
When the network administrator has completed the changes to filters and route-maps that are
applied on incoming information (changes that will implement a new routing policy), the clear
ip bgp ip-address soft in command is executed on the router in privileged EXEC mode. After
the command has been entered, the router will not tear the session down. Instead, the router
resends the saved copy of the received routing information through the new filters, and the
result is stored in the local BGP table.
clear ip bgp
To reset a BGP connection using BGP soft reconfiguration, use the clear ip bgp EXEC
command at the system prompt.
clear ip bgp {* | address | peer-group-name} [soft [in | out]]
Syntax Description
Parameter
Description
Resets all current BGP sessions.
Resets only the identified BGP neighbor.
Resets the specified BGP peer group.
(Optional) Soft reset. Does not reset the session.
(Optional) Triggers inbound or outbound soft reconfiguration.

If the in or out option is not specified, both inbound and outbound
soft reset are triggered.
3-108
Outbound Soft Reconfiguration

Cisco IOS Commands
BGP v3.23-9
When the network administrator has completed the changes to filters and route-maps that are
applied on the outgoing information (changes that will implement a new routing policy), the
clear ip bgp ip-address soft out command is executed on the router in privileged EXEC mode.
After the command has been entered, the router will not tear the session down. Instead, the
table version number of the neighbor is reset to 0. When the next update interval for the
neighbor arrives, the local router will go through the entire BGP table and find that all the
routes need to be sent to the neighbor because they all have a table version number higher
than 0.
This process causes all the BGP routes to be resent through the new filters.
3-109

This topic identifies the Cisco IOS tools that are available to monitor the operation of a soft
reconfiguration.
BGP v3.23-10
The show ip bgp command is used to display the local BGP table. You can check the entries
that have been propagated to a specific neighbor with the show ip bgp neighbor ip-address
advertised command. It displays the subset of the local BGP table that has passed the splithorizon check and all outgoing filters for the neighbor.
You can check incoming information that is received from a neighbor with the show ip bgp
neighbor ip-address routes command. It displays which of the routes in the local BGP table
were received (and accepted) from the indicated neighbor. Only routes that are passed by the
incoming filter for the neighbor are displayed.
If the soft-reconfiguration inbound feature is enabled for a neighbor, the information that is
saved in the extra copy outside the filters is displayed using the show ip bgp neighbor ipaddress received command.
These commands are useful when you are troubleshooting the routing policy. You can compare
routes outside the incoming filters with what was actually accepted into the BGP table from a
neighbor. In addition, routes that are transmitted and advertised to a neighbor can be compared
to what is inside the outgoing filters in the local BGP table.
3-110

This topic describes the function of the BGP Soft Reset Enhancement feature.

Provides automatic support for dynamic soft reset of
inbound BGP routing table updates that is not dependent
upon stored routing table update information
Requires no preconfiguration (as with the neighbor softreconfiguration command)
Requires much less memory than the previous soft reset
method for inbound routing table updates
BGP v3.23-11
Whenever there is a change in the routing policy, the BGP session must be cleared, or reset, for
the new policy to take effect. There are two types of reset, hard reset and soft reset. Clearing a
BGP session using a hard reset invalidates the cache and results in a negative impact on the
operation of networks as the information in the cache becomes unavailable. Soft reset is
recommended because it allows routing tables to be reconfigured and activated without clearing
the BGP session. Soft reset is done on a per-neighbor basis. There are two types of soft reset:
Dynamic inbound soft reset: When soft reset is used to generate inbound updates from a
neighbor
Outbound soft reset: When soft reset is used to send a new set of updates to a neighbor
Previously, to perform a soft reset for inbound routing table updates, the neighbor softreconfiguration command directed the Cisco IOS software in the local BGP router to store all
received (inbound) routing policy updates without modification. This method is memoryintensive and not recommended unless absolutely necessary. (Outbound updates have never
required the extra memory and are not affected by this feature.)
The BGP Soft Reset Enhancement feature, however, provides automatic support for dynamic
soft reset of inbound BGP routing table updates that is not dependent on stored routing table
update information. The new method requires no preconfiguration (as with the neighbor softreconfiguration command) and requires much less memory than the previous soft reset
method for inbound routing table updates.
3-111
There are a number of benefits to the BGP Soft Reset Enhancement feature:
Allows dynamic route refresh requests: This feature provides a way to initiate
nondisruptive routing policy changes by allowing the dynamic exchange of route refresh
requests between BGP routers, and the subsequent readvertisement of the respective
outbound routing tables.
Requires no preconfiguration: Because support for the soft reset using the route refresh
capability is included in this release of the Cisco IOS software, no further router
configuration is required. You can initiate a soft inbound reset using only the clear ip bgp
in command.
Requires no additional memory resources: Unlike a soft reset using the stored inbound
routing table updates provided by the neighbor soft-reconfiguration command, when both
BGP peers support the route refresh capability, inbound routing table updates are not stored
in the local BGP router. The soft reset requests are exchanged dynamically, and no
additional memory is required.
Provides flexibility: There are now two available methods for inbound soft reset; the older
method, using stored inbound routing table updates, and the method provided by this
feature, using dynamic exchange of update information.
When the routing policy of a BGP neighbor changes, the session must be reset (cleared) for the
changes to take effect. Because resetting a BGP session can be disruptive to networks, a soft
reset method is recommended for reconfiguring the routing table. Previously, in order to
reconfigure the inbound routing table, both the local BGP router and the BGP peer first needed
to be configured to store incoming routing policy updates using the neighbor softreconfiguration command. Additional resources, particularly memory, were required to store
the inbound routing table updates. The clear ip bgp command could then initiate the soft reset,
which generated a new set of inbound routing table updates using the stored information.
The BGP Soft Reset Enhancement feature provides an additional method for soft reset that
allows the dynamic exchange of route refresh requests and routing information between BGP
routers and the subsequent readvertisement of the respective outbound routing table. Soft reset
using the route refresh capability does not require preconfiguration and consumes no additional
memory resources.
To use this new method, both BGP peers must support the soft route refresh capability, which
is advertised in the Open message sent when a peer sends its routing table update. Any router
running BGP with this software release automatically supports the route refresh capability.
Routers running earlier Cisco IOS software releases do not support the route refresh capability
and must use the older soft reset method. If the soft reset fails, you can still clear the BGP
session, but it will have a negative impact on network operations and should be used only as a
last resort.
Note
3-112
Outbound resets have never required preconfiguration or storing of routing table updates
and remain unchanged by the BGP Soft Reset Enhancement feature.
Route Refresh
This topic describes the function and benefits of the route refresh function.
Route Refresh
Route refresh is a new BGP capability.
It is used to request a neighbor to resend routing
information.
It is typically used after configuration changes to update the
BGP table (route-map, distribute-list, prefix-list, filter-list,
weight, local preference, MED, and so on).
The traditional way of accomplishing this function is to clear
the BGP session.
BGP v3.23-12
Route refresh is one of the new capabilities of BGP. Routers use the route refresh feature to
request a neighbor to resend all the routing information when it is needed.
There are several ways of refreshing the routing information from a neighbor:
Clearing the neighbor relationship
Soft-clearing the neighbor relationship (if soft reconfiguration is enabled for this specific
neighbor)
Using route refresh (if the neighbor supports this capability)
Note
To use soft reset without preconfiguration, both BGP peers must support the soft route
refresh capability, which is advertised in the Open message that is sent when the peers
establish a TCP session. Routers that run Cisco IOS software releases earlier than Release
12.1 do not support the route refresh capability and must clear the BGP session using the
neighbor soft-reconfiguration command.
3-113
Route Refresh (Cont.)

Inbound soft reconfiguration consumes memory on the
receiving router.
It is needed only because there is no mechanism in
standard BGP to request retransmission of BGP routes.
BGP route refresh is an optional BGP capability that allows a
BGP router to request retransmission of BGP routes from a
neighbor.
BGP v3.23-13
The soft-reconfiguration inbound feature consumes large volumes of memory in the Internet
environment. The number of routes that can be received from a peer router on the Internet is so
large that it is not feasible to store an extra copy.
The only reason for making the extra copy is to be able to replay the data through the new
routing policy without tearing down the session and re-establishing it.
What is needed is a mechanism to ask the neighbor router to do a clear soft outbound. If this
were possible, the extra copy would not be needed. The neighboring router, of course, has its
own copy in its BGP table, which it could resend to the local router whenever it is signaled to
do so.
There is no such mechanism in standard BGP, but there is an optional BGP capability that
allows one router to request a refresh from its neighbor: route refresh.
3-114
The table compares the various methods of BGP session reset, stating the advantages and
disadvantages of each.
Type of Reset
Advantages
Disadvantages
Hard reset
No memory overhead.
The prefixes in the BGP, IP, and FIB

tables that are provided by the
neighbor are lost.
Not recommended.
Outbound soft reset
No configuration, no storing of
routing table updates.
Does not reset inbound routing table

updates.
Dynamic inbound soft

reset
Does not clear the BGP session

or cache.
Both BGP routers must support the

route refresh capability (Cisco IOS
Software Release 12.1 and later
releases).
Does not require storing of routing

table updates, and has no
memory overhead.
Configured inbound soft
reset (uses the neighbor
soft-reconfiguration
command)
Can be used when both BGP

routers do not support the
automatic route refresh capability.
Requires preconfiguration.
Stores all received (inbound) routing
policy updates without modification,
and is thus memory-intensive.
Recommended only when absolutely
necessary.
3-115
Example: Route Refresh

The example shows the steps in a route refresh.
Route Refresh (Cont.)
Step 1 - Route refresh is negotiated when the BGP session is established.

Step 2 - Inbound routing policy is changed on RTR-B.
Step 3 - Operator requests inbound route refresh.
Step 4 - RTR-B sends route refresh message to RTR-A.
Step 5 - RTR-A resends all BGP routes to RTR-B.
BGP v3.23-14
The ability to use the route refresh feature must be negotiated by the router when the BGP
session is first established. The local router keeps a record that the capability is available with
the neighbor. There is no need to keep a copy of the routing information that is received from
the neighbor if it has the ability to refresh.
After reconfiguring the filters and route-maps that will implement a new routing policy, a
network administrator can issue the clear ip bgp ip-address soft in command in the local
router. The router checks whether the route refresh capability is available, and if it is, requests a
resend of the BGP table of the neighbor instead of replaying its own copy.
3-116
Using Route Refresh

This topic identifies the Cisco IOS command that is required to perform a route refresh.
Using Route Refresh
Sends a route refresh message to the neighbor or neighbors

Only works if the neighbor has previously advertised the
route refresh capability
BGP v3.23-15
Use the clear ip bgp * in command to send a route refresh message to all neighbors or clear ip
bgp ip-address in to send a route refresh message to a specific neighbor.
You need not use the soft keyword, because soft reset is automatically assumed when the route
refresh capability is supported.
clear ip bgp
To reset a BGP connection with BGP soft reconfiguration, use the clear ip bgp privileged
EXEC command at the system prompt.
clear ip bgp {* | ip-address | peer-group-name} [soft [in | out]]
Syntax Description
Parameter
Description
Resets the specified BGP peer group.
(Optional) Soft reset. Does not reset the session.

If the in or out option is not specified, both inbound and outbound
soft reset are triggered.
3-117

This topic identifies the Cisco IOS commands that are required to monitor route refresh
operation.
Verifies the support for route refresh capability
BGP v3.23-16
Use the show ip bgp neighbor command to see whether the neighbor supports the route refresh
message.
Note
3-118
The printout of the show ip bgp neighbor command varies among Cisco IOS releases. The
printout in the figure here was generated by Cisco IOS Software Release 12.0(1)S and
represents a manual configuration of soft reset.
Monitoring Route Refresh (Cont.)
Debug output after BGP session reset

BGP v3.23-17
Use debug ip bgp to display the negotiation of capabilities. Debugging displays received
capabilities.
The example shows that a neighbor is advertising both old-style and standard (new-style) route
refresh. After the session has been established, an initial standard route refresh message is sent
by the router for the address family 1/1 (IP version 4 [IPv4] unicast).
3-119
Monitoring Route Refresh (Cont.)
Debug output after route refresh

BGP v3.23-18
Debugging also shows a route refresh message being sent to a neighbor after the network
administrator issues the clear ip bgp ip-address in command from privileged EXEC mode.
3-120

This topic identifies the need to use route-maps to influence route selection in a BGP network.

Some scenarios require complex filters.
Filters on IP prefixes coming from specific AS number
Filters on other BGP attributes
In some cases, network administrators even need to modify

BGP attributes.
Route-maps provide a solution to both requirements.
BGP v3.23-19
Network administrators cannot achieve certain complex filtering goals by using a prefix-list
only or by using an AS-path filter-list only. Using both of these filters simultaneously means
that a route must be permitted by both to be accepted. Sometimes the goal is to permit a
specific prefix if it is received with a specific AS-path and to deny it otherwise.
Combinations of tests can be implemented using route-maps. A route-map is a powerful
filtering tool that can also modify routing information. Different attributes can have their values
set or changed by the route-map.
3-121
Summary
Summary
Because of the huge volumes of routing information that
BGP is capable of handling and the effects of a mass routing
update, BGP cannot use traditional routing update methods.
Soft reconfiguration provides the possibility to run all routes
through filters without tearing down the sessions.
The Cisco IOS commands that are required to configure and
perform a soft reconfiguration include the neighbor softreconfiguration router configuration command, which
configures Cisco IOS software to start storing updates and
the clear ip bgp EXEC command, which resets a BGP
connection using BGP soft reconfiguration.
BGP v3.23-20
Summary (Cont.)
The Cisco IOS tools that are available to monitor the
operation of a soft reconfiguration include the show ip bgp
command, which displays the local BGP table, the show ip
bgp neighbor ip-address routes command, which checks
incoming information that is received from a neighbor, and
the show ip bgp neighbor ip-address received command, which
displays the information that is saved in the extra copy
outside the filters.
The BGP Soft Reset Enhancement feature provides
automatic support for dynamic soft reset of inbound BGP
routing table updates that is not dependent upon stored
routing table update information. This method requires no
preconfiguration and needs much less memory than the
previous soft reset method for inbound routing table
updates.
3-122
BGP v3.23-21
Summary (Cont.)
Route refresh is a new BGP capability that is used to request
a neighbor to resend routing information after configuration
changes.
The clear ip bgp ip-address soft in command sends a route
refresh message to the neighboring router and executes if
the neighbor has previously advertised the route refresh
capability.
To verify that a neighbor supports route refresh, you can use
the show ip bgp neighbor command. To display the negotiation
process, you can use the debug ip bgp command.
Network administrators cannot achieve certain complex
filtering goals by using a prefix-list only or by using an ASpath filter list only. A route-map is a powerful filtering tool
that can also modify routing information.
BGP v3.23-22
3-123
3-124
Module Summary
Module Summary
The multihomed customer network must exchange BGP
information with both ISP networks. Dynamic routing is
required for full redundancy, and BGP is the only protocol
available that can be used in this scenario.
An AS-path filter is created by an AS-path access-list. The
access-list is applied to a set of routes from which to subset
can be selected.
Use prefix-lists to filter incoming or outgoing BGP updates to
neighbors and to filter routes that are being redistributed into
the BGP process from other routing protocols.
BGP v3.23-1

Outbound route filtering is a mechanism that is used to
minimize the number of updates that are requested from a
neighbor.
Route-maps provide a method to perform a variety of
compound, complex filtering operations (such as
dropping denied routes and modifying attributes of the
permitted routes) within a single tool.
Soft reconfiguration provides the ability to run all routes
through filters without tearing down the sessions.
BGP v3.23-2
3-125
This module discussed BGP route filtering and BGP route selection policies. The module
described multihomed BGP networks and identified the need for BGP route selection. This
module also addressed configuring BGP to influence route selection by using AS-path filters,
prefix-list filters, and route-maps. Outbound route filtering was also explained. In addition,
details about soft reconfiguration and route refresh were provided.
References
Cisco Systems, Inc. Sample Configuration for BGP with Two Different Service Providers
(Multihoming). http://www.cisco.com/warp/public/459/27.html.
Cisco Systems, Inc. Using Regular Expressions in BGP.
http://www.cisco.com/warp/public/459/26.html.
Cisco Systems, Inc. BGP Case Studies (see BGP Case Studies 3 section).
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1c
bgp.htm#xtocid15.
Cisco Systems, Inc. BGP Prefix-Based Outbound Route Filtering.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ft
11borf.htm.
Internet Engineering Task Force (IETF) Network Working Group. Cooperative Route
Filtering Capability for BGP-4.
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-12.txt
Cisco Systems, Inc. BGP Case Studies (see BGP Case Studies 1 section).
http://www.cisco.com/warp/public/459/bgp-toc.html#routemaps.
Cisco Systems, Inc. Compatible Systems Setup Guides: BGP Configuration Guide.
http://www.cisco.com/warp/public/707/cscsupport/setup_guides/bgp.html#bgpRouteMap.
Cisco Systems, Inc. BGP Soft Reset Enhancement.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/sft
rst.htm.
3-126
Module Self-Check
Q1)
What are two reasons why a customer would want to connect to two ISPs?
(Choose two.) (Source: Using Multihomed BGP Networks)
A)
B)
C)
D)
Q2)
What are the two technical requirements for multihomed customers? (Choose two.)
(Source: Using Multihomed BGP Networks)
A)
B)
C)
D)
Q3)
The ISPs must assign a range of IP network numbers to the customer.

The customer network must exchange BGP information with each ISP
network.
In most cases, the customer must have its own public AS number.
The customer network must not use AS-path filters.
Which of the following statements best illustrates the importance of BGP policies that
influence route selection in a multihomed BGP network? (Source: Using Multihomed
BGP Networks)
A)
B)
C)
D)
Q4)
to expand capacity for Internet traffic

to better protect confidential information as it travels through the Internet
to provide redundancy to mission-critical services that are offered over the
Internet
to efficiently route Internet traffic to two different divisions within the
company
The default BGP route selection does not always result in optimum routing.
The default BGP route selection always results in optimum routing.
After the route selection behavior has been set, it cannot be changed.
The customer receives all routes from both service providers, giving
redundancy; therefore, BGP policies are not necessary.
Which three of the following are potential customer routing policies? (Choose three.)
(Source: Using Multihomed BGP Networks)
A)
B)
C)
D)
E)
F)
One service provider is designated as primary, and the other is a backup.

Traffic is load-balanced across both ISP networks.
Traffic toward a specific destination goes through only one of the ISPs.
Traffic to direct customers of the ISPs goes direct; all other traffic goes through
the primary ISP.
The two ISPs may have similar peering agreements with other ISPs.
The ISPs use default routing to the customer, and the customer uses static
routing to the ISP (or ISPs).
3-127
Q5)
Which statement about the need to influence BGP route selection in a service provider
environment is accurate? (Source: Using Multihomed BGP Networks)
A)
B)
C)
D)
Q6)
Which two potential multihomed network issues can be prevented with IP prefix
filters? (Choose two.) (Source: Using Multihomed BGP Networks)
A)
B)
C)
D)
Q7)
F)
213 72 218 31 727

27 317 271 50 72
315 27 723 19 91
72 591 368 20 87
What is the difference between the regular expressions _100_ and _100$? (Source:
Employing AS-Path Filters)
A)
B)
C)
D)
3-128
to ensure that only locally originated routes are announced

to limit routes that are advertised from IBGP neighbors
to select a subset of all routes based on their originating AS
to limit neighbor route updates to specific AS-originated routes
to ensure that all destination autonomous systems should be received from a
specified neighbor
to change the weight or local preference attributes for all destination
autonomous systems
Which AS path is matched by the regular expression 72$? (Source: Employing ASPath Filters)
A)
B)
C)
D)
Q9)
the propagation of private AS numbers

the propagation of private addresses that are used in the network
the propagation of unreachable next-hop addresses
the propagation of more specific prefixes from an address range
Which three goals represent appropriate reasons to apply AS-path filters? (Choose
three.) (Source: Employing AS-Path Filters)
A)
B)
C)
D)
E)
Q8)
If both ISP connections terminate in one single customer router, only some
routes that are received from the primary ISP can be assigned a BGP weight.
In most cases, it is more optimal to reach other customers connected to the
backup ISP via the backup link, compared with reaching them via the primary
link.
All routes that are received from the primary ISP over the primary link are
assigned a local preference value, which is lower than the default value of 100.
When one ISP connection terminates in one single customer router, all routes
that are received from that ISP are assigned a BGP weight.
The first expression refers to routes that have the substring 100 in their AS
paths; the second expression refers only to routes that are directly connected to
AS 100.
The first expression refers to routes that have the substring 100 in their AS
paths; the second expression refers only to routes that originated in AS 100.
The first expression refers to routes that go through AS 100; the second
expression refers to routes that originated in AS 100.
The first expression refers to routes that are directly connected to AS 100; the
second expression refers to routes that originated in AS 100.
Q10)
How do you match AS paths that contain exactly two single-digit AS numbers?
(Source: Employing AS-Path Filters)
A)
B)
C)
D)
Q11)
Which three steps are required to apply a new inbound routing policy to a neighbor?
(Choose three.) (Source: Employing AS-Path Filters)
A)
B)
C)
D)
Q12)
to ensure that only valid IP prefixes are announced to the ISPs

to set a limit on the number of prefixes that can be accepted from the ISPs
to prevent the customer from receiving its own IP prefixes from the ISP
to verify that the customer has received full Internet route tables
Which three of the following choices are advantages of prefix-lists over access-lists?
(Choose three.) (Source: Filtering with Prefix-Lists)
A)
B)
C)
D)
E)
F)
Q15)
show ip bgp access-list command

show ip bgp filter command
show ip bgp regexp command
show ip bgp summary command
What are two reasons that a multihomed customer needs prefix-lists? (Choose two.)
(Source: Filtering with Prefix-Lists)
A)
B)
C)
D)
Q14)
Define an AS-path access-list.

Attach the AS-path filter to inbound or outbound updates for a specific BGP
neighbor.
Send incoming and outgoing AS-path filters to the BGP neighbor.
Force the updates to go through the new filter.
How can you test your regular expression? (Source: Employing AS-Path Filters)
A)
B)
C)
D)
Q13)
use the expression **

use the expression ..
use the expression [0-9]_[0-9]
use the expression ^[0-9]_[0-9]$
significant performance improvement on long filters

support for incremental updates
ability to consist of any number of lines, each of which indicates a test and a
result
flexibility
more complex command-line interface
sequential scanning of prefix-lists within Cisco IOS software
When you define prefix-lists, what are two reasons to use sequence numbers? (Choose
two.) (Source: Filtering with Prefix-Lists)
A)
B)
C)
D)
to reference the associated access-list for the prefix-list entry

to provide a means of linking an AS-path filter-list to the prefix-list
to provide an execution order for prefix-list entries
to provide a means of inserting or deleting list entries
3-129
Q16)
Which of the following statements is accurate about the ge and le parameters in the ip
prefix-list global configuration command required to configure prefix-list filters?
A)
B)
C)
D)
Q17)
Which of the following statements about implementing prefix-lists in a BGP network is

accurate? (Source: Filtering with Prefix-Lists)
A)
B)
C)
D)
Q18)
D)
standard BGP communities filtering

extended BGP communities filtering
AS-path filtering
prefix-list filtering
What are two key benefits to using outbound route filtering? (Choose two.) (Source:
Using Outbound Route Filtering)
A)
B)
C)
D)
3-130
not a feature of the show ip prefix-list command

by specifying the detail keyword
with the longer keyword to display all matches except those with more specific
entries
by specifying the first-match keyword
Which of the following best describes the capabilities of the proprietary ORF type that
is supported on Cisco routers? (Source: Using Outbound Route Filtering)
A)
B)
C)
D)
Q21)
by configuring a neighbor prefix-list statement for each BGP peer

by configuring a neighbor distribute-list statement for each neighbor
by using the BGP peer-group option with the neighbor statement
by configuring the prefix-list as a global filter under the BGP routing process
How can you use the show ip prefix-list command to display the prefix-list entry that
matches a specific prefix and length? (Source: Filtering with Prefix-Lists)
A)
B)
C)
Q20)
You can optionally apply filter-lists and prefix-lists on either incoming or

outgoing neighbors in any combination.
You can optionally apply filter-lists and prefix-lists only on outgoing neighbors
in any combination.
Either the incoming prefix-list or the incoming filter-list must permit the routes
that are received from a neighbor before they are accepted into the BGP table.
Outgoing routes must pass the outgoing prefix-list before being transmitted to
the neighbor.
How can you apply the same prefix-list to multiple BGP neighbors on a router?
A)
B)
C)
D)
Q19)
No match is assumed when neither ge nor le is specified.

The range is assumed to be from ge-value to 142 only if the ge attribute is
specified.
The range is assumed to be from len to 32 only if the le attribute is specified.
An exact match is assumed when neither ge nor le is specified.
conserves CPU cycles

improves security
reduces bandwidth that is used by unnecessary routing updates
increases neighbor availability
Q22)
Which two of the following statements about BGP prefix-based outbound route
filtering are accurate? (Choose two.) (Source: Using Outbound Route Filtering)
A)
B)
C)
D)
Q23)
How should you configure the neighbor capability orf prefix-list command on a
router that is applying a prefix-list filter as an outbound route policy? (Source: Using
Outbound Route Filtering)
A)
B)
C)
D)
Q24)
show running-config | begin bgp command

show ip bgp negotiate command
show ip bgp neighbors command
show ip prefix-list command
What are two prerequisites before you can configure ORF prefix-list functionality?
(Choose two.) (Source: Using Outbound Route Filtering)
A)
B)
C)
D)
Q26)
send
receive
both
prefix-filter
What are two methods of determining that a router has ORF capabilities exchange
configured? (Choose two.) (Source: Using Outbound Route Filtering)
A)
B)
C)
D)
Q25)
uses BGP ORF send and receive capabilities to minimize the number of BGP
updates that are sent between BGP peers
can limit the number of unwanted routing updates
increases the amount of resources required to receive and discard routes that
would otherwise be filtered out
can be used to increase the amount of processing on a router that is not
accepting full routes from a service provider network
A route refresh must be sent using the clear ip bgp command.

A BGP peering session between the ORF routers must be up and running.
ORF capabilities must be enabled on both routers.
You must configure a prefix-list filter on the receiving router.
Which of the following statements about the function of a route-map is accurate?

(Source: Applying Route-Maps as BGP Filters)
A)
B)
C)
D)
A route-map cannot be used to modify attributes of the permitted routes.

A route-map is a filter that uses a series of match conditions, and that which is
denied by the route-map is dropped.
A route-map is less complex than the access-list.
Each route-map statement starts with a series of match clauses.
3-131
Q27)
Which three of the following statements are accurate about the BGP Route-Map Policy
List Support feature? (Choose three.) (Source: Applying Route-Maps as BGP Filters)
A)
B)
C)
D)
E)
F)
Q28)
Which two of the following are functions of the BGP Route-Map Continue feature?
(Choose two.) (Source: Applying Route-Maps as BGP Filters)
A)
B)
C)
D)
Q29)
B)
C)
D)
By default, a route-map has an implicit permit any statement if no match is

found.
You must configure a route-map with a permit parameter and no match
clause.
You must configure a route-map with a deny parameter and a deny none
clause.
You must configure a route-map with a permit any match clause.
What happens to incoming BGP updates that do not match any route-map match
clauses? (Source: Applying Route-Maps as BGP Filters)
A)
B)
C)
D)
3-132
match ip next-hop
match ip address
show ip bgp route-map
How do you implement a permit all statement when you are using route-maps?
(Source: Applying Route-Maps as BGP Filters)
A)
Q31)
provides the ability to pause if a sequence number is not specified

provides the capability to execute additional entries in a route-map after an
entry is executed with successful match and set clauses
allows modularization of network policy configuration so that repeated policy
definitions can be expanded within the same route-map
allows configuration and organization of more modular policy definitions to
reduce the number of policy configurations that are repeated within the same
route-map
Which of the following commands is used to distribute any routes that have a
destination network number address that is permitted by a standard access-list, an
extended access-list, or a prefix-list, or to perform policy routing on packets? (Source:
Applying Route-Maps as BGP Filters)
A)
B)
C)
D)
Q30)
The BGP Route-Map Policy List Support feature allows a network operator to
group route-map match clauses into named lists called policy-lists.
The network operator manually reconfigures each recurring group of match
clauses that occur in multiple route-map entries.
The AND and OR semantics in the route-map function differently for policylists than for match and set clauses.
To create a BGP policy-list, use the ip policy-list command in policy-map
configuration mode.
To configure a route-map to evaluate and process a BGP policy-list in a routemap, use the match policy-list command in route-map configuration mode.
To display information about a configured policy-list and policy-list entries,
use the show ip policy-list command in route-map configuration mode.
They are entered into the BGP table.

They are entered into the BGP table and marked with a weight of 32768.
They are not accepted by the router or entered into the BGP table.
They are entered into the BGP table if a matching route exists in the IP routing
table.
Q32)
Which three BGP attributes can you set using route-maps? (Choose three.) (Source:
A)
B)
C)
D)
E)
F)
Q33)
What are two reasons for using route-map sequence numbers? (Choose two.) (Source:
A)
B)
C)
D)
Q34)
C)
D)
C)
D)
It clears the session after you reconfigure the new routing policy.
It creates a copy of all routes that are received from a neighbor after the filters
are applied.
It requires extra memory to hold a copy of all routes that are received from the
neighbor.
It resets the table version number of the neighbor to 0.
Which two steps must you complete to use inbound soft configuration functionality?
(Choose two.) (Source: Implementing Changes in BGP Policy)
A)
B)
C)
D)
Q37)
Clearing a BGP session takes a long time and can disrupt packet forwarding.
You cannot recover information that is sent while the BGP session is being
cleared.
You cannot automatically re-establish sessions that are torn down during the
clearing operation.
You cannot selectively tear down BGP sessions; you must clear sessions with
all neighbors.
What is the impact of inbound soft reconfiguration? (Source: Implementing Changes in

BGP Policy)
A)
B)
Q36)
to allow insertion or deletion of route-map entries

to order the execution sequence of route-map match clauses
to provide an ordered execution sequence for the route-map
to map between prefix-list statements and route-map match clauses
Why is clearing a BGP session a disruptive change in routing policy? (Source:

Implementing Changes in BGP Policy)
A)
B)
Q35)
MED
path origin
administrative distance
weight metric
next-hop
atomic aggregate
Clear the BGP session inbound on the local router.

Clear the BGP session outbound on the remote router.
Configure the local neighbor with the soft-reconfiguration in command.
Configure the remote neighbor with the soft-reconfiguration out command.
Match the functions to the tools used to monitor the operation of a soft reconfiguration.
(Source: Implementing Changes in BGP Policy)
A)
B)
C)
display which of the routes in the local BGP table were received (and accepted)
from the indicated neighbor
check the entries that have been propagated to a specific neighbor
display the information that is saved in the extra copy outside the filters
_____ 1.
show ip bgp neighbor ip-address received command
_____ 2.
show ip bgp neighbor ip-address advertised command
_____ 3.
show ip bgp neighbor ip-address routes command
3-133
Q38)
Which two of the following are functions of the BGP Soft Reset Enhancement feature?
(Choose two.) (Source: Implementing Changes in BGP Policy)
A)
B)
C)
D)
Q39)
Which of the following statements about the command that is required to perform a
route refresh is accurate? (Source: Implementing Changes in BGP Policy)
A)
B)
C)
D)
Q40)
B)
C)
D)
C)
D)
A flag in the BGP table indicates the presence of route refresh capability.
The show ip bgp neighbor command indicates whether the option is
supported.
Initiate the debug ip bgp negotiation command to see whether the router has
completed a route refresh capabilities exchange.
Execute the clear ip bgp * command. Command-line BGP status messages
will indicate route refresh support capabilities.
Which of the following statements about using route-maps as filters is accurate?

(Source: Implementing Changes in BGP Policy)
A)
B)
C)
D)
3-134
when there is insufficient memory to hold a copy of the BGP table of the
neighbor
when a route refresh fails
when you wish to troubleshoot filters and use the show ip bgp neighbor
command with the received-routes option
when the neighboring router does not support the route refresh capability
How do you determine whether a BGP neighbor supports route refresh? (Source:
Implementing Changes in BGP Policy)
A)
B)
Q42)
You will use the clear ip bgp * in command to send a route refresh message to
all neighbors.
You will use the clear ip bgp ip-address in command to send a route refresh
message to all neighbors.
You must use the soft keyword with the clear ip bgp command because soft
reset is not automatically assumed when the route refresh capability is
supported.
The clear ip bgp command works even if the neighbor has not previously
advertised the route refresh capability.
What are two situations in which you would prefer inbound soft reconfiguration to
route refresh? (Choose two.) (Source: Implementing Changes in BGP Policy)
A)
Q41)
allows dynamic route refresh requests

requires no preconfiguration
provides newer method for inbound soft reset that uses stored inbound routing
table updates
uses expanded memory
Network administrators can achieve certain complex filtering goals by using a

prefix-list only or by using an AS-path filter list only; therefore, route-maps are
not necessarily a good solution.
Combinations of tests cannot be implemented using route-maps; therefore, in
some cases, an AS-path filter list is preferred.
Route-maps have less capability for filtering than access-lists.
Route-maps provide both complex filters and a way to modify BGP attributes.

Q1)
A, C
Q2)
B, C
Q3)
Q4)
A, C, D
Q5)
Q6)
B, D
Q7)
A, C, D
Q8)
Q9)
Q10)
Q11)
A, B, D
Q12)
Q13)
A, C
Q14)
A, B, D
Q15)
C, D
Q16)
Q17)
Q18)
Q19)
Q20)
Q21)
A, C
Q22)
A, B
Q23)
Q24)
A, C
Q25)
B, C
Q26)
Q27)
A, D, E
Q28)
B, D
Q29)
Q30)
Q31)
Q32)
A, D, E
Q33)
A, C
Q34)
Q35)
Q36)
A, C
Q37)
1-C
2-B
3-A
Q38)
A, B
Q39)
Q40)
C, D
Q41)
Q42)
3-135
3-136
Module 4
Route Selection Using

Attributes
Overview
Routes learned via Border Gateway Protocol (BGP) have properties that are associated with
them that aid a router in determining the best route to a destination when multiple paths to that
particular destination exist. These properties are referred to as BGP attributes. This module
introduces the role of BGP attributes, and explains how their presence influences route
selection in BGP. Understanding how BGP attributes influence route selection is required for
the design of robust networks.
This module provides advanced information on how to connect Internet customers to multiple
service providers. It includes an in-depth description of BGP attributes that are used in route
selection, including weight, local preference, autonomous system (AS)-path prepending, multiexit discriminator (MED), and BGP communities.
Module Objectives
Upon completing this module, you will be able to complete the correct BGP configuration to
successfully connect the customer network to the Internet in a network scenario in which
multiple connections must be implemented This ability includes being able to meet these
objectives:
Successfully configure BGP to influence route selection by using the weight attribute in a
customer scenario in which you must support multiple ISP connections
Use the local preference attribute to influence route selection in a customer scenario in
which you must support multiple ISP connections
Use AS-path prepending to influence the return path that is selected by the neighboring
autonomous systems in a customer scenario in which you must support multiple ISP
connections
Use the MED attribute to influence route selection in a customer scenario in which you
must support multiple ISP connections
Use BGP community attributes to influence route selection in a customer scenario in which
you must support multiple ISP connections
4-2
Lesson 1
Influencing BGP Route

Selection with Weights
Overview
When connections to multiple providers are required, it is important that Border Gateway
Protocol (BGP) select the optimum route for traffic to use. The optimum, or best, route may not
be what the network designer intended based on design criteria, administrative policies, or
corporate mandate. Fortunately, BGP provides many tools for administrators to influence route
selection. One of these tools is the weight attribute.
This lesson discusses how to influence BGP route selection by setting the weight attribute of
incoming BGP routes. Two methods that are used to set the weight attribute, default weight and
route-maps, are discussed in this lesson. This lesson also explains how to monitor the BGP
table to verify correct weight configuration and properly influence path selection.
Objectives
selection by using the weight attribute in a customer scenario in which you must support
multiple ISP connections. This ability includes being able to meet these objectives:
List BGP route selection criteria for best-path route selection
Describe the use of BGP weights to influence the BGP route selection process
Influence the BGP route selection process by configuring per-neighbor weights
Influence the BGP route selection process by configuring BGP weights with route-maps
Identify the Cisco IOS commands that are required to monitor BGP route selection
and weights
Summarize BGP route selection and filtering tools

This topic lists the criteria that are used by BGP for best-path route selection.
Prefer highest weight (local to router)

Prefer highest local preference (global within AS)
Prefer routes that the router originated
Prefer shorter AS paths (only length is compared)
Prefer lowest origin code (IGP < EGP < Incomplete)
Prefer lowest MED
Prefer external (EBGP) paths over internal (IBGP)
For IBGP paths, prefer path through closest IGP neighbor
For EBGP paths, prefer oldest (most stable) path
Prefer paths from router with the lower BGP router-ID
BGP v3.24-3
BGP route selection criteria take the weight parameter into consideration first. If a router has
two alternative paths to the same destination, and their weight values are different, BGP selects
the route with the highest weight value as the best. Only when the two alternatives have equal
weight is the next criterion, local preference, checked.
A high local preference value is preferred over a low value. Only when the two alternatives
have an equal local preference is the next criterion checked.
4-4

This topic describes how network administrators can use BGP weights to influence the BGP
route selection process.

BGP routing policy can be specified by using:
Weight: provides local routing policy (within a router)
Local preference: provides AS-wide routing policy
BGP weights are specified per neighbor.

Default weight
AS-path-based weight
Complex criteria with route-maps
BGP v3.24-4
The weight attribute is local to a single router only. The weight value is never propagated by
the BGP protocol, and this value constitutes a routing policy local to the router.
Local preference is assigned to a route as an attribute. This attribute is carried with the route on
all internal BGP sessions. In this situation all other BGP-speaking routers within the
autonomous system (AS) receive the same information. Normally, a router assigns a local
preference to a route that is received on an external BGP session before it is accepted and
entered in the BGP table of the border router. Routers propagate the local preference attribute
on internal BGP sessions only. This policy constitutes a routing policy for the entire AS.
The router can assign the weight attribute to a route in two ways:
All routes that are received from a specific neighbor can be assigned a default weight value.
This weight value indicates that the neighbor is preferred over the other neighbors.
A route-map that is applied on incoming routes from a neighbor can be used to select some
routes and assign them weight values. Remember that a route-map also acts as a filter and
will silently drop the routes that are not permitted by any statement in the route-map.
If configured, the default weight assignment on routes that are received from a neighbor is
applied first. All routes that are received from the neighbor are assigned a weight value as
defined by the default weight.
4-5
When a route-map is applied, it is configured on the router. The route-map can be arbitrarily
complex and select routes based on various selection criteria, such as a network number or AS
path. The selected routes can have some attributes altered. The route-map can set the weight
values of permitted routes. Selection can be done in several route-map statements, giving the
opportunity to assign a certain weight value to some routes and another weight value to others.
A route-map can also completely filter out routes.
4-6

This topic describes how to influence the BGP route selection process by configuring perneighbor weights.
All routes from the BGP neighbor get the specified weight.
BGP routes with higher weight are preferred.
Weight is applied only to new incoming updates.
To enforce new weights, reestablish BGP sessions with your
neighbors by using the clear ip bgp command.
BGP v3.24-5
neighbor weight
To assign a weight to a neighbor connection, use the neighbor weight router configuration
command.
neighbor {ip-address | peer-group-name} weight weight
To remove a weight assignment, use the no form of this command.
no neighbor {ip-address | peer-group-name} weight weight
Syntax Description
Parameter
Description
Weight to assign. Acceptable values are 0 to 65535.
All routes that are received from the neighbor after the configuration line is in place are
assigned the weight value. To make sure that all routes from the neighbor receive the new
weight value, you can restart the BGP session, forcing the neighbor to resend all routes.
If no weight value is specified, the default value of 0 is applied.
4-7
Restarting BGP sessions might be necessary after making a configuration change in the routing
policy. The configuration change itself will not alter the already-received routes. The clear ip
bgp EXEC command tears down the BGP session, and the session automatically restarts.
4-8
Example: Configuring Per-Neighbor Weights

In this example, the multihomed customer would like to use the primary link to the primary
Internet service provider (ISP) for all destinations.
Configuring Per-Neighbor Weights (Cont.)
Routes received from primary ISP should be preferred over routes

received from backup ISP.
BGP v3.24-6
The weight is configured by the customer on both BGP sessions, giving a higher weight to the
routes that are received from the primary ISP compared to those that are received from the
backup ISP.
Any time that the multihomed customer receives routing information about the same IP
network number from both the ISPs, the customer compares the weights assigned to the routes.
Those received from the primary ISP will always win this comparison. The multihomed
customer sends the outgoing IP packets to the destination network via the primary ISP
regardless of the other BGP attributes that are assigned to both alternatives.
Consequently, the other customer that is directly connected to the backup ISP will also be
reached via the primary ISP.
4-9
Configuring Per-Neighbor Weights (Cont.)
BGP v3.24-7
In this example, the multihomed customer has received routes to three different class A
networks outside of its own AS (network 21.0.0.0/8, network 37.0.0.0/8, and network
40.0.0.0/8). The customer has received all three routes from both the primary ISP and the
backup ISP.
When the routes were received from the primary ISP, the weight value 150 was assigned to
each of the routes. When the routes were received from the backup ISP, the weight value 100
was assigned to each of the routes.
The customer router now makes the route selection. It has two alternative paths for each
destination network. For each of them, the router selects the path via the primary ISP as the
best. It makes this selection regardless of other BGP attributes, such as AS-path length.
The network 21.0.0.0/8 is reached via the primary ISP although it is actually a network in the
AS of the backup ISP (AS 21).
The class A network 1.0.0.0/8 in this example is injected into the BGP table by this router. By
default, locally sourced routes are assigned a weight of 32768.
4-10

This topic describes how to influence the BGP route selection process by configuring BGP
weights with route-maps.

Weights can be set with route-maps in complex scenarios.
Routes can be matched on any combination of prefix-lists,
AS-path filters, or other BGP attributes.
Routes not matched by the route-map are discarded.
BGP v3.24-8
The route-map is a powerful tool to select and alter routing information. When a route-map is
applied to incoming information from a BGP neighbor, each received update is examined as it
passes through the route-map. Statements in the route-map are executed in the order that is
specified by their sequence numbers.
The first statement in the route-map for which all the match clauses indicate a match is the one
that is used. If the route-map says permit, the set clauses are applied to the route, the route is
accepted, and the weight is changed.
Match clauses can be arbitrarily complex. One of them can refer to an AS-path access-list that
does matching on AS paths. Another can refer to a prefix-list that does matching on the
announced network number. Only when all configured match clauses are evaluated is the routemap statement used and its result, permit or deny, applied.
If a received route is not matched by any of the route-map statements, and the end of the routemap is reached, the route-map logic has an implicit deny rule. This rule means that if no
statement selects a route, the route is discarded.
If the implicit deny rule is not desired, an explicit permit all at the end of the route-map can
overrule it. To ensure that such a route-map statement is the last statement, you should assign it
a very high sequence number. It should not have any match clause at all. The lack of a match
clause means match all. By not configuring any set clause, you can ensure that no attributes
are altered by the statement.
4-11
Example: Changing Weights with Route-Maps

This example shows a route-map that sets the weight value to each route that it receives from a
neighbor.
Changing Weights with Route-Maps (Cont.)

Set weight 200 to networks coming from 2.3.4.5
originated in AS 21.
BGP v3.24-9
All received routes have their AS paths checked against the AS-path access-list 47. Those
routes with an AS path that indicates that they originated in AS 21 are permitted by the AS-path
access-list 47 as referenced by route-map statement number 10. Routes that are permitted and
selected by route-map statement number 10 in the w200 route-map will have their weight set to
200 as indicated by the set clause in the route-map.
The routes that are not originated in AS 21 (routes that are not permitted by AS-path access-list
47) are then tested by route-map statement number 20. This statement does not include a match
clause, indicating that all routes are matched. Therefore, all routes that are not matched by
route-map statement 10 are matched by route-map statement 20. The route-map has been
configured with an explicit permit all statement at the end of the route-map.
Routes that are matched by route-map statement 20 have their weight set to 100. The result is
that the routes that originated in AS 21 are accepted by the router and assigned the weight 200.
All others are accepted and assigned the weight 100. No route is discarded by this route-map.
Note
4-12
Specifying weights with filter-lists is no longer supported in Cisco IOS Software Release
12.1, and the command has already been removed from Cisco IOS Software Release
12.1T. These releases use an incoming route-map, where you match an AS path with the
match as-path command and set the weight with the set weight command. When you are
using a route-map as a replacement for the filter-list with the weight option, make sure that
specifying a permit entry in the route-map without an associated match condition does not
filter all other routes. Using route-maps as a weight-setting mechanism is explained later in
this lesson.
Monitoring BGP Route Selection and Weights

This topic lists the Cisco IOS commands that are required to monitor BGP route selection and
weights.
Monitoring BGP Route

Selection and Weights

Displays all BGP routes
Best routes marked with >
Weight associated with every route displayed

Displays detailed information about all paths for a single prefix
BGP v3.24-10
show ip bgp
Syntax Description
Parameter
Description
(Optional) Network number that is entered to display a particular

network in the BGP routing table
(Optional) Displays all BGP routes that match the address-mask

pair
(Optional) Displays a route and its more specific routes
Without any argument, the show ip bgp command displays the entire BGP table. The routes
that are selected as the best are indicated by the greater-than (>) character.
To get more detailed information about routes to a specific destination network, you can use the
network number, and optionally the subnet mask, as an argument on the command line. These
additions display more detailed information about that specific network.
4-13
Example: Monitoring BGP Route Selection and Weights

The figure shows all routes in the BGP table.

Selection and Weights (Cont.)
BGP v3.24-11
The show ip bgp command provides a printout of all routes in the BGP table. Each route is
displayed on one line. This one-line limitation means that more detailed information about the
route cannot be displayed because of lack of space.
The network number is displayed, and if the subnet mask differs from the natural mask, the
prefix length is indicated. The BGP next-hop attribute, multi-exit discriminator (MED), local
preference, weight, AS-path, and origin code are displayed on the line. Local preference is
displayed only if it is not the default value.
The printout is sorted in network number order. If there is more than one route to the same
network, the network number is printed on the first line only. The other routes to the same
network have their network field left blank on the output.
Routes that are selected as the best to reach a certain destination network are indicated by the
greater than (>) character.
In this example, weight has been used to prefer routes received from the neighbor in AS 37.
Therefore, although the AS path is shorter via AS 213, the class A network 10.0.0.0/8 is
reached via AS 37 (because the weight is higher).
Network 12.0.0.0 is local with the self-originated path selected as best resulting in the next-hop
address of 0.0.0.0 and a weight of 32768.
Information about network 14.0.0.0/8 is received only from the neighbor in AS 387. Because
there is no alternative, the route is selected as best.
4-14

Selection and Weights (Cont.)
BGP v3.24-12
The show ip bgp command with a network number as an argument displays more detailed
information about that network only. First, a short summary that indicates the network number
and prefix length is displayed, along with the table version number for this route. The next line
indicates how many alternative routes have been received and which one of them has been
selected by the router as the best.
Next, there are a couple of lines for each of the received routes to reach the network. For each
of the routes, all attributes are displayed. The one selected as the best also has the word best
displayed.
In this example, there are two alternatives to reach network 11.0.0.0/8. Each of them is received
from different neighbors in AS 213. The network 11.0.0.0 is created in AS 213.
The route selection mechanism has selected the first route that is listed as the best. It was
chosen because the MED (metric) value is lower.
4-15
BGP Route Selection and Filtering Tools

Summary
This topic presents a summary of all BGP filtering tools in the order in which they are applied.
BGP Route Selection and

Filtering Tools Summary
BGP v3.24-13
The figure shows all the possible applications of prefix-lists, filter-lists, weights, and routemaps. They are applied in the order indicated.
Prefix-lists and filter-lists, both in and out, filter out routes and discard those that are not
permitted. Weight setting is applicable only on incoming routes because a router never
propagates the weight attribute to its neighbors. Route-maps can be filters that discard routes
but can also be used to modify and set various attributes on both incoming and outgoing routes.
4-16
Summary
Summary
A number of criteria are used by BGP for best-path route
selection.
BGP weights can be used to influence the BGP route
selection process; all routes that are received from a
specific neighbor can be assigned a default weight value, or
a route-map that is applied on incoming routes from a
neighbor can be used to select some routes and assign
them weight values.
You can use the neighbor weight command to assign a weight
value to all routes that are received from a neighbor.
BGP v3.24-14
Summary (Cont.)
Route-maps can be applied to neighbors to set the weight
attribute of received routes.
You can use the show ip bgp command to display all bgp
routes, the routes that are selected by BGP as best, and the
weight attribute setting for each route.
BGP route selection and filtering tools (prefix-lists, filter-lists,
weights, and route-maps) are applied in a specific order.
BGP v3.24-15
4-17
4-18
Lesson 2

Overview
selection. One of these tools is the local preference attribute.
This lesson discusses how to influence BGP route selection by setting the BGP local preference
attribute of incoming BGP routes. Local preference is similar to the weight attribute but differs
from the BGP weight attribute in that weight is local to a specific router on which it is
configured. Two methods that are used to set the local preference attribute, default local
preference and route-maps, are discussed in this lesson. This lesson also explains how to
monitor the BGP table to verify correct local preference configuration and to properly influence
path selection.
Objectives
Upon completing this lesson, you will be able to use the local preference attribute to influence
route selection in a customer scenario in which you must support multiple ISP connections.
Explain why using BGP weights might not provide consistent BGP route selection in an AS
Describe how the BGP local preference attribute influences BGP route selection
Identify the Cisco IOS command that is required to configure default BGP local preference
on a router
Identify the Cisco IOS commands that are required to configure BGP local preference
using route-maps
Identify the Cisco IOS commands that are required to monitor BGP local preference
Consistent Route Selection Within the AS

This topic explains why using BGP weights might not provide consistent BGP route selection
inside an autonomous system (AS).
Consistent Route Selection

Within the AS
Q1: Which routing protocol must be run in AS 213?

A1: You must run IBGP in AS 213.
BGP v3.24-3
Using BGP in autonomous systems with a single neighbor relationship usually does not require
any advanced features. In situations like the one shown in the figure, however, it is important to
ensure that customer routers choose the correct link. Obviously, the router should choose the
2-Mbps link and use the 64-kbps link only for backup purposes.
To make sure that the router selects the upper link (2-Mbps link) as its primary link and has the
ability to switch over to the backup if a failure occurs, you must configure an Internal Border
Gateway Protocol (IBGP) session between the two border routers in AS 213.
4-20

Within the AS (Cont.)
Q2: How will you influence the route selection on routers

in AS 213 so that they select the fastest route?
A2: Use weights on EBGP and IBGP sessions.
BGP v3.24-4
One way of changing the default route selection is to use weights. Weight is an attribute that is
locally significant to a router. Weight is a property, or parameter, and is, therefore, not seen on
any neighboring routers. When designing BGP networks using weights, network administrators
should set the weights on every router. If there is more than one path for the same network, a
router will choose the one with the highest weight. The default value for weight is 0.
In this example, the upper router in AS 213 sets a weight of 100 for routes that are received
over the 2-Mbps link from AS 462 (primary link) and prefers them to possible internal updates
from the bottom router, where the default weight is 0. The bottom router sets a weight of 100
for internal routes that are received from the upper router and prefers them to routes that are
received from AS 387. As a result, all packets will leave the AS through the primary 2-Mbps
link.
4-21

BGP v3.24-5
The configurations that are shown in the figure demonstrate how to change the default weight
on a per-neighbor basis. If you use the neighbor weight command, all newly arrived updates
will have a weight of 100. Updates coming from the other neighbor will still have the default
weight of 0.
After you have applied the neighbor weight command, a refresh is needed from the neighbor.
There are three ways of doing this, depending on the Cisco IOS version:
Use the clear ip bgp neighbor address command to clear the neighbor relationship and
re-establish it to refresh the BGP entries and apply the weight.
Configure soft reconfiguration for the neighbor and use the clear command. You can
perform all subsequent clearing by using the clear ip bgp neighbor address soft in
command, which does not reset the neighbor relationship. The soft reconfiguration feature
is supported by Cisco starting with Cisco IOS Software Release 11.2.
Use the clear ip bgp neighbor address in command if both neighboring routers support
the route refresh. The route refresh feature is available from Cisco starting with Cisco IOS
Software Release 12.1.
See the module Route Selection Using Policy Controls for a detailed description of the
commands here.
4-22
Example: Consistent Route Selection Within the AS

The figure shows two of the routers in AS 213 with two route-maps.

Have the traffic run over the fastest line available.
BGP v3.24-6
This example is more complex. When you are trying to implement this example with weights, it
requires two route-maps on each router within AS 213. Luckily, BGP has a similar mechanism
that you can use for consistent AS-wide route selection: local preference.
4-23

This topic describes how the BGP local preference attribute influences BGP route selection.

You can use local preference to ensure AS-wide route
selection policy.
Any BGP router can set local preference when
processing incoming route updates, when doing
redistribution, or when sending outgoing route
updates.
Local preference is used to select routes with equal
weight.
Local preference is stripped in outgoing EBGP updates
except in EBGP updates with confederation peers.
BGP v3.24-7
Local preference is similar to weight; because it is an attribute, you can set it once and then
view it on neighboring routers without having to reset it. This attribute has a default value of
100, which the router will apply to locally originated routes and updates that come in from
external neighbors. Updates that come from internal neighbors already have the local
preference attribute.
Local preference is the second-strongest criterion in the route selection process. If there are two
or more paths available for the same network, a router will first compare weight, and if the
weights are equal for all paths, the router will then compare the local preference attributes. The
path with the highest local preference value will be preferred.
The local preference attribute is automatically stripped out of outgoing updates to External
Border Gateway Protocol (EBGP) sessions. This practice means that you can use this attribute
only within a single AS to influence the route selection process.
4-24
BGP Local Preference (Cont.)

Local preference is the second strongest BGP route selection
parameter.
Remember the BGP route selection rules:
Highest weight preferred (local to router)
Highest local preference preferred (global within AS)
Other BGP route selection rules
Weights configured on a router override local preference

settings.
To ensure consistent AS-wide route selection:
Do not change local preference within the AS.
Do not use BGP weights.
BGP v3.24-8
Local preference is the second-strongest BGP route selection parameter. Remember the route
selection rules:
1. Prefer the highest weight (local to router).
2. Prefer the highest local preference (global within AS).
3. Process all remaining BGP route selection rules.
Because network administrators can use both weight and local preference to manipulate the
route selection process, they must decide which one to use. If local preference is used, the
weight should be the same for all paths.
Network administrators can use weight on an individual router to override local preference
settings that are used in the rest of the AS.
In most cases, it is enough to change the default local preference on updates coming from
external neighbors. Network administrators should avoid changing the local preference attribute
on internal sessions to prevent unnecessary complexity and unpredictable behavior.
4-25
BGP Local Preference (Cont.)
BGP v3.24-9
Network administrators can apply local preference in the following ways:

Use a route-map with the set local-preference command. You can use the route-map on
incoming updates from all neighbors or on outgoing updates to internal neighbors (not
recommended).
Use the bgp default local-preference command to change the default local preference
value that is applied to all updates that come from external neighbors or that originate
locally.
4-26

This topic describes the Cisco IOS command that is required to configure default BGP local
preference on a Cisco router.

This command changes the default local preference value.
The specified value is applied to all routes that do not have
local preference set (EBGP routes).
The default value of this parameter is 100, allowing you to
specify more desirable or less desirable routers.
BGP v3.24-10
You can use the bgp default local-preference command in BGP configuration mode to change
the default value of local preference. The new default value applies only to locally originated
routes and those that are received from external neighbors.
Setting a value lower than the default of 100 will result in the router preferring internal paths to
external (normally a router would prefer external routes).
Setting a value higher than 100 will result in external paths being preferred to all internal paths
(also those with a shorter AS path).
4-27
Example: Configuring Default Local Preference

In the figure, the local preference attribute is used instead of weights.
Configuring Default Local

Preference (Cont.)
BGP v3.24-11
The two indicated routers in AS 213 have different default local preference values that are
applied to external updates. The bottom router receives updates from the external neighbor and
applies local preference to them. The same router then receives updates from the upper router,
which set a local preference of 120 to all external updates. The bottom router then compares all
paths and, where two paths exist, chooses the one with the higher local preference (120).
4-28
Configuring Local Preference with Route-Maps

This topic lists the Cisco IOS commands that are required to configure BGP local preference
with route-map statements.
Configuring Local Preference

with Route-Maps
Changes BGP local preference only for routes matched by the

route-map entry
Applies route-map to incoming updates from specified neighbor

or outgoing updates to specified neighbor
Per-neighbor local preference configured by using a route-map
with no match condition
BGP v3.24-12
To have more control over setting local preference, you may be forced to use a route-map. A
route-map can have more sequenced statements, each with a different set local-preference
command and a different match condition. If there is no match command, the route-map
statement will apply local preference to all routes. The route-map can then be applied to BGP
route updates in either the incoming or outgoing direction.
Note
Applying a route-map to outgoing updates on external sessions will have no effect on local
preference in the neighboring AS.
When routers use a route-map to set local preference, the route-map is typically applied to
incoming BGP routes that are advertised by an EBGP neighbor. The local router uses the local
preference attribute in BGP route selection. In addition, the router also propagates the attribute
to all IBGP sessions in the local AS. Normally, no modifications of local preference are made
on IBGP sessions. This restriction ensures that all routers in the local AS use the same local
preference value and make the same decision in the route selection process.
Note
If a network is not matched in any of the route-map statements, the network will be filtered.
To permit unmatched networks without setting the local preference attribute, you should add
another route-map statement without match or set commands to the end of the route-map.
This statement should simply permit the remaining networks.
4-29
Example: Configuring Local Preference with Route-Maps

In this example, both routers in AS 213 have two external sessions.
Configuring Local Preference

with Route-Maps (Cont.)
BGP v3.24-13
Using the bgp default local-preference command is no longer possible because the secondfastest link is on another router.
The configuration here sets local preference according to the bandwidth of the link. A similar
configuration exists on the bottom router. If the primary (2-Mbps) link fails, the paths that are
learned through the bottom router in AS 213 (routes with a local preference of 512) will be
used.
4-30

This topic lists the Cisco IOS commands that are necessary to monitor BGP local preference.

Nondefault local preference is displayed in the show ip bgp
printout.
Local preference is displayed in the show ip bgp prefix
printout.
Local preference is displayed in BGP update debugging
(only for inbound updates, starting with Cisco IOS Software
Release 12.0).
BGP v3.24-14
Although local preference is not a mandatory attribute, it is applied to every route. When you
are using the show ip bgp command, a locally applied default value is not shown. All other
values are displayed. You should use the show ip bgp prefix command to also display the
locally applied value.
The output that is displayed from show and debug commands will vary depending on the Cisco
IOS version. Newer versions typically display more information. In Cisco IOS Software
Release 12.0 and in later versions, enabling debugging of incoming routing updates will also
display the local preference attribute.
4-31
Example: Monitoring Local Preference

In the figure, the network shown was used to collect output from the show and debug
commands in the next few examples.
Monitoring Local Preference (Cont.)
BGP v3.24-15
Every physical connection also includes a BGP session. All monitoring and troubleshooting
commands were used on router RTR-A.
RTR-A has one internal and two external neighbors. RTR-B is setting local preference 100 for
all updates, and RTR-A is setting a default local preference (value 60) for all external updates
except for those coming from router RTR-D, where a route-map is used to set a local
preference of 90. The following pages show the output of show and debug commands on
router RTR-A.
4-32

Nondefault local preference is displayed in the show ip bgp
printout.
BGP v3.24-16
The output in the figure contains routes with three different local preference values:
Network 10.0.0.0/8 originates locally on RTR-A, and the applied default local preference
60 is not displayed.
The second path for network 12.0.0.0/8 was received from RTR-D and received a local
preference value of 90 by the route-map.
All routes that are received from router RTR-B are marked as internal and have a local
preference value of 100 set on RTR-B.
Note
The output of the show ip bgp command will not display the local preference value if the
value is the same as the bgp default local-preference value in the local router. In the
example, RTR-B uses its default local preference value (100). When these routes are
propagated to RTR-A, RTR-A displays the local preference value of 100 because it is
different from the default local preference value that is configured on RTR-A.
4-33

All values for local preference are displayed in the show ip bgp
prefix printout.
BGP v3.24-17
Use the show ip bgp prefix command to see more detailed information about a specific
network, including the locally applied default local preference.
In this example, there are three paths to reach the same network:
The first path is external and was received from router RTR-C. The new default local
preference value 60 was applied to the update.
The second path is external and was received from router RTR-D. The route-map was used
to set a local preference of 90.
The third path is internal and was received from RTR-B. The update already contained a
local preference attribute with a value of 100.
Router RTR-A chose the last path as best because it has the highest local preference.
4-34

Local preference received in a BGP update is displayed in
debugging outputs in Cisco IOS Software Release 12.0 and later.
BGP v3.24-18
This figure shows the debugging output of incoming BGP updates. Because a router propagates
the local preference attribute to other routers in the same AS only, local preference will be
associated with routes sent from internal neighbors.
4-35
Summary
Summary
Local preference is similar to the weight attribute in that you
can use both to influence BGP path selection, but it differs
from the BGP weight attribute in that weight is local to the
specific router on which it is configured.
You can use local preference to ensure AS-wide route
selection policy because it can be seen on neighboring
routers without the need to reset it.
You should avoid mixing weight and local preference
because weight has priority when you are selecting the best
path.
Local preference can be configured using either the bgp
default local-preference preference command or with route-map
statements.
You can display local preference with the show ip bgp or show
ip bgp prefix commands. The former displays only nondefault
local preference settings.
4-36
BGP v3.24-19
Lesson 3
Using AS-Path Prepending

Overview
When connections to multiple providers are required it is important that Border Gateway
selection. One of these tools is autonomous system (AS)-path prepending.
Problems can arise when administrative policies mandate a specific return path be used for
traffic returning to the AS, but AS-path prepending potentially allows the customer to influence
the route selection of its service providers. This lesson describes AS-path prepending and the
Cisco IOS commands required to properly configure and monitor AS-path configurations and
filtering requirements for influencing route selection using AS-path prepending.
Objectives
Upon completing this lesson, you will be able to use AS-path prepending to influence the return
path that is selected by the neighboring autonomous systems in a customer scenario where you
must support multiple ISP connections. This ability includes being able to meet these
objectives:
Explain the need to influence BGP return path selection in a service provider environment
Describe the function of AS-path prepending and how you can use it to facilitate proper
return path selection
Identify design considerations when you are implementing AS-path prepending to
influence return path selection
Identify the Cisco IOS commands that are required to configure AS-path prepending in a
multihomed network
Identify the Cisco IOS commands that are required to monitor the operation of AS-path
prepending
Describe the concerns with using AS-path filters when neighboring autonomous systems
require AS-path prepending
Describe the function of the BGP Hide Local-Autonomous System feature in combining
separate BGP networks under a single AS
Return Path Selection in a Multihomed AS

This topic describes the need to influence BGP return path selection in a service provider
environment.
Return Path Selection in a

Multihomed AS
Requirement: The return traffic to the customer must arrive over the
highest-speed access link.
BGP v3.24-3
It is fairly easy for an AS to select the appropriate path for outgoing traffic. It is much more
complicated to influence other autonomous systems to select the appropriate path for traffic that
is returning to a specific AS.
To configure the preferred path only for outgoing traffic and not for incoming (return) traffic is
likely to result in asymmetrical traffic flow as well as suboptimal performance of the return
traffic. In the figure, outgoing traffic is directed to the high-speed line (2 Mbps) as a result of
configuring local preference or weight. However, the return traffic from AS 387 would take the
default path over the low-speed line (64 kbps). The low-speed line would be a limiting factor in
the overall performance that the network could achieve.
In this example, AS 213 requests AS 387 to send packets toward network 10.0.0.0/8 via AS
462. The reason for this request is to improve network performance and minimize delay
(assuming, of course, that the connectivity between AS 387 and AS 462 is better than the direct
64-kbps link between AS 387 and AS 213).
4-38
Default Return Path
Result: The return traffic flows over the path with the shortest AS-path
length.
BGP v3.24-4
If no BGP path selection tools are configured on the route to influence the traffic flow, AS 387
will use the shortest AS path. This action will result in unwanted behavior because the return
traffic to AS 213 will be sent over the low-speed WAN link.
AS 213 announces network 10.0.0.0/8 over EBGP sessions to both AS 462 and AS 387. When
AS 213 sends EBGP updates, it changes the AS-path attribute according to BGP specifications.
Both AS 462 and AS 387 receive a BGP update for network 10.0.0.0/8 with the AS path set to
213.
Because AS 462 selects the route for network 10.0.0.0/8 that it received from AS 213 as its best
route, AS 462 uses that route and forwards it to AS 387. According to BGP specifications, AS
462 also changes the AS-path attribute. AS 387 receives the route to network 10.0.0.0/8 from
AS 462 with an AS path set to 462 213.
AS 387 has now received two alternative routes to network 10.0.0.0/8 (the direct route from AS
213 and the route through AS 462). Because nothing is configured in AS 387 to influence the
flow of traffic, the router will use the BGP route selection rule of shortest AS path to select the
best return path to network 10.0.0.0/8.
4-39
Proper Return Path Selection
Q: How do you select the proper return path from AS 387?

A: Use local preference in AS 387.
Q: Will the administrator of AS 387 configure it?
A: Unlikely.
BGP v3.24-5
Remember that the incoming traffic flow (from the perspective of AS 213) will be a result of
the route selection for outgoing traffic in AS 387. The traffic that is going out from AS 387 will
end up as incoming traffic in AS 213.
If AS 387 configures some changes that cause the route selection process for outgoing traffic to
prefer to reach network 10.0.0.0/8 via AS 462, the changes would result in behavior matching
the desired administrative policy for AS 213, which specifies that incoming traffic to the AS
should be received over the high-speed link.
One way to accomplish the desired administrative policy in AS 213 is to configure the router in
AS 387, which is receiving EBGP updates directly from AS 213, to assign a local preference
value less than the default value (100) to all routes that are received from AS 213. The router in
AS 387 is also configured specifically not to set local preference on External Border Gateway
Protocol (EBGP) routes that are received from AS 462. This configuration results in
assignment of the default value of 100 to all routes received from AS 462. When the route
selection process in AS 387 selects the best route to reach network 10.0.0.0/8, the difference in
local preference values causes AS 387 routers to select the path via AS 462 as the best.
However, all the configuration work to complete this process must be performed in AS 387.
The network administrators of AS 387 would be required to modify the router configurations in
AS 387 to satisfy the administrative policy requirements of AS 213. All changes must be
documented and maintained according to the rules and procedures that have been adopted by
AS 387.
If AS 387 is a major Internet service provider (ISP), the network administrators most likely are
too busy doing other things to tailor router configurations that are based on the demand of a
single leaf (nontransit) AS that lacks bandwidth on a redundant connection.
4-40
BGP Route Selection Rules

BGP route selection uses the following criteria:
Prefer largest weight.
Prefer largest local preference.
Prefer routes that the router originated.
Prefer shorter AS paths.
Use other route selection rules.
Manipulating the outgoing AS-path length could result in proper

return path selection.
BGP v3.24-6
Recall that BGP route selection uses the following criteria:

Prefer the largest weight.
Prefer the largest local preference.
Prefer routes that the router originated.
Prefer shorter AS paths.
Then, prefer all other route selection criteria.
It is unlikely that the operator of an AS can request changes in router configurations in another
AS. This limitation makes it virtually impossible to influence another AS to select the desired
path based on the weight and local preference attributes, because both options would require
configuration changes in the neighboring AS.
But if both the weight and the local preference parameters are left at their default settings, they
will not indicate a difference. This configuration causes the route selection process to continue
down the list of selection criteria. The third criterion for selection will not influence route
selection in this scenario, because none of the routes originated at the router that is performing
the route selection. The fourth criterion will apply, however, because the AS paths have
different lengths.
If the AS path is not manually manipulated by some administrative means, the path going over
the fewest number of autonomous systems is selected by the router regardless of available
bandwidth. However, if the AS that is attempting to influence the incoming traffic flow is
sending out EBGP updates with a manipulated AS-path attribute over that undesired path, the
receiver of this update is less likely to select it as the best because the AS path now appears to
be longer.
The benefit of manipulating AS paths to influence the route selection is that the configuration
that is needed is done in the AS that is requesting a desired return path.
4-41
AS-Path Prepending
This topic describes the function of AS-path prepending and how you can use it to facilitate
proper return path selection.
AS-Path Prepending
Manual manipulation of AS-path length is called AS-path
prepending.
The AS path should be extended with multiple copies of the
AS number of the sender.
AS-path prepending is used to:
Ensure proper return path selection
Distribute the return traffic load for multihomed customers
BGP v3.24-7
You can manipulate AS paths by prepending AS numbers to existing AS paths. Normally, you
perform AS-path prepending on outgoing EBGP updates over the nondesired return path.
Because the AS paths sent out over the nondesired link become longer than the AS path sent
out over the preferred path, the nondesired link is now less likely to be used as the return path.
The length of the AS path is extended because additional copies of the AS number of the sender
are prepended to (added to the beginning of) the AS-path attribute. To avoid clashes with BGP
loop prevention mechanisms, no other AS number, except that of the sending AS, should be
prepended to the AS-path attribute.
If another AS number is prepended in the AS path, the routers in the AS that has been
prepended will reject the update because of BGP loop prevention mechanisms.
You can configure prepending on a router for all routing updates that you send to a neighbor or
only on a subset of them.
4-42
Example: AS-Path Prepending

In this example, administrative policy in AS 213 prefers that the low-speed link be used for
backup purposes only.
AS-Path Prepending (Cont.)
Result: The return traffic flows over the desired return path.
BGP v3.24-8
As long as the high-speed link between AS 213 and AS 462 is available, all traffic should flow
toward AS 213 using the high-speed link.
To accomplish this goal, you can configure the router in AS 213 that sends EBGP updates to
AS 387 by prepending the AS path with two copies of the AS number 213. AS 387 receives
two alternative routes to reach network 10.0.0.0/8: the update that it has received directly from
AS 213 (that has a manipulated AS path with a length of three) and the update that it has
received via AS 462 (that was not manually manipulated and therefore contains an AS-path
length of two).
When AS 387 starts the route selection process to determine which route to use to reach
network 10.0.0.0/8, it checks the AS-path length after the weight and local preference
parameters. In this case, neither weight nor local preference has been configured, so the length
of the AS path will be the deciding factor in the route selection process. Consequently, AS 387
prefers the shortest AS path and thus forwards packets toward network 10.0.0.0/8 via AS 462.
The desired administrative policy has been met, and AS 213 will receive incoming traffic over
the high-speed link.
If the forwarding path from AS 387 via AS 462 to AS 213 and network 10.0.0.0/8 is later
broken, the BGP update to reach network 10.0.0.0/8 is revoked. In case of such a network
failure, AS 387 will have only one remaining path to reach network 10.0.0.0/8. The route
selection process now has only one choice, the route directly to AS 213 over the low-speed
WAN link. The low-speed link will therefore serve as backup to the high-speed WAN link.
4-43
AS-Path Prepending (Cont.)
Prepend the AS path with the AS number of the sender, not the AS
number of the receiver.
BGP v3.24-9
When you are manually manipulating AS paths, the only valid AS number that you can
prepend is the AS number of the sender. Prepending any other AS number will cause problems.
In the example, AS 213 is prepending AS number 387. The egress router performs AS-path
prepending when the route is on its way to be transmitted to AS 387. After the manual
manipulation, BGP automatically changes the AS path according to the BGP specifications.
The local AS number should always be added first when updates are sent over an EBGP
session. Therefore, when AS 387 receives the BGP update, the AS path contains the value 213
387. The AS number 387 was set by the manual manipulation, and the AS number 213 was
prepended automatically by BGP because the update was sent over an EBGP session.
When the edge router in AS 387 receives the BGP update, it checks the AS path to verify that
the BGP updates were not propagated accidentally by a routing loop. Because the edge router
finds its own AS number in the AS path, it assumes that the BGP update has already been in
AS 387. According to the BGP specification, the update will be silently ignored.
Now assume that AS 213 had, for the manual manipulation, used a different AS number, not its
own and not AS number 387. Would AS 387 now have accepted the update? The answer is yes.
However, in this scenario, a problem would have appeared at a later stage when the route
finally reached the actual AS belonging to the manually prepended AS number. This AS would
have rejected the route because it would have found its own AS number somewhere in the AS
path.
4-44
AS-Path Prepending Design Considerations

This topic identifies design considerations when you are implementing AS-path prepending to
influence return path selection.
AS-Path Prepending
Design Considerations
There is no exact mechanism to calculate the required
prepended AS-path length.
If a primary and backup scenario is desired:
Use a long prepended AS path over the backup link to ensure that the
primary AS path will always be shorter.
A long backup AS path consumes memory on every Internet router.
Experiment with various AS-path lengths until the backup link
is idle.
Add a few more AS numbers for additional security (unexpected changes in
the Internet).
If traffic load distribution is desired:

Start with a short prepended AS path, monitor link use, and extend the
prepended path length as needed.
Continuously monitor the link use and change the prepended
AS-path length if required.
BGP v3.24-10
How many copies of the AS number of the sender should you prepend to the AS path? The
answer depends on the goals of the administrative policy. In the general case, it is not easy to
determine the exact number of required AS numbers to prepend. The sending AS does not
know what alternative paths are available to other autonomous systems.
The following are two typical cases in which you can use AS-path prepending for return path
selection:
Establishing a primary/backup link: As an announced backup (prepended) route
propagates through the Internet, all the routers along the way that receive the route need to
store it together with its AS-path attribute. If this information is long, it will consume extra
memory in these routers. However, because routers forward only routes that are selected as
best, an AS that receives multiple alternatives to a destination will select the route with the
shortest AS path and forward only that route.
In the case where both the primary and the secondary link are up, the neighboring AS will
receive two routes to the same destination that differ only in the AS-path length. The route
with the shorter AS path will be subsequently advertised through the Internet.
In the case where the primary link fails, the route with the longer AS path is the only
remaining route. As a result, the primary route is withdrawn, and the prepended route is
advertised through the Internet. In this case, extra memory will be consumed in each
Internet router because of the storage of the prepended (longer) AS path.
4-45
The longer the AS path that is announced to the EBGP neighbor on the other side of the
backup link, the less likely it is that incoming traffic will be received from that neighbor.
The network administrator can make a clever guess about how many copies of the AS
number to prepend. After the prepending is implemented, the network administrator has to
examine the result. If the expected result is not achieved, the configuration can be changed
and a few more copies of the AS number can be prepended.
After AS-path prepending has generated the desired results, the network administrator may
take the precaution of prepending a few more copies of the AS number to the AS path. This
action protects the customer from packets being routed over the backup link at a possible
later stage when the topology between remote autonomous systems has unexpectedly
changed, yielding a longer AS path to reach the primary link.
Distributing the load of return traffic: In a multihomed scenario, there is no way to
exactly predetermine the volume of traffic that will be received over a particular link. The
traffic load on different links will change depending on where the senders are located
(which autonomous systems they belong to). The network topology and the way that
different remote autonomous systems are interconnected may also change with time,
changing the load distribution. Only constant monitoring and fine-tuning will ensure that
the desired results are achieved.
In a first attempt at load distribution, the network administrator can configure a router that
is connected to an overused link to prepend only a few extra copies of the local AS number.
After the network has been given time to converge, the network administrator must check
the change in load distribution. Monitoring of the load must be done for a period long
enough to be statistically significant (several days or more). If enough volume of traffic has
not moved from the overused link to the underused link, the administrator must prepend
more copies of the local AS number, and the process of resending local routes and
monitoring the results starts all over again.
4-46

This topic identifies the Cisco IOS commands that are required to configure AS-path
prepending in a multihomed network.
Prepends the specified AS number sequence to the routes

matched by the route-map entry
AS numbers prepended to the AS path from the BGP table; the
AS number of the sender always prepended to the end result
Applies the route-map to outgoing updates sent to the specified

BGP neighbor
BGP v3.24-11
You can configure manual manipulation of the AS-path attribute (prepending) using a routemap with the set as-path prepend command. The route-map is used to prepend the specified
AS numbers to outgoing EBGP route updates that are matched with the match condition, as
specified in the route-map. AS-path prepending is completed first, and then the route is subject
to the normal AS-path modification procedures when it is sent over an EBGP session.
You can also use the route-map to select only a subset of routes that should have their AS path
manually manipulated. Use the set as-path prepend command with the appropriate route-map
permit statement.
Note
Changing an outgoing route-map affects only the BGP updates that are sent after the
change. To propagate the new and longer AS path with all announced routes, the routes
must all be resent by the router. To do this, use the privileged EXEC command clear ip bgp
with the soft out qualifier.
set as-path
To modify an AS path for BGP routes, use the set as-path route-map configuration command.
set as-path {tag | prepend as-path-string}
To not modify the AS path, use the no form of this command.
no set as-path {tag | prepend as-path-string}
4-47
Syntax Description
Parameter
Description
Converts the tag of a route into an AS path

Applies only when redistributing routes into BGP
Appends the string that follows the keyword prepend to the AS

path of the route that is matched by the route-map
Applies to inbound and outbound BGP route-maps
4-48
Example: Configuring AS-Path Prepending

In this example, the lower router in AS 213 is configured to prepend its own AS number five
times for all updates that are sent to the EBGP neighbor 1.0.0.2 in AS 387.
Configuring AS-Path Prepending (Cont.)
BGP v3.24-12
This configuration will result in AS 387 receiving a route to network 10.0.0.0/8 with an AS
path containing the AS number 213 six times (213 213 213 213 213 213). In accordance with
BGP specifications, Cisco IOS software automatically adds the sixth copy of the AS number as
the route leaves AS 213.
The configuration of the AS 213 router is completed in two steps:
Step 1
First, a route-map named prepend is created. The route-map selects all BGP routes
and prepends five copies of 213 to the existing AS-path attribute that is already
attached to each route. The lack of match conditions in the route-map indicates that
all routes are matched.
Step 2
The route-map is applied to all outgoing updates to the EBGP neighbor 1.0.0.2.
4-49

This topic identifies the Cisco IOS commands that are required to monitor the operation of ASpath prepending.

AS-path prepending cannot be monitored or debugged
on the sending router.
debug ip bgp updates displays the BGP entry prior to routemap processing.
show route-map does not display how many routes have
matched a route-map entry.
Results of AS-path prepending can be observed on the

receiving router.
BGP v3.24-13
When you are monitoring AS-path prepending, the router doing the prepending is not the
proper point to observe the results of the AS-path prepend operation. For instance, output from
the debug ip bgp updates command does not display the prepended paths, because the routemap doing the prepending is applied afterward.
The show route-map command displays the configuration details of a route-map. The
matching criteria and AS-path manipulation are displayed as output of the command. However,
there is no indication of how many routes have been matched by a route-map statement and
thus had their AS paths manipulated.
A better place for observing AS-path prepending is on the router receiving the BGP update that
contains the prepended AS path. At that point, you can use the pattern of AS number sequences
in the received AS-path attribute of received routes to find the routes that have a prepended AS
path.
4-50
Monitoring AS-Path Prepending (Cont.)

Displays all BGP routes with AS paths matching a regular
expression
BGP v3.24-14
In the figure, the show ip bgp regexp command is used to find all the routes in the BGP table
of the receiving router in AS 387 that are directly received from AS 213 and have at least one
extra copy of AS number 213 in their AS path. Network 10.0.0.0/8 is displayed as the only
route meeting this selection criterion. The AS path has been prepended with two extra copies of
AS 213. The egress router in AS 213 automatically added the third copy of AS 213 because the
route was sent across an EBGP session.
4-51
AS-Path Filtering Concerns with AS-Path

Prepending
This topic describes the concerns of using AS-path filters when neighboring autonomous
systems require AS-path prepending.
AS-Path Filtering Concerns? AS-Path

Prepending
Service providers usually use AS-path filters to control

incoming BGP updates from their customers.
BGP v3.24-15
Service providers normally expect their customers to send routes that originate only in the AS
of the customer. However, because customers might not do so, proactive thinking and care for
the rest of the Internet cause the service provider to implement AS-path filters on incoming
updates that are received from their customers.
The network administrator of the service provider in the figure could configure individual
filters for each neighbor. However, a single AS-path access-list permitting only AS paths with a
length of exactly one AS number would be a better solution because the service provider can
uniformly apply it to all incoming routes from all customers (possibly using a peer group).
In the figure, the service provider (AS 387) has configured a filter-list, which allows only AS
paths that have a length of one AS number. When the customer changes its router configuration
and starts to announce network 10.0.0.0/8 with a prepended AS path, the filter-list for incoming
routes to AS 387 in the service provider router will filter those routes out. This filtering results
in a situation where the network 10.0.0.0/8 is not reachable over the link between AS 213 and
AS 387. Therefore, the backup function is not available.
Network 10.0.0.0/8 is, however, still reachable via the path going through AS 462. This
situation means that AS 387 can send packets to network 10.0.0.0/8 but not over the direct link
to AS 213. This failure may be hard to detect because, during normal conditions, all
autonomous systems in the figure can exchange traffic.
After AS 387 loses the route to network 10.0.0.0/8 via AS 462, possibly because the primary
link between AS 213 and AS 462 is gone, the problem will be obvious. AS 387 can now no
longer reach network 10.0.0.0/8 at all, although the physical link between AS 213 and AS 387
is available.
4-52

Prepending (Cont.)
The incoming AS-path filters of the service provider
need to be modified to support AS-path
prepending.
To support AS-path prepending, service providers
should implement regular expression variables to
create a uniform AS-path filter for all customers.
Example: ^([0-9]+)(_\1)*$
BGP v3.24-16
Because the AS of the service provider will receive customer routes with prepended AS-paths
that have a length greater than one AS number, the provider must modify its incoming filters.
The service provider needs to create a new inbound regular expression filter, using regular
expression variables and parentheses for recall.
What is needed is a filter that will allow any AS path containing one or multiple copies of the
same AS number. An example of such a filter is as follows:
^([0-9]+)(_\1)*$
This filter matches any AS path beginning with any AS number and continues with no or
multiple repetitions of that same AS number (the variable \1 repeats the value in the
brackets). The regular expression would therefore match AS paths 99 99 99, 2 2 2, or 100, but
it would not match AS path 100 99.
4-53

Prepending (Cont.)
BGP v3.24-18
In the figure, the service provider (AS 387) has configured an individual filter for all routes that
are received directly from AS 213. The AS path is required to start with 213. Then multiple
copies of 213 may follow it. The asterisk allows for zero occurrences, permitting the AS path
with a single copy of 213 as well.
If the same service provider router has more customers that are attached to it, they will all
require an individual filter-list because the AS number of the customer is explicitly indicated in
the regular expression.
An alternative would be to implement the AS-path filter by using regular expression variables.
4-54

This topic describes how the BGP Hide Local-Autonomous System feature simplifies the task
of changing the AS number in a BGP network.

Feature
Allows you to transparently change the AS number
for the entire BGP network
Ensures that routes can be propagated throughout
the AS
neighbor local-as command in address family or
router configuration mode allows customization of
the AS number for EBGP peer groupings
BGP v3.24-19
Changing the AS number may be necessary when two separate BGP networks are combined
under a single AS, a situation that typically occurs when one ISP purchases another ISP.
Changing the AS number in a BGP network can be difficult because, during the transition,
Internal Border Gateway Protocol (IBGP) peers will reject external routes from peers with a
local AS number in the AS number path to prevent routing loops. The BGP Hide LocalAutonomous System feature allows you to transparently change the AS number for the entire
BGP network and ensure that routes can be propagated throughout the AS, while the AS
number transition is incomplete.
neighbor local-as
To allow customization of the AS number for EBGP peer groupings, use the neighbor local-as
command in address family or router configuration mode.
neighbor {ip-address | peer-group-name} local-as as-number [no-prepend]
no neighbor {ip-address | peer-group-name} local-as as-number
4-55
Syntax Description
Parameter
Description
IP address of the local BGP-speaking neighbor.
Valid AS number from 1 to 65535.

Do not specify the AS number to which the neighbor belongs.
Configures the router to not prepend the local AS number to any

routes received from an external peer.
The neighbor local-as command is used initially to configure BGP peers to support two local
AS numbers to maintain peering between two separate BGP networks. This configuration
allows the ISP to immediately make the transition without any impact on existing customer
configurations. When the customer configurations have been updated, the next step is to
complete the transition from the old AS number to the new AS number.
When the neighbor local-as command is configured on a BGP peer, the local AS number is
automatically prepended to all routes that are learned from EBGP peers by default. This
behavior, however, makes changing the AS number for a service provider or large BGP
network difficult because routes with the prepended AS number will be rejected by IBGP peers
that are configured with the same AS number. For example, if you configure an IBGP peer with
the neighbor 10.0.0.2 local-as 20 statement, all routes that are learned from the 10.0.0.2
external peer will automatically have the AS number 20 prepended. Internal routers that are
configured with the AS number 20 will detect these routes as routing loops and reject them.
This behavior requires you to change the AS number for all IBGP peers at the same time.
4-56
Summary
Summary
If the preferred path for incoming (return) traffic is not
configured, the likely result is an asymmetrical traffic flow as
well as suboptimal performance of the return traffic.
AS-path prepending is performed on outgoing EBGP
updates over the nondesired return path or the path where
the traffic load should be reduced.
You should use a long prepended AS path over the backup
link to ensure that the primary AS path will always be
shorter. However, care should be taken because a long
backup AS path consumes memory.
Manual manipulation of the AS-path attribute (prepending) is
configured using a route-map with the set as-path prepend
command.
Monitoring AS-path prepending is best accomplished on the
router that is receiving the prepended routes because the
prepended path will not be visible on the prepending router.
BGP v3.24-20
Summary (Cont.)
You can use the show ip bgp regexp command to find all the
routes on the receiving router with prepended AS paths.
Service providers with customers that use AS-path
prepending must create new AS-path filters using specific
AS-path entries or with regular expression variables to
accommodate AS-path lengths greater than one AS number.
The BGP Hide Local-Autonomous System feature allows you
to transparently change the AS number for the entire BGP
network and ensure that routes can be propagated
throughout the AS, while the AS number transition is
incomplete.
BGP v3.24-21
4-57
4-58
Lesson 4
Understanding BGP Multi-Exit

Discriminators
Overview
Protocol (BGP) select the optimum route for traffic to use. It is equally important that the return
path that is selected be the optimum return path into the autonomous system (AS). The
optimum, or best, route may not be what the network designer intended based on design
criteria, administrative policies, or corporate mandate. Fortunately, BGP provides a tool for
administrators to influence route selection, the multi-exit discriminator (MED) attribute.
This lesson discusses how to influence BGP route selection by setting the BGP MED attribute
of outgoing BGP routes. Two methods that are used to set the MED attribute, the default MED
and route-maps, are discussed in this lesson. In addition to basic MED attribute configuration,
advanced commands to manipulate MED properties are discussed, as well as how to monitor
and troubleshoot the BGP table to verify correct MED configuration and to properly influence
path selection.
Objectives
Upon completing this lesson, you will be able to use the MED attribute to influence route
selection in a customer scenario in which you must support multiple ISP connections. This
Describe how the MED can be used to facilitate proper return path selection
Explain how the value of the MED attribute changes inside a BGP AS and between
different BGP autonomous systems
Identify the Cisco IOS command that is required to configure changes to the default BGP
MED on a Cisco IOS router
Identify the Cisco IOS commands that are required to configure the BGP MED using routemaps
Identify the Cisco IOS commands that are required to configure advanced MED features on
Cisco routers
Identify the Cisco IOS commands that are required to monitor the BGP MED
Identify the Cisco IOS commands that are required to troubleshoot the BGP MED
configurations

This topic describes how you can use the MED attribute to facilitate proper return path
selection.
Q: How can you make sure that the return traffic takes the right
path?
BGP v3.24-3
When multiple connections between providers are required, BGP attributes such as weight and
local preference solve only half the problem: how to choose the right path out of the AS. This
topic focuses on the second, more complex half of the problem: how to influence neighboring
autonomous systems to choose the correct return path back into the AS.
4-60
Multi-Exit Discriminator
You can use the MED to influence path selection in neighbor
autonomous systems.
An AS can specify its preferred entry point using the MED in
outgoing EBGP updates.
The MED is not propagated outside of a receiving AS.
The default value of the MED attribute is 0.
The MED is called the metric in Cisco IOS software.
The MED is a weak metric.
A lower MED value means more preferred.
BGP v3.24-4
The MED attribute is a hint to external neighbors about the preferred path into an AS when
multiple entry points exist. You can apply the MED attribute on outgoing updates to a
neighboring AS to influence the route selection process in that AS. The MED attribute is useful
only when there are multiple entry points into an AS.
The MED attribute, which is sent to an external neighbor, will be seen only within that AS. An
AS that receives a route that contains the MED attribute will not advertise that MED beyond its
local AS.
The default value of the MED attribute is 0. A lower value of the MED attribute indicates a
more preferred path.
The MED attribute is considered a weak metric. In contrast with weight and local preference,
a router will prefer a path with the smallest MED value but only if the weight, local preference,
AS-path, and origin code attributes are equal. Using the MED may not yield the expected result
if the neighboring AS modifies any of the stronger BGP route selection mechanisms.
Note
The term that is used in Cisco IOS software for MED is metric. The term metric also
applies to the set command that is used in route-maps as well as all show and debug
commands.
4-61

This topic explains how the value of the MED attribute changes inside a BGP AS and between
different BGP autonomous systems.
BGP v3.24-5
The figure shows how the value of the MED attribute is assigned, depending upon the routing
information source. A route-map must be configured on a router to manually assign a value to
the MED attribute. For the networks that are also present in the BGP table, the router assigns a
default value from the metric in the routing table and copies it into the MED attribute. The
MED attribute is automatically removed on external sessions if the attribute did not originate in
the local AS.
4-62

This topic describes the Cisco IOS command that is required to configure changes to the default
BGP MED on a Cisco IOS router.

The MED is copied from the IGP cost in the router that sources
the route (through the network command or through route
redistribution).
You can change the MED value for redistributed routes with the
default-metric command.
BGP v3.24-6
The MED is not a mandatory attribute, and there is no MED attribute that is attached to a route
by default. The only exception is if the router is originating networks that have an exact match
in the routing table (through the network command or through redistribution). In that case, the
router uses the metric in the routing table as the MED attribute value.
Using the default-metric command in BGP configuration mode causes all redistributed
networks to have the specified MED value.
default-metric (BGP)
To set the default metric (MED) value for BGP routes, use the default-metric command in
router configuration mode.
default-metric number
To return to the default state, use the no form of this command.
no default-metric number
Syntax Description
Parameter
Description
Default metric value that is appropriate for the specified routing

protocol
4-63

This topic lists the Cisco IOS commands that are required to configure changes to the BGP
MED attribute with route-map statements.
Changes MED for routes matched by the route-map entry
Applies a route-map to incoming updates from a specified

neighbor or to outgoing updates to a specified neighbor
Per-neighbor MED configured by using a route-map with no
match condition
BGP v3.24-7
You can use a route-map to set the MED on incoming or outgoing updates. Use the set metric
command within route-map configuration mode to set the MED attribute.
4-64
Example: Changing the MED with Route-Maps

The example shows how to set a per-neighbor MED on an outgoing update.
Changing the MED with Route-Maps (Cont.)
BGP v3.24-8
The result of this action is that the neighboring AS will prefer the upper link to AS 213. The
solution, of course, relies on the neighboring AS not changing the weight, local preference,
AS-path, or origin code attributes in updates that it receives from AS 213.
4-65

This topic lists the Cisco IOS commands that are required to configure advanced MED features
on Cisco routers.
By default, the MED is considered only during selection of

routes from the same AS.
With always-compare-med, the MED is also considered for routes
coming from a different AS.
If the MED is not attached to a BGP route, it is interpreted as

value 0, and thus as the best metric.
With this command, a missing MED is interpreted as infinity
(worst).
BGP v3.24-9
Several rules exist on when and how you should use the MED attribute:
You should use the MED in the route selection process only if both (all) paths come from
the same AS. Use the bgp always-compare-med command to force the router to compare
the MED even if the paths come from different autonomous systems. You need to enable
this option in the entire AS; otherwise, routing loops can occur.
According to a BGP standard describing MED, you should regard a missing MED attribute
as an infinite value. Cisco IOS software, on the other hand, regards a missing MED
attribute as having a value of 0. Use the bgp bestpath med missing-med-worst command
when combining equipment from different vendors. An even better solution is to make sure
that every update carries a MED attribute.
4-66
Advanced MED Configuration (Cont.)
By default, the MED is considered only during selection of

routes from the same AS, which does not include intraconfederation autonomous systems.
Use this command to allow routers to compare paths learned
from confederation peers.
This command changes the BGP route selection procedure to a

deterministic but slower one.
BGP v3.24-10
You must use the bgp bestpath med confed command when you use the MED within a
confederation to influence the route selection process. A router will compare MED values for
the routes that originate in the confederation.
When you enable a deterministic MED comparison, you allow a router to compare MED values
before it considers BGP route type (external or internal) and Interior Gateway Protocol (IGP)
metric to the next-hop address. The router will compare MED values immediately after the
AS-path length.
Note
Cisco recommends enabling the bgp deterministic-med command in all new network
rollouts. For existing networks, you must deploy the command either on all routers at the
same time or incrementally, with care to avoid possible IBGP routing loops.
4-67
Example: Advanced MED Configuration

The following example demonstrates how the bgp deterministic-med and bgp alwayscompare-med commands can influence MED-based path selection. Consider the following
BGP routes for network 172.16.0.0/16 in the order that they are received:

Note
BGP compares multiple routes to a single destination in pairs, starting with the newest entry
and moving toward the oldest entry (starting at the top of the list and moving down). For
example, entry 1 and entry 2 are compared. The better of these two is then compared to
entry 3, and so on.
In the case where both commands are disabled, BGP compares entry 1 and entry 2. Entry 2 is
chosen as the better of these two because it has a lower router-ID. The MED is not checked
because the paths are from a different neighbor AS. Next, entry 2 is compared to entry 3. BGP
chooses entry 2 as the best path because it is external.
In the case where the bgp deterministic-med command is disabled and the bgp alwayscompare-med command has been enabled, BGP compares entry 1 to entry 2. These entries are
from different autonomous systems, but because the bgp always-compare-med command is
enabled, the MED is used in the comparison. Entry 1 is the better of these two entries because it
has a lower MED value. Next, BGP compares entry 1 to entry 3. The MED is checked again
because the entries are now from the same AS. BGP chooses entry 3 as the best path.
In the case where the bgp deterministic-med command has been enabled and the bgp alwayscompare-med command has been disabled, BGP groups routes from the same AS together and
compares the best entries of each group. The BGP table looks like the following:

There is a group for AS 65100 and a group for AS 65500. BGP compares the best entries for
each group. Entry 1 is the best of its group because it is the only route from AS 100. BGP
compares entry 1 to the best of group AS 65500, entry 2 (because it has the lowest MED).
Because the two entries are not from the same neighbor AS, the MED is not considered in the
comparison. The EBGP route wins over the IBGP route, making entry 1 the best route.
If the bgp always-compare-med command were also enabled, BGP would have taken the
MED into account for the last comparison and have selected entry 2 as the best path.
4-68
Monitoring the MED

This topic lists the Cisco IOS commands that are required to monitor the BGP MED attribute
on a Cisco router.
Monitoring the MED

The MED is displayed in show ip bgp [prefix] printout as the
metric field.
The MED after route-map processing is displayed in BGP
update debugging.
The MED received from a neighbor is displayed in show ip bgp
neighbor received-routes printouts.
BGP v3.24-11
All BGP-related show and debug commands display the value of the MED attribute. If the
inbound soft reconfiguration feature is enabled on the router, the original MED attribute that is
received by the router is also displayed. The following examples demonstrate command output
for Cisco show ip bgp commands.
4-69
Example: Monitoring the MED

This example illustrates monitoring the BGP table to verify correct MED configurations.
Monitoring the MED (Cont.)
BGP v3.24-12
The same network used in the previous lesson on BGP local preference is used in this topic to
produce the sample output that follows. All commands were executed on router RTR-C.
Some routing updates from router RTR-B are sent to router RTR-C with a MED of 500. Some
updates from RTR-B to RTR-C have the MED set to 0, and some are without a MED attribute.
Inbound soft reconfiguration is used on router RTR-C.
4-70

MED is displayed in show ip bgp printout.
BGP v3.24-13
Both networks that are received from router RTR-B have a MED of 500. Network 10.0.0.0/8,
which is received from RTR-A, has no MED attribute, while network 11.0.0.0/8 has a MED
value of 0.
4-71

MED values are also displayed in show ip bgp prefix printout.
BGP v3.24-14
When looking at detailed information for a specific network, you will see the MED (via the
show ip bgp prefix command) only if the attribute exists.
4-72

This topic lists the Cisco IOS commands that are required to troubleshoot BGP MED
configurations on a Cisco router.

MED sent to a neighbor (after the outgoing route-map) is
displayed in debugging outputs.
BGP v3.24-15
If debugging is necessary to troubleshoot a problem, the MED, among other attributes, is

displayed. This example shows the MED attribute set with an outgoing route-map.
4-73
Troubleshooting the MED (Cont.)

MED stored in the BGP table (after the incoming route-map
processing) is displayed in debugging outputs.
BGP v3.24-16
This debugging example shows the MED attribute value after the update has been processed by
an incoming route-map.

Original MED received from a neighbor (before the incoming
route-map processing) is displayed in show ip bgp neighbor
received.
BGP v3.24-17
To see the original MED, you need to enable soft reconfiguration on the router. The show ip
bgp neighbor address received-routes command displays the original updates before any
filters or route-maps have filtered or changed them.
4-74

Both original route and modified route are displayed with a
route-map when inbound soft reconfiguration is configured.
BGP v3.24-18
If soft reconfiguration is enabled, the original updates to the MED attribute are available by
using the show ip bgp prefix command. The original versions are marked with the receivedonly keyword and follow the version that is in the global BGP table. In the figure, the received
update had no MED attribute but a value of 1000 was later applied through a route-map.
4-75
Summary
Summary
The MED is a weak parameter in the route selection
processit is used only if weight, local preference, AS path,
and origin code are equal. By default, the MED is compared
only for paths that were received from the same AS.
The MED is not a mandatory attribute and is normally not
present in BGP updates, except when a router originates a
network that has an exact match in the routing tablethe MED
is given a value copied from the metric in the routing table.
There is no MED attribute that is attached to a route by default,
so to set the default metric value (MED) for BGP routes, use the
default-metric command in router configuration mode.
You can use a route-map to set an arbitrary MED value to sent
or received routes.
BGP v3.24-19
Summary (Cont.)
You can configure advanced MED parameters to modify the
default MED behaviors. For example, the bgp always-comparemed command forces the router to compare the MED even if
paths came from different autonomous systems, and you
must use the bgp bestpath med confed command when you
use the MED within a confederation to influence the route
selection process
The MED is displayed in show commands as the metric field.
The MED that was stored in the BGP table after processing
the incoming route-map is displayed in the output of the
debug ip bgp update command.
4-76
BGP v3.24-20
Lesson 5

Overview
When connections to multiple Internet service providers (ISPs) are required, it is important that
Border Gateway Protocol (BGP) select the optimum route for traffic to use. It is equally
important that the return path that is selected be the optimum return path into the autonomous
system (AS). The optimum, or best, route may not be what the network designer intended based
on design criteria, administrative policies, or corporate mandate. Fortunately, BGP provides
tools for administrators to influence route selection. The BGP community attribute is one such
tool.
This lesson discusses how to influence BGP route selection by setting the BGP community
attribute on outgoing BGP routes and describes BGP communities and their use to facilitate
proper return path selection. The configuration details of BGP communities and the use of
community-lists and route-maps to influence route selection are also discussed. This lesson
concludes by explaining how to monitor BGP community attributes.
Objectives
Upon completing this lesson, you will be able to use BGP community attributes to influence
route selection in a customer scenario where you must support multiple ISP connections. This
Describe the issues of return path selection for multihomed customers and why you cannot
use the BGP attributes of weight, local preference, and MED to solve these issues
Describe the basic qualities of BGP communities
Describe how BGP communities facilitate proper return path selection
List the steps that are required to successfully deploy communities in a BGP-based network
Identify the Cisco IOS commands that are required to configure route tagging with BGP
communities
Identify the Cisco IOS command that is required to enable BGP community propagation
Identify the Cisco IOS commands that are required to match routes based on attached BGP
communities using community-lists
Describe the function of the BGP Named Community Lists feature
Describe the function of the BGP Cost Community feature

Describe the function of the BGP Link Bandwidth feature
Describe how BGP supports sequenced entries in extended community-lists
Identify the Cisco IOS command that is required to match routes based on attached BGP
communities using route-maps
Identify the Cisco IOS commands that are required to monitor BGP communities
4-78

This topic describes the issues of return path selection for multihomed customers and why you
cannot use the BGP attributes of weight, local preference, and multi-exit discriminator (MED)
to resolve these issues.
Q:
A:
How do you select the proper return path from AS 387 without using AS-path prepending
in AS 213?
Use local preference in AS 387.
Q:
A:
Will the administrator of AS 387 configure it?

Unlikely.
BGP v3.24-3
In this example, the customer and the backup service provider would like to avoid AS-path
prepending and rely on other BGP tools to properly route the return traffic over the highestspeed WAN link.
Using the MED to influence the preferred return path is not possible because the MED cannot
be propagated across several autonomous systems. AS 387 would, therefore, receive networks
from AS 213 directly with the MED attribute but would receive networks without a MED
attribute from AS 462. In any case, BGP route selection would be based on the length of the AS
path, and even if the MED was present and used the shortest path, the path would still be
through the slow 64-kbps link.
The only option for resolving this issue is to use local preference in AS 387. The problem with
this solution is that service providers normally do not rush to implement every wish that their
customers might have.
This lesson describes a solution to this case study that uses the transitive optional attribute
called BGP community in conjunction with local preference.
4-79

This topic describes the basic qualities of BGP communities.

BGP communities are a means of tagging routes to ensure
consistent filtering or route selection policy.
Any BGP router can tag routes in incoming and outgoing
routing updates or when doing redistribution.
Any BGP router can filter routes in incoming or outgoing
updates or select preferred routes based on communities.
By default, communities are stripped in outgoing BGP
updates.
BGP v3.24-4
BGP communities are attributes that are used to group and filter routes. Communities are
designed to give the network operator the ability to apply policies to large numbers of routes by
using match and set clauses in the configuration of route maps. Community-lists are used in
this process to identify and filter routes by their common attributes.
A community is an attribute that is used to tag BGP routes. A router can apply it to any BGP
route by using a route-map. Other routers can then perform any action based on the tag
(community) that is attached to the route.
There can be more than one BGP community that is attached to a single route, but the routers,
by default, remove communities in outgoing BGP updates.
4-80
BGP Communities Overview (Cont.)

The community attribute is a transitive optional attribute. Its
value is a 32-bit number (range 0 to 4,294,967,200).
Each network in a BGP routing table can be tagged with a set
of communities.
The standards define several filtering-oriented communities:
no-advertise: Do not advertise routes to any peer.
no-export: Do not advertise routes to real EBGP peers.
local-as: Do not advertise routes to any EBGP peers.
internet: Advertise this route to the Internet community.
Routers that do not support communities pass them along

unchanged.
BGP v3.24-5
The community attribute is a 32-bit transitive optional BGP attribute that was designed to
group destinations and apply routing decision (accept, prefer, redistribute, and so on) according
to communities to allow the easy application of administrative policies. BGP communities
provide a mechanism to reduce BGP configuration complexity on a router controlling the
distribution of routing information.
A set of community values has been predefined. When a router receives a route that has been
marked with a predefined community, the router will perform a specific, predefined action that
is based on that community setting as follows:
no-advertise: If a router receives an update carrying this community, it will not forward it
to any neighbor.
no-export: If a router receives an update carrying this community, it will not propagate it
to any external neighbors except intra-confederation external neighbors. This is the most
widely used predefined community attribute.
local-as: This community has a similar meaning to no-export, but it keeps a route within
the local AS (or member-AS within the confederation). The route is not sent to external
BGP neighbors or to intra-confederation external neighbors.
internet: Advertise this route to the Internet community. All routers belong to it.
Routers that do not support the community attribute will pass the attribute to other neighbors
because it is a transitive attribute.
4-81
BGP Communities Overview (Cont.)

Defining your own communities
A 32-bit community value is split into two parts:
High-order 16 bits contain the AS number of the AS that defines
the community meaning.
Low-order 16 bits have local significance.
Values of all zeroes and all ones in high-order 16 bits are

reserved.
Cisco IOS parser allows you to specify a 32-bit community
value as:
[AS-number]:[low-order-16-bits]
BGP v3.24-6
Community attributes are usually used between neighboring autonomous systems. For the BGP
communities to be globally unique, a public AS number should be part of the community value.
For this reason, you can enter the community value as two 16-bit numbers separated by a colon.
The first number (high-order 16 bits) should be the AS number of the AS that defines the
community value, and the second number should be a value that is assigned a certain meaning
(that is, translation of a community value into local preference in the neighboring AS).
Communities can also be used internally within an AS (to ensure AS-wide routing policy), in
which case the first 16 bits should contain the AS number of the local AS.
4-82
Using Communities
This topic describes how BGP communities can facilitate proper return path selection.
Using Communities
Define administrative policy goals.
Design filters and route selection policy to achieve
administrative goals.
Define communities that signal individual goals.
Configure route tagging on entry points or let BGP
neighbors tag the routes.
Configure community distribution.
Configure route filters and route selection parameters
based on communities.
BGP v3.24-7
Designing a BGP solution around BGP communities usually requires the following steps:
Step 1
Define administrative policy goals that you need to implement.
Step 2
Define the filters and route selection policy that will achieve the required goals.
Step 3
Assign a community value to each goal.
Step 4
Apply communities on incoming updates from neighboring autonomous systems or

tell the neighbors to set the communities themselves.
Step 5
Enable community distribution throughout your AS to allow community

propagation.
Step 6
Match communities with route-maps and route filters, change BGP attributes, or
influence the route selection process based on the communities that are attached to
the BGP routes.
4-83
Example: Using Communities

This example shows how you can define goals and assign communities to them.
Using Communities (Cont.)

Define administrative policy goals.
Solve asymmetrical customer routing problems.
Design filters and path selection policy to achieve

administrative goals.
Set local preference of customer routes to 50 for customers
using the backup ISP.
Define communities that signal individual goals.

Community 387:17 is used to indicate that the local
preference of the route should be lowered to 50.
BGP v3.24-8
This table lists the goals and the community values.

Goal
Community Value
Set local preference of 50.
387:17
Set local preference of 150.
387:18
Prepend the AS path once when sending the

network to external neighbors.
387:21
Prepend the AS path twice when sending the

network to external neighbors.
387:22
Prepend the AS path three times when sending

the network to external neighbors.
387:23
All customers of the service provider should know this list so that they can use the BGP
communities without having to discuss their use with the service provider.
4-84

This topic lists the activities that are required to successfully deploy BGP communities in a
BGP-based network.

Configure BGP communities as follows:
Configure route tagging with BGP communities.
Configure BGP community propagation.
Define BGP community access-lists (community-lists) to
match BGP communities.
Configure route-maps that match on community-lists and
filter routes or set other BGP attributes.
Apply route-maps to incoming or outgoing updates.
BGP v3.24-9
Configuration activities when you are using communities include the following:
Setting communities, which requires a route-map.
Enabling community propagation per neighbor for all internal neighbors. If communities
are sent to external neighbors, you must enable community propagation for external
neighbors.
Creating community-lists to be used within route-maps to match on community values.
Creating route-maps where community-lists are used to match on community values. You
can then use route-maps to filter based on community values or to set other parameters or
attributes (for example, local preference, MED, or AS-path prepending).
Applying route-maps to incoming or outgoing updates.
4-85
Configuring Route Tagging with BGP

Communities
This topic lists the Cisco IOS commands that are required to configure route tagging with BGP
communities.
Configuring Route Tagging with

BGP Communities
Route tagging with communities is always done with a routemap.

You can specify any number of communities.
Communities specified in the set keyword overwrite existing
communities unless you specify the additive option.
BGP v3.24-10
In a route-map configuration mode, you should use the set community command to attach a
community attribute (or a set of communities) to a route. You can attach up to 32 communities
to a single route with one route-map set statement. If the keyword additive is used, the original
communities are preserved and the router simply appends the new communities to the route.
Omitting the additive keyword results in the overwriting of any original community attributes.
4-86

BGP Communities (Cont.)
This command applies a route-map to inbound or outbound

BGP updates.
The route-map can set BGP communities or other BGP
attributes.
Applies a route-map to redistributed routes
BGP v3.24-11
You can apply a route-map to incoming or outgoing updates. You can also use it with
redistribution from another routing protocol.
Note
A route-map is a filtering mechanism that has an implicit deny for all networks that are not
matched in any route-map statement. If a route-map is not intended to filter routes, then you
should add another route-map statement at the end to permit all remaining networks without
changing it (no match and no set commands are used within that route-map statement).
Originally, Cisco IOS software accepted and displayed BGP community values as a single
32-bit value in a digital format. Newer Cisco IOS versions support the new format, where you
can set or view a community as two colon-separated 16-bit numbers.
The global command ip bgp-community new-format is recommended on all routers whenever
communities contain the AS number.
After being converted, configuration files with communities in the new as:nn format are not
compatible with older versions of Cisco IOS software. This example shows the difference in
appearance between the old and new formats:

After the ip bgp-community new-format command:

4-87
Example: Configuring Route Tagging with BGP Communities

In this example, a border router in AS 213 applies a community value of 387:17 to all networks
that are sent to neighboring AS 387.

BGP v3.24-12
Another route-map entry is not needed because the first statement permits all networks (no
match command means match all).
If it is more desirable to set communities on specific routes, you can use a standard access-list
to match against, with the match ip address command in the route-map.
In a later example, networks with community 387:17 will have the local preference changed to
a value of 50 within AS 387 to force AS 387 to prefer the other path that carries the default
local preference of 100.
4-88

This topic describes the Cisco IOS command that is required to enable BGP community
propagation to BGP neighbors.

By default, communities are stripped in outgoing BGP updates.
You must manually configure community propagation to BGP
neighbors.
BGP peer groups are ideal for configuring BGP community
propagation toward a large number of neighbors.
BGP v3.24-13
A command that is commonly forgotten by network administrators when configuring BGP

communities is the neighbor ip-address send-community command. This command is needed
to propagate community attributes to BGP neighbors. Even if you use an outgoing route-map to
set communities, by default, the router will strip out any community values that are attached to
outgoing BGP updates if you have not configured this command for the specific BGP neighbor.
You can also apply this command to a peer group.
4-89
Example: Configuring Community Propagation

This example illustrates community propagation.

(Cont.)
BGP v3.24-14
The configuration example that was discussed earlier in this lesson must include the sendcommunity command to enable community propagation from AS 213 to AS 387.
4-90

This topic lists the Cisco IOS commands that are required to match routes based on attached
BGP communities using community-lists.

This command defines a simple community-list.
Community-lists are similar to access-liststhey are evaluated
sequentially, line by line.
All values listed in one line have to match for the line to match
and permit or deny a route.
You can use the keyword internet to match any community.
BGP v3.24-15
You can use a standard community access-list to find community attributes in routing updates.
A standard community-list is defined by its assigned list number, which can range from 1 to 99.
Community-lists are similar to standard IP access-lists in the following ways:
The router evaluates the lines in the community-list sequentially.
If no line matches communities that are attached to a BGP route, the route is implicitly
denied.
Standard community-lists are different from standard IP access-lists in the following ways:
The keyword internet should be used to permit any community value.
If more values are listed in a single line, they all have to be in an update to produce a
match.
4-91
Defining BGP Community-Lists (Cont.)

This command defines an extended community-list.
Extended community-lists are like simple community-lists, but
they match based on regular expressions.
Communities attached to a route are ordered, converted to
string, and matched with regexp.
Use .* to match any community value.
BGP v3.24-16
An expanded community-list is defined by its assigned list number, which can range from 100
to 199. Regular expressions are used to match community attributes. When a router processes a
list of communities that are attached to a network update, they are converted into an ordered
string of characters. This example shows how the process is accomplished:
1. The original list of communities in an update:
10.0.0.0/8, NH=1.1.1.1, origin=I, AS-path=20 30 40, community=10:101,
community=10:201, community=10:105, community=10:205
2. A string of characters containing an ordered list of community values:
_10:101_10:105_10:201_10_205_ (_ represents a space)
3. A regular expression:
permit _10:.0[1-5]_ (_ represents an underscore that matches spaces)
4. The result:
This regular expression permits the route because it permits all routes with communities
where the first 16 bits carry the AS number 10 and the second 16 bits contain 0 as the
second digit and a number between 1 and 5 as the third digit; the first digit can be anything
(as indicated by the .).
Use regular expression .* to permit any community.
4-92
Example: Defining BGP Community-Lists

This example shows a portion of the configuration of the router in AS 387.
Defining BGP Community-Lists (Cont.)
BGP v3.24-17
The access-list has been configured to match communities that were previously set by the
router in AS 213.
4-93

This topic describes the function of the BGP Named Community Lists feature.

Allows the network operator to assign meaningful names to
community-lists and increases the number of communitylists that can be configured
Can be configured with regular expressions and with
numbered community-lists
No limitation on the number of community attributes that can
be configured for a named community-list
Increases the number of community-lists that can be
configured by a network operator because there is no
limitation on the number of named community-list that can
be configured
BGP v3.24-18
The BGP Named Community Lists feature introduces a new type of community-list called the
named community-list. A named community-list can be configured with regular expressions
and with numbered community-lists. The BGP Named Community Lists feature allows the
network operator to assign meaningful names to community-lists. All rules of numbered
communities apply to named community-lists except that there is no limitation on the number
of community attributes that can be configured for a named community-list. Although both
standard and expanded community-lists have a limitation of 100 community groups that can be
configured within each type of list, a named community-list does not have this limitation.
ip-community-list
To create a numbered or named community-list for BGP and to control access to it, use the ip
community-list command in global configuration mode.
ip community-list {standard-list-number | expanded-list-number [regular-expression] |
{standard | expanded} community-list-name} {permit | deny} community-number |
regular-expression
To delete the community-list, use the no form of this command.
no ip community-list standard-list-number | expanded-list-number | community-list-name
4-94
Syntax Description
Parameter
Description
Specifies a standard community-list number from 1 to 99 that

identifies one or more permit or deny groups of communities.
Specifies an expanded community-list number from 100 to 199

that identifies one or more permit or deny groups of communities.
Configures a standard named community-list.
Configures an expanded named community-list.
The community-list name.
Permits access for a matching condition.
Denies access for a matching condition.
Community number configured by a set community command.

Valid value is one of the following:
A number from 1 to 4294967200. You can specify a single
number or multiple numbers separated by a space.
internetThe Internet community.
no-exportRoutes with this community are sent to peers in
other subautonomous systems within a confederation. Do not
advertise this route to an External BGP (EBGP) peer. External
systems are those outside the confederation. If there is no
confederation, an external system is any EBGP peer.
local-asSend this route to peers in other subautonomous
systems within the local confederation. Do not advertise this route
to an external system.
no-advertiseDo not advertise this route to any peer (internal
or external).
match community
To match a BGP community, use the match community command in route-map configuration
mode.
match community standard-list-number | expanded-list-number | community-list-name
[exact]
To remove the match community command from the configuration file and restore the system
to its default condition where the software removes the BGP community list entry, use the no
form of this command.
no match community standard-list-number | expanded-list-number | community-list-name
[exact]
4-95
Syntax Description
Parameter
Description
Specifies a standard community-list number from 1 to 99 that

identifies one or more permit or deny groups of communities.
Specifies an expanded community-list number from 100 to 199

that identifies one or more permit or deny groups of communities.
The community-list name.
(Optional) Indicates that an exact match is required.

All of the communities and only those communities specified must
be present.
set comm-list delete

To remove communities from the community attribute of an inbound or outbound update, use
the set comm-list delete command in route-map configuration mode.
set comm-list community-list-number | community-list-name delete
To negate a previous set comm-list delete command, use the no form of this command.
no set comm-list community-list-number | community-list-name delete
Syntax Description
4-96
Parameter
Description
A standard or expanded community-list number
A standard or expanded community-list name
Named Community List Examples

The following example creates a standard community-list that permits all routes except the
routes with the communities 5 and 10 or 10 and 15:

The following example creates a standard community-list that permits all routes within the
local AS:

The following example creates a standard named community-list with the name
COMMUNITY_A that permits all routes within the local AS and denies all routes with the
internet community attribute:

The following example creates an expanded named community-list with the name
COMMUNITY_B that will not advertise routes to EBGP peers:

The following example creates a named community-list with the name COMMUNITY_C that
will not advertise this route to any EBGP or EBGP peers:

The following example uses a regular expression. The example creates a filter that will deny all
communities that contain a number:

4-97
BGP Cost Community

This topic describes the function of the BGP Cost Community feature.
BGP Cost Community

Allows you to customize the BGP best-path selection
process for a local AS or confederation
Applied to internal routes by configuring the set extcommunity
cost command in a route map
Influences the BGP best-path selection process at the POI
Can be used as a tie breaker during the best-path selection
process
BGP v3.24-19
The cost community is a nontransitive extended community attribute that is passed to Internal
BGP (IBGP) and confederation peers but not to EBGP peers. The configuration of the BGP
Cost Community feature allows you to customize the BGP best-path selection process for a
local AS or confederation by assigning cost values to specific routes.
The cost community attribute is applied to internal routes by configuring the set extcommunity
cost command in a route map.
set extcommunity cost

To create a set clause to apply the cost community attribute to routes that pass through a route
map, use the set extcommunity cost command in route-map configuration mode.
set extcommunity cost [igp] community-id cost-value
To delete the cost community set clause, use the no form of this command.
no set extcommunity cost [igp] community-id cost-value
4-98
Syntax Description
Parameter
Description
The IGP point of insertion (POI).

The configuration of this keyword forces the cost community to be
evaluated after the IGP distance to the next hop has been
compared.
The ID for the configured extended community.

The range is from 0 to 255.
The configured cost that is set for matching paths in the route
map.
The range is from 0 to 4294967295.
The cost community set clause is configured with a cost community ID number (0 to 255) and
cost number (0 to 4294967295). The cost number value determines the preference for the path.
The path with the lowest cost community number is preferred. Paths that are not specifically
configured with the cost community attribute are assigned a default cost number value of
2147483647 (the midpoint between 0 and 4294967295) and evaluated by the best-path
selection process accordingly. When two paths have been configured with the same cost
number value, the path selection process prefers the path with the lowest cost community ID.
The cost extended community attribute is propagated to IBGP peers when extended community
exchange is enabled with the neighbor send-community command.
The cost community attribute influences the BGP best-path selection process at the point of
insertion (POI). By default, the POI follows the IGP metric comparison. When BGP receives
multiple paths to the same destination, it uses the best-path selection process to determine
which path is the best path. BGP automatically makes the decision and installs the best path
into the routing table. The POI allows you to assign a preference to a specific path when
multiple equal-cost paths are available. If the POI is not valid for local best-path selection, the
cost community attribute is silently ignored.
Multiple paths can be configured with the cost community attribute for the same POI. The path
with the lowest cost community ID is considered first. In other words, all of the cost
community paths for a specific POI are considered, starting with the one with the lowest cost
community ID. Paths that do not contain the cost community (for the POI and community ID
being evaluated) are assigned the default community cost value (2147483647). If the cost
community values are equal, then cost community comparison proceeds to the next-lowest
community ID for this POI.
Applying the cost community attribute at the POI allows you to assign a value to a path
originated or learned by a peer in any part of the local AS or confederation. The cost
community can be used as a tie breaker during the best path selection process. Multiple
instances of the cost community can be configured for separate equal-cost paths within the
same AS or confederation. For example, a lower cost community value can be applied to a
specific exit path in a network with multiple equal-cost exit points, and the specific exit path
will be preferred by the BGP best-path selection process.
4-99
BGP Cost Community Configuration Example

The following example configuration shows the configuration of the set extcommunity cost
command. This example applies the cost community ID of 1 and cost community value of 100
to routes that are permitted by the route-map. This configuration will cause the best-path
selection process to prefer this route over other equal-cost paths that were not permitted by this
route map sequence.

4-100
BGP Link Bandwidth

This topic describes the function of the BGP Link Bandwidth feature.
BGP Link Bandwidth Feature

Used to enable multipath load balancing for external links
with unequal bandwidth capacity
Enabled under an IPv4 or VPNv4 address family sessions by
entering the bgp dmzlink-bw command
Routes learned from directly connected external neighbor
propagated through the IBGP network with the bandwidth of
the source external link
BGP v3.24-20
The BGP Link Bandwidth feature is used to enable multipath load balancing for external links
with unequal bandwidth capacity. This feature is enabled under an IP version 4 (IPv4) or
Virtual Private Network version 4 (VPNv4) address-family session by entering the bgp
dmzlink-bw command. This feature supports IBGP, EBGP multipath load balancing, and
Enhanced Interior Gateway Routing Protocol (EIGRP) multipath load balancing in
Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). When this feature is
enabled, routes learned from directly connected external neighbors are propagated through the
IBGP network with the bandwidth of the source external link.
The BGP Link Bandwidth feature allows BGP to be configured to send traffic over multiple
IBGP or EBGP learned paths where the traffic that is sent is proportional to the bandwidth of
the links that are used to exit the AS. The configuration of this feature can be used with EBGP
and IBGP multipath features to enable unequal-cost load balancing over multiple links.
Unequal-cost load balancing over links with unequal bandwidth was not possible in BGP
before the BGP Link Bandwidth feature was introduced.
The link bandwidth extended community attribute indicates the preference of an AS exit link in
terms of bandwidth. This extended community is applied to external links between directly
connected EBGP peers by entering the neighbor dmzlink-bw command. The link bandwidth
extended community attribute is propagated to IBGP peers when extended community
exchange is enabled with the neighbor send-community command.
4-101
bgp dmzlink-bw
To configure BGP to distribute traffic proportionally over external links with unequal
bandwidth when multipath load balancing is enabled, use the bgp dmzlink-bw command in
address family configuration mode.
bgp dmzlink-bw
To disable traffic distribution proportional to the link bandwidth, use the no form of this
command.
no bgp dmzlink-bw
This command has no keywords or arguments.
neighbor dmzlink-bw
To configure BGP to advertise the bandwidth of links that are used to exit an AS, use the
neighbor dmzlink-bw command in address family configuration mode.
neighbor ip-address dmzlink-bw
To disable link bandwidth advertisement, use the no form of this command.
no neighbor ip-address dmzlink-bw
Syntax Description
Parameter
Description
The IP address that identifies the external interface
The link bandwidth extended community attribute is a 4-byte value that is configured for a link
on the demilitarized zone (DMZ) interface that connects two single-hop EBGP peers. The link
bandwidth extended community attribute is used as a traffic-sharing value relative to other
paths while forwarding traffic. Two paths are designated as equal for load balancing if the
weight, local preference, AS-path length, MED, and Interior Gateway Protocol (IGP) costs are
the same.
4-102

In this example, the BGP Link Bandwidth feature is configured so that BGP will distribute
traffic proportionally to the bandwidth of each external link.
BGP Link Bandwidth Configuration
BGP v3.24-21
The figure shows two external autonomous systems connected by three links, with each AS
carrying a different amount of bandwidth (unequal-cost links). Multipath load balancing is
enabled, and traffic is balanced proportionally.
4-103

Router A Configuration
In the following example, Router A is configured to support IBGP multipath load balancing
and to exchange the BGP extended community attribute with IBGP neighbors:

Router B Configuration
In the following example, Router B is configured to support multipath load balancing, to
distribute Router D and Router E link traffic proportionally to the bandwidth of each link, and
to advertise the bandwidth of these links to IBGP neighbors as an extended community:

4-104
Router C Configuration
In the following example, Router C is configured to support multipath load balancing and to
advertise the bandwidth of the link with Router E to IBGP neighbors as an extended
community:

4-105
BGP Support for Sequenced Entries in Extended

Community Lists
This topic describes the BGP Support for Sequenced Entries in Extended Community Lists
feature.
BGP Support for Sequenced Entries

in Extended Community Lists
Allows automatic sequencing of individual entries in BGP
extended community-lists
Provides the ability to remove or resequence extended
community-list entries without deleting the entire existing
extended community list
Configures sequence numbers for extended community-list
entries
Resequences existing sequence numbers for extended
community-list entries
Configures an extended community-list to use default values
BGP v3.24-22
This feature allows automatic sequencing of individual entries in BGP extended communitylists. This feature also provides the ability to remove or resequence extended community-list
entries without deleting the entire existing extended community-list.
Both named and numbered extended community-lists can be configured in IP extended
community-list configuration mode. To enter IP extended community-list configuration mode,
issue the ip extcommunity-list command with either the expanded or standard keyword
followed by the extended community-list name. This configuration mode supports all of the
functions that are available in global configuration mode. In addition, you can perform the
following operations:
Configure sequence numbers for extended community-list entries
Resequence existing sequence numbers for extended community-list entries
Configure an extended community-list to use default values
4-106
ip extcommunity-list
To create an extended community-list and control access to it, use the ip extcommunity-list
command in global configuration mode.
ip extcommunity-list expanded-list-number | expanded list-name {permit | deny}
[regular-expression] | standard-list-number | standard list-name {permit | deny} [rt
extcom-value] [soo extcom-value]
To delete the entire community-list, use the no form of this command.
no ip extcommunity-list expanded-list-number | expanded list-name | standard-listnumber | standard list-name
Syntax Description
Parameter
Description
An expanded list number from 100 to 500 that identifies one or

more permit or deny groups of extended communities.
A standard list number from 1 to 99 that identifies one or more

permit or deny groups of extended communities.
Creates an expanded named extended community-list and enters

IP extended community-list configuration mode.
Creates a standard named extended community-list and enters

IP extended community-list configuration mode.
Permits access for a matching condition.
Denies access for a matching condition.
(Optional) An input string pattern to match against.
(Optional) Specifies the route target (RT) extended community

attribute.
The rt keyword can be configured only with standard extended
community-lists and not expanded community-lists.
(Optional) Specifies the site of origin (SOO) extended community

attribute.
The soo keyword can be configured only with standard extended
community-lists and not expanded community-lists.
Specifies the RT or SOO extended community value.

The value can be one of the following combinations:
autonomous-system-number : network-number
ip-address : network-number
The colon is used to separate the AS number and network
number or IP address and network number.
(Optional) The sequence number of a named or numbered

extended community-list.
This value can be a number from 1 to 2147483647.
4-107
Parameter
Description
(Optional) Sets a keyword or argument to default behavior or

value.
(Optional) Exits IP extended community-list configuration mode.
(Optional) Changes the sequences of extended community-list

entries to the default sequence numbering or to the specified
sequence numbering.
Extended community entries are sequenced by 10-number
increments by default.
(Optional) Specifies the number for the first entry in an extended

community-list.
(Optional) Specifies the increment range for each subsequent

extended community-list entry.
Sequenced Extended Community-List Entry Configuration:

Example
The following example creates and configures a named extended community-list that will
permit routes only from RT 64512:10, 65000:20, 64535:30 and SOO 65535:40. All other routes
are implicitly denied.

Resequenced Extended Community-List Entry Configuration:

Example
The following example resequences the extended community-list entries in the named
community-list. The first entry is resequenced to the number 50 and the range for each
subsequent entry to follow by 100 (for example, 150, 250, 350, and so on):

4-108
Sequenced Extended Community-List Entry Verification:

Example
The following example uses the show ip extcommunity-list EXEC command to display routes
that are permitted by the named extended community-list. This example also shows the
configuration from the first example after it has been resequence with user-defined values.

4-109
Matching BGP Communities with Route-Maps

This topic discusses the command that is required to match routes based on attached BGP
communities using route-maps.
Matching BGP Communities

with Route-Maps

Community-lists are used in match conditions in route-maps to
match on communities attached to BGP routes.
A route-map with a community-list matches a route if at least
some communities attached to the route match the communitylist.
With the exact option, all communities attached to the route have
to match the community-list.
You can use route-maps to filter routes or set other BGP
attributes based on communities attached to routes.
BGP v3.24-23
Network administrators use route-maps to match networks that carry a subset of communities
that are permitted by the community-list. Other parameters or attributes can then be set based
on community values. If you use the keyword exact, all communities that are attached to a
BGP route have to be matched by the community-list.
You can use a route-map to filter or modify BGP routing updates. Any BGP-related set
commands can be used to set BGP parameters and attributes (that is, weight, local preference,
and MED).
4-110

Route selection
You can use route-maps to set weights, local preference, or
metric based on BGP communities attached to the BGP route.
Normal route selection rules apply afterward.
Routes not accepted by route-map are dropped.
Default filters
Routes tagged with community no-export are sent to IBGP
peers and intra-confederation EBGP peers.
Routes tagged with local-as are sent to IBGP peers.
Routes tagged with no-advertise are not sent in any outgoing
BGP updates.
BGP v3.24-24
As mentioned before, there are some predefined community values that cause routers to
automatically filter routing updates:
no-advertise: If a router receives an update carrying this community, the router will not
forward it to any neighbor.
local-as: This community has a similar meaning to no-export, but it keeps a route within
the local subautonomous system. The route is not propagated to intra-confederation
external neighbors or to any other external neighbors.
no-export: If a router receives an update carrying this community, the router will not
propagate it to any external neighbors except to intra-confederation external neighbors.
internet: This value advertises this route to the Internet community, to which all routers
belong.
4-111
Example: Matching BGP Communities with Route-Maps

This example shows a configuration that translates community 387:17 into local preference 50.

BGP v3.24-25
All updates that are received from neighboring AS 213 are processed by the route-map, which
uses a community-list to find community 387:17. If the community-list matches one of the
community attributes, the set command is executed and the route is permitted. If the route does
not contain the right community, the route is simply permitted by route-map statement 9999
without changing anything in the update.
The result is that AS 387 prefers other paths to AS 213 because they have a default local
preference of 100.
4-112
This topic lists the commands that are required to monitor BGP communities.
Communities are displayed in show ip bgp prefix printout.
Communities are not displayed in debugging outputs.
Routes in the BGP table tagged with a set of communities or
routes matching a community-list can be displayed.
BGP v3.24-26
Because a community is an attribute that can appear more than once in a single update, the
show ip bgp command does not show it. You can view communities only if you use the show
ip bgp prefix command.
If you use the show ip bgp community-list command, all networks that are permitted by the
community-list are listed.
4-113
Monitoring Communities (Cont.)

Communities are displayed only in show ip bgp prefix printout.
BGP v3.24-27
This example shows the output of the show ip bgp prefix command where inbound soft
reconfiguration was enabled on one of the neighbors. The original update contained one single
community attribute (387:17), which can be seen from the second path marked with receivedonly. This update was then processed by an inbound route-map, which matched the
community 387:17 and changed the local preference of the received route to 50.
Another use of the show command is to filter the output of the show ip bgp command.
If the keyword community is included, all networks that have at least one community attribute
are displayed.
If the keyword community is followed by one or more community values, only the networks
that carry all those communities are displayed.
4-114

Displays all routes in a BGP table that have at least one
community attached

Displays all routes in a BGP table that have all the specified
communities attached
BGP v3.24-28
4-115

Displays all routes in BGP table that have exactly the specified

Displays all routes in BGP table that match community-list
clist
BGP v3.24-29
If the keyword exact is added at the end, only the networks that match exactly are displayed.
You can also use a community-list to filter the output of the show ip bgp command.
4-116
Summary
Summary
You can use the BGP community attribute to create an AS-wide
routing policy or to provide services to neighboring autonomous
systems.
Community attributes are usually used between neighboring
autonomous systems. Routers that do not support the
community attribute will pass the attribute to other neighbors
because it is a transitive attribute.
A community is an attribute that is used to tag BGP routes that
you can use to manipulate path selection and enforce
administrative policies.
To set the community attribute, you must use a route-map.
In route-map configuration mode, you should use the set
community command.
You must configure propagation of BGP communities on the
routers on a per-neighbor basis; otherwise, the BGP
communities are removed from the outgoing BGP updates.
BGP v3.24-30
Summary (Cont.)
You can use community-lists to match against the community
attribute as a method of route selection.
Communities are designed to give the network operator the
ability to apply policies to large numbers of routes by using
match and set clauses in the configuration of route maps. The
BGP Named Community Lists feature allows the network
operator to assign meaningful names to community-lists and
increases the number of community-lists that can be configured
by a network operator.
The configuration of the BGP Cost Community feature allows
you to customize the BGP best path selection process for a
local AS or confederation by assigning cost values to specific
routes.
The BGP Link Bandwidth feature is used to enable multipath
load balancing for external links with unequal bandwidth
capacity.
BGP v3.24-31
4-117
Summary (Cont.)
BGP Support for Sequenced Entries in Extended Community
Lists allows automatic sequencing of individual entries in
BGP extended community-lists and also provides the ability
to remove or resequence extended community list entries
without deleting the entire existing extended community-list.
A route-map is used to match networks that carry a subset of
communities that are permitted by the community-list.
You can view communities only if you use the show ip bgp
prefix command.
4-118
BGP v3.24-32
Module Summary
Module Summary
Weights are the first criterion in BGP route selection, and
two methods are used to set the weight attribute (default
weight and route-maps).
Local preference is the second-strongest criterion in the
route selection process, and it can be configured using
either the bgp default local-preference preference command
or route-map statements.
AS-path prepending is performed on outgoing EBGP
updates over the nondesired return path or the path
where the traffic load should be reduced.
BGP v3.24-1
Module Summary
The MED is a weak parameter in the route selection
process? it is used only if weight, local preference, AS
path, and origin code are equal.
A community is an attribute that is used to tag BGP
routes that you can use to manipulate path selection and
enforce administrative policies.
BGP v3.24-2
4-119
This module discussed attributes influencing route selection. The first lesson described how to
influence BGP route selection by setting the weight attribute of incoming BGP routes. The
second lesson discussed how to influence BGP route selection by setting the BGP local
preference attribute of incoming BGP routes. The third lesson described AS-path prepending
and the Cisco IOS commands required to properly configure and monitor AS-path
configurations. The fourth lesson explained how to influence BGP route selection by setting the
BGP MED attribute of outgoing BGP routes. Finally, the fifth lesson described how to
influence BGP route selection by setting the BGP community attribute on outgoing BGP routes
and discussed BGP communities and their use to facilitate proper return path selection.
References
Cisco Systems, Inc. Border Gateway Protocol.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm.
cfbgp.htm#xtocid15.
Cisco Systems, Inc. BGP Case Studies.
4-120
Module Self-Check
Q1)
What is the difference between local preference and weight? (Source: Influencing BGP
Route Selection with Weights)
A)
B)
C)
D)
Q2)
What is the default weight for routes that are received from a BGP neighbor? (Source:
Influencing BGP Route Selection with Weights)
A)
B)
C)
D)
Q3)
B)
C)
D)
assign higher weights to all routes that are received from the backup ISP
assign lower weights to all routes that are received from the backup ISP
assign higher weights to all routes that are received from the primary ISP
assign lower weights to all routes that are received from the primary ISP
When you are using route-maps to modify weights, what happens by default to a route
that does not match any of the route-map statements? (Source: Influencing BGP Route
Selection with Weights)
A)
B)
C)
D)
Q6)
Before the new weights can take effect, the BGP process on the router must be
removed and reconfigured.
The router must first be rebooted for the new weights to take effect.
The new weights will be applied after the BGP update interval of 30 minutes
expires.
The new weight configuration is applied to all routes that are received
following the configuration change.
How could you implement a primary/backup ISP routing policy by using weights?
(Source: Influencing BGP Route Selection with Weights)
A)
B)
C)
D)
Q5)
0
100
32768
depends on the Cisco IOS release
When are the weights that are configured on a neighbor enforced? (Source: Influencing
BGP Route Selection with Weights)
A)
Q4)
Local preference has a higher priority in BGP path selection.

Local preference is used AS-wide while weight is local to a single router.
Local preference is local only to a specific BGP-speaking router.
Local preference is used to influence incoming path selection.
The route is accepted with the weight attribute unmodified.

The route is discarded.
The route is inserted into the BGP table but not into the IP routing table.
An error is displayed on the router console and in router debugs.
Which method of influencing route selection with weights is the last to be applied on
an incoming interface? (Source: Influencing BGP Route Selection with Weights)
A)
B)
C)
D)
prefix-list
route-map
filter-list weight
default weight
4-121
Q7)
Which two of the following statements are correct regarding BGP route selection?
(Choose two.) (Source: Influencing BGP Route Selection with Weights)
A)
B)
C)
D)
E)
Q8)
What is a key difference between the local preference and weight attributes? (Source:
Setting BGP Local Preference)
A)
B)
C)
D)
Q9)
B)
C)
D)
set local-preference
bgp default local-preference
show ip bgp
show ip bgp prefix
Which Cisco IOS command is necessary to display the locally applied BGP value?
(Source: Setting BGP Local Preference)
A)
B)
C)
D)
4-122
set local-preference
bgp default local-preference
show ip bgp
show ip bgp prefix
Which Cisco IOS command is used to configure BGP local preference with route-map
statements? (Source: Setting BGP Local Preference)
A)
B)
C)
D)
Q12)
When you set local preference, you can view it on neighboring routers, but you
must reset it.
You can use local preference to ensure AS-wide route selection policy.
Local preference is used to select routes with unequal weights.
Local preference is the second-strongest criterion in the route selection process.
Which Cisco IOS command is used to change the default value of local preference?
(Source: Setting BGP Local Preference)
A)
B)
C)
D)
Q11)
Local preference is local to the route on which it is configured.

Local preference is local to the AS within which it has been configured.
Local preference is local to the BGP administrative domain.
Local preference is global to a BGP domain.
Which two of the following statements about the influence of local preference on BGP
route selection is accurate? (Choose two.) (Source: Setting BGP Local Preference)
A)
Q10)
If two routes have the same weight attribute, the route with the lowest local
preference is chosen.
The route with the highest weight is always chosen first.
The weight attribute is global within an AS.
The weight attribute is only local to the local router.
The weight value is propagated by all routers.
show bgp preference detail

show ip bgp
show ip bgp detail
show ip bgp prefix
Q13)
What is AS-path prepending? (Source: Using AS-Path Prepending)

A)
B)
C)
D)
Q14)
The AS path will be the route selection criterion that is used when which of the
following is true? (Source: Using AS-Path Prepending)
A)
B)
C)
D)
Q15)
It is the first criterion that is used in BGP route selection.

It is used when there is no difference in weight, local preference, or route
origination.
It is used when the MED is identical on the candidate routes.
The weight, local preference, MED, and origin attributes must be identical
before the AS-path attribute is used for route selection.
Which command do you use to manipulate the AS-path attribute? (Source: Using ASPath Prepending)
A)
B)
C)
D)
Q16)
when a router, sending a BGP update, adds the AS number of the router from
which it received the route to the AS-path attribute
when a router, sending a BGP update, adds the AS number of the router to
which it is sending the route to the AS-path attribute
when a router, sending a BGP update, adds its AS number to the AS-path
attribute multiple times
when a router uses the AS-path attribute in route selection
the global configuration command set as-path prepend as-number

the router configuration command set as-path prepend as-number
set as-path prepend as-number in a route-map
the interface global command set as-path prepend as-number
The following configuration is from a router in AS 347, which is advertising network

11.0.0.0/8 to an EBGP neighbor 2.0.0.2 in AS 529:

What are the contents of the AS-path attribute for route 11.0.0.0/8 on a router that is
residing in AS 529? (Source: Using AS-Path Prepending)
A)
B)
C)
D)
Q17)
347 347 347

347 347 347 347
529 347 347 347
529 347 347 347 347
Why do network administrators need to use AS-path prepending? (Source: Using ASPath Prepending)
A)
B)
C)
D)
AS-path prepending allows a customer to potentially influence return path

route selection.
AS-path prepending is used on a customer router to control outgoing route
updates.
Service providers use AS-path prepending to control incoming updates from a
customer AS.
AS-path prepending is used between service providers that are connected to the
same customer AS to determine which will be the primary link to the customer.
4-123
Q18)
How does AS-path prepending affect a router? (Source: Using AS-Path Prepending)
A)
B)
C)
D)
Q19)
Which two of the following are characteristics of the function of the BGP Hide LocalAutonomous System feature? (Choose two.) (Source: Using AS-Path Prepending)
A)
B)
C)
D)
Q20)
D)
largest weight
originated routes
AS-path length
lowest IP address
Which two statements about the Cisco IOS command that is required to configure
changes to the default BGP MED on a Cisco IOS router are accurate? (Choose two.)
(Source: Understanding BGP Multi-Exit Discriminators)
A)
B)
C)
D)
4-124
to influence path selection out of an originating AS

to provide a strong metric to select the best path when multiple routes exist
to have a BGP attribute traversing many autonomous systems while
influencing path selection
to influence the return path of traffic back into an AS
What are three BGP attributes that are compared before the MED? (Choose three.)
(Source: Understanding BGP Multi-Exit Discriminators)
A)
B)
C)
D)
Q22)
allows you to transparently change the AS number for the entire BGP network
ensures that routes can be propagated throughout the AS
allows customization of the AS number for EBGP peer groupings through the
set as-path command
changes the AS number for all IBGP peers at the same time
What is the typical application of the MED attribute? (Source: Understanding BGP
Multi-Exit Discriminators)
A)
B)
C)
Q21)
AS-path prepending is simply a term that is used to describe when a router uses
the AS-path attribute in route selection and hence does not affect router
resources.
The longer the AS-path attribute attached to BGP updates, the more router
memory requirements increase.
AS-path prepending does not impact the router because Cisco IOS software
recognizes that AS-path prepending is in use and stores a single AS number
with a pointer to the number of AS-path prepends.
AS-path prepending causes the router to operate in process-switching mode
because the BGP update must be stored, manipulated, and then rewritten to
accommodate the new AS-path attribute.
The MED is a mandatory attribute.

Using the default-metric command in BGP configuration mode will cause one
redistributed network to have the specified MED value.
There is no MED attribute that is attached to a route by default.
To set the default metric value (MED) for BGP routes, use the default-metric
command.
Q23)
Which two statements about the Cisco IOS commands that are required to configure
changes to the BGP MED attribute with route-map statements are accurate? (Choose
two.) (Source: Understanding BGP Multi-Exit Discriminators)
A)
B)
C)
D)
Q24)
Which two of the following statements about the Cisco IOS commands that are
required to configure advanced MED features on Cisco routers are accurate? (Choose
two.) (Source: Understanding BGP Multi-Exit Discriminators)
A)
B)
C)
D)
Q25)
The bgp bestpath med confed command allows routers to compare paths
learned from confederation peers.
When you enable a deterministic MED comparison, you allow a router to
compare MED values after it considers BGP route type (external or internal)
and IGP metric to the next-hop address.
Use the bgp always-compare-med command to force the router to compare
the MED even if the paths come from different autonomous systems.
Cisco IOS software, on the other hand, regards a missing MED attribute as
having a value of 1.
If you configure inbound soft reconfiguration with a route-map and issue the show ip
bgp prefix command, which value of the MED attribute is displayed? (Source:
Understanding BGP Multi-Exit Discriminators)
A)
B)
C)
D)
Q26)
The set metric command is used within route-map configuration mode to set
the MED attribute.
The neighbor address route-map name in | out command applies a route-map
to incoming updates from all neighbors.
Per-neighbor MED is configured by using a route-map with a match condition.
You can use a route-map to set the MED on incoming or outgoing updates.
Only the original route (no MED) is displayed.

Both the original route and the modified route are displayed.
Only the modified route is displayed.
The MED attribute is not displayed with the show ip bgp prefix command.
Which of the following statements about the Cisco IOS commands that are required to
troubleshoot BGP MED configurations on a Cisco router is accurate? (Source:
Understanding BGP Multi-Exit Discriminators)
A)
B)
C)
D)
To see the original MED, you need to enable hard reconfiguration on the
router.
The command show ip bgp neighbor address received-routes displays the
original updates before any filters or route-maps have filtered or changed them.
If hard reconfiguration is enabled, the original updates to the MED attribute are
available by using the show ip bgp prefix command.
Issuing the show ip route command will display the MED value.
4-125
Q27)
What are two reasons why it is not feasible to use the MED to influence return path
selection when multiple autonomous systems are involved? (Choose two.) (Source:
Addressing BGP Communities)
A)
B)
C)
D)
Q28)
Does the community attribute have any influence on BGP path selection? (Source:
A)
B)
C)
D)
Q29)
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
_____ 1.
Define the filters and route selection policy that will achieve the required
goals.
_____ 2.
Define administrative policy goals that you need to implement.
_____ 3.
Apply communities on incoming updates from neighboring autonomous

systems or tell the neighbors to set the communities themselves.
_____ 4.
Assign a community value to each goal.
_____ 5.
Match communities with route-maps and route filters, change BGP

attributes, or influence the route selection process based on the
communities that are attached to the BGP routes.
_____ 6.
Enable community distribution throughout your AS to allow community

propagation.
How many community tags can be attached to a single BGP route? (Source:
A)
B)
C)
D)
4-126
No, communities are simply tags that are applied to BGP routes.
No, communities are nontransitive attributes.
Yes, BGP paths are selected based on the value in the community tag.
Yes, the community attribute is part of the BGP route selection process.
Match the steps with the actions describing how BGP communities can facilitate proper
return path selection. (Source: Addressing BGP Communities)
A)
B)
C)
D)
E)
F)
Q30)
The MED attribute is designed to influence outbound path selection only.

The AS-path attribute would be used for path selection regardless of any
configured MED value.
The weight attribute will always be used, given that it is first in the BGP route
selection process.
The MED cannot be propagated across several autonomous systems.
1
32
255
depends on the number that is configured with the ip bgp community
command
Q31)
Which three of the following are activities that are required to successfully deploy BGP
communities in a BGP-based network? (Choose three.) (Source: Addressing BGP
Communities)
A)
B)
C)
D)
Q32)
Which two of the following statements about the Cisco IOS commands that are
required to configure route tagging with BGP communities are accurate? (Choose two.)
(Source: Addressing BGP Communities)
A)
B)
C)
D)
Q33)
D)
Community propagation to BGP neighbors is automatically configured.

It is necessary to manually strip communities in outgoing BGP updates.
The neighbor ip-address send-community command cannot be applied to a
peer group.
The neighbor ip-address send-community command is needed to propagate
community attributes to BGP neighbors.
Which match criteria are specified in a standard BGP community-list? (Source:

A)
B)
C)
D)
Q35)
You can attach up to 35 communities to a single route with one route-map set
statement.
Omitting the additive keyword from the set community command results in
overwriting any original community attributes.
The global command ip bgp-community new-format is recommended on all
routers whenever communities contain the AS number.
You cannot use a route-map with redistribution from another routing protocol.
Which of the following statements about the Cisco IOS command that is required to
enable BGP community propagation to BGP neighbors is accurate? (Source:
A)
B)
C)
Q34)
setting communities, which requires a route-map

creating community-lists to be used within route-maps to match on community
values
enabling community propagation per neighbor for designated internal
neighbors
creating route-maps where community-lists are used to match on community
values
destination IP addresses
regular expressions
community attribute values
AS numbers
What is the result of tagging a route with the no-export community? (Source:
A)
B)
C)
D)
The route will not be advertised within the local AS.

The upstream AS will not be allowed to export the route.
The route cannot be exported to another routing protocol.
The router will not propagate the route to any external neighbors except to
intra-confederation external neighbors.
4-127
Q36)
Match the functions to the Cisco IOS commands that monitor BGP communities.
(Source: Addressing BGP Communities)
A)
B)
C)
D)
Q37)
_____ 1.
displays all routes in a BGP table that have all the specified communities
attached
_____ 2.
displays all routes in a BGP table that have at least one community
attached
_____ 3.
displays all routes in BGP table that match community-list clist
_____ 4.
displays all routes in BGP table that have exactly the specified
Which two of the following statements about the function of the BGP Link Bandwidth
feature are accurate? (Choose two.) (Source: Addressing BGP Communities)
A)
B)
C)
D)
Q38)
The BGP Link Bandwidth feature is used to enable multipath load balancing
for external links with unequal bandwidth capacity.
When the BGP Link Bandwidth feature is enabled, routes learned from directly
connected external neighbor are propagated through the IBGP network with
the bandwidth of the source external link.
The configuration of the BGP Link Bandwidth feature can be used only with
IBGP multipath features to enable unequal-cost load balancing over multiple
links.
To configure BGP to advertise the bandwidth of links that are used to exit an
AS use the bgp dmzlink-bw command.
Which three of the following functions of BGP named community-lists are accurate?
(Choose three.) (Source: Addressing BGP Communities)
A)
B)
C)
D)
E)
F)
4-128
show ip bgp community

show ip bgp community as:nn [as:nn ]
show ip bgp community as:nn [as:nn ] exact
show ip bgp community-list clist
allows the network operator to assign meaningful names to community-lists

sets limits on the number of named community-list that can be configured
cannot be configured with regular expressions and with numbered communitylists
increases the number of community-lists that can be configured by a network
operator
applies policies to large numbers of routes by using match and set clauses in
the configuration of route maps
sets limit of 200 community groups that can be configured within each type of
list
Q39)
Which two of the following statements about the BGP Cost Community feature are
accurate? (Choose two.) (Source: Addressing BGP Communities)
A)
B)
C)
D)
Q40)
The path with the highest cost community number is preferred.

The cost community attribute influences the BGP best path selection process at
the POI.
The cost community can be used as a tie breaker during the best-path
selection process.
If the cost community values are equal, then cost community comparison
proceeds to the next highest community ID for this POI.
Which three of the following are functions of the BGP Support for Sequenced Entries
in Extended Community Lists? (Choose three.) (Source: Addressing BGP
Communities)
A)
B)
C)
D)
E)
F)
allows automatic sequencing of individual entries in BGP extended

community-lists
provides the ability to remove or resequence extended community-list entries
without deleting the entire existing extended community-list
configures an extended community-list to use custom values
removes or resequences extended community-list entries while deleting the
entire existing extended community-list
is activated by the ip extcommunity-list command in global configuration
mode
configures sequence numbers for standard community-list entries
4-129
4-130
Q1)
Q2)
Q3)
Q4)
Q5)
Q6)
Q7)
B, D
Q8)
Q9)
B, D
Q10)
Q11)
Q12)
Q13)
Q14)
Q15)
Q16)
Q17)
Q18)
Q19)
A, B
Q20)
Q21)
A, B, C
Q22)
C, D
Q23)
A, D
Q24)
A, C
Q25)
Q26)
Q27)
B, D
Q28)
Q29)
1-B,
2-A
3-D,
4-C
5-E
6-F
Q30)
Q31)
A, B, D
Q32)
B, C
Q33)
Q34)
Q35)
Q36)
1-B
2-A
3-D
4-C
Q37)
A, B
Q38)
A, D, E
Q39)
B, C
Q40)
A, B, E
Module 5
Customer-to-Provider
Connectivity with BGP
Overview
Today, companies use the Internet for a variety of reasons, including increasing employee
productivity, increasing sales, increasing customer satisfaction, and reducing cycle time. A key
component in connecting companies to the Internet is the service provider. Depending on
business goals, application requirements, and administrative policies, a company will use
different methods to connect to a service provideror even multiple service providers.
This module discusses the different requirements for connectivity between customers and
service providers. Included in this module is a discussion of physical connection methods,
redundancy, load balancing, and technical requirements such as addressing and autonomous
system (AS) numbering. In addition, this module details the configuration requirements to
connect a customer to a single service provider by using static routes and the Border Gateway
Protocol (BGP). Also provided in this module are the configuration requirements to connect a
customer to multiple service providers by using BGP.
Module Objectives
Upon completing this module, you will be able to configure the service provider network to
behave as a transit AS in a typical implementation with multiple BGP connections to other
autonomous systems. This ability includes being able to meet these objectives:
Describe the requirements to connect customer networks to the Internet in a service
provider environment
Implement customer connectivity by using static routing in a service provider network
Implement customer connectivity using BGP in a customer implementation in which you
must support multiple connections to a single ISP
Implement customer connectivity using BGP in a customer scenario in which you must
support connections to multiple ISPs
5-2
Lesson 1
Understanding Customer-toProvider Connectivity

Requirements
Overview
Customers connect to the Internet by using service providers to enable applications such as
intranet connectivity with Virtual Private Networks (VPNs), extranet connectivity with
suppliers, and other Internet applications. When planning network connectivity to an Internet
service provider (ISP), network designers must give careful consideration to the various aspects
of the connectivity, including physical connection types, the redundancy provided by the
connection method that is chosen, IP addressing requirements, and autonomous system (AS)
numbering considerations, if the network design is going to meet both the business and
technical requirements of the applications that are planned for the network.
This lesson discusses solutions for connecting customer networks to service providers. Also
included in this lesson is a discussion of customer network redundancy requirements, routing
requirements, IP addressing requirements, and autonomous system (AS) numbering
requirements.
Objectives
Upon completing this lesson, you will be able to describe the requirements to connect customer
networks to the Internet in a service provider environment. This ability includes being able to
Identify various physical connections that are used by customers to connect to a service
provider
Describe the levels of redundancy that are provided by each physical connection type that
is used by customers to connect to a service provider
Identify various routing schemes that are used by customers to connect to a service
provider
Describe routing schemes that are appropriate for each physical connection type that is
used by customers to connect to a service provider
Describe the addressing schemes that are used by customers to connect to a service
provider
Describe the AS numbering schemes that are used by customers to connect to a service
provider
5-4

This topic identifies the various physical connections that are used by customers to connect to a
service provider.

Internet customers have a wide range of connectivity
and redundancy requirements:
Single permanent connection to the Internet
Multiple permanent connections to a single provider in
primary and backup configuration
Multiple permanent connections to a single provider used for
load sharing of traffic
Connections to multiple service providers for maximum
redundancy
BGP v3.25-3
Service provider customers have different requirements for their Internet connectivity. These
different requirements result in different solutions:
A single permanent connection to one ISP. This solution meets the requirements for the
vast majority of customers.
Multiple permanent connections in which one of the lines is primary and the other line is
used for backup only. This setup also provides redundancy on the links. Compared to a
dial-up backup, a permanent backup link is preferred for various reasons, such as the severe
bandwidth limitations on dial-up lines and the time that is required to establish a dial-up
connection.
Multiple permanent connections to one ISP, which is used for load sharing of traffic. This
solution gives redundancy on the links but also provides additional bandwidth.
Permanent connections to more than one ISP. This solution provides the highest level of
redundancy, because it not only can cope with link-level failures but also with failures
within the network of a service provider.
5-5
Redundancy in Customer Connections

This topic describes the levels of redundancy that are provided by each physical connection
type that is used by customers to connect to a service provider.
Single Permanent Connection

to the Internet
The simplest setup: a single link between the customer network

and the Internet
No redundancy for link or equipment failure
BGP v3.25-4
A single permanent connection to one ISP is the most common setup. This setup is also the
simplest to implement.
The customer network has an edge router. This router is connected to one of the edge routers of
the ISP. The connection is permanent and could be a leased line, a Frame Relay or ATM
permanent virtual circuit (PVC), a LAN segment, or something equivalent.
There is no redundancy in this solution. Any failure on the permanent link or either of the two
edge routers causes a complete outage of the service. Serious failures within the ISP network
that affect all customers of this ISP also affect the customer in this example.
5-6
Multiple Permanent Connections

Providing Redundancy
Customers wanting increased redundancy install several physical links to the

Internet.
Redundant links are used in primary and backup setup or for load sharing.
Redundancy is for link or equipment failure.
There is no redundancy for service provider failure.
BGP v3.25-5
In this setup, one customer edge router connects to one ISP edge router. A different customer
edge router is used to connect to another ISP edge router. If one of these routers fails, only one
of the connections breaks down; the other connection is still available.
In some cases, the two links may be implemented between the customer and the provider for
load sharing and in other cases strictly for backup purposes. Backup PVCs in Frame Relay or
ATM networks can sometimes be very cost-efficient, provided that these PVCs carry only a
very small volume of traffic and that the primary path is available.
When load sharing between both links is a desired network characteristic, the distribution of the
load over the links is more complicated than when both links terminate in the same router.
Again, because the customer is connected to a single ISP, serious ISP network failures that
affect all customers of this ISP will also affect the customer in this scenario, regardless of the
backup link.
5-7
Multiple Permanent Connections

Providing Load Sharing
Customers wanting to increase their access speed can install several

physical links between a pair of routers.
There is redundancy for link failure.
There is no redundancy for equipment failure.
Load sharing in this setup is optimal.
BGP v3.25-6
In the example, a single router in the customer network is connected to a single router in the
ISP network. The redundancy is limited to the link level because router failures are not covered.
Using two parallel links between two routers allows for an optimal distribution of load over the
links.
Depending on the switching path that is used in the customer and the ISP routers, load sharing
can be performed based on the destination address only (fast switching), on source-destination
address pairs (default behavior for Cisco Express Forwarding [CEF]), or on a packet-by-packet
basis (process switching or CEF).
As in the previous examples, serious ISP network failures that affect all customers of this ISP
will also affect this customer, regardless of the link backup.
5-8
Connections to Multiple
Service Providers
Customers with maximum redundancy requirements install physical links to

multiple ISPs.
There is redundancy for link, equipment, or service provider failure.
Primary and backup setup is complex without service provider assistance.
Good load sharing is impossible to achieve.
BGP v3.25-7
In the example, two edge routers in the customer network have one permanent connection each
to different ISPs. Link failures and router failures are covered by the redundancy in exactly the
same way as in the previous example in which the two customer routers are connected to two
different routers in one ISP network. However, because the two connections in this example go
to two different ISPs, the redundancy also covers problems within one ISP network.
The two links may in some cases be implemented by the customer for load sharing and in other
cases be used strictly for backup purposes. Controlling load distribution over the links is more
complicated in this example. Avoiding any load on the backup link may require assistance from
the ISP to which the backup link is connected.
Load sharing between the links in this setup can never be optimal. Equal distribution of the
return traffic load from the Internet over the two separate links cannot be achieved. Distribution
of the load of outgoing traffic is done based on destination addresses. Slowly adjusting the
appropriate router configuration parameters and observing the link traffic load changes that
result can enable you to reach an acceptable distribution of router traffic between the two links.
5-9

This topic identifies various routing schemes that customers use to connect to a service
provider.

Static or dynamic routing can be used between an Internet
customer and an ISP.
BGP is the only acceptable dynamic routing protocol.
Because of its lower complexity, static routing is preferred.
BGP v3.25-8
Different solutions for connecting a customer network to the network of an ISP require
different methods of routing information exchange:
Static routing: Static routing is preferred because of its lower complexity. In a normal
case, the customer network must have a default route to the ISP network and the ISP
network must have a route to the IP prefixes that the customer has in its network. As
always, static routing provides very low, if any, redundancy.
Dynamic routing: Dynamic routing provides redundancy. The customer and the ISP
networks must be configured to exchange a common routing protocol. BGP is the only
choice because of the large volumes of routing information, the inherent security
mechanisms of BGP, and the ability of BGP to handle routing policies.
5-10
Customer Routing
This topic describes routing schemes that are appropriate for each physical connection type that
is used by customers to connect to a service provider.
Customer Routing? Single Permanent

Connection
Static routing is usually adequate.

BGP should not be used in this setup.
BGP v3.25-9
When the customer has a single permanent connection to the Internet, static routing is usually
adequate. The physical topology does not provide any redundancy, and it is therefore
unnecessary to add the complexity of dynamic routing. Keep the network simple by avoiding
the use of BGP in this case.
5-11
Customer Routing? Multiple Connections
Static routing is preferred if physical link failure can be

detected.
Traffic will enter a black hole if the physical link failure is not
detected.
BGP v3.25-10
Multiple permanent connections between a single router on the customer network and a single
router on the service provider network should be configured with static routing, provided that
link failure can be detected by link-level procedures.
With this type of connection, two static routes are configured on each network, pointing to both
links between the customer and the ISP. If either of the links fails, the link-level procedures
should detect this failure and place the interface in a down state. In this case, the static route is
invalid and is not used for forwarding packets. The router will subsequently forward all packets
over the remaining link.
If the link-level procedures cannot detect a link failure, the static route pointing out over the
failed link is still valid. The router continues to use this static route to send some of the traffic
out on the failed interface. This situation effectively creates a black hole for some of the
traffic.
5-12
Customer Routing? Multiple

Connections (Cont.)
You can still use static routing if link and remote equipment
failure can be detected reliably.
BGP between the customer and the service provider is usually
used in this setup.
BGP v3.25-11
You can also use static routing for multiple permanent connections between two different
routers on the customer network to two different routers on the service provider network if the
failures can be detected by the link-level procedures. When one of the connections is lost, the
link-level procedure detects this loss and places the interface in a down state. Because the
interface is in the down state, the static route that points out of the down interface becomes
invalid. As a result, the router stops the redistribution of the static route into BGP.
However, customers that require the use of multiple connections and multiple routers very
often do not rely on the link-level procedures. These customers require a routing protocol such
as BGP to detect the failures. Because BGP uses handshaking and reliable transfer, it always
detects a failed link or failed remote router.
Multiple permanent connections to more than one ISP always require the use of dynamic
routing with BGP. The customers that require this type of connection do not just want to protect
the network connectivity from link failures or remote router failures, they also want to protect
their network connectivity from serious problems in the network of an ISP.
Monitoring the link status cannot detect a problem inside one of the ISP networks. If the link is
still up and the ISP edge router is still up, the link-level procedures do not indicate any
problems. However, the ISP network may suffer from severe problems. An ISP network can be
partitioned or disconnected from the rest of the Internet without having any problems with the
edge router and the access line to the customer network.
The only way to detect this situation is to use BGP with both ISPs and receive full Internet
routing from both of them. When one of the ISPs has problems, the edge router, being the BGP
neighbor of the customer, withdraws the routes that it can no longer reach. This action means
that the customer routers know which Internet routes that each ISP can reach at the moment.
5-13
Addressing Requirements
This topic describes the various addressing schemes that customers use to connect to a service
provider.
Addressing Requirements? Single-Homed

Customers
Customers connected to a single service provider
usually get their address space from the provider.
Provider-assigned (PA) address space.
This is the most common customer setup.
Customer has to renumber if service provider changes.
Customers gets only a small address block from the

service provider.
Private addresses are used inside customer network.
NAT must be used
BGP v3.25-13
Customers that are connected to a single ISP usually get their address space assigned by the
ISP. An ISP is usually assigned a large address space to delegate to its customers. Because all
customers of one ISP get their addresses from one address space or a few address spaces, it is
very likely that the ISP is able to aggregate the customer addresses before sending the routes to
the rest of the Internet.
Most customers are connected to a single ISP, which means that they are using providerassigned (PA) addresses. If the customer should decide to change its service provider, the
customer must return its PA addresses to the old ISP and receive a new assignment of PA
addresses from the new ISP. Otherwise, the ISPs are no longer able to perform efficient address
aggregation.
The consequence for the customer is that the customer has to renumber its network when it
changes its service provider.
Some customers decide to use private addresses within their network and do Network Address
Translation (NAT) at the connection point to the ISP. This setup means that customers require
only a very small portion of public addresses from the ISP. In addition to conserving address
space for the benefit of the Internet as a whole, this setup also means that when the customer
decides to change its service provider, addresses are renumbered only at the NAT point. The
rest of the customer network does not need to be renumbered.
5-14
Addressing Requirements? Multihomed

Customers
Customers connected to multiple service providers
should get their own address space.
Provider-independent (PI) address space.
No renumbering is required for a service provider change.
Some service providers might not guarantee routing for small
block (for example, /24) of PI space.
Multihomed customers can sometimes use PA address

space.
The customer must have a separate public AS number.
The provider must agree to having another ISP advertise its
address space.
BGP v3.25-14
Customers that are connected to more than one ISP should, if possible, assign their own address
space and not have addresses that are delegated from any of their ISPs. Such assigned addresses
are called provider-independent (PI) addresses.
A customer using PI addresses can change its service provider without renumbering its
network. The address space is not in any way bound to a particular provider. This arrangement
means that no ISP can aggregate the customer routes before sending them to the rest of the
Internet. The routes propagate through the Internet with the prefix lengths given.
Some large ISPs filter out routes with long prefixes. ISPs do not want to populate their routing
tables with a large number of explicit routes that should have been aggregated into a route
summary before they were sent to them. As a result, the customer announcing small blocks of
PI addresses, which cannot be aggregated, may not be reachable from all parts of the Internet.
A larger block of PI addresses solves the problem.
A multihomed customer can in some cases use PA addresses. The address space must be
assigned from one of the ISPs. When the customer announces the block of PA addresses to both
ISPs, both should propagate the addresses to the rest of the Internet. The provider that assigned
the address space should also announce the larger block of addresses, of which the customer is
announcing a subset.
Other ISPs now receive two alternate explicit routes and an overlapping route summary.
Filtering out explicit routes is more likely at this time because the other ISPs recognize these as
routes that can be aggregated. If the other ISPs filter out the more explicit routes, the customer
is still reachable as long as both providers are announcing the overlapping route summary.
5-15
Example: Addressing Requirements

In this example, the customer uses private addresses inside its own network.
Addressing Requirements? Public and

Private
BGP v3.25-15
Only a very small network segment, called the customer demilitarized zone (DMZ), has been
assigned public addresses.
The customer network is connected to the customer DMZ using two alternate firewalls with
both firewalls doing NAT. All packets leaving the customer network have their addresses
translated to a public address belonging to the DMZ subnet. The reverse translation is made in
the reverse traffic direction.
In this case, the customer requires only a very small block of public addresses. These addresses
can be PA addresses. If the customer decides to change its service provider, renumbering is not
a problem because only a few devices need to be reconfigured by the customer.
Care must be taken so that traffic flows symmetrically through the firewalls. Otherwise, NAT
does not work. The easiest way to achieve this symmetry is to allow only one firewall be active
at a time.
5-16
AS Number Allocation
This topic describes various AS numbering schemes that customers use to connect to a service
provider.
AS Number AllocationSingle-Homed
Customers
Customers running BGP with the service provider need their own BGP
AS number.
Private AS numbers (6451265535) can be used for customers
connected to a single service provider.
BGP v3.25-16
BGP requires the use of AS numbers. When BGP is configured, the AS number is mandatory
information. Public AS numbers are a scarce resource, however. Customers should use public
AS numbers only when they are required. A customer that uses BGP to exchange routing
information with only one ISP does not require a public AS number. This customer can use a
private AS number.
An ISP network that is running BGP with some of its customers must determine whether a
public or a private AS number is required for each customer. When the customer can use a
private AS number, the ISP must allocate one from the range of private AS numbers (64512 to
65535). The ISP must make sure not to assign any of the private AS numbers to more than one
customer.
When the ISP receives BGP routes from the customer, the ISP routers see the private AS
number in the AS path and treat the private number as any other AS number. However, before
the ISP propagates any of these routes to the rest of the Internet, it must remove the private AS
numbers from the AS path, because the same AS number may be in use by someone else. After
the private AS number is removed, the route appears as belonging to the public AS of the ISP.
5-17
AS Number AllocationMultihomed
Customers
Multihomed customers must run BGP with their service

providers.
Multihomed customers must use public AS numbers for their
autonomous systems.
BGP v3.25-17
A multihomed customer requires a public AS number and must run BGP with both of its ISPs.
The customer should not use a private AS number because both ISPs must propagate the
customer routes to the rest of the Internet. If the customer does use a private AS number, and
both ISPs remove the number before sending it to the rest of the Internet, then the customer
routes will appear to be local in the public AS of both ISPs. To make BGP work correctly,
multihomed customers need to avoid this situation.
Note
With the help of the AS number translation feature, private AS numbers can also be used for
multihomed customers, but this type of configuration is not encouraged.
Multihomed customers are correctly connected to the Internet by assigning a public AS number
to the customer network. This public AS number appears in the AS path and should be
propagated by the service provider to the rest of the Internet. The customer network is now
reachable by the rest of the Internet through both providers. The route with the shortest AS path
is used by Internet endpoints as the best route to the customer network.
5-18
Summary
Summary
Different customers have different requirements for their
Internet connections. These connectivity options include a
single connection to a single ISP, multiple connections to the
same ISP, and multiple connections to different ISPs.
The least redundant, and most common, connection is a
single permanent connection to a single ISP. Multiple
permanent connections provide redundancy for links or
equipment only; multiple permanent connections with load
sharing provide redundancy only for link failure; and
connections to multiple service providers offer redundancy
for link, equipment, or provider failure.
Depending upon the networking requirements of the
customer, static (preferable) or dynamic routing may be used
to connect a customer to an ISP.
BGP v3.25-18
Summary (Cont.)
For a single permanent connection to the Internet, for multiple
permanent connections between a single router on the
customer network and a single router on the ISP network, and
for two different routers on the customer network connected to
two different routers on the ISP network, static routing is
usually adequate. Multiple permanent connections to more than
one ISP always require the use of dynamic routing with BGP,
however.
Customers that are connected to a single ISP usually get their
PA address space assigned by the ISP, while customers that
are connected to more than one ISP should, if possible, assign
their own PI address space and not have addresses that are
delegated from any of their ISPs.
Whenever BGP is in use, an AS number is required. The
customer does not need a public AS number if it is connected
to a single ISP. A multihomed customer, however, requires a
public AS number.
BGP v3.25-19
5-19
5-20
Lesson 2
Implementing Customer
Connectivity Using Static
Routing
Overview
When a customer can connect to the Internet through either a single connection to a service
provider or multiple connections to the same Internet service provider (ISP), static routing is
the simplest routing approach to implement between customer and provider. When network
administrators are implementing customer-to-provider connectivity with static routes,
knowledge of static routing implementation guidelines will aid in successfully deploying static
routing network configurations.
This lesson discusses static routing as a solution for connecting customer networks to service
providers. Also included in this lesson is a discussion of when static routing should be used
between a customer and a provider and information on how to configure static routing in
nonredundant, backup, and load-sharing configurations.
Objectives
Upon completing this lesson, you will be able to implement customer connectivity by using
static routing in a service provider network. This ability includes being able to meet these
objectives:
Identify when to use static routing between a customer and a service provider in a BGP
environment
Describe the characteristics of static routing between a customer and a service provider in a
BGP environment
Identify design considerations for propagating static routes in a service provider network
Configure static route propagation in a BGP environment with different service levels
Configure a typical backup setup that uses static routing between a customer and a service
provider in a BGP environment
Describe the limitations of floating static routes when they are used in typical backup static
routing scenarios and the corrective actions to overcome these limitations
Describe the characteristics of load sharing when you are configuring static routing
between a customer and a service provider
5-22

This topic identifies when to use static routing between a customer and a service provider in a
Border Gateway Protocol (BGP) environment.

Static routing is used for:
Customers with a single connection to the Internet
Customers with multiple connections to the same service
provider in environments where link and equipment failure
can be detected
Dynamic routing with BGP must be used in all other cases.
BGP v3.25-3
Static routing is the best solution to implement when there is no redundancy in the network
topology. A single connection between the customer network and the service provider network
does not provide any redundancy. If the link goes down, the connection is lost regardless of
which routing protocol is configured in the customer or provider network. When there are
redundant connections between the customer network and the network of a single service
provider, static routing can be used under specific circumstances.
A static default route must be conditionally announced by the customer edge routers that are
using an Interior Gateway Protocol (IGP). If the link to one of the customer edge routers goes
down, then the router must be able to detect the failure and invalidate the static default route.
Announcement of this router as a default gateway that is using an IGP must now cease.
Likewise, on the service provider edge routers, the static routes that are pointing to the
customer networks must be invalidated if the link between them goes down, and redistribution
to BGP is therefore stopped.
If link-level procedures cannot detect a link failure, the interface remains in the up state. The
static routes are not invalidated, and packets are forwarded into a black hole. In such cases,
because the router cannot detect a failure at the link level, BGP must be used between the
customer and the provider.
BGP must also be used between the customer and the service provider networks when the
customer is multihomed. This is the case regardless of which link failure detection mechanisms
are in use.
5-23

This topic describes the characteristics of static routing between a customer and a service
provider in a BGP environment.

The customer network must announce a default route.
Redistribute default route into customer IGP if the
customer is running EIGRP.
Use default-information originate if the customer is running
OSPF or RIP.
Customer routes should be carried in BGP, not
core IGP.
Redistribute static routes into BGP, not IGP.
Routes to subnets of the provider address block should not
be propagated to other autonomous systems.
Mark redistributed routes with no-export community.
Use static route tags for consistent tagging.
BGP v3.25-4
When static routing is implemented between the customer network and the ISP network, the
edge router of the customer must announce itself as a default gateway or a gateway of last
resort. This procedure must be done using the IGP within the customer network because
different routers within the customer network must be able to select the best route to the exit
point of the network.
Different IGPs use different methods of announcing a router as a gateway of last resort.
Enhanced Interior Gateway Routing Protocol (EIGRP) uses the concept of default network,
while Open Shortest Path First (OSPF) and Routing Information Protocol (RIP) send
reachability information about network 0.0.0.0/0. In either case, the network operators of the
customer network are responsible for configuring their network to use the customer edge router
as a gateway of last resort.
When static routing is used between the customer and the provider, the edge router of the
provider must propagate a static route that points to the customer network, to all other routers
within the ISP network, and also to the rest of the Internet. The network operators in the ISP
network propagate the route using a configuration command to start redistributing the routes
into BGP.
Customer routes should not be redistributed into the IGP of the ISP network. Care should be
taken that the IGP of the ISP network does not carry too many routes. Redistributing customer
routes into the IGP could potentially cause poor performance and might eventually cause a
complete shutdown of IGP routing at the service provider.
5-24
If a customer uses provider-assigned (PA) addresses and the ISP announces a large block of
addresses for which the network of this customer is only a small portion of the block, then the
routes of this customer should not be propagated by the service provider to the rest of the
Internet. Instead, the rest of the Internet should receive only an announcement containing the
larger block of addresses.
An easy way of achieving this setup is to use communities within the ISP network. Any
customer route that should not be announced to the rest of the Internet is marked using the
no-export community. To ensure that the BGP communities are propagated, at least over all
Internal Border Gateway Protocol (IBGP) sessions, the network operators of the ISP network
must configure a send-community option for all IBGP neighbors. The edge routers of the ISP
network then see the no-export community and filter those routes out before sending the update
to External Border Gateway Protocol (EBGP) neighbors.
Communities are set using route-maps. A route-map can select routes based on various
attributes. One of these attributes is the route tag. Through configuration, a route tag can be
assigned by the router to specific static routes. This option means that the network operators of
the ISP network can invent a scheme of tagging where all static routes that should not be
propagated to other autonomous systems are assigned a specific tag. Then a route-map can
select all routes with that tag and assign them the no-export community.
5-25
Example: Characteristics of Static Routing

In the figure, the customer network is connected to the Internet by using a single permanent
connection to a single service provider.
Characteristics of Static Routing (Cont.)
Default route is configured on the

customer router
Default route is redistributed into
the customer network
Route for customer address space

is configured on provider router
Customer route is redistributed
into BGP
BGP v3.25-5
In this case, a routing protocol does not add any redundancy and would only add complexity.
The customer edge router has a static default route pointing to the interface serial 0. If the serial
interface goes down, the route becomes invalid. The default-information originate command
is configured in the OSPF process on the customer router; therefore, the router announces a
default route into OSPF as long as it has a valid default route itself.
The service provider edge router also has a static route, declaring the customer IP network
number as reachable over the serial 0 interface. It also becomes invalid if the interface goes into
the down state. The ISP edge router must forward this information to all other ISP routers and
to the rest of the Internet. This action is accomplished by redistributing the static route into
BGP. As long as the static route is valid, BGP announces it. To the rest of the Internet, the
customer network appears as reachable within the autonomous system (AS) of the ISP. As far
as the rest of the Internet is concerned, the customer is a part of the service provider AS.
5-26
Designing Static Route Propagation in a Service

Provider Network
This topic identifies the design considerations for propagating static routes in a service provider
network.
Designing Static Route Propagation in a

Service Provider Network
Identify all possible combination of services offered to a
customer, including QoS services.
Assign a tag to each combination of services.
Configure a route-map that matches defined tags and sets
BGP communities or other BGP attributes.
Redistribute static routes into BGP through a route-map.
For each customer, configure a static route toward the
customer with the proper tag.
BGP v3.25-6
You can easily extend the principle of using tags when you are configuring static routes, and of
assigning different communities based on those tags, to implement a more complex routing
policy. To propagate static routes in a service provider network, complete these steps:
Step 1
Identify all different service levels that are offered to customers and then all the
different combinations of these service levels.
Step 2
Assign each combination its own tag value and its own community.
Step 3
Configure a route-map, which selects routes with each of the assigned tags and sets
the corresponding community value. Because the processing of a route-map stops
when the match clause of a statement is met, each route should be assigned a single
combination of communities only. Therefore, you must take great care to assign a
tag and a community combination to each combination of services that are provided.
Note
Step 4
When the provider edge routers redistribute static routes into BGP, these routes must pass
through the route-map. BGP assigns the correct community depending on the tag values
that are given on the configuration line for each of the static routes.
Finally, configure static routes. Before you configure a static route for a specific
customer, you must identify the combination of the services that are provided to this
customer. Then you must look up the corresponding tag value. After you have
configured the route, you must assign the tag.
5-27
With this routing policy, every static route to a customer network is assigned a tag and the
redistributed BGP route is assigned a corresponding community. The BGP communities that
are attached to the routes signal to other routers in the ISP network which particular service
combination you should use.
5-28
Example: Static Route Propagation

This example shows a scenario with varied service levels in which static route propagation is
configured in a BGP environment.
Static Route Propagation Scenario

Sample service offering
Addressing
Provider-assigned address
blocks are not propagated to
upstream ISPs.
Provider-independent address
blocks are propagated to
upstream ISP.
Quality of service
Normal customers
Gold customers
Define static route tags
Advertise
Customer
Route
QoS
Type
Route
Tag
Community
Values
No
Normal
1000
no-export
387:31000
Yes
Normal
1001
387:31000
No
Gold
2000
no-export
387:32000
Yes
Gold
2001
387:32000
BGP v3.25-7
In this scenario, the service provider offers two different service levels to its customers: Normal
and Gold. Customers are also assigned IP address blocks. Some customers have PA addresses,
which the ISP does not announce as explicit routes. The large route summary block announced
by the ISP covers these customers. Other customers use provider-independent (PI) addresses
that must be explicitly announced to the Internet by the service provider.
Because there are two different quality of service (QoS) services, Normal and Gold, and
because there are both PA and PI addresses, the total number of combinations to cover the
network policy is four:
Normal QoS routes that are assigned by the ISP and should not be explicitly announced
Normal QoS routes that are PI routes and should be explicitly announced
Gold QoS routes that are assigned by the ISP and should not be explicitly announced
Gold QoS routes that are PI routes and should be explicitly announced
Each of these four combinations receives its own tag value and its own community
combination.
5-29
Static Route PropagationConfigure

Route-Maps
BGP v3.25-8
Network operators configure a route-map in the ISP edge router that has the static routes to the
customer network. Redistribution of the configured customer static routes into BGP is also
performed at the ISP edge router.
Because a route-map can match an individual route in a single route-map statement only, a
single tag value, representing each combination of services, must be assigned to the static
routes by the router. When a route is matched, the interpretation of the route-map for that
individual route stops. The route-map has one statement for each combination, and each
statement matches a tag value and assigns the corresponding community combination for that
tag.
The route-map is applied during the redistribution of customer static routes into BGP at the
provider edge router. Because the route-map has no permit any statement at the end, the static
routes that are not assigned any of the tags being used are not redistributed. The route-map
filters these routes out, forcing the network operators to make a tag assignment to all customer
routes. Furthermore, the route-map filtering can help catch administrator configuration entry
errors, thus giving all customers the service combination that they are entitled to.
5-30
Static Route PropagationRedistribution

and Customer Routes
BGP v3.25-9
The figure shows how the service provider edge router uses the route-map named IntoBGP
when redistributing static routes into BGP. Because the route-map assigns community values
that will be used by other routers within the ISP network, network operators must configure all
IBGP neighbors with the send-community qualifier.
Use the no auto-summary BGP configuration command to avoid having the subnet
11.2.3.0/24 automatically summarized into 11.0.0.0/8.
When connecting customers, the network operators identify which service combination to use
for this particular customer. The three services associated with this particular customer are as
follows:
Apply normal QoS
Use a PA network number
Do not enable the provider to explicitly announce customer routes
A static route to the customer is configured and assigned the appropriate tag value of 1000,
which represents the specified services that are assigned to the customer.
5-31
Static Route PropagationStatic Routes on

the Provider Edge Router
BGP v3.25-10
The show ip route command displays information from the routing table about subnet
11.2.3.0/24. The route is learned by static configuration and is redistributed via BGP. The
router, through the use of a statically assigned tag, has assigned a tag value of 1000 to the
customer route, and the route must pass through the route-map into BGP before being inserted
into the BGP table.
The show ip bgp command displays information from the BGP table about subnet 11.2.3.0/24.
The route is local within this AS and is sourced by this router. The BGP communities
387:31000 and no-export have been assigned by the router to the redistributed customer route
by using the provider-defined route-map prior to inserting the customer route into the BGP
table.
5-32

This topic explains how to configure a typical backup setup that uses static routing between a
customer and a service provider in a BGP environment.
BGP v3.25-11
This example illustrates a case where the customer network has two connections to a single
service provider. One connection between the customer network and the ISP is the primary
connection, and the other connection is used for backup purposes only. If link-level procedures
can detect link failures and a failure in the remote router, then static routing can be used instead
of a dynamic routing protocol between the customer and provider networks.
As in the previous example, where no backup link is available, the primary edge router of the
customer has a static default route toward the ISP and the primary edge router of the ISP has
static routes toward the customer. The customer router redistributes the static default route into
its IGP. The ISP router redistributes the static routes into BGP.
If the primary link goes down, the link-level procedures set the interface to the down state,
causing the static routes pointing out through the interface to be invalid and removing the
routes from the routing table. When the interface changes back to the up state, the static route
will reappear in the routing table.
Redistribution of routes into any routing protocol is conditioned by the appearance of the route
in the routing table. Thus, if the interface goes down, the router removes the static route from
its routing table, and the route is withdrawn from the routing protocol. When the static route
reappears, the redistribution process inserts it into the routing protocol again.
5-33
The backup edge router of the customer also uses a default static route toward the ISP, via the
backup link. The backup edge router is also redistributing the default route into the IGP.
However, the static route that is used is a floating static route, which is assigned a high
administrative distance (AD), higher than the AD of the customer IGP. As long as the primary
link works, the IGP provides the customer backup edge router with the primary default route.
Because of the higher AD, the backup static default route is not installed into the backup router
routing table. Because the static route is not in the routing table, it is not redistributed. If the
primary link fails, the IGP no longer feeds the backup edge router with a default route. The
backup static default route is the only remaining default route. Therefore, the router will install
the floating default route into its routing table and subsequently redistribute it into the IGP.
The backup edge router of the ISP can also use floating static routes, which are redistributed
into the ISP BGP process.
5-34
BGP Backup with Static Routes (Cont.)
BGP v3.25-12
In the figure, the customer network and the ISP network are connected using leased lines with
High-Level Data Link Control (HDLC) encapsulation. Both the primary and the backup edge
routers in the customer network have a static default route toward the serial interface leading to
the ISP. Both routers also do redistribution of the default route into the OSPF protocol, which is
being used as an IGP within the customer network.
However, the static default route in the backup edge router is configured with an AD value set
to 250. This AD value is higher than the AD values of any routing protocol. This configuration
means that as long as the backup router receives the default route by OSPF, the static default
route is not used.
When the primary link goes down, the static default route in the primary router is not valid. The
OSPF protocol stops announcing the default route, because the default-information originate
command makes OSPF contingent on the availability of that static default route in the routing
table before announcement.
The backup router now installs its static default route in the routing table. The conditions for
announcing the default route by OSPF are met and the rest of the customer routers see the
backup router as the gateway of last resort.
5-35
BGP v3.25-13
When floating static routes are configured on the provider edge routers, they are also
redistributed into BGP. This configuration makes things a little bit more complicated.
The network operator configures a floating static route to the customer subnet 11.2.3.0/24. In
the provider edge router, the floating static route is assigned the same tag value as the tag value
being used in the primary router. The route-map IntoBGP is the same as in the primary router
and provides the routes to the customer network with the same communities (the same QoS
level and indication whether to explicitly announce route prefix to the rest of the Internet).
The floating static route is configured with an AD value of 250. This value is higher than any
routing protocol. When the backup edge router of the ISP no longer receives any routing
protocol information about the customer networks, the router will automatically install the
floating static route and subsequently redistribute it into BGP.
Based on BGP route selection rules, the redistributed floating static route will always remain
the preferred path if additional BGP configuration is not performed on the provider edge router.
This preference means that regardless of whether the primary link comes back, the backup
router selects the locally sourced route as the best route. Therefore, the backup router continues
to announce a path toward the customer network. The backup link does not go back to the Idle
state.
5-36

The BGP table on the service provider backup router contains
the floating static route.
BGP v3.25-14
In this example, the show ip bgp command is used in the backup edge router of the provider to
display the information about the customer network 11.2.3.0/24. The primary link has come
back, so the backup router now sees two alternate routes. The first route is the route that the
router itself has redistributed into BGP using the floating static route. This route is locally
sourced by this AS and has been assigned a weight value of 32768. The second route is the one
that has been received by IBGP from the primary edge router. This AS also sources this route,
but no weight value is assigned.
The BGP route selection algorithm selects the route with weight value 32768 as the best. As a
result, the route that was received from the primary edge router is not a candidate to be installed
in the routing table and never competes with the floating static route. The floating static route
stays in the routing table, and redistribution of the route continues until the backup link goes
down and the route becomes invalid.
5-37

This topic describes the limitations of floating static routes when used in typical backup static
routing scenarios and the corrective actions to overcome these limitations.

Limitations and corrections
Floating static routes do not work correctly with BGP.
Weight has to be lowered to default value for other BGP
routes to be considered.
BGP local preference has to be changed for floating static
routes redistributed into BGP, to make sure other routes take
precedence.
Administrative distance cannot be matched with a route-map;
additional tags need to be defined for static routes.
BGP v3.25-15
Unfortunately, floating static routes do not work correctly with BGP. After they are inserted,
the floating static route is never removed from the routing table even if the primary link comes
back.
Whenever you use floating static routes in combination with redistribution into BGP, you will
need to take additional configuration steps to ensure that the BGP route selection algorithm
selects the primary route as the best BGP route when it reappears:
When a router redistributes a floating static route into BGP, the weight value assigned to
the floating static route must be reduced. Otherwise, the floating static route will always be
selected as the best BGP route after the first failure of the primary link occurs.
Local preference values must be also be assigned by the router to the floating static route so
that the floating static route has a lower local preference than the primary route. This
assignment ensures that the primary route is selected as the best BGP route after it comes
back.
These two requirements must be specified on the provider edge router in the route-map
IntoBGP that is used for the redistribution. The route-map must select the floating static routes
and set weight and local preference. However, a route-map cannot do matching based on the
AD value that has been assigned to a static route. Some other means are required to make it
possible for the route-map to distinguish between normal static routes that should have normal
weight and local preference and the floating static ones that should have their values modified.
The solution is to create additional tag values for this set of static routes. The tag value must not
only reflect the QoS level and whether to announce the route, but the tag value must also
indicate if it is a primary route or a backup route.
5-38
Floating Static Routes with BGP (Cont.)

Sample Static Route Tags with Backup
Advertise
Customer
Route
Backup
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
QoS Type
Tag
Community
Values
Local
Preference
Normal
1000
no-export
387:31000
100
Normal
1010
no-export
387:31000
50
Normal
1001
387:31000
100
Normal
1011
387:31000
50
Gold
2000
no-export
387:32000
100
Gold
2010
no-export
387:32000
50
Gold
2001
387:32000
100
Gold
2011
387:32000
50
BGP v3.25-16
Eight tag values have currently been identified. Each tag value indicates a specific combination
of explicit route propagation (backup or primary) and QoS level.
When network operators configure static routes in the provider edge router, they must consider
which of the combinations that they should use for the route. The route-map that they use when
redistributing the static routes into BGP must be configured to recognize all eight combinations
and to set the appropriate weight and community and local preference values.
5-39
Floating Static Routes with BGP (Cont.)

The redistribution route-map needs to be updated on all
provider edge routers.
Only the first half of the route-map is displayed.
BGP v3.25-17
The configuration output in the figure displays the first half of the route-map IntoBGP. The
output shows how four of the eight different tags are identified by match clauses. For each of
the tag values, the route-map sets the community, the local preference, and, in some cases, the
weight.
Because the displayed half of the route-map deals only with the four tags that indicate QoS
Normal, all statements in the configuration display have set the BGP community attribute to
387:31000. The part of the route-map that is not shown deals with the four tags that indicate
QoS Gold, which would be configured to set the BGP community attribute to 387:32000.
Tag values of 1000, 1010, 2000, and 2010 indicate that the route should not be explicitly
propagated. The routes that should not be explicitly advertised by the provider to the rest of the
Internet are assigned the no-export community by the route-map.
Tag values 1010, 1011, 2010, and 2011 all indicate that the route is a backup route. Those tags
have their weight value set to 0 and their local preference value set to 50. These settings ensure
that on the return of a failed primary route, the provider edge router will select the primary
route as its best path and remove the backup floating static route from its route table.
5-40
Load Sharing with Static Routes

This topic describes the characteristics of load sharing when you are configuring static routing
between a customer and a service provider.
Load Sharing with Static Routes:

Outgoing Traffic
Outgoing traffic load sharing is easy to achieve.

Each customer router uses the closest customer edge router as the
exit point.
Balanced load sharing is achieved if the customer edge routers are
collocated.
BGP v3.25-18
Load sharing of outgoing customer traffic is accomplished by configuring a standard default

static route in both customer edge routers. Each static route is valid as long as the serial link in
each router is up. When both static routes are valid, both customer edge routers announce the
default route into the customer network.
The remaining routers in the customer network see two candidate gateways of last resort. These
remaining routers choose the closest one, with respect to the IGP metric. The part of the
network that is closer to the uppermost exit point uses that exit point for all outgoing traffic.
The other part of the network uses the other (lower) exit point.
If both exit points are collocated, they are equally distant from each of the other routers in the
customer network. Each router within the customer network therefore uses load sharing of
traffic sent out both exit points.
5-41

Return Traffic
Load sharing of return traffic is impossible to achieve with

multiple edge routers.
All provider routers select the same BGP route to the destination.
All return traffic arrives at the same provider edge router.
BGP v3.25-19
The provider routers receive routes toward the customer network via BGP. BGP in its default
behavior selects a single route as the best route, allowing no load sharing. The provider routers
that receive the same BGP route from two edge routers will always select the closer edge router
(if all other BGP attributes are equal, the IBGP route with the closer next hop is selected). The
part of the ISP network that is closer to the uppermost connection uses that connection. The
other part of the ISP network uses the other (lower) connection.
If both connection points are collocated, all provider routers select the same IBGP route based
on router-ID (because the IGP metrics are always equal) and all the return traffic is sent over a
single link toward the customer network, resulting in no load sharing.
Note
5-42
Since Cisco IOS Software Release 12.2, the IBGP multipath load-sharing feature enables
the BGP-speaking router to select multiple IBGP paths as the best paths to a destination.
The best paths or multipaths are then installed in the IP routing table of the router.

Optimizing Return Traffic
You can optimize return traffic load sharing.
Each provider edge router advertises only part of the
customer address space into the provider backbone.
Every provider edge router also advertises the whole
customer address space for backup purposes.
Load sharing is not optimalevery link will carry

return traffic for part of the customer address space.
BGP v3.25-20
To obtain better control of the return traffic load, the customer address space must be
advertised to the provider edge routers using multiple, more explicit routes. The upper edge
router could advertise half the address space, and the lower edge router could advertise the
other half. For backup reasons, they also should both advertise the entire address space as a
larger route summary.
As long as both paths are available, the traffic from the ISP to the customer uses the most
explicit route. In this case, two explicit routes are used to send traffic representing one half of
the address space over one link and traffic representing the other half of the address space over
the other link.
Load sharing in this way does not result in an equal load on the links but rather a statistically
based distribution of the traffic load over the links.
5-43
Example: Load Sharing with Static Routes

In the example, the customer address space 11.2.3.0/24 is partitioned into two smaller blocks:
11.2.3.0/25 and 11.2.3.128/25.

Optimizing Return Traffic (Cont.)
BGP v3.25-21
The upper provider edge router advertises the route to 11.2.3.0/25, and the lower router
advertises the route to 11.2.3.128/25. Both edge routers also advertise the entire address space
11.2.3.0/24.
The routers in the ISP network direct traffic with destination addresses in the 11.2.3.0/25 range
to the upper connection point. Traffic to destinations in the 11.2.3.128/25 range is directed to
the lower connection point.
5-44
Summary
Summary
You can use static routing in most cases when the customer
network is connected to a single ISP. If there is a single
connection, you should always use static routing, because
there is no redundancy.
In static routing, the customer network must announce a
default route; customer routes should be carried in BGP, not
core IGP; and routes to subnets of the provider address block
should not be propagated to other autonomous systems.
In propagating static routes in a service provider network,
identify all different service levels that are offered to
customers and then all the combinations of these service
levels, assign each combination its own tag value and its own
community, configure a route-map, and configure static
routes.
BGP v3.25-22
Summary (Cont.)
Depending on the origin of the customer address space, the
provider may elect not to advertise the customer space,
choosing to advertise a larger aggregate route instead.
When you are using static routes in a backup scenario,
floating static routes are used on the backup routers. After
the backup floating static route becomes active, its AD is
ignored by BGP because the locally originated route will
have a higher weight and be preferred, requiring the use of
BGP attributes to ensure proper floating static operation.
Load balancing can be achieved for outgoing traffic. Return
traffic causes problems when multiple connections exist to
more than one provider router.
BGP v3.25-23
5-45
5-46
Lesson 3
Connecting a Multihomed
Customer to a Single Service
Provider
Overview
When multiple connections to the same service provider are the only means that a customer has
of connecting to the Internet, it is important that the connections be correctly configured to
ensure proper interaction between the customer and service provider network. It is also
important to understand how to configure routing protocols so that customer backup or loadbalancing requirements are met.
This lesson discusses the use of multiple connections between a customer and a single Internet
service provider (ISP) for backup and load-sharing purposes. Included in this lesson is a
discussion of how to configure a customer network and a provider network to accommodate
multiple connections between them. Also discussed in this lesson are topics specific to
networks with multiple connections between a customer and a single provider, such as private
autonomous system (AS) number removal and configuration of a network to support either
backup links or load sharing (balancing).
Objectives
Upon completing this lesson, you will be able to implement customer connectivity using BGP
in a customer implementation in which you must support multiple connections to a single ISP.
Configure BGP on a customer network to establish routing between a multihomed
customer and a single service provider
Configure conditional advertising of a customer address space when you are using BGP to
establish routing between a multihomed customer and a single service provider
Configure BGP on a service provider network to establish routing between a multihomed
customer and a single service provider
Disable the propagation of private AS numbers to EBGP peers in a service provider
network where a multihomed customer is advertising private numbers in the AS path
Describe the BGP Support for Dual-AS Configuration for Network AS Migrations feature
Configure a typical backup setup between a multihomed customer and a single service
provider in a BGP environment
Describe how you can implement load sharing between a multihomed customer and a
single service provider in a BGP environment
Identify the Cisco IOS command that is required to configure load sharing between a
multihomed customer and a single service provider using BGP multipath
Configure load sharing between a multihomed customer and a single service provider using
EBGP multihop
5-48
Configuring BGP on Multihomed Customer

Routers
This topic describes how to configure Border Gateway Protocol (BGP) on a customer network
to establish routing between a multihomed customer and a single service provider.

Routers
BGP v3.25-3
In the example, the customer network is connected to a service provider network using multiple
permanent links. BGP is used to exchange routing information between the customer and the
provider.
Selecting BGP as the routing protocol between the customer and provider network ensures that
a link failure or the failure of a remote router is detected. In this scenario, the customer does not
require the use of a public AS number or full Internet routing. Instead, a private AS number is
assigned to the customer network, and the ISP sends a default route to the customer through
BGP.
The big difference in this case, as compared to a network scenario where static routes and
redistribution are used, is that routers within the private AS of the customer now advertise the
customer routes via BGP. Thus, the customer is responsible for announcing its own address
space. The ISP receives routes from the customer and conditionally propagates them (similar to
static routing). If the customer uses provider-assigned (PA) address space and the ISP can
summarize the address space, it will not propagate the explicit routes from the customer to the
Internet. The private AS number in the AS-path attribute must be removed before the ISP can
propagate any of the customer routes.
5-49
Because the customer is now creating BGP routes that are received by the ISP, any error made
by the customer can influence routing operation within the ISP network and, if propagated,
within the Internet as a whole. Announcing a route to a network to which the customer has not
been assigned may cause routing problems. There is always a risk that such routing problems
can occur in a service provider network. However, the risk is much greater when the customer,
whose network administrators usually have less experience with BGP, enters the configuration.
To reduce the risk of erroneous route advertising, the ISP should always filter any BGP
information that it has received from the customer network. The ISP should reject routes to
networks that are not expected to be in the customer AS. Routes that contain an AS path with
unexpected AS numbers should also be rejected.
5-50
Example: Configuring BGP on Multihomed Customer

In the figure, the customer has been assigned the private AS number 65001.

Routers (Cont.)
The customer address space is advertised on every customer edge router.

Customer edge routers run IBGP between themselves and advertise the default
route to the rest of the customer network.
BGP v3.25-4
Both customer edge routers are configured to run BGP and should advertise all of the customer
networks with the network command. If only one router advertises the network, a single point
of failure has been introduced. The two customer edge routers must also run IBGP between
them to make common decisions regarding BGP routing information.
Each customer edge router has an External Border Gateway Protocol (EBGP) session with the
ISP router on the other side of the link. Over that EBGP session, the ISP announces only a
default route to the customer AS. When EBGP receives the default route, it installs it in the
routing table and redistributes it into the Interior Gateway Protocol (IGP) in this case, Open
Shortest Path First (OSPF) of the customer.
5-51
Conditional Advertising in Multihomed Customer

Networks
This topic describes how to configure conditional advertising of a customer address space when
you are using BGP.
Conditional Advertising in Multihomed

Customer Networks
Customer edge routers should announce the whole customer
address space into BGP.
The static route covering the whole customer address should
point to the core of the customer network, not to null 0.
The customer edge router revokes the BGP announcement of
customer address space if the edge router loses connectivity
with the customer core.
BGP v3.25-5
As a rule of thumb, the customer should announce addresses as large as possible (the larger the
address space that can be aggregated, the better). The BGP advertisement is configured on the
customer edge routers using the network command. Route advertisement is conditioned by the
appearance of a corresponding network or subnet in the routing table of the edge router. If the
network or subnet is manually entered into the routing table by configuring a static route to null
0, the condition is always true because the static route is always there, and the BGP
advertisement is always performed.
If the customer edge router loses connectivity to the rest of the customer network but is still
connected to the ISP network, BGP advertisement must cease. In this case, BGP advertisement
can be stopped if BGP advertisements are bound to the reachability status of a specific subnet
in the core of the customer network, according to the customer IGP.
The problem with using a static route to null 0 is that it conditions the network statement in the
BGP configuration so that BGP always advertises the route. If the customer edge router loses
connectivity with the rest of the customer network, the router continues to advertise the entire
customer address space. The ISP network receives a valid route from the customer edge router.
Traffic is sent to this router, but because the router has lost connectivity with the rest of the
network, the traffic is dropped (routed to the null 0 interface using the static route).
5-52
Example: Conditional Advertising in Multihomed Customer

Networks
In this example, the customer network uses the address space 13.5.0.0/16.
Conditional Advertising in Multihomed

Customer Networks (Cont.)
BGP v3.25-6
The address space is further subnetted at the customer site. One of the subnets (subnet
13.5.1.0/24) is identified as being a central part of the customer core network.
The customer edge routers participate in the IGP routing of the customer. This participation
means that these routers have information about which of the subnets within the address space
13.5.0.0/16 are currently reachable. If these subnets are available, there is an explicit route to
each of them. If any of the subnets go down, or if the path toward them goes down, the route to
that subnet is removed from the routing table.
The BGP advertisement in each of the customer edge routers is configured to advertise the full
address space that is used by the customer. When this route is advertised by the customer edge
routers, the ISP network, and thus the rest of the Internet, see the complete address space of the
customer as one single route, 13.5.0.0/16.
Advertisement of the customer address space by BGP is conditioned by the appearance of the
static route, IP route 13.5.0.0 255.255.0.0 13.5.1.1. If the static route is valid, then the BGP
route 13.5.0.0/16 is advertised. The static route is a recursive route, which means that the router
takes another look in the routing table for the address 13.5.1.1 before determining what to do
with the static route. The idea is that 13.5.1.1 is reachable via the IGP. The subnet 13.5.1.0/24
is announced by the IGP. If this subnet is reachable by the edge router, then the static route to
13.5.0.0/16 is valid. If there is no route to 13.5.1.1, then the static route is invalid.
Note
The condition, whether or not to advertise the entire customer address space 13.5.0.0/16, is
controlled by the IGP reachability of a single subnet, 13.5.1.0/24.
The IGP configuration also includes origination of the default route by both edge routers.
5-53
Configuring BGP on Service Provider Routers

This topic describes how to configure BGP on a service provider network to establish routing
between a multihomed customer and a single service provider.
Configuring BGP on
Service Provider Routers
The service provider must:

Advertise a default route to the customer through BGP
Filter incoming BGP updates with a prefix-list to verify that the customer
announces only the assigned address space
Filter incoming BGP updates with an AS-path filter-list to verify that the customer
uses only its own AS number
Optionally, the no-export community should be set on customer routes.

BGP v3.25-7
In the ISP network, the two edge routers must have BGP sessions configured for the customer.
There is no point in feeding the full Internet routing table to the customer, because the table
contains the same set of routes for both links and the customer always uses the ISP for all
traffic toward the Internet. Injection of a default route in the customer network would
accomplish the same task.
The customer is responsible for its own advertisements. Because customers are much less likely
to be experienced in BGP configuration than the ISP, they are more likely to make errors.
Therefore, the ISP must protect itself and the rest of the Internet from those errors.
The service provider should use a prefix-list that allows only customer-assigned routes and
denies any other route to ensure that private address space or any other illegal networks that are
erroneously announced by the customer never reach the ISP BGP table. Filtering based on the
AS path also provides some protection from customer configuration errors. Only routes that
originated within the customer AS are allowed. A filter-list performs this check.
If the customer address space is PA address space and it represents only a small part of a larger
block that is announced by the ISP, the explicit BGP routes that are received from the customer
need not be advertised to the rest of the Internet. The ISP can announce the big block, attracting
any traffic toward any subnet within the block. After the traffic enters the ISP network, the
more explicit routes to the customer network are available and used. In this case, the provider
edge router can tag the BGP routes that are received from the customer with the no-export wellknown community, restricting them from being sent by the ISP to any other AS.
5-54
Configuring BGP on
Service Provider Routers (Cont.)

By default, the default route (0.0.0.0/0) is not advertised in
outgoing BGP updates.
The neighbor default-originate command advertises the default
route to a BGP neighbor even if the default route is not present
in the BGP table.
Note: The default route is not sent through the outbound BGP
filters (prefix-list, filter-list, or route-map).
BGP v3.25-8
The default route, 0.0.0.0/0, is not advertised in outgoing BGP updates unless it is explicitly
configured. The neighbor default-originate router configuration command is used to initiate
the advertisement of the default route to a neighbor.
No checking is done by BGP before the default route is advertised. The default route does not
need to be present in the BGP table before it is advertised using this command. The default
route is also sent without being filtered by any outgoing prefix-lists, filter-lists, or route-maps.
5-55
Example: Configuring BGP on Service Provider Routers

This example shows the configuration of an ISP edge router.
Configuring BGP on
Service Provider Routers (Cont.)
BGP v3.25-9
The customer is assigned the private AS number 65001. The BGP session is opened with the
customer IP address, 10.0.0.1.
The ISP sends the default route only to the customer. This route is configured using first the
default-originate command and then the prefix-list DefaultOnly.
Received routes from the customer must first pass the prefix-list CustomerA. There is one
dedicated prefix-list for each individual customer; the prefix-list permits only the routes that the
customer is allowed to announce. If the routes are allowed by the prefix-list, they must also
pass the filter-list named 15 in. In this case, the filter allows the private AS of the customer in
any number of repetitions, as long as it is the only AS number in the path. This filter-list allows
for AS-path prepending configurations on the customer side. If the received route is allowed by
both the prefix-list and the filter-list, then the route-map AllCustomersIn is applied.
The route-map is a general route-map that is used for all customers. It checks every route that is
received, via the prefix-list Provider, and if the route is within the big block of PA address
space that the ISP announces to the rest of the Internet, the customer route is marked with the
no-export community. This mark means that the route is used within the ISP AS only and is not
sent to the rest of the Internet.
Routes that are received from the customer and are allowed by the prefix-list and filter-list, but
do not fall within the PA address space, are allowed by the route-map and are not changed in
any way. The ISP propagates these routes to the rest of the Internet.
5-56

This topic describes how to disable the propagation of private AS numbers to EBGP peers in a
service provider network in which a multihomed customer is advertising private numbers in the
AS path.
Private AS Number Propagation
Private AS numbers should not be advertised into the Internet.

The private AS numbers must be removed from the AS path before the
customer BGP routes are advertised to other service providers.
BGP v3.25-10
Routes that are received by the ISP from the customer are propagated to the rest of the Internet
only if they are part of the provider-independent (PI) address space.
When the ISP receives BGP routes from the customer, the AS-path attribute of the received
routes contains only the AS number of the customer. If the customer uses AS-path prepending,
there may be several repetitions of the customer AS number in the AS path. If customer routes
are propagated by the service provider to the Internet, the AS number of the customer will be
present in the AS path unless it is explicitly removed.
Note
If the customer has been assigned a private AS number, this AS number must never be
advertised by any router to the rest of the Internet.
Removal of a private AS number from the AS path is accomplished by using the removeprivate-as command on the ISP EBGP sessions with the rest of the Internet. In the figure,
removal of the private AS number takes place on the EBGP session between AS 387 and AS
217.
5-57

The command modifies AS-path processing on outgoing
updates sent to specified neighbor.
Private AS numbers are removed from the tail of the AS path
before the update is sent.
Private AS numbers followed by a public AS number are not
removed.
The AS number of the sender is prepended to the AS path after
this operation.
BGP v3.25-11
neighbor remove-private-as
To remove private AS numbers from the AS path (a list of AS numbers that a route passes
through to reach a BGP peer) in outbound routing updates, use the neighbor remove-privateas router configuration command.
neighbor {ip-address | peer-group-name} remove-private-as
no neighbor {ip-address | peer-group-name} remove-private-as
Syntax Description
Parameter
Description
Use this command on the service provider egress routers. Before any of the customer routes of
the ISP are advertised by the service provider to the rest of the Internet, the AS numbers in the
range 64512 to 65535 must be removed. The command removes those AS numbers if they are
at the tail end of the AS path.
Caution
Private AS numbers followed by public AS numbers are not removed because the
commands visibility is only on the last (tail end) AS number.
The AS number of the ISP is automatically prepended to the AS-path attribute after the
remove-private-as operation has completed. This situation means that the AS number of the
ISP has not already been prepended to the AS-path attribute when the tail of the AS path is
checked for private AS numbers.
5-58
Example: Removing Private AS Numbers

In this example, the service provider AS (387) receives routes from the customer.
Removing Private AS Numbers (Cont.)
BGP v3.25-12
The customer is assigned the private AS number 65001 by the ISP; therefore, routes that are
received by the provider have an AS path containing only AS 65001. This information should
be kept and used within the ISP network and should never be propagated to the rest of the
Internet (AS 217 in this example).
The edge router in AS 387 has been configured to remove private AS numbers on EBGP routes
toward AS 217. If private AS numbers appear in the tail end of the AS path (before AS 387 is
added), they are removed.
This configuration must be applied to all egress routers in AS 387 that serve EBGP neighbors
leading to other ISPs. No private AS number may be present in an AS path of a route that is
propagated to a network using a public AS number.
5-59
BGP Support for Dual AS Configuration for

Network AS Migrations
This topic describes the BGP Support for Dual AS Configuration for Network AS Migrations
feature.
BGP Support for Dual AS Configuration for

Network AS
Allows you to merge a secondary AS under a primary AS
without disrupting customer peering sessions
Allows a router to appear, to external peers, as a member of
secondary AS during the AS migration
Allows a network operator to merge the autonomous
systems and then later migrate customers to new
configurations during normal service windows without
disrupting existing peering arrangements
If misconfigured, increases the possibility that routing loops
can be created
BGP v3.25-13
AS migration can be necessary when a telecommunications provider or ISP purchases another

network. It is desirable for the provider to be able to integrate the second AS without disrupting
existing customer peering arrangements. The amount of configuration required in the customer
networks can make this a cumbersome task that is difficult to complete without disrupting
service, however.
The BGP Support for Dual AS Configuration for Network AS Migrations feature allows you to
merge a secondary AS under a primary AS without disrupting customer peering sessions. The
configuration of this feature is transparent to customer networks. This feature allows a router to
appear, to external peers, as a member of secondary AS during the AS migration. It also allows
the network operator to merge the autonomous systems and then later migrate customers to new
configurations during normal service windows without disrupting existing peering
arrangements.
The neighbor local-as command is used to customize the AS-path attribute by adding and
removing AS numbers for routes received from EBGP neighbors.
5-60
neighbor local-as
To customize the AS-path attribute for routes received from an EBGP neighbor, use the
neighbor local-as command in address-family or router configuration mode.
neighbor ip-address local-as [as-number [no-prepend [replace-as [dual-as]]]]
To disable AS-path attribute customization, use the no form of this command.
no neighbor ip-address local-as
Syntax Description
Parameter
Description
Specifies the IP address of the EBGP neighbor.
Specifies an AS number to prepend to the AS-path attribute.

The range of values for this argument is any valid AS number
from 1 to 65535.
(Optional) Does not prepend the local AS number to any routes

received from the EBGP neighbor.
(Optional) Prepends only the local AS number to the AS-path

attribute.
The AS number from the local BGP routing process is not
prepended.
(Optional) Configures the EBGP neighbor to establish a peering

session using the real AS number (from the local BGP routing
process) or by using the AS number configured with the ipaddress argument (local-as)
Note
AS-path customization increases the possibility that routing loops can be created if it is
misconfigured. The larger the number of customer peerings, the greater the risk. You can
minimize this possibility by applying policies on the ingress interfaces to block the AS
number that is in transition or routes that have no local-as configuration.
Caution
BGP prepends the AS number from each BGP network that a route traverses to maintain
network reachability information and to prevent routing loops. This feature should be
configured only for the AS migration and should be deconfigured after the transition has
been completed. This procedure should be attempted only by an experienced network
operator, because routing loops can be created with improper configuration.
5-61
Dual-AS Configuration: Example

The following examples show how this feature is used to merge two autonomous systems
without interrupting peering arrangements with the customer network. The neighbor local-as
command is configured to allow Router1 to maintain peering sessions through AS 100 and
AS 200. Router2 is a customer router that runs a BGP routing process in AS 300 and is
configured to peer with AS 200.
AS 100 (provider network):

AS 200 (provider network):

AS 300 (customer network):

After the transition is complete, the configuration on Router3 can be updated to peer with
AS 100 during a normal maintenance window or during other scheduled downtime.

5-62
Dual-AS Confederation Configuration: Example

The following example can be used in place of the Router1 configuration in the previous
example. The only difference between these configurations is that in this example Router1 is
configured to be part of a confederation.

Replace-AS Configuration: Example

The following example strips private AS 64512 from outbound routing updates for the
10.3.3.33 neighbor and replaces it with AS 300:

5-63

This topic explains how to configure a typical backup setup between a multihomed customer
and a service provider in a BGP environment.

The route selection is controlled entirely by the
customer routers.
Local preference is used to differentiate primary and backup
links for the outgoing traffic.
The MED is used to differentiate primary and backup links for
the return traffic.
No service provider configuration is required.
BGP v3.25-14
When a customer uses BGP on multiple links between its network and the ISP network, the
customer is solely responsible for controlling how it uses the links. The customer can choose to
use its links in a primary/backup scenario or in a load-sharing scenario.
If one link is primary, then the other should be used for backup only. The customer can use the
local preference configuration to direct all outgoing traffic over the primary link.
Incoming traffic to the customer is controlled by using either AS-path prepending or the multiexit discriminator (MED). Because the customer has multiple connections to the same AS, the
MED is the ideal attribute to use. When the customer announces its routes to the ISP, a bad
(high) MED value on the backup link and a good (low) value on the primary link are set.
The MED and AS-path length are checked by the receiving EBGP peer only if the weight and
local preference attributes have not been configured. In this case, the ISP should not use any of
these configuration options. The ISP should rely solely on the attributes that it has received
from the customer.
5-64
Example: Primary/Backup Link Selection

In the figure, the customer is connected to the ISP over two permanent connections.
Primary and Backup Link Selection
BGP v3.25-15
The customer uses the upper connection as the primary connection and the lower connection as
the backup.
The BGP configuration on the ISP side is transparent. This transparency means that no
particular preference is configured to use the upper or lower connection. The ISP relies on the
attribute values that are received from the customer.
The primary edge router on the customer side is configured to set local preference to the value
100 on all EBGP routes that are received. The backup edge router sets the local preference
attribute to a value of 50. This configuration means that the outgoing traffic toward any
destination that is announced by the ISP is primarily sent over the upper link.
Incoming traffic to the customer is directed to the primary link by using the MED. In the
primary edge router of the customer, all routes that are sent to the ISP have their MED attribute
set to the value 1000 by the route-map named LowMED out. In the backup edge router of the
customer, all routes that are sent to the ISP have their MED attribute set to the value 2000 by
the route-map named HiMED out. Because the ISP receives the routes with all other
attributes set to the same values, the MED values direct traffic for the customer to the primary
link.
5-65
Load Sharing with the Multihomed Customer

This topic describes how you can implement load sharing between a multihomed customer and
a service provider in a BGP environment.
Load Sharing with the Multihomed

Customer
Load sharing of outgoing customer traffic is
identical to the static routing scenario.
You can implement load sharing of return traffic in a
number of ways:
Announce portions of the customer address space to each
upstream router
Configure BGP multipath support in the service provider
network
Use EBGP multihop in environments where parallel links run
between a pair of routers
BGP v3.25-16
Load sharing of outgoing traffic from the customer network is identical to the static routing
scenario. The customer IGP is configured to send information about a gateway of last resort.
There is no difference whether the edge router gets its default by static routing or by incoming
EBGP updates.
Load sharing of the return traffic coming back to the customer network from the ISP can be
implemented in a number of ways:
The customer can divide its address space into several announcements. The customer edge
router can send each announcement over one of its EBGP sessions with the ISP. For
backup purposes, the customer should advertise the entire address space over all of its
EBGP sessions. The ISP now uses the most explicit route rule, and as long as both links are
up, traffic with destinations within one part of the customer address space is routed over
one of the links and traffic to the other part is routed over the other link.
If the customer announces equivalent routes over both links, the ISP routers use the closest
connection with respect to the IGP of the ISP. If an ISP router has an equivalent distance to
both connection points, the use of the maximum-paths (BGP multipath) option causes
load sharing.
If the multiple links between the customer and the ISP network terminate in one single
router on the customer side and one single router on the ISP side, the two routers must
establish their EBGP session from loopback interface to loopback interface. Static or
dynamic routing is required for one router to get information on how to reach the loopback
interface of the other router. The use of the ebgp-multihop option is also required because
the address of the neighbor is not directly connected.
5-66
Load Sharing with BGP Multipath

This topic presents the Cisco IOS command that is required to configure load sharing between a
multihomed customer and a service provider through the use of BGP multipath.
Configuring BGP Multipath Support

By default, BGP selects a single path as the best path and
installs it in the IP routing table.
With maximum-paths configured, a BGP router can select several
identical EBGP routes as the best routes and install them in the
IP routing table for load-sharing purposes.
The BGP router can install up to six BGP routes in the IP routing
table.
BGP v3.25-17
By default, BGP route selection rules select one, and only one, route as the best. If there are
two identical routes, the tiebreaker is either the most stable route or the router-ID of the peer
router that is advertising the route. However, when the maximum-paths router configuration
command is used, the BGP route selection process will select more than one route as best if
they are identical. The routes are all installed in the routing table, and load sharing takes place.
maximum-paths
To control the maximum number of parallel routes that an IP routing protocol can support, use
the maximum-paths command in address family or router configuration mode.
maximum-paths number
To restore the default value, use the no form of this command.
no maximum-paths
Syntax Description
Parameter
Description
Maximum number of parallel routes that an IP routing protocol

installs in a routing table, in the range of 1 to 6
5-67
Note
Load sharing between alternative BGP routes is achieved only if the EBGP routes are
identical according to all BGP route selection rules and maximum-paths is configured with
a value larger than 1.
A BGP router can install up to six BGP routes in the IP routing table. The actual type of load
sharing (per-session or per-packet) that occurs between the routes depends on the switching
mode that is used.
5-68

This topic describes how to configure load sharing between a multihomed customer and a
service provider through the use of EBGP multihop.
Because of recursive lookup, load sharing toward a BGP

destination always occurs if there are several equal-cost IGP paths
to the BGP next hop.
Equal-cost IGP paths are easily generated if the BGP next hop is not
directly connected.
BGP v3.25-18
When two adjacent routers have multiple links between them, you can configure the EBGP
session from loopback interface to loopback interface. In this case, you must use the ebgpmultihop option to make the BGP session go into the active state. There must be static or
dynamic routing in use to provide both routers with information on how to reach the loopback
interfaces of each other. Otherwise, their EBGP session does not complete establishment.
Routing to the loopback interface of the neighboring router is required to establish the EBGP
session and is also used in the recursive lookup when the routes are installed by the router in its
routing table. The two routes to the loopback interface of the neighboring router should be
equivalent for load sharing to occur.
After configuration, one single EBGP session is established between the two routers. This
session is used to exchange the routing information. There is only one BGP route to each
destination, and it has a next hop that refers to the loopback interface of the other router.
Before installing a route to a specific destination in its routing table, a router will perform a
recursive lookup to resolve the next hop. In this case, the recursive lookup will result in finding
two alternative routes. The router will install the BGP route to the final destination twice in the
routing table (Forwarding Information Base [FIB]). The first time, the route is installed with
one of the resolved next-hop addresses, and the second time with the other resolved next-hop
address. Because multiple equal-cost paths exist, the router can load-share over the two paths,
depending on the switching mode.
5-69
Configuring Multihop EBGP Sessions

By default, EBGP neighbors must be directly connected.
The ebgp-multihop command declares an EBGP neighbor to be
distant (several hops away).
The number of hops can be specified in the TTL parameter.
This command is usually used to run EBGP between loopback
interfaces for dial backup or load-sharing purposes.
Use with extreme caution; routing loops can occur very easily.
BGP v3.25-19
By default, EBGP neighbors must be directly connected. Cisco IOS software verifies that an
EBGP neighbor is reachable as directly connected over one of the router interfaces before the
session goes into the active state. For an EBGP session, IP packets that carry the TCP segments
with BGP information are also sent using a Time to Live (TTL) value set to the value 1. This
value means that they cannot be routed.
The ebgp-multihop neighbor configuration command changes this behavior. Although the
neighbor is several hops away, the session goes into the Active state, and packets start to be
exchanged. The TTL value of the IP packets is set to a value larger than 1. If no value is
specified on the command line, 255 is used.
Use the ebgp-multihop command when you are establishing EBGP sessions between loopback
interfaces for load-sharing purposes. You must take great care when using ebgp-multihop,
because proper packet forwarding relies on all the intermediate routers along the path to the
EBGP peer to make the correct forwarding decision. If the intermediate routers have a correct
path to the EBGP peer but a wrong path to the final destination, the packet may get into a
routing loop.
5-70
Example: Load Sharing with EBGP Multihop

In the figure, the customer network and the ISP network are connected using two parallel links
between a single router on the customer side and a single router on the ISP side.
Load Sharing with EBGP Multihop (Cont.)
BGP v3.25-20
In this case, only one EBGP session is configured between the customer and provider routers.
The session should be established from the loopback interface in one router to the loopback
interface in the other.
Each of the two edge routers has two static host routes that point to the loopback interface on
the other router. The EBGP session is established from loopback to loopback using ebgpmultihop.
The customer receives an EBGP route from the ISP with the next hop set to 1.0.0.1. The
customer edge router performs a recursive lookup and finds that it can reach 1.0.0.1 via 2.0.0.1
and via 2.0.0.5. These two routes are equivalent. Therefore, the route to the final destination is
installed in the routing table of the customer router using both paths.
Depending on the switching mode in use, load sharing is done per packet, per destination, or
per source and destination pair.
In this example, link-level procedures ensure that if one of the links goes down, the
corresponding static link goes down. All BGP routes in the routing table that rely on the static
route to the link that went down are invalidated. However, the BGP routes in the routing table
that rely on the remaining link are still valid and used.
5-71
Summary
Summary
When a customer has multiple connections to a single ISP and the
link-level procedures cannot detect a link failure, a routing protocol
is required. For security reasons, this routing protocol must be BGP.
The AS number that is used by the customer does not have to be a
public AS number; it can be a private AS number in the range 64512
to 65535.
When conditionally advertising customer networks to the ISP, you
should use a static route covering the whole customer address
space and pointing to the core of the customer network instead of
null 0.
The ISP should advertise a default route to the customer through
BGP. Incoming filters should also be used by the provider to ensure
that only the correct address space and AS number are advertised
by the customer.
The BGP Support for Dual AS Configuration for Network AS
Migrations feature allows you to merge a secondary AS under a
primary AS without disrupting customer peering sessions.
BGP v3.25-21
Summary (Cont.)
Private AS numbers must never be propagated to the rest of the
Internet. The ISP must therefore remove the private AS numbers from
the AS path before sending them to another public AS.
You can use parallel links between the customer network and the
network of a single ISP for backup or load-sharing purposes. The
customer can control the outgoing load using local preference and
also control the incoming load using the MED (metric) attribute. With
the MED, the links go to a single remote AS.
By announcing portions of its address space, a customer can use
maximum paths and EBGP multihop to provide load sharing over
multiple links.
EBGP multihop can be used for load balancing only if redundant links
terminate on the same provider router.
5-72
BGP v3.25-22
Lesson 4
Connecting a Multihomed
Customer to Multiple Service
Providers
Overview
When a customer requires the maximum redundancy in its network design, it should implement
a multihomed strategy that uses multiple service providers. This configuration requires specific
considerations to be implemented properly. Addressing and autonomous system (AS) number
selection are important considerations that affect the implementation of the network. It is also
important to understand how to configure routing protocols so that customer backup or loadsharing requirements are met.
This lesson discusses using multiple connections between a customer and multiple service
providers for backup and load-sharing purposes. Also included in this lesson is a discussion of
the Border Gateway Protocol (BGP) characteristics that are used to configure customer and
provider networks to accommodate the multiple connections between them. This lesson also
discusses topics specific to networks with multiple connections between a customer and
multiple providers such as address selection, private AS number translation, and configuration
of the network to support either backup links or load sharing.
Objectives
Upon completing this lesson, you will be able to implement customer connectivity using BGP
in a customer scenario where you must support connections to multiple ISPs. This ability
Describe BGP configuration characteristics that are used to establish routing between a
multihomed customer and multiple service providers
Describe addressing strategies that are available to a multihomed customer that is
connected to multiple service providers
Describe AS numbering strategies that are available to a multihomed customer that is
connected to multiple service providers
Describe the operation of AS number translation
Describe how you can implement a typical backup setup between a multihomed customer
and multiple service providers in a BGP environment
Describe the use of BGP attributes to influence inbound link selection in customer
networks that are multihomed to multiple service providers
Describe how you can implement load sharing between a multihomed customer and
multiple service providers in a BGP environment
5-74
Configuring BGP for Multihomed Customers

This topic describes the different characteristics of a BGP configuration that is used to establish
routing between a multihomed customer and multiple service providers.
Configuring BGP for Multihomed

Customers
BGP v3.25-3
The highest level of resilience to network failures is achieved in network designs that connect
the customer network to two different service provider networks. Customers use this option
when the requirement for resilient Internet connectivity is very high. This requirement also
involves duplication of equipment to make the customer network fully redundant.
BGP must be used between the customer and both service providers, because static routing will
not work in this type of network. It is not enough to detect link failures or a failure in the
remote router by link-level procedures. Failures that occur beyond the directly connected router
must also be detected, and the only means of detecting these failures is by using a routing
protocol. The only routing protocol that is suited for the Internet environment is BGP. Correctly
configured, BGP takes care of rerouting in the following situations:
Link failure between the customer network and the network of one of the Internet service
providers (ISPs).
Edge router failure on either the customer or the ISP side
Link failure or router failure within the customer network that causes the customer edge
router to lose connectivity with the customer network core. This situation requires correct
configuration of route advertisement as described in an earlier lesson.
Link failure or router failure within the ISP network that causes the ISP edge router to lose
connectivity with the rest of the Internet
5-75
Multihomed customers have multiple permanent links to different ISPs. The links should
terminate in different edge routers in the customer network. Otherwise, one of the major
advantages, resilience to router failure, is lost.
Multihomed customers should use BGP with both ISPs. The customer should advertise its
address space to both providers. Route advertisement should be configured in both customer
edge routers. The advertisement should be conditioned at the edge routers by the appropriate
route policies leading toward the core of the customer network. This setup is analogous to that
configured when you are connecting a multihomed customer network to a single provider.
The customer should take care not to move any routing information between the two ISPs. It
must use outgoing filters to prevent any route that is received from one of the ISPs from being
propagated to the other. Otherwise, the customer network appears as a transit network between
the two ISPs.
Both ISPs must apply filters on the incoming BGP information from the customer to protect
themselves and the rest of the Internet from errors in the BGP configuration of the customer.
Each of the service providers must accept routes from the customer that indicate networks
within the customer address space only. AS-path filter-lists should be implemented on the
provider edge routers to allow incoming routes only if they have the correct AS-path attribute
value. If the incoming filters on the ISP edge router accept customer routes, then the service
provider should propagate those routes to the rest of the Internet.
Both ISPs must provide the customer with at least some BGP routes. Depending on customer
requirements, the volume of BGP routes that are provided by the ISP could range anywhere
from the default route only to the full Internet routing table.
5-76
Configuring BGP for Multihomed

Customers (Cont.)
BGP v3.25-4
Before configuring the multihomed network, you need to consider the following questions:
Should any of the links be used as primary and the others as backup?
Should both links share the load?
What address space is the customer using? Is the customer address space provider-assigned
(PA) or provider-independent (PI)?
What AS number is the customer using? (Is the customer using a public or a private
AS number?)
5-77
Multihomed Customer Address Space Selection

This topic describes the various addressing strategies that are available to a multihomed
customer that is connected to multiple service providers.
Multihomed Customer
Address Space Selection
Provider-independent address space
If the customer owns the address space, there should be
no limitations regarding announcing it to both service
providers.
Provider-assigned address space

If the customer uses ISP-assigned small address blocks,
then there is no purpose in using BGP to provide
redundant connectivity. NAT is easier to implement and
solves the problem of reverse path.
BGP v3.25-5
If the customer has its own address space, it should announce it to both service providers. Both
providers are responsible for propagating the customer routes to the rest of the Internet without
doing any summarization.
However, if the customer uses a small block of addresses that is assigned by one of the ISPs, an
alternative design, not involving BGP, is to use two different PA address spaces and do
Network Address Translation (NAT). With NAT, the router translates traffic going out over
one of its connections to one of the PA addresses. If traffic goes out the other way, the
addresses are translated to an address from the address space of the other provider.
5-78
Multihomed Customer AS Number Selection

This topic describes the various AS numbering strategies that are available to a multihomed
customer that is connected to multiple service providers.
Multihomed Customer
AS Number Selection
Registered, public AS number (recommended):
Preferred option, but difficult to get
Does not require ISPs to assign a private AS number
Consistent routing information in the Internet
Private AS number (discouraged):

Easier to get (even easier with AS translation)
One private AS number: The customer has to be able to use the same
private AS number with multiple providers.
Multiple private AS numbers: The customer gets a private AS number
assigned by each provider and uses one of them internally; the others
have to be translated.
Causes inconsistent routing information
BGP v3.25-6
The use of BGP requires an AS number. The preferred option is to use a registered, public AS
number. However, registered AS numbers are assigned only to those who really need them
because public AS numbers are a scarce resource. A customer with BGP sessions to multiple
ISPs must use a registered, public AS number. A customer that is connected to only one ISP
does not require a public AS number. In that case, a private AS number in the range 64512 to
65535 is sufficient.
Whenever the customer has a public AS number assigned, there are no conflicts in the BGP
setup, because the number is guaranteed to be unique within the Internet. Route announcements
are made by both the customer and service provider without tampering with the AS path. As a
result, consistent AS-path information is propagated by the service provider to the rest of the
Internet.
In cases where the customer does not have a public AS number, it must use a private AS
number. Because private AS numbers are not propagated to the Internet, several network
administrators can, independently of each other, make this assignment. In this case, AS
numbers are reused, which conserves AS number space. A service provider normally assigns
private AS numbers to its customers. This arrangement ensures that unique private AS numbers
are used among the customers of a single ISP.
5-79
When a customer is going to be multihomed and the private AS number that has already been
assigned by one of the ISPs comes in conflict with an AS number that has been assigned by the
other ISP, the customer needs to consider renumbering the customer AS. If the two service
providers can reach a common agreement on which private AS number that the multihomed
customer should use, renumbering is a solution. If no common agreement can be made or if
renumbering, for some reason, is not an option, AS translation must be configured on the
customer network.
No router should ever propagate private AS numbers to the rest of the Internet. An ISP can
keep track of which private AS numbers that it has assigned to its customers and avoid reuse or
conflicts within that scope. However, as soon as the scope is widened to include other ISPs,
conflicts will happen. Each ISP, therefore, removes private AS numbers from the AS path
before sending routes outside its own AS.
When the routes with the private AS numbers removed are propagated to the rest of the
Internet, the AS path looks as though the routes were originated within the public AS of the
ISP. All information about the private AS lying behind the public AS is lost. In the case of a
multihomed customer, the customer routes are, in the first step, propagated into each of the
autonomous systems of its ISPs. In the next step, the routes have the private AS number
removed as the routes are propagated to the rest of the Internet. Now the customer routes
appear to be originating in the autonomous systems of both ISPs. To an outside observer, there
is now an AS-path inconsistency because it looks as though the same route belongs to different
autonomous systems.
5-80
This topic describes the operation of AS number translation.
On one EBGP adjacency, the real AS number is used.

On the other EBGP adjacency, the AS number is translated to the one
assigned by the second ISP.
BGP v3.25-7
The figure shows a case where a customer is multihomed but forced to use two private AS
numbers (for example, because of the scarcity of public AS numbers).
In the figure, service provider A has assigned the private AS number 65053 to the customer.
Service provider B did not agree to use this private AS number when connecting to the
customer. Instead, service provider B has assigned the private AS number 65286.
The customer now has two different private AS numbers: 65053 and 65286. The customer
decides to use 65053 internally. All router BGP configuration lines have 65053 as the AS
number. The customer uses AS number 65286 only when establishing the External Border
Gateway Protocol (EBGP) session to AS 234.
In the example, service provider A (AS 123) has an EBGP session to the customer where the
AS number 65053 is used at the customer end. Service provider B (AS 234) has an EBGP
session to the customer where the AS number 65286 is used at the customer end. Translation
between these two private AS numbers takes place in the customer edge router as part of the
EBGP session to AS 234.
5-81
AS Number Translation (Cont.)

Optionally, the customer can get two different private AS
numbers assigned by the service providers.
Internally, the customer can use an ISP-assigned AS number or
even any other private AS number.
Externally, the customer is seen as one private AS number to
ISP 1 and as a different AS to ISP 2.
Note: When you are using this option, the AS path of the
customer network contains two AS numbers. The ISP has to
adapt the incoming AS-path filters.
BGP v3.25-8
The neighbor ip-address local-as private-as router configuration command is used to indicate
the AS number that the local router uses as its local AS number in the BGP Open message. The
remote router is assumed to have an EBGP session to the indicated local AS.
Internally, the customer network uses another private AS number. When routes are sent to the
neighbor, the internal AS number is automatically prepended in the AS path first, and then the
specified local AS number is prepended as well. As a consequence, the ISP receives the routes
with an AS path with both AS numbers in it. The ISP has to adapt its incoming filter-lists as a
result of this situation.
Note
5-82
Some service providers might be unwilling to change their AS-path input filters, leaving the
customer no other option than to use a public AS number or to connect to a single ISP with
a private AS number.

This topic describes how you can implement a typical backup setup between a multihomed
customer and multiple service providers in a BGP environment.

Outgoing link selection:
You can use the same solution as with multihomed
customers connected to one service provider.
Incoming link selection:

You cannot use the MED because it can be sent only to the
neighboring AS and no farther.
You must use other means such as BGP communities or ASpath prepending to achieve incoming link selection.
BGP v3.25-9
When using BGP on multiple links between a customer and several service provider networks,
the customer is solely responsible for controlling the use of the links between them for outgoing
traffic. The customer chooses whether to use these links in a primary/backup or a load-sharing
configuration.
If one link is primary and the other is used for backup purposes only, the customer can use the
local preference attribute in the configuration to direct all outgoing traffic over the primary link.
This configuration is no different than the configuration that is used for customers with
multiple connections running BGP to a single service provider.
Controlling the load distribution of incoming traffic over multiple links is more difficult in the
multihomed scenario when links to multiple service providers are used. You cannot use the
multi-exit discriminator (MED) when the customer connects to multiple providers because the
updates are sent to two different autonomous systems. Recall that the MED is used only when
you compare routes that are received from a single directly connected AS over two parallel
links. Therefore, route selection decisions will most likely use the AS-path attribute and prefer
the route with the shortest AS-path length.
5-83

This topic describes the use of BGP attributes to influence inbound link selection in customer
networks that are multihomed to multiple service providers.

BGP communities:
Customer sets the appropriate BGP community attribute
on updates sent to the backup ISP
Requires the ISP to translate the BGP community attribute
to a local preference attribute that is lower than the default
value of 100
May not work in all situations
AS-path prepending:
Multiple copies of customer AS number prepended to the
AS path to lengthen the AS path sent over the backup link
Customer not dependent on the provider configuration
Always works
BGP v3.25-10
To remove incoming traffic from the backup link, the customer must influence route selection
in the backup AS. The backup ISP must be forced to prefer the primary path to reach the
customer network, although this choice means selecting a route with a longer AS path.
One way to influence route selection is to use local preference in the network of the backup
ISP. Using local preference creates an administrative scalability issue if each customer requires
its use, because the ISP must maintain the configuration.
One scalable way of setting local preference in an ISP network is to use communities. The
customer sets a well-known community value on the routes that are sent to the backup ISP. The
ISP recognizes the community and sets the local preference for these routes. This solution is
available only if the ISP has implemented and announced the use of communities. If
communities and a local preference setting are used, route selection occurs only if there are
alternative routes to compare.
Another way of influencing route selection in the backup ISP is to do AS-path prepending
before sending the advertisement to the backup ISP. When the customer sends routes over the
backup link, multiple copies of its own AS number are prepended to the AS path of each route.
The backup ISP receives the routes and makes normal route-selection decisions. No special
weight or local preference settings are used; the BGP route selection is based exclusively on the
AS-path length. No special configuration is required in the service provider network.
5-84
BGP Incoming Link Selection Using

BGP Communities
BGP v3.25-11
In the example here, the backup service provider B (AS 234) has defined the meaning of
community 234:50. When AS 234 receives routes with this community, the local preference is
set to 50.
The customer AS 387 is advertising the route over the primary link without any communities. It
is received by AS 123 and propagated to AS 234. When AS 234 receives the route via AS 123,
there is no community set. AS 234 therefore assigns the default local preference value of 100.
The customer is also advertising the route over the backup link. However, in this case, the route
has the community 234:50 set. When AS 234 receives this route, it recognizes the community,
and the local preference value is set to 50.
Route selection is now performed in AS 234. The route that has been received via AS 123 is
preferred based on the local preference values.
5-85

BGP v3.25-12
Even when the use of communities is correctly configured, the desired load distribution may
not always be achieved. As this example shows, AS 234 does not always receive the primary
route, although nothing is wrong in the network.
The customer AS 387 sends routes with community 234:50 over the backup link to AS 234. AS
234 receives the routes and sets the local preference to 50. If AS 234 over some period of time
selects the directly connected path to AS 387 as the best, it propagates the route to AS 321. As
the route is propagated over the EBGP session between AS 234 and AS 321, the local
preference value that is used within AS 234 is lost.
AS 321 does not have any use for the community 234:50 because this community is defined
and implemented only within AS 234. Potentially, the community value can also be stripped off
during BGP route propagation.
Customer AS 387 also sends the routes over the primary link to AS 123. The routes are
propagated to AS 321, which now sees two alternative routes to the destination networks within
AS 387. Neither weight nor local preference is used by the routers in AS 321 as criteria for
reaching AS 387. Both alternatives have equal AS-path lengths.
The route selection decision that will be made in AS 321 is hard to predict, but the outcome
definitely influences the route selection decision that was made in AS 234. If AS 321 prefers
the route to the customer network via AS 234 for any reason, then the second-best alternative
via AS 123 and the primary link is never propagated to AS 234.
In this case, AS 234 never sees the primary path and has to stick to the backup link and
announce the route to AS 321. The network has reached a steady state when the traffic uses the
backup link although the primary link is available.
5-86

AS-Path Prepending
BGP v3.25-13
In this example, the customer AS 387 is performing AS-path prepending on the backup link.
Three copies of the customer AS number (387) are prepended to the AS path. As the route goes
out over the EBGP session, BGP prepends the local AS number to the AS-path attribute.
AS 234 receives routes from AS 387 over the backup link with an AS-path length of four (the
original AS 387 plus three prepended copies that the customer edge router applied to the
AS-path attribute).
The customer advertises networks without AS-path prepending over the primary link. AS 123
receives routes with an AS-path length of one and propagates these routes to AS 321, which
then receives them with an AS-path length of two.
If, for a short period of time, AS 321 received the customer routes via AS 234, the AS-path
length of those routes would have been five. In that case, AS 321 selects the route from AS 123
as the best and propagates it to AS 234.
AS 234 now sees both alternatives. The customer routes that have been received directly from
the customer have an AS-path length of four. The routes that have been received via AS 321
have an AS-path length of three. Because no weight or local preference is configured in this
example, AS 234 selects the route via AS 321 as the best.
The desired result, to have all traffic enter the customer network via the primary link, is now
achieved.
Note
If the backup ISP is implementing incoming AS-path filters for this customer with the length
of the AS path equal to one, the ISP has to change the configuration of the AS-path filter for
the customer. The ISP can either create a new filter, allowing multiple copies of the
customer AS number only for this customer, or use regular expression variables to create a
common filter for all customers that belong to one peer group.
5-87

This topic describes how you can implement load sharing between a multihomed customer and
multiple service providers in a BGP environment.

Load sharing for outgoing traffic:
You can use the same solution as with multihomed customers
connected to one service provider.
Load sharing for incoming traffic:

The only load-sharing option that you can use in this setup is
to separate address space into two or more smaller address
blocks.
Some traffic analysis is needed to fine-tune address space
separation according to link bandwidths.
You should use AS-path prepending to ensure symmetric
routing as well as backup for noncontiguous address blocks.
BGP v3.25-14
Load sharing over links to two different ISPs can be compared to doing load sharing over two
parallel links to a single ISP. The only difference is that there is only one option that is
available to control incoming traffic. Controlling load distribution of the outgoing traffic is
configured in exactly the same way as when a multihomed customer connects to a single
service provider.
The customer can control the load distribution of incoming traffic based on traffic destination.
The customer divides its address space into several announcements. One announcement is sent
to one of the ISPs. Another announcement is sent to the other ISP. For backup purposes, the
customer announces the entire address space to both ISPs. The ISPs now use the most-explicit
route rule, and as long as both links are up, traffic with destinations within one part of the
customer address space is routed over one of the links and traffic to the other part is routed over
the other link.
It is very difficult to predict the volume of traffic that will be directed to one part of the
customer address space and the volume that will be directed to the other part. You should
monitor the results of changing route updates by watching the load on the links before and after
implementing the change. If the load distribution is not satisfactory, you can further modify the
division of the address space. You must then check the load on the links again and further finetune the configuration.
A customer may decide to use both the division of address space into several advertisements
and AS-path prepending together. Some part of the customer address space may be advertised
by the customer network with a longer AS path over one of the links to fine-tune the load. Also,
there may be cases where there are noncontiguous subnets that cannot be divided because the
prefixes would be too long. These subnets are evenly distributed between the links in a
primary/backup configuration.
5-88
Summary
Summary
Customers that require the maximum redundancy in their
network design should implement a configuration that is
multihomed to multiple service providers.
A customer that is multihomed to multiple BGP service
providers must advertise its address space to both ISPs and
take care not to transmit any routing information between
the two ISPs.
The internal addresses of the customer must be advertised
to both ISPs. Depending on the addressing scheme that is
used by the customer, NAT may be required.
Customers that are connected to only one ISP do not require
a public AS number, while customers connected to multiple
ISPs must use an AS number that all ISPs agree to.
BGP v3.25-15
Summary (Cont.)
You can use AS number translation to prepend a different AS
number to the AS path, which allows the customer to use a
single private AS number in the network.
Outgoing route selection in primary/backup connectivity is
achieved using local preference. Incoming route selection
should be implemented using either BGP communities to tag
customer routes or AS-path prepending.
Load-sharing configurations for outgoing traffic are the same
as those used in the scenario in which the customer is
multihomed to a single provider. You can perform load
sharing of incoming traffic when you are multihomed to
multiple providers only if separate address spaces are
advertised to each provider. You can also use AS-path
prepending of this configuration for fine-tuning.
BGP v3.25-16
5-89
Module Summary
Module Summary
There are a number of connectivity aspects that must be considered in
planning network connectivity to an ISP, including physical connection
types, the redundancy provided by the connection method that is
chosen, IP addressing requirements, and AS numbering
considerations.
Implementing customer-to-provider connectivity with static routes
requires a knowledge of the characteristics and design considerations
related to static routes and of how to configure static routing in
nonredundant, backup, and load-sharing configurations.
In configuring a customer network and a provider network to
accommodate multiple connections between them, considerations such
as private AS number removal and configuration of a network to
support either backup links or load sharing (balancing) are involved.
Customers that require the maximum redundancy in their network
design should implement a configuration that is multihomed to multiple
service providers, addressing considerations such as address
selection, private AS number translation, and configuration of the
network to support either backup links or load sharing.
BGP v3.25-1
This module explained the different requirements for connectivity between customers and
service providers. The first lesson provided a connectivity overview that included physical
connection methods, redundancy, load balancing, and technical requirements. The second
lesson described how to implement customer connectivity by using static routing in a service
provider network. The third lesson addressed the implementation of customer connectivity
using BGP in a customer scenario in which multiple connections to a single ISP were
supported. The final lesson focused on the implementation of customer connectivity using BGP
in a customer scenario in which connections to multiple ISPs were supported.
5-90
References
Cisco Systems, Inc. The Easy Guide to Selecting an Internet Service Provider.
http://www.cisco.com/warp/public/cc/so/cuso/smso/crn/ezgd_pl.htm.
Cisco Systems, Inc. How NAT Works.
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.
shtml.
Cisco Systems, Inc. Sample Configurations for Load Sharing with BGP in Single and
Multihomed Environments: Sample Configurations.
Cisco Systems, Inc. Sample Configuration for BGP with Two Different Service Providers
(Multihoming). http://www.cisco.com/warp/public/459/27.html.
Doyle, Jeff. Routing TCP/IP, Volume 1. Cisco Press, 1998, ISBN 1-57870-041-8.
Cisco Systems, Inc. Removing Private Autonomous System Numbers in BGP.
Cisco Systems, Inc. How BGP Routers Use the Multi-Exit Discriminator for Best Path
Selection. http://www.cisco.com/warp/public/459/37.html.
Cisco Systems, Inc. Configuring the BGP Local-AS Feature.
5-91
Module Self-Check
Q1)
If a customer requires additional bandwidth and redundancy, which approach is

preferred? (Source: Understanding Customer-to-Provider Connectivity Requirements)
A)
B)
C)
D)
Q2)
Which type of redundancy do multiple permanent connections that provide loadsharing configuration display? (Source: Understanding Customer-to-Provider
Connectivity Requirements)
A)
B)
C)
D)
Q3)
B)
C)
D)
When one of the connections is lost, the link level detects this loss and places
the interface in a down state.
Monitoring of the link status cannot detect a problem inside one of the ISP
networks.
Static routes detect problems inside one of the ISP networks.
It is not required, and static routing may be used.
What can be done when a customer is assigned only a very small subnet of public
addresses? (Source: Understanding Customer-to-Provider Connectivity Requirements)
A)
B)
C)
D)
5-92
policy-based routing
dynamic routing
content routing
static routing
Why is it that with multiple permanent connections to more than one ISP, the use of
dynamic routing with BGP is required? (Source: Understanding Customer-to-Provider
A)
Q5)
link
equipment
service provider
routing protocol
In a customer-to-provider routing scheme, which method of routing is preferred

because of its lower complexity? (Source: Understanding Customer-to-Provider
A)
B)
C)
D)
Q4)
a single permanent connection to one ISP

permanent connections to more than one ISP
dial-up connections to more than one ISP
multiple permanent connections to one ISP
purchase more addresses as required

use NAT
add a service provider
add links to the same service provider
Q6)
What are two different addressing schemes that customers use to connect to a service
provider? (Choose two.) (Source: Understanding Customer-to-Provider Connectivity
Requirements)
A)
B)
C)
D)
Q7)
Which two of the following criteria are required for a customer to be multihomed to
multiple ISPs? (Choose two.) (Source: Understanding Customer-to-Provider
A)
B)
C)
D)
Q8)
a route tag
the export community
the no-export community
the public address filter
When you are designing static route propagation in a service provider network, which
three steps must you take? (Choose three.) (Source: Implementing Customer
Connectivity Using Static Routing)
A)
B)
C)
D)
Q11)
The router must be able to detect a link failure.

The default route must be announced using the customer IGP.
If one link goes down, the interface must remain in an up state.
The customer IGP must continue to advertise the static default route.
A customer route that should not be announced to the rest of the Internet is marked
using what? (Source: Implementing Customer Connectivity Using Static Routing)
A)
B)
C)
D)
Q10)
The customer must have a public AS number.

The customer must have a private AS number.
The customer must run BGP with both of its ISPs.
The customer must run BGP with one ISP and may use static routing with the
other.
What are two requirements for being able to use static routing as part of installing
redundant connections between the customer network and a single service provider
network? (Choose two.) (Source: Implementing Customer Connectivity Using Static
Routing)
A)
B)
C)
D)
Q9)
provider-independent
customer-independent
provider-assigned
customer-assigned
assign a tag to each combination of services

configure a community that matches defined tags
redistribute static routes into BGP through a route-map
identify all possible combinations of services that are offered to a customer
What does a route-map assign that will be used by other routers within a network?
(Source: Implementing Customer Connectivity Using Static Routing)
A)
B)
C)
D)
a tag
community values
public addressing
QoS
5-93
Q12)
Which three key pieces of information can you derive from the following router
command output? (Choose three.) (Source: Implementing Customer Connectivity
Using Static Routing)

A)
B)
C)
D)
Q13)
Which two things can you do to overcome the problems that occur when a floating
static route is redistributed into BGP? (Choose two.) (Source: Implementing Customer
Connectivity Using Static Routing)
A)
B)
C)
D)
Q14)
Outgoing traffic load sharing is easy to achieve.

Each customer router uses the closest customer edge router as the exit point.
Balanced load sharing is achieved if the customer edge routers are collocated.
Local preference values must be assigned, giving the floating static route a
lower local preference value than the primary route.
What are three responsibilities of the customer when the customer is multihomed to a
single service provider? (Choose three.) (Source: Connecting a Multihomed Customer
to a Single Service Provider)
A)
B)
C)
D)
5-94
You must raise the weight value.

You must lower the weight value.
You must set the AD at a higher value than all other routes.
You must assign local preference values, giving the floating static route a
lower local preference value than the primary route.
What are three characteristics of using static routes during load sharing of outgoing
traffic? (Choose three.) (Source: Implementing Customer Connectivity Using Static
Routing)
A)
B)
C)
D)
Q15)
The primary link has come back up, so the backup router now sees two
alternate routes.
The primary link has not come back up, but the backup router still sees two
alternate routes.
The first route is the route that the router itself has redistributed into BGP using
the floating static route. This route is locally sourced by the AS and has been
assigned a weight value of 32768.
The second route is the one that has been received by IBGP from the primary
edge router. The AS also sources this route, but no weight value is assigned.
Customer edge routers must run IBGP between them.

The customer must advertise a default route.
The customer must conditionally advertise its assigned address space into
BGP.
The customer edge routers must run EBGP with the provider.
Q16)
Given the following router command output, which method has been used to influence
return traffic in a primary/backup link implementation for this multihomed customer?
(Source: Connecting a Multihomed Customer to a Single Service Provider)

A)
B)
C)
D)
Q17)
C)
D)
MED
local preference
weight
AS-path prepending
The provider must advertise a default route to the customer through BGP.
The provider must filter customer routes to verify that proper addressing is
used.
The provider must remove the private AS number, if it is in use by the
customer.
The provider must configure new AS-path filters to allow AS-path prepending;
otherwise, a primary/backup link cannot be established.
What will occur if private AS numbers are advertised to the Internet? (Source:
Connecting a Multihomed Customer to a Single Service Provider)
A)
B)
C)
D)
Q19)
What are three responsibilities of the provider router when supporting a multihomed
customer? (Choose three.) (Source: Connecting a Multihomed Customer to a Single
Service Provider)
A)
B)
Q18)
The Internet will not be able to route packets.

Internet routers could drop routes based on BGP loop-prevention mechanisms.
Customer load balancing will not function.
Customer configurations for the primary/backup link using AS-path
prepending will not function.
Which two BGP configurations are required to properly implement a backup solution
for a multihomed customer that is connected to a single provider? (Choose two.)
(Source: Connecting a Multihomed Customer to a Single Service Provider)
A)
B)
C)
D)
The customer should set local preference to influence outgoing route selection.
The customer should set the weight attribute to influence outgoing path
selection.
The customer should set the MED on each route to influence return path
selection.
The customer should configure AS-path prepending to ensure proper outgoing
path selection.
5-95
Q20)
A customer router has been configured with maximum paths set to a value of 4. Given
the following router command output, over how many links will the router need to
perform load balancing? (Source: Connecting a Multihomed Customer to a Single
Service Provider)

A)
B)
C)
D)
Q21)
D)
The router will use only the path marked as best by BGP.
The router will perform load balancing over two paths to reach network
10.10.20.0/24.
The router will perform load balancing over three paths to reach network
10.10.20.0/24.
There is not enough information to determine the correct answer.
advertising of split addressing space to the provider

configuring ebgp-multihop between the customer and the provider
using the BGP maximum-paths command to perform load balancing over
parallel links
configuring multiple static routes that point to the provider
Why is it not required to configure maximum paths under the BGP routing process
when load balancing is being performed because the ebgp-multihop command has
been configured? (Source: Connecting a Multihomed Customer to a Single Service
Provider)
A)
B)
C)
D)
5-96
Which three methods can you use to provide load sharing over network links between a
multihomed customer and a single provider? (Choose three.) (Source: Connecting a
Multihomed Customer to a Single Service Provider)
A)
B)
C)
Q22)
By default, BGP will perform load balancing over up to four paths,

configurable up to six.
The static route or IGP process is responsible for load balancing in this
configuration.
Configuring multihop enables maximum paths equal to the TTL setting of the
neighbor ebgp-multihop command.
Configuring ebgp-multipath is a required component of ebgp-multihop load
balancing.
Q23)
Which two of the following characteristics accurately describe the BGP Support for
Dual AS Configuration for Network AS Migrations feature? (Choose two.) (Source:
Connecting a Multihomed Customer to a Single Service Provider)
A)
B)
C)
D)
Q24)
A multihomed customer is using AS number 65550 internally. The customer is

connected to two different providers. Provider 1 (in AS 222) has assigned the customer
an AS number of AS 65101. Provider 2 (in AS 333) has assigned the customer an AS
number of AS 65201. Given that the customer will use AS number translation for its
internal AS, what is the AS-path attribute (attached to routes that originated in the
customer network) that will be displayed on a router in the network of Provider 2?
(Source: Connecting a Multihomed Customer to Multiple Service Providers)
A)
B)
C)
D)
Q25)
65550 i
65201 i
65201 65550 i
333 65201 i
Which three methods can you use to provide load sharing over network links between a
multihomed customer and multiple providers? (Choose three.) (Source: Connecting a
Multihomed Customer to Multiple Service Providers)
A)
B)
C)
D)
Q26)
allows you to merge a secondary AS under a primary AS without disrupting

customer peering sessions
allows a router to appear, to external peers, as a member of primary AS during
the AS migration
allows a router to appear, to external peers, as a member of secondary AS
during the AS migration
eliminates the possibility that routing loops can be created
advertising of split addressing space to the provider

configuring of multiple static routes that point to the provider
using the BGP maximum-paths command to perform load sharing over
parallel links
AS-path prepending to fine-tune the load-sharing configuration
What are three BGP configuration characteristics of a multihomed customer that is

connected to multiple providers? (Choose three.) (Source: Connecting a Multihomed
Customer to Multiple Service Providers)
A)
B)
C)
D)
The customer announces assigned addressing to its providers through BGP

The customer announces a default route to its network through BGP.
The provider announces a default route, local routes, or full Internet routing to
the customer via BGP.
The customer configures outbound filters to prevent its network from
becoming a transit area.
5-97
Q27)
A multihomed customer is using AS number 1024 and is connected to two different

providers (Provider 1: AS 222 and Provider 2: AS 333). The customer has configured
the MED to ensure a proper return path so that Provider 1 is the primary provider and
Provider 2 is the backup provider. Unfortunately, return traffic continues to use the
backup link. What is a possible cause of this problem? (Source: Connecting a
Multihomed Customer to Multiple Service Providers)
A)
B)
C)
D)
Q28)
What are three important considerations for customers that wish to connect to multiple
providers? (Choose three.) (Source: Connecting a Multihomed Customer to Multiple
Service Providers)
A)
B)
C)
D)
Q29)
The customer has to consider whether to use PA or PI address space.

The customer has to decide whether to use static routes or BGP to connect to
upstream providers.
The customer has to decide whether to use a public AS number or a private AS
number scheme.
The customer has to decide whether to perform load sharing or use a
primary/backup implementation over redundant links.
Which AS number selection is the best possible choice for a customer that is
multihomed to multiple providers? (Source: Connecting a Multihomed Customer to
Multiple Service Providers)
A)
B)
C)
D)
5-98
The backup provider is ignoring the MED attribute on received routes.

The MED attribute cannot be sent to the backup provider because it is local to
AS 1024 only.
The customer has not set the proper BGP communities to allow the primary
and backup providers to correctly set the MED attribute.
The MED cannot be used in this scenario, because it will not be advertised to
providers upstream of Provider 2.
a single public AS number

a single private AS number
two private AS numbers that are used in conjunction with AS number
translation
multiple private AS numbers, one used internally by the customer and the
others used in conjunction with AS number translation for each provider
Q30)
Given the following router command output, which two methods have been configured
to influence return traffic in a primary/backup link for this multihomed customer?
(Choose two.) (Source: Connecting a Multihomed Customer to Multiple Service
Providers)

A)
B)
C)
D)
MED
local preference
split address advertisement
AS-path prepending
5-99
5-100
Q1)
Q2)
Q3)
Q4)
Q5)
Q6)
A, C
Q7)
A, C
Q8)
A, B
Q9)
Q10)
A, C, D
Q11)
Q12)
A, C, D
Q13)
B, D
Q14)
A, B, C
Q15)
A, C, D
Q16)
Q17)
A, B, C
Q18)
Q19)
A, C
Q20)
Q21)
A, B, C
Q22)
Q23)
A, C
Q24)
Q25)
A, C, D
Q26)
A, C, D
Q27)
Q28)
A, C, D
Q29)
Q30)
C, D
Module 6
Scaling Service Provider

Networks
Overview
In standard Border Gateway Protocol (BGP) implementations, all BGP routers within an
autonomous system (AS) must be fully meshed so that all external routing information can be
distributed among the other routers that reside within the AS. Therefore, within an AS, all
routers must establish TCP sessions with all other BGP routers. As the AS grows, scalability
challenges arise because of an ever-increasing number of TCP sessions and demands for router
CPU and memory resources.
This module discusses network scalability concerns that are common to large, complex service
provider networks. The module also discusses BGP route reflectors and confederations as
scalability mechanisms that allow network designers to steer away from BGP full-mesh
requirements and improve network scalability by reducing the number of TCP sessions that are
required within an AS. Also discussed in this module are the Cisco IOS commands that are
needed to configure and monitor BGP route reflectors and confederations.
Module Objectives
Upon completing this module, you will be able to enable route reflection and confederations as
possible solutions to BGP scaling issues in a typical service provider network with multiple
BGP connections to other autonomous systems. This ability includes being able to meet these
objectives:
Describe common routing scalability issues in service provider networks
Describe the function of route reflectors in a BGP environment
Describe the function of hierarchical route reflectors, based upon established route reflector
design rules
Configure proper operation of route reflectors to modify IBGP split-horizon rules in an
existing IBGP network
Describe the function of confederations in a BGP environment
Configure proper operation of confederations to modify IBGP AS-path processing in an
existing IBGP network
6-2
Lesson 1
Scaling IGP and BGP in

Service Provider Networks
Overview
Properly scaling IP addressing, Interior Gateway Protocols (IGPs), and Border Gateway
Protocol (BGP) is a common area of concern to all service providers and can be the difference
between a successful and a problematic BGP implementation. Because service provider
networks are complex and must meet the administrative policy and routing demands of the
internal network, different customers, and other providers, proper scaling is crucial to the
success of the network. Interactions between IGPs and the BGP, specifically when network
administrators are supporting internal routing, customer connectivity, and transit traffic (and the
administrative policies that match), can be quite complex. Furthermore, the large number of
prefixes that are required to support full Internet routing requires administrators to fully
characterize IGP and BGP interactions for internal networks and customers alike.
This lesson discusses network scalability concerns common to large, complex service provider
networks. Included in this lesson is a description of a typical Internet service provider (ISP)
network and discussion of the propagation of internal and customer routing information, scaling
considerations for IGPs and BGP, and scaling of IP addressing in service provider networks.
Objectives
Upon completing this lesson, you will be able to describe common routing scalability issues in
service provider networks. This ability includes being able to meet these objectives:
Describe the basic structure of service provider networks
Describe the propagation of internal and customer routes in service provider networks
Describe proper scaling of IGPs and BGP in service provider networks
Describe scaling issues that are relevant to IP addressing in ISP networks
Describe the function of BGP policy accounting in relation to BGP scaling

This topic describes the basic structure of service provider networks.

Runs BGP or static routing with customer
Exchanges routes with other service providers via BGP
Runs IBGP between its own BGP speakers
Runs one instance of IGP (OSPF or IS-IS)
IGP used for internal routes only
BGP v3.26-3
The common service provider network runs External Border Gateway Protocol (EBGP) or
static routing with customers. EBGP is always used as the routing protocol between different
service providers.
Internal Border Gateway Protocol (IBGP) is required in the provider network because all
EBGP-speaking routers in an autonomous system (AS) must exchange external routes via
IBGP. Also, non-EBGP speakers are required to take part in the IBGP exchange if they are in a
transit path and forward packets based on destination IP addresses.
The service provider network also runs an IGP. The protocols of choice are Open Shortest Path
First (OSPF) and Intermediate System-to-Intermediate System (IS-IS). The IGP is used for two
purposes:
Provides IP connectivity between all IBGP speakers so that TCP sessions for IBGP can be
established between BGP-speaking routers
Provides optimal routing to the BGP next-hop address
A single IGP should be used within the entire AS. This setup facilitates effective packet
forwarding from the ingress router to egress routers. The IGP is configured to carry internal
routes only, including internal links and loopback addresses of the routers. For performance and
scalability reasons, no customer routes or external routes should be injected into the IGP.
6-4
Common Service Provider Network (Cont.)
BGP v3.26-4
The typical service provider network consists of a network core that connects various edge
devices. Some of the edge devices connect customers; others connect to other service providers.
The edge devices that connect to other service providers use EBGP to exchange routing
information. The edge devices that connect customers use either static routing or EBGP.
Unless Multiprotocol Label Switching (MPLS) is configured on the service provider backbone,
routers in a transit path are also required to have full routing information. Therefore, these
routers take part in the IBGP routing exchange.
An IGP is also required within the service provider network. The IGP is used to carry internal
routes, including the loopback interface addresses of IBGP-speaking routers. The IGP provides
reachability information to establish IBGP sessions and to perform the recursive routing lookup
for the BGP next hop.
6-5
Networks are divided into POPs.

Different types of media are concentrated at the POP.
Optimal routing between POPs is desired.
BGP v3.26-5
Service provider devices that connect access links to customers are physically located in groups
that are called points of presence (POPs). In general, the POP is a group of routers where access
links are terminated. The edge routers that peer with other service providers can in this sense be
considered a POP.
Service providers use different types of access links with different types of customers and
usually mix access links in the same POP. Some customers use leased lines, others use xDSL,
and still others use dial-in access or any other access that the provider can support.
POP routers connect to the network core using a layer of concentration routers at the POP. The
network core forwards packets between POPs, various customer access points, or peering
points with other service providers. Optimal routing between POPs is a desirable feature.
6-6
POP routers use BGP or static routing with customer routers.

The provider core IGP is a single instance of IS-IS or OSPF.
The core IGP is used only within the service provider backbone.
BGP v3.26-6
Customer access lines terminate in the POP edge routers. In many cases, the POP edge routers
use static routing to customer networks. The POP edge routers advertise static routes to the rest
of the service provider network and to other autonomous systems using BGP.
Service providers use BGP routing with the customer when redundancy requires the use of a
routing protocol.
The service provider backbone typically uses a single instance of either IS-IS or OSPF as its
IGP. The IGP is used within the provider backbone only. The provider backbone exchanges no
IGP routing information with customer routers or with routers in other autonomous systems.
6-7
Route Propagation in Service Provider Networks

This topic describes the propagation of internal and customer routes in service provider
networks.
Route Propagation in
Service Provider Networks
BGP route propagation
BGP carries customer routes.
BGP carries other provider routes.
IGP route propagation

IGP is responsible only for the next hop.
Do not redistribute BGP into IGP.

IGP performance and convergence time suffer if a large
number of routes are carried.
No IGP is capable of carrying full Internet routes.
A full Internet routing table has exceeded 110,000 routes.
BGP v3.26-7
It is important to avoid sending any unnecessary routing information in the IGP. The IGP
performs best if it carries as few routes as possible. Optimally, the IGP should contain only
information about BGP next hops and routes that are internal to the service provider network,
enabling the establishment of IBGP sessions.
All other routing information should be carried in BGP, which is designed to scale for large
volumes of routing information. Customer routes and the routes from other service providers
should be carried in BGP. These routes should not be propagated from BGP into the provider
IGP.
IGP performance and convergence time suffer if the IGP carries a larger number of routes. The
design goal should be to minimize the volume of routing information that is carried by the IGP.
Naturally, the number of route flaps is also reduced as the number of routes is reduced.
BGP scales to a much larger volume of routing information because of the inherent qualities of
the design of BGP. Potentially, the BGP routers of the service provider can receive the full
Internet routing table, which has exceeded 110,000 routes. You should therefore never
redistribute the routing information that has been received by BGP into the IGP, because no
IGP is capable of carrying several tens of thousands of routes.
6-8
Routing Information Exchange

with Other Service Providers
BGP is used to exchange routing information between Internet

service providers.
BGP v3.26-8
Provider edge routers use BGP to exchange routing information with other service provider
networks for redundancy and scalability reasons.
Static routing with other service providers is generally not a viable solution due to the dynamic
routing requirements of the service provider environment. Routing information is received at
provider edge routers using EBGP and then propagated using IBGP to the rest of the service
provider network. At another edge router, the routing information is further propagated to a
different service provider using EBGP with other autonomous systems.
6-9
Routing Information Exchange

with Customers
The provider edge router redistributes static customer routes

into BGP.
BGP carries customer routes.
BGP v3.26-9
The provider edge router typically uses static routing to reach customer networks. In this case,
the customer typically configures a static default route that points to the edge router of the
service provider.
The provider edge router redistributes customer static routes into BGP. The service provider
network then uses BGP to propagate the information to the rest of the service provider network
using IBGP. The service provider also advertises customer routing information to other
autonomous systems using BGP.
6-10
Next-Hop Resolution
The core IGP of the service provider should carry information only
about backbone links and loopback addresses.
BGP v3.26-10
The IGP used in the service provider core should carry information only about backbone links
and loopback addresses. The service provider should use BGP to carry all other information.
Use the BGP next-hop-self command when BGP routing is exchanged with the customer or
other service providers. Using the next-hop-self command results in the BGP next hop being
set to the loopback address of the service provider edge router and not to the access link address
of the customer. The IGP can then be relieved of the burden of carrying information about the
access link. The benefit of not carrying customer link information is that a flapping access link
will not disturb the service provider IGP.
6-11
Scaling Service Provider Routing Protocols

This topic describes proper scaling of IGPs and BGP in service provider networks.

Routing Protocols
IGP responsibilities
Carrying route to BGP next hop
Providing optimal path to next hop
Converging to alternate path so that BGP peering is
maintained
BGP responsibilities
Generating BGP update

Scaling BGP policies
Scaling IBGP mesh
Reducing impact of flapping routes
BGP v3.26-11
The IGP is responsible for the following:

Carrying routes to the BGP next hops to facilitate recursive routing
Providing an optimal path to the next hop, thereby optimizing packet flow toward all BGP
destinations
Converging to an alternate path in the case of lost links or routers in a redundant network
(which should be quick so that BGP sessions are not lost)
The BGP is responsible for the following:
Generating BGP updates about reachable and unreachable networks
Implementing and scaling the BGP routing policy, which can be quite cumbersome in large
service provider networks with many EBGP-speaking routers
Implementing and scaling IBGP sessions between all BGP-speaking routers in the AS
Reducing the impact of individual flapping routes through route summarization
6-12
Scaling IGP
Loopbacks and internal links carried only
Good addressing structure within the POP required
Loopback addresses taken out of a different address space
and not summarized
Summarization of internal link addresses on POP level
Optimal routes to loopbacks needed only (with proper
summarization)
BGP v3.26-12
In scaling an IGP, it is important to limit the number of routes that are carried by the IGP.
Optimally, the IGP carries only loopback interfaces and internal links.
The number of routes that are carried by the IGP can be even further reduced with route
summarization. However, care must be taken because loopback addresses should never be
summarized. Route summarization always introduces the risk of suboptimal routing and should
be carefully planned, because it is important that recursive routing lookup always use optimal
routing to the next hop. Also, in an MPLS environment, a label switched path (LSP) must be
unbroken between edge routers, and summarizing loopback interfaces will break the LSP.
Internal links can always be summarized because they are not used as BGP next-hop addresses.
To facilitate proper route summarization, internal links and loopback interfaces on a router
should be assigned addresses from two different address spaces. Also, the internal links of a
router should be assigned addresses depending upon which POP the routers belong to.
If implemented correctly, all internal router links in one POP can be summarized at the POP
level and injected into the core as a single route. But, all router loopback addresses within the
POP are still propagated into the core as individual host routes, giving optimal routing to all
loopback interfaces.
6-13
Scaling BGP
BGP policy scaling
The AS routing policy should be unitary and easy to maintain.
This goal is achieved by reusing the same configuration in all EBGPspeaking routers.
IBGP mesh scaling

Avoid unnecessary duplicate updates over a physical link.
Updates and table size scaling

Route summarization is the key to scalability.
BGP v3.26-13
The task of scaling BGP actually involves three different and independent scaling tasks:
BGP policy scaling: The AS routing policy should be unitary and easy to maintain.
Different edge routers of the same AS should not use different policies and thereby
advertise different routes to neighboring autonomous systems. Regardless of which router
is currently active, the same routing policy should be in place. Administratively, replication
of the same routing policies requires the same configuration lines in several edge routers.
IBGP mesh scaling: All BGP-speaking routers must be updated with consistent IBGP
information. In the traditional BGP approach, ensuring consistent routing information was
achieved by establishing a full mesh of IBGP sessions between all routers within the AS.
An IBGP full mesh is certainly not scalable, and several tools are now available to achieve
the same results without the full mesh.
Updates and table size scaling: The number of routes in the routing table and the number
of updates that are sent and received represent the third scaling task. Route summarization
is the key to this scalability.
6-14

This topic describes the scaling issues that are relevant to IP addressing in service provider
networks.

Private vs. public addresses
Private addresses on links break traceroute when run from
inside a firewall.
Private addresses on loopbacks call for careful external
routing.
MPLS with TTL propagation disabled solves the traceroute
issue.
Otherwise, use public addresses in service provider
networks.
BGP v3.26-14
Using private addresses in a service provider network has some drawbacks. Private addresses
on the provider internal links will cause trouble for the traceroute application. When the
traceroute command is executed from a router inside a customer network that resides inside a
firewall, the Internet Control Message Protocol (ICMP) replies that are generated by the
provider router will have the source IP address assigned using the outgoing interface. If this is a
private address, the customer firewall will most likely filter the packet because of addressspoofing detection rules. Even if the packet were allowed to enter the customer network,
Domain Name System (DNS) reverse lookups would either fail or result in confusing printouts.
Using MPLS without Time to Live (TTL) propagation in the service provider network can
easily overcome the traceroute problem with private addresses. If these functions are used, the
provider network will appear as a single hop to the traceroute application. The intermediate
routers will be invisible and thus can use private addresses.
Using private addresses on the service provider router loopback interfaces is possible.
However, you must take care not to advertise any private addresses to any other AS.
A rule of safety is to prevent the announcement of any private addresses by using prefix-lists
that are applied on outgoing updates to external neighbors. The same prefix-list mechanism can
also be used on the provider edge routers to prevent accepting private addresses from any other
AS if the other AS, by mistake, announces private addresses.
6-15
Example: Scaling Service Provider Addressing

This example illustrates assigning addresses to allow for route summarization.

Addressing? Example
Assign addresses to allow for route summarization.
BGP v3.26-15
In the figure, the left POP has been allocated two different address spaces. The address space
210.1.1.0/24 has been allocated to assign addresses to internal links within the POP. The
address space 173.16.1.16/28 is used to assign addresses to loopback interfaces on routers
within the POP.
Likewise, the right POP has assigned 210.1.2.0/24 to internal links and 173.16.1.32/28 to be
used with loopback interfaces.
The two POPs connect to the core, and, as they do, both summarize the range for their internal
links while they avoid summarizing the addresses that are assigned to the loopback interfaces
of the POP routers.
6-16

This topic describes the function of BGP policy accounting in relation to BGP scaling.
BGP v3.26-16
As network administrators learn to manage and scale larger and larger networks, they must also
be able to account for the usage of a growing customer base. How can you ensure that
customers are being charged correctly for their network utilization? How can you ensure that
they are receiving the services for which they have contracted? BGP policy accounting
addresses these concerns.
BGP policy accounting using AS numbers can be used to improve the design of network circuit
peering and transit agreements between ISPs.
BGP policy accounting measures and classifies IP traffic that is sent to, or received from,
different peers. Policy accounting is enabled on an input interface, and counters based on
parameters such as community-list, AS number, or AS path are assigned to identify the IP
traffic. Using BGP policy accounting, you can account for traffic according to the route that it
traverses. Service providers can identify and account for all traffic by customer and can bill
accordingly. In the figure, BGP policy accounting can be implemented in Router A to measure
packet and byte volumes in AS buckets. Customers are billed appropriately for traffic that is
routed from a domestic, international, or satellite source.
Using the BGP table-map command, prefixes added to the routing table are classified by BGP
attribute, AS number, or AS path. Packet and byte counters are incremented per input interface.
A Cisco IOS policy-based classifier maps the traffic into one of eight possible buckets,
representing different traffic classes.
Implementing BGP policy accounting on an edge router can highlight potential design
improvements for peering and transit agreements.
6-17
bgp-policy
To enable BGP policy accounting or policy propagation on an interface, use the bgp-policy
command in interface configuration mode.
bgp-policy {accounting | ip-prec-map}
To disable BGP policy propagation or policy accounting, use the no form of this command.
no bgp-policy {accounting | ip-prec-map}
Syntax Description
Parameter
Description
Accounting policy based on community-lists, AS numbers, or AS

paths
Quality of service (QoS) policy based on the IP precedence
set traffic-index
To indicate where to output packets that pass a match clause of a route map for BGP policy
accounting, use the set traffic-index command in route-map configuration mode.
set traffic-index bucket-number
To delete an entry, use the no form of this command.
no set traffic-index bucket-number
Syntax Description
Parameter
Description
Number, in the range from 1 to 8, representing a bucket into

which packet and byte statistics are collected for a specific traffic
classification
The BGP Policy Accounting Output Interface Accounting feature introduces several extensions
to enable BGP policy accounting (PA) on an output interface and to include accounting based
on a source address for both input and output traffic on an interface. Counters based on
parameters such as community-list, AS number, or AS path are assigned to identify the IP
traffic.
6-18
Specifying the Match Criteria for BGP Policy Accounting:

Example
In the following example, BGP communities are specified in community-lists, and a route-map
named set_bucket is configured to match each of the community-lists to a specific accounting
bucket using the set traffic-index command:

Classifying the IP Traffic and Enabling BGP Policy Accounting:

Example
In the following example, BGP policy accounting is enabled on packet over SONET (POS)
interface 7/0. The policy accounting criteria are based on the source address of the input traffic,
and the table-map command is used to modify the bucket number when the IP routing table is
updated with routes learned from BGP.

6-19
Summary
Summary
The service provider network usually consists of a network
core that interconnects edge devices connecting customers or
other service providers and that are located at various POPs.
Service providers use an IGP to carry internal routes and to
provide optimal routing between POPs, the information that is
needed for IBGP sessions to be established, and the addresses
that are required for BGP next-hop resolution.
In scaling IGPs and BGP in service provider networks, the IGP
is responsible for carrying routes to the BGP next hops,
providing an optimal path to the next hop, and converging to
an alternate path in the case of lost links or routers; the BGP is
responsible for generating BGP updates about reachable and
unreachable networks, implementing and scaling the BGP
routing policy, and reducing the impact of individual flapping
routes through route summarization.
BGP v3.26-17
Summary (Cont.)
Using private addresses on the service provider router
loopback interfaces is possible, but you must take care not to
advertise any private addresses to any other autonomous
systems. You can prevent the announcement of any private
addresses by using prefix-lists that are applied on outgoing
updates to external neighbors.
BGP policy accounting measures and classifies IP traffic that is
sent to, or received from, different peers. Policy accounting is
enabled on an input interface, and counters based on
parameters such as community-list, AS number, or AS path are
assigned to identify the IP traffic.
6-20
BGP v3.26-18
Lesson 2

Overview
Large Border Gateway Protocol (BGP) networks cannot properly scale without relying on
performance-enhancing tools such as route reflectors and confederations. Route reflectors
enable BGP routing information to be distributed in a fashion that does not require a physical
fully meshed network. Network overhead is reduced by decreasing the number of TCP
connections that are required to distribute routing information and by lessening router CPU and
memory requirements.
This lesson introduces BGP route reflectors by explaining why they improve BGP scalability.
Modified split-horizon rules, applied when you are using route reflectors, are also discussed.
The lesson concludes by describing the various redundancy mechanisms that are used with
route reflectors, including route reflector clusters.
Objectives
Upon completing this lesson, you will be able to describe the function of route reflectors in a
BGP environment. This ability includes being able to meet these objectives:
Explain the need for BGP route reflectors in BGP transit backbones
Explain how route reflectors modify traditional IBGP split-horizon rules
Explain the benefits of deploying redundant route reflectors
Explain how route reflector clusters prevent loops in the deployment of route reflectors in
redundant configurations
Describe additional route reflector mechanisms that have been designed to prevent routing
loops

This topic explains the need for BGP route reflectors by describing the scalability issues of
BGP transit backbones.

IBGP requires a full mesh between all
BGP-speaking routers.
Unnecessary duplicate routing traffic
Solutions
Route reflectors modify IBGP split-horizon rules.
BGP confederations modify IBGP AS-path processing.
BGP v3.26-3
Classic Internal Border Gateway Protocol (IBGP) split-horizon rules specify that updates that
are received on an External Border Gateway Protocol (EBGP) session should be forwarded on
all IBGP and EBGP sessions, but updates that are received on an IBGP session should be
forwarded only to all EBGP sessions. This rule requires a BGP boundary router to be able to
send routing updates to all other BGP-speaking routers in its own autonomous system (AS)
directly through a separate IBGP session to each of them.
The primary reason for the IBGP split-horizon rule is to avoid routing information loops within
the AS. If the information that is received through an IBGP session is forwarded on other IBGP
sessions, the information might come back to the originator and be forwarded again in a neverending loop. The originator would not detect the loop because no BGP attributes are changed
on IBGP sessions.
The general design rule in classic IBGP is to have a full mesh of IBGP sessions. But a full
mesh of IBGP sessions between n number of routers would require (n * (n 1)) / 2 IBGP
sessions. For example, a router with an AS that contains 10 routers would require (10 * (10
1)) / 2 = 45 IBGP sessions. Imagine the number of sessions (and the associated router
configuration) that would be required for a single AS containing 500 routers.
Every IBGP session uses a single TCP session to another IBGP peer. An update that must be
sent to all IBGP peers must be sent on each of the individual TCP sessions. If a router is
attached to the rest of the network over just a single link, this single link has to carry all TCP/IP
packets for all IBGP sessions. This requirement results in multiplication of the update over the
single link.
6-22
Route reflectors are BGP scalability mechanisms that enable routing information to be
redistributed to all routers within an AS while eliminating the need for a fully meshed topology
within the AS. This feature reduces the number of TCP sessions that must be maintained,
lowering network overhead and CPU and memory resource requirements.
Two different solutions are available to achieve greater scalability when you are faced with the
full-mesh rules of IBGP autonomous systems:
Route reflectors modify the classic IBGP split-horizon rule and allow a particular router to
forward incoming IBGP updates to an outgoing IBGP session under certain conditions.
This router becomes a concentration router, or a route reflector.
BGP confederations (covered in a separate lesson) introduce the concept of a number of
smaller autonomous systems within the original AS. The small autonomous systems
exchange BGP updates between them using intra-confederation EBGP sessions.
6-23

This topic explains how route reflectors modify traditional IBGP split-horizon rules.
Classic IBGP: IBGP routes are not

propagated to other IBGP peers.
Route reflector can propagate IBGP

routes to other IBGP peers.
Full mesh of IBGP peers is therefore

required.
Full mesh of IBGP peers is no longer

required.
BGP v3.26-4
In classic IBGP, the BGP boundary router needs to forward the route that is received from an
EBGP peer to every other router within its own AS using a dedicated IBGP session for each
one. Also, the BGP boundary router forwards routes that are sourced by a router in the same
way. To allow every router to update every other router, a full mesh of IBGP sessions is
required.
The IBGP route reflector design relaxes the need for a full mesh. The router configured as a
route reflector, under certain conditions, will relay updates that are received through an IBGP
session to another IBGP session. This capability requires modifications of the classic IBGP
split-horizon rules.
The route reflector concept introduces processing overhead on the concentration router and, if it
is configured incorrectly, can cause routing loops and instability.
6-24
Route Reflector Split-Horizon Rules (Cont.)
BGP v3.26-5
When you implement a route-reflector-based IBGP network, the BGP routers are divided into
route reflectors (which implement modified split-horizon rules) and clients (which are behaving
like traditional IBGP routers).
Route reflector clients are excluded from the full mesh. They can have any number of EBGP
sessions but may have only one IBGP session, the session with their route reflector. Clients
conform to the classic IBGP split-horizon rules and forward a received route from EBGP on
their IBGP neighbor sessions. But the route reflector conforms to the route reflector splithorizon rules and recognizes that it has an IBGP session to a client. When the IBGP update is
received from the client, the route reflector forwards the update to other IBGP neighbors,
therefore alleviating the IBGP full-mesh requirement for its clients.
Similarly, when the route reflector receives an IBGP update from a neighbor that is not its
client, it forwards the update to all of its clients.
Forwarding of an IBGP update in a route reflector does not change the next-hop attribute or any
other common BGP attribute. This feature means that the client will use the optimum route by
means of recursive routing, regardless of the way that it has received the BGP route.
6-25
Route Reflector Split-Horizon Rules (Cont.)
BGP v3.26-6
The figure shows how an AS with nine routers running BGP reduces the required number of
IBGP TCP sessions from 36 to 11 by using route reflectors.
The table presents detailed IBGP split-horizon rules as modified by the introduction of BGP
route reflectors. For purposes of definition, a route reflector is a BGP speaker that can
advertise IBGP learned routers to another IBGP peer and, hence, can reflect routes. IBGP peers
of the route reflector fall under two categories: clients and nonclients. The route reflector
and its clients form a cluster. All IBGP peers of the route reflector that are not part of the
cluster are nonclients. A classic IBGP router is a router that does not support route reflector
functionality.
Type of Router
Classic
Route reflector
Client
6-26
Incoming Update
From
Is Forwarded To
EBGP peer
All peers (IBGP and EBGP)
IBGP peer
EBGP peers
EBGP peer
Nonclient IBGP peer
EBGP peers and clients
Client IBGP peer
All peers but the sender
EBGP peer
IBGP peer
EBGP peers

This topic explains the benefits of deploying redundant route reflectors.
BGP v3.26-7
Clients may have any number of EBGP peers but may have IBGP sessions only with their route
reflector or reflectors. If the reflector fails, its client can no longer send BGP updates to, or
receive them from, the rest of the AS. The route reflector is, therefore, a single point of failure.
To avoid introducing a single point of failure into the network, the route reflector functionality
must be as redundant as the physical network. If a client will still be physically attached to the
network after its route reflector has failed, the client should have a redundant route reflector.
Thus, in all highly available networks, route reflectors must be redundant.
6-27
Redundant Route Reflectors (Cont.)
BGP v3.26-8
A client may have IBGP sessions to more than one route reflector to avoid a single point of
failure. Each client will receive the same route from both of its reflectors. Both route reflectors
will receive the same IBGP update from their client, and they will both reflect the update to the
rest of the clients. Additionally, both route reflectors will get updated from the full mesh and
reflect those updates to their clients. As a result, each client will get two copies of all routes.
Under certain circumstances (particularly when you use weights on IBGP sessions to influence
BGP route selection), improper route reflection can result in an IBGP routing loop that is
impossible to detect. Additional BGP attributes are thus necessary to prevent these routing
loops.
6-28

This topic explains how route reflector clusters prevent loops in the deployment of route
reflectors in redundant configurations.

A group of redundant route reflectors and their clients form a
cluster.
Each cluster must have a unique cluster-ID.
Each time a route is reflected, the cluster-ID is added to the
cluster-list BGP attribute.
The route that already contains the local cluster-ID in the
cluster-list is not reflected.
BGP v3.26-9
A router that is acting as a route reflector client does not require any specific configuration. It
simply has fewer IBGP sessions than it would have if it were part of the full mesh. But
improperly configuring the client to also be a reflector could easily cause a loop. An IBGP
route coming in from one of the real reflectors to the client could be forwarded by the client,
erroneously acting as reflector, to the other reflector.
Route reflector clusters prevent IBGP routing loops in redundant route reflector designs.
The role of the network designer is to properly identify which route reflectors and their clients
will form a cluster. The designer assigns to the cluster a cluster-ID number that is unique within
the AS.
Note
The cluster-ID number must be configured in the route reflectors. The clients should not be
configured with this information.
A route reflector router can reflect routes only within a single cluster. A route reflector can,
however, participate in another cluster but only as a client. A client can function as a client only
to a route reflector belonging to the same cluster.
When a route is reflected, the reflector creates the cluster-list attribute and attaches it to the
route if it does not already exist. It then sets its cluster-ID number in the cluster-list or adds its
cluster-ID number to an already existing cluster-list attribute. If the route, for any reason, is
ever reflected back to the same reflector, it will recognize its cluster-ID number in the clusterlist and not forward it again. The first route reflector that reflects the route also sets an
additional BGP attribute, called originator-ID, and adds it to the BGP router-ID of its client.
6-29
Note
The cluster-list and originator-ID attributes are nontransitive optional BGP attributes,
allowing routers that do not support route reflector functionality to coexist with route
reflectors and their clients in the same AS.
Based on cluster-list and originator-ID attributes, routers can implement two loop-prevention
mechanisms:
Any router that receives an IBGP update with the originator-ID attribute set to its own BGP
router-ID will ignore that update.
Any route reflector that receives an IBGP update with its cluster-ID already in the clusterlist will ignore that update.
6-30
Example: Route Reflector Clusters

The figure shows a cluster with redundant route reflectors.
Route Reflector Clusters (Cont.)
BGP v3.26-10
The client in the cluster forwards the received EBGP update to both reflectors. The route
reflectors forward the update into the IBGP full mesh. This behavior means that they send the
update to each other as well. But when a route reflector receives a BGP update from another
route reflector, it recognizes their common cluster-ID number in the cluster-list attribute.
Therefore, the newly received route update is ignored.
6-31
Additional Route Reflector Loop-Prevention

Mechanisms
This topic describes additional route reflector mechanisms designed to prevent routing loops.
Additional Route Reflector

Loop-Prevention Mechanisms
Every time a route is reflected, the router-ID of the originating
IBGP router is stored in the originator-ID BGP attribute.
A router receiving an IBGP route with originator-ID set to its
own router-ID ignores that route.
The BGP path selection procedure is modified to take into
account cluster-list and originator-ID.
BGP v3.26-11
When a route is reflected, the route reflector sets the originator-ID BGP attribute (nontransitive
optional BGP attribute) to the router-ID of the peer from which it received the route. Any router
that receives a route with its own router-ID in the originator-ID attribute silently ignores that
route.
BGP path selection rules have been modified to select the best route in scenarios where a router
might receive reflected and nonreflected routes or several reflected routes:
The traditional BGP path selection parameters such as weight, local preference, origin,
and multi-exit discriminator (MED) are compared first.
If these parameters are equal, the routes that are received from EBGP neighbors are
preferred over routes that are received from IBGP neighbors.
When a router receives two IBGP routes, the nonreflected routes (routes with no
originator-ID attribute) are preferred over reflected routes.
The reflected routes with shorter cluster-lists are preferred over routes with longer
cluster-lists.
If the additional route-reflector-oriented selection criteria do not yield a decision, the rest of
the traditional BGP path selection rules are followed.
6-32
Summary
Summary
BGP route reflectors were introduced to free the network
designers from IBGP full-mesh requirements that prevent
large networks from scaling.
BGP route reflectors modify IBGP split-horizon rules in that
all routes that are received from a route reflector client are
sent to all other IBGP neighbors, and all routes that are
received from a nonclient IBGP neighbor are sent to all route
reflector clients.
A route reflector is a single point of failure, and therefore
redundancy should be implemented in a network containing
route reflectors.
BGP v3.26-12
Summary (Cont.)
Route reflector clusters were introduced in the BGP route
reflector architecture to support redundancy, preventing
IBGP routing loops in redundant route reflector designs.
The originator-ID and cluster-list BGP attributes were
introduced to prevent routing loops in route reflector
environments.
BGP v3.26-13
6-33
6-34
Lesson 3
Designing Networks with

Route Reflectors
Overview
performance-enhancing tools such as route reflectors and confederations. Route reflectors are a
BGP scalability mechanism that enables routing information to be redistributed to all routers
within an autonomous system (AS) while eliminating the need for a fully meshed topology
within the AS. Properly implementing these features requires careful network design within the
AS.
This lesson introduces the network design rules that network designers should follow when
implementing a network with BGP route reflectors. It also lists the potential issues that can
arise if the network design rules are not adhered to. The lesson concludes by describing the
concept of hierarchical route reflectors.
Objectives
Upon completing this lesson, you will be able to describe the function of hierarchical route
reflectors, based on established route reflector design rules. This ability includes being able to
List the network design rules for implementing BGP route reflectors
List the potential issues that can arise if you do not follow the route reflector network
design rules
Explain the function of hierarchical route reflectors

This topic lists the network design rules for implementing BGP route reflectors and Internal
Border Gateway Protocol (IBGP) sessions.

Route reflector rules
Route reflector rules divide a transit AS into smaller areas
(called clusters).
Each cluster contains route reflectors and route reflector
clients.
Routers that do not support route reflector functionality act as
a one-router cluster or as a route reflector client.
BGP v3.26-3
The physical topology of the network could serve as a guide to route reflector design.
Implementing route reflectors within the transit AS will create smaller areas (or groups) of
routers. These smaller groupings of routers are called clusters. A cluster consists of route
reflector routers, either redundant or nonredundant, and the client routers that are connected to
them.
In designing the implementation of route reflectors within a transit AS, identify a group of
peripheral routers that are physically connected to the same backbone router or routers.
Consider the peripheral routers as clients and the backbone routers as route reflectors. Then,
consider this group of routers together to form a cluster.
Note
Additional design examples and rules are available in the module BGP Transit Autonomous
Systems.
Only the routers that are configured as route reflectors require a Cisco IOS software version
with route reflector functionality. A router lacking this functionality in its installed Cisco IOS
software can function as a client or be a part of the full mesh. Normally, this situation is not a
concern because route reflector functionality has been incorporated in Cisco IOS software since
Release 11.1.
6-36
Network Design with Route

Reflectors (Cont.)
IBGP session rules
All clients in a cluster must establish IBGP sessions with and
only with all route reflectors in the cluster.
An IBGP full mesh between all route reflectors within the AS
is required.
Routers that are not route reflectors can participate in the
IBGP full mesh or be route reflector clients.
BGP v3.26-4
The principal goal for designing networks with BGP route reflectors is to reduce the size of the
full mesh of IBGP sessions by excluding some routers from the mesh. The routers that are
excluded from the full mesh, the clients, have to send their IBGP information to, and receive it
from, at least one router that belongs to the full mesh, the route reflector. Thus, the full mesh is
still there, but it is smaller, and all route reflectors have to be part of it.
All clients in a cluster should have IBGP sessions with all their route reflectors and their route
reflectors only. If a client does not have sessions with all the reflectors in the cluster, the
redundancy is violated. If a client has IBGP sessions to routers other than the route reflectors,
unnecessary routing traffic is generated.
Both clients and other routers, those that are not route reflectors, obey the classic IBGP splithorizon rules. Thus, non-route-reflector routers are either clients to a reflector or are
participating directly in the full mesh.
Scaling Service Provider Network
6-37
Example: Network Design with Route Reflectors

In this example, the routers that serve as route reflectors and the non-route-reflector router have
IBGP sessions in a full mesh.
Network Design with Route

Reflectors? Example
BGP v3.26-5
In the area called the redundant cluster, the four client routers and the two route reflector
routers make up the cluster. Each of the four client routers has an IBGP session with the two
route reflectors and only with those two route reflectors.
In the nonredundant area, each of the two client routers has a single physical connection to a
route reflector router. These three routers form a nonredundant cluster. The router designated as
the route reflector in the cluster is already a single point of failure in this physical design
because a failure of this router will prevent the clients in the cluster from reaching the rest of
the network. Therefore, there is no new single point of failure that is introduced when the router
is configured as the only route reflector in this cluster. Each of the two clients has a single
IBGP session to the route reflector.
The other router shown is not configured as a route reflector nor is it a client to any other route
reflector. This other router serves as an example of where a non-route-reflector router
participates in the full mesh.
6-38

This topic lists the potential issues that can arise if the route reflector network design rules as
explained in the previous topic are not followed.

Potential problems that can occur when you deviate
from the route reflector network design rules:
Issue
Result
Clients do not have sessions with Clients will not receive all IBGP
all reflectors in a cluster.
routes.
Clients have sessions with
reflectors in several clusters.
Clients will receive duplicate

copies of the same route.
Clients have IBGP sessions with

other clients.
Clients will receive duplicate

copies of the same route.
BGP v3.26-6
Two nontransitive optional BGP attributes, originator-ID and cluster-list, are both used to
prevent fatal loops of information. The use of these two attributes makes a network fairly
insensitive to poor configuration. However, for optimal performance, you must have an optimal
configuration. Here are some of the problems that could occur if you deviate from route
reflector network design rules:
If route reflectors are not connected with IBGP sessions in a full mesh, some clusters will
not have all the routes.
If a client has IBGP sessions with some route reflectors in a cluster, but not with all of
them, the client might miss some BGP routes.
If a client has IBGP sessions to route reflectors that belong to different clusters, the BGP
update from the client will be forwarded by the client into the full mesh with different
cluster-IDs in the cluster-list attribute. When the BGP update enters the mesh, it will reach
the other route reflector, which will, unnecessarily, accept the route as valid and forward it
into its cluster. This situation, in turn, causes unnecessary duplication of updates to the
clients.
If a client has IBGP sessions to other clients in the same cluster, those clients will receive
unnecessary duplications of updates.
6-39

This topic explains the function of hierarchical route reflectors.

Problem:
In very large networks, a single layer of route reflectors might
not be enough.
Solution:
A hierarchy of route reflectors can be established.
A route reflector can be a client of another route reflector.
The hierarchy can be as deep as needed.
BGP v3.26-7
Network designers can build route reflector clusters in hierarchies. With hierarchies, a router
serving as a route reflector in one cluster can act as a client in another cluster.
Clients are not configured to be route reflector clients; they simply have fewer IBGP sessions.
However, a network designer must configure a route reflector. In configuring an IBGP session
on a route reflector, the designer must configure the session to reach a client in order for the
route reflector IBGP split-horizon rules to start working. All other IBGP sessions that are
configured on the route reflector are a part of the full mesh. Also, the designer must configure
the cluster-ID on the route reflector.
A router that is configured to be a route reflector will still have ordinary IBGP sessions that are
part of the full mesh. If these sessions are reduced in number and only a few remain, and the
remaining ones reach a second level of route reflectors, a hierarchy of route reflectors is
created.
When a designer builds a first level of clusters, the remaining full mesh is smaller than when all
routers belonged to it. But if it is large enough, the designer can build an additional level of
route reflectors.
6-40
Example: Hierarchical Route Reflectors

In this example, the first level of route reflector clusters was built by creating cluster 11 and
cluster 12.
Hierarchical Route Reflectors (Cont.)
BGP v3.26-8
This first step reduced the original full mesh of 14 routers to a full mesh of 8 routers.
A second level of route reflector clusters was built by creating cluster 27. This second step
further reduced the full mesh of eight routers to a full mesh consisting of only two routers. Only
the two route reflectors in cluster 27 should be connected in a full mesh.
When a client in the lowest level receives an External Border Gateway Protocol (EBGP)
update, it will forward it on all configured IBGP sessions to a route reflector. The route
reflector recognizes BGP updates that are received from configured clients and will forward
these updates to all other clients that use normal IBGP sessions. The update, sent on a normal
IBGP session, will be a second-level client update to the second-level route reflector. The
second-level route reflector will recognize that the update was received from a client and will
forward it to all other clients and into the full mesh.
6-41
Summary
Summary
All route reflectors in a cluster should have IBGP sessions to
all clients in the cluster. The route reflectors also participate
in the IBGP full mesh, and they should have no other IBGP
sessions.
When the route reflector clients do not have IBGP sessions
with all route reflectors in the cluster, they might not receive
all IBGP routes.
When the clients have additional IBGP sessions with routers
that are not their route reflectors, they receive unnecessary
IBGP routes and potentially encounter a routing loop.
Route reflector clusters can be built in hierarchies. A router
that is a route reflector in one cluster can act as client in
another cluster.
6-42
BGP v3.26-9
Lesson 4
Configuring and Monitoring

Route Reflectors
Overview
performance-enhancing tools such as route reflectors and confederations. Route reflectors
full-mesh network. Implementing such a network requires knowledge of the steps to properly
migrate and configure route reflectors and the commands that are used to verify the operation
of a configured network.
This lesson introduces the steps that are required to successfully migrate an existing
autonomous system (AS) to BGP route reflectors. It also lists the Cisco IOS commands that are
required to configure and monitor route reflectors.
Objectives
Upon completing this lesson, you will be able to configure proper operation of route reflectors
to modify IBGP split-horizon rules in an existing IBGP network. This ability includes being
able to meet these objectives:
List the steps to migrate an existing IBGP backbone to a backbone with route reflectors
Identify the configuration changes and related Cisco IOS commands that are required to
configure route reflectors on a BGP backbone
Identify the Cisco IOS commands that are required to monitor a BGP backbone that
contains route reflectors

This topic lists the steps that are required to successfully migrate an existing Internal Border
Gateway Protocol (IBGP) backbone to a backbone with route reflectors.

Divide the AS into areas (clusters).
Assign a cluster-ID to each area.
On route reflector clients, retain only IBGP sessions with

route reflectors in their cluster.
On route reflectors, retain only IBGP sessions with other
route reflectors and clients in their cluster.
Configure cluster-ID on every route reflector.
Configure clients on every route reflector.
BGP v3.26-3
The physical topology of the AS serves as a guide to designing clusters. You should introduce
no additional single points of failure when you are deploying route reflectors. If the physical
topology is redundant, a good practice is to have redundant route reflectors. If the physical
topology is not redundant, introducing a nonredundant cluster does not add a single point of
failure because the network was already nonredundant.
The following planning and preparation steps are required before you migrate from a full mesh
of IBGP sessions to a route reflector design:
Step 1
Identify a group of peripheral routers that are physically connected to the same set of
backbone routers. Consider the peripheral routers as clients and the backbone routers
as route reflectors. Let the routers form a cluster. Make sure that no router belongs to
two different clusters, because this setup would represent an illegal configuration.
Step 2
Create a numbering plan that indicates how numbers are assigned to the clusters in
the network. The plan must make sure to uniquely identify each of the clusters
within the AS. Clusters are not seen from outside the AS, so the plan does not need
to be coordinated with any other AS. To ease troubleshooting, it is recommended
that numbers lower than 256 be used, because cluster-IDs are displayed in IP
address format.
Note
6-44
The default value of a cluster-ID is the BGP router-ID of the route reflector. If you decide to
implement nonredundant clusters, you do not have to plan the cluster-ID numbers, because
the BGP router-IDs should be unique.

This topic lists the configuration changes and related Cisco IOS commands that are required to
configure BGP route reflectors.

Configure cluster-ID on route reflectors.
Configure BGP neighbors as route reflector clients on the
route reflectors.
No configuration is needed on the route reflector clients.
Make sure IBGP neighbor is removed on both ends of the
IBGP session.
BGP v3.26-4
As part of the planning and preparation that is necessary to migrate from a full mesh of IBGP
sessions to a route reflector design, you need to make the following configuration changes:
Configure the proper cluster-ID value on the route reflectors.
Configure the route reflector with information about which IBGP neighbor sessions are
reaching their clients.
In the clients, remove all IBGP sessions to neighbors that are not route reflectors in the
client cluster.
Make sure that the IBGP neighbor is removed on both ends of the IBGP session.
6-45
Configuring Route Reflectors (Cont.)

Optionally assigns a cluster-ID to the route reflector (default
value is router-ID)
Required only for clusters with redundant reflectors
Cluster-ID cannot be changed after the first client is configured

Configures an IBGP neighbor to be a client of this reflector
BGP v3.26-5
bgp cluster-id
Use the bgp cluster-id command to configure the cluster-ID if the BGP cluster has redundant
route reflectors.
bgp cluster-id cluster-id
To remove the cluster-ID, use the no form of this command.
no bgp cluster-id cluster-id
Syntax Description
Parameter
Description
Cluster-ID of the router acting as a route reflector.

The cluster-ID is a maximum of 4 bytes.
6-46
neighbor route-reflector-client
This command used to configure the router as a BGP route reflector and configure the specified
neighbor as its client. When all the clients are disabled, the local router is no longer a route
reflector.
neighbor ip-address route-reflector-client
To indicate that the neighbor is not a client, use the no form of this command.
no neighbor ip-address route-reflector-client
Syntax Description
Parameter
Description
Neighbor IP address
By default, there is no route reflector in the AS.
6-47
Example: Configuring Route Reflectors

In this example, AS 123 has been divided into clusters with route reflectors.
Configuring Route Reflectors (Cont.)
BGP v3.26-6
The routers with router-ID 1.0.0.1 and 1.0.0.2 are route reflectors in a cluster that has been
assigned cluster-ID 175. The routers with router-ID 1.0.0.3 and 1.0.0.4 are clients to these two
route reflectors.
The figure shows a portion of the configuration in router 1.0.0.1. The cluster-ID is assigned to
the router under the router bgp process definition of the router configuration. After the router
has been assigned, the route reflector client configuration is added under the router bgp
process for the two neighbors that identify the two sessions reaching clients.
6-48

This topic lists the Cisco IOS commands that are required to monitor route reflector
configurations.
Displays whether a neighbor is a route reflector client
Displays additional path attributes (originator-ID and cluster-list)
BGP v3.26-7

In this case, the show ip bgp neighbors command is used on the router not to see routes or
paths that have been received but to see the status of the neighbor session, so no other qualifiers
than the optional IP address are given.
show ip bgp
When details are displayed for a specific route entry in the BGP table, the cluster-list and
originator-ID attributes are also shown.
6-49
Monitoring Route Reflectors (Cont.)
BGP v3.26-8
The show ip bgp neighbors command, issued on the route reflector router, indicates that the
neighbor is a route reflector client.
6-50
Monitoring Route Reflectors (Cont.)
Routes received from the client as seen on the reflector
Reflected routes as seen on the client

BGP v3.26-9
The first example of a show ip bgp command is issued on a route reflector router. It shows that
this particular entry in the BGP table was received from a route reflector client.
The second example shows an entry in the BGP table that at some point was reflected from a
route reflector. The reflecting router has added the originator-ID and cluster-list attributes to the
route.
6-51
Summary
Summary
To successfully migrate an existing IBGP backbone to a
backbone with route reflectors: Divide the AS into areas
(clusters). On route reflector clients, retain only IBGP
sessions with route reflectors in their cluster. On route
reflectors, retain only IBGP sessions with other route
reflectors and clients in their cluster.
There are only two Cisco IOS commands that are used to
configure BGP route reflectors: bgp cluster-id and neighbor ipaddress route-reflector-client.
The show ip bgp neighbors command will display whether a
neighbor is a route reflector client, and the show ip bgp prefix
command will display the originator-ID and cluster-list
attributes.
6-52
BGP v3.26-10
Lesson 5
Introducing Confederations
Overview
performance-enhancing tools such as route reflectors and confederations. Routers within an
autonomous system (AS) are typically configured in a full mesh. Confederations and route
reflectors are BGP scalability mechanisms that enable routing information to be redistributed to
all routers within an AS while eliminating the need for a fully meshed topology within the AS.
These features reduce the number of TCP sessions that must be maintained, which lowers
network overhead and CPU and memory requirements. Confederations can serve as an
alternative or a complement to route reflectors, enabling network administrators to break up an
AS into a set of logical subautonomous systems.
This lesson introduces BGP confederations by explaining why confederations are used to
improve BGP scalability. This lesson also discusses AS-path propagation and processing in an
AS that contains confederations.
Objectives
Upon completing this lesson, you will be able to describe the function of confederations in a
BGP environment. This ability includes being able to meet these objectives:
Describe the IBGP full-mesh requirement when you are using a transit AS in relation to the
potential issues that this requirement can cause
Explain how you can use BGP confederations to split an AS into a series of smaller
autonomous systems
Describe AS-path propagation in BGP confederations
Explain AS-path attribute processing in an AS that contains BGP confederations
Explain the properties of intra-confederation EBGP sessions

This topic describes the Internal Border Gateway Protocol (IBGP) full-mesh requirement when
you are using a transit AS and the potential issues that this requirement can cause.

IBGP requires a full mesh between all
BGP-speaking routers.
Unnecessary duplication of routing traffic
Solutions
Route reflectors modify IBGP split-horizon rules.
BGP confederations modify IBGP AS-path processing.
BGP v3.26-3
Classic IBGP split-horizon rules specify that BGP updates that are received on an External
Border Gateway Protocol (EBGP) session should be forwarded on all IBGP and EBGP
sessions, but BGP updates that are received on an IBGP session should be forwarded on all
EBGP sessions only. This rule requires a boundary router to be able to update all other BGPspeaking routers in its own AS directly via an IBGP session that is established to each of them.
IBGP split-horizon rules avoid routing information loops within the AS. If IBGP information
were forwarded to another IBGP peer router, the information might come back to the originator
and be forwarded again in a never-ending loop. The originator would not detect the loop
because no BGP attributes are changed when an update is sent through an IBGP session.
The general design rule in classic IBGP is to have a full mesh of IBGP sessions between all
BGP-speaking routers inside an AS. However, a full mesh of IBGP sessions between n number
of routers would require (n * (n 1)) / 2 IBGP sessions. For example, an AS with 10 routers
would require (10 * (10 1)) / 2 = 45 IBGP sessions.
Every BGP session between two routers is established through a separate TCP session to the
BGP peer. An update that must be sent to all IBGP peers must be sent separately on each of the
TCP sessions. If a router is attached to the rest of the network over just a single link, this single
link has to carry all TCP/IP packets for all IBGP sessions. This requirement results in
duplication of BGP updates over the single link.
6-54
Two solutions are available to achieve greater scalability when you are faced with the full-mesh
rules of IBGP autonomous systems:
Route reflectors: Route reflectors modify the classic IBGP split-horizon rules and allow a
particular router to forward incoming IBGP updates to an outgoing IBGP session under
certain conditions. This router becomes a concentration router, or a route reflector.
BGP confederations: BGP confederations introduce the concept of a number of smaller
autonomous systems within the original AS. The small autonomous systems exchange BGP
updates between them using intra-confederation EBGP sessions.
Example: IBGP Transit AS Problems

A large service provider backbone, acting as a transit AS, contains 150 routers. Because the
classic IBGP design rule requires a full mesh, the AS would require 11,175 sessions
(n * [n 1] / 2). This number is impractical, so you should use other solutions, such as BGP
confederations, to reduce the full-mesh requirements of the network.
6-55
Splitting a Transit AS with BGP Confederations

This topic describes how you can use BGP confederations to split an AS into a series of smaller
autonomous systems.
Splitting a Transit AS with

BGP Confederations
Splitting the AS into smaller autonomous systems would reduce the

number of BGP sessions, but extra AS numbers are not available.
Confederations enable internal AS numbers to be hidden and
announce only one (external) AS number to EBGP neighbors.
BGP v3.26-4
A large number of routers in a large transit AS would traditionally introduce a complex fullmesh structure of IBGP sessions. By splitting the AS into a number of small autonomous
systems, you can provide each one of the small systems with a fairly simple IBGP structure.
Interconnections between these autonomous systems could then be made using EBGP, which
allows for arbitrary topologies.
Splitting an AS into smaller autonomous systems requires a large number of official AS
numbers, which are a scarce resource.
However, by introducing the BGP confederation, you can enable a large AS to be partitioned
into a number of smaller autonomous systems (called member autonomous systems) where
each is internal to the larger AS. The AS numbers of each member-AS that is used within the
confederation are never visible from outside the confederation itself. This invisibility allows
private AS numbers (in the range 64512 to 65535) to be assigned to autonomous systems inside
a confederation to identify a member-AS, without the need to coordinate AS number
assignments with an official AS delegation authority.
Within a member-AS, the classic IBGP rules apply. Therefore, all BGP routers inside the
member-AS must still maintain a full mesh of BGP sessions.
Between member autonomous systems inside a confederation, EBGP sessions are established.
These EBGP sessions behave slightly differently from classic EBGP sessions and are therefore
named intra-confederation EBGP sessions to differentiate them from true EBGP sessions.
6-56
AS-Path Propagation Within the BGP

Confederation
This topic describes how the AS-path attribute is propagated inside and outside of the BGP
confederation.
AS-Path Propagation Within the

BGP Confederation
IBGP session
The AS path is not changed.
Intra-confederation EBGP session

The intra-confederation AS number is prepended to the AS
path.
EBGP session with external peer

Intra-confederation AS numbers are removed from the AS
path.
The external AS number is prepended to the AS path.
BGP v3.26-5
The mandatory well-known BGP attribute AS-path is modified on EBGP and intraconfederation EBGP sessions. The sender prepends its own AS number to the AS path
whenever an EBGP update is sent. When a BGP update traverses the Internet, every AS it
passes through is recorded in the AS path. If the update, for any reason, comes back to an AS in
which it has already been, the receiving router recognizes its own AS in the AS path and
silently ignores the update. This mechanism prevents information loops and allows arbitrary
topology when you are interconnecting autonomous systems.
IBGP sessions do not modify the AS-path attribute, so the topology within each AS is limited
to the full mesh, and the propagation of BGP updates across multiple IBGP sessions is
prohibited.
When a router sends a BGP update over an intra-confederation EBGP session, it prepends the
member-AS number to the AS path. This information is maintained by the routers within the
confederation and prevents routing information loops inside the confederation.
When a router sends a BGP update over a true EBGP session to an AS outside of the
confederation, it removes the part of the AS path describing the member-AS numbers and
prepends the official AS number to the AS path. As a result, the confederation appears as one
single AS to the outside world.
6-57
Example: AS-Path Propagation Within the BGP Confederation

The figure illustrates how the AS-path attribute is processed within a BGP confederation.
AS-Path Propagation Within the

BGP Confederation (Cont.)
BGP v3.26-6
Network X originates inside AS 12 and is announced by the edge router in AS 12 over a true
EBGP session to the ingress router in the confederation. The edge router in AS 12 determines
that the edge router that it is communicating with resides in AS 42. AS 12 prepends its assigned
AS number in the AS path (which was previously empty, because network X originated in AS
12). When the EBGP update arrives at the confederation member-AS 65001, the AS-path
attribute has been set to 12.
The member-AS 65001 has intra-confederation EBGP sessions to member-AS 65002 and to
member-AS 65003. The router in AS 65001 prepends its own AS number to the AS path. When
doing this, it signals that this part of the AS path describes the intra-confederation AS path.
When printed out, the intra-confederation part of the AS path is displayed within parentheses.
Therefore, when member AS 65001 sends the update to member-AS 65002 and member-AS
65003, the route to network X has an AS-path attribute set to (65001) 12.
Within a member-AS, the router sends the update using classic IBGP. The router does not
modify the AS path when transmitting it over an IBGP session.
Member-AS 65002 and member-AS 65003 both prepend their AS number, so member-AS
65004 receives the update about the route to X via two different paths, one with AS path
(65002 65001) 12 and the other with AS path (65003 65001) 12.
Member-AS 65004 selects one of the alternatives as the best BGP route. It then forwards this
update on the intra-confederation EBGP session. This update could introduce a loop, but if the
update were ever to be forwarded all the way back up to member-AS 65001, the loop would be
detected and member-AS 65001 would silently ignore the update.
6-58
Member-AS 65004 also forwards the update about network X on a true EBGP session to
AS 14. When it does, it removes all the parenthesized information in the AS path and replaces
it with the official AS number of the confederation, 42. AS 14 thus receives the update about
network X with an AS path that is set to 42 12.
The routers in AS 14 select the best path based on the length of the AS path if no other policy is
configured. AS14 will see the route to X with an AS-path length of two. When AS 14 forwards
packets that are destined for network X into the confederation (AS 42), member-AS 65004
must make a forwarding decision. This decision process inside the confederation will use both
confederate AS paths for loop avoidance but not for choosing the shortest AS path within the
confederation. The multiple step BGP path-selection process will treat both AS paths as equal
and have to use the other attributes to select the preferred path. All else being equal, the BGP
decision process chooses normal EBGP routes over confederation EBGP routes and
confederation EBGP over IBGP routes.
6-59

This topic explains how the BGP AS-path attribute is processed within an AS that contains a
BGP confederation.

Intra-confederation AS path is encoded as a separate
segment of the AS path.
The intra-confederation AS path is displayed in parentheses
when you are using Cisco IOS show commands.
All routers within the BGP confederation have to

support BGP confederations.
A router not supporting BGP confederations will reject an AS
path with unknown segment type.
BGP v3.26-7
When BGP routing updates are sent by BGP-speaking routers over a BGP session, the BGP
attributes are encoded in a binary structure. The AS-path attribute, which is printed out and
displayed as a text string, is actually a type, length, value (TLV) binary field, which is
composed of several segments. The intra-confederation part of the AS path is encoded by the
intra-confederation router as a separate segment of the AS path with a new type code. This
segment of the AS path contains a sequence of AS numbers that encode the member
autonomous systems that the BGP update has traversed.
Because this segment is an extension to the original interpretation of the mandatory well-known
BGP attribute AS path, a BGP implementation that does not support BGP confederations will
not understand the intra-confederation part of the AS path. If a router receives a BGP update
with a mandatory well-known attribute that the router cannot interpret, it will send a
notification to the neighbor that sent the offending update and terminate the session. A router
that does not support BGP confederations, therefore, cannot operate inside a BGP
confederation.
6-60
Intra-Confederation EBGP Session Properties

This topic describes EBGP sessions between different autonomous systems that are contained
within the confederation.
Intra-Confederation EBGP
Session Properties
Behaves like EBGP session during session
establishment
The EBGP neighbor has to be directly connected, or you
have to configure ebgp-multihop on the neighbor.
Behaves like IBGP session when propagating routing

updates
The local preference, MED, and next-hop attributes are
retained.
The whole confederation can run one IGP, providing optimal
routing based on the next-hop attribute in the BGP routing
table.
BGP v3.26-8
Intra-confederation EBGP sessions, while having EBGP-like properties (for example, updating
the AS-path attribute when propagating BGP routes), still run inside a real AS and therefore
have to share some properties with IBGP sessions to achieve the same end results. Similar to
IBGP sessions, the BGP attributes of local preference, multi-exit discriminator (MED), and
next-hop are not changed in updates that are propagated across intra-confederation EBGP
sessions. All routers in all member autonomous systems inside the confederation consequently
use the same next-hop address when they are doing recursive routing. Because all intraconfederation routers use the same next-hop address, the entire confederation should use the
same Interior Gateway Protocol (IGP) to resolve the BGP next-hop address. The IGP
information should not be limited by the member-AS boundary.
On the other hand, intra-confederation EBGP sessions behave exactly like EBGP sessions when
they are established. EBGP sessions are normally opened between directly connected
interfaces. However, because all routers within the confederation run the same IGP and
exchange internal routing information, there is no problem for them to open multihop sessions.
Resiliency of BGP sessions and consequent stability of BGP routing are introduced into the
network if the intra-confederation EBGP sessions are established between loopback interfaces,
just like IBGP sessions normally are.
When intra-confederation EBGP sessions are opened between loopback interfaces, the ebgpmultihop qualifier must be given to the session. Otherwise the EBGP session will never leave
the Idle state.
6-61
Actually, the intra-confederation EBGP sessions could be established between intraconfederation routers in an arbitrary topology, not necessarily following the physical topology.
The next hop of the route will always contain the IP address of a BGP router outside of the
confederation, and packet forwarding will follow the optimal path, because recursive routing
will rely on the IGP to reach the BGP next hop. The intra-confederation EBGP sessions are
merely used to distribute the BGP updates to all member autonomous systems. To avoid
unnecessary duplication of routing updates, network designers should take great care when
designing the topology of the intra-confederation EBGP sessions.
6-62
Summary
Summary
IBGP requires a full mesh between all BGP-speaking routers;
route reflectors modify IBGP split-horizon rules, and BGP
confederations modify IBGP AS-path processing.
The full-mesh requirement is relaxed through introduction of
member autonomous systems into which the original
autonomous system is split.
The additional autonomous system numbers are hidden from
the outside world by modified AS-path update procedures.
The intra-confederation segment is removed from the AS
path by the egress confederation router prior to prepending
the official AS number when sending a BGP update to an
external AS.
Intra-confederation EBGP sessions act like EBGP sessions from
a session-establishment perspective, and they act like IBGP
sessions from the BGP attribute-propagation perspective.
BGP v3.26-9
6-63
6-64
Lesson 6
Configuring and Monitoring

Confederations
Overview
performance-enhancing tools such as route reflectors and confederations. Confederations
full-mesh network. Implementing such a network requires knowledge of the steps to properly
migrate and configure BGP confederations and the commands that are used to verify the
operation of the configured network.
This lesson introduces the steps that are required to successfully migrate an existing
autonomous system (AS) to BGP confederations. It also presents the Cisco IOS commands that
are required to configure and monitor confederations.
Objectives
Upon completing this lesson, you will be able to configure proper operation of confederations
to modify IBGP AS-path processing in an existing IBGP network. This ability includes being
Describe the basic design rules that network designers should follow when planning a
transit AS for BGP confederations
Explain how to plan a BGP backbone for a configuration that includes BGP confederations
Explain how to configure BGP confederations on a BGP backbone
Identify the Cisco IOS commands that are required to monitor a BGP backbone that
contains BGP confederations

This topic describes the basic design rules that network designers should follow when planning
a transit AS for BGP confederations.

IBGP full mesh within each member-AS is required.
Route reflectors might be used within each AS to relax the
IBGP full-mesh requirements.
There is no topology limitation on EBGP sessions

between autonomous systems within a
confederation.
The intra-confederation EBGP sessions will follow the
physical topology of the network.
BGP v3.26-3
When designing BGP confederations, keep in mind two basic design rules:
There are no restrictions on intra-confederation EBGP sessions.
A full mesh of IBGP sessions is still needed inside every member-AS.
BGP confederations do not modify Internal Border Gateway Protocol (IBGP) behavior, and,
therefore, the classic IBGP split-horizon rules still apply. As a result, a full mesh of IBGP
sessions between all routers in the member-AS is required. The basic idea of BGP
confederations is to make the member-AS smaller than the original AS so that the full mesh
will not be too complex. Route reflector functionality is also available within a member-AS to
reduce the complexity of IBGP sessions if needed.
In theory, the member autonomous systems may be interconnected by intra-confederation
External Border Gateway Protocol (EBGP) sessions in an arbitrary topology. However, a
structure that is too complicated introduces unnecessary duplication of information. There is no
split-horizon function on EBGP sessions, meaning that in a redundant configuration, where a
BGP update may be forwarded by a router over two different member autonomous systems to
reach a third member-AS, the receiving member-AS will get both copies of the update.
Experience shows that a centralized confederation design leads to the best behavior.
Centralized design means that all member autonomous systems will exchange information with
each other via a central member-AS backbone.
6-66
On the other hand, too few intra-confederation EBGP sessions may introduce single points of
failure. If two member autonomous systems are redundantly connected on the physical level
but have only a single intra-confederation EBGP session between them, a single point of failure
is introduced.
Good network design should never introduce additional single points of failure. If the physical
topology is redundant, then the intra-confederation EBGP sessions should be redundant as well.
In a hierarchical network topology, the network core could serve as a central member-AS
backbone. The more peripheral parts of the network could be divided into several member
autonomous systems that are all connected to the central member-AS.
6-67

This topic explains how to plan a BGP backbone for a configuration that includes BGP
confederations.

Divide the transit AS into smaller areas.
Follow the physical topology of the network.
Define the AS number for each area.

Use AS numbers reserved for private use
(64512 65535).
Verify the Cisco IOS release level.

All routers have to support BGP confederations.
Convert each area into an AS.

A total rewrite of the BGP configuration is required.
BGP v3.26-4
The physical topology of the AS serves as a guide to design the confederation. You should
introduce no additional single points of failure when implementing the confederation. If the
physical topology is redundant, good practice is to have redundant intra-confederation EBGP
sessions. If the physical topology is not redundant, introducing a nonredundant set of sessions
does not add a single point of failurethe network was already nonredundant.
You need to make the following preparations before migrating from a full mesh of IBGP
sessions to a confederation design:
Identify a group of core routers that can serve as a central member-AS.
Identify several groups of more peripheral routers where, within each group, routers are
well connected. Let each group be its own member-AS.
Make a plan for assigning AS numbers (64512 to 65535) to your member-AS. The plan
must uniquely identify each member-AS within the confederation. No member-AS is seen
from outside the confederation, so you do not need to coordinate the plan with any other
AS.
Make sure that no router is lacking support (the correct Cisco IOS release level) for a BGP
confederation. If any router lacks support for this feature, it will break the network.
Remove the original BGP configuration with the original official AS number.
Note
6-68
Support for the BGP confederation feature is included in Cisco IOS software releases from
Release 10.3.

This topic explains how to configure BGP confederations on a BGP backbone. An example of a
BGP confederations configuration is also included in this topic.

Start the BGP process with the member-AS number.
Specify an external AS number.
Must be defined in all routers within confederation
List all member-AS numbers in the confederation.

Must be defined in all routers with an EBGP session
BGP v3.26-5
After you have done the preparation that is necessary to migrate from a full mesh of IBGP
sessions to a confederation design, you need to complete the following configuration steps:
Step 1
Make a new BGP configuration that uses the internal member-AS number according
to the AS number plan for the confederation.
Step 2
Specify the original official AS number as the identifier of the confederation. This
information will be used by egress confederation routers whenever you are
communicating with other external autonomous systems.
Step 3
Specify a list of the member-AS numbers being used. The router uses this
information to distinguish between intra-confederation EBGP behavior and true
EBGP behavior.
Step 4
Configure all the IBGP sessions in the full mesh within the member-AS.
Step 5
Configure intra-confederation EBGP sessions between each member-AS in a way

that introduces no additional single point of failure.
Step 6
Configure true EBGP sessions with external autonomous systems.
Note
Removing the original BGP configuration and creating a new BGP configuration will always
cause interruption in network availability. Migration to BGP confederation has to be a wellplanned process.
6-69
Configuring BGP Confederations (Cont.)

Removes old BGP process and configures BGP process with
member-AS number

Configures external confederation-wide AS number
Defines all the other autonomous systems in the confederation

BGP v3.26-6
router bgp
To configure the BGP routing process, use the router bgp global configuration command.
router bgp as-number
To remove a routing process, use the no form of this command.
no router bgp as-number
Syntax Description
Parameter
Description
Number of an AS that identifies the router to other BGP routers

and tags the routing information that is passed along
Note
The AS number that is specified when you are configuring a BGP process inside a
confederation is the intra-confederation (member) AS number.
bgp confederation identifier

To specify a BGP confederation identifier, use the bgp confederation identifier router
bgp confederation identifier external-as-number
To remove the confederation identifier, use the no form of this command.
no bgp confederation identifier external-as-number
6-70
Syntax Description
Parameter
Description
Public AS number that the confederation is using externally
bgp confederation peers

To configure the autonomous systems that belong to the confederation, use the bgp
confederation peers router configuration command.
bgp confederation peers as-number [as-number]
To remove an AS from the confederation, use the no form of this command.
no bgp confederation peers as-number [as-number ]
Syntax Description
Parameter
Description
AS numbers of member autonomous systems inside the

confederation
This list is used by the router to distinguish an intra-confederation
EBGP session from a real EBGP session with an external AS.
6-71
Example: Configuring BGP Confederations

This example illustrates the use of confederation-related BGP configuration commands.
Configuring BGP ConfederationsSample

Configuration
Note
BGP v3.26-7
The example shows only a portion of the configuration of router 1.0.0.4. The configuration
displayed is not a complete configurationonly those parts that are relevant to BGP
confederations are displayed.
AS 123 is transformed into a BGP confederation. The member-AS 65001 serves as a central
member-AS. Member autonomous systems 65002 and 65003 are connected to AS 65001. From
the outside, the confederation looks like a single AS, still identified by AS number 123.
The internal member-AS number is specified in the router bgp configuration command. This
number is the AS number that will be prepended to the AS-path attribute by the router when
updates are forwarded across intra-confederation EBGP sessions.
The original, official AS number is given as the BGP confederation identifier. This number is
the AS number that will replace the internal member-AS information when egress
confederation routers forward updates across EBGP sessions with external autonomous
systems.
The bgp confederation peers configuration step allows the router to identify the type of
session to be opened with the BGP peers that are configured through the neighbor statement.
Neighbor 1.0.0.3 is in the same member-AS, so its session is an IBGP session. Both neighbor
1.0.0.2 (AS 65002) and 1.0.0.1 (AS 65003) belong to different member autonomous systems
(the AS number appears in the list of BGP confederation peers), so their sessions are intraconfederation EBGP sessions.
Neighbor 2.7.1.1 belongs to AS 222, which is not listed as a member-AS in the bgp
confederation peers command, so its session is a true EBGP session.
6-72

This topic identifies the basic commands that are used to monitor a BGP backbone that you
have configured with BGP confederations.

Displays whether a neighbor is within the confederation

Displays internal and external segments of the
AS-path attribute
Displays whether the path is external, internal, or intraconfederation external
BGP v3.26-8

6-73
Syntax Description
Parameter
Description
Address of a specific neighbor about which you wish to display

information.
Displays all received routes (both accepted and rejected) from

the specified neighbor.
Displays all routes that are received and accepted.

This is a subset of the output from the received-routes keyword.
Displays all the routes that the router has advertised to the
neighbor.
Regular expression that is used to match the paths that are

received.
Displays the dampened routes to the neighbor at the IP address

that is specified.
If the show ip bgp neighbors command is executed on a router without any keywords, the
resulting information that is displayed does not show routes or paths that are received by the
router, but instead shows the status of its neighbor sessions.
show ip bgp
When details are displayed for a specific route entry in the BGP table, the next hop and AS path
are displayed along with information that indicates whether a BGP update was received over an
intra-confederation EBGP session or a regular EBGP session.
Syntax Description
6-74
Parameter
Description
Network number, which is entered to display a particular network

in the BGP routing table
Displays all BGP routes that match the address and mask pair
Displays the network route and its more specific routes
Monitoring Intra-Confederation
EBGP Neighbors
BGP v3.26-9
In the figure, the show ip bgp neighbors command has been executed on a router within a
confederation. As a result, information about the intra-confederation EBGP session is
displayed. The session is an external link (indicating an EBGP session) under common
administration (indicating an intra-confederation EBGP session).
6-75
Monitoring Confederation Routes
BGP v3.26-10
In this example, the show ip bgp command is executed on a router within the confederation to
display information about the class A network 14.0.0.0.
The command response indicates that the router has received information about the network
14.0.0.0 on two different BGP sessions. One of the sessions is an intra-confederation EBGP
session, and the other session is an IBGP session. Both updates have the same next-hop
address, which was set by the true EBGP peer that originally sent the update into the
confederation. The next hop is resolved by recursive routing, and, therefore, the forwarding
decision will be the same regardless of which BGP entries are actually used. The second IP
address is the address of the neighbor, which is followed by the router-ID of that neighbor
(enclosed in parentheses).
The AS path is the same for both entries. It contains a parenthesized number, (65001). This is
the part of the AS path that describes the intra-confederation AS path. The part of the AS path
that follows is the external part, 387. This number reveals that the confederation has a true
EBGP session with the official AS (AS 387), from which an update about network 14.0.0.0 was
received. The update was forwarded to the router using IBGP within member-AS 65001. The
router in the local member-AS on which this command was executed has two different intraconfederation EBGP sessions with member-AS 65001. So, the update about network 14.0.0.0
has entered the local AS via two different paths.
6-76
Summary
Summary
BGP confederations do not modify IBGP behavior; thus, the
classic IBGP split-horizon rules still apply, and a full mesh of
IBGP sessions between all routers in the member AS is still
required.
A proper migration plan is important because the change to
BGP confederation involves a major reconfiguration of BGP
routing.
BGP confederations are configured by specifying the
confederation identifier and other member-AS peers.
The show ip bgp neighbors command has been modified to
display whether a BGP neighbor is part of a BGP
confederation.
BGP v3.26-11
6-77
6-78
Module Summary
Module Summary
Service providers use an IGP to carry internal routes and to
provide optimal routing between POPs, the information that
is needed for IBGP sessions to be established, and the
addresses that are required for BGP next-hop resolution.
Route reflectors enable BGP routing information to be
distributed in a fashion that does not require a physical fully
meshed network.
Route reflector clusters can be built in hierarchies. A router
that is a route reflector in one cluster can act as a client in
another cluster.
BGP v3.26-1

There are only two Cisco IOS commands that are used to
configure route reflectors: bgp cluster-id and neighbor ipaddress route-reflector-client.
BGP confederations are a scalability mechanism that relaxes
the IBGP full-mesh requirements of classic BGP.
BGP confederations are configured by specifying the
confederation identifier and other member-AS peers.
BGP v3.26-2
6-79
This module discussed network scalability concerns that are common in large service provider
networks. The first lesson outlined the service provider network and described the scaling of
IGP and BGP. The next three lessons explained route reflectors specifically, operating them,
the concept of hierarchical route reflectors, and configuring them. The last two lessons
described the operation of confederations and how to configure them.
References
Cisco Systems, Inc. Designing Large-Scale IP Internetworks.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2003.htm.
Cisco Systems, Inc. BGP Case Studies. BGP Case Studies 4
http://www.cisco.com/warp/public/459/bgp-toc.html#routereflectors.
cfbgp.htm#xtocid45.
Traina, Paul. Autonomous System Confederations for BGP.
http://www.ietf.org/rfc/rfc1965.txt?number=1965.
6-80
Module Self-Check
Q1)
Which three characteristics are common to typical service provider networks?

(Choose three.) (Source: Scaling IGP and BGP in Service Provider Networks)
A)
B)
C)
D)
Q2)
What is the typical role of an IGP within a service provider network? (Source: Scaling
IGP and BGP in Service Provider Networks)
A)
B)
C)
D)
Q3)
The IGP carries customer routes for redistribution into BGP at the provider
edge.
The IGP advertises a default route to customers of the service provider.
The IGP resolves next-hop IP addresses.
The IGP carries BGP routes across the provider network.
Why should you avoid the use of private IP addressing in service provider networks?
(Source: Scaling IGP and BGP in Service Provider Networks)
A)
B)
C)
D)
Q4)
The provider network uses two IGPs, one for customer routes and one for
internal provider routes.
Service providers exchange routes with other providers using BGP.
Service providers run IBGP within their network in addition to their IGP
requirements.
Service providers typically use either static routes or EBGP with their
customers.
Private addressing can prevent customer network troubleshooting utilities such

as traceroute from functioning correctly.
Private IP addressing is not allowed on the Internet and will not function in a
service provider network.
Private IP addressing prevents the service provider from properly summarizing
customer routes if it is also using private address space.
Private IP addressing prevents service provider applications such as MPLS
from operating properly in an Internet-supporting environment.
Which three requirements are key to properly scaling BGP in a service provider
environment? (Choose three.) (Source: Scaling IGP and BGP in Service Provider
Networks)
A)
B)
C)
D)
IBGP full-mesh scaling tools to reduce duplicate traffic within the AS

summarization of customer routes to reduce the number of prefixes that are
carried
improvement in BGP convergence time by using the IGP for route propagation
within the provider AS
proper scaling of the AS-wide routing policy to ease administration and
maintenance requirements
6-81
Q5)
Which two of the following statements about the function of BGP policy accounting
are accurate? (Choose two.) (Source: Scaling IGP and BGP in Service Provider
Networks)
A)
B)
C)
D)
Q6)
What is the main problem that is solved by implementing BGP route reflectors?
(Source: Introducing Route Reflectors)
A)
B)
C)
D)
Q7)
C)
D)
B)
C)
D)
All neighbors peer with the route reflector, and a large number of neighbors
can make the route reflector router unstable.
EBGP peers can inject BGP updates into the AS only through the route
reflector.
Route reflectors maintain more routing information, which makes them more
prone to congestion and failure.
Clients can form IBGP relationships only with the route reflector.
What is the main reason for implementing redundant route reflectors with clusters?
A)
B)
C)
D)
6-82
forwards EBGP updates to all peers (IBGP and EBGP)

treats all neighbors as EBGP peers, which eliminates the IBGP mesh
requirements
forwards IBGP updates from clients to other IBGP neighbors
appends the cluster-ID to the AS path, which allows peers to be treated as
EBGP neighbors
Why are redundant route reflectors mandatory in any high-availability network design?
A)
Q9)
the large number of routes that are carried in the IGP when BGP is deployed
the ability of BGP to scale a single AS in a large network
the need for a homogeneous method of applying policies to routes that are
carried through an AS
the ability to support service-level parameters with greater ease
How does a route reflector modify the IBGP split-horizon rule? (Source: Introducing
Route Reflectors)
A)
B)
Q8)
BGP policy accounting is enabled on an output interface.

BGP policy accounting using AS numbers can be used to improve the design
of network circuit peering and transit agreements between ISPs.
In BGP policy accounting, counters based on parameters such as communitylist, AS number, or AS path are assigned to identify the IP traffic.
A Cisco IOS policy-based classifier maps the traffic into one of five possible
buckets, representing different traffic classes.
to eliminate routing loops in redundant configurations

to limit the number of neighbor sessions with each route reflector
to provide another scalability mechanism targeted at removing the IBGP fullmesh requirement
to enhance security within the AS
Q10)
How does the originator-ID attribute assist in the elimination of routing loops that are
caused by redundant route reflector designs? (Source: Introducing Route Reflectors)
A)
B)
C)
D)
Q11)
What can occur if a client has IBGP neighbor relationships with other routers that are
not configured as route reflectors? (Source: Designing Networks with Route
Reflectors)
A)
B)
C)
D)
Q12)
D)
This is an invalid configuration.

The client might not receive all BGP routes.
EBGP routes that are received by the client will not be distributed properly
throughout the AS.
Duplicate routing traffic will be sent to the client.
Which problem are hierarchical route reflectors designed to solve? (Source: Designing
Networks with Route Reflectors)
A)
B)
C)
D)
Q14)
This is an invalid configuration.

The client will notify the route reflector and be promoted to a route reflector as
well.
Routing black holes can occur and cause lost traffic inside the AS.
Unnecessary routing traffic will be generated.
Which potential problem can occur if a client does not have an IBGP session with all
route reflectors in a cluster? (Source: Designing Networks with Route Reflectors)
A)
B)
C)
Q13)
If the originator-ID matches the router-ID of the reflector, local preference is

set on the route to make it a backup.
The originator-ID attribute is set to the cluster-ID to ensure that a route
traverses the AS only one time.
A router that receives a route in which the originator-ID matches its router-ID
will ignore that route.
The originator-ID allows the router to know if the route originated locally or
from an external source so that administrative distance rules for the route can
be verified.
lack of a consistent application of security and routing policies throughout the

AS
scalability of autonomous systems in very large routing domains
routing loops caused by redundant cluster configurations
administrative overhead when you are implementing router reflector network
designs
Which two BGP parameters do you have to configure on a route reflector?

(Choose two.) (Source: Configuring and Monitoring Route Reflectors)
A)
B)
C)
D)
cluster-ID
originator-ID
cluster-list
route reflector clients
6-83
Q15)
What are three migration steps that are required to convert from a fully meshed IBGP
AS to an AS that is based on route reflectors? (Choose three.) (Source: Configuring and
Monitoring Route Reflectors)
A)
B)
C)
D)
Q16)
Which command should you use to identify route reflector clients without inspecting
the router configuration? (Source: Configuring and Monitoring Route Reflectors)
A)
B)
C)
D)
Q17)
D)
to all EBGP neighbor sessions

inside each member AS
between the member autonomous systems in the confederation
no longer applies when confederations are used in an AS
How does an IBGP router that receives the AS-path attribute in a BGP update
determine whether the route has crossed a member-AS within a confederation?
(Source: Introducing Confederations)
A)
B)
C)
D)
6-84
the large number of routes that are carried in the IGP when BGP is deployed
the ability for BGP to scale a single AS in a large network
the need for a homogeneous method of applying policies to routes that are
carried through an AS
the ability to support service level parameters with greater ease
Although confederations eliminate the need for a fully meshed topology within the AS,
where does the BGP full-mesh requirement still apply? (Source: Introducing
Confederations)
A)
B)
C)
D)
Q19)
show ip bgp prefix

show ip bgp clients
show ip bgp summary
What is the main problem that is solved by implementing BGP confederations?

A)
B)
C)
Q18)
remove unnecessary IBGP sessions

configure the clients on the route reflectors
configure IBGP sessions between route reflector clients
configure the cluster-ID on the route reflectors
The router can determine this fact by the presence of the confederation bit in
the flag field of the BGP update.
The router can determine this fact because the AS-path attribute will contain
only the AS number of the ingress EBGP peer.
The member-AS numbers will be indicated by the presence of parentheses
surrounding the AS number entry.
The IBGP router cannot determine whether the route has crossed a member-AS
because the AS number of each AS boundary that has been crossed is
appended to the AS-path attribute.
Q20)
How does an EBGP router that receives the AS-path attribute in a BGP update
determine whether the route has crossed a member-AS within a confederation?
A)
B)
C)
D)
Q21)
Why is it impossible for a router that does not support BGP confederations to operate
inside an AS that is configured as a confederation? (Source: Introducing
Confederations)
A)
B)
C)
D)
Q22)
The router will believe that the AS path is longer than the actual AS path and
route incorrectly.
The router will be unable to interpret the AS-path attribute and terminate its
BGP session with a peer.
The router will automatically convert the intra-confederation AS numbers to
the external AS number of the confederation, causing an AS number mismatch.
The router will process BGP updates as normal because it has to be aware only
of the member-AS to which it belongs, causing incorrect routing information to
propagate through the AS.
Which three IBGP properties are retained within the confederation even though EBGP
sessions between member autonomous systems are formed? (Choose three.) (Source:
Introducing Confederations)
A)
B)
C)
D)
Q23)
The router can determine this fact by the presence of the confederation bit in
the flag field of the BGP update.
The router can determine this fact because the AS-path attribute will contain
only the AS number of the ingress EBGP peer.
The member-AS numbers will be indicated by the presence of parentheses
surrounding the AS number entry.
The EBGP router cannot determine whether the route has crossed a memberAS because the member-AS entries are removed from the AS path prior to
exiting the confederation.
local preference
MED
weight
next-hop
How can you reduce the IBGP full mesh within a confederation AS? (Source:
Configuring and Monitoring Confederations)
A)
B)
C)
D)
You cannot reduce the full mesh because all IBGP peers must be fully meshed
within the member-AS.
Implementing router reflectors inside a member-AS can reduce the IBGP fullmesh requirement.
You can nest a confederation within a confederation to remove the IBGP fullmesh requirement.
Because confederations are used, there is no requirement for an IBGP full
mesh within each member-AS.
6-85
Q24)
Which two BGP parameters do you need to specify on every router within a
confederation? (Choose two.) (Source: Configuring and Monitoring Confederations)
A)
B)
C)
D)
Q25)
What does the BGP confederation identifier define? (Source: Configuring and
Monitoring Confederations)
A)
B)
C)
D)
Q26)
the AS number of the confederation external peer

the public AS number that the confederation is using externally
the AS number of the member-AS
the MD5 authentication password for the confederation
How will the show ip bgp command display the intra-confederation segment of the AS
path? (Source: Configuring and Monitoring Confederations)
A)
B)
C)
D)
6-86
a list of all AS numbers in the confederation

a list of all true EBGP sessions
the official AS number (as the identifier of the confederation)
the correct MD5 authentication password in each peer
as a regular entry in the AS-path attribute

as a separate AS-path list independent of the AS-path attribute
as an entry in the AS path enclosed by parentheses
not displayed because it is not a part of the EBGP AS path

Q1)
B, C, D
Q2)
Q3)
Q4)
A, B, D
Q5)
B, C
Q6)
Q7)
Q8)
Q9)
Q10)
Q11)
Q12)
Q13)
Q14)
A, D
Q15)
A, B, D
Q16)
Q17)
Q18)
Q19)
Q20)
Q21)
Q22)
A, B, D
Q23)
Q24)
A, C
Q25)
Q26)
6-87
6-88
Module 7

Overview
The Border Gateway Protocol (BGP) is designed for reliability and scalability. As such, it has
become the de facto standard protocol that is used to carry the more than 110,000 prefixes in
the Internet today. Likewise, BGP has a tremendous amount of flexibility with regard to
administrative policy controls, route selection, performance tuning, and scalability features.
This module introduces advanced BGP configuration tools that are designed to improve BGP
scalability and performance. Tools that are discussed in this module include convergence time
reduction features, limiting the number of prefixes, peer groups, and route dampening.
Module Objectives
Upon completing this module, you will be able to use available BGP tools and features to
optimize the scalability of the BGP routing protocol in a typical BGP network. This ability
Configure Cisco IOS performance improvements to reduce BGP convergence time
Configure BGP to limit the number of prefixes that are received from a neighbor
Use BGP peer groups to share common configuration parameters between multiple BGP
peers
Use route dampening to minimize the impact of unstable routes
7-2
Lesson 1

Overview
As the number of routes in the Internet increases, demands on router CPU and memory
resources will increase. Border Gateway Protocol (BGP) processing affects both router
resources and network convergence time. It is important that network convergence be as fast as
possible to ensure accurate routing information between domains. It is also important that
router resources be optimized whenever possible. Cisco IOS performance improvements for
BGP are designed to aid network administrators in achieving these goals.
This lesson introduces various Cisco IOS performance improvements that have been designed
to reduce BGP convergence time. Included in this lesson are discussions of convergence, BGP
routing processes, and the effects of BGP routing processes on router CPU resources. The
lesson also discusses the commands that are required to configure and monitor BGP for various
Cisco IOS performance improvements in the areas of path maximum transmission unit (PMTU)
discovery, input hold queue, BGP scan time, and BGP advertisement interval.
Objectives
Upon completing this lesson, you will be able to configure Cisco IOS performance
improvements to reduce BGP convergence time. This ability includes being able to meet these
objectives:
Describe convergence in BGP networks
Describe the BGP router processes and their functions
Describe the effects of BGP processes on router CPU resources
Identify Cisco IOS performance improvements to reduce BGP convergence time
Identify the Cisco IOS commands required to configure and monitor PMTU discovery
Identify the Cisco IOS commands required to configure and monitor the input queue depth
on a router interface
Identify the Cisco IOS commands required to configure and monitor BGP scan time
Identify the Cisco IOS commands required to configure and monitor the BGP
advertisement interval
Describe the function of the BGP Nonstop Forwarding Awareness feature
BGP Convergence
This topic describes the concept of convergence in BGP networks.
BGP Convergence
As the number of routes in the Internet routing table grows,
the time it takes for BGP to converge increases.
The Internet currently contains more than 110,000 prefixes.
Network convergence times can range from 10 minutes to
more than one hour.
BGP is considered converged when:
All routes have been accepted.
All routes have been installed in the routing table.
The table version for all peers equals the table version of the
BGP table.
The input queue and output queue for all peers is 0.
BGP v3.27-3
As the number of routes in the Internet routing table grows, service providers and large
enterprise customers are experiencing a dramatic increase in the amount of time that BGP takes
to converge. Networks that once converged in 10 or 15 minutes may now take up to an hour in
some cases, and even longer in extreme situations. In general, convergence is defined as the
process of bringing all routing tables to a state of consistency. The BGP routing protocol is
considered converged when the following conditions are true:
All routes have been installed in the routing table.
The table version for all peers equals the table version of the BGP table.
Convergence time is an important consideration in a network, because nonconverged networks
can cause routing loops, packet delays, and even packet loss as a result of black holes.
7-4
BGP Processes
This topic describes the different BGP router processes and their functions.
BGP Processes
Process
Description
Interval
BGP open
Performs BGP peer establishment.
At initialization, when
establishing a TCP
connection with a BGP
peer
BGP I/O
Handles queuing and processing of BGP

packets (updates and keepalives).
As BGP control
packets are received
BGP scanner
Walks the BGP table and confirms reachability

of the next hops. BGP scanner also checks
conditional advertisement to determine
whether or not BGP should advertise
condition prefixes. Performs route dampening.
Every 60 seconds
BGP router
Calculates the best BGP path and processes

any route changes. It also sends and receives
routes, establishes peers, and interacts with
the routing information base (RIB).
Once per second and

when adding,
removing, or softreconfiguring a BGP
peer
BGP scanner and BGP router are responsible for a large number of calculations
and can lead to high CPU utilization.
BGP v3.27-4
In general, a Cisco IOS process consists of the individual threads and associated data that
perform router tasks, such as system maintenance, packet switching, and implementing routing
protocols.
Note
A thread is an information placeholder that allows a single process to be halted (interrupted)

on the router so that the CPU can service another process. The information that is contained
within the thread allows the interrupted process to restart exactly where it left off when the
CPU is ready to continue to service that process thread.
Several Cisco IOS processes that are executed on the router enable BGP to run. You can use
the show process cpu | include BGP command to see the volume of CPU resources that are
consumed (utilization) because of running BGP processes.
The figure lists the function of each of the BGP router processes and how often each process is
executed on the router. It shows that each process runs at different times, depending on the
tasks that are handled by the specific process. Because BGP scanner and BGP router are
responsible for a large number of calculations, you may notice high CPU utilization during the
running of either one of these processes.
7-5

This topic describes how running BGP router processes affects router CPU resources.

BGP scanner process
High CPU utilization stemming from the BGP scanner
process can be expected for short durations on a router
carrying a large Internet routing table.
While the BGP scanner runs, low-priority processes need
to wait a longer time to access the CPU.
BGP router process

The BGP router process runs about once per second to
check for work.
The BGP router consumes all free CPU cycles.
BGP v3.27-5
On routers that carry a large Internet routing table, high CPU utilization stemming from the
BGP scanner process can be expected for short periods of time. Once per minute, the BGP
scanner walks (scans) the BGP routing table and performs important maintenance tasks.
These tasks include checking the next hop that is referenced in the BGP table of the router and
verifying that the next-hop devices can be reached. Thus, a large BGP table takes an equally
large amount of time to be walked and validated.
The BGP scanner walks the BGP routing table to update any data structures and walks the table
for route redistribution purposes. In this context, the routing table is also known as the routing
information base (RIB), which the router outputs when the show ip route command is
executed. Both tables are stored separately in the router memory and can be very large, thus
consuming CPU and memory resources.
Because the BGP scanner runs through the entire BGP table, the duration of the high CPU
utilization condition that is caused by the BGP scanner process varies with the number of
neighbors and the number of routes that are learned per neighbor.
While the BGP scanner runs, low-priority processes need to wait a longer time to access the
CPU. One low-priority process controls Internet Control Message Protocol (ICMP) packets
such as pings. Packets that are destined to or have originated from the router may experience
higher than expected latency because the ICMP process must wait behind the BGP scanner.
The BGP scanner process runs for some time, is suspended, then ICMP runs, ICMP is
suspended, the BGP scanner runs, and so on. In contrast, pings sent through a router should be
switched via Cisco Express Forwarding (CEF) and should not experience any additional
latency. When you are troubleshooting periodic spikes in latency, compare forwarding times
for packets that are forwarded through a router versus packets that are processed directly by the
CPU on the router.
7-6
The BGP router process runs about once per second to check for work. BGP convergence
defines the duration between the time when the first BGP peer is established and the point at
which BGP is converged. To ensure the shortest possible convergence times, the BGP router
consumes all free CPU cycles. However, after it starts, it relinquishes (or suspends) the CPU
intermittently.
Example: CPU Effects of BGP Processes

Convergence time is a direct measurement of how long the BGP router process runs on the
CPU, not the total time that the process is actually running. This example investigates the high
CPU utilization condition during BGP convergence as BGP exchanges prefixes with two
External Border Gateway Protocol (EBGP) peers.
Step 1
Capture a baseline for normal CPU utilization before starting the test.

Step 2
After the test starts, the CPU reaches 100 percent utilization. The show process cpu
command shows that the high CPU condition is caused by the BGP router, denoted
by 139 (the Cisco IOS process ID for the BGP router) in the following output:

Step 3
Monitor the router by capturing multiple outputs of the show ip bgp summary and
show process cpu commands during the event. The show ip bgp summary
command captures the state of the BGP neighbors.
Step 4
When the router completes prefix exchange with its BGP peers, the CPU utilization
rates should return to normal levels. The computed 1-minute and 5-minute averages
will settle back down as well but may show higher than normal levels for a longer
period than the 5-second rate.

Step 5
Using the output from the show commands will allow you to compute the BGP
convergence time. In particular, the Up/Down column of the show ip bgp summary
command is compared to the start and stop times of the high CPU utilization
condition. Typically, BGP convergence can take several minutes when routers
exchange a large Internet routing table.
7-7

This topic identifies Cisco IOS performance improvements that reduce BGP convergence
times.

You can reduce BGP convergence time and high CPU utilization
caused by BGP processes in the following ways:
Queuing to TCP peer connections
BGP now automatically queues data aggressively from the BGP
output queue to the TCP socket for each peer
Deploying BGP peer groups

Simplifies BGP configuration and enhances BGP scalability
Enabling the path MTU feature

Improves efficiency by dynamically determining the largest MTU that
you can use without creating packets that need to be fragmented
Increasing interface input queues

Improves convergence by reducing dropped TCP ACKs
BGP v3.27-6
BGP convergence can often be an issue in networks requiring quick propagation of routing
information. Cisco IOS software provides the following performance-improvement features,
which have been designed to reduce BGP convergence time and the high CPU utilization that is
caused by a running BGP process:
Queuing to TCP peer connections: Instead of queuing data once per second, BGP now
queues data aggressively from the BGP output queue to the TCP socket for each peer until
the output queues have drained completely. Because BGP now sends at a faster rate, it
converges more quickly.
BGP peer groups: The major benefit of specifying a BGP peer group is that it reduces the
volume of system resources (CPU and memory) that are used in BGP update generation.
Peer groups also simplify BGP configuration because many repetitive configuration
elements (such as filters) are applied by the router only once (to the peer group) instead of
applying them to each neighbor.
Because peer groups allow the routing table to be checked only once and allow updates to
be replicated to all other in-sync peer group members (depending on the number of peer
group members, the number of prefixes in the table, and the number of prefixes that are
advertised), they can significantly reduce router resource requirements.
7-8
PMTU feature: All TCP sessions are bounded by a limit on the number of bytes that a
single packet can transport. This limit, known as the Maximum Segment Size (MSS), is
536 bytes by default. In other words, TCP breaks up packets in a transmit queue into 536byte chunks before passing packets down to the IP layer. The advantage of a 536-byte MSS
is that packets are not likely to be fragmented at an IP device along the path to the
destination, because most links use an MTU of at least 1500 bytes. The disadvantage is that
smaller packets increase the amount of bandwidth that is used for transport overhead.
Because BGP builds a TCP connection to all peers, a 536-byte MSS affects BGP
convergence times. The solution is to enable the PMTU feature by means of the ip tcp
path-mtu-discovery command. You can use this feature to dynamically determine how
large the MSS value can be without creating packets that need to be fragmented. PMTU
allows TCP to determine the smallest MTU size among all links in a TCP session. TCP
then uses this MTU value, minus room for the IP and TCP headers, as the MSS for the
session.
Increase interface input queues: If BGP is advertising thousands of routes to many
neighbors, TCP must transmit thousands of packets. BGP peers receive these packets and
send TCP acknowledgments (ACKs) to the advertising BGP speaker, causing the BGP
speaker to receive a flood of TCP ACKs in a short period of time. If the ACKs arrive at a
rate that is too high for the router CPU, packets back up in inbound interface queues.
By default, router interfaces use an input queue size of 75 packets. In addition, special
control packets such as BGP updates use a special queue with Selective Packet Discard
(SPD). This special queue holds 100 packets. During BGP convergence, TCP ACKs can
quickly fill the 175 spots of input buffering, causing newly arriving packets to be dropped.
On routers with 15 or more BGP peers that also exchange the full Internet routing table,
more than 10,000 drops per interface per minute may be seen. Increasing the interface input
queue depth using the hold-queue in command helps reduce the number of dropped TCP
ACKs, reducing the amount of work that BGP must do to converge.
7-9
Improving BGP Convergence (Cont.)

BGP convergence can also be improved to some
extent by:
Configuring a smaller interval for the BGP scanner process
(scan time)
Configuring a smaller advertisement interval between BGP
neighbors
Limitation:
Not recommended in routers dealing with large BGP tables
Could lead to CPU or memory exhaustion
BGP v3.27-7
Network administrators also need to improve BGP convergence in certain scenarios; for
example, in networks using the conditional advertisement feature. There are two additional
BGP parameters that they can use to influence BGP convergence speed:
Scan time: Controlling the BGP scanner process, responsible for verifying information in
the BGP table
Advertisement interval: Controlling the rate at which successive advertisements are sent
to a BGP neighbor
Network administrators must take care when configuring these two parameters. Setting the
values too low for a specific network environment could lead to a significant consumption of
router resources. The larger the BGP tables and the more unstable the BGP network, the greater
the danger of exhausting the resources of a router.
7-10
PMTU Discovery
This topic identifies the Cisco IOS commands that are required to configure and monitor
PMTU discovery.
PMTU Discovery
This command enables the PMTU discovery feature for all new
TCP connections from the router.
The age timer is a time interval for how often TCP re-estimates
the path MTU with a larger MSS (default age timer is 10
minutes).
This feature is described in RFC 1191.
BGP v3.27-8
PMTU discovery is a method for maximizing the use of available bandwidth in the network
between the endpoints of a TCP connection. It is described in RFC 1191. Existing connections
are not affected when this feature is turned on or off.
Customers using TCP connections to move bulk data between systems on distinct subnets
would benefit most by enabling this feature.
The age timer is a time interval for how often TCP re-estimates the PMTU with a larger MSS.
The default value of the age timer is 10 minutes, but it can be manually configured up to 30
minutes or disabled (set to infinite). If the MSS that is used for the connection is smaller than
the peer connection can handle, the router will attempt to use a larger MSS each time that the
age timer expires. The discovery process is stopped when either the sent MSS is as large as the
peer negotiated or the user has disabled the timer on the router. You can turn off the age timer
by setting it to infinite.
ip tcp path-mtu-discovery
To enable the PMTU discovery feature for all new TCP connections from the router, use the ip
tcp path-mtu-discovery global configuration command.
ip tcp path-mtu-discovery [age-timer {minutes | infinite}]
To disable the function, use the no form of this command.
no ip tcp path-mtu-discovery [age-timer {minutes | infinite}]
7-11
Syntax Description
Parameter
Description
(Optional) Time interval (in minutes) after which TCP re-estimates

the PMTU with a larger MSS.
The maximum interval is 30 minutes; the default is 10 minutes.
7-12
(Optional) Turns off the age timer.
Monitoring PMTU Discovery
The default MSS is 536 bytes.
After enabling of the PMTU discovery feature, the MSS has

been increased.
BGP v3.27-9
By default, the MSS is 536 bytes. As shown in the figure, the show ip bgp neighbors | include
max data command can be used to verify the size of the MSS before the PMTU discovery
feature is enabled on the router.
After using the ip tcp path-mtu-discovery command to enable PMTU discovery, the router
dynamically determines how large the MSS can be without creating IP packets that require
fragmentation. At the bottom of figure, the output shows that the PMTU feature has been
enabled and the show ip bgp neighbors | include max data command has been used to
determine that the PMTU discovery feature has set the MSS to 1460 bytes.
7-13

This topic identifies the Cisco IOS commands that are required to configure and monitor the
input queue depth on a router interface.
This command limits the size of the IP queue on an interface.

The default input hold-queue limit is 75 packets, configurable
from 0 to 65,535 packets.
A length of 1000 will normally resolve problems caused by input
queue drops of TCP ACKs.
BGP v3.27-10
Each interface owns an input queue into which incoming packets are placed to await processing
by the router. Frequently, the rate at which incoming packets are placed in the input queue
exceeds the rate at which the router can process the packets. Each input queue has a size that
indicates the maximum number of packets that can be placed in the queue. After the input
queue becomes full, the interface drops any new incoming packets.
hold-queue
To specify the size of the IP input or output queue on an interface, use the hold-queue
command in interface configuration mode.
hold-queue length {in | out}
To restore the default values for an interface, use the no form of this command with the
appropriate keyword.
no hold-queue length {in | out}
7-14
Syntax Description
Parameter
Description
Integer that specifies the maximum number of packets in the

queue.
The range of allowed values is 0 to 65535.
Specifies the input queue.

The default is 75 packets. For asynchronous interfaces, the
default is 10 packets. These limits prevent a malfunctioning
interface from consuming an excessive amount of memory.
Specifies the output queue.

The default is 40 packets. For asynchronous interfaces, the
default is 10 packets. These limits prevent a malfunctioning
interface from consuming an excessive amount of memory.
Caution
Increasing the hold queue can have detrimental effects on network routing and response
times. For protocols that use SEQ or ACK packets to determine round-trip times, do not
increase the output queue. Dropping packets instead informs hosts to slow down
transmissions to match available bandwidth. This approach is generally better than having
duplicate copies of the same packet within the network (which can happen with large hold
queues).
Note
The Cisco 12000 Series now uses a default SPD headroom value of 1000. It retains the
default input queue size of 75. Use the show spd command to view these special input
queues.
7-15
Monitoring Input Queue Depth
BGP v3.27-11
In the figure, the show interface {interface-identifier} command displays the current input
queue levels and the number of incoming packets dropped.
The input queue x/y counter displays the current number of packets in the input queue x and the
current size of the input queue y. The drops counter indicates the number of incoming packets
that have been dropped.
If the current number of packets in the input queue is consistently at or greater than 80 percent
of the current size of the input queue, the size of the input queue may require tuning to
accommodate the rate of incoming packets. Even if the current number of packets in the input
queue never seems to approach the size of the input queue, bursts of packets may still be
overflowing the queue. If the drops counter is increasing at a high rate, the size of the input
queue may require tuning to accommodate the bursts.
7-16
BGP Scan Time

This topic identifies the Cisco IOS commands that are required to configure and monitor BGP
scan time.
BGP Scan Time

This command changes the default value of BGP scanner
process runs (default = 60 seconds).
The BGP scanner walks the BGP table and confirms the
reachability of next hops.
The BGP scanner process is also responsible for advanced
features such as conditional advertisement check and
performing route dampening.
BGP v3.27-12
Network administrators use the bgp scan-time command to configure the time interval for
repetitions of the BGP scanner process.
The BGP scanner process walks (scans) the BGP table and confirms the reachability of next
hops. A change of this status triggers a new BGP route selection for the network. Changes are
then propagated by the router to established BGP neighbors. Increasing the BGP scanner
process frequency will make the router find a changed status more quickly, but it will also
consume more CPU resources.
The BGP scanner process is also responsible for some advanced BGP features. It checks the
conditional advertisement to determine whether or not BGP should advertise conditional
prefixes or perform route dampening.
bgp scan-time
To configure a nondefault value of the scanning interval for BGP routing information, use the
bgp scan-time command.
bgp scan-time [import] scanner-interval
To disable the scanning interval of a router, use the no form of this command.
no bgp scan-time
7-17
Syntax Description
Parameter
Description
(Optional) Configures import processing of Virtual Private

Network version 4 (VPNv4) unicast routing information from BGP
routers into routing tables.
Specifies the scanning interval of BGP routing information.

Valid values that are used for selecting the desired scanning
interval are from 5 to 60 seconds. By default, the scanning
interval is 60 seconds.
7-18
Monitoring BGP Scan Time
Scan interval is defined per BGP router process and address

family
Checked with show ip bgp summary command
BGP v3.27-13
You can check the configured BGP scan interval using the show ip bgp summary command.
The configured BGP scan interval will apply to the entire BGP routing protocol process.
7-19

This topic identifies the Cisco IOS commands that are required to configure and monitor the
BGP advertisement interval.
This command changes the default time interval in the sending

of BGP routing updates for a specific neighbor:
If lowered, can improve convergence
Can consume considerable resources in a jittery
network if the value is set too low
Default values:
30 seconds for EBGP neighbors
5 seconds for IBGP neighbors
BGP v3.27-14
With the help of the neighbor advertisement-interval command, network administrators can
modify the default advertisement interval for a specific BGP peer. BGP advertisements are
rate-limited by the router that is using the advertisement interval timer (defined as the
parameter MinRouteAdvertisementInterval in RFC 1771). When a BGP-speaking router sends
a route update to a neighbor for a specific destination, it is not allowed to send another update
to the neighbor about the same destination until a period of time equal to the advertisement
interval has elapsed. In that way, the advertisement interval timer acts as a form of rate limiting
on a per-destination basis, even though the value of the advertisement interval is configured for
each neighbor.
It is important to note that during the time that the router is waiting for the advertisement
interval timer to expire, the router can still receive and process route updates from BGP
neighbors. Using the neighbor advertisement-interval command does not rate-limit BGP
route selection (inbound updates and subsequent processing) but only the rate of outgoing route
advertisements.
When faster propagation of successive BGP updates (which are batched and rate-limited) is
required, the network administrator can lower the default value of the advertisement interval,
thus improving convergence.
In routers that handle large BGP tables and less stable networks, lowering the advertisement
interval could potentially lead to consuming large portions of router resources.
7-20
neighbor advertisement-interval
To set the minimum interval in the sending of BGP routing updates, use the neighbor
advertisement-interval router configuration command.
neighbor {ip-address | peer-group-name} advertisement-interval seconds
no neighbor {ip-address | peer-group-name} advertisement-interval seconds
Syntax Description
Parameter
Description
Neighbor IP address.

If a BGP peer group is specified by using the peer-group-name
argument, all members of the peer group will inherit the
characteristic that is configured with this command.
Time in seconds.
Integer from 0 to 600.
The default is 30 seconds for external peers and 5 seconds for
internal peers.
7-21
Monitoring the BGP Advertisement Interval
Defined per BGP neighbor and address family

Manually configured minimum value stated under address family
output of show ip bgp neighbors command
BGP v3.27-15
You can examine the currently configured BGP advertisement interval with the show ip bgp
neighbors command. The advertisement interval is defined for a specific neighbor in a specific
BGP address family. Actual values of the advertisement interval are therefore stated under the
specific address-family portion of the neighbor output. The default timer for EBGP is 30
seconds. After the parameter was changed in the example shown in the figure, the timer
switched to 15 seconds.
7-22
BGP Nonstop Forwarding Awareness

This topic describes the function of the BGP Nonstop Forwarding Awareness feature.
NSF Awareness
Allows an NSF-aware router to assist NSF-capable and NSFaware neighbors to continue forwarding packets during a
switchover operation or during a well-known failure condition
Minimizes the effects of the following:
Well-known failure conditions (for example, a stuck-inactive event)
Unexpected events (for example, an RP switchover
operation)
Scheduled events (for example, a hitless software
upgrade)
BGP v3.27-16
Cisco Nonstop Forwarding (NSF) awareness allows an NSF-aware router to assist NSF-capable
and NSF-aware neighbors to continue forwarding packets during a switchover operation or
during a well-known failure condition. The Enhanced Interior Gateway Routing Protocol
(EIGRP) Nonstop Forwarding Awareness feature allows an NSF-aware router that is running
EIGRP to forward packets along routes that are already known for a router that is performing a
switchover operation or is in a well-known failure mode. This capability allows the EIGRP
peers of the failing router to retain the routing information that is advertised by the failing
router and continue to use this information until the failed router has returned to normal
operating behavior and is able to exchange routing information. The peering session is
maintained throughout the entire NSF operation.
The deployment of EIGRP NSF awareness can minimize the effects of the following:
Well-known failure conditions (for example, a stuck-in-active event)
Unexpected events (for example, a route processor [RP] switchover operation)
Scheduled events (for example, a hitless software upgrade)
EIGRP NSF awareness is enabled by default, and its operation is transparent to the network
operator and EIGRP peers that do not support NSF capabilities.
NSF-aware routers are completely compatible with non-NSF-aware or -capable neighbors in an
EIGRP network. A non-NSF-aware neighbor will ignore NSF capabilities and reset the
adjacency when they are received.
7-23
The NSF-capable router will drop any queries that are received while converging to minimize
the number of transient routes that are sent to neighbors. But the NSF-capable router will still
acknowledge these queries to prevent these neighbors from resetting adjacency.
Note
An NSF-aware router must be up and completely converged with the network before it can
assist an NSF-capable router in an NSF restart operation.
The route-hold timer sets the maximum period of time that the NSF-aware router will hold
known routes for an NSF-capable neighbor during a switchover operation or a well-known
failure condition. The route-hold timer is configurable so that you can tune network
performance and avoid undesired effects, such as black holing routes if the switchover
operation takes too much time. When this timer expires, the NSF-aware router scans the
topology table and discards any stale routes, allowing EIGRP peers to find alternate routes
instead of waiting during a long switchover operation.
7-24
timers nsf route-hold

To set the route-hold timer to determine how long an NSF-aware router that is running EIGRP
will hold routes for an inactive peer, use the timers nsf route-hold command in router
configuration mode.
timers nsf route-hold seconds
To return the route-hold timer to the default value, use the no form of this command.
no timers nsf route-hold
Syntax Description
Parameter
Description
The time, in seconds, that EIGRP will hold routes for an inactive
peer.
The configurable time range is from 20 to 300 seconds.
7-25
Summary
Summary
Convergence is defined as the process of bringing all route tables
to a consistent state.
Several Cisco IOS processes (including BGP open, I/O, scanner,
and router) that are executed on the router enable BGP to run.
The BGP scanner and BGP router processes can significantly
impact the CPU utilization of the router, causing some low-priority
processes to suffer increased processing delays.
You can reduce BGP convergence time and high CPU utilization
caused by BGP processes in the following ways: queuing to TCP
peer connections, deploying BGP peer groups, enabling the PMTU
feature, and increasing interface input queues.
The PMTU discovery feature, implemented through the ip tcp pathmtu-discovery global configuration command, finds the largest packet
that can be sent to a destination without requiring IP fragmentation,
minimizing packet overhead.
BGP v3.27-17
Summary (Cont.)
Increasing the input queue depth is a technique that can
eliminate dropped TCP ACKs, resulting in improved BGP
convergence. To specify the size of the IP input or output
queue on an interface, use the hold-queue command.
Reducing the time between runs of the BGP scanner process
(using the bgp scan-time command to configure the time
interval for repetitions of the BGP scanner process) improves
BGP convergence at the cost of increased CPU resource
consumption.
With the help of the neighbor advertisement-interval command,
you can reduce the advertisement interval, causing BGP
updates to be sent to neighbors more quickly and resulting
in improved BGP convergence time.
NSF awareness allows an NSF-aware router to assist NSFcapable and NSF-aware neighbors to continue forwarding
packets during a switchover operation or during a wellknown failure condition.
7-26
BGP v3.27-18
Lesson 2
Limiting the Number of

Prefixes Received from a BGP
Neighbor
Overview
There are currently more than 110,000 prefixes on the Internet. There are many circumstances
in which network administrators do not need or desire their routers to carry full Internet
routing. Furthermore, there is a need to provide protective controls on customer-facing routers
to ensure that a configuration error does not cause the accidental advertisement of prefixes from
autonomous systems that did not originate them.
Border Gateway Protocol (BGP) is designed for reliability and scalability. As such, it has a
tremendous amount of flexibility regarding administrative policy controls, route selection, and
performance tuning and scalability features. This lesson introduces an advanced BGP
configuration tool that has been designed to improve BGP scalability and performance by
reducing the number of prefixes that a router receives from a BGP neighbor. Also discussed in
this lesson is the need for prefix limiting and how to configure and monitor the maximumprefix function.
Objectives
Upon completing this lesson, you will be able to configure BGP to limit the number of prefixes
that are received from a neighbor. This ability includes being able to meet these objectives:
Describe the need for limiting the number of routes that are received from a BGP neighbor
Identify the Cisco IOS command that is required to configure the BGP maximum-prefix
function
Identify the Cisco IOS command that is required to monitor the BGP maximum-prefix
function
Limiting the Number of Routes Received from a

Neighbor
This topic describes the need for limiting the number of routes (prefixes) that are received from
a BGP neighbor.
Limiting the Number of Routes Received

from a Neighbor
Definition of problem:
All other filtering mechanisms specify only what you are
willing to accept but not how much.
A misconfigured BGP neighbor can send a huge number of
prefixes that can exhaust the memory of a router or overload
the CPU (several Internet-wide incidents have already
occurred).
A new tool is needed to establish a hard limit on the number
of prefixes received from a neighbor.
BGP v3.27-3
Incoming filters and route-maps indicate the BGP attribute values that a route should have to be
accepted. Route filters can be applied that match routes based on the network number or the
BGP attributes that are attached to a route. The most commonly applied filter is one that
matches the contents of the autonomous system (AS)-path attribute.
An Internet service provider (ISP) with a multihomed customer may use filters to ensure that
the routes that are received from the customer originate within the AS of the customer. Using
an AS-path access-list is one method of achieving this goal.
An improperly configured filter in a customer router may accidentally cause a large number of
Internet routes to be received by the customer. Even worse, a faulty configuration may cause
prefixes to be advertised by the customer as though the routes originated inside the customer
AS. This situation would result in a BGP table in the ISP router that lists many of the possible
destination networks on the Internet as reachable in the customer AS (with the AS path
containing only a single entry, the customer AS). The BGP route selection in the ISP network
would select those routes as the best (based on the AS-path length) and direct much of the
provider traffic intended for the Internet to the customer network.
An AS-path filter in the ISP router would not prevent this accident. The routes that are sent by
the customer have the anticipated AS-path value. A prefix-list that distinctly identifies and
permits each of the network numbers that the customer may advertise would have prevented the
accident. But such a prefix-list is hard to maintain.
7-28
Configuring the BGP Maximum-Prefix Function

This topic identifies the Cisco IOS command that is used to configure the maximum-prefix
function in BGP.
Configuring the BGP

Maximum-Prefix Function
This command controls how many prefixes can be received

from a neighbor.
The optional threshold parameter specifies the percentage where
a warning message is logged (default is 75%).
The optional warning-only keyword specifies the action on
exceeding the maximum number (default is to drop the neighbor
relationship).
The optional restart keyword instructs the router to try to reestablish the session after the specified interval in minutes.
BGP v3.27-4
A scalable solution to the need for limiting the number of routes (prefixes) that are received
from a BGP neighbor is to use a new tool that limits the number of routes that are received
from a specific neighbor.
neighbor maximum-prefix
To control how many prefixes that a BGP router can receive from a neighbor, use the neighbor
maximum-prefix router configuration command.
neighbor {ip-address | peer-group-name} maximum-prefix maximum [threshold]
[warning-only] [restart restart-interval]
no neighbor {ip-address | peer-group-name} maximum-prefix maximum
7-29
Syntax Description
Parameter
Description
Maximum number of prefixes that are allowed from this neighbor.
(Optional) Integer specifying at what percentage of maximum the

router starts to generate a warning message.
The range is 1 to 100 percent; the default is 75 percent.
(Optional) Allows the router to generate a log message when the

maximum is exceeded, instead of terminating the peering.
(Optional) Configures the router to automatically re-establish a

peering session that has been disabled because the maximumprefix limit has been exceeded.
The configurable range of the restart interval is from 1 to 65,535
minutes.
This command allows you to configure a maximum number of prefixes that a BGP router is
allowed to receive from a peer. It adds another mechanism (in addition to distribute-lists, filterlists, and route-maps) to control prefixes that are received from a peer.
When the number of received prefixes exceeds the maximum number that is configured, the
router terminates the peering (by default). However, if the warning-only keyword is
configured, the router sends a log message but continues peering with the sender. If the peer is
terminated, the peer session remains down until the clear ip bgp command is issued on the
router, unless you have included the restart keyword in the configuration.
Note
You can use the bgp dampening command to configure the dampening of a flapping route
or interface when a peer is sending too many prefixes and causing network instability. You
should need the restart command only when you are troubleshooting or tuning a router that
is sending an excessive number of prefixes.
The BGP Restart Session After Max-Prefix Limit feature enhances the capabilities of the
neighbor maximum-prefix command with the introduction of the restart keyword. This
enhancement allows the network operator to configure the time interval after which a peering
session is re-established by a router when the number of prefixes that have been received from
a peer has exceeded the maximum prefix limit. The restart keyword has a configurable timer
argument that is specified in minutes. The time range of the timer argument is from 1 to 65535.
This feature attempts to re-establish a disabled peering session at the time interval that is
configured by the network operator. However, the configuration of the restart timer alone
cannot change or correct a peer that is sending an excessive number of prefixes. The network
operator will need to reconfigure the maximum-prefix limit or reduce the number of prefixes
that are sent from the peer. A peer that is configured to send too many prefixes can cause
instability in the network, where an excessive number of prefixes are rapidly advertised and
withdrawn. In this case, the warning-only keyword can be configured to disable the restart
capability while the network operator corrects the underlying problem.
7-30
Monitoring the BGP Maximum-Prefix Function

This topic identifies the Cisco IOS command that is used to monitor the operation of the
maximum-prefix function in BGP.
Monitoring the BGP Maximum-Prefix

Function

For neighbors with the maximum-prefix function configured,
displays the maximum number of prefixes and the warning
threshold
For neighbors exceeding the maximum number of prefixes,
displays the reason that the BGP session is idle
BGP v3.27-5
Network administrators use the show ip bgp neighbors command to monitor the status of BGP
neighbors. Among other things, the command displays information about how many prefixes a
BGP router has received from a neighbor and if any limits have been configured.
7-31
Example: Monitoring the BGP

In this example, the neighbor with IP address 1.3.0.3 has been configured with a prefix limit of
five prefixes.

Function (Cont.)
BGP v3.27-6
Currently, the BGP router has received two prefixes, which is under the limit. The threshold for
the warning message is set to 70 percent, meaning that after receiving four prefixes from the
1.3.0.3 neighbor, the BGP router will generate a warning message.
7-32

Function (Cont.)
BGP v3.27-7
The logging outputs, in the example here, show that a BGP neighbor is close to exceeding the
configured maximum-prefix limit. The total number of received prefixes has reached four,
which is over the threshold to generate a warning message. The warning is displayed on the
console and optionally sent to a syslog server.
The logging output then shows that two more prefixes have been received. The total number is
now six, which is above the configured limit. The BGP session is therefore terminated. The
output of the show ip bgp neighbors command shows that the reason for resetting the session
is that the peer exceeded the configured maximum number of prefixes. As a result of the
session being reset, the BGP session will remain in the Idle state.
To force the neighbor from the Idle state into the Active state and to re-establish the BGP
session, the network administrator must issue the clear ip bgp ip-address command for the
neighbor (except if the network administrator has specified the restart keyword in the
configuration, in which case the router tries to re-establish the BGP session automatically after
the expiration of the configured restart timeout interval).
7-33
Summary
Summary
An improperly configured filter in a customer router may
accidentally cause a large number of Internet routes to be
received by the customer.
The neighbor maximum-prefix command allows you to configure
a maximum number of prefixes that a BGP router is allowed to
receive from a peer. When the number of received prefixes
exceeds the maximum number configured, the router either
terminates the peering (by default) or sends a log message but
continues peering with the sender.
You can use the show ip bgp neighbors command to monitor the
status of BGP neighbors, displaying information about the
number of prefixes that a BGP router has received from a
neighbor and if any limits have been configured.
7-34
BGP v3.27-8
Lesson 3
Implementing BGP Peer

Groups
Overview
Scaling routers to meet the demands of full Internet routing and associated administrative
policies requires protocols like Border Gateway Protocol (BGP) with embedded scalability
mechanisms. In environments where network administrators must configure a large number of
BGP peers, peer groups are a scalability tool that reduces both administrative overhead and
router resource requirements.
Typical service provider networks usually contain BGP-speaking routers that consist of many
neighbors that are configured with the same administrative policies (such as outbound routemaps, distribute-lists, filter-lists, update source, and so on). Network administrators can group
together neighbors with the same update policies into peer groups to simplify configuration
and, more importantly, to make BGP updates more efficient. This lesson introduces peer groups
as a BGP scalability mechanism. The lesson also discusses the commands that are required to
properly configure and monitor BGP peer groups.
Objectives
Upon completing this lesson, you will be able to use BGP peer groups to share common
configuration parameters between multiple BGP peers. This ability includes being able to meet
these objectives:
Describe the need for BGP peer groups
Describe the performance benefits of using BGP peer groups
Describe the limitations of BGP peer groups
Describe the characteristics of BGP peer groups when they are implemented in Cisco IOS
software
Describe the function of the BGP Dynamic Update Peer-Groups feature
Describe the function of the BGP Configuration Using Peer Templates feature
Identify the Cisco IOS commands that are required to configure BGP peer groups
Identify the Cisco IOS commands that are required to monitor BGP peer groups

This topic describes the need for BGP peer groups.

BGP routers could have a large number of neighbors
with similar requirements:
Provider edge router with many customer connections
BGP route reflector with many IBGP peers
Provider edge router at an exchange point
Most of the parameters specified for the BGP

neighbors are identical, with a few exceptions.
BGP v3.27-3
In many cases, a network administrator must configure a single router with a large number of
neighbors, each neighbor having parameters similar to the others. This situation may cause
time-consuming configuration work, because the network administrator has to configure almost
the same filter-list, route-map, and prefix-list for all of the neighbors. A service provider
network with an edge router having a large number of customers attached to it, where each
customer requires its own BGP session, may find that all of the BGP sessions to its customer
routers have almost identical configurations.
Likewise, Internal Border Gateway Protocol (IBGP) sessions are almost always identically
configured. If a full mesh is deployed within an autonomous system (AS), a large number of
peer configurations might exist. Recall that an AS containing only 15 routers will require ([15 *
14] / 2) = 105 neighbor sessions to meet the full-mesh requirement of BGP. Configuring 105
neighbors with duplicate parameters leads to a tremendous amount of redundant configuration.
To ease the burden of configuring a large number of neighbors with identical or similar
parameters (for example, route-maps, filter-lists, or prefix-lists), the concept of peer groups was
introduced. The network administrator can configure a template, or peer group. The
administrator configures the peer group with all the BGP parameters that are to be applied to
many BGP peers. Actual BGP neighbors are bound to the peer group, and the network
administrator applies the peer group configuration on each of the BGP sessions. BGP neighbors
of a single router can be divided into several groups, each group having its own BGP
parameters. Actual neighbors are then bound to the appropriate group, resulting in an optimum
BGP configuration.
7-36
Example: Peer Group RequirementsCustomer Connections

This example illustrates a service provider network with a group of customer autonomous
systems that can be treated in the same (or a very similar) way.
Peer Group Requirements Example:

Customer Connections
BGP v3.27-4
The customer autonomous systems are all assumed to announce local networks only. All
customer autonomous systems should receive BGP updates with the same set of Internet routes,
and the customer autonomous systems are all assumed to generate only a small number of
prefixes.
This situation makes the neighbor configuration almost identical for each of the customers,
with only a few changes that are specific to each neighbor.
In this scenario, the use of the peer group function is highly desirable. The network
administrator can configure BGP neighbors in the customer autonomous systems using a single
peer group. The administrator configures the peer group template with references to routemaps, filter-lists, prefix-lists, and the maximum number of received prefixes. Then the IP
addresses of the customer routers are bound to the peer group, and the peer group configuration
is applied to all of them.
7-37
Example: Peer Group RequirementsBGP Route Reflector

This example illustrates the BGP route reflector.

BGP Route Reflector
BGP v3.27-5
To apply a consistent routing policy within the entire local AS, the network administrator needs
to configure every IBGP session identically. If a router in the AS is supplied with some
information, then all the routers should be supplied with the same information. Otherwise, an
inconsistent routing policy within the AS might cause inconsistent routing or application of
BGP policies.
The peer group function is a good tool to make sure that all IBGP peers receive the same
configuration information. The network administrator configures a peer group template with
the required parameters, such as the neighbor AS number, enabling of the send-community
option, setting of the update source to a loopback interface, and router authentication
mechanisms. Then all the internal neighbor IP addresses are bound to the peer group, and the
peer group configuration is applied to all of them. This approach ensures a consistent routing
policy within the AS.
In a service provider network, the routers that are assigned as route reflectors are the routers
with the largest number of IBGP sessions. These are the routers where the peer group function
is most useful.
7-38
Example: Peer Group Requirements Edge Router at a Peering

Point
This example illustrates an edge router at a peering point.

Edge Router at a Peering Point
BGP v3.27-6
The edge router that is located in the network where the service provider exchanges routes with
other service providers is also a suitable place to use peer groups. From the edge router, the
service provider AS can peer with a large number of other service providers.
All peering autonomous systems should receive the same set of routes, namely the routes local
to the service provider AS and the routes that are received from customer autonomous systems.
Also, all routes that are received by the service provider peering router from all peering
autonomous systems are processed almost identically. The characteristic of the exchange
network is the same regardless of which neighbor the routes are received from. If the peering
point is an FDDI, ATM, Gigabit Ethernet, or Dynamic Packet Transport (DPT) network, the
preference of using the network for packet exchange may be different. However, for each
single peering point, all neighbors are reachable over the same network, and the preference is
quite likely to be the same.
Additionally, a number of other parameters could be the same, such as removing private AS
numbers and limiting the number of routes received. In these cases, the network administrator
can apply these parameters on the peer group template before the actual IP addresses of the
neighbors are bound to the peer group.
7-39
Peer Groups as a BGP Performance Tool

This topic describes the performance benefits of using BGP peer groups.
Peer Groups as a BGP

Performance Tool
Cisco IOS software builds individual BGP updates for
each BGP neighbor.
The CPU load imposed by the BGP process is
proportional to the number of BGP neighbors.
A single BGP update is built for all members of a BGP

peer group.
The CPU load does not increase linearly with the
increased number of neighbors.
Hint: Use peer groups wherever possible to reduce the
CPU load of the BGP process.
BGP v3.27-7
By default, Cisco IOS software builds BGP updates for each neighbor individually. Building
BGP updates involves a number of router-CPU-consuming tasks, including scanning the BGP
table and applying a variety of outgoing filtering mechanisms (filter-lists, route-maps, and
prefix-lists). These tasks imply that when a router is configured with a large number of
neighbors, the CPU load grows proportionally.
However, with the use of peer groups, some of the router CPU utilization that is imposed by
BGP update generation is significantly reduced, because the use of peer groups allows the
router to run the BGP update (including all outgoing filter processing) only once for the entire
peer group. The router, after it has finished building the BGP update, sends it to each member
of the peer group. The actual TCP transmission still has to be done on a per-neighbor basis
because of the connection-oriented characteristics of BGP sessions.
So, router CPU load does increase when there are more neighbors of a router, because of
increased TCP workload, but the use of peer groups can significantly reduce the increase.
Therefore, network administrators should use peer groups whenever possible to reduce the CPU
load.
Note
7-40
BGP peer groups are the fundamental BGP scalability tool and should be used in all
environments where a router has a large number of BGP neighbors.

This topic describes the limitations of BGP peer groups.

Peer groups have a number of limitations because of
the way that they are used to build BGP updates.
Per-neighbor BGP parameters that affect outbound
updates cannot be changed for peer group members.
IBGP and EBGP neighbors cannot be mixed in a peer
group.
BGP v3.27-8
Because the router builds only one update for all members of the same peer group, some
restrictions apply to members of the peer group:
There cannot be different outbound filters, route-maps, or other means that could possibly
cause different updates to be sent to two members of the same peer group. Cisco IOS
software creates only one update, which is subsequently replicated to all members. Any
violation of this rule could cause unexpected results.
External Border Gateway Protocol (EBGP) and IBGP updates are very different. EBGP
updates have the AS-path attribute changed. IBGP sessions pass only the local preference
attribute. The multi-exit discriminator (MED) attribute that is received from a remote AS is
passed on to IBGP sessions but is removed before it is sent on an EBGP session. Therefore,
you cannot assign IBGP neighbors and EBGP neighbors to the same peer group because
they cannot receive a replication of the same update.
Prior to Cisco IOS Software Release 11.1(18)CC, a route reflector client could not be a member
of a peer group. When the peer group leader was a route reflector client and an update was
received from it, the route reflector split-horizon rules prevented the update from being sent
back to the sender. Therefore, no update was generated for any members of the peer group.
When using peer groups in combination with route reflectors, make sure that all routers in the
AS are running Cisco IOS releases later than 11.1(18)CC, where this restriction is lifted.
Because the router sends the same update to each of the peer group members, the next-hop
BGP attribute is replicated. The receivers of the information must be able to use the same nexthop IP address, requiring the receivers to be in the same IP subnet. If two receivers are on
different subnets, only one of them will receive a valid next-hop attribute. The other routers
will receive a next-hop IP address that is inaccessible. This restriction was also removed in
Cisco IOS Release 11.1(18)CC, making BGP peer groups an ideal scalability tool.
7-41
BGP Peer Groups in Cisco IOS Software

This topic describes the characteristics of BGP peer groups when they are implemented in
Cisco IOS software.
BGP Peer Groups in

Cisco IOS Software
BGP peer group creates a neighbor parameter template.
Configurable parameters include the following:
Community propagation
Source interface for TCP session
EBGP multihop sessions
MD5 password
Neighbor weight
Filter-lists and distribute-lists
Route-maps
Individual parameters specified in a peer group can be

overridden on a neighbor-by-neighbor basis.
BGP v3.27-9
On a Cisco IOS router, the peer group is created as a template. The template is configured to do
the following:
Propagate, or not propagate, the community attribute
Use the IP address of a specific interface as the source address when opening the TCP
session
Use, or not use, the EBGP multihop function
Use, or not use, Message Digest 5 (MD5) authentication on the BGP sessions
Assign a particular weight value to the routes that are received
Filter out any incoming or outgoing routes based on the content of the AS-path attribute
that are associated with the route or the network number of the route
Pass the incoming or outgoing routes through a particular route-map
When actual neighboring routers are assigned to the peer group on a router, all of the attributes
that are configured for the peer group are applied to all peer group members. Cisco IOS
software optimizes the outgoing routes by running through the outgoing filters and route-maps
only once and then replicating the results to each of the peer group members. In reality, Cisco
IOS software assigns a peer group leader, for which the software generates an update, and this
update is replicated by the leader to all other members of the peer group.
Some parameters configured on the peer group can be overridden by neighbor configurations,
but only if the individual configurations apply on incoming updates. Outgoing updates are
always prepared for the peer group leader and then replicated to the other members of the peer
group.
7-42
BGP Dynamic Update Peer-Groups Feature

This topic describes the function of the BGP Dynamic Update Peer-Groups feature.
BGP Dynamic Update Peer Groups Feature

Separates BGP update generation from peer-group
configuration
Introduces a new algorithm that dynamically calculates and
optimizes update-groups of neighbors that share the same
outbound policies
Requires no configuration by the network operator? optimal
BGP update message generation occurs automatically and
independently
BGP v3.27-10
In previous versions of Cisco IOS software, BGP update messages were grouped together
based on peer-group configurations. This method of grouping neighbors together for BGP
update message generation reduced the amount of system processing resources needed to
process the routing table. This method, however, had the following limitations:
All neighbors that shared the same peer-group configuration also had to share the same
outbound routing policies.
All neighbors had to belong to the same peer group and address family. Neighbors
configured in different peer groups cannot belong to different address families.
These limitations existed to balance optimal update generation and replication against peergroup configuration. These limitations also caused the network operator to configure smaller
peer groups, which reduced the efficiency of update message generation.
The BGP Dynamic Update Peer-Groups feature separates BGP update generation from peergroup configuration, The BGP Dynamic Update Peer-Groups feature introduces a new
algorithm that dynamically calculates and optimizes update-groups of neighbors that share the
same outbound policies and can share the same update messages.
This feature does not require any configuration by the network operator. Optimal BGP updatemessage generation occurs automatically and independently. BGP neighbor configuration is no
longer restricted by outbound routing policies, and update-groups can belong to different
address families. When a change to outbound policy occurs, the router automatically
recalculates update-group memberships and applies the changes by triggering an outbound soft
reset after a 3-minute timer expires. This behavior is designed to provide the network operator
with time to change the configuration if a mistake is made.
7-43
If no argument is specified, the clear up bgp update-group command recalculates all updategroups. Specific index numbers for update groups and information about update-group
membership is displayed in the output of the show ip bgp update-group and debug ip bgp
groups commands.
clear ip bgp update-group

To clear BGP update-group member sessions, use the clear ip bgp update-group command in
privileged EXEC mode.
clear ip bgp update-group [index-group | ip-address]
Syntax Description
Parameter
Description
(Optional) Specifies that the update-group with corresponding

index number will be reset.
The range of update-group index numbers is from 1 to
4294967295.
(Optional) Specifies the IP address of a single peer that will be

reset.
The output of the debug ip bgp groups command displays information about update-group
calculations and the addition and removal of update-group members. Information about peer
groups and peer-policy and peer-session templates is also displayed in the output of this
command as neighbor configurations change.
Note
The output of this command can be very verbose, so this command should not be
deployed in a production network unless you are troubleshooting a problem.
debug ip bgp groups

To display information related to the processing of BGP update-groups, use the debug ip bgp
update privileged EXEC mode.
debug ip bgp groups [index-group | ip-address]
To disable the display of BGP update information, use the no form of this command.
no debug ip bgp groups
7-44
Syntax Description
Parameter
Description
(Optional) Specifies that update-group debugging information for

the corresponding index number will be displayed.
4294967295.
(Optional) Specifies that update-group debugging information for

a single peer will be displayed.
The following example output from the debug ip bgp groups command shows the
recalculation of update-groups after the clear ip bgp groups command was issued:

show ip bgp replication

To display update replication statistics for BGP update-groups, use the show ip bgp
replication command in EXEC mode.
show ip bgp replication [index-group | ip-address]
Syntax Description
Parameter
Description
(Optional) Specifies that update replication statistics for the

update-group with corresponding index number will be displayed.
4294967295.
(Optional) Specifies the IP address of a single neighbor for which

update-group statistics will be displayed.
7-45
The following sample output from the show ip bgp replication command shows update-group
replication information for all for neighbors:

2 internal 2 10.4.9.5 0 0 0 0
show ip bgp update-group

To display information about BGP update-groups, use the show ip bgp update-group
command in EXEC mode.
show ip bgp update-group [index-group | ip-address] [summary]
Syntax Description
Parameter
Description
(Optional) Displays the update-group with corresponding index

number.
4294967295.
(Optional) Displays the IP address of a single neighbor.
(Optional) Displays a summary of update-group member

information.
The output can be filtered to show information for a single indexgroup or peer with the index-group or ip-address argument.
The following sample output from the show ip bgp update-group command shows updategroup information for all neighbors:

7-46

10.4.9.5 10.4.9.8
7-47

This topic describes the function of the BGP Configuration Using Peer Templates feature.

This feature introduces a new mechanism called the peer
template.
A peer template is a configuration pattern that can be applied
to neighbors that share common policies.
Peer templates are reusable and support inheritance, which
allows the network operator to group and apply distinct
neighbor configurations for BGP neighbors that share
common policies.
Peer templates also allow the network operator to define very
complex configuration patterns through the ability of a peer
template to inherit a configuration from another peer
template.
BGP v3.27-11
The BGP Dynamic Update Peer-Groups feature separates peer-group configuration from
update group generation. BGP neighbor configuration is no longer restricted by outbound
routing policies, and update-groups can belong to different address families. Even though BGP
update-message generation has been separated from peer-group configuration, peer group
configuration still has the following limitations:
A neighbor can belong only to one peer group.
Neighbors that belong to different address families cannot belong to the same peer group.
Different sets of policies cannot be grouped and applied to a neighbor.
To address the limitations of peer groups, the BGP Configuration Using Peer Templates feature
was introduced along with the BGP Dynamic Update Peer-Groups feature.
A peer template is a configuration pattern that can be applied to neighbors that share common
policies. Peer templates are reusable and support inheritance, which allows the network
operator to group and apply distinct neighbor configurations for BGP neighbors that share
common policies. Peer templates also allow the network operator to define very complex
configuration patterns through the ability of a peer template to inherit a configuration from
another peer template.
7-48
Peer Templates
Peer session templates are used to group and apply the
configuration of general session commands that are common
to all address-family and NLRI configuration modes.
Peer policy templates are used to group and apply the
configuration of commands that are applied within specific
address-family and NLRI configuration modes.
BGP v3.27-12
There are two types of peer templates:

Peer session templates are used to group and apply the configuration of general session
commands that are common to all address-families and Network Layer Reachability
Information (NLRI) configuration modes.
Peer policy templates are used to group and apply the configuration of commands that are
applied within specific address-families and NLRI configuration modes.
Peer templates improve the flexibility and enhance the capability of neighbor configuration.
Peer templates also provide an alternative to peer group configuration and overcome some
limitations of peer groups. With the configuration of the BGP Configuration Using Peer
Templates feature and the support of the BGP Dynamic Update Peer-Groups feature, the
network operator no longer needs to configure peer groups in BGP and can benefit from
improved configuration flexibility and faster convergence.
The inheritance capability is a key component of peer-template operation. Inheritance in a peer
template is similar to the node and tree structures commonly found in general computingfor
example, file and directory trees. A peer template can directly or indirectly inherit a
configuration from another peer template. The directly inherited peer template represents the
tree in the structure, and the indirectly inherited peer template represents a node in the tree.
Because each node also supports inheritance, branches can be created that apply the
configurations of all indirectly inherited peer templates within a chain that traces back to the
directly inherited peer template or the source of the tree. This structure eliminates the need to
repeat configuration statements that are commonly reapplied to groups of neighbors, because
common configuration statements can be applied once and then indirectly inherited by peer
templates that are applied to neighbor groups with common configurations.
Inheritance expands the scalability and flexibility of neighbor configuration by allowing you to
chain together peer-template configurations to create simple configurations that inherit
common configuration statements or complex configurations that apply very specific
configuration statements along with common inherited configurations.
7-49
Peer Session Commands

General session commands that are common for neighbors that are configured in different
address families can be configured within the same peer session template. Peer session
templates are created and configured in peer session configuration mode. Only general session
commands can be configured in a peer session template.
General session commands can be configured once in a peer session template and then applied
to many neighbors through the direct application of a peer session template or through indirect
inheritance from a peer session template. The configuration of peer session templates simplifies
the configuration of general session commands that are commonly applied to all neighbors
within an AS.
Peer session templates support direct and indirect inheritance. A peer can be configured with
only one peer session template at a time, and that peer session template can contain only one
indirectly inherited peer session template. However, each inherited session template can also
contain one indirectly inherited peer session template. So, only one directly applied peer
session template and up to seven additional indirectly inherited peer session templates can be
applied, allowing you to apply a maximum of eight peer session configurations to a neighbor:
the configuration from the directly inherited peer session template and the configurations from
up to seven indirectly inherited peer session templates. Inherited peer session templates are
evaluated first, and the directly applied template is evaluated and applied last. So, if a general
session command is reapplied with a different value, the subsequent value has priority and
overwrites the previous value that was configured in the indirectly inherited template.
Peer session templates support only general session commands. BGP policy configuration
commands that are configured only for specific address families or NLRI configuration modes
are configured with peer policy templates.
template peer-session
To create a peer session template and enter session template configuration mode, use the
template peer-session command in router configuration mode.
template peer-session session-template-name
To remove a peer session template, use the no form of this command.
no template peer-session session-template-name
Syntax Description
Parameter
Description
Name or tag for the peer session template
The inherit peer-session command configures a peer session template to inherit the
configuration of another peer session template.
inherit peer-session
To configure a peer session template to inherit the configuration of another peer session
template, use the inherit peer-session command in session-template configuration mode.
7-50
inherit peer-session session-template-name

To remove an inherit statement from a peer session template, use the no form of this command.
no inherit peer-session session-template-name
Syntax Description
Parameter
Description
Name of the peer session template to be inherited
The neighbor inherit peer-session command is used to send locally configured session
templates to the specified neighbor. If the session template is configured to inherit
configurations from other session templates, the specified neighbor will also indirectly inherit
these configurations from the other session templates. A neighbor can directly inherit only one
peer session template and indirectly inherit up to seven peer session templates.
Note
A BGP neighbor cannot be configured to work with both peer groups and peer templates. A
BGP neighbor can be configured to belong only to a peer group or to inherit policies only
from peer templates.
neighbor inherit peer-session

To send a peer session template to a neighbor so that the neighbor can inherit the configuration,
use the neighbor inherit peer-session command in address family or router configuration
mode.
neighbor ip-address inherit peer-session session-template-name
To stop sending the peer session template, use the no form of this command.
no neighbor ip-address inherit peer-session session-template-name
Syntax Description
Parameter
Description
IP address of the neighbor
Name or tag for the peer session template
The show ip bgp template peer-session command is used to display locally configured peer
session templates. The output can be filtered to display a single peer session template with the
peer-session-name argument. This command also supports all standard output modifiers.
show ip bgp template peer-session

To display peer policy template configurations, use the show ip bgp template peer-session
show ip bgp template peer-session [session-template-name]
7-51
Syntax Description
Parameter
Description
(Optional) Name of a locally configured peer session template
Peer Policy Commands

Peer policy templates are used to configure BGP policy commands that are configured for
neighbors that belong to specific address families and NLRI configuration modes. Like peer
session templates, peer policy templates are configured once and then applied to many
neighbors through the direct application of a peer policy template or through inheritance from
peer policy templates. The configuration of peer policy templates simplifies the configuration
of BGP policy commands that are applied to all neighbors within an AS.
Peer policy templates support direct and indirect inheritance from up to eight peer policy
templates. Inherited peer policy templates are configured with sequence numbers, like routemaps. An inherited peer policy template, like a route-map, is evaluated starting with the inherit
statement with the lowest sequence number and ending with the highest sequence number.
However, there is a difference: A peer policy template will not fall through like a route-map.
Every sequence is evaluated, and if a BGP policy command is reapplied with different value, it
overwrites any previous value from a lower sequence number.
Peer policy templates support only general policy commands. BGP policy configuration
commands that are configured only for specific address families or NLRI configuration modes
are configured with peer policy templates.
inherit peer-policy
To configure a peer policy template to inherit the configuration from another peer policy
template, use the inherit peer-policy command in policy-template configuration mode.
inherit peer-policy policy-template-name sequence-number
To remove an inherit statement from a peer policy template, use the no form of this command.
no inherit peer-policy policy-template-name sequence-number
Syntax Description
Parameter
Description
Name of the peer policy template to be inherited.
Sequence number that sets the order in which the peer policy
template is evaluated.
Like a route-map sequence number, the lowest sequence
number is evaluated first.
The neighbor inherit peer-policy command is used to send locally configured policy
templates to the specified neighbor. If the policy template is configured to inherit
configurations from other peer policy templates, the specified neighbor will also indirectly
inherit these configurations from the other peer policy templates. A directly applied peer policy
7-52
template can directly or indirectly inherit configurations from up to seven peer policy
templates. So, a total of eight peer policy templates can be applied to a neighbor or neighbor
group.
neighbor inherit peer-policy

To send a peer policy template to a neighbor so that the neighbor can inherit the configuration,
use the neighbor inherit peer-policy command in address-family or router configuration
mode.
neighbor ip-address inherit peer-policy policy-template-name
To stop sending the peer policy template, use the no form of this command.
no neighbor ip-address inherit peer-policy policy-template-name
Syntax Description
Parameter
Description
IP address of the neighbor
Name or tag for the peer policy template
show ip bgp template peer-policy

To display locally configured peer policy templates, use the show ip bgp template peer-policy
show ip bgp template peer-policy [policy-template-name]
Syntax Description
Parameter
Description
(Optional) Name of a locally configured peer policy template
7-53

This topic identifies the commands that are used to configure BGP peer groups on Cisco IOS
routers.
Creates a BGP peer group

Peer group names are case-sensitive
Specifies any BGP parameter for the peer group
BGP v3.27-13
To configure BGP peer groups on Cisco IOS routers, perform the following steps:
Step 1
Create a BGP peer group.
Step 2
Specify parameters for the BGP peer group.
Step 3
Create a BGP neighbor.
Step 4
Assign a neighbor into the peer group.
neighbor peer-group (Creating)

To create a BGP peer group, use the neighbor peer-group router configuration command.
neighbor peer-group-name peer-group
To remove the peer group and all of its members, use the no form of this command.
no neighbor peer-group-name peer-group
After you have created a peer group using the neighbor peer-group command, you can
configure it with the neighbor commands. By default, members of the peer group inherit all the
configuration options of the peer group. You can also configure members to override the
options that do not affect outbound updates.
Peer group members will always inherit the following configuration options: remote-as (if
configured), version, update-source, out-route-map, out-filter-list, out-dist-list, minimumadvertisement-interval, and next-hop-self. All peer group members will inherit changes that
are made to the peer group.
7-54
Configuring Peer Groups (Cont.)
Assigns a BGP neighbor to a peer group.

The neighbor inherits all the BGP parameters specified for the
peer group.
Overrides a BGP parameter specified for the peer group with a

neighbor-specific parameter.
BGP v3.27-14
neighbor peer-group (Assigning Members)

To configure a BGP neighbor to be a member of a peer group, use the neighbor peer-group
router configuration command.
neighbor ip-address peer-group peer-group-name
To remove the neighbor from the peer group, use the no form of this command.
no neighbor ip-address peer-group peer-group-name
Syntax Description
Parameter
Description
IP address of the BGP neighbor that belongs to the peer group

that is specified by the tag
Name of the BGP peer group to which this neighbor belongs
After you have assigned an actual neighbor to be a member of the peer group, all configurations
made to the peer group template are then applied to all the neighbors that are assigned to that
peer group.
Through configuration, peer group configurations may be overridden for an individual
neighbor, provided that the changes apply only to incoming updates. Remember that outgoing
updates are prepared only once and then replicated.
7-55
Example: BGP Peer GroupCustomer Connections

In this example, the router in AS 123 is being configured with a peer group named
Customers.
BGP Peer Group Example:

Customer Connections
BGP v3.27-15
This peer group is used for all customers of the service provider because they share an almost
identical routing policy. The peer group is first created as a template, which is configured with
an incoming route-map named Cust_In and an outgoing route-map named Cust_Out, as
well as an incoming AS-path filter-list number of 10. The peer group is also configured with a
maximum limit of 50 received prefixes.
Then neighbors in AS 213 and AS 314 are assigned to the peer group. These additions mean
that the router in AS 123 will attempt to open BGP sessions with those routers. If the BGP
sessions succeed, the route-maps Cust_In and Cust_Out will be used with both neighbors on
incoming and outgoing routes, respectively. The maximum number of received prefixes that
can configured in the Customer peer group will also be applied to both neighbors.
Filter-list 10 will be used to filter out any incoming routes from peer group members unless
otherwise specified. However, in the case of the neighbor in AS 314, the individual
configuration of filter-list 21 will override the peer group configuration, and the AS-path
access-list number 21 will be used instead.
The peer group is a very powerful tool when network administrators are dealing with a large
number of neighbors with almost identical configurations. However, if any of the customers
require routing information that differs from that of other members of the Customer peer group,
then that neighbor must be removed from the peer group and configured as an individual
neighbor. This would be the reason for not including the AS 337 neighbor in the Customer peer
group.
7-56
Example: BGP Peer GroupBGP Route Reflector

In this example, a router acting as a BGP route reflector has four IBGP neighbors.

BGP Route Reflector
BGP v3.27-16
In a large AS, some routers may have a large number of IBGP sessions. A peer group that is
named IBGP_peers is created to handle all of the IBGP sessions. The peer group is created
and configured with the remote AS, update-source, MD5 authentication, and communitypassing parameters. When the actual neighbors are configured as members of the peer group,
all these configuration parameters will apply to all of the neighbors.
In the case of IBGP, the remote AS can also be configured as a part of the peer group
configuration because the AS number is the same for each of the peer group members.
The peer group is a very powerful tool when you are dealing with a large number of IBGP
neighbors because you can give all of the neighbors the same configuration to ensure a
consistent AS-wide routing policy.
7-57
Example: BGP Peer GroupEdge Router at a Peering Point

In this example, the router in AS 123 is being configured with a peer group named Peering.

Edge Router at a Peering Point
BGP v3.27-17
This peer group is used for all peer providers because they share an almost identical routing
policy. The peer group is first created as a template, which is configured with an incoming
AS-path filter-list (list 10) and an outgoing route-map named PeerMap. The maximum
number of received prefixes is also set in the peer group to 50. The peer group has also been
configured to remove private AS numbers (AS numbers in the range 64512 to 65535 inclusive)
from all AS paths before the routes are sent to the peer AS.
The neighbors in AS 745 and in AS 837 are then assigned to the peer group, meaning that the
router in AS 123 will attempt to open BGP sessions with those routers. If the BGP sessions are
successfully established, filter-list 10 and the route-map PeerMap, as configured in the peer
group, will be applied to incoming and outgoing routes from both neighbors, respectively.
As defined in the router configuration, filter-list 10 filters out any incoming routes from peer
group members unless otherwise specified. However, in the case of the neighbor in AS 837, the
individual configuration of no filter-list 10 will override the peer group configuration, and
thus, the filter-list will not be used for this neighbor. The limitation on the number of received
routes from AS 837 is also removed from the neighbor in AS 837.
The peer group is a very powerful tool when you are dealing with a large number of neighbors
with almost identical configurations. However, if any of the customers that are assigned to the
peer group require routing information that is different from other members of the peer group,
then that neighbor must be removed from the peer group and configured individually.
7-58

This topic lists the Cisco IOS commands that are required to monitor BGP peer groups.
Displays the definition of the specified peer group or all peer

groups
Displays summary status of all neighbors in the peer group
Clears BGP session with all peer group members

BGP v3.27-18
show ip bgp peer-group

To display information about BGP peer groups, use the show ip bgp peer-group EXEC
command.
show ip bgp peer-group [peer-group-name] summary
Syntax Description
Parameter
Description
(Optional) Displays information about that specific peer group
(Optional) Displays a summary of the status of all the members of

a peer group
clear ip bgp
To reset the BGP sessions with all the members of a peer group, use the clear ip bgp EXEC
command.
clear ip bgp {* | neighbor-address | peer-group-name} [soft [in | out]]
7-59
Syntax Description
Parameter
Description
(Optional) Displays information about that specific peer group.
(Optional) Initiates soft reconfiguration.

If you do not specify the in or out option, both inbound and
outbound soft reconfiguration are triggered.
7-60
Monitoring Peer Groups (Cont.)
BGP v3.27-19
In this example, the show ip bgp peer-group command displays information about the peer
group named wg_peers. One of the peer group members (192.168.20.1) has been selected as
the peer group leader, meaning that all outgoing BGP updates are processed as if they were
being sent to this neighbor. Thereafter, the update is replicated on all the BGP sessions to the
other members in the wg_peers peer group.
A peer group should have only IBGP members or EBGP members. In the example shown, the
members are EBGP neighbors.
All parameters that are configured for the peer group are listed in the show ip bgp peer-group
command output. In the example, the peer group wg_peers has been configured in the
following manner:

7-61
The printout is identical to a show ip bgp summary printout but displays

only neighbors that are members of the specified peer group.
BGP v3.27-20
The show ip bgp peer-group peer-group-name summary command is used in this example to
display only the summary status information about the neighbors who are members of the peer
group wg_peers.
Note
7-62
The show ip bgp summary command is described in the module BGP Overview.
BGP v3.27-21
The show ip bgp neighbor command displays additional information about BGP neighbors
that are members of a peer group.
In the example here, the membership in the peer group wg_peers is indicated, in addition to
other information as displayed by the command.
7-63
Summary
Summary
Peer groups were introduced to ease the burden of
configuring a large number of neighbors with identical or
similar parameters.
The use of peer groups can significantly reduce the increased
router CPU load when there are more neighbors of a router.
Peer groups have limitations because of the way that they are
used to build BGP updates: Per-neighbor BGP parameters
that affect outbound updates cannot be changed for peer
group members, and IBGP and EBGP neighbors cannot be
mixed in a peer group.
Cisco IOS software optimizes the outgoing routes by running
through the outgoing filters and route-maps only once and
then replicating the results to each of the peer group
members.
BGP v3.27-22
Summary (Cont.)
The BGP Dynamic Update Peer-Groups feature separates BGP
update generation from peer-group configuration, using an algorithm
that dynamically calculates and optimizes update-groups of
neighbors that share the same outbound policies and can share the
same update messages.
Peer templates improve the flexibility and enhance the capability of
neighbor configuration. Peer templates also provide an alternative to
peer group configuration and overcome some limitations of peer
groups.
To configure BGP peer groups on Cisco IOS routers, create a BGP
peer group, specify parameters for the BGP peer group, create a
BGP neighbor, and then assign a neighbor to the peer group.
You can use the show ip bgp peer-group command to monitor
information about BGP peer groups and the clear ip bgp command to
reset the BGP sessions with all the members of a peer group.
7-64
BGP v3.27-23
Lesson 4

Overview
Even when a Border Gateway Protocol (BGP) implementation is correctly configured and
highly robust, the performance of the routing process on any given router is limited. Limiting
the propagation of unstable routes, specifically when they are not beneficial to the network,
becomes an important issue because it reduces the processing requirements of the router that is
forced to process routing table state changes.
Route dampening is a BGP feature that has been designed to reduce BGP processing
requirements by minimizing the propagation of unstable routes to BGP peers. Autonomous
system (AS) border routers, in any BGP implementation, cannot rely upon external peers to
sufficiently shield the AS from routing table instability. Route dampening allows route
instability to be contained at an AS border router that borders the instability.
This lesson describes the purpose and operation of the route-dampening feature on Cisco IOS
routers. Also discussed in this lesson are the Cisco IOS commands that are required to enable
route dampening, modify default dampening parameters, and release a route that has been
suppressed because of dampening. The Cisco IOS commands that are used to monitor route
dampening are also discussed.
Objectives
Upon completing this lesson, you will be able to use route dampening to minimize the impact
of unstable routes. This ability includes being able to meet these objectives:
Describe the purpose of BGP route dampening
Describe the operation of BGP route dampening
Identify the Cisco IOS commands that are required to configure BGP route dampening
Identify the Cisco IOS commands that are required to release dampened routes
Identify the Cisco IOS commands that are required to monitor BGP route-dampening
BGP Route Dampening

This topic describes the purpose of BGP route dampening.
BGP Route Dampening

Designed to reduce router processing load caused by unstable
routes
Prevents sustained routing oscillations without affecting other
well-behaved routes
Defined in RFC 2439: BGP Route Flap Dampening
A tool designed to help minimize the number of BGP updates
Other update reduction tools:
Batching of BGP updates
Per-neighbor update timers
BGP v3.27-3
BGP is the only routing protocol that is designed for large internetworks with the specific
intention of carrying a large number of prefixes. There are several mechanisms that are built
into BGP that ensure maximum router stability.
For example, a BGP router does not forward BGP routing updates immediately after receiving
them. Every time a BGP router sends an update, it starts a 5-second timer for internal neighbors
and a 30-second timer for external neighbors. No new updates can be sent until that timer
expires. The result is that if a router contains a link that is flapping repeatedly (available, then
unavailable, then available, then unavailable, and so on) at a rate of once per second, external
routers see the flap at a much slower rate. Routers that are external to the source of the flap are
not forced to recalculate the best path every second but, at most, every 30 seconds.
Reducing the rate at which neighboring routers process flapping routes assists in reducing the
requirements to process the BGP update. However, routers that process routing updates for
unstable routes are still wasting resources in determining the best route to the destination.
Because the unstable route is oscillating between up and down, each route update that a router
receives causes it to process the unstable route all over again. A better approach is to remove
the update about the route until it can be guaranteed that the destination is more stable.
With this goal in mind, an additional BGP scalability mechanism called route flap dampening
was created to reduce route update processing requirements by suppressing unstable routes.
7-66
BGP Route Dampening (Cont.)

Minimizes the amount of BGP update processing in the
Internet by suppressing unstable (flapping) routes
Does not suppress routes that occasionally flap
Suppresses routes that are likely to flap in the future based
on the history of their behavior
Flap = Remove route
Suppress = Do not use a route after it reappears
BGP v3.27-4
Most service providers hold routing information for the entire Internet. Therefore, a flapping
link somewhere in the Internet can cause all routers in the Internet to keep processing changes
because of one single link. If, however, one of the autonomous systems in the Internet
implements route dampening, the flapping network is suppressed. The route is not propagated
further to other autonomous systems until the configured rules of route dampening allow it.
A flap refers to a route that is repeatedly available, then unavailable, then available, then
unavailable, and so on. If a route flaps once or twice, it is typically not considered a flap from
an administrative perspective. If the flapping happens more often, however, there is probably
something wrong with the destination and the route should be suppressed. The BGP router
stores a suppressed route in the BGP table but does not consider it in the BGP path-selection
process and does not therefore propagate it to other BGP neighbors or use it for data
forwarding.
7-67
This topic describes the operation of BGP route dampening.
Each time an EBGP route flaps, it gets 1000 penalty points (IGBP
routes are not dampened).
The penalty placed on a route decays according to the
exponential decay algorithm.
When the penalty exceeds the suppress limit, the route is
dampened (no longer used or propagated to other neighbors).
A dampened route is propagated when the penalty drops below
the reuse limit.
BGP v3.27-5
A BGP router with route dampening enabled keeps track of all routes (even those that are
unreachable) so that it can recall the penalties that are assigned to each route. Every time a
route flap occurs, the flapping route receives 1000 penalty points. The penalty is gradually
decreased through the use of a decaying algorithm. If a route flaps several times, it will be
penalized (gain enough penalty points) and subsequently reach and exceed the suppress limit.
Any route that reaches the suppress limit is no longer forwarded to other neighbors until the
assigned penalty is once again below the reuse limit. An exponential decay algorithm reduces
penalty points that are applied to a flapping route. After the number of penalty points that are
assigned to a route falls below the reuse limit, the BGP router once again advertises the route.
7-68
Route-Dampening Operation (Cont.)

The flap history is forgotten when the penalty drops below
half of the reuse limit.
A route is never dampened for more time than the maximum
suppress limit.
An unreachable route with a flap history is put in the history
stateit stays in the BGP table but only to maintain the flap
history.
A penalty is applied on the individual path in the BGP table,
not on the IP prefix.
BGP v3.27-6
A router stops tracking penalty points when they are below half of the reuse limit.
The maximum suppress limit defines the maximum duration that a route can be suppressed
after it has been suppressed.
After route dampening is enabled, the router never removes a route from the BGP table. A
route that has been withdrawn by a BGP neighbor can still be seen in the BGP table and is
marked with an h (history state).
A penalty is always applied to a path and not a prefix. If one of the paths is flapping, it does not
mean that the destination is flapping.
7-69

This topic identifies the Cisco IOS commands that are required to configure BGP route
dampening.

Configures BGP route dampening
BGP dampening parameters:
half-life
Decay time in which the penalty is halved
suppress
Value when the route starts dampening
reuse
Value when the dampened route is reused
max-suppress-time
Maximum time to suppress the route
route-map
Name of route-map controlling dampening
BGP v3.27-7
To enable route dampening, use the bgp dampening command. Optionally, you can change the
default settings of the route-dampening parameters.
Route flap dampening requires the following parameters:
half-life: The half-life is the time that is needed for the penalty to halve (default is 15
minutes).
suppress: When a route has more penalty points than the suppress limit, the route is
suppressed (default is 2000).
reuse: After the flapping has stopped and the penalty for a route has fallen below the reuse
limit, the route is unsuppressed (default is 750).
max-suppress-time: No route can be suppressed longer than the max-suppress-time minutes
(default is 1 hour; maximum is 255 minutes).
You can specify the four route flap-dampening parameters directly with the bgp dampening
command. Alternatively, you can create a route-map that specifies different dampening
parameters for different sets of routes, and then you can apply the route-map with the bgp
dampening route-map command.
7-70
Configuring BGP Route Dampening (Cont.)

Most Internet service providers use default values:
A flapping route is dampened after three successive flaps.
A route stays suppressed for approximately 30 minutes.
Net result: The route is lost for 30 minutes if a BGP session
with a neighbor is cleared three times in succession.
Default dampening parameter values are:
half-life
15 minutes
suppress
2000
reuse
750
max-suppress-time
60 minutes (4x half-life)
per-flap penalty
1000 (nonconfigurable)
BGP v3.27-8
This sample calculation shows how long a route that flaps three times is suppressed with the
default values of the Cisco IOS route-dampening parameters. Each time that a route flaps, it
accumulates another 1000 points. After the third flap, the route has almost 3000 points.
Remember that the penalty is gradually decreased through the use of a decaying algorithm,
causing a reduction in the number of points that the route accumulates. It takes 15 minutes for
the penalty to drop below 1500 (provided there are no further flaps) and another 15 minutes to
drop below the reuse limit of 750.
Many service providers change the default parameters to allow a maximum suppress time of
several hours.
Note
Using the clear ip bgp * command is regarded as a flap to neighboring autonomous

systems. Using this command several times may cause neighboring autonomous systems to
suppress prefixes for some time even if there is nothing wrong with the route.
Note
Using the clear ip bgp * [soft] [in | out] command is not regarded as a flap, and this
command should be used instead of clear ip bgp * for clearing the neighbor relationships.
You can change all default values if you specify them in the optional parameters of the bgp
dampening command. The per-flap penalty is the only value that is not configurable.
7-71
Configuring BGP Route Dampening (Cont.)
This command sets the BGP dampening parameters for

individual routes matched by a route-map entry.
Apply this route-map to the bgp dampening command instead of
specifying individual parameters.
Applications:
Less aggressive dampening of routes toward root DNS
servers (or other servers)
Dampening of smaller prefixes more aggressively
Selective dampening based on BGP neighbor and
route-map match criteria
BGP v3.27-9
Many service providers prefer to implement selective dampening. Larger prefixes are usually
less likely to flap and should not be penalized as aggressively as the smaller prefixes that
populate most of the BGP table.
You can use a route-map in combination with a prefix-list to match on prefix length and to set
different route-dampening parameters for larger prefixes than for smaller ones. A practical
service provider policy is to use a route-map to exclude root Domain Name System (DNS)
servers from dampening altogether.
You can then attach the route-map to the BGP route-dampening process with the bgp
dampening route-map command.
7-72

This topic identifies the Cisco IOS commands that are used to release dampened routes.
Clears the flap statistics but does not release dampened routes

Releases all the dampened routes or just the specified network
Flap statistics or dampened routes also cleared when the BGP
session with the neighbor is lost
BGP v3.27-10
There are two timers that are calculated for every route when it flaps:
Time to forget: The time that it takes before all flap history is deleted. Using the clear ip
bgp flap-statistics command deletes all penalty information, but it does not release the
dampened paths.
Time to reuse: The time that it takes before a route can be considered for best-path
processing. Using the clear ip bgp dampening command resets this timer for all networks
or for specified networks so that they are no longer suppressed. The flap statistics,
however, are still kept, and the next flap will cause the previously dampened paths to be
suppressed again.
clear ip bgp flap-statistics

To clear BGP flap statistics, use the clear ip bgp flap-statistics privileged EXEC command.
clear ip bgp ip-address flap-statistics [{regexp regexp} | {filter-list list-name} | {ipaddress network-mask}]
7-73
Syntax Description
Parameter
Description
(Optional) Clears flap statistics for a single entry at this IP

address.
If this argument is placed before flap-statistics, the router clears
flap statistics for all paths from the neighbor at this address.
(Optional) Clears flap statistics for all the paths that match the
regular expression.
(Optional) Clears flap statistics for all the paths that pass the
access-list.
(Optional) Network mask that is applied to the ip-address

argument.
clear ip bgp dampening

To clear BGP route-dampening information and unsuppress the suppressed routes, use the clear
ip bgp dampening privileged EXEC command.
clear ip bgp dampening [ip-address network-mask]
Syntax Description
Parameter
Description
(Optional) Clears flap statistics for a single entry at this IP

address.
If this argument is placed before flap-statistics, the router clears
flap statistics for all paths from the neighbor at this address.
7-74
(Optional) Network mask that is applied to the ip-address

argument.

This topic identifies the Cisco IOS commands that are required to monitor BGP route
dampening.

Displays the dampened routes
Displays flap statistics for all routes with dampening history

Can match routes against regular expressions, AS-path accesslists, a specific route, or more specific routes

Displays the BGP dampening events
BGP v3.27-11
The penalty that is placed on a network is decayed until the reuse limit is reached, upon which
the route is once again advertised. Every time that a route flap occurs, the penalty is
recalculated. In the router, the penalty is encoded as the time that it takes for the penalty to
decay below the reuse limit. At half of the reuse limit, the dampening information for the route
to the network is removed.
Use the show ip bgp dampened-paths command to list all routes that are currently suppressed
because of dampening.
Use the show ip bgp flap-statistics command to list all routes that have a penalty that is still
above the time-to-forget limit. You can also use this command in combination with regular
expressions and filter-lists.
The show ip bgp flap-statistics prefix command displays detailed dampening information
about a specific network.
The show ip bgp flap-statistics prefix mask longer-prefix command displays dampening
information about a specific network and its subnets.
Use the debug ip bgp dampening command to display BGP dampening events as they occur
in real time.
7-75
Example: Monitoring Route Dampening

The example shows how, after the first flap (when a route becomes unreachable), the router
withdraws the route but keeps it in its own database to keep track of the penalty. The route
enters the history state.

Example
7-76
BGP v3.27-12

Example (Cont.)
BGP v3.27-13
Using show ip bgp displays suppressed prefixes with the state h.

Using show ip bgp prefix displays suppressed prefixes that are marked with history entry.
If a prefix is in the history state, it means that it is currently unreachable but that the
information has been kept in the BGP table to keep track of the penalty.
7-77

Example (Cont.)
BGP v3.27-14
The example here shows how, after the third flap, the penalty of the route exceeds the suppress
limit, and the route could be suppressed. When the route exceeds the suppress limit, one of two
things could happen:
The router will put the route in the history state if the route is currently unreachable.
The router will suppress the route if the route is currently reachable.
7-78

Example (Cont.)
BGP v3.27-15
The figure displays the debugging messages that accompany the three route flaps that were
illustrated in the previous figure. After the 12.0.0.0/8 prefix flaps for the third time, the router
assigns a new penalty of 2681 to the route. Because the new penalty exceeds the suppress limit
of 2000, the 12.0.0.0/8 prefix is suppressed by the router for 27 minutes (if it remains stable).
Using the show ip bgp command displays all suppressed prefixes that have their state marked
as dampened (d).
7-79

Example (Cont.)
BGP v3.27-16
The show ip bgp dampened-paths command is used to list all networks that are currently
suppressed because of dampening.
The show ip bgp prefix command displays detailed information among other paths about
suppressed prefixes. These prefixes are marked with the words suppressed due to dampening.
7-80

Example (Cont.)
BGP v3.27-17
The penalty of the route is decreased following an exponential curve. After a while, the penalty
drops below the suppress limit, but the route is not yet releasedthe route is released only after
the penalty drops further below the reuse limit. In the example here, the route flaps again,
further increasing the penalty.
7-81

Example (Cont.)
BGP v3.27-18
In the example here, the route has stabilized, and the penalty gradually drops below the reuse
limit. At that point, the BGP router releases the route, and it can now be selected as the best
BGP path. If the released route is selected by the router as the best BGP path, it is also
propagated to BGP neighbors and used for data forwarding.
When the penalty that is associated with a route drops below half of the reuse limit, the penalty
and the flap history that are associated with the route are cleared by the router.
7-82
Summary
Summary
Route dampening is a BGP feature that is designed to reduce
BGP processing requirements by minimizing the propagation
of unstable routes to BGP peers.
A router with route dampening enabled keeps track of all
routes and the penalties that are assigned to them. Each time
a flap occurs, the flapping route receives 1000 penalty
points; if the route penalties reach the suppress limit, the
route is no longer forwarded to other neighbors until the
assigned penalty has decayed below the reuse limit.
You can implement route dampening with the bgp dampening
command either globally in the BGP process or selectively
using a route-map.
BGP v3.27-20
Summary (Cont.)
Use the clear ip bgp flap-statistics command to delete all
penalty information without releasing the dampened paths.
The clear ip bgp dampening command clears dampening
information and releases suppressed routes.
The show ip bgp dampened-paths command lists all routes that
are currently suppressed because of dampening, the show ip
bgp flap-statistics command lists all routes that have a penalty
that is still above the time-to-forget limit, the show ip bgp flapstatistics prefix command displays detailed dampening
information about a specific network, the show ip bgp flapstatistics prefix mask longer-prefix command displays
dampening information about a specific network and its
subnets, and the debug ip bgp dampening command displays
BGP dampening events as they occur in real time.
BGP v3.27-21
7-83
Module Summary
Module Summary
Increased BGP convergence time and high CPU utilization
caused by the BGP scanner and BGP router processes can
be reduced with Cisco IOS tools such as peer groups and
PMTU discovery.
The maximum-prefix function is a scalable solution that limits
the number of routes that a BGP router can receive from a
specific neighbor.
Peer groups are a fundamental BGP scalability tool and
should be used in all environments where a router has a large
number of BGP neighbors.
Route dampening is a BGP feature that is designed to reduce
BGP processing requirements by minimizing the propagation
of unstable routes to BGP peers.
BGP v3.27-1
This module introduced advanced BGP configuration tools designed to improve BGP
scalability and performance. The first lesson described various Cisco IOS performance
improvements that have been designed to reduce BGP convergence time. The second lesson
explained how to configure BGP to limit the number of prefixes received from a neighbor. The
third lesson described how to use BGP peer groups to share common configuration parameters
between multiple BGP peers. The final lesson described how to utilize route dampening to
minimize the impact of unstable routes.
7-84
References
Cisco Systems, Inc. Cisco IOS IP and IP Routing Command Reference, Release 12.1.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/index.htm.
Griffin, T. and Wilfong, G.T. An Analysis of BGP Convergence Properties. SIGCOMM
1999.
Pei, D., Xiaoliang, Z., Wang, L., Massey, D. Mankin, A., Wu, S.F., and Zhang, L.
Improving BGP Convergence Through Consistency Assertions. 2002.
Cisco Systems, Inc. BGP Restart Session After Maximum-Prefix Limit.
http://www.cisco.com/en/US/partner/products/ps6566/products_feature_guide09186a00801
545d5.html .
Cisco Systems, Inc. BGP Peer Groups.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1c
bgp.htm#xtocid45.
Cisco Systems, Inc. BGP Case Studies. BGP Case Studies 4.
http://www.cisco.com/warp/public/459/bgp-toc.html#flapdampen.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1c
dbgp.htm#xtocid61.
7-85
Module Self-Check
Q1)
What are three characteristics of a converged BGP network? (Choose three.) (Source:
Improving BGP Convergence)
A)
B)
C)
D)
Q2)
Which two of the following modifications result in improved BGP convergence?

(Choose two.) (Source: Improving BGP Convergence)
A)
B)
C)
D)
Q3)
sends routing updates to BGP neighbors

walks the BGP table for routes to enter into the IP routing table
confirms the reachability of BGP next hops
scans the router configuration to establish and maintain BGP neighbors
One of your BGP core routers is experiencing periodic slow responses to ping packets
that are being directed to it from the network management console. The router has just
been configured to receive full Internet routes, and you suspect that the BGP router
process is causing CPU utilization issues in the core router. Which two router
commands should you use to confirm your suspicion? (Choose two.) (Source:
A)
B)
C)
D)
7-86
increasing the default value of BGP hold time

lowering the default value of BGP scan time
increasing the default value of the neighbor advertisement intervals
lowering the default value of the neighbor advertisement intervals
What is the main task of the BGP scanner process? (Source: Improving BGP
Convergence)
A)
B)
C)
D)
Q4)

All routes in the BGP table have been installed in the routing table.
The table version for all peers equals the table version of the BGP table.
show ip route
show ip bgp summary
show process cpu
show memory
Q5)
The output of a show interfaces fastethernet 0/0 command follows:

How has the interface been modified to improve BGP convergence? (Source:
A)
B)
C)
D)
Q6)
The output queue has been decreased to expedite packet forwarding out the
Fast Ethernet interface.
The drop threshold of the input queue has been set to begin randomly
discarding packets after the queue reaches 50 packets deep.
PMTU discovery has been enabled by setting the interface MSS to 1460 bytes.
The size of the input queue has been increased to support up to 500 incoming
packets.
Refer to the following Cisco IOS router output:

Which two parameters would indicate that the BGP network has converged? (Choose
two.) (Source: Improving BGP Convergence)
A)
B)
C)
D)
Q7)
The TblVer for all neighbors is 16.

V is set to 4 for all neighbors.
The InQ and OutQ for all neighbors is 0.
All neighbors are in the Established state and have the same PfxRcd value.
Using the command output from item 6, identify how frequently the BGP scanner
process will run on the router. (Source: Improving BGP Convergence)
A)
B)
C)
D)
By default, the process will run every 60 seconds.

The process has run 16 times and will run again when the next BGP update
arrives.
The process will run on this router every 120 seconds.
It cannot be determined from this output.
7-87
Q8)
What are two potential issues that are caused by modifying the default scan time and
advertisement interval on a BGP router? (Choose two.) (Source: Improving BGP
Convergence)
A)
B)
C)
D)
Q9)
Which two of the following statements about the EIGRP Nonstop Forwarding
Awareness feature are accurate? (Choose two.) (Source: Improving BGP Convergence)
A)
B)
C)
D)
Q10)
D)
The neighbor has exceeded the maximum number of allowed prefixes.

The maximum-prefix threshold has been reached.
The restart option has not been specified with the maximum-prefix
command.
The neighbor is more than one hop away.
Which two of the following characteristics accurately describe the show ip bgp
neighbors command? (Choose two.) (Source: Limiting the Number of Prefixes
Received from a BGP Neighbor)
A)
B)
C)
D)
7-88
to prevent denial-of-service attacks

to protect against incorrect router configuration on the neighbor side
to prevent redundant routing information from being loaded into the BGP table
to avoid overloading router memory and CPU resources
In which two situations would a directly connected BGP neighbor stay in the Idle state?
(Choose two.) (Source: Limiting the Number of Prefixes Received from a BGP
Neighbor)
A)
B)
C)
Q12)
NSF-aware routers are sometimes incompatible with non-NSF-aware or

-capable neighbors in an EIGRP network.
EIGRP NSF awareness must be enabled by an administrator.
The deployment of EIGRP NSF awareness can minimize the effects of wellknown failure conditions.
NSF awareness allows an NSF-aware router to assist NSF-capable and NSFaware neighbors to continue forwarding packets during a switchover operation
or during a well-known failure condition.
What are three reasons to limit the number of BGP prefixes that are received from a
neighbor? (Choose three.) (Source: Limiting the Number of Prefixes Received from a
BGP Neighbor)
A)
B)
C)
D)
Q11)
Router CPU resources can be exhausted.

Router memory resources can be depleted.
Routing loops are more likely.
BGP could converge faster than the IGP and cause network black holes.
for neighbors with the maximum-prefix function configured, displays the

maximum number of prefixes and the warning threshold
for neighbors exceeding the maximum number of prefixes, displays the reason
that the BGP session is idle
for neighbors with unstable routes, displays the feasible successor for those
routes
for neighbors in confederations, displays the route reflector status of those
neighbors
Q13)
What is the need for BGP peer groups? (Source: Implementing BGP Peer Groups)
A)
B)
C)
D)
Q14)
Which of the following statements about the benefit of BGP peer groups is accurate?
(Source: Implementing BGP Peer Groups)
A)
B)
C)
D)
Q15)
EBGP and IBGP neighbors cannot be members of the same peer group.
All routers in the peer group must belong to the same AS.
Peer group members cannot contain different outbound filtering mechanisms.
Peer group members must have the same inbound filtering mechanisms.
Which two of the following characteristics accurately describe BGP peer groups?
(Choose two.) (Source: Implementing BGP Peer Groups)
A)
B)
C)
D)
Q17)
With BGP peer groups, all of the router CPU utilization that is imposed by
BGP update generation is significantly reduced.
With BGP peer groups, some of the router CPU utilization that is imposed by
BGP update generation is significantly reduced.
Network administrators should use peer groups to make smaller networks more
productive.
With BGP peer groups, neighbor relationships are automatically created.
What are two limitations of BGP peer groups on Cisco routers? (Choose two.) (Source:
Implementing BGP Peer Groups)
A)
B)
C)
D)
Q16)
can be used to configure the same set of parameters for a number of BGP
neighbors in a common template
can be used to allow anonymous BGP neighbors
allow EBGP peers to be configured with the same AS number and parameters
can be used to hide the identity of BGP peers from external neighbors
A BGP peer group creates a neighbor parameter template.

When actual neighboring routers are assigned to the peer group on a router, all
of the attributes that are configured for the peer group are applied to selected
peer group members.
One of the configurable parameters includes community propagation.
Individual parameters specified in a peer group cannot be overridden on a
neighbor-by-neighbor basis.
Which two of the following characteristics accurately describe the function of the BGP
Dynamic Update Peer-Groups feature? (Choose two.) (Source: Implementing BGP
Peer Groups)
A)
B)
C)
D)
does not provide the operator with time to change the configuration if a
mistake is made
separates BGP update generation from peer-group configuration
does not require any configuration by the network operator
requires minimal configuration by the network operator
7-89
Q18)
Which two of the following statements accurately describe the function of the BGP
Configuration Using Peer Templates feature? (Choose two.) (Source: Implementing
BGP Peer Groups)
A)
B)
C)
D)
Q19)
What are three steps that are required to properly configure BGP peer groups on Cisco
routers? (Choose three.) (Source: Implementing BGP Peer Groups)
A)
B)
C)
D)
Q20)
split horizon
route dampening
synchronization
per-neighbor update timers
What are two things that happen to an EBGP route that has become unreachable when
BGP route dampening is used? (Choose two.) (Source: Using BGP Route Dampening)
A)
B)
C)
D)
7-90
a tool designed to help minimize the number of BGP updates

suppresses routes that occasionally flap
designed to reduce router processing load caused by unstable routes
prevents sustained routing oscillation, with some affect on other well-behaved
routes
Which two mechanisms are built into BGP to make it more scalable by reducing the
route-processing requirements of BGP routers? (Choose two.) (Source: Using BGP
Route Dampening)
A)
B)
C)
D)
Q23)
show ip bgp
show peer-group summary
show ip bgp neighbor
show ip bgp peer-group summary
Which two descriptions of the purpose of BGP route dampening are accurate? (Choose
two.) (Source: Using BGP Route Dampening)
A)
B)
C)
D)
Q22)
specify parameters for the BGP peer group

create a BGP peer group
enable the peer group by clearing the BGP session
assign a neighbor into the peer group
Which command do you use to display the summary status of all neighbors in a peer
group? (Source: Implementing BGP Peer Groups)
A)
B)
C)
D)
Q21)
Network operators must still configure some peer groups in BGP, even if using
the BGP Configuration Using Peer Templates feature.
Peer templates overcome all limitations of peer groups.
Peer templates improve the flexibility and enhance the capability of neighbor
configuration.
You can chain together peer template configurations to create simple or
complex configurations.
It is removed from the IP routing table.

It is removed from the BGP table.
It remains in the IP routing table as long as its penalty remains greater than 50
percent of the reuse limit.
It is kept in the BGP table and marked as a history entry
Q24)
What are two methods of enabling route dampening on a Cisco router? (Choose two.)
(Source: Using BGP Route Dampening)
A)
B)
C)
D)
Q25)
globally, by enabling route dampening in global router configuration mode

globally, by enabling route dampening under the BGP routing process
on specific routes by enabling route dampening on a specific interface
by using a route-map in the BGP process to apply route dampening to specific
routes
Which two things could happen to a BGP route that is penalized above the reuse limit
but has an assigned penalty that is under the suppress limit? (Choose two.) (Source:
Using BGP Route Dampening)
A)
B)
C)
D)
The route is suppressed from BGP updates if it is reachable.

The route is marked as a history entry in the BGP table.
The route is withdrawn from the IP routing table.
The route continues to be advertised.
7-91
7-92
Q1)
A, C, D
Q2)
B, D
Q3)
Q4)
B, C
Q5)
Q6)
A, C
Q7)
Q8)
A, B
Q9)
C,D
Q10)
A, B, D
Q11)
A, C
Q12)
A, B
Q13)
Q14)
Q15)
A, C
Q16)
A, C
Q17)
B, C
Q18)
C, D
Q19)
A, B, D
Q20)
Q21)
A, C
Q22)
B, D
Q23)
A, D
Q24)
B, D
Q25)
B, C
BGP
Configuring BGP on
Cisco Routers
Version 3.2
Lab Guide
CLS Production Servies: 12.29.05
Copyright
2005, Cisco Systems, Inc. All rights reserved.
Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax
numbers are listed on the Cisco Website at www.cisco.com/go/offices.
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica
Croatia Cyprus Czech Republic Denmark Dubai, UAE Finland France Germany Greece
Hong Kong SAR Hungary India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia
Mexico The Netherlands New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania
Russia Saudi Arabia Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland
Taiwan Thailand Turkey Ukraine United Kingdom United States Venezuela Vietnam Zimbabwe
Copyright 2005 Cisco Systems, Inc. All rights reserved. CCSP, the Cisco Square Bridge logo, Follow
Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live,
Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST,
BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering
the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive,
GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard,
LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar,
Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView
Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are
registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0501R)
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED AS IS. CISCO MAKES AND YOU RECEIVE NO
WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY
OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO
SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING,
USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be
accurate, it falls subject to the disclaimer above.
BGP
Lab Guide
Overview
This guide presents the instructions and other information concerning the lab activities for this
course. You can find the solutions in the lab activity Answer Key.
Outline
This guide includes these activities:
Lab 1-1: Initial Lab Setup
Lab 1-2: Configuring Basic BGP
Lab 2-1: Configuring a Transit AS
Lab 3-1: Using Multihomed BGP Networks
Lab 3-2: Employing AS-Path Filters
Lab 3-3: Filtering with Prefix-Lists
Lab 3-4: Implementing Changes in BGP Policy
Lab 4-1: Influencing BGP Route Selection with Weights
Lab 4-2: Setting BGP Local Preference
Lab 4-3: Understanding BGP Multi-Exit Discriminators
Lab 4-4: Addressing BGP Communities
Lab 6-1: Introducing Route Reflectors
Lab 6-2: Configuring and Monitoring Confederations
Lab 7-1: Limiting the Number of Prefixes Received from a BGP Neighbor
Lab 7-2: Implementing BGP Peer Groups
Lab 7-3: Using BGP Route Dampening
Answer Key
Lab 1-1: Initial Lab Setup

Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activity, you will perform initial router configuration, configure the interfaces on your
routers, and establish IGP connectivity across your core backbone. After completing this
activity, you will be able to meet this objective:
Prepare your workgroup to complete the lab activities in the Configuring BGP on Cisco
Routers (BGP) course
Visual Objective
The figure illustrates what you will accomplish in this activity.
Visual Objective for Lab 1-1:

Initial Lab Setup
BGP v3.23
The figure displays the physical connectivity within your workgroup. You have control over
routers WGxR1 through WGxR4. You can also telnet to other routers that are shown in the
figure, but you cannot configure them.
The first serial interface of each of your routers is connected to the Frame Relay switch. The
first (Fast) Ethernet interface of each router is connected to the LAN segment. All routers,
including the shared ones (Good, Cheap, and Client), have one serial link to the Frame Relay
switch.

Initial Lab Setup (Cont.)
BGP v3.24
The figure displays the logical connectivity of your workgroup. Frame Relay DLCIs are
already configured on the Frame Relay switch to provide this topology.
Required Resources
These are the resources and equipment required to complete this activity. Your workgroup
requires the following components:
Four Cisco 2610 routers with a WIC-1T and BGP-capable operating system software
installed.
Four CAB-X21FC + CAB-X21MT DTE-DCE serial cable combinations. The DCE side of
the cable is connected to the Cisco 3660.
Two Ethernet 10BASE-T patch cables.
IBM PC (or compatible) with Windows 95/98 and an installed Ethernet adapter.
The lab backbone requires the following components (supporting up to eight workgroups):
One Cisco 2610 router with a WIC-1T and BGP-capable operating system software
installed
Two Cisco 2610 routers with BGP-capable operating system software installed
One Cisco 3640 router with an installed NM-8A/S
Two Cisco Catalyst 2924M XL Ethernet switches
Three Ethernet 10BASE-T patch cables
Lab Guide
Command List
The table describes the commands that are used in this activity.
Command
Description
Configures an interface type and places you in interface

configuration mode
Administratively activates an interface
Sets a primary or secondary IP address for an interface
Enables and specifies the Frame Relay encapsulation

method
Assigns a DLCI to a specified Frame Relay subinterface

on the router or access server
Displays the statistical information specific to an

interface
Enables OSPF routing, which places you in router

configuration mode
Defines an interface on which OSPF runs, and defines

the area ID for that interface
Configures the OSPF network type for a specified

interface
Eases configuration of the lab by defining a static hostname-to-address mapping in the host cachea
suggestion would be to map to the loopback interface
with the highest IP address of each router
Eases configuration of the lab by disabling the IP DNSbased host-name-to-address translation
Job Aids
These job aids are available to help you complete the lab activity.
The laboratory is organized as a number of workgroups that are connected to two common
backbones:
ISP exchange point, also called the provider backbone, where two upstream service
providers are located
Client ISP backbone, where your customer is connected
Every workgroup has four routers, WGxR1, WGxR2, WGxR3, and WGxR4, where x is the
number of the workgroup. There are also three shared routers, Good, Cheap, and Client.
You will perform initial router configuration and prepare the routers for further activities.
During this procedure, configure passwords, serial interfaces, and IP addresses on each
router in your workgroup. You will also configure an IGP in your workgroup.
Task 1: Initial Lab Setup

In this activity, you will perform initial router configuration, configure the interfaces on your
routers, and establish IGP connectivity across your core backbone.
Activity Procedure
Complete these steps:
Step 1
Step 2
Perform initial configuration of your routers using the parameters in the following
table.
Parameter
Value
Host name
Use host names as shown in the second Visual

Objective figure (x is the number of your workgroup).
Enable password
Cisco
VTY password
Cisco
WAN link encapsulation
Frame Relay
WAN link bandwidth
128 kbps (configured on the Frame Relay switch)
Configure two loopback addresses on each of your workgroup routers with the IP
addresses from the following table.
Router
Interface
Address
Subnet Mask
WGxR1
Loopback 0
197.x.1.1
255.255.255.0
Loopback 1
197.x.8.1
255.255.255.0
Loopback 0
197.x.2.1
255.255.255.0
Loopback 1
197.x.3.1
255.255.255.0
Loopback 0
197.x.4.1
255.255.255.0
Loopback 1
197.x.5.1
255.255.255.0
Loopback 0
197.x.6.1
255.255.255.0
Loopback 1
197.x.7.1
255.255.255.0
WGxR2
WGxR3
WGxR4
Step 3
Note
Configure LAN IP addresses on WGxR1 and WGxR4 using parameters from the
following table.
Parameter
Value
ISP exchange point subnet
192.168.20.x, subnet mask 255.255.255.0
Client ISP subnet
192.168.21.x, subnet mask 255.255.255.0
Router Good has IP address 192.168.20.20, and router Cheap has IP address
192.168.20.22. They are shared by all workgroups. Router Client has IP address
192.168.21.99 and is shared by all workgroups. Frame Relay DLCIs have the same value
on both ends of the link.
Lab Guide
Step 4
Configure point-to-point Frame Relay subinterfaces on the Frame Relay links. The
IP addresses to be used on the link, as well as the DLCI values for the Frame Relay
virtual circuits, are shown in the following table.
First Router
IP Address
Second Router
IP Address
DLCI
WGxR1
192.168.x.1/30
WGxR2
192.168.x.2/30
100
WGxR2
192.168.x.5/30
WGxR3
192.168.x.6/30
101
WGxR3
192.168.x.9/30
WGxR4
192.168.x.10/30
102
Step 5
Configure IP host mappings to ease Telnet hopping between routers.
Step 6
Configure any IGP between your routers. Make sure that you do not use the IGP on
the backbone LANs.
Note
It is preferred that you use a classless IGP, such as OSPF, for this step.
Activity Verification
You have completed this task when you attain these results:
All router interfaces are active (line up, line protocol up).
You can telnet and ping between all core routers.
Lab 1-2: Configuring Basic BGP

Activity Objective
In this activity, you will configure BGP. After completing this activity, you will be able to meet
these objectives:
Configure initial BGP setup
Configure BGP neighbors
Announce local networks in BGP
Redistribute routes into BGP
Configure basic BGP route aggregation
Monitor the status of the BGP routing process
Monitor BGP neighbors
Monitor the BGP table
Visual Objective

BGP v3.25
The figure displays the BGP session that you will establish between WGxR1 and the Good
service provider.
Lab Guide
Required Resources
These are the resources and equipment required to complete this activity.
Your workgroup requires the following components:
installed.
installed
Command List
Command
Description
Places you in BGP configuration mode
Establishes a BGP session by using your workgroup

number as the AS number
Announces IP prefixes in BGP
Configures a static IP route
Defines or modifies an existing entry in a route-map
Matches routes in a route-map
Sets the origin in a route-map
Redistributes from your IGP into BGP
Creates summary prefixesuse the summary-only

keyword to suppress more-specific prefixes
Verifies whether the BGP session is up
Enables you to view detailed information about the

neighbor
Enables you to inspect the contents of the BGP table
Enables you to view detailed information about

prefixes (aggregates)

[]
Generates a default external route into an OSPF

routing domainto enable advertising of the default
route regardless of whether the software has a
default route, use the option always
Job Aids
You must connect to the Internet using BGP, ensuring that all users in your network have
Internet access. You will connect to a single service provider and statically announce the
address space that the Internet Registry has assigned to you.
Lab Guide
Task 1: Configuring BGP

In this task, you will configure your network backbone for basic BGP connectivity with a
service provider to establish BGP peering.
Activity Procedure
Step 1
Start the BGP process on WGxR1. Use your workgroup number as the AS number.
Step 2
Configure the Good router to be your BGP neighbor using the parameters in the
table.
Parameter
Value
Service provider IP address
192.168.20.20
Service provider AS number
20
Step 3
Announce the IP prefix 197.x.0.0/16 by configuring it in the BGP routing process.

Also announce network 192.168.x.0/24.
Step 4
Ensure that WGxR1 is the exit point for your pod and is originating a default route
for your IGP.
You have completed this activity when you attain these results:
You can verify that you have established a BGP session. Remember that it may take up to a
minute to establish a BGP session. Your display should resemble the following output.

You can view detailed information about the neighbor. Your display should resemble the
following output.

10

Note
The number of prefixes may vary, depending on the progress of other pods.
You can see a large number of networks being advertised by the Good provider when you
inspect the contents of the BGP table on your router. Your display should resemble the
following output.

Networks

originating in
AS 3. Origin

code is

incomplete

because

networks are

redistributed.

Network

originating

in AS 2.
You can telnet from WGxR1 into the router Good and verify that it is receiving your
networks over BGP.
You can verify that you are receiving networks that are announced by other customers.
Lab Guide
11
You can perform ping and trace from WGxR4 to 192.20.11.1 (an Internet destination that is
announced by router Good).
Answer these questions:
Q1)
What do you need in order to propagate classful networks?
Q2)
What do you need in order to propagate classless networks (supernets or subnets)?
Q3)
Why do some networks that are received from router Good have a next-hop address
pointing to other routers?
Q4)
What command would you use to see whether a neighbor is sending you any updates
and how many?
Task 2: Configuring Route Redistribution in BGP

Your network has grown, and you can no longer rely on manually configuring your address
space in the BGP process. In this task, you will use redistribution to announce a large number
of networks into the BGP routing process. You will also use route-maps to set the origin of
BGP routes to IGP instead of incomplete.
In this task, you will remove all networks from your BGP definitions (from Task 1) and
announce them by using redistribution from your IGP into BGP with a route-map, which sets
the origin code to IGP. Make sure that you do not announce the 192.168.20.0/24 and
192.168.21.0/24 networks into BGP.
Activity Procedure
Step 1
Remove all BGP network statements from the previous activity.
Step 2
Telnet to router Good and verify that it no longer receives your networks.
Step 3
Configure an access-list that permits all your networks except those that are shared
among workgroups.
Step 4
Configure a route-map. Use the new access-list with a match command in the routemap. Use the set command in the route-map to set the origin to IGP.
Note
Step 5
Route-maps will be covered in detail in the module Route Selection Using Policy Controls.
Configure redistribution from your IGP into BGP by using the previously configured
route-map.
You can log in to the service provider router (Good) and verify that it receives proper
networks from you. Your display should resemble the following output.
12
Individual subnets
are seen if
no auto-summaryc
ommand is used in
BGP.
You can ensure that you are not originating networks 192.168.20.0/24 and 192.168.21.0/24.
You can verify that your networks are removed from the BGP table when they become
unavailable (try shutting down one of the loopback interfaces).
Q1)
What is the major difference between this implementation and the previous one?
Which is better and why?
Q2)
What precautions do you have to take when using redistribution?
Task 3: Configuring BGP Aggregation

Your ISP has requested that you provide only summarized prefixes for your address range
197.x.0.0. However, because of diagnostic needs, you still need to announce the network
197.x.8.0.
In this task, you will configure BGP aggregation as requested, using the aggregate-address
command.
Activity Procedure
Step 1
Log in to the router Good; verify that the ISP sees all your individual loopback
networks.
Step 2
Use the aggregate command in your BGP process to aggregate the 197.x.0.0
network as requested by your ISP.
Lab Guide
13
Note
Use the keyword summary-only if you do not want to announce individual prefixes.
You can verify that the correct routing information is present by checking the BGP table on
your router WGxR1
You can log in to the service provider (Good) router and check its BGP table to see that
suppressed networks should not be visible on router Good.
You can view detailed information about one of the aggregates.
14
Q1)
Do you see all your prefixes on the provider router? Why?
Q2)
What do you need to be able to generate and propagate aggregate routes?
Lab 2-1: Configuring a Transit AS

Activity Objective
In this activity, you will enable a service provider network with multiple BGP connections to
other autonomous systems to behave as a transit AS. After completing this activity, you will be
Plan the migration of an existing backbone toward a fully meshed IBGP backbone that is
designed for transit traffic
Configure IBGP sessions between loopback interfaces
Configure BGP synchronization to ensure successful IBGP operation of the transit AS
Monitor IBGP operation
Visual Objective

BGP v3.26
The figure displays the required BGP connectivity within your AS and the BGP sessions with
your customer and your upstream ISPs.
Lab Guide
15
Required Resources
installed.
installed
Command List
Command
Description
Establishes an IBGP session by using your workgroup

Uses the IP address of the specified interface as the

source address for the BGP session
Enables you to use a regular expression to filter the

output of the show ip bgp command
Configures the router as the next hop for a BGPspeaking neighbor
Disables synchronization of IGP and BGP routes
Job Aids
With the rapid growth of the Internet, you decide to become an ISP, and you already have
your first customer.
In this activity, you will transform your network into a transit AS that runs BGP on all core
routers.
16
Configure a full mesh of IBGP sessions between all routers in your AS. Establish these
BGP sessions between Loopback 0 interfaces.
Task 1: Configuring the BGP Transit AS

In this task, you will configure your network backbone as a fully meshed IBGP backbone
acting as a transit AS.
Activity Procedure
Step 1
Clean up your BGP configuration by removing the BGP process and the default
route from the IGP on WGxR1. You may also remove the access-list and route-map.
Step 2
Start the BGP process on all routers in your workgroup.
Step 3
Advertise your prefixes (loopbacks, 197.x.0.0/16, and 192.168.x.0/24) in BGP on

routers WGxR1 and WGxR4.
Step 4
Re-establish the neighbor relationships to router Good without any filters on router
WGxR1. Use the parameters from the following table.
Step 5
Router
AS Number
IP Address
Good
20
192.168.20.20
Establish a BGP session with router Client on router WGxR4. Use the parameters
from the following table.
Parameter
Value
Client IP address
192.168.21.99
Client AS number
99
Step 6
Configure all routers in your workgroup as IBGP neighbors (IBGP full mesh). Use
loopback interfaces to establish these IBGP sessions. (Make sure synchronization
has been turned off, answering the no synchronization command.)
Step 7
Ensure EBGP reachability by all IBGP-speaking routers within your transit AS

without redistributing the connected interfaces of either external Ethernet.
You can check BGP on all core routers and the router Client and ensure that they have
established the correct sessions with their peers. Your display should resemble the
following output.

Lab Guide
17
You can check the BGP table on router Client and verify that it is correctly receiving BGP
routes. Your display should resemble the following output.

You can use traceroute from router WGxR1 to the loopback interface on router Client
(197.99.1.1). You should see a path similar to this one:

18

Q1)
Check the BGP table on router Client. How many prefixes coming from your AS are in
that BGP table?
Q2)
Is there any other way of discovering how many prefixes you have advertised to the
router Client?
Q3)
Why did you have to disable synchronization?
Q4)
Why did you have to establish a full mesh of IBGP sessions?
Lab Guide
19
Lab 3-1: Using Multihomed BGP Networks

Activity Objective
In this activity, you will configure BGP as part of a customer scenario where you must support
connections to multiple ISPs. After completing this activity, you will be able to meet these
objectives:
Configure BGP neighbors to support a multihomed customer scenario
Monitor the status of the BGP routing process
Monitor BGP neighbors in a multihomed customer scenario
Visual Objective

Using Multihomed BGP Networks
BGP v3.27
The figure shows the connectivity that you need to establish for the second BGP session with
the new provider router (Cheap).
Required Resources
installed.
20
installed
Command List
Command
Description
Starts a BGP session with the neighboring AS
Assigns a weight to all updates that are received

from the specified neighbor
Verifies the state of BGP sessions
Enables you to inspect the contents of the BGP

table
Job Aids
You have started to provide mission-critical e-commerce services, and you must ensure
their high availability. You decide to connect to a new ISP, Cheap, using Cheap as your
primary ISP and Good as your backup ISP.
Task 1: Configuring Multihomed BGP Networks

In this activity, you will configure BGP as part of a customer scenario where you must support
connections to multiple ISPs.
Activity Procedure
Step 1
Remove BGP from routers WGxR2, WGxR3, and WGxR4. Leave only the existing
EBGP session on router WGxR1 to Good. Because only WGxR1 is running BGP,
enable synchronization and restore IGP default routing for your pod.
Lab Guide
21
Step 2
Step 3
Configure the second BGP neighbor on WGxR1 using the parameters in this table.
Service Provider
Parameter
Value
Cheap
AS number
22
IP address
192.168.20.22
Change the default weight on neighbor Cheap to 100 using the neighbor ip-address
weight command to give preference to routes that are announced from router Cheap
over those announced from router Good. (Do not forget to refresh your BGP routes.)
Note
BGP weights are covered in detail in the module Route Selection Using Attributes and its
supporting lab activities.
You can verify that both BGP sessions are up. Your display should resemble the following
output.

Both sessions are

up, and 23 prefixes

were received from

both neighbors.

You can check all the BGP prefixes with two paths to verify that your router prefers the
one through router Cheap. Your display should resemble the following output.

Both paths have

the same next-hop
address.
22

Q1)
What can happen if a multihomed AS is passing routing information learned from one
neighbor to another neighbor?
Q2)
Why do some prefixes have two paths but both use the same next-hop address?
Lab Guide
23
Lab 3-2: Employing AS-Path Filters

Activity Objective
In this activity, you will configure BGP to influence route selection using AS-path filters where
connections to multiple ISPs must be supported. After completing this activity, you will be able
to meet these objectives:
Identify where you can apply an AS-path filter when configuring a router to influence route
selection
Configure AS-path filters to influence route selection
Monitor the operation of configured AS-path filters
Visual Objective

BGP v3.28
The figure shows the structure of the autonomous systems beyond AS 20 and AS 22. This
information will assist you in your verification and any troubleshooting steps.
Required Resources
installed.
24
installed
Command List
Command
Description
Filters incoming or outgoing updates with the

specified AS-path filter
Specifies the AS-path filter

table

Enables you to check a filter
Clears the BGP session
Job Aids
Your service providers complain that you propagate routes between them and that you
could potentially become a transit network.
You have also discovered that the service provider Cheap does not provide you with good
connectivity to your users in AS 213. Therefore, you want to accept the routes originating
in AS 213 only from the provider Good.
Customers in AS 214 request that you use only the provider Cheap to communicate with
them because of security reasons.
Use AS-path filters to filter incoming routes and to limit propagation of transit routes.
Select routes between the Good and Cheap service providers based on the following
criteria:
Accept routes originating in AS 213 only from router Good.

Lab Guide
25
Accept routes with AS 214 in the AS path only from router Cheap.
Ensure that you do not act as a transit AS between the two service provider routers
(Good and Cheap).
Task 1: Configuring AS-Path Filters

In this activity, you will configure BGP to influence route selection using AS-path filters where
connections to multiple ISPs must be supported.
Activity Procedure
Step 1
Log in to the Good and Cheap routers and verify the service provider claims that you
propagate the routes between them. Your display should resemble the following
output.
Router Good:
Router Cheap:
Configuring AS-path access-lists:

Step 2
With the ip as-path access-list command, configure an AS-path access-list to deny

routes that have number 213 as the last number in the AS path. The filter should
permit all other routes.
Step 3
Configure another AS-path access-list to deny routes that contain number 214 as the
last number in the AS path. The filter should permit all other routes.
Step 4
Configure an AS-path access-list to permit prefixes originating in your AS and deny

all other prefixes.
The BGP table showing prefixes that have 213 or 214 in their path (before applying the ASpath filters) should look like this:

26
Applying AS-path access-lists:

Step 5
Apply the AS-path access-lists that you configured in the previous steps to your
BGP neighbors.
You can verify that all paths containing AS 213 are received only from router Good and
that all paths containing AS 214 are received only from router Cheap. Your display should
resemble the following output.

You can verify that routers Good and Cheap are not receiving any prefixes that do not
originate in your AS. Your display should resemble the following output.


Lab Guide
27
28
Q1)
By this time, the BGP table should contain a large number of prefixes. What regular
expression would you use with the show ip bgp command on WGxR1 to view the
prefixes that are originated by your AS?
Q2)
What regular expression would you use on router Good or Cheap to view the prefixes
that originate in your AS?
Q3)
that are received from your AS?
Q4)
How can you test your AS-path filters before applying them and clearing BGP
neighbors?
Lab 3-3: Filtering with Prefix-Lists

Complete this lab activity to practice what you have learned in the related module.
Activity Objective
In this activity, you will configure BGP to influence route selection using prefix-list filters
where you must support connections to multiple ISPs. After completing this activity, you will
be able to meet these objectives:
Configure filtering of inbound or outbound updates with prefix-lists
Modify configured prefix-list filters
Monitor the operation of configured prefix-list filters
Visual Objective

BGP v3.29
The figure shows the connectivity that is established between your AS and the two service
providers Good and Cheap.
Required Resources
installed.
Lab Guide
29
installed
Command List
Command
Description
Enables you to create an entry in a prefix-list
Filters incoming prefixes

table

Displays a BGP routing table based on the contents

of the prefix-list
Job Aids
The memory consumption on WGxR1 has increased because of the large BGP tables that
have been received from your service providers. You realize that the service providers
announce a large number of very small prefixes to you. Some of the announced prefixes are
also in the private IP (RFC 1918) address space.
In this activity, you will minimize the size of the BGP table on your router with inbound
filters that are implemented with prefix-lists. You will also filter any prefixes in the private
IP address space that you might receive from your service providers.
Your analysis shows that you must perform the following tasks to minimize the size of the
BGP table on router WGxR1:
30
Do not accept any subnets of class B networks from router Cheap.

Do not accept class C networks or their subnets from router Good.
Do not accept any private networks (RFC 1918) from either neighbor.
Use prefix-lists to perform these tasks.
Task 1: Filtering with Prefix-Lists

In this activity, you will configure BGP to influence route selection using prefix-list filters
where you must support connections to multiple ISPs.
Activity Procedure
Step 1
Verify that your current BGP table looks somewhat like the following:
Configuring prefix-lists:
Step 2
Based on your analysis, create prefix-lists to filter incoming updates from routers
Good and Cheap.
Lab Guide
31
Applying prefix-lists:
Step 3
Apply the prefix-lists that you have created to updates coming from routers Good
and Cheap. (Dont forget to refresh your BGP routes.)
You can inspect your BGP table and check the proper operation of your prefix-list filters. If
your Cisco IOS software version is Release 12.2(11)T or later, you can also issue the show
ip bgp prefix-list prefix-list-name command. Your display should resemble the following
output.

Full BGP table:

32

Q1)
Are neighboring workgroups still reachable?
Q2)
Why does router WGxR1 still accept class B networks from router Cheap?
Lab Guide
33
Lab 3-4: Implementing Changes in BGP Policy

Activity Objective
Note
The latest versions of Cisco IOS software include a route refresh capability using the clear
ip bgp command. If a router is running an earlier version of Cisco IOS software, however,
then it is necessary to configure the soft reconfiguration feature to minimize the impact of
expediting BGP policy updates.
In this activity, you will configure the soft reconfiguration feature to minimize the impact of
expediting BGP policy updates in a network scenario where you must support connections to
multiple ISPs. After completing this activity, you will be able to meet these objectives:
Configure and perform a soft reconfiguration
Monitor the operation of a soft reconfiguration
Visual Objective

Implementing Changes in BGP Policy
BGP v3.210
The figure displays the required BGP connectivity within your workgroup, as well as the BGP
sessions with two different service providers.
34
Required Resources
installed.
installed
Command List
Command
Description
Enables inbound soft reconfiguration

table
Shows detailed information about a specific

neighbor
Enables you to view all updates that are received

from the specified neighbor (before filters)
Enables you to use a regular expression to filter

the output of the show ip bgp command
Lab Guide
35
Note
Routers running Cisco IOS software releases prior to Release 12.1 do not support the route
refresh capability and must clear the BGP session using the neighbor soft-reconfiguration
command. Clearing the BGP session using the neighbor soft-reconfiguration command
has a negative effect on network operations and should only be used as a last resort.
Routers running Cisco IOS Software Release 12.1 or later releases support the route
refresh capability and dynamic soft resets, and can use the clear ip bgp {* | address | peergroup name} in command to clear the BGP session. To determine whether a BGP router
supports this capability, use the show ip bgp neighbors command. If a router supports the
route refresh capability, the following message is displayed: Received route refresh
capability from peer.
Job Aids
Your customers complain that they are sometimes unable to reach your e-commerce
servers. You suspect that the frequent changes in your BGP routing policies might be the
reason, and you would like to implement a mechanism that enables you to perform
nondisruptive changes in routing policies. Unfortunately, your service providers run a
Cisco IOS release that does not support BGP route refresh functionality.
In this activity, you will configure soft reconfiguration to enable nondisruptive changes in
BGP routing policies.
Task 1: Configuring Soft Reconfiguration

In this activity, you will configure the soft reconfiguration feature to minimize the impact of
expediting BGP policy updates in a network scenario where you must support connections to
multiple ISPs.
Activity Procedure
Step 1
Before you begin, check to ensure that soft reconfiguration is not configured. Your
display should resemble the following output.
Step 2
Note
36
Enable inbound soft reconfiguration on WGxR1 to both neighbors Good and Cheap.
Using the neighbor soft-reconfiguration command may require your router to have much
more memory than normally needed.

Lab Guide
37
38
Q1)
What command do you use to show which entries in the BGP table of the local router
have been propagated to a specific neighbor?
Q2)
What command do you use to display which of the routes in the local BGP table have
been received and accepted from an indicated neighbor?
Lab 4-1: Influencing BGP Route Selection with

Weights
Activity Objective
In this activity, you will configure BGP to influence route selection by using the weight
attribute in a situation where you must support connections to multiple ISPs. After completing
this activity, you will be able to meet these objectives:
Influence the BGP route selection process by configuring per-neighbor weights
Influence the BGP route selection process by configuring BGP weights with route-maps
Monitor BGP route selection and weights
Visual Objective

Influencing BGP Route Selection with Weights
BGP v3.211
Lab Guide
39
Required Resources
installed.
installed
Command List
Commands
40
Command
Description
Assigns a weight to all updates that are received

from the specified neighbor
Applies a route-map to incoming or outgoing routes
Specifies route-map matching criteria to match an

AS-path access-list
Sets the weight in a route-map
Verifies that both BGP sessions are up

table
Clears the BGP session with your neighbor
Job Aids
Currently, you are using the service provider Cheap as your primary provider for Internet
connectivity and the service provider Good as your backup provider. As a result of this
policy, the link toward the Good service provider is underused, while the link toward the
provider Cheap is overloaded.
An analysis of the Internet structure beyond your service providers indicates that you can
improve the link use if you send traffic toward AS 213 and AS 37 directly to the Good
service provider.
In this activity, you will improve the simple routing policy that you created in the lab
activity Using Multihomed BGP Networks by specifying BGP weights with route-maps.
You must implement the following routing policy:
Prefer routes announced from router Cheap over those announced from router Good.
Prefer routes going through or originating in AS 213 or AS 37 from router Good.
Task 1: Influencing BGP Route Selection with Weights

In this activity, you will configure BGP to influence route selection by using the weight
attribute in a situation where you must support connections to multiple ISPs.
Activity Procedure
Configuring AS-path access-lists:
Step 1
Create an AS-path access-list that permits either AS number 213 or 37 in the AS

path (one is sufficient).
Setting per-neighbor default weights:

Step 2
(Optional) Set default weights for both neighboring routers. For example, use 100
for Good and 200 for Cheap as weights.
Step 3
Inspect your BGP table to verify that you prefer routes coming from Cheap to routes
coming from Good.
Using AS-path filters within route-maps to set weights:

Step 4
Create a new route-map. Use the previously configured AS-path access-list as the
match condition in one of the route-map statements, and set the weight of matched
routes as needed. Remember that routes matching this AS-path access-list from
Good should give the highest weight; therefore, you might use 300 for the weight.
Step 5
Apply the route-map to incoming updates from router Good.
You can verify your BGP table to see that all prefixes with two paths prefer the one
through router Cheap. Your display should resemble the following output.
Lab Guide
41
42
Q1)
Did all paths automatically get a weight of 100 or 200? Why not? What did you have to
do?
Q2)
Name some parameters and attributes that are used for best-path selection.
Lab 4-2: Setting BGP Local Preference

Activity Objective
In this activity, you will configure BGP to influence route selection using the local preference
attribute in a situation where you must support multiple connections to an ISP. After
completing this activity, you will be able to meet these objectives:
Configure BGP local preference using route-maps
Monitor BGP local preference
Visual Objective

BGP v3.212
The figure shows the new physical connectivity, BGP sessions, and the expected traffic flow in
the network.
Required Resources
installed.
Lab Guide
43
installed
Command List
Commands
Command
Description
Disables BGP synchronization
Applies a route-map to incoming or outgoing routing

updates
Sets the local preference attribute within a routemap

table

Restarts the BGP session with your BGP neighbor
Job Aids
You want to have two links with the Good service provider to increase the reliability of
your Internet service. With several links that connect you to the same service provider, you
must use local preference in your AS to ensure consistent AS-wide routing policy.
In this activity, you will establish a second link toward the Good service provider and use
the local preference attribute to select the newly established link as the preferred exit point
from your network.
The additional link that you establish will connect WGxR2 and the Good router through the
Frame Relay network. You will configure an EBGP session between WGxR2 and Good
over this link. All traffic from your AS toward Good should flow over this link.
44
On WGxR2, use DLCI 20x and IP address 192.168.3x.1/30 for the Frame Relay link
connection. The other side of this PVC is connected to router Good, which is already
configured.
The BGP routing design contains the following items:
AS x should prefer AS 20 as the upstream service provider. Router WGxR2 should

be used as the exit point under normal circumstances.
Peering to AS 20 through WGxR1 should be used only if the primary link fails.
Task 1: Setting BGP Local Preference

In this activity, you will configure BGP to influence route selection using the local preference
attribute in a situation where you must support multiple connections to an ISP.
Activity Procedure
Configuring additional IP connectivity:
Step 1
Create another point-to-point subinterface on WGxR2 using the parameters from the
following table.
Router
IP Address
DLCI
WGxR2
192.168.3x.1/30
20x
Establishing EBGP peering between WGxR2 and router Good:

Step 2
Configure the router Good as the EBGP neighbor by using the parameters from the
following table.
Parameter
Value
Service provider IP address
192.168.3x.2
Service provider AS number
20
Establishing full-mesh IBGP:

Step 3
Establish IBGP sessions between all routers in your pod with disabled
synchronization. Remember to use the good practice of implementing a stable
loopback interface address for peering.
Step 4
Remember that external networks are not carried in your IGP. Remember, the
networks need to be advertised in the IGP.
Using local preference to ensure AS-wide routing policy:

Step 5
On WGxR1, remove neighbor weight statements and any route-map statements that
modify the weight attribute on WGxR1 for the routers Good and Cheap.
Step 6
Create a new route-map on router WGxR2. Within the route map, set the local
preference higher than the default value of 100 (for example, 200).
Step 7
Apply the route-map to incoming updates from router Good.
Lab Guide
45
Step 8
Perform clearing of the BGP session between the routers by using the clear ip bgp *
command. Use a soft clearing of WGxR1 if you still have soft inbound
reconfiguration enabled.
On WGxR2, you can verify that the local preference has been changed and also note the
IBGP routes. Your display should resemble the following output.

You can use the traceroute command from router WGxR4 and WGxR1 to 192.20.11.1.
Your display should resemble the following output.

46
You can use traceroute from router Good to interface loopback0 on routers WGxR4 and
WGxR1. (Note that this result might depend on the age of the EBGP sessions from Step 8
above [oldest EBGP path that was selected] and necessitate clearing of the router Good
peer with WGxR2 to demonstrate asymmetrical routing. The next lab will address these
issues.)
Note
You may need to use an extended traceroute from router Good. Use the command
traceroute 197.1.7.1 source lo 0.

You can compare the two outputs of the traceroute command to determine whether the
routing is symmetrical. Both traceroute commands should show router WGxR2 in the
path.

Q1)
Is routing between router WGxR1 and Good symmetrical?
Q2)
Which routers receive the local preference attribute?
Lab Guide
47
Lab 4-3: Understanding BGP Multi-Exit

Discriminators
Activity Objective
In this activity, you will configure BGP to influence route selection using the MED attribute in
a situation where you must support multiple connections to an ISP. After completing this
activity, you will be able to meet these objectives:
Configure the BGP MED using route-maps
Monitor the BGP MED
Visual Objective

Understanding BGP Multi-Exit Discriminators
BGP v3.213
The figure shows the physical connectivity, BGP sessions, and traffic flow in the network.
Required Resources
installed.
48
installed
Command List
Commands
Command
Description

updates
Sets the MED in a route-map
Resets the BGP peer

table

Job Aids
You have noticed that the traffic from router Good toward your AS sometimes passes
through the router WGxR1, resulting in asymmetrical routing. You will use the MED to
indicate to the Good router the exit point that it should use.
Note
This activity is a continuation of the previous lab activity.
The implementation should ensure symmetrical routing. You should use backup peering
only when the primary link is down. Use the MED to influence neighboring AS 20 to
choose the preferred return path.
Lab Guide
49
Task 1: Configuring BGP Multi-Exit Discriminators

In this activity, you will configure BGP to influence route selection using the MED attribute in
a situation where you must support multiple connections to an ISP.
Activity Procedure
Step 1
Before starting the activity, check the BGP table for router Good to see whether the
MED is present in BGP updates that are received from WGxR1 and WGxR2.
Configuring WGxR1 to set the MED:

Step 2
Create a new route-map, which sets the BGP MED to a high value (for example,
200). Apply the route-map to outgoing updates toward the router Good.
Configuring WGxR2 to set the MED:

Step 3
Create a new route-map, which sets the BGP MED to a low value (for example,
100). Apply the route-map to outgoing updates toward the router Good.
You can check the BGP table on router Good to see whether the MED is present in BGP
updates that are received from WGxR1 and WGxR2. Your display should resemble the
following output.
Note
Remember to advertise your networks.
50

You can use the traceroute command from routers WGxR4 and WGxR1 to 192.20.11.1.

You can use the traceroute command from router Good to interface loopback1 on routers
WGxR4 and WGxR1. Your display should resemble the following output.

You can compare the two outputs of the traceroute command to determine whether the
routing is symmetrical. Both traceroute commands should show router WGxR2 in the
path.
Lab Guide
51
52
Q1)
Which parameters and attributes have to be equal before the MED is compared to
select the best path?
Q2)
What is the default value of the MED?
Lab 4-4: Addressing BGP Communities

Activity Objective
In this activity, you will configure BGP to influence route selection by using the BGP
community attribute in a situation where you must support multiple connections to an ISP.
After completing this activity, you will be able to meet these objectives:
Configure route tagging by using BGP communities
Configure BGP community propagation
Monitor BGP communities
Visual Objective

BGP v3.214
The figure shows the physical connectivity, BGP sessions, and traffic flow in the network.
Required Resources
installed.
Lab Guide
53
installed
Command List
54
Commands
Command
Description

updates
Matches communities in a route-map by using a

community-list
Sets community attributes in a route-mapuse the

keyword additive to append communities instead of
replacing them
Sets local preference attribute
Configures BGP communities using as:nn format
Creates a community access-list

Enables you to view BGP routes that have at least one

community attribute or those that are specified in the
command
Enables you to view BGP routes that are permitted by

the specified community-list
Enables community propagation to BGP neighbors
Disables communication with a BGP neighbor
Lab Guide
55
Job Aids
Your second service provider Cheap has upgraded its link to your network to match that of
the provider Good. You decide to change your route selection policy to use the newly
updated link from Cheap. As a result of the new service that is available from Cheap, you
decide to remove the backup link to provider Good because you can now achieve both link
and provider redundancy.
You wish for all outgoing traffic to continue using the link to Good, but all return traffic
should use the newly updated link from Cheap. Knowing that you have a connection to the
provider Good, you still wish to use the primary connection to Good for return traffic
should the link to provider Cheap fail.
You cannot influence return path selection across multiple providers, and you solicit
assistance from provider Good. Provider Good agrees to set local preference for any routes
that you mark as follows:
Local preference of 50 for routes marked with a community attribute of x:20
Task 1: Configuring BGP Communities

In this activity, you will configure BGP to influence route selection by using the BGP
community attribute in a situation where you must support multiple connections to an ISP.
Activity Procedure
Step 1
Before starting this lab, use the traceroute command from router Good to 197.x.7.1.
The trace should match this display (where x is your workgroup number):

Step 2
Remove the BGP neighbor statement on WGxR1 for router Good or simply disable
communication via the neighbor shutdown command.
Configuring BGP community propagation:

Step 3
Configure BGP community propagation on router WGxR2.
Step 4
Enable your WGxR2 router to configure communities using the as:nn format.
Configuring outbound filters on WGxR2:
56
Step 5
Create a route-map to set the community attribute on all BGP updates that are sent
from WGxR2 to the provider Good. Set the community attribute to x:20, where x is
your workgroup number.
Step 6
Apply the route-map to the BGP neighbor Good in the outbound direction.
You can log in to the router Good and verify that the BGP community attribute has been
correctly set. Your display should resemble the following output.

You can log in to router Good and perform the same traceroute that was done before you
started the configuration in this lab. Your display should resemble the following output.

Note
Normally, you would expect to see that the first line of the traceroute shows Cheap as the
first hop. However, because the routers Good, Cheap, and WGxR1 share a common
Ethernet segment, the BGP next-hop rule states the following: If the current BGP next hop is
in the same IP subnet as the receiving router, the next hop is not changed; otherwise, it is
changed to the IP address of the sending router. The next-hop rule applies even when there
is no BGP connection between Good and WGxR1.
On router Good, you can execute the command: show ip bgp 197.1.7.1. Your display
should resemble the following output.

Note that the best path, because of local preference, is the bottom route, and the next hop is
192.168.20.22 (Cheap), but because of the shared media, the next hop has not been changed.
This result is true even though the AS-path length is longer, because local preference is a
stronger route-selection tool.
Q1)
What do you have to do to enable community propagation?
Lab Guide
57
Q2)
58
What mechanisms can you use to match or set communities?
Lab 6-1: Introducing Route Reflectors

Activity Objective
In this activity, you will enable route reflectors to modify IBGP split-horizon rules in a transit
AS. After completing this activity, you will be able to meet these objectives:
Plan the migration of an existing IBGP backbone to a backbone with route reflectors
Configure BGP route reflectors on a BGP backbone
Monitor a BGP backbone that contains route reflectors
Visual Objective

BGP v3.215
The required IBGP sessions and the cluster structure are outlined in the figure.
Required Resources
installed.
Lab Guide
59

installed
Command List
Commands
Command
Description
Specifies the cluster-ID
Establishes an IBGP session by using your workgroup


Job Aids
In this activity, you will replace the IBGP full mesh with a hierarchy of BGP route
reflectors.
Configure IBGP sessions in your AS according to this design:
60
Cluster 1 is your top-level cluster. Within this cluster, router WGxR3 is the route
reflector, and WGxR2 is the client.
WGxR2 is the route reflector in cluster 2, and WGxR1 is its client.
Router WGxR4 is not participating in any cluster and needs to be in IBGP full mesh
with top-level route reflectors.
Task 1: Configuring Route Reflectors

In this activity, you will enable route reflectors to modify IBGP split-horizon rules in a transit
AS.
Activity Procedure
Cleaning up your BGP configurations:
Step 1
Remove the EBGP session on WGxR2 to router Good. Remember to remove nexthop-self because EBGP is no longer configured.
Step 2
Enable the shutdown neighbor from WGxR1 to Good or reconfigure if the neighbor
statement was removed.
Step 3
Configure EBGP from WGxR4 to router Client as 192.168.21.99 with AS 99.

Remember that the external network is not announced in your IGP.
Option: WGxR1 filters to Good and Cheap can be removed or left intact.
Configuring the top-level route reflector WGxR3:

Step 4
Configure cluster-ID 101 on the top-level route reflector WGxR3. Configure the
client on WGxR3 and remove unnecessary IBGP sessions.
Configuring the second-level route reflector WGxR2:

Step 5
Configure cluster-ID 102 on WGxR2. Configure the client on WGxR2 and remove
unnecessary IBGP sessions from WGxR2.
Removing unnecessary BGP neighbors from your AS:

Step 6
Remove the IBGP sessions that are no longer needed from routers in your pod.
You can check your BGP connections on the core routers and ensure that they are
connected only to the peers, as shown in the lab diagram. Your display should resemble the
following output.

Lab Guide
61
You can check to see whether router Client is receiving networks from your network. The
command output will vary depending on filters. Your display should resemble the
following output.

You can check to see whether the cluster-list attribute is applied to routes passing through
the AS. Your display should resemble the following output.

62

Q1)
Did this design require you to configure a cluster-ID?
Q2)
What is the default cluster-ID?
Q3)
When do you have to configure a cluster-ID?
Lab Guide
63
Lab 6-2: Configuring and Monitoring

Confederations
Activity Objective
In this activity, you will enable confederations to modify IBGP AS-path processing in a transit
AS. After completing this activity, you will be able to meet these objectives:
Plan the migration of an existing IBGP backbone toward BGP confederations
Configure BGP confederations on a BGP backbone
Monitor a BGP backbone containing BGP confederations
Visual Objective

Configuring and Monitoring Confederations
BGP v3.216
The AS numbers that will be used in the confederation, as well as the BGP sessions that must
be established, are shown in the figure. Routers in member autonomous systems should
originate their own networks. The sessions should be established on the routers between
Loopback0 interfaces as shown in the figure.
64
Required Resources
installed.
installed
Three Ethernet 10-BASE-T patch cables
Command List
Lab Guide
65
Commands
Command
Description
Specifies the real AS number
Lists the neighboring intra-confederation autonomous

systems

Configures a BGP neighbor
Configures the source interface of a BGP session
Configures an EBGP session between neighbors that

are not directly connected
Job Aids
To successfully complete this activity, you must remove all BGP processes and start new
processes with private AS numbers according to this table.
Router
Member-AS Number
WGxR1
AS 65001
WGxR2, WGxR3
AS 65002
WGxR4
AS 65003
AS 99 should receive only prefixes that originate in your AS x and AS 37. You should
accept only prefixes that originate in AS 99 from router Client.
Task 1: Configuring Confederations

In this activity, you will enable confederations to modify IBGP AS-path processing in a transit
AS.
Activity Procedure
Perform the following steps on all routers in your workgroup:
66
Step 1
Remove the BGP process and start a new BGP process with the proper member-AS
number.
Step 2
Announce networks that originate in this subautonomous system. Also announce

network 192.168.x.0/24.
Step 3
Set the confederation identifier by using your real AS number. List all intraconfederation neighboring autonomous systems by using the bgp confederation
peers command.
Step 4
Establish intra-confederation EBGP sessions and IBGP sessions within the memberAS. Use loopback interfaces for all BGP sessions.
Perform the following steps only on the specific router that is indicated in each step:
Step 5
On WGxR1, configure routers Good and Cheap as your BGP neighbors.
Step 6
On WGxR4, configure router Client as your BGP neighbor.
Step 7
On WGxR4, apply AS-path filters to incoming and outgoing updates toward router
Client.
Note
The filter that permits networks that originate in your AS needs to be changed to permit all
prefixes that originate in all intra-confederation autonomous systems.
Check to see whether router Client is receiving only your networks and those originating in
AS 37. Your display should resemble the following output.

Note
Another way to verify filters is to enter the following command on WGxR4:

WGxR4#show ip bgp neighbors 192.168.21.99 advertised-routes.
Use the show ip route ospf command to make sure that your IGP carries only your internal
networks.
Q1)
What additional command did you have to use to establish intra-confederation EBGP
sessions between loopback interfaces?
Q2)
Why was it necessary to change the AS-path filters?
Lab Guide
67
Lab 7-1: Limiting the Number of Prefixes

Received from a BGP Neighbor
Activity Objective
In this activity, you will configure BGP to limit the number of prefixes that are received from a
neighbor. After completing this activity, you will be able to meet these objectives:
Configure the BGP maximum-prefix function
Monitor the BGP maximum-prefix function
Visual Objective
Visual Objective for Lab 7-1: Limiting the Number

of Prefixes Received from a BGP Neighbor
BGP v3.217
Required Resources
installed.
68
installed
Command List
Commands
Command
Description
Specifies the allowed maximum number of prefixes
Shows detailed information about a specific neighbor

Job Aids
You have noticed that one of your upstream service providers occasionally announces a
very large number of BGP prefixes, which results in memory and CPU overload on your
router (WGxR1). You suspect that the service provider might have internal problems, and
you would like to be protected against these problems. The service provider is asking for
evidence that you are receiving more prefixes than you should.
In this activity, you will configure logging on your router to warn you if you receive more
BGP prefixes than you should from your service provider.
Your analysis shows that you must perform the following tasks to minimize the size of the
BGP table on router WGxR1:
Create a warning log whenever your service provider (Cheap) sends you more than
15 prefixes.
Lab Guide
69
Task 1: Limiting the Number of Prefixes Received

In this activity, you will configure BGP to limit the number of prefixes that are received from a
BGP neighbor.
Activity Procedure
Configuring the maximum-prefix function:
Step 1
Set a limit to the number of prefixes that your router WGxR1 accepts from router
Cheap. Do not disable BGP, but instead create a warning message in the router log.
Step 2
Check your console for the following two messages:

Step 3
After showing the service provider your logs, you have decided to take
administrative action by implementing a BGP policy that will terminate the neighbor
session between you and your upstream provider (Cheap) should it continue to
violate your agreement on the number of prefixes that are advertised to your
network. Configure your router such that the BGP session is terminated if your
router (WGxR1) receives more than the agreed number of prefixes.
You can verify that both neighbors are up. If not, you can find out why. Your display

70
You can increase the number of allowed prefixes to continue testing. You can clear the
neighbor session between your WGxR1 router and router Cheap afterward.
You can inspect the prefixes that your router is receiving from Cheap with the show ip bgp
neighbors command and the routes keyword. Your display should resemble the following
output.

You can increase the number of allowed prefixes so that all of the prefixes coming from
Cheap will be allowed and the session will not be terminated.
You can clear the neighbor session (configuration done in this activity) between your
WGxR1 router and router Cheap afterward and ensure that the neighbor session remains
active.
Lab Guide
71
Answer this question:

Q1)
72
What can you configure on your router to allow the BGP session to restart
automatically if the received number of prefixes exceeds the configured maximum?
Lab 7-2: Implementing BGP Peer Groups

Activity Objective
In this activity, you will use BGP peer groups to share common configuration parameters
between multiple BGP peers. After completing this activity, you will be able to meet these
objectives:
Configure BGP peer groups
Monitor the operation of BGP peer groups
Visual Objective

Implementing BGP Peer Groups
BGP v3.218
Required Resources
installed.
Lab Guide
73
installed
Command List
Commands
Command
Description
Creates a BGP or multiprotocol BGP peer group
Configures a BGP neighbor to be a member of a peer

group
Specifies the allowed maximum number of prefixes
Shows detailed information about a specific neighbor
Enables you to display information about BGP peer

groups
Job Aids
After working with the Cheap provider, you have finally resolved the maximum-prefix
violation problem that your network was experiencing. You have decided to increase the
number of prefixes that are allowed and to make prefix limiting a universally applied policy
for all peers.
In this activity, you will configure router WGxR1 to terminate the neighbor session
between you and your upstream providers if you receive more than 50 BGP prefixes from
them.
You will use BGP peer groups to implement the policy to ease administration when more
peers are added and to minimize router CPU utilization.
74
Task 1: Configuring BGP Peer Groups

In this activity, you will use BGP peer groups to share common configuration parameters
between multiple BGP peers.
Activity Procedure
Creating a BGP peer group:
Step 1
Create a BGP peer group on your WGxR1 router to set a limit to the number of
prefixes that your router accepts. BGP sessions should be terminated if the number
of received prefixes exceeds 50.
Note
BGP sessions with Good and Cheap must be up in case you forgot to reestablish the
disabled session with Cheap by increasing BGP prefix limit (as suggested at the end of the
previous lab).
Assigning a neighbor into a peer group:

Step 2
Configure the neighbor connections for the service provider routers Good and Cheap
to be members of the peer group.
On WGxR1, you can use the show ip bgp peer-group peer-group-name command with the
summary keyword to verify that you have configured the correct neighbors as members of
the peer group. Your display should resemble the following output.

On WGxR1, you can use the show ip bgp peer-group command to verify that the
parameters of the peer group have been properly configured. Your display should resemble
the following output.

Lab Guide
75
You can use the show ip bgp neighbors command and the received-routes keyword to
inspect the prefixes that your router is receiving from both Good and Cheap. Your display

You can clear the neighbor session between your WGxR1 router and router Cheap
afterward and ensure that the neighbor session remains active.
Answer this question:
Q1)
76
If the number of prefixes that are received from both providers exceeds 50, what single
command can you use to reset the BGP sessions on both routers?
Lab 7-3: Using BGP Route Dampening

Activity Objective
In this activity, you will use route dampening to minimize the impact of unstable routes. After
completing this activity, you will be able to meet these objectives:
Configure BGP route dampening
Release dampened routes
Monitor BGP route dampening
Visual Objective

BGP v3.219
The figure shows the connectivity that is established between your AS and the Client router.
Required Resources
installed.
Lab Guide
77

installed
Command List
Commands
78
Command
Description
Specifies BGP dampening parameters by using a routemap
Matches BGP communities in a route-map by using a

community-list
Sets the BGP route-dampening factors
Creates a community access-list
Enables you to view prefixes that have previously

flapped
Enables you to view prefixes that are currently

suppressed

Enables you to view BGP routes that have at least one

BGP community attribute or those that are specified in
the command
Enables you to view BGP routes that are permitted by

the specified community-list
Enables you to see major events that are related to

route dampening
Job Aids
Service providers usually use BGP route dampening to minimize the impact that route flaps
in the Internet can have on the stability of their networks. BGP route dampening also
reduces the CPU load on the routers that are running BGP. In this activity, you will
minimize the impact of flapping routes on your AS and upstream autonomous systems by
implementing BGP route dampening.
Configure graded route dampening for routes that are received from the Client router
according to the following design:
If a prefix contains a community attribute of x:300, then the prefix should not be
dampened.
Prefixes longer than /23 should have a half-life of 20 minutes.
Prefixes between /9 and /22 should have a half-life of 15 minutes.
Prefixes between /0 and /8 should have a half-life of 10 minutes.
Maximum suppression time should be changed to four times the half-life time for all
prefixes.
Task 1: Using BGP Route Dampening

In this activity, you will use route dampening to minimize the impact of unstable routes.
Activity Procedure
Creating filters for the dampening route-map:
Step 1
Create a community-list that matches prefixes that carry a BGP community of x:300
(where x is your real AS number, not your member-AS number).
Step 2
Create a prefix-list that matches all prefixes that are longer than /23.
Step 3
Create a prefix-list that matches all prefixes that are longer than /8.
Creating a route-map for route dampening:

Step 4
Create a new route-map. The first statement of the new route-map should match
prefixes that carry a BGP community of x:300. No route-dampening parameters
need to be set.
Step 5
The second statement should match prefixes that are longer than /23. Set the half-life
parameter to 20 minutes and max-suppress-time to 80 minutes, and use default
values for other parameters (reuse 750, suppress 2000).
Step 6
The third statement should match prefixes that are longer than /8. Set the half-life
parameter to 15 minutes and max-suppress-time to 60 minutes, and use default
values for other parameters (reuse 750, suppress 2000).
Lab Guide
79
Step 7
The last statement should match all other prefixes (no match command). Set the
half-life parameter to 10 minutes and max-suppress-time to 40 minutes, and use
default values for other parameters (reuse 750, suppress 2000).
Step 8
Enter BGP configuration mode and, using the bgp dampening route-map
route-map command, start BGP route dampening based on the created route-map.
You can shut down interface Loopback55 on router Client several times to create flaps. and
use the show ip bgp flap-statistics and show ip bgp dampened-paths commands to verify
the operation of route dampening on your WGxR4 router. Your display should resemble the
following output.

Note
This command is being replaced with the show ip bgp dampening dampened-paths
command. Try it as well.
Note
This command is being replaced with the show ip bgp dampening flap-statistics
command. Try it as well.

80

Q1)
What is the purpose of route dampening?
Q2)
Which routes are affected by route dampening?
Lab Guide
81
Answer Key
The correct answers and expected solutions for the activities that are described in this guide
appear here.
Lab 1-1 Answer Key: Initial Lab Setup

When you complete this activity, your router configuration will be similar to the following,
with differences that are specific to your device or workgroup:

82
Lab Guide
83
Lab 1-2 Answer Key: Configuring Basic BGP

with differences that are specific to your device or workgroup.
Task 1: Configuring BGP

Use the following command sequence on your router WGxR1 (replace x with your
workgroup number):

Also, make sure that you announce a default route into your network. If you are running OSPF
in your network, the command sequence to use is as follows:

Answers to Review Questions

Q1)
What do you need in order to be able to propagate classful networks?

There must be at least one subnet in the routing table, and the network must be listed in
the BGP process with no mask attached to it.
Q2)
What do you need to be able to propagate classless networks (supernets or subnets)?

The prefix must be listed in the BGP process together with its proper mask. The exact
corresponding entry must also be present in the IP routing table.
Q3)
Why do some networks that are received from router Good have a next-hop address
pointing to other routers?
Router Good performs next-hop processing and sets the next hop to router Cheap for
routes that are received from Cheap and propagated to you.
Q4)
What command would you use to see whether a neighbor is sending you any updates
and how many?
You would use the show ip bgp neighbor command.
84
Task 2: Configuring Route Redistribution in BGP

workgroup number):


Q1)
What is the major difference between this implementation and the previous one?
Which is better and why?
The previous implementation is better for service provider environments because it is
more controlled. This implementation is better for enterprise networks because it is
more dynamic.
Q2)
What precautions do you have to take when using redistribution?

You should always filter redistributed routes with a route-map to make sure that
unwanted networks are not announced into BGP.
Task 3: Configuring BGP Aggregation

workgroup number):

Lab Guide
85

Q1)
Do you see all your prefixes on the provider router? Why?

You should see only the configured aggregates and the routes that are not within the
aggregation range on the provider router. All the other routes should be suppressed.
Q2)
What do you need to be able to generate and propagate aggregates?

The aggregate address has to be configured in the BGP process, and a prefix within the
aggregate range has to be present in the BGP table.
Before aggregation:
After aggregation:

86
Lab 2-1 Answer Key: Configuring a Transit AS

Task 1: Configuring the BGP Transit AS

Use the following command sequence on your router WGxR1:




Lab Guide
87

Q1)
Check the BGP table on router Client. How many prefixes coming from your AS are in
that BGP table?
20
Q2)
Is there any other way of discovering how many prefixes you have advertised to the
router Client?
show ip bgp neighbor ip-address advertised
Q3)
Why did you have to disable synchronization?

You should use BGP synchronization only in networks where BGP routes are
redistributed in IGP. This design is no longer viable for service provider networks
because of the large number of routes that are advertised in the Internet.
Q4)
Why did you have to establish a full mesh of IBGP sessions?

IBGP split-horizon rules require a full mesh of IBGP sessions within the AS.
88
Lab 3-1 Answer Key: Using Multihomed BGP Networks

Use the following command sequence on your router WGxR1 (replace x with your workgroup
number):


Q1)
What can happen if a multihomed AS is passing routing information learned from one
neighbor to another neighbor?
The multihomed AS that is passing routes between BGP neighbors can become a
transit AS.
Q2)
Why do some prefixes have two paths but both use the same next-hop address?
Both service providers are connected to the same subnet as all the customers, and the
BGP next-hop processing optimizes the data flow.
Lab Guide
89
Lab 3-2 Answer Key: Employing AS-Path Filters

workgroup number):


Q1)
By this time, the BGP table should contain a large number of prefixes. What regular
expression would you use with the show ip bgp command on WGxR1 to view the
prefixes that are originated by your AS?
Use show ip bgp regexp ^$.
Q2)
that originate in your AS?
Use show ip bgp regexp _x$.
AS is 1.

Q3)
that are received from your AS?
Use show ip bgp regexp ^x_.

90
Q4)
How can you test your AS-path filters before applying them and clearing BGP
neighbors?
You can test the AS-path filters with the show ip bgp filter-list filter command.
Lab Guide
91
Lab 3-3 Answer Key: Filtering with Prefix-Lists

number):


Q1)
Are neighboring workgroups still reachable?

Yes, they are still reachable.
Q2)
Why does router WGxR1 still accept class B networks from router Cheap?
Only subnets of class B networks are filtered, not the class B networks themselves.
92
Lab 3-4 Answer Key: Implementing Changes in BGP Policy

number):


Q1)
What command do you use to show which entries in the BGP table of the local router
have been propagated to a specific neighbor?
show ip bgp neighbors ip-address advertised
Q2)
What command do you use to display which of the routes in the local BGP table have
been received and accepted from an indicated neighbor?
show ip bgp neighbors ip-address routes
Lab Guide
93
Lab 4-1 Answer Key: Influencing BGP Route Selection with

Weights
workgroup number):


Q1)
Did all paths automatically get a weight of 100 or 200? Why not? What did you have to
do?
The BGP sessions had to be reset in order to apply newly configured weights to
incoming BGP routes.
Q2)
Name some parameters and attributes that are used for best-path selection.
The following BGP parameters and attributes are used for BGP best-path selection in
the order specified: weight, local preference, AS-path length, origin code, MED.
94
Lab 4-2 Answer Key: Setting BGP Local Preference

Use the following command sequence on your workgroup routers as indicated (replace x with
your workgroup number):
Configuration of router WGxR2:



Q1)
Is routing between router WGxR1 and Good symmetrical?

Initially, the routing is not symmetrical, because the router Good prefers more stable
EBGP routes received from WGxR1 and the router WGxR1 prefers routes received
from WGxR2.
Q2)
Which routers receive the local preference attribute?

Only routers within the AS receive the local preference attribute.
Lab Guide
95
Lab 4-3 Answer Key: Understanding BGP Multi-Exit

Discriminators
workgroup number):



Q1)
Which parameters and attributes have to be equal before the MED is compared to
select the best path?
The MED is used only to compare routes that are received from the same AS that have
equal weight, local preference, AS-path length, and origin code.
Q2)
What is the default value of the MED?

For networks that originated in the local AS, the default MED value is the IGP metric
from the IP routing table. For transit networks, the MED is removed by the router in
outgoing EBGP updates.
96
Lab 4-4 Answer Key: Addressing BGP Communities

number):

number):


Q1)
What do you have to do to enable community propagation?

Enable BGP community propagation with the neighbor send-community command.
Q2)
What mechanisms can you use to match or set communities?

Only route-maps allow matching or setting of BGP communities.
Lab Guide
97
Lab 6-1 Answer Key: Introducing Route Reflectors






Q1)
Did this design require you to configure a cluster-ID?

This design did not require specified cluster-IDs, because there are no redundant route
reflectors in the network.
Q2)
What is the default cluster-ID?

The default cluster-ID is the BGP router-ID.
Q3)
When do you have to configure a cluster-ID?

You need to configure a cluster-ID in redundant route reflector designs.
98
Lab 6-2 Answer Key: Configuring and Monitoring

Confederations




Lab Guide
99

Q1)
What additional command did you have to use to establish intra-confederation EBGP
sessions between loopback interfaces?
To establish intra-confederation EBGP sessions between loopback interfaces, you must
specify ebgp-multihop on the intra-confederation EBGP neighbor.
Q2)
Why was it necessary to change the AS-path filters?

The AS path of the local network has changed, because it includes the member-AS
numbers.
100
Lab 7-1 Answer Key: Limiting the Number of Prefixes Received

from a BGP Neighbor

Answer to Review Question

Q1)
What can you configure on your router to allow the BGP session to restart
automatically if the received number of prefixes exceeds the configured maximum?
restart parameter of the maximum-prefix command:
neighbor ip-address maximum-prefix maximum restart
Lab Guide
101
Lab 7-2 Answer Key: Implementing BGP Peer Groups


Answer to Review Question

Q1)
If the number of prefixes that are received from both providers exceeds 50, what single
command can you use to reset the BGP sessions on both routers?
clear ip bgp peer-group peer-group-name soft in
In this example it would be the following:
clear ip bgp peer-group SvcPro soft in
102
Lab 7-3 Answer Key: Using BGP Route Dampening



Q1)
What is the purpose of route dampening?

Route dampening minimizes the impact of route flaps in downstream autonomous
systems upon local and upstream autonomous systems.
Q2)
Which routes are affected by route dampening?

Route dampening affects only EBGP routes.
Lab Guide
103
104

Configuring BGP On Cisco Routers

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Configuring BGP On Cisco Routers

Enviado por

Direitos autorais:

Formatos disponíveis

BGP

2005, Cisco Systems, Inc. All rights reserved.

Understanding BGP Path Attributes

Establishing BGP Sessions

Processing BGP Routes

Building the IP Routing Table

Configuring Basic BGP

Monitoring and Troubleshooting BGP

Configuring BGP on Cisco Routers (BGP) v3.2

2005, Cisco Systems, Inc.

BGP Transit Autonomous Systems

Working with a Transit AS

Interacting with IBGP and EBGP in a Transit AS

Forwarding Packets in a Transit AS

2005, Cisco Systems, Inc.

Configuring BGP on Cisco Routers (BGP) v3.2

Changing the Administrative Distance of BGP Routes

Monitoring and Troubleshooting IBGP in a Transit AS

Route Selection Using Policy Controls

Using Multihomed BGP Networks

Employing AS-Path Filters

Configuring BGP on Cisco Routers (BGP) v3.2

2005, Cisco Systems, Inc.

Filtering with Prefix-Lists

Using Outbound Route Filtering

Applying Route-Maps as BGP Filters

Configuring BGP on Cisco Routers (BGP) v3.2

Implementing Changes in BGP Policy

Influencing BGP Route Selection with Weights

Setting BGP Local Preference

Using AS-Path Prepending

Configuring BGP on Cisco Routers (BGP) v3.2

Understanding BGP Multi-Exit Discriminators

Addressing BGP Communities

Configuring BGP on Cisco Routers (BGP) v3.2

Sequenced Extended Community-List Entry Configuration: Example

Customer-to-Provider Connectivity with BGP

Understanding Customer-to-Provider Connectivity Requirements

Implementing Customer Connectivity Using Static Routing

Connecting a Multihomed Customer to a Single Service Provider

Configuring BGP on Cisco Routers (BGP) v3.2

Backup Solutions with BGP

Connecting a Multihomed Customer to Multiple Service Providers

Scaling Service Provider Networks

Scaling IGP and BGP in Service Provider Networks

Introducing Route Reflectors

Designing Networks with Route Reflectors

2005, Cisco Systems, Inc.

Configuring BGP on Cisco Routers (BGP) v3.2

Example: Network Design with Route Reflectors

Configuring and Monitoring Route Reflectors

Configuring and Monitoring Confederations

Optimizing BGP Scalability

Improving BGP Convergence

Configuring BGP on Cisco Routers (BGP) v3.2

CPU Effects of BGP Processes

Limiting the Number of Prefixes Received from a BGP Neighbor

Implementing BGP Peer Groups

Configuring BGP on Cisco Routers (BGP) v3.2

Using BGP Route Dampening

Configuring BGP on Cisco Routers (BGP) v3.2

2005, Cisco Systems, Inc.

Learner Skills and Knowledge