Default routes advertised by protocols

CriscoSystems · ‎10-23-2009

I don't believe I THOROUGHLY understand the "default-information originate [always]" commands in OSPF, so I set something up in my lab wherein Router E ran OSPF and had the "default-information originate" command configured. Routers F,G, and H became neighbors, but things went wacko during the adjacency-formation process (a router with a lower ID became DR, one neighbor stayed in EXSTART for five minutes...it was MADNESS). So I powered down E, F, and G but left H on.

I noticed an hour later that despite Router E, the originator of the default route, being down for more than an hour, Router H still had the "candidate default" route in its table, with E's interface as the next hop.

As best I know, dynamic routing info would not stay in the route table of a neighbor router running a protocol if that route's next-hop router went dead.

So with advertised default routes, they are originated by a routing protocol on one router but then considered static by the routers that receive it?

(Also weirdly, I did clear ip route * on Router H and the default route disappeared but then reappeared anyway; despite Router E remaining completely unconnected.)

Giuseppe Larosa · ‎10-24-2009

Hello Stuey,

this is interesting to show some limits of link state protocols.

I remember a similar case of a colleague complaining of orphaned LSAs.

my understanding is that each LSA is a data structure with only one owner that is the advertising router.

The LSA is flooded in the OSPF area and all routers in the area have the same link state DB.

However, for a given LSA only the originator node can do the following:

it can refresh it after 30 minutes (half the maximum life of an LSA)

it can modify it

or when it is applicable like for an LSA type 5 it can withdraw it in order to be purged from the database.

You haven't said how your routers have been interconnected.

All we know is that an LSA type 5 describing a default route 0.0.0.0/0 has been originated by RE and successfully propagated to RH that has it in its LS DB.

Then suddenly you have decided to power off or isolate all OSPF routers with the exception of RH.

Then you look at RH, you see it has no OSPF neighbors and you still see this orphaned LSA in the routing table.

Edit:

I see more then hour later it was still there.

I would say this is more a SW bug that a characteristic of OSPF itself.

Hope to help

Giuseppe

CriscoSystems · ‎10-26-2009

They were all connected by token-ring.

Once E, F, and G were powered down (and I think I rebooted H in the meantime), H's ospf database looked well: It had only H's own Type 1 LSA in there.

Except I think that only raises more confusion about how E's default route got back in there!

This makes me wonder about how OSPF treats an advertised default route if the default route itself isn't an OSPF link: a scenario wherein the default route's next hop isn't participating in OSPF; and its link wasn't included in an OSPF router-config network statement on the advertising router...