O'Reilly Book Excerpts: BGP

Editor's Note: In this second installment on Traffic Engineering, excerpted from O'Reilly's BGP, learn how to influence the BGP path-selection process.

Setting the Local Preference

The easiest and most effective way to influence the BGP path selection process is to adjust the Local Preference. This works well when certain routes are always better than others, for instance:

Example 6-2 shows part of a BGP configuration where the routes received from both peers receive different Local Preference values.

Example 6-2: Setting the Local Preference for all routes received from a BGP neighbor

!
router bgp 60055
 neighbor 192.0.254.17 remote-as 40077
 neighbor 192.0.254.17 route-map ispa-in in
 neighbor 219.2.19.1 remote-as 50066
 neighbor 219.2.19.1 route-map ispb-in in
!
route-map ispa-in permit 10
 set local-preference 90
!
route-map ispb-in permit 10
 set local-preference 110
!

In This Series

The permit keyword in the route-map statement means matched routes will be permitted to enter the BGP table or be propagated to the neighbor; a deny route map will filter out all routes matching the match clause. The number 10 is the sequence number, used to apply the different route maps with the same tag in the right sequence. In this case, there is only one route map for each tag (ispa-in and ispb-in), so the sequence number doesn't do anything.

Since we want to match all routes, there is no need to supply a match clause for the route maps. Both route maps just use a set clause to set the Local Preference for every route that is received from the respective neighbor. This has the effect that if ISP B has a route to a destination, this route will always be preferred over the route ISP A has to the same destination. Routes from ISP A will be used only if there is no matching route over ISP B. This would be a good routing policy if traffic over ISP B is a lot cheaper than traffic over ISP A. Example 6-3 shows the BGP table after applying the route maps.

Example 6-3: Partial BGP table with different Local Preferences

BR1#show ip bgp
BGP table version is 619734, local router ID is  192.0.254.18
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network     Next Hop      Metric LocPrf Path
*  7.7.0.0/19  192.0.254.17             90 40077 397 i
*>             219.2.19.1              110 50066 5703 397 i
*  8.8.0.0/16  192.0.254.17             90 40077 30021 i
*>             219.2.19.1              110 50066 30021 i
*  9.9.0.0/20  192.0.254.17             90 40077 5930 1070 i
*>             219.2.19.1              110 50066 1070 i

Under normal circumstances, the router would choose the route over AS 40077 for network 7.7.0.0/19 because the path over AS 50066 is longer. The higher Local Preference has precedence over the AS path length, however, so the route over ISP B is selected, as indicated with a > character. For 8.8.0.0/16, the AS path is the same length, so under other circumstances the decision would have come down to the tie- breaking rules. And for 9.9.0.0/20, the higher Local Preference doesn't really make a difference, because the route over AS 50066 has a shorter path anyway.

This policy works well as long as ISP B provides good connectivity to all destinations on the Net. But maybe ISP B peers with AS 30088 over a heavily congested connection, as shown in Figure 6-2.

Figure 6-2. The congestion between ISP B and AS 30088

In this case, routes that traverse AS 30088 should be avoided. This is accomplished in Example 6-4.

Example 6-4: Setting the Local Preference depending on AS path

!
ip as-path access-list 4 permit _30088_
ip as-path access-list 4 deny .*
!
route-map ispa-in permit 10
 set local-preference 90
!
route-map ispb-in permit 10
 match as-path 4
 set local-preference 80
!
route-map ispb-in permit 20
 set local-preference 110
!

The route map ispb-in permit 10 uses a match clause pointing to AS path access list 4 to find all routes with AS number 30088 in their AS path. The underscore characters before and after the AS number match a space, and the beginning or the end of the path. For a five-digit AS number, this doesn't make a difference, but the regular expression "3008" not only matches paths with AS number 3008 in it, but also with AS numbers such as 13008, 30080, 30081 and so on.

The routes received from ISP B that match AS path access list 4 are assigned a Local Preference value of 80. Routes not matching AS path access list 4 will be evaluated by the ispb-in permit 20 route map. There, they are always matched and assigned a Local Preference of 110.

Example 6-5 shows the result of applying these route maps for a route to a customer of AS 30088. Under normal circumstances, the second route would have been chosen because the path is shorter, but the modified Local Preference values make sure the first route is used.

Example 6-5: The result of Local Preference manipulation

BR1#show ip bgp 221.169.0.0
BGP routing table entry for 221.169.0.0/20, version 239188
Paths: (2 available, best #1)
  Not advertised to any peer
  40077 1800 30088 20099
    192.0.254.17 from 192.0.254.17 (192.0.254.17)
      Origin IGP, metric 20, localpref 90, valid, external, best, ref 2
  50066 30088 20099
    219.2.19.1 from 219.2.19.1 (219.2.13.237)
      Origin IGP, localpref 80, valid, external, ref 2

Manipulating Inbound AS Paths

Bypassing the AS path length comparison and the possible subsequent steps by setting the Local Preference isn't always the most appropriate way to influence the route-selection process. For instance, a route with twelve ASes in the path will be preferred over one with a single AS in the path if the Local Preference is higher, but it's hard to imagine a situation in which a path that's so much longer is still preferable. An alternative is to manipulate the way the router evaluates the AS path or to manipulate the AS path itself. Bay (now Nortel) routers allow a weight to be set for each AS, and the total weight of the path is calculated for each route. Cisco and most other vendors lack such an elegant and powerful mechanism, but they usually allow some sort of direct manipulation of the path. The usual way to do this is by prepending your own AS number to the end of the path one or more times. The path is then announced to external BGP peers in its modified state, which may not be desirable, so this technique is mostly suited for multihomed end-user networks and not for ISPs. Example 6-6 shows route maps to modify the AS path rather than the Local Preference as was done in Example 6-4. The ispb-in permit 10 route map prepends the path for paths that match AS path access list 4 because they contain AS 30088. Then the second ispb-in route map matches all remaining routes (without the need for either a match or a set clause), so they are included in the BGP table without modifications.

Example 6-6: Prepending the AS path

!
ip as-path access-list 4 permit _30088_
ip as-path access-list 4 deny .*
!
route-map ispa-in permit 10
 set as-path prepend 60055
!
route-map ispb-in permit 10
 match as-path 4
 set as-path prepend 60055 60055 60055
!
route-map ispb-in permit 20
!

As a result of these AS path manipulations, more traffic will flow over ISP B, since the path over ISP A is now longer. For some destinations, however, the longer path over ISP A may still be shorter, or the paths over A and B may be the same length, so that BGP has to employ the tie-breaking rules to select the best route. Example 6-7 shows the result for a route over AS 30088. Originally, the route over ISP B was shorter. But this route had its path prepended with the local AS number three times and the route over ISP A just once, so the route over ISP A is preferred.

Example 6-7: The result of AS path manipulation

BR1#show ip bgp 221.169.0.0
BGP routing table entry for 221.169.0.0/20, version 247873
Paths: (2 available, best #1)
  Not advertised to any peer
  60055 40077 1800 30088 20099
    192.0.254.17 from 192.0.254.17 (192.0.253.83)
      Origin IGP, metric 20, localpref 100, valid, external, best, ref 2
  60055 60055 60055 50066 30088 20099
    219.2.19.1 from 219.2.19.1 (219.2.13.237)
      Origin IGP, localpref 100, valid, external, ref 2

Note that the metric (MED) for the route over ISP A is 20, while the route over ISP B doesn't have a metric. Default IOS behavior is to treat a route without a MED metric as having a MED with the value 0. This may be changed to the opposite behavior (which conforms to IETF recommendations) using the bgp bestpath med missing-as-worst command in recent IOS versions. A missing MED then equals the highest (worst) possible value, as the command suggests. To me, the IETF behavior makes slightly more sense, but if you want to use MEDs, it's a good idea to make sure the routes actually have a MED set and do not depend on default behavior.

Inbound Communities

Depending on your upstream ISP, incoming routes may be "colored" with several communities. This can work both ways: later in this chapter, we'll see how setting communities for the routes you send to an ISP can trigger actions inside the ISP's network. Many ISPs use communities to convey information about the origin of routes. This information can include whether the route was received from a customer, a peer or an upstream ISP, or the location where the route was learned. The next example is based on the following:

  • The AS 60055 network is located in Chicago.

  • ISP A (AS 40077) is a national network connecting to MAE East but not to the Chicago NAP, and it doesn't use communities.

  • ISP B (AS 50066) is a regional ISP that connects to the Ameritech (Chicago) NAP and to MAE East in Virginia.

  • Routes ISP B learns at the Chicago NAP have the community 50066:3001.

  • Routes ISP B learns at MAE East have the community 50066:3002.

  • ISP B's connection to the Chicago NAP is excellent, but their connection to MAE East is somewhat congested.

This situation is depicted in Figure 6-3. The width of the lines connecting both ISPs to the interconnect locations indicates the available bandwidth.

Figure 6-3. Example national and regional ISP connectivity

Routes over the Chicago NAP through ISP B are most likely a lot better than routes to the same destinations over ISP A because of ISP A's lack of local or regional interconnection with other networks. It makes sense to assign a higher Local Preference to ISP B's Chicago NAP routes. If the paths for routes to destinations behind MAE East are the same, the path over ISP A should be preferred, because ISP A's connection to MAE East isn't congested. On the other hand, if ISP A's route to such a destination is much longer, it's probably better to suffer some congestion over ISP B than to take the scenic route over ISP A. This can be accomplished by assigning a default MED metric of 10 to all routes (overwriting the existing MED, if there was one), except routes from ISP B over MAE East; those get a metric of 20. Example 6-8 implements this routing policy.

Example 6-8: Using communities to help select the best route

!

router bgp 60055
 bgp always-compare-med
!
ip bgp-community new-format
ip community-list 1 permit 50066:3001
ip community-list 1 deny
ip community-list 2 permit 50066:3002
ip community-list 2 deny
!
route-map ispa-in permit 10
 set metric 10
!
route-map ispb-in permit 10
 match community 1
 set metric 10
 set local-preference 120
!
route-map ispb-in permit 20
 match community 2
 set metric 20
!
route-map ispb-in permit 30
 set metric 10
!

The bgp always-compare-med command makes the router take the MED metric into account when comparing routes even when the two routes to a destination aren't received from the same AS. The ip bgp-community new-format command makes the router show all community-related information in the AS:nn format. Without it, communities are shown as single, very large numbers. Example 6-9 shows part of the BGP table after the BGP sessions have been reset and the new route maps have been applied.

Example 6-9: Partial listing of the BGP table

BR1#show ip bgp
BGP table version is 620121, local router ID is  192.0.254.18
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network     Next Hop      Metric LocPrf Path
*  7.7.0.0/19  192.0.254.17      10        40077 397 i
*>             219.2.19.1        10    120 50066 5703 397 i
*> 8.8.0.0/16  192.0.254.17      10        40077 30021 i
*              219.2.19.1        20        50066 30021 i
*  9.9.0.0/20  192.0.254.17      10        40077 5930 1070 i
*>             219.2.19.1        20        50066 1070 i

The first network in this example, 7.7.0.0/19, has a shorter path over ISP A (AS 40077), but it has the community 50066:3001 (not visible in this example) because ISP B (AS 50066) learned the route in Chicago, and the route map ispb-in has changed the Local Preference to 120. The route over ISP A has an empty Local Preference value, which is treated as a value of 100. Thus the route over ISP B is preferred.

ISPs A and B both peer with AS 30021 (network 8.8.0.0/16) at MAE East, so the route from ISP B contains the community 50066:3002, and the MED is changed to 20. The Local Preference and AS path length are the same for both ISP A and ISP B, so the MED is the deciding factor, and the router selects the route over ISP A.

The situation for network 9.9.0.0/20 is similar to that of network 8.8.0.0/16: ISP B also learns this route at MAE East. But ISP A doesn't directly peer with AS 1070, which explains the longer path. So the route over ISP B is selected because its path is shorter.

RPSL Routing Policy

Example 6-10 shows the Routing Policy Specification Language (RPSL) version of the routing policy for the configuration listed in Example 6-8 for inclusion in a Routing Registry.

Example 6-10: RPSL routing policy with communities

aut-num:      AS60055
import:       from AS40077
              action pref = 2; med = 10;
              accept ANY
import:       from AS50066
              action pref = 1; med = 10;
              accept community(50066:3001);
              action pref = 2; med = 20;
              accept community(50066:3002);
              action pref = 2; med = 10;
              accept ANY;
export:       to AS40077 announce AS60055
export:       to AS50066 announce AS60055
default:      to AS40077
default:      to AS50066

The import: clauses are executed from top to bottom, so if a route has both communities 50066:3001 and 50066:3002 set, it matches the first clause and receive a pref of 1 and a med of 10. Note that the pref keyword in RPSL isn't the same as the Local Preference: a lower pref is more preferred, while for Local Preference, a higher value is more preferred. In this policy, Local Preference 100 is translated into pref 2, and Local Preference 120 becomes pref 1.

BGP Load Balancing

When a single router has two connections to the same AS, it's possible to load-balance outgoing traffic over those connections by instructing the router to insert more than one route with the same NLRI into the routing table. Depending on the switching mode the router uses, half the packets will flow over one connection and the other half over the other (per packet load balancing), or half the destination IP addresses will be routed over one connection and the other half over the other (per destination load balancing). Load balancing is enabled by setting maximum-paths to a value higher than one (the maximum is six):

!
router bgp 60055
 maximum-paths 4
!

With this setting in effect, up to four routes are entered into the routing table, as long as the routes are received from routers in the same AS, and the AS paths and MED metrics are identical. The maximum-paths keyword applies to all BGP peers: it isn't possible to enable load balancing for some peers and not for others. However, it's simple to prevent load balancing by giving each incoming route a different MED.

Load balancing can work in both directions only if there are multiple connections between one router at one end and one router at the other end. This means that both connections are unavailable if the router on either side fails, creating two single points of failure, unless there are other connections (terminating at other routers) in addition to the ones eligible for load balancing. There is no requirement that load balancing be enabled on both ends. For instance, if both connections terminate at different routers at your ISP, it isn't possible to load-balance your incoming traffic, but as long as both connections terminate on one router at your end, you can still configure load balancing for outgoing traffic.

In the next installment learn how to balance inbound traffic.


Return to ONLamp.com.