Automatic Load Balancing

As is probably clear from the previous scenarios, load balancing is not a very intuitive task and requires extensive planning. To help, Cisco IOS software supports dynamic load balancing for identical destinations learned via EBGP by the same router and coming from the same autonomous system. This will reduce configuration efforts.

---

Troubleshooting:  
Ch. 11, pp. 382-385. Automatic Load Balancing

---

Figure 6-11 illustrates an example in which the same router (NY) is connected to its provider via two links and is getting identical routing on both links. A Cisco router will keep in its IP routing table up to six identical BGP routes to the same destination. When passing on the EBGP updates to the IBGP peers, however, the router will only pass on one best route. The next hop address of the route will automatically be changed to reflect the router's (NY) own IP address instead of having the EBGP next hop address carried into IBGP. Note that this is done automatically only in the case where load balancing is configured dynamically.

Figure 6-11  Router receiving identical routes from two sources.

By default, a Cisco router will load balance on a per destination (Host) basis. Balancing on a destination basis is done in round-robin fashion. One host will be locked to one path, the next host will be locked to the other path, and so on.

Figure 6-11 assumes that the customer is getting two identical routes to network 192.213.10.0/24. Without automatic load balancing, the BGP process prefers one path only. It is up to the administrator to try to affect the BGP decision by changing attributes to balance the traffic between paths.

With automatic balancing, BGP will keep two entries for the 192.213.10.0/24 prefix, one via the SF link and one via the NY link. Outbound traffic from the customer network will then be split over the two links on a round-robin basis, assuming that the customer needs to send traffic to the destinations 192.213.10.1 to 192.213.10.6. Destination 10.1 will be reached via the SF link, destination 10.2 will go over the NY link, destination 10.3 will go over the SF link, and so on.

---

Note:  
Load balancing in this manner works only when dealing with identical routing updates coming into the same router from the same provider. This method does not work to load balance in a multiprovider environment.

---

In the example illustrated in figure 6-11, automatic load balancing works well for outbound traffic. For inbound traffic, you must resort to manipulating metrics to influence the provider's decision.

Balancing Between Two Routers Sharing Multiple Paths

In some situations, two routers share multiple physical paths for backup or higher bandwidth services, as illustrated in figure 6-12.

Figure 6-12  Load balancing between two routers sharing multiple paths.

To balance traffic in this environment, one option is to implement dynamic balancing. This is simply a special situation of the previous automatic load balancing case. Dynamic load balancing, however, will result in extra overhead for the routers. Each router would receive duplicate update messages from the other router. In the case of full routing, the result would be approximately 42,000 routes arriving on each link. Instead, it is possible (and preferable) to achieve load balancing for the situation illustrated in figure 6-12 by using a static approach.

In the normal behavior, BGP keeps the best next hop for each prefix it learns. As seen in table 6-1, RTA will receive two identical BGP routes for NetX. BGP will pick the best route and install it in its IP routing table. In this case, BGP has picked the route via next hop 10.10.10.2. Table 6-2 illustrates RTA's IP routing table where the next hop 10.10.10.2 is reachable via link1. As a result of this configuration, traffic toward networks learned from RTB will be sent over link1. Hence, no load balancing is achieved.

---

Troubleshooting:  
Ch. 11, pp. 385-387. Balancing Between Two Routers Sharing Multiple Paths

---

BGP can be fooled by setting the next hop to a virtual interface rather than the physical link and by using the IP routing table to do the actual load balancing.In figure 6-13, RTB can be assigned a loopback interface (virtual interface), and RTA can use that address to set up the BGP neighbor connection. This way, the loopback interface itself and not the IP address of the physical link will be used as a next hop. Some dynamic IGP or static routing can be used to load balance between the links independent of BGP.

Figure 6-13  A single BGP session across multiple physical links.

As seen in table 6-3, RTA will receive its BGP routes from its neighbor 12.12.12.12 and will be able to reach NetX via the next hop 12.12.12.12. Table 6-4 illustrates RTA's IP routing table. Next hop 12.12.12.12 can be reached via link1 and link2. Reachability of the 12.12.12.0/24 network can be achieved via IGP or by pointing multiple static routes toward link1 and link2. The router can now load balance the traffic. Due to the recursive route lookup in this scenario, load balancing is done per network rather than per destinations. Networks learned from RTB can now be reached round robin over multiple links.