EIGRP For The CCNA: Equal-Cost Load Balancing Lab
We covered split horizon in depth in the previous installment of this EIGRP tutorial series. Right now, we’re going to do the same for load balancing and take a first-hand look at what happens when a successor suddenly leaves the EIGRP routing table.
It is not required to have read the previous tutorials to follow this lab.
Here’s our network. It’s the same as in previous installments, except a broadcast segment has been added.
We have two entries for the 172.12.23.0 /27 network in R1’s EIGRP route table. Sounds good. But why two entries for that route when the other two routes have only one entry?
There are two paths to 172.12.23.0 /27 thanks to equal-cost load balancing, a default behavior of EIGRP. Since the metric for these two paths to 172.12.23.0 /27 is exactly the same (2172416), both paths are put into the EIGRP route table and the load to that network is balanced over the two paths.
Before we look at R1’s topology table, a quick reminder: all routes in the EIGRP route table are successors, and you’ll find feasible successors and successors in the EIGRP topology table.
When equal-cost load balancing is in effect, you’ll see multiple successors for the same route in the topology table. Here, we see two successors for 172.12.23.0/27, and both are in the EIGRP route table, since their metrics are exactly the same.
That’s not the case for the other two routes that have two entries. R1 has two valid loop-free routes to 2.2.2.0 /24 in the topology table, but the metrics are unequal. As a result, the path with the lowest metric (2297856) is named the successor and is placed into the EIGRP route table. The other path is a feasible successor and will become the successor if the current successor leaves the route table. A similar situation exists with the two valid routes to 3.3.3.0 /24.
Before we continue with load balancing, let’s see the successor and feasible successor in action. According to the topology table, R1 is currently using 172.12.123.2 as the next-hop IP address for traffic heading for 2.2.2.0 /24. To test the feasible successor, I’ll remove R2’s serial link from the EIGRP lab.
As we’d expect, the adjacency between R1 and R2 is lost, verified by show ip eigrp neighbor on R1.
Let’s review the current network topology, with the link from R2 to the cloud now gone.
Does R1 still have an entry for R2’s loopback in its routing and topology tables?
The route that was the feasible successor is now the successor, just as it should be, and R1 can still ping R2’s loopback.
But what if the lost successor route returns? Let’s find out by adding our lost network back on R2.
With our network back to its original state…
… R1 has the same successor and feasible successors for 2.2.2.0 /24 and 3.3.3.0 /24 as it did before we removed EIGRP from R2’s serial interface. R1 is also again performing equal-cost load balancing for packets destined for 172.12.23.0 /27.
Now that we’ve seen equal-cost load balancing in action, it’s time for some unequal-cost balancing.
CCNA Lab: EIGRP Unequal-Cost Load Balancing
Use these other tutorials to propel you to CCNA success!