Best Path Selection from different OSPF Process ID

When two OSPF processes are configured on a router and if same prefix is received on both OSPF process, it will be treated as like received from two different routing protocol and metric/LSA type will be ignored. Selection will be purely based on administrative distance. If the administrative distance is same, Router appears to select the best path based on lowest process ID.

The below topology has been configured to run OSPF process 1 and 100 on both R1 and R2.

The above statement has been tested by two test cases,

Test Case 1 :

Loopback 2 on R2 is redistributed into process 123 and configured with “network 22.22.22.0 0.0.0.255 area 0 “ into process 1.

R2#show run | sec ospf

router ospf 1

router-id 150.1.2.2

log-adjacency-changes

network 22.22.22.2 0.0.0.0 area 0

network 150.1.12.2 0.0.0.0 area 0

router ospf 123

router-id 2.2.2.2

log-adjacency-changes

redistribute connected subnets route-map CONN2OSPF

network 150.1.21.2 0.0.0.0 area 0

R2#

R2#route-map CONN2OSPF permit 10

match interface Loopback2

R2#

On R1, it can be confirmed that 22.22.22.0/24 is received as Type 1 LSA (router) via process 1 and Type 5 LSA (external) via process 123,

R1#show ip ospf database router 150.1.2.2 | inc Process|22.22

OSPF Router with ID (1.1.1.1) (Process ID 123)

OSPF Router with ID (150.1.1.1) (Process ID 1)

(Link ID) Network/subnet number: 22.22.22.2

R1#show ip ospf database external 22.22.22.0

OSPF Router with ID (1.1.1.1) (Process ID 123)

Type-5 AS External Link States

Routing Bit Set on this LSA

LS age: 1788

Options: (No TOS-capability, DC)

LS Type: AS External Link

Link State ID: 22.22.22.0 (External Network Number )

Advertising Router: 2.2.2.2

LS Seq Number: 80000001

Checksum: 0x90C5

Length: 36

Network Mask: /24

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 0.0.0.0

External Route Tag: 0

OSPF Router with ID (150.1.1.1) (Process ID 1)

R1#

On R1, it is observed that route from process ID of numerically less number is preferred. In our case, Type 1 LSA from OSPF process 1 is selected and installed in routing table.

Clearing the routing table or clearing OSPF process doesn’t make any difference.

R1#show ip route 22.22.22.0

Routing entry for 22.22.22.0/24

Known via "ospf 1", distance 110, metric 11, type intra area

Last update from 150.1.12.2 on Ethernet0/0.12, 00:00:17 ago

Routing Descriptor Blocks:

* 150.1.12.2, from 150.1.2.2, 00:00:17 ago, via Ethernet0/0.12

Route metric is 11, traffic share count is 1

R1#

R1#clear ip route *

R1#clear ip ospf process

Reset ALL OSPF processes? [no]: yes

R1#show ip route 22.22.22.0

% Network not in table

R1#show ip route 22.22.22.0

Routing entry for 22.22.22.0/24

Known via "ospf 1", distance 110, metric 11, type intra area

Last update from 150.1.12.2 on Ethernet0/0.12, 00:00:03 ago

Routing Descriptor Blocks:

* 150.1.12.2, from 150.1.2.2, 00:00:03 ago, via Ethernet0/0.12

Route metric is 11, traffic share count is 1

R1#

Test Case 2:

Loopback 2 on R2 is redistributed into process 1 and configured with “network 22.22.22.0 0.0.0.255 area 0 “ into process 123.

R2#show run | sec ospf

router ospf 1

router-id 150.1.2.2

log-adjacency-changes

redistribute connected subnets route-map CONN2OSPF

network 150.1.12.2 0.0.0.0 area 0

router ospf 123

router-id 2.2.2.2

log-adjacency-changes

network 22.22.22.2 0.0.0.0 area 0

network 150.1.21.2 0.0.0.0 area 0

R2#

On R1, it can now be observed that 22.22.22.0/24 is received as Type 1 LSA (router) via OSPF process 123 and Type 5 LSA (external) via OSPF process 1 as below,

R1#show ip ospf database router | inc Process|22.22.

OSPF Router with ID (1.1.1.1) (Process ID 123)

(Link ID) Network/subnet number: 22.22.22.0

OSPF Router with ID (150.1.1.1) (Process ID 1)

OSPF Router with ID (10.1.14.1) (Process ID 45)

R1#

R1#show ip ospf database external 22.22.22.0

OSPF Router with ID (1.1.1.1) (Process ID 123)

OSPF Router with ID (150.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA

LS age: 117

Options: (No TOS-capability, DC)

LS Type: AS External Link

Link State ID: 22.22.22.0 (External Network Number )

Advertising Router: 150.1.2.2

LS Seq Number: 80000001

Checksum: 0x5F63

Length: 36

Network Mask: /24

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 0.0.0.0

External Route Tag: 0

OSPF Router with ID (10.1.14.1) (Process ID 45)

R1#

On R1, it is observed that route from process ID of numerically less number is preferred. In our case, Type 5 LSA from OSPF process 1 is selected and installed in routing table.

Clearing the routing table or clearing OSPF process doesn’t make any difference.

R1#show ip route 22.22.22.0

Routing entry for 22.22.22.0/24

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10

Last update from 150.1.12.2 on Ethernet0/0.12, 00:03:17 ago

Routing Descriptor Blocks:

* 150.1.12.2, from 150.1.2.2, 00:03:17 ago, via Ethernet0/0.12

Route metric is 20, traffic share count is 1

R1#

R1#clear ip route *

R1#clear ip ospf pro

Reset ALL OSPF processes? [no]: yes

R1#

R1#show ip route 22.22.22.0

% Network not in table

R1#show ip route 22.22.22.0

% Network not in table

R1#show ip route 22.22.22.0

Routing entry for 22.22.22.0/24

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10

Last update from 150.1.12.2 on Ethernet0/0.12, 00:00:00 ago

Routing Descriptor Blocks:

* 150.1.12.2, from 150.1.2.2, 00:00:00 ago, via Ethernet0/0.12

Route metric is 20, traffic share count is 1

R1#

Testcase 3:

Now let us try test case 2 setup, but allow route received from Process ID 123 to be installed in routing table and then advertise same prefix via OSPF process 1.

I have shut the interface connected & Configured for OSPF Process 1 and receive route 22.22.22.0/24 only from Process 123.

R1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)#int e0/0.12

R1(config-subif)#shut

R1(config-subif)#

R1(config-subif)#do sh ip ospf data router | in Proce|22.22.22.

OSPF Router with ID (150.1.1.1) (Process ID 123)

(Link ID) Network/subnet number: 22.22.22.0

OSPF Router with ID (1.1.1.1) (Process ID 1)

OSPF Router with ID (10.1.14.1) (Process ID 45)

R1(config-subif)#do sh ip ospf data external 22.22.22.0

OSPF Router with ID (150.1.1.1) (Process ID 123)

OSPF Router with ID (1.1.1.1) (Process ID 1)

OSPF Router with ID (10.1.14.1) (Process ID 45)

R1(config-subif)#do show ip route 22.22.22.2

Routing entry for 22.22.22.0/24

Known via "ospf 123", distance 110, metric 2, type intra area

Last update from 150.1.21.2 on Ethernet0/0.21, 00:02:55 ago

Routing Descriptor Blocks:

* 150.1.21.2, from 2.2.2.2, 00:02:55 ago, via Ethernet0/0.21

Route metric is 2, traffic share count is 1

R1(config-subif)#

Now, I will un shut the interface and receive route 22.22.22.0/24 from Process 1.

R1(config)#int e0/0.12

R1(config-subif)#no shut

R1(config-subif)#do sh ip ospf data router | inc Proce|22.22.22.

OSPF Router with ID (150.1.1.1) (Process ID 123)

(Link ID) Network/subnet number: 22.22.22.0

OSPF Router with ID (1.1.1.1) (Process ID 1)

OSPF Router with ID (10.1.14.1) (Process ID 45)

R1(config-subif)#do sh ip ospf database external 22.22.22.0

OSPF Router with ID (150.1.1.1) (Process ID 123)

OSPF Router with ID (1.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA

LS age: 510

Options: (No TOS-capability, DC)

LS Type: AS External Link

Link State ID: 22.22.22.0 (External Network Number )

Advertising Router: 150.1.2.2

LS Seq Number: 80000013

Checksum: 0x3B75

Length: 36

Network Mask: /24

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 0.0.0.0

External Route Tag: 0

OSPF Router with ID (10.1.14.1) (Process ID 45)

R1(config-subif)#

It still can be observed that OSPF route from Process 123 is not preempted by route from Process 1.

When routing table is cleared, route from Process 1 will be installed.

R1#show ip route 22.22.22.2

Routing entry for 22.22.22.0/24

Known via "ospf 123", distance 110, metric 2, type intra area

Last update from 150.1.21.2 on Ethernet0/0.21, 00:07:18 ago

Routing Descriptor Blocks:

* 150.1.21.2, from 2.2.2.2, 00:07:18 ago, via Ethernet0/0.21

Route metric is 2, traffic share count is 1

R1#clear ip route *

R1#show ip route 22.22.22.2

Routing entry for 22.22.22.0/24

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10

Last update from 150.1.12.2 on Ethernet0/0.12, 00:00:01 ago

Routing Descriptor Blocks:

* 150.1.12.2, from 150.1.2.2, 00:00:01 ago, via Ethernet0/0.12

Route metric is 20, traffic share count is 1

R1#

Tried with modifying the router-id and it still it appears to select the route based on lowest process ID.

Conclusion:

The above testing appears that when a router running 2 OSPF processes receives same prefix from different process, it will ignore metric/LSA Type and will only check the Administrative Distance (AD). If both are same, it will install based on lowest process ID.

In case, we receive the prefix via highest process ID and already installed in routing table, it will not be preempted by the lowest process ID until you clear the routing table.

Note: This is not any Official statement and documented based on my testing and understanding.

Multi Area OSPF - Loop avoidance

The favorite OSPF question that pops up in most of the network interview is “Why does Multi-Area OSPF scenario requires all Inter-Area traffic to traverse over backbone area?”

The simple answer is to avoid routing loop. The detailed answer is below,

In OSPF Multi Area scenario, all OSPF routers will have full view of topology only within the area and have to rely on Area Border Router for information outside the area. This makes OSPF to behave like Distance Vector protocol. As it relies on information from neighbor and doesn’t have entire view of the topology outside the area, Inter-Area routes are subject to routing loop.

The above vulnerability results in need of some mechanism to avoid any Inter-Area routing loop.

RFC 2328 defines the way how Inter-Area routes will be calculated to avoid any routing loops.

As per RFC 2328, ABR definition and Inter-Area routes calculation are defined as below,

Area Border Router - Any router running OSPF attached to multiple areas is known as Area Border Router (ABR). An ABR will have topological information of all attached areas and will run SPF for each area. (Section 3.3)

Inter-Area Route Calculation - Inter-Area routes will be calculated by examining Summary LSAs (Type-3). If the OSPF router is attached to single area, it will examine Summary LSA of that area and if the OSPF router is connected to multi area (ABR), it will examine the backbone Summary LSAs. (Section 16.2)

On OSPF Multi-Area scenario, an ABR will perform Inter-Area route calculation based only on backbone Summary LSAs (i.e) Type 3 LSA received from backbone Area. So all inter-area traffic will obviously traverse over backbone and thereby avoiding any routing loops.

In this topology, when the above mentioned two definitions about ABR and Inter-Area route calculation are imposed, we may end up with routing issue as below,

As per ABR definition, R3 being attached to multiple area will assume it as ABR and will send Router LSA with Border bit set and will have Type 3 LSA from Area 1 and Area 2 in its respective topology table. R4 will see both R2 and R3 as border router.

As per Inter-Area route calculation definition, R3 being an ABR needs to examine/run SPF for Summary LSA only from backbone area and not from other areas. This rule stops R3 from running SPF on Summary LSA present in Area 1 and Area 2 and so no Inter-Area routes will be installed in R3’s routing table. The situation gets worse when internal OSPF routers in Area 2 have R3 as best path to reach R2.

Cisco’s Implementation is a bit different that, an OSPF router will assume itself as ABR only when at least one attached area is backbone.

This above Cisco definition about ABR helps to avoid such routing issues. Now R3 will not consider it as ABR as it doesn’t have any of its attached area as backbone. So will run SPF on Summary-LSA from both areas and so will have inter-area routes installed in routing table.

Verification:

• R3 will not set Border bit in Router LSA,

R4#show ip ospf database router 11.11.3.3 | inc Area Border

R4#show ip ospf database router 11.11.2.2 | inc Area Border

Area Border Router

R4#

• R3 will have SPF run on Summary LSAs from non-backbone and will be installed in routing table,

R3#sh ip route ospf

22.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

O 22.22.4.4/32 [110/49] via 11.11.34.4, 00:02:34, Serial2/0.34

O IA 22.22.22.2/32 [110/49] via 11.11.23.2, 00:02:34, Serial2/0.1

O 22.22.45.0/24 [110/49] via 11.11.34.4, 00:02:34, Serial2/0.34

11.0.0.0/8 is variably subnetted, 9 subnets, 2 masks

O IA 11.11.2.2/32 [110/49] via 11.11.23.2, 00:02:34, Serial2/0.1

O IA 11.11.1.1/32 [110/49] via 11.11.13.1, 00:02:34, Serial2/0.13

O IA 11.11.11.1/32 [110/49] via 11.11.13.1, 00:02:34, Serial2/0.13

O IA 11.11.12.0/24 [110/49] via 11.11.23.2, 00:02:34, Serial2/0.1

[110/49] via 11.11.13.1, 00:02:34, Serial2/0.13

O 11.11.24.0/24 [110/96] via 11.11.23.2, 00:02:34, Serial2/0.1

R3#

• R4 can reach R1’s loopback interface in Area 11 via R3,

R4#traceroute 11.11.1.1

Type escape sequence to abort.

Tracing the route to 11.11.1.1

1 11.11.34.3 212 msec 76 msec 40 msec

2 11.11.13.1 84 msec * 76 msec

R4#