Understanding OSPF

[DrakoNoo]

Hello,

Hopefully this isn't too confusing to look at but I'm playing around with this test topology in GNS3 to get a better understanding of how OSPF works.  

My question is when looking at the routing table of router "Three-Two" it sees the loopback 2.2.2.2 from Router "Two" via OSPF2 as an internal route.  If I shutdown the link (red X) router "Three-Two" then sees the route to 2.2.2.2 via the external redistributed route from OSPF1.  Makes sense to me so far except when the link gets re-enabled router "Three-Two" keeps the external route in the routing table and stays that way.  Should the internal route not get put back into the routing table once the link comes back up or is there something that I'm not understanding.

Before link failure:

Three-Two#show ip route | include 2.2.2
O 2.2.2.2 [110/21] via 172.29.23.2, 00:00:08, Ethernet1/3

After link failure:

Three-Two#show ip route | include 2.2.2
O E2 2.2.2.2 [110/500] via 30.20.20.1, 00:00:07, Ethernet0/0

Thanks

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/4170-ospfprocesses.html

I think this unpredictable behave of run two ospf process and redistrubte prefix between it.

Can you change AD of one process and check result 

MHM

[David Ruess]

Hello,

Can you provide the results of the show ip ospf database command. During and after link failure. This is to check to see if the device is even learning the route back from its internal path (which I believe it should be).

-David

[DrakoNoo]

Thanks MHM for the suggestion.  If I set the OSPF2 intra-area distance on router "Three-Two" to 105 the route does fail back and forth properly.

[DrakoNoo]

Hi David,

Without playing around with the AD settings this is what the database looks like during/after the link failure.

During failure

Three-Two#show ip ospf 2 database

OSPF Router with ID (172.29.23.3) (Process ID 2)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
172.29.23.3 172.29.23.3 2 0x80000001 0x002856 1

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 172.29.23.3 1 0x80000001 0x0082C4 33
2.2.2.2 172.29.23.3 1 0x80000001 0x0054EE 33
3.3.3.3 172.29.23.3 1 0x80000001 0x00A8EF 33
10.20.20.0 172.29.23.3 1 0x80000001 0x0060B8 33
10.30.30.0 172.29.23.3 1 0x80000001 0x00798B 33
20.10.10.0 172.29.23.3 2 0x80000001 0x00C45E 33
20.30.30.0 172.29.23.3 2 0x80000001 0x00F604 33
30.10.10.0 172.29.23.3 2 0x80000001 0x001F4A 33
30.20.20.0 172.29.23.3 2 0x80000001 0x00D38B 33
172.29.12.0 172.29.23.3 2 0x80000001 0x000A6B 33
172.29.13.0 172.29.23.3 3 0x80000001 0x00FE75 33

Link brought back up

Three-Two#show ip ospf 2 database

OSPF Router with ID (172.29.23.3) (Process ID 2)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
2.2.2.2 2.2.2.2 338 0x80000003 0x006587 3
20.10.10.2 20.10.10.2 816 0x80000004 0x007606 1
172.29.23.2 172.29.23.2 14 0x80000012 0x00F3DA 2
172.29.23.3 172.29.23.3 9 0x80000013 0x003254 1

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
20.10.10.2 20.10.10.2 344 0x80000004 0x00F1BE
20.30.30.2 172.29.23.2 343 0x80000005 0x000B0B
172.29.23.3 172.29.23.3 13 0x80000001 0x005358

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 20.10.10.2 241 0x80000003 0x002F35 11
1.1.1.1 172.29.23.3 78 0x80000001 0x0082C4 33
2.2.2.2 172.29.23.3 78 0x80000001 0x0054EE 33
3.3.3.3 20.10.10.2 1102 0x80000002 0x00ED20 11
3.3.3.3 172.29.23.3 80 0x80000001 0x00A8EF 33
10.20.20.0 20.10.10.2 242 0x80000003 0x000334 11
10.20.20.0 172.29.23.3 80 0x80000001 0x0060B8 33
10.30.30.0 20.10.10.2 242 0x80000003 0x008098 11
10.30.30.0 172.29.23.3 80 0x80000001 0x00798B 33
20.10.10.0 172.29.23.3 80 0x80000001 0x00C45E 33
20.30.30.0 172.29.23.3 80 0x80000001 0x00F604 33
30.10.10.0 20.10.10.2 1102 0x80000002 0x000ADD 11
30.10.10.0 172.29.23.3 80 0x80000001 0x001F4A 33
30.20.20.0 20.10.10.2 1102 0x80000002 0x0023B0 11
30.20.20.0 172.29.23.3 16 0x80000004 0x00CD8E 33
172.29.12.0 20.10.10.2 242 0x80000003 0x004855 11
172.29.12.0 172.29.23.3 80 0x80000001 0x000A6B 33
172.29.13.0 20.10.10.2 244 0x80000003 0x006A14 11
172.29.13.0 172.29.23.3 82 0x80000001 0x00FE75 33
172.29.23.0 20.10.10.2 383 0x80000001 0x005ADF 11

Thanks

[David Ruess]

Well it does show its learning it back after the link failure. Not sure why its not putting it back in the routing table. You could also do a debug ip routing on the router to see what's added/removed from the routing table when you fail and enable the link again.

[Giuseppe Larosa · Accepted solution]

Hello @DrakoNoo ,

what you see is normal because you are dealing with two different OSPF processes and both of them compete for installing a route for prefix 2.2.2.2.

However, the distinction between types of routes intra area , inter area , external routes work only within a single OSPF process.

This is called "ships in the night".

Simply put each process presents a candidate route with AD 110 and a metric to the IP routing table manager daemon that picks up one in case of  a tie on both AD, metric value. The IP routing table manager is not aware that one process has an internal route and the other one has an external route.

For better tuning in  a scenario like yours one OSPF process should act as the core process and the other one as edge process.

In both OSPF processes you can use the following command

distance ospf   <O distance > <O IA distance > < O Ex distance>

the default is 110 for all three , but you can increase the AD for external routes to avoid the competition

Hope to help

Giuseppe

[Ruben Cocheno · Accepted solution]

@DrakoNoo 

That seems that fact that you using different processes, and the router doesn't prefer one over the other. This interesting article is about multiple processes and redistribution.

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/4170-ospfprocesses.html#toc-hId--1391470770

[DrakoNoo]

Interesting - I didn't catch that part in the article.  Seems to be exactly what was happening.

 Now, if a route is installed via one process, it is not overwritten by another OSPF process with the same administrative domain (AD), unless the route is first deleted from the routing table by the process that initially installed the route in the routing table.

Funny enough I tried using a different image/router in GNS3 and it did fail over properly.  I guess as mentioned the behavior is unpredictable when configured this way and should be avoided in a real network.

Thanks

[paul driver]

Hello
TBH that is extremely convoluted to read through and to understand exactly what your trying to accomplish.
Bellow is the OSPF path section criteria which you could review and assist you in what you are trying to achieve.

pre 15.1 ios release
Intra-Area (O)
Inter-Area (O IA)
External Type 1 (E1)
NSSA Type 1 (N1)
External Type 2 (E2)
NSSA Type 2 (N2)

post 15.1 ios release
Intra-Area (O)
inter-Area (O IA)
NSSA Type 1 (N1)
External Type 1 (E1)
NSSA Type 2 (N2)
External Type 2 (E2)

[MHM Cisco World]

So in end you change AD as I suggested in first post or not? 

MHM