EIGRP has a composite metric made up of bandwidth, delay, reliability, load,
and MTU. By default, it utilizes only bandwidth and delay. Other routing
protocols use different metrics. For example, OSPF uses a metric based on
interface cost. OSPF cost is derived from the bandwidth of the link. Cisco uses
100,000,000/bandwidth to get that cost.
EIGRP does not understand the
metrics of other protocols so it is necessary to input a default metric when
doing redistribution.
Figure
shows a network
that could produce the problem in which redistributed routes do not get
installed in the routing table of the receiver. OSPF is redistributed into
EIGRP at R1, but R2 is not receiving the EIGRP routes.
R1 and R3 are
running OSPF in area 0, whereas R1 and R2 are running EIGRP. R3 is announcing
131.108.6.0/24 through OSPF to R1. In R1, OSPF routes are being redistributed
into EIGRP, but R2 is not receiving 131.108.6.0/24 through EIGRP.
Debugs and Verification
Figure
shows
that R3 is advertising 131.108.6.0/24 through OSPF to R1. Figure
shows that R1 is
redistributing OSPF into EIGRP. However, examining the routing table in R2,
Figure
shows that
131.108.6.0/24 is not being installed in the routing table.
Solution
To solve this problem, R1 needs to include the
metric option with the redistribute
statement, so that it can convert the OSPF metric properly. Figure
shows the new
configuration for R1. OSPF is redistributed into EIGRP with metric values of
bandwidth, delay, reliability, load, and MTU. Even if reliability and load are
not being used in the EIGRP metric, these values must be included in the
redistribute command.
 |
NOTE:
MTU is not part of the composite metric for EIGRP, but must be
included in the redistribute command.
|
Another solution is to use the default-metric
command under router eigrp. Figure
shows the syntax
for using the default-metric command, with the same values
of bandwidth, delay, reliability, load and MTU.
The route is now
installed in the routing table of R2.