The ultimate solution for preventing the EIGRP stuck in active problem is to
manually summarize the routes whenever possible and to have a hierarchical
network design. An example of a poor network design that will not scale in a
large EIGRP network is shown.

In the
example, each core router represents a region of the entire network and shows
that there is no hierarchy in the IP addressing scheme.
The Core 1
router is injecting routes 1.1.1.0, 3.3.4.0, 1.1.2.0, and 2.2.3.0 into the core
network. The addresses are so scattered that no manual summarization is
possible.
The other core routers are experiencing the same problem. The
Core 3 and Core 4 routers can not summarize any routes into the core network.
As a result, of the FastEthernet link of 3.3.3.0 network keeps flapping, the
query would travel to the Core 3 router and then the query also would be seen
in the Core1 and Core 4 region. Ultimately, the query will traverse to all
routers in the internetwork, this would dramatically increase the likelihood of
an EIGRP stuck in active problem.
The best practice is to readdress the
IP addressing scheme. One region should take only a block of IP addresses, this
way, the core routers would be capable of summarizing the routes into the core,
resulting in a reduced routing table in the core. The routers and the query
would be contained only in one region. Figure
shows an
improved and more scalable EIGRP network design.
Comparing the example
networks makes it evident that the network presented in the second example is
much more structured.
The Core
1 router region takes only the 1.0.0.0 block of IP addresses, the Core 4 region
takes only the 2.0.0.0 block, and the Core 3 region takes only the 3.0.0.0
block of IP addresses. This enables the three core routers to summarize their
routes into the core. If the Fast Ethernet network of 3.3.3.0 flaps in the Core
3 region, the query would be bounded only in the Core 3 region and would not
travel the entire network to affect all of the routers in the network.