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.
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 220.127.116.11 remote-as 40077 neighbor 18.104.22.168 route-map ispa-in in neighbor 22.214.171.124 remote-as 50066 neighbor 126.96.36.199 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
Traffic Engineering: Queuing, Traffic Shaping, and Policing
Traffic Engineering: Finding the Right Route
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 (
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 188.8.131.52 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 * 184.108.40.206/19 220.127.116.11 90 40077 397 i *> 18.104.22.168 110 50066 5703 397 i * 22.214.171.124/16 126.96.36.199 90 40077 30021 i *> 188.8.131.52 110 50066 30021 i * 184.108.40.206/20 220.127.116.11 90 40077 5930 1070 i *> 18.104.22.168 110 50066 1070 i
Under normal circumstances, the router would choose the route over AS 40077 for network
22.214.171.124/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
126.96.36.199/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
188.8.131.52/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 184.108.40.206 BGP routing table entry for 220.127.116.11/20, version 239188 Paths: (2 available, best #1) Not advertised to any peer 40077 1800 30088 20099 18.104.22.168 from 22.214.171.124 (126.96.36.199) Origin IGP, metric 20, localpref 90, valid, external, best, ref 2 50066 30088 20099 188.8.131.52 from 184.108.40.206 (220.127.116.11) Origin IGP, localpref 80, valid, external, ref 2
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 18.104.22.168 BGP routing table entry for 22.214.171.124/20, version 247873 Paths: (2 available, best #1) Not advertised to any peer 60055 40077 1800 30088 20099 126.96.36.199 from 188.8.131.52 (184.108.40.206) Origin IGP, metric 20, localpref 100, valid, external, best, ref 2 60055 60055 60055 50066 30088 20099 220.127.116.11 from 18.104.22.168 (22.214.171.124) 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.
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
Routes ISP B learns at MAE East have the community
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 126.96.36.199 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 * 188.8.131.52/19 184.108.40.206 10 40077 397 i *> 220.127.116.11 10 120 50066 5703 397 i *> 18.104.22.168/16 22.214.171.124 10 40077 30021 i * 126.96.36.199 20 50066 30021 i * 188.8.131.52/20 184.108.40.206 10 40077 5930 1070 i *> 220.127.116.11 20 50066 1070 i
The first network in this example,
18.104.22.168/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
22.214.171.124/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
126.96.36.199/20 is similar to that of network
188.8.131.52/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.
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: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.
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.
Iljitsch van Beijnum has been working with BGP in ISP and end-user networks since 1996.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.