OSPF – OSPF LSAs and the Link State Database (LSDB) Part II

Network Link State Advertisements (Type 2)

OSPF uses the Network Link State Advertisement (Type 2 LSA) to advertise the routers on the multi-access segment. This LSA is generated by the DR and is flooded only within the area. Because the other non-DR/BDR routers do not establish adjacencies with each other, the Network LSA allows those routers to know about the other routers on the multi-access segment.

To view information specific to the Network LSAs, the show ip ospf database network [options] commands should be used. As stated earlier, being as specific when using the show ip ospf database command not only reduces the amount of information you have to parse through, it also indicates that you understand what you are looking for. The show ip ospf database network command on R3 shows the following:

From the output above, the Link State ID prints the interface address of the DR. This is the same address that is printed in the (Link ID) Designated Router address field in the Type 1 LSA for the transit network, as was shown in the previous section. The Advertising Router field contains the RID for the DR. The Attached Router field lists the router IDs of all routers connected or attached to the same multi-access network segment.

NOTE: The same information can be viewed using the show ip ospf database network adv-router 2.2.2.2command, which lists the Network LSAs advertised by the DR (R2) or the show ip ospf database network 10.0.1.2, which lists the Link State ID, which is also the physical address of the router as illustrated below:

Network Summary Link State Advertisements (Type 3)

The Network (Type 3) LSA is a summary of destinations outside of the local area, but within the OSPF domain. In other words, this LSA advertises inter-area routing information. The Network LSA does not carry any topological information. Instead, the only information contained in the LSA is an IP prefix. Type 3 LSAs are generated by ABRs and are flooded to all adjacent areas. By default, each Type 3 LSA matches a single Router or Network LSA on a one-for-one basis. In other words, a Type 3 exists for each individual Type 1 and Type 2 LSA. Special attention must be paid to how these LSAs are propagated in relation to the OSPF backbone. This propagation or flooding is performed as follows:

• Network Summary (Type 3) LSAs are advertised from a non-backbone area to the OSPF backbone for intra-area routes, i.e. for Type 1 and Type 2 LSAs

• Network Summary (Type 3) LSAs are advertised from the OSPF backbone to other non-backbone areas for both intra-area, i.e. area 0 Type 1 and Type 2 LSAs, and inter-area routes, i.e. for the Type 3 LSAs flooded into the backbone by other ABRs

The same network topology used in previous LSA examples and is again shown in Figure 3-17 will be used to reinforce the theoretical discussing pertaining to Type 3 LSAs in the network:

Fig. 3-17. Understanding OSPF LSAs

In Cisco IOS software, the show ip ospf database summary [options] command is used to view the Summary LSAs in the LSDB. If no options are specified the entire LSDB is printed as illustrated in the following output:

In the output above, we can see that a Network Summary 3 LSA is included in the LSDB for all inter-area routes in the network. These LSAs are generated by the ABR, which is R3 and are then flooded into area 2. The show ip ospf database summary command prints detailed information on each of the individual LSAs. In addition to other information, the show ip ospf database summary command prints the Link State ID for each LSA, the network mask, as well as the route metric which is the ABR lowest cost metric (best route) to the destination network and not the metric of the local router which receives the LSA. The output of this command is illustrated below:

NOTE: As can be seen in the output above, the metric for the 2.2.2.2 route, for example, is listed as 2. This is the metric to reach that subnet from R3 and not from R4.  R4 would calculate its metric to this same destination by adding that metric to the cost (metric) between itself and R4. Assuming a default OSPF cost of 64 for the link between R4 and R3, the route metric for 2.2.2.2 route would be calculated by adding 64 and 2, resulting in a metric of 66 as shown below:

The same would be applicable for the other entries in the LSDB. The route metric for 1.1.1.1 would be 64 + 66, which results in a metric of 130; while the route metric for 10.0.0.0 would be 64 + 65, which results in a metric of 129. This is reflected in the output below:

It is important to understand this concept when looking at the LSDB as it is often a source of confusion. OSPF metric calculation will be described in detail later in this chapter.

In a large multi-area OSPF network, this command prints a lot of information. Therefore, if you know exactly what you are looking for, information on specific Type 3 LSAs can be viewed by issuing the show ip ospf database summary [Link State ID] command as illustrated in the following output for the 172.16.1.0/24 link on router R1 as seen on router R4:

The next three Link State Advertisements, Type 4, Type 5, and Type 7, are used in external route calculation. Type 4 and Type 5 LSAs are described in the following section. Type 7 LSAs will be described later in this chapter when we discuss the different types of OSPF areas.

Network Summary Link State Advertisements (Type 4)

The Type 4 LSA describes information about an Autonomous System Boundary Router (ASBR).  This LSA contains the same packet format as the Type 3 LSA and performs the same basic functionality, with some notable differences. Like the Type 3 LSA, the Type 4 LSA is generated by the ABR. For both LSAs, the advertising router field contains the RID of the ABR that generated the summary LSA.

However, the Type 4 LSA is created by the ABR for each ASBR reachable by a Router LSA. The ABR then injects the Type 4 LSA into the appropriate area. This LSA provides reachability information to the ASBR itself. The key differences between the Type 3 and Type 4 LSAs that you should be familiar with are listed below in Table 3-2

Tab. 3-2. Type 3 and Type 4 Summary LSAs
Based on the topology illustrated in Figure 3-16, the current LSBD on R4 shows the Type 1 and Type 3 LSAs as illustrated in the previous examples. Keep in mind that no Type 2 LSAs exist because R4 is connected to R3 via a P2P link. Now, R1 will be configured as an ASBR by configuring a static route on the router and redistributing this information into OSPF. This configuration is implemented on R1 as follows:

NOTE: Route redistribution is described in detail later in this guide.

Because R1 is injecting external information into the OSPF domain, it automatically becomes an ASBR and a Type 4 LSA is generated by the ABR and flooded into their connected areas. Beginning with R3, the Type 4 LSA is generated by R2 (ABR) and advertised to this router. This entry is now present in the LSDB on R3 as illustrated in the following output:

In the output above, the Type 4 LSA flooded in area 0 contains the Link ID (router ID) of the ASBR, which is 1.1.1.1. This LSA is generated by R2, as specified in the ADV Router field. Because R3 is also an ASBR, it generates the Type 4 LSA for area 4 and changes the ADV Router field to itself (3.3.3.3). Detailed information on the Type 4 LSA can be viewed by issuing the show ip ospf database asbr-summary [Link State ID] command as follows:

On R4, the show ip ospf database asbr-summary command also lists the router ID of the ASBR (R1) but indicates that the LSA is generated by R3 (ABR) as illustrated below:

External Summary Link State Advertisements (Type 5)

The External Link State Advertisement is used to describe destinations that are external to the autonomous system. In other words, Type 5 LSAs provide the network information necessary to reach the external networks. In addition to external routes, the default route for an OSPF routing domain can also be injected as a Type 5 Link State Advertisement.

The External LSA has a domain-flooding scope. This means that the ABR no longer stops the flooding process, but instead continues it into its respective areas. The only areas that External LSAs are not flooded to are stub-type Areas. Stub-type Areas are special OSPF areas. These areas are described in detail in the following section. Before Type 5 LSAs are installed into the routing table, two conditions must be satisfied:

• The router calculating the Type 5 LSA must have a Type 4 LSA for the ASBR
• The router must know about the forwarding address contained in the Type 5 LSA

Without a Type 4 LSA in the LSDB, it is not possible for the router to calculate the route to the ASBR. As described in the previous section, the Type 4 LSA is generated by the ABR and advertises the route to the ASBR; however, it does not actually advertise the external routing information to the rest of the OSPF domain.

The Forwarding Address is a 4-byte field that is contained within the External 5 LSA. This field specifies the address to which data to the advertised external network should be forwarded. The default value contained in this field is 0.0.0.0, which means that traffic to the advertised external network should be forwarded to the ASBR. Continuing from the previous example, R4 received the Type 4 LSA from R3 when R1 was configured as an ASBR. The corresponding External LSA for the external route is therefore also included in the Link State Database on R4 as illustrated in the following output:

Detailed information about the Type 5 LSA can be viewed via the show ip ospf database external command. The output printed by this command is illustrated below:

Referencing the output shown above, the Link State type field indicates that this is an External (Type) 5 LSA. The Link State ID field contains the external network number. The Advertising Router field contains the router ID (RID) of the ASBR, which is R1. R4 is able to reach the ASBR because of the Type 4 LSA in the LSDB.

The Network Mask field contains the mask of the external network. Within the External LSA packet header, Bit E is used to specify the type of external metric. OSPF uses two types of external metric: Type 1 or Type 2. If this bit is set, the external metric is Type 2. If not set, this external metric is Type 1.  By default, this bit will always be set in Cisco IOS software and all external OSPF routes have a Type 2 metric.

The difference between Type 1 and Type 2 external metrics is that in a Type 1 metric, the OSPF metric and costs change at every hop in the network; however, with Type 2, the external metric does not change. External Type 1 routes consider both internal and external metrics (costs); whereas external Type 2 routes consider the external metric (costs). This will be described in detail again in the following chapter on route redistribution.

And finally, the Forward Address field contains all zeros which means traffic to the external network should be forwarded to the ASBR. There are, however, four reasons when this field will contain a non-zero value. These reasons are as follows:

• If the ASBRs next-hop interface network type is not P2P or point-to-multipoint
• If OSPF is enabled on the ASBRs next-hop interface
• If the next-hop interface of the ASBR falls into a defined OSPF network range
• If the ASBRs next-hop interface is not a passive OSPF interface

As an example of when a non-zero Forward Address would be shown, the static route that was previously configured on R1 is changed to point to the next hop address 172.16.1.254 off the Ethernet0/0 interface of R1 instead of the Null0 interface as illustrated in the following output:

Because the 172.16.1.0/24 subnet on R1 is already been advertised by OSPF, there is no need to configure anetwork statement for this subnet.  However, based on this configuration change, and because the next-hop interface of the ASBR falls into a defined OSPF network range, the Forward Address on the Type 5 LSA contains the next hop IP address and not the default all-zero value and illustrated below on R4:

Now that we have a solid understanding of the different types of LSAs, we will conclude this section by learning about how to protect the Link State Database.
Protecting the Link State Database

In very large networks, the LSDB may become very, very large. This large number of LSAs requires more router resources, such as memory and processing cycles to process. If these resources are heavily taxed, other router functions, such as the forwarding of data, may be affected. There are two ways the size of the LSDB may be controlled:

• Configuring stub area types, restricting the propagation of certain LSAs to those areas
• Restricting the number of non self-originated LSAs the router will store in the LSDB

NOTE: The operation and configuration of different stub OSPF area types will be described in detail in the following section. This will not be included in this section.

Regarding the second point made above, the max-lsa <maximum-number> [threshold-percentage] [warning-only] [ignore-time <minutes>] [ignore-count <count-number>] [reset-time <minutes>]router configuration command can be used to specify the maximum number of LSAs generated by other routers that the local router will keep in the LSDB.  The threshold-percentage allows you to specify a threshold, which once exceeded, will cause the router to generate and log a warning message.

By default, the router will generate and log a warning message at 75% of the value specified in the max-lsa <maximum-number> configuration. The warning-only keyword configures the router to log a warning message and take no further action. The ignore-time <minutes>keyword configures the router to ignore all neighbors for the configured interval. The default value for this keyword is five (5) minutes.

The ignore-count <count-number> keyword specifies the number of times the OSPF process can be placed into the ignore state. The default for this keyword is five (5) times. And finally, the reset-time <minutes> keyword specifies the time period after which the ignore count will be reset to zero (0). The default for this keyword is 10 times.

NOTE: You are not expected to perform any advanced OSPF configurations using the max-lsa command. However, it is important that you have a basic understanding of its functionality and what it is used for.  The following configuration example illustrates how to configure the router to store up to 100 LSAs from neighbors and generate a warning when received LSAs have reached 50% of this number:

This configuration is validated using the show ip ospf [process ID] command:

NOTE: The other variables that are configurable using the additional keywords supported by the max-lsa router configuration command are using their default values.