RIP v2 and OSPF Redistribution Problem

[AbouFares]

Hello Everybody,

I am struggling with redistributing RIP (v2) & OSPF and some help on that would be much appreciated. So, here some context:

I am new to routing and our teacher asked us to set up two networks in Packet Tracer, one running with RIP v2 and the other one with OSPF, and to finally interconnect them. So I've basically configured two times 4 routers, each one connected to one PC. In the first group of 4 routers, I've launch RIP v2 and in the second group, I've launch OSPF. Here below a screenshot of each network (don't pay attention to the yellow lines yet, they will be used for the interconnection later):

FIRST NETWORK - RIP v2

SECOND NETWORK - OSPF

Till there, everything is fine and all PC wihtin one network can ping each other successfully. I've simply used the following command to configure the RIP v2 for each router (example provided for the router 1 - the things between bracket, e.g. (ou conf t), weren't used):

 And the following commands for configuring OSPF (example provided for the router 5):

The result of show running-config for each router is not shown here to avoid too heavy text but it's basically the same as shown in the diagram above.

To interconnect the two networks, I've added two central routers assuring the role of redistribution as shown below:

I've used following commands to configure these routers in both mode (RIP v2 and OSPF) as well as to lauch the redistribution:

ROUTEUR 9

ROUTEUR10

This is where the problem stands. At one period in time, this works very fine. The route tables were first generated correctly and I was able to ping from one PC of the first network to another PC of the second network and the other way around. However, after putting on sleep my compuer for two days and quickly double checking that everything was still fine before going to my teacher to defend the case orally, the interconnection was not working anymore. I cancelled and rewrite everything (from no router rip & no router ospf to the command shown above) and it worked again. Then, guess what?! When in front of my teacher (just after driving from home to school), it was again not working and althought I tried to debug the thing by rewriting everything during one hour, I was unsuccessfull...

Now, it's probably too late to pass the exam but I'm really curious to understand what happened? I noticed the routing table of ROUTER 9 I documented in my report before putting on sleep my laptop were different (and correct) than the ones when I was in front of my teacher. Here is what I wrote in my report:

And here the current table for the same router:

"Router#sh ip route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

O E2 192.168.0.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O E2 192.168.1.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O E2 192.168.2.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O E2 192.168.3.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

192.168.4.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.4.0/24 is directly connected, GigabitEthernet0/0

L 192.168.4.1/32 is directly connected, GigabitEthernet0/0

192.168.5.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.5.0/24 is directly connected, GigabitEthernet0/1

L 192.168.5.1/32 is directly connected, GigabitEthernet0/1

O E2 192.168.11.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O E2 192.168.12.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O E2 192.168.13.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O E2 192.168.14.0/24 [110/20] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O 192.168.40.0/24 [110/4] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O 192.168.41.0/24 [110/3] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O 192.168.42.0/24 [110/3] via 192.168.112.2, 00:06:33, GigabitEthernet0/2

O 192.168.43.0/24 [110/4] via 192.168.112.2, 00:06:33, GigabitEthernet0/2

O 192.168.44.0/24 [110/4] via 192.168.112.2, 00:06:33, GigabitEthernet0/2

O 192.168.45.0/24 [110/3] via 192.168.112.2, 00:06:33, GigabitEthernet0/2

O 192.168.46.0/24 [110/3] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O 192.168.47.0/24 [110/3] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O 192.168.48.0/24 [110/2] via 192.168.112.2, 00:06:53, GigabitEthernet0/2

O 192.168.49.0/24 [110/2] via 192.168.112.2, 00:06:33, GigabitEthernet0/2

192.168.112.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.112.0/24 is directly connected, GigabitEthernet0/2

L 192.168.112.1/32 is directly connected, GigabitEthernet0/2

Router#"

Notice the difference: no R anymore in the table and for packets destinated to network 192.168.12.0 it is now sent to 192.168.112.2 (which is incorrect and creating a loop when the packet is returning from an OSPF PC to a RIP PC) while previously it was correctly sent to 192.168.4.2. Actually, now everything is wrongly sent to 192.168.112.2. Besides, I've also noticed the following sentence:

"192.168.5.0/24 is variably subnetted, 2 subnets, 2 masks

C 192.168.5.0/24 is directly connected, GigabitEthernet0/1

L 192.168.5.1/32 is directly connected, GigabitEthernet0/1"

which seem to me very wierd since evey mask I've used in the project is the same (255.255.255.0) and I expect then same /24 everywhere...

Now my question is threefold:

Q1. is there anything wrong with commands used to interconnect both network (one running on RIP v2 and the other on OSPF) as shown above?

Q2. How can we explain that it first worked twice before no more working in between putting computed to sleep?

Q3. What could be corrected to make the ping between one PC running on RIP v2 to one PC running on OSPF working?

In advance, many thanks for your clarificaiton!

With my best regards,

[Francesco Molino]

Hi

Can you share your packet tracer file with your configs done?

Your config looks like ok.

However, based on the output, it seems there's a loop and if that's the case, this is normal that R9 learns the route from OSPF as the AD is lower than RIP AD.

With your simulation file, I'll be able to check if there's a loop or something else.

[AbouFares]

Hi Francesco,

Thanks for your reply !

Sure, please find attached the last version of my Packet Tracer file (version saved just before going to my teacher when the pings were working and routing table of ROUTER 9 was correct).

It seems indeed there is a loop originating from ROUTER 9 because this latter sends back any traffic coming from the right side (running on OSPF) via ROUTER 10 to ROUTER 10 again (as shown in its table "via 192.168.112.2") while it should send it to the left side (network running on RIP v2). But I still cannot explain why ROUTER 9's table has changed from the one captured in my report (screenshot above) to the current one with everyting being sent to 112.2 (copy-paste above). I saved all config with the command "copy running-config startup-config" though.

In advance, many thanks for your investigation!

With my best regards,

PS:it seems not possible to attach the PacketTracer file here:

"The file CPR_Routage_Dynamique__v2_20180124.pkt does not have a valid extension for an attachment and has been removed. jpg,gif,png,xlsx,tar,rtf,csv,ppt,pptx,mov,mp4,qt,wmv,doc,docx,pdf,jpeg,txt,xls,arf are the valid extensions."

Should I share it with you via an alternative way (email)?

[Georg Pauwen]

Hello,

rename the .pkt file to a .jpg file, this allows you to upload...

[AbouFares]

Alright, thanks!

Here it is:

[Francesco Molino · Accepted solution]

Hi

First of all, just to recap, OSPF AD is 110 and RIP is 120. A router will always prefer the lowest one, then OSPF.

Usually, in real word, to avoid that type of issue, you'll:

• Tag RIP routes when redistributing them into OSPF
• Use route-map on RIP to deny this tagged subnets when redistributing OSPF into RIP.

These are recommendations and best practices when dealing with redistribution inter protocol and you need to take care of different AD to not do any loop.

Now in your design, you have RIP and OSPF configured between R9 and R10 and redistribution is done on both routers (R9 and R10) for both protocols. Based on protocol decision, OSPF will be preferred.

I don't see why you configured RIP on R10. R10 should be part of your OSPF world and R9 will be part of the 2 worlds.

The router doing the redistribution would be the one at the border of each world and that can be R9 or R10 but not both.

Also, you can deal with tags to limit that if you really want to have redistribution on both routers (again that's useless) but Packet Tracer isn't able to deal with redistribution and route-map where a real router will allow you such thing. Doing that will also complicate your design and that's not needed.

To solve your issue, remove the redistribution on R10 and also your RIP as it's useless. R9 will be kept as is with all redistribution and everything should work as expected. This is a solution.

As you can't deal with tag, you can modify the RIP AD lower than OSPF, let's say 95 and you would apply the following commands (it will set AD to 95 for routers coming from both R9 neighbors)

distance 95 192.168.4.2 0.0.0.0
distance 95 192.168.5.2 0.0.0.0

But the solution and simple one in your design is to remove R10 from RIP domain and redistribution as well from R10.

[AbouFares]

Hi Francesco,

Many thanks for your investigation and detailed explanation.

Concerning the fact of having two routers performing the redistribution, I was actually also planing to use just one router as responsible for joining both networks, which is the most logical and simple solution, but our teacher asked us explicitly to use more than one router for the junction (now, I start getting why: probably to get us in trouble :p), reason why I have two routers (R9 & R10) performing the redistribution. As the design is now, it is indeed pointless but the idea behind that was probably to have like 4 interconnected routers doing the join for redundancy purposes. Nevertheless, I did not adventure myself to that since I was already in trouble with just 2 routers...

However, I followed your instructions and removed RIP from R10 ("no router rip") as well as redistribution for remaining OSPF (no redistribute rip subnets) but I am afraid I still cannot ping successfully one PC from RIP world to another PC from OSPF world and vice-versa. The table of R9 is still sending everything to R10 (via 112.2) as shown above and when I tarce the route, it confirms that once packet gets into R9, it starts being ping-ponged between R9 and R10:

I have attached the updated Packet Tracer file for your review.

I did not try the alternative solution B you proposed (changing the default distance) though.

UPDATE: very wierd but while writing these words, it now started to work. It maybe just needed some time to refresh the config. Now, everything works perfectly. The ping works fine:

And the routes are automatically recomputed when shutting down an interface, which was the ultimate goal of that exercice. Example below when pinging PC4 from PC1 before and after sutting down Gig2/0 on ROUTER4:

I would remember as key takeover to have only one single router performing the junction OR to modify default distances.

Once again, a BIG thank you for your help Francesco!

With my best regards,

[Francesco Molino]

You're welcome.

And if you want to use 2 routers, you can have R9 and R10 in parallel connected both to R1 and R4 instead of connected in front together. In that way, it will work differently