clear ip route *

[izackvail]

I am a little confused on exactly what this command is doing depending on the routing protocol that I am running.

If run in RIP I believe this will clear the routing table and trigger an update. I know that in OSPF this will clear the routing table but I think it is just repopulating again with the OSPF database right? Is it forcing OSPF to run SPF? Does this force EIGRP to re-calculate routes?

I guess my question is:

Which IGP protocols does this command trigger an update for?

Does this command cause EIGRP and OSPF to run DUAL or SPF calculations?

Thank you!

[Richard Burts]

Izack

clear ip route * does not cause recalculation of routes in either OSPF or EIGRP. If you want to cause recalculation I would suggest that you clear a neighbor or perhaps clear the process.

HTH

Rick

[izackvail]

I understand how to force a recalculation. My question is what exactly is this command doing?

In EIGRP and OSPF it doesn't seem to me like it is really doing anything since this only seems to affect the routing table and not the topology or database. Is that a fair assessment or am I missing something?

[Richard Burts]

Izack

What the command is doing is to clear the content of the IP routing table and forcing the process that manages the IP routing table to relearn the routes and repopulate the table.

In terms of the EIGRP process and the OSPF process you are correct that it does not make any changes in these processes or their topology tables. It does make a change in the process that manages the content of the IP routing table.

HTH

Rick

[izackvail]

So in other words if there is a discrepancy between the routing table and the topology table in EIGRP or OSPF this would force the routing table to refresh and synchronize but wouldn't affect the EIGRP or OSPF routing processes. Is that correct?

I believe this does affect the RIP and IGRP routing processes though doesn't it? I think this actually triggers an update for those protocols?

[Richard Burts]

Izack

I do not believe that clear ip route * will trigger an update in any of the dynamic routing protocols.

HTH

Rick

[RanilG]

clear ip route *

clears the routing table, sends initialization messages to routing protocols and recalculates the default.

HTH

[johnlloyd_13]

all distance vector and link-state routing protocols will trigger an update if you issue this command.

ospf will run again spf and eigrp will also run again dual and apply to their topology table database in order to get the best routes, in other words to get a new routing table

remember the 3 tables: neighbor, topology and routing tables

[izackvail]

I actually ended up setting up a little lab. It turns out that with RIP "clear ip route *" does trigger an update and actually clears out the RIP database also.

With OSPF it doesn't trigger an update. I determined this by watching debug ip packet when I ran the clear command. It does however cause the SPF algorithm to run.

R2#sh ip ospf | i times

SPF algorithm executed 3 times

R2#clear ip route *

R2#sh ip ospf | i times

SPF algorithm executed 4 times

R2#clear ip route *

R2#sh ip ospf | i times

SPF algorithm executed 5 times

R2#clear ip route *

R2#sh ip ospf | i times

SPF algorithm executed 6 times

R2#clear ip route *

R2#sh ip ospf | i times

SPF algorithm executed 7 times

With EIGRP it triggers an update and causes EIGRP to recalculate the routing table.

R2#clear ip route *

R2#sh ip eigrp events | b 441

441 09:35:28.231 Conn rt change: 10.2.2.0/24 Loopback1

442 09:35:28.231 Lost route 1=forceactv: 10.2.2.0/24 0

443 09:35:28.231 Conn rt change: 172.16.1.0/24 Serial1/0

444 09:35:28.231 Lost route 1=forceactv: 172.16.1.0/24 0

445 09:35:28.231 Change queue emptied, entries: 1

446 09:35:28.231 Metric set: 10.2.2.0/24 128256

447 09:35:28.231 Update reason, delay: new if 4294967295

448 09:35:28.231 Update sent, RD: 10.2.2.0/24

449 09:35:28.231 Update reason, delay: metric chg 4294967295

450 09:35:28.231 Update sent, RD: 10.2.2.0/24 4294967295

451 09:35:28.231 Route install: 10.2.2.0/24 0.0.0.0

452 09:35:28.231 Find FS: 10.2.2.0/24 4294967295

453 09:35:28.231 Rcv update met/succmet: 128256 0

454 09:35:28.231 Rcv update dest/orig: 10.2.2.0/24 Connected

455 09:35:28.231 Metric set: 10.2.2.0/24 4294967295

456 09:35:28.231 Conn rt change: 10.2.2.0/24 Loopback1

457 09:35:28.227 Change queue emptied, entries: 1

458 09:35:28.227 Metric set: 172.16.1.0/24 2169856

459 09:35:28.227 Update reason, delay: new if 4294967295

460 09:35:28.227 Update sent, RD: 172.16.1.0/24 4294967295

461 09:35:28.227 Update reason, delay: metric chg 4294967295

462 09:35:28.227 Update sent, RD: 172.16.1.0/24 4294967295

463 09:35:28.227 Route install: 172.16.1.0/24 0.0.0.0

464 09:35:28.227 Find FS: 172.16.1.0/24 4294967295

465 09:35:28.227 Rcv update met/succmet: 2169856 0

466 09:35:28.227 Rcv update dest/orig: 172.16.1.0/24 Connected

467 09:35:28.227 Metric set: 172.16.1.0/24 4294967295

468 09:35:28.227 Conn rt change: 172.16.1.0/24 Serial1/0

R2#

[Richard Burts]

Izack

Thanks for posting back to this thread with the results of your setting it up in the lab. Frequently the best way to resolve questions like this is to set up routers and test it out. And your results are clear and convincing. They desserve the rating that I have given them.

HTH

Rick

[izackvail]

Thanks Rick!