Going through the JNCIS-ENT course, I realized that I had forgotten so much of the details about the different LSA types and all of its intricacies. Next to being able to answer trick exam questions, knowing the LSAs and their working helps a lot when dealing with complex OSPF problems or optimizing your network topologies. As I really needed a refresher for this exam and my upcoming NP refresh I created this simple topology and tried to document as much of my findings as possible.
Lab Topology
We have four routers interconnected via OSPF. The area configuration is as follows.
- vMX1 – RID 1.1.1.1 – connected to area 12
- vMX2 – RID 2.2.2.2 – connected to area 12 and backbone area 0
- vMX3 – RID 3.3.3.3 – connected to backbone area 0 and area 34
- vMX4 – RID 4.4.4.4 – connected to area 34
Below is the standard configuration that is running on router VMX2 – Router ID, area statements and active interfaces. The other routers have similar configuration for their respective interfaces and areas.
[edit]
root@vMX2# show
routing-options {
router-id 2.2.2.2;
}
protocols {
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0 {
passive;
}
}
area 0.0.0.12 {
interface ge-0/0/1.0;
}
}
}
For now, until we move on to the Type 7 LSA, all areas are configured as standard areas. Before we start, here is an output of the LSA database on router VMX2. As it’s connected to two areas, it’s keeping two LSDBs. We’ll be using this router’s database for the first set of LSAs.
root@vMX2> show ospf database
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *2.2.2.2 2.2.2.2 0x80000180 2034 0x22 0x4d8 48
Router 3.3.3.3 3.3.3.3 0x8000017f 2044 0x22 0x1ab6 48
Network 172.16.23.3 3.3.3.3 0x8000017b 1794 0x22 0x7651 32
Summary *1.1.1.1 2.2.2.2 0x80000070 1784 0x22 0x4a76 28
Summary 4.4.4.4 3.3.3.3 0x80000001 53 0x22 0x809f 28
Summary *172.16.12.0 2.2.2.2 0x8000017c 1034 0x22 0x539b 28
Summary 172.16.34.0 3.3.3.3 0x8000017d 1544 0x22 0x4093 28
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 1.1.1.1 1.1.1.1 0x80000073 253 0x22 0xd03 48
Router *2.2.2.2 2.2.2.2 0x80000074 784 0x22 0xe0b 36
Network *172.16.12.2 2.2.2.2 0x80000071 534 0x22 0xda10 32
Summary *2.2.2.2 2.2.2.2 0x80000071 284 0x22 0x10ac 28
Summary *3.3.3.3 2.2.2.2 0x80000071 34 0x22 0xebcb 28
Summary *4.4.4.4 2.2.2.2 0x80000001 52 0x22 0xa87a 28
Summary *172.16.23.0 2.2.2.2 0x80000070 2784 0x22 0xf4fb 28
Summary *172.16.34.0 2.2.2.2 0x80000070 2534 0x22 0x855f 28
LSA Type 1 – Router LSA
The first LSA type is generated by every router participating in OSPF and lists all of the router’s links together with their associated cost, as well the OSPF neigbhours it has inside the area. Every router will flood a Router LSA for each area it is active in.
Looking at our OSPF database from before, router 2.2.2.2 has received a router LSA from router 1.1.1.1 and router 3.3.3.3 (Adv Rtr). Those LSAs are only seen in their respective areas, which demonstrates that a router LSA never leaves an area. We can further drill down to display only routers LSAs with the following command.
root@vMX2> show ospf database router
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *2.2.2.2 2.2.2.2 0x80000181 149 0x22 0x2d9 48
Router 3.3.3.3 3.3.3.3 0x80000180 37 0x22 0x18b7 48
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 1.1.1.1 1.1.1.1 0x80000073 1174 0x22 0xd03 48
Router *2.2.2.2 2.2.2.2 0x80000074 1705 0x22 0xe0b 36
If we want to get more specific and view the contents of the actual LSA, we can do so by specifying the LSA ID and adding the extensive command. Let’s see what router 1.1.1.1 is telling us about itself.
root@vMX2> show ospf database router lsa-id 1.1.1.1 extensive
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 1.1.1.1 1.1.1.1 0x80000073 1274 0x22 0xd03 48
bits 0x0, link count 2
id 172.16.12.2, data 172.16.12.1, Type Transit (2)
Topology count: 0, Default metric: 1
id 1.1.1.1, data 255.255.255.255, Type Stub (3)
Topology count: 0, Default metric: 0
Topology default (ID 0)
Type: Transit, Node ID: 172.16.12.2
Metric: 1, Bidirectional
Aging timer 00:38:45
Installed 00:21:13 ago, expires in 00:38:46, sent 3d 19:45:06 ago
Last changed 00:21:13 ago, Change count: 4
The router is advertising its two links in the LSA (link count 2). The LSA identifier is the originating router’s RID. The first link is an OSPF type Transit where it has a neighbourship with router 172.16.12.2 (data). If we configured the interface-type to p2p, we would see this as the link type. The router also has a Stub link with prefix 1.1.1.1/32, which means that this network contains only one router.
LSA Type 2 – Network LSA
The second LSA type is the Network LSA, which is generated by the Designated Router on a multi-access (broadcast or non-broadcast) segment. It lists all of the routers connected to the segment. It is generated only by the Designated Router to prevent duplicate LSAs.
Our router 2.2.2.2 has received the following network LSAs in area 12:
root@vMX2> show ospf database area 0.0.0.12 network
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Network *172.16.12.2 2.2.2.2 0x8000001b 2085 0x22 0x87b9 32
Drilling down on this particular LSA, it contains the following information:
root@vMX2> ... 0.0.0.12 network lsa-id 172.16.12.2 extensive
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Network *172.16.12.2 2.2.2.2 0x8000001b 2099 0x22 0x87b9 32
mask 255.255.255.0
attached router 2.2.2.2
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: 2.2.2.2
Metric: 0, Bidirectional
Gen timer 00:15:01
Aging timer 00:25:01
Installed 00:34:59 ago, expires in 00:25:01, sent 00:34:57 ago
Last changed 22:03:21 ago, Change count: 1, Ours
From this LSA, we can tell that the network has a /24 mask and that it has router 1.1.1.1 and 2.2.2.2 attached to it. It does not include a cost or metric for the routers, because from the network’s point of view, the cost to the attached routers is zero. If we wanted to know more information about a particular router, we can use the attached router ID which in turn refers to the router LSA we looked at earlier.
LSA Type 3 – Network Summary
This LSA type is generated by Area Border Routers and flooded into a particular area to represent destinations outside of the area. In the opposite direction, the ABR will also advertise prefixes from a non-backbone area back into backbone area 0 with a network LSA. They are flooded into areas where the destination prefix was not found. One thing worth noting is that this only counts for inter-area destinations learned inside the OSPF AS. Routes external to OSPF will use a different LSA type which I’ll cover later.
Again, we will view the contents of router 2.2.2.2’s database for area 12.
root@vMX2> show ospf database area 0.0.0.12 netsummary
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary *2.2.2.2 2.2.2.2 0x800000ae 2289 0x22 0x95e9 28
Summary *3.3.3.3 2.2.2.2 0x800000ae 1689 0x22 0x7109 28
Summary *4.4.4.4 2.2.2.2 0x8000003e 1989 0x22 0x2eb7 28
Summary *172.16.23.0 2.2.2.2 0x800000ae 1389 0x22 0x783a 28
Summary *172.16.34.0 2.2.2.2 0x800000ae 1089 0x22 0x99d 28
Router 2.2.2.2, as the area border router, has generated these LSAs itself (*) and flooded them into area 12. Comparing this to the diagram and the full LSA database, we can tell that it has created network summaries for Router, Network and Summary LSAs inside area 0.
root@vMX2>show ospf database area 12 netsummary lsa-id 172.16.34.0 extensive
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary *172.16.34.0 2.2.2.2 0x800000ae 1527 0x22 0x99d 28
mask 255.255.255.0
Topology default (ID 0) -> Metric: 2
Gen timer 00:24:33
Aging timer 00:34:33
Installed 00:25:27 ago, expires in 00:34:33, sent 00:25:25 ago
Last changed 5d 22:58:56 ago, Change count: 2, Ours
The LSA ID matches the destination network’s prefix. In this case, router R2 knows about the network 172.16.34.0/24 and added a cost of 2 to reach it. Router 1.1.1.1 will add this value to its own cost to ABR 2.2.2.2 to determine the ultimate cost for the route.
LSA Type 4 – ASBR Summary
When a router is advertising routes from sources external to the OSPF AS, it is called an Autonomous System Border Router (ASBR). Like any other router, it will generate a router LSA for itself (Type 1) into its own area but with a special flag E set. When this LSA is received by the other ABR, the router LSA will be converted into a Type 4 LSA when it is flooded into other areas. The LSA is flooded throughout the entire OSPF Autonomous System and lets other routers know how to reach the ASBR.
To demonstrate, I have configured router 4.4.4.4 to redistribute route 10.4.0.0/24 from its loopback interface as an external route. First, define the export policy as a policy-statement.
root@vMX4# show policy-options
policy-statement redist-direct {
term term1 {
from {
protocol direct;
interface lo0.0;
}
then accept;
}
}
Then, configure OSPF to use that statement as its export policy.
root@vMX4# show protocols ospf
export redist-direct;
area 0.0.0.34 {
interface ge-0/0/0.0;
}
We will now see an external route for 10.4.0.0/24, and an ASBR summary for 4.4.4.4 in the database on router 2.2.2.2
root@vMX2> show ospf database area 12
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 1.1.1.1 1.1.1.1 0x800000b6 2563 0x22 0x8646 48
Router *2.2.2.2 2.2.2.2 0x800000b8 559 0x22 0x854f 36
Network *172.16.12.2 2.2.2.2 0x8000001d 259 0x22 0x83bb 32
Summary *2.2.2.2 2.2.2.2 0x800000af 2359 0x22 0x93ea 28
Summary *3.3.3.3 2.2.2.2 0x800000af 1759 0x22 0x6f0a 28
Summary *172.16.23.0 2.2.2.2 0x800000af 1459 0x22 0x763b 28
Summary *172.16.34.0 2.2.2.2 0x800000af 1159 0x22 0x79e 28
ASBRSum *4.4.4.4 2.2.2.2 0x80000001 986 0x22 0x9a87 28
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.4.0.0 4.4.4.4 0x80000001 99 0x22 0xd5be 36
Let’s see what’s inside the ASBR summary…
root@vMX2> ... 12 asbrsummary lsa-id 4.4.4.4 extensive
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
ASBRSum *4.4.4.4 2.2.2.2 0x80000001 177 0x22 0x9a87 28
mask 0.0.0.0
Topology default (ID 0) -> Metric: 2
Gen timer 00:47:03
Aging timer 00:57:03
Installed 00:02:57 ago, expires in 00:57:03, sent 00:02:57 ago
Last changed 00:02:57 ago, Change count: 1, Ours
The LSA ID is the router ID of the ASBR, and router 2.2.2.2 has a cost of 2 to reach it.
For completeness’ sake, the command below shows that the LSA was originally a Type 1 in area 34 before being converted into an ASBR summary by router 3.3.3.3, when flooding it into area 0.
root@vMX3> show ospf database lsa-id 4.4.4.4
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
ASBRSum *4.4.4.4 3.3.3.3 0x80000001 1090 0x22 0x72ac 28
OSPF database, Area 0.0.0.34
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 4.4.4.4 4.4.4.4 0x800000b8 1091 0x22 0x68d 36
LSA Type 5 – AS External LSA
When the ASBR imports routes from outside the Autonomous System, either through static or protocol redistribution, it will flood them into its area as AS External LSAs. This type of LSA is flooded throughout the OSPF topology except for stub areas.
Router 2.2.2.2 has received the external route from ASBR router 4.4.4.4.
root@vMX2> show ospf database area 12 external
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.4.0.0 4.4.4.4 0x80000001 577 0x22 0xd5be 36
The original ASBR’s RID is preserved in the Advertising Router field.
root@vMX2> show ospf database area 12 lsa-id 10.4.0.0 extensive
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.4.0.0 4.4.4.4 0x80000001 675 0x22 0xd5be 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Aging timer 00:48:44
Installed 00:11:13 ago, expires in 00:48:45, sent 00:11:13 ago
Last changed 00:11:13 ago, Change count: 1
Router 2.2.2.2 has now learned about the external route 10.4.0.0/24 and will need to recursively use ASBR 4.4.4.4 to reach it. Because the route was injected with the default Type E2, inter-area OSPF link cost is not taken into consideration, and the associated cost is zero as injected by router 4.4.4.4. Before we wrap up on this LSA type, the external route types might need some clarification.
E1 and E2 type routes
External routes or Type 5 LSAs can be imported as either Type 1 or Type 2 routes. When injecting as E2 routes, the autonomous system’s internal cost metrics are not taken into consideration when the LSA is flooded throughout the topology. This the default behaviour and it’s fine in simple stub topologies, but as OSPF is by design a cost-based protocol, using E1 routes makes more sense. This will make the routers combine the route’s original metric with the cost to reach the ASBR (Type 4 LSA), resulting in the total route cost. Let’s demonstrate…
The external route type is configured in the routing-policy. Here’s an example of my export policy before making any changes.
[edit policy-options policy-statement redist-direct]
root@vMX4# show
term term1 {
from {
protocol direct;
interface lo0.0;
}
then accept;
}
Now, if we want to set the route as an E1, we define this an action in the policy term. I will import the route with a default cost of 5 and set them as type E1.
[edit policy-options policy-statement redist-direct]
root@vMX4# set term term1 then external type 1
[edit policy-options policy-statement redist-direct]
root@vMX4# set term term1 then metric 5
[edit policy-options policy-statement redist-direct]
root@vMX4# show
term term1 {
from {
protocol direct;
interface lo0.0;
}
then {
metric 5;
external {
type 1;
}
accept;
}
}
After a commit, we have the following LSA in our database.
root@vMX2> show ospf database external lsa-id 10.4.0.0 extensive
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.4.0.0 4.4.4.4 0x8000003d 86 0x22 0xcc7 36
mask 255.255.255.0
Topology default (ID 0)
Type: 1, Metric: 5, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Aging timer 00:58:33
Installed 00:01:24 ago, expires in 00:58:34, sent 00:01:24 ago
Last changed 00:01:24 ago, Change count: 4
The same route is now received as E1 (Type: 1). The cost was injected with a cost of 5 but when we validate in the RIB, we see it has a metric of 7 for the route.
root@vMX2> show route 10.4.0.0 | match metric 10.4.0.0/24 *[OSPF/150] 00:02:09, metric 7, tag 0
This confirms that Total Cost = Cost of Route (5) + Cost to ASBR (2)…
LSA Type 7 – NSSA External
When an area is configured as a stub, external routes or Type 5 LSAs will not be allowed in and commonly replaced by one default route. This reduces the LSDB size on the stub routers and keeps the topology simple, but there might be cases where you do need external routes to originate in those stub areas. For these cases, the Not-So-Stubby Area was designed. This allows you to place an ASBR in the stub area and still import external routes, but this time with a special LSA type. When it traverses to the backbone area, the stub-to-backbone ABR will convert the NSSA External LSA into a standard Type-5 External LSA.
To demonstrate, I have converted area 34 to a NSSA on both router 3 and router 4.
root@vMX4# show
export redist-direct;
area 0.0.0.34 {
nssa;
interface ge-0/0/0.0;
}
The Type 5 LSA that was previously flooded by router 4.4.4.4 will now be shown as an NSSA External LSA.
root@vMX4> show ospf database
OSPF database, Area 0.0.0.34
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 3.3.3.3 3.3.3.3 0x80000005 227 0x20 0xcc84 36
Router *4.4.4.4 4.4.4.4 0x80000004 226 0x20 0x8dbc 36
Network *172.16.34.4 4.4.4.4 0x80000002 226 0x20 0x3dee 32
Summary 1.1.1.1 3.3.3.3 0x80000002 227 0x20 0x31fa 28
Summary 2.2.2.2 3.3.3.3 0x80000002 227 0x20 0xf830 28
Summary 3.3.3.3 3.3.3.3 0x80000002 227 0x20 0xc065 28
Summary 172.16.12.0 3.3.3.3 0x80000002 227 0x20 0x5512 28
Summary 172.16.23.0 3.3.3.3 0x80000002 227 0x20 0xd18b 28
NSSA *10.4.0.0 4.4.4.4 0x80000002 226 0x28 0x2cf7 36
On the last line, we have our Type 7 LSA. Inside it we find the following information…
root@vMX4> show ospf database lsa-id 10.4.0.0 extensive
OSPF database, Area 0.0.0.34
Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA *10.4.0.0 4.4.4.4 0x80000002 262 0x28 0x2cf7 36
mask 255.255.255.0
Topology default (ID 0)
Type: 1, Metric: 5, Fwd addr: 172.16.34.4, Tag: 0.0.0.0
Gen timer 00:45:37
Aging timer 00:55:37
Installed 00:04:22 ago, expires in 00:55:38, sent 00:04:22 ago
Last changed 00:04:22 ago, Change count: 2, Ours
The LSA contents are almost identical to the previous one, except that the router’s LAN IP is now in the Fwd address field.
Hopping back to router 2, we see the same prefix has been received as an External, Type 5, LSA.
root@vMX2> show ospf database lsa-id 10.4.0.0 extensive
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.4.0.0 3.3.3.3 0x80000002 715 0x22 0xc06f 36
mask 255.255.255.0
Topology default (ID 0)
Type: 1, Metric: 5, Fwd addr: 172.16.34.4, Tag: 0.0.0.0
Aging timer 00:48:05
Installed 00:11:52 ago, expires in 00:48:05, sent 00:11:50 ago
Last changed 00:12:16 ago, Change count: 1
Interestingly, the advertising router is no longer 4.4.4.4 but 3.3.3.3, as this was the one that generated the Type 5 LSA. Because this router is now also acting as an ASBR, it advertised its own Router LSA with the E bit set which is into an ASBR summary LSA by router 2.2.2.2 when it is sent into area 12.
root@vMX2> show ospf database asbrsummary
OSPF database, Area 0.0.0.12
Type ID Adv Rtr Seq Age Opt Cksum Len
ASBRSum *3.3.3.3 2.2.2.2 0x80000001 1006 0x22 0xbe68 28
From the perspective of the other routers, this device is now the source of the external route and the same logic we saw earlier is applied.
There you go, some of the things I’ve learned labbing LSAs. If you have anything to add, or spotted some inaccuracy, I’m always happy to hear in the comments!