oreilly.comSafari Books Online.Conferences.


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
BGP routing table entry for, version 247873
Paths: (2 available, best #1)
  Not advertised to any peer
  60055 40077 1800 30088 20099 from (
      Origin IGP, metric 20, localpref 100, valid, external, best, ref 2
  60055 60055 60055 50066 30088 20099 from (
      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
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
*      10        40077 397 i
*>           10    120 50066 5703 397 i
*>      10        40077 30021 i
*            20        50066 30021 i
*      10        40077 5930 1070 i
*>           20        50066 1070 i

The first network in this example,, 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 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 is similar to that of network 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.

Iljitsch van Beijnum has been working with BGP in ISP and end-user networks since 1996.

Return to

Sponsored by: