Finally, informational EIGRP RFC 7868 has been published. It is not anymore Cisco’s EIGRP, it is an open standard. Without a most critical feature of EIGRP,can we really say that? Why Cisco doesn’t share the most important feature which can help in large scale EIGRP design although industry has been asking from them for a long time? EIGRP RFC 7868 specifies EIGRP Dual Algorithm, EIGRP Packets such as Update, Query and Reply, EIGRP Operation, and EIGRP Metrics (K1,K2,….K6).
And since EIGP is RFC anymore, other vendors can legally implement EIGRP. There was couple of open source EIGRP implementations already,but with the RFC status, seeing new implementations among the big vendors would not be a big deal. In addition to EIGRP packet types and metric values, there are a couple of important things to understand about EIGRP. Among them is how EIGRP, as a distance vector protocol, calculates a best path and advertise it to the neighbors.
Understanding what is EIGRP successor, EIGRP feasible successor, EIGRP feasibility condition, metric values and usage in real life deployments is among the most important parameters in EIGRP that should be properly understood. EIGRP RFC is an 80-page document, which provides detailed explanations of the protocol.
However, it lacks EIGRP Stub, one of the most important features if not the most important one. I always say, even if it is an RFC, the usability of EIGRP in large scale deployment will be limited without EIGRP Stub feature. But Why is EIGRP Stub feature so important to users? EIGRP Stub feature provides fast convergence in case of failure. Not only that, it reduces unnecessary control plane traffic between the routers as well as protecting routers used as transit routers.
Figure-1 EIGRP Convergence and Stub Feature
In Figure-1, 192.168.0.0/24 network is connected to Router A. If that network fails, EIGRP puts that route in the Active mode and sends EIGRP query to every neighbor. Nonetheless, the Active mode is not good. Besides, in steady state, EIGRP routes are in Passive mode. In Figure-1, C, D, and E are spoke routers and shouldn’t be used to reach the network behind Hub routers.
Thus, EIGRP Stub should be enabled on these routers. Some of these routers can be really slow. And they may not send EIGRP reply packets back to the Router A’s EIGRP query packets immediately. In fact, Router A has to wait for each neighbor to declare that the route is unreachable. In large scale network, there might be thousands of spokes.
And waiting for each router might significantly slow down the network convergence. Not only that, Hub router would send EIGRP query to thousands of neighbors, which would be a lot of burdens on the CPU. That’s not all.
Hub router has to process EIGRP reply packet from thousands of spokes nodes, most probably almost at the same time. This process would put a lot of burdens on the input queue and CPU of the Hub routers. In sum, EIGRP RFC has finally been published. But as expected, it lacks EIGRP Stub feature. EIGRP Stub is the most important feature in large-scale EIGRP design. Actually I should say, large scale Enterprise network design, because EIGRP is not used commonly in the Service Provider networks for lots of reason. And common usage in the Enterprise networks of EIGRP stub feature is on the spoke nodes in DMVPN design.
EIGRP Stub should always be used at the Edge of network, even the topology is not Hub and Spoke. Needless to say, I heard from Donnie Savage who is the real man behind EIGRP and also main author of this RFC that in the future, EIGRP Stub feature might be open to the Public. But only time can tell if this prediction is true. By the way; Who do you think will implement or do you think that big vendors will implement EIGRP in their equipment ? Let’s discuss in the comment section below.