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 0.0.0.0 was not there. A sh ip route 0.0.0.0 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 0.0.0.0 to be in the route table, which it is.
Try using 'default-information originate always' so the default route will be advertised whether or not the router has a default route
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.
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?
his device took a new router ID which without looking at his config, Im throwing a possible problem with redistribution. If he would of had the 'always' keyword in there it wouldnt of been removed, regardless of the new router id situation.
Like I said, too many theories and no configs to look at.
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 10.0.0.0 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.
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.
A clear ip route 0.0.0.0 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.
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.
I would have to say this situation will be unresolved until we look at configurations. If redistribution is a factor there could be many variable causing this. Dont you agree?