OSPF Default Information Originate

Unanswered Question
May 12th, 2007

I have 2821 routers at 2 sites running EBGP with service providers, and IBGP to each other. The 2821s run OSPF as an IGP and are connected to ASA5520 firewalls, and to each other. The 2821s are in area 0, with one site being area 1 and the other area 2. The ISPs are sending a default route as well as the full BGP table. Default information originate is used in OSPF at both sites to inject the BGP learned default route.

Yesterday we had an ASA crash and reload at one of the sites. It came up with a new router ID and was not passing routes inside or outside until we cleared the OSPF processes on the adjacent routers. Even then the default route was absent. Looked at the OSPF database in the 2821s and was not there. A sh ip route showed the BGP route as expected. I tried various clear commands, but finally just added always to the default information originate, and the default showed up in OSPF.

I am perplexed. This has worked fine for over a year. Dug into the books, and can find no other requirement for default information originate except for to be in the route table, which it is.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
sundar.palaniappan Sat, 05/12/2007 - 19:28

It sounds like a caveat in the IOS. If the default route exists in the routing table then OSPF should originate the default route without having to use the 'always' keyword.

The bug, if it turns out to be one, could be probably due to the fact the router mayn't be scanning the routing table regularly and that's probably the reason why OSPF failed to originate the default route. Just do a bug scrub and you may be able to spot the culprit.

I just noticed someone posted that you should use the 'default information-orignate always' command and that mayn't be viable option if you have redundant paths via another link/router. Moreover, OSPF should originate the default route without having to use the 'always' keyword as the default route does get repopulated in the routing table.



sundar.palaniappan Sat, 05/12/2007 - 19:40

Not sure what you are trying to say?

How do you explain this behavior where the default route exists in the routing table, learned via EBGP, but OSPF doesn't originate the default route. But, once the 'always' keyword is used it starts originating the default route?



dgahm Sun, 05/13/2007 - 22:01


I did configure the always to get it working, but since the ISPs are advertising a default, I should not have to do it that way. It would take a double point failure (lose both the ISP and connectivity to the other 2821)to black hole traffic, but I want to understand why this is happening, and was wondering if anyone else had seen this before. The crash on the ASA should not really have had any impact on this at all.

It is really a straight forward config, with no redistribution on the 2821s. On the router connecting to the ASA on the internal network I am doing mutual redistribution between OSPF and EIGRP, but with route maps to only pass the default and our public networks to the internal EIGRP, and to OSPF.

I agree that a bug makes the most sense, but it is unusual to run into a bug with such a basic OSPF function.


sundar.palaniappan Mon, 05/14/2007 - 04:36


I bet if you reload the 2800 it will start originating the default route without using the always keyword. I have seen a similar situation, not exactly the same, for one of my customers and we had to file a new IOS bug with the TAC.

Once the 2800 learns the default route after the outage the OSPF process should start originating the default route and that's not happening as you don't see an LSA in the database. It sounds to me as if the OSPF process isn't even paying attention to the routing table and the 'always' keyword causes the route to be originated irrespective of whether or not the route exists in the routing table.



dgahm Mon, 05/14/2007 - 11:29


A clear ip route fixed the default information originate.

So now I'm wondering if this is normal behavior for the OSPF default information originate to key only on changes to the route table. In this case the default route was always present in the route table, and was only lost from the OSPF database. That still doesn't explain why an OSPF router in area 1 could come up with a new router ID, and cause both BGP routers with OSPF default information originate (one of which doesn't touch area 1) to lose their OSPF default routes. It does tend to make me think it won't be a problem in the future unless we add a new ASA interface with a higher IP. I have a maintenance window in a couple weeks when I can do some testing.


sundar.palaniappan Wed, 05/16/2007 - 10:56

I don't see any rationale why the router should remove the default route LSA if the downstream neighbor's router-id changed. It doesn't look like normal behavior. All it's supposed to do is look at the routing table and if a default route exists then it has to originate an LSA for that. To add more value to our suspicion clearing the ip route resolves the problem.

Let us know what comes out of your testing.




This Discussion