Troubleshooting RIP Redistribution Problems

‚  < ‚  Free Open Study ‚  > ‚  

This section talks about problems that can happen during redistribution in RIP. Redistribution refers to the case when another routing protocol or a static route or connected route is being injected into RIP. Special care is required during this process to avoid any routing loops . In addition, metric (hop count) should be defined during this process, to avoid problems.

The most prevalent problem encountered with RIP redistribution is that redistributed routes are not being installed in the routing table of the RIP routers receiving these routes. When destination routes are not present in a routing table, no data can reach those destinations. 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. As discussed in Chapter 2, 15 is the maximum hop count that RIP supports; anything greater than 15 is treated as the infinite metric and, upon receipt, is dropped.

Figure 3-42 shows the network setup that could produce the problem in which redistributed routes do not get installed in the routing table of the receiver.

Figure 3-42. Network Vulnerable to Redistributed Route Problems

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 redis-tributed into RIP, but R2 is not receiving 131.108.6.0/24 through RIP.

Figure 3-43 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-43. Flowchart to Resolve Redistributed Route Problems

Debugs and Verification

To troubleshoot this problem, you need to investigate whether R1 is receiving 131.108.6.0/24.

Example 3-111 shows that R3 is advertising 131.108.6.0/24 through OSPF to R1.

Example 3-111 show ip route Output Confirms That OSPF Is Working Fine and That R1 Is Receiving 131.108.6.0/24
 R1#  show ip route 131.108.6.0  Routing entry for 131.108.6.0/24   Known via "ospf 1", distance 110, metric 20, type intra area 

R1 must be configured to redistribute OSPF routes in RIP. Example 3-112 shows that R1 is redistributing OSPF in RIP.

Example 3-112 Configuring R1 So That OSPF Is Redistributed in RIP
 R1#  router rip   version 2    redistribute ospf 1    network 131.108.0.0  

Now, you must first investigate R2 whether 131.108.6.0/24 is coming.

Example 3-113 shows that, in R2, 131.108.6.0/24 is not present in the RIP routing table.

Example 3-113 R2 Routing Table Does Not Reflect That 131.108.6.0/24 Is Present
 R2#  show ip route 131.108.6.0   % Subnet not in table  

There are two basic ways to view this issue. The first is a simple show run on R1. The second is to run the debug ip rip on R2 command to watch the process.

Example 3-114 shows the output of debug ip rip.

Example 3-114 debug ip rip Output Shows That 131.108.6.0/24 Is Inaccessible
 R2#  debug ip rip  RIP: received v2 update from 131.108.1.1 on Ethernet1  131.108.6.0/24 -> 0.0.0.0 in 16 hops (inaccessible)  

Solution

In RIP-1 or RIP-2, 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, the 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 a 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.

Without the default metric configuration in R1, R2, upon receiving this update, complains about the excessive metric and marks it as (inaccessible), as shown in Example 3-114.

To correct this problem, R1 needs to assign a valid metric through configuration when doing the redistribution, as done for R1 in Example 3-115.

Example 3-115 Assigning a Valid Metric for Successful Redistribution
 R1#  router rip   version 2    redistribute ospf 1 metric 1    network 131.108.0.0  

In the configuration of Example 3-155, all redistributed routes from OSPF in RIP get a metric of 1. This metric is treated as hop count by R2.

Example 3-116 shows that R2 is receiving the correct route with a metric of 1.

Example 3-116 debug ip rip Reveals That the New Configuration for R1 Works and That R2 Is Receiving the Correct Route
 R2#  debug ip rip  RIP: received v2 update from 131.108.1.1 on Ethernet1  131.108.6.0/24 -> 0.0.0.0 in 1 hops  

Example 3-117 shows that the route gets installed in the routing table of R2.

Example 3-117 R2 Routing Table Reflects That the Redistribution for Route 131.108.6.0/24 Is Successful
 R2#  show ip route 131.108.6.0  Routing entry for 131.108.6.0/24   Known via "rip", distance 120, metric 1 
‚  < ‚  Free Open Study ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net