OSPF Type-5's preferring to be advertised from BDR in OSPF DB?

[Oh Drother]

Hi all,

I was hoping for clarification regarding the OSPF database, with respect to the topology above. Both cores have type-7 LSAs coming from the directly redistributed subnets at 7236 site, which they then turn into type-5 LSA's. I'm confused as to why I am not seeing type-5's show from BOTH cores for the 7236 site subnets in the OSPF database. For whatever reason, the BDR (core-2) is somehow winning some sort of election in the OSPF database, and the 7236 sites show as being advertised only from core-2:

Router#show ip ospf database | b Type-5 AS External Link States
Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
10.19.96.0 10.3.0.135 527 0x80000002 0x007E26 1155
10.19.96.0 10.3.0.136 540 0x80000002 0x00782B 1155
10.210.111.0 10.3.0.135 527 0x80000002 0x0060B4 1155
10.210.111.0 10.3.0.136 540 0x80000002 0x005AB9 1155
10.210.122.0 10.3.0.135 527 0x80000002 0x005D6E 1155
10.210.122.0 10.3.0.136 540 0x80000002 0x005773 1155
10.210.124.0 10.3.0.135 527 0x80000002 0x004C7C 1155
10.210.124.0 10.3.0.136 540 0x80000002 0x004681 1155
10.210.126.32 10.3.0.135 527 0x80000002 0x003A8B 1155
10.210.126.32 10.3.0.136 540 0x80000002 0x003490 1155
10.212.16.0 10.3.0.136 396 0x80000001 0x00E251 7236
10.212.16.128 10.3.0.136 396 0x80000001 0x009B78 7236
10.212.17.0 10.3.0.136 396 0x80000001 0x009281 7236
10.212.22.0 10.3.0.136 396 0x80000001 0x0056B9 7236
192.168.23.0 10.3.0.136 396 0x80000001 0x001B68 7236
192.168.50.0 10.3.0.136 396 0x80000001 0x00F077 7236

From the router, we can clearly see that core-1 is the DR:

Router#show ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
10.3.0.135 200 FULL/DR 00:00:12 10.210.126.71 GigabitEthernet1
10.3.0.136 150 FULL/BDR 00:00:12 10.210.126.72 GigabitEthernet1

I know that core-1 has the ability to advertise the type-5's because if i shut the interface on core-2, facing the 7236 site, then the OSPF database will show as core-1 advertising them:

core-1# show ip ospf database external
OSPF Router with ID (10.3.0.135) (Process ID 100 VRF default)

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
10.19.96.0 10.3.0.135 766 0x80000002 0x7e26 1155
10.19.96.0 10.3.0.136 779 0x80000002 0x782b 1155
10.210.111.0 10.3.0.135 766 0x80000002 0x60b4 1155
10.210.111.0 10.3.0.136 779 0x80000002 0x5ab9 1155
10.210.122.0 10.3.0.135 766 0x80000002 0x5d6e 1155
10.210.122.0 10.3.0.136 779 0x80000002 0x5773 1155
10.210.124.0 10.3.0.135 766 0x80000002 0x4c7c 1155
10.210.124.0 10.3.0.136 779 0x80000002 0x4681 1155
10.210.126.32 10.3.0.135 766 0x80000002 0x3a8b 1155
10.210.126.32 10.3.0.136 779 0x80000002 0x3490 1155
10.212.16.0 10.3.0.135 111 0x80000001 0xe84c 7236
10.212.16.128 10.3.0.135 111 0x80000001 0xa173 7236
10.212.17.0 10.3.0.135 111 0x80000001 0x987c 7236
10.212.22.0 10.3.0.135 111 0x80000001 0x5cb4 7236
192.168.23.0 10.3.0.135 111 0x80000001 0x2163 7236
192.168.50.0 10.3.0.135 111 0x80000001 0xf672 7236

As far as routing goes, we are equal cost load-balancing to both cores for the subnets at 7236:

Router#show ip route ospf 100 | b 192.168.50.0
O E1 192.168.50.0/24 [110/221] via 10.210.126.72, 00:01:42, GigabitEthernet1
                                    [110/221] via 10.210.126.71, 00:01:42, GigabitEthernet1

So, my question is:

Shouldn't there be two type-5 LSA's (from both cores) showing in the OSPF database for the 7236 subnets, similar to how the 1155 subnets are showing type-5's advertised from each core? If that is not the case, then why is core-2 beating core-1 and advertising the type-5 for the 7236 subnets?

[Peter Paluch · Accepted solution]

Hello,

What you see is expected. Only the ABR with the highest OSPF Router ID performs the LSA Type 7-to-5 translation. This is because Type-7 LSAs have a non-zero forwarding address (FA) set, and so the router performing the translation is not important - the path to the external network does not necessarily traverse through the translator. It is the FA that determines through which ASBR to reach the external network. This also means, however, that if the Type 7 LSAs would be translated by two or more ABRs, then the resulting Type 5 LSAs would be duplicated and would bring no additional information. OSPF RFC 2328 calls such LSAs to be functionally equivalent - sharing the same type, Link State ID (encoding the network address), netmask, metric, metric type, and forwarding address - and requires that only the router with the highest RID advertises them:

https://tools.ietf.org/html/rfc2328#page-142

The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA.

NSSA RFC 3101 retakes this principle, and combines it with another rule: You can have a router forcibly configured to perform the translation (using area ... nssa translate type7 always). If you have such a router, then other routers won't act as translators. If you do not have such a router configured, then the ABR with the highest RID will be the translator (the "Nt" bit below is a bit indicating that the router is unconditionally configured to the role of NSSA translator):

https://tools.ietf.org/html/rfc3101#page-16

An NSSA border router whose NSSA's NSSATranslatorRole is set to Candidate must maintain a list of the NSSA's border routers that are reachable both over the NSSA and as ASBRs over the AS's transit topology. Any change in this list, or to the Nt bit settings of members of this list, causes the NSSA border router to reevaluate its NSSATranslatorState. If there exists another border router in this list whose router-LSA has bit Nt set or who has a higher router ID, then its NSSATranslatorState is disabled. Otherwise its NSSATranslatorState is elected.

I hope this clarifies the behavior - but please feel welcome to ask further!

Best regards,
Peter

[Oh Drother]

This is likely one of the best in depth and precise answers I could have ever hoped for. Thank you so much!

[Peter Paluch]

Hi Kyle,

Thank you very much for your kind words. You are welcome!

Best regards,
Peter