OSPF is probably the most common IGP in both the enterprise and service provider networks. It’s a pretty manageable protocol and easy to understand, although sometimes we may get confused with the different announcement types and the situations where they apply. So let’s see if we can put some light in all this.
This is the scenario we’ll use for our tests:
Every OSPF device in the network announces the state of each of its own links. And these announcements reach every OSPF device in the same area. Every time an OSPF router gets an advertisement from another OSPF router, it floods this advertisement to its neighbors (this is a little bit different in multi-access networks). So at the end, every OSPF device in the area has the same topology information.
This info is kept in the OSPF database. That’s why when a new neighbor is discovered, after checking some parameters, the process of exchanging database starts and it’s completely necessary that all the OSPF devices in the same area have the same information.
The first thing that could lead us to confusion about the OSPF database is that in it, we won’t find prefixes but LSAs. Then, each LSA encapsulates one ore more prefixes from neighbor advertisements. So, when you run the command “show ip ospf database“, don’t expect to find at first all the prefixes that the router can reach.
Let’s start with the different OSPF LSA types, we can find:
- LSA type 1: called Router Links LSA
- LSA type 2: called Network Links LSA
- LSA type 3: called Network Summary LSA
- LSA type 4: called ASBR LSA
- LSA type 5: called External LSA
- LSA type 7: called NSSA External LSA
There are some other LSA types, but they come into play when traffic-engineering and other advanced features are present in the network.
For this post, we will focus on LSA types 1 and 2. We will discuss types 3, 4, 5 and 7 in future posts.
LSA Type-1
This is the basic LSA, every device participating in OSPF sends these and in it announces the state of each of its OSPF links. When the command show ip ospf database is used, every line under the statement Router Link States is an LSA type 1 belonging to a different router.
Every LSA is identified by the router-id of the router which the LSA belongs to.
R3#show ip ospf database
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1341 0x80000005 0x0049DB 5
2.2.2.2 2.2.2.2 1355 0x80000005 0x006D6C 5
3.3.3.3 3.3.3.3 1340 0x80000005 0x005BBD 4
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.10.23.2 2.2.2.2 1443 0x80000001 0x00F8F2
From the output, we can see that there are 3 devices running OSPF in Area 0, and no more routers, because we got 3 different LSAs type 1. Each router generates one LSA type 1.
We see also information about the age of the LSA, sequence number and checksum. We see also the number of links each LSA carries, from the sixth column.
Then, so far we know there are 3 routers with router-ids 1.1.1.1, 2.2.2.2 and 3.3.3.3. The first one announces 5 links, the second one 5 links too, and the third one 4 links.
If we check these LSAs type 1, we will get more info about each router. And something very important to keep in mind is that every router in the same area has the same database. So we could get to know all the OSPF info of a router without having to connect to that remote router. Just dropping the command
show ip ospf database router from any other router in the area (check this
post where Daniel decodes what network type a Core OSPF Router is using without doing any show run command in that router).
Let’s check on R3 how R2’s LSA looks like:
R3#show ip ospf database router 2.2.2.2
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
LS age: 1385
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 80000005
Checksum: 0x6D6C
Length: 84
Number of Links: 5
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.2.2.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 20.20.20.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.23.2
(Link Data) Router Interface address: 10.10.23.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 1.1.1.1
(Link Data) Router Interface address: 10.10.12.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.10.12.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 10
OSPF makes differentiation between Transit Networks and Stub Networks. A transit network is a network where multiple routers could exist, therefore where multiple neighborships could be built (such as broadcast networks). However, a stub network is a network where no router or at most one other router can exist (such as Loopbacks or point-to-point networks).
From the above output we see that R2 has 5 links connected. The true is that in fact has 4 links, but one of them is counted two times: first time as Stub Network, and second time as a “connected to another router”. From this info we can get to know that this link is apoint-to-point link with network/mask number 10.10.12.0/24, and connected to another router whose router-id is 1.1.1.1. The IP that R2 uses on this link is 10.10.12.2, and its OSPF cost is 10 (from the line saying Metrics). A bunch of nice info!!!
All this information is very valuable because they get a picture of the network, knowing how the routers are connected and the cost of the links.
R3 has to build the spf tree and add the cost to reach R2 in order to know the cost to reach its networks.
We see also two stub networks not connected to any other router. These networks could be Loopback interfaces or point-to-point interfaces with no other router in the link. In our scenario, these networks are the Loopbacks of R2. Looking the info we see the IP and mask of each Loopback interface, and the costs that R2 has to reach them.
There is a link remaining, and it appears as transit network. This transit network deserves a second look:
R3#sh ip ospf database router 2.2.2.2
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
LS age: 1385
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 80000005
Checksum: 0x6D6C
Length: 84
Number of Links: 5
Link connected to: a Stub Network
(Link ID) Network/subnet number: 2.2.2.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 20.20.20.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.23.2
(Link Data) Router Interface address: 10.10.23.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 1.1.1.1
(Link Data) Router Interface address: 10.10.12.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.10.12.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 10
From this output we get several things. First, it’s a multi-access network, since it appears as transit network. Indeed, there is already a DR, whose IP address is 10.10.23.2, and the IP address that R2 is using in this link is 10.10.23.2, so its R2 itself who is acting as the DR. We can see also the cost that R2 uses to reach this network.
Every time we see a transit network, we should see a Type 2 related to that network advertisement.
LSA Type-2
This LSA is present every time there is an OSPF multi-access network (transit network). In this kind of network, OSPF behaves in a particular way. Instead of each device building a neighborship with each other, a Designated Router (DR) is chosen. Also a Backup DR is chosen (BDR), and the rest of the routers behave as DROther. Every DROther router builds a neighborship with DR and BDR routers in the transit network, and they send their LSA type 1 announcements only to them (using multicast address 224.0.0.6). Then, the DR retransmits these LSA Type 1 to all its neighbors, inside the transit network and outside the transit network. It also builds a new LSA type 2 with information about the transit network. Only the DR is in charge of generating this LSA Type 2, and only the DR sends it to all the neighbors, even the ones in the transit network, putting itself as the virtual owner of this LSA. That’s why every time there is a Transit Network, there is an LSA Type 2 related to that network.
In the OSPF database, the LSA Types 2 are under the line “Net Link States”
R3#show ip ospf database
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1341 0x80000005 0x0049DB 5
2.2.2.2 2.2.2.2 1355 0x80000005 0x006D6C 5
3.3.3.3 3.3.3.3 1340 0x80000005 0x005BBD 4
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.10.23.2 2.2.2.2 1443 0x80000001 0x00F8F2
Be aware that for the same transit network, there will be as much LSA types 1 announcing it as Routers in that transit network. But there will be only one LSA Type 2 for that network, generated by the DR.
Let’s have a deeper look on this LSA type 2. To check this LSA, we need to use the command show ip ospf database network and the IP address of the link, not the router-id. That IP address is the one that the DR has on that link, in our case 10.10.23.2:
R3# show ip ospf database network 10.10.23.2
OSPF Router with ID (3.3.3.3) (Process ID 1)
Net Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 711
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.10.23.2 (address of Designated Router)
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0xF8F2
Length: 32
Network Mask: /24
Attached Router: 2.2.2.2
Attached Router: 3.3.3.3
What do we have here? Well, first of all, we see that the advertising router is 2.2.2.2. So thats the router in charge of gathering all the info of the transit network and building the LSA type 2. We also see that there are 2 routers in this transit network: routers 2.2.2.2 and 3.3.3.3.
But we are missing something, don’t we? There is no cost associated to this network. Well, that’s because the cost to reach that network is announced in the LSA type 1 by each router.
Conclusion
As we have seen, each OSPF router in the network generates an LSA Type 1 with information about all its links. This LSAs are propagated all around the same area, and it gives information about IP Prefixes, costs and type of network (Stub/Transit) of the link. And for those networks that are multi-access networks (Transit Networks), the LSA Type 2 gives info about which routers are running on that network. This LSA Type 2 is generated only by the Designated Router on that transit network.
In future posts we will focus on other LSAs such as LSA Type 3, Type 4, Type 5 and Type 7.
The network which we will focus on for this post is the following:
One of the advantages of OSPF is the possibility of segmenting the network in areas. In fact, it’s necessary to do it in large networks, so the OSPF Database is smaller and more stable. We will see why later.Let’s have a look in the OSPF Database of R1 and let’s try to get connectivity info from the LSA type 3:
R1#sh ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 951 0x80000005 0x0049DB 5
2.2.2.2 2.2.2.2 767 0x80000002 0x007665 5
3.3.3.3 3.3.3.3 883 0x80000006 0x005CBA 4
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.10.23.3 3.3.3.3 912 0x80000001 0x00F8F2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
4.4.4.4 2.2.2.2 757 0x80000001 0x000317
5.5.5.5 3.3.3.3 840 0x80000001 0x00B65B
10.10.24.0 2.2.2.2 757 0x80000001 0x00AD51
10.10.35.0 3.3.3.3 873 0x80000001 0x0016D9
So R1 is getting four different LSAs type 3, two of them announced by the router whose ID is 2.2.2.2 (info extracted from the second colummn), and the other two announced by the router whose ID is 3.3.3.3. These advertising routers (ADV Router) are the ABRs for the Area 0.
Every router belonging to two areas is an ABR (Area Border Router), and it’s in charge of generating a summary of the prefixes in one area and announcing them to the other area as a LSA type 3. In every LSA type 3, the ABR router puts itself as next-hop for the route.
Let’s have a deeper look of the LSA type 3. We can type the command show ip ospf database summary adv-router followed by the ID of the ABR router to get info of all the LSAs type 3 announced by that router, or we can use the command show ip ospf database summary followed by the IP of the link we want to get more info:
R1#sh ip ospf database summary 4.4.4.4
OSPF Router with ID (1.1.1.1) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 829
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 4.4.4.4 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0x317
Length: 28
Network Mask: /32
MTID: 0 Metric: 11
What do we got here? Well, this LSA gives us several key pieces of information:
- First, we know the info of this LSA is valid and candidate to be added to the RIB, since the routing bit has been set on the LSA
- The IP of the link and its mask is 4.4.4.4/32
- In order to reach this link, we must go through the ABR 2.2.2.2
- The metric for 2.2.2.2 to reach the link 4.4.4.4 is 11
This last bit is very interesting. The metric for that prefix is the metric from R2’s point of view, not the metric that the owner of the route has, as we could find in the R4’s LSA type 1. And this behavior – one router telling its point of view about a route to the rest of the net – reminds me of something … yeah, it reminds me to the distance vector protocols! It’s funny, but OSPF behaves like a distanve vector protocol when it takes the LSA type 3 into account. Do you see the difference? In the LSA type 1, each router informs about its links and its cost, so everyone in the area can get this info directly from the source. However, with LSA type 3, the ABR informs about its point of view. It makes a summary about the original area, it hides the topology in that area, and just gives the info about the prefix and the cost it has to reach that prefix.
This summary, as I mentioned at the beginning, makes the OSPF Database smaller and more stable. Smaller because a LSA type 3 has less info than an LSA type 1 (check
Part I of this series to learn more about LSA type 1 and LSA type 2). And more stable because LSA type 3 are calculated in a less CPU-intensive cycle of SPF (LSA type 1 and type 2 are used in the first SPF calculation, more CPU-intensive; after that, the topology of the network is built, so the rest of LSAs are added to the nodes in the topology in a second less CPU-intensive cycle of the SPF calculation).
Let’s see how R5 perceives the world from the area 5:
R5#sh ip ospf database
OSPF Router with ID (5.5.5.5) (Process ID 1)
Router Link States (Area 5)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 598 0x80000004 0x00224D 2
5.5.5.5 5.5.5.5 547 0x80000004 0x0081BF 3
Summary Net Link States (Area 5)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 598 0x80000003 0x006BB4
2.2.2.2 3.3.3.3 598 0x80000004 0x003BDF
3.3.3.3 3.3.3.3 598 0x80000003 0x00AA77
4.4.4.4 3.3.3.3 598 0x80000004 0x0043C5
10.10.12.0 3.3.3.3 598 0x80000003 0x007486
10.10.13.0 3.3.3.3 598 0x80000003 0x0005FE
10.10.23.0 3.3.3.3 598 0x80000003 0x009663
10.10.24.0 3.3.3.3 598 0x80000004 0x00EDFF
20.20.20.2 3.3.3.3 598 0x80000004 0x00B034
As we see, R5’s Database has only 2 LSA type 1, one from R3 announcing its link in area 5, and another one from R5, with all the info about its links in area 5. The rest of the routing information comes from the different LSA type 3 that the ABR (in our scenario, R3) has injected into area 5. So R3 takes all the info in Area 0 and makes a summary link advertisement to inject in Area 5. It takes not only the LSA type 1 and type 2 present in Area 0, but also the LSA type 3 that there are in Area 0.
There is something interesting to mention here, and it’s that when the ABR injects the LSA type 3 into the nonbackbone area, it takes into account all LSA type 1, type 2 and type 3 present in the backbone area. But only LSA type 1 and type 2 (intra-area routes) present in the nonbackbone area are injected back into the backbone as LSA type 3. LSA type 3 already present in a nonbackbone area are not announced back to the backbone area.
We could make some calculations based on the number of LSAs of each type in each area:
R1#sh ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 951 0x80000005 0x0049DB 5
2.2.2.2 2.2.2.2 767 0x80000002 0x007665 5
3.3.3.3 3.3.3.3 883 0x80000006 0x005CBA 4
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.10.23.3 3.3.3.3 912 0x80000001 0x00F8F2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
4.4.4.4 2.2.2.2 757 0x80000001 0x000317
5.5.5.5 3.3.3.3 840 0x80000001 0x00B65B
10.10.24.0 2.2.2.2 757 0x80000001 0x00AD51
10.10.35.0 3.3.3.3 873 0x80000001 0x0016D9
R5#sh ip ospf database
OSPF Router with ID (5.5.5.5) (Process ID 1)
Router Link States (Area 5)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 598 0x80000004 0x00224D 2
5.5.5.5 5.5.5.5 547 0x80000004 0x0081BF 3
Summary Net Link States (Area 5)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 598 0x80000003 0x006BB4
2.2.2.2 3.3.3.3 598 0x80000004 0x003BDF
3.3.3.3 3.3.3.3 598 0x80000003 0x00AA77
4.4.4.4 3.3.3.3 598 0x80000004 0x0043C5
10.10.12.0 3.3.3.3 598 0x80000003 0x007486
10.10.13.0 3.3.3.3 598 0x80000003 0x0005FE
10.10.23.0 3.3.3.3 598 0x80000003 0x009663
10.10.24.0 3.3.3.3 598 0x80000004 0x00EDFF
20.20.20.2 3.3.3.3 598 0x80000004 0x00B034
R4#sh ip ospf database
OSPF Router with ID (4.4.4.4) (Process ID 1)
Router Link States (Area 4)
Link ID ADV Router Age Seq# Checksum Link count
2.2.2.2 2.2.2.2 1018 0x80000002 0x00CAC9 2
4.4.4.4 4.4.4.4 1015 0x80000003 0x00C0A8 3
Summary Net Link States (Area 4)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 2.2.2.2 1037 0x80000001 0x008D98
2.2.2.2 2.2.2.2 1047 0x80000001 0x00FA31
3.3.3.3 2.2.2.2 987 0x80000002 0x002FED
5.5.5.5 2.2.2.2 987 0x80000002 0x0037D3
10.10.12.0 2.2.2.2 1037 0x80000001 0x0032D8
10.10.13.0 2.2.2.2 1037 0x80000001 0x008B74
10.10.23.0 2.2.2.2 1037 0x80000001 0x00B847
10.10.35.0 2.2.2.2 987 0x80000002 0x009652
20.20.20.2 2.2.2.2 1047 0x80000001 0x007085
Counting the LSAs per area:
| LSA type 1 and LSA type 2 | LSA type 3 |
| AREA 0 | 3 type 1 and 1 type 2 (the link between R2 and R3 is a broadcast network | 4 |
| AREA 4 | 2 type 1 (one from each router in the area) | 9 |
| AREA 5 | 2 type 1 (one from each router in the area) | 9 |
When designing an OSPF network, we have to keep in mind simplicity, scalability and stability. Depending on how many routers we got in the net and the topology of the net, we have to decide how many areas to build and how many routers to put in each area. Of course, one of the main goals is to get a very stable backbone, so it can help us to choose where to put the area border.
We can mention some other things about LSA type 3. For example, if a Router finds the same prefix learned via LSA type 1 and via LSA type 3, it will prefer always the prefix learned via the LSA type 1. This is so because an LSA type 1 means the prefix belongs to the same area where the router is looking at; however, an LSA type 3 is a summary from another area. Imagine there are 2 ABRs in area 5: the first one will inject into Area 0 an LSA type 3 from Area 5. The second ABR will have one LSA type 1 for that prefix from Area 5 and one LSA type 3 for the same prefix from Area 0. It will prefer to use the direct link to Area 5 in order to reach de prefix.
And there is another interesting thing about LSA type 3. We know OSPF doesnt allow to filter LSA type 1 and type 2 messages, because it’s necessary that all routers in the same area have the same LSA type 1 and LSA type 2 info, otherwise the result of the SPF calculation would not be accurate. But it’s allowed to filter LSA type 3, and it can be done at ABRs. Even more, not only filtering, but also aggregating is allowed. For that purpose we can use the following commands at ABRs:
- area x range: in order to summarize several prefixes in one aggregated prefix. It’s possible to choose to advertised the aggregated (advertised) or not to advertised the aggregated (not-advertised) what means the prefixes are filtered out
- area x filter-list prefix: to filter out a specific prefix from one area to another area
