OSPF Database on Junos: Router (Type 1) and Network (Type 2) 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 Router and Network LSAs, which are crucial for intra-area (single area) OSPF operations.

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)

We’ll start by looking into the database on R1. We’re interested only in Router LSAs. Let’s take a look at them.

R1:

markom@R1> show ospf database router

    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          0x80000006  2608  0x22 0x9f1a  48
Router   3.3.3.3          3.3.3.3          0x80000006  2364  0x22 0x4f56  48

    OSPF database, Area 0.0.0.14
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *1.1.1.1          1.1.1.1          0x80000004   155  0x22 0x3bdb  48
Router   4.4.4.4          4.4.4.4          0x80000005   722  0x22 0xa3e4  60

We can see a summarized information about the LSA type we needed in all areas available on this device. Self-generated LSAs are marked with an asterisk. This information, by itself, doesn’t tell us much. Junos gives us plenty of options to drill-down.

R1:

markom@R1> show ospf database router ?
Possible completions:
  <[Enter]>            Execute this command
  advertising-router   Router ID of advertising router
  area                 OSPF area ID
  brief                Display brief output (default)
  detail               Display detailed output
  extensive            Display extensive output
  instance             Name of OSPF instance
  lsa-id               Link-state advertisement ID
  summary              Display summary output
  |                    Pipe through a command

Plenty of options there, but let’s put them in context. I would like to examine all Router LSAs originated by R1’s neighbor R4, in area 0.0.0.14 and I would like to see as much detail about them as possible. To do that, I will combine “advertising-router”, “area” and “extensive” keywords to the above command. Let’s see what we get as the output and how we can read it.

R1:

markom@R1> show ospf database router advertising-router 4.4.4.4 area 14 extensive

    OSPF database, Area 0.0.0.14
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   4.4.4.4          4.4.4.4          0x80000005  1354  0x22 0xa3e4  60
  bits 0x2, link count 3
  id 1.1.1.1, data 192.168.14.4, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 192.168.14.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 1
  id 192.168.0.4, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: PointToPoint, Node ID: 1.1.1.1
      Metric: 1, Bidirectional
  Aging timer 00:37:25
  Installed 00:22:31 ago, expires in 00:37:26
  Last changed 01:12:33 ago, Change count: 4

Minor Observation
After first seeing this output and after being used to the output of Cisco IOS, I found myself both delighted and disappointed. I was delighted because Junos shows information in a more concise and easy to read output. I was Disappointed because some of the information doesn’t seem to be “translated”. For example if the router is ASBR or an ABR, no Junos command would show us that in a human-readable form. IOS would.

First part of the output shows us the same summarized information we saw before, only limited to the advertising router and area we specified. Following that is the extensive information about the actual contents of this LSA.

First line of this output shows us the information about the router itself in a form that is not readily human-readable. Bits section refers to V, E and B bits in the LSA header, which have the following meaning.

Name Position Value Description
V 100 4 Router has at least one virtual link with an adjacent neighbor on it.
E 010 2 Router is an ASBR.
B 001 1 Router is an ABR.

Any combination of these bits is possible, but some combinations will never happen, unless the OSPF implementation is seriously broken. In our case, this bit-field has the value of 2, which means the E-bit is set, indicating that R4 is the ASBR. We can also see that R4 is advertising three links in area 0.0.0.14. At first glance, this may not make any sense, since the router has only two links in this area plus the external prefix, but let’s analyze the contents a bit more.

Those lines I highlighted red refer to the point-to-point link between R1 and R4. The first part describes the link itself and the latter part describes the relationship between the two.

Lines highlighted green also refer to the same link. This is expected for all the point-to-point links, since the point-to-point link is always advertised as a stub link, as well as the relationship between the two routers.

Lines highlighted blue part describes the Loopback interface.

At the end, we can see OSPF timers, which control re-flooding of the information in the area. These can be very useful when troubleshooting instabilities in your network.

Let’s now turn to the link between R1 and R3. This link has not been defined as point-to-point, which makes it a broadcast by default. Let’s see how that link is described by R1 and R2. I will look for this information on R1.

R1:

markom@R1> show ospf database router advertising-router 1.1.1.1 extensive 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          0x80000009   326  0x22 0x991d  48
  bits 0x1, link count 2
  id 192.168.13.3, data 192.168.13.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 192.168.0.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 192.168.13.3
      Metric: 1, Bidirectional
  Gen timer 00:20:15
  Aging timer 00:54:33
  Installed 00:05:26 ago, expires in 00:54:34, sent 00:05:26 ago
  Last changed 00:05:26 ago, Change count: 5, Ours

markom@R1> show ospf database router advertising-router 3.3.3.3 extensive area 0

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   3.3.3.3          3.3.3.3          0x80000007  2672  0x22 0x4d57  48
  bits 0x1, link count 2
  id 192.168.13.3, data 192.168.13.3, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 192.168.0.3, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 192.168.13.3
      Metric: 1, Bidirectional
  Aging timer 00:15:28
  Installed 00:44:29 ago, expires in 00:15:28
  Last changed 01:58:05 ago, Change count: 2

Just as before, I used the color coding to describe various parts. Those lines highlighted red describe the link from R1’s perspective. We can see (underlined) a reference to R3’s IP address on the shared segment. This is an indicator that R3 is in fact a designated router. Let’s check that.

markom@R1> show ospf neighbor 3.3.3.3 detail
Address          Interface              State     ID               Pri  Dead
192.168.13.3     ge-0/0/2.0             Full      3.3.3.3          128    34
  Area 0.0.0.0, opt 0x42, DR 192.168.13.3, BDR 192.168.13.1
  Up 02:10:58, adjacent 02:10:16

This information works together with the blue lines, which indicate that a network (Type 2) LSA with the ID of 192.168.13.3 should be used. This information is identical on both our routers.

Green lines are R3’s point of view. We can see that the information is very similar to the one on R1, with only the local IP address being different.

Let’s take a look at that Network LSA, generated by R3. Just as before, I’ll use R1 to dig this information out.

R1:

markom@R1> show ospf database network extensive

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Network  192.168.13.3     3.3.3.3          0x80000005   637  0x22 0x762a  32
  mask 255.255.255.0
  attached router 3.3.3.3
  attached router 1.1.1.1
  Topology default (ID 0)
    Type: Transit, Node ID: 1.1.1.1
      Metric: 0, Bidirectional
    Type: Transit, Node ID: 3.3.3.3
      Metric: 0, Bidirectional
  Aging timer 00:49:23
  Installed 00:10:34 ago, expires in 00:49:23
  Last changed 02:14:09 ago, Change count: 1

Information contained in this LSA completes the transit links defined in Router LSAs on R1 and R3.

Next time, I will take a closer look at inter-area network summaries.

She’s back in Mountain View, while I’m spending the time in Research Triangle Park on a two-week bootcamp. I miss her a lot.

  1. Milan Miljkovic

    Great blog Marko! Hate to be nitpicking, but there is a typo in section comparing 2 Area 0 routers: “Let’s now turn to the link between R1 and R2”. Someone might get confused :smile:

    There is also: “Those lines highlighted red describe the link from R1’s perspective. We can see (underlined) a reference to R3’s IP address on the shared segment. ” What’s underlined in red is the R1’s loopback address, not R3’s.

    Cheers,
    Milan

  2. why cant i see your blogposts when i click on read more link :(

    • Now that’s a very good question. It looks like few posts didn’t survive my latest server change acrobatics. Let me work on that, it should be coming up soon(~ish).

      Thanks for letting me know.

    • Yeah, it looks like something broke in my WordPress setup after I changed the operating system under its feet. It will take some maneuvering to fix this. Again – thanks for bringing it to my attention.

  3. show ospf overview shows brief info about abr/asbr/nssa router:

    # run show ospf overview
    Instance: master
      Router ID: 172.16.0.34
      Route table index: 0
      Area border router, AS boundary router, NSSA router
      LSA refresh time: 50 minutes
      DoNotAge uncapable
        Area scope LSAs received with no DC bit: 1
      Area: 0.0.0.0
        Stub type: Not Stub
        Authentication Type: None
        Area border routers: 0, AS boundary routers: 1
        Neighbors
          Up (in full state): 2
        DoNotAge uncapable
          Area scope LSAs received with no DC bit: 1
      Area: 0.0.0.1
        Stub type: Stub NSSA, Stub cost: 12
        Authentication Type: None
        Area border routers: 0, AS boundary routers: 1
        Neighbors
          Up (in full state): 1
      Topology: default (ID 0)
        Prefix export count: 1
        Full SPF runs: 225
        SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
        Backup SPF: Not Needed

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>