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.
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.
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.
Hi,
I could not reproduce the issue. I tested with Junos 12.3R2.5. Maybe Juniper fixed this behavior?