How does ospf choose the perfer default-route

[Hele Du]

Hi everyone,

I have a topology like following,

The both R1 and R2 are generate a default route which is used default-information originate always respectively.

On R3 and R4 I can see two default routes like following,

On R5 , I also can see two default routes ,but its from one router(when I used "clear ip ospf pro" on one of them , it will choose another one). Like the following,

These are also two different type 5 LSAs in R5`s database.

So how does R5 choose the default route ? Is the first receive default route will install in route table?

[Rolf Fischer]

I think this is more related to the routing-table than to OSPF.

A show ip ospf border-router should look more or less like this:

i 1.1.1.1 [2] via 192.168.45.4, FastEthernet1/0, ASBR, Area 0, SPF 11

i 1.1.1.1 [2] via 192.168.35.3, FastEthernet0/0, ASBR, Area 0, SPF 11

i 2.2.2.2 [2] via 192.168.45.4, FastEthernet1/0, ASBR, Area 0, SPF 11

i 2.2.2.2 [2] via 192.168.35.3, FastEthernet0/0, ASBR, Area 0, SPF 11

Both ASBRs are reachable through the same two links each, both in the same area and with the same cost.

The originating ASBR has to be reachable from R5 to install it's external OSPF prefixes into the routing-table but there is no preference for one ASBR over the other when the next-hops and the costs are the same. So the information from the first received LSA will be used to install the route, and with reception of the second LSA the routing-table doesn't have to be updated because the second LSA it doesn't have a better path nor an alternative path to the current (note that the originating ASBR is not part of the routing-table, just prefixes, metrics and next-hops).

When you clear the process of the ASBR which is currently announcing the default-route for R5, it's LSAs will be deleted and the LSA of the other ASBR will make it meanwhile because they are still in the LSDB.

HTH

Rolf

[Jon Marshall]

Rolf

I am glad you answered because i couldn't figure this out

Why does OSPF not simply add the other defaault routes to the routing table when it receives them as the default i believe is up to 4 equal cost routes. I understand what you are saying about the router simply using the first ones, but are you saying once the SPF calculation has been done any routes received that are the same type and cost are not used ?

Jon

[Rolf Fischer]

Hi Jon,

to be honest: I had to lab it in gns3 and play for a while ;-)

Why does OSPF not simply add the other defaault routes to the routing  table when it receives them as the default i believe is up to 4 equal  cost routes.

the point is that from the routing-table's perspective, there are only 2 equal cost routes.

One with 192.168.35.3 (in my example above) and one with 192.168.45.4 as the next hop. The fact that R5 learns the very same information originated from another ASBR as well doesn't require the installation of additional routes, as the next-hops and metics are exacly the same. There simply is nothing to load-share when the next-hops are the same.

Does that make sense?

Rolf

[Jon Marshall]

Rolf

Yes it makes perfect sense and i'm glad you are around to explain these sort of things to people like me

Thanks very much.

Jon

[Rolf Fischer]

Jon,

thanks for your kind words. I've been learning so much here at CSC so I'm always glad when I'm able to give something back.

Best regards

Rolf

[Rolf Fischer · Accepted solution]

Just an update: I tried another IOS (12.4T train) on R5 and found out that the behaviour now is slightly different:

Now it seems that the newest LSA is installed in the routing table:

! clear ip ospf proc on 2.2.2.2

Dec 11 21:23:47: OSPF-RIB-LOCAL: Add 0.0.0.0/0.0.0.0, area dummy area, type 8, dist 12, forward 11, tag 0x1, via 192.168.45.4 FastEthernet0/1, route flags 0x800, path flags 0x0, source 1.1.1.1, spf 26, list-type 3

Dec 11 21:23:47: OSPF-RIB-LOCAL: Add 0.0.0.0/0.0.0.0, area dummy area, type 8, dist 12, forward 11, tag 0x1, via 192.168.35.3 FastEthernet0/0, route flags 0x800, path flags 0x0, source 1.1.1.1, spf 26, list-type 3

Dec 11 21:23:47: OSPF-RIB-GLOBAL: Network update succeeded 0.0.0.0/0.0.0.0, via 192.168.45.4 on FastEthernet0/1, distance 12, flags 0x0, source 1.1.1.1, tag 0x1, type 8, return: 0

Dec 11 21:23:47: OSPF-RIB-GLOBAL: Network update succeeded 0.0.0.0/0.0.0.0, via 192.168.35.3 on FastEthernet0/0, distance 12, flags 0x0, source 1.1.1.1, tag 0x1, type 8, return: 0

show ip ospf rib 0.0.0.0 0.0.0.0

*>  0.0.0.0/0, Ext1, cost 12, tag 1

     flags 0x1, SPF Instance 34, age 00:00:10, fwd cost 11

      via 192.168.45.4, FastEthernet0/1

       flags 0x4, LSA: 5/0.0.0.0/1.1.1.1

      via 192.168.35.3, FastEthernet0/0

       flags 0x4, LSA: 5/0.0.0.0/1.1.1.1

! ~5 seconds later (SPF run)

Dec 11 21:23:53: OSPF-RIB-LOCAL: Add 0.0.0.0/0.0.0.0, area dummy area, type 8, dist 12, forward 11, tag 0x1, via 192.168.45.4 FastEthernet0/1, route flags 0x800, path flags 0x0, source 1.1.1.1, spf 29, list-type 3

Dec 11 21:23:53: OSPF-RIB-LOCAL: Add 0.0.0.0/0.0.0.0, area dummy area, type 8, dist 12, forward 11, tag 0x1, via 192.168.35.3 FastEthernet0/0, route flags 0x800, path flags 0x0, source 1.1.1.1, spf 29, list-type 3

Dec 11 21:23:53: OSPF-RIB-LOCAL: Add 0.0.0.0/0.0.0.0, area dummy area, type 8, dist 12, forward 11, tag 0x1, via 192.168.45.4 FastEthernet0/1, route flags 0x800, path flags 0x0, source 2.2.2.2, spf 29, list-type 3

Dec 11 21:23:53: OSPF-RIB-LOCAL: Add 0.0.0.0/0.0.0.0, area dummy area, type 8, dist 12, forward 11, tag 0x1, via 192.168.35.3 FastEthernet0/0, route flags 0x800, path flags 0x0, source 2.2.2.2, spf 29, list-type 3

Dec 11 21:23:53: OSPF-RIB-GLOBAL: Network update succeeded 0.0.0.0/0.0.0.0, via 192.168.45.4 on FastEthernet0/1, distance 12, flags 0x0, source 2.2.2.2, tag 0x1, type 8, return: 0

Dec 11 21:23:53: OSPF-RIB-GLOBAL: Network update succeeded 0.0.0.0/0.0.0.0, via 192.168.35.3 on FastEthernet0/0, distance 12, flags 0x0, source 2.2.2.2, tag 0x1, type 8, return: 0

show ip ospf rib 0.0.0.0 0.0.0.0

*>  0.0.0.0/0, Ext1, cost 12, tag 1

     flags 0x1, SPF Instance 35, age 00:02:58, fwd cost 11

      via 192.168.45.4, FastEthernet0/1

       flags 0x4, LSA: 5/0.0.0.0/2.2.2.2

      via 192.168.35.3, FastEthernet0/0

       flags 0x4, LSA: 5/0.0.0.0/2.2.2.2

[Hele Du]

HI Rolf,

Thank you for you answer.

I used 12.4 25D yesterday, I thought the oldder LSA would installed in routing table in that topology on R5.

I will test 12.4T today, may be it will as your shown choose the newer LSA  install in routing table.

[Hele Du]

Hi Rolf,

I had tested 12.4 T8 on my GNS 3 with 7200 series.

It as your shown would be install a newer LSA in their routing table on that scenario

[Rolf Fischer]

Thanks for the feedback!

I think the interaction between routing protocol data structures and the routing tables will always depend on the (I)OS implementation.

Using the most recent information sounds logical, whereas keeping the previous information can be the more stable approach.

However, we could see that from a routing-table's perspective this doesn't make a difference. The routes have to be refreshed after a SPF run in both cases and the result is also the same, regardless from which ASBR the routes are taken.

Pretty interesting discussion!

Best regards

Rolf