Content

| 5.10 |  | Troubleshooting Redistribution |
| 5.10.1 |  | Redistribution problems with RIP |

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.

In RIP, the metric for a route is treated as a hop count that shows the number of routers that exist along this route. The maximum hop count that RIP supports is 15; anything greater than 15 is treated as the infinite metric and, upon receipt, is dropped.

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 RIP, 16 is considered to be an infinite metric. Any update with a metric greater than 15 will not be considered for entry into the routing table.

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.