Problem: Multiple BGP Connections to the Same BGP Neighbor AS, but Traffic Goes Out Through Only One Connection-Cause: BGP Neighbor Is Influencing Outbound Traffic by Sending MED or Prepended AS_PATH

Problem: Multiple BGP Connections to the Same BGP Neighbor AS, but Traffic Goes Out Through Only One Connection ‚ Cause: BGP Neighbor Is Influencing Outbound Traffic by Sending MED or Prepended AS_PATH

Typically, BGP networks are multihomed to different ISPs or the same ISP to provide redundancy or to load-share traffic. In some scenarios, the BGP network might be dual homed to the same ISP and might be running BGP with that ISP. Instead of load sharing traffic to the ISP over multiple connections, traffic might exit only from one connection.

These connections might be of equal bandwidth or might be different.

If the multiple EBGP connection links are of equal bandwidth and traffic exits from only one of those EBGP connections, this is not desirable and can lead to severe performance degradation because of packet loss and round-trip delays over the congested link. If the EBGP connections are of different bandwidth ‚ say, T3 (45 Mbps) and T1 (1.5 Mbps) ‚ it might be desirable for all traffic to go out through the T3 exit point. This section discusses the issue in which all EBGP connections going to the same ISP are of equal bandwidth but traffic goes out from only one of those links.

In the network illustrated in Figure 15-38, AS 109 has three EBGP peerings with AS 110, and AS 110 is advertising the same prefixes, P1, P2, P3, and so forth, at all peering points. However, all traffic from AS 109 destined for these prefixes uses a single exit point, X, with AS 110. This results in congestion at X and unnecessary usage of the AS 109 backbone.

Figure 15-38. BGP Network in Which Traffic Is Routed Inefficiently

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

Figure 15-39. Problem-Resolution Flowchart

Typically, EBGP speakers agree on sending and accepting MEDs from each other. However, AS 110 might send a lower MED to AS 109 for all its prefixes at connection X. This would result in AS 109 choosing Exit X as a best path to reach Prefixes P1, P2, and P3. Throughout the BGP domain of AS 109, all BGP speakers install Exit X as a next hop for all routes, P1, P2, and P3. All traffic to these prefixes originating or traversing through AS 109 choose Exit X.

This results in clogging Exit X, and traffic uses available bandwidth in the AS 109 backbone. Notice that exit points Y and Z are left unused for traffic destined for Prefixes P1, P2, and P3.

Solution

You can address this problem a number of ways:

• Request AS 110 to send the proper MED for each prefix.

• Don't accept MED from AS 110.

• Manually change LOCAL_PREFERENCE for P1, P2, and P3 at all the exit points, X, Y, and Z.

Request AS 110 to Send the Proper MED for Each Prefix

MED exchange with an EBGP peer is a tricky and bilateral game. Typically, BGP carriers accept MEDs only on a mutual basis in a process in which both carriers accept each other's MED. Accepting MED means that BGP carriers carry each other's traffic through the backbone and try to route the traffic in an optimal fashion.

If this mutual agreement takes place between AS 109 and AS 110, AS 109 can request AS 110 to send proper MEDs for prefixes announced. For example, if Prefix P1 is closer to Exit X, AS 110 should send a MED for P1 at X. A similar process should take place for P2 at Y and P3 at Z, if they are closer there. Traffic destined for Prefixes P1, P2, and P3 will ride the AS 109 backbone the most and enter AS 110 at the optimal exit from the AS 109 BGP speaker's view.

Don't Accept MED from AS 110

Request AS 110 either to not send the MED or to manually set the MED to 0 at peering points X, Y, and Z and for all prefixes from AS 110. This results in AS 109 picking the closest exit point, X, Y, or Z, for Prefixes P1, P2, and P3 through the lowest IGP (OSPF, IS-IS, and so on) cost to reach these exit points. Manually setting the MED to 0 can be done through a route map, as demonstrated in Example 15-75.

Example 15-75 Manually Setting the MED to 0 to Override Any Advertised MED from AS 110

  route-map influencing_traffic permit 10   set metric 0   !  R1#  router BGP 109   neighbor 4.4.4.4 remote-as 110  neighbor 4.4.4.4 route-map influencing_traffic in 

This route map should be applied at all EBGP connections between AS 109 and AS 110. Example 15-75 shows this route map applied only between R1 and R4.

The configuration in Example 15-75 sets the MED value for all the prefixes from AS 110 to 0. Now, BGP speakers in AS 109 use the IGP cost as a tiebreaker in the BGP best-path selection process. This results in traffic destined to Prefixes P1, P2, and P3 choosing the closest exit point.

Manually Change LOCAL_PREFERENCE for P1, P2, and P3 at All the Exit Points X, Y, and Z

To use this solution, AS 109 must know which exit point is closer to which prefix.

For example, if Prefix P1 is closer to exit point X, AS 109 should make the LOCAL_PREFERENCE higher for Prefix P1 at X. This method can be used for P2 and P3 if they are closer to Y and Z, respectively.

Example 15-76 shows a sample configuration at exit point X to change the LOCAL_PREFERENCE higher for P1 than the default value of 100.

Example 15-76 Setting the LOCAL_PREFERENCE Value Higher to Select the Best Exit Point

 R1#  router BGP 109   neighbor 4.4.4.4 remote-as 110   neighbor 4.4.4.4 route-map influencing_traffic in   route-map influencing_traffic permit 10   match ip address 1   set local-preference 200   !   route-map influencing_traffic permit 20  set local-preference 100 

In Example 15-76, the route map influencing traffic is applied between R1 and R4 . Access list 1, not shown, permits Prefix P1 only. Therefore, for P1, the LOCAL_PREF will be 200; for the rest of the prefixes, it will be the default, which is 100. A similar route map with proper prefix permitting in access list 1 needs to be applied at all EBGP connections between AS 109 and AS 110.

With the configuration addition in Example 15-76, Prefix P1 gets a LOCAL_PREF of 200 at R1, and all routers in AS 109 receive Prefix P1 with a LOCAL_PREF of 200. R1 and all routers in AS 109 select R1 as an exit point to reach P1 because of the higher LOCAL_PREFERENCE.

This method does not scale well in large BGP networks in which BGP speakers advertise and receive thousands of prefixes. Changing the LOCAL_PREFERENCE for each prefix could become cumbersome. A situation might arise in which AS 110 Prefixes P1, P2, and P3 also are advertised by another EBGP speaker ‚ say, AS 111. AS 109 might set a higher LOCAL_PREFERENCE for AS 111 than from AS 110. In this situation, traffic from AS 109 destined for P1, P2, and P3 take AS 111 as an exit point, resulting in suboptimal routing. AS 109 must ensure that AS 110 Prefixes P1, P2, and P3 receive higher LOCAL_PREFERENCE from X, Y, and Z.