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.
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.
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
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 R2. 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 0OSPF 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 0OSPF 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.
Recent Comments