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.

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.

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.