This chapter examines the Open Shortest Path First (OSPF) routing protocol, which is one of the most commonly used interior gateway protocols in IP networking. OSPF is an open-standard protocol based primarily on RFC 2328. OSPF is a fairly complex protocol made up of several protocol handshakes, database advertisements, and packet types. This chapter describes basic configuration and verification of OSPF, in both single and multiple areas, and explores OSPF configuration over specific network types. The chapter also covers configuration and verification of advanced OSPF features, including passive interface, default routes, summarization, virtual links, changing the cost metric, and special area types. The chapter concludes with a discussion of OSPF authentication configuration and verification.
Understanding OSPF Terminology and Operation
This section introduces the major characteristics of the OSPF routing protocol, including a description of link-state routing protocols, area structures, link-state adjacencies, shortest path first (SPF) metric calculations, and link-state data structures.
Link-State Routing Protocols
The need to overcome the limitations of distance vector routing protocols led to the development of link-state routing protocols. Link-state routing protocols have the following characteristics:
-
They respond quickly to network changes.
-
They send triggered updates when a network change occurs.
-
They send periodic updates, known as link-state refresh, at long time intervals, such as every 30 minutes.
Link-state routing protocols generate routing updates only when a change occurs in the network topology. When a link changes state, the device that detected the change creates a link-state advertisement (LSA) concerning that link, as shown in Figure 3-1. The LSA propagates to all neighboring devices using a special multicast address. Each routing device stores the LSA, forwards the LSA to all neighboring devices (within an area; areas are described in the next section, “OSPF Area Structure”) and updates its link-state database (LSDB). This flooding of the LSA ensures that all routing devices can update their databases and then update their routing tables to reflect the new topology. As shown in Figure 3-1, the LSDB is used to calculate the best paths through the network. Link-state routers find the best paths to a destination by applying Dijkstra’s algorithm, also known as SPF, against the LSDB to build the SPF tree. Each router selects the best paths from their SPF tree and places them in their routing table.
OSPF and Integrated Intermediate System-to-Intermediate System (IS-IS) are classified as link-state routing protocols because of the manner in which they distribute routing information and calculate routes.
Routers running link-state routing protocols collect routing information from all other routers in the network (or from within a defined area of the network), and then each router independently calculates its best paths to all destinations in the network, using Dijkstra’s (SPF) algorithm. Incorrect information from any particular router is less likely to cause confusion because each router maintains its own view of the network.
For all the routers in the network to make consistent routing decisions, each link-state router must keep a record of the following information:
-
Its immediate neighbor routers— If the router loses contact with a neighbor router, within a few seconds it invalidates all paths through that router and recalculates its paths through the network. For OSPF, adjacency information about neighbors is stored in the OSPF neighbor table, also known as an adjacency database.
-
All the other routers in the network, or in its area of the network, and their attached networks— The router recognizes other routers and networks through LSAs, which are flooded through the network. LSAs are stored in a topology table or database (which is also called an LSDB).
-
The best paths to each destination— Each router independently calculates the best paths to each destination in the network using Dijkstra’s (SPF) algorithm. All paths are kept in the LSDB. The best paths are then offered to the routing table (also called the forwarding database). Packets arriving at the router are forwarded based on the information held in the routing table.
| Note | You might encounter different terminology for the various OSPF tables, as follows: -
OSPF neighbor table = adjacency database -
OSPF topology table = OSPF topology database = LSDB -
Routing table = forwarding database
|
The memory resources required to maintain these tables can be a drawback to link-state protocols. However, because the topology table (LSDB) is identical in all OSPF routers in an area and contains full information about all the routers and links in an area, each router can independently select a loop-free and efficient path, based on cost (as described in the “OSPF Metric Calculation” section, later in this chapter), to reach every network in the area. This benefit overcomes the “routing by rumor” limitations of distance vector routing.
Recall that routers running distance vector routing protocols rely on routing decisions from their neighbors. Individual routers do not have the full picture of the network topology. In comparison, each router running a link-state routing protocol has the full picture of the network topology and can independently make a decision based on an accurate picture of the network topology.
OSPF Area Structure
In small networks, the web of router links is not complex, and paths to individual destinations are easily deduced. However, in large networks, the resulting web is highly complex, and the number of potential paths to each destination is large. Therefore, the Dijkstra calculations comparing all of these possible routes can be very complex and can take significant time, resulting in issues such as those shown in Figure 3-2.
If an area becomes too big, the following issues need to be addressed:
-
Frequent SPF algorithm calculations— In a large network, changes are inevitable, so the routers spend many CPU cycles recalculating the SPF algorithm and updating the routing table.
-
Large routing table— OSPF does not perform route summarization by default. If the routes are not summarized, the routing table can become very large, depending on the size of the network.
-
Large LSDB— Because the LSDB covers the topology of the entire network, each router must maintain an entry for every network in the area, even if not every route is selected for the routing table.
Link-state routing protocols usually reduce the size of the Dijkstra calculations by partitioning the network into areas, as shown in Figure 3-3. The number of routers in an area and the number of LSAs that flood only within the area are smaller, which means that the LSDB or topology database for an area is small. Consequently, the Dijkstra calculation is easier and takes less time. Interarea routing still occurs, but many of the internal routing operations, such as SPF calculations, can remain within individual areas. For example, if area 1 is having problems with a link going up and down, routers in other areas do not need to continually run their SPF calculation, because they can be isolated from the problem in area 1.
Assuming a proper IP addressing hierarchy and proper OSPF configuration is in place, using multiple OSPF areas has several important advantages:
-
Reduced frequency of SPF calculations— Because detailed route information exists within each area, it is not necessary to flood all link-state changes to all other areas. Therefore, only routers that are affected by the change need to recalculate the SPF algorithm and the impact of the change is localized within the area.
-
Smaller routing tables— With multiple areas, detailed route entries for specific networks within an area can remain in the area. Instead of advertising these explicit routes outside the area, routers can be configured to summarize the routes into one or more summary addresses. Advertising these summaries reduces the number of LSAs propagated between areas but keeps all networks reachable.
-
Reduced LSU overhead— LSUs contain a variety of LSA types, including link-state and summary information. Rather than send an LSU about each network within an area, a router can advertise a single summarized route or a small number of routes between areas, thereby reducing the overhead associated with LSUs when they cross areas.
OSPF uses a two-layer area hierarchy:
-
Backbone area— An OSPF area whose primary function is the fast and efficient movement of IP packets. Backbone areas interconnect with other OSPF area types. Generally, end users are not found within a backbone area. The backbone area is also called OSPF area 0. Hierarchical networking defines area 0 as the core to which all other areas directly connect.
| Note | In some Cisco documentation, you will see the backbone area referred to as a transit area. However, in the OSPF RFC, a transit area is related to virtual links, as described in detail in the “OSPF Virtual Links” section, later in this chapter. |
-
Regular (nonbackbone) area— An OSPF area whose primary function is to connect users and resources. Regular areas (also called normal areas) are usually set up along functional or geographic groupings. By default, a regular area does not allow traffic from another area to use its links to reach other areas. By default, all traffic from other areas must cross backbone area 0. Regular areas can have several subtypes, including standard area, stub area, totally stubby area, not-so-stubby area (NSSA), and totally stubby NSSA. The “Configuring OSPF Special Area Types” section, later in this chapter, discusses area types in further detail.
| Note | “Totally stubby NSSA” are also sometimes referred to as “totally NSSA” or “totally stub NSSA.” Consider all of these terms to be synonyms. |
OSPF forces this rigid two-layer area hierarchy. The network’s underlying physical connectivity must map to the two-layer area structure, with all nonbackbone areas attaching directly to area 0.
OSPF Areas
In link-state routing protocols, all routers must keep a copy of the LSDB. The more OSPF routers that exist (and the more links on those routers), the larger the LSDB. It can be advantageous to have all information in all routers, but this approach does not scale to large network sizes. The area concept is a compromise. Routers inside an area maintain detailed information about the links and routers located within that area. OSPF can be configured so that only general or summary information about routers and links in other areas is maintained.
When OSPF is configured properly and a router or link fails, that information is flooded along adjacencies to only routers in the local area. Routers outside the area do not receive this information. By maintaining a hierarchical structure and limiting the number of routers in an area, an OSPF autonomous system (AS) can scale to very large sizes.
As mentioned, OSPF areas require a hierarchical structure, meaning that all areas must connect directly to area 0. In Figure 3-4, notice that links between area 1 routers and area 2 routers are not allowed. All interarea traffic must pass through the backbone area 0. The optimal number of routers per area varies based on factors such as network stability, but in the “Designing Large Scale IP Internetworks” document, Cisco recommends the following guidelines:
These values are recommended to ensure that OSPF calculations do not overwhelm the routers. Of course, the network design and link stability can also affect the load on the routers.
| Note | The “Designing Large Scale IP Internetworks” document is part of the Internetworking Design Guide written in the 1990s. There are large networks today in which the design exceeds these guidelines. However, this document is referenced by Cisco and therefore is included here. |
Area Terminology
OSPF routers of different types control the traffic that goes in and out of areas. The following are the four router types, as shown in Figure 3-4:
-
Internal router— Routers that have all of their interfaces in the same area. All routers within the same area have identical LSDBs.
-
Backbone router— Routers that sit in the perimeter of the backbone area 0 and that have at least one interface connected to area 0. Backbone routers maintain OSPF routing information using the same procedures and algorithms as internal routers.
-
Area Border Router (ABR)— Routers that have interfaces attached to multiple areas, maintain separate LSDBs for each area to which they connect, and route traffic destined for or arriving from other areas. ABRs connect area 0 to a nonbackbone area and are exit points for the area, which means that routing information destined for another area can get there only via the ABR of the local area. ABRs distribute this routing information into the backbone. The backbone routers then forward the information to the other ABRs. ABRs are the only point where area address summarization can be configured (to summarize the routing information from the LSDBs of their attached areas). ABRs separate LSA flooding zones, and may function as the source of default routes. An area can have one or more ABRs.
The ideal design is to have each ABR connected to two areas only, the backbone and another area. As mentioned, the recommended upper limit is three areas.
-
Autonomous System Boundary Router (ASBR)— Routers that have at least one interface attached to a different routing domain (such as another OSPF autonomous system or a domain using the Enhanced Interior Gateway Protocol [EIGRP]). An OSPF autonomous system consists of all the OSPF areas and the routers within them. ASBRs can redistribute external routes into the OSPF domain and vice versa.
| Note | Redistribution is defined as the capability of boundary routers connecting different routing domains to exchange and advertise routing information between those routing domains. Redistribution is covered in Chapter 4, “Manipulating Routing Updates.” |
A router can be more than one router type. For example, if a router interconnects to area 0 and area 1, and to a non-OSPF network, it is both an ABR and an ASBR.
A router has a separate LSDB for each area to which it connects. Therefore, an ABR will have one LSDB for area 0 and another LSDB for the other area in which it participates. Two routers belonging to the same area maintain identical LSDBs for that area.
An LSDB is synchronized between pairs of adjacent routers, as described in the next section.
OSPF Adjacencies
A router running a link-state routing protocol must first establish neighbor adjacencies, by exchanging hello packets with the neighboring routers, as shown in Figure 3-5. In general, routers establish adjacencies as follows:
-
The router sends and receives hello packets to and from its neighboring routers. The destination address is typically a multicast address.
-
The routers exchange hello packets subject to protocol-specific parameters, such as checking whether the neighbor is in the same area, using the same hello interval, and so on. Routers declare the neighbor up when the exchange is complete.
-
After two routers establish neighbor adjacency using hello packets, they synchronize their LSDBs by exchanging LSAs and confirming the receipt of LSAs from the adjacent router. The two neighbor routers now recognize that they have synchronized their LSDBs with each other. For OSPF, this means that the routers are now in full adjacency state with each other.
-
If necessary, the routers forward any new LSAs to other neighboring routers, ensuring complete synchronization of link-state information inside the area.
The two OSPF routers on a point-to-point serial link, usually encapsulated in High-Level Data Link Control (HDLC) or Point-to-Point Protocol (PPP), form a full adjacency with each other.
However, OSPF routers on broadcast networks, such as LAN links, elect one router as the designated router (DR) and another as the backup designated router (BDR). All other routers on the LAN form full adjacencies with these two routers and pass LSAs only to them. The DR forwards updates received from one neighbor on the LAN to all other neighbors on that same LAN. One of the main functions of a DR is to ensure that all the routers on the same LAN have an identical LSDB. Thus, on broadcast networks, an LSDB is synchronized between a DROTHER (a router that is not a DR or a BDR) and its DR and BDR.
The DR passes its LSDB to any new routers that join that LAN. Having all the routers on that LAN pass the same information to the new router is inefficient, so the one DR router represents the other routers to a new router on the LAN or to other routers in the area.
Routers on the LAN also maintain a partial-neighbor relationship, called a two-way adjacency state, with the other routers on the LAN that are not the DR or BDR, the DROTHERs. For example, if in Figure 3-5, Router A is the DR and Router B is the BDR, Router C will form a full adjacency with both Routers A and B, and a two-way adjacency with Routers D and E.
It is important to note that the DR concept is at the link level. In a multiaccess broadcast environment, each network segment has its own DR and BDR. For example, a router connected to multiple multiaccess broadcast networks can be a DR on one segment and a DROTHER on another segment.
| Note | LSAs are also called link-state protocol data units (PDUs). |
LSAs report the state of routers and the links between routers—hence the term link state. Thus, link-state information must be synchronized between routers. To accomplish this, LSAs have the following characteristics:
-
LSAs are reliable. There is a method for acknowledging their delivery.
-
LSAs are flooded throughout the area (or throughout the domain if there is only one area).
-
LSAs have a sequence number and a set lifetime, so each router recognizes that it has the most current version of the LSA.
-
LSAs are periodically refreshed to confirm topology information before they age out of the LSDB.
Only by reliably flooding link-state information can every router in the area or domain ensure that it has the latest, most accurate view of the network. Only then can the router make reliable routing decisions that are consistent with the decisions of other routers in the network.
OSPF Metric Calculation
Edsger Dijkstra designed the mathematical algorithm used by link-state routing protocols for calculating the best paths through complex networks. By assigning a cost to each link in the network, and by placing the specific node at the root of a tree and summing the costs toward each given destination, the branches of the tree can be calculated to determine the best path to each destination. The best paths are offered to the forwarding database (the routing table).
For OSPF, the default behavior on Cisco routers is that the interface cost is calculated based on its configured bandwidth. The higher the bandwidth, the lower the cost. The default OSPF cost on Cisco routers is calculated using the formula (100) / (bandwidth in megabits per second [Mbps]). This formula can also be written as (108) / (bandwidth in bps).
| Note | The OSPF RFC 2328 does not specify what the link cost should be, but on Cisco routers it defaults to being inversely proportional to the link’s bandwidth. |
If the link bandwidth is changed, the OSPF cost will change. Only one cost can be assigned per interface. It is advertised as the link cost in the router link advertisements. Default OSPF costs are as follows:
-
56-kbps serial link—Default cost is 1785.
-
64-kbps serial link—Default cost is 1562.
-
T1 (1.544-Mbps serial link)—Default cost is 64.
-
E1 (2.048-Mbps serial link)—Default cost is 48.
-
Ethernet—Default cost is 10.
-
Fast Ethernet—Default cost is 1.
-
FDDI—Default cost is 1.
-
ATM—Default cost is 1.
You can also manually define an OSPF cost for each interface, which overrides the default cost value (as described in more detail in the “Changing the Cost Metric” section, later in this chapter).
Figure 3-6 is an example of a Dijkstra calculation. The following occurs:
-
Router H advertises its presence to Router E. Router E passes Router H’s and its own advertisements to its neighbors (Routers C and G). Router G passes these and its own advertisements to D, and so on.
-
These LSAs follow the split-horizon rule, which dictates that a router should never advertise an LSA to the router from which it came. In this example, Router E does not advertise Router H’s LSAs back to Router H.
-
Router X has four neighbor routers: A, B, C, and D. From these routers, it receives the LSAs from all other routers in the network. From these LSAs, it can also deduce the links between all routers and draw the web of routers shown in Figure 3-6.
-
Each Fast Ethernet link in Figure 3-6 is assigned an OSPF cost of 1. By summing the costs to each destination, the router can deduce the best path to each destination.
-
The right side of Figure 3-6 shows the resulting best paths (the SPF tree) from Router X. From these best paths, shown with solid lines, routes to destination networks attached to each router are offered to the routing table; for each route, the next-hop address is the appropriate neighboring router (A, B, C, or D).
Link-State Data Structures
Each LSA entry has its own aging timer, which the Link-State Age field carries. After a default of 30 minutes (expressed in seconds in the Link-State Age field), the router that originated the entry resends the LSA, with a higher sequence number, in a link-state update (LSU), to verify that the link is still active. If the LSA were to reach its maximum age (maxage) of 60 minutes, it would be discarded. An LSU can contain one or more LSAs. This LSA validation method saves on bandwidth compared to distance vector routers, which send their entire routing table at short, periodic intervals.
As shown in Figure 3-7, when each router receives the LSU, it does the following:
-
If the LSA entry does not already exist, the router adds the entry to its LSDB, sends back a link-state acknowledgment (LSAck), floods the information to other routers, runs SPF, and updates its routing table.
-
If the entry already exists and the received LSA has the same sequence number, the router ignores the LSA entry.
-
If the entry already exists but the LSA includes newer information (it has a higher sequence number), the router adds the entry to its LSDB, sends back an LSAck, floods the information to other routers, runs SPF, and updates its routing table.
-
If the entry already exists but the LSA includes older information, it sends an LSU to the sender with its newer information.
OSPF Packets
OSPF performs several functions, including the following:
-
Neighbor discovery, to form adjacencies
-
Flooding link-state information, to facilitate LSDBs being built in each router
-
Running SPF to calculate the shortest path to all known destinations
-
Populating the routing table with the best routes to all known destinations
Changes might occur in the state of the links after the routing table is initially populated. OSPF detects these changes and responds by flooding the information about the changes within areas, and possibly to other areas, to maintain the LSDBs in all neighboring routers.
This section describes the five OSPF packet types, listed in Table 3-1, and explains where and how these packets interact to build OSPF neighbor adjacencies and maintain the OSPF topology database.
Table 3-1: OSPF Packets
Open table as spreadsheet | Type | Packet Name | Description |
| 1 | Hello | Discovers neighbors and builds adjacencies between them |
| 2 | Database description (DBD) | Checks for database synchronization between routers |
| 3 | Link-state request (LSR) | Requests specific link-state records from another router |
| 4 | LSU | Sends specifically requested link-state records |
| 5 | LSAck | Acknowledges the other packet types |
All five OSPF packets are encapsulated directly in an IP payload, as shown in Figure 3-8. The OSPF packet does not use Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). OSPF requires a reliable packet transport scheme, and because TCP is not used, OSPF defines its own acknowledgment routine using an acknowledgment packet (OSPF packet type 5).
As shown in Figure 3-8, a protocol identifier of 89 in the IP header indicates an OSPF packet. Each OSPF packet begins with a header with the following fields:
-
Version Number— Set to 2 for OSPF Version 2, the current IPv4 version of OSPF. (OSPF Version 3 is used for IP version 6 [IPv6], as described in Chapter 8, “Implementing IPv6 in an Enterprise Network.”)
-
Type— Differentiates the five OSPF packet types.
-
Packet Length— The length of the OSPF packet in bytes.
-
Router ID— Defines which router is the packet’s source.
-
Area ID— Defines the area in which the packet originated.
-
Checksum— Used for packet header error detection to ensure that the OSPF packet was not corrupted during transmission.
-
Authentication Type— An option in OSPF that describes either no authentication, clear-text passwords, or encrypted message digest 5 (MD5) for router authentication.
-
Authentication— Used with authentication type.
| Note | OSPF authentication is covered in the “Configuring and Verifying OSPF Authentication” section, later in this chapter. |
-
Data— Contains different information, depending on the OSPF packet type:
-
For the hello packet—Contains a list of known neighbors.
-
For the DBD packet—Contains a summary of the LSDB, which includes all known router IDs and their last sequence number, among several other fields.
-
For the LSR packet—Contains the type of LSU needed and the router ID of the router that has the needed LSU.
-
For the LSU packet—Contains the full LSA entries. Multiple LSA entries can fit in one OSPF update packet.
-
For the LSAck packet—This data field is empty.
Establishing OSPF Neighbor Adjacencies: Hello
OSPF routing depends on the status of a link between two routers. The Hello protocol establishes and maintains neighbor relationships by ensuring bidirectional (two-way) communication between neighbors. Bidirectional communication occurs when a router sees itself listed in the hello packet received from a neighbor. Neighbor OSPF routers must recognize each other on the network before they can share routing information.
Each interface participating in OSPF uses the IP multicast address 224.0.0.5 to periodically send hello packets. As shown in Figure 3-9, a hello packet contains the following information:
-
Router ID— A 32-bit number that uniquely identifies the router. The highest IP address on an active interface is chosen by default unless a loopback interface address exists or the router ID is manually configured (this process is described later, in the “OSPF Router ID” section). For example, IP address 172.16.12.1 would be chosen over 172.16.1.1. This router ID is important in establishing neighbor relationships and coordinating LSU exchanges. The router ID is also used to break ties during the DR and BDR selection processes if the OSPF priority values are equal (as described in the “Electing a DR and BDR and Setting Priority” section, later in this chapter).
-
Hello and dead intervals— The hello interval specifies how often, in seconds, a router sends hello packets (10 seconds is the default on multiaccess networks). The dead interval is the amount of time in seconds that a router waits to hear from a neighbor before declaring the neighbor router out of service (the dead interval is four times the hello interval by default). These timers must be the same on neighboring routers; otherwise an adjacency will not be established.
-
Neighbors— The Neighbors field lists the adjacent routers with which this router has established bidirectional communication. Bidirectional communication is indicated when the router sees itself listed in the Neighbors field of the hello packet from the neighbor.
-
Area ID— To communicate, two routers must share a common segment, and their interfaces must belong to the same OSPF area on that segment. These routers will all have the same link-state information for that area.
-
Router priority— An 8-bit number that indicates a router’s priority. Priority is used when selecting a DR and BDR.
-
DR and BDR IP addresses— If known, the IP addresses of the DR and BDR for the specific multiaccess network.
-
Authentication password— If router authentication is enabled, two routers must exchange the same password. Authentication is not required, but if it is enabled, all peer routers must have the same password.
-
Stub area flag— A stub area is a special area. The stub area technique reduces routing updates by replacing them with a default route. Two neighboring routers must agree on the stub area flag in the hello packets. The “Configuring OSPF Special Area Types” section, later in this chapter, describes stub areas in greater detail.
The following hello packet fields must match on neighboring routers for them to establish an adjacency:
-
Hello Interval
-
Dead Interval
-
Area ID
-
Authentication Password
-
Stub Area Flag
| Note | For routers to establish an adjacency on an interface, the primary IP addresses on the routers’ interfaces must also be on the same subnet with the same mask, and the interface maximum transmission unit (MTU) must match. |
Exchange Process and OSPF Neighbor Adjacency States
When routers running OSPF initialize, they first go through an exchange process, using the Hello protocol. In this process, the routers go through various states (detailed in the upcoming “OSPF Neighbor States” section), as shown in Figure 3-10 and described as follows:
-
Router A is enabled on the LAN; OSPF on the interface 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 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 running OSPF receive the hello packet from Router A and add Router A to their list of neighbors. These routers are now in the neighbor init state.
-
All routers that received the hello packet send a unicast reply packet to Router A with their corresponding information. The Neighbor field in the hello packet includes all other neighboring routers, including Router A.
-
When Router A receives these hello packets, it adds all the routers that have its router ID in their hello packets to its own neighbor relationship database. Router A is now in the neighbor two-way state with these routers. At this point, all routers that have each other in their lists of neighbors have established bidirectional communication.
Periodically (every 10 seconds by default on broadcast networks) the routers in a network exchange hello packets to ensure that communication is still working.
If the link is a broadcast network, such as an Ethernet LAN link, a DR and BDR must be selected for the link. The DR and BDR form adjacencies with all other routers on the LAN link. This process must occur before the routers can begin exchanging link-state information.
| Note | If a router joins a broadcast network in which there is already a DR and BDR, it will get to the neighbor two-way state with all routers, including the DR and BDR, and those that are DROTHER (not DR or BDR). The joining router will continue to form full bidirectional adjacencies only with the DR and BDR. |
After the DR and BDR have been selected, the routers are considered to be in the neighbor exstart state and they are ready to discover the link-state information about the internetwork and create their LSDBs. The process used to discover the network routes is the exchange protocol, which gets the neighbors to a full state of communication.
Although the hello packets (OSPF packet type 1) are used in the hello protocol, the other four types of OSPF packets are used during the process of exchanging and synchronizing LSDBs, as follows:
-
OSPF packet type 2 DBD— Used to describe the LSAs available in the LSDB
-
OSPF packet type 3 LSR— Used to request missing LSA information
-
OSPF packet type 4 LSU— Used to send complete LSAs
-
OSPF packet type 5 LSAck— Used to acknowledge LSUs, to ensure reliable transport and information exchange
OSPF type 4 and type 5 packets are sent to the OSPF multicast IP address, except when retransmitting, when sent across a virtual link, and on nonbroadcast networks. All other packets are sent to a unicast IP address.
The exchange protocol process is shown in Figure 3-11. The first step in this process is for the DR and BDR to establish adjacencies with each of the other routers. In this figure, assume that Router B has been selected as the DR for the link (the DR selection process is described in the “Electing a DR and BDR and Setting Priority” section, later in this chapter). The exchange protocol operates as follows:
-
In the neighbor exstart state, a master and slave relationship is created between each router and its adjacent DR and BDR. The router with the higher router ID acts as the master during the exchange process.
| Note | Recall that only the DR exchanges and synchronizes link-state information with the routers to which it has established adjacencies. Having the DR represent the network in this capacity reduces the amount of routing update traffic. |
-
The master and slave routers exchange one or more DBD packets (also called DDPs). The routers are in the neighbor exchange state.
A DBD includes information about the LSA entry header that appears in the router’s LSDB. The entries can be about a link or about a network. Each LSA entry header includes information about the link-state type, the address of the advertising router, the link’s cost, 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 the following actions, as shown in Figure 3-12:
Figure 3-12: Adding Link-State Entries.
-
It acknowledges the receipt of the DBD using the LSAck packet.
-
It compares the information it received with the information it has in its own LSDB. If the DBD has a more current link-state entry, the router sends an LSR to the other router. When routers are sending LSRs, they are in the neighbor 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 sends an LSAck.
-
The router adds the new link-state entries to its LSDB.
After all LSRs have been satisfied for a given router, the adjacent routers are considered synchronized and in a neighbor full state. When adjacent routers are in a full state, they do not repeat the exchange protocol unless the neighbor state changes from full.
The routers must be in a full state with a neighbor before they can route traffic on an interface. Remember, on a broadcast link, routers reach full neighbor state only with the DR and BDR, but they reach two-way state with other routers on the link. At this point, all the routers in the area should have identical LSDBs.
OSPF Neighbor States
The following is a brief summary of the states OSPF may pass through before becoming adjacent to (neighbors with) another router:
-
Down: No active neighbor detected.
-
Init: Hello packet received.
-
Two-way: Router sees its own router ID in a received hello packet.
-
ExStart: Master/slave roles determined.
-
Exchange: DBDs (summary of LSDB) sent.
-
Loading: Exchange of LSRs and LSUs, to populate LSDBs.
-
Full: Neighbors fully adjacent.
With neighbors on NBMA interfaces (such as Frame Relay), OSPF may also go into the Attempt state before the init state. The Attempt state indicates that no recent information has been received from the neighbor and that an effort will be made to contact the neighbor by sending hello packets at a reduced poll interval.
Maintaining Routing Information
In a link-state routing environment, it is very important for the link-state databases of all routers to stay synchronized. When a change in a link state occurs, as shown in Figure 3-13, the routers use a flooding process to notify the other routers in the network of the change. LSUs provide the mechanism for flooding LSAs. OSPF simplifies the synchronization issue by requiring only adjacent routers to remain synchronized.
| Note | Although it is not shown in Figure 3-13, all LSUs are acknowledged. |
In general, the following are the flooding process steps in a multiaccess network:
-
A router notices a change in a link state and multicasts an LSU packet, which includes the updated LSA entry with the sequence number incremented, to 224.0.0.6. This address goes to all OSPF DRs and BDRs. (On point-to-point links, the LSU is multicast to 224.0.0.5.) An LSU packet might contain several distinct LSAs.
-
The DR receives the LSU, processes it (as described earlier in Figure 3-7), acknowledges the receipt of the change and floods the LSU to other routers on the network using the OSPF multicast address 224.0.0.5. 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.
-
If a router is connected to other networks, it floods the LSU to those other networks by forwarding the LSU to the DR of the multiaccess network (or to the adjacent router if in a point-to-point network). That DR, in turn, multicasts the LSU to the other routers in the network.
-
The router updates its LSDB using the LSU that includes the changed LSA. It then recomputes the SPF algorithm against the updated database after a short delay and updates the routing table as necessary.
| Note | The timers throttle spf router configuration command, introduced in Cisco IOS Software Release 12.2(14)S, enables the OSPF throttling feature so that the SPF calculations can be potentially delayed during network instability. The “OSPF Shortest Path First Throttling” section of the Cisco IOS IP Routing Protocols Configuration Guide provides details about this command. This command replaces the timers spf command in earlier Cisco IOS Software releases. |
Notice in this process, OSPF uses two multicast addresses:
Summaries of individual link-state entries, not the complete link-state entries, are sent every 30 minutes to ensure LSDB synchronization. Each link-state entry has a timer to determine when the LSA refresh update must be sent. Each link-state entry also has a maximum age (maxage) of 60 minutes. As mentioned, if a link-state entry is not refreshed within 60 minutes, it is removed from the LSDB.
A change in the topology database is a necessary but not sufficient condition for SPF recalculation. SPF is triggered if any of the following occur:
-
The LSA’s Options field has changed.
-
The LSA’s LS age is set to maxage.
-
The Length field in the LSA header has changed.
-
The contents of the LSA (excluding the LSA header) have changed.
An SPF calculation is performed separately for each area in the topology database.
| Note | In a Cisco router, if a route already exists, the routing table is used at the same time the SPF algorithm is calculating. However, if the SPF is calculating a new route, the new route is used only after the SPF calculation is complete. |
OSPF Link-State Sequence Numbers
This section describes the combination of the maxage timer, the refresh timer, and the link-state sequence numbers, which help OSPF maintain a database of only the most recent link-state records.
An LSA is considered to be more recent if it has the following:
-
A higher sequence number
-
A higher checksum number (if the sequence numbers are equal)
-
An age equal to maxage (indicating the LSA is poisoned)
-
A significantly smaller (younger) LS age
The link-state sequence number field in an LSA header is 32 bits long. Beginning with the leftmost bit set, the first legal sequence number is 0x80000001, and the last number is 0x7FFFFFFF. The sequence number is used to detect old or redundant LSA records. The larger the number, the more recent the LSA.
To ensure an accurate database, OSPF floods (refreshes) each LSA every 30 minutes. This interval is called the LSRefreshTime. Each time a record is flooded, the sequence number is incremented by 1. When a router receives a new LSA update it resets the LSA record’s age. An LSA never remains in the database for longer than the maximum age of 1 hour without a refresh.
It is possible for an LSA to exist in the database for long periods of time, being refreshed every 30 minutes. At some point the sequence number needs to wrap back to the starting sequence number. When this process occurs, the existing LSA is prematurely aged out (the maxage timer is immediately set to 1 hour) and flushed. The LSA then restarts its sequencing at 0x80000001.
The partial output of the show ip ospf database command in Example 3-1 demonstrates how the LS age and LS sequence numbers are kept in the database. Every OSPF router announces a router LSA for those interfaces that it owns in an area. The link ID in the output is the router ID of the router that created the router LSA. The advertising router (shown as ADV Router in the output) is the router ID of the OSPF router that announced the router LSA. Generally, the link ID and advertising router for a router LSA are the same.
The first router LSA entry in the OSPF database shown in Example 3-1 indicates that the router LSA with link ID 192.168.1.67 has been updated eight times (because the sequence number is 0x80000008) and that the last update occurred 48 seconds ago (as indicated in the Age column).
Example 3-1: LSA Database Sequence Numbers and Maxage
RouterA#show ip ospf database
OSPF Router with ID (192.168.1.67) (Process ID 10)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
192.168.1.67 192.168.1.67 48 0x80000008 0xB112 2
192.168.2.130 192.168.2.130 212 0x80000006 0x3F44 2
Verifying Packet Flow
The debug ip ospf packet command is used to troubleshoot and verify that OSPF packets are flowing properly between two routers; Example 3-2 demonstrates output from this command. Notice that the output shows the fields in the OSPF header, but they are not described in any detail. Table 3-2 describes the OSPF packet header fields represented in this output.
Table 3-2: debug ip ospf packet Command
Open table as spreadsheet | Field | Description |
| v: | Identifies the version of OSPF; OSPFv2 in this example. |
| t: | Specifies the OSPF packet type: 1—Hello 2—DBD 3—LSR 4—LSU 5—LSAck This example has a Type 1 packet, a hello packet. |
| l: | Specifies the OSPF packet length in bytes; 48 in this example. |
| rid: | Displays the OSPF router ID; 10.0.0.12 in this example. |
| aid: | Shows the OSPF area ID; 0.0.0.1 in this example. |
| chk: | Displays the OSPF checksum; D882 in this example. |
| aut: | Provides the OSPF authentication type: 0—No authentication 1—Simple password 2—MD5 No authentication is used in this example. |
| auk: | Specifies the OSPF authentication key, if used. It is not used in this example. |
| keyid: | Displays the MD5 key ID; only used for MD5 authentication. It is not used in this example. |
| seq: | Provides the sequence number; only used for MD5 authentication. It is not used in this example. |
| from: | Interface from which this packet was received, S0/0/0.2 in this example. |
Example 3-2: Debug of a Single Packet
R1#debug ip ospf packet
OSPF packet debugging is on
R1#
*Apr 16 11:03:51.206: OSPF: rcv. v:2 t:1 l:48 rid:10.0.0.12
aid:0.0.0.1 chk:D882 aut:0 auk: from Serial0/0/0.2
1 comments
Thank you for sharing this.
Post a Comment