Building the Link-State Database
OSPF, as a link-state protocol, uses several different packets to exchange the information about network topology between routers. These packets are called link-state advertisements (LSAs), and they describe the network topology in great detail. Each router stores the received LSA packets in the link-state database (LSDB). After LSDBs are synced between the routers, OSPF uses the shortest path first (SPF) algorithm to calculate the best routes. The best intra-area routes are calculated individually by each OSPF router. For the best interarea route calculation, the internal router must rely also on the best path information received from the ABRs.
Upon completing this section, you will be able to do the following:
- List and describe different LSA types
- Describe how OSPF LSAs are also reflooded at periodic intervals
- Describe the exchange of information in a network without a designated router
- Describe the exchange of information in a network with a designated router
- Explain when SPF algorithms occur
- Describe how the cost of intra-area routes is calculated
- Describe how the cost of interarea routes is calculated
- Describe rules selecting between intra-area and interarea routes
OSPF LSA Types
Knowing the detailed topology of the OSPF area is required for a router to calculate the best paths. Topology details are described by LSAs, which are the building blocks of the OSPF LSDB. Individually, LSAs act as database records. In combination, they describe the entire topology of an OSPF network area. Figure 3-11 shows a sample topology, highlighting the most common types of OSPF LSAs, which are described in further detail in the list that follows.
)
Figure 3-11 OSPF LSA Types
- Type 1, Router LSA: Every router generates router link advertisements for each area to which it belongs. Router link advertisements describe the state of the router links to the area and are flooded only within that particular area. For all types of LSAs, there are 20-byte LSA headers. One of the fields of the LSA header is the link-state ID. The link-state ID of the type 1 LSA is the originating router ID.
- Type 2, Network LSA: DRs generate network link advertisements for multiaccess networks. Network link advertisements describe the set of routers that are attached to a particular multiaccess network. Network link advertisements are flooded in the area that contains the network. The link-state ID of the type 2 LSA is the IP interface address of the DR.
- Type 3, Summary LSA: An ABR takes the information that it learned in one area and describes and summarizes it for another area in the summary link advertisement. This summarization is not on by default. The link-state ID of the type 3 LSA is the destination network number.
- Type 4, ASBR Summary LSA: The ASBR summary link advertisement informs the rest of the OSPF domain how to get to the ASBR. The link-state ID includes the router ID of the described ASBR.
- Type 5, Autonomous System LSA: Autonomous system external link advertisements, which are generated by ASBRs, describe routes to destinations that are external to the autonomous system. They get flooded everywhere, except into special areas. The link-state ID of the type 5 LSA is the external network number.
Other LSA types include the following:
- Type 6: Specialized LSAs that are used in multicast OSPF applications
- Type 7: Used in special area type NSSA for external routes
- Type 8, 9: Used in OSPFv3 for link-local addresses and intra-area prefix
- Type 10, 11: Generic LSAs, also called opaque, which allow future extensions of OSPF
Examining the OSPF Link-State Database
This section analyzes the OSPF LSDB and the different types of LSAs using the topology in Figure 3-12. All routers have already been preconfigured with OSPF. In the figure, R1 is an ABR between areas 0, 1, and 2. R3 acts as the ASBR between the OSPF routing domain and an external domain. LSA types 1 and 2 are flooded between routers within an area. Type 3 and type 5 LSAs are flooded when exchanging information about backbone and standard areas. Type 4 LSAs are injected into the backbone by the ABR because all routers in the OSPF domain need to reach the ASBR (R3).
)
Figure 3-12 OSPF Topology
OSPF Link-State Database
Example 3-25 shows R4’s routing table, which includes several OSPF routes because all the routers have already been configured.
Example 3-25 R4’s Routing Table
R4# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/16 is subnetted, 1 subnets
O E2 10.0.0.0 [110/20] via 172.16.14.1, 00:46:48, Ethernet0/0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA 172.16.12.0/30 [110/74] via 172.16.14.1, 03:19:12, Ethernet0/0
O IA 172.16.13.0/30 [110/20] via 172.16.14.1, 03:19:12, Ethernet0/0
C 172.16.14.0/30 is directly connected, Ethernet0/0
L 172.16.14.2/32 is directly connected, Ethernet0/0
O 192.168.1.0/24 [110/11] via 172.16.14.1, 00:36:19, Ethernet0/0
O IA 192.168.2.0/24 [110/75] via 172.16.14.1, 00:47:59, Ethernet0/0
Notice the intra-area route 192.168.1.0/24 and interarea routes describing WAN links 172.16.12.0/30, 172.16.13.0/30, and the remote subnet 192.168.2.0/24 on R2. There is also routing information about an OSPF external route that is describing network 10.0.0.0/16. This route is injected into OSPF on R3, which has connectivity to external networks.
Example 3-26 displays the OSPF database on R4.
Example 3-26 R4’s OSPF LSDB
R4# show ip ospf database
OSPF Router with ID (4.4.4.4) (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 291 0x8000000B 0x00966C 2
4.4.4.4 4.4.4.4 1993 0x80000007 0x001C4E 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.14.2 4.4.4.4 1993 0x80000006 0x0091B5
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.12.0 1.1.1.1 291 0x80000007 0x00C567
172.16.13.0 1.1.1.1 291 0x80000007 0x009CC5
192.168.2.0 1.1.1.1 1031 0x80000002 0x002E5D
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
3.3.3.3 1.1.1.1 1031 0x80000002 0x0035EB
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 3.3.3.3 977 0x80000002 0x000980 0
The OSPF database contains all LSAs that describe the network topology. The show ip ospf database command displays the content of the LSDB and verifies information about specific LSAs.
The output reveals the presence of different LSA types. For each LSA type, you can see which router advertised it, the age of the LSA, and the value of the link ID.
In Example 3-26, notice two different type 1 LSAs, or router link advertisements, generated by routers with router ID 1.1.1.1 and 4.4.4.4.
Example 3-27 displays the details of R4’s type 1 LSAs
Example 3-27 R4 Type 1 LSA Details
R4# show ip ospf database router
OSPF Router with ID (4.4.4.4) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 321
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
LS Seq Number: 8000000B
Checksum: 0x966C
Length: 48
Area Border Router
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 172.16.14.2
(Link Data) Router Interface address: 172.16.14.1
Number of MTID metrics: 0
TOS 0 Metrics: 10
LS age: 2023
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 4.4.4.4
Advertising Router: 4.4.4.4
LS Seq Number: 80000007
Checksum: 0x1C4E
Length: 36
Number of Links: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 172.16.14.2
(Link Data) Router Interface address: 172.16.14.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
Type 1 LSAs are generated by every router and flooded within the area. They describe the state of the router links in that area. R4 has two type 1 LSAs in the database: one received from R1 with router ID 1.1.1.1, and one that was generated by R4.
The content of the displayed LSA reveals that R1 is an ABR with two links. The output shows details for both links, to what kind of network the links are connected, and their settings, such as the IP configuration. Link can be connected to a stub, to another router (point-to-point), or to a transit network. The transit network describes Ethernet or NMBA segment, which can include two or more routers. If the link is connected to a transit network, the LSA also includes the info about the DR address.
The LSDB keeps copies of all LSAs, including those that were generated locally on the router. An example of a local LSA is the second advertisement that is displayed in the output. It includes the same topology parameters as the first LSA, but this time from a perspective of router R4.
OSPF identifies all LSAs using a 32-bit LSID. When generating a type 1 LSA, the router uses its own router ID as the value of LSID.
Using the self-originate command argument, Example 3-28 displays locally generated type 1 LSAs on R4.
Example 3-28 Locally Generated Type 1 LSAs on R4
R4# show ip ospf database router self-originate
OSPF Router with ID (4.4.4.4) (Process ID 1)
Router Link States (Area 0)
LS age: 23
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 4.4.4.4
Advertising Router: 4.4.4.4
LS Seq Number: 80000008
Checksum: 0x1A4F
Length: 36
Number of Links: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 172.16.14.2
(Link Data) Router Interface address: 172.16.14.2
Number of MTID metrics: 0
TOS 0 Metrics: 10
The output shows the type 1 LSA, which describes the interface that is enabled in OSPF area 0 on router R4.
R4 has an interface that is connected to a transit network; therefore, the DR information is also included. You can see that R4 is the DR on the segment.
Example 3-29 shows the OSPF database on router R2.
Example 3-29 R2’s OSPF LSDB
R2# show ip ospf database
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 403 0x80000008 0x0097B7 1
2.2.2.2 2.2.2.2 1088 0x80000008 0x006E5C 2
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
172.16.12.2 2.2.2.2 587 0x80000003 0x00A5B6
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
172.16.13.0 1.1.1.1 403 0x80000007 0x009CC5
172.16.14.0 1.1.1.1 403 0x80000007 0x0091CF
192.168.1.0 1.1.1.1 403 0x80000002 0x00B616
Summary ASB Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
3.3.3.3 1.1.1.1 1143 0x80000002 0x0035EB
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 3.3.3.3 1089 0x80000002 0x000980 0
OSPF type 1 LSAs are exchanged only within OSPF areas. Router R2, which has interfaces that are configured in OSPF area 1, should not see any type 1 LSAs that were originated on R4. The output of the OSPF database from R2 confirms this. No type 1 LSA with the advertising router parameter set to 4.4.4.4 can be found in the LSDB.
Example 3-30 displays the LSAs on R1.
Example 3-30 R1’s OSPF LSDB
R1# show 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 445 0x8000000B 0x00966C 2
4.4.4.4 4.4.4.4 103 0x80000008 0x001A4F 1
<Output omitted>
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 445 0x80000008 0x0097B7 1
2.2.2.2 2.2.2.2 1133 0x80000008 0x006E5C 2
<Output omitted>
Router Link States (Area 2)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 445 0x80000008 0x00DDA5 1
3.3.3.3 3.3.3.3 1131 0x8000000A 0x00521D 1
<Output omitted>
Notice that router R1 is the only router that is in multiple areas. As an ABR, its OSPF database includes type 1 LSAs from all three areas.
OSPF Type 2 Network LSA
Figure 3-13 shows a type 2 LSA, which is generated for every transit broadcast or NBMA network within an area.
)
Figure 3-13 OSPF Type 2 LSA
The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, and the subnet mask that is used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.
Example 3-31 shows R4’s OSPF LSDB with a focus on the type 2 LSAs.
Example 3-31 R4’s Type 2 LSAs
R4# show ip ospf database
OSPF Router with ID (4.4.4.4) (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 486 0x8000000B 0x00966C 2
4.4.4.4 4.4.4.4 142 0x80000008 0x001A4F 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.14.2 4.4.4.4 142 0x80000007 0x008FB6
<Output omitted>
Notice that R4 has only one type 2 LSA in its LSDB. This is expected because there is only one multiaccess network in area 0.
Example 3-32 shows the details of a type 2 LSA on router R4.
Example 3-32 R4’s Type 2 LSA Details
R4# show ip ospf database network
OSPF Router with ID (4.4.4.4) (Process ID 1)
Net Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 170
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 172.16.14.2 (address of Designated Router)
Advertising Router: 4.4.4.4
LS Seq Number: 80000007
Checksum: 0x8FB6
Length: 32
Network Mask: /30
Attached Router: 4.4.4.4
Attached Router: 1.1.1.1
The content of the displayed type 2 LSA describes the network segment listing the DR address, the attached routers, and the used subnet mask. This information is used by each router participating in OSPF to build the exact picture of the described multiaccess segment, which cannot be fully described with just type 1 LSAs.
OSPF Type 3 Summary LSA
ABRs do not forward type 1 and 2 LSAs between areas to improve OSPF scalability. However, other routers still need to learn how to reach interarea subnets in other areas. OSPF advertises these subnets on ABRs by using type 3 summary LSAs, as shown in Figure 3-14.
)
Figure 3-14 OSPF Type 3 LSA
The ABRs generate type 3 summary LSAs to describe any networks that are owned by an area to the rest of the areas in the OSPF autonomous system, as shown in the figure.
Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.
Notice that the figure only illustrates how information is propagated from area 10 to the other areas. Type 3 LSAs are also advertised by ABRs in other direction, from area 20 to area 0, and from area 0 into area 10.
By default, OSPF does not automatically summarize groups of contiguous subnets. OSPF does not summarize a network to its classful boundary. A type 3 LSA is advertised into the backbone area for every subnet that is defined in the originating area, which can cause flooding problems in larger networks.
As a best practice, you can use manual route summarization on ABRs to limit the amount of information that is exchanged between the areas.
Example 3-33 displays R4’s OSPF LSDB, with the focus on type 3 LSAs.
Example 3-33 R4’s Type 3 LSAs
R4# show ip ospf database
OSPF Router with ID (4.4.4.4) (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 583 0x8000000B 0x00966C 2
4.4.4.4 4.4.4.4 238 0x80000008 0x001A4F 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.14.2 4.4.4.4 238 0x80000007 0x008FB6
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.12.0 1.1.1.1 583 0x80000007 0x00C567
172.16.13.0 1.1.1.1 583 0x80000007 0x009CC5
192.168.2.0 1.1.1.1 1322 0x80000002 0x002E5D
<Output omitted>
The LSDB on router R4 includes three different type 3 summary LSAs, all advertised into area 1 by the ABR R1.
Example 3-34 shows the details of R4’s type 3 LSAs.
Example 3-34 R4’s Type 3 LSA Details
R4# show ip ospf database summary
OSPF Router with ID (4.4.4.4) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 608
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 172.16.12.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000007
Checksum: 0xC567
Length: 28
Network Mask: /30
MTID: 0 Metric: 64
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 608
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 172.16.13.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000007
Checksum: 0x9CC5
Length: 28
Network Mask: /30
MTID: 0 Metric: 10
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1348
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 192.168.2.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000002
Checksum: 0x2E5D
Length: 28
Network Mask: /24
MTID: 0 Metric: 65
The output in the examples shows detailed information about three type 3 LSAs in the LSDB. Each type 3 LSA has a link-state ID field, which carries the network address, and together with the attached subnet mask describes the interarea network. Notice that all three LSAs were advertised by the router having router ID set to 1.1.1.1, which is the ABR router R1.
OSPF Type 4 ASBR Summary LSA
Figure 3-15 shows a type 4 summary LSA generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to the ASBR. The link-state ID is set to the ASBR router ID. All traffic that is destined to an external autonomous system requires routing table knowledge of the ASBR that originated the external routes.
)
Figure 3-15 OSPF Type 4 LSA
In the figure, the ASBR sends a type 1 router LSA with a bit (known as the external bit) that is set to identify itself as an ASBR. When the ABR (identified with the border bit in the router LSA) receives this type 1 LSA, it builds a type 4 LSA and floods it to the backbone, area 0. Subsequent ABRs regenerate a type 4 LSA to flood it into their areas.
Example 3-35 shows R4’s OSPF LSDB with a focus on type 4 LSAs.
Example 3-35 R4’s Type 4 LSAs
R4# show ip ospf database
OSPF Router with ID (4.4.4.4) (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 666 0x8000000B 0x00966C 2
4.4.4.4 4.4.4.4 321 0x80000008 0x001A4F 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.14.2 4.4.4.4 321 0x80000007 0x008FB6
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.12.0 1.1.1.1 666 0x80000007 0x00C567
172.16.13.0 1.1.1.1 666 0x80000007 0x009CC5
192.168.2.0 1.1.1.1 1405 0x80000002 0x002E5D
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
3.3.3.3 1.1.1.1 1405 0x80000002 0x0035EB
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 3.3.3.3 1351 0x80000002 0x000980 0
There is only one type 4 LSA present in the R4 OSPF database. The type 4 LSA was generated by ABR R1 and describing the ASBR with the router ID 3.3.3.3.
Example 3-36 shows the details of the type 4 LSA on R4.
Example 3-36 R4’s Type 4 LSA Details
R4# show ip ospf database asbr-summary
OSPF Router with ID (4.4.4.4) (Process ID 1)
Summary ASB Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1420
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 3.3.3.3 (AS Boundary Router address)
Advertising Router: 1.1.1.1
LS Seq Number: 80000002
Checksum: 0x35EB
Length: 28
Network Mask: /0
MTID: 0 Metric: 10
A type 4 LSA contains information about the existence of the ASBR in the OSPF autonomous system. The information is advertised to R4 from R1, which recognizes the ASBR capability of R3 with a router ID of 3.3.3.3.
OSPF Type 5 External LSA
Figure 3-16 shows type 5 external LSAs used to describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.
)
Figure 3-16 OSPF Type 5 LSA
The link-state ID is the external network number. Because of the flooding scope and depending on the number of external networks, the default lack of route summarization can also be a major issue with external LSAs. Therefore, you should consider summarization of external network numbers at the ASBR to reduce flooding problems.
Example 3-37 shows R4’s OSPF LSDB, with a focus on type 5 LSAs.
Example 3-37 R4’s OSPF LSDB
R4# show ip ospf database
OSPF Router with ID (4.4.4.4) (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 724 0x8000000B 0x00966C 2
4.4.4.4 4.4.4.4 380 0x80000008 0x001A4F 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.14.2 4.4.4.4 380 0x80000007 0x008FB6
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.12.0 1.1.1.1 724 0x80000007 0x00C567
172.16.13.0 1.1.1.1 724 0x80000007 0x009CC5
192.168.2.0 1.1.1.1 1463 0x80000002 0x002E5D
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
3.3.3.3 1.1.1.1 1463 0x80000002 0x0035EB
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 3.3.3.3 1410 0x80000002 0x000980 0
The LSDB on R4 contains one external LSA describing external network 10.0.0.0, which was advertised into OSPF by router R3 with a router ID 3.3.3.3.
Example 3-38 shows the details of a type 5 LSA on R4.
Example 3-38 R4’s Type 5 LSA Details
R4# show ip ospf database external
OSPF Router with ID (4.4.4.4) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1434
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 10.0.0.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x980
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
An external LSA on R4 describes the external network 10.0.0.0 with the subnet mask /16. The LSA is advertised by the R3 with a router ID 3.3.3.3. The zero forwarding address tells the rest of the routers in the OSPF domain that ASBR itself is the gateway to get to the external routes. Router R4 gathers information described in the type 5 LSA combined with the information received in the type 4 LSA, which describes the ASBR capability of router R3. This way, R4 learns how to reach the external networks.
Periodic OSPF Database Changes
Although OSPF does not refresh routing updates periodically, it does reflood LSAs every 30 minutes. Each LSA includes the link-state age variable, which counts the age of the LSA packet. When a network change occurs, the LSA’s advertising router generates an updated LSA to reflect the change in the network topology. Each updated LSA includes incremented sequence number so that other routers can distinguish an updated LSA from the old one.
If the LS age variable reaches 30 minutes, meaning that there was no updated LSA created in the last half an hour, it gets automatically regenerated with an increased sequence number and flooded through the OSPF autonomous system. Only the router that originally generated the LSA, the one with the directly connected link, will resend the LSA every 30 minutes.
The output of the OSPF LSDB reveals the value of the current link-state age timer for all LSAs. In a normally operating network, you will not see the age variable with values higher than 1800 seconds.
When an LSA reaches a max age of 60 minutes in the LSDB, it is removed from the LSDB, and the router will perform a new SPF calculation. The router floods the LSA to other routers, informing them to remove the LSA as well.
Because this update is only used to refresh the LSDB, it is sometimes called a paranoid update.
Exchanging and Synchronizing LSDBs
Once a bidirectional adjacency is formed, OSPF neighbors follow an exact procedure to synchronize the LSDBs between them.
When routers that are running OSPF are initialized, an exchange process using the hello protocol is the first procedure. The exchange process that happens when routers appear on the network is illustrated in the Figure 3-17 and detailed in the list that follows.
)
Figure 3-17 Establishing Neighbor Adjacencies
- Router R1 is enabled on the LAN and is in a down state because it has not exchanged information with any other router. It begins by sending a Hello packet through each of its interfaces that are participating in OSPF, even though it does not know the identity of the DR or of any other routers. The Hello packet is sent out using the multicast address 224.0.0.5.
- All directly connected routers that are running OSPF receive the Hello packet from router R1 and add R1 to their lists of neighbors. After adding R1 to the list, other routers are in the Init state.
- Each router that received the Hello packet sends a unicast reply Hello packet to R1 with its corresponding information. The neighbor field in the Hello packet includes all neighboring routers and R1.
- When R1 receives these Hello packets, it adds all the routers that had its router ID in their Hello packets to its own neighbor relationship database. After this process, R1 is in the 2-way state. At this point, all routers that have each other in their lists of neighbors have established bidirectional communication.
If the link type is a broadcast network, like Ethernet, a DR and BDR election occurs before the neighboring state proceeds to the next phase.
In the ExStart state, a master-slave relationship is determined between the adjacent neighbors. The router with the higher router ID acts as the master during the exchange process. In Figure 3-17, R2 becomes the master.
Routers R1 and R2 exchange one or more DBD packets while they are in the Exchange state. A DBD includes information about the LSA entry header that appears in the LSDB of the router. The entries can be about a link or a network. Each LSA entry header includes information about the link-state type, the address of the advertising router, the cost of the link, and the sequence number. The router uses the sequence number to determine the “newness” of the received link-state information.
When the router receives the DBD, it performs these actions, as shown in Figure 3-18:
- It acknowledges the receipt of the DBD using the LSAck packet.
- It compares the information that it received with the information that it has. If the DBD has a more up-to-date link-state entry, the router sends an LSR to the other router. When routers start sending LSRs, they are in the loading state.
The other router responds with the complete information about the requested entry in an LSU packet. Again, when the router receives an LSU, it returns an LSAck.
Figure 3-18 Exchanging and Synchronizing a LSDB
)
The router adds the new link-state entries to its LSDB.
When all LSRs have been satisfied for a given router, the adjacent routers are considered synchronized. They are in a Full state, and their LSDBs should be identical. The routers must be in a Full state before they can route traffic.
Synchronizing the LSDB on Multiaccess Networks
On multiaccess segments like Ethernet, OSPF optimizes the LSDB synchronization and the exchange of LSAs. When routers form a neighbor relationship on a multiaccess segment, the DR and BDR election takes place when routers are in the 2-Way state. The router with a highest OSPF priority, or highest router ID in case of a tie, is elected as a DR. Similarly, the router with the second highest priority or router ID becomes the BDR.
While the DR and BDR proceed in establishing the neighborship with all routers on the segment, other routers establish full adjacency only with the DR and BDR. The neighbor state of other neighbors stays in the 2-Way state.
Non-DR router exchange their databases only with the DR. The DR takes care to synchronize any new or changed LSAs with the rest of the routers on the segment.
In the flooding process that is illustrated in Figure 3-19, routers perform the following steps:
- Step 1. A router notices a change in a link state and multicasts an LSU packet (which includes the updated LSA entry) to all OSPF DRs and BDRs at multicast address 224.0.0.6. An LSU packet may contain several distinct LSAs.
- Step 2. The DR acknowledges receipt of the change and floods the LSU to others on the network using the OSPF multicast address 224.0.0.5.
- Step 3. After receiving the LSU, each router responds to the DR with an LSAck. To make the flooding procedure reliable, each LSA must be acknowledged separately.
Step 4. The router updates its LSDB using the LSU that includes the changed LSA.
Figure 3-19 Synchronizing the LSDB on an Multiaccess Network
)
){kind=link}
Running the SPF Algorithm
Every time there is a change in the network topology, OSPF needs to reevaluate its shortest path calculations. OSPF uses SPF to determine best paths toward destinations. The network topology that is described in the LSDB is used as an input for calculation. Network topology change can influence best path selection; therefore, routers must rerun SPF each time there is an intra-area topology change.
Interarea changes, which are described in type 3 LSAs, do not trigger the SPF recalculation because the input information for the best path calculation remains unchanged. The router determines the best paths for interarea routes based on the calculation of the best path toward the ABR. The changes that are described in type 3 LSAs do not influence how the router reaches the ABR; therefore, SPF recalculation is not needed.
You can verify how often the SPF algorithm was executed by using the show ip ospf command, as shown in Example 3-39. The output will also show you when the algorithm was last executed.
Example 3-39 Verifying OSPF Frequency of the SPF Algorithm
R1# show ip ospf | begin Area
Area BACKBONE(0) (Inactive)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:35:04:959 ago
SPF algorithm executed 5 times
Area ranges are
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 1
Configuring OSPF Path Selection
In this section, we will analyze and influence how OSPF determines link costs to calculate the best path, continuing with the previous topology shown in Figure 3-20.
)
Figure 3-20 Topology for OSPF Path Selection
OSPF Path Selection
In Example 3-40, the output of the show ip ospf command verifies how many times the SFP algorithm was executed.
Example 3-40 Verifying the SPF Calculations on R1
R1# show ip ospf | begin Area
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has no authentication
SPF algorithm last executed 00:02:17.777 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 7. Checksum Sum 0x0348C4
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
<Output omitted>
The command output shows you how many times SPF has already run, together with the information about the last execution.
On R1, the link toward R4 is disabled and reenabled in Example 3-41. The number of SPF executions is verified afterward.
Example 3-41 SPF Calculated on R1
R1(config)# interface ethernet 0/0
R1(config-if)# shutdown
*Jan 31 12:33:20.617: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0/0 from
FULL to DOWN, Neighbor Down: Interface down or detached
*Jan 31 12:33:22.613: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to
administratively down
*Jan 31 12:33:23.617: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0,
changed state to down
R1(config-if)# no shutdown
*Jan 31 12:33:29.125: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
*Jan 31 12:33:30.129: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0,
changed state to up
*Jan 31 12:33:35.040: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0/0 from
LOADING to FULL, Loading Done
R1(config-if)# do show ip ospf | begin Area
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has no authentication
SPF algorithm last executed 00:00:07.752 ago
SPF algorithm executed 5 times
Area ranges are
Number of LSA 7. Checksum Sum 0x033ACB
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
<Output omitted>
Disabling the interface on R1 in area 0 triggers SPF calculation. Enabling the interface back into the OSPF triggers another SPF calculation. As a result, the counter displayed in the output has increased.
Link flap caused two recalculations of SPF algorithm. Frequent changes of link status can lead to frequent SPF calculation, which can utilize router resources.
OSPF Best Path Calculation
Once LSDBs are synchronized among OSPF neighbors, each router needs to determine on its own the best paths over the network topology.
When SPF is trying to determine the best path toward a known destination, it compares total costs of specific paths against each other. The paths with the lowest costs are selected as the best paths. The OSPF cost is an indication of the overhead to send packets over an interface. OSPF cost is computed automatically for each interface that is assigned into an OSPF process, using the following formula:
Cost = Reference bandwidth / Interface bandwidth
The cost value is a 16-bit positive number between 1 and 65,535, where a lower value is a more desirable metric. Reference bandwidth is set to 100 Mbps by default.
On high-bandwidth links (100 Mbps and more), automatic cost assignment no longer works. (It would result in all costs being equal to 1.) On these links, OSPF costs must be set manually on each interface.
For example, a 64-Kbps link gets a metric of 1562, and a T1 link gets a metric of 64. Cost is applied on all router link paths, and route decisions are made on the total cost of a path. The metric is only relevant on an outbound path; route decisions are not made for inbound traffic. The OSPF cost is recomputed after every bandwidth change, and the Dijkstra’s algorithm determines the best path by adding all link costs along a path.
Example 3-42 reveals the interface bandwidth and the OSPF cost of the Frame Relay interface on R1.
Example 3-42 Examining the Interface Bandwidth and OSPF Cost on R1
R1# show interface serial 2/0 Serial2/0 is up, line protocol is up Hardware is M4T Internet address is 172.16.12.1/30 MTU 1500 bytes,BW 1544 Kbit/sec, DLY 20000 usec,reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, crc 16, loopback not set <Output omitted> R1# show ip ospf interface serial 2/0 Serial2/0 is up, line protocol is up Internet Address 172.16.12.1/30, Area 1, Attached via Network Statement Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST,Cost: 64Topology-MTID Cost Disabled Shutdown Topology Name 0 64 no no Base Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 2.2.2.2, Interface address 172.16.12.2 Backup Designated router (ID) 1.1.1.1, Interface address 172.16.12.1 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 <Output omitted>
The first command in the output displays bandwidth of the serial interface, which connects R1 with R2. The second output shows that OSPF calculated the cost of 64 for this interface. The cost was calculated by dividing the reference bandwidth of 100 Mbps with the actual interface bandwidth.
Default OSPF Costs
OSPF calculates the default interface costs, based on the interface type and the default reference bandwidth, shown in Table 3-2.
Table 3-2 Default OSPF Costs
|
Link Type |
Default Cost |
|
T1 (1.544-Mbps serial link) |
64 |
|
Ethernet |
10 |
|
Fast Ethernet |
1 |
|
Gigabit Ethernet |
1 |
|
10-Gigabit Ethernet |
1 |
The default reference bandwidth of 100 Mbps is not suitable to calculate OSPF costs for links faster than Fast Ethernet. All such links gets assigned cost of 1, and OSPF cannot optimally choose the shortest path as it treats all the high-speed links as equal.
To improve OSPF behavior, you can adjust reference bandwidth to a higher value by using the auto-cost reference-bandwidth OSPF configuration command.
In Example 3-43, the reference bandwidth on R1 is changed to 10 Gbps.
Example 3-43 Modifying the Reference Bandwidth on R1
R1(config)# router ospf 1
R1(config-router)# auto-cost reference-bandwidth 10000
% OSPF: Reference bandwidth is changed.
Please ensure reference bandwidth is consistent across all routers.
You can change the OSPF reference bandwidth under OSPF configuration mode by using the auto-cost reference-bandwidth command. The reference bandwidth value is inserted in megabits per second.
Notice also the warning that is displayed by the prompt. Only consistent reference bandwidth across OSPF domain ensures that all routers calculate the best paths correctly.
Example 3-44 highlights the OSPF link cost of R1’s serial interface.
Example 3-44 R1’s OSPF Cost on Serial 2/0
R1# show ip ospf interface serial 2/0
Serial2/0 is up, line protocol is up
Internet Address 172.16.12.1/30, Area 1, Attached via Network Statement
Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 6476
Topology-MTID Cost Disabled Shutdown Topology Name
0 6476 no no Base
<Output omitted>
The changed OSPF reference bandwidth results in updated OSPF costs for all interfaces. The cost for Serial 2/0 interface has increased from 64 to 6476. The new cost was calculated based on reference bandwidth of 10 Gbps divided by the interface speed of 1.544 Mbps.
In Example 3-45, the interface bandwidth is changed on R1’s Serial 2/0 interface.
Example 3-45 Changing the Interface Bandwidth on R1’s Serial 2/0 Interface
R1(config)# interface serial 2/0 R1(config-if)# bandwidth 10000
Changing the OSPF reference bandwidth influences the cost of all local interfaces included in the OSPF. Commonly, you will need to influence the cost just for a specific interface on the router. Using the bandwidth command, you can change how IOS treats a specific interface by default. Bandwidth setting changes the artificial value of the interface bandwidth that is derived by IOS based on the interface type. A manually set bandwidth value on the interface overrides the default value and is used by OSPF as input to the interface cost calculation.
Modifying the bandwidth not only influences OSPF but also other routing protocols like EIGRP, which takes the bandwidth into account when calculating the EIGRP metric.
The interface bandwidth and the OSPF cost of the serial interface on R1 are verified in Example 3-46.
Example 3-46 Verifying the Interface Bandwidth and OSPF Cost on R1’s Serial 2/0 Interface
R1# show interfaces serial 2/0
Serial2/0 is up, line protocol is up
Hardware is M4T
Internet address is 172.16.12.1/30
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 20000 usec,
<Output omitted>
R1# show ip ospf interface serial 2/0
Serial2/0 is up, line protocol is up
Internet Address 172.16.12.1/30, Area 1, Attached via Network Statement
Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 1000
Topology-MTID Cost Disabled Shutdown Topology Name
0 1000 no no Base
<Output omitted>
The interface verification command displays the updated interface bandwidth, which was manually set to 10 Mbps. The change of the interface bandwidth is also reflected in the newly calculated OSPF cost, which is shown in the second output. The cost was calculated by dividing the reference bandwidth of 10000 Mbps with the configured bandwidth of 10 Mbps.
In Example 3-47, the OSPF cost of the serial interface link on R1 is changed using the ip ospf cost interface command.
Example 3-47 Changing the OSPF Cost on an Interface
R1(config)# interface serial 2/0 R1(config-if)# ip ospf cost 500
Using the OSPF interface configuration command, you can directly change the OSPF cost of specific interface. Cost of the interface can be set to a value between 1 and 65,535. This command overrides whatever value is calculated based on the reference bandwidth and the interface bandwidth.
The OSPF cost of the serial interface on R1 is verified in Example 3-48.
Example 3-48 Verifying the OSPF Interface Costs on R1
R1# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Lo0 1 0 192.168.1.1/24 1 P2P 0/0 Et0/0 1 0 172.16.14.1/30 1000 DR 1/1Se2/01 1 172.16.12.1/30500BDR 1/1 Et0/1 1 2 172.16.13.1/30 1000 BDR 1/1
To verify the OSPF cost, you can also use the brief keyword in the show ip ospf interface command. The verification command displays the summarized information on all OSPF-enabled interfaces, including the cost of the interface. You can notice the updated cost of the serial interface, which was manually configured in the previous step. In the output, you can observe the manually configured cost setting of the serial interface.
Calculating the Cost of Intra-Area Routes
To calculate the cost of intra-area routes, the router first analyzes OSPF database and identifies all subnets within its area. For each possible route, OSPF calculates the cost to reach the destination by summing up the individual interface costs. For each subnet, the route with the lowest total cost is selected as the best route.
Analyzing the topology in the Figure 3-21 from R1’s perspective, notice that it can reach intra-area network A either via ABR1 or ABR2. The autonomous system path through ABR1 is associated with the lower cost, so it will be selected as the best path.
)
Figure 3-21 Calculating the Cost of Intra-Area Routes
In a scenario where two paths would have the same lowest total cost, both routes would be selected as the best paths and inserted in the routing table. As a result, a router would perform equal-cost load balancing.
Calculating the Cost of Interarea Routes
The internal OSPF router within an area receives only summarized info about interarea routes. As a result, the cost of an interarea route cannot be calculated the same way as for the intra-area routes.
When ABRs propagate information about the interarea routes with type 3 LSAs, they include their lowest cost to reach a specific subnet in the advertisement. The internal router adds its cost to reach a specific ABR to the cost announced in a type 3 LSA. Then it selects the route with the lowest total cost as the best route.
Router R1, in Figure 3-22, learns about network B from both ABRs. ABR2 in type 2 LSA reports the lowest cost to reach network B as 6, while ABR1 reports the cost of 21. Router R1 determines the lowest cost to reach both ABRs and adds this cost to the one received in LSA. Router R1 selects the route via ABR2 as the total lowest cost route and tries to install it into the routing table.
)
Figure 3-22 Calculating the Cost of Interarea Routes
Selecting Between Intra-Area and Interarea Routes
To eliminate the single point of failure on area borders, at least two ABRs are used in most networks. As a result, ABR can learn about a specific subnet from internal routers and also from the other ABR. ABR can learn an intra-area route and also an interarea route for the same destination. Even though the interarea route could have lower cost to the specific subnet, the intra-area path is always the preferred choice.
In the example topology in Figure 3-23, ABR1 learns about network B directly from a router R4 and also from the ABR2. Even though the interarea path has a cost of 16, the intra-area path with a total cost of 21 is selected as the best path.
)
Figure 3-23 Selecting Between Intra-Area and Interarea Routes