for router R1, where only one route is being
installed in the routing table. Debugs and Verification
Figure shows the output of debug ip igrp
transactions command on router R1, revealing that R1 is
receiving two equal-cost path routes. However, the routing
table showed that only one route is being installed. Figure
shows the current configuration for router R1. The
maximum-path command has been configured with the value of
1, which prevents IGRP from installing more than one path in
the routing table. By default, the maximum-path is set
to four. If the command maximum-path 1 is used, it will
only allow one path to the destination even though more than
one path exists. The maximum-path 1 command should only
be used when load balancing is not desired. Solution
By default, Cisco IOS Software allows up to four equal-cost
routes to be installed into the routing table. This can be
increased up to six routes if configured properly. Figure shows
the configuration that installs six equal-cost route paths in
the routing table. This example makes more sense when there are
more than four paths and only four are being installed in the
routing table. Because four equal-cost routes is the default,
the maximum-paths command can be configured to
accommodate a fifth or possibly sixth route.
Content
5.5 Troubleshooting IGRP 5.5.5
Candidate default Except for IGRP, the way to set the
gateway of last resort for all other routing protocols is to
define a static route to 0.0.0.0 with a mask of 0.0.0.0. That
route can then be propagated within RIP and OSPF with the
default-information originate command, and within
EIGRP with the redistribute static command. IGRP does
not understand the 0.0.0.0 static route, so there is a
different way to set the gateway of last resort in IGRP. Figure
shows a sample network where router R1 will send default
traffic out the 155.155.155.0/24 network. Router R1 wants to
propagate this gateway of last resort to router R2. Figure
shows the configuration of router R1, without a gateway of last
resort configured. Debugs and Verification
Figure
shows the routing table in R2, which R2 is receiving
155.155.155.0/24, but it is not a candidate for default.
Solution
IGRP is incapable of carrying the 0.0.0.0/0
(also known as a default route). Instead, IGRP uses the
default-network command to mark a network as a candidate
for default. In this example, R1 is sending 155.155.155.0/24
and it is desirable to make R1 a candidate for default. To do
that, the configuration on R1 must be changed to establish
155.155.0.0 as the default network. Upon doing this, IGRP will
automatically start treating 155.155.155.0/24 as the candidate
for default and will set the gateway of last resort on router
R2. Figure shows the configuration for default-network on R1.
This ip default-network statement must always point
toward a major network, not a subnet, otherwise, it will not
set the gateway of last resort. Figure illustrates that after
the configuration change on R1, the debug ip igrp
transactions output shows IGRP treating 155.155.155.0/24 as
an exterior route because it is marked as a candidate for
default route. Figure now shows that the gateway of last resort
is set and that 155.155.155.0/24 is marked as a candidate for
default. Also, the * next to the I in the routing table means
that this entry is a candidate for default route. Note:
When troubleshooting issues regarding default routes with RIP
and OSPF, be sure a static 0.0.0.0/0 route and the
default-information originate command is configured on the
entrance router (or in the case of OSPF, the ASBR). With EIGRP,
the static 0.0.0.0/0 route and the redistribute static command
must be configured on the entrance router.
Content
5.6 Troubleshooting EIGRP
5.6.1 Mismatched K values For EIGRP to establish
its neighbors, the K constant value to manipulate the EIGRP
metric must be the same. In the EIGRP metric calculation, the
default for the K value is set so that only the bandwidth and
the delay of the interface are used to calculate the EIGRP
metric. At times, the network administrator might want other
interface values, such as load and reliability, to determine
the EIGRP metric. Therefore, the K values must be changed.
Because only bandwidth and delay are used in the calculations,
the remaining K values are set to a value of 0 by default.
Note: Cisco usually recommends that network
administrators do not modify the default metric of using
bandwidth and delay. However, the K values must be the same for
all the routers or EIGRP will not establish a neighbor
relationship. An example of two routers with mismatched K
values is illustrated. Modifying the K values will affect how
much, if any, of bandwidth, delay, reliability, and load will
have on the metric calculation. Modifying these K values will
have the following affect: - K1 for bandwidth
- K2 for load
- K3 for delay
- K4 and K5 for
reliability
Debugs and Verification
Figure shows the K values on RTR B have been changed to
include load and reliability, along with bandwidth and delay.
K1, K2, K3, and K4 have all been set to 1. The metric
weights command shows that these values have been modified.
The first value is the type of service (TOS) which is not
supported, but must be included. RTR A retains the default K
values of K1 and K3 set to 1 for bandwidth and delay only, with
all other K values set to 0. If router such as RTR A is using
the default, normally the metric weights command would
not be included in the configuration. The command show ip
eigrp neighbors on both RTR A and RTB B would show an empty
list. Troubleshooting this problem requires careful scrutiny of
the routers configuration. Solution
The solution is
to configure the same K values on all routers in the EIGRP
domain. Figure shows the modification made to RTR A to match
the K values on RTR B. At this point both routers will be able
to establish a neighbor relationship and exchange routing
information.
Content 5.6
Troubleshooting EIGRP 5.6.2 Mismatched AS
number EIGRP will not form any neighbor relationships with
routers that have different autonomous system numbers. If the
AS numbers are mismatched, no adjacency is formed. This problem
is usually caused by misconfiguration on the routers. Figure
shows two routers running EIGRP. Debugs and
Verification
Figure shows the configurations of both
routers. Because the two routers have different AS numbers,
using the command show ip eigrp neighbors on both RTR A
and RTB B would show an empty list. Solution
The
solution is to modify one of the two routers so the AS numbers
are the same. Figure shows both routers configured with the
same AS number, EIGRP AS 1. At this point, both routers will be
able to establish a neighbor relationship and exchange routing
information.
Content 5.6
Troubleshooting EIGRP 5.6.3 Stuck in active –
determining the problem When troubleshooting an EIGRP stuck
in active problem, two questions need to be answered:
- Why is the route active?
- Why is the route stuck?
Determining why the route is active is not
necessarily a difficult task. Sometimes, the route that
constantly is going active could be due to a flapping link. Or,
if the route is a host route (/32 route), it is possible that
it is from a dial-in connection that gets disconnected. A more
important and difficult task is determining why an active route
becomes stuck. Usually, an active route gets stuck for one of
the following reasons: - Bad or congested link
- Low router resources, such as low memory or high CPU
processing on the router
- Long query range
- Excessive redundancy
By default, the stuck in
active timer is only 180 seconds. If the EIGRP neighbor does