OSPFv2 - ASBR originates a Type 5 LSA, when it is only configured in an NSSA

[jhiggins-NZ]

Issue:

• ASBR is originating a Type 5 LSA, even through its only configured to reside in a NSSA.
• The Type 5 LSA is not being originated into the NSSA (area 4) however.
• Expected behaviour is the Type 5 is only generated if the node is acting as an ASBR for a non-NSSA area - which permits External LSAs.

. .

Setup:

• Ubuntu 16.04
• Kernel 4.11
• 3.0 branch

. .

Topology:

Area 0 ------ R2 ------ Area 4 (NSSA) ------ R3 ----- RIP

. .

Example:

vLSR-R3# show ip ospf database self-originate

       OSPF Router with ID (3.3.3.3)

                Router Link States (Area 0.0.0.4 [NSSA])

Link ID         ADV Router      Age  Seq#       CkSum  Link count
3.3.3.3         3.3.3.3          598 0x80000031 0xd51d 1

                Net Link States (Area 0.0.0.4 [NSSA])

Link ID         ADV Router      Age  Seq#       CkSum
192.168.23.3    3.3.3.3          538 0x80000010 0xbbe5

                NSSA-external Link States (Area 0.0.0.4 [NSSA])

Link ID         ADV Router      Age  Seq#       CkSum  Route
13.13.13.13     3.3.3.3         1458 0x80000005 0xe20a E2 13.13.13.13/32 [0x0]

                AS External Link States

Link ID         ADV Router      Age  Seq#       CkSum  Route
13.13.13.13     3.3.3.3         1458 0x80000005 0xf089 E2 13.13.13.13/32 [0x0]         <<<<<< HERE

vLSR-R3# sh run
Building configuration...

Current configuration:
!
<cut for brevity>
!
interface eth0
 ip address 192.168.23.3/24
 ip ospf area 0.0.0.4
!
interface eth1
 ip address 192.168.133.3/24
!
router rip
 version 2
 redistribute ospf
 network 192.168.133.0/24
!
router ospf
 ospf router-id 3.3.3.3
 redistribute rip
 area 4 nssa translate-candidate
!

vLSR-R3# show ip ospf
 OSPF Routing Process, Router ID: 3.3.3.3
 Supports only single TOS (TOS0) routes
 This implementation conforms to RFC2328
 RFC1583Compatibility flag is disabled
 OpaqueCapability flag is disabled
 Initial SPF scheduling delay 0 millisec(s)
 Minimum hold time between consecutive SPFs 50 millisec(s)
 Maximum hold time between consecutive SPFs 5000 millisec(s)
 Hold time multiplier is currently 1
 SPF algorithm last executed 2h46m00s ago
 Last SPF duration 70 usecs
 SPF timer is inactive
 LSA minimum interval 5000 msecs
 LSA minimum arrival 1000 msecs
 Write Multiplier set to 20
 Refresh timer 10 secs
 This router is an ASBR (injecting external routing information)
 Number of external LSA 1. Checksum Sum 0x0000ee8a          
 Number of opaque AS LSA 0. Checksum Sum 0x00000000
 Number of areas attached to this router: 1
 Area ID: 0.0.0.4 (NSSA)
   Shortcutting mode: Default, S-bit consensus: no
   Number of interfaces in this area: Total: 1, Active: 1
   It is an NSSA configuration.
   Elected NSSA/ABR performs type-7/type-5 LSA translation.
   It is not ABR, therefore not Translator.
   Number of fully adjacent neighbors in this area: 1
   Area has no authentication
   Number of full virtual adjacencies going through this area: 0
   SPF algorithm executed 33 times
   Number of LSA 19
   Number of router LSA 2. Checksum Sum 0x0000db09
   Number of network LSA 1. Checksum Sum 0x0000bbe5
   Number of summary LSA 15. Checksum Sum 0x0007899a
   Number of ASBR summary LSA 0. Checksum Sum 0x00000000
   Number of NSSA LSA 1. Checksum Sum 0x0000e00b
   Number of opaque link LSA 0. Checksum Sum 0x00000000
   Number of opaque area LSA 0. Checksum Sum 0x00000000

[bisdhdh]

@donaldsharp I am looking into this issue!

[bisdhdh]

@donaldsharp NSSA feature seems to be broken in various ways. The main reason behind is the design of NSSA. More details on this would be shared below.

[rohitgeek]

Hi @donaldsharp ,

As @bisdhdh mentioned, here I am sharing some of the test cases where NSSA doesn't yield the expected results:

Topology:

1- As per standard NSSA ASBR should not generate a type-5 LSA. NSSA is designed to prevent LSA-5 in that area. However this seems to be broken in FRR. Please refer below screen shot:

2- NSSA doesn't stop LSA TYPE-7 translation, even if it is configured to do so. In this case, we used "area 1 nssa translate-never” command to stop translation:

However below OSPF update was received on neighbor router, which seems to be an unexpected behavior.

3- FRR doesn't generate a N2/N1 type route, instead it generates E1/E2 routes even for an NSSA area:

4- NSSA Translator election in FRR happens based on the router-id (highest router-id wins). However if there are 2 ABR connecting to NSSA and primary translator goes down, then other ABR doesn't take over, instead all Type-5 LSAs in remote area are disappeared:

When primary ABR (R3 in topology) goes down, we do not see LSA-5 in area 2 anymore. Which signifies that R2 doesn't take over as ABR:

Please let me know if you need any further information from my end.

Regards, Rohit Sharma

[craterman]

Is it fixed in FRR 7.4 or 7.5? This is still present in 7.3.1