OSPF Database on Junos: NSSA External (Type 7) LSA

In this article, I will take a look into OSPF database on Junos and see what kind of information I can dig out for NSSA External LSAs, which are crucial for the propagation of external (exported) routes in OSPF NSSA areas. In this article, I get to have a little bit fun at Juniper’s expense… or mine?

This article is a part of an article series “OSPF Database on Junos”. Here are the links to other articles. Please note that not all may be available right now.

OSPF Databse on Junos Series

The following diagram shows the network we’re working on. Please note that the original introduction was created using a home-made emulator, while for the remainder of the series, I used Junosphere.

Junos OSPF (Junosphere)

Default Metric for External Routes
Unlike IOS, whish sets the default metric for external routes to a non-zero value, Junos apparently sets the metric to 0. To illustrate the behavior a little bit better, I will modify the INJECT export policy on R4 to set the default metric to 10.

policy-statement INJECT {
    from protocol static;
    then {
        metric 10;
        accept;
    }
}

In order to explore the NSSA behavior, the first thing we’ll do is to change the area 0.0.0.14 to be NSSA. That’s an easy fix.

R1 and R4:

protocols {
    ospf {
        area 0.0.0.14 {
            nssa;
        }
    }
}

Once we’ve done that, let’s examine the contents of the database on R4.

R4:

markom@R4> show ospf database nssa detail

    OSPF database, Area 0.0.0.14
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
NSSA    *10.0.0.0         4.4.4.4          0x80000002    80  0x28 0xd6c1  36
  mask 255.255.255.0
  Topology default (ID 0)
    Type: 1, Metric: 10, Fwd addr: 192.168.0.4, Tag: 0.0.0.0

The information is there and just as we expected it. Please note the forward address, which is set to the lo0.0 address of R4. This will be used as a “shortcut” for calculating the next-hop information. At this point, I’m making a mental note to examine how Junos is handling that, but it’s a subject for some other time. I have discovered something much more entertaining here…

How about R1? What information do we have there?

R1:

markom@R1> show ospf database lsa-id 10.0.0.0 detail

    OSPF database, Area 0.0.0.14
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
NSSA     10.0.0.0         4.4.4.4          0x80000002   160  0x28 0xd6c1  36
  mask 255.255.255.0
  Topology default (ID 0)
    Type: 1, Metric: 10, Fwd addr: 192.168.0.4, Tag: 0.0.0.0
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern  *10.0.0.0         1.1.1.1          0x80000001   151  0x22 0xa904  36
  mask 255.255.255.0
  Topology default (ID 0)
    Type: 1, Metric: 10, Fwd addr: 192.168.0.4, Tag: 0.0.0.0

We can see here that R1 has two entries for 10.0.0.0/24 in its database. One of these entries is Type 7 LSA it received from R4 and the other one is Type 5 it generated to propagate into the backbone area. Forward address is unchanged.

I just have to poke Juniper in the eye, even though that wasn’t my intention when I started writing this… Take a look at this!

R1:

markom@R1> show ospf database asbrsummary

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
ASBRSum *4.4.4.4          1.1.1.1          0x80000001   347  0x22 0xae78  28

R1 will actually generate Type 4 LSA for an ASBR in an NSSA area! This is not in accordance with the RFC and is absolutely unnecessary! For an NSSA area with large number of ASBRs, this could be a potential performance issue (or not). This information will never be used, since all routers in area 0 and beyond will use only Type 5 LSA generated by R1, which we can prove by examining the database on R3.

R3:

markom@R3> show ospf database area 0

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   1.1.1.1          1.1.1.1          0x80000011   453  0x22 0x8f1d  48
Router  *3.3.3.3          3.3.3.3          0x8000000f   452  0x22 0x3d5f  48
Network *192.168.13.3     3.3.3.3          0x80000001   452  0x22 0x7e26  32
Summary *192.168.0.2      3.3.3.3          0x80000007   456  0x22 0x6757  28
Summary  192.168.0.4      1.1.1.1          0x80000001   458  0x22 0x9b2f  28
Summary  192.168.14.0     1.1.1.1          0x8000000a    42  0x22 0x17a0  28
Summary *192.168.23.0     3.3.3.3          0x80000009    62  0x22 0x792e  28
ASBRSum  4.4.4.4          1.1.1.1          0x80000001   458  0x22 0xae78  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern   10.0.0.0         1.1.1.1          0x80000001   458  0x22 0xa904  36

You see how there is only one external LSA, generated by R1, but we still have that utterly useless Type 4 for R4 there? Type 4 is, of course, required by R2 to reach this Type 5 LSA, but that Type 4 would have been generated for R1, by R3. I’m now thinking that someone at Juniper didn’t quite understand how this process works and customers didn’t really care about it. It’s not a major issue, just a bit wasteful behavior.

R1:

markom@R2> show ospf database

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *2.2.2.2          2.2.2.2          0x8000000c   529  0x22 0x3f3e  60
Router   3.3.3.3          3.3.3.3          0x8000000b   531  0x22 0x9f54  48
Summary  192.168.0.1      3.3.3.3          0x80000008   524  0x22 0x6f4f  28
Summary  192.168.0.3      3.3.3.3          0x80000007   537  0x22 0x536b  28
Summary  192.168.0.4      3.3.3.3          0x80000009   524  0x22 0x5960  28
Summary  192.168.13.0     3.3.3.3          0x80000008   537  0x22 0xe9c8  28
Summary  192.168.14.0     3.3.3.3          0x80000008   524  0x22 0xe8c7  28
ASBRSum  1.1.1.1          3.3.3.3          0x80000004   524  0x22 0xf631  28
ASBRSum  4.4.4.4          3.3.3.3          0x80000009   524  0x22 0x6ca9  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern   10.0.0.0         1.1.1.1          0x80000001   532  0x22 0xa904  36

Surprise, surprise, look at that entry for R4 here, too! I digress though.

We can see here that Type 7 LSA behaves very similarly to the Type 7 in IOS, however the translation process from Type 7 to Type is somewhat less optimized in Junos because of those extra ASBR Summary LSAs.

Writing these series of articles was a great learning experience for me. I love discovering and learning new things. I also discovered few things I would like to further research and, of course, document here. Both of my dear readers are by now probably guessing that I’m preparing for something… experty in the future. I am, but I don’t know when.

She’s at home and this is my last day in RTP. I’m flying back home tomorrow and I can’t wait to be with her again. I really miss her.

  1. Hi,
    I could not reproduce the issue. I tested with Junos 12.3R2.5. Maybe Juniper fixed this behavior?

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>