In this Post I would like to explore Unequal Cost Load Balancing with EIGRP and particularly how we configure EIGRP in order to achieve load balancing. I will talk about the feasible distance, the metric weights, offset-list, the different methods we can use to change traffic sharing among multiple unequal Cost paths with EIGRP and I will finally quickly cover CEF load balancing.
For this post I will use the following topology:
IGP: EIGRP AS 100
Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services
I would like to invite all my readers to participate to this EIGRP challenge which highlight the EIGRP STUB feature. As you may already know EIGRP use the query/reply process to find an alternate path for a route that it has lost if no feasible successor are present in the topology table. This process can slow down EIGRP convergence. To improve this behavior which is inherent to EIGRP (distance vector protocol, only knows routes being advertised by neighbors, unlike OSPF which has a full overview over the topology) there are 2 solutions. The goal of these 2 solutions is to reduce the query domain.
- The first solution is to use summarization. When a router lose a route it sends a query to all its connected neighbors to ask for an alternate path. If one of the neighbor has a summary route containing the more specific prefix lost by the neighbor, the query process will stop and the neighbor will send a reply back to the querier router telling him that it has no route for this prefix. The query will not go further. If summarization was not configured the query will have propagated through the network until it eventually reach a last hop router.
- The second solution is to use the EIGRP STUB feature. When a router is configured as a EIGRP STUB it will annonce itself as so to its connected neighbors. Then these neighbors will know that he is the last hop router and hence will not send query to him.
In this challenge I would use the EIGRP STUB feature to demonstrate what could be the consequence of using this feature in the wrong place in the network. Please consider the following topology: