OSPF networks advertised even after undoing the network command?

[paperangel220]

I have a network in Packet Tracer 8.2 that looks like this:

All of the interface addresses are configured correctly.

My OSPF configuration on R1 is:

router ospf 1
network 209.165.0.0 0.0.0.255 area 0
network 192.168.3.0 0.0.0.255 area 0

My OSPF configuration on R2 is:

router ospf 1
network 209.165.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0

I then removed the 192.168.3.0/24 network in OSPF on R1 with:
no network 192.168.3.0 0.0.0.255 area 0

However, even after I fast forwarded, the 192.168.3.0/24 network is present on R2's routing table

I have to close Packet Tracer and then reopen it for the route to disappear.

Why is this the case? Is this normal or is it a bug in Packet Tracer? Thanks for the help!

[David Ruess · Accepted solution]

Hello,

After removing the network it will take some time for the OSPF process to gather up the info and send a "max-age" for the network to R2 basically saying age it out of your database. It shouldn't take THAT long but I have seen it take about 30 seconds, and up to a minute. Also keep in mid PT is not exact in the way it processes things because its a simulator and not all functions work at 100%. Sometimes it just gets "stuck".

You can also do a 

clear ip ospf process

on one of the routers and type y for yes when it prompts you. This SHOULD speed things along without you having to close the program.

Hope that helps

-Daivid

[MHM Cisco World]

just you must wait until prefix is age out. 
or instead of remove

net 

command under ospf you can shut the link and the router immediate send withdraw update to all router declare that the link is down and this prefix in not aviable anymore. 

[Joseph W. Doherty]

As a side note, this "timeout" issue, can be a (serious) real-world problem too.  Not, usually caused by removing a network statement, but by lost of path connectivity that takes a bit of time to detect, like relying on OSPF adjacency timeouts, where by default, the lost of a working path might take up to 40 seconds.  Even in cases of an valid secondary path, traffic might be directed toward the loss path (a black hole) until the routing table is updated.