Problem: Multiple Exit Points Exist but Traffic Goes Out Through One or Few Exit Routers-Cause: BGP Policy Definition Causes Traffic to Exit from One Place

Problem: Multiple Exit Points Exist but Traffic Goes Out Through One or Few Exit Routers ‚ Cause: BGP Policy Definition Causes Traffic to Exit from One Place

This problem commonly is seen when an AS receives the same prefix announcements from mul-tiple EBGP connections but traffic destined to those prefixes prefers only one or two exit points.

As illustrated by Figure 15-34, AS 109 has multiple connections to other autonomous systems. AS 109 has three EBGP connections with AS 110, two with AS 111, and one with AS 112. AS 111 is peering with AS 110 and AS 112.

Figure 15-34. Autonomous System with Multiple Connections to Other Autonomous Systems with Multiple Exit Points

Prefixes P1, P2, and P3 are originated by AS 110 and are advertised to EBGP neighboring autonomous systems 109, 111, and 112. AS 109 receive updates for these prefixes from multiple locations ‚ three updates from AS 110, two from AS 111, and one from AS 112. Even with such redundant BGP advertisements for Prefixes P1, P2, and P3, all the traffic for these prefixes from AS 110 might take only one or two exit points. The rest of the connections are underutilized . Such a scenario typically results in overutilized links because traffic tends to exit from one or two preferred paths, as governed by BGP policy of AS 109.

Figure 15-35 shows the flowchart to follow to resolve this problem.

Figure 15-35. Problem-Resolution Flowchart

AS 109 BGP installs its best path for Prefixes P1, P2, and P3 in the IP routing table, and traffic destined for these prefixes will look in the routing tables for routers in AS 109. It is crucial to understand how BGP selects the best path; to do this, BGP operators must understand how BGP path attributes work. These attributes include AS_PATH, LOCAL_PREFERENCE, MED, ORIGIN, and so on, as discussed in detail in Chapter 14.

This section discusses how AS_PATH affects traffic patterns in AS 109 for Prefixes P1, P2, and P3. It is assumed that AS 109 is not configured with any additional BGP policies.

Recall that AS_PATH contains a list of autonomous systems that an update has traversed.

This section shows the AS_PATH list of R1 and R4 as an example; you are encouraged to come up with the AS_PATH list for R2 and R3 as an exercise.

R1 has two updates for Prefixes P1, P2, and P3 and the AS_PATH would like the following:

• 110 ‚ Path from a direct connection between R1 and AS 110. This would be an EBGP path with an AS_PATH length of 1.

• 110 ‚ Path from R2. This would be an IBGP path with an AS_PATH length of 1.

Out of these two paths, the first one will be selected as best because, with the same AS_PATH length, the EBGP path is better than the IBGP path.

R4 AS_PATH would like the following:

• 112 111 110 ‚ Path from R4 and AS 112 connection. This is an EBGP path with an AS_PATH length of 3.

• 111 110 ‚ Path from R4 and AS 111 connection. This is an EBGP path with an AS_PATH length of 2.

• 110 ‚ Path from R1. This would be an IBGP path with an AS_PATH length of 1.

• 110 ‚ Path from R2. This would be an IBGP path with an AS_PATH length of 1.

• 110 ‚ Path from R3. This would be an IBGP path with an AS_PATH length of 1.

The AS_PATH length of the third, fourth, and fifth paths is 1, and best-path selection will be based on IBGP next -hop cost through the IGP. If you assume that the third path from R1 wins, all traffic from R4 destined for Prefixes P1, P2, and P3 will exit from R1 and the AS 110 connection, leaving path 1, 2, 4, and 5 links not used at all for Prefixes P1, P2, and P3.

Refer back to Chapter 14 for the full description of how the best-path calculation method works.

This example could be a real-life one in which AS 110 is a big Tier 1 ISP that peers BGP with just about all other ISPs, big or small. Chances are, AS 110 will provide AS 109 with most of the BGP prefixes (P1, P2, and P3) with the shortest AS_PATH. This will influence AS 109's BGP best-path procedure to pick AS 110 as the first preference to carry traffic for P1, P2, and P3, which, in turn , results in clogging links that connect AS 109 to AS 110 directly. Because AS 109 has not made any BGP policy change for P1, P2, and P3, AS 109 is at the mercy of BGP neighbors and is left with no control of traffic flow from its AS 109 to P1, P2, and P3. The links from AS 109 to AS 111, 112, and so forth are used minimally , resulting in wasted high-cost bandwidth.

Solution

If a situation arises in which one BGP neighbor (AS 110, in this example) is attracting all the traffic from AS 109 to Prefixes P1, P2, and P3, AS 109 BGP operators should define local policies within AS 109 to overcome this behavior.

Using the BGP attribute LOCAL_PREFERENCE is done commonly to predictably control the traffic leaving the local AS (AS 109, in this example). AS 109 can choose to make AS 111 and AS 112 carry traffic for Prefix P2 and P3, respectively, and can leave the rest for AS 110.

Example 15-70 shows an example of how R2 in AS 109 can change LOCAL_PREFERENCE on a per-prefix basis with a neighbor in AS 111 to make AS 111 attract all the traffic for P2.

Example 15-70 Implementing the LOCAL_PREFERENCE Attribute to Control the Traffic Flow

 R2#  router bgp 109   neighbor 172.16.1.1 remote-as 111   neighbor 172.16.1.1 route-map influencing_traffic in   access-list 1 permit P2 wild_card   access-list 2 permit any   route-map influencing_traffic permit 10   match ip address 1   set local-preference 200   !   route-map influencing_traffic permit 20   match ip address 2  set local-preference 90 

Access list 1 is permitting Prefix P2. The actual access list would have the real IP prefix; P2 is used just for illustration purposes. The first sequence 10 of route-map influencing_traffic allows P2 to be set with a LOCAL_PREFERENCE of 200, and sequence 20 of the same route map sets a LOCAL_PREFERENCE of 90 for the other prefixes (P1 and P3). This results in making P2's LOCAL_PREF 200, thus making AS 111 path the best path for P2 only. Setting the P1 and P3 LOCAL_PREF attributes to 90 would have no effect because, in Cisco IOS Software, the default value for LOCAL_PREFERENCE is 100; AS 110 will be picked as the best path for P1 and P3.

With the size of the BGP routing table today, it is difficult to manage traffic on a prefix-by-prefix basis. Typically, BGP speakers change the LOCAL_PREFERENCE value based on the AS_PATH list. AS 109 might decide that all prefixes that come from AS 111 that have in the AS_PATH list either "111" or "111 and one more AS" should be selected as best paths through AS 111 neighbors. Therefore, AS 110 and AS 112 should not be the preferred carriers for prefixes that are originated by AS 111 or that are coming from an AS directly peering with AS 111.

Manipulating BGP attributes (LOCAL_PREFERENCE) based on AS_PATH list requires the use of the as_path access-list command, which uses UNIX-like regular expressions.

Example 15-71 shows a configuration example of Router R2 in AS 109 that changes the LOCAL_PREFERENCE of all the prefixes of those received from AS 111 that have in the AS_PATH list either "111" or "111 and one more AS."

Example 15-71 LOCAL_PREFERENCE Manipulation Using AS_PATH List

 R2#  router bgp 109   neighbor 172.16.1.1 remote-as 111   neighbor 172.16.1.1 route-map influencing_traffic in   !   ip as-path access-list 1 permit ^111$   ip as-path access-list 1 permit ^111 [0-9]+$   ip as-path access-list 2 permit .*   route-map influencing_traffic permit 10   match as-path 1   set local-preference 200   !   route-map influencing_traffic permit 20   match as-path 2  set local-preference 90 

The first sequence number, 10, of route-map influencing_traffic looks at AS path 1, which permits any prefix that has in its AS_PATH list either "111" or "111 and one more AS"; it then sets the LOCAL_PREFERENCE to 200, making links to AS 111 the preferred path from the AS 109 BGP view. The regular expression ^111$ means that AS_PATH should contain only one AS, and that is AS 111.

The expression ^111 [0-9]+$ means that AS_PATH should contain two autonomous systems, but the first one must be AS 111; the second one can be any AS. The expression .* means any AS.

The second sequence number, 20, of route-map influencing_traffic looks at AS path 2, which permits everything and makes the LOCAL_PREFERENCE lower than the default of 100 so that other carriers can pick the rest of the traffic.

BGP attribute manipulation based on AS_PATH is a fairly common practice among savvy BGP operators because wildcard operations allow covering a larger number of prefixes to be checked in fewer lines of configuration.

In essence, it is crucial that BGP operators manage their traffic flow by making necessary BGP attribute changes to influence the BGP path-selection process. This ensures predictable traffic management within an AS and allows future upgrades in bandwidth to easily be judged.