The most prevalent problem encountered with redistribution is that
redistributed routes are not being installed in the routing table of the
routers receiving these routes. The most common cause of this is a metric that
is not defined during redistribution into RIP.
Figure
shows a network
that could produce the problem in which redistributed routes do not get
installed in the routing table of the receiver. R1 and R3 are running OSPF in
area 0, whereas R1 and R2 are running RIP. R3 is announcing 131.108.6.0/24
through OSPF to R1. In R1, OSPF routes are being redistributed into RIP, but R2
is not receiving 131.108.6.0/24 through RIP.
Debugs and
Verification
The first step is to investigate whether R1 is receiving
131.108.6.0/24. Figure
shows
that R3 is advertising 131.108.6.0/24 through OSPF to R1. Figure
shows that R1 is
redistributing OSPF into RIP on R1.
The next step is to check whether or
not R2 is receiving the 131.108.6.0/24 route. Figure
shows that in
R2, 131.108.6.0/24 is not present in the routing table.
The output of
debug ip rip on R2 which shows that R2 is receiving the
131.108.6.0/24 route, but with a metric of 16 hops (infinity).

Solution
In this example, an OSPF route in R1 for 131.108.6.0/24
has a metric of 20. When OSPF is redistributed into RIP in R1, OSPF advertised
131.108.6.0/24 with the default metric of 20, which exceeds the maximum metric
allowed in RIP. OSPF knows only cost as a metric, whereas RIP utilizes hop
count. No metric translation facility exists, so the administrator must
configure a metric to be assigned to redistributed routes.
To correct
this problem, R1 needs to assign a valid metric when configuring the
redistribution. This can be done with either the metric
option in the redistribute command or with
default-metric command.
In this
configuration all redistributed routes from OSPF into RIP get a metric of 1.
This metric is treated as hop count by R2.
Figure
shows that R2 is
now receiving the correct route with a metric of 1.