When I configure an OSPF router with "default-information originate always", that router starts to unconditionally announce 0.0.0.0/0 route -- but the router itself will no longer have 0.0.0.0/0 router from other router(s) in its route table. See following output (abbreviated, the router has Lo0 = 192.168.0.2, 192.168.0.1 is other directly connected router):
Router#sh ip ospf database
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag 0.0.0.0 192.168.0.1 851 0x80000001 0x00291F 1 <-- other router's def.route 0.0.0.0 192.168.0.2 692 0x80000001 0x002324 1
Router#sh ip ro
Gateway of last resort is not set <-- I have 0.0.0.0/0 from rtr 192.168.0.1 in my DB, but not in RT
C 192.168.0.0/24 is directly connected, FastEthernet1/0
I don't quite get the logic of this behaviour and I couldn't find any explanation. The thing is, that my company has routing setup where this actually causes black hole routing, when one of the default-route-propagating routers loses its BGP routes.
I am confused about some parts of your question. Perhaps you can clarify and if we understand the situation more clearly perhaps we can give better answers about your issue.
You indicate that 192.168.0.1 and 192.168.0.2 are loopback addresses. But the routing table shows that 192.168.0.0 is directly connected on your FastEthernet interface:
C 192.168.0.0/24 is directly connected, FastEthernet1/0 How can this subnet be on your FastEthernet interface and addresses within that subnet be loopback addresses?
I am also puzzled why you want this router to be configured with default-information originate (and not sure why you need to specify "always"). If the only default route that the router has is the one that it learned from an OSPF neighbor then why would you want it to originate a default route and advertise it into OSPF?
It seems to me that your problem would be solved if you did not configure default-information originate on this router and let the network just use the default route generated by the OSPF neighbor. It seems to me that one default route in the network is enough. And as you explain forcing a second OSPF router to originate a default route can cause problems.
First of all, let me repeat the question I have: "Why does OSPF's 'default-information originate always' drop default router from routing table when it does have fully valid one received from another router in OSPF database".
BTW, the outputs in the original were from lab test (sorry about the confusion with the loopbacks). Below is actual diagram of actual network:
RTR A and B:
- have full BGP table from their ISP peers
- have iBGP session with each other
- participate in internal OSPF
- both have "default-information originate always" in their "router ospf N" section, so they inject default into the network; other routers use OSPF cost to decide which default to use
In steady state this works fine and there is no problem.
If one of the router is completely down, there is also no problem as the other handles all traffic and default route is injected properly.
Where things break up is when one of the router loses all BGP sessions. This means it is still announcing default route, but:
a) it does not have full BGP table (of course)
b) it does not have default route (ie. "Gateway of last resort is not set")
So traffic goes to this router which then drops it, because it does not know what to do with it. Actually, things are worse than that: when the other router (which has BGP up) announces default with better cost, traffic still gets black-holed, if the BGP-down router happens to be in the traffic flow's path.
So what, you say, just don't bring down BGP and you're all fine, what's the matter. The matter is, that when the router boots up, OSPF converges quickly, but before BGP loads full table, all traffic winding up at the router gets again black-holed. This can last some 3 minutes. Yes, I know OSPF can be configured to wait for BGP convergence, but the original question was why does "default-information originate always" drop default route even when it has it in OSPF database, remember?
When you configure a router under OSPF with default-information originate alway then you are instructing the router to always and unconditionally use its own default route. So it does not maintain a default learned from its neighbor.
It seems to me, based on your most recent explanation, that the optimum solution is not not configure the "always". If you configure the routers with default-information originate then if they have a learned default route they will generate the OSPF default route. And if they do not alreay have a learned default route then they will not advertise the OSPF default route. It seems to me that this would solve your problem.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...