You are on page 1of 70

Cisco − BGP Case Studies

Cisco − BGP Case Studies

Table of Contents
BGP Case Studies................................................................................................................................................1

BGP Case Studies Section 1...............................................................................................................................2
Introduction..............................................................................................................................................2
How Does BGP Work?...............................................................................................................2
eBGP and iBGP.......................................................................................................................................2
Enabling BGP Routing............................................................................................................................3
Forming BGP Neighbors.........................................................................................................................3
BGP and Loopback Interfaces.................................................................................................................5
eBGP Multihop........................................................................................................................................6
eBGP Multihop (Load Balancing)..............................................................................................6
Route Maps..............................................................................................................................................7
Network Command................................................................................................................................10
Redistribution............................................................................................................................10
Static Routes and Redistribution...............................................................................................12
iBGP.......................................................................................................................................................13
The BGP Decision Algorithm...................................................................................................14

BGP Case Studies Section 2.............................................................................................................................15
As_path Attribute...................................................................................................................................15
Origin Attribute......................................................................................................................................16
BGP Nexthop Attribute.........................................................................................................................17
BGP Nexthop (Multiaccess Networks).....................................................................................18
BGP Nexthop (NBMA)............................................................................................................18
Nexthopself...............................................................................................................................19
BGP Backdoor.......................................................................................................................................19
Synchronization.....................................................................................................................................20
Disabling Synchronization........................................................................................................21
Weight Attribute....................................................................................................................................22
Local Preference Attribute.....................................................................................................................24
Metric Attribute.....................................................................................................................................25
Community Attribute.............................................................................................................................27

BGP Case Studies Section 3.............................................................................................................................29
BGP Filtering.........................................................................................................................................29
Route Filtering..........................................................................................................................29
Path Filtering.............................................................................................................................30
BGP Community Filtering........................................................................................................31
AS−Regular Expression.........................................................................................................................32
BGP Neighbors and Route Maps...........................................................................................................34
Use of set as−path prepend Command.....................................................................................35
BGP Peer Groups......................................................................................................................36

BGP Case Studies Section 4.............................................................................................................................38
CIDR and Aggregate Addresses............................................................................................................38
Aggregate Commands...............................................................................................................39
CIDR Example 1.......................................................................................................................40
CIDR Example 2 (as−set).........................................................................................................41

i

Cisco − BGP Case Studies

Table of Contents
BGP Case Studies Section 4
BGP Confederation................................................................................................................................42
Route Reflectors.....................................................................................................................................44
Multiple RRs within a Cluster..................................................................................................46
RR and Conventional BGP Speakers........................................................................................48
Avoiding Looping of Routing Information..............................................................................49
Route Flap Dampening..........................................................................................................................49
How BGP Selects a Path........................................................................................................................52

BGP Case Studies Section 5.............................................................................................................................53
Practical Design Example......................................................................................................................53

ii

All rights reserved. 2002 Document ID: 17013 Cisco − BGP Case Studies . Updated: May 07.BGP Case Studies This document contains the following BGP case studies: BGP Case Studies Section 1 Introduction eBGP and iBGP Enabling BGP Routing Forming BGP Neighbors BGP and Loopback Interfaces eBGP Multihop Route Maps Network Command iBGP BGP Case Studies Section 2 AS_path Attribute Origin Attribute BGP Nexthop Attribute BGP Backdoor Synchronization Weight Attribute Local Preference Attribute Metric Attribute Community Attribute BGP Case Studies Section 3 BGP Filtering AS−Regular Expression BGP Neighbors and Route Maps BGP Case Studies Section 4 CIDR and Aggregate Addresses BGP Confederation Route Reflectors Route Flap Dampening How BGP Selects a Path BGP Case Studies Section 5 Practical Design Example Go to next section All contents are Copyright © 1992−−2002 Cisco Systems Inc. Important Notices and Privacy Statement.

or neighbors. An AS is a set of routers under a single technical administration. allows you to create loop−free interdomain routing between autonomous systems (AS). The version number changes whenever BGP updates the table due to routing information changes. When BGP is running between routers in the same AS. we call this exterior BGP (eBGP). This is done by a combination of internal BGP (iBGP) peering between routers inside an AS and by redistributing BGP information to Internal Gateway Protocols (IGPs) running in the AS. Two BGP routers form a TCP connection between one another (peer routers) and exchange messages to open and confirm the connection parameters. After this exchange. This information is mainly an indication of the full paths (BGP AS numbers) that a route should take in order to reach the destination network. BGP routers exchange network reachability information. Cisco − BGP Case Studies . Routers in an AS can use multiple interior gateway protocols to exchange routing information inside the AS and an exterior gateway protocol to route packets outside the AS. defined in RFC 1771 .BGP Case Studies Section 1 Introduction eBGP and iBGP Enabling BGP Routing Forming BGP Neighbors BGP and Loopback Interfaces eBGP Multihop Route Maps Network Command iBGP Introduction The Border Gateway Protocol (BGP). BGP peers initially exchange their full BGP routing tables. It is necessary to ensure reachability for networks within an AS before sending the information to external ASs. As you see below. which should be the same for all of its BGP peers. How Does BGP Work? BGP uses TCP as its transport protocol (port 179). it could be used as a transit service for other ASs. eBGP and iBGP If an AS has multiple BGP speakers. AS200 is a transit AS for AS100 and AS300. As far as this paper is concerned. This information helps in constructing a graph of ASs that are loop−free and where routing policies can be applied in order to enforce some restrictions on the routing behavior. we call this iBGP. BGP keeps a version number of the BGP table. incremental updates are sent as the routing table changes. Any two routers that have formed a TCP connection in order to exchange BGP routing information are called peers. when BGP is running between routers belonging to two different ASs. Keepalive packets are sent to ensure that the connection is alive between the BGP peers and notification packets are sent in response to errors or special conditions.

The next step in the configuration process is to define BGP neighbors. which indicates the routers that are trying to talk BGP. the BGP version they're running. Let's assume you want to have two routers. One sure way to verify reachability is an extended ping between the two IP addresses. the routers send open messages in order to exchange values such as the AS number. The ip−address is the next hop directly−connected address for eBGP and any IP address on the other router for iBGP. Use this neighbor command to establish a TCP connection: neighbor ip−address remote−as number The remote−as number is the AS number of the router we're trying to connect to using BGP. The TCP connection is essential in order for the two peer routers to start exchanging routing updates. The extended ping forces the pinging router to use as source the IP address specified in the neighbor command rather than the IP address of the interface the packet is going out from. Any state other than "established" is an indication that the two routers didn't become neighbors. and BGP updates won't be exchanged. We start by defining the router process and the AS number to which the routers belong. RTA and RTB. Use this command to enable BGP on a router: router bgp autonomous−system RTA# router bgp 100 RTB# router bgp 200 The above statements indicate that RTA is running BGP and it belongs to AS100 and RTB is running BGP and it belongs to AS200. It's essential that the two IP addresses used in the neighbor command of the peer routers be able to reach one another. Cisco − BGP Case Studies . talk BGP. In the first example RTA and RTB are in different ASs and in the second example both routers belong to the same AS. After these values are confirmed and accepted the neighbor connection is established. Forming BGP Neighbors Two BGP routers become neighbors once they establish a TCP connection between each other.Enabling BGP Routing Use these steps to enable and configure BGP. the BGP router ID and the keepalive hold time. Once the TCP connection is up.

any time new information comes in. the remote router ID (highest IP address on the router or the highest loopback interface in case it exists) and the table version (this is the state of the table.1.1 remote−as 200 In the above example RTA and RTB are running eBGP. as long as there is some IGP running that allows the two neighbors to reach one another.1.213. Also.1 remote−as 200 RTB# router bgp 200 neighbor 129.1.220. clear ip bgp address (where address is the neighbor address) clear ip bgp * (clear all neighbor connections) By default. You should also note the BGP version is 4.213. Pay special attention to the BGP state. the table increases the version and a version that keeps incrementing indicates that some route is flapping causing routes to continuously be updated).2 remote−as 100 neighbor 175. perform the following task in router configuration mode: neighbor {ip address|peer−group−name}version value An example of the neighbor command configuration follows: RTA# router bgp 100 neighbor 129. iBGP routers don't have to be directly connected. BGP sessions begin using BGP version 4 and negotiating downward to earlier versions if necessary.It is important to reset the neighbor connection in case any BGP configuration changes are made in order for the new parameters to take effect. To prevent negotiations and force the BGP version used to communicate with a neighbor.2 remote−as 200 RTC# router bgp 200 neighbor 175. since anything other than state "established" indicates the peers aren't up. Cisco − BGP Case Studies . The difference between eBGP and iBGP is manifested by having the remote−as number pointing to either an external or an internal AS. RTB and RTC are running iBGP.212.220. The following is an example of the information that the show ip bgp neighbors command displays. the eBGP peers are directly connected while the iBGP peers are not.

Normally the loopback interface is used to make sure the IP address of the neighbor stays up and is independent of hardware functioning properly. RTA does this by adding the update−source int loopback configuration (neighbor 190.11. peer routers are frequently directly connected and loopback doesn't apply. If you use the IP address of a loopback interface in the neighbor command.225.11.225. remote AS 200.1.1 remote−as 100 In the above example.1 remote−as 100 neighbor 190.225. external link BGP version 4. Note that RTA has used the physical interface IP address (190.11. hold time is 180. RTA and RTB are running iBGP inside AS 100. which is why RTB doesn't need any special configuration.1 BGP state = Established.225.1). 0 notifications.225.1. up for 0:10:59 Last read 0:00:29.1 update−source loopback 1) and this statement forces BGP to use the IP address of its loopback interface when talking to neighbor 190. 0 in queue Sent 2826 messages.220. in this case RTA has to force BGP to use the loopback IP address as the source in the TCP neighbor connection. RTA# router bgp 100 neighbor 190. 0 notifications. 0 in queue Connections established 11. The command used to indicate a loopback interface is: neighbor ip−address update−source interface The following example illustrates the use of this command. remote router ID 175. #show ip bgp neighbors BGP neighbor is 129.1 update−source loopback 1 RTB# router bgp 100 neighbor 150. The neighbor router needs to tell BGP it's using a loopback interface rather than a physical interface to initiate the BGP neighbor TCP connection.1. dropped 10 BGP and Loopback Interfaces Using a loopback interface to define neighbors is common with iBGP.1. table version = 3.213.11. you need some extra configuration on the neighbor router.11.212. RTB is using in its neighbor command the loopback interface of RTA (150. but not with eBGP. In the case of eBGP.212. keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 2828 messages.1.1) of RTB as a neighbor. Cisco − BGP Case Studies .12.

11.255.0 1.0 ip route 160.2 RTB# Cisco − BGP Case Studies .2 ip route 160. you can use eBGP multihop. which allows the neighbor connection to be established between two non−directly−connected external peers. The multihop is used only for eBGP and not for iBGP. RTB is indicating a neighbor that is directly connected (129.11. RTA needs to indicate that it's using ebgp−multihop.1 255.1 update−source loopback 0 network 150.0 2.0. The following example illustrates of eBGP multihop. To achieve this. eBGP Multihop (Load Balancing) RTA# int loopback 0 ip address 150.10.0 255.1.2.1.1. a Cisco router can run eBGP with a third party router that doesn't allow the two external peers to be directly connected.0.1 ebgp−multihop neighbor 160.1.2 remote−as 100 RTA is indicating an external neighbor that isn't directly connected.0. On the other hand.225.1.10.10.10.1. RTA# router bgp 100 neighbor 180.213.0 255.0.2).10.eBGP Multihop In some cases.255.255. which is why it doesn't need the ebgp−multihop command.10. The following example shows how to achieve load balancing with BGP in a particular case where we have eBGP over parallel lines.213. You should also configure an IGP or static routing to allow the non−connected neighbors to reach each other.1.255.0.225.1 remote−as 300 neighbor 180.1.1 remote−as 200 neighbor 160.10.0 router bgp 100 neighbor 160.2.1 ebgp−multihop RTB# router bgp 300 neighbor 129.

10. Route Maps At this point I would like to introduce route maps because they will be used heavily with BGP.1.1 set metric 5 Cisco − BGP Case Studies . For example.1. and the second will have a sequence number of 20. The above can be illustrated by the following commands: match ip address 1.10.1. We use static routes (we could also use an IGP) to introduce two equal cost paths to reach the destination.255.2. In normal situations. If the first set of conditions is not met then we proceed to a higher instance of the route map.0 255.1.1 then the metric for that update will be set to 5.255. int loopback 0 ip address 160.255.0 ip route 150.2 and the other one via 2.1. the first set of conditions will be applied via instance 10. BGP picks one of the lines to send packets on.2.1.0 255. the next hop for eBGP is the loopback interface.0.0. and the same for RTB.0 1. route−map MYMAP permit 10 (first set of conditions goes here.0 router bgp 200 neighbor 150.1 255.1 ebgp−multihop network 160.1. The format of the route map follows: route−map map−tag [[permit | deny] | [sequence−number]] The map−tag is just a name you give to the route−map.10.) When applying route map MYMAP to incoming or outgoing routes. By introducing loopback interfaces.1.1.) route−map MYMAP permit 20 (second set of conditions goes here.2.1: one via 1. and load balancing wouldn't happen. The sequence number is just an indication of the position a new route map is to have in the list of route maps already configured with the same name.1. For example.1 The above example illustrates the use of loopback interfaces.0.0.2. update−source and ebgp−multihop.255.10. if I define two instances of the route map.10. route map is a method used to control and modify routing information.1 update−source loopback 0 neighbor 150. match and set configuration commands. RTA has two choices to reach next hop 160.1. Multiple instances of the same route map (same name−tag) can be defined.0 2. In the BGP context.10.1 ip route 150. let us call it MYMAP. I could define a route map that checks outgoing updates and if there is a match for IP address 1. Each route map will consist of a list of match and set configuration.2.1 remote−as 100 neighbor 150. This is a workaround in order to achieve load balancing between two eBGP speakers over parallel serial lines.1. This is done by defining conditions for redistributing routes from one routing protocol to another or controlling routing information when injected in and out of BGP.0. The match will specify a match criteria and set specifies a set action if the criteria enforced by the match command are met.1. the first instance will have a sequence−number of 10.10.10.

If the match criteria are met and we have a deny then the route will not be redistributed or controlled and we break out of the list. rather redistributing between protocols.Now. The related commands for match are: match as−path match community match clns match interface match ip address match ip next−hop match ip route−source match metric match route−type match tag The related commands for set are: set as−path set clns set automatic−tag set community set interface set default interface set ip default next−hop set level set local−preference set metric set metric−type set next−hop set origin set tag set weight Let's look at some route−map examples: Cisco − BGP Case Studies . This restriction is lifted in Cisco IOS Software Release 11. when you use route maps for filtering BGP updates (as we will see later). If the match criteria are not met and we have a permit or deny then the next instance of the route map (instance 20 for example) will be checked.2. you cannot filter on the inbound when using a match command on the IP address. and so on until we either break out or finish all the instances of the route map. In Cisco IOS® software releases earlier than 11. If we finish the list without a match then the route we are looking at will not be accepted nor forwarded. if the match criteria are met and we have a permit then the routes will be redistributed or controlled as specified by the set action and we break out of the list.2 and later. Filtering on the outbound is acceptable.

RTA and RTC are running BGP.0.255 In the above example if a route matches the IP address 170.0 passive−interface Serial0 redistribute bgp 100 route−map SETMETRIC router bgp 100 neighbor 2.0.0 it will have a metric of 2 and then we break out of the route map list. Since route maps cannot be applied on the inbound when matching based on an ip address.0.0. we have to use an outbound route map on RTC: RTC# router bgp 300 network 170. If RTA wants to redistribute to RTB routes about 170. It is always very important to ask the question.0. If there is no match then we go down the route map list which says. Example 2: Suppose in the above example we did not want AS100 to accept updates about 170. set everything else to metric 5.0 route−map SETMETRIC permit 10 match ip−address 1 set metric 2 route−map SETMETRIC permit 20 set metric 5 access−list 1 permit 170.0 network 150.0. what will happen to routes that do not match any of the match statements because they will be dropped by default.10.10.10. RTA is getting updates via BGP and redistributing them to rip.2.0.2.0 Cisco − BGP Case Studies .0 0.0.Example 1: Assume RTA and RTB are running rip.0.0 network 2.0.10.0.10.0 with a metric of 2 and all other routes with a metric of 5 then we might use the following configuration: RTA# router rip network 3.3 remote−as 300 network 150.10.0.0.255.10.

220. let's look at how to start exchanging network information.2 remote−as 100 neighbor 2. EIGRP. Note that we need the static route to get the router to generate 192.0.2.0 mask 255.213. RTA is announcing 129. The mask portion is used because BGP version 4 (BGP4) can handle subnetting and supernetting. some of these routes might have been learned via BGP and you do not need to send them out again. neighbor 2. rather we are trying to indicate to BGP what networks it should originate from this box.0 ip route 192. A maximum of 200 entries of the network command are accepted.0 because the static route will put a matching entry in the routing table.255 access−list 1 permit 0. RIP.0.2.) into BGP. The /16 indicates that we are using a supernet of the class C address and we are advertizing the first two octets (the first 16 bits).0.0.10.213.0/16. etc.255.255.0 null 0 The above example indicates that router A.0.1. Careful filtering should be applied to make sure you are sending to the internet only routes that you want to advertise and not everything you have. static or learned dynamically. An example of the network command follows: RTA# router bgp 1 network 192.0 255. will generate a network entry for 192. Redistribution The network command is one way to advertise your networks via BGP.213. This is a different concept from what you are used to configuring with IGRP and RIP.0. The network command will work if the network you are trying to advertise is known to the router.0. OSPF.255.0. Look at RTC's configuration: Cisco − BGP Case Studies .0. Network Command The format of the network command follows: network network−number [mask network−mask] The network command controls what networks are originated by this box.213. I will go through these methods one by one.255 Now that you feel more comfortable with how to start BGP and how to define a neighbor. This sounds scary because now you are dumping all of your internal routes into BGP.0.2.0. Let us look at the example below. There are multiple ways to send network information using BGP.0 255.255.255.0.2 route−map STOPUPDATES out route−map STOPUPDATES permit 10 match ip address 1 access−list 1 deny 170. With this command we are not trying to run BGP on a certain interface. whether connected. Another way is to redistribute your IGP (IGRP.213.0 and RTC is announcing 175.2.0 0.

0 but AS100 is.213.1 remote−as 300 neighbor 1.0 again into BGP) This will cause 129.0 redistribute bgp 200 default−metric 1000 100 250 100 1500 router bgp 200 neighbor 1.1.1.0 to be originated by your AS.If you use a network command you will have: RTC# router eigrp 10 network 175. Cisco − BGP Case Studies .255.0 0.0) If you use redistribution instead you will have: RTC# router eigrp 10 network 175. The correct configuration would be: RTC# router eigrp 10 network 175.0.1.0.220.0.1.0.1 distribute−list 1 out redistribute eigrp 10 access−list 1 permit 175.220.0 redistribute bgp 200 default−metric 1000 100 250 100 1500 router bgp 200 neighbor 1.220.255 The access−list is used to control what networks are to be originated from AS200. So you would have to use filters to prevent that network from being sourced out by your AS.1 remote−as 300 network 175.1.220.213.0.1.0 mask 255.0. This is misleading because you are not the source of 129.220.1.1.1 remote−as 300 redistribute eigrp 10 (eigrp will inject 129.255.0 redistribute bgp 200 default−metric 1000 100 250 100 1500 router bgp 200 neighbor 1.0 (this will limit the networks originated by your AS to 175.0.1.1.220.0.213.1.

2 remote−as 300 Cisco − BGP Case Studies .20. The only difference is that BGP will consider these routes as having an origin of incomplete (unknown)..20.10.220. Please remember that these routes are generated in addition to other BGP routes that BGP has learned via neighbors (internal or external).255. We have discussed how we can use different methods to originate routes out of our autonomous system.2 remote−as 300 network 150.. So if I get the packet and there is a more specific match than 175.Static Routes and Redistribution You could always use static routes to originate a network or a subnet. In the above example the same could have been accomplished by doing: RTC# router eigrp 10 network 175.1. Injecting BGP into IGP is always done by redistribution.. The null 0 interface means disregard the packet.0. will indicate your AS as the origin for these networks. This is a nice way to advertise a supernet.0 255.0.0 redistribute bgp 200 default−metric 1000 100 250 100 1500 router bgp 200 neighbor 1.1.10.0. ip route 175.1 remote−as 300 redistribute static . or redistribution or static.10.0 (which exists of course) the router will send it to the specific match otherwise it will disregard it. Example: RTA# router bgp 100 neighbor 150.255. The difference is that routes generated by the network command. BGP passes on information that it learns from one peer to other peers.220.220..0 RTB# router bgp 200 neighbor 160..0.0 null0 .

50.0. why can't we do the same thing by learning via eBGP redistributing into IGP and then redistributing again into another AS? We can. Again the difference is that the network command will add an extra advertisement for these same networks indicating that AS300 is also an origin for these routes.0 to AS100 with origin still AS100.00 Note that you do not need network 150.0 or network 160.1 remote−as 100 neighbor 170. RTB will pass 150.10. but iBGP offers more flexibility and more efficient ways to exchange information within an AS.10.0. RTA will generate a route 150.0.20.20.10.1 remote−as 100 neighbor 160. RTA# router bgp 100 neighbor 190.10.0.10.0 RTC# router bgp 300 neighbor 150.0 and will send it to AS300 then RTC will pass this route to AS200 with the origin kept as AS100.2 remote−as 300 network 150.0 RTB# router bgp 100 Cisco − BGP Case Studies .0 in RTC unless you want RTC to also generate these networks on top of passing them on as they come in from AS100 and AS200.1 remote−as 200 network 170.20.0. assume AS200 above had a direct BGP connection into AS100. network 160.10.10. iBGP iBGP is used if an AS wants to act as a transit system to other ASs.10. for example iBGP provides us with ways to control what is the best exit point out of the AS by using local preference (will be discussed later). This is to insure a loop free interdomain topology. RTA will notice that the update has originated from its own AS and will ignore it. For example. You might ask. An important point to remember is that BGP will not accept updates that have originated from its own AS.10.10.0.10.

is that when a BGP speaker receives an update from other BGP speakers in its own AS (IBGP).. administrative weights.0 Note: An important point to remember.50. Return to table of contents Go to next section Cisco Systems TAC Certified Learn more about Cisco TAC Certification. The BGP updates coming from RTB to RTA will be sent to RTE (outside of the AS) but not to RTD (inside of the AS).0 RTC# router bgp 400 neighbor 175. local preference. metric and so on. such as next hop. Updated: May 07. The receiving BGP speaker will redistribute that information to other BGP speakers outside of its AS. the receiving BGP speaker will not redistribute that information to other BGP speakers in its own AS. All rights reserved.10.40. In the following section I will try to explain these attributes and show how they are used.30.2 remote−as 100 network 175..40.10. the protocol will have to decide which paths to choose in order to reach a specific destination.1 remote−as 100 neighbor 175.1 remote−as 400 network 190. We will start with the path attribute. 2002 Document ID: 17013 Cisco − BGP Case Studies . All contents are Copyright © 1992−−2002 Cisco Systems Inc. The decision process is based on different attributes. BGP will always propagate the best path to its neighbors. BGP will choose only a single path to reach a specific destination. That is why it is important to sustain a full mesh between the IBGP speakers within an AS. neighbor 150. In the above diagram. Important Notices and Privacy Statement.0. RTA and RTB are running iBGP and RTA and RTD are running iBGP also. The BGP Decision Algorithm After BGP receives updates about different destinations from different autonomous systems.10. the route origin.10. path length. origin code. This is why an iBGP peering should be made between RTB and RTD in order not to break the flow of the updates.10.

BGP Case Studies Section 2

AS_path Attribute
Origin Attribute
BGP Nexthop Attribute
BGP Backdoor
Synchronization
Weight Attribute
Local Preference Attribute
Metric Attribute
Community Attribute

As_path Attribute

Whenever a route update passes through an AS, the AS number is prepended to that update. The AS_path
attribute is actually the list of AS numbers that a route has traversed in order to reach a destination. An
AS−SET is an ordered mathematical set {} of all the ASs that have been traversed. An example of AS−SET is
given later.

In the above example, network 190.10.0.0 is advertised by RTB in AS200, when that route traverses AS300
and RTC will append its own AS number to it. So when 190.10.0.0 reaches RTA it will have two AS numbers
attached to it: first 200 then 300. So as far as RTA is concerned the path to reach 190.10.0.0 is (300,200).

The same applies for 170.10.0.0 and 180.10.0.0. RTB will have to take path (300,100) i.e. traverse AS300 and
then AS100 in order to reach 170.10.0.0. RTC will have to traverse path (200) in order to reach 190.10.0.0
and path (100) in order to reach 170.10.0.0.

Cisco − BGP Case Studies

Origin Attribute
The origin is a mandatory attribute that defines the origin of the path information. The origin attribute can
assume three values:

IGP: Network Layer Reachability Information (NLRI) is interior to the originating AS. This normally happens
when we use the bgp network command or when IGP is redistributed into BGP, then the origin of the path
info will be IGP. This is indicated with an "i" in the BGP table.

EGP: NLRI is learned via EGP (Exterior Gateway Protocol). This is
indicated with an "e" in the BGP table.

INCOMPLETE: NLRI is unknown or learned via some other means. This usually occurs when we redistribute
a static route into BGP and the origin of the route will be incomplete. This is indicated with an "?" in the BGP
table.

RTA#
router bgp 100
neighbor 190.10.50.1 remote−as 100
neighbor 170.10.20.2 remote−as 300
network 150.10.0.0
redistribute static

ip route 190.10.0.0 255.255.0.0 null0

RTB#
router bgp 100
neighbor 150.10.30.1 remote−as 100
network 190.10.50.0

RTE#
router bgp 300
neighbor 170.10.20.1 remote−as 100
network 170.10.0.0

RTA will reach 170.10.0.0 via: 300 i (which means the next AS path is 300 and the origin of the route is IGP).
RTA will also reach 190.10.50.0 via: i (which means, the entry is in the same AS and the origin is IGP).

Cisco − BGP Case Studies

RTE will reach 150.10.0.0 via: 100 i (the next AS is 100 and the origin is IGP).
RTE will also reach 190.10.0.0 via: 100 ? (the next AS is 100 and the
origin is incomplete "?", coming from a static route).

BGP Nexthop Attribute

The BGP nexthop attribute is the next hop IP address that is going to be used to reach a certain destination.

For EBGP, the next hop is always the IP address of the neighbor specified in the neighbor command. In the
above example, RTC will advertise 170.10.0.0 to RTA with a next hop of 170.10.20.2 and RTA will advertise
150.10.0.0 to RTC with a next hop of 170.10.20.1. For IBGP, the protocol states that the next hop advertised
by EBGP should be carried into IBGP. Because of that rule, RTA will advertise 170.10.0.0 to its IBGP peer
RTB with a next hop of 170.10.20.2. So according to RTB, the next hop to reach 170.10.0.0 is 170.10.20.2
and not 150.10.30.1.

You should make sure that RTB can reach 170.10.20.2 via IGP, otherwise RTB will drop packets destined to
170.10.0.0 because the next hop address would be inaccessible. For example, if RTB is running IGRP you
could also run igrp on RTA network 170.10.0.0. You would want to make IGRP passive on the link to RTC
so BGP is only exchanged.

RTA#
router bgp 100
neighbor 170.10.20.2 remote−as 300
neighbor 150.10.50.1 remote−as 100
network 150.10.0.0

RTB#
router bgp 100
neighbor 150.10.30.1 remote−as 100

RTC#
router bgp 300
neighbor 170.10.20.1 remote−as 100
network 170.10.0.0

*RTC will advertise 170.10.0.0 to RTA with a NextHop 170.10.20.2
*RTA will advertise 170.10.0.0 to RTB with a NextHop= 170.10.20.2
(The external NextHop via EBGP is sent via IBGP)

Cisco − BGP Case Studies

*RTC will advertise 180. but NBMA (Non Broadcast Media Access) then further complications will occur.10.3 and not its own IP address (170.Special care should be taken when dealing with multiaccess and NBMA networks as described in the following sections.0 via 170.20. RTC is running BGP with RTA. This is because the network between RTA.3.0 to RTA with a NextHop 170.2).20. When RTC sends a BGP update to RTA regarding 180.3.20.0 it will use as next hop 170. If the common media to RTA.10. RTC and RTD was not multiaccess.20.0. BGP Nexthop (NBMA) If the common media as you see in the shaded area above is a frame relay or any NBMA cloud then the exact Cisco − BGP Case Studies . RTC can reach network 180. Assume that RTC and RTD in AS300 are running OSPF. RTC and RTD is a multiaccess network and it makes more sense for RTA to use RTD as a next hop to reach 180.20. BGP Nexthop (Multiaccess Networks) The following example shows how the nexthop will behave on a multiaccess network such as ethernet.0.20.0 rather than making an extra hop via RTC.20.10.20.0.0.10.

EBGP updates have a distance of 20 which is lower than the IGP distances. In order to remedy this situation a command called NextHopself is created.1 next−hop−self RTC advertises 180. RTA and RTB are running some kind of IGP (RIP.10.1 remote−as 100 neighbor 170.20.20.20. RTA and RTC are running EBGP.0. In the previous example.0.0. Nexthopself Because of certain situations with the nexthop as we saw in the previous example. The syntax is: neighbor {ip−address|peer−group−name} next−hop−self The next−hop−self command allows us to force BGP to use a specified IP address as the next hop rather than letting the protocol choose the next hop. and cannot reach the next hop.10. etc.3. the following configuration solves our problem: RTC# router bgp 300 neighbor 170. and RTB and RTC are running EBGP.0 to RTA with a next hop of 170.20.2 BGP Backdoor Consider the above diagram. RTC will advertise 180.10. In this case routing will fail. 100 for IGRP. Default distance is 120 for RIP. RTA will receive updates about 160.0 via two routing protocols: Cisco − BGP Case Studies . IGRP.10. a command called next−hop−self is created.0 with a NextHop = 170. 90 for EIGRP and 110 for OSPF.).10. The problem is that RTA does not have a direct PVC to RTD.behavior will occur as if we were connected via ethernet.20. By definition.20.

0 via RTB (IGP). BGP has the following distances. • Use BGP backdoor.10. but is not advertised as a normal network entry. and also learns it from RTC via EBGP with distance 20.10. which is not recommended. If we want RTA to learn about 160. Synchronization Cisco − BGP Case Studies . BGP backdoor makes the IGP route the preferred route. but that could be changed by the distance command: distance bgp external−distance internal−distance local−distance external−distance:20 internal−distance:200 local−distance:200 RTA will pick EBGP via RTC because of the lower distance.0 backdoor Network 160.2. then we have two options: • Change EBGP's external distance or IGP's distance.0.0.10.1 remote−as 300 network 160.0 is treated as a local entry.10.0. For BGP this network will be treated as a locally assigned network except it will not be advertised in BGP updates. Use the following network address backdoor command.0.0 router bgp 100 neighbor 2. RTA# router eigrp 10 network 160. RTA learns 160. By default.0 from RTB via EIGRP with distance 90.2. The configured network is the network that we would like to reach via IGP.10.EBGP with a distance of 20 and IGP with a distance higher than 20.0. but because of the backdoor command EIGRP is preferred. Normally EBGP is preferred.

0 into IGP. so RTB will get the update and will be able to reach 170. RTA and RTB are running IBGP. you can disable synchronization. RTB will have to send the traffic to RTE. or if all routers in your AS will be running BGP. and your router will be waiting forever for an IGP update about a certain route before sending it to external peers.10.10.10.0. the router has no way of knowing that. RTC in AS300 is sending updates about 170.2.10. RTB will wait to hear about 170. You have to disable synchronization manually in this case for routing to work correctly: router bgp 100 no synchronization Cisco − BGP Case Studies .0. Disabling synchronization is not automatic. We can fool RTB into thinking that IGP has propagated the information by adding a static route in RTB pointing to 170.Before we discuss synchronization let us look at the following scenario.10. In the above example. In order to reach the next hop.2.0. if you have all your routers in the AS running BGP and you are not running any IGP.0. If RTB starts advertising to AS400 that he can reach 170.1 (remember that the next hop is carried via IBGP). If you will not be passing traffic from a different autonomous system through your AS.0. BGP will wait until IGP has propagated the route within the AS and then will advertise it to external peers.0 via next hop 2.0 via IGP before it starts sending the update to RTD. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly. BGP should not advertise a route before all routers in your AS have learned about the route via IGP.10.10.0.0 then traffic coming from RTD to RTB with destination 170.0 will flow in and get dropped at RTE. Synchronization states: If your autonomous system is passing traffic from another AS to a third AS.0 even exists.10.10. so at this point RTE has no idea that 170. This is called synchronization. Disabling Synchronization In some cases you do not need synchronization.0. Care should be taken to make sure that other routers can reach 170.0.0. Assume that RTA has not redistributed network 170.0.0.0 otherwise we will have a problem reaching that network.

1.1.4 remote−as 100 Weight Attribute Cisco − BGP Case Studies .0.0.3.3.0 neighbor 3.3.1.1.) RTB# router bgp 100 network 150.10.10.0.1 remote−as 100 network 175.10.3.0 in its IP routing table and advertises it to !−− RTD even if it does not have an IGP path to 170.0 RTA# router bgp 100 network 150.0.3 remote−as 100 no synchronization !−− RTB puts 170.(Make sure you do a clear ip bgp address to reset the session.2 remote−as 400 neighbor 3.10.0 neighbor 1.0) RTD# router bgp 400 neighbor 1.0.10.

1.2.2.. It is a value that only makes sense to the specific router and which is not propagated or carried through any of the route updates. The same outcome as above can be achieved by using routemaps.2 remote−as 200 neighbor 2..0. • Using AS path access−lists: ip as−path access−list access−list−number {permit|deny} as−regular−expression neighbor ip−address filter−list access−list−number weight weight.0.2 remote−as 200 neighbor 2. The same outcome can be achieved using IP as−path and filter lists.0 and has to decide which way to go. RTB has also learned about network 175.2 route−map setweightin in .1. RTA has learned about network 175.2 weight 100 !−− route to 175.1.0.0 from AS4 and will propagate it to RTC. ip as−path access−list 5 permit ^100$ . RTA is preferred as the next hop.1 route−map setweightin in neighbor 2.0.2. • Using route−maps.0.0 from RTA has 200 weight neighbor 2..2.1.10.2.1 remote−as 100 neighbor 1.2.1.2.2..10.The weight attribute is a Cisco defined attribute.1 weight 200 !−− route to 175.2 filter−list 6 weight 100 .1 remote−as 100 neighbor 1. then we will force RTC to use RTA as a next hop to reach 175.2. The weight is used for a best path selection process.1 filter−list 5 weight 200 neighbor 2.1 remote−as 100 neighbor 1.. RTC# router bgp 300 neighbor 1..10. The weight is assigned locally to the router. ip as−path access−list 5 permit ^100$ !−− this only permits path 100 ip as−path access−list 6 permit ^200$ . RTC# router bgp 300 neighbor 1.2.1.10.1.1.0. A weight can be a number from 0 to 65535..1. RTC has now two ways for reaching 175. If on RTC we can set the weight of the updates coming from RTA to be higher than the weight of updates coming from RTB. Paths that the router originates have a weight of 32768 by default and other paths have a weight of zero. Let us study the above example.1.2. RTC# router bgp 300 neighbor 1.10. Routes with a higher weight are preferred when multiple routes exist to the same destination. route−map setweightin permit 10 Cisco − BGP Case Studies .0 from AS4 and will propagate the update to RTC..1. This is achieved by using multiple methods: • Using the neighbor command: neighbor {ip−address|peer−group} weight weight.2 remote−as 200 neighbor 2.10.0 from RTB will have 100 weight Routes with higher weight are preferred when multiple routes exist to the same destination.2.0.1.

11.0. Local preference will help us determine which way to exit AS256 in order to reach that network. RTC# router bgp 256 neighbor 1.10. match as−path 5 set weight 200 !−− anything that applies to access−list 5. In the above diagram. A path with a higher local preference is more preferred. have weight 200 route−map setweightin permit 20 set weight 100 !−− anything else would have weight 100 Local Preference Attribute Local preference is an indication to the AS about which path is preferred to exit the AS in order to reach a certain network.1.0 from two different sides of the organization.2 remote−as 256 bgp default local−preference 150 RTD# router bgp 256 neighbor 3.1 remote−as 256 bgp default local−preference 200 Cisco − BGP Case Studies .4 remote−as 300 neighbor 128. The default value for local preference is 100. The following configuration will set the local preference for updates coming from AS300 to 200 and those coming from AS100 to 150.11.3. local preference is an attribute that is exchanged among routers in the same AS.3. such as packets from AS100. Local preference is set via the bgp default local−preference < value> command or with route−maps as will be demonstrated in the following example: The bgp default local−preference command will set the local preference on the updates out of the router going to peers in the same AS.213.213. AS256 is receiving updates about 170.1.1 remote−as 100 neighbor 128. Let us assume that RTD is the preferred exit point. Unlike the weight attribute which is only relevant to the local router.

route−map setlocalin permit 10 match as−path 7 set local−preference 200 route−map setlocalin permit 20 set local−preference 150 With this configuration. The same RTD will set the local preference of all updates to 200.0 has a higher local preference when coming from AS300 rather than when coming from AS100.. In the above example. ip as−path access−list 7 permit ^300$ . Metric Attribute The metric attribute which is also called Multi_exit_discriminator.4 remote−as 300 neighbor 3.10. This is a dynamic way to influence another AS on which way to choose in order to reach a certain route given that we have multiple entry points into that AS.3.213. All traffic in AS256 addressed to that network will be sent to RTD as an exit point. MED (BGP4) or Inter−As (BGP3) is a hint to external neighbors about the preferred path into an AS.In the above configuration RTC will set the local preference of all updates to 150.3. any update coming from AS300 will be set with a local preference of 200.3.1 remote−as 256 . both RTC and RTD will realize that network 170. This means that updates coming from AS34 will also be tagged with the local preference of 200. This is why we can use route maps to specify what specific updates need to be tagged with a specific local preference as shown below: RTD# router bgp 256 neighbor 3. Any other updates such as those coming from AS34 will be set with a value of 150. Cisco − BGP Case Studies .. This might not be needed.0. all updates received by RTD will be tagged with local preference 200 when they reach RTD..4 route−map setlocalin in neighbor 128.. More flexibility is provided by using route maps. Since local preference is exchanged within AS256.3..11. A lower value of a metric is more preferred.

1 remote−as 300 route−map setmetricout permit 10 set metric 200 RTB# router bgp 400 neighbor 4. Assume that we have set the metric coming from RTC to 120. the metric coming from RTD to 200 and the metric coming from RTB to 50. considering all other attributes are the same.2.2 route−map setmetricout out neighbor 1.. When RTA gets an update from RTB with metric 50.4.0.3.3.2 remote−as 100 neighbor 3.2. RTD and RTB. he can not compare it to 120 because RTC and RTB are in different ASs (RTA has to choose based on some other attributes).0 via three different routers: RTC. we have to configure RTA as follows: Cisco − BGP Case Studies . RTC and RTD are in AS300 and RTB is in AS400. RTA will pick RTC as next hop.1.1 remote−as 300 neighbor 3.4. that metric will be set back to 0 as shown in the above diagram. Unless otherwise specified. When the same update is passed on to a third AS.1.4 route−map setmetricout out route−map setmetricout permit 10 set metric 50 With the above configs. RTC# router bgp 300 neighbor 2.2.3.2.2 remote−as 100 neighbor 2. In order for the router to compare metrics from neighbors coming from different ASs the special configuration command "bgp always−compare−med" should be configured on the router. AS100 is getting information about network 180.1. Given that by default a router compares metrics coming from neighbors in the same AS.3 remote−as 300 neighbor 4.3.2 remote−as 300 route−map setmetricout permit 10 set metric 120 RTD# router bgp 300 neighbor 3. metric is exchanged between ASs. The Metric default value is 0.2 route−map setmetricout out neighbor 1.1.Unlike local preference.3.3.3 remote−as 400 .4. In order to force RTA to compare the metrics we have to add bgp always−compare−med to RTA.2.4.10.2.4 remote−as 100 neighbor 4.4. This is illustrated in the configs below: RTA# router bgp 100 neighbor 2. A metric is carried into an AS but does not leave the AS. In order to have RTB included in the metric comparison. that metric is used for decision making inside the AS. RTA can only compare the metric coming from RTC to the metric coming from RTD and will pick RTC as the best next hop because 120 is less than 200. When an update enters the AS with a certain metric... a router will compare metrics for paths from neighbors in the same AS.4. In the above diagram.

294. The community attribute is a way to group destinations in a certain community and apply routing decisions (accept. redistribute.3.4.10.) according to those communities.3. The route map set command has the following syntax: set community community−number [additive] A few predefined well known communities (community−number) are: • no−export (Do not advertise to EBGP peers) • no−advertise (Do not advertise this route to any peer) • internet (Advertise this route to the internet community.0 with a metric of 50 Community Attribute The community attribute is a transitive. Metric can also be set while redistributing routes into BGP using the default−metric number command. optional attribute in the range 0 to 4. this attribute is not sent to neighbors by default.21 remote−as 300 neighbor 3.10.3 remote−as 400 bgp always−compare−med In this case RTA will pick RTB as the best next hop in order to reach network 180.3 remote−as 300 neighbor 4. We can use route maps to set the community attributes. RTA# router bgp 100 neighbor 2.255. Even if we set the community attribute.0.0. if we use the keyword additive then the 200 is added to the community.200.0 null 0 !−− Causes RTB to send out 180. Assume in the above example that RTB is injecting a network via static into AS100 then the following configs: RTB# router bgp 400 redistribute static default−metric 50 ip route 180. In order to send the attribute to our neighbor we have to use the following: Cisco − BGP Case Studies .2.4.967.0.0 255. 200 replaces any old community that already exits. prefer.0.10. etc. any router belongs to it) An example of route maps where community is set is: route−map communitymap match ip address 1 set community no−advertise or route−map setcommunity match as−path 1 set community 200 additive If the additive keyword is not set.0.

3...3 remote−as 300 neighbor 3.3. Updated: May 07.3 route−map setcommunity out Go to previous section Return to table of contents Go to next section Cisco Systems TAC Certified Learn more about Cisco TAC Certification. All rights reserved. 2002 Document ID: 17013 Cisco − BGP Case Studies .3.3. neighbor {ip−address|peer−group−name} send−community Here's an example: RTA# router bgp 100 neighbor 3. All contents are Copyright © 1992−−2002 Cisco Systems Inc.3.3.3 send−community neighbor 3. Important Notices and Privacy Statement.

0 and sending it to RTC. Use the following command in the router configuration mode: neighbor {ip−address|peer−group−name} distribute−list access−list−number {in|out} In the following example. on path information or on communities.0 neighbor 3. choosing one over the other depends on the specific network configuration.10.BGP Case Studies Section 3 BGP Filtering AS−Regular Expression BGP Neighbors and Route Maps BGP Filtering Sending and receiving BGP updates can be controlled by using a number of different filtering methods. you can filter BGP based on routing updates to or from a particular neighbor.0. RTB is originating network 160.2.0 0.2.3. we would have to apply an access−list to filter those updates and apply it when talking to RTA: RTC# router bgp 300 network 170.255 Cisco − BGP Case Studies .0. Route Filtering In order to restrict the routing information that the router learns or advertises.3 remote−as 200 neighbor 2.2 remote−as 100 neighbor 2. In order to achieve this. an access−list is defined and applied to the updates to or from a neighbor.2 distribute−list 1 out access−list 1 deny 160.3.0. If RTC wanted to stop those updates from propagating to AS100. BGP updates can be filtered based on route information.0.255. All methods will achieve the same results.10.2.2.10.

0.255 255.0/8 (this notation means that we are using 8 bits of subnet mask starting from the far left of the IP address.0.255.X and our goal is to filter updates and advertise only 160.255.10. this is equivalent to 160.2 filter−list 1 out !−− the 1 is the access list number below ip as−path access−list 1 deny ^200$ ip as−path access−list 1 permit .0.2.0/8 we have to use an extended access list of the following format: access−list 101 permit ip 160.0. which is described in the next section.0.0 255.0.X.0 255.0 0.0.10.0.2.2.0.0/9 and so on.0.255. This list permits 160.0.255.3 remote−as 200 neighbor 2.255 permits 160.2. The command access−list 1 permit 160. Path Filtering You can specify an access list on both incoming and outgoing updates based on the BGP autonomous system paths information.0.0.0.0.0/8.0.x.0.* Cisco − BGP Case Studies .3.0 0. In the above figure we can block updates about 160. To do this use the following statements.0 RTC# router bgp 300 neighbor 3.160.0. Assume in the above example that RTB has different subnets of 160.0).0.0.10.0/8 only.0. Another type of filtering is path filtering. In order to restrict the update to only 160. ip as−path access−list access−list−number {permit|deny} as−regular−expression neighbor {ip−address|peer−group−name} filter−list access−list−number {in|out} The following example stops RTC from sending RTA updates about 160.2 remote−as 100 neighbor 2.0 from going to AS100 by defining an access list on RTC that prevents any updates that have originated from AS200 from being sent to AS100.255 !−− filter out all routing updates about 160.0. access−list 1 permit 0.x Using access−lists is a bit tricky when you are dealing with supernets that might cause some conflicts.10.255.0.0.3.0.0.0 0.255.0.

updates originated by AS400 will have path information of the form (200. or a space.* is another regular expression with the period meaning "any character" and the * meaning "the repetition of that character". which is needed to permit all other updates to be sent. In case of BGP we are specifying a string consisting of path information that an input should match. By building a regular expression we specify a string that input must match. ex: [abcd] Atom An atom is a single character.* is actually any path information. So .10. the beginning of the input string. What would happen if instead of using ^200$ we have used ^200? If you have an AS400 (see figure above).). Piece A piece is an atom followed by one of the following symbols: * (Matches 0 or more sequences of the atom) + (Matches 1 or more sequences of the atom) Cisco − BGP Case Studies .In the above example. the end of the input string. such as the following: . In the previous example we specified the string ^200$ and wanted path information coming inside updates to match it in order to perform a decision. The ^200$ is called a regular expression. The . The next section explains what is involved in creating a regular expression. Since RTB sends updates about 160.0. AS−Regular Expression A regular expression is a pattern to match against an input string. This shows all the paths that have matched the configured regular expression. right brace (}). left brace ({). (Matches any single character) ^ (Matches the beginning of the input string) $ (Matches the end of the input string) \ (Matches the character) − (Matches a comma (. A good way to check whether we have implemented the correct regular expression is to use the show ip bgp regexp <regular expression> command. Those updates will match the access list ^200 because they start with 200 and will be prevented from being sent to RTA which is not the required behavior. this update matches the access list and will be denied. 400) with 200 being first and 400 being last. access−list 1 states: deny any updates with path information that start with 200 (^) and end with 200 ($).0 with path information starting with 200 and ending with 200. The regular expression is composed of the following: Range A range is a sequence of characters contained within left and right square brackets. with ^ meaning "starts with" and $ meaning "ends with".

0 neighbor 3.0 255.0.255 Cisco − BGP Case Studies .3. Another method is community filtering.10.0. The no−export community attribute is used: RTB# router bgp 200 network 160.3.1 route−map setcommunity out route−map setcommunity match ip address 1 set community no−export access−list 1 permit 0.255.255.3.3. Community has been discussed previously and here are few examples of how we can use it.* (Coming from AS100) ^$ (Originated from this AS) BGP Community Filtering We have already seen route filtering and as−path filtering. Examples of regular expressions follow: a* (Any occurrence of the letter "a".0.3. including none) a+ ( At least one occurrence of the letter "a" should be present) ab?a (This matches "aa" or "aba") _100_ (Via AS100) ^100$ (Origin AS100) ^100 .1 send−community neighbor 3.3.? (Matches the atom or the null string) Branch A branch is a 0 or more concatenated pieces.1 remote−as 300 neighbor 3. We would like RTB above to set the community attribute to the BGP routes it is advertising such that RTC would not propagate these routes to its external peers.

Note also that we had to use the neighbor send−community command in order to send this attribute to RTC.3. The value 100 200 will be added to any existing community value before being sent to RTC.0 255.3. RTB# router bgp 200 network 160.3. it will not propagate them to its external peer RTA. ip community−list community−list−number {permit|deny} community−number For example we can define the following route map. In example two above.3 remote−as 200 neighbor 3. match−on−community: route−map match−on−community match community 10 !−− 10 is the community−list number set weight 20 ip community−list 10 permit 200 300 !−− 200 300 is the community number We can use the above in order to filter or set certain parameters like weight and metric based on the community value in certain updates.3.3 route−map check−community in route−map check−community permit 10 match community 1 set weight 20 route−map check−community permit 20 match community 2 exact set weight 10 route−map check−community permit 30 match community 3 ip community−list 1 permit 100 ip community−list 2 permit 200 ip community−list 3 permit internet Cisco − BGP Case Studies .1 send−community neighbor 3. When RTC gets the updates with the attribute no−export.1 route−map setcommunity out route−map setcommunity match ip address 2 set community 100 200 additive access−list 2 permit 0.255 A community list is a group of communities that we use in a match clause of a route map which allows us to do filtering or setting attributes based on different lists of community numbers.3.3.3.Note that we have used the route−map setcommunity command in order to set the community to no−export.255.3.0. If RTC wants to set the weight based on those values we could do the following: RTC# router bgp 300 neighbor 3.0 neighbor 3. In the example below.255.0.0.3. RTB was sending updates to RTC with a community of 100 200.1 remote−as 300 neighbor 3. RTB has set the community attribute to 100 200 additive.10.3.

3. Remember that anything that does not match.10. will be dropped by default.3 route−map stamp in route−map stamp match as−path 1 set weight 20 ip as−path access−list 1 permit ^200$ Any updates that originate from AS200 have a path information that starts with 200 and ends with 200 and will be permitted. RTC# router bgp 300 network 170.3. We can achieve this with a combination of neighbor and as−path access lists. we want to set the weight on the accepted routes to 20.3 remote−as 200 neighbor 3. Route maps associated with the neighbor statement have no affect on incoming updates when matching based on the IP address: neighbor ip−address route−map route−map−name Assume in the above diagram we want RTC to learn from AS200 about networks that are local to AS200 and nothing else.0 neighbor 3. The last community list is here to make sure that other updates are not dropped.In the above example. Cisco − BGP Case Studies . Any route that has only 200 as community will match list 2 and will have weight 20.0.3. Any other updates will be dropped. Also. The keyword exact states that community should consist of 200 only and nothing else.3. The keyword internet means all routes because all routes are members of the internet community. BGP Neighbors and Route Maps The neighbor command can be used in conjunction with route maps to perform either filtering or parameter setting on incoming and outgoing updates. any route that has 100 in its community attribute will match list 1 and will have the weight set to 20.

10. Suppose in the above diagram that RTC is advertising its own network 170. 300) and the second one is via AS400 with PATH (400.2..Assume that we want the following: • Updates originating from AS200 to be accepted with weight 20. • Updates originating from AS400 to be dropped. Use of set as−path prepend Command In some situations we are forced to manipulate the path information in order to manipulate the BGP decision process. the routers in AS600 will have network reachability information about 150.10.0.0. When the information is propagated to AS600.3.10..3.3 route−map stamp in route−map stamp permit 10 match as−path 1 set weight 20 route−map stamp permit 20 match as−path 2 set weight 10 ip as−path access−list 1 permit ^200$ ip as−path access−list 2 permit ^200 600 .0. • Other updates to have a weight of 10. 200. 300) received from AS100. AS300 will be getting all its traffic via AS100. A common practice is to repeat our own AS number using the following: RTC# router bgp 300 network 170. RTC# router bgp 300 network 170. 300.10.2.300).0 via AS100 with a PATH information of: (100.3 remote−as 200 neighbor 3.0.0 to two different ASs: AS100 and AS200. If we want to influence this decision from the AS300 end we can make the PATH through AS100 look like it is longer than the PATH going through AS400. We can do this by prepending autonomous system numbers to the existing path info advertised to AS100.0 neighbor 2.0 via two different routes. Cisco − BGP Case Studies . Assuming that all other attributes are the same AS600 will pick the shortest path and will choose the route via AS100.2. 300) which is longer than (400. 300.0. and will set a weight of 10 for updates that are behind AS400 and will drop updates coming from AS400. AS600 will receive updates about 170. the first route is via AS100 with PATH (100.2 remote−as 100 neighbor 2.3.* The above statement will set a weight of 20 for updates that are local to AS200. 200.2 route−map SETPATH out route−map SETPATH set as−path prepend 300 300 Because of the above configuration.3.2.0 neighbor 3.10. The command that is used with a route map is: set as−path prepend<As−path#><As−path#> .

We have defined a separate filter−list 3 for neighbor RTE.3. you can only override options set on the inbound.6. such as a route map SETMETRIC to set the metric to 5 and two different filter lists 1 and 2.2 peer−group internalmap neighbor 3. To define a peer group use the following: neighbor peer−group−name peer−group In the following example we will see how peer groups are applied to internal and external BGP neighbors. Members can also be configured to override these options if these options do not affect outbound updates.2 peer−group internalmap neighbor 5.3. Instead of defining the same policies for each separate neighbor.5. etc. we define a peer group name and we assign these policies to the peer group. Update policies are usually set by route maps. In the same diagram we will configure RTC with a peer−group externalmap and we will apply it to external neighbors. Members of the peer group inherit all of the configuration options of the peer group. Cisco − BGP Case Studies . and this will override filter−list 2 inside the peer group. let us look at how we can use peer groups with external neighbors. is a group of BGP neighbors with the same update policies. RTF and RTG. We have applied the peer group to all internal neighbors RTE.6.3. Note that we could only override options that affect inbound updates.5.2 filter−list 3 in In the above configuration. Now. distribute−lists and filter−lists.2 peer−group internalmap neighbor 3. we have defined a peer group named internalmap and we have defined some policies for that group. RTC# router bgp 300 neighbor internalmap peer−group neighbor internalmap remote−as 300 neighbor internalmap route−map SETMETRIC out neighbor internalmap filter−list 1 out neighbor internalmap filter−list 2 in neighbor 5.BGP Peer Groups A BGP peer group.3.

2. All rights reserved.2 by assigning filter−list 3.2 peer−group externalmap neighbor 4.2.2 filter−list 3 in Note that in the above configs we have defined the remote−as statements outside of the peer group because we have to define different external ASs.2 remote−as 600 neighbor 4.1.2.2 peer−group externalmap neighbor 1..1.2 remote−as 100 neighbor 2.1.1. Updated: May 07.2 remote−as 200 neighbor 1.4.1. Go to previous section Return to table of contents Go to next section Cisco Systems TAC Certified Learn more about Cisco TAC Certification. All contents are Copyright © 1992−−2002 Cisco Systems Inc.2 peer−group externalmap neighbor 1. Important Notices and Privacy Statement.4.1. Also we did an override for the inbound updates of neighbor 1.1.4. 2002 Document ID: 17013 Cisco − BGP Case Studies .2.1. RTC# router bgp 300 neighbor externalmap peer−group neighbor externalmap route−map SETMETRIC neighbor externalmap filter−list 1 out neighbor externalmap filter−list 2 in neighbor 2.4..

0/16 where the 16 is the number of bits in the subnet mask counting from the far left of the IP address.0.0 RTC will propagate the aggregate address 160.0.0.3 remote−as 200 neighbor 2. network 192.0.0.10. Aggregates are used to minimize the size of routing tables. There is no notion of classes anymore (class A.0 255.0.255. B or C). RTB is generating network 160.1 remote−as 300 network 160.0.0.0.0.0.10.3.2 remote−as 100 network 170.0 aggregate−address 160.0. For example.2. Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised.0 255.3.213.3.0.3. In the example below.10.0 #RTC router bgp 300 neighbor 3.0 which used to be an illegal class C network is now a legal supernet represented by 192.0 to RTA.0. We will configure RTC to propagate a supernet of that route 160. Cisco − BGP Case Studies .BGP Case Studies Section 4 CIDR and Aggregate Addresses BGP Confederation Route Reflectors Route Flap Dampening How BGP Selects a Path CIDR and Aggregate Addresses One of the main enhancements of BGP4 over BGP3 is Classless Interdomain Routing (CIDR). CIDR or supernetting is a new way of looking at IP addresses. RTB# router bgp 200 neighbor 3.213.0 to RTA.213.0.0.0. This is similar to 192.2.

0. The upcoming CIDR example discusses this situation. aggregate 129.10.0 as−set This command will be discussed in an example by itself in the following sections.0.0. In case we would like to suppress more specific routes when doing the aggregation we can define a route map and apply it to the aggregates. from redistributing an IGP or static into BGP or via the network command (network 160. Please note that if we are aggregating a network that is injected into our BGP via the network statement (ex: network 160.0.0.0 if it does not have a more specific entry of 160.0.0 have been propagated to RTA.10.10.0 on RTB) then the network entry is always injected into BGP updates even though we are using "the aggregate summary−only" command.0 255.0 only and NOT the more specific route then we would have to use the following: aggregate−address address mask summary−only This will a advertise the prefix only.0.0 255.0 will propagate an additional network 160.0.0.0. This will allow us to be selective about which more specific routes to suppress.0. and all of the more specific routes. For example.0 summary−only will propagate network 160.0.0. The outcome of this is that both networks 160.0. The command aggregate−address 160. aggregate−address address mask as−set This advertises the prefix and the more specific routes but it includes as−set information in the path information of the routing updates.0.0). The command aggregate 160.0 to be propagated.0.0 and suppress the more specific route 160.0.0 and 160.0.0.0.0.0 from being also propagated to RTA.Aggregate Commands There is a wide range of aggregate commands.0. Please note that you can not aggregate an address if you do not have a more specific route of that address in the BGP routing table.0.0 and will suppress the more specific route 160. we can use the following route map: Cisco − BGP Case Studies . The more specific route could have been injected into the BGP table via incoming updates from other ASs. if we would like to aggregate 160.0.10.0 and allow 160.0.0. In case we would like RTC to propagate network 160.10. RTB can not generate an aggregate for 160.0.0.20. In the previous diagram. The first command is the one used in the previous example: aggregate−address address mask This will advertise the prefix route.10. all the more specific routes are suppressed. This is what we mean by advertising the prefix and the more specific route.0.0.0 in its BGP table.0.0 but will not prevent 160. It is important to understand how each one works in order to have the desired aggregation behavior. aggregate−address address−mask suppress−map map−name This advertises the prefix and the more specific routes but it suppresses advertisement according to a route−map.0.

2.10.0. route−map SETMETRIC set origin igp aggregate−address 160.0.20. You cannot have RTB generate a prefix for 160.0 255.0 even if you use the aggregate summary−only command because RTB is the originator of 160.10.3 remote−as 200 neighbor 2.255 By definition of the suppress−map. meaning AS200 is the originator of 160.255 access−list 1 deny 0.3.10.0. Cisco − BGP Case Studies .0.2 remote−as 100 neighbor 2.0 255.2.10.0 is local to AS200.2. route−map CHECK permit 10 match ip address 1 access−list 1 permit 160.0 attribute−map SETORIGIN CIDR Example 1 Request: Allow RTB to advertise the prefix 160.2 remote−as 100 network 170. RTC# router bgp 300 neighbor 3.0.255.0 255.0.0. The problem here is that network 160.0.0.0.0.255.0 and suppress all the more specific routes.10.0. Then we apply the route−map to the aggregate statement.0.0. There are two solutions to this problem.0.0 aggregate−address 160. any packets permitted by the access list would be suppressed from the updates.255.0 without generating an entry for 160.0.0. The following route map when applied to the aggregate attribute−map command will set the origin of the aggregates to IGP.0 0.0.0.0.3.0.2.0.0.0 suppress−map CHECK Another variation is the: aggregate−address address mask attribute−map map−name This allows us to set the attributes (such as metric) when aggregates are sent out.

3.0.0. regardless of how many times it may have appeared in multiple paths that were aggregated. This has the same effect except that the origin of the update will be set to IGP.0.0 mask 255. All the path information is included in that set irrespective of which path came first.1 remote−as 300 redistribute static !−− This generates an update for 160.0.0 255. The outcome is that RTB will advertise the aggregate with an origin of incomplete (?).3.0.0. RTB# router bgp 200 network 160.0 255.0.0.0.10.1 remote−as 300 RTA# router bgp 100 Cisco − BGP Case Studies .0. In the following example RTC is getting updates about 160.0 from RTB.0 from RTA and updates about 160.0.0.0 null0 CIDR Example 2 (as−set) AS−SETS are used in aggregation to reduce the size of the path information by listing the AS number only once. By adding the aggregate as−set statement we force RTC to generate path information in the form of a set {}.0/8 and send it to RTD.The first solution is to use a static route and redistribute it into BGP.0. The as−set aggregate command is used in situations were aggregation of information causes loss of information regarding the path attribute.3.0.0.3.0 null0 In the second solution.0.0 neighbor 3.0 !−− with the origin path as *incomplete* ip route 160. RTB# router bgp 200 network 160.0 !−− This marks the update with origin IGP neighbor 3.0. RTB# router bgp 200 neighbor 3. in addition to the static route we add an entry for the network command.3.0.10. Suppose RTC wants to aggregate network 160.1 remote−as 300 redistribute static ip route 160.20.3. RTD would not know what the origin of that route is.0.

they exchange routing as if they were using IBGP.2.0 neighbor 2.4.0 belongs to a set {100 200}. RTC# router bgp 300 neighbor 3. the confederation (the group of ASs) will look like a single AS.2 remote−as 100 neighbor 4.1 remote−as 300 Case 1: RTC does not have an as−set statement.0.0 255.3 remote−as 200 neighbor 2. Each AS by itself will have IBGP fully meshed and has connections to other AS's inside the confederation.4 remote−as 400 aggregate 160.0.3.0.0.0. next hop.0. The next two subjects.0 255.0.2.0/8 with no indication !−− that 160.0.0 255.0 summary−only aggregate 160. network 160. Even though these ASs will have EBGP peers to ASs within the confederation.3.0 summary−only !−− this causes RTC to send RTD updates about 160.0/8 to RTD with path information (300) as if the route has originated from AS300.3.0 is actually coming from two different autonomous !−− systems. To the outside world.0.0.2.3 remote−as 200 neighbor 2.4.0. The group of ASs will look to the outside world as one AS with the AS number being the confederation identifier. this may create loops if RT4 has an entry back into AS100.0.4.0.2. BGP Confederation BGP confederation is implemented in order to reduce the IBGP mesh inside an AS.4.0.2.4 remote−as 400 aggregate 160.0.0. The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Case 2: RTC# router bgp 300 neighbor 3.0 as−set !−− causes RTC to send RTD updates about 160.0. To configure a BGP confederation use the following: bgp confederation identifier autonomous−system The confederation identifier will be the AS number of the confederation group.0.0.20.0.0. metric and local preference information are preserved.0.0.3.2. Peering within the confederation between multiple ASs is done via the following command: bgp confederation peers autonomous−system [autonomous−system] The following is an example of confederation: Cisco − BGP Case Studies . RTC will send an update 160.0/8 with an !−− indication that 160.2 remote−as 100 neighbor 4. are designed for ISPs who would like to further control the explosion of iBGP peering inside their autonomous systems. confederation and route reflectors.

2 remote−as 60 (IBGP connection within AS60) neighbor 128.1 remote−as 70 (BGP connection with confederation peer 70) neighbor 6. but we are only interested in the BGP speakers that have EBGP connections to other ASs).6.1 remote−as 50(BGP connection with confederation peer 50) neighbor 135.1 remote−as 60 (BGP connection with confederation peer 60) neighbor 135.14. The outside world will see only one AS500.1 remote−as 50 (IBGP connection within AS50) neighbor 128. Note that RTA has no knowledge of ASs 50. By using confederation we can divide AS500 into multiple ASs: AS50. Let's look at a sample configuration of routers RTC.212.30. RTD and RTA.5.6.5 remote−as 100 (EBGP connection to external AS100) RTD# router bgp 60 bgp confederation identifier 500 bgp confederation peers 50 70 neighbor 129.20. AS60 and AS70 we define a full mesh of IBGP peers and we define the list of confederation peers using the bgp confederation peers command.4 remote−as 500 (EBGP connection to confederation 500) Cisco − BGP Case Studies .30. We give the AS a confederation identifier of 500.212. If you want to make a full IBGP mesh inside AS500 then you would need nine peer connections for each router.210.10.6 remote−as 600 (EBGP connection to external AS600) RTA# router bgp 100 neighbor 5. RTA has only knowledge of AS500. RTC# router bgp 50 bgp confederation identifier 500 bgp confederation peers 60 70 neighbor 128.213.5.213. 60 or 70. For each AS50.1 remote−as 70 (BGP connection with confederation peer 70) neighbor 5.11.Let us assume that you have an autonomous system 500 consisting of nine BGP speakers (other non BGP speakers exist also. 8 IBGP peers and one EBGP peer to external ASs.5.213.210. AS60 and AS70.14.1 remote−as 50 (IBGP connection within AS50) neighbor 129.5.

As demonstrated in the Internal BGP section. By utilizing the route reflector concept. RTB and RTC above would form a cluster with a single RR within AS100. RTC would be configured with the neighbor route−reflector−client command pointing at RTA and RTB's IP addresses. RTA. This will reduce the number of IBGP peers within an AS. By relaxing this restriction a bit and by providing additional control. a BGP speaker will not advertise a route learned via another IBGP speaker to a third IBGP speaker. RTB and RTC within AS100. Cisco − BGP Case Studies . Peering between RTA and RTB is not needed because RTC will be a route reflector for the updates coming from RTA and RTB. a full IBGP mesh should be maintained between RTA. we can allow a router to advertise (reflect) IBGP learned routes to other IBGP speakers. The combination of the RR and its clients is called a cluster. In our example. Other IBGP peers of the RR that are not clients are called non−clients. In normal cases. neighbor route−reflector−client The router with the above command would be the RR and the neighbors pointed at would be the clients of that RR.Route Reflectors Another solution for the explosion of IBGP peering within an autonomous system is Route Reflectors (RR). RTC could be elected as a RR and have a partial IBGP peering with RTA and RTB.

1 route−reflector−client neighbor 7. The following is the relative BGP configuration of routers RTC. 3. Route from a client peer: reflect to all the non−client peers and also to the client peers.2. According to RTC.2. Clients should not peer with IBGP speakers outside their cluster. RTD and RTB: RTC# router bgp 100 neighbor 2.7.8 remote−as 200 RTB# router bgp 100 Cisco − BGP Case Studies . Other RRs could belong to the same cluster (client group) or to other clusters.4 remote−as 100 neighbor 8. Remember that clients of an RR are pointed at using the neighbor route−reflector−client command. RTA.1.1.4.An autonomous system can have more than one route reflector.1.1. Consider the above diagram.4.2 route−reflector−client neighbor 1. Note that RTD. When a route is received by a RR. 2. a RR would treat other RRs just like any other IBGP speaker. RTG is a RR in a third cluster. each RR will be configured with other RRs as non−client peers in a fully meshed topology.7 remote−as 100 neighbor 4.8. Route from an EBGP peer: send the update to all client and non−client peers. Route from a non−client peer: reflect to all the clients within the cluster. the AS could be divided into multiple clusters.2. RTC and RTG are fully meshed but routers within a cluster are not.2. The same RTD is the RR for its clients RTE and RTF.2 remote−as 100 neighbor 2.8.1 remote−as 100 neighbor 1. In a simple configuration. RTA and RTB are clients and anything else is a non−client. RTB and RTC form a single cluster with RTC being the RR. it will do the following depending on the peer type: 1.7.

5.12 remote−as 300 RTD# router bgp 100 neighbor 6. A cluster−list is a sequence of cluster−ids that the route has passed. non transitive BGP attribute that is four bytes long and is created by a RR. If this update has an empty cluster−list the RR will create one. Thus.6. a cluster might have more than one RR.3 remote−as 100 neighbor 12.7. 2.7.7 remote−as 100 neighbor 3. Multiple RRs within a Cluster Usually. it will append the local cluster−id to the cluster−list.5. This attribute will carry the router−id (RID) of the originator of the route in the local AS.6. In this case.3.5 route−reflector−client neighbor 7. Cluster−list: this will be discussed in the next section.5 remote−as 100 neighbor 5.3. neighbor 3. a RR can identify if the routing Cisco − BGP Case Studies . In order to increase redundancy and avoid single points of failure. the cluster will be identified by the router ID of the RR.6. All RRs in the same cluster need to be configured with a 4 byte cluster−id so that a RR can recognize updates from RRs in the same cluster.6.3 remote−as 100 As the IBGP learned routes are reflected. Using this attribute. if the routing information comes back to the originator. The Route Reflector scheme has a few methods to avoid this: 1.12. a cluster of clients will have a single RR.6 remote−as 100 neighbor 6. due to poor configuration. When a RR reflects a route from its clients to non−clients outside of the cluster. it is possible to have the routing information loop. it will be ignored. Originator−id: this is an optional.6 route−reflector−client neighbor 5.5.5.3.3.12.

10. RTE.7 remote−as 100 neighbor 3.6 route−reflector−client neighbor 7.3 remote−as 100 neighbor 11.5.7.11. peer−goups should not be used. Cisco − BGP Case Studies .7.information is looped back to the same cluster due to poor configuration.9 remote−as 300 bgp cluster−id 10 RTD# router bgp 100 neighbor 10.2.8.4.5 remote−as 100 neighbor 5.5.2 remote−as 100 neighbor 2. The following are the configuration of RTH.9.1 remote−as 100 neighbor 1.4 remote−as 100 neighbor 13.6.6 route−reflector−client neighbor 7. RTF and RTC: RTH# router bgp 100 neighbor 4.6.10 remote−as 100 neighbor 5. then a potential withdrawal to the source of a route on the RR would be sent to all clients inside the cluster and could cause problems.6 remote−as 100 neighbor 6. is that peer−groups were not used in the above configuration.4. RTF and RTH belong to one cluster with both RTD and RTH being RRs for the same cluster.13 remote−as 500 RTC# router bgp 100 neighbor 1.5.6.2.5.2. RTD.11 remote−as 400 bgp cluster−id 10 RTF# router bgp 100 neighbor 10.4.1. In case RTD goes down.5 route−reflector−client neighbor 6.4.5.4 remote−as 100 neighbor 7.2. If the local cluster−id is found in the cluster−list.5.1. RTD.10.5 route−reflector−client neighbor 6.10 remote−as 100 neighbor 8.8 remote−as 200 Note that we did not need the cluster command for RTC because only one RR exists in that cluster.7.10.3. In the above diagram. the advertisement will be ignored.4.13.5.1.7.10.7 remote−as 100 neighbor 3.9.5 remote−as 100 neighbor 5.1.10 remote−as 100 neighbor 4.10. If the clients inside a cluster do not have direct IBGP peers among one another and they exchange updates through the RR.6.6.7.8.6.6.2 route−reflector−client neighbor 4.3.1 route−reflector−client neighbor 2.7 remote−as 100 neighbor 10. Note the redundancy in that RTH has a fully meshed peering with all the RRs.6.7. If peer groups were to be configured.4.4 remote−as 100 neighbor 5. An important thing to note.3 remote−as 100 neighbor 9.3. RTH will take its place.10.11.5.6 remote−as 100 neighbor 6.3.13.

This would allow easy and gradual migration from the current IBGP model to the route reflector model.2. RTD. it is only the RRs that would have to be upgraded. If BGP client−to−client reflection were turned off on the RR and redundant BGP peering was made between the clients.4.2 remote−as 100 Cisco − BGP Case Studies . In the above diagram.13.6. Later on. then using peer groups would be alright.1.1. RTC.13.5. Clients do not have to understand the route reflection scheme. RTE and RTF have the concept of route reflection.5 route−reflector−client neighbor 3.6.2.The router sub−command bgp client−to−client reflection is enabled by default on the RR.5.5 remote−as 100 neighbor 5. RTA and RTB are what we call conventional routers and cannot be configured as RRs.3 remote−as 100 neighbor 2. We will call these routers conventional BGP speakers.6 remote−as 100 neighbor 6.2 remote−as 100 neighbor 1.4 remote−as 100 neighbor 2. Normal IBGP mesh could be done between these routers and RTD.5. One could start creating clusters by configuring a single router as RR and making other RRs and their clients normal IBGP peers.5.6 route−reflector−client neighbor 5. RTC could be made a RR with clients RTA and RTB.3. The following is the configuration of RTD and RTC: RTD# router bgp 100 neighbor 6.3.6. when we are ready to upgrade. Then more clusters could be created gradually. The route reflector scheme will allow such conventional BGP speakers to coexist.2.2.1 remote−as 100 neighbor 13.4.13 remote−as 300 RTC# router bgp 100 neighbor 4.6. RR and Conventional BGP Speakers It is normal in an AS to have BGP speakers that do not understand the concept of route reflectors. These routers could be either members of a client group or a non−client group.

range is 1−255. current default is 15 min) • <reuse−value> (range is 1−20000. Route Flap Dampening Route dampening (introduced in Cisco IOS version 11. Once the penalty decreases below a predefined "reuse−limit". default is 750) • <suppress−value> (range is 1−20000. the advertisement of the route will be suppressed. dampening will be off by default. The following are the commands used to control route dampening: • bgp dampening (will turn on dampening) • no bgp dampening (will turn off dampening) • bgp dampening <half−life−time> (will change the half−life−time) A command that sets all parameters at the same time is: • bgp dampening <half−life−time> <reuse> <suppress> <maximum−suppress−time> • <half−life−time> (range is 1−45 min.14. criteria are defined to identify poorly behaved routes. The penalty will be decayed at a granularity of 5 seconds and the routes will be un−suppressed at a granularity of 10 seconds. Another means of controlling loops is to put more restrictions on the set clause of out−bound route−maps. default is 4 times half−life−time) Cisco − BGP Case Studies . learned via IBGP will not be dampened. default is 2000) • <max−suppress−time> (maximum duration a route can be suppressed. This might change if there is a need to have this feature enabled by default.1 remote−as 100 neighbor 14. which is a per neighbor configuration option. This is to avoid the IBGP peers having higher penalty for routes external to the AS. Avoiding Looping of Routing Information We have mentioned so far two attributes that are used to prevent potential information looping: originator−id and cluster−list. More restrictions are also put on nexthop−self. The dampening information is kept until the penalty becomes less than half of "reuse−limit" . As soon as the cumulative penalty reaches a predefined "suppress−limit". The set clause for out−bound route−maps does not affect routes reflected to IBGP peers. Initially. A route which is flapping gets a penalty for each flap (1000).14.0) is a mechanism to minimize the instability caused by route flapping and oscillation over the network. at that point the information is purged from the router.1. the route advertisement will be un−suppressed. neighbor 1. Routes. When used on RRs the nexthop−self will only affect the nexthop of EBGP learned routes because the nexthop of reflected routes should not be changed. The penalty will be exponentially decayed based on a preconfigured "half−time". we would remove the IBGP full mesh and have RTA and RTB become clients of RTC. To accomplish this. external to an AS.14 remote−as 400 When we are ready to upgrade RTC and make it a RR.1.

h history. e − EGP.15.2 255.208.0 192. * valid.0.6 remote−as 100 RTB is configured for route dampening with default parameters. Assuming the EBGP link to RTD is stable.174 255.0. * valid.10.0.255.252 router bgp 100 bgp dampening network 203.5 0 0 300 i *> 203.10.255.10.10. RTB's BGP table will look like this: RTB#show ip bgp BGP table version is 24.208.0 0.208.0 0 32768 i In order to simulate a route flap.10. d damped.5 255.208.15.250.15. ? − incomplete Network Next Hop Metric LocPrf Weight Path h 192.208.10.15.252 router bgp 300 network 192.250.208.2 Status codes: s suppressed.250.255.255.250.6 on RTD.208. > best. RTB's BGP table would look like this: RTB#show ip bgp BGP table version is 24. RTB# hostname RTB interface Serial0 ip address 203.15. local router ID is 203.0 neighbor 192.250.250.0 0.15.5 remote−as 300 RTD# hostname RTD interface Loopback0 ip address 192. d damped.2 Status codes: s suppressed. i − internal Origin codes: i − IGP. > best.10. use clear ip bgp 192. ? − incomplete Network Next Hop Metric LocPrf Weight Path *> 192. i − internal Origin codes: i − IGP.0 neighbor 192.255.255.208.10.0 192. local router ID is 203.208.255. e − EGP. h history.10.208.255.0 0 32768 i Cisco − BGP Case Studies .6 255.5 0 0 300 i *> 203.10.252 interface Serial1 ip address 192.208.10.0.192 interface Serial0/0 ip address 192.

metric 0.208.10.208. flapped 3 times in 0:05:18 . version 32 Paths: (1 available. e − EGP. Which means that we do not have a best path to the route but information about the route flapping still exists.174) Origin IGP.208.0 255. metric 0.5 0 0 300 i *> 203.208.10.0 192.208. in our case (750/2=375). * valid.5 (192.m. in our case 750 (default).10.D m.10. reuse in 0:27:00 The route has been dampened (suppressed).0. no best path) 300.C.15.m.5 (192.0 255.B.10.m. external Dampinfo: penalty 2615.10.5 from 192.250. > best.10.The BGP entry for 192.208.5 from 192.0 BGP routing table entry for 192.208.208.208.208. no best path) 300 (history entry) 192.m longer−prefixes (displays flap statistics for more specific entries) • show ip bgp neighbor [dampened−routes] | [flap−statistics] (displays flap statistics for all paths from a neighbor) • clear ip bgp flap−statistics (clears flap statistics for all routes) Cisco − BGP Case Studies .10.m (displays flap statistics for a single entry) • show ip bgp flap−statistics A. version 25 Paths: (1 available.0. (suppressed due to dampening) 192. The following are the commands used to show and clear flap statistics information: • show ip bgp flap−statistics (displays flap statistics for all the paths) • show ip bgp−flap−statistics regexp <regexp> (displays flap statistics for all paths that match the regexp) • show ip bgp flap−statistics filter−list <list> (displays flap statistics for all paths that pass the filter) • show ip bgp flap−statistics A.0. i − internal Origin codes: i − IGP.2 Status codes: s suppressed.0.0 has been put in a "history" state. external Dampinfo: penalty 910.10. RTB#show ip bgp 192. If the route flaps few more times we will see the following: RTB#show ip bgp BGP table version is 32.255.0 0 32768 i RTB#show ip bgp 192.208.10.0 BGP routing table entry for 192.C.B.255. local router ID is 203.15.10.m.208.208.255. flapped 1 times in 0:02:03 The route has been given a penalty for flapping but the penalty is still below the "suppress limit" (default is 2000). ? − incomplete Network Next Hop Metric LocPrf Weight Path *d 192.174) Origin IGP.250.D m. d damped.The dampening information will be purged when the penalty becomes less than half of the reuse−limit.255. valid. The route is not yet suppressed.0 0.10. The route will be reused when the penalty reaches the "reuse value". h history.10.

• clear ip bgp flap−statistics regexp <regexp> (clears flap statistics for all the paths that match the regexp) • clear ip bgp flap−statistics filter−list <list> (clears flap statistics for all the paths that pass the filter) • clear ip bgp flap−statistics A.. Important Notices and Privacy Statement. All rights reserved. All contents are Copyright © 1992−−2002 Cisco Systems Inc.D flap−statistics (clears flap statistics for all paths from a neighbor) How BGP Selects a Path Now that we are familiar with the BGP attributes and terminology. Go to previous section Return to table of contents Go to next section Cisco Systems TAC Certified Learn more about Cisco TAC Certification. 2002 Document ID: 17013 Cisco − BGP Case Studies .m (clears flap statistics for a single entry) • clear ip bgp A. refer to BGP Best Path Selection Algorithm.m. The following section contains a design example that shows the configuration and routing tables as they actually appear on Cisco routers.C.. Updated: May 07.B.D m.C.m.B.

0 Cisco − BGP Case Studies .14.41 255. These aren't the final configurations. Assuming that we're connected to two ISPs. it's always good to run iBGP within your AS in order to have a better control of your routes.255.255.13. AS200 and AS300.BGP Case Studies Section 5 Practical Design Example We'll build the above configuration step by step and see what can go wrong along the way.250. In this example we run iBGP inside AS100 between RTA and RTB.255.0 interface Ethernet0 ip address 203.1 255. Whenever you have an AS that is connected to two ISPs via eBGP. and we run OSPF as an IGP.255. the following is the first run of the configurations for all the routers. RTA# hostname RTA ip subnet−zero interface Loopback0 ip address 203.250.

255.14.0.255 area 0 router bgp 100 network 203.252 router ospf 10 network 203.255.208.250.213.41 remote−as 100 RTC# hostname RTC ip subnet−zero interface Loopback0 ip address 128.2 255.255.0.250.255.5 remote−as 300 neighbor 203.250.255.252 router bgp 200 network 128.2 remote−as 100 neighbor 203.255. interface Serial0 ip address 128.250.0 0.255.2 update−source Loopback0 RTF# hostname RTF ip subnet−zero interface Ethernet0 ip address 203.0.2 255.255.130 255.250.63.63.15.0.1 remote−as 100 Cisco − BGP Case Studies .14.1 255.250.250.255.250.255.0.1 255.250.0 neighbor 128.0 0.255 area 0 RTB# hostname RTB ip subnet−zero interface Serial0 ip address 203.15.63.10.213.13.63.213.0 neighbor 128.10.0.255.2 255.0 network 203.255 area 0 router bgp 100 network 203.250.252 router ospf 10 network 203.15.15.0 interface Serial1 ip address 203.213.255.252 router ospf 10 network 203.255.255.192 interface Serial2/0 ip address 128.0.255.250.213.2 remote−as 200 neighbor 203.6 255.255.5 255.252 ! interface Serial2/1 ip address 128.13.252 interface Serial1 ip address 192.63.250.255.255.208.213.63.0 0.213.255.0 neighbor 192.15.

0 neighbor 192.1 remote−as 500 neighbor 192.10.192 interface Serial0/0 ip address 192.252 router bgp 300 network 192.211.211.252 ! interface Serial0/1 ip address 192. throughout this example I use the network command to inject networks into BGP.2 255.208.63.213.63.255.213.255.2 remote−as 300 neighbor 195.208.10.255.211.208.211.255.208.211.255.252 interface Serial1 ip address 195.255.2 255.252 router bgp 500 network 195.252 interface Serial1 ip address 128.255.255. This is why.252 clockrate 1000000 router bgp 400 network 200.10.208.213.255.10.192 interface Serial0 ip address 192.255.0 neighbor 128.255.2 remote−as 400 It's always better to use the network command or redistribute static entries into BGP to advertise networks. Cisco − BGP Case Studies .255.174 255.6 255.208.10.10.10.1 255.174 255.10.255.0 neighbor 192.5 255.10.1 255. neighbor 128.255.10.5 remote−as 200 neighbor 195.200.10.10.255.6 remote−as 100 RTE# hostname RTE ip subnet−zero interface Loopback0 ip address 200.63.211.255.10.10.208.6 remote−as 400 RTD# hostname RTD ip subnet−zero interface Loopback0 ip address 192.255.200. rather than redistributing IGP into BGP.0 interface Serial0 ip address 195.208.255.1 255.10.1 remote−as 500 RTG# hostname RTG ip subnet−zero interface Loopback0 ip address 195.10.

S − static. RTB#show ip bgp BGP table version is 4. B − BGP D − EIGRP.213. Serial0 O 203.0 203.0 128. RTB hasn't learned about 128.0 128.213.2.10.2 100 0 200 400 500 i *i200. 02:50:46. Serial0 203.63.213.250.213. network 128.15.0 [110/74] via 203.63.250.14.208. local router ID is 203. and this way RTB would know how to reach the next hop 128. Serial0 It doesn't look like any of the BGP entries has made it to the routing table.13. d damped. The following is RTB's BGP table.250.250.0.63. L1 − IS−IS level−1.0.2. e − EGP. I − IGRP.250.2 Status codes: s suppressed. ? − incomplete Network Next Hop Metric LocPrf Weight Path *i128.1.41 [110/75] via 203. EX − EIGRP external. RTA's configuration would be as shown below. E2 − OSPF external type 2. We can run OSPF on RTA's s0 interface and make it passive.252 is subnetted.213.0 255.255.63.0.0 203.0 128.255 is subnetted.13.10. i − internal Origin codes: i − IGP. has a next hop 0.250. L2 − IS−IS level−2. The "i" at the beginning means that the entry was learned via an iBGP peer.250.2.0 0 32768 i Let me go over the basic notations of the above table.250.213.255. Notice the next hop attribute. > best.250.2 100 0 200 400 500 300 i *i195.15. * valid.213. This is true because we don't have a way to reach that next hop via our IGP (OSPF). The "i" at the end indicates the origin of the path information to be IGP. The path info is intuitive.0. h history.0 255.250.15.250.2 0 100 0 200 i *i192. 1 subnets O 203.63.213.Let's start with the s1 interface on RTB shutdown. M − mobile.0 via a next hop of 128. The > symbol indicates that BGP has chosen the best route based on the list of decision steps that I have gone through earlier in this document under "How BGP selects a Path". O − OSPF.63.15. R − RIP.63.0 128.15.0 is learned via path 200 with a next hop of 128.10.13. Note that any locally generated entry. 02:50:45. Let's look at the IP routing table: RTB#show ip route Codes: C − connected.211. The first problem is the next hop for these entries.213.2.0 is directly connected.0 via OSPF.15.250.2 100 0 200 400 i *>i203. 1 subnets C 203.41 0 100 0 i *>203.0.213.63. such as 203.200. There are two problems here.13.0. Doing this. For example. which is the eBGP next hop carried into iBGP. which we'll examine in turn.213. We could also change the next hop by using the bgp nexthopself command between RTA and RTB.255. RTA# hostname RTA ip subnet−zero Cisco − BGP Case Studies .0. BGP picks one best path to reach a destination.250.41 0 100 0 i *>i203. * − candidate default Gateway of last resort is not set 203.0 0.1.14.213.250. IA − OSPF inter area E1 − OSPF external type 1.0. as if the link between RTB and RTD doesn't exist.13.255.63. E − EGP i − IS−IS. installs it in the IP routing table and advertises it to other BGP peers. is unreachable.15. 128.0. RTB knows about 128.

0 255.15. L1 − IS−IS level−1.250.250. Serial0 O 203.15.250. IA − OSPF inter area E1 − OSPF external type 1. S − static.13.15.252 router ospf 10 passive−interface Serial0 network 203.2 0 100 0 200 i *>i192. which means that BGP can reach the next hop.250.250.255 is subnetted.0 0.10.250.0. h history.0 128.1.213.208. 00:04:47.14.15.0. ? − incomplete Network Next Hop Metric LocPrf Weight Path *>i128.250.15.15. E2 − OSPF external type 2.1 255. EX − EIGRP external.208.10. Let's look at the routing table: RTB#show ip route Codes: C − connected.250.10.255 area 0 router bgp 100 network 203. > best.0 0 32768 i Note that all the entries have >.63.0. * − candidate default Gateway of last resort is not set 203.255.0.255 area 0 network 128.255. M − mobile.255.0. I − IGRP.0 128.15.2 Status codes: s suppressed.255.0 255.255. * valid.0 and 195.255.1.13.250.255. interface Loopback0 ip address 203. Serial0 The second problem is that we still don't see the BGP entries in the routing table.2 100 0 200 400 i *>i203.0 is now reachable via OSPF.41 0 100 0 i *> 203.0.0.0 interface Serial0 ip address 128.0 [110/74] via 203.1.13.250.250.252 is subnetted.10.0 0.0.250.0 neighbor 128.0 [110/138] via 203. 1 subnets O 203.213.13.213.255.10.14.63.252 is subnetted.250.13.213.200.63. Serial0 203.213. 00:04:46.255.213.255.0 203.63. 1 subnets C 203.255. local router ID is 203. This is a synchronization issue: BGP isn't putting these entries in the routing table and won't send them in BGP updates because it's not synchronized with the IGP.0 128.63.63.250.0.2 remote−as 100 neighbor 203.255.213.0 128.14.0 203. L2 − IS−IS level−2.211. 00:04:46. B − BGP D − EIGRP.15.15.255. e − EGP.41 [110/75] via 203.0 0. Note that RTF has no notion of networks 192.2 remote−as 200 neighbor 203.1 255.13.2 100 0 200 400 500 300 i *>i195. d damped.2 update−source Loopback0 The new BGP table on RTB now looks like this: RTB#show ip bgp BGP table version is 10. E − EGP i − IS−IS.255.211. 1 subnets O 128.0 because we haven't redistributed BGP into OSPF Cisco − BGP Case Studies .213.250.250.250.63.213.250.41 0 100 0 i *>i203. Serial0 128.41 255.213.250.0 mask 255.0 interface Ethernet0 ip address 203. O − OSPF.250. R − RIP. the only difference is that 128.0 is directly connected.255.2 100 0 200 400 500 i *>i200.0.63. i − internal Origin codes: i − IGP.0 255.213.

255.213.200. EX − EIGRP external. 2 masks B 128. O − OSPF.1.255.255.0.252 is subnetted.252 is subnetted.15.255.255 [110/75] via 203.15.255.255.0.255. 00:14:15.250. Serial1 C 203.255.10.63.1. 00:14:15. L2 − IS−IS level−2.13. but there's no way we can reach those networks because RTF in the middle doesn't know how to reach them: RTF#show ip route Codes: C − connected.10.0 255.0 is directly connected. 2 masks O 203.255. EX − EIGRP external.63.63.14.63. Serial0 B 203. but connectivity is still be broken.15. 1 subnets O 128. 00:01:08 O 128. S − static.250.13. Serial0 The routing table looks fine.41.0. with a metric of 2000.255.255.0 255.213.2.15. * − candidate default Gateway of last resort is not set 203. L1 − IS−IS level−1.13.41 255. O − OSPF.0 is directly connected.213.250.yet. M − mobile.255 is subnetted. IA − OSPF inter area E1 − OSPF external type 1. if we turn synchronization off.0 [200/0] via 128. 00:12:37. B − BGP D − EIGRP. R − RIP.1.0 [110/74] via 203. Serial0 O 203.255.255.208. 00:12:37.250. R − RIP.41 255. 2 subnets.0 255.213.250.0.0 is directly connected.14. 00:01:07 B 192. 00:01:07 203. 1 subnets O 203.13. Serial0 128.15. I − IGRP.1. S − static.213. turning off synchronization in this situation didn't help.10. IA − OSPF inter area E1 − OSPF external type 1.41 [110/11] via 203.250.0 255.15.0 [200/0] via 128.2.250.0 is variably subnetted.252 [110/138] via 203.13. the entries appear in the routing table.1.250.0 255.2.250. E2 − OSPF external type 2.250.213. 2 subnets.0 [200/0] via 203. B − BGP D − EIGRP.255.0 Cisco − BGP Case Studies .0 is variably subnetted. * − candidate default Gateway of last resort is not set B 200.14.0 [200/0] via 128. 1 subnets C 203.0 255. 00:12:37.250.213. RTA# hostname RTA ip subnet−zero interface Loopback0 ip address 203.213.255.0 255. In this scenario. E − EGP i − IS−IS.14.250. L1 − IS−IS level−1.211.13. E − EGP i − IS−IS.250.250. I − IGRP. Ethernet0 128.2. If you turn off synchronization on RTB this is what will happen: RTB#show ip route Codes: C − connected.63.250.0 [200/0] via 128. M − mobile. Let's redistribute BGP into OSPF on RTA.0 [110/74] via 203.255.255. Ethernet0 So.250.63. Ethernet0 203. 00:01:08 203. L2 − IS−IS level−2.213. but we'll need it for other issues later on. 00:01:07 B 195.252 is subnetted.250. 1 subnets C 203.15.250.13. E2 − OSPF external type 2.

250. Loopback1 C 203.250.10.0 0.1 255. 00:00:16.213.252 [110/138] via 203.15.63.250.213. L2 − IS−IS level−2.13.0 is directly connected. Serial0 O E2 195.250. 00:00:15.213. routing loops will occur because in order to get to next hop 192.250. Serial0 O E2 203.250.208. 2 subnets.13. If we don't take this step. S − static.2 update−source Loopback0 The routing table looks like this: RTB#show ip route Codes: C − connected.0 mask 255.0.255.0.63. We'll keep sync off on RTB in order for it to advertise 203.0 for the same reason.250.252 router ospf 10 redistribute bgp 100 metric 2000 subnets passive−interface Serial0 network 203.63. Serial0 203. 2 masks O E2 128.0.0 interface Serial0 ip address 128. 00:00:14.0 [110/2000] via 203.0 [110/2000] via 203.15.0 255. E − EGP i − IS−IS.250.255. 00:00:15.0.250. Let's bring up RTB's s1 interface to see what the routes look like.250. IA − OSPF inter area E1 − OSPF external type 1.1.213.0.255. 00:00:14. B − BGP D − EIGRP.255 area 0 router bgp 100 network 203.1.255.0 [110/2000] via 203.1.8 is directly connected.0.0 255.0 [110/2000] via 203.0 0.255.0 [110/2000] via 203.250.15.10.5 via IGP.13.255.15.5.250. Let's also turn off synchronization on RTA in order for it to advertise 203.15.0.255. M − mobile.15.0. and enable OSPF on serial 1 of RTB to make it passive in order for RTA to know about the next hop 192.1 255. * − candidate default Gateway of last resort is not set O E2 200.250.0 neighbor 128. Serial0 The BGP entries have disappeared because OSPF has a better distance (110) than iBGP (200).208. Serial0 O 203.250. I − IGRP.15.Serial0 O 128.15. E2 − OSPF external type 2.10.1.10.15.250. because it won't sync up with OSPF due to the difference in masks.255.211. 00:00:15.0 is variably subnetted. Serial0 203.1.213.252 is subnetted.15.255.255.250.15.15.0 [110/74] via 203.255. 2 subnets.0. 00:00:15.250.250.2 remote−as 100 neighbor 203.250.255.255 area 0 network 128. EX − EIGRP external.250.255. 00:00:14.14. we'd have to go the other way via eBGP. R − RIP.1.255 [110/75] via 203.250.208.15.1.0 255.255.213.10.14.0 is variably subnetted.15.250.200.0 255.0.13.41 255.255. The updated configs of RTA and RTB are as follows: RTA# hostname RTA Cisco − BGP Case Studies .255. L1 − IS−IS level−1.2 remote−as 200 neighbor 203.1. Serial0 128. interface Ethernet0 ip address 203. Serial0 O E2 192. 2 subnets C 203. 2 masks O 203. O − OSPF.

6 255.213.213.0 neighbor 192.250.0 0.0.255. i −internal Origin codes: i − IGP.0.10.0 0.250. h history.250.213.0 128.250.0.5 remote−as 300 neighbor 203.2 remote−as 200 neighbor 203.213.211.255 area 0 network 128. ip subnet−zero interface Loopback0 ip address 203.0 0.2 remote−as 100 neighbor 203.10.0 neighbor 128.13.208.63.63.0 0 32768 i Cisco − BGP Case Studies .13.0.208.250.41 255.255.2 0 200 400 500 i *> 200.255.14.255.10.10.0.208.0 interface Ethernet0 ip address 203.0 interface Serial0 ip address 128.255 area 0 router bgp 100 no synchronization network 203.0 192.0. ? − incomplete Network Next Hop Metric LocPrf Weight Path *> 128.10.255.15.213.63.0.0 128.250.0 network 203.14.2 255.208.0 0.255 area 0 network 192.0 0.2 update−source Loopback0 RTB# hostname RTB ip subnet−zero interface Serial0 ip address 203. local router ID is 203.250.213. * valid.2 0 200 400 i *> 203.208.255.13.0.1 255.250.41 Status codes: s suppressed.252 interface Serial1 ip address 192.208.250.255.63.252 router ospf 10 redistribute bgp 100 metric 1000 subnets passive−interface Serial1 network 203.41 remote−as 100 And the BGP tables look like this: RTA#show ip bgp BGP table version is 117.63.255.255 area 0 router bgp 100 no synchronization network 203. > best.2 0 0 200 i *>i192.255. d damped.10. e − EGP.255.200.255.255.0.252 router ospf 10 redistribute bgp 100 metric 2000 subnets passive−interface Serial0 network 203.250.13.250.5 100 0 300 500 i * 128.15.255.213.0.0 192.13.255.15.250.15.5 0 100 0 300 i *>i195.1 255.10.0.250.

15.213.41 255.0 192. Because of aggregation. * valid.0 203.13. In our example.255.208.211. e − EGP. metric. In our example. One way is to have a primary ISP and a backup ISP. This can occur if you use the same pool of IP addresses (same major net) when talking to the two ISPs. we receive partial routes from AS200 and only local routes from AS300.10.255.0.41 0 100 0 i *> 203. We could learn partial routes from one of the ISPs and default routes to both ISPs. You might find out that all incoming traffic to your AS is coming via one single point even though you have multiple points to the Internet.250.0 192.0.14.41 0 100 0 i *>i203. we have two different major nets when talking to the two ISPs.0 203. d damped.63.5 0 300 500 400 200 i *> 192.208.10.250.200.250.252 router ospf 10 redistribute bgp 100 metric 2000 subnets passive−interface Serial0 Cisco − BGP Case Studies .5 0 300 500 400 i *>i203.63.250.2 100 0 200 400 i * 192. AS200 and AS300.13. and entry points to your network could occur via RTA or RTB. or weight.255. local router ID is 203.0 203.250.2 0 100 0 i RTB#show ip bgp BGP table version is 12.15.213. if AS400 has somehow set its exit point to be via AS200 based on attributes such as local preference. then there is nothing you can do.10.0 0. your whole AS might look like one whole entity to the outside world. h history.0 0.213.0 interface Serial0 ip address 128.250. This is the final configuration for all of the routers: RTA# hostname RTA ip subnet−zero interface Loopback0 ip address 203.15.0 128.250.2 0 100 0 200 i * 192.10.0 128. In this example.255. One service provider might be closer to a certain destination than another.10.0.13.15.10 Status codes: s suppressed.10.1 255.0 0 32768 i *>i203.14.208.0 interface Ethernet0 ip address 203. But.250. i −internal Origin codes: i − IGP.63.250. You might try to effect that decision by prepending path numbers to your updates to make the path length look longer (set as−path prepend).1 255.5 0 0 300 i *> 195. *> 203. Another potential reason for asymmetry is the different advertised path length to reach your AS.0 0 32768 i There are multiple ways to design our network to talk to the two different ISPs. Both RTA and RTB are generating default routes into OSPF with RTB being preferred (lower metric). > best.0.13.208.14.10.213. ? − incomplete Network Next Hop Metric LocPrf Weight Path *>i128. traffic from AS400 destined to your network always comes in via RTA because of the shorter path.208.255. This way we can balance outgoing traffic between the two ISPs.250.255.250.0.5 0 300 500 i *>i200. Potential asymmetry might occur if traffic going out from RTA comes back via RTB.

63. We used the default−information originate command with OSPF to inject the default route inside the OSPF domain.0 interface Serial1 ip address 203.6 255.250. network 203.0 is automatically redistributed into RIP without additional configuration.255.2 remote−as 200 neighbor 128.250.250.213.0. the default information is injected into the IGP domain after redistributing BGP into IGRP and EIGRP.252 router ospf 10 redistribute bgp 100 metric 1000 subnets passive−interface Serial1 network 203.0.250. RTF# hostname RTF ip subnet−zero interface Ethernet0 ip address 203.0.2 update−source Loopback0 ip classless ip default−network 200. We also used this command with ISIS and BGP.0.255.255 area 0 network 128.0 neighbor 128. For RIP.252 interface Serial0 ip address 203.250.250.250.250.1 255. using the ip default−network command. 0.0 route−map setlocalpref permit 10 set local−preference 200 On RTA.255.255.2 255.0 to be the candidate default.0.14.255.0. We also picked network 200.0 0.10.250.213.255.252 ! interface Serial1 ip address 192.255.2 255.0 network 203.15.250.0 into the IGP domain.250.200.14.0.0 0.15.255 area 0 default−information originate metric 2000 router bgp 100 no synchronization network 203.2 remote−as 100 neighbor 203.0.13.0.255.0 0. Also.255 area 0 Cisco − BGP Case Studies .0.15.0.63.255.252 router ospf 10 network 203. For IGRP and EIGRP.255.0.10 255.255 area 0 ip classless RTB# hostname RTB ip subnet−zero interface Loopback1 ip address 203. with IGRP and EIGRP we can redistribute a static route to 0.255.255.0. the local preference for routes coming from AS200 is set to 200.0 0.2 route−map setlocalpref in neighbor 203.15.208.213.200.255.15.0.255.

If you wanted to advertise the local routes and the neighbor routes (customers of the ISP) you can use the following: ^300_[0−9]* This is the output of the regular expression indicating AS300's local routes: RTB#show ip bgp regexp ^300$ BGP table version is 14. local router ID is 203.10 Status codes: s suppressed.252 router bgp 200 network 128.13.211.10. we aggregated 128.2 255.0 ip as−path access−list 1 permit ^300$ route−map localonly permit 10 match as−path 1 set local−preference 300 For RTB.10.192 interface Serial2/0 ip address 128.213.6 0.213.0/16 and indicated the specific routes to be injected into AS100.255. Note that we only advertised AS300's local routes.41 remote−as 100 ! ip classless ip default−network 192. d damped.208.63.213.255.213.252 ! interface Serial2/1 ip address 128.0.63.208.0. This way AS100 picks RTB for AS300's local routes.208.1 distribute−list 1 out neighbor 128.213. h history. network 192.6 remote−as 400 ip classless access−list 1 deny 195. e − EGP.250.208. i − internal Origin codes: i − IGP.213.10.10.0 192.208.10. Any path information that doesn't match ^300$ is dropped.0 neighbor 128. * valid.255.255. > best.5 remote−as 300 neighbor 192.255.250.255.0.63.0.250.5 255.0.255.1 remote−as 100 neighbor 128.63.10.63. which is higher than the iBGP updates coming from RTA.15.0. which is lower than 200 coming from RTA.5 route−map localonly in neighbor 203. ? − incomplete Network Next Hop Metric LocPrf Weight Path *> 192.5 0 300 0 300 RTC# hostname RTC ip subnet−zero interface Loopback0 ip address 128.255 access−list 1 permit any On RTC.130 255. If the ISP Cisco − BGP Case Studies .0 area 0 default−information originate metric 1000 ! router bgp 100 no synchronization network 203.0 neighbor 192.213. the local preference for updates coming from AS300 is set to 300.208.63. so RTA is preferred. Any other routes on RTB (if they exist) are sent internally with a local preference of 100.213.0 0.15.

0 summary−only neighbor 192.255.2 send−community neighbor 192.5 255.refuses to do this task then you have to filter on the incoming end of AS100.252 ! interface Serial0/1 ip address 192.0 neighbor 192.0 0.10.255.211.208. This way RTD won't export that route to RTB.255.208.1 255.208.10.10.255.174 255.255. It doesn't matter in our case because RTB isn't accepting these routes anyway.255.211.211.255.208.255.10.255.174 255.10.1 255.255.10.211.2 route−map setcommunity out neighbor 195.1 remote−as 500 neighbor 192.0 aggregate−address 195.192 ! interface Serial0/0 ip address 192.252 router bgp 300 network 192.0 updates towards RTD.208.255 access−list 2 permit any route−map setcommunity permit 20 match ip address 2 ! route−map setcommunity permit 10 match ip address 1 set community no−export On RTG.10.0.0.10.211.252 router bgp 500 network 195.255.208.255.6 remote−as 100 RTG# hostname RTG ip subnet−zero interface Loopback0 ip address 195.0 255.10.208.0.211.192 interface Serial0 ip address 192.255.211.2 remote−as 400 ! ip classless access−list 1 permit 195.10.0.10.2 remote−as 300 neighbor 192.208.255.2 255.10.208.208. we demonstrate the use of community filtering by adding a no−export community to 195. RTD# hostname RTD ip subnet−zero interface Loopback0 ip address 192.0.10.252 interface Serial1 ip address 195. RTE# hostname RTE ip subnet−zero interface Loopback0 Cisco − BGP Case Studies .10.

255.0 [110/1000] via 203.208.63.255.255.208. B − BGP D − EIGRP.0.0. R − RIP.0 0.255. i − internal Origin codes: i − IGP. local router ID is 203.0 203.255.255.10.10 255. RTF and RTB: RTA#show ip bgp BGP table version is 21.255.255.255.208.213.0 [200/0] via 203.200. 00:41:25 C 203.0 interface Serial0 ip address 195.250.213.6 255.250.0.0 192.0.15.14.213.2. 2 masks B 128. * − candidate default Gateway of last resort is 128.200.250.213. 00:02:38 RTF#show ip route Codes: C − connected.208.0 is variably subnetted.255.2.0.213.13.10.0.0 255.250. 00:41:25.63.13.0.0/16 128.0 255.208.250.255.2. Ethernet0 128.255. E − EGP i − IS−IS.2. 2 subnets.63. 3 masks O 203.200.0 is variably subnetted.0 255.213.250.255.14. S − static.0.0 255. h history.213.2. M − mobile.14.252 interface Serial1 ip address 128. Ethernet0/0 B* 200.15.0 0. L1 − IS−IS level−1. B − BGP D − EIGRP.213.2.250.1 remote−as 500 ip classless RTE is aggregating 200.200.14.0 [20/0] via 128.0 255.13.14.10.10. Following are the final BGP and routing tables for RTA.211.0/16.255. 00:41:25. Ethernet0 C 203.4 255.2 0 200 0 200 i *>i192.0 is directly connected.0. > best. ? − incomplete Network Next Hop Metric LocPrf Weight Path *> 128.0 0 32768 i *> 203.0 is variably subnetted. Ethernet0 O 203.0/0 [110/1000] via 203.250.1 255.10.200.2.250. Serial0 O*E2 0.10.0.2 to network 200. 2 subnets. I − IGRP.0 255.5 remote−as 200 neighbor 195.213.10. 2 masks O E2 192.252 router bgp 400 network 200.15. L2 − IS−IS level−2.0 0 32768 i *>i203.255.0 255.0 [20/0] via 128.5 0 300 0 300 i *> 200.255.252 [110/74] via 203.250. R − RIP.63.2 255.255. ip address 200.15.15.255. e − EGP.63.0 aggregate−address 200.250.14.250.0.14.200.0 is directly connected.255.41 Status codes: s suppressed. O − OSPF. M − mobile.213.255 [110/75] via 203.0.0 192. E2 − OSPF external type 2.0.200.63. * valid. 00:41:25.211. S − static.10.0 128.250.0. EX − EIGRP external.252 is directly connected.15. Loopback0 203. 00:41:25.252 [110/138] via 203. Ethernet0 O 192.15. 3 subnets.63.63.2 200 0 200 400 i *> 203.2 0 100 0 i RTA#show ip route Codes: C − connected.0. d damped.255.0.0 summary−only neighbor 128.250. IA − OSPF inter area E1 − OSPF external type 1. EX − EIGRP external. O − OSPF.250.250.2.10. 00:41:26 C 128. Ethernet0 B 203. I − IGRP.213.255.250. IA − OSPF inter area Cisco − BGP Case Studies .0.

255.255.15. Other known networks.15.0 [20/0] via 192. R − RIP. If something happens to the connection between RTB and RTD.255. Ethernet0 O E2 200.0 128.250.0 is variably subnetted.250.250. E1 − OSPF external type 1.14.1.0.255.208. such as 192.4 255. Serial1 O 192.213.0 is variably subnetted.252 [110/74] via 203. such as 200.252 is directly connected.14.208. L2 − IS−IS level−2.15.10.0 * 192.252 [110/128] via 203.2. E − EGP i − IS−IS.41 0 100 0 i *> 203.208.0.63.10.0.5. 00:45:01.208.0 is variably subnetted. Serial1 C 203.208.200.13.10 255.2.255. 2 subnets.14.0.255.10.250. Ethernet0 203.0. S − static.255.0 is variably subnetted.250.255. 00:50:46 C 192. 2 masks B* 192.15. 2 subnets.0.200.250.0 203. 01:12:11.255.250.14.0 is directly connected.255.0.0.250.0 0 32768 i RTB#show ip route Codes: C − connected.250.41 255. i − internal Origin codes: i − IGP.10. The gateway of last resort is set to RTB. 2 masks O 203. ? − incomplete Network Next Hop Metric LocPrf Weight Path *>i128.255. local router ID is 203.213. Serial1 203.10. Ethernet0 O E2 203.208.213. are to be reached through RTB.250. L1 − IS−IS level−1. then the default advertised by RTA kicks in with a metric of 2000.2.0.250.0 255. d damped. * valid. E − EGP i − IS−IS.1. 2 subnets.14.213.0.255 Cisco − BGP Case Studies .13.0. 01:12:09. Ethernet0 O*E2 0.4 255.10.0 203.250.213.10. O − OSPF.255.0. 01:12:09. > best. 2 masks O 203.0 255.13.208.0 [110/2000] via 203.250.1.0.255.0 255.250.10 Status codes: s suppressed.0 255.0 192. * − candidate default Gateway of last resort is 192.15.0 [110/1000] via 203.208.15.250.250.255.250. EX − EIGRP external.14.0 255. L1 − IS−IS level−1.255.0 [110/2000] via 203. 00:03:33.2 to network 0. 2 masks O E2 192.0 255.0.2 0 200 0 200 i *> 192.1. * − candidate default Gateway of last resort is 203.13.252 is directly connected.5 to network 192. B − BGP D − EIGRP. 2 masks O 203.0/16 128.14. M − mobile.255.0.0.255. 00:48:50.15.255. Ethernet0 128. E2 − OSPF external type 2.250.208. Ethernet0 O 128.0 [110/2000] via 203. 2 subnets.2 200 0 200 400 i *>i203.0 is variably subnetted.208.15.255.200.250.1.41 255.0 0.255.0 192.250.250.0.10.13. 2 masks O E2 128.15.13.0 is variably subnetted.15.208. e − EGP.255 [110/11] via 203. RTB#show ip bgp BGP table version is 14. Serial1 Note RTF's routing table indicates that networks local to AS300. E2 − OSPF external type 2.250.5 0 300 0 300 i *>i200.213. 00:03:47. 01:12:09. are to be reached through RTA. h history.0 [110/1000] via 203.208. Serial1 203.41 0 100 0 i *>i203. 2 subnets.10.13.10.250. Serial1 C 203.0 0.10.63.255 [110/65] via 203.13.0 255. L2 − IS−IS level−2. IA − OSPF inter area E1 − OSPF external type 1.63.250.2.255.255.250. 01:12:09. I − IGRP.10. 2 subnets.0.

0.15.0.63.0.1.250.250.250. 00:08:33.1. 00:05:42.255.0/0 [110/2000] via 203. 00:46:55.255. 2 masks O E2 128.250. Loopback1 C 203.0.213.15.250.250.0 255.0 [110/2000] via 203.1. 01:15:40.14. Serial0 O*E2 0.250.250.15.213. Updated: May 07. 01:20:33.0 is directly connected.255.0 [110/74] via 203.200.250.15.255. 01:20:34.255. All rights reserved.250.252 is subnetted.1.15.15.0 255.255.15.213.15.252 [110/138] via 203.0 is variably subnetted.15. Serial0 O E2 203.13.0 255.0 255.8 is directly connected. 2002 Document ID: 17013 Cisco − BGP Case Studies . [110/75] via 203.255.1.250. Important Notices and Privacy Statement.0 255.250.0. Serial0 203.0. Serial0 O 203. Serial0 O 128.15.1. 2 subnets C 203. 2 subnets. 01:20:33.0 [110/2000] via 203.255. Serial0 O E2 200.0. Serial0 128.1.0 [110/2000] via 203. Serial0 Go to previous section Return to table of contents All contents are Copyright © 1992−−2002 Cisco Systems Inc.