Ospf new dynamic route learnt

[IrmanGhaffar]

Hi all, 

  Hope someone can shed some light on a perplexing issue Iam having with ospf.

So I have a router with 2 peers (asbr's) connected to bgp peers further upstream into mpls.

If I am learning a prefix from peer 1 all is good and well, now let's say several hours later peer 2 also learnt the same route from upstream mpls.

It's come into my routers ospf database and has a better metric than the one my router already installed in its route table via peer 1.

Should the routing table discard the route to the prefix via peer1 and now install the route via peer 2?

I thought it should but seems the update is not dynamic by nature... 

Has anyone else come across this problem?

Thanks all

[Francesco Molino]

Hi

Based on description, a better route will always be preferred.

Now to see why it's not your case, can you show the detail of how this prefix is learned in ospf from both peers, also share the ospf database info for this specific prefix please.

[IrmanGhaffar]

Thanks for the replies.

A bit more on the topology then.

Core-1 and Core-2 have an Uplink to their respective local WAN router and run OSPF process 10 to it.

The local WAN router runs BGP up to the MPLS, and redistributes BGP routes --> OSPF 10 with a  metric of 255 and tags them. Core-1 routes are in OSPF process 10 and get redistributed into BGP so its all mutual.

The direct link between Core-1 and Core-2 is running OSPF process 11 as a P2P.

Core-1 and Core-2 also redistribute OSPF 10 --> 11 and visa versa.

Now lets look at Core-1 route table:

O E2 10.1.104.0/24 [110/255] via 10.2.101.253, 00:03:05, Vlan101
O E2 10.1.103.0/24 [110/255] via 10.2.101.253, 00:03:05, Vlan101

This shows the routes are E2, have a metric of 255 etc... This is coming from the local WAN router.

Meanwhile, 10.1.xxx.x actually originates from Core-2 (Vlans) in OSPF Process 10. Since redistribution is in play, it should also be an E2 route but should be a better metric than 255. 

Here is Core-1 OSPF Database:

OSPF Router with ID (10.255.255.252) (Process ID 11)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
10.255.255.252 10.255.255.252 444 0x8000002A 0x006981 1
10.255.255.253 10.255.255.253 463 0x8000002B 0x006581 1

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
10.255.255.253 10.255.255.253 463 0x80000026 0x0009ED

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 10.255.255.252 464 0x80000001 0x009D05 11
0.0.0.0 10.255.255.253 494 0x80000001 0x00970A 11
10.1.101.0 10.255.255.252 444 0x80000002 0x002C35 8888
10.1.101.0 10.255.255.253 1456 0x80000025 0x00C028 9991
10.1.102.0 10.255.255.252 444 0x80000002 0x00213F 8888
10.1.102.0 10.255.255.253 1456 0x80000025 0x00B532 9991
10.1.103.0 10.255.255.252 444 0x80000002 0x001649 8888
10.1.103.0 10.255.255.253 1457 0x80000025 0x00AA3C 9991
10.1.104.0 10.255.255.252 445 0x80000002 0x000B53 8888
10.1.104.0 10.255.255.253 1457 0x80000025 0x009F46 9991
10.2.101.0 10.255.255.252 954 0x80000024 0x0067DC 8881
10.2.101.0 10.255.255.253 464 0x80000002 0x008182 9999
10.2.102.0 10.255.255.252 954 0x80000024 0x005CE6 8881
10.2.102.0 10.255.255.253 464 0x80000002 0x00768C 9999
10.2.103.0 10.255.255.252 954 0x80000024 0x0051F0 8881
10.2.103.0 10.255.255.253 464 0x80000002 0x006B96 9999
10.2.104.0 10.255.255.252 954 0x80000024 0x0046FA 8881
10.2.104.0 10.255.255.253 464 0x80000002 0x0060A0 9999
10.173.0.0 10.255.255.252 697 0x80000023 0x0027D2 8888
10.173.0.2 10.255.255.253 972 0x80000023 0x007427 9999

OSPF Router with ID (10.2.101.254) (Process ID 10)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
10.2.101.253 10.2.101.253 1152 0x80000027 0x00034A 1
10.2.101.254 10.2.101.254 1127 0x8000002A 0x009A1F 4

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
10.2.101.253 10.2.101.253 1152 0x80000024 0x00C493

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
10.1.101.0 10.2.101.253 395 0x80000002 0x0050A8 8888
10.1.102.0 10.2.101.253 395 0x80000002 0x0045B2 8888
10.1.103.0 10.2.101.253 395 0x80000002 0x003ABC 8888
10.1.104.0 10.2.101.253 395 0x80000002 0x002FC6 8888
10.173.0.0 10.2.101.253 900 0x80000023 0x004B46 8888
10.173.0.2 10.2.101.254 357 0x80000002 0x00DA79 9999
10.255.255.252 10.2.101.253 397 0x80000002 0x00CF93 8888
10.255.255.252 10.2.101.254 359 0x80000002 0x0092A9 0

So I wonder what happens If i bring down CORE-1 WAN Link... 

O E2 10.1.104.0/24 [110/1] via 10.255.255.253, 19:02:47, Vlan901
O E2 10.1.103.0/24 [110/1] via 10.255.255.253, 19:02:47, Vlan901

Ah the better route is now in the routing table, but only because the worse one has disappeared. I would have thought this behaviour to be dynamic.... I.e. if the route with a metric of 255 is in the routing table and a better ones comes along, OSPF would withdraw the route with metric 255 from the routing table and install the one with a better metric.

Oh and I brought back the CORE-1 WAN router link, and the better metric route remained, until I repeated the whole failure situation again :)

If anyone wants config files let me know. Happy to provide.

Thanks

[paul driver]

Hello

It all depends on how the metric is seen, Ospf can count the costing of external routes differently.

Type E1 counts the sum of internal cost to the asbr and the external cost of the route
Type E2 counts the cost only the external cost of the route

Now if either of these are the same and a newer lsa comes in and that has a shorter path the the asbr then it should be that new lsa which gets installed into the rib.

sh ip ospf border-routers

res

Paul

[IrmanGhaffar]

Hey,

  Thanks doe the response Paul.

The output of he command is as below on Core-1

#show ip ospf border-routers

#

OSPF Process 11 internal Routing Table

Codes: i - Intra-area route, I - Inter-area route

i 10.255.255.253 [1] via 10.255.255.253, Vlan901, ASBR, Area 0, SPF 9

#

OSPF Process 10 internal Routing Table

Codes: i - Intra-area route, I - Inter-area route

i 10.2.101.253 [1] via 10.2.101.253, Vlan101, ASBR, Area 0, SPF 7

###

So for Process 10, the Border router is its local WAN router. However for 11 it is the adjacent Core-2 router (both cores have a physical P2P connection).

Wouldn't Core-1 also be an ASBR since it joins to another ospf Autonomous system (OSPF 11)?

I was under the impression if all Core-1 received 2 "E2" ospf prefixes, it would then compare metrics. In this case 255 is worse than 1 so it would choose the new prefix with lower metric and dynamically discard the prefix it had installed in the rib with a metric of 255.

Thanks again.

[Francesco Molino]

Can you share the following outputs please:
- sh ip protocols
- sh ip route 10.1.104.0 (everything has to be up)
- sh ip route 10.1.104.0 (wan 1 link has to be down like your example)

[IrmanGhaffar]

Hi Francesco,

Thanks for getting back to me. The output from core-1 as requested is below:

Core-1# show ip proto

Routing Protocol is "ospf 10"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 10.2.101.254
It is an autonomous system boundary router
Redistributing External Routes from,
ospf 11, includes subnets in redistribution
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Routing on Interfaces Configured Explicitly (Area 0):
Vlan104
Vlan103
Vlan102
Vlan101
Passive Interface(s):
FastEthernet0/0
... To ...
FastEthernet0/15
Vlan1
Vlan901
Routing Information Sources:
Gateway Distance Last Update
10.2.101.253 110 2d06h
10.2.101.254 110 3d01h
Distance: (default is 110)

#

Routing Protocol is "ospf 11"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 10.255.255.252
It is an autonomous system boundary router
Redistributing External Routes from,

ospf 10, includes subnets in redistribution
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Routing on Interfaces Configured Explicitly (Area 0):
Vlan901
Passive Interface(s):
FastEthernet0/0
.. To ..
FastEthernet0/14
Passive Interface(s):
FastEthernet0/15
Vlan1
Vlan101
Vlan102
Vlan103
Vlan104
Routing Information Sources:
Gateway Distance Last Update
10.255.255.252 110 2d06h
10.255.255.253 110 00:03:19
Distance: (default is 110)

sh ip route 10.1.104.0 (Everything us up)  <-- 10.1.104.0 exists on core-2 as an SVI

Core-1#show ip route 10.1.104.0
Routing entry for 10.1.104.0/24
Known via "ospf 10", distance 110, metric 255
Tag 8888, type extern 2, forward metric 1
Redistributing via ospf 11
Advertised by ospf 11 subnets route-map EAD-FILTER
Last update from 10.2.101.253 on Vlan101, 2d06h ago
Routing Descriptor Blocks:
* 10.2.101.253, from 10.2.101.253, 2d06h ago, via Vlan101
Route metric is 255, traffic share count is 1
Route tag 8888

 ## As you can see, route in RIB is being learned from its local WAN router (we want the direct link to be selected as best and end up in the RIB).

- show ip route 10.1.104.0 (Local WAN link is now down):

Core-1#  show ip route 10.1.104.0

Routing entry for 10.1.104.0/24
Known via "ospf 11", distance 110, metric 1
Tag 9991, type extern 2, forward metric 1
Redistributing via ospf 10
Advertised by ospf 10 subnets
Last update from 10.255.255.253 on Vlan901, 00:00:16 ago
Routing Descriptor Blocks:
* 10.255.255.253, from 10.255.255.253, 00:00:16 ago, via Vlan901
Route metric is 1, traffic share count is 1
Route tag 9991

WAN-1 router (WAN Link is still down, Fa0/0)

WAN-1# Show ip route 10.1.104.0

Routing entry for 10.1.104.0/24
Known via "ospf 10", distance 110, metric 1
Tag 9991, type extern 2, forward metric 1
Redistributing via bgp 65001
Advertised by bgp 65001 route-map DENY-TAG-OUT
Last update from 10.2.101.254 on FastEthernet0/1, 00:02:17 ago
Routing Descriptor Blocks:
* 10.2.101.254, from 10.2.101.254, 00:02:17 ago, via FastEthernet0/1
Route metric is 1, traffic share count is 1
Route tag 9991

*** Now if i bring the Fa0/0 on the WAN router up again (thats the WAN Link), the routing table remains constant i.e. 10.1.104.0 is still reachable via 10.255.255.253 (i.e. Local link). It will remain this way until the LAN link fails and we will end up in the situation we had in the output above i.e. 10.1.104.0 is reachable via the WAN, not LAN (even though LAN is back up).

Hope that makes sense....

I have tested this many times now, also included a more detailed diagram in the post which may help.

Thanks again for your help and assistance.

[Francesco Molino]

I don't see anything here that can say why you're getting the route from the other peer. Can you share your config please on all devices (route-maps and ospf).
You forgot adding the new detailed diagram.

[IrmanGhaffar · Accepted solution]

Hello Francesco,
I posted the detailed topology as per reply to Salemmahara comment...
In any case I think I have got to the bottom of the problem...
I am running 2 ospf processes on a single device. It would appear the one that makes it into the RIB first (from either OSPF 10 or 11) will remain in there regardless of metric. I tested this out by putting all devices and interfaces in the same OSPF process and it chose the metric as I expected it to..

If you agree with this let me know otherwise I will post more detailed configs here.

Thanks again

[Francesco Molino · Accepted solution]

I agree on this but I wanted to validate anyways with your real config, just to make sure.

I saw now the design and it appears that OSPF 11 is kind of backdoor/redundant link. I wouldn't set it up in area 0 but in another area.

[salemmahara]

Hi

We're here to help( If we can:) )

Could you pleasssssssssssse send us a topology diagram which shows addressing too? It must show your area design too.

Something like simple drawings which you can search.

I'll do my best to help you with my brief knowledge in Routing.

[IrmanGhaffar]

Hey Salemmahara,

I have attached a detailed diagram with IP addresses.

Let me know if you want me to explain it but the above should be a good explanation so far.

Thanks

[IrmanGhaffar]

Can anyone help with problem?

Driving me crazy!

Thanks

[paul driver]

Hello

---

@IrmanGhaffar wrote:

The direct link between Core-1 and Core-2 is running OSPF process 11 as a P2P.

Core-1 and Core-2 also redistribute OSPF 10 --> 11 and visa versa.

---

Why?  they are in the same backbone area anyway, Relocate them over to PID 11 and test again.

res

Paul

[IrmanGhaffar]

HI Paul,

  The reason I have the P2P running on its own OSPF instance is because I want to retain the route tagging element which is quite important for my setup

The question however does remain, why would an OSPF E2 route with a cost of 255 remain in the routing table when there there is another OSPF E2 route with a cost of 1 available?

I will however try to run a single OSPF instance with area 0 being the P2P, and area1/2 of the switches connected to the local WAN routers. Hopefully I will be able to tag in and out of ospf areas.

Thanks