Basic Principles
Protocol-based Load Balancing
Equal-cost load balancing
The NetEngine 8000 F supports equal-cost load balancing, enabling you to configure multiple routes to the same destination and with the same preference. If there are no routes with higher priorities, these equal-cost routes are all used. The NetEngine 8000 F always selects a different route for the IP packets to the destination. This balances traffic among multiple routes.
A specified routing protocol can learn several different routes to the same destination. If the protocol priority is higher than the priorities of all the other active protocols, these routes are all considered valid. As a result, load balancing of IP traffic is ensured at the routing protocol layer. In actual applications, routing protocols OSPF, BGP, and IS-IS and static routes support load balancing.
On the network shown in Figure 1, OSPF is used as the routing protocol.
OSPF is configured on Device A, Device B, Device C, Device D, and Device E. OSPF learns three different routes.
Packets entering Device A through Port 1 and heading for Device E are sent to the destination according to specific load balancing modes by the three routes, implementing load balancing.
Unequal-cost load balancing
When equal-cost load balancing is performed, traffic is load-balanced over paths, irrespective of the difference between link bandwidths. In this situation, low-bandwidth links may be congested, whereas high-bandwidth links may be idle. Unequal-cost load balancing can solve this problem by balancing traffic based on the bandwidths of the outbound interfaces.
Load balancing modes and algorithms of equal-cost and unequal-cost load balancing are the same.
The working mechanisms of equal-cost load balancing and unequal-cost load balancing are similar. The difference is that unequal-cost load balancing carries bandwidth information to the FIB and generates an NHP table according to the bandwidth ratio so that load balancing can be performed based on the bandwidth ratio.
In Figure 1, after unequal-cost load balancing is enabled on Device A, traffic is load-balanced based on the bandwidth ratio of the three outbound interfaces on Device A. For example, if the bandwidths of the three outbound interfaces are 0.5 Gbit/s, 1 Gbit/s, and 2.5 Gbit/s, respectively, traffic is load-balanced by these interfaces at the ratio of 1:2:5.
MPLS load balancing
When MPLS load balancing is performed, the NP checks the load balancing table and then hashes packets to different load balancing items.
In Figure 2, two equal-cost LSPs exist between Device B and Device C so that MPLS load balancing can be performed.
Multicast load balancing
Multicast load balancing can be configured based on the multicast source, multicast group, or multicast priority.
Trunk Load Balancing
A trunk is a logical interface in which several physical interfaces of the same type are bundled. Trunks provide higher bandwidth than each individual physical interface, improve connection redundancy, and load balance traffic over links.
Trunk load balancing for Layer 3 unicast and MPLS packets
Per-packet load balancing mode can be configured for Layer 3 unicast and MPLS packets to implement trunk load balancing. By default, per-flow load balancing mode is used.
Trunk load balancing for multicast
By default, trunk load balancing for multicast is performed based on the multicast source and group.
Two-Level Hash
When links connecting to next hops are trunk links, the traffic that is hashed based on protocol-based load balancing is further hashed based on the trunk forwarding table. This is the two-level hash.
The hash algorithm is first performed on Link 1 and trunk links.
Traffic on the trunk links is hashed to two trunk member interfaces.
Two-level hash works as follows:
A trunk, being regarded as a link, participates in the first-level hash with other links. The mechanism of the first-level hash is the same as that of protocol-based load balancing. The trunk traffic that has been load balanced according to the hash algorithm based on the NHP table is further load balanced according to the hash algorithm based on the trunk forwarding table. After that, second-level hash is implemented.
Two-Level Load Balancing
In Figure 5, traffic is load balanced between Device A and Device B, and between Device B and Device C. If the two load balancing processes use the same algorithm to calculate the hash key, the same flow is always distributed to the same link. In this case, the forwarding of the traffic is unbalanced.
Two-level load balancing works as follows:
A random number is introduced to the hash algorithm on each device. Random numbers vary depending on devices, which ensures different hash results.