bgp short note file

8/12/2019 BGP Short note file

1/60

Understanding Border Gateway Protocol

Version 4 (BGP-4)

BGP Path Attr ibute

BGP metrics are called Path Attributes Path attributes are used to calculate the best path when multiple paths to the particular

destination exists

BGP attributes are divided into 2 partso Well known attributeso Optional attributes

Well known attributes

Supported by each BGP router i.e attributes are required to be recognized by all BGPimplementation

All well-known attributes are sent to BGP speakers Well-known attributes are further dived into two parts:-

o Well known mandatoryo Well known discretionary

Well known mandatory

Must be include in every single BGP routing table update. These well-known mandatoryattributes are:-

Origin Next-hop AS Path

Origin

When BGP router originates a route, it well set origin attributes.

Origin attributes are:-

IGP :- If ip subnet publish via network statement or via aggregation EGP: - Today nobody in word uses EGP that was in use till 1990 before BGP. BGP is an

EGP but BGP is not a part of EGP

Unknown: - If ip subnet will inject via redistribution it will display via ?in sh ip BGP


2/60

Next-Hop

Ip address of the next hop router to which receiver router will forward packet to the destination

network.

Next hop will change in EBGP on point to point link

Next hop will not change in EBGP on BMA Next hop will not change in EBGP on NBMA Next hop will not change in IBGP

AS-Path

Series or sequence of AS If a router which generate a BGP route then generated network have empty AS-Path

attributes

When a network leaves AS then before leaving router will prepends its own AS to appearfirst in the AS path.Well Known Di scretionary

They are optional, could be present or not in BGP routing updates i.e they are not required.

Basically it depends upon you, if you are the network administrator whether you want to send it

or not. Discretionary are two types:-

Local Preference Atomic aggregate

Local Preference

It is use in BGP route selection process It will move within AS Router prefer route with highest local preference value Default value of local preference is 100 With the help of local preference we can change routing decision of entire local AS

Atomic Aggregate

It is a result of route summarization called aggregationin BGP It will attached with summarized route when BGP router will send update to BGP

speakers

Atomic aggregate will informs router that a route has been summarized


3/60

Optional attr ibutes

Does not have to be supported by all the router manufacturers Optional attributes are private attributes that can be vendor specific. You can create own

router and decide if you want to support BGP or do not want to support some of the

optional attributes

Optional attributes are two types:-o Transitive optional attributeso Non-transitive optional

Transiti ve optional attr ibutes

Continue traveling to the systems whether they are recognized by the router or notes If a router propagates an unknown transitive optional attributes, it will set an additional

bit in the attributes header, known as partial bits to indicates that one of the router in the

path did not recognize the meaning of a transitive optional attributes Transitive optional attributes are two types

o Aggregatoro Community

Aggregator

It will tell you the ip address (RID) and AS of the router that will generate the BGP

summarization or aggregate address

Community

It is use for route tagging i.e identification or masking Community is a numerical values that can be attached to the certain routes as they will

move from the router. Other routes that will receive route with tag, apply filter process

according to task

Non-Transiti ve Optional

Stripped off by the router if does not understand it or does not want to propagate thatattributes

MED is a Non-transitive optional attributesMED (Multi Exi t Discriminator)

Med is useful to influence the BGP route selection process When multiple links are connected between 2 AS. One AS can change the routing policy

of another AS. i.e it can break the GOLDEN RULE OF BGP


4/60

Character istic of BGP

BGP also known as path vector protocol BGP is the most tunable protocol BGP is the slowest protocol BGP use policy base routing BGP is a application layer protocol BGP use tcp port number 179 Automatically neighbors discover is not exist in BGP, you have to define neighbor

statically.

BGP also create 3 tables :-o Neighbor tableo BGP tableo Routing table

Neighbor table contain information of BGP neighbor that can be directly connected orcannot be directly connected

BGP table contain information of network IDS along with BGP attributes Routing table has the best routes In case of BGP after neighbor adjacency BGP table will exchange There is no periodic update in BGP but BGP have batches update, in case of IBGP

batches update timer is 5 sec while in case of EBGP update times is 30 sec

AD of IBGP is 200 and EBGP is 20 Metric of BGP is attributes also known as rich metric

BGP message types is OK NOT UPDATE .o O=open message (a) open sent (b) open confirmo K= keepaliveo Not= notification message

BGP route selection Process

If next hop is unreachable packet will be dropped Highest weight path will be preferred Highest local preference path will be preferred

Originated locally will be preferred Shortest AS path Origin code Lowest MED EBGP over IBGP Closest IGB neighbor (IBGP) Oldest path in EBGP


5/60

Lowest RID Lowest interface IP

When neighborship wil l not formed

If neighbor ip address is not reachable Port number 179 is blocked Wrong AS define

I BGP Implementation

R1#conf t

#router BGP 12

#neighbor 12.1.1.6 remote-as 12

(agar as same hai means IBGP peering)

R2#conf t

#router BGP 12

#neighbor 12.1.1.5 remote-as 12

R1#sh ip BGP summary

12.1.16 v4 .state/prefix (agar state ke neeche kuch nahi likh matlab neighborship)


6/60

BGP route state

Idle Connect Active Open sent Open confirm Establish

State / Prefix receive (agar prefix receive ke neeche 0 hai to matlab koi bhi network receive nahi

hua hai.

#sh ip BGP (it will show BGP table)

Publish network in BGP

R1#conf t

#router BGP 12

#network 192.168.100.0 (BGP me classful network publish karne ke liye subnet mask nahi dena

padta hai

#network 12.1.1.4 mask 255.255.255.252 (classless network publish karne ke liye subnet mask

dena padta hai)

R1# sh ip BGP

*> 192.168.100.0

* ka matlab hai Best aur > is ka matlab hai valid (Best and Valid)

*> jab tak ye dono symbol nahi hogenge BGP router us route ko doosre router ko nahi bhejega.

Jab BGP table me ye dono symbol *> hote hai tabhi wo routing table me bhejega.

IBGP=internal BGP

Jo network khud generate ki jati hai unka weight 32768 hota hai

R2(config-router)#redistribute connected

Popular terms in BGP are as follows:-

IP prefixThis refers to the IP subnet assigned to networks by the official governing bodythat manages IP addresses.

BGP feedThis is a commonly used term for a BGP session that provides reachability


7/60

information of IP prefixes on the Internet. In this context, terms such as full feedandpartial

feedare also used. Full feedrefers to all the Internet prefixes, whereaspartial feedrefers to

a subset of the Internet IP prefixes, based on the traffic requirements.

BGP peerBGP peersand BGP neighborsare terms that refer to network devices in the

same network that run BGP.

Router ID (RID)This is a 32-bit unique identifier representing a BGP speaker. In Cisco

IOS Software, the RID is the highest loopback IP address. When loopbacks are notconfigured, the highest IP address of the interface that is up is taken as the RID. RID can

also be manually configured in Cisco IOS.

Exit pointThis is a router that connects two autonomous systems, and traffic comes inand goes out to Internet through the exit point. In most examples, there will be more thanone router running EBGP for redundancy and for other requirements.

External BGP (EBGP)When BGP is run between two autonomous systems, such a BGPsession is called External BGP (EBGP). EBGP is primarily used in two different environments:- Between ISPs and their customersIn this case, customer IP prefixes are advertised

through BGP to the ISP and the ISP advertises them to the Internet. However, ISP might

advertise full feed or partial feed of the BGP table of the Internet routes to the customer.- Between different ISPs In this case, IP prefixes are advertised to peering ISP

connections. This is how all the Internet is glued together.

Internal BGP (IBGP)A BGP session between two routers in the same AS is called an

IBGP session. Typically, this is between two or more routers.

Internet exchange points (IXP)IXP provides a Real-State in which most, if not all, ofthe big ISPs exchange BGP routes with each other.

BGP peering arrangement In EBGP connections, the two autonomous systems must

agree on the kind of BGP peering. The following are the most popular kinds used in theInternet today:- Transit peeringSuppose that AS A is running EBGP with AS B. If B is configured sothat it will pass all Internet traffic from A, B is a transit provider of A. Typically, B will

provide a full BGP feed to A.- Public peeringAn EBGP session at IXP is called public peering.- Private peeringAn EBGP session on a private link between two autonomous systems is

called private peering. It offloads traffic from public-peering locations that are typicallycongested

Dual or multihomingWhen an AS runs more than one EBGP session with the same ordifferent AS, it is considered dual or mutlihomed to that AS. Dual-homed networks might

have single or multiple routers in the AS. This provides redundant connections to the

Internet and also provides load sharing.

Administrative distance (AD)

Cisco IOS Software assigns an AD to each protocol. ADhas local significance in the router and is not exchanged with any other routers. In CiscoIOS Software, EBGP and IBGP have an AD of 20 and 200, respectively. When a prefix islearned by two different protocols in the same router, AD does the tie breaking and the

lower AD prefix is installed in the IP routing table. Cisco IOS Software also enables you to

reconfigure AD values under the routing protocol command set using the distancecommand.BGP best pathBy definition of RFC 1771, BGP must decide on a single best route out of

many to install in the routing table. If BGP receives multiple advertisements from multiple


8/60

neighbors for the same prefix, it must decide on a single best route through BGP best-path

selection, discussed later in this chapter. It is this best route that BGP installs in the IP

routing table and advertises to other BGP neighbors.

BGP best pathBy definition of RFC 1771, BGP must decide on a single best route out of

many to install in the routing table. If BGP receives multiple advertisements from multiple

neighbors for the same prefix, it must decide on a single best route through BGP best-pathselection, discussed later in this chapter. It is this best route that BGP installs in the IP

routing table and advertises to other BGP neighbors.

Hot potatoA commonly used term for a BGP policy that governs that traffic will exit theAS from the closest exit-point router.

Cold potato A commonly used term for a BGP policy that governs that traffic will bedelivered through the path that is closest to the destination. Optimal routing can be viewed

as cold potato routing.

Figure 14-1shows that AS A, C, and D are running EBGP sessions with AS B. Routers AS

Bnamely, R1, R2, R3, R4, and R5are shown to run IBGP with each other, and they are

fully meshed with each other. AS A is dual homedto AS B for redundancy and loadsharing. AS A has one high-bandwidth link and one low-bandwidth link to AS B. Inaddition, AS B is providing transit services to AS C, and AS C also has a private

peering sessionwith AS D.

Figure 14-1. Sample BGP Network


9/60

Figure 14-1provides a simple view of an ISP B network. All such ISPs connect with each

other to

form this Internet. These ISPs might connect at IXP, or they might have private peeringwith each other, like AS C and AS D do in this figure. Figure 14-1 shows that all

autonomous systems except for AS C must go through AS B to reach other networks. AS Cmay use its private peering link with AS D for all Internet traffic or some other traffic,

depending on the kind of BGP feed (full or partial) exchanged. The kind of BGP feed from ASD to AS C and local BGP policy of C dictates how traffic goes out of the C network. This is

one example of BGP policy. In another example from Figure 14-1, AS A is dual homed withAS B but has one high-bandwidth link and another low-bandwidth link. AS A might use a

high-bandwidth link to its full capacity and might not use low bandwidth at all; AS A can

choose to use a low-bandwidth link for some traffic, and the rest of the traffic can go on thebigger link. All these policies and requirements can be serviced by BGP, and that makes

usage of BGP so important and powerful.

BGP-4 Protocol Specification and Functionality

BGP relies on a reliable transport mechanism to establish its connection and for exchanging

information between BGP peers. BGP uses TCP port 179 for this purpose and benefits fromthe TCP protocol to offer reliable communication between BGP speakers When BGP is

configured with a neighbor IP address, it goes through a series of stages before it reaches

the desired Establishedstate in which BGP has negotiated all the required parameters and iswilling to exchange BGP routes. BGP goes through the following stages of neighbor

relationship,

1. IdleNo BGP resources are allocated in Idle state, and no incoming BGP connections

are allowed.

2. ConnectBGP waits for a TCP connection to be completed. If successful, the BGP statemachine moves into OpenSent state after sending the OPEN message to the peer. Failure in

this state could result in either going into Active state or Connect state, or reverting back toIdle state, depending on the failure reasons.

3. ActiveIn this state, a TCP connection is initiated to establish a BGP peer relationship.If successful, BGP sends its OPEN message to the peer and moves to OpenSent state.Failure can result in going to the Active or Idle states.

4. OpenSentAfter sending an OPEN message to the peer, BGP waits in this statefor the OPEN reply. If a successful reply comes in, the BGP state moves to

OpenConfirm and a keepalive is sent to the peer. Failure can result in sending the BGP

state back to Idle or Active.

5. OpenConfirm

The BGP state machine is one step away from reaching its final state(Established). BGP waits in this state for keepalives from the peer. If successful, the statemoves to Established; otherwise, the state moves back to Idle based on the errors.

6. Established This is the state in which BGP can exchange information between thepeers. The information can be updates, keepalives, or notification.


10/60

Figure 14-3. External BGP Neighbor Relationship Example

There are two ways to configure when peering EBGP: Case 1R1 and R2 are peering with a physical interface. Case 2 R1 and R2 are indirectly connected or they are peering with each other's

loopback interfaces. The peering relationship with R1 and R2 in Case 1 means that the R1

peering IP address is in the same subnet as its own physical interface.

The configuration for this case is as follows:R1#:router BGP 109neighbor 131.108.1.2 remote-as 110

R1 in Figure 14-3has an interface with an IP address of 131.108.1.1. Figure 14-4shows

two scenarios of multihop EBGP sessions indicative of the peering relationship in Case 2. In

this figure, EBGP peering between R1 and R2 is done with each other's loopback addresses.This is typically seen when multiple connections exist between the two autonomous systems

and both links should carry traffic. Either each AS runs two separate BGP neighborrelationships on two separate physical interfaces, or they can configure one BGP neighbor to

the loopback and configure two static routes to reach each other's loopback. The lattermethod is preferable because it saves an extra BGP neighbor relationship.


11/60

Figure 14-4. EBGP Peering Relationship Through Loopback

Interfaces

In Figure 14-5, R3 in AS 110 might not be capable of running BGP, so R1 and R2 must peer

with each going through R3.

Figure 14-5. EBGP Peering Relationship Through a Third-Party

Router


12/60

In both cases of Figure 14-4and Figure 14-5, it is assumed that all routers have reachability

to R1 and R2's loopback addresses. Loopback addresses are used because they are virtual

interfaces and they never go down like physical interfaces do. Even if one physical interfacegoes down, BGP between loopbacks remains up as long as they exist as redundant paths to

each other's loopbacks.

Example 14-1shows a sample configuration of R1 to configure multihop EBGP session.

Example 14-1 Sample Configuration of R1 to Show Multihop EBGPSessionR1#:router BGP 109

neighbor 131.108.10.2 remote-as 110neighbor 131.108.10.2 EBGP-multihop 5neighbor 131.108.10.2 update-source Loopback0

EBGP-multihop 5means that neighbor 131.108.10.2 can be only five hops away from R1,

and the Time To Live (TTL) field in the IP header is set to 5.update-source Loopback0means that all BGP updates are sourced from the Loopback 0 address of R1. R2 uses

131.108.10.1 as the next-hop address for all routes learned through R1.

Internal BGP Neighbor RelationshipsAssume that R1 and R2 belong to the same AS, 109, as shown in Figure 14-6.

Figure 14-6. Internal BGP Neighbor Relationship Example

If R1 and R2 are IBGP neighbors, meaning that they are BGP neighbors in the same AS, theconfiguration cases can be any of the following:Case 1R1 and R2 are peering with a physical interface of each other, and peering is done

with the IP address that belongs to the subnet that they both share. The configuration of R1is as follows:


13/60

router BGP 109neighbor 131.108.1.2 remote-as 109

Case 2R1 and R2 are either indirectly connected or they are peering with each other'sloopback interfaces. The configuration of R1 is as follows:router BGP 109

neighbor 131.108.10.2 remote-as 109neighbor 131.108.10.2 update-source Loopback0

NOTEThe neighbor 131.108.10.2 EBGP-multihopcommand is not needed. In cases of IBGP,the TTL in the IP header is set to 255 in Cisco IOS Software because it is assumed that IBGPneighbors might not be physically directly connected. In addition, an IBGP neighbor

relationship can also be established between loopback addresses that are considered a

multihop away from each other. In case of a physical failure in the network, IBGP can usealternate physical paths, if they exist, to reach the loopback of the BGP neighbor. This way,

IBGP remains intact, even in the case of physical failures along the way.

Advertising RoutesA BGP router can advertise or receive updates from its BGP peer only if it has achieved theEstablished state with its neighbor. A router running BGP will advertise only a prefix to other

neighbors that it is going to use in its routing table. Such a prefix is called the best path

(defined later in the chapter). A rule similar to the split-horizon works in BGP as well. Aprefix learned from a neighbor will not be advertised back to that neighbor if that was thebest route. Cisco IOS Software offers multiple ways to advertise prefixes in BGP. One rule

that BGP follows when advertising prefixes to other neighbors is that the prefix beingadvertised mustexist in the routing table of the advertising router.

In Figure 14-7, R1 advertises 131.108.1.0/24 through BGP to its BGP peer, R2.

Figure 14-7. Route Advertisement


14/60

In Cisco IOS Software BGP, there are three ways to advertise the prefix:Using the network statementAs with other routing protocols, this is the first option.

The following configuration advertises 131.108.1.0/24 through the network statement inR1:router BGP 109network 131.108.1.0 mask 255.255.255.0

131.108.1.0/24 must exist in the routing table of R1; otherwise, 131.108.1.0/24 will not beadvertised in BGP. The maskkeyword followed by the actual mask of the prefix is needed

when subnetted routes are being advertised.Using the redistribute commandIf 131.108.1.0/24 is a connected route in R1's routingtable, the following configuration will advertise 131.108.1.0/24 in BGP:router BGP 109redistribute connectedno auto-summary

With this configuration, all the connected routes, including 131.108.1.0/24, are advertised.

To allow only 131.108.1.0/24 to advertise, BGP must use the filtering mechanism explainedlater in this chapter. Command no auto-summary is used because BGPs by default

advertises redistributed routes to their natural Classful mask. For example, 131.108.1.0/24being a Class B prefix would go as 131.108.0.0/16 without this command.

Using the aggregate statementPrefixes are aggregated or summarized to reduce thenumber of prefix announcements and reduce the size of the routing table. The Cisco IOS

Software aggregatefeature in BGP announces summarized routes. If more specific routesof 131.108.1.0/24 are present in the BGP tablefor example, 131.108.1.128/26the

following configuration advertises 131.108.1.0/24 in BGP:R1#:router BGP 109aggregate-address 131.108.1.0 255.255.255.0

You need to understand two important rules for the setup shown in

Figure 14-8:Rule 1Aggregation or summarization of subnets can happen only if those subnet exist in

BGP table.Rule 2For the aggregated (summarized) route, Cisco IOS installs an IP route with the

next hop to Null0 in the IP routing table. This is done to insure that a valid route exists inthe routing table to annouce it to other BGP peers.


15/60

Figure 14-8. Demonstrating the Rules for AggregatedRoutes/Summarized Subnets

As Figure 14-8illustrates, per Rule 1, R1 has 131.108.1.128/25 and 131.108.1.192/26 in its

BGP table, but it is configured to advertise 131.108.1.0/24 to R2. For Rule 2, when theaggregate-address command is used, Cisco IOS Software automatically installs

131.108.1.0/24 with a next-hop interface of NULL0 in its routing table. The output inExample 14-2 illustrates that R1 is configured to advertise 131.108.1.128/25 and

131.108.1.192/26. R1 is also generating an aggregate of 131.108.1.0/24. The first portion

displays the BGP table to show that all three routes, including the aggregate, are in the BGPtable. The second portion shows the detailed display of the aggregated route in R1. The

third portion indicates that Cisco IOS Software automatically installs a Null0 route for theaggregatestatement.

Example 14-2 Configuration and Output for Setup in Figure 14-8R1#:router BGP 1network 131.108.1.192 mask 255.255.255.192network 131.108.1.128 mask 255.255.255.128aggregate-address 131.108.1.0 255.255.255.0

R1#show ip BGPBGP table version is 5, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 131.108.1.0/24 0.0.0.0 32768 i*> 131.108.1.128/25 0.0.0.0 0 32768 i

*> 131.108.1.192/26 0.0.0.0 0 32768 i_____________________________________________________________________________________R1#show ip BGP 131.108.1.0 255.255.255.0BGP routing table entry for 131.108.1.0/24, version 3Paths: (1 available, best #1, table Default-IP-Routing-Table)


16/60

Local, (aggregated by 1 1.1.1.1)0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate,

best_____________________________________________________________________________________

R1#show ip route 131.108.1.0Routing entry for 131.108.1.0/25

Known via "static", distance 1, metric 0 (connected)Routing Descriptor Blocks:* directly connected, via Null0

Route metric is 0, traffic share count is 1

Null0 is a bit bucket and will not cause any harm for the data traffic because data traffic isswitched based on more specific /25 and /26 routes, not this /24 NULL 0 route. With the

aggregate-address command in Cisco IOS Software, BGP advertises the aggregate and

the subnetted routes as well. Cisco IOS allows a knob in configuration that will suppressthese subnetted routes; only the aggregated prefix will be announced:

R1#router BGP 1aggregate-address 131.108.1.0 255.255.255.0summary-only

Synchronization RuleThis rule in RFC 1771 states that the IGP routing table must be synchronized with the IBGP

routing table. This can happen only if EBGP-learned routes are redistributed in IGP (OSPF)

as the ASBR. The potential of black-holing traffic exists if IGP is not synchronized with IBGP-learned routes. Figure 14-9shows how synchronization rule can black-hole traffic. R2, R3,and R4 are in AS 110 running IBGP and also OSPF. R1 in AS 109 advertises prefix

131.108.1.0/24 through EBGP to R2, which advertises this prefix to R3 and R4; and R4

advertises to its EBGP neighbor R5.

Figure 14-9. Network Traffic Susceptible to Black-Holing


17/60

Assume that all the routers except R3 have processed this BGP update and have installed

the route for 131.108.1.0/24 in their routing tables. If sources behind R5 start sendingtraffic to 131.108.1.0/24, packets arrive at R4, and the R4 routing table might report thatthe next hop to reach 131.108.1.0/24 is through R3. As a result, data traffic arrives at R3

and is dropped because R3 is still processing the update and does not have the route to

reach 131.108.1.0/24. This is called transient black-holingof traffic. Over time, R3 will havethe route and will be capable of passing traffic for 131.108.1.0/24. By the RFC 1771

synchronization rule, R5 should have waited until its IGP (OSPF) would have also receivedthe route for 131.108.1.0/24; then it could have advertised the route to external peer R5 to

attract traffic. Announcing all EBGP routes in IGP requires manual redistribution at ASBR(R1) in this example. R1 must redistribute 131.108.1.0/24 in OSPF so that all routers in AS110 definitely receive the prefix. However, with the size of Internet routing tables today, it

is not possible or scalable to redistribute a full Internet feed into IGP. Therefore, all BGPspeakers running Cisco IOS Software turn off synchronization using the following command:

R2#router BGP 110no Sysnchronization

Transient black-holing can still happen, but by turning off synchronization, IGP is notrequired to carry full BGP routes. In cases where some routers are not running BGP and

they are in transit path of the IBGP neighbor, synchronization cannot be turned off and BGP

must be redistributed in the IGP.

Receiving RoutesIn BGP, if the BGP peer is in the Established state, no additional configuration is needed toreceive routing updates. BGP will accept all the updates from the peer, provided that thoseupdates pass the necessary checks for packet format and filters.

Policy Control


18/60

Policy control means that BGP provides power to control prefix filtering and manage IP

traffic flow into and out of the BGP network. BGP policies can flow downstream and affect

policy of those autonomous systems to which routes are being propagated. In a large BGPnetwork that is divided into multiple regions, special requirements must be met in terms of

what type and how much traffic can flow in and out of each region. BGP policy control givesnetwork operators a highly scalable way of maintaining traffic flows. BGP policies are

defined by BGP attributes that consist of the following:

LOCAL_PREF AS_PATH MULTI_EXIT_DISC (MED) ORIGIN NEXT_HOP ATOMIC_AGGREGATE AGGREGATOR

Figure 14-10. Network Designed to Take Advantage of BGP Routing

Policies

Single BGP AS is divided into multiple regions. Traffic flows from source to destination,

crossing multiple regions based on the BGP policy defined. In Figure 14-10, it seems morelogical that traffic from source to destination travels Region 1, Region 2, and Region 3, and

then to the final destination because that seems to be the shortest path from source to


19/60

destination. Region 2, however, is configured with a BGP policy that shifts traffic from

Region 2 to Region 4 instead. Network architects design and decide on such policies when

traffic takes a longer path. Factors such as bandwidth availability, congestion, routercapacity, and many others play a significant role in the definition of these policies. How is a

BGP policy created? Manipulation of BGP attributes defines BGP policies. Packet forwardingin a router happens from the routing table and BGP policy dictates which route of many is

chosen to go in the routing table.

Figure 14-11illustrates a simple example of policy control in the case of EBGP.

Figure 14-11. BGP Policy Control Example

AS 109 network administrators require a BGP policy so that, as shown in destined to131.108.1.0/24 from AS 109 must use the R1R3 link. The R1R2 link should be used as a

backup. This can happen only if routing tables in all the devices of AS 109 show R1R3 asthe exit point and if the path through R2 is present in the BGP table and not in routing table

of R1. The method of choosing one path over the other is accomplished by manipulating the

right BGP attribute. In Figure 14-11, R1 learns two paths to reach 131.108.1.0/24one


20/60

through R2 and the other through R3. R1 must pick the path through R3 because of the

required BGP policy, and BGP attributes must be changed so that the path from R3 becomes

more attractive than the path from R2. When that happens, IP traffic (after following therouting table) flows from all devices in AS 109 to exit through R3 to reach 131.108.1.0/24.

The following sections explain using the BGP attributes and the methods of changing themto define BGP policies.

Policy Control Using BGP AttributesBGP picks a best path for a destination IP prefix from multiple paths and then installs it in

the routing table. This best path forwards IP traffic. By default, BGP does a decent job ofchoosing the appropriate path; however, with the huge size of router-based networks, it is

essential that BGP path selection be managed by network operators to have a BGP policythat optimally uses the network. BGP attributes are often manipulated to manage BGP

networks. Examples of most commonly used BGP attributes are listed here: LOCAL_PREF AS_PATH MULTI_EXIT_DISC (MED) ORIGIN

NEXT_HOP WEIGHT (WEIGHT is not a BGP attributeit is a Cisco proprietary attribute)

The sections that follow describe these BGP attributes in greater detail and describe how tomanipulate them for BGP policy control, where applicable.

LOCAL_PREF Attribute

A 32-bit non-negative integer value of LOCAL_PREF in BGP updates defines a preference of

one exit point within an AS over others to reach the originator of the route. LOCAL_PREFhas no significance outside an AS; therefore, it affects only the outgoing traffic from an AS.

LOCAL_PREF is not advertised to EBGP neighbors and is propagated to only IBGP neighbors.Figure 14-12explains how LOCAL_PREF is handled in networks running BGP.

Figure 14-12. LOCAL_PREF Attribute Operation in BGP Networks


21/60

R1 in AS 109 is advertising 131.108.1.0/24 to its EBGP neighbors R2 and R3 in AS 110. BGPupdates sent to EBGP neighbors do not contain LOCAL_PREF. In Cisco IOS Software,

LOCAL_PREF is given a default value of 100 for all the prefixes learned from EBGP

neighbors. Cisco IOS Software also allows the user to configure LOCAL_PREF, as shownlater in this chapter. As the link between R1 and R2 is bigger than the link from R1 to R3, it

is likely desired that traffic from AS 110 to AS 109 use the R1R2 link rather than the R1

R3 link. Therefore, R2 is configured so that it changes the LOCAL_PREF to 200 for all the

prefixes that it learned from R1. Because LOCAL_PREF is advertised to all IBGP neighbors,R3, R4, and R5 receive 131.108.1.0/24 with a LOCAL_PREF of 200 from R2. R3 has anadditional path for 131.108.1.0/24 from R1, and its LOCAL_PREF was unchanged and is

defaulted to 100. Now, R3 must decide between two paths for 131.108.1.0/24, one from R1and the other from R2. As explained later in the discussion of best-path calculation of BGP,

the path with the higher LOCAL_PREF wins; therefore, the path from R2 will win and getinstalled in the routing table for R3. Similarly, R4 and R5 will choose R2 to reach

131.108.1.0/24. In Figure 14-12, R4 and R5 are receiving only one path for131.108.1.0/24, and that is from R2. If they were receiving multiple paths from multiple

IBGP neighbors, they would have decided on the best path based on a higher LOCAL_PREF,just like R3 did. When R6 in AS 111 is sending traffic for 131.108.1.1, it exits AS 110 from

R2 because AS 110 has preferred R2 as an exit point for 131.108.1.0/24. Figure 14-12explains that LOCAL_PREF plays a significant role in managing outgoing traffic from AS 109

to destinations outside AS 109.Example 14-3shows the configuration needed to manipulatethe LOCAL_PREF attribute in R2, as illustrated in Figure 14-12.

Example 14-3 Configuring the LOCAL_PREF AttributeR2#router BGP 110neighbor 1.1.1.1 remote-as 109neighbor 1.1.1.1 route-map SET_LOCAL_PREF in


22/60

route-map SET_LOCAL_PREF permit 10match ip address 1set local-preference 200

route-map SET_LOCAL_PREF permit 20match ip address 2

access-list 1 permit 131.108.1.0access-list 2 permit anyThe IP address of R1 in AS 109 is 1.1.1.1. SET_LOCAL_PREF is the route map that is appliedon an EBGP session with R1. The route map usage is defined in detail in Chapter 1,

"Understanding IP Routing." The first sequence of the route map has a matchstatementagainst access-list 1 that permits 131.108.1.0/24. The set command configures theLOCAL_PREF to 200 for prefixes that pass access-list 1. The second sequence of the route

map is necessary to allow all other prefixes from this neighbor without changing the

LOCAL_PREF. After this configuration in R2, the output of the BGP table for prefix131.108.1.0/24 from R2 and R3 looks like Example 14-4.

Example 14-4 BGP Output of the Prefix 131.108.1.0/24 AfterLOCAL_PREF Change

R2#show ip BGP 131.108.1.0BGP routing table entry for 131.108.1.0/24, version 8Paths: (1 available, best #1)

Advertised to non peer-group peers:1.1.8.3

109

1.1.7.1 from 1.1.7.1 (10.1.1.1)Origin IGP, metric 0, localpref 200, valid, external, best

_____________________________________________________________________________________


Not advertised to any peer1091.1.7.1 (metric 307200) from 1.1.8.2 (10.0.0.5)

Origin IGP, metric 0, localpref 200, valid, internal, best109

1.1.2.1 from 1.1.2.1 (10.1.1.1)Origin IGP, metric 0, localpref 100, valid, external

R3 has two updates, one from R1 and the other from R2. The path from R2 is selected as

the best path because of the higher LOCAL_PREF.

MULTI_EXIT_DISC (MED) Attribute

A 32-bit non-negative integer value of MED in BGP updates defines a method to choose

among multiple exit points in the same neighboring AS. MED is a nontransitive attribute of

BGP; therefore, if it is received from an EBGP neighbor, it is sent to an IBGP neighbor, but itdoes not get propagated to other EBGP neighbors. Figure 14-13explains the usage of MED.

In AS 109, RI has two links to AS 110. The link between R1 and R2 has a higher bandwidth


23/60

than the link between R1 and R3. Therefore, R1 might decide that all traffic destined to

131.108.1.0/24 must exit AS 110 through the R1R2 link, not the R1R3 link.

Figure 14-13. MULTI_EXIT_DISC (MED) Attribute Operation in BGPNetworks

A lower MED value is preferred when comparing the two updates. In Cisco IOS Software,

MED is compared only between updates from within the same AS. To compare MED valuesin updates from different autonomous systems, Cisco IOS Software must be configured withBGP always-comparemed in BGP subcommands. The AS 109 policy dictates that all traffic

destined for 131.108.1.0/24 should come through the R1R2 link and that the R1R3 linkshould be used as a backup in case the R1R2 link goes down. To achieve this, R1advertises 131.108.1.0/24 to both neighbors in R2 and R3 in AS 110. However, R1 should

advertise a lower MED value to R2 than to R3.Example 14-5shows a sample configuration

of R1 to achieve the goal.

Example 14-5 Configuring the MED Attribute

R1#router BGP 109

neighbor 1.1.7.2 remote-as 110neighbor 1.1.7.2 route-mapSEND_LOWER_MEDoutneighbor 1.1.2.3 remote-as 110neighbor 1.1.2.3 route-mapSEND_HIGHER_MEDout

route-mapSEND_LOWER_MEDpermit 10match ip address 1

setmetric 10


24/60

!route-mapSEND_LOWER_MEDpermit 20match ip address 2

route-mapSEND_HIGHER_MEDpermit 10match ip address 1set metric 20

!route-mapSEND_HIGHER_MEDpermit 20match ip address 2

access-list 1 permit 131.108.1.0access-list 2 permit any

1.1.7.2 and 1.1.2.3 are two neighbors of R1. They are both configured with route maps toadvertise a MED of 10 and 20, respectively, for the prefix 131.108.1.0/24. This occurs in

sequence 10 of the route map. Sequence 20 permits all other prefixes, if any, advertised

from R1 to R2 and R3, and no MED changes were applied to them. Example 14-6shows theoutput of R3 and R2 after this configuration change in R1.

Example 14-6 Output of BGP Table from R3 and R2 After the MED

Advertisement from R1


Not advertised to any peer109


1091.1.7.1 from 1.1.8.2 (10.0.0.5)

Origin IGP, metric 10, localpref 100, valid, internal, best_____________________________________________________________________________________R2#show ip BGP 131.108.1.0

BGP routing table entry for 131.108.1.0/24, version 10Paths: (1 available, best #1)

Advertised to non peer-group peers:1.1.8.3


With this configuration, the prefix 131.108.1.0/24 MED field looks like the following in R2

and R3:In R2, MED = 10 for the path from R1.In R3, MED = 10 for the path from R2; MED = 20 for the path from R1.

R2 has only one path for 131.108.1.0/24, whereas R3 has two. This is because R2 is

advertising its best route to all its IBGP neighbors (R3, R4, and R5, in this example). R3's

best path for 131.108.1.0/24 is from R2, so R3 will not advertise its best path back to R2because that path originally came from R2.


25/60

Because the lower MED wins in BGP best-path calculation, in R3, the path from R2 wins over

the path from R1. Thus, all traffic from autonomous system 110 for 131.108.1.0/24 will exit

through R2.

MED is a nontransitive attribute and will not be advertised to AS 111 by AS 110. R5 and R6might configure to advertise the same or different MED to R6 in AS 111, but the MED value

originally set by R1 in AS 109 will not be kept.

Because of the BGP MED policy of R1, traffic from R6 in AS 111 to 131.108.1.1 in AS 109will exit from R2, not from R3 in AS 110. The MED attribute plays a significant role in

influencing incoming traffic in case multiple connections exist between the same AS. The

example in Figure 14-13is most commonly seen in enterprise BGP networks where routersin AS 109 are dual homed to an ISP in AS 110.

In Cisco IOS Software, MED is compared only between updates from within the same AS. InExample 14-5, R3 compared MEDs because 131.108.1.0/24 came from the same AS 109.To compare MED values in updates from different autonomous systems, Cisco IOS Software

must be configured with BGP always-compare-medin BGP subcommands. Figure 14-14

shows a more complex example, as seen in ISP networks advertising MED to other ISP.

Figure 14-14. MULTI_EXIT_DISC (MED) Attribute Operation Between

ISPs


26/60

AS 109 has two regional connections, east and west, with AS 110. AS 109 needs to make

sure that regional traffic destined to AS 109 regions must enter through their respective

regional links. This can be accomplished by defining the following:

AS 109 must advertise the proper MEDs, as shown in Figure 14-14. AS 110 must honor AS 109 MED announcements.

The first task is achieved through the configuration shown later in this chapter. The second

task is more of a peering agreement between AS 109 and AS 110. Honoring MED meansthat AS 110 must accept the MED announcements from AS 109 and will not overwrite themwith its own policies. Honoring MED is typically a two-way relationship: AS 110 honors AS

109 MED only if AS 109 does the same for AS 110 MED. By honoring the MED, AS 110carries traffic destined to AS 109 through its backbone and exits at the closest point in AS109. If AS 110 decides not to honor AS 109 MED, it will have its own policies to carry traffic

for AS 109. Instead of an optimal exit point, AS 110 might choose the closest exit point.

Figure 14-15shows how traffic flows in AS 110 when it honors the MEDfrom AS 109.

Figure 14-15. MULTI_EXIT_DISC (MED) Attribute Operation Between

ISPs


27/60

Traffic sourcing behind R2 destined for 140.1.1.1 will traverse AS 110 backbone routers

because they have all received the proper MED announcement from AS 109 as the MED ispropagated within the IBGP cloud. This traffic exits AS 110 at R5, the exit point closest to

the destination, 141.1.1.1. Similarly, traffic behind R4 destined for 131.108.1.1 exits atR3.In some situations, ISPs do not honor each other's MEDs. In this case, AS 110 mightdump all traffic destined to AS 109 to its closest exit point and not carry its traffic through

the backbone. Such an example can arise when traffic destined to 140.1.1.1 from sourcesbehind R2 carries over to R3 and exits to R1; AS 109 must carry that traffic across itsbackbone to reach R6 in the east region. Proper usage of the MED attribute can also be

called cold potato routing(defined earlier in the chapter).

AS_PATH AttributeThe AS_PATH attribute defines the list of autonomous systems through which a BGP update

has traversed. It is a mandatory attribute that BGP updates must carry, and it is changedonly when a BGP update is sent to an EBGP neighbor. Figure 14-16 explains how the

AS_PATH attribute works.

Figure 14-16. AS_PATH Attribute Operation in BGP Networks


28/60

AS 109 is advertising 131.108.1.0/24 to its EBGP neighbor in AS 110. The BGP speaker

must prepend its AS number at the left-most position in the AS_PATH attribute field, whilesending an update to its EBGP neighbor. R1 prepends its AS number 109 in that field. R2advertises this update to its IBGP speakers R3 and R4 but does not change the AS_PATH.

R3 and R4 prepend their AS 110 when advertising this prefix to AS 111. When a router

receives a BGP update that has an AS_PATH attribute that lists its own AS in it, that updateis considered looped and is dropped. This mechanism is used in BGP to detect routing loops.A smaller AS_PATH length is preferred when comparing the two BGP updates. Refer back tothe network topology in Figure 14-13. AS 109 wants to define a BGP policy so that all traffic

destined to 131.108.1.0/24 from AS 110 must enter through the R2

R1 link, and the R3

R1link should be used as a backup. Visualizing that in R2, R3, and R4 (all in AS 110), theAS_PATH field for the prefix 131.108.1.0/24 is 109. R3 has two paths for this prefix, one

from R1 and the other from R2. The best-path calculation rule will tie because the AS_PATHlength is identical, at 1. BGP Best-path calculation moves down to next tie-breaking criteria,

per the best-path calculation rule described in this chapter. Example 14-7demonstrateshow R1 can achieve its goal of preferring the R1R2 link over the R1R3 link for traffic

destined to 131.108.1.0/24/.

One approach is to use MEDs so that R1 advertises a lower MED when advertising prefix

131.108.1.0/24 to R2 and advertises a higher MED to R3. Another approach is to make the

AS_PATH length longer for the advertisement from R1 to R3 for this prefix. Because the BGPbest-path calculation rule looks at AS_PATH length as the tie-breaker rule between multiple

paths, the R1R3 path will lose and the R1

R2 path will win and be installed in the routing

table. Example 14-7shows the configuration needed in R1 to achieve this.

Example 14-7 Using the AS_PATH Attribute on R1 to Dictate the BestPathR1#


29/60

router BGP 109network 131.108.1.0 mask 255.255.255.0neighbor 1.1.2.3 remote-as 110neighbor 1.1.2.3 route-map AS_PREPEND outneighbor 1.1.7.2 remote-as 110

route-map AS_PREPEND permit 10match ip address 1set as-path prepend 109 109

!route-map AS_PREPEND permit 20match ip address 2

access-list 1 permit 131.108.1.0access-list 2 permit any

1.1.2.3 is the R3 IP address, and route-map AS_PREPENDis configured in R1 for R3 toincrease the length of the AS_PATH attribute by prepending AS 109 twice in the list. route-

map AS_PREPEND sequence 10 has a match clause that makes sure that only

131.108.1.0/24 gets this prepended AS_PATH, and sequence 20ensures that the rest ofthe prefixes from R1 to R3 remain unchanged. Access lists 1 and 2 are defined to achieve

that. After this configuration, R3 has two updates for prefix 131.108.1.0/24, one from R2and another from R1 with the prepended AS_PATH. R2 just has a single update from R1.

Example 14-8shows the output for R3 and R2.

Example 14-8 show ip BGP Output from R3 and R2 After AS_PATH

Manipulation in R1


Not advertised to any peer109 109 109


1091.1.7.1 from 1.1.8.2 (10.0.0.5)

Origin IGP, metric 0, localpref 100, valid, internal, best_____________________________________________________________________________________R2#show ip BGP 131.108.1.0BGP routing table entry for 131.108.1.0/24, version 6Paths: (1 available, best #1)

Advertised to non peer-group peers:

1.1.8.3109


For prefix 131.108.1.0/24, the AS_PATH field looks like the following in R2 and R3:In R2, AS_PATH = 109 for path from R2In R3, AS_PATH = 109 109 109 for path from R1; AS_PATH = 109 for path from R2


30/60

Because in R3 the AS_PATH length of an update from R1 is (3) and from R2 is (1), R3 picks

the path from R2 over the path from R1. This way, all traffic from AS 110 destined for

131.108.1.0/24 in AS 109 would exit through R2. R2 has only one path for 131.108.1.0/24,whereas R3 has two. This is because R2 is advertising its best route to all its IBGP neighbors

(R3, R4, and R5, in this example). R3's best path for 131.108.1.0/24 is from R2, so R3 doesnot advertise its best path back to R2 because it originally came from R2.

The AS_PATH prepend technique to influence incoming traffic is used in cases when AS 110

does not honor MEDs from AS 109, or when AS 109 is dual homed to different ISPs.Typically, Enterprise BGP networks use the AS_PATH prepend technique with their ISPs

because the number of prefixes that they advertise are small and can be easily managed, as

showed in Example 14-7. In ISP networks in which the number of prefixes is in themagnitude of thousands, managing AS_PATH per prefix does not scale well; therefore, ISPs

rely on LOCAL_PREF, MED, and WEIGHT to manage their traffic. ISP might use AS_PATH

prepend in packets to solve temporary problems but typically does not deploy this as astandard, widely used policy.

By observing the AS_PATH, a BGP speaker can find out which AS originated the prefix and

how many autonomous systems this prefix has traversed. The right-most AS is theoriginator of the prefix and the left-most is the neighboring AS that has announced the

prefix. The middle autonomous systems in the AS_PATH are the intermediate autonomous

systems that the prefix has traversed. Such an order of AS_PATH is called anAS_SEQUENCE,in which AS_PATH sequence is in the order that it has maintained.

Another form of AS_PATH attribute,AS_SET,can be explained if AS 110 aggregates routes

learned from AS 109 and other autonomous systems and announces a prefix that containsall the listings of autonomous systems, but the order of AS_PATH is not maintained. For

example, AS 110 is aggregating 131.108.1.0/24 and 131.108.2.0/24 to 131.108.8.0/26 andadvertised to AS 111. The /24s were learned from AS 109 and AS 108. AS 110 might

choose to configure AS_PATH as AS_SET. Such an AS_PATH might look like this:

The order of AS 108 and AS 109 is not preserved. AS_SEQUENCE is the default behavior ofBGP, whereas AS_SET is a configurable option in Cisco IOS Software.

NEXT_HOP AttributeThe IP address of the border router should be used as a next hop to reach prefixes

propagated by that border router. This could be an IP address that belongs in the same ASor it could be an external IP address that shares the same subnet as that on a borderrouter. NEXT_HOP is typically learned through an Interior Gateway Protocol (IGP), such as

OSPF or IS-IS, and the cost to reach the NEXT_HOP often plays an important rule in

calculating the best path. Referring back to Figure 14-16, in AS 110, the NEXT_HOP for131.108.1.0/24 is the IP address of the R1 subnet that connects to R2. The NEXT_HOP

attribute is not changed throughout the AS. Cisco IOS allows the user to change the

NEXT_HOP to be the IP address of an internal border router instead of an external address,such as Loopback of R2. This is done by using the neighbor IBGP-NeighborIP-addressnext-hop-self command in BGP. By changing NEXT_HOP from an external address to the

loopback, routers carry one less subnet in the routing table. Because loopback IP addressesare carried in IGP, no additional work is needed to propagate the NEXT_HOP.ORIGIN AttributeThe originator of the BGP update generates the ORIGIN attribute and defines how theoriginal path was originated. Each prefix has an ORIGIN attribute. Routers, which receive

updates with the ORIGIN attribute, should forward the ORIGIN attribute to all BGP


31/60

neighbors unchanged. Table 14-1describes the meaning of the different ORIGIN attribute

codes and explains how these prefixes were originated.

Table 14-1. ORIGIN Attribute Codes

WEIGHT is a 4-byte integer number and is not a BGP attribute because it is not defined in

RFC 1771. It is a Cisco Systems, Inc. proprietary attribute that has priority over all other

BGP attributes when doing the best-path calculation in Cisco IOS Software. WEIGHT is notshared with any BGP neighbor because it has local significance in the router and because

the neighboring router might not understand Cisco's proprietary attribute.

Because WEIGHT has local significance in the router, it does not affect neighboring routers'BGP policy, as in the case of LOCAL_PREF and MED that gets shared among other routers in

the AS, and all the AS is affected when using those attributes. Figure 14-17explains the useof WEIGHT. AS 109 has three exit points and connects to three different ISPs. AS 109 haslow-bandwidth links in its Core, so therefore AS 109 would like to have BGP policy that

makes minimal use of the Core. This can happen if each exit router chooses all the prefixes

from its corresponding connected ISP as the best route. In Cisco IOS Software, if R1, R2,and R3 assign WEIGHT to all the prefixes learned from ISP1, ISP2, and ISP3, respectively,R1, R2, and R3 choose ISP1, ISP2, and ISP3, respectively, for all Internet routes. Traffic

originated from the source connected to R1 always exits through ISP1, as shown in Figure14-17. This way, the core of AS 109 never carries any Internet traffic unless a BGP sessionwith an ISP fails anywhere.


32/60

Figure 14-17. Usage WEIGHT to Avoid Using the IBGP Core

Such BGP policy is also called hot Potato routing,as defined in the introductory portion of

the chapter. Referring back to the network topology in Figure 14-13, AS 110 decided on aBGP policy stating that R3 should use R3R1 link to reach 131.108.1.0/24 advertised by R1.

Any policy change in R2 (LOCAL_PREF and so forth) should not affect R3 policy. The easiestway to accomplish this is to assign WEIGHT in R3 on the prefix 131.108.1.0/24 received

from R1. Example 14-9shows the configuration needed in R3 to assign WEIGHT.

Example 14-9 Sample Configuration of R3 to Assign WEIGHTR3#router BGP 110no synchronization

neighbor 1.1.2.1 remote-as 109neighbor 1.1.2.1 route-map SET_WEIGHT inneighbor 1.1.8.2 remote-as 110

route-map SET_WEIGHT permit 10match ip address 1set weight 2000

!route-map SET_WEIGHT permit 20


33/60

match ip address 2access-list 1 permit 131.108.1.0access-list 2 permit any

1.1.2.1 is the IP address of R1 in AS 109. SET_WEIGHT is the route map that is applied onan EBGP session with R1. The route map usage is defined in detail in Chapter 1. The first

sequence of route- map 10has a matchstatement against access-list 1,which permits131.108.1.0/24. The set command configures the WEIGHT to 2000 for prefixes that passaccess-list 1. The second sequence of the route map is necessary to allow all otherprefixes from this neighbor without changing the WEIGHT. Example 14-10shows the output

from R3 after setting the WEIGHT.

Example 14-10 WEIGHT Assignment Shown in BGP OutputR3#show ip BGP 131.108.1.0BGP routing table entry for 131.108.1.0/24, version 11Paths: (2 available, best #1)

Advertised to non peer-group peers:

1.1.8.2109

1.1.2.1 from 1.1.2.1 (10.1.1.1)Origin IGP, metric 20, localpref 100, weight 2000, valid, external, best

1091.1.7.1 from 1.1.8.2 (10.0.0.5)Origin IGP, metric 10, localpref 100, valid, internal

R3 has two paths for 131.108.1.0/24, one from R1 and the other from R2. Even though thepath from R2 has a MED of 10, R3 prefers the path from R1 because of the WEIGHT

assignment. In bestpath calculation, WEIGHT has the highest priority over all other

attributes. With WEIGHT, R3 uses the R1R3 link for traffic destined to 131.108.1.0/24 fromR3. The rest of AS 110 follows BGP policy defined in other routers to determine the path to

reach 131.108.1.0/24.

Reading BGP Attributes from Cisco IOS Software OutputThis section demonstrates how BGP attributes are read from the outputs of showcommands in the Cisco IOS Software. Example 14-11shows the sample output of a BGPprefix received from an EBGP peer. Example 14-11 is from route-server.cerf.net.

Example 14-11 BGP Update from an EBGP Peershow ip BGP 3.0.0.01740 701 80


Table 14-2lists the BGP attributes shown in Example 14-11.

Table 14-2. Explanation of BGP Attributes in Example 14-11


34/60

A MED of 20 means that neighbor 192.41.177.69 configured its BGP policy to send the MED

of 20. Example 14-12shows sample output of a BGP prefix received from an IBGP peer.Example 14-12is from MAE-West Looking Glass of InterMedia.

Example 14-12 BGP Update from an IBGP Peershow ip BGP 198.133.219.01 109

4.24.7.77 (metric 90200) from 165.117.1.127 (165.117.1.127)Origin IGP, metric 40, localpref 100, valid, internal, bestCommunity: 1:1000 2548:183 2548:234 2548:666 3706:153

Table 14-3lists the BGP attributes shown in Example 14-12.


35/60

Table 14-3. Explanation of BGP Attributes in Example 14-12

A MED of 40 means that either the IBGP neighbor 165.117.1.127 or the EBGP neighbor

4.24.7.77 of 165.117.1.127 configured its BGP policy to send the MED of 40. Later in this

chapter, communities are discussed.

Use of Route Maps in Policy ControlRoute maps are used extensively in BGP when it comes to managing policies. The routemap might contain matchand setstatements. The matchstatement matches a specificvalue, such as an IP prefix. The set statement changes BGP attributes. The route map

feature is mainly used with one of the following statements: aggregate, neighbor,

network,or redistribute. Example 14-13demonstrates a sample route map.

Example 14-13 Sample Route Map Used for Policy Control


36/60

router BGP 2neighbor A remote-as 1

neighbor A route-map test outroute-map test permit 10match ip address 1set metric 20

!route-map test permit 20match ip address 2

access-list 1 permit 131.108.1.0

access-list 2 permit any

The match ip address 1 statement examines access list 1, which allows only the prefix

131.108.1.0/24 to go to the set metric 20command. The remaining prefixes go throughwithout any additional modification in the route-map test permit 20 statement, which

examines accesslist 2, which permits all prefixes and sets no attribute.

The following sections explain and demonstrate the most common match and setstatement in route maps when used with BGP.

Using the match ip address Command in a Route Map

View the different options available for the match ip address command by entering the

following:match ip address ?

1-199 IP access-list number1300-2699 IP access-list number (expanded range)WORD IP access-list nameprefix-list Match entries of prefix-lists

Example 14-14demonstrates applying the match ip addressstatement to a route map.

Example 14-14 Using the match ip address Statement in a Route Maproute-map test permit 10match ip address 1access-list 1 permit 131.108.1.0

Using the match community Command in a Route MapWhen prefixes contain communities, you should use a route map with the match

community command to examine the prefix that has the communities configured.View the different options available for the match communitycommand by entering the

following:

match community ?1-99 Community-list number (standard)100-199 Community-list number (extended)exact-match Do exact matching of communities

Example 14-15demonstrates applying the match communitystatement to a route map.

Example 14-15 Using the match community Statement in a RouteMaproute-map test permit 10


37/60

match community 1ip community-list 1 permit 1:1

match community 1means that it will examine community-list filter 1,which permitsprefixes that have community 1:1 configured. Later, this chapter describes communities in

depth.

Using the match as-path Command in a Route Map The AS_PATH attribute in the BGP table is viewed as a text string; therefore, UNIX-like

regular expressions can examine the beginning, end, or middle content of the string.AS_PATH filters are commonly used on Internet routers running BGP. Instead of listing each

prefix in an access list, you can configure Cisco IOS Software to match against all the

prefixes that came in from AS 109.

Similarly, AS_PATH filter can be configured to pass only prefixes that have an AS_PATH

equal to 109.View the different options available for the match as-path command byentering the following:

match as-path ?

1-199 AS path access-listExample 14-16demonstrates applying the match as-pathstatement to a route map.

Example 14-16 Using the match as-path Statement in a Route Maproute-map test permit 10match as-path 1

ip as-path access-list 1 permit ^109$

Here, as-path access-list 1permits all prefixes that have the AS_PATH field equal to 109.All other prefixes are denied. Usage of regular expression is powerful and complex. You are

encouraged to read the Cisco IOS Software documentation before using regular expressions

in your access lists. Table 14-4explains some commonly used regular expressions and theirusage.


38/60

Table 14-4. Common Regular Expressions in Access Lists

set as-path prepend is used when the AS_PATH attribute is changed. This commandprepends the AS number(s) listed in the SET command. Usage of AS_PATH prepends is

discussed in detail earlier. View the different options available for the set as-pathprepend

command by entering the following:set as-path prepend ?

1-65535 AS number

Using the set community Command in a Route MapCommunities are assigned to prefixes using the set community command in the routemap. A matchstatement before set communityassigns communities only to prefixes that

pass the match. Without the match statement, all prefixes will be assigned with

communities configured. View the different options available for the set communitycommand by entering the following:set community ?

1-4294967295 community numberaa:nn community number in aa:nn formatadditive Add to the existing communitylocal-AS Do not send outside local AS (well-known community)


39/60

no-advertise Do not advertise to any peer (well-known community)no-export Do not export to next AS (well-known community)

none No community attribute

Using the set local-preference Command in a Route MapView the different options available for the set local-preferencecommand by entering the

following:set local-preference ?

0-4294967295Preference value

Using the set metric Command in a Route Map View the different options available for the set metriccommand by entering the following:set metric ?

+/-metric Add or subtract metric0-4294967295 Metric value or Bandwidth in Kbits per second

Using the set weight Command in a Route MapView the different options available for the set weightcommand by entering the following:

set weight ?0-4294967295Weight value

Policy Control Using filter-list, distribute-list, prefix-list, Communities,and Outbound Route Filtering (ORF)

Cisco IOS Software offers powerful configuration tools for managing advertising andreceiving prefixes in BGP. Network operators running BGP must have configuration options

to filter what comes in and what goes out in BGP updates from their network. The following

sections discuss the capabilities offered by Cisco IOS Software to control BGP prefixes in ascalable manner by using filter lists, distribute lists, prefix lists, communities, and ORF.

Use of Filter Lists in Policy ControlFilter lists permit or deny BGP updates based on the AS_PATH attribute. Filter lists are used

per the neighbor statement inbound, outbound, or both. Example 14-17 demonstratesconfiguring a filter list for policy control.

Example 14-17 Configuring a Filter Listrouter BGP 110

neighbor 131.108.10.1 remote-as 109neighbor 131.108.10.1 filter-list 1 in

ip as-path access-list 1 permit ^109$

The ip as-pathstatement uses UNIX-like regular expressions, and it is examined against

the AS_PATH attribute in the BGP update. In this example, all incoming updates from

neighbor 131.108.10.1 are examined against as-path 1, which is configured to permitupdates with the AS_PATH attribute equal to 109.

AS_PATH filters are scalable because, for example, ^109$ covers all the prefixes andavoids an otherwise lengthy access list, which would involve listing all the prefixes.

Use of Distribute Lists in Policy ControlLike filter lists, distribute lists are used per neighbor statement inbound, outbound, orboth. They operate on IP access lists. In distribute lists, prefixes are permitted or denied

based on the networks listed in the access list. Example 14-18makes use of standard IP


40/60

access list 1 used with a distribute list. In standard access lists, a router makes the

filtering decision based on the prefix network, not based on its mask. Extended access lists

enable not only network filtering, but also filtering based on the mask of the prefix.

Example 14-18 Using Distribute Lists in a Standard IP Access List

R2#

router BGP 110neighbor 131.108.10.1 remote-as 109neighbor 131.108.10.1distribute-list 1 inaccess-list 1 permit 131.108.1.0 0.0.0.255

Example 14-18uses standard IP access-list 1with a distribute list configured for neighbor131.108.10.1 inbound. All prefixes that this neighbor advertises to R2 are checked againstaccess-list 1,which permits network 131.108.1.0. This network could have a mask of /24,

/25, and so on because the standard access list offers no checking for a mask. Example 14-

19makes use of extended IP access lists.

Example 14-19 Using Distribute Lists in an Extended IP Access Listrouter BGP 110neighbor 131.108.10.1 remote-as 109neighbor 131.108.10.1 distribute-list 101 inaccess-list 101 permit ip 131.108.1.0 0.0.0.0 255.255.255.0 0.0.0.0

In standard access lists (1 to 99), the wildcard mask can be applied only on the prefix, noton its mask, whereas, in extended access lists, the subnet mask of the BGP update also canbe checked against the access list. When used in BGP for filtering as in this example, the

syntax of extended access lists has a different meaning. Extended access lists, when used in

interface packet filtering, have a source address portion and a destination address portion.When extended access lists are used with BGP distribute lists, the source address portion is

the network number and the destination portion is the mask of that network.

Therefore, for access-list 101,when used in BGP, the distribute list can also be read asfollows:permitIP Prefix wild-card-for-prefix Mask_of the_prefix wild-card-for-maskaccess-list 101 in Example 14-19 permits 131.108.1.0 only with the mask of255.255.255.0. Refer to Chapter 1or the Cisco IOS Software documentation for a more in-

depth explanation of standard and extended access lists.

Use of Prefix Lists in Policy Control

Prefix lists replace distribute lists because they offer user-friendly configuration optionswhen filtering based on IP prefixes. Instead of writing difficult prefix wildcard and mask

wildcard combinations in an extended access list applied in a distribute list, prefix lists use a

configuration that is easy to read and comprehend. Example 14-20 shows a sampleconfiguration substitution for the configuration in Example 14-19, but it uses a prefix listinstead of a distribute list.

Example 14-19had access-list 101 that permitted 131.108.1.0/24 only. Example 14-20uses prefix-listto achieve that.

Example 14-20 Sample Configuration to Show How Prefix Lists WorkR2#:


41/60

router BGP 110

neighbor 131.108.10.1 remote-as 109neighbor 131.108.10.1prefix-list FILTER1 inip prefix-list FILTER1 seq 1 permit 131.108.1.0/24

NOTEPrefix-listalso has an implicit deny at the end, like distribute-listand AS_PATH list.In Example 14-20, FILTER1 is the name of the prefix list that is applied on the neighbor131.108.10.1 on all the incoming BGP updates. prefix-list FILTER1operation will be donein sequential ascending order; the smallest sequence number will be examined first. seq 1

permits 131.108.1.0/24. The prefix list certainly offers a simpler, yet powerful, method to

achieve what distribute lists once offered.

Use of Communities in Policy ControlRFC 1997 defines the BGP COMMUNITIES attribute, which describes a community as "agroup of destinations which share some common property." A community is a 32-bitnumber that is assigned to a prefix by configuration and that is propagated to all neighbors

in a BGP update. A prefix can be assigned with multiple communities, with a maximum of

255 different communities per prefix. BGP operators can group networks into communities.For example, all networks in the east region of an internetwork are assigned a community,

and the networks in the west region of an internetwork are assigned a different community.

Thus, community numbers act as a tag for each prefix. By looking at the community in BGPoutput, it becomes easy to distinguish east region prefixes from west region prefixes.

Communities can be represented in two ways in Cisco IOS Software. Conventional style is a

plain 32bit number; newer style uses the format AS:nn, where AS is the autonomoussystem and nn is a 2byte number. The newer format can be used after ip BGP new-format

under the BGP subcommand.

Figure 14-18shows how sets of prefixes are grouped in certain communities. BGP attribute

manipulation is often done on a per-community basis.


42/60

Figure 14-18. Network to Show How Prefixes Are Grouped intoCommunities for Easier Operation in the Receiver

In Figure 14-18, AS 109 and 110 are configured with EBGP. In AS 109, 131.108.1.0/24 and

131.108.2.0/24 belong to community 109:1, and 131.108.3.0/24 and 131.108.4.0/24belong to community 109:2.Example 14-21 shows a sample configuration in R1, which

assigns communities. Assume that R1 can originate 131.108.1.0/24, 131.108.2.0/24,

131.108.3.0/24, and 131.108.4.0/24.

Example 14-21 Sample Configuration to Assign Communities perPrefixR1#router BGP 109network 131.108.1.0 mask 255.255.255.0network 131.108.2.0 mask 255.255.255.0network 131.108.3.0 mask 255.255.255.0

network 131.108.4.0 mask 255.255.255.0neighbor 131.108.6.2 remote-as 110neighbor 131.108.6.2send-communityneighbor 131.108.6.2route-map SET_COMMUNITY out

ip BGP-community new-formataccess-list 1 permit 131.108.2.0access-list 1 permit 131.108.1.0


43/60

access-list 2 permit 131.108.4.0access-list 2 permit 131.108.3.0route-map SET_COMMUNITY permit 10match ip address 1set community 109:1

!

route-map SET_COMMUNITY permit 20match ip address 2set community 109:2

R1 has configured route-map SET_COMMUNITYand applied it to neighbor 131.108.6.2for all the outbound BGP updates that R1 advertises to R2. route-map SET_COMMUNITY

has a matchclause in each sequence that matches against the access list. If the prefix is

per-mitted in the access list, it is assigned a community based on which access list it ispermitted by. In Example 14-21, 131.108.2.0/24 is permitted by access-list 1,so it will be

assigned with community 109:1. Similarly, 131.108.4.0/24 gets community 109:2. R2

receives these updates with communities and might be configured to assign LOCAL_PREFbased on the communities. R2 might assign LOCAL_PREF based on individual prefix, but itwould be difficult to manage if the number of prefixes grows to several thousand.

Example 14-22shows the sample configuration of R2, which assigns a LOCAL_PREF value of

200 for prefixes that belong to community 109:1, and assigns a LOCAL_PREF value of 50 forprefixes that belong to community 109:2.

Example 14-22 Sample Configuration to Show Community FilterUsage in Configuring BGP PolicyR2#

router BGP 110neighbor 131.108.6.1 remote-as 109neighbor 131.108.6.1 route-mapSET_LOCAL_PREF inneighbor 131.108.6.1 send-community

ip BGP-community new-formatip community-list 1 permit 109:1ip community-list 2 permit 109:2

route-map SET_LOCAL_PREF permit 10match community 1set local-preference 200

!

route-map SET_LOCAL_PREF permit 20

match community 2

set local-preference 50Route maps are configured to match against community list filters 1 and 2 that look for

these communities in BGP updates. If the community is found in the update, the set

operation is performed.

Example 14-23shows the BGP table for R2. All prefixes that belong to community 109:1 are

assigned a LOCAL_PREF value of 200. Prefixes with community 109:2 are assigned aLOCAL_PREF value of 50.


44/60

Example 14-23 Router R2 BGP Table Reflects LOCAL_PREFAssignment Along with CommunitiesR2# show ip BGP 131.108.1.0BGP routing table entry for 131.108.1.0/24, version 4Paths: (1 available, best #1, table Default-IP-Routing-Table)


131.108.6.1 from 131.108.6.1 (131.108.10.1)Origin IGP, metric 0, localpref 200, valid, external, bestCommunity: 109:1

R2# show ip BGP 131.108.3.0BGP routing table entry for 131.108.3.0/24, version 2Paths: (1 available, best #1, table Default-IP-Routing-Table)


131.108.6.1 from 131.108.6.1 (131.108.10.1)

Origin IGP, metric 0, localpref 50, valid, external, bestCommunity: 109:2

The LOCAL_PREF assignment and community is listed for each prefix. Community usagegives a scalable way to manage the BGP prefix in a large BGP network. BGP policies can beconfigured based on a single community number that might represent thousands of

prefixes. For example, Router R1 in the east region of a large network wants to assign

LOCAL_PREF of 200 to all prefixes of west region routes. If west region routers assign acertain community number to all their prefixes when advertising to the east region, RouterR1 will simply assign LOCAL_PREF in a route map by matching against a community that

east region has set. Router R1 could have made a huge access list to permit each prefix andaccomplish the same result, but, using community matching, R1 accomplished it in ascalable fashion.

Not only are communities used in BGP policy control, but they also aid in troubleshooting

BGP network problems. Customer BGP prefixes can be assigned with distinct and differentcommunities from peering ISP prefixes. If a customer prefix is having an issue, just lookingat the distinct community can isolate customer prefixes, and troubleshooting can be done

faster. Such benefits make community usage common in BGP networks.

Use of Outbound Route Filtering in Policy ControlThe document draft-chen-BGP-prefix-orf-00.txt defines the functionality of exchangingprefix listbased outbound route filter (ORF) capability. When configured with ORF, one

router pushes its inbound prefix list to ORF-capable BGP neighbors. Upon receipt, the

pushed prefix list is automatically configured as the outbound prefix list.

Typically, when routers must deny certain prefixes from other routers, they use filter lists,distribute lists, prefix lists, and so on as inbound filters. The receiver denies the prefix after

the sender has sent that prefix. ORF offers a dynamic way in which the receiver advertises

its inbound filter to the sender; the sender then installs that filter on its outbound neighborrelationship to the receiver. When a neighbor relationship is formed between two routers,

they exchange ORF capability that verifies whether both routers are ORF-capable. Onlywhen both agree can the ORF feature be used.


45/60

Figure 14-19shows how BGP speakers make use of ORF. The bold numbers indicate the

sequence of events in ORF, defined in the list following the figure.

Figure 14-19. Outbound Route Filter (ORF) Operations

1. R2 in AS 110 is advertising prefixes 131.108.2.0/24 and 131.108.3.0/24 to R1 in AS

109.2. R1's goal is to deny 131.108.2.0/24 and accept everything else that comes from R2. Thisis done through a prefix list named ABC, as shown in the Example 14-24configuration.3. R1 advertises its inbound prefix list ABC to R2 through the ORF mechanism.4. R2 installs prefix list ABC as an outbound filter for neighbor R1.

In Figure 14-19, R2 is originating 131.108.2.0/24 and 131.108.3.0/24. R1 wants to deny131.108.2.0/24 and receive everything else. Without ORF, R1 must configure an inbound

prefix list that will deny 131.108.2.0/24. Without ORF, this is achieved at the expense ofreceiving the update and then filtering it, thus wasting lots of resources, such as CPUprocessing in R2 to advertise the prefixes, link bandwidth to carry the updates that will be

dropped at R1, and CPU processing in R1 to filter those updates. ORF sends an inbound

prefix list filter to the neighbor. After receiving this prefix list, the neighbor applies it as anoutbound prefix list. All updates then must pass by the prefix list, saving extra computationat the receiver.


46/60

Example 14-24shows how R1 can send its inbound prefix list ABC to R2.

Example 14-24 Sample Configuration to Show How ORF Can Be UsedR1:router BGP 109BGP log-neighbor-changesneighbor 131.108.6.2remote-as 110neighbor 131.108.6.2EBGP-multihop 2

neighbor 131.108.6.2 capability orf prefix-list bothneighbor 131.108.6.2prefix-list ABC in

!ip prefix-list ABC seq 5 deny 131.108.2.0/24ip prefix-list ABC seq 10 permit 0.0.0.0/0 le 32 R1#clear ip BGP 131.108.6.2in prefix-filterR1#show ip BGPBGP table version is 2, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 131.108.3.0/24 131.108.6.2 0 0 110 I

The neighbor 131.108.6.2 capability orf prefix-filter bothenables ORF capability in R1with the BGP neighbor, and this capability indicates that the R1 is willing to accept or send a

prefix list with the neighbor R2.

The neighbor 131.108.6.2 prefix-list ABC incommand means that R1 has configured aninbound prefix list ABC for R2, which simply denies 131.108.2.0/24 and permits all other

prefixes. The clear ip BGP 131.108.6.2 in prefix-filterin R1 pushes its inbound prefix list

filter to R2.

The show ip BGP command shows that R1 is only receiving 131.108.3.0/24 as R2 has

accepted prefix-list ABC that denies 131.108.2.0/24. Example 14-25shows the necessaryconfiguration of R2 to accept the ORF from R1 configured in Example 14-24.

Example 14-25 Sample Configuration of R2 to Accept ORF from R1R2:router BGP 110network 131.108.2.0 mask 255.255.255.0network 131.108.3.0 mask 255.255.255.0

neighbor 131.108.6.1 remote-as 109neighbor 131.108.6.1 EBGP-multihop 2neighbor131.108.6.1 capability orf prefix-list both

R2#show ip BGPBGP table version is 3, local router ID is 2.2.2.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 131.108.2.0/24 0.0.0.0 0 32768 i*> 131.108.3.0/24 0.0.0.0 0 32768 IR2#show ip BGP neighbors 131.108.6.1 received prefix-filter


47/60

Address family: IPv4 Unicastip prefix-list 131.108.6.1: 2 entries

seq 5 deny 131.108.2.0/24seq 10 permit 0.0.0.0/0 le 32

The neighbor 131.108.6.1 capability orf prefix-list bothcommand enables ORF capabilityin R2 with the BGP neighbor, and this capability indicates that the R2 is willing to accept or

send a prefix list with the neighbor R1. The two showcommands in R2 indicate that R2 isadvertising the two prefixes and R2 has received the prefix list from R1 that denies131.108.2.0/24 and permits everything else. When R2 accepts the prefix-list ABC, it installsit as an outbound prefix-list, resulting in denial of 131.108.2.0/24 and permitting

131.108.3.0/24. R2 has the option to overwrite received prefix-filter with its own. ORF is apowerful mechanism to install inbound prefix lists on the remote end, thus avoidingunnecessary routing updates on the link and saving receiver CPU time to process those

updates and deny them.

Route DampeningRoute dampening is the feature that reduces propagation of flapping routes in the Internet.

Route flapping occurs when IP routes are removed and put back in a routing table. This can

be because of physical layer failure, routing protocol failure, or router node failure, and soon. When these flaps are announced through BGP to the Internet, all of Internet routersrunning BGP are affected, as they have to remove and install such flapping routes. In an

unstable internal network where IP routes continuously flaps, this instability is propagatedthrough BGP throughout the Internet. Route dampening is the feature that minimizes this

instability by assigning a penalty to such flapping routes. When the penalty reaches apredefined limit (suppress limit), that route is removed from the routing table and is not

advertised to Internet. When the route stops flapping, the penalty decreases exponentially.

When the penalty is reduced to a predefined limit (reuse limit), that route is installed againand propagated through BGP. Some of the rules and definitions regarding route dampening

are as follows: Cisco IOS Software applicationRoute dampening applies to EBGP neighbors only. Flap penaltyEach flap receives a penalty of 1000. A penalty is assigned only whenroutes are withdrawn and not when they are re-advertised. Suppress limit A route is suppressed and removed from the routing table if the

penalty exceeds this limit. The default suppress limit is 2000. Half-life timeEvery 5 sec, a penalty is exponentially reduced such that in half-life the

penalty will be reduced to half of its value. Default Half-Life Time is 15 minutes. Reuse limitWith exponential reduction of penalty, a penalty will reach its reuse limitat which the route will no longer be suppressed and will be installed and advertised to otherBGP speaker. The Reuse-limit default is 750. When penalty is half of Reuse-limit, the

dampening information will be purged. History stateWhen flap (withdrawal) occurs, a route is assigned a penalty of 1000.In this state, BGP does not have the route because it is withdrawn, but BGP maintain the

information about the route in history state to keep track of dampening.

Damp state

With repeated flaps, where the penalty exceeds the suppress limit, theroute is removed from routing table and is not advertised to any BGP speaker. Maximum duration of dampeningDefault is 4 times of half-life time (15 minutes).

A route can only be dampened for 1 hour in default settings. In Cisco IOS Software,dampening is configured as shown in Example 14-26.

Example 14-26 Configuration of Dampening in Cisco IOS Software

R3#


48/60

router BGP 110BGP dampening

With this configuration, the half-life, reuse limit, suppress limit, and maximum suppresstime will get defaults of 15 min, 750, 2000, and 1 hour, respectively. These values can be

changed with the configuration shown in Example 14-27.

Example 14-27 Configuration to Change Dampening Parametersrouter BGP 110BGP dampening 1 400 2000 4

In Example 14-27, the half-life is 1, reuse limit is 400, suppress limit is 2000, and themaximum suppress time is 4 times the half-life, so routes will be suppressed for a

maximum of 4 minutes. The example that follows demonstrates how dampening works andwhat sequence of events the Cisco router goes through when routes are flapped.

In a simple network, R1 and R3 are running EBGP. R1 is advertising 131.108.1.0/24 to R3.Example 14-28shows the sequence of events when R3 has dampening enabled and R1 is

flapping 131.108.1.0/24. R3 is running following debugs to observe the sequence of events.

NOTEDebugs should be run carefully as excessive debug output can influence routerperformance.

Example 14-28 Route Dampening ExampleR3#debug ip BGP updates 1debug ip BGP dampening 1access-list 1 permit 131.108.1.0 0.0.0.0_____________________________________________________________________________________

! First Sequence: R1 has withdrawn 131.108.1./24R3#Jul 7:20:33.151 MDT: BGP: 1.1.2.1 rcv UPDATE about131.108.1.0/24 withdrawn24 1.Jul 4 17:20:33.151 MDT: BGP: charge penalty for131.108.1.0/24 path 109

2with halflife-time 15 reuse/suppress 750/2000.Jul 24 17:20:33.151 MDT: flapped 1 times since 00:00:00. New penalty is 1000 R3#show ip BGP 131.108.1.0BGP routing table entry for 131.108.1.0/24, version 3Paths: (1 available, no best path)

Flag: 0x88Not advertised to any peer109 (history entry)

1.1.2.1 from 1.1.2.1 (10.1.1.1)Origin IGP, metric 20, localpref 100, externalDampinfo: penalty 1000, flapped 1 times in 00:00:04

_____________________________________________________________________________________! Second Sequence: R1 announces 131.108.1.0/24 to R3.


49/60

R3#Jul 24 17:21:01.214 MDT: BGP: 1.1.2.1 rcv UPDATE about 131.108.1.0/24 R3#show ip BGP 131.108.1.0BGP routing table entry for 131.108.1.0/24, version 4Paths: (1 available, best #1)Flag: 0x88


1.1.2.1 from 1.1.2.1 (10.1.1.1)Origin IGP, metric 20, localpref 100, valid, external, bestDampinfo: penalty 972, flapped 1 times in 00:00:39

_____________________________________________________________________________________! Third Sequence: R1 has again withdrawn 131.108.1./24R3#Jul 24 17:21:31.882 MDT: BGP: 1.1.2.1rcv UPDATE about 131.108.1.0/24 -- withdrawn.Jul 24 17:21:31.882 MDT: BGP:charge penalty for 131.108.1.0/24 path 109 with

halflife-time 15 reuse/suppress 750/2000.Jul 24 17:21:31.882 MDT:flapped 2 times since 00:00:58. New penalty is 1960R3#show ip BGP 131.108.1.0BGP routing table entry for 131.

bgp short note file

Documents