Strange NSSA and NSTSA default route installation behavior

[luca-loner]

Hi everyone,

I’ve been testing various configuration scenarios for NSSA and NSTSA areas in OSPF. However, I’ve encountered a strange behavior that I still can’t figure out, despite spending a lot of time trying to understand it. Here’s the topology:

R8 is an ASBR and performs EIGRP routes and default-route redistribution in area 1, which is an NSSA. Since I wanted to verify the OSPF path selection rules, I’m redistributing it as an N1 route.

R8#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "eigrp 1", distance 90, metric 3072, candidate default path, type internal
  Redistributing via ospf 1, eigrp 1
  Last update from 10.10.108.10 on GigabitEthernet0/1, 03:15:29 ago
  Routing Descriptor Blocks:
  * 10.10.108.10, from 10.10.108.10, 03:15:29 ago, via GigabitEthernet0/1
      Route metric is 3072, traffic share count is 1
      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R8#

router ospf 1
 area 1 nssa default-information-originate metric-type 1
 redistribute eigrp 1 subnets

 Looking at the OSPF database, you can see that the default route is being distributed through a Type 7 LSA.

R8#show ip ospf database nssa 0.0.0.0

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

                Type-7 AS External Link States (Area 1)

  LS age: 1723
  Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 10.12.8.8
  LS Seq Number: 80000006
  Checksum: 0xBB1D
  Length: 36
  Network Mask: /0
        Metric Type: 1 (Comparable directly to link state metric)
        MTID: 0 
        Metric: 1 
        Forward Address: 10.12.8.8
        External Route Tag: 0

R8#

 R12 also performs redistribution in area 0, but the default route is distributed as E2:

router ospf 1
 default-information originate

R12#show ip ospf database external 0.0.0.0 adv-router 10.12.12.12

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

                Type-5 AS External Link States

  LS age: 1656
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 10.12.12.12
  LS Seq Number: 80000002
  Checksum: 0xE1A1
  Length: 36
  Network Mask: /0
        Metric Type: 2 (Larger than any link state path)
        MTID: 0 
        Metric: 1 
        Forward Address: 0.0.0.0
        External Route Tag: 1

R12#

R5 and R8 agree on the area type, which is configured as NSSA between them. R2 has been configured to set Area 1 as Not-so-totally-stubby with the command "area 1 nssa no-summary".

Therefore, R5 receives an LSA Type 5 for the default route of type E2 that is distributed by R12 in Area 0, while in Area 1, it receives an LSA Type 7 for the default route of type N1 distributed by R8. Consequently, according to the logic described in RFC 3101, R5 uses R8 as the next hop for the default route:

R5#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 1", distance 110, metric 3, candidate default path, type NSSA extern 1
  Last update from 10.10.58.8 on GigabitEthernet0/2, 00:05:07 ago
  Routing Descriptor Blocks:
  * 10.10.58.8, from 10.12.8.8, 00:05:07 ago, via GigabitEthernet0/2
      Route metric is 3, traffic share count is 1
R5#

Everything seems to be correct so far, except for the behavior of R2. The issue is that if I set area 1 as NSTSA, R2 selects R12 as the next hop. If I configure it as NSSA, R2 selects R8 as the next hop:

R2(config)#router ospf 1
R2(config-router)#area 1 nssa no-summary 
R2(config-router)#do show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 1", distance 110, metric 1, candidate default path
  Tag 1, type extern 2, forward metric 3
  Last update from 10.10.12.1 on GigabitEthernet0/1, 00:11:44 ago
  Routing Descriptor Blocks:
  * 10.10.12.1, from 10.12.12.12, 00:11:44 ago, via GigabitEthernet0/1
      Route metric is 1, traffic share count is 1
      Route tag 1
R2(config-router)#

R2(config-router)#no area 1 nssa no-summary 
R2(config-router)#area 1 nssa
R2(config-router)#do show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 1", distance 110, metric 3, candidate default path, type NSSA extern 1
  Last update from 10.10.28.8 on GigabitEthernet0/0, 00:00:08 ago
  Routing Descriptor Blocks:
  * 10.10.28.8, from 10.12.8.8, 00:00:08 ago, via GigabitEthernet0/0
      Route metric is 3, traffic share count is 1
R2(config-router)#

When I try to "debug ip ospf 1 rib" and switch from NSSA to NSTA, I observe:

OSPF-1 LRIB : Updating route 0.0.0.0/0 
OSPF-1 LRIB :  Add path area dummy area, type Ext2, dist 1,  forward 3, tag 0x1, via 10.10.12.1 GigabitEthernet0/1, route flags (None), path flags (none), source 10.12.12.12, spf 15, list-type change_list 
OSPF-1 LRIB : Updating route 10.10.108.0/24 
OSPF-1 LRIB :  Add path area 1, type NSSA2, dist 20,  forward 2, tag 0x0, via 10.10.28.8 GigabitEthernet0/0, route flags (ViaFwAddr, IntraNonBB, NSSA P-bit), path flags (none), source 10.12.8.8, spf 15, list-type change_list 
OSPF-1 GRIB :   IP route replace of 1 next hops succeeded for 0.0.0.0/0 (flags 0x0, type Ext2, tag 0x1), retcode 0 
OSPF-1 GRIB :   Next hop via 10.10.12.1 on GigabitEthernet0/1 (distance 1, source 10.12.12.12, label 1048578) installed 
OSPF-1 LRIB : Sync'ed 0.0.0.0/0 type Ext2 - change (Change, PathChange, NssaReplace): added 1 paths, deleted 0 paths, spf 15, route instance 15 
OSPF-1 REDIS: Translate 0.0.0.0/0 into Type-7 LSA, metric 16777215, metric-type 0, forw addr 0.0.0.0, tag 0x0 

When I switch it back to NSSA:

OSPF-1 LRIB : Updating route 0.0.0.0/0 
OSPF-1 LRIB :  Add path area 1, type NSSA1, dist 3,  forward 2, tag 0x0, via 10.10.28.8 GigabitEthernet0/0, route flags (ViaFwAddr, IntraNonBB, NSSA P-bit), path flags (none), source 10.12.8.8, spf 18, list-type change_list 
OSPF-1 LRIB : Updating route 10.10.108.0/24 
OSPF-1 LRIB :  Add path area 1, type NSSA2, dist 20,  forward 2, tag 0x0, via 10.10.28.8 GigabitEthernet0/0, route flags (ViaFwAddr, IntraNonBB, NSSA P-bit), path flags (none), source 10.12.8.8, spf 18, list-type change_list 
OSPF-1 GRIB :   IP route replace of 1 next hops succeeded for 10.10.108.0/24 (flags 0x0, type NSSA2, tag 0x0), retcode 0 
OSPF-1 GRIB :   Next hop via 10.10.28.8 on GigabitEthernet0/0 (distance 20, source 10.12.8.8, label 1048578) installed 
OSPF-1 GRIB :   IP route replace of 1 next hops succeeded for 0.0.0.0/0 (flags 0x0, type NSSA1, tag 0x0), retcode 0 

I thought that NSSA and NSTA were compatible, just like Stub and Totally Stub areas (for example, for traffic engineering). After all, the difference lies only in the filtering of LSA Type 3. Can anyone explain why this happens?

Thank you all.

[MHM Cisco World]

Can you more elaborate 

Thanks 

MHM

[luca-loner]

In detail, what is unclear to you that I can explain better?

Thanks

[MHM Cisco World]

""R5 and R8 agree on the area type, which is configured as NSSA between them. R2 has been configured to set Area 1 as Not-so-totally-stubby with the command "area 1 nssa no-summary".""

This confuse me' how same area different types ?

That  not correct.

MHM

[Joseph W. Doherty]

What's the actual equipment environment you're doing this on?  (I.e. devices, and OSs?)

Have NOT really analyzed your description, but whenever "strange" interarea OSPF routing arises, what comes to my mind is RFC 1583 superseded by RFC 2328 but some Cisco equipment using different defaults (IOS vs. NXOS) and/or different configuration options.  I.e.  again, this may have absolutely nothing to do with what you describe.

[luca-loner]

I use EVE-NG environment, so I don't have specific hardware. The version of Cisco IOSv I'm using is IOSv 15.6(1)T. Thank you for pointing out that RFC. I'll check it out to see if I find the explanation.

[Giuseppe Larosa · Accepted solution]

Hello @luca-loner ,

both R2 and R5 have ABR role between area 0 and area 1  ABR(0,1) we can indicate in this way.

R12 is an ASBR in area 0 so we can indicate it as ASBR(0)

R8 is ASBR in area 1 that is NSSA. So R8 is ASBR(1-NSSA)

so R8 generates an OSPF  type 7  O N1 via default-information originate metric-type 1.

But R2 and R5 are both ABR nodes between area 0 and area 1.

From OSPF design point of view or both of them are configured for totally NSSA with

area 1 nssa no-summary

or both should be configured with

area 1 nssa

note : to revert from area 1 nssa no-summary you issue

no area 1 nssa no-summary

you should see area 1 nssa at that point.

So my guess is that R2 when configured with area 1 nssa no-summary is not going to accept the LSA type 7 from R8 in area 1, because it has to ignore R8 as ASBR border router.

In the LSA type 7 we see that forwarding address is set:

>>

Forward Address: 10.12.8.8

 originated by R8

This is another key difference with the LSA type 5 originated by R12 where Forwarding Address is set to 0.0.0.0.

Edit:

R2 when configured with area 1 nssa no-summary is expected to generate a default route 0.0.0/0 to push into Area 1 because the no-summary option filters all LSa type 3 and type 4 coming from area 0.

See RFC3101 section 2.5

>>

Else if the destination is a Type-7 default route (destination
          ID = DefaultDestination) and one of the following is true,
          then do nothing with this LSA and consider the next in the
          list:





Murphy                      Standards Track                    [Page 11]

---

RFC 3101       The OSPF Not-So-Stubby Area (NSSA) Option    January 2003


            o  The calculating router is a border router and the LSA has
               its P-bit clear.  Appendix E describes a technique
               whereby an NSSA border router installs a Type-7 default
               LSA without propagating it.

            o  The calculating router is a border router and is
               suppressing the import of summary routes as Type-3
               summary-LSAs.

this is why R2 is ignoring R8's O N1 0.0.0.0/0 because of the no-summary option added. What you see is expected as it is explained in the RFC 3101.

Hope to help

Giuseppe

[luca-loner]

Oh, thank you Giuseppe!

I had completely overlooked this section of the RFC. Now everything is clear to me, and thinking about it, I also understand the reason why this happens.

I'll use the following topology as an example, now modified:

R2 considers area 1 as a NSTSA, while the other routers in area 1 see it as a normal NSSA. So, R2 generates a default route into area 1 for inter-area destinations, which is of type "O IA", and therefore preferred over an "O N1". So R13 would replace its current O N1 default route with that O IA, but if R2 didn't remove the N1 type default route that has R13 as the next hop (to reach R8), a loop would be created.

Once again, thank you very much, Giuseppe!

Luca

[Giuseppe Larosa]

Hello @luca-loner ,

I think R2 if configured with area 1 nssa no-summary prepares itself to inject a default route O IA 0.0.0.0/0 as an LSA type 3, however the generation of this default route is not automatic ( it is automatic toward Stub areas or Totally Stub Areas but with NSSA it is left to the network engineer to decide if sending a default route into the NSSA area or not).

In any case R2 is not going to accept anymore the O N1 0.0.0.0/0 LSA type 7 originated by R8 as it is explained in the RFC 3101 section 2.5.

I would configure R2 and R5 in the same way it is a more clean design.

Hope to help

Giuseppe