Route Redistribution Issues Part I – RIP and OSPF

This is part of task I had on IEWB volume 3 workbook lab 1. I tweaked it a little. I wanted to get better idea of redistribution when there are multiple points of redistribution. It is always the hardest concept for me to get my head around because there so many things going on. I know the tasks may only be a few points, but it affects reachability which can hurt you later if you do not have it.

If you develop a thought process for it and recognize patterns and spot issues beforehand, you will be better off. I don't have any configurations here, just my thought flow. I was doing this practice lab at the same but I just wanted to document the thoughts.


Perform redistribution between RIP and OSPF on R4 and R5 and ensure reachability to the loopback interfaces on R1 and R9 from anywhere when R4 or R5’s frame link are down. If both are down then reachability to R9 and R1 cannot be achieved from R2.

Thought Process:

First thing I would do is identify which networks need to be learned via each protocol on each router, along with back up routes:

Router	Destination	Primary Route	Backup Route
R1	R9, LAN59	RIP via R4	n/a
R4	R9, LAN59 R1	RIP via R5 RIP via R1	OSPF via R5 n/a
R5	R1, LAN14 R9	RIP via R4 RIP via R9	OSPF via R4 n/a
R9	R1, LAN14	RIP via R5	n/a
R2	All	OSPF via R4 or R5	n/a

Next thing is to break down the redistribution into steps. These steps can be in various orders which may affect traffic flow, but I like to start with the edge networks in and resolve issues as we progress. We have 4 steps here:

Step 1: Redistribute RIP into OSPF on R5
R2 now has access to R9 loopback and LAN59 via R5
R5 has no changes to it’s routes
R4 now learns the route to R9 and LAN59 via OSPF through R5
R1 no longer has a route to R9 or LAN59 because R4 learns these via OSPF, not RIP anymore

Step 2: Redistribute RIP into OSPF on R4
R2 now has access to R1 loopback and LAN14 via R4.
R4 is the same as in step 1.
R5 now learns the route to R1 Loopback and LAN14 via OSPF through R4
R9 cannot reach R1 anymore because R5 is learning R1 and LAN14 through OSPF, not RIP

Issues remaining after steps 1 and 2:
R1 or R9 cannot respond to pings from R2 because they do not have a route for the OSPF network.
R1 and R9 cannot reach each other’s loopbacks or connected LANs.

Step 3: Redistribute OSPF into RIP on R4
Here is we encounter a loop. The reason is that once R4 does this it will now advertise RIP routes back to R1 and R5 that may have already been in RIP to begin with. So the problems will be with any existing RIP routes on these routers. R5 currently has a RIP route for R9 loopback with a metric of 1. R4 is going to redistribute this route back to R5 also with a mteric of 1 (the metric is up to use, but I use 1 for example). R5 now will load share between two routes to R9. One router will be a loop (the one through R4). R5 has no way of knowing that this route is the same route it redistributed into OSPF. We can resolve this by setting a higher metric on the routes that R4 redistributes into RIP. Setting the metric to 2 in this example resolves the issue.

R2 now has reachability to R1 and LAN14, but still no reachability to R9 because R9 has no route back. R9 also has no route to R1.

Step 4: Redistribute OSPF into RIP on R5
In the final step of redistribution R5, we may cause another loop by advertising R1’s loopback back to R4 over the serial link with a metric 1. However, we set the metric to 2 to rpevent this.

Shutting down serial link between R4 and R5:
Because this link is not used for any transit networks, this link does not affect reachability to R1 or R9 whether up or down.

Shutting down only R5 frame-relay interface:
R5 loses its OSPF networks and learns all routes via RIP through R4. R4 uses the RIP link to reach R9 and LAN59.

Shutting down only R4 frame-relay interface:
R4 loses it OSPF networks and learns all routes via RIP through R5. LAN14 and R1 are still learned directly from R1.