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.
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.
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/32Topology 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 detailOSPF 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 detailOSPF 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/32inet.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 detailOSPF 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.4inet.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!
Recent Comments