Configuring BGP wrt Exchange Ponts

 
 i. Intro
 I. Concepts
 A. The Routing table vs. the BGP table
 B. Redistribution
 C. Controlling advertisements either by controlling redistributed
  IGP's, or filtering outbound BGP announcements.
 D. BGP characteristical redistribution
 E. Selection of routes -- weight, local-pref, AS-PATH
 F. CIDR & Aggregation
 1. HowTo
 2. redistribution
II. distribute-lists
III. filter-lists
IV. Pro's and Con's of using filter-lists vs. distribute-lists
 V. Miscellaneous Options
 A. BGP Communities
 B. next-hop-self
VI. Sample configuration
VII. Glossary
 
 
 
 
i. Introduction
 
When participanting in a public exchange point, it is important to be aware
of all the aspects involved in the exchange of routes and that they have
the desired effects on routing. There are a few concepts in higher levels
of the Internet known as peering and transit, and just peering. The
distinction between the two is quite important.
 
When you purchase a T1 from a national provider, you expect to be able to
point a default route at them, and have your routes announced such that
you will have full Internet connectivity despite the fact that you maintain
only a single Internet connection. This is known as transit. Another 
version of this is where you receive full routing tables from this provider,
and you announce your own routes via BGP, which would be more appropriately
referred to as peering and transit.
 
If you were to simply "peer" with another provider, be they national or 
local, your are getting something quite different. First off, the term peer
is used in two ways, the first of which is simply a technical term
referring to a BGP neighbor, or a router you have an established BGP [peering]
session with. Unlike many IGP's which broadcast their routing information, BGP
uses a tcp connection in order to exchange routing information, and each
connection must be explicity configured from both sides. Technically speaking,
a BGP peer refers to the single point where the session is set up, whereas
in a broader sense, it refers to the entirety of both networks being peered, 
as well as a difference in the way the relationship between both companies 
is viewed. Peering only implies that each network has access and permission to
access the other network and their clients. Defaulting to a peer is 
considered impolite, and is technically considered stealing [bandwidth].
 
If the financial impact was not obvious at this point, peering is usually
given for free, where as transit is sold for a fee. Despite the fact that
peering is almost always given away for free, it is many times not in the
best interest of another provider to peer with you. This may be because
the reachability of your network is of little concern to them, and their's
may be of great concern to you. While paying for this privilege is certainly
a possibility, the usual course is to not obtain peering at all. An example
of this relationship would be a typical Mom&Pop ISP attempting to peer with
Sprintlink. This displays an uneven relationship where the smaller network 
is in every position to be a client, and there is no reason why the larger
entity should give away service.
 
The notes below explain configuration of a Cisco router for the purpose of
integrating local peering sessions (local ISP's -- competitors) with a 
transit provider (Sprint, MCI, UUnet, Net99, or other).
 
I. Concepts
 
When dealing with BGP, there are two distinct routing tables that you should
be aware of, the main routing table, and the BGP table. The routing table
consists of the chosen best route to reach a network for any routing protocol,
be that RIP, OSPF, IGRP, static, connected, or BGP derived networks. The
BGP table consists of routes received only via BGP, and may contain several
duplicate ways to reach the same network (henceforth refered to as prefix).
As updates are recieved via BGP, the best route to a prefix may change, and
this change will be reflected in the main routing table. You can analyze the
different routing tables by using the commands 'show ip route' and 'show
ip bgp'.
 
As these tables being logically seperate, it follows that just because the
route is in the main routing table does not mean that it will be in the BGP
table, and hence will not be advertised via BGP. In order for the desired
routes to appear in the BGP table, they must be redistributed into BGP. This
is performed by selecting an IGP to be redistributed. It is not uncommon
to redistribute RIP or OSPF into BGP, however, this is considered quite 
dangerous, as it does not afford a great deal of control. It is much safer
to redistribute static routes, as they must be manually entered into the
router in order to be advertised. Routes from IGP's can be received from
may places, such as customers (though usually on accident). If you make
a typo in your configuration, at the very least you should be able to blame
it on yourself, and not have to make excuses for your clients. This can 
get exceptionally embarrasing, particularly if you were to, say, accidentally
break routing to netscape, or some other equally known or important network, 
for parts of the Internet.
 
Redistribution is done in the router bgp [asn] section of your router 
config, and implemented using the commands 'redistribute static', 'redistribute
rip', or 'redistribute ospf [process number]', for example.
 
If you insist on redistributing an IGP, you will at the very least wish to 
filter your announcements after they have been inserted into the BGP table, 
but before they are advertised to a peer. This can be done by using 
distribute-lists. A distribute-list is comprised of a statement after the
bgp peer statement, such as 'neighbor [neighbor ip address] distribute-list
30 out' where 30 is the number of an access-list which restricts the ranges
of IP addresses that are distributed. Note that just because this list does
not mean that you will announce these ranges of IP addresses, only that you
will *permit* prefix's in this range to be announced. If the prefix is not
in the BGP table it will not be advertised. This may be a result of the prefix
either not being in the routing table or not being redistributed, or both.
Distribute-lists are discussed in more detail in section II.
 
A characteristic of BGP is that all routes received from an external peer (EBGP)
(a neighbor with an Autonomous System Number ('ASN') different than that of
your own) are advertised to other EBGP peers and iBGP peers (a neighbor with
the same ASN, or internal). If you have a distribute-list in place for all
peers, you should be impervious to this behavior, howver, you can also filter
the information received from other peers through the use of a filter-list,
which is discussed in section III.
 
In order to predict how your router will behave when you recieve routes
for the same prefix, there is a complex set of relationships you should 
understand, as well as know a bit about BGP itself.
 
Unlike RIP, which computes a metric or distance based on the number of 
routers the announcement transverses on it's way to get to you, BGP
determines the distance based on number of AS's the prefix passes on it's
way to you. Each AS may contain many router hops. It stores the ASN for each
AS it passes through in the form of an AS-PATH. All else being equal, the
prefix with the shortest AS-PATH will be the preferred route. Naturally, 
the Cisco has many overrides for this behaviour by using weights or 
preferences. These weights or preferences can either be applied to an
entire peer by using a simple statement against the neighbor in the bgp
section, such as 'neighbor [ip address] weight 50', or by matching regular
expressions for paths, and using a route-map, such as 'neighbor [ip address]
route-map ANS-pref in' where the route map would look like
 
route-map ANS-pref permit 10
match as-path 55
set weight 10
 
route-map ANS-pref permit 20
match as-path 100
set weight 5
 
ip as-path access-list 55 permit _690_
ip as-path access-list 100 permit .*
 
For the purposes of a typical NAP configuration, where you are connected
to only a single NAP, weighting should not be necessary, and the shortest
path to your peers will always be prefered given that the AS-PATH will only
contain one hop, and anything heard from anywhere else will contain at least
one additional hop. If this is not the behaviour you are seeing, then you
either have another provider advertising a route they shouldn't, or you have
received the route via an IGP (on accident, presumably). It is generally
a good idea to passive-interface your NAP interface for all IGP's you run,
as you do not particularly care to advertise or receive routes in an 
unmanagable form.
 
Weights, local-preferences, and the use of route-maps is discussed 
extensively in another paper.
 
While CIDR has been around for several years now, it should probably be 
given some background in case you haven't worked with it extensively in
the past. CIDR allows you to take consequetive prefix's (usually Class C's) and
advertise them as a single prefix. The easiest way to "aggregate" a group
of prefix's is to use the aggregate-address command in the bgp section.
A simple 'agg [beginning network address] [supernet mask]' will take care
of it. This probably won't perform as expected, though, because while your
Cisco will announce the aggregate, it will also advertise the more specific
routes as well. In order to fix this, add a "summary-only" switch to the
end of the aggregate-address command.
 
An interesting side affect of adding this command is that you will see this
prefix show up in the BGP table as being routed to Null0, but it may not be
advertised. This is one of a few exceptions where a prefix showing up in BGP
table will not be advertised to it's peers. What is needed is what I refer
to as a way to "kick start" the announcement. You must have a route inside
that CIDR block in your main table, and redistributed into BGP. I typically
take the entire aggregate route, and statically route it to Null0. This has
at least one nice side effect which is that you can guarantee that you will
be announcing this aggregate to all of your peers given that your router and
link to them is still up, regardless of anything happening inside your
network, such as router reloads, down circuits, or IGP screwups. Your
neighbors will appreciate that you do not send them frequent BGP updates,
known as flaps. Frequent flaps can cause your AS to be dampened, but even
worse, flaps have a horrid effect on the Internet, as they chew router CPU,
and can even bring a router to its knees forcing a reload if route-flaps
are received in high enough succession. Statically routing large blocks
of network allocations to Null0 is often referred to as "nailing down" 
announcements.
 
As a side note, if you need help figuring out what the supernet's are for
chunks of IP addresses, the aggis perl script works quite nicely, and 
can be obtained from ftp://ftp.rtd.com/pub/networking/aggis. Its use is 
simple. "aggis -d 205.199.184 8" where 8 specifies the number of networks
you want in the block, and the 205.199.184 is the starting point.
 
 8 Class C nets starting at 205.199.184 can be represented as:
 
 205.199.184/21(255.255.248) ( 8 nets: 205.199.184 - 205.199.191 )
 
To configure this in your router, you would use the line:
 
 agg 205.199.184.0 255.255.248.0 summ
 
and then to nail it down:
 
 ip route 205.199.184.0 255.255.248.0 null0
 
 
NOTE: Please don't try this on your router. I used an RTD block as an 
example. ;-)
 
II. distribute-lists
 
III. filter-lists
 
IV. Pros and Cons for distribute-lists vs. filter-lists.
 
I personally like using a combination of both, however they can be effective
used by themselves. The choice depends a lot on what kind of clients you
typically provide services to. For many ISP's, a distribute-list should
be sufficient, and provide good protection against accidental redistribution.
They do not tend to work well if you have clients that run BGP with you, as
you have to manually update your access-list each time they want to announce
a new network. While this is nice from a security standpoint, they may not
appreciate it a great deal. If you obtain a number of smaller blocks, you
also may find yourself updating frequently, in which case it will get annoying,
particularly when you forget to update your access-list, and spend half the
day debugging the wrong problem.
 
Filter lists can be fairly simple to implement, particularly if you have
no BGP speaking clients, or very few of them. They are safe as long as
you are careful and aware of how your local network impacts your announcements.
 
V. Misc. Options
A. Communities
B. next-hop-self
 
VI. Sample configurations
 
router bgp 101
no sync
aggregate-address 215.199.32.0 255.255.224.0 summary-only
neighbor 198.32.230.10 remote-as 200
neighbor 198.32.230.10 distribute-list 2 out
neighbor 198.32.230.11 remote-as 300
neighbor 198.32.230.11 distribute-list 2 out
redistribute static
 
access-list 2 permit 215.199.32.0 0.0.255.255
 
ip route 215.199.32.0 255.255.224.0 null0
 
 
VII. Glossary
 
aggregate: To combine something, in this case, routing advertisements
AS: Autonomous System. Usually the same network, though many larger networks
 are seperated into several Autonomous Systems, and utilize different
 ASN's.
ASN: Autonomous System Number
BGP: Border Gateway Protocol
CIDR: Classless Inter-Domain Routing
Cisco: If you don't know what a Cisco is, you're reading the wrong tutorial.
iBGP: Internal Peering session
IGP: Internal Gateway Protocol, such as RIP, OSPF, or IGRP (static counts, too)
EBGP: External Peering session
EGP: External Gateway Protocol, such as EGP or BGP.
peer: a bgp configuration that establishes another router that you would
 exchange routes.
prefix: A generic classification referring to a network or group of networks
 that appear as a single network entry.

Viking Home

We are a continual work in process E-mail us describing any problem. Thank you.

Portions copyright © 1996, Viking Services. Last modified May 6, 1996.
All Rights Reserved. Reproduction without permission is strictly prohibited. Other trademarks or are the property of their respective owners.