Problem: Load Balancing and Managing Outbound Traffic in an IBGP Network-Cause: By Default, IBGP in Cisco IOS Software Allows Only a Single Path to Get Installed in the Routing Table Even Though Multiple Equal BGP Paths Exist

Problem: Load Balancing and Managing Outbound Traffic in an IBGP Network ‚ Cause: By Default, IBGP in Cisco IOS Software Allows Only a Single Path to Get Installed in the Routing Table Even Though Multiple Equal BGP Paths Exist

If multiple paths are received from different IBGP neighbors for the same prefix, only one best path will be selected and installed in the routing table. This results in other alternate paths being unused.

Figure 15-43 shows a simple IBGP network in which R1 has an IBGP peering with R2 and R3. Both R2 and R3 are advertising 100.100.100.0/24 with next hops of 2.2.2.2 and 3.3.3.3, respectively, to R1. By default, R1 goes through its BGP best-path calculation and installs a single route for 100.100.100.0/24. Two paths exist, but only one sends traffic to 100.100.100.0/24.

Figure 15-43. IBGP Network with IBGP Peering to Two Routers

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

Figure 15-44. Problem-Resolution Flowchart

Debugs and Verification

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

Example 15-83 Output of R1 Having Multiple IBGP 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 #1)   Not advertised to any peer   110     2.2.2.2(metric 11) from 2.2.2.2 (2.2.2.2)       Origin IGP, metric 0, localpref 100, valid, internal,  best  110     3.3.3.3(metric 11) from 3.3.3.3 (3.3.3.3)       Origin IGP, metric 0, localpref 100, valid, internal R1#  show ip route 100.100.100.0  Routing entry for 100.100.100.0/24   Known via "bgp 109", distance 200, metric 0   Tag 110, type internal   Last update from 2.2.2.2  00:32:25 ago   Routing Descriptor Blocks: 2.2.2.2, from 2.2.2.2, 00:32:25 ago       Route metric is 0, traffic share count is 1 AS Hops 1 

Solution

Cisco IOS Software allows, by configuration, the selection of multiple IBGP paths for the same prefix to go in the routing table, as demonstrated in Example 15-84.

Example 15-84 Configuration Addition in R1 to Allow Multiple IBGP Paths to Get Installed in the Routing Table for 100.100.100.0/24

 R1#  router bgp 109  neighbor 2.2.2.2 remote-as 109 neighbor 3.3.3.3 remote-as 109 neighbor 2.2.2.2 update-source loopback0 neighbor 3.3.3.3 update-source loopback0  maximum-paths ibgp 2  

maximum-paths ibgp 2 allows two IBGP-learned paths to be installed in the routing table, and both paths are used in carrying traffic for 100.100.100.0/24. For maximum-paths ibgp to work, the following conditions must be met:

• In both paths, all BGP attributes ‚ LOCAL_PREF, MED,ORIGIN, and AS_PATH (entire AS_PATH) ‚ must be identical.

• Both paths must be learned through IBGP.

• Both paths must be synchronized.

• Both paths must have a reachable next hop.

• Both paths must have an EQUAL IGP cost to the next hop.

Example 15-85 shows the output of BGP table in R1 after applying the maximum-paths ibgp command.

Example 15-85 Effect of Applying maximum-paths ibgp Command in R1

 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     2.2.2.2 from 2.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal,  best, multipath  110     3.3.3.3 from 3.3.3.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal,  multipath  

Both of these paths are marked as "multipath" in the highlighted BGP output, and both will be installed in the routing table, as shown in Example 15-86.

Example 15-86 Multiple IBGP Paths for 100.100.100.0/24 in the Routing Table of R1

 R1#  show ip route 100.100.100.0  Routing entry for 100.100.100.0/24   Known via "bgp 109", distance 200, metric 0   Tag 109, type internal   Last update from 88.88.88.78 00:34:36 ago   Routing Descriptor Blocks:   *  2.2.2.2  , from 2.2.2.2, 00:34:36 ago Route metric is 0, traffic share count is 1  AS Hops 1  3.3.3.3  , from 3.3.3.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 IBGP connections, thus load sharing across multiple IBGP connections.