OSPF Database on Junos: Network Summary (Type 3) 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 Network Summary LSAs, which are crucial for inter-area (multiple 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)

Let’s start by looking into the OSPF database on one of our ABRs, R3. I’m interested to see only Network Summary LSA information in all areas on it. I will first see the overview and then look for more details.

R3:

markom@R3> show ospf database netsummary

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *192.168.0.2      3.3.3.3          0x80000004   419  0x22 0x6d54  28
Summary  192.168.0.4      1.1.1.1          0x80000004  1452  0x22 0x9532  28
Summary  192.168.14.0     1.1.1.1          0x80000006   600  0x22 0x1f9c  28
Summary *192.168.23.0     3.3.3.3          0x80000005  1919  0x22 0x812a  28

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *192.168.0.1      3.3.3.3          0x80000004   919  0x22 0x774b  28
Summary *192.168.0.3      3.3.3.3          0x80000004  2419  0x22 0x5968  28
Summary *192.168.0.4      3.3.3.3          0x80000004   169  0x22 0x635b  28
Summary *192.168.13.0     3.3.3.3          0x80000005  2169  0x22 0xefc5  28
Summary *192.168.14.0     3.3.3.3          0x80000004   669  0x22 0xf0c3  28

As it’s always the case with Junos, we are helpfully reminded about locally generated information in a form of asterisk (*). Now, let’s take a look at the database in area 23 and see what kind of information is there, again, from R3’s perspective. To cut on the output lengths, I will skip the information about the timers by using “detail” instead of “extensive” keywords.

markom@R3> show ospf database netsummary area 23 detail

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *192.168.0.1      3.3.3.3          0x80000004  1023  0x22 0x774b  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 1
Summary *192.168.0.3      3.3.3.3          0x80000004  2523  0x22 0x5968  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 0
Summary *192.168.0.4      3.3.3.3          0x80000004   273  0x22 0x635b  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 2
Summary *192.168.13.0     3.3.3.3          0x80000005  2273  0x22 0xefc5  28
  mask 255.255.255.0
  Topology default (ID 0) -> Metric: 1
Summary *192.168.14.0     3.3.3.3          0x80000004   773  0x22 0xf0c3  28
  mask 255.255.255.0
  Topology default (ID 0) -> Metric: 2

Since R3 is the only ABR in area 23, it’s expected that every single one of these LSAs is generated by R3 itself. This information shows us how the routes from the backbone area are summarized and injected into area 23. Let’s try to see the lifetime of a single route, 192.168.0.4/32 from its entrance into area 0 all the way to R2, a stub router in area 23. We’ll start from R1.

R1:

markom@R1> show ospf route 192.168.0.4/32
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop      
                   Type  Type       Type            Interface     Address/LSP
192.168.0.4/32     Intra Network    IP            1 ge-0/0/1.0    192.168.14.4

markom@R1> show ospf database netsummary area 0 lsa-id 192.168.0.4 detail

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *192.168.0.4      1.1.1.1          0x80000004  1805  0x22 0x9532  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 1

I highlighted in blue the metric information in the routing table and in greenthe information in the generated LSA. We can see that R1’s generated LSA carries the same metric as is visible in its routing table. How about the LSA generated for area 23 on R3? Just as an illustration of different ways to obtain the same information, I will use slightly different show commands on R3.

R3:

markom@R3> show ospf database netsummary lsa-id 192.168.0.4 detail

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary  192.168.0.4      1.1.1.1          0x80000004  2530  0x22 0x9532  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 1

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *192.168.0.4      3.3.3.3          0x80000004  1247  0x22 0x635b  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 2

markom@R3> show route terse 192.168.0.4/32

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 192.168.0.4/32     O  10          2            >192.168.13.1

In the above output, highlighted blue is the information advertised by R1. We can see it’s identical to the data we’ve seen on R1 itself. The red output is the information generated by R3 from its own routing table, which is the information highlighted in green.

Finally, the information on R2.

R2:

markom@R2> show ospf database lsa-id 192.168.0.4 detail

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary  192.168.0.4      3.3.3.3          0x80000004  1634  0x22 0x635b  28
  mask 255.255.255.255
  Topology default (ID 0) -> Metric: 2

markom@R2> show route 192.168.0.4

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.4/32     *[OSPF/10] 02:45:33, metric 3
                    > to 192.168.23.3 via ge-0/0/1.0

We can see that the green highlight matches the LSA generated by R3 and the information in the routing table uses a simple distance-vector logic of adding the cost to the ABR.

She’s still all alone while I’m all alone in RTP. One more week and I’ll be back home. I love teaching, but home is home!

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>