OSPF "default-information originate always" trouble

[borek]

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.

Can someone enlighten me?

--

Borek Lupomesky

Vodafone CZ

[Richard Burts]

Borek

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.

HTH

Rick

[Tharak Abraham]

Borek,

1.What role does that router which you did a default-info-originate play in the network ?

Does it peer with BGP from the ISP ?

2. Please post a "sh ip route" on the router doing the default-info

or

Type in a default route on the same router to the legitimate next hop

3.If you dont mind, just draw in your approach/ edge-design and we will help you get rid of the black hole !!

[borek]

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?

[Richard Burts]

Borek

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.

HTH

Rick

[Giuseppe Larosa]

Hello Borek,

>> but the original question was why does "default-information originate  always" drop default route even when it has it in OSPF database,  remember?

I agree with Rick, with always keyword you are asking to originate an LSA type 5 for net 0.0.0.0/0 regardless of the presence of a default  route in local node IP routing table.

Actually if the always option is removed, and an OSPF default route is received from an OSPF neighbor it is accepted and the locally generated route is suppressed.

If the local node would accept the default route coming from OSPF domain it should suppress its own advertisement.

In a case like yours I would use

I would not use the always keyword

you can use a route-map to check the existance of a BGP route 0.0.0.0 with a certain IP next-hop

metric type O E1

alternatively, if no BGP default route is received you could use reliable static routing to check the state of IP next-hop of a local static route for 0.0.0.0/0.

see

http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html

I would use max metric waiting for BGP.

if the link to ISP fails it is likely to be down for more then 3 minutes so the focus should be in correct handling of real faults.

Edit:

yes max-metric external-lsa wait-for-bgp

says until BGP table is converged

http://www.cisco.com/en/US/docs/ios/iproute_ospf/command/reference/iro_osp2.html#wp1012938

Hope to help

Giuseppe

[syed_khalid_khursheed]

hi,

1- If both router are originating a default route with "ALWAYS" keyword and both installs the route of each other, this could create a routing loop.

2- you can always install a default route even with the "ALWAYS" keyword, if the Administrative Distance is lower than that of OSPF; which 110.

3- Usually the "ALWAY" keyword is not a wise chioce, unless downstream routers don't have any other exit.

HTH

Syed Khalid Ali