Traffic Engineering: Local Routing Policy
Pages: 1, 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 188.8.131.52 BGP routing table entry for 184.108.40.206/20, version 247873 Paths: (2 available, best #1) Not advertised to any peer 60055 40077 1800 30088 20099 220.127.116.11 from 18.104.22.168 (22.214.171.124) Origin IGP, metric 20, localpref 100, valid, external, best, ref 2 60055 60055 60055 50066 30088 20099 126.96.36.199 from 188.8.131.52 (184.108.40.206) 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 220.127.116.11 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 * 18.104.22.168/19 22.214.171.124 10 40077 397 i *> 126.96.36.199 10 120 50066 5703 397 i *> 188.8.131.52/16 184.108.40.206 10 40077 30021 i * 220.127.116.11 20 50066 30021 i * 18.104.22.168/20 22.214.171.124 10 40077 5930 1070 i *> 126.96.36.199 20 50066 1070 i
The first network in this example,
188.8.131.52/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
184.108.40.206/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
220.127.116.11/20 is similar to that of network
18.104.22.168/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: 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.
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.
Iljitsch van Beijnum has been working with BGP in ISP and end-user networks since 1996.
Return to ONLamp.com.