Advanced BGP – Basic BGP Load Balancing and Load Sharing

BGP supports both load balancing and load sharing implementations.  However, before delving into the specifics on the techniques that are within the scope of the ROUTE exam, it is imperative to have a good understanding of the differences between the two similar terms.

Load Balancing

Load balancing is used to split the load to the same destination across multiple paths. This may be to a destination network or even a destination host. With load balancing, the traffic is distributed in an even manner across the multiple links to the same destination network. Load balancing is therefore unidirectional because it does not necessarily mean that the same multiple paths will be used by return traffic from that same destination network or host. Cisco IOS software supports different types of load balancing algorithms, such as per-packet, per-destination, and round-robin load balancing.

It is important to understand that not all load balancing algorithms are the same. Even though the router might have multiple equal cost paths to the same destination, the switching algorithm that is used to actually forward the packets might only support a single path due to algorithm limitations or operation. Load balancing is supported at Layers 2, 3 and 4 and is uni-directional. In other words, load balancing is performed in a single direction. Just because the local router is load balancing across multiple links does not necessarily mean the same links will also be used for load balancing in the return direction. This too must be configured.

Load Sharing

Like load balancing, load sharing is also used to split the load to the same destination across multiple paths. However, unlike load balancing, load sharing does not distribute the traffic evenly across the multiple paths; instead it just sends packets over multiple paths.

While load balancing is used only to distribute outgoing traffic, load sharing can be used to distribute both incoming and outgoing traffic. This solution provides greater flexibility is implementations with unequal cost links to the same destination. For example, EIGRP can be used to load share across multiple unequal cost links. The same can be done with BGP.

Now that we have a solid understanding of the differences between load balancing and load sharing, the following sections describe basic BGP techniques that can be used for load balancing as well as for load sharing. As previously stated, while Cisco IOS software supports multiple options, the majority of those are beyond the scope of the current ROUTE exam and are not included in this chapter, or the remainder of this guide.

Border Gateway Protocol Inbound Load Balancing and Load Sharing

As was previously stated, there are numerous ways in which load balancing and load sharing can be implemented when using BGP.  The most load balancing and load sharing options are available in stub multi-homed implementations. If, for example, two links are provisioned between the enterprise edge and provider edge routers, load balancing can be performed by peering the routers using the eBGP multihop solution as shown in Figure 7-8:

Fig. 7-8. BGP Multihop Load Balancing

Referencing Figure 7-8, the BGP multihop feature can be used to load balance inbound, as well as outbound, traffic. While BGP is not explicitly configured to load balance, the static routes configured on both the ISP and enterprise routers are equal cost paths and assuming the router switching mechanism supports using more than one equal cost path, e.g. Cisco Express Forwarding (CEF), packets are sent on a one-for-one basis across both of the physical links as the NEXT_HOP for the BGP prefixes is the Loopback 0 interface.

When connected to the same ISP using two routers, it is also possible to implement an inbound load sharing policy by splitting the subnet in half and then advertising it to the ISP.  For example, assume that an enterprise owns the 150.254.254.0/24 address space. The enterprise is dual-homed to the same ISP using two physical routers. In order to utilize both links, the enterprise could split the address space in half and have one edge router advertise the 150.254.254.0/25 prefix to its upstream ISP peer, while the other edge router advertises the 150.254.254.128/25 prefix to its upstream ISP peer. For redundancy, both routers would also still advertise the 150.254.254.0/24. This implementation is illustrated in Figure 7-9:

Fig. 7-9. BGP Inbound Load Sharing Using the Same ISP

Referencing Figure 7-9, AS 1234 (the ISP) uses the E1-P1 link to send traffic destined to the 150.254.254.0/25 prefix and the E2-P2 link to send traffic destined to the 150.254.254.128/25 prefix. If either of the links between the enterprise and the ISP is unavailable, the 150.254.254.0/24 prefix is used to forward packets to the portion of the subnet that is no longer being advertised. This provides redundancy for the inbound load sharing implementation.

And alternative solution would be to use BGP attributes to influence the inbound load sharing. For example, AS 65001 (the enterprise) could advertise both the 150.254.254.0/25 and 150.254.254.128/25 prefixes to the ISP. Enterprise edge router E1 would then be configured to advertise the 150.254.254.128/25 prefix with a higher MED to the ISP while enterprise edge router E2 would be configured to advertise the 150.254.254.0/25 prefix with a higher MED to the ISP. The result is that the AS 1234 prefers the E1-P1 link for all of the traffic destined to the 150.254.254.0/25 prefix, and prefers the E2-P2 link for all traffic destined to the 150.254.254.128/25 prefix. If either one of the links fails, this implementation also still allows for redundancy using the remaining individual path.

NOTE: It is important to know that splitting the subnet in half does not automatically mean that load balancing is being performed. It is quite possible that the bulk of the traffic may be destined to hosts in only one half of the subnet meaning that one of the links is more utilized that the other.  Do not confuse this solution with load balancing.

The final scenario we will discuss in this section is how to implement load sharing when peered to more than one Internet Service Provider. This is performed using the AS_PATH attribute, specifically AS_PATH prepending in Cisco IOS software. Continuing from the previous example, AS_PATH prepending could be used to advertise one prefix with a longer AS_PATH to one ISP, while the advertising the second prefix to the second ISP with a longer AS_PATH. This type of implementation is illustrated in Figure 7-10:

Fig. 7-10. BGP Inbound Load Sharing Using Two Different ISPs

Figure 7-10 illustrates the use of the AS_PATH attribute and how it can be used to implement inbound load sharing – not load balancing – when multihomed to more than a single ISP. By prepending an additional autonomous system to the AS_PATH list for the 150.254.254.128/25 prefix, the path advertised by router E1 to the ISP in AS 1 will be longer than the path advertised by the router E2 to the ISP in AS 2, when propagated to upstream autonomous systems and the general Internet community. This means that the path via router AS 2 is preferred for inbound traffic from autonomous systems upstream of AS 2, including other Internet community. The same concept is also applicable to the 150.254.254.0/25, with the exception that the preferred inbound path is via the ISP using AS 1.

Border Gateway Protocol Outbound Load Balancing and Load Sharing

As was stated in the previous section, the multihop feature can be used for both inbound and outbound load balancing – assuming equal cost links are provisioned between the enterprise edge and service provider edge routers. In addition to this, BGP also supports additional configurations that can be used to perform outbound load balancing. A commonly used eBGP command is the maximum-paths <1-6> router configuration command.

As we learned in the previous chapter, BGP selects only one best path and installs that path into the routing table. However, in implementations when a single enterprise edge router is dual-homed to the same ISP, themaximum-paths <1-6> command can be used to load balance between the equal cost paths. The implementation of this command is illustrated in Figure 7-11:

Fig. 7-11. External BGP Outbound Load Balancing

Prior to using the maximum-paths <1-6> router configuration command, assuming default BGP configuration, router E1 prefers the route received from P1 as illustrated below:

This same path is installed into the IP RIB and is used to forward packets to 150.254.254.0/24:

Assuming that both links are similar, for example, they are both T1 links, the maximum-paths <1-6> router configuration command can be used to configure router E1 to perform outbound load balancing using both links. This configuration is implemented as follows:

Following this configuration, the BGP RIB on router E1 shows that eBGP Multipath has been configured as illustrated in the following output:

Referencing the output above, it is important to remember that the eBGP Multipath feature does affect the path selection process. As can be seen, router E1 still shows that the best path to the destination network is via router P1 (1.1.1.1). Although this is the best path, the eBGP Multipath feature allows the router to install up to the maxim number of specified equal cost paths into the routing table. This can be validated using the show ip route command as shown below:

While the maximum-paths <1-6> command is used to configure eBGP Multipath, the same command cannot be used for iBGP Multipath. Instead, the maximum-paths ibgp <number> command must be used. Unlike themaximum-paths <1-6> command, with the maximum-paths ibg <number> command, the supported number of paths is dependent on the version of Cisco IOS software that the router is running. Table 7-3 lists the maximum supported number of paths for various Cisco IOS software versions:

Tab.7-3. Supported Number of Paths for iBGP Load Balancing

NOTE: You are not required to memorize the IOS versions and maximum supported paths in Table 7-3. The ROUTE exam is based on IOS 12.4 which has a maximum number of 16 paths.

The use of the command is illustrated referencing the iBGP topology illustrated in Figure 7-12:

Fig. 7-12. Internal BGP Outbound Load Balancing

Figure 7-12 shows a basic network that includes four routers. All routers reside within AS 65001 and all routers have an iBGP peer relationship with every other router. In other words, this is a full mesh iBGP implementation. Routers R3 and R4 are connected to external subnet 150.254.254.0/24. These routers are advertising this prefix to the other iBGP peers, R1 and R2. Assuming a basic iBGP implementation, the BGP RIB on R1 shows the following:

The single entry (best path) is then installed into the routing table which shows the following:

To configure iBGP Multipath, allowing both routes to be installed into the routing table, the following configuration must be implemented on R1:

Following this configuration, the BGP RIB on router R1 shows the following:

As is the case with eBGP Multipath, the BGP path selection process is not affected by the actual Multipath configuration because we can see in the output above that R1 still shows the path from R3 (3.3.3.3) as the best path because R3 has a lower RID than R4. However, the Multipath configuration allows the local router to install both paths into the RIB as follows:

NOTE: When implementing iBGP Multipath, the NEXT_HOPs must have the same IGP route metric. If not, then iBGP Multipath will not work even if configured on the router.  Given Loopback interfaces are used for peering in this example, it is important to ensure that the IGP route metric for 3.3.3.3/32 and 4.4.4.4/32 is the same on R1 and R2 as shown for 3.3.3.3.32 on R1:

The IGP metric for 4.4.4.4/32 is also the same as illustrated in the following output:

NOTE: In addition to using default IGP metric calculation, you can also manually adjust the route metric using supported commands for the specific IGP; however, this is not recommended and should be avoided when implementing the iBGP Multipath feature.

In addition to using the maximum-paths commands for load balancing, BGP also supports a plethora of other options can also be used to implement outbound load sharing. Common implementations make use of route filtering, either by filtering or using AS_PATH filtering, as well as the manipulation of other BGP attributes, such as LOCAL_PREF and WEIGHT.

The options that will be available to you for outbound load sharing or load balancing depends on the number of prefixes received from the upstream ISP(s). For example, if only a default route is received, the options are minimal. However, if a complete Internet routing table is received, many more options can be used to implement load sharing in the outbound direction.