Foundation Topics

BGP Attributes

Routes learned via BGP have associated properties that are used to determine the best route to a destination when multiple paths exist to a particular destination. These properties are referred to as BGP attributes; designing robust networks requires an understanding of how BGP attributes influence route selection. This chapter describes the attributes that BGP uses in the route selection process.

Table 16-2 lists the attributes supported by Cisco IOS.

Table 16-2. BGP Attributes
Attribute NameCategoryDescription
AggregatorOptional, transitiveRouter ID and AS of router that summarized. Not used in path selection.
AS_PathWell-known, mandatoryList of AS route has passed through. Prefer shortest path.
Atomic aggregateWell-known, discretionarySummary includes multiple AS. Not used in path selection.
Cluster IDOptional, nontransitiveOriginating cluster. Not used in path selection.
CommunityOptional, transitiveRoute tag. Not used in path selection.
Local preferenceWell-known, discretionaryMetric for external paths, for internal neighbors. Prefer highest.
Multiple Exit Discriminator (MED)Optional, nontransitiveInforms external peers which path to take into the autonomous system. Prefer lowest.
Next HopWell-known, mandatoryExternal peer in neighboring AS. Not used in path selection.
OriginWell-known, mandatoryLowest origin type preferred: (i)IGP is lower than (e)EGP, and EGP is lower than (?)incomplete.
Originator IDOptional, nontransitiveIdentifies Route Reflector. Not used in path selection.
WeightOptional, not communicated to peersAdministrative Cisco attribute. Prefer highest.

It is possible for BGP to receive multiple advertisements for the same route from multiple sources. BGP selects only one path as the best path. When the path is selected, BGP puts the selected path in the IP routing table and propagates the path to its neighbors. Table 16-3 displays the complete path selection process, summarizing the descriptions in this section.

Table 16-3. BGP Path Selection
OrderPreferenceDescription
0. SynchronizedTRUEUse only routes that meet the synchronization requirement
1. WeightHighestAdministrative override
2. Local PreferenceHighestUsed internally to pick path out of AS
3. Self originatedTRUEUsed to prefer paths originated on this router
4. AS-PathShortestMinimize AS-hops
5. Origini<?Prefer stability
6. MEDLowestUsed external to come in
7. ExternalEBGP<IBGPExternal path preferred over internal path
8. IGP costLowestLook for more information
9. EBGP PeeringOldestPrefer stability
10. RIDLowestChoose one with lowest BGP router ID


Looking at Table 16-3, it seems that there is a lot to know about BGP. This is an accurate impression. Unfortunately, this is one case where you simply have to memorize content; you must memorize Table 16-3. Notice that the first two steps (after synchronization) prefer higher values, the third step is true or false, and the remaining steps prefer lower values.

In general, with BGP, the three most important concepts to master are

  • Synchronization rule

  • BGP Split Horizon

  • BGP Path Selection

Controlling BGP Path Selection

The path selection criteria gives BGP a reasonable idea about the best way to route traffic in the Internet, but there are still times when an administrator has a more complete understanding of requirements than the router. In those cases, each BGP attribute may be tuned until the desired routing is achieved.

There are many methods to influence path selection, but the route maps are by far the most common technique for implementing policy routing. You can use the route map technique described in this section for any attribute, but this section describes only the weight and local preference attributes.

Using the Weight Attribute

The Cisco proprietary weight attribute selects the exit interface when there are multiple paths to the same destination. The higher the weight value, the better the path. Weight is local to the router and the attribute is not propagated to other routers. To configure the weight attribute, use the following command:

Router(config-router)# neighbor {ip-address | peer-group-name} weight weight

					  

Remember that weight can be a value from 0 to 65,535. The default weight is 0, unless this router sources the route (in which case the weight defaults to 32,768).

Figure 16-1 illustrates the use of the weight attribute, and Example 16-1 shows how the path through San Francisco is chosen. As you can see, the weight has been set on Chicago, making it prefer the path through San Francisco no matter which network it is trying to reach. The best path to 130.16.0.0 is through New York, but the path chosen will be through San Francisco.

Figure 16-1. The Weight Attribute and Selecting a Path

[View full size image]


Example 16-1. Sample Configuration to Illustrate Tuning the Weight Attribute

Chicago(config)# router bgp 100
Chicago(config-router)# bgp log-neighbor-changes
Chicago(config-router)# neighbor 167.55.191.3 remote-as 100
Chicago(config-router)# neighbor 167.55.199.2 remote-as 100
Chicago(config-router)# neighbor 167.55.199.2 weight 200

Remember that weight is a very powerful attribute—weight is considered before any other value and trumps all other settings.

Using the Local-Preference Attribute

The local preference is equally easy to configure. You can set it on either a default or a per-prefix basis. The syntax for the default command is

Router(config-router)# bgp default local-preference value

Local preference has a range from 0 to 4,294,967,295; higher values are preferred in selecting routes. The default is 100.

Example 16-2 is based on Figure 16-2. The local preference, set in the San Francisco router to 200, is propagated in the updates to all its peers. Likewise, the local preference of 100 set in the New York router is propagated to its peers. When Chicago has to decide on a path to the network 130.16.0.0, the highest local preference attribute dictates the San Francisco router as the exit point from the autonomous system.

Figure 16-2. Using Local Preference to Select a Path

[View full size image]


Example 16-2. Sample Configuration Illustrating Local Preference

SanFrancisco(config)# router bgp 100
!
SanFrancisco(config-router)# bgp default local-preference 200
SanFrancisco(config-router)# aggregate-address 167.55.0.0 255.255.0.0 summary-only
SanFrancisco(config-router)# neighbor 100.2.4.4 remote-as 400
SanFrancisco(config-router)# neighbor 100.2.4.4 default-originate
!
SanFrancisco(config-router)# neighbor 167.55.195.3 remote-as 100
SanFrancisco(config-router)# neighbor 167.55.199.1 remote-as 100
--------------------------------------------------------------------------------
NewYork(config)# router bgp 100
!
NewYork(config-router)# bgp default local-preference 100
NewYork(config-router)# network 167.55.0.0
NewYork(config-router)# aggregate-address 167.55.0.0 255.255.0.0 summary-only
NewYork(config-router)# neighbor 100.2.3.2 remote-as 300
NewYork(config-router)# neighbor 167.55.191.1 remote-as 100
NewYork(config-router)# neighbor 167.55.195.2 remote-as 100

					  

Local preference can also be set per prefix. Although several methods exist to filter or modify routes using BGP, route maps is the only technique we explore. To use a route map to change BGP parameters, apply the route map to the peer using the neighbor command.

Router(config-router)# neighbor {IP | peer group} route-map route-map name {in|out}

					  

Example 16-3 shows a route map applied to routes received from a peer. Routes are compared to an access list and permitted routes have a local preference set to 500. Route map line 20 does not include a match command and so matches all routes, meaning that routes denied by the access list have a local preference set to 50.

Example 16-3. Local Preference Set for Specific Prefixes

Hickory(config)# router bgp 100
Hickory(config-router)# neighbor 10.5.5.25 remote-as 100
Hickory(config-router)# neighbor 10.5.5.25 route-map example_LP in
Hickory(config-router)# exit
Hickory(config)# access-list 5 permit 10.1.1.0 0.0.0.255
Hickory(config)# route-map example_LP permit 10
Hickory(config-rmap)# match ip address 5
Hickory(config-rmap)# set ip local-preference 500
Hickory(config)# route-map example_LP permit 20
Hickory(config-rmap)# set ip local-preference 50

Using the MED Attribute

Multi-exit discriminator (MED) is advertised to external neighbors to try to influence path selection into an AS. For instance, consider a case where there are redundant links to an ISP and you want traffic to flow across the higher bandwidth path. Weight or LP could be used to control how local routers send traffic out of the AS, but external neighbors do not receive this information. A lower MED could be set on one path, indicating to your neighbors that they should reply on this circuit.

MED is often called a weak attribute, because MED is only considered after weight, local preference, AS-path length, and origin. MED is an optional, nontransitive attribute—lower MED is preferred. The default MED is 0. The syntax for setting MED on all routes is

Router(config-router)# default-metric value

Example 16-4 shows a route map applied to routes advertised to a peer. Advertised routes are first compared to an access list and permitted routes have a metric set to 500. Route map line 20 does not include a match command and so matches all routes, meaning that routes denied by the access list have a metric of 5000.

Example 16-4. MED Set for Specific Prefixes

Hickory(config)# router bgp 100
Hickory(config-router)# neighbor 10.6.6.36 remote-as 200
Hickory(config-router)# neighbor 10.6.6.36 route-map med_rm out
Hickory(config-router)# exit
Hickory(config)# access-list 5 permit 10.1.1.0 0.0.0.255
Hickory(config)# route-map med_rm permit 10
Hickory(config-rmap)# match ip address 5
Hickory(config-rmap)# set metric 500
Hickory(config)# route-map med_rm permit 20
Hickory(config-rmap)# set metric 5000

Verifying the Configuration of Attributes

It is always important to be able to check your work, particularly when that work defines an entire organization's method of connecting to the Internet.

The show ip bgp command shows attribute values and status. It is a good command to verify configuration changes and manage the traffic flow to and from the autonomous system.

Example 16-5 shows how BGP is running before the configuration in Example 16-2. The next hop is to 100.2.3.2, which is in autonomous system 300 because the traffic would be routed via New York. Note that in Example 16-3, the local preference on Chicago has been set by the BGP process to be 100 by default.

Example 16-5. The show ip bgp Command Example for Chicago Before Attributes Are Set

Chicago# show ip bgp
BGP table version is 22, local router ID is 192.168.0.231
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure
Origin codes: i - IGP, e - EGP, ? ñ incomplete

   Network             Next Hop         Metric LocPrf  Weight Path
*>i4.0.0.0          100.2.4.4                0    100       0 400 I
*>i5.0.0.0          100.2.3.2                0    100       0 300 I
*>i100.2.3.0/29     100.2.3.2                0    100       0 300 I
*>i100.2.4.0/29     100.2.4.4                0    100       0 400 I
*>i130.16.0.0       100.2.3.2                0    100       0 300 I
r>i167.55.0.0       167.55.191.3        281600    100       0 I
Chicago#

					  

Example 16-6 occurs after a weight is set to 200 for the neighbor 167.55.199.5, which is San Francisco. This forces the longest path to be taken to 130.16.0.0 via San Francisco.

Example 16-6. The show ip bgp Command Example Showing the Use of the Weight Attribute

Chicago# show ip bgp
BGP table version is 8, local router ID is 192.168.0.231
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf  Weight Path
*>i4.0.0.0          100.2.4.4                0    100     200 400 i
*>i5.0.0.0          100.2.3.2                0    100       0 300 i
*>i100.2.3.0/29     100.2.3.2                0    100       0 300 i
*>i100.2.4.0/29     100.2.4.4                0    100     200 400 i
*>i130.16.0.0       100.2.4.4                     100     200 400 500 300 i
* i                 100.2.3.2                0    100       0 300 i
r>i167.55.0.0       167.55.191.3        281600    100       0 i
Chicago#

					  

Table 16-4 describes significant fields shown in Examples 16-3 and 16-4. The large metric values in these examples derive from the respective IGPs.

Table 16-4. Explanation of Output from the show ip bgp Command
FieldDescription
BGP table versionInternal table version number. This is incremented whenever the table changes.
local router IDThe IP address that is used as a BGP ID.
status codesStatus is displayed at the beginning of each line. It will be one of the following values:

s—suppressed.

*—valid.

>—best entry to use for that network.

i—learned via an iBGP session.

d—dampened.
OriginThe origin code is placed at the end of each AS-path. It can be one of the following values:

i—advertised with a BGP network command.

e—originated from an EGP.

?—redistributed into BGP from an IGP.
NetworkA destination prefix.
Next hopIP address of the first external neighbor along the path. An entry of 0.0.0.0 indicates that the route is self-originated.
MetricIf shown, this is the value of the metric between autonomous systems. This field is frequently not used.
LocPrfLocal preference values as set on the routers with interfaces to other autonomous systems. It defines how preferable that router is as a transit point out of the autonomous system. The default value is 100.
WeightWeight of the route, determining which path the router will choose. It is proprietary to Cisco and is an attribute local to the router.
PathAutonomous system paths to the destination network. There can be one entry in this field for each autonomous system in the path.




 
ASPTreeView.com
 
Evaluation has ДЙ№єЛµЪШЦХexpired.
Info...