Problem: Load Balancing and Managing Outbound Traffic from a Single Router When Dual Homed to Same ISP-Cause: BGP Installs Only One Best Path in the Routing Table

Problem: Load Balancing and Managing Outbound Traffic from a Single Router When Dual Homed to Same ISP ‚ Cause: BGP Installs Only One Best Path in the Routing Table

In multihomed scenarios, a common concern that enterprise network operators face is improperly utilizing the external links going to the ISP. Typically, enterprise customers dual-home to either the same or different ISPs to load-share outgoing and incoming traffic.

Figure 15-41 shows a simple setup of R1 of AS 109 dual homed to same ISP AS 110 at R2 and R3. Both R2 and R3 are advertising prefix 100.100.100.0/24 to R1. Ideally, R1 should load-share traffic destined for prefix 100.100.100.0/24, but, by default, this does not happen and only one of the many paths available is used.

Figure 15-41. 1AS Dual Homed to Same ISP AS

BGP selects only a single best route for a prefix out of many alternate paths. This is the default behavior governed by RFC 1771. R1 will have two paths for prefix 100.100.100.0/24 ‚ one from R2 and the other from R3. R1 will go through its BGP best-path calculation and will pick and install one route in the routing table.

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

Figure 15-42. Problem-Resolution Flowchart

Debugs Verification

Example 15-80 shows output in R1 receiving two paths for prefix 100.100.100.0/24 but installing only one.

Example 15-80 Output of R1 Having Multiple Paths for 100.100.100.0/24 but Installing Only One in Its Routing Table

 R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (2 available, best #2)   Not advertised to any peer   110     141.108.1.3 from 141.108.1.3 (1.2.1.1)       Origin IGP, metric 0, localpref 100, valid, external   110     141.108.1.1 from 141.108.1.1 (141.108.6.1)       Origin IGP, metric 0, localpref 100, valid, external,  best  R1#  show ip route 100.100.100.0  Routing entry for 100.100.100.0/24   Known via "bgp 109", distance 20, metric 0   Tag 110, type external   Last update from 141.108.1.1  00:32:25 ago   Routing Descriptor Blocks:   * 141.108.1.1, from 141.108.1.1, 00:32:25 ago       Route metric is 0, traffic share count is 1       AS Hops 1 

Solution

Fortunately, Cisco IOS Software allows, by configuration, the installation of more than one route for the same prefix, as demonstrated in Example 15-81. This does come with a tight check: Multiple paths that are candidates to go in the routing table have the exact same BGP attribute except for the router ID (RID). If two or more paths have identical attributes except for the RID, they can go in the routing table and load sharing can be achieved for traffic going to that prefix.

Example 15-81 Configuration Addition in R1 to Allow Multiple Paths to Be Installed in the Routing Table for 100.100.100.0/24

 R1#  router bgp 109   neighbor 141.108.1.1 remote-as 110   neighbor 141.108.1.3 remote-as 110    maximum-paths 2   R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (2 available, best #2)   Not advertised to any peer   110     141.108.1.3 from 141.108.1.3 (1.2.1.1) Origin IGP, metric 0, localpref 100, valid, external,  multipath  110     141.108.1.1 from 141.108.1.1 (141.108.6.1) Origin IGP, metric 0, localpref 100, valid, external,  best, multipath  

The maximum-path 2 command allows two equal BGP paths to be installed in the routing table. Cisco IOS Software allows a maximum of six equal paths. Notice that in the BGP output, only one path has "best" in its output, but both have "multipath" and thus both will be installed in the routing table, as shown in the output of Example 15-82.

Example 15-82 Multiple Paths for 100.100.100.0/24 in the Routing Table

 R1#  show ip route 100.100.100.0  Routing entry for 100.100.100.0/24   Known via "bgp 109", distance 20, metric 0   Tag 110, type external   Last update from 88.88.88.78 00:34:36 ago   Routing Descriptor Blocks:  * 141.108.1.1  , from 141.108.1.1, 00:34:36 ago       Route metric is 0, traffic share count is 1       AS Hops 1  141.108.1.3  , from 141.108.1.3, 00:34:36 ago Route metric is 0, traffic share count is 1 AS Hops 1 

Traffic from R1 sent to 100.100.100.0/24 will use both BGP connections, thus load sharing across dual-homed connections.