Troubleshooting Inbound IP Traffic Flow Issues Because of BGP Policies

Just as in managing outbound IP traffic from an AS, Cisco IOS Software offers BGP operators configuration options to manage inbound traffic in an AS. It is important that inbound traffic from other autonomous systems be managed well. If this does not happen, capacity of the network will not be fully utilized. This causes congestion in one part of the network while the other parts are underutilized . The end result of this mismanagement of inbound traffic flow is sluggish throughput, slow round-trip times, and delays in IP traffic. Therefore, it is essential that all inbound BGP policies are checked and configured correctly.

Some of the most common problems in managing inbound IP traffic in an AS using BGP are as follows :

• Multiple connections exist to an AS, but all the traffic comes in through one BGP neighbor, X, in the same AS.

• A BGP neighbor in AS 110 should just be a backup provider, but some traffic from Internet still comes through AS 110.

• Asymmetrical routing occurs.

• Traffic to a certain subnet should come through a particular connection, but it is coming from somewhere else.

Problem: Multiple Connections Exist to an AS, but All the Traffic Comes in Through One BGP Neighbor, X, in the same AS ‚ Cause: Either BGP Neighbor at X Has a BGP Policy Configured to Make Itself Preferred over the Other Peering Points, or the Networks Are Advertised to Attract Traffic from Only X

As Figure 15-45 illustrates, AS 109 has multiple BGP connections to AS 110, and AS 109 is advertising prefix 100.100.100.0/24 to AS 110 at all locations. However, all the traffic from AS 110 to 100.100.100.0/24 comes through the connection at X. All other links between the two autonomous systems are underutilized.

Figure 15-45. Two EBGP Connections Between Two Autonomous Systems, and One Link Carries Traffic

There might be multiple reasons for this behavior, but two of the most common scenarios are as follows:

• AS 110 has the BGP policy configured so that all updates from AS 109 at location X get the LOCAL_PREFERENCE higher than at all other neighbors with AS 109. This results in making X the preferred exit point from AS 110 to AS 109 for 100.100.100.0/24.

  In Figure 15-45, both R1 and R2 in AS 109 are advertising 100.100.100.0/24 to R6 and R8 in AS 110, respectively. R8 is changing the LOCAL_PREFERENCE of 100.100.100.0/24 so that R8 becomes the exit point from all BGP speakers in AS 110 to reach 100.100.100.0/24. This situation will make the link between R6 and R1 unutilized, and all the traffic to 100.100.100.0/24 will follow the R8 ‚ R2 link. The "Debugs and Verification" section explains how R8 can be configured to achieve this.

• AS 109 is influencing traffic by advertising different MED values for the prefix 100.100.100.0/24 at different locations.

  In Figure 15-46, both R1 and R2 are advertising 100.100.100.0/24, but with different MEDs. R1 is advertising a MED of 20, while a MED of 1 comes from R2 at X. In AS 110 BGP best- path selection, the lowest MED can influence this decision. As described in Chapter 14 in detail, if BGP best-path selection breaks the tie between the two paths based on the MED, the path from R2 will win and make it the most attractive exit point from AS 110 to AS 109 to reach 100.100.100.0/24. The "Debugs and Verification" section explains how R2 can be configured to achieve this.

  Figure 15-46. How Inbound Traffic Is Influenced by the MED

  

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

Figure 15-47. Problem-Resolution Flowchart

Debugs and Verification

This section discusses both cases of inbound traffic influence, discussed in the problem/cause presentation in the preceding section. Both necessary router configurations and show command outputs are displayed to examine the problem.

Case 1

This case is the one shown in Figure 15-45, in which R8 changed the LOCAL_PREFERENCE for 100.100.100.0/24. Example 15-87 shows the configuration in R8. The only significant con-figuration change is in R8, where route-map influencing_traffic is configured.

Example 15-87 R8 Configuration to Change LOCAL_PREFERENCE to Affect Best-Path Calculation of BGP

 R8#  router bgp 110   no synchronization   neighbor 172.16.28.2 remote-as 109   neighbor 172.16.28.2 route-map influencing_traffic in   neighbor 172.16.126.6 remote-as 110   !    access-list 1 permit 100.100.100.0    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 

In Example 15-87, R8 is configured with route-map influencing_traffic sequence 10, which changes the LOCAL_PREFERENCE to 200 for prefix 100.100.100.0/24 permitted by access list 1. The highest LOCAL_PREFERENCE wins in BGP best-path calculation, which affects all IBGP speakers in AS 110 (R6, in this example) and makes the path from R8 the best exit point to reach 100.100.100.0/24. Sequence 20 of the route map influencing traffic changes the LOCAL_PREFERENCE attribute to 90 for all other routes learned from neighbor 172.16.28.2 (R2).

The output in Example 15-88 shows how BGP in R6 selects R8 as the best exit point. Notice that the first path (the best path) is an IBGP path from R6 to R8 with a LOCAL_PREFERENCE of 200. The second path is from the R1 ‚ R6 connection.

The output from R8 in Example 15-88 shows that it has only a path for 100.100.100.0/24 and that is from R2. LOCAL_PREFERENCE is shown as 200, making it a best path advertised to R6.

Example 15-88 show ip bgp Command Output Reveals the Best Exit Point

 R6#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 6 Paths: (2 available, best #1, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   172.16.126.1   109     172.16.28.2 (metric 20) from 172.16.28.8 (172.16.8.8)       Origin IGP, metric 0,  localpref 200  , valid, internal, best 109     172.16.126.1 from 172.16.126.1 (172.16.1.1)       Origin IGP, metric 0, localpref 100, valid, external _____________________________________________________________________________________ R8#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Not advertised to any peer   109     172.16.28.2 from 172.16.28.2 (172.16.2.2)       Origin IGP, metric 0,  localpref 200  , valid, external, best 

Case 2

This case is the one shown in Figure 15-46, in which R1 and R2 advertise different MEDs for 100.100.100.0/24 to R6 and R8, respectively.

Example 15-89 details the configuration needed in R1 and R2. R6 and R8 have the standard BGP configuration for a simple neighbor relationship, so it is not shown. R1 and R2 have route-map MED_advertisement that advertises MEDs to their EBGP neighbors R6 and R8, respectively.

Example 15-89 MED Advertisement from R1 and R2 to Influence Inbound Traffic for 100.100.100.0/24

 R1#  router bgp 109  no synchronization  bgp log-neighbor-changes  network 100.100.100.0 mask 255.255.255.0  network 200.100.100.0  neighbor 172.16.126.2 remote-as 109  neighbor 172.16.126.6 remote-as 110  neighbor 172.16.126.6 route-map MED_advertisement out access-list 1 permit 100.100.100.0 access-list 2 permit any ! route-map MED_advertisement permit 10  match ip address 1  set metric 20  ! route-map MED_advertisement permit 20  match ip address 2  set metric 100 _____________________________________________________________________________________ R2#  router bgp 109  no synchronization  network 100.100.100.0 mask 255.255.255.0  neighbor 172.16.28.8 remote-as 110  neighbor 172.16.28.8  route-map MED_advertisement out  neighbor 172.16.126.1 remote-as 109 ! ! access-list 1 permit 100.100.100.0 access-list 2 permit any route-map MED_advertisement permit 10  match ip address 1  set metric 1  ! route-map MED_advertisement permit 20  match ip address 2  set metric 200 

In Example 15-89, R1 and R2 have route-map MED_advertisement configured with neighbors R6 and R8, respectively. In the case of R1, sequence 10 of the route map sets MED of 20 for 100.100.100.0/24 by access list 1 and sets the rest of the prefix MED to 100 by sequence 20 of the route map.

R2 is configured in a similar manner to R1, but the MED of 1 is sent to R8 for 100.100.100.0/24 and a MED of 200 is sent for rest of the prefixes.

The output in Example 15-90 shows the BGP output of prefix 100.100.100.0/24. The MED value of 1 is learned from R2 at R8, making this route the best route in AS 110.

All traffic from AS 110 to prefix 100.100.100.0/24 will exit from X at R8. Notice the output in R6, which prefers the IBGP update from R8 because of a lower MED for prefix 100.100.100.0/24.

Example 15-90 BGP Output for Prefix 100.100.100.0/24 Reveals the Best Route

 R8#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 12 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   172.16.126.6   109     172.16.28.2 from 172.16.28.2 (172.16.2.2)       Origin IGP,  metric 1  , localpref 100, valid, external, best _____________________________________________________________________________________ R6#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 13 Paths: (2 available, best #2, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   172.16.126.1   109     172.16.126.1 from 172.16.126.1 (172.16.1.1)       Origin IGP, metric 20, localpref 100, valid, external   109     172.16.28.2 (metric 20) from 172.16.28.8 (172.16.8.8)       Origin IGP,  metric 1  , localpref 100, valid, internal, best 

Solution

Return traffic influence can be desired as in Case 2, or it might happen as in Case 1. AS 109 BGP operators must understand what is causing this influence.

In Case 1, in which AS 110 changed its BGP policy by altering the LOCAL_PREFERENCE, BGP does not offer any commands for AS 109 to influence the AS 110 policy. Each AS can force its own policy, and the outside AS cannot change that. The solution for the Case 1 problem lies with the AS 109 administrator requesting AS 110 to remove any policy that affects AS 109.

In Case 2, AS 109 announced a MED and AS 110 was not configured to change LOCAL_PREFERENCE (as in Case 1).

If the MED announcement is not producing the desired behavior for AS 109 inbound traffic management, these MEDs should be removed, and the normal BGP policies of AS 110 should decide on the best entry into AS 109.

In larger BGP networks with numerous exit points and multiple BGP AS connections, traffic balance could become a challenge. Therefore, careful BGP policies and peering agreements must be created between BGP speakers, and traffic flow must be carefully observed .

Problem: Multiple Connections Exist to Several BGP Neighbors, but Most of the Traffic from Internet to 100.100.100.0/24 Always Comes in Through One BGP Neighbor from AS 110 ‚ Cause: Route Advertisements for 100.100.100.0/24 in AS 109 Attract Internet Traffic Through That BGP Neighbor in AS 110

When a BGP prefix is observed from a global Internet point-of-view , few BGP attributes stay intact from the originator of that prefix. For example, AS_PATH, ORIGIN_CODE and AGGREGATOR are the most common BGP attributes that get carried no matter how many autonomous systems a BGP update crosses. The most popular attributes, LOCAL_PREFERENCE and MED, do not cross an AS boundary. Therefore, they do not play any role in influencing return traffic from sources multiple autonomous systems away.

As discussed in Chapter 14, the most common BGP attributes that get used in the BGP best-path algorithm are LOCAL_PREFERENCE, AS_PATH and MED. Out of these, AS_PATH is the only attribute that stays intact from the originator of the prefix to any Internet BGP speaker.

Figure 15-48 shows the BGP update flow from AS 109 and also shows BGP best-path selection at each intermediate AS. AS 109 is originating AS 100.100.100.0/24, and its goal is to receive traffic from the Internet for 100.100.100.0/24 only through AS 110, not through AS 111.

Figure 15-48. BGP Update Flow from AS 109/Best-Path Selection at Intermediate Autonomous Systems

Solution

The following are two common practices that BGP administrators use to achieve the previously mentioned goal:

• AS 109 advertises network 100.100.100.0/24 with a much longer AS_PATH list to all BGP neighbors except AS 110. If autonomous systems 110, 112, and 113 do not make any additional changes in the BGP policy, autonomous systems 112 and 113 always go through AS 110 to reach 100.100.100.0/24.

  This results in all traffic to network 100.100.100.0/24 entering AS 109 to traverse AS 110; the links between AS 109 and AS 111 for redundancy.

• AS 109 advertises 100.100.100.0/24 only to AS 110, not to BGP neighbor AS 111. Therefore, traffic from the Internet sees only one path to reach 100.100.100.0/24 ‚ through AS 110 to AS 109. However, this case loses redundancy if AS 109 loses its BGP session with AS 110.