Packet Tarcer lab tells me to remove OSPF process to troubleshoot

[hfakoor222]

Here is the

packet ttracer

lab, chapter 8 ENSARI ocg.

to troubleshoot it I recognized R3 on the top right had wrong OSPF area assigned. So I fixed it. Now routes aren't propogating from autside the area to R3. So I clear the ospf process. No luck. So i decide to see if shutting down interface off/on will help. No luck. So i look at the solution. And it states:

It appears that R3 is missing the

OSPFv2 interarea 192.168.0.0/21

summary route. To solve this problem, completely remove the

OSPFv2 routing

process from router R3 and then re-add it.

R3# configure terminal

R3(config)# no router ospf 1

R3(config)# router ospf 1

R3(config-router)# router-id 3.3.3.3

R3(config-router)# network 172.16.1.32 0.0.0.31 area 2

R3(config-router)# network 172.16.1.64 0.0.0.31 area 2

Would any one have a quick guess as to why it recommended me to remove ospf process and to reset it to propagate the routes? Shouldn't there be another way to fix this other than removing an entire protocol and resetting it? I looked through the running configs, nothing stood out to me. Just thought it was an odd recommendation as a solution, not sure if anyone has insight.

Here's R3 running config after I reset the OSPF process. I didn't even change the process configuration except for   

network 172.16.1.32.0 0.0.0.31

area 0

  changed it to

area 2

. That's all that was required. However routes from outside weren't propogating until i removed the process and reset it. Anyone have any insight as to why removing the protocol had this effect?

[M02@rt37]

Hello @hfakoor222,

Thanks for that share!

Removing and re-adding the OSPF process on R3 might have resolved the issue because it forces the router to reestablish OSPF neighbor relationships and relearn the OSPF database. When you changed the OSPF area configuration for R3, it's possible that the OSPF adjacency and routing information didn't update properly, causing the routes from outside the area to not propagate to R3.

By removing the OSPF process and reconfiguring it, you essentially reset the OSPF process on R3, allowing it to start fresh and rebuild the OSPF database with the correct area configuration. This ensures that all OSPF neighbors and routes are properly synchronized.

While removing and re-adding the OSPF process can be an effective troubleshooting step in some cases, it's not always the ideal solution. In a production network, such a step may disrupt routing and cause unnecessary downtime. In real-world scenarios, it's important to carefully analyze the configuration, OSPF database, and OSPF neighbor relationships to identify the root cause of the issue before resorting to such drastic measures.

In this specific case, it's possible that there was an underlying issue with the OSPF database or neighbor relationships that was resolved by removing and re-adding the OSPF process. Without more information, it's challenging to determine the exact cause.

[David Ruess · Accepted solution]

Hello,

Packet tracer

isnt perfect. I have run into many issues with routes not propagating. Even when processes are reset. Likely in a real life production network you would not have to do this as it would work adding the couple of commands.  It also takes OSPF a few seconds to flush its database and when moving routes to another area or changing metrics. Again,

packet tracer

isnt the best at this so it recommended just starting over as a way to not run into these issues.

-David

[Flavio Miranda]

Hi

 This might be a bug on the

packetTracer

and someone came up with this workaround. Make no sense on real world but in simulator we need to accept this kind of situation in order to move on with the lab.

[hfakoor222]

Thanks fo all the advice, what was strange is that this was the recommended solution.