notes: Troubleshooting Inbound IP Traffic Flow Issues Because of BGP Policies

1.  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.

debugs and verification:

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

Case1:  Upstream AS  has the BGP policy configured so that all updates from your AS at location X get the LOCAL_PREFERENCE higher than at all other neighbors with your AS. This results in making X the preferred exit point from upstream AS 110 to  your AS  for some local subnets.



show ip bgp a.b.c.d

Case2:  Your AS is influencing traffic by advertising different MED values for the prefix some of your local subnet at different locations.

Solution

Return traffic influence can be desired as in Case 2, or it might happen as in Case 1.

In Case 1, in which upstream AS changed its BGP policy by altering the LOCAL_PREFERENCE, BGP does not offer any commands for your AS to influence the upstream AS 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 local AS administrator requesting AS 110 to remove any policy that affects your local AS.

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

If the MED announcement is not producing the desired behavior for your local AS inbound traffic management, these MEDs should be removed, and the normal BGP policies of upstream AS 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.

2.  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

Topology:

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.

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.

Solution:

a.  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.

b.  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.