This process is typical troubleshooting
methodology for combating the EGIRP stuck in active problem.
Sometimes, chasing the query, hop by hop, leads to a loop, or
there are simply too many neighbors that did not reply to the
query. In this case, simplify and reduce the complexity of the
EIGRP topology by cutting down the redundancy. The simpler the
EIGRP topology is, the easier it is to troubleshoot an EIGRP
stuck in active problem.
Content 5.6
Troubleshooting EIGRP 5.6.5 Stuck in active
– the ultimate solution 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. The more networks EIGRP
summarizes, the less work EIGRP has to do when a major
convergence takes place. Therefore, this reduces the number of
queries being sent out and ultimately reduces the occurrence of
EIGRP stuck in active errors. 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. Summarization and hierarchy are the best design
practices for a large-scale network.
Content
5.6 Troubleshooting EIGRP
5.6.6 Duplicate router IDs There are times that
EIGRP will not install routes because of a duplicate router ID
problem. EIGRP does not use router ID as extensively as OSPF.
EIGRP uses the notion of router ID only for external routes to
prevent loops. EIGRP chooses the router ID based on the highest
IP address of the loopback interfaces on the router. If the
router does not have any loopback interface, the highest active
IP address of all the interfaces is chosen as the router ID for
EIGRP. Figure shows the network setup for this example on EIGRP
router IDs. Figure shows the pertinent configurations for the
cause of this problem. Router X is redistributing a route of
150.150.0.0/16 from OSPF into EIGRP and is sending the route
several hops to Router C. Router C receives the route and sends
the route as EIGRP external routes to Router B. Router B
installs the route in the routing table and sends it to Router
A. The debug output verifies how Router B sends the
route to Router A. Debugs and Verification
The
problem is that Router A is not installing the 150.150.0.0/16
route in the routing table. As a matter of fact, Router A is
not showing the 150.150.0.0/16 route in its topology table.
Going back to Router B, the route is in the routing table, and
the topology table appears. Router B shows that it is getting
the routes from Router C. By looking at the external data
section, it can be noticed that the originating router is
192.168.1.1, which is seven hops away. The original protocol
that originated the route 150.150.0.0/16 is OSPF with the
metric of 64. Notice that the originating router is
192.168.1.1. Looking back at the configuration of Router A,
notice that Router A also has an IP address of 192.168.1.1
configured on Ethernet 0, and it is the highest IP address on
the router. All of this evidence points to a duplicate router
ID problem in EIGRP that causes Router A not to install routes.
Because Router X and Router A have the same router ID
(192.168.1.1), when Router A receives the route from Router B,
it looks at the external data section of the route to see who
is the originating router. In this case, Router A sees the
originating router as192.168.1.1, which is its own router ID.
Router A does not put the route in its topology table because
it thinks that it is the originator of the route and that by
receiving the route back from other neighbors, it must be a
loop. So, to prevent a routing loop, Router A does not put the
route of 150.150.0.0/16 in the topology table. Consequently,
the route does not appear in the routing table. Router A will
not install any external routes that originate from Router X
because external routes carry the router ID in their EIGRP
update packet. Router A will install internal EIGRP routes from
Router X without any problem. The duplicate router ID problem
happens only for external routes. Solution
The
solution to the duplicate router ID problem is to change the IP
address of the loopback interface of Router X or to change the
IP address of Ethernet 0 on Router A. The rule of thumb is to
never configure the same IP address on two places in the
network. Figure shows the change the loopback IP address of
Router X to 192.168.9.1/32 to fix this problem. The result of
the IP address change in Router X is the installment of the
150.150.0.0/16 route in Router A.
Content
5.6 Troubleshooting EIGRP
5.6.7 EIGRP error messages This section discusses
some of the most common EIGRP errors that appear and the
meaning behind these EIGRP error messages. DUAL-3-SIA
This message means that the primary route is gone and no
feasible successor is available. The router has sent out the
queries to its neighbor and has not heard the reply from a
particular neighbor for more than three minutes. The route
state is now stuck in active state. Neighbor is not on
common subnet
This message means that the router has
heard a hello packet from a neighbor that is not on the same
subnet as the router. DUAL-3-BADCOUNT
Badcount means
that EIGRP believes that it knows of more routes for a given
network than actually exists. It is typically, but not always,
seen in conjunction with DUAL-3-SIAs, but it is not believed to
cause any problems itself. Unequal, <route>,
dndb=<metric>, query=<metric>
This message
indicates that there is an EIGRP internal error. However, the
router is coded to fully recover from this internal error. The
EIGRP internal error is caused by a software problem and should
not affect the operation of the router. The plan of action is
to report this error to the Cisco TAC and have the experts
decode the traceback message. At some point the Cisco IOS
Software should be upgraded accordingly. IP-EIGRP: Callback:
callback_routes
At some point, EIGRP attempted to
install routes to the destinations and failed, most commonly
because of the existence of a route with a better
administrative distance. When this occurs, EIGRP registers its
route as a backup route. When the better route disappears from
the routing table, EIGRP is called back through callback_routes