Deploying BGP4 (RST-243)

Session Number
Presentation_ID © 2002, Cisco Systems, Inc. All rights reserved. 1

Deploying BGP-4
RST-243
Torsten Neuber
tneuber@cisco.com
RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 3

Prerequisites
• Understand how BGP scales Internet

routing by connecting ISPs with globally
unique AS numbers
• Understand need for stable BGP
advertisement (ie BGP dampening)
• Understand difference between BGP
external and internal BGP
• Basic protocol knowledge: TCP port
179—incremental updates

Prerequisites
• Understand BGP attributes: ASPATH,

NEXT_HOP, MED, LOCAL_PREF—allow
routing policy via route-map.
• Understand the bestpath decision
algorithm
• Know why to turn off synchronization
and auto-summary!

Overview
• Protocol Overview
• Using BGP Attributes
• Deploying IBGP
• Deploying EBGP
Connecting to an ISP
Being an ISP
• Focus on Stability, Scalability, and
Configuration Templates

Complex Network Scalability
Scalable
Stable
Simple

Recap of BGP
What Is it? Why Use it?

Basic to Basics
Peering
A C
AS 100 AS 101
B D
• Runs over TCP—port 179 E
• Path vector protocol

AS 102
• Incremental updates
• “Internal” and “External” BGP

General Operation
• Learns multiple paths via internal

and external BGP speakers
• Picks THE bestpath, installs it in
the IP forwarding table, forwards to EBGP
neighbors (not IBGP)
• Policies applied by influencing the
bestpath selection

BGP Sessions—TCP Port 179,
4 Basic Message Types
• 1: OPEN MESSAGE
Exchange AS, router ID, holdtime
Capability negotiation
• 2: NOTIFICATION
Example: “peer in wrong AS”
• 3: KEEPALIVE—when no updates
• 4: UPDATES (incremental)

BGP Attributes—Tools for Routing Policy
1: ORIGIN 7: AGGREGATOR
2: AS-PATH 8: COMMUNITY
3: NEXT-HOP 9: ORIGINATOR_ID
4: MED 10: CLUSTER_LIST
5: LOCAL_PREF 14: MP_REACH_NLRI
6: ATOMIC_AGGREGATE 15: MP_UNREACH_NLRI

Why Use It?
• You need to scale your IGP

• You’re a multihomed ISP customer
• You need to transit full Internet routes

Deploying BGP
Turn of the Archaic Features!

BGP Template - BGP Global Settings
router bgp 1
bgp deterministic-med
no synchronization
no auto-summary
distance 200 200 200
For BGP config templates from now on, I’ll

assume you’ve already done this!

Deploying Internal BGP
Loopbacks, Peer-Groups, Route Reflectors and Confederations

Guidelines for Stable IBGP
• IBGP peer using loopback addresses

neighbor { ip address | peer-group}
update-source loopback0
• Independent of physical
interface failure
• IGP performs any load-sharing
• IBGP only—use on RR clients with care!!!

Peering with Loopbacks
Without Loopbacks, the TCP

Session Is Always
Sourced from the IP Address
A B
of the Outbound Interface—
Which Can Go Down!
• Configuration:
Router A 1.0.1.1 1.0.1.2
router bgp 1
neighbor 1.0.1.1 remote-as 1 If Redundant Paths Exist,
Router B Use Loopback Interfaces
router bgp 1 to Establish the Session
neighbor 1.0.1.2 remote-as 1

Guidelines for Scaling IBGP
• Carry only next-hops in IGP

• Carry full routes in BGP only
if necessary
• Do not redistribute BGP into IGP
• Use peer groups and RRs

BGP Template—IBGP Peers
IBGP Peer Group AS1

router bgp 1
neighbor internal peer-group
neighbor internal description ibgp peers
neighbor internal remote-as 1
neighbor internal update-source Loopback0
neighbor internal next-hop-self
neighbor internal send-community
neighbor internal version 4
neighbor internal password 7 03085A09
neighbor 1.0.0.1 peer-group internal
neighbor 1.0.0.2 peer-group internal
What Is a Peer Group?
• Simplifies configuration
• All peer-group members have
a common outbound policy
• Updates generated once per peer group
• Members can have different
inbound policy

Why Route Reflectors?
Avoid n(n-1)/2 iBGP Mesh
13 Routers =>
78 IBGP
Sessions!
n=1000 => Nearly
Half a Million
iBGP Sessions!

Using Route Reflectors
Backbone
RR
RRC RR
RR RRC
Cluster A RRC
RR
RR
Cluster C
Golden Rule Cluster B
of RR Loop Avoidance:
“RR Topology Should Follow RRC
Physical Topology”
RR
=> Be Careful with Loopback Peering!!!!
Cluster D
Route Reflectors
• Provide additional control to allow

router to advertise (reflect) iBGP
learned routes to other iBGP peers
Method to reduce the size of the iBGP mesh
• Normal BGP speakers can coexist
Only the RR has to support this feature
neighbor x.x.x.x route-reflector-client

Route Reflectors—Terminology
Non-client Route Reflector
Clusters
Clients Clients
Lines Represent Both Physical Links and BGP Logical Connections
Route Reflectors—Terminology (Cont.)
• Route reflector
Router that reflects the iBGP information
• Client
Routers between which the RR reflects
updates (may be fully meshed among
themselves)
• Cluster
Set of one or more RRs and their clients
(may overlap)
• Non-client
iBGP neighbour outside the cluster
What Is a Route Reflector?
• Reflector receives path from clients and

non clients
• If best path is from a client, reflect to
clients and non-clients
• If best path is from a non-client, reflect
to clients

Route Reflectors—Hierarchy
• Clusters may be
configured
hierarchically Level 1
RRs in a cluster are clients

of RRs in a higher level Level 2
Provides a
“natural”
method to limit routing
information sent to lower
levels

Deploying Route Reflectors
• Divide backbone into multiple clusters

• Each cluster contains at least one
RR; Clients can peer with RRs in other
clusters for redundancy
• RRs are fully meshed via IBGP
• Still use single IGP—next-hop unmodified
by RR; unless via explicit inbound
route-map

Route Reflectors—Migration
• Where to place the route reflectors?

Follow the physical topology!
This will guarantee that the packet forwarding won’t be
affected
• Configure one RR at a time

Eliminate redundant iBGP sessions
Place one RR per cluster

• Step 0:
full iBGP mesh A
B C
D
E
Logical Links
Physical AND Logical Links

• Step 1:
configure D A
as a RR; E
is the client
B C
D RR
E
Logical Links

• Step 2:
eliminate A
unnecessary
iBGP links
B C
D RR
E
Logical Links

• Step 3:
repeat for other A
clusters
and iBGP
links RR
B C
RR
D RR
E
Logical Links

BGP Template: Peer-Group for RR Clients
router bgp 1
Will this Break the
neighbor rr-client peer-group “Golden Rule?”
neighbor rr-client description RR clients
neighbor rr-client remote-as 1
neighbor rr-client update-source Loopback0
neighbor rr-client route-reflector-client
neighbor rr-client next-hop-self This Line on RRs
Only RRCs Use
neighbor rr-client send-community Still Use Internal
Peer Group
neighbor rr-client version 4
neighbor rr-client password 7 03085A09
neighbor 10.0.1.1 peer-group rr-client
neighbor 10.0.1.2 peer-group rr-client
RR Specific BGP Attributes
Router id
RR
1.3.1.1
1.4.1.1 RRC Router id

A 1.2.1.1
RR
• Example: C
RRC
RouterB>sh ip bgp 3.0.0.0 B Router id D
BGP routing table entry for 3.0.0.0/8 1.1.1.1
3
1.0.1.2 from 1.4.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 1.1.1.1 1.0.1.2

Cluster list: 1.3.1.1, 1.2.1.1
AS3
3.0.0.0

BGP Attributes: ORIGINATOR_ID
• ORIGINATOR_ID
Router ID of IBGP speaker that injects
route into AS—applied by RR
• Useful for troubleshooting and
loop detection

BGP Attributes: CLUSTER_LIST
• CLUSTER_LIST
String of CLUSTER_IDs through which the
route has passed
• Usually CLUSTER_ID=ROUTER_ID
• Overridden by: bgp cluster-id x.x.x.x—but
remember: don’t do this!!!!
• Useful for troubleshooting and
loop detection

Route Reflectors—Redundancy
• Multiple RRs can be configured in the

same cluster—but we now advise
against this
Other RRs in the same cluster should
be treated as iBGP peers (non-clients)
All RRs in the cluster must have the same
cluster-id
• A router may be a client for RRs
in different clusters

Multiple Route Reflectors
cluster-id 3.0.0.1
1.0.0.1
routerB>sh ip bgp 10.0.0.0 RR2 RR1

BGP routing table entry for 198.10.10.0/24
3 B
2.0.0.2 from 1.0.0.1 (1.0.1.1) 1.0.1.1
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 1.0.1.1
Cluster list: 3.0.0.1 eBGP
If A and C have the same
CLUSTER_ID, C will not reflect
2.0.0.2
routes from A to B ( ignored due to
3.0.0.1 in the CLUSTER_LIST) 10.0.0.0/24
⇒If the direct links C-D and B-A fail, Lines Represent Both Physical
Links and BGP Logical Connections
D cannot reach 10.0.0.0

Route Reflectors—Results
• Number of neighbors is reduced

No need for full iBGP mesh
• Number of routes propagated is reduced
Each RR advertises only the best path
to its clients
• Stability and scalability are achieved!

Confederations
• Divide the AS into sub-AS

eBGP between sub-AS, but some iBGP
information is kept
Preserve NEXT_HOP across the
sub-AS (IGP carries this information)
Preserve LOCAL_PREF and MED
• Usually a single IGP

Confederations (Cont.)
• Visible to outside world as single AS—

“Confederation Indentifier”
Each sub-AS uses a number from the
private space
• iBGP speakers in sub-AS are
fully meshed
The total number of neighbors is reduced by
limiting the full mesh requirement to only the
peers in the sub-AS

Sub-AS
65530
AS 2
B Sub-AS
65531
Sub-AS
65532
• Configuration (rtr B):

router bgp 65532
confederation identifier 2
bgp confederation peers 65530 65531

Route Propagation Decisions
• Same as with “normal” BGP:

From peer in same sub-AS → only to
external peers
From external peers → to all neighbors
• “External peers” refers to
Peers outside the confederation
Peers in a different sub-AS
Preserve LOCAL_PREF, MED and NEXT_HOP

• Example (cont.):
BGP table version is 78, local router ID is 141.153.17.1
Status codes: s suppressed, d damped, h history,
* valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 141.153.14.3 0 100 0 (65531) 1 i
*> 141.153.0.0 141.153.30.2 0 100 0 (65530) i
*> 144.10.0.0 141.153.12.1 0 100 0 (65530) i
*> 199.10.10.0 141.153.29.2 0 100 0 (65530) 1 i

RRs or Confederations
Internet Multi-Level Policy Migration

Scalability
Connectivity Hierarchy Control Complexity
Anywhere
Medium
Confederations In the Yes Yes Medium
To High
Network
Route Anywhere
Reflectors In the Yes Yes Very High Very Low
Network

More Points about Confeds
• Can ease “absorbing” other ISPs into you

ISP—eg, if one ISP buys another (can use
local-as feature to do a similar thing)
• You can use route-reflectors within
confederation sub-as to reduce the sub-as
ibgp mesh

So Far…
• Is IBGP peering Stable?

Use loopbacks for peering
• Will it Scale?
Use peer groups
Use route reflectors
• Simple, hierarchical config?

COMMUNITIES
They’re for Everyone!

Problem: Scale Routing Policy
Solution: COMMUNITY
• NOT in decision algorithm

• BGP route can be a member of many
communities
• Typical communities:
Destinations learned from customers
Destinations learned from ISPs or peers
Destinations in VPN—BGP community is
fundamental to the operation of BGP VPNs

Solution: COMMUNITY
Communities:
1:100—Customer Routes
1:80— ISP Routes ISP 2
ISP 1
ISP 3 ISP 4
0.0.0.0
Customer 1 Customer 2
(no Default, (Uses Default,
Wants Full Routes) Wants Your Routes)
Solution: COMMUNITY
Communities: Set Community

1:100—Customer Routes 1:80
1:80— ISP Routes ISP 2
ISP 1 Match Community

1:100
Match Community
1:100 1:80 Match Community
ISP 3 1:100 ISP 4
Set Community 0.0.0.0

1:100
Customer 1 Customer 2
(no Default, (Uses Default,
Wants Full Routes) Wants Your Routes)
BGP Attributes: COMMUNITY
• Activated per neighbor/peer-group:

neighbor {peer-address | peer-group-name}
send-community
• Carried across AS boundaries
• Common convention is string
of four bytes: <AS>:[0-65536]

BGP Attributes: COMMUNITY (Cont.)
• Each destination can be a member of

multiple communities
• Using a route-map: set community
<1-4294967295> community number
aa:nn community number in aa:nn format
additive Add to the existing community
none No community attribute
local-AS Do not send to EBGP peers (well-known
community)
no-advertise Do not advertise to any peer (well-known
community)
no-export Do not export outside AS/confed (well-known
community)

Community Filters
• Filter based on Community Strings

ip community-list <1-99> [permit|deny] comm
ip community-list <100-199> [permit|deny]
regexp
• Per neighbor
Inbound or outbound route-maps
match community <number> [exact-match]
exact match only for standard lists

Community Filters
• Example 1:
Mark some prefixes as part of the 1:120 community
(+remove existing community!)
• Configuration:
router bgp 1
neighbor 10.0.0.1 send-community
neighbor 10.0.0.1 route-map set_community out
!
route-map set_community 10 permit
match ip address 1
set community 1:120
!
access-list 1 permit 10.10.0.0 0.0.255.255
Community Filters
• Example 2:
Set LOCAL_PREF depending on the community that
the prefix belongs to.
• Configuration:
router bgp 1
neighbor 10.0.0.1 route-map filter_on_community in
!
route-map filter_on_community 10 permit
match community 1
set local-preference 150
!
ip community-list 1 permit 2:150

Regular Expression Syntax—URL
• Overview of IOS regular expression

syntax:
http://www.cisco.com/univercd/cc/td/doc/prod
uct/software/ios11/arbook/arapptrn.htm

Deploying External BGP
for Enterprises
Aggregation, Policy, and Loadsharing

Tasks
• Steps
Configure neighbor
Advertise stable prefixes to your ISP
Set inbound policy
Set output policy
Configure loadsharing/multi-homing

BGP Template: BGP to an ISP
AS 2
Router B:
router bgp 1 10.0.0.0
network 10.60.0.0 mask 255.255.0.0
.1 A
neighbor external peer-group
neighbor external remote-as 2
AS 1 Is a Customer
neighbor external description ISP connection
of ISP AS 2
neighbor external remove-private-AS
neighbor external version 4
neighbor external prefix-list ispout out ; “accident” filter 10.200.0.0
neighbor external route-map ispout out ; “real” filter
neighbor external route-map ispin in .2 B
neighbor external password 7 020A0559
10.60.0.0/16
neighbor external maximum-prefix 65000 [warning-only]
neighbor 10.200.0.1 peer-group external AS1
ip route 10.60.0.0 255.255.0.0 null0 254

Neighbor Template: Notes
The slide shows a “complete” EBGP configuration. Notice that it has quite a few
more features enabled than the simple configuration I gave at the start of the
session. These features are not all mandatory—they are suggestions, and you
should read the justifications that follow to see if they make sense in your network.
I begin my generating a stable aggregate (or supernet) route that covers all of the
subnets in my network. There is no need for the Internet to know about more
specific routes in my network, and I do not want to “flap” routes as these
individual subnets may come and go within my network.
First, even though there is only one neighbor, I define a peer group. This does no
harm, and may remind me to re-use the peer-group if I have a another session to
the same ISP (with the same outbound policy), thereby obtaining the update
generation efficiency that comes with this feature.
Next, I define the remote-as 2, and the provide a text description. I also instruct the
neighbor to remove any private AS numbers (64512-65535). Although not strictly
necessary if you are not using private AS, this is a nice safeguard should you ever
decide to use private AS numbers in your network, and forget to update your
outbound policy accordingly.
I lock down the BGP version to version 4, to guard against the hopefully rare, but
possible, outcome the ISP configures their sessions with version 3 (call me
paranoid :-) ).

Neighbor Template: BGP to an ISP
Now I apply the routing policy. Because I’m paranoid, I double-up on the outbound
policy. I apply a route-map containing a community list as my “primary” filter;
however I back this up with a prefix list. This is only really feasible if you are an
enterprise and the number of entries in the prefix-list is small. For an ISP, you will
probably just use a community list, and extreme care!!!
I apply an inbound policy, which essentially prevents me against mistakes my ISP
make make, such as sending me my own routes, sending me private IP address
space (eg network 10.0.0.0 etc).
Speaking of mistakes: what if the ISP messes up their outbound policy and sends
me more routes than the memory in my router can take? If this router is not only
connecting me to the outside world, but also performing critical routing functions
WITHIN my network, it would be bad for a problem with the ISP to disrupt internal
network connectivity. I protect my router against this by using the “maximum-
prefix” command. I know roughly how many routes my ISP should be sending me,
and I choose a number a little higher than this—if the ISP sends me more, then the
router will close down the session, and keep it down until I issue a “clear ip bgp
10.200.0.1”. Alternatively, if I know that network management is quick to respond
to problems, I could just configure the command to log a warning instead.
Finally, I apply a password, negotiated with my ISP, to the session.

Maximum Prefix Tracking (Cont.)
• Sample logs:
The number of prefixes received from a peer
reaches 75% of the maximum configured:
%BGP-4-MAXPFX: No. of prefix received
from 44.1.1.2 reaches 3, max 4
The number of prefix exceeds the maximum
number of prefixes configured:
%BGP-3-MAXPFXEXCEED: No. of prefix
received from 44.1.1.2: 4 exceed limit 3

Tasks
• Steps
Configure neighbor
Set inbound policy
Set output policy

Advertise Stable Prefixes to Your ISP
• Avoid redistribution—it propagates IGP

instabilities to the Internet; Unstable
routes may be dampened!
• Try to summarize!
• For loadsharing, may split the
aggregate—more later

BGP Template: BGP to an ISP
The first instinct for many people is to redistribute their IGP into BGP. This is a bad
idea for a couple of reasons:
First, IGPs tend to have a lot our routing activity as they route-around network
failures. This is the good an dproper behavior of an IGP. However, one of
primary goals of BGP is to hide “internal” rouring changes to your network
that have no impact on global routing. Remember it is common practice by
ISPs in the Internet to “dampen” unstable routes learned from the customers
of other ISPs.
Second, the subnetting used by an IGP is probably not of interest to the wider
Internet. As with good IGP design, you should attempt to “summarize” you
routes, so that you advertise the minimum number of routes to the Internet
routing tables. It’s everyone’s responsibility to try and minimize the size of the
Internet routing tables.
You can also use a route-map to adjust other BGP attributes. For example, you
may connect to your ISPs in two location, and generate two aggregates. You can
set the MEDs so that traffic for one aggregate will come into one link, and traffic to
the other will come in the other link (with both links providing a backup to the
other). Now I apply the routing policy.

Why Summarize?
• Reduce number of Internet prefixes

• Increase stability—aggregate stays
even if specifics come and go

How to Summarize?
• Use the “network” statement to define

prefix—can add route-map
• network statement only installs BGP route
if there is a matching route in IGP
=> lock down a stable static to null0; set admin
distance to 254 so it does not override any
“real” IGP route
router bgp 1
network 10.60.0.0 mask 255.255.0.0 <route-map>
:
ip route 10.60.1.0 255.255.255.0 null0 254

Tasks
• Steps
Configure neighbor
Set inbound policy
Set output policy

Why Inbound Policy?
• Apply a recognizable community to

use in outbound filters or other policy
• Apply local preferences
• Filter our you own/martian routes
• Multihoming loadsharing—more later

BGP Template—Inbound Policy
route-map ISPin permit deny 10

match ip address prefix-list ISPout sanity-check
route-map ISPin permit 20
set local-preference 200 routes from ISP—you could
use the“no-export” well
set community 1:2 known community instead

Notes on Inbound Policy Template
Now let’s look at inbound policy. The roles of inbound policy are to protect you
against mistakes made by your ISP; to place routes into communities for
subsequent use in outbound policy; and to modify BGP attributes to allow us to
control which exit we use to send traffic to various destinations on the Internet.
To implement inbound policy I apply a route-map to the peer-group. Remember
than inbound-policy does NOT have to be the same for all peer-group members, so
I can apply different policies to different neighbors within a peer-group.
The route-map, which I’ve call ISPin does three things:
1) rejects any networks in prefix-list ISPout—this prefix lists contains the
prefixes I send to my ISP, so I should not expect to receive them back. I also
call a prefix list that rejects private address space and other “insane” or
“martian” (not on this planet!) routes.
2) applied a local-preference of 200 to all of the routes—perhaps because this
exist point is the primary exit point, and another connection to my ISP is the
backup, and uses the default local-preference of 100.
3) Put the routes in community 1:2, which signifies “routes I’ve learned from
my ISP”.

Sanity-Check Prefix-List 1/2
ip prefix-list sanity-check seq 5 deny 0.0.0.0/32
# deny the default route - YOU MAY WANT TO OMIT THIS LINE
ip prefix-list sanity-check seq 10 deny 0.0.0.0/8 le 32
# deny anything beginning with 0
ip prefix-list sanity-check seq 15 deny 0.0.0.0/1 ge 20
# deny masks > 20 for all class A nets (1-127)
# deny 10/8 per RFC1918
# reserved by IANA - loopback address
deny masks >= 17 for all class B nets (129-191)
# deny net 128.0 - reserved by IANA
# deny 172.16 as RFC1918

Sanity-Check Prefix-List 2/2
# class C 192.0.20.0 reserved by IANA
# deny 192.168/16 per RFC1918
# deny 191.255.0.0 - IANA reserved (I think)
# deny masks > 25 for class C (192-222)
# deny anything in net 223 - IANA reserved
# deny class D/Experimental

Tasks
• Steps
Configure neighbor
Set inbound policy
Set output policy

Why Outbound Policy?
• Main filter based on communities

• Adding a prefix filter helps protect against
mistakes (can apply as-path filters too)
• Send community based on agreements
with ISP—eg RFC1998 (remember to
config send-community)
• Multihoming loadsharing policy

Notes On Outbound Policy
Now that inbound policy is set, I next setup the outbound policy. A common
mistake made by many enterprises that dual home it to take a full set of routes
from one ISP, and immediately send them up to the other ISP. This effectively says
the entire Internet is reachable through your network!!! Outbound policy prevents
this from occurring, so you can see why it’s critical.
I typically use primary outbound filter based on communities. I only send to my ISP
all of the routes originated in my network, which I identify with the community 1:1.
In smaller installations, where the number of prefixes in the network is small, I may
also use a prefix-list as a “backup” for the primary community filter. This does
nothing more than to help protect the world against my mistakes!!! :-)
I may also have configured some communities in agreement with my ISP. For
example, RFC1998 describes a way to indicate which of your ISPs is primary a
secondary for a particular set of routes.
Finally, you can configure any multihoming/loadsharing policy. You may want to
divide your address space, and make traffic to half of your network come in via one
ISP, and traffic for the other half come in through the other.

BGP Template—Outbound Policy
ip prefix-list ISPout seq 5 permit 10.60.0.0 255.255.0.0

:
ip community-list 1 permit 1:1 ; all routes to send to ISP
:
route-map ISPout permit 10
match community 1 ; Internet transit community
set community 1:3 [additive] ; something agreed with ISP

Notes On Outbound Policy
The previous slide shows my outbound policy. First, the prefix-list ISPout matches
all of the routes I intend to send to the Internet—in this case only one—life is
simple in the powerpoint world of network design :-) This prefix-list is my “backup”
in case I make a mistake with communities. I only used it on my connections to
my ISP.
The primary filter is based on communities. I match all communities in community-
list 1: ie, only community 1:1, corresponding to all the routes local to my network.
This assumes that on ingress to by BGP tables (either via EBGP sessions,
“network/aggregate-address”, or redistribution from an IGP, I have used a route-
map to set the community to 1:1.
Finally I add the outbound community to 1:3 community attribute. This is done to
meet some arbitrary agreement I’ve have made with my ISP on how it will treat
routes I put in this community.

Tasks
• Steps
Configure neighbor
Set inbound policy
Set output policy

Load-Sharing Template: Single Path
Router A:
interface loopback 0
ip address 1.0.0.1 255.255.255.255
ip route 2.0.0.1 255.255.255.255 serial0/0
ip route 2.0.0.1 255.255.255.255 serial0/1
!
router bgp 1
neighbor 2.0.0.1 update-source loopback0
neighbor 2.0.0.1 ebgp-multi-hop 2
B
A Loopback 0
2.0.0.1
AS2
AS1

Load-Sharing Template: Multiple
Paths from Same AS
Router A:
router bgp 1
maximum-paths 2 ; can configure up to 6
B
2.0.0.1
A
AS 2
2.0.0.2
AS 1 C
• Outbound loadsharing works well :-)

• Inbound loadsharing depends on ISP IGP :-|
What Is Multi-homing?
• Connecting to two or more ISPs to

increase:
Reliability—one ISP fails, still OK
Performance—better paths to common
Internet destinations

Types of Multi-homing
• Three common cases:

Default from all ISPs
Default + customer routes from all ISPs
Full routes from all ISPs
• Look first at outbound loadsharing

Default from All ISPs
• Low memory/CPU solution

• All ISPs send (or you generate) default
• ISP decided by IGP metrics to
reach default

Default from All ISPs
Customer
AS 4
4.0.0.0/8
ISP ISP
AS 2 AS 3
D E
0.0.0.0 0.0.0.0
A B
AS 1
C Chooses Lowest
IGP Metric to Default
C

Customer+Default from All ISPs
• Medium memory and CPU

• “Best” path—usually shortest AS-path
• Use local-preference to override based on
prefix, as-path, or community
• IGP metric to default used to reach non-
direct customers of ISPs

Customer Routers from All ISPs
Customer
AS 4
4.0.0.0/8
ISP ISP
AS 2 AS 3
D E
A B
C Chooses AS 1
Shortest AS Path
C
Customer Routes from All ISPs
Customer
AS 4
4.0.0.0/8
ISP ISP
AS 2 AS 3
D 800 E
A B ip prefix-list AS4 permit 4.0.0.0/8

C Chooses Highest
Local-Preference
AS 1 route-map AS3in permit 10
match ip address prefix-list AS4
set local-preference 800
C
Customer Routes from All ISPs
Tier 1 ISP Tier 1 ISP AS 6

AS 4 AS 5
Tier 2 ISP Tier 1 ISP
AS 2 AS3
D E
A B
AS 1
AS400 Takes Sub-
Optimal AS Path
C

Full Routes from All ISPs
• Higher memory/CPU solution

• Reach all destinations by “best”
path—usually shortest AS path
• Can still manually tune
using local-pref and
as-path/community/prefix matches

Full Routes from All ISPs
Tier 1 ISP Tier 1 ISP AS 6

AS 4 AS 5
Tier 2 ISP Tier 1 ISP
AS 2 AS3
D E
A B
AS 1
C Chooses
Shortest AS Path
C

Controlling Inbound Traffic?
• Inbound is more difficult to control due to

lack of a transitive metric
• You can evenly divide outgoing address
blocks across providers, but what
happens to redundancy?
• If you split your address block, ISPs may
filter out the specifics anyway

Controlling Inbound Traffic? (Cont.)
• Bad Internet citizen:

Divide address space
Set as-path prepend
• Good Internet citizen—RFC2260
Divide address space
Use “advertise maps”
• Results may not be as good as NAT with
transport level loadsharing
Warning: if you split your address block using these techniques
it may be filtered by some ISPs
Using AS-PATH Prepend
10.1.0.0/16 3 1 1
10.1.0.0/16 2 1 (best)
Customer 10.2.0.0/16 3 1 (best)
to
10.1/16 AS 100 10.2.0.0/16 2 1 1
ISP
ISP
AS 2 AS 3
30.0.0.1
D E
router bgp 1
A B
neighbor 30.0.0.1 route-map AS3out out
AS 1 ip prefix-list AS1 permit 10.1.0.0/16
route-map AS3out permit 10
10.1/16 C 10.2/16
match ip address prefix-list AS1
set as-path prepend 1

Using an Advertise-Map
router bgp 100
neighbor <R1> advertise-map am non-exist-map bb
1.10/16 access-list 1 permit 10.15.7.0 !Advertise when...
10.15.7/24 Auto-Inject access-list 2 permit 10.15.0.0 !… this disappears
route-map am permit 10
match ip address 1
route-map bb permit 10.15/16
ISP1
match ip address 2 ISP2
R1
R3
1.10.6/24 10.15.7/24 10.15.20/30
R2 R4
AS 2
10.15.7/24
1.10.6/24
1.10.6.1
10.15.7.4

Summary for Enterprise EBGP
• Stability through:
Aggregation/summary routes
Multihoming
Inbound/outbound policy
• Scalability of memory/CPU:
Default, customer routes, full routes
• Simplicity using “standard” solutions

Deploying External BGP
for ISPs
Route Aggregation, Customer Aggregation, NAPs

ISP EBGP Tasks
• Configure stable aggregates

• Scale BGP customer aggregation
• Offer a choice of route-feeds
• Peer with other providers
• Provide a backup service

What Is Aggregation?
• Summarization based on specifics from

the BGP routing table
10.60.1.0 255.255.255.0
10.60.2.0 255.255.255.240
=> 10.60.0.0 255.255.0.0

How to Aggregate
• aggregate-address 10.60.0.0 255.255.0.0

{as-set} {summary-only} {route-map}
• Use as-set to include path and community
info from specifics
• summary-only suppresses specifics
• route-map sets other attributes

How to Aggregate—Notes
So what is aggregation? Aggregation is generating that all-important stable route

that summarizes all of the routes I want to send to the Internet. My route is stable
because it is common practice by ISPs in the Internet to “dampen” the routes
learned from the customers of other ISPs.
Generating a stable aggregating it a three step process. First I configure the
“aggregate-address” command to define the aggregate prefix to be generated. The
command includes both net and mask.
If I include the “as-set” keyword, it causes the router to generate an AS-SET within
the AS-PATH. Remember from earlier in the session, that an AS-SET includes AS-
PATH information from all more specific routes that contributed to the aggregate.
As well as generating an AS-SET, the router will also include BGP community
information from all of the more specific routes in the community attribute of the
aggregate route.
By default, the aggregate address command does NOT filter out the more specific
BGP routes. TO do this you need to add the “summary-address” keyword. Mostly
likely you will want to do this.
You can also use a route-map to adjust other BGP attributes. For example, you
may connect to your ISPs in two location, and generate two aggregate. You can set
the MEDs so that traffic for one aggregate will come into one link, and traffic to the
other will come in the other link (with both links providing a backup to the other).

Why Aggregate?
• Reduce number of Internet prefixes—

advertise only your CIDR block
• Increase stability—aggregate stays
even if specifics come and go
• Stable aggregate generation:
router bgp 1
aggregate-address 10.60.0.0 255.255.0.0 as-set summary-only
network 10.60.1.0 255.255.255.0
:
ip route 10.60.1.0 255.255.255.0 null0 254

Why Aggregate: Notes
Once you’ve configured the aggregate, the next step is to configure a stable MORE
SPECIFIC route in the BGP table. After all, your aggregate depends on the existing
of more specific routes, to you must ensure at least one of the more specific
routes is stable.
To do this, use the “network” command. Choose a more specific route than your
aggregate—a route that is used somewhere in route network. In the slide I’ve
chosen 10.60.1/24.
The network command will install a corresponding route in the BGP table, ONLY if
there is a matching route in the IP routing table. The third, and final step, is
therefore to generate a stable route in the IP routing table. To do this, I configure a
STATIC route for 10.60.1/24, pointing to the NULL0 interface. However, I do not
want this route to override any “real” route that I’m learning via an IGP for
10.60.1/24—so, I set the ADMIN DISTANCE of the static route to 254.
Note that if you do note want to generate AS-SET/community summary
information, you can omit the aggregate-address command. Use the network
command to generate the aggregate prefix, and then put a matching static route in
pointing to NULL0. Many, perhaps most, folks tend to do it this way, and do not
use the aggregate address command. Note that you need to be careful to filter out
more specific BGP routes if you use this technique, as the network command does
not provide any “summary-only” functionality.

BGP Attributes Atomic Aggregate
• Indicates loss of AS-PATH information

• Must not be removed once set
• Set by: aggregate-address x.x.x.x
• Not set if as-set keyword is used, however,
AS-SET and COMMUNITY then carries
information about specifics

BGP Attributes: Aggregator
• AS number and IP address of router

generating aggregate
• Useful for troubleshooting
• Only set by aggregate-address; NOT set
by the network statement

Aggregate Attributes
NEXT_HOP = local (0.0.0.0)

WEIGHT = 32768
LOCAL_PREF = none (assume 100)
AS_PATH = AS_SET or nothing
ORIGIN = IGP
MED = none

ISP EBGP Tasks

• Provide a backup service
• Propagate QoS policy

Customer Aggregation Guidelines
• Define at least three peer groups:

cust-default—send default route only
cust-cust—send customer routes only
cust-full —send full Internet routes
• Identify routes via communities
eg, 2:100=customers; 2:80=peers
• Apply passwords and an inbound prefix-
list on a per neighbor basis

Customer Aggregation
Your AS CORE
CIDR Block: 10.0.0.0/8
Route Reflector
Aggregation Router
(RR Client)
Client Peer Group
Full Routes “Default” Customer Routes

Peer Group Peer Group Peer Group
Apply Passwords and Inbound
Prefix-list Directly to Each Neighbor
BGP template - customers
neighbor x.x.x.x remote-as X

neighbor x.x.x.x peer-group (cust-full or cust_cust
or cust_default)
neighbor x.x.x.x password <password>
neighbor x.x.x.x prefix-list ASXXX in
.
ip prefix-list ASXXX seq 5 permit <prefix>

BGP template - full routes peer-group
neighbor cust-full peer-group

neighbor cust-full description Send full Routes
neighbor cust-full remove-private-AS
neighbor cust-full version 4
neighbor cust-full route-map cust-in in
neighbor cust-full route-map
full-routes out
.

BGP template: full routes route-map
ip prefix-list cidr-block seq 5 deny 10.0.0.0/8 ge 9

ip prefix-list cidr-block seq 10 permit 0.0.0.0/0 le 32
.
route-map full-routes permit 10
match ip cidr-block ; deny CIDR subnets
match community 1 80 ; customer & peers
set metric-type internal ; MED = IGP metric
set ip next-hop peer-address ; our own
BGP template: customer inbound
route-map
route-map cust-in permit 10

set metric 4294967294 ; ignore MED
set ip next-hop peer-address
set community 2:100

BGP template: customer routes
peer-group
neighbor cust-cust peer-group

neighbor cust-cust description customer routes
neighbor cust-cust remove-private-AS
neighbor cust-cust version 4
neighbor cust-cust route-map cust-in in
neighbor cust-cust route-map cust-routes out

BGP Template: template: customer
routes route-map
route-map cust-routes permit 10

match ip cidr-block
match community 1 ; customers only
set metric-type internal ; MED = igp metric

BGP Template: default route
peer-group
neighbor cust-default peer-group

neighbor cust-default description Send default
neighbor cust-default default-originate
route-map default-route
neighbor cust-default remove-private-AS
neighbor cust-default version 4
neighbor cust-default route-map cust-in in
neighbor cust-default prefix-list deny-all out
ip prefix-list deny-all seq 5 deny 0.0.0.0/0 le 32

ISP EBGP Tasks


Peering with other ISPs
• Similar to EBGP customer aggregation

except inbound prefix filtering is rarely
used (lack of global registry)
• Use maximum-prefix and prefix sanity
checking instead
• Still use per-neighbor passwords!

BGP Template: ISP peers peer-group
neighbor nap peer-group

neighbor nap description for peer ISPs
neighbor nap remove-private-AS
neighbor nap version 4
neighbor nap prefix-list sanity-check in
neighbor nap prefix-list cidr-block out
neighbor nap route-map nap-out out
neighbor nap maximum prefix 30000

BGP Template: ISP peers route-
route-map nap-out permit 10

match community 1 ; customers only
set metric-type internal ; MED = IGP metric

Peer Groups for NAPs:
Sanity-Check Prefix-List
# FIRST - FILTER OUT YOUR IGP ADDRESS SPACE!!
ip prefix-list sanity-check seq 5 deny 0.0.0.0/32
# deny the default route
# deny anything beginning with 0
# deny masks > 20 for all class A nets (1-127)
# deny 10/8 per RFC1918
# reserved by IANA - loopback address
deny masks >= 17 for all class B nets (129-191)
# deny net 128.0 - reserved by IANA
# deny 172.16 as RFC1918
Peer Groups for NAPs:
Sanity-Check Prefix-List

# deny 192.168/16 per RFC1918
# deny 191.255.0.0 - IANA reserved (I think)
# deny masks > 25 for class C (192-222)
# deny anything in net 223 - IANA reserved
# deny class D/Experimental

Summary for Deploying EBGP
• Stability through:
Aggregation/summary routes
Inbound prefix-filtering and passwords
Apply “sanity-check” and maximum-prefix
feature to ISP peering
• Scalability of memory/CPU:
Three peer-groups for customers: Default,
customer routes, full routes
One peer group for ISP peers
• Simplicity using “standard” solutions
Session Summary 1
• Scalability:
Use attributes, especially community
Use peer groups and route reflectors
• Stability:
Use loopback addresses for IBGP
Generate aggregates/summary addresses
Apply passwords
Always filter inbound and outbound

Session Summary 2
• Simplicity—standard solutions:
Three multihoming options
Group customers into communities
Apply standard policy at the edge
Avoid “special configs”
Script your config generation

For Further Reference:
• BGP bestpath
http://www.cisco.com/warp/public/459/25.shtml
• Case studies on www.cisco.com:
http://www.cisco.com/warp/public/459/18.html
• www.cisco.com—search “BGP <feature>”
• www.nanog.org

Recommended Reading
Cisco BGP-4 Command and

Configuration Handbook
ISBN: 1-58705-017-X
Advanced IP Network Design
ISBN: 1-57870-097-3
Internet Routing Architectures
ISBN: 1-57870-233-X
Routing TCP/IP, Volume II
ISBN: 1-57870-089-2
Troubleshooting IP Routing Protocols
ISBN: 1-58705-019-6
Available online or on-site at the Cisco Company Store

Deploying BGP-4
RST-243

Please Complete Your
Evaluation Form
RST-243

Session Number
Presentation_ID © 2002, Cisco Systems, Inc. All rights reserved. 133

Deploying BGP4 (RST-243)

Uploaded by

Document Information

Original Description:

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

Deploying BGP4 (RST-243)

Uploaded by

Copyright:

Available Formats

Session Number

Presentation_ID © 2002, Cisco Systems, Inc. All rights reserved. 1

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 3

• Understand how BGP scales Internet

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 4

• Understand BGP attributes: ASPATH,

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 5

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 6

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 7

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 8

• Runs over TCP—port 179 E

• Path vector protocol

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 9

• Learns multiple paths via internal

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 10

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 11

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 12

• You need to scale your IGP

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 13

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 14

For BGP config templates from now on, I’ll

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 15

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 16

• IBGP peer using loopback addresses

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 17

Without Loopbacks, the TCP

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 18

• Carry only next-hops in IGP

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 19

IBGP Peer Group AS1

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 21

Avoid n(n-1)/2 iBGP Mesh

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 22

• Provide additional control to allow

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 24

Non-client Route Reflector

• Reflector receives path from clients and

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 27

RRs in a cluster are clients

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 28

• Divide backbone into multiple clusters

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 29

• Where to place the route reflectors?

• Configure one RR at a time

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 30

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 31

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 32

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 33

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 34

1.4.1.1 RRC Router id

Originator: 1.1.1.1 1.0.1.2

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 36

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 37

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 38

• Multiple RRs can be configured in the

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 39

routerB>sh ip bgp 10.0.0.0 RR2 RR1

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 40

• Number of neighbors is reduced

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 41

• Divide the AS into sub-AS

RST-243 © 2002, Cisco Systems, Inc. All rights reserved. 42

• Visible to outside world as single AS—