Cisco BGP V 3.1 Lab Guide

Configuring BGP on Cisco Routers
Remote Lab Guide

L5976E-003
August 2004
Blank
Configuring BGP on Cisco Routers

Remote Lab Guide
BGP Version 3.1
L5976E-003
August 2004
Copyright Information
Copyright 2004, 2003
Global Knowledge Network, Inc.
The following publication, Configuring BGP on Cisco Routers Remote Lab Guide, was developed by Global
Knowledge Network, Inc. All rights reserved. No part of this publication may be reproduced or distributed in
any form or by any means without the prior written permission of the copyright holder.
This courseware may contain licensed images from the following sources: Corel Corporation, Corel Gallery;
Broderbund Company, ClickArt 200,000; Nova Development Corporation, Art Explosion 125,000.
Products and company names are the trademarks, registered trademarks, and service marks of their respective
owners. Throughout this manual, Global Knowledge has used its best efforts to distinguish proprietary
trademarks from descriptive names by following the capitalization styles used by the manufacturer.
Project Team
DENISE DONOHUE
NANCY DUNHAM
CHUCK TERRIEN
ERIC STRAUSE
Course Director
Director, Content Development, Instructor-Led Training
Vice-President, Cisco Training Worldwide
Product Manager, Cisco Training U.S.
9000 Regency Parkway

Cary, North Carolina 27511
Phone: 919-461-8600
1-800-COURSES
Fax: 919-461-8646
www.globalknowedge.com
Welcome!
Thank you for selecting Global Knowledge as your training provider. Our primary goal is
to be your lifelong training partner and support your needs in seeking career success. We
hope that you will think of us first for all your future IT training needs.
About Global Knowledge

Your Lifelong Training Partner
Global Knowledge is dedicated to improving the way companies and individuals learn,
use, and master technology. As a worldwide leader in IT education and learning solutions,
we empower customers with choice about when, where, and how they want their IT
learning solutions designed and delivered. With our solutions, IT professionals and
enterprises can choose how to build their skills. Our training is delivered via live Virtual
Classroom e-Learning, Self-Paced e-Learning, or traditional Classroom Learning. We also
provide in-depth learning solutions that include enrollment, assessment, progress tracking,
and an extensive portfolio of training development tools. Our ability to provide complete
IT training solutions and to construct them within varying budgets enables Global
Knowledge to offer a top training value.
Learn from Instructors with Real-World Experience

In addition to quality content, another key benefit customers receive as part of the Global
Knowledge training experience is our team of subject matter experts who are not only
instructors, but also professionals who work on a daily basis with the technologies they
teach. This is one of the reasons Global Knowledges instructors stand out: they not only
teach in the classroom, but they work in the real world.
Build Your Personalized Training Plan

Partner with a Global Knowledge IT Training Advisor to navigate your complex career
choices and build a complimentary personalized training plan.
Configuring BGP on Cisco Routers Remote Lab Guide

Training Options
Classroom Learning
Offers traditional training with instructors and students in the same location, working
hands-on with related equipment.
Virtual Classroom e-Learning

Delivers classroom interaction over the Internet. An instructor and students gather in a
virtual classroom and interact using live audio and on-screen graphics.
Self-Paced e-Learning
Enables students to focus their training on specific topics at their own pace and at their
most comfortable locations: office, home, or elsewhere.
Expert Mentoring
Gives students access to instructors, experts, and peers in the field for questions, advice,
and general guidance in their training and careers.
Live Labs
Allows students to practice skills on real-world equipment in a real-time environment
remotely from anywhere in the world.
Global Knowledge Online Reference Library

Provides full online access to the complete contents of over 2,000 IT books for one small
annual subscription fee.
Enterprise Services
Provides customized solutions and management tools to meet business needs. Get
complete blended IT solutions constructed within varying budgets for a top training value.
College Credit
Teams Global Knowledge with the San Diego State University College of Extended
Studies to provide accredited IT technical training through selected courses.
vi

Ways to Save
Special Offers
Provides customers with cost-savings through product offers, multi-course packages, and
promotions on selected training options. Visit www.globalknowledge.com for the latest
information.
Back2Back
Pairs complementary courses designed to be attended during the same week and offers
cost savings when purchased in a Back2Back arrangement.
Hot Seats
Provides significant discounts on select training sessions.
Learning Advantage
Enables enterprises to get flexibility, cost savings, and choice by prepaying for training
and enjoying significant discounts on IT training courses.
GSA Schedule
Offers the most complete GSA Schedule available through schedule GS-35F-4390G,
which includes hundreds of titles. Get the discounted government rate when you purchase
courses through the GSA or by using your Smart Pay card.

vii
How to Get More Information

www.globalknowledge.com
Provides online access to the resources below as well as course descriptions, schedules,
training options, savings programs, learning resources, latest updates, and more.
1-800-COURSES
Gives direct access to a knowledgeable IT Training Advisor or Customer Service
Representative to discuss training needs, options, and services.
IT Training Catalog
Provides a printed resource for course descriptions, schedules, training options, savings
programs, and more.
My Global Knowledge
Provides an online account and a customized training portal for Global Knowledge
customers to manage, expand, and accelerate their learning. View training histories, get
exclusive discount and promotional offers, obtain additional information, join discussion
groups, and much more.
Free Web Seminars

Teams Global Knowledge with the industrys leading experts to offer a continuing
series of free one-hour Web Seminars presented as real-time Webcasts with live,
streaming audio. Topics range from specific IT certifications to IT skills and trends.
e-Newsletter
Delivers a personalized electronic newsletter containing information on new courses,
special offers, free seminars, plus other IT-related news and tutorials.
Free e-Learning Demos

Provides risk-free opportunities to try market-leading e-Learning solutions including
Self-Paced e-Learning, Virtual Classroom e-Learning, Labs, and the Global Knowledge
Online Reference Library.
viii

Table of Contents
Instructions for Using Global Knowledge Remote Labs
Accessing the Remote Labs ............................................................................... I-2
BGP Pod Topology ..............................................................................................I-5
BGP Lab Autonomous System Structure ............................................................I-6
Lab 1: Pod Setup

Exercise Objective ........................................................................................... L1-2
Task 1: Physical and Logical Connectivity .................................................L1-4
Task 2: Configuring an Interior Routing Protocol .......................................L1-6
Exercise Verification...................................................................................L1-7
Lab 2: Configuring EBGP Peerings

Task 1: Configure eBGP Peerings .............................................................L2-4
Task 2: Advertise Networks into BGP ........................................................L2-4
Task 3: Optimizing BGP.............................................................................L2-6
Lab 3: Configuring IBGP Peerings

Task 1: Configuring an iBGP Peer ...................................................................L3-4
Task 2: Tuning the BGP Configuration.............................................................L3-5
Task 3: Providing Connectivity for the Internal Routers ...................................L3-6
Task 4: Cleaning Up .........................................................................................L3-7
Exercise Verification .........................................................................................L3-7
Lab 4: Using AS Path Filers and Regular Expressions

Task 1: Filtering Outbound Advertisements ...............................................L4-3
TOC-1
Task 2: Filtering Inbound Advertisements..................................................L4-5

Task 3: Verification.....................................................................................L4-6
Lab 5: Filtering Route Updates Using Prefix Lists

Exercise Objective........................................................................................... L5-2
Task 1: Create and Apply the Prefix Lists ..................................................L5-3
Lab 6: Route Refresh and Soft Reconfiguration

Task 1: Resetting a BGP Session..............................................................L6-4
Task 2: Route Refresh ...............................................................................L6-5
Task 3: Soft Reconfiguration......................................................................L6-6
Lab 7: Configuring the Weight Attribute

Task 1: Configuring a Second eBGP Peer.................................................L7-4
Task 2: Configuring Weight........................................................................L7-5
Lab 8: Configuring the Local Preference Attribute

Task 1: Clean-up........................................................................................L8-3
Task 2: Setting Local Preference ...............................................................L8-4
Lab 9: AS-Path Prepending

Task 1: Configuring AS-Path Prepending ..................................................L9-4
TOC-2

Lab 10: Configuring the MED Attribute

Exercise Objective ......................................................................................... L10-2
Task 1: Configure the MED Attribute .......................................................L10-3
Task 2: Verify the MED Configuration......................................................L10-5
Exercise Verification.................................................................................L10-6
Lab 11: Using the Community Attribute

Task 1: Clean-Up .....................................................................................L11-4
Task 2: Setting the Community Attribute..................................................L11-6
Task 3: Set Local Preference...................................................................L11-7
Lab 12: Becoming a Service Provider

Task 1: Clean-Up .....................................................................................L12-4
Task 2: Configure Full-mesh iBGP...........................................................L12-5
Task 3: Configure eBGP Peering.............................................................L12-6
Task 4: Tuning the Peering with the Customer ........................................L12-7
Lab 13: Using Route Reflectors

Task 1: Configuring Route Reflectors ......................................................L13-4
Lab 14: Using Confederations

Task 1: Configure Confederations ...........................................................L14-4
Task 2: Filtering Customer Routes...........................................................L14-6

TOC-3
Lab 15: Monitoring and Tuning BGP Resource Use

Exercise Objective......................................................................................... L15-2
Task 1: Monitoring BGP Resource Use ...................................................L15-4
Task 2: Settings to Speed BGP Convergence .........................................L15-5
Task 3: Limiting Inbound Prefixes ............................................................L15-5
Lab 16: Using Peer Groups

Task 1: Clean-Up .....................................................................................L16-4
Task 2: Creating and Applying a Peer Group ..........................................L16-4
Exercise Verification .......................................................................................L16-6
Lab 17: Using Route Dampening

Task 1: Lab Preparation...........................................................................L17-4
Task 2: Configuring Route Dampening ....................................................L17-4
Task 3: Monitoring Dampening ................................................................L17-5
Appendix A: BGP Lab Solutions

Lab Solutions.................................................................................................... A-2
Lab 1 Pod Setup ...................................................................................... A-2
Lab 2 Configuring EBGP Peerings........................................................... A-3
Lab 3 Configuring IBGP Peerings ............................................................ A-4
Lab 4 Using AS Path Filters and Regular Expressions............................ A-5
Lab 5 Filtering Route Updates Using Prefix Lists..................................... A-6
Lab 6 Route Refresh and Soft Reconfiguration ....................................... A-7
Lab 7 Configuring the Weight Attribute .................................................... A-8
Lab 8 Configuring the Local Preference Attribute .................................... A-9
Lab 9 AS-Path Prepending .................................................................... A-10
Lab 10 Configuring the MED Attribute ................................................... A-11
TOC-4

Lab 11 Using the Community Attribute .................................................. A-13

Lab 12 Becoming a Service Provider..................................................... A-14
Lab 13 Using Route Reflectors .............................................................. A-16
Lab 14 Using Confederations................................................................. A-17
Lab 15 Monitoring and Tuning BGP Resource Use ............................... A-19
Lab 16 Using Peer Groups..................................................................... A-19
Lab 17 Using Route Dampening ............................................................ A-20

TOC-5
TOC-6

Instructions for Using Global

Knowledge Remote Labs

I-1
Instructions
Accessing the Remote Labs
1. To access your remote labs, go to https://www.remotelabs.com and log in with

your assigned User ID and Password.
If you are taking these labs in a classroom setting, then your instructor will give you
one User ID and Password for your entire pod.
If you are taking these labs on your own, as part of an online Virtual Classroom
Learning course, or as part of a Self-Paced e-Learning course, or as part of an e-Lab
Bundle, then your User ID and Password will be emailed directly to you.
2. After logging in, individual students will be presented with a list of labs you have
been scheduled to take. (Classroom students will go directly to the screen below.)
Choose the lab you wish to start with. You may also choose the Default
Configuration if you wish to configure the equipment from scratch, or work on a lab
of your own design. In the Default Configuration, the equipment has only a basic
configuration on it.
I-2

Instructions
3. Students taking individual labs will then be able to either schedule a lab in advance,
or take the lab immediately if equipment is available. Classroom students see steps
4 and 5.
4. For classroom students, click on Pod x (x being your pod number) and then
choose the Reset To link. In the example above, the Reset To link is found
under Pod 1.
5. From the Reset To dialog box drop-down menu, select the lab you would like
to perform and then click the Reset button. When you do this, the lab equipment
will be configured with the correct settings from the lab previous to this one.
I-3
Instructions
6. A progression bar will indicate when the lab that was selected is ready. While
waiting, it is a good idea to review the lab documentation, which contains the steps
and instructions to be performed for the selected lab. Once the setup is complete,
you may go ahead and perform your lab.
7. If you are moving directly from one lab to the next, you can simply choose to
Change Doc rather than completely reset the equipment. Optionally, repeat steps
4 and 5 to reset the remote lab equipment for other labs. The Reset to link can
also be used to do labs out of order, as it loads the correct configuration from the lab
immediately prior to the one you are taking.
8. In the labs, the character x designates your pod number, and the character y
designates your device (router or switch) number. You will need to use these when
configuring such things as IP addresses, frame relay DLCIs, and device names. It is
a good idea to make a drawing of your pod and record the IP addresses, etc. to use
for your reference as you do the labs. You can use the ones below as a guide. NOT
EVERY INTERFACE AND DLCI IS USED IN EVERY LAB!
9. Classroom students can stay logged into the labs for the entire day, but at the end of
the day, they should log out of the system. Individual students will be disconnected
from the lab when their time expires, but will also need to log out of the system
when they are done.
I-4

Instructions
BGP Pod Topology

BBR1
S0 - 172.31.x.3
E0 - 10.254.0.1
BBR2
S0 - 172.31.xx.4
E0 - 10.254.0.2
AS 64998
AS 64999
BBR1
BBR2
Frame
Relay
S0.1 - 172.31.x.1/24
DLCI 1xy
10.254.0.3x/24
S0.2 - 172.31.xx.1/24
E1
S0
DLCI 2xy
10.x.1.3/24
E0
E0 10.x.1.1/24
PxR3
PxR1
S0
S1
10.x.3.3/24
10.x.0.1/24
AS 6500x
10.x.0.2/24
S1
All pod routers have a loopback

interface - 10.x.100.10y/32
10.x.3.4/24
S0
10.x.2.4/24
PxR2
S0
E0 10.x.2.2/24
E0
PxR4
Frame
Relay
Customer
AS 64997

I-5
Instructions
BGP Lab Autonomous System Structure

The diagram below shows the Autonomous System structure used in the labs for
Configuring BGP on Cisco Routers. This will be helpful for understanding the paths
you see when you look at the BGP databases, and for understanding exercises that
require you to filter routes with specific AS paths.
AS
65125
AS
65208
AS
64714
AS
65517
192.168.96.0
192.168.208.0
172.27.0.0
172.25.0.0
AS
65102
10.102.1.0
AS
64999
AS
64998
Pod
Autonomous
Systems
65001 - 65008
I-6
AS
65107
10.107.1.0
AS
64997
10.97.97.0

Pod Setup

L1-1
Pod Setup
Exercise Objective
In this exercise, you will place a basic configuration on the four routers in your pod,
including IP addressing, loopback interfaces, frame relay configuration, enable an
interior routing protocol, and verify connectivity.
Visual Objective
A S 64998
A S 64999
BB R 1
B BR 2
F ra m e
R e la y
1 0 .x .1 0 0 .1 0 1 /3 2
1 7 2 .3 1 .x .1 /2 4
D LC I 1xy
1 0 .2 5 4 .0 .3 x /2 4
S0
Lo0
PxR1
S1
1 0 .x .0 .1 /2 4
E1
E0
E0
1 0 .x .1 0 0 .1 0 3 /3 2
Lo0
PxR 3
S0
1 0 .x .3 .3 /2 4
A S 6500x
1 0 .x .0 .2 /2 4
1 0 .x .3 .4 /2 4
S1
S0
1 0 .x .2 .4 /2 4
Lo0
1 0 .x .1 0 0 .1 0 2 /3 2
PxR2
S0
E 0 1 0 .x .2 .2 /2 4
E0
PxR 4
Lo0
1 0 .x .1 0 0 .1 0 4 /3 2
F ra m e
R e la y
C u s to m e r
A S 64997
Figure 1: Lab Topology
The figure shows the complete topology of the lab equipment. You will not use
every connection in every lab. In this exercise you will configurePxR1s frame
relay connection to Backbone Router 1 (BBR1), and PxR3s Ethernet connection to
Back Bone Router 2 (BBR2). Additionally, you will configure and connect the four
pod routers to each other over HDLC and Ethernet connections.
L1-2

Pod Setup
Note
Throughout the exercise the pod number is referred to with x and the
router number with y. Substitute the appropriate number as needed.
This lab exercise requires a topology of a pod and preconfigured core. No

interaction between pods is required. A pod consists of these devices:
Two end users
Two end-user stations
Four Cisco routers
Command List
The commands used in this exercise are described in the following table. NOTE:
The commands are in alphabetical order, not the order in which you will use them.
Table 1: Commands
Router Prompt
Command
Description
(config-if)#
encapsulation frame-relay
Enables Frame Relay

encapsulation.
(config-if)#
frame-relay interfacedlci 1xy
Associates a DLCI with a

subinterface
(config)#
hostname PxRy
Gives the router a host name
(config-if)#
ip address 10.x.1.1
255.255.255.0
Assigns an IP address to an
interface
(config-router)#
network 10.0.0.0
Starts RIP routing on interfaces

in the 10.0.0.0 network
(config-router)#
passive-interface e1
Prevents RIP from advertising

out interface e1
(config)#
router rip
Starts the RIP routing process

L1-3
Pod Setup
Task 1: Physical and Logical Connectivity

Connect to each of the pods routers; configure physical connectivity and IP
addresses. Additionally, configure a loopback interface on each router.
Complete these steps:

1. Connect to your assigned routers. Your router should not have a configuration on it.
If your router has a configuration, delete the configuration using the erase start
command, and then use the reload command to return the router to an unconfigured
state. Assign a hostname to each router using the following format: PxRy, where x
is your pod number, and y is your router number.
router#conf t
Enter configuration commands, one per line.
router(config)#hostname PxRy
End with CNTL/Z.
2. At PxR1, configure interface serial 0 for frame relay encapsulation. Create a pointto-point subinterface serial 0.1 and assign it DLCI 1x1, where x is your pod
number. Create a loopback interface, Lo0. Assign IP addresses to your interfaces
according to the following table (the routers Ethernet interface is not used for this
lab). Serial 1 is the DCE end of a back-to-back connection, so it will need a clock
rate of 64000. Remember that you will need to no shut all your interfaces.
Interface
IP Address
S0.1
172.31.x.1/24
S1
10.x.0.1/24
Lo0
10.x.100.101/32
PxR1(config)#interface s0
PxR1(config-if)#encapsulation frame-relay
PxR1(config-if)#no shut
PxR1(config-if)#interface s 0.1 point-to-point
PxR1(config-subif)#ip address 172.31.x.1 255.255.255.0
PxR1(config-subif)#frame-relay interface-dlci 1x1
PxR1(config-fr-dlci)#exit
PxR1(config-subif)#interface s1
PxR1(config-if)#ip address 10.x.0.1 255.255.255.0
PxR1(config-if)#clock rate 64000
PxR1(config-if)#interface lo0
L1-4

Pod Setup
3. At PxR2, create a loopback interface, Lo0. Assign IP addresses to your interfaces

according to the following table. (Interface serial 0 will NOT be used yet.)
Remember that you will need to no shut all your interfaces.
Interface
IP Address
S1
10.x.0.2/24
E0
10.x.2.2/24
Lo0
10.x.100.102/32
PxR2(config)#interface lo0
PxR2(config-if)#interface s1
PxR2(config-if)#interface e0

according to the following table (the Ethernet 0 interface is not used in this lab).
Serial 0 is the DCE end of a back-to-back connection, so it will need a clock rate of
64000. Remember that you will need to no shut all your interfaces.
Interface
IP Address
S0
10.x.3.3/24
E1
10.254.0.3x/24 (x=pod number)
Lo0
10.x.100.103/32
PxR3(config-if)#clock rate 64000
PxR3(config-if)#interface e1
PxR3(config-if)#ip address 10.254.0.3x 255.255.255.0
PxR3(config-if)#interface loo0

L1-5
Pod Setup

according to the following table. Remember that you will need to no shut all your
interfaces.
Interface
IP Address
S0
10.x.3.4/24
E0
10.x.2.4/24
Lo0
10.x.100.104/32
PxR4(config)#interface e0
PxR4(config-if)#interface lo0
6. Verify that all your router interfaces are up, and have the correct IP addresses. Use
commands such as show ip interface and ping to verify connectivity.
Task 2: Configuring an Interior Routing Protocol

Enable the RIP interior routing protocol.
1. Enable RIP version 2 on all the pod routers, on all their interfaces with the
following exceptions:
DO NOT enable RIP on PxR1s interface S0 and on PxR3s interface E1. These will
be used for BGP only. Do not create a network statement for the 172.31.0.0
network, and you must make PxR3s E1 interface passive for RIP routing.
Additionally, disable RIP auto-summarization on all the pod routers.
The following commands demonstrate configuring RIPv2 as your IGP:
PxRy#conf t
Enter configuration commands, one per line.
PxRy(config)#router rip
PxRy(config-router)#network 10.0.0.0
PxRy(config-router)#version 2
PxRy(config-router)#no auto-summary
End with CNTL/Z.
On PxR3 only:(config-router)#passive-interface e1
L1-6

Pod Setup
2. Verify that all routers are running the RIP routing protocol, and that they are all
running version 2, using the show ip protocols command.
3. Verify that all routers have routes for all the internal pod interfaces in their routing
table, using the show ip route command. Your output should resemble this
example, taken from Pod 4, Router 1. (Note that even though the E1 interface on
PxR3 was set as passive, RIP still advertises that network (10.254.0.0) since it falls
under the network statement.)
P4R1#show ip route
[output omitted]
Gateway of last resort is not set
C
R
R
R
R
R
C
C
R
172.31.0.0/24 is subnetted, 1 subnets

172.31.4.0 is directly connected, Serial0.1
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
10.4.100.104/32 [120/2] via 10.4.0.2, 00:00:03, Serial1
10.4.100.102/32 [120/1] via 10.4.0.2, 00:00:03, Serial1
10.4.2.0/24 [120/1] via 10.4.0.2, 00:00:03, Serial1
10.4.100.103/32 [120/3] via 10.4.0.2, 00:00:03, Serial1
10.4.3.0/24 [120/2] via 10.4.0.2, 00:00:03, Serial1
10.4.0.0/24 is directly connected, Serial1
10.4.100.101/32 is directly connected, Loopback0
10.254.0.0/24 [120/3] via 10.4.0.2, 00:00:04, Serial1
Exercise Verification
You have successfully completed this exercise when you attain these results:
All routers have the appropriate physical and logical connectivity.
All routers are passing routes within the pod.

L1-7
Pod Setup
L1-8

Configuring EBGP Peerings

L2-1
Exercise Objective
In this exercise, you will create two eBGP peerings, advertise networks into BGP,
and redistribute your IGP into BGP. Additionally, you will notice the effects of
BGP auto-summarization. You will summarize your pods routes to your external
neighbor.
Visual Objective
AS 64998
AS 64999
BBR1
BBR2
Frame
Relay
172.31.x.1/24
DLCI 1xy
S0
PxR1
S1
10.x.0.1/24
10.254.0.3x/24
E1
E0
E0
PxR3
S0
10.x.3.3/24
AS 6500x
10.x.0.2/24
10.x.3.4/24
S0
S1
10.x.2.4/24
PxR2
S0
E0 10.x.2.2/24
E0
PxR4
The figure shows the topology of the lab equipment used in this exercise. In this
exercise you will use the connection between PxR1 and BBR1, the connection
between PxR3 and BBR2, and the connections within the pod.
L2-2


Note

Two end users
Two end-users stations
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
(config-router)#
aggregate-address
10.x.0.0 255.255.0.0
summary-only
Summarizes BGP routes and

suppresses the advertisement of
the explicit routes
(config-router)#
neighbor ip-address
remote-as as-number
Configures a router as a BGP

neighbor
(config-router)#
network prefix mask

subnet-mask
(config-router)#
no auto-summary
Turns off auto-summarization of

routes by BGP
(config-router)#
no synchronization
Turns off BGP synchronization
(config-router)#
redistribute rip
Allows BGP to advertise routes

learned RIP
(config)#
router bgp 6500x
Enables BGP routing process
> or #
show ip bgp
Displays the BGP database
> or #
show ip bgp summary
Displays a summary of the BGP

neighbor database

L2-3
Task 1: Configure eBGP Peerings

In this part of the lab, you will enable BGP on PxR1 and PxR3, in AS 6500x.
Configure an eBGP peering between PxR1 and BBR1, and an eBGP peering
between PxR3 and BBR2.

1. On PxR1, make sure you can ping the directly connected interface of BBR1
(172.31.x.3) before going further.
On PxR3, make sure you can ping the directly connected interface of BBR2
(10.254.0.2) before going further.
2. At both PxR1 and PxR3, enable BGP using Autonomous System number 6500x,
where x is your pod number.
PxR1/PxR3(config)#router bgp 6500x
3. At PxR1, configure router BBR1 as a BGP neighbor. Use BBR1s directly

connected interface (172.31.x.3) as the IP address you peer with. BBR1 is in AS
64998
PxR1(config-router)#neighbor 172.31.x.3 remote-as 64998
4. At PxR3, configure BBR2 as a BGP neighbor. Use BBR2s directly connected

interface (10.254.0.2) as the IP address you peer with. BBR2 is in AS 64999.
PxR3(config-router)#neighbor 10.254.0.2 remote-as 64999
5. Verify that your eBGP peering is established before proceeding. Your output should
resemble the following example, taken from Pod 5, Router 1. The fact that there is a
number under the State/PfxRcd column means that the session is established.
P5R1#show ip bgp summary
Neighbor
V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
172.31.5.3 4 64998 19
5
49
0
0 00:01:17
38
Task 2: Advertise Networks into BGP

1. At both PxR1 and PxR3, redistribute your IGP into BGP.
PxR1/PxR3(config-router)#redistribute rip
L2-4

2. Display the BGP database to make sure your pod networks are in BGP. Your output
should resemble the following, taken from Pod 5, Router 1. Notice that your pod
subnets do not appear in the BGP database. BGP automatically summarizes to the
classful boundary when networks are inserted into the database.
P5R1#show ip bgp
BGP table version is 50, local router ID is 10.5.100.101
Status codes: s suppressed, d damped, h history, * valid, >
best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Path
*> 10.0.0.0
*> 10.97.97.0/24
64998 64997 i
*> 10.102.1.0/24
64998 65102 i
*> 10.107.1.0/24
64998 64999 65107 I
[output omitted]
Next Hop
Metric LocPrf Weight
0.0.0.0
172.31.5.3
172.31.5.3
172.31.5.3
32768 ?
0
0
0
3. You must disable BGP auto-summarization, in order for all the subnets to appear in
the BGP table. At both PxR1 and PxR3, disable BGP auto-summarization using the
command no auto-summary in BGP configuration mode.
PxR1/PxR3(config)#router bgp 65005
PxR1/PxR3(config-router)#no auto-summary
4. Examine the BGP database once more, to see if your subnets are now present. Your
output should resemble the following, taken from P5R1. Notice that the subnets are
indeed present.
P5R1#show ip bgp
best, i - internal
Network
Path
*> 10.5.0.0/24
*> 10.5.2.0/24
*> 10.5.100.101/32
*> 10.5.100.102/32
[output omitted]
Next Hop
0.0.0.0
10.5.0.2
0.0.0.0
10.5.0.2


0
1
0
1
32768
32768
32768
32768
?
?
?
?
L2-5
5. Telnet to your eBGP neighbor and look at the routing table. (You can view the
routing table from User mode.) The backbone routers are also running some IGPs
so the routing table will have numerous routes. To make it easier for you to find
your routes, use the command show ip route bgp to filter the display. Are your
pods routes present as BGP routes? If so, suspend or exit the telnet session and
proceed to the next step. If not, troubleshoot your BGP configuration.
Task 3: Optimizing BGP

1. Your pod is advertising each subnet in the pod to BBR1 and BBR2. This is
unnecessary. Any routes that start with the IP address of 10.x are reachable by via
your edge routers. Configure PxR1 and PxR3 to summarize your pods routes to
10.x.0.0/16, and to advertise only the summary route.
PxR1/PxR3(config-router)#aggregate-address 10.x.0.0 255.255.0.0
summary-only
2. Look at the IP routing table on PxR1 and PxR3. Do you have a route for 10.x.0.0?
What is the next-hop for the 10.x.0.0/16 route? Why is it set to Null0?
3. Resume the telnet session to your eBGP neighbor and examine the routing table
again. Is your summary route present? Are the explicit routes present?
Examine the BGP database on the backbone router. You should see only the
summary route in both the BGP and the routing tables. Exit the telnet session.
4. All traffic bound out of the pod must go through the edge routers, PxR1 and PxR3.
There are too many BGP routes to advertise into RIP, so instead you will send a
default route to the internal routers.
On PxR1 and PxR3, configure RIP to advertise a default route into the pod. To
accomplish this, first create a default route pointing to your eBGP neighbor. Then
use the command default-information originate under the RIP routing process.
5. It speeds up RIP convergence if you clear the routes on PxR1 and PxR3 after
configuring them to advertise default information. Use the command clear ip route
*.
Wait a minute, and then examine the routing tables on PxR2 and PxR4. Is the
default route present? How did they learn that default route?
6. Verify that the internal routers have connectivity to the backbone via the default
route.
On PxR2, ping 192.168.125.1, an IP address in the core that requires transit through
BBR1. The ping should succeed.
L2-6

On PxR4, ping 172.25.20.1, an IP address in the core that requires transit through
BBR2. The ping should succeed.
You have established an eBGP peering between PxR1 and between PxR3
and BBR2.
Routes are being exchanged between the edge pod routers and their eBGP
peers.
You have summarized your routes to your eBGP peers.
You have advertised a default route to the other routers in your pod.

L2-7
L2-8

Configuring IBGP Peerings

L3-1
Exercise Objective
In this exercise, you will configure an iBGP peering with the other edge router in
your pod. This is for redundancy, to give your network a backup path in case there
are problems with your other external path.
Visual Objective
AS 64998
AS 64999
BBR1
BBR2
10.254.0.2
Frame
Relay
10.x.100.101/32
172.31.x.1/24
DLCI 1xy
S0
10.254.0.3x/24
E1 10.x.100.103/32
10.x.1.1/24
Lo0
PxR1
S1
10.x.0.1/24
E0
10.x.1.3/24
E0
PxR3 Lo0
S0
10.x.3.3/24
AS 6500x
10.x.0.2/24
10.x.3.4/24
S1
S0
10.x.2.4/24
Lo0
PxR2
10.x.100.102/32 S0
E0 10.x.2.2/24
E0
Lo0
PxR4 10.x.100.104/32
The figure shows the topology of the equipment used in this lab. In this exercise
you connect PxR1 to Back Bone Router 1 (BBR1) over the Frame Relay network.
PxR3 connects to BBR2 over an Ethernet link. You will enable the Ethernet link
between the two routers at the end of the lab.
L3-2


Note

Two end users
Two end-users stations
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
(config)#
interface ethernet 0
Enters the interface configuration

mode
(config-if)#
ip address 10.x.1.y
255.255.255.0
Configures an IP address on the

interface
(config-router)#
neighbor 10.x.100.10y
remote-as 6500x
Configures the other edge router

as an iBGP neighbor.
(config-router)#
update-source lo0
Changes the source address in

BGP messages
(config-router)#
no synchronization
Disables BGP synchronization
(config-router)#
redistribute connected
Advertises a connected interface

into RIP, but does not start the
RIP process on that interface
(config)#
router bgp 6500x
Enables configuration of BGP

parameters
> or #
show ip bgp
> or #
show ip bgp summary
Displays a summary of the BGP

neighbor database

L3-3
Task 1: Configuring an iBGP Peer

In your current configuration, each edge router peers with a different backbone
router, simulating peering to two ISPs. Each edge router has a default route pointing
to its eBGP peer. The internal routers have a default route pointing to the edge
routers. There are two paths out of your pod, but the edge routers each know only
one path. To remedy this, PxR1 and PxR3 need to exchange routing information. In
this task you will configure these two routers to be iBGP peers, using the following
steps.

1. Each router has a loopback interface already configured, with an IP address of
10.x.100.10y where x is your pod number and y is the router number. In this lab,
you will establish iBGP peering between the loopback interfaces of PxR1 and PxR3.
Therefore these interfaces must be reachable.
At both PxR1 and PxR3, ping the other edge routers loopback interface to verify
connectivity.
2. When your ping is successful, configure the other edge router as a BGP neighbor.
PxR1 will peer with PxR3s loopback IP address of 10.x.100.103. PxR3 will peer
with PxR1s loopback IP address of 10.x.100.101. Remember to use your
neighbors IP address in the command, not your own.
3. The two edge routers are not directly connected. Will the peering work? What
assumption does iBGP make about how peers are connected?
Check to see if the peering is established using show ip bgp summary. The two
routers should not be peers yet, because there is another command that must be
given. The BGP process must be told to use the IP address of the loopback interface
as the source address in its messages.
4. By default, BGP will source its messages from the IP address of the exit interface.
In our case, each router will use the address of the serial interface as the source IP
address. The neighboring router will look at its neighbor statements to see if it is
configured to peer with a router at that IP address. We have told PxR1 and PxR3 to
peer with a loopback IP address; therefore they must be configured to use that as
their source address.
Configure both PxR1 and PxR3 to use loopback 0 as the source of the updates for
their iBGP sessions.
PxR1(config-router)#neighbor 10.5.100.103 update-source lo0
PxR3(config-router)#neighbor 10.5.100.101 update-source lo0
L3-4

5. You should see the neighbor relationships become established. Once they are, use
show ip bgp to verify that you are receiving BGP routes from the other edge router.
Each edge router should now have two paths in their BGP database for each
external network.
6. Since your pod now has redundant paths to the outside world, test that redundancy.
Shut down the Ethernet 1 interface on PxR3, to test the backup path through PxR1
and AS 64998. Wait a minute, and then look at the IP routing table on PxR3. Are
the BGP networks in the routing table now, pointing toward PxR1? They should not
be, because there is more work you need to do.
Task 2: Tuning the BGP Configuration

Change the configuration on PxR1 and PxR3 so that they are able to use each other
as backup routes.
1. On PxR3, look at the BGP database detail about network 172.25.20.0, a network off
BBR2. You were previously able to ping this network from PxR4. Your output
should resemble the following example, taken from Pod 5. Notice that the last line
says the route is not synchronized.
P5R3#show ip bgp 172.25.20.0
BGP routing table entry for 172.25.20.0/24, version 636
Paths: (1 available, no best path)
Not advertised to any peer
64998 64999 64714 65517
172.31.5.3 (inaccessible) from 10.5.100.101 (10.5.100.101)
Origin IGP, localpref 100, valid, internal, not
synchronized
2. The BGP synchronization rule is preventing PxR3 from using those routes. If the
situation were reversed, it would also prevent PxR1 from using PxR3 as a backup.
This rule says that a BGP router is not allowed to use routes advertised by an iBGP
peer unless those routes are already present in the IP routing table, learned via an
IGP. This is to prevent black holes within your network. Disable BGP
synchronization on both PxR1 and PxR3 in order to use the redundant BGP routes.
3. Wait a minute, and then examine the IP routing table again. Are the routes present
in the routing table of PxR3? They should not be, because there is one more
problem. Look at the BGP database on PxR3 and find the next-hop IP address for
those routes. It is the address of the serial interface on BBR1. Look again at the
routing table. Is there a route for that network?
Because the router does not know how to get to the next-hop address, it cannot use
those routes. (Notice in the output from Step 7 the word inaccessible next to the
next hop address.) We will remedy this in the next step by redistributing the
L3-5
network between PxR1 and BBR1 into RIP. RIP can then provide next hop
information to PxR3.
4. At PxR1, redistribute the connected interfaces into RIP. All interfaces in the
10.x.0.0 network are already present in the RIP database, and RIP is running on
those interfaces. Redistributing connected will place the 172.31.x.0 network into the
RIP database, but will not start the RIP process on interface S0.1. Wait a minute,
and then check the IP routing table on PxR3. The BGP routes should now be
present.
PxR1(config)#router rip
PxR1(config-router)#redistribute connected
Task 3: Providing Connectivity for the Internal Routers

1. Test the backup path from the internal routers. From both PxR2 and PxR4, ping
172.25.20.1 a network off BBR2. Do the pings from both routers succeed?
2. The ping from PxR4 should not succeed. To find out why, trace the route to
172.25.20.1. Your results should resemble the following example taken from Pod 5.
P5R4#trace 172.25.20.1
Type escape sequence to abort.
Tracing the route to 172.25.20.1
1 10.5.3.3 20 msec 20 msec 16 msec
2 10.5.3.4 40 msec 36 msec 32 msec
*
Notice that the packet goes to PxR3, then back to PxR4. You have created a routing
loop by disabling synchronization.
3. When synchronization is disabled, then you need a physical path of BGP peers
through your AS. Otherwise, a routing loop results and your AS becomes a black
hole for traffic (this is the condition synchronization was designed to prevent.) You
have a currently unused Ethernet connection between PxR1 and PxR3. Enable
interface Ethernet 0 on both routers and assign it the following IP address:
PxR1: 10.x.1.1/24
PxR3: 10.x.1.3/24
4. Once the Ethernet 0 interface is up and RIP has converged across that link, try the
ping again. From PxR4, ping 172.25.20.1. The ping should succeed this time. You
have now achieved redundancy in your internet connections via iBGP peering,
disabling synchronization, and enabling the physical link between PxR1 and PxR3.
L3-6


PxR4#ping 172.25.20.1
Sending 5, 100-byte ICMP Echos to 172.25.20.1, timeout is 2
seconds:
!!!!!
Success rate is 100 percent(5/5),round-trip min/avg/max
=72/72/76 ms
Task 4: Cleaning Up
1. Re-enable the Ethernet 1 interface on PxR3. Verify that your peering with BBR2 is
re-established and PxR3 is receiving BGP routes from BBR2.
2. Display the BGP database on BBR1 and find the route to 10.107.1.0, a network that
originated in AS 65107. This autonomous system is directly connected to BBR2.
What are the possible paths for AS 64998 to use in reaching AS 65107? Is your AS
one of them? Your AS should be listed, but not chosen, as a next hop.
3. BBR1 and BBR2 are peers, and BBR1 chooses to route through BBR2 for that
network. However, if the link between BBR1 and BBR2 went down, there is a
possibility that you could become a transit autonomous system. This means that all
traffic between them could flow through your AS. In general, this is something to
be avoided, unless you are providing Internet access services. In Lab 4 you will
learn to filter your advertisements in order to prevent becoming a transit AS.
You have established an iBGP peering between PxR1 and PxR2.
BGP synchronization is disabled on PxR1 and PxR3, so they can use each
other as a backup to their path through their external peer.
PxR3 has a valid next hop for the routes it learns from PxR1.
The Ethernet link between the two edge routers is configured and enabled.

L3-7
L3-8

Using AS Path Filers and

Regular Expressions

L4-1
Using AS Path Filers and Regular Expressions
Exercise Objectives
Filter your eBGP routes in order to avoid becoming a transit AS.
Establish policies about which neighbors you will use to reach specific
autonomous systems.
Configure and apply two AS Path filters using regular expressions
Visual Objective
AS 64998
AS 64999
BBR1
BBR2
10.254.0.2
172.31.x.3
Fram e
Relay
10.x.100.101/32
172.31.x.1/24
D LC I 1xy
S0
10.254.0.3x/24
10.x.100.103/32
E1
10.x.1.1/24
Lo0
PxR 1
S1
10.x.0.1/24
E0
10.x.1.3/24
E0
PxR 3 Lo0
S0
10.x.3.3/24
A S 6500x
10.x.0.2/24
10.x.3.4/24
S0
S1
10.x.2.4/24
Lo0
10.x.100.102/32
PxR 2
S0
E0 10.x.2.2/24
E0
Lo0
PxR 4
10.x.100.104/32
The figure shows the topology of the equipment used in this lab.
Note
L4-2


Two end users
Four Cisco routers
Command List
The commands used in this exercise are described in the table here. NOTE: The
commands are in alphabetical order, not the order in which you will use them.
Table 1: Commands
Router Prompt
Command
Description
clear ip bgp ip-address
Resets the BGP session with a

neighbor
(config)#
ip as-path access-list
number permit|deny
regular-expression
Creates an access list to filter

based on the AS path attribute
(config-router)#
neighbor 172.31.x.3
filter-list 1 out|in
Applies an AS-path access list

to a BGP neighbor
> or #
show ip as-path-accesslist [number]
Displays configured AS-path

access lists
> or #
show ip bgp
> or #
show ip bgp filter-list

number
Limits the display of the BGP

database to prefixes whose AS
path matches the specified filter
list
> or #
show ip bgp regexp ^6500x_
Limits the display of the BGP

database to prefixes matching
the regular expression
Task 1: Filtering Outbound Advertisements

BBR1 and BBR2 think they can use your network as a transit AS because you are
advertising routes learned from your external neighbors. Instead, you should only
advertise routes that originate in your own AS. Configure an AS-path access list to
accomplish this, and apply it to your external neighbors to filter outbound routing
updates. NOTE: Your filters will not take effect until you complete Step 11.

L4-3

1. From PxR1, telnet to BBR1 (172.31.x.3), and from PxR3, telnet to BBR2
(10.254.0.2). Examine the BGP database on these routers, looking for the paths to
AS 65107 on BBR1 and the path to AS 65102 on BBR2. These autonomous
systems are directly connected to BBR2 and BBR1, respectively. (See the diagram
of the AS structure as a reference.) You will see that the two backbone routers
consider your AS (6500x) a possible path between them.
Your AS is advertising all the routes it receives from both BBR routers. A route
advertisement is the promise to get traffic to that network, so in effect you are
telling the backbone routers that they can get to those networks through your AS.
To prevent this, your AS should advertise only the routes that are local to it, your
internal pod networks.
The local AS number is prepended to the AS path list when a route advertisement
leaves the autonomous system. Your internal pod routes have no AS number
associated with them until they are advertised to the backbone by either PxR1 or
PxR3. Therefore, if you allow PxR1 and PxR3 to advertise to their external
neighbors only routes with an empty AS path list, then the backbone will only send
you traffic bound for those networks. You will not become a transit AS.
2. At both PxR1 and PxR3, create an AS-path access list that permits only routes
originated in your AS. That is, you want to permit only routes that have an empty
AS path list. Use a regular expression to specify this.
PxR1/PxR3(config)#ip as-path access-list 1 permit ^$
3. Apply the AS-path access-list to your eBGP neighbor. You want to filter routes that
are advertised to your external neighbor (BBR1 or BBR2) only. No filter should be
applied to your internal neighbor. You are filtering route advertisements that are
leaving your router, thus the filter should be applied outbound. NOTE: Although the
filters are applied, they will not actually take effect until step 12 of this lab.
PxR1(config)#router bgp 6500x
PxR1(config-router)#neighbor 172.31.x.3 filter-list 1 out
PxR3(config-router)#neighbor 10.254.0.2 filter-list 1 out
L4-4

Task 2: Filtering Inbound Advertisements

Your company has established a policy that you should use only the path through
BBR1 for AS 65102, and only the path through BBR2 for AS 65107. Configure AS
path filters to accomplish this, and apply them to your external neighbors to filter
inbound routing updates.
AS 65102 is directly connected to BBR1, advertising network 10.102.1.0. In this
exercise, you want to use only the path through BBR1 for traffic bound to AS
65102. If that path goes down, connectivity is lost.
AS 65107 is directly connected to BBR2, advertising network 10.107.1.0. In this
exercise, you want to use only the path through BBR2 for traffic bound to AS
65107. If that path goes down, connectivity is lost.
1. On PxR1, configure a policy to filter out any advertisements from BBR1 to PxR1
about routes originating in AS 65107. Do this by creating an AS-path access list
that denies updates about routes originating in AS 65107, but permits all other
routes.
PxR1(config)#ip as-path access-list 2 deny _65107$
PxR1(config)#ip as-path access-list 2 permit .*
2. Apply the access list to filter inbound route advertisements from BBR1.
3. On PxR3, configure a policy to filter out any advertisements from BBR2 to PxR3
about routes originating in AS 65102. Do this by creating an AS-path access list
that denies originating in AS 65102, but permits all other routes.
PxR3(config)#ip as-path access-list 2 deny _65102$
PxR3(config)#ip as-path access-list 2 permit .*
4. Apply the access list to filter inbound route advertisements from BBR2.

L4-5
Task 3: Verification
1. Verify the configuration of your as-path access lists using the show ip as-pathaccess-list command.
2. Look at the BGP tables on PxR1 and PxR3. Are the filtered routes present in the
BGP database? NOTE: Although the filters are applied, they will not actually take
effect until you complete step 11 of this lab.
3. Telnet to one of the backbone routers (BBR1 or BBR2) and examine the BGP
database. Are you still a transit AS for them? Use the show ip bgp regexp ^6500x_
command to quickly find all the routes your AS has advertised.
4. New BGP policy changes only take effect when there are new route updates to
send, thus the filtered routes should still be in the databases. To make your changes
take effect immediately, clear the BGP session with your external neighbor. This
causes the session to be terminated, and all the routes to be withdrawn. Your router
will then try to re-establish the session, and each router will re-advertise its routes.
When the routes are re-advertised, they will go through the new filters.
On PxR1, use the command clear ip bgp 172.31.x.3.
On PxR3, use the command clear ip bgp 10.254.0.2
5. Once the session has been re-established, check the BGP databases again, repeating
the previous show commands. Are your filters acting as you expected? Within the
pod, you should now see only one path for network 10.102.0.0, through BBR1, and
one path for network 10.107.0.0, through BBR2. Additionally, on BBR1 and BBR2,
advertisements from your network should have an AS path of only your pods AS.
You have filtered the BGP advertisements from your pod to the backbone
routers.
You have filtered the BGP advertisements from the backbone routers to your
pod.
L4-6

Filtering Route Updates Using

Prefix Lists

L5-1
Filtering Route Updates Using Prefix Lists
Exercise Objective
Routers within the core are summarizing some of their routes, however they are
advertising both the summary route and the specific routes to your pod. This is a
waste of bandwidth and router resources the summary route is all you need. In
this exercise, you will configure and apply prefix lists in order to filter out the
specific routes.
Visual Objective
A S 64998
A S 64999
BBR1
BBR2
1 0 .2 5 4 .0 .2
1 7 2 .3 1 .x .3
F ra m e
R e la y
1 7 2 .3 1 .x .1 /2 4
1 0 .2 5 4 .0 .3 x /2 4
D LC I 1xy
S0
E 1 1 0 .x .1 0 0 .1 0 3 /3 2
1 0 .x .1 0 0 .1 0 1 /3 2
1 0 .x .1 .1 /2 4
E0
1 0 .x .1 .3 /2 4 E 0
Lo0 PxR1
P xR 3 Lo0
S0
S1
1 0 .x .0 .1 /2 4
1 0 .x .3 .3 /2 4
A S 6500x
1 0 .x .0 .2 /2 4
1 0 .x .3 .4 /2 4
S1
S0
1 0 .x .2 .4 /2 4
Lo0
1 0 .x .1 0 0 .1 0 2 /3 2
PxR2
S0
E 0 1 0 .x .2 .2 /2 4
E0
PxR4
Lo0
1 0 .x .1 0 0 .1 0 4 /3 2
The figure shows the topology of the equipment used in this lab. In this exercise,
PxR1 connects to BBR1 through a frame relay circuit, and PxR3 connects to
BBR2 through an Ethernet connection.
Note
L5-2


Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
clear ip bgp ip-address
Tears down and restarts a BGP

neighbor peering
(config)#
ip prefix-list name [seq

no. permit|deny
prefix/length [ge length]
[le length]
Creates a line in a prefix list.
(config-router)#
neighbor ip address
prefix-list list-name in
Applies a prefix list to a BGP

neighbor
> or #
show ip bgp neighbor ipaddress
Displays detailed information

about a BGP neighbor
> or #
show ip prefix-list
Displays any prefix lists that are

configured on the router
Task 1: Create and Apply the Prefix Lists

BBR1 is summarizing some subnets of two class C networks to a /24 mask. BBR2
is summarizing some subnets of two class B networks to a /16 mask. They are
advertising both the summaries and the specific routes to you. This wastes
bandwidth and router resources, since you dont need the information contained in
the specific routes. Create a prefix list that will accept advertisements for those
class C networks from BBR1 only if they have a /24 mask or less, and for those
class B networks from BBR2 only if they have a /16 mask or less.
Note
Filtering inbound routes will save bandwidth in advertisements only to

your downstream peers, since your upstream peer is still advertising all
the routes to you. It will conserve router resources on your router as well
as on downstream routers.

L5-3

1. At PxR1 and PxR3, issue the show ip bgp summary command.
How many network entries does your router have? ____________
How many paths? ______________
How many bytes of memory is the BGP table using? ______________________
2. At PxR1 and PxR3, display the BGP database. The following networks and
summaries should be present. These are the routes to which you will apply the
filter.
172.27.14.0/24
172.27.15.0/24
172.27.16.0/24
172.27.17.0/24
Summary:172.27.0.0/16
192.168.125.0/26
192.168.125.64/26
192.168.125.128/26
192.168.125.192/26
Summary:192.168.125.0/24
172.25.17.0/24
172.25.18.0/24
172.25.19.0/24
172.25.20.0/24
Summary:172.25.0.0/16
192.168.208.0/26
192.168.208.64/26
192.168.208.128/26
192.168.208.192/26
Summary:192.168.208.0/24
3. By referring to the diagram of the AS-path structure, you can see that BBR1 and
BBR2 are connected to each other. In fact, they are BGP peers. Because of this,
PxR1 and PxR3 are getting advertisements about all four networks from their
external neighbor. On both PxR1 and PxR3, create a prefix list that filters out the
specific routes for those networks and permits only the summary route. Remember
to permit all routes for all other networks. Your prefix list may resemble the
following example.
ip
ip
ip
ip
ip
prefix-list
prefix-list
prefix-list
prefix-list
prefix-list
SUM_ONLY
SUM_ONLY
SUM_ONLY
SUM_ONLY
SUM_ONLY
seq
seq
seq
seq
seq
10
20
30
40
50
deny 172.27.0.0/16 ge 17
deny 172.25.0.0/16 ge 17
deny 192.168.125.0/24 ge 25
deny 192.168.208.0/24 ge 25
permit 0.0.0.0/0 le 32
4. Before applying the prefix list, verify it with the show ip prefix-list command.
5. Because you want to filter prefixes that are advertised to you from your external
neighbor, apply the prefix list inbound.
6. Using the show ip bgp neighbor ip-address command, verify that the prefix list is
applied to the correct neighbor, and in the correct direction.
L5-4

7. In order for the policy to take effect, the backbone routers must re-advertise their
routes to us. Force them to do this by clearing the BGP session between your
router and its external neighbor. This is disruptive to routing, and is not usually
recommended. In the next lab you will practice less drastic ways of applying a
policy.
8. Once your eBGP peer is back up, display the BGP database on PxR1 and PxR3 to
see if your filter worked. Do you see only the summaries for those four networks?
Are all your other routes still there?
9. Use the command show ip prefix-list detail to see the number of hits for each line
in your prefix list. Did each line get at least one hit?
PxRy#show ip prefix-list detail
Prefix-list with the last deletion/insertion: SUM_ONLY
ip prefix-list SUM_ONLY:
count: 5, range entries: 5, sequences: 10 - 50, refcount: 3
seq 10 deny 172.27.0.0/16 ge 17 (hit count: 4, refcount: 3)
seq 20 deny 172.25.0.0/16 ge 17 (hit count: 4, refcount: 1)
seq 30 deny 192.168.125.0/24 ge 25 (hit count: 3, refcount:
2)
seq 40 deny 192.168.208.0/24 ge 25 (hit count: 3, refcount:
1)
seq 50 permit 0.0.0.0/0 le 32 (hit count: 16, refcount: 1)
10. Issue the command show ip bgp summary once more.

How many network entries does your router have now? ____________
How many bytes of memory is the BGP table using? ______________
Is BGP less resource-intensive for your router now? ______________
The specific routes have been filtered for networks 172.25.0.0/16,
172.27.0.0/16, 192.168.125.0/24, and 192.168.208.0/24.
Other routes are still being advertised and received.

L5-5
L5-6

Route Refresh and Soft

Reconfiguration

L6-1
Route Refresh and Soft Reconfiguration
Exercise Objective
New BGP policies are applied only when routes are advertised, which could be a
long time. In previous labs we have forced the advertisement by resetting the BGP
peering. This is disruptive to routing, and not usually a good idea. In this exercise,
you will explore and configure two other options for applying BGP policies soft
reconfiguration and route refresh.
Visual Objective
AS 64998
A S 64999
BBR1
BBR2
1 0 .2 5 4 .0 .2
1 7 2 .3 1 .x .3
F ra m e
R e la y
1 7 2 .3 1 .x .1 /2 4
D LC I 1xy
1 0 .x .1 0 0 .1 0 1 /3 2
1 0 .2 5 4 .0 .3 x /2 4
S0
E1
1 0 .x .1 0 0 .1 0 3 /3 2
1 0 .x .1 .1 /2 4
Lo0
PxR 1
S1
1 0 .x .0 .1 /2 4
1 0 .x .1 .3 /2 4 E 0
E0
Lo0
PxR3
S0
1 0 .x .3 .3 /2 4
A S 6500x
1 0 .x .0 .2 /2 4
1 0 .x .3 .4 /2 4
S0
S1
1 0 .x .2 .4 /2 4
Lo0
PxR2
1 0 .x .1 0 0 .1 0 2 /3 2 S 0
E 0 1 0 .x .2 .2 /2 4
E0
Lo0
P x R 4 1 0 .x .1 0 0 .1 0 4 /3 2
PxR1 connects to BBR1 through a frame relay circuit, and PxR3 connects to BBR2
through an Ethernet connection.
Note
L6-2


Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
clear ip bgp {*|ip

address|peer-group name}
in
Triggers a route refresh

message
clear ip bgp {*|ipaddress|peer-group name}

soft in
Causes the router to re-apply

any filters to the saved copy of
neighbor routes.
debug ip bgp
Displays real-time BGP actions
debug ip bgp updates
Displays real-time BGP updates

sent and received
(config-router)#
neighbor ip-address
soft-reconfiguration
inbound
Tells your router to keep a copy

of all the routes advertised by
that neighbor
> or #
show ip bgp neighbor
Displays detailed information

about BGP neighbors
> or #
show ip bgp neighbor ipaddress received-routes
Displays the original routes

received from a neighbor, when
inbound soft reconfiguration is
enabled

L6-3
Task 1: Resetting a BGP Session

In previous labs, you have reset the BGP session in order to make new policies take
effect. In this task, you will debug BGP then reset the session, and watch what
happens. Then you will compare this to the other two methods of making policies
take effect.
1. At both PxR1 and PxR3, turn on general BGP debugging and debugging of BGP
updates.
2. Clear the BGP session with your iBGP neighbor, at either router. Watch the debug
output to see what messages are sent and received. You should see the session being
torn down, and then re-established. After that, route advertisements will be
exchanged between the two routers. Your output should resemble the following,
taken from Pod 4 Router 3. NOTE: some output is omitted.
PxR1 or PxR3#clear ip bgp ip-address
3w3d: BGP: 10.4.100.101 went from Established to Idle
3w3d: %BGP-5-ADJCHANGE: neighbor 10.4.100.101 Down User reset
3w3d: BGP: 10.4.100.101 closing
3w3d: BGP: 10.4.100.101 went from Idle to Active
3w3d: BGP: 10.4.100.101 open active, delay 5964ms
3w3d: BGP(0): Aggregate processing for IPv4 Unicast
[output omitted]
w3d: BGP: 10.4.100.101 open active, local address 10.4.100.103
3w3d: BGP: 10.4.100.101 went from Active to OpenSent
3w3d: BGP: 10.4.100.101 sending OPEN, version 4, my as: 65004
3w3d: BGP: 10.4.100.101 send message type 1, length (incl.
header) 45
3w3d: BGP: 10.4.100.101 rcv message type 1, length (excl.
header) 26
3w3d: BGP: 10.4.100.101 rcv OPEN, version 4
3w3d: BGP: 10.4.100.101 rcv OPEN w/ OPTION parameter len: 16
3w3d: BGP: 10.4.100.101 rcvd OPEN w/ optional parameter type 2
(Capability) len 6
3w3d: BGP: 10.4.100.101 OPEN has CAPABILITY code: 1, length 4
3w3d: BGP: 10.4.100.101 OPEN has MP_EXT CAP for afi/safi: 1/1
(Capability) len 2
3w3d: BGP: 10.4.100.101 OPEN has CAPABILITY code: 128, length 0
3w3d: BGP: 10.4.100.101 OPEN has ROUTE-REFRESH capability(old)
for all address-families
(Capability) len 2
3w3d: BGP: 10.4.100.101 OPEN has CAPAB
PxR3#ILITY code: 2, length 0
3w3d: BGP: 10.4.100.101 OPEN has ROUTE-REFRESH capability(new)
for all address-families
3w3d: BGP: 10.4.100.101 went from OpenSent to OpenConfirm
L6-4


3w3d: BGP: 10.4.100.101
header) 19
3w3d: BGP: 10.4.100.101
header) 0
3w3d: BGP: 10.4.100.101
3w3d: %BGP-5-ADJCHANGE:
send message type 4, length (incl.

rcv message type 4, length (excl.
went from OpenConfirm to Established
neighbor 10.4.100.101 Up

header) 19
3w3d: BGP(0): 10.4.100.101 computing updates, afi 0, neighbor
version 0, table version 247, starting at 0.0.0.0
3w3d: BGP(0): 10.4.100.101 NEXT_HOP part 1 net 10.97.97.0/24,
next 10.254.0.3
3w3d: BGP(0): 10.4.100.101 send UPDATE (format) 10.97.97.0/24,
next 10.254.0.3, metric 0, path 64999 64997
[further output omitted]
3. Turn off the debug (the fastest way to do this is with the command u all, short for
undebug all).
Task 2: Route Refresh

Route refresh is a BGP capability that is negotiated between two routers when they
first establish a session. It lets a router request that a neighbor resend its route
information, so that it can be passed through a new inbound policy. Since there is
no configuration involved, you will verify that your routers have this capability, and
watch it in action.

1. At both PxR1 and PxR3, display information about your BGP neighbors with the
show ip bgp neighbor command. Look for route refresh capability. Below is a
partial output from this command.
PxR1/PxR3#show ip bgp neighbor 10.x.100.10y
BGP neighbor is 10.x.100.101, remote AS 6500x, internal link
BGP version 4, remote router ID 10.x.100.101
BGP state = Established, up for 00:07:55
Last read 00:00:55, hold time is 180, keepalive interval is
60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Address family IPv4 Unicast: advertised and received
Received 7497 messages, 0 notifications, 0 in queue
Sent 7463 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Default minimum time between advertisement runs is 5 seconds
L6-5
2. Turn on debugging of BGP and BGP updates once again.

3. Trigger a route refresh message to your internal BGP peer (either PxR1 or PxR3)
with clear ip bgp ip-address in. Watch the debug output to see what messages are
sent and received. Your output should resemble the following sample, taken from
Router 3:
PxR3#clear ip bgp 10.4.100
header) 19
PxR3#clear ip bgp 10.4.100.101 in
PxR3#
3w3d: BGP: 10.4.100.101 sending REFRESH_REQ(5) for afi/safi:
1/1
header) 23
3w3d: BGP(0): 10.4.100.101 rcvd UPDATE w/ attr: nexthop
10.4.100.101, origin i, localpref 100, metric 0
3w3d: BGP(0): 10.4.100.101 rcvd 172.31.4.0/24...duplicate
ignored
172.31.4.3, origin i, localpref 100, path 64998 64997
3w3d: BGP(0): 10.4.100.101 rcvd 10.97.97.0/24...duplicate
ignored
172.31.4.3, origin i, localpref 100, atomic-aggregate,
aggregated by 64998 172.31.8.3, path 64998 65208 65125
4. Turn off the BGP debugging. Compare the router actions during a route refresh with
those when you reset the session in step 2. Is the session between the two routers
disrupted during the route refresh? Which was faster?
Task 3: Soft Reconfiguration

1. At both PxR1 and PxR3, verify that soft reconfiguration is not enabled with your
external neighbor, with the command show ip bgp neighbor ip-address receivedroutes.
PxR1#show ip bgp neighbor 172.31.x.3 received-routes
% Inbound soft reconfiguration not enabled on 172.31.x.3
PxR3#show ip bgp neighbor 10.254.0.2 received-routes
% Inbound soft reconfiguration not enabled on 10.254.0.2
2. At PxR1 and PxR3, issue the show ip bgp summary command.

L6-6


How many bytes of memory is the BGP table using? _______________________.
This is for use in a later step.
3. Next, enable inbound soft reconfiguration with your external BGP neighbor (either
BBR1 172.31.x.3 or BBR2 10.254.0.2). Issue the show ip bgp neighbor ipaddress received-routes command again to verify that soft inbound reconfiguration
is active. You should see routes listed this time.
4. Once again, turn on debugging of BGP and BGP updates.
Issue the command for a soft inbound clearing of the session with your external
BGP peer, clear ip bgp ip-address soft in.
5. Once again, watch the debug output to see what messages are sent and received.
Compare it to the previous two methods of applying policy. Is the BGP session torn
down? Does the neighbor router resend any information? Which is fastest? Your
output should resemble the following from Pod 1, Router 3.
P1R3#debug ip bgp
BGP debugging is on
P1R3#debug ip bgp updates
BGP updates debugging is on
P1R3#clear ip bgp 10.254.0.2 soft in
PxR3#
00:18:36: BGP(0): start inbound soft reconfiguration for
10.254.0.2
00:18:36: BGP(0): process 10.102.1.0/24, next hop 0.88.68.54,
metric 0 from 10.254.0.2
00:18:36: BGP(0): Prefix 10.102.1.0/24 rejected by inbound
filter-list.
00:18:36: BGP(0): update denied
distribute/prefix-list.
00:18:36: BGP(0): process 172.25.19.0/24, next hop 0.8
L6-7

P8.68.94, metric 0 from 10.254.0.2
6. At PxR1 and PxR3, issue the show ip bgp summary command again and look at
the amount of memory being used by BGP.
How many bytes of memory is the BGP table using now? ____________________
7. Compare that to the amount you noted in Step 9. Has enabling soft reconfiguration
caused memory use to increase?
8. Remove the neighbor ip-address soft-reconfiguration inbound statement from
your EBGP peer.
You have seen how BGP route refresh works
You have configured BGP inbound soft reconfiguration and watched how it
works.
You have compared the three methods of forcing the router to immediately
apply a new policy.
L6-8

Configuring the Weight

Attribute

L7-1
Configuring the Weight Attribute
Exercise Objective
Weight is a value that is local to the router, and is used to control the path choice
when a router has more than one local path to a destination. In this exercise, you
will configure a second BGP peering for your edge routers. You will then set a
weight value for routes received from each eBGP neighbor, and monitor the
resulting path choice.
Visual Objective
BBR1
S 0 - 1 7 2 .3 1 .x .3
E 0 - 1 0 .2 5 4 .0 .1
BBR2
S 0 - 1 7 2 .3 1 .x x .4
E 0 - 1 0 .2 5 4 .0 .2
AS 64998
AS 64999
BBR1
BBR2
F ra m e
R e la y
1 0 .x .1 0 0 . 1 0 1 /3 2
S 0 .1 - 1 7 2 . 3 1 .x . 1 /2 4
DLC I 1xy
S 0 .2 - 1 7 2 .3 1 . x x . 1 /2 4
S0
DLC I 2xy
Lo0
PxR 1
S1
1 0 .x .0 . 1 /2 4
E0
1 0 .2 5 4 .0 . 3 x /2 4
E1
1 0 .x . 1 .1 /2 4
E0
1 0 .x .1 .3 /2 4
1 0 .x . 1 0 0 .1 0 3 /3 2
Lo0
PxR 3
S0
1 0 .x . 3 .3 /2 4
A S 6500x
1 0 .x .0 . 2 /2 4
1 0 .x .3 .4 /2 4
S1
S0
1 0 .x .2 . 4 /2 4
Lo0
1 0 .x .1 0 0 . 1 0 2 /3 2
PxR2
S0
E 0 1 0 . x .2 .2 /2 4
E0
PxR4
Lo0
1 0 . x .1 0 0 .1 0 4 /3 2
PxR1 connects to BBR1 and BBR2 through a frame relay circuit, and PxR3
connects to BBR1 and BBR2 through an Ethernet connection.
L7-2


Note

Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
(config-if)#
frame-relay interfacedlci 2x1
Associates a DLCI with a

frame-relay subinterface
(config)#
interface s0.2 point-topoint
Creates a second frame-relay

subinterface.
(config)#
ip as-path access-list 3
permit regexp
Creates a line in an AS-path

access list
(config-route-map)#
match as-path ACL-no.
Matches against an AS-path

access-list
(config-router)#
neighbor ip-address
route-map in
Applies an inbound route-map

to the specified neighbor
(config-router)
neighbor ip-address
weight 100
Sets a weight of 100 on all

routes received from the
specified neighbor
(config-router)
no neighbor ip-address
prefix-list list-name in
Removes an inbound prefix list

from a neighbor
(config)#
route-map name permit|deny seq-no.
Creates a route map statement
(config-route-map)#
set weight 150
Sets the weight for routes that

match the statement
> or #
show ip bgp regexp

_64714_
Displays a filtered view of the

BGP database
show route-map name
Displays the configured route

map

L7-3
Task 1: Configuring a Second eBGP Peer

Configure PxR1 and PxR3 to peer with the other backbone router.
Configure PxR1 by completing these steps:

1. Remove the prefix list from your EBGP peer, so that you are getting full routes
from each peer. Do a route refresh with your EBGP neighbor once the prefix list is
removed.
PxR1(config-router)#no neighbor 172.31.x.3 prefix-list SUM-ONLY
in
PxR3(config-router)#no neighbor 10.254.0.2 prefix-list SUM_ONLY
in
2. On PxR1, create a second point-to-point subinterface under interface serial 0. Give

it an IP address of 172.31.xx.1/24, where xx stands for your pod number twice.
For instance, pod 3s IP address is 172.31.33.1. Associate DLCI number 2x1 with
the new subinterface.
PxR1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PxR1(config)#interface s0.2 point-to-point
PxR1(config-subif)#ip address 172.31.xx.1 255.255.255.0
3. This new subinterface has a PVC connecting it to BBR2. Ping the interface of
BBR2 (172.31.xx.4) to verify connectivity. Do not proceed to the next step until you
can ping BBR2.
4. Currently PxR1 has an iBGP peering with PxR3, and an eBGP peering with BBR1.
Configure PxR1 to peer with BBR2. BBR2 is in AS 64999, IP address 172.31.xx.4.
Configure PxR3 by completing these steps:

5. BBR1 is on the same Ethernet network as PxR3 and BBR2. On PxR3, ping BBR1s
Ethernet interface (10.254.0.1) to verify connectivity. Do not proceed to the next
step until you can ping BBR1.
6. Currently PxR3 has an iBGP peering with PxR1, and an eBGP peering with BBR2.
Configure it to peer with BBR1. BBR1 is in AS 64998, IP address 10.254.0.1.
L7-4

Task 2: Configuring Weight

Once the BGP session is established, note the paths chosen to AS 65208 and AS
64714. Use weight to cause PxR1 to use AS 64999 as the next hop for AS 65208,
and PxR3 to use AS 64998 as the next hop for AS 64714.
1. On both PxR1 and PxR3, display the BGP neighbor list, and verify that your session
with your new external neighbor is established. Each router should have three BGP
neighbors; the number of prefixes received will be listed when the session is
established.
2. Look at the BGP databases on PxR1 and PxR3. On PxR1, what is the next hop
chosen for traffic originating in AS 65208? On PxR3, what is the next hop chosen
for traffic originating in AS 64714? (To make this easier to find, you may want to
filter the database display by using a regular expression with your show ip bgp
command.)
PxR1#show ip bgp regexp _65208$
3. PxR1 should see BBR1 as the next hop for AS 65208, and PxR3 should see BBR2
as the next hop for AS 64714, based on shortest AS path length. In the next few
steps you will control the BGP path selection in the following ways.
On PxR1, change the default behavior of BGP by configuring the following:
Set the weight of all routes received from BBR1 to 100
Set the weight of routes originating in AS 65208 to 150, when they are
advertised by BBR2
On PxR3, change the default behavior of BGP by configuring the following:
Set the weight of all routes received from BBR2 to 100
Set the weight of routes originating in AS 64714 to 150, when they are
advertised by BBR1.
Accomplish the first requirement by setting weight to 100, using a neighbor
statement. If you are configuring PxR1, set the weight on routes from BBR1. If you
are configuring PxR3, set the weight on routes from BBR2.
4. To accomplish the second requirement, you must first configure an AS-path access
list that matches the appropriate AS path. If you are doing these labs in the
classroom, you already have two access lists created. Display these, note their
numbers, and be sure to use a different number for your new access list.
PxR1#show ip as-path-access-list
AS path access list 1
L7-5

permit ^$
deny _65107$
permit .*
Your AS-path access list may resemble the following example:

PxR1(config)#ip as-path access-list 3 permit _65208$
5. Next, create a route map that matches the AS-path access list and sets the weight to
150. Remember to put a second line in your route map that has no match or set
statements, in order to let all other routes through unchanged. Display the route map
to make sure it is correct before applying it to your neighbor.
PxR1/PxR3(config)#route-map WEIGHT permit 10
PxR1/PxR3(config-route-map)#match as-path 3
PxR1/PxR3(config-route-map)#set weight 150
PxR1/PxR3(config-route-map)#exit
PxR1/PxR3(config)#route-map WEIGHT permit 20
PxR1/PxR3#show route-map WEIGHT
route-map WEIGHT, permit, sequence 10
Match clauses:
as-path (as-path filter): 3
Set clauses:
weight 150
Policy routing matches: 0 packets, 0 bytes
route-map WEIGHT, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
6. Apply the route map to your eBGP neighbor in a neighbor statement. If you are
configuring PxR1, apply it to BBR2. If you are configuring PxR3, apply it to BBR1.
You are setting the weight for routes advertised to you, so apply the route map
inbound (which is the only direction you can set weight.)
7. Make the policy take effect by sending a route refresh to BOTH BBR1 and BBR2.
You do this by using the clear ip bgp ip-address in command.
8. Look at the BGP database on PxR1 and PxR3 once again. Are your weight values
present? What is the path chosen for AS 64714 on PxR3, and the path chosen for
AS 65208 on PxR1? Has it changed? Your router should choose the route with the
highest weight over the route with the shortest AS path.
L7-6


Your output should resemble this example taken from Pod 1, Router 1:
best, i - internal
Origin codes: i - IGP, e - EGP, ? incomplete
Network
Next Hop
Metric LocPrf Weight Path
* 192.168.208.0/26 172.31.1.3
0
100 64998
65208 i
*>
172.31.11.4
150 64999
64998 65208 i
* i
10.254.0.1
0
100
0 64998
65208 i
*> 192.168.208.0
172.31.11.4
150 64999
64998 65208 i
* i
10.254.0.1
100
0 64998
65208 i
*
172.31.1.3
100 64998
65208 i
* 192.168.208.64/26
172.31.1.3
0
100 64998
65208 i
*>
172.31.11.4
150 64999
64998 65208 i
* i
10.254.0.1
0
100
0 64998
65208 i
* 192.168.208.128/26
172.31.1.3
0
100 64998
65208 i
*>
172.31.11.4
150 64999
64998 65208 i
* i
10.254.0.1
0
100
0 64998
65208 i
* 192.168.208.192/26
172.31.1.3
0
100 64998
65208 i
*>
172.31.11.4
150 64999
64998 65208 i
* i
10.254.0.1
0
100
0 64998
65208 i

L7-7
Set BGP weight using both a neighbor statement and a route map.
L7-8

Configuring the Local

Preference Attribute

L8-1
Configuring the Local Preference Attribute
Exercise Objective
The local preference attribute is advertised within an autonomous system, and
influences BGP path choice for all routers in that autonomous system. In this
exercise, you will configure the routers to advertise a local preference value that
causes them to use the path through PxR3 to AS 64999 as their primary exit from
the AS, and the path through PxR1 to AS 64999 as a backup.
Visual Objective
BBR1
S 0 - 1 7 2 .3 1 .x .3
E 0 - 1 0 .2 5 4 .0 .1
BBR2
S 0 - 1 7 2 .3 1 .x x .4
E 0 - 1 0 .2 5 4 .0 .2
A S 64998
A S 64999
BBR1
BBR2
F ra m e
R e la y
S 0 .1 - 1 7 2 . 3 1 .x . 1 /2 4
D LC I 1xy
S 0 .2 - 1 7 2 .3 1 . x x .1 / 2 4
S0
D LC I 2xy
1 0 . x .1 0 0 .1 0 1 /3 2
1 0 .2 5 4 .0 .3 x /2 4
1 0 . x .1 .1 /2 4
Lo0
PxR1
S1
1 0 . x .0 .1 /2 4
E0
1 0 .x .1 0 0 .1 0 3 /3 2
E1
1 0 .x .1 . 3 /2 4
E0
Lo0
PxR3
S0
1 0 . x .3 .3 /2 4
A S 6500x
1 0 . x .0 .2 /2 4
1 0 .x .3 .4 / 2 4
S1
S0
1 0 .x .2 .4 /2 4
Lo0
1 0 . x .1 0 0 .1 0 2 /3 2
PxR2
S0
E 0 1 0 .x .2 . 2 /2 4
E0
PxR4
Lo0
1 0 .x .1 0 0 .1 0 4 / 3 2
Note
L8-2


Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
(config-router)#
neighbor ip-address
route-map name in
Applies a route map to a

BGP neighbor
(config-router)#
route-map name in
Removes the route map

setting a weight value from
your BGP neighbor
(config-router)#
weight 100
Removes the command

setting a default weight for
all routes from this neighbor
(config)#
route-map name
permit|deny seq-no.
Creates a route map
(config-routemap)#
set local-preference
150
Sets the local preference

value to 150
Task 1: Clean-up
If you are doing this lab individually, you can skip this Task it has already been
done for you. If you are doing this lab in a classroom, either do the following steps
or reset your equipment to Lab BGP08.
Remove the weight policy and the filter lists applied during previous labs.

1. Connect to your assigned edge routers (PxR1 and PxR3). Give the command show
run | begin bgp to see your BGP configuration. Note the neighbor statements that
add a weight value to routes from your neighbors, and the ones that apply a filter
list to an eBGP neighbor. They should look something like this (your route-map
name may differ):
L8-3

neighbor
neighbor
neighbor
neighbor
172.31.xx.4 route-map Weight in

172.31.x.3 weight 100
172.31.x.3 filter-list 2 in
172.31.x.3 filter-list 1 out
neighbor
neighbor
neighbor
neighbor
10.254.0.1
10.254.0.2
10.254.0.2
10.254.0.2
route-map Weight in
weight 100
filter-list 2 in
filter-list 1 out
2. On both PxR1 and PxR3, remove those BGP neighbor statements by typing the
command with a no in front of it. Make sure you do not remove the statement that
makes you BGP peers with these routers!
PxR1(config-router)#no neighbor
172.31.x.3 weight 100

172.31.xx.4 route-map WEIGHT in
172.31.x.3 filter-list 2 in
172.31.x.3 filter-list 1 out

10.254.0.2
10.254.0.1
10.254.0.2
10.254.0.2
weight 100
route-map WEIGHT in
filter-list 2 in
filter-list 1 out
Task 2: Setting Local Preference

Your ISP in AS 64999 (BBR2) has given you a special deal on Internet access, so
you want to send all your pod traffic that way, still maintaining AS 64998 and
BBR1 as a backup. The link between PxR3 and BBR2 is faster than the link
between PxR1 and BBR2, so you want all traffic to use that link. Configure local
preference on PxR1 and PxR3 so that both routers prefer the path through PxR3 and
BBR2 for all the external networks.
1. View the BGP database. Are there any local preference values present? At this
point, there should only be a local preference value of 100 on routes advertised to
you by your iBGP peer.
2. Configure PxR1 to act as a backup route to BBR2 in case the link through PxR3
fails. To do this, create a route map on PxR1 that sets a local preference of 150.
(The local preference value must be higher than the default local preference of 100
given to routes from BBR1.) The route map needs no match statement, so that it
will match all routes. Apply this route map to BBR2 (172.31.xx.4), inbound.
L8-4

3. In order for PxR3 to be the preferred exit point, it needs to advertise a higher local
preference than is being advertised by PxR1. Configure PxR3 to set a local
preference value of 200 on all routes received from BBR2. To do this, create a route
map that sets a local preference of 200. (The route map needs no match statement,
so that it will match all routes.) Apply this route map to BBR2 (10.254.0.2),
inbound.
4. What must you do for the policy to take effect immediately? Use the route refresh
capability by giving the command clear ip bgp * in to refresh the routes from all of
your neighbors.
5. View the BGP database on PxR1 and PxR3 again. Do you see the local preference
values? Are they correct?
You will see fewer routes in PxR3s database than before. This is due to split
horizon PxR1 is using PxR3 as its next-hop for most of its routes. Therefore it will
not advertise those routes back to PxR3.
6. Look at your IP routing table. Do all external routes lead through PxR3 and BBR2?
On both PxR1 and PxR3, all external routes should point to BBR2 (10.254.0.2). Do
one last test from PxR1, trace the route to 192.168.208.1. This is a network in an
AS connected to BBR1, so the normal path to it would be through BBR1. Make
sure that the traceroute shows the packets going through PxR3 and BBR2. Your
results should resemble the following:
PxR1#trace 192.168.208.1
1 10.8.1.3 4 msec 8 msec 4 msec
2 10.254.0.2 8 msec 20 msec 8 msec
3 10.254.0.1 16 msec * 16 msec
Your pods edge routers advertise the appropriate local preference.
You can verify the path your pod traffic is taking by using traceroute.

L8-5
L8-6

AS-Path Prepending

L9-1
AS-Path Prepending
Exercise Objective
In previous labs, weight and local preference were used to influence the path taken
by traffic bound out of your pod. Now you will influence the path that traffic takes
into your pod. BGP does not allow you to set policies for other autonomous
systems. However, there are ways you can influence their path decision. In this
exercise, you will configure AS-path prepending in order to make one path into
your AS look more attractive than the other.
Visual Objective
BBR1
S 0 - 172.31.x.3
E 0 - 10.254.0.1
BBR2
S 0 - 172.31.xx.4
E 0 - 10.254.0.2
A S 64998
A S 64999
BBR1
BBR2
F ram e
R elay
S 0.1 - 1 72.31 .x .1 /2 4
D L C I 1 xy
S0 .2 - 1 72.31.xx .1 /2 4
10.x.10 0.101 /3 2
S0
D L C I 2 xy
L o0
P xR 1
S1
10.x.0.1/24
1 0.254 .0 .3 x/24
E1
E0
E0
10 .x .1 00.10 3/32
P xR 3 Lo 0
S0
10.x.3.3/24
A S 6500x
10.x.0.2/24
10.x.3.4/24
S0
S1
1 0.x.2.4/24
L o0
10.x.10 0.102 /3 2
Px R 2
S0
E 0 10 .x .2 .2 /2 4
E0
Px R 4
Lo0
10 .x .1 00.10 4/32
L9-2

AS-Path Prepending
Note

Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
clear ip bgp ipaddress soft out
Causes outbound routes to be

tested against the new policy
and readvertised
(config)#
route-map name
permit|deny seq-no.
Creates a route map

statement.
(config-routemap)#
set as-path prepend

AS-no. AS-no. etc.
Prepends your AS number

multiple times onto route
advertisements
> or #
show ip bgp regexp

regexp
Filters the output of the show

ip bgp command

L9-3
AS-Path Prepending
Task 1: Configuring AS-Path Prepending

The rest of the world has two paths to your autonomous system: through AS 64998
(BBR1) and through AS 64999 (BBR2). The path through AS 64999 and BBR2 is
your primary path. Local preference has been set to make all outbound traffic go
through BBR2. You would like to also use BBR2 for inbound traffic. Use AS-path
prepending to make the path through BBR1 less attractive to the rest of the world.

1. AS-path prepending is set by using a route map. At both PxR1 and PxR3, configure
a route map that matches all routes, and prepends your pod AS number four times.
PxR1/PxR3(config)#route-map PREPEND permit 10
PxR1/PxR3(config-route-map)#set as-path prepend 6500x 6500x
6500x 6500x
2. A path with a long AS path is less likely to be chosen than one with a short AS path.
You want the path to your AS that goes through BBR1 to have a longer AS path
than the one through BBR2, in the eyes of the rest of the world. Therefore, apply
the route-map to BBR1, on both PxR1 and PxR3. The AS path attribute is added
when routes leave your autonomous system, so apply the route map outbound.
3. Do an outbound soft clearing of the BGP session, to make the new policy take
effect immediately.
4. Telnet to BBR1 and view the BGP database. Look for your prepended routes. To
make it easier, use a regular expression to filter the routes displayed (for example,
show ip bgp regexp _6500x_6500x_). Your results should look similar to this
example. You should see the AS path prepended to the routes advertised by your
pod. Why is it listed five times instead of four?
BBR1>show ip bgp regexp _6500x_6500x
best, i - internal
Network
Next Hop
Path
* 10.x.0.0/16
10.254.0.3x
0
6500x 6500x 6500x 6500x 6500x i
*
172.31.x.1
0
6500x 6500x 6500x 6500x 6500x i
* 10.97.97.0/24
10.254.0.2
0
6500x 6500x 6500x 6500x 6500x 64999 64997 i
L9-4

AS-Path Prepending
* 10.107.1.0/24
10.254.0.2
6500x 6500x 6500x 6500x 6500x 64999 65107 I
[output omitted]
5. View the entire BGP database, and verify that the path selected for the summary
route to your pod leads through BBR2.
BBR1>show ip bgp
best, i - internal
Network
Next Hop
* 10.x.0.0/16
10.254.0.3x
6500x 6500x 6500x 6500x i
*>
10.254.0.3x
6500x i
*
172.31.x.1
6500x 6500x 6500x 6500x I
[output omitted]

0 6500x
0 64999
0 6500x
6. Telnet to BBR2 and view the BGP database. You should not see the prepending on
any of your pod routes.
You have influenced the path selection for inbound traffic by using AS-path
prepending.

L9-5
AS-Path Prepending
L9-6

Configuring the MED Attribute

L10-1
Exercise Objective
BGP does not allow you to set policies for other autonomous systems; they decide
for themselves what paths their traffic takes. Therefore, you cannot directly control
the path taken by traffic bound for your network. You can influence it, however.
One way is by using AS-path prepending, as covered in Lab 9. In this exercise you
will configure a second way by setting the Multi-Exit Discriminator (MED)
attribute.
Visual Objective
BBR1
S 0 - 1 72.31.x.3
E 0 - 1 0.254.0.1
BBR2
S 0 - 172 .3 1.xx.4
E 0 - 10.254 .0.2
A S 64998
A S 64999
BBR1
BBR2
F ram e
R elay
S 0.1 - 172 .31.x.1 /24

D LC I 1xy
S 0.2 - 172 .31.xx .1/24
10 .x.100 .101/3 2
D LC I 2xy
S0
1 0.254.0.3x/2 4
E1
10.x .1.1/24
L o0
PxR1
S1
10.x.0 .1/24
E0
10.x.1 .3/24
E0
1 0.x.10 0.103 /32
P xR 3 L o0
S0
1 0.x.3.3 /24
A S 65 00x
10.x.0 .2/24
10.x.3.4/24
S0
S1
10.x.2 .4/24
Lo 0
10 .x.100 .102/3 2
P xR 2
S0
E 0 10 .x.2.2 /24
E0
PxR4
L o0
10.x.100.104/32
L10-2

Note

Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
clear ip bgp ipaddress soft out
Causes the router to readvertise routes to a

neighbor
(config-router)#
neighbor ip-address
route-map name out
Applies a route map to a

BGP neighbor
(config)#
route-map name
permit|deny seq-no.
Creates a route map

statement
(config-routemap)#
set metric value
Sets the MED to the

specified value
> or #
show ip bgp 10.x.0.0
Displays more detailed

information on the routes to
that network
Task 1: Configure the MED Attribute

By using AS-path prepending, your autonomous system is making it more likely
that traffic bound into your network will go through BBR2. However, BBR2 has
two ways into your AS through PxR1 and PxR3. Since all outbound traffic is
going through PxR3, you would like to have symmetrical routing. You want all
L10-3
inbound traffic to be handled by PxR1. In this task, you will set the MED values
advertised to BBR2 to encourage it to take the path you want.

1. Telnet to BBR2 (IP addresses 172.31.xx.4 and 10.254.0.2) and view the MED
values on the route to 10.254.0.0 advertised by your pod. Because this route was
redistributed into BGP from RIP, it will have a MED value equal to the RIP metric.
Your pod also advertises a summary route, but it has no MED value since it was
originated within BGP.
BBR2>show ip bgp 10.254.0.0
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to peer-groups:
students students2
Advertised to non peer-group peers:
10.254.0.1 10.254.0.3
65001
172.31.xx.1 from 172.31.xx.1 (10.x.100.101)
Origin incomplete, metric 3, localpref 100, valid,
external
2. If all other attributes are equal, the path with the lowest MED is chosen. Configure
PxR1 to advertise a higher MED to BBR2 than PxR3. You set the MED value in a
route map.
On PxR1, create a route map that matches all routes and sets the MED to 100. When
configuring a route map, the MED is called metric.
3. Apply the route map to your BGP neighbor BBR2. Since the MED is set in routes
advertised from your AS, apply the route map outbound.
4. On PxR3, create a route map that matches all routes and sets the MED to 50. When
configuring a route map, the MED is called metric. Remember that you want the
path through PxR3 to be more attractive to BBR2 than the path through PxR1, so its
MED must be lower.
5. Apply the route map to your BGP neighbor BBR2. Since the MED is set in routes
advertised from your AS, apply the route map outbound.
6. Do a soft outbound clearing of the BGP session with BBR2 to force the policy to
take effect right away.
L10-4

Task 2: Verify the MED Configuration

1. Telnet to BBR2 and look for your network in the BGP database. Notice that MED is
called metric in the BGP database. Has the appropriate MED been set? Is the nexthop the address of PxR1? Your results should resemble the following example:
BBR2>show ip bgp
[output omitted]
Network
*> 10.x.0.0/16
*
Next Hop
10.254.0.3x
172.31.xx.1

50
0 6500x i
100
0 6500x I
2. Use the command show ip bgp 10.x.0.0 to get more detailed information on your
pods advertisements. Your results should resemble the following example, taken
from Pod 4. Is the correct metric shown?
BBR2>show ip bgp 10.4.0.0
Advertised to peer-groups:
students
10.254.0.1 10.254.0.3
65004, (aggregated by 65004 10.4.100.101)
10.254.0.34 from 10.254.0.34 (10.4.100.103)
Origin IGP, metric 50, localpref 100, valid, external,
atomic-aggregate, best
65004, (aggregated by 65004 10.4.100.101)
172.31.44.1 from 172.31.44.1 (10.4.100.101)
Origin IGP, metric 100, localpref 100, valid, external,
atomic-aggregate
3. Telnet to BBR1. From BBR1, trace the route to the loopback IP address of PxR2
(10.x.100.102). It should go through BBR2 (AS 64999) and PxR3 (10.254.0.3x),
due to the combined actions of AS-path prepending and MED. (Notice that the
actual next-hop used is the IP address of PxR3, rather than BBR2. This is due to the
way BGP advertises next hop addresses on a multi-access network.)
BBR1>trace 10.x.100.102
1 10.254.0.3x [AS 64999] 8 msec 4 msec 4 msec
2 10.x.1.1 [AS 6500x] 12 msec
10.x.3.4 [AS 6500x] 24 msec
10.x.1.1 [AS 6500x] 8 msec
3 10.x.2.2 [AS 6500x] 28 msec
10.x.0.2 [AS 6500x] 28 msec *
L10-5
You have influenced path selection on BBR1 by advertising a MED value
from PxR1 and PxR3.
L10-6

Using the Community Attribute

L11-1
Exercise Objective
Communities are a way of tagging BGP routes. The community value is sent along
with the route, and then other BGP routers can set policies based on this community
value. In this exercise, you will:
Tag a group of routes with a community value.
Configure another router to set local preference on routes with that
community value.
Visual Objective
AS 64998
AS 64999
BBR1
BBR2
10.254.0.2
172.31.x.3
Fram e
R elay
10.x.100.101/32
172.31.x.1/24
DLCI 1xy
S0
10.254.0.3x/24
10.x.100.103/32
E1
10.x.1.1/24
Lo0
PxR1
S1
10.x.0.1/24
E0
10.x.1.3/24
E0
PxR3 Lo0
S0
10.x.3.3/24
AS 6500x
10.x.0.2/24
10.x.3.4/24
S0
S1
10.x.2.4/24
Lo0
10.x.100.102/32
PxR2
S0
E0 10.x.2.2/24
E0
PxR4
Lo0
10.x.100.104/32
L11-2


Note

Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
(config)#
ip bgp new-format
Use aa:nn format for BGP

communities
(config)#
ip community-list 1
permit 6500x:200
Creates a line in a standard

community list
(config-routemap)#
match community 1
Matches against a
community list, in a route
map
(config-router)#
neighbor 10.254.0.2
route-map COMMUNITY in
Tags routes from neighbor

with a community value
(config-router)#
send-community
Configures BGP to send a

community value to a
neighbor
(config-router)#
Removes BGP peering with

a neighbor
(config-router)#
route-map LP in
Removes a route map from a

BGP neighbor
(config)#
route-map COMMUNITY
permit 10
Creates a route map

statement
(config)#
router bgp 6500x
Enables BGP configuration
(config-routemap)#
set community
6500x:200
Sets a community value on

routes
(config-routemap)#
set local-preference
200
Sets a local preference of

200 for matching routes

L11-3

> or #
show ip bgp community

6500x:200
Displays routes with the

specified community
attribute
show run | begin bgp
Filters the display of the

show run command
Task 1: Clean-Up
Currently, PxR1 is advertising a local preference value of 150 for all its routes
received from BBR2. PxR3 is advertising a local preference value of 200 for all its
routes received from BBR2. Remove this local preference configuration that was
applied in a previous lab.
Additionally, both routers peer with both backbone routers. Remove the dual eBGP
peering. PxR1 should peer only with BBR1, and PxR3 should peer only with BBR2.

1. On PxR3, use the command show run | begin bgp to see your BGP configuration.
Find the BGP neighbor statement that applies the local preference route map. You
should see output similar to the following.
PxR3#show run | begin bgp
router bgp 6500x
no synchronization
bgp log-neighbor-changes
aggregate-address 10.x.0.0 255.255.0.0 summary-only
neighbor 10.x.100.101 remote-as 65004
neighbor 10.x.100.101 update-source Loopback0
neighbor 10.254.0.1 remote-as 64998
neighbor 10.254.0.1 route-map MED out
neighbor 10.254.0.2 route-map LP in
neighbor 10.254.0.2 route-map PREPEND out
neighbor 10.254.0.2 filter-list 2 in
neighbor 10.254.0.2 filter-list 1 out
no auto-summary
2. On PxR3, remove the route maps that apply local preference and MED to your
neighbor BBR2 (10.254.0.2). Make sure you do not remove the neighbor peering!
PxR3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PxR3(config-router)#no neighbor 10.254.0.2 route-map LP in
PxR3(config-router)#no neighbor 10.254.0.2 route-map MED out
L11-4

3. On PxR1, find the BGP neighbor statement that configures peering with BBR2, and
remove it.
PxR1(config-router)#no neighbor 172.31.xx.4
On PxR3, find the BGP neighbor statement that configures peering with BBR1, and
remove it.
PxR3(config-router)#no neighbor 10.254.0.1
4. Initiate a soft clearing of ALL your BGP sessions to force the local preference
change to take effect. Display the BGP database to verify that there are no longer
any local preference values of 150 and 200 listed. You will see a local preference of
100 for routes advertised from your internal peer.
5. Display the BGP neighbor list. PxR1 should now peer only with PxR3 and BBR1.
PxR3 should now peer only with PxR1 and BBR2. Verify that your peering is
correct.
PxR1#show ip bgp summary
[output omitted]
Neighbor
V
AS MsgRcvd MsgSent
Up/Down State/PfxRcd
10.x.100.103
4 6500x
11850
11914
2d12h
10
172.31.x.3
4 64998
11449
11192
2d00h
16
[output omitted]
Neighbor
V
AS MsgRcvd MsgSent
10.x.100.101
4 6500x
4321
4303
2d12h
10
10.254.0.2
4 64999
4276
4072
2d12h
16

TblVer
InQ OutQ
998
998
TblVer
InQ OutQ
608
608
L11-5
Task 2: Setting the Community Attribute

You still want to prefer PxR3 as the exit point for most of your pods external
traffic. In a previous lab, you configured local preference on each router to
accomplish this. In this task, configure PxR3 to tag its routes with a community
value. In the next task, PxR1 will set local preference based on that community
value.
1. On PxR1 and PxR3, configure the router to use the new AA:NN format of
community numbering.
PxR1/PxR3(config)#ip bgp new-format
2. On PxR3, create a route map that matches all routes, and sets a community value of
6500x:200 (where x is your pod number.) Add the keyword additive as BBR2 is
advertising a community to PxR3.
PxR3(config)#route-map COMMUNITY permit 10
PxR3(config-route-map)#set community 6500x:200 additive
3. All routes advertised to PxR3 from BBR2 must be tagged with the community
value. Thus, apply the route map to BBR2 inbound.
4. This community attribute must be sent to your iBGP neighbor, PxR1. By default,
the community attribute is not sent to any neighbors. Configure PxR3 to send
communities to PxR1.
PxR3(config-router)#neighbor 10.x.100.101 send-community
5. Initiate a route refresh by doing an inbound clearing of the BGP session with BBR2,
so that the route-map will be applied to the routes.
6. Display the routes in the BGP database that have a community attribute set, by
using the command show ip bgp community 6500x:200. Make sure the routes
from BBR2 have been tagged with the appropriate community value.
L11-6

Task 3: Set Local Preference

In the previous task, PxR3 was configured to tag its routes with a community value.
In this task, configure PxR1 to set local preference based on that community value.
1. On PxR1, display the routes in the BGP database that have a community attribute
set, by using the command show ip bgp community 6500x:200, where x is your
pod number. Make sure the routes from PxR3 have been tagged with the appropriate
community value.
2. Configure a community list that permits the community 6500x:200.
PxR1(config)#ip community-list 1 permit 6500x:200
3. Create a route map that matches your community list, and sets local preference to
200.
PxR1(config)#route-map COMMUNITY permit 10
PxR1(config-route-map)#match community 1
PxR1(config-route-map)#set local-preference 200
4. The local preference attribute should be set on all routes advertised by PxR3.
Configure a BGP neighbor statement that applies the route map to PxR3, inbound.
5. Do an inbound route refresh of the session with PxR3 to force the new policy to
take effect. Display the BGP database on PxR1 and verify that all routes from PxR3
now have a local preference value of 200.
You have set a community of 6500x:200 on routes from BBR2.
You have set the local preference attribute on routes with a community of
6500x:200.

L11-7
L11-8

Becoming a Service Provider

L12-1
Exercise Objective
In this exercise, your autonomous system will become a Service Provider, providing
access to a customer AS. You will:
Configure full-mesh iBGP within the pod
Peer with the customer AS
Filter routes sent to and received from the customer AS
Visual Objective
A S 64998
A S 64999
BBR1
BBR2
1 0 . 2 5 4 . 0 .2
1 7 2 .3 1 .x .3
F ra m e
R e la y
1 0 . x .1 0 0 . 1 0 1 / 3 2
S0
1 7 2 .3 1 .x .1 /2 4
D LC I 1xy
1 0 . 2 5 4 . 0 .3 x / 2 4
1 0 . x .1 0 0 . 1 0 3 / 3 2
E1
1 0 .x .1 .1 /2 4
Lo0
PxR1
S1
1 0 .x .0 .1 /2 4
E0
1 0 .x .1 .3 /2 4
E0
Lo0
PxR3
S0
1 0 .x .3 .3 /2 4
A S 6500x
1 0 .x .0 .2 /2 4
1 0 . x .3 . 4 /2 4
S0
S1
1 0 .x . 2 . 4 / 2 4
Lo0
1 0 . x .1 0 0 . 1 0 2 / 3 2
PxR2
S0
E 0 1 0 .x .2 .2 /2 4
E0
PxR4
1 7 2 . 3 1 . 1 0 x . 2 /3 0
DLCI 3x1
Lo0
1 0 .x .1 0 0 .1 0 4 /3 2
F ram e
R e la y
1 7 2 .3 1 .1 0 x .1
C u s to m e r
A S 64997
L12-2

through an Ethernet connection. PxR2 connects to the Customer router through a
frame relay circuit.
Note

Two end users
Four Cisco routers
Command List
Commands
Router Prompt
Command
Description
(config-router)#
aggregate-address
prefix subnet-mask
summary-only
Summarizes BGP routes
(config)#
as-path access-list
no. permit|deny
regexp
Configures a line in an ASpath filter
(config-router)#
neighbor ip-address
filter-list no.
Applies an AS-path filter to a

BGP neighbor
(config-router)#
neighbor ip-address
remote-as as-no.
Configures a BGP peering
(config-router)#
neighbor ip-address
update-source lo0
Sources BGP message
(config-router)#
network prefix mask

subnet-mask
Originates a BGP
advertisement for a network
(config-router)#
no auto-summary
Disables autosummarization
(config-router)#
no defaultinformation originate
Removes the advertising of a

default route
(config)#
no router bgp 6500x
Removes the BGP routing

process
(config-router)#
no synchronization
Disables BGP synchronization

L12-3

(config)#
router bgp 6500x
Enables the BGP routing

process
> or #

ip-address advertised
Displays the routes advertised

to that BGP neighbor
> or #

ip-address routes
Displays the routes received

from that BGP neighbor
Task 1: Clean-Up
In this lab you will configure your pod to be a transit AS and to peer with a
customer AS. This requires you to make so many changes to your BGP
configuration that is it quicker to just start over. Thus, remove the old BGP
configuration and the RIP default route.

1. Remove BGP from PxR1 and PxR3.
PxR1(config)#no router bgp 6500x
PxR3(config)#no router bgp 6500x
2. Remove the default route advertisement from the RIP routing process on PxR1 and
PxR3.
PxR1/PxR3(config)#router rip
PxR1/PxR3(config-router)#no default-information originate
L12-4

Task 2: Configure Full-mesh iBGP

Configure full-mesh iBGP peering within the pod. Use the loopback IP addresses in
your neighbor statements. The diagram below shows the logical connections you
will configure in this lab. Each dotted line represents a BGP session.
BBR2
BBR1
PxR1
PxR3
PxR 2
PxR 4
C u s to m e r
Figure 13: Logical Connections
1. Re-enable BGP on each of your pod routers. Use AS number 6500x, where x is
your pod number.
2. Configure each of the four routers in your pod to peer with the other three pod
routers. Each router has a loopback interface with an IP address in the format of
10.x.100.10y, where x is your pod number and y is the router number. Peer with
this loopback IP address. Remember to use the update-source loopback 0
command. Each router should have three iBGP neighbors when you are done.
PxRy(config-router)#neighbor
10.x.100.10y
10.x.100.10y
10.x.100.10y
10.x.100.10y
10.x.100.10y
10.x.100.10y
remote-as 6500x
update-source lo0
remote-as 6500x
update-source lo0
remote-as 6500x
update-source lo0
3. Disable autosummarization and synchronization under each BGP process.

L12-5
4. On PxR1 and PxR3, advertise your pod networks into BGP, using the network
command. Summarize your networks to 10.x.0.0/16, and advertise only the
summary route.
PxR1PxR3(config-router)#network 10.x.0.0 mask 255.255.255.0
PxR1/PxR3(config-router)#network 10.x.1.0 mask 255.255.255.0
PxR1/PxR3(config-router)#aggregate-address 10.x.0.0 255.255.0.0
summary-only
5. Verify that all your iBGP sessions are established, and that all pod routers have a
route to the 10.x.0.0 network in their BGP database.
Task 3: Configure eBGP Peering

Establish eBGP sessions between PxR1 and BBR1, and between PxR3 and BBR2,
without any filters. Establish a BGP session between PxR2 and the Customer.
1. On PxR1, configure BBR1 as a BGP neighbor. BBR1 is in AS 64998, IP address
172.31.x.3.
On PxR3, configure BBR2 as a BGP neighbor. BBR2 is in AS 64999, IP address
10.254.0.2.
2. You AS will provide Internet access to a customer located in AS 64997. A framerelay PVC has been established between PxR2 and the customer for this purpose.
On PxR2, configure interface serial 0 for frame relay and no shut the interface.
Create a point-to-point subinterface, S0.1. Give it an IP address of 172.31.10x.2/30
and a DLCI of 3x1.
PxR2(config)#int s0
PxR2(config-if)#encapsulation frame-relay
PxR2(config-if)#int s0.1 point-to-point
PxR2(config-subif)#ip address 172.31.10x.2 255.255.255.252
3. Configure PxR2 to peer with the customers router, using a neighbor IP address of
172.31.10x.1 and AS number 64997.
PxR2(config-router)#neighbor 172.31.10x.1 remote-as 64997
4. On PxR1 and PxR2, redistribute connected interfaces into RIP. This will cause RIP
to advertise the networks connecting the routers with their eBGP peers, thus giving
L12-6

BGP valid next-hop addresses. The RIP process on PxR3 already advertises the
network connecting it with BBR2, since it falls within the 10.0.0.0 network.
5. At PxR1, PxR2, and PxR3, verify that the eBGP sessions are established. At PxR4,
display the BGP database and verify that it is receiving routes from the three
external autonomous systems. Show ip route at all four routers to verify that BGP
routes are in the routing table.
6. Telnet to the customer and verify that it is receiving routes from PxR2. The telnet
password is Global. Use show ip bgp neighbor 172.31.10x.2 routes to display only
the routes received from PxR2.
Task 4: Tuning the Peering with the Customer

The customer has other BGP peerings. If they configure their BGP incorrectly, they
could become a transit AS for you. You want to go through BBR1 and BBR2 for
your external routes, not through the customer. To guard against this, accept only
local routes from the customer.
Additionally, the customer is peering with you to gain better access to routes in AS
65125 and AS 65517. Advertise only your local routes and routes from those ASs to
the customer.
1. At PxR2, create an AS-path access list that permits only routes originating in AS
64997. Apply the filter to routes received from the customer.
PxR2(config-router)#neighbor 172.31.10x.1 filter-list 1 in
2. Create another AS-path access-list that permits only routes from your AS, and those
from AS 65125 and AS 65517. Apply that filter to routes sent to the customer.
PxR2(config)#ip as-path access-list 2 permit ^$
PxR2(config-router)#neighbor 172.31.10x.1 filter-list 2 out
3. Do a soft clearing of the BGP session between PxR2 and the customer, in order to
make the policy take effect.
4. Display the BGP database on PxR2 and verify that you are receiving only local
routes from the customer. Verify that you are sending only local routes, and routes
from AS 65125 and 65517 with show ip bgp neighbor 172.31.10x.1 advertised.

L12-7
5. Telnet to customer and make sure your routes are in the BGP database. The telnet
password is Global. Use show ip bgp neighbor 172.31.10x.2 routes to display only
the routes received from PxR2.
6. From PxR1 or PxR3, telnet to one of the backbone routers, and make sure that they
are receiving routes originating in AS 64997 from you.
Note
The filters for the customer route will be removed and reapplied in Lab
BGP14, Confederations. If you are doing this exercise in a classroom, or
are an individual planning to do Lab 14, show run and copy the parts of
PxR2s configuration that relate to the filters. Save them in a Notepad file
on your desktop for use in that lab.
Full mesh iBGP is established within the pod.
EBGP sessions with BBR1, BBR2, and the customer are established.
Routes sent to and received from the customer are filtered.
L12-8

Using Route Reflectors

L13-1
Exercise Objective
Full-mesh iBGP is not very scalable. In this exercise, you will transition the pod
from a full-mesh to a hierarchical route reflector design.
Visual Objective
A S 64998
A S 64999
BBR1
BBR2
1 0 .2 5 4 . 0 . 2
1 7 2 .3 1 .x .3
F ra m e
R e la y
1 0 . x .1 0 0 . 1 0 1 /3 2
S0
1 7 2 .3 1 .x .1 /2 4
D LC I 1xy
1 0 .2 5 4 .0 .3 x /2 4
1 0 .x .1 0 0 .1 0 3 /3 2
E1
1 0 . x .1 . 1 / 2 4
Lo0
PxR1
S1
1 0 .x .0 .1 /2 4
E0
1 0 . x .1 . 3 / 2 4 E 0
Lo0
PxR 3
S0
1 0 .x .3 .3 /2 4
A S 6500x
1 0 .x .0 .2 /2 4
1 0 .x .3 .4 /2 4
S1
S0
1 0 .x .2 .4 /2 4
Lo0
1 0 . x .1 0 0 . 1 0 2 /3 2
PxR2
S0
E 0 1 0 .x . 2 . 2 / 2 4
1 7 2 .3 1 .1 0 x .2 /3 0
DLCI 3x1
E0
PxR4
Lo0
1 0 .x .1 0 0 .1 0 4 /3 2
F ra m e
R e la y
1 7 2 .3 1 . 1 0 x . 1
C u s to m e r
A S 64997
The figure shows the physical topology of the equipment used in this lab. In this
exercise, PxR1 connects to BBR1 through a frame relay circuit, and PxR3 connects
to BBR2 through an Ethernet connection. PxR2 connects to the Customer router
through a frame relay circuit.
L13-2


Note

Two end users
Four Cisco routers
Command List
Table 1: Commands
Router Prompt
Command
Description
(config-router)#
bgp cluster-id no.
Assigns a cluster ID to a
route reflector
(config-router)#
neighbor ip-address
route-reflector-client
Configures a neighbor as a
route reflector client, and
thus configures the local
router as a route reflector
(config-router)#
Removes a BGP neighbor
> or #
show ip bgp prefix
Displays detailed
information about the
specified network

L13-3
Task 1: Configuring Route Reflectors

The following figure shows the logical connectivity used in this lab. The dotted
lines represent BGP sessions. PxR1 and PxR3 are route reflectors. PxR3 is the toptier route reflector, and has routers PxR1 and PxR4 as clients. PxR1 is the secondtier route reflector, and has PxR2 as a client. Notice that there are far fewer peerings
needed within the pod than with full-mesh iBGP.
BBR2
BBR1
R R C lu s te r
143
R R -P x R 1
R R -P x R 3
RR
C lu s te r
12
PxR2
PxR 4
C u s to m e r
Figure 15: Logical Connections

1. On PxR3, configure a cluster ID of 143. Since there is only one route reflector in
this cluster, it is not actually necessary to assign a cluster ID this is done here to
give you practice with the command.
PxR3(config-router)#bgp cluster-id 143
2. Configure PxR1 and PxR4 as route reflector clients of PxR3. On which router is this
configured the client or the route reflector?
PxR3(config-router)#neighbor 10.x.100.101 route-reflectorclient
L13-4

3. Remove the peering between PxR3 and PxR2. Display the running configuration to
verify your BGP configuration.
4. On PxR1, configure a cluster ID of 12. As before, since there is only one route
reflector in this cluster, it is not actually necessary to assign a cluster ID this is
done here to give you practice with the command.
PxR1(config-router)#bgp cluster-id 12
5. Configure PxR2 as a route reflector client of PxR1. On which router is this

configured the client or the route reflector?
6. Remove the peering between PxR1 and PxR4. Display the running configuration to
verify your BGP configuration.
7. At PxR2, remove all of the iBGP peerings except the one with PxR1.
8. At PxR4, remove all of the iBGP peerings except the one with PxR3.
9. Display the BGP database on all the pod routers, and make sure they are all still
receiving routes.
10. On PxR1 and PxR3, the route-reflectors, look at the BGP information for network
10.97.97.0, a network in the customers AS. On PxR1, you will see it marked as
received from a route-reflector client. On PxR3, it is also marked as received from a
route-reflector client, but notice that PxR1 has marked it with a cluster list.
PxR1#show ip bgp 10.97.97.0
10.4.100.103 172.31.4.3
64997, (Received from a RR-client)
172.31.10x.1 (metric 1) from 10.x.100.102 (10.x.100.102)
Origin IGP, metric 0, localpref 100, valid, internal,
best
64998 64997
172.31.x.3 from 172.31.x.3 (172.31.8.3)
Origin IGP, localpref 100, valid, external
10.x.100.104 10.254.0.2
L13-5

64997, (Received from a RR-client)
172.31.10x.1 (metric 2) from 10.x.100.101 (10.x.100.101)
best
Originator: 10.x.100.102, Cluster list: 0.0.0.12
11. On PxR2, look at a route from BBR1: show ip bgp 192.168.100.0. On PxR4, look
at a route from the customer: show ip bgp 10.97.97.0. Verify that the cluster list
attribute is being applied to these routes. Notice that the cluster list on PxR4
includes both clusters.
172.31.10x.1
64999 64714 65208 65125
10.254.0.2 (metric 2) from 10.x.100.101 (10.x.100.101)
best
Originator: 10.x.100.103, Cluster list: 0.0.0.12
Not advertised to any peer
64997
172.31.10x.1 (metric 1) from 10.x.100.103 (10.x.100.103)
best
Originator: 10.x.100.102, Cluster list: 0.0.0.143,
0.0.0.12
12. Was routing disrupted while you were configuring the route reflectors and clients?
Configuring route reflectors is simple, and can be done gradually and without
disrupting routing. In Lab BGP14 you will configure confederations, another way to
lessen the overhead of full-mesh iBGP. When that lab is done, contrast the
configuration of route reflectors with the configuration of confederations.
L13-6

Your routers have the following BGP neighbors:
PxR1 eBGP with BBR1, iBGP with PxR2 andPxR3
PxR2 eBGP with customer, iBGP with PxR1
PxR3 eBGP with BBR2, iBGP with PxR1 and PxR4
PxR4 iBGP with PxR3
PxR1 is a route reflector for PxR2, and PxR3 is a route reflector for PxR1 and
PxR4
All routers are receiving all appropriate routes.

L13-7
L13-8

Using Confederations

L14-1
Exercise Objective
Another way to avoid the overhead of full-mesh iBGP is to break the autonomous
system into confederations. In this exercise, you will create two confederations
within the pod.
Visual Objective
AS 64998
A S 64999
BBR1
BBR2
10.254.0.2
172.31.x.3
Fram e
R elay
A S 6500x
10.x.100.101/32
S0
10.x.100.103/32
E1
10.x.1.1/24
Lo0
10.x.0.1/24
PxR 1
S1
10.x.1.3/24 E0
E0
Confederation
As 65112
10.x.0.2/24
PxR3 Lo0
S0
10.x.3.3/24
Confederation
AS 65134
S1
S0
10.x.3.4/24
10.x.2.4/24
Lo0
10.x.100.102/32
PxR2
S0
E0 10.x.2.2/24
E0
PxR4
Lo0
10.x.100.104/32
Fram e
R elay
172.31.10x.1
C ustom er
A S 64997
L14-2

Note

Two end users
Four Cisco routers
Command List
Commands
Router Prompt
Command
Description
(config-router)#
aggregate-address
prefix subnet-mask no
summary
Summarizes BGP routes
(config)#
as-path access-list
no. permit|deny regexp
Creates a line in an AS-path

access list.
(config-router)#
bgp confederation
identifier as-no.
Tells BGP its true AS number
(config-router)#
bgp confederation
peers as-no.
Tells BGP which other

confederations are within its
AS
(config-router)#
neighbor ip-address
ebgp-multihop max-hops
Allows an eBGP session

between non-connected
neighbors by telling BGP to
look more than one hop
away for the neighbor IP
address.
(config-router)#
neighbor ip-address
filter-list no. in|out
Applies an AS-path access

list to a neighbor

L14-3
(config-router)#
neighbor ip-address
remote-as as-no.
Configures a BGP neighbor.

(Be sure to use the
confederation AS number for
peering within the pod.)
(config-router)#
neighbor ip-address
update-source lo0
Sources BGP messages

from the IP address of
loopback 0
(config-router)#
network prefix mask

subnet-mask
Advertises a network into

BGP
(config)#
no router bgp as-no.
Removes the BGP routing

process
> or #

ip-address advertised
| routes
Displays routes advertised to

or received from the
specified neighbor
Task 1: Configure Confederations

Break the pod into two confederations. PxR1 and PxR2 are in confederation 65112,
and PxR3 and PxR4 are in confederation 65134. Ensure you still have connectivity
with your eBGP neighbors.

1. A BGP router that is part of a confederation uses the confederation number as its
autonomous system number. Currently, your routers are using AS 6500x. You must
remove the current BGP process and replace it with the new one.
Before removing BGP, you may want to copy your eBGP peering statements and
the BGP network statements on PxR1, PxR2, and PxR3 and paste them into a
Notepad file. Also, if you didnt do so in Lab 12, copy the configuration for the ASpath filters on PxR2 into the Notepad file. This will save you some typing in a later
step.
2. Remove the current BGP process on all the pod routers. Configure the
confederations as follows:
PxR1 and PxR2: AS 65112
PxR3 and PxR4: AS 65134
PxR1/PxR2(config)#no router bgp 6500x
PxR3/PxR4(config)#no router bgp 6500x
L14-4

3. BGP needs to know what its real AS number is, and the AS numbers of the other
confederations within its autonomous system. Configure the confederation identifier
and the confederation peers on each pod router. The pods real AS number is 6500x,
where x is your pod number.
PxR1/PxR2(config-router)#bgp confederation identifier 6500x
PxR1/PxR2(config-router)#bgp confederation peers 65134
PxR3/PxR4(config-router)#bgp confederation identifier 6500x
PxR3/PxR4(config-router)#bgp confederation peers 65112
4. Configure peering according to the following table. Peer with loopback IP addresses
on all pod routers. Use the confederation AS numbers for peering within the pod.
Remember that peering between confederations is considered an eBGP connection.
In order to peer with loopback addresses across a confederation border you must
use the neighbor ip-address ebgp-multihop hop-count command, in addition to
update-source loopback 0.
Router
Peer With
IP Address
AS Number
PxR1
PxR2
10.x.100.102
65112
PxR3
10.x.100.103
65134
BBR1
172.31.x.3
64998
PxR1
10.x.100.101
65112
Customer
172.31.10x.1
64997
PxR4
10.x.100.104
65134
PxR1
10.x.100.101
65112
BBR2
10.254.0.2
64999
PxR3
10.x.100.103
65134
PxR2
PxR3
PxR4
5. Advertise your pod networks into BGP on PxR1 and PxR3, using network
statements. Summarize them to 10.x.0.0/16, and advertise only the summary.
Additionally, advertise the networks connecting to your external neighbors on
PxR1, PxR2, and PxR3. If you copied the network statements in Step 1 of this lab,
you can just paste them into the configuration.
6. Turn off BGP synchronization and autosummarization on all routers.
7. Verify that all BGP sessions are established before proceeding.
L14-5
Task 2: Filtering Customer Routes

Change the customer filters to reflect the new configuration, and re-apply them.
1. On PxR2, go to global configuration mode, copy the two AS-path filters from the
Notepad file, and paste them into the configuration. DO NOT apply the filters yet.
(These AS-path access lists filter routes sent to and received from the customer AS.)
If you did not copy these down in Step1, type in the following commands:
ip
ip
ip
ip
as-path
as-path
as-path
as-path
access-list
access-list
access-list
access-list
1
2
2
2
permit
permit
permit
permit
_64997$
^$
_65125$
_65517$
2. The AS-path filter for routes sent to the customer needs to be modified to reflect the
confederation structure. Currently the filter permits routes originating in your AS,
AS 65517, and AS 65125. Any routes originated by PxR3 or PxR4 will have the AS
number of their member AS listed first in its path. (View the BGP database on PxR2
to verify this.) Add one more line to AS-Path access list 2, to permit routes
originating in your other confederation autonomous system, AS 65134.
PxR2(config)#ip as-path access-list 2 permit ^\(65134$
3. Verify the AS-path access list.

PxR2#show ip as-path-access-list
permit _64997$
permit ^$
permit _65125$
permit _65517$
permit ^\(65134$
4. Apply the AS-path filter to the BGP neighbor Customer (172.31.10x.1), and do a
soft clearing of the BGP session to force it to take effect right away.
PxR2(config-router)#neighbor 172.31.10x.1 filter-list 1 in
PxR2(config-router)#neighbor 172.31.10x.1 filter-list 2 out
PxR2(config-router)#^Z
PxR2#clear ip bgp 172.31.10x.1 soft
L14-6

5. View the BGP database on PxR2 to verify that it is receiving only local routes from
the customer. Use show ip bgp neighbor 172.31.10x.1 routes to filter your display.
View the routes you are advertising to the customer with show ip bgp neighbor
172.31.10x.1 advertised. You should additionally see the confederation identifier
for routes from the other confederation.
6. Telnet to the customer (172.31.10x.1, telnet password Global) and verify that it is
receiving the appropriate routes from your AS. Use show ip bgp neighbor
172.31.10x.2 routes to filter the display. You should see only routes from your AS,
AS 65517, and AS 65125. Are any confederation identifiers listed?
7. On PxR3, view the BGP database. You should see the confederation identifier for
routes from the other confederation.
8. You have now configured the same logical BGP structure as you did using route
reflectors in Lab 13. Both confederations and route reflectors help reduce the
number of iBGP peerings needed. Recall the steps needed to configure route
reflectors in Lab 13. Which is less disruptive to implement in your network
confederations or route reflectors? Which is more scalable?
Configure two confederations within the pod.
Configure intra- and inter-confederation peerings.
Configure an AS-path access list for use with confederations

L14-7
L14-8

Monitoring and Tuning BGP

Resource Use

L15-1
Monitoring and Tuning BGP Resource Use
Exercise Objective
BGP is meant to handle very large routing tables, but as the routing table grows, so
does the demand on router resources. In this exercise you will learn to:
Troubleshoot CPU usage problems
Troubleshoot BGP updates congesting an interface
Examine timers to speed BGP convergence
Limit the number of prefixes received from a BGP neighbor
Visual Objective
A S 64998
A S 64999
B BR 1
B BR2
1 0 .2 5 4 .0 .2
1 7 2 .3 1 .x .3
F ra m e
R e la y
A S 6500x
1 0 .x .1 0 0 .1 0 1 /3 2
S0
1 0 .x .1 0 0 .1 0 3 /3 2
E1
1 0 .x .1 .1 /2 4
Lo0
1 0 .x .0 .1 /2 4
P xR 1
S1
1 0 .x .1 .3 /2 4 E 0
E0
C o n fe d e ra tio n
A s 65112
1 0 .x .0 .2 /2 4
Lo0
P xR 3
S0
1 0 .x .3 .3 /2 4
C o n fe d e r a tio n
A S 65134
S0
S1
1 0 .x .3 .4 /2 4
1 0 .x .2 .4 /2 4
Lo0
1 0 .x .1 0 0 .1 0 2 /3 2
PxR2
S0
E 0 1 0 .x .2 .2 /2 4
E0
PxR 4
Lo0
1 0 .x .1 0 0 .1 0 4 /3 2
F ra m e
R e la y
1 7 2 .3 1 .1 0 x .1
C u s to m e r
A S 64997
L15-2

Note

Two end users
Four Cisco routers
Command List
Commands
Router Prompt
Command
Description
clear counters
interface
Zeros the counters on the

interface
clear ip bgp ipaddress
Resets the BGP session with

a neighbor
(config-router)#
neighbor ip-address
maximum-prefix max
threshold%
Limits the number of prefixes

received from a BGP peer
> or #
show interface type

number
Displays counters and

configuration for an interface
> or #
Lists information about a

BGP neighbor, such as the
advertisement interval
> or #
show ip bgp summary
Lists the BGP neighbors, and

other information such as the
scan time
> or #
show process cpu
Displays the CPU usage by

process

L15-3
Task 1: Monitoring BGP Resource Use

Use show commands to monitor BGPs effect on CPU use and interface congestion.

1. At PxR1 clear the counters on interface S0.
At PxR3, clear the counters on interface E1.
PxR1#clear counters s0
Clear "show interface" counters on this interface [confirm]
PxR3#clear counters e1
Clear "show interface" counters on this interface [confirm]
2. Examine the current CPU load with show process cpu. At the top of the display,
note the average CPU usage.
What is the 5-second value? __________________
The one-minute value? __________________________
3. Reset the BGP session with your EBGP peer. Make sure you do a hard clearing, not
a soft one.
4. When the neighbor relationship is back up, display the CPU load once again.
What is the 5-second value now? ________________
The one-minute value? _______________________
Most likely, the number of updates in our network is not overwhelming the CPU,
even on our small lab routers. In a very large network, this could become
significant, however.
5. If BGP is receiving or sending a large number of updates at one time, it could cause
congestion on the interface. When congestion occurs, packets may get dropped.
You cleared the counters on the interface connected to your EBGP peer at the
beginning of this lab, and then caused BGP to send and receive updates. Examine
the effect of BGP on that interface.
Use show interface s0 on PxR1 and show interface e1 on PxR3. Examine the
output and fill in the following information.
Total output drops: _________________________
Packets input _________________ / Bytes input ___________________
Packets output ________________ / Bytes output __________________
L15-4

These figures show traffic across that interface just since the beginning of the lab. Is
the traffic from BGP updates congesting the interface? If so, you can increase the
input queue depth or configure a different queuing strategy on the output queue.
Task 2: Settings to Speed BGP Convergence

BGP is built to be reliable, not fast. There are timers that can be changed to speed
convergence. Changing these timers has a price, however, and should not be done
lightly. In this task, examine the default BGP scan time and advertisement interval.
1. The BGP scan process checks the BGP table periodically to see if all next-hops are
still reachable. If any are not, BGP will choose a new route (if available) and
advertise the changed information to its neighbors. The value of this timer can be
lowered to cause BGP to notice changes faster. This consumes more CPU
resources, however.
The scan timer can be viewed with show ip bgp summary. The timer has not been
changed from its default; what is the default BGP scan time? __________________
2. The BGP advertisement interval controls how frequently the router may send an
update to a neighbor. It can be lowered to allow more frequent updates, but this also
consumes more resources.
Move to PxR1 and PxR3. Examine the advertisement interval for your eBGP
neighbor and also your iBGP confederation peer with show ip bgp neighbor ipaddress. This timer has not been changed from its default.
What is the default advertisement interval for your eBGP neighbor? ____________
For your iBGP neighbor? ___________
Task 3: Limiting Inbound Prefixes

In a small network like this, BGP does not put too much of a strain on a routers
resources, and the default settings are fine. One other way to protect your router
against future problems is to limit the number of prefixes you will accept from a
neighbor. A misconfigured neighbor who unexpectedly sends you the entire Internet
routing table could cause big problems! In this task, limit the number of prefixes
received from the backbone routers.
1. Configure PxR1 to limit the number of prefixes it receives from BBR1. PxR1 is in
confederation AS 65112, BBR1s IP address is 172.31.x.3.
Configure PxR3 to limit the number of prefixes it receives from BBR2. PxR3 is in
confederation AS 65134, BBR2s IP address is 10.254.0.2.
Set a limit of 15 prefixes, with a warning threshold of 66%.
PxR1(config)#router bgp 65112
L15-5

PxR1(config-router)#neighbor 172.31.x.3 maximum-prefix 15 66
PxR3(config-router)#neighbor 10.254.0.2 maximum-prefix 15 66
2. On both PxR1 and PxR3, trigger a route refresh from the backbone routes with
clear ip bgp ip-address in.
3. Watch the console screen for the warning message and the neighbor teardown. Your
results should resemble the following example, taken from PxR1.
PxR1#
19:03:09: %BGP-3-MAXPFXEXCEED: No. of prefix received from
172.31.x.3 (afi 0): 32 exceed limit 15
19:03:10: %BGP-5-ADJCHANGE: neighbor 172.31.x.3 Down BGP
Notification sent
PxR1#
19:03:10: %BGP-3-NOTIFICATION: sent to neighbor 172.31.x.3 3/1
(update malformed) 0 bytes
4. On both PxR1 and PxR3, use show ip bgp neighbor ip-address to verify the prefix
limit and the warning threshold. According to this output, what must you do to
restore the peering?
By default, once a neighbor relationship has been torn down for violating the
maximum prefixes, you must clear the session to restart it, if you merely increase
the number of allowed prefixes. (Adding the restart keyword to the maximumprefix command causes the router to attempt to restart the BGP session after a
specified interval. The restart command is available beginning in IOS release
12.3.)
PxR1#show ip bgp neighbor 172.31.x.3
BGP neighbor is 172.31.x.3, remote AS 64998, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Idle
Last read 00:00:28, hold time is 180, keepalive interval is
60 seconds
Received 898 messages, 0 notifications, 0 in queue
Sent 897 messages, 1 notifications, 0 in queue
Route refresh request: received 0, sent 1
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 95, neighbor version 0
Index 3, Offset 0, Mask 0x8, maximum limit 15
Threshold for warning message 66%
Number of NLRIs in the update sent: max 4, min 0
L15-6


Connections established 1; dropped 1
Last reset 00:00:28, due to BGP Notification sent, update
malformed
Peer had exceeded the max. no. of prefixes configured.
Reduce the no. of prefix and clear ip bgp 172.31.x.3 to
restore peering
No active TCP connection
5. Once you have seen the result of this command, and verified your configuration,
remove the maximum-prefix setting. Since you removed the limit, rather than
increasing the number of allowed prefixes, BGP will attempt to restore the peering.
You do not need to clear the neighbor relationship.
PxR1(config-router)#no neighbor 172.31.x.3 maximum-prefix 15 66
PxR3(config-router)#no neighbor 10.254.0.2 maximum-prefix 15 66
6. Verify that all the BGP peerings are established once again.
Used commands to troubleshoot problems with BGP resource usage.
Examined the settings of BGP timers
Limited the number of prefixes received from a BGP neighbor

L15-7
L15-8

Using Peer Groups

L16-1
Using Peer Groups
Exercise Objective
This exercise investigates the use of peer groups to simplify BGP configuration.
You will configure full-mesh iBGP peering using peer groups.
Visual Objective
A S 64998
AS 64999
B BR 1
BBR2
1 0 .2 5 4 .0 .2
1 7 2 .3 1 .x .3
F ra m e
R e la y
1 7 2 .3 1 .x .1 /2 4
1 0 .2 5 4 .0 .3 x /2 4
DLCI 1xy
S0
E 1 1 0 .x .1 0 0 .1 0 3 /3 2
1 0 .x .1 0 0 .1 0 1 /3 2
1 0 .x .1 .1 /2 4
E0
1 0 .x .1 .3 /2 4 E 0
Lo0
Lo0
PxR1
PxR 3
S0
S1
1 0 .x .0 .1 /2 4
1 0 .x .3 .3 /2 4
A S 6500x
1 0 .x .0 .2 /2 4
1 0 .x .3 .4 /2 4
S1
S0
1 0 .x .2 .4 /2 4
Lo0
1 0 .x .1 0 0 .1 0 2 /3 2
PxR2
S0
E 0 1 0 .x .2 .2 /2 4
E0
Lo0
P x R 4 1 0 .x .1 0 0 .1 0 4 /3 2
1 7 2 .3 1 .1 0 x .2 /3 0
D LCI 3x1
F ra m e
R e la y
1 7 2 .3 1 .1 0 x .1
C u s to m e r
A S 64997
L16-2

Using Peer Groups

Note

Two end users
Four Cisco routers
Command List
Commands
Router Prompt
Command
Description
(config-router)#
neighbor ip-address
peer-group
Adds a neighbor to a peer

group
(config-router)#
neighbor ip-address
remote-as as-no.
Configures a router as a
BGP neighbor
(config-router)#
neighbor peer-groupname configuration
Applies a BGP setting to a

peer group
(config-router)#
neighbor peer-groupname peer-group
Creates a BGP peer group
(config-router)#
no auto-summary
Disables autosummarization
of routes
(config)#
no router bgp
confederation-as-no.
Removes the confederation

BGP process
(config-router)#
no synchronization
Disables BGP
synchronization
(config)#
router bgp real-AS-no.
Enables BGP configuration
> or #
show ip bgp community
Displays routes in the BGP

database with the community
attribute
> or #
show ip bgp summary
Displays a list of BGP peers

L16-3
Using Peer Groups
Task 1: Clean-Up
The lab begins with the pod divided into two confederations. PxR1 and PxR2 are in
confederation 65112; PxR3 and PxR4 are in confederation 65134. Tear down and
restructure your BGP network one last time, in order to remove the confederation
configuration. Use AS number 6500x, and use peer groups in configuring full-mesh
iBGP within the pod.

1. Remove BGP from each router in the pod.
PxR1/PxR2(config)#no router bgp 65112
PxR3/PxR4(config)#no router bgp 65134
2. Re-enable BGP using the original AS number (6500x, where x is your pod
number). Disable auto-summary and synchronization. Set up the following eBGP
peerings:
PxR1 Configure eBGP with BBR1 (172.31.x.3, AS 64998).
PxR2 Configure eBGP with Customer (172.31.10x.1, AS 64997).
PxR3 Configure eBGP with BBR2 (10.254.0.2, AS 64999). Redistribute RIP into
BGP on PxR3.
Verify that that the EBGP neighbors are established before continuing to the next
step.
Task 2: Creating and Applying a Peer Group

On each router, create a peer group that configures the common settings for your
iBGP peers. Configure full-mesh iBGP using this peer group.
1. Create a peer group on each of your pod routers. The peer group name is local to the
router, so you can name it whatever you wish. Configure the peer group with the
following neighbor settings:
remote-as 6500x
update-source loopback 0
send-community
password cisco
Additionally, on PxR1, PxR2 and PxR3 ONLY, add the following:
next-hop-self
L16-4

Using Peer Groups

POD
POD
POD
POD
POD
peer-group
remote-as 6500x
update-source lo0
send-community
password cisco
PxR1/PxR2/PxR3(config-router)#neighbor POD next-hop-self
2. Set up full-mesh peering within the pod, using loopback IP addresses. Now that you
have configured the peer group, you need only one command per neighbor:
neighbor ip-address peer-group peer-group-name
Contrast this configuration with the number of commands needed to configure fullmesh iBGP in Lab 12. Peer groups can greatly simplify your configuration.
PxRy(config-router)#neighbor 10.x.100.10y peer-group POD
3. Once all the routers are configured, verify that all the neighbors are established and
routes are being received on all routers. Your output should resemble this example,
taken from router 1.
BGP router identifier 10.x.100.101, local AS number 6500x
BGP table version is 70, main routing table version 70
38 network entries and 57 paths using 5738 bytes of memory
25 BGP path attribute entries using 1500 bytes of memory
16 BGP AS-PATH entries using 416 bytes of memory
1 BGP community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP activity 38/25 prefixes, 101/44 paths, scan interval 60
secs
Neighbor
V
AS MsgRcvd MsgSent
10.x.100.102
4 6500x
27
23
00:03:33
8
10.x.100.103
4 6500x
19
13
00:00:39
17
10.x.100.104
4 6500x
4
10
00:00:09
0
172.31.x.3
4 64998
77
78
00:58:30
32

TblVer
InQ OutQ
70
70
70
70
L16-5
Using Peer Groups
4. The backbone router BBR2 is sending a community value into the pod, to enable
you to further test your configuration. You can view this with show ip bpg
community. This command displays all routes with a community attribute set. You
will see more routes displayed on PxR3 which peers with BBR2 than on the other
routers. This is because PxR3 only advertises its best route to each network to its
neighbors, and some of the routes marked with a community are not the best route.
PxR3#show ip bgp community
BGP table version is 53, local router ID is 10.x.100.103
best, i - internal
Network
Next Hop
Path
* 10.102.1.0/24
10.254.0.2
64999 64998 65102 i
* 10.254.0.0/24
10.254.0.2
64999 i
* 172.31.1.0/24
10.254.0.2
64999 64998 i
* 172.31.2.0/24
10.254.0.2
64999 64998 i
* 172.31.3.0/24
10.254.0.2
64999 64998 i
* 172.31.4.0/24
10.254.0.2
64999 64998 i
*> 172.31.11.0/24
10.254.0.2
64999 i
*> 172.31.22.0/24
10.254.0.2
64999 i
*> 172.31.33.0/24
10.254.0.2
64999 i
*> 172.31.44.0/24
10.254.0.2
64999 i

0
0
0
0
0
0
0
Created a peer group
Used that peer group in configuring full-mesh iBGP
L16-6

Using Route Dampening

L17-1
Exercise Objective
Route dampening prevents flapping routes from generating constant BGP messages
and high CPU usage, updating and withdrawing the route. In this exercise, you will:
Configure and apply route dampening to a set of routes
Monitor the results when those routes flap
Visual Objective
A S 64998
A S 64999
BB R1
BB R2
1 0 .2 5 4 .0 .2
1 7 2 .3 1 .x .3
F ram e
R e la y
1 0 .x .1 0 0 .1 0 1 /3 2
1 7 2 .3 1 .x .1 /2 4
D LC I 1xy
1 0 .2 5 4 .0 .3 x /2 4
S0
1 0 .x .1 0 0 .1 0 3 /3 2
E1
1 0 .x .1 .3 /2 4
Lo0
PxR 1
S1
1 0 .x .0 .1 /2 4
E0
E0
1 0 .x .1 .1 /2 4
Lo0
PxR 3
S0
1 0 .x .3 .3 /2 4
A S 6500x
1 0 .x .0 .2 /2 4
1 0 .x .3 .4 /2 4
S0
S1
1 0 .x .2 .4 /2 4
Lo0
1 0 .x .1 0 0 .1 0 2 /3 2
PxR 2
S0
E 0 1 0 .x .2 .2 /2 4
E0
1 7 2 .3 1 .1 0 x .2 /3 0
D LC I 3x1
PxR4
L o 1 1 0 .4 x .1 4 4 .1 /2 4
Lo0
A S 6504x
F ra m e
R e la y
1 0 .x .1 0 0 .1 0 4 /3 2
1 7 2 .3 1 .1 0 x .1
C u s to m e r
A S 64997
L17-2


Note

Two end users
Four Cisco routers
Command List
Commands
Router Prompt
Command
Description
(config)#
access-list no. permit

prefix wildcard-mask
Creates a standard IP
access list
(config-router)#
bgp dampening routemap name
Enables route dampening

according to the parameters
in the route map
(config-routemap)#
match ip address listno.
Matches against an access

list
(config)#
route-map name permit

seq-no.
Creates a route map

statement
(config-routemap)#
set dampening halflife reuse suppress

max-suppress-time
Sets route dampening and

optional dampening
parameters
> or #
show ip bgp dampenedpaths
Displays prefixes currently

dampened
> or #
show ip bgp flapstatistics
Displays prefixes that have

flapped
> or #

ip-address routes
Displays routes in the BGP

database from the specified
neighbor

L17-3

> or #
show run | begin bgp
Filters the display of the

show run command
Task 1: Lab Preparation

If you are doing this lab in a classroom, choose Reset to from the menu on the left
of your lab screen, and choose to reset the equipment to Lab 17. This will
reconfigure the BGP structure of your pod to reflect that in the diagram at the
beginning of the lab. If you are doing this lab individually, the configuration is
already done for you. The new BGP structure is:
PxR1, PxR2, and PxR3 are in AS 6500x, where x is your pod number.
PxR4 is in AS 6504x, where x is your pod number.
PxR1 peers with BBR1, PxR2, PxR3, and PxR4
PxR2 peers with the Customer, PxR1, and PxR3
PxR3 peers with BBR2, PxR1, PxR2, and PxR4
PxR4 peers with PxR1 and PxR3.
Task 2: Configuring Route Dampening

When a route goes down, BGP sends a WITHDRAWN message to its neighbors. If
it comes back up, BGP must send an UPDATE message. If the route is going up
and down frequently, this causes a lot of messages to be generated, and thus extra
CPU use. Route dampening suspends the advertisement of a route that flaps
excessively.
In this task, you will configure PxR1 and PxR3 to apply route dampening to a route
from PxR4.

1. At PxR1 and PxR3, display the routes in the BGP database that were originated by
PxR4, in AS 6504x. To view only the routes from PxR4, use show ip bgp neighbor
10.x.100.104 routes.
What network is PxR4 originating? ______________________
PxR1#show ip bgp neighbor 10.x.100.104 routes
best, i - internal
L17-4


Network
*> 10.4x.144.0/24
Next Hop
10.x.100.104

0
0 6504x I
2. You want to dampen this route if it flaps, but do not dampen any other routes. On
PxR1 and PxR3, configure an access list that permits network, 10.4x.144.0/24.
PxR1/PxR3(config)#access-list 1 permit 10.4x.144.0 0.0.0.255
3. Configure a route map that matches your access list and sets route dampening.
Adjust the default parameters for the dampening as follows:
Half-life of 10 minutes
Reuse value of 750
Suppress value of 1000
Maximum suppress time of 40 minutes
PxR1/PxR3(config)#route-map DAMPEN permit 10
PxR1/PxR3(config-route-map)#match ip address 1
PxR1/PxR3(config-route-map)#set dampening 10 750 1000 40
4. Enable route dampening under the BGP process on PxR1 and PxR3, using the route
map, with bgp dampening route-map name.
PxR1/PxR3(config-route-map)#router bgp 6500x
PxR1/PxR3(config-router)#bgp dampening route-map DAMPEN
Task 3: Monitoring Dampening

Cause a route to flap, and monitor the results.
1. View the configuration on PxR1 and PxR3. Verify that the access list and route map
are configured correctly, and that dampening is configured correctly under the BGP
process. Relevant parts of the configuration are shown below:
router bgp 6500x
bgp dampening route-map DAMPEN
access-list 1 permit 10.4x.144.0 0.0.0.255
route-map DAMPEN permit 10
match ip address 1
set dampening 10 750 1000 40
2. Network 10.4x.144.0 is on PxR4s interface Loopback 1. Connect to PxR4 and shut

the Loopback 1 interface, then wait a minute (literally). Display the BGP table on
either PxR1 or PxR3. Look at the entry for network 10.4x.144.0. It should have an
L17-5
h in front of it, to indicate that the router is keeping a history of points for this
route.
Note
Be sure you dont shut the Loopback 0 interface by mistake! You are
peering with that IP address, so if you shut it, your BGP peering will be
affected. If you are doing this lab in a classroom, coordinate the shutting
of the interface with your pod mate.
3. No shut the loopback 1 interface, wait a minute (literally), then shut it again. Repeat
this cycle.
4. After the route has flapped a few times, verify the route dampening. On PxR1 and
PxR3, use show ip bgp dampened-paths and show ip bgp flap-statistics to view
only those routes that have been dampened. Is the network you noted in Step 1
being dampened? Are any other networks being dampened?
PxR3#show ip bgp dampened-paths
best, i - internal
Network
*d 10.4x.144.0/24
From
10.x.100.104
Reuse
Path
00:12:20 6504x I
PxR3#show ip bgp flap-statistics

best, i - internal
Network
Path
*d 10.4x.144.0/24
6504x
From
Flaps Duration Reuse
10.x.100.104
00:03:17 00:12:20
5. Examine the details for that network with show ip bgp 10.xx.144.0. Is this route
being advertised? How long before it can be reused (assuming it does not flap
again)?
6. Good job!
You configure route dampening
You monitor route dampening statistics
L17-6

Appendix A: BGP Lab

Solutions

A-1
Appendix A
Lab Solutions
The following examples list typical solutions for the problems presented in the BGP
lab exercises. For each lab, only the relevant parts of the configuration are shown
those parts that illustrate changes made to the configuration during the lab.
Substitute your pod number for x where appropriate.
Lab 1 Pod Setup

Router 1
hostname PxR1
!
interface Loopback0
ip address 10.x.100.101 255.255.255.255
!
interface Serial0
no ip address
!
interface Serial0.1 point-to-point
ip address 172.31.x.1 255.255.255.0
frame-relay interface-dlci 1x1
!
interface Serial1
ip address 10.x.0.1 255.255.255.0
clockrate 64000
!
router rip
version 2
network 10.0.0.0
no auto-summary
Router 2
hostname PxR2
!
interface Loopback0
ip address 10.x.100.102 255.255.255.255
!
interface Ethernet0
ip address 10.x.2.2 255.255.255.0
!!
interface Serial1
ip address 10.x.0.2 255.255.255.0
!
router rip
version 2
network 10.0.0.0
no auto-summary
A-2

Appendix A
Router 3
hostname PxR3
!
interface Loopback0
ip address 10.x.100.103 255.255.255.255
!
interface Ethernet1
ip address 10.254.0.3x 255.255.255.0
!
interface Serial0
ip address 10.x.3.3 255.255.255.0
clockrate 64000
!
router rip
version 2
passive-interface Ethernet1
network 10.0.0.0
no auto-summary
Router 4
hostname PxR4
!
interface Loopback0
ip address 10.x.100.104 255.255.255.255
!
interface Ethernet0
ip address 10.x.2.4 255.255.255.0
!
interface Serial0
ip address 10.x.3.4 255.255.255.0
no fair-queue
!
router rip
version 2
network 10.0.0.0
no auto-summary
Lab 2 Configuring EBGP Peerings

Router 1
router rip
version 2
network 10.0.0.0
default-information originate
no auto-summary
!
router bgp 65005
A-3
Appendix A
aggregate-address 10.5.0.0 255.255.0.0
redistribute rip
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.31.5.3
Router 3
router rip
version 2
passive-interface Ethernet1
network 10.0.0.0
no auto-summary
!
router bgp 65005
redistribute rip
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.254.0.2
Lab 3 Configuring IBGP Peerings

Router 1
interface Ethernet0
ip address 10.5.1.1 255.255.255.0
!
router rip
version 2
network 10.0.0.0
no auto-summary
!
router bgp 6500x
no synchronization
redistribute rip
neighbor 10.x.100.103 remote-as 6500x
neighbor 172.31.x.3 remote-as 64998
no auto-summary
A-4

Appendix A
Router 3
interface Ethernet0
ip address 10.5.1.3 255.255.255.0
!
router bgp 65005
no synchronization
redistribute rip
neighbor 10.5.100.101 update-source Loopback0
no auto-summary
Lab 4 Using AS Path Filters and Regular Expressions

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 172.31.x.3 filter-list 2 in
neighbor 172.31.x.3 filter-list 1 out
no auto-summary
!
ip as-path access-list 1 permit ^$
ip as-path access-list 2 deny _65107$
ip as-path access-list 2 permit .*
Router 3
router bgp 6500x
no synchronization
redistribute rip
no auto-summary
!
A-5
Appendix A
Lab 5 Filtering Route Updates Using Prefix Lists

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 172.31.x.3 prefix-list SUM_ONLY in
no auto-summary
!
!
ip prefix-list SUM_ONLY seq 10 deny 172.27.0.0/16 ge 17
ip prefix-list SUM_ONLY seq 50 permit 0.0.0.0/0 le 32
Router 3
router bgp 6500x
no synchronization
redistribute rip
neighbor 10.254.0.2 prefix-list SUM_ONLY in
no auto-summary
!
A-6

Appendix A
ip
!
ip
ip
ip
ip
ip
as-path access-list 2 permit .*

prefix-list
prefix-list
prefix-list
prefix-list
prefix-list
SUM_ONLY
SUM_ONLY
SUM_ONLY
SUM_ONLY
SUM_ONLY
seq
seq
seq
seq
seq
10
20
30
40
50
deny 172.27.0.0/16 ge 17
deny 172.25.0.0/16 ge 17
deny 192.168.125.0/24 ge 25
deny 192.168.208.0/24 ge 25
permit 0.0.0.0/0 le 32
Lab 6 Route Refresh and Soft Reconfiguration

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 172.31.x.3 prefix-list SUM_ONLY in
no auto-summary
!
!
ip prefix-list SUM_ONLY seq 50 permit 0.0.0.0/0 le 32
Router 3
router bgp 6500x
no synchronization
redistribute rip
neighbor 10.254.0.2 prefix-list SUM_ONLY in
no auto-summary
!
A-7
Appendix A
ip
ip
ip
!
ip
ip
ip
ip
ip
as-path access-list 1 permit ^$

as-path access-list 2 deny _65102$
as-path access-list 2 permit .*
prefix-list
prefix-list
prefix-list
prefix-list
prefix-list
SUM_ONLY
SUM_ONLY
SUM_ONLY
SUM_ONLY
SUM_ONLY
seq
seq
seq
seq
seq
10
20
30
40
50
deny 172.27.0.0/16 ge 17
deny 172.25.0.0/16 ge 17
deny 192.168.125.0/24 ge 25
deny 192.168.208.0/24 ge 25
permit 0.0.0.0/0 le 32
Lab 7 Configuring the Weight Attribute

Router 1
interface Serial0
no ip address
no fair-queue
no shut
!
ip address 172.31.x.1 255.255.255.0
!
ip address 172.31.xx.1 255.255.255.0
!
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 172.31.x.3 weight 100
neighbor 172.31.xx.4 remote-as 64999
neighbor 172.31.xx.4 route-map WEIGHT in
no auto-summary
!
ip as-path access-list 3 permit _65208$
!
A-8

Appendix A
route-map WEIGHT permit 10
match as-path 3
set weight 150
Router3
router bgp 6500x
no synchronization
redistribute rip
neighbor 10.254.0.1 route-map WEIGHT in
neighbor 10.254.0.2 weight 100
no auto-summary
!
!
match as-path 3
set weight 150
Lab 8 Configuring the Local Preference Attribute

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 172.31.xx.4 route-map LP in
no auto-summary
!
A-9
Appendix A
!
route-map LP permit 10
set local-preference 150
Router 3
router bgp 6500x
no synchronization
redistribute rip
no auto-summary
!
!!
Lab 9 AS-Path Prepending

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 172.31.x.3 route-map PREPEND out
neighbor 172.31.xx.4 route-map LP in
no auto-summary
!
A-10

Appendix A
!!
!
route-map PREPEND permit 10
set as-path prepend 6500x 6500x 6500x 6500x
Router 3
router bgp 6500x
no synchronization
redistribute rip
no auto-summary
!
!!
!
Lab 10 Configuring the MED Attribute

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 172.31.x.3 route-map PREPEND in
neighbor 172.31.xx.4 route-map LP out
neighbor 172.31.x.3 route-map MED out
A-11
Appendix A
no auto-summary
!
!!
!
route-map MED permit 10
set metric 100
!
Router 3
router bgp 6500x
no synchronization
redistribute rip
neighbor 10.254.0.2 route-map MED out
no auto-summary
!
!!
!
route-map MED permit 10
set metric 50
!
A-12

Appendix A
Lab 11 Using the Community Attribute

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
redistribute rip
neighbor 10.x.100.103 route-map COMMUNITY in
neighbor 172.31.x.3 route-map PREPEND in
no auto-summary
!
ip bgp-community new-format
ip community-list 1 permit 6500x:200
!!
route-map COMMUNITY permit 10
match community 1
Router 3
router bgp 6500x
no synchronization
redistribute rip
neighbor 10.x.100.101 send-community
neighbor 10.254.0.2 route-map COMMUNITY in
no auto-summary
!
ip bgp-community new-format
!
route-map COMMUNITY permit 10
set community 6500x:200 additive
A-13
Appendix A
Lab 12 Becoming a Service Provider

Router 1
router bgp 6500x
no synchronization
network 172.31.x.0 mask 255.255.255.0
network 10.x.0.0 mask 255.255.255.0
network 10.x.1.0 mask 255.255.255.0
network 10.x.2.0 mask 255.255.255.0
network 10.x.3.0 mask 255.255.255.0
no auto-summary
Router 2
interface Serial0
no ip address
no ip route-cache
no ip mroute-cache
!
ip address 172.31.10x.2 255.255.255.252
no ip route-cache
!
router rip
version 2
network 10.0.0.0
no auto-summary
!
router bgp 6500x
no synchronization
network 172.31.10x.0 mask 255.255.255.252
A-14

Appendix A
neighbor 10.x.100.104
neighbor 172.31.10x.1
no auto-summary
!
remote-as 6500x
update-source Loopback0
remote-as 64997
filter-list 1 in
filter-list 2 out
1
2
2
2
permit
permit
permit
permit
_64997$
^$
_65125$
_65517$
Router 3
router bgp 6500x
no synchronization
network 10.x.0.0 mask 255.255.255.0
network 10.x.1.0 mask 255.255.255.0
network 10.x.2.0 mask 255.255.255.0
network 10.x.3.0 mask 255.255.255.0
no auto-summary
Router 4
router bgp 6500x
no synchronization
no auto-summary

A-15
Appendix A
Lab 13 Using Route Reflectors

Router 1
router bgp 6500x
no synchronization
bgp cluster-id 12
network 172.31.10x.0 mask 255.255.255.252
network 10.x.0.0 mask 255.255.255.0
network 10.x.1.0 mask 255.255.255.0
network 10.x.2.0 mask 255.255.255.0
network 10.x.3.0 mask 255.255.255.0
neighbor 10.x.100.102 route-reflector-client
no auto-summary
Router 2
router bgp 6500x
no synchronization
network 172.31.10x.0 mask 255.255.255.252
neighbor 172.31.10x.1 remote-as 64997
neighbor 172.31.10x.1 filter-list 1 in
neighbor 172.31.10x.1 filter-list 2 out
no auto-summary
!
Router 3
router bgp 6500x
no synchronization
bgp cluster-id 143
network 10.x.0.0 mask 255.255.255.0
network 10.x.1.0 mask 255.255.255.0
network 10.x.2.0 mask 255.255.255.0
network 10.x.3.0 mask 255.255.255.0
A-16

Appendix A
no auto-summary
Router 4
router bgp 6500x
no synchronization
no auto-summary
Lab 14 Using Confederations

Router 1
router bgp 65112
no synchronization
bgp confederation identifier 6500x
bgp confederation peers 65134
network 10.x.0.0 mask 255.255.255.0
network 10.x.1.0 mask 255.255.255.0
network 10.x.2.0 mask 255.255.255.0
network 10.x.3.0 mask 255.255.255.0
network 172.31.x.0 mask 255.255.255.0
neighbor 10.x.100.103 ebgp-multihop 5
no auto-summary
Router 2
router bgp 65112
no synchronization
network 172.31.108.0 mask 255.255.255.252
A-17
Appendix A
no auto-summary
!
ip
ip
ip
ip
ip
ip
as-path
as-path
as-path
as-path
as-path
as-path
access-list
access-list
access-list
access-list
access-list
access-list
remote-as 65112
remote-as 64997
filter-list 1 in
filter-list 2 out
1
2
2
2
2
2
permit
permit
permit
permit
permit
permit
_64997$
^$
_65125$
_65517$
_65112$
^\(65134$
Router 3
router bgp 65134
no synchronization
network 10.x.0.0 mask 255.255.255.0
network 10.x.1.0 mask 255.255.255.0
network 10.x.2.0 mask 255.255.255.0
network 10.x.3.0 mask 255.255.255.0
no auto-summary
Router 4
router bgp 65134
no synchronization
no auto-summary
A-18

Appendix A
Lab 15 Monitoring and Tuning BGP Resource Use

No changes are made to the final configuration in this lab. The final configuration is
the same as in Lab 14 above.
Lab 16 Using Peer Groups

Router 1
router bgp 6500x
no synchronization
neighbor POD peer-group
neighbor POD remote-as 6500x
neighbor POD password cisco
neighbor POD update-source Loopback0
neighbor POD next-hop-self
neighbor POD send-community
neighbor 10.x.100.102 peer-group POD
no auto-summary
Router 2
router bgp 6500x
no synchronization
neighbor 172.31.10x.1 remote-as 64997
no auto-summary
Router 3
router bgp 6500x
no synchronization
redistribute rip
A-19
Appendix A
no auto-summary
Router 4
router bgp 6500x
no synchronization
no auto-summary
Lab 17 Using Route Dampening

Router 1
router bgp 6500x
no synchronization
no auto-summary
!
!
match ip address 1
Router 2
router bgp 6500x
no synchronization
neighbor 10.x.100.101 next-hop-self
A-20

Appendix A
no auto-summary
remote-as 6500x
next-hop-self
remote-as 64997
filter-list 1 in
!
ip classless
ip http server
Router 3
router bgp 6500x
no synchronization
redistribute rip
no auto-summary
!
!
match ip address 1
Router 4
router bgp 6504x
no auto
no sync
network 10.4x.144.0 mask 255.255.255.0

A-21
Appendix A
A-22

Blended Learning Solutions

from Global Knowledge
The Power of Choice is Yours.
Get the IT Training you needhow and when you need it.
Mix and match our Classroom, Virtual Classroom, and e-Learning to
create the exact blend of the IT training you need. You get the same
great content in every method we offer.
Classroom
Learning
Virtual Classroom
Learning
Self-Paced
e-Learning
Train in the classroom with

our expert instructors.
Live training with real

instructors delivered
over the Web.
Self-paced training via CD

or over the Web, plus
e-mentoring and e-Labs.
1-800-COURSES
www.globalknowledge.com

Cisco BGP V 3.1 Lab Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco BGP V 3.1 Lab Guide

Uploaded by

Copyright:

Available Formats

Configuring BGP on Cisco Routers

Remote Lab Guide

Configuring BGP on Cisco Routers

9000 Regency Parkway

About Global Knowledge

Learn from Instructors with Real-World Experience

Build Your Personalized Training Plan

Configuring BGP on Cisco Routers Remote Lab Guide

Virtual Classroom e-Learning

Global Knowledge Online Reference Library

Configuring BGP on Cisco Routers Remote Lab Guide

Configuring BGP on Cisco Routers Remote Lab Guide

How to Get More Information

Free Web Seminars

Free e-Learning Demos

Configuring BGP on Cisco Routers Remote Lab Guide

Lab 1: Pod Setup

Lab 2: Configuring EBGP Peerings

Lab 3: Configuring IBGP Peerings

Lab 4: Using AS Path Filers and Regular Expressions

Task 2: Filtering Inbound Advertisements..................................................L4-5

Lab 5: Filtering Route Updates Using Prefix Lists

Lab 6: Route Refresh and Soft Reconfiguration

Lab 7: Configuring the Weight Attribute

Lab 8: Configuring the Local Preference Attribute

Lab 9: AS-Path Prepending

Configuring BGP on Cisco Routers Remote Lab Guide

Lab 10: Configuring the MED Attribute

Lab 11: Using the Community Attribute

Lab 12: Becoming a Service Provider

Lab 13: Using Route Reflectors

Lab 14: Using Confederations

Configuring BGP on Cisco Routers Remote Lab Guide

Lab 15: Monitoring and Tuning BGP Resource Use

Lab 16: Using Peer Groups

Lab 17: Using Route Dampening

Appendix A: BGP Lab Solutions

Configuring BGP on Cisco Routers Remote Lab Guide

Lab 11 Using the Community Attribute .................................................. A-13

Configuring BGP on Cisco Routers Remote Lab Guide

Configuring BGP on Cisco Routers Remote Lab Guide

Instructions for Using Global

Configuring BGP on Cisco Routers Remote Lab Guide

Accessing the Remote Labs

1. To access your remote labs, go to https://www.remotelabs.com and log in with

Configuring BGP on Cisco Routers Remote Lab Guide

Configuring BGP on Cisco Routers Remote Lab Guide

BGP Pod Topology

All pod routers have a loopback

Configuring BGP on Cisco Routers Remote Lab Guide

BGP Lab Autonomous System Structure

Configuring BGP on Cisco Routers Remote Lab Guide

Configuring BGP on Cisco Routers Remote Lab Guide

Configuring BGP on Cisco Routers Remote Lab Guide

This lab exercise requires a topology of a pod and preconfigured core. No

Enables Frame Relay

frame-relay interfacedlci 1xy

Associates a DLCI with a

Gives the router a host name

Starts RIP routing on interfaces

Prevents RIP from advertising

Starts the RIP routing process

Configuring BGP on Cisco Routers Remote Lab Guide