Foundation Topics
Understanding OSPF Fundamentals
Rarely is a name as descriptive as the one given to this protocol—Open Shortest Path First (OSPF). OSPF is an open standard, defined in detail in many RFCs, including RFC 2328. OSPF uses the SPF algorithm to compute the best path to destinations. OSPF builds loop-free paths that converge quickly, but it often requires more processor power and memory than distance vector routing protocols. OSPF can also be more complicated because there are many topology and configuration options to consider.
OSPF is designed to offer flexibility in network design and, as an open standard, support linking routers from various vendors.
This section describes OSPF operation with the assumption that you have some experience with OSPF. Many of the details specific to the underlying OSPF operation are omitted, to focus on the important concepts appropriate to an Exam Certification Guide.
OSPF Snapshot
A link-state routing protocol is a sophisticated routing protocol based on the Dijkstra Shortest Path First (SPF) algorithm. When compared to distance-vector routing, link-state routing processes more information locally to reduce network traffic, trading additional memory and processor time for less bandwidth consumption. Link-state routing protocols record all possible routes, and therefore avoid many of the techniques required by distance-vector protocols to avoid loops.
OSPF, in particular, is a link-state routing protocol used within an autonomous system. It has a number of advantages over distance-vector routing protocols, including the following:
OSPF is classless and allows summarization.
It converges very quickly.
OSPF is a standard, and ubiquitous support can be expected in a heterogeneous environment.
It conserves network bandwidth.
It uses multicasts instead of broadcasts.
It sends incremental change-based updates.
It uses cost as the metric.
Distance-vector routing protocols advertise routes to neighbors, but a link-state routing protocol advertises a list of its connections. When a link comes up or goes down, a link-state advertisement (LSA) is generated. In the context of link-state routing, a neighbor is simply a directly connected router, or a router on the opposing end of a WAN link, with the same network address (an exception to this is a virtual link, discussed in Chapter 7, "Using OSPF Across Multiple Areas"). LSAs are shared with neighbors and a topological database, also called a link-state database (LDSB) or topology table, is built. LSAs are marked with sequence numbers so that older or newer versions of an advertisement can be recognized; sequence numbers start at 0x8000 0001 and iterate to 0xFFFF FFFF before wrapping back around to 0x0000 00000. Eventually, every router in the same "area" has the same LSDB. Each router then processes this database using SPF and places the best routes into its routing table.
The topology database is the router view of the network within the area. It includes every OSPF router within the area and all the connected networks. This database is essentially a routing table—a routing table for which no path decisions have been made.
To view the current status of the link-state database, use the show ip opsf database command as shown in Example 5-1.
Example 5-1. The show ip ospf database Command Output
SanJose# show ip ospf database
OSPF Router with ID (140.100.32.10) (Process ID 100)
Router Link States (Area 3)
Link ID ADV Router Age Seq# Checksum Link count
140.100.17.131 140.100.17.131 471 0x80000008 0xA469 1
140.100.17.132 140.100.17.132 215 0x80000007 0xA467 1
140.100.17.194 140.100.17.194 1489 0x8000000B 0xFF16 1
140.100.23.1 140.100.23.1 505 0x80000006 0x56B3 1
140.100.32.10 140.100.32.10 512 0x8000000C 0x46BA 3
140.100.32.11 140.100.32.11 150 0x80000006 0x6A73 1
140.100.32.12 140.100.32.12 1135 0x80000002 0x8E30 1
Net Link States (Area 3)
Link ID ADV Router Age Seq# Checksum
140.100.17.130 140.100.23.1 220 0x80000007 0x3B42
140.100.17.194 140.100.17.194 1490 0x80000002 0x15C9
140.100.32.11 140.100.32.11 150 0x80000004 0x379E
|
To reiterate, the topology database is updated by the LSAs and each router within an area has exactly the same topology database. All routers must have the same view of the network; otherwise, routing loops or loss of connectivity will result.
As soon as a router realizes that there has been a change in the network topology, the router is responsible for informing the rest of the routers in the area. Typically, it will identify a change in the state of one of its links for one of the following reasons:
The router loses the physical or data-link layer connectivity on a connected network.
The router does not receive a predetermined number of consecutive OSPF hello messages.
The router receives an LSA update from an adjacent neighbor, informing it of the change in the network topology.
In any of these instances, the router will generate an LSA and flood it to all its neighbors with the following stipulations:
If the LSA is new, the route is added to the database, the route is flooded out other links so other routers are updated, and SPF is rerun.
If the sequence number is the same as the current entry in the topology table, the router ignores the advertisement.
If the sequence number is older, the router sends the newer copy (from memory) back to the advertiser to make sure that all neighbors have the latest LSA.
All OSPF operations center on populating and maintaining the following tables:
Neighbor table
Topology database
Routing table
It is useful now to take a step back and focus on the relationships between pairs of OSPF speakers.
Neighbors and Adjacencies
OSPF develops neighbor relationships with routers on the same link by exchanging hello messages (sometimes shortened to hellos). Upon initial exchange of hello messages, the routers add each other to their respective neighbor tables. A neighbor table is a list of connected OSPF speakers (devices running OSPF). OSPF speakers send multicast hellos with destination address 224.0.0.5 on all OSPF-enabled interfaces. OSPF sends out hello packets every 10 seconds on a broadcast link and every 30 seconds on a nonbroadcast link. The contents of a hello message are shown in Table 5-2.
| Value | Description |
|---|---|
| Router ID | A 32-bit number that is unique to this router. |
| Hello and dead interval | Period of time between hellos and the timeout. |
| Neighbor list | List of neighbor Router IDs. |
| Area ID | Area number. |
| Priority | Highest priority is elected the designated router. |
| DR and BDR | IP address of designated routers. |
| Authentication | Password, if enabled. |
| Stub Area Flag | TRUE if this is a stub area. |
After two routers complete an initial exchange based on hellos, they go through a process of exchanging information about the network. After the routers have synchronized their information, they are adjacent. Figure 5-1 outlines the formal states that a neighbor relationship transitions through in the process of forming a "full" adjacency. Once full state is reached, tables must be kept up-to-date. LSAs are re-sent whenever there is a change, or every 30 minutes to keep them "fresh."
Figure 5-1. The States of Updating the Routers About the Network
The following list describes each possible state of a neighbor relationship:
Down— This is the first OSPF neighbor state. It means that no information (hellos) has been received from this neighbor.
Attempt— This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor from which hellos have not been received within the dead interval.
Init— This state indicates that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet.
2-Way— This state indicates that bi-directional communication has been established between two routers.
Exstart— Once the DR and BDR are elected, the actual process of exchanging link-state information can start between the routers and their DR and BDR.
Exchange— In the exchange state, OSPF routers exchange database descriptor (DBD) packets.
Loading— In this state, the actual exchange of link-state information occurs.
Full— In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the router databases are fully synchronized.
Hellos continue to be sent periodically and the adjacency is maintained as long as hellos are exchanged. Missing hello messages result in a router declaring the adjacency dead.
As soon as OSPF identifies a problem, it modifies its LSAs accordingly and sends the updated LSAs to the remaining neighbors (with full adjacencies). Being event-driven, this LSA process intrinsically improves convergence time and reduces the amount of information that needs to be sent across the network.
One key piece of information exchanged in LSAs is OSPF metric information.
Many OSPF vendor implementations assign each link a cost of 10. The Cisco implementation makes cost inversely proportional to 100 Mbps, as follows:
An administrator can override this default cost. Typically, this is done for compatibility with other OSPF speakers or because some links are faster than 100 Mbps.
Sometimes the metric is equivalent for multiple paths to a destination. In this case, OSPF will load balance over each of the equivalent interfaces. Cisco routers will automatically perform equal-cost load balancing for up to four paths, but this parameter can be increased by configuration to as many as sixteen paths.
The cost is applied to the outgoing interface. The routing process will select the lowest cumulative cost to a remote network.
Designated Router and Backup Designated Router
If routers are connected to a broadcast segment (for example, when several routers in one VLAN are on the same switch) then one router on the segment is assigned the duty of maintaining adjacencies with all other segment routers. This job is known as the designated router (DR) and the responsible router is selected using information in hello messages. For redundancy, a backup designated router (BDR) is also elected.
DRs are created on multiaccess links because the number of adjacencies grows at a quadratic rate. For a network of n routers, the number of adjacencies required would be
Two routers require the following adjacencies:
Four routers require the following adjacencies:
Ten routers require the following adjacencies:
As you can see, maintaining the segment consumes increasingly more bandwidth and processing as the number of routing devices increases.
The purpose of a DR is to be the one router to which all other routers are adjacent. Using a DR reduces the number of adjacencies that consume bandwidth and processing to n – 1. Yes, larger networks still involve more processing, but with a DR, the adjacencies scale with the network. This growth rate is shown in Table 5-3 and illustrated in Figure 5-2.
| Routers | Adjacencies Needed Without a DR | Adjacencies Needed with a DR Only | Adjacencies Needed Using a DR and BDR |
|---|---|---|---|
| 1 | 0 | 0 | 1 |
| 2 | 1 | 1 | 3 |
| 3 | 3 | 2 | 5 |
| 4 | 6 | 3 | 7 |
| 5 | 10 | 4 | 9 |
| 6 | 15 | 5 | 11 |
| 7 | 21 | 6 | 13 |
| 8 | 28 | 7 | 15 |
| 9 | 36 | 8 | 17 |
| 10 | 45 | 9 | 19 |
Figure 5-2. Adjacencies from Table 5-3
The role of the DR is to receive updates and distribute them to each segment router, making sure that each router acknowledges receipt and has a synchronized copy of the LSDB. Routers advertise changes to the "AllDRs" multicast address, 224.0.0.6. The DRs then advertise the LSA using the "AllSPF" multicast address, 224.0.0.5. Each router then acknowledges receipt.
The BDR listens passively to this exchange and maintains a relationship with all the routers. If the DR stops producing hellos, the BDR promotes itself and assumes that role.
Note that DRs and BDRs are only useful on multiaccess links because they reduce adjacencies. The concept of a DR is not used on point-to-point links because there can be only one adjacency.
Note
DRs are elected on point-to-point Ethernet links, which are very common in modern networks. Because the DR and BDR are not necessary on a point-to-point Ethernet link, some current design guides recommend changing the Ethernet interfaces to point-to-point mode.
If a DR fails, the BDR is promoted. The BDR is elected on the basis of highest OSPF priority and ties are broken in favor of the highest IP address. The default priority is 1 and a priority of 0 prevents a router from being elected. Priority can be set from 0–255; to change the priority from its default for a particular interface, use the following command:
Router(config-if)# ip ospf priority number
DRs are stable—even if a better candidate joins the network the DR will not change.
To put this description in context, consider the network shown in Figure 5-3. There are five routers, A through E, with priorities ranging from zero to three. Intuitively, you might expect that A would be the DR, that B would be the BDR, and that E would never let itself be elected. Generally, this is true, but it neglects some important details.
Figure 5-3. Example OSPF Segment, with Priorities
Imagine that Router C starts first. Router C sends out hellos and waits the dead time for a response. Receiving no response, Router C conducts an election and becomes the BDR. Because there is no DR, Router C promotes itself to DR. Next, suppose that Router E starts. Router E has a priority of zero, so it will not become the BDR. Router B starts third and is elected BDR. Router A and Router D start last.
In this scenario, Router C is the DR and Router B is the BDR—not what we expected. This is because designated routers do not preempt—once elected they serve until they are rebooted. If Router C restarts, Router B promotes itself to DR and Router A is elected BDR while Router C is down. If Router B goes down, Router A promotes itself and elects Router C or Router D (whichever has the highest IP address). Finally, when the BDR is rebooted, Router B wins the election for BDR.
Note
In addition to rebooting, clearing the OSPF process using the Privilege EXEC mode command clear ip ospf process * on the DR will force a DR/BDR election.
Multiple Areas
An OSPF area is a logical grouping of routers that are running OSPF with identical topological databases. An area is a subdivision of the OSPF routing domain. Each area runs SPF separately and summaries are passed between each area.
This section begins with a description of the problems associated with single-area networks, and then discusses how multiple-area structures overcome problems specific to a large single area.
Problems with OSPF in a Single Area
Consider a growing OSPF network with a single area. Several problems emerge in relation to capacity:
The SPF algorithm runs more frequently. The larger the network, the greater the probability of a network change and a recalculation of the entire area. Each recalculation in a large network takes longer and involves more work than recalculations in a small area.
The larger the area, the greater the size of the routing table. The routing table is not sent out wholesale, as in a distance vector routing protocol. However, the greater the size of the table, the longer each lookup becomes. The memory requirements on the router also increase as the size of the table increases.
In a large network, the topological database increases in size and eventually becomes unmanageable. The topology table is exchanged between adjacent routers at least every 30 minutes.
As the various databases increase in size and the calculations increase in frequency, the CPU utilization increases while the available memory decreases. This can affect network latency or cause link congestion, resulting in various additional problems, such as convergence time, loss of connectivity, loss of packets, and system hangs.
Area Structure
OSPF creates a two-level hierarchy of areas. Area zero (also called the backbone area or transit area) is always the central area; all other areas attach to area zero. Area zero forms the top level in the hierarchy and the remaining areas form the bottom level of the hierarchy. This hierarchical design supports summarization and minimizes routing table entries.
Routers in area zero are called backbone routers. Routers that link area zero and another area are called Area Border Routers (ABR). OSPF routers that redistribute routing information from another routing protocol are called Autonomous System Boundary Routers (ASBR).
OSPF Packet Types
As OSPF link-state information is shared between areas, an intricate set of mechanisms is followed, relying on a number of different OSPF packet types. All OSPF traffic is transmitted inside IP packets. Receivers recognize OSPF traffic because it is marked as IP protocol 89.
OSPF includes five packet types:
Hello packets— Establish communication with directly attached neighbors.
Database Descriptor (DBD)— Sends a list of router IDs from whom the router has an LSA and the current sequence number. This information is used to compare information about the network.
Link State Requests (LSR)— Follow DBDs to ask for any missing LSAs.
Link State update (LSU)— Replies to a link-state request with the requested data.
Link-state acknowledgements (LSAck)— Confirm receipt of link-state information.
All OSPF packets have a common format that contains the following nine fields:
Version— All packets are assumed to be version 2 in this chapter. OSPF version 3 is discussed in the context of IPv6 in Part VIII of this book.
Type— There are five packet types, numbered 1 to 5.
Packet Length— The length in bytes.
Router ID— 32-bit identifier for the router.
Area ID— 32-bit identifier for the area.
Checksum— Standard 16-bit checksum.
Authentication Type— OSPFv2 supports three authentication methods:
- no authentication
- plaintext passwords
- MD5 hashes
Authentication Data— 64-bit data, either empty, with a plain-text word, or with a "message digest" of a shared secret.
Data— Values being communicated.
Configuring OSPF in a Single Area
This section examines the configuration of a Cisco router for OSPF within a single area. The commands are few in number and relatively simple; the implications of the commands on the network are somewhat more complicated.
Required Commands for Configuring OSPF Within a Single Area
In this section, you learn to configure an internal OSPF router. An internal router is one in which all interfaces lie within a single area. The sole OSPF function of an internal router is to route within the area.
The router needs to understand how to participate in the OSPF network, as defined by the following parameters:
OSPF process— Declare an OSPF process.
Participating interfaces— Identify the interfaces to be used by OSPF.
Area— Define area per interface. This discussion assumes that all active interfaces are in the same area.
Router ID— A unique 32-bit ID, usually drawn from an interface IP address.
The following subsections describe the commands required for configuring OSPF on a single internal router.
Enabling the OSPF Routing Protocol
To configure OSPF as the routing protocol, use the following command:
Router(config)# router ospf process-number
Here, process-number is not globally significant. It is possible to have more than one process running on a router (although that would be an unusual configuration) and two OSPF processes could route for different parts of the network. The process number does not have to be the same on every router in the area.
The OSPF network Command
Once OSPF is turned on, you must define the interfaces that are to participate in OSPF and the area that they reside in by using the following command:
Router(config-router)# network network-number wildcard-mask area area-number
Caution
Be careful with this command. It is the cause of many errors in configuration, normally due to a misapplication of the wildcard-mask parameter, either including too many or too few interfaces in a particular OSPF area.
Like RIP, the network command identifies the interfaces on which OSPF is to be active. Unlike RIP, this command has a wildcard mask that allows it to be very specific. All interfaces that match the network wildcard pattern will be active in OSPF in the given area.
The area parameter places the interface in an area. A router can have different interfaces in different areas (and thus be an ABR). The area-number is a 32-bit field and the format can either be a simple decimal or in dotted-decimal format. Some implementations of OSPF might only understand one of the formats, but the Cisco IOS accepts either form.
After identifying the interfaces on the router that are participating in the OSPF domain, hellos are exchanged, LSAs are sent, and the router inserts itself into the network.
Note
If there are stub networks connected to a router, it is useful to issue the command redistribute connected subnets. This command includes the connected subnets in OSPF advertisements without actually running OSPF on them. A route-map is often used with this command to exclude interfaces that are explicitly configured with OSPF.
You can apply the network command in different ways, yet each way achieves similar results.
Imagine that a router has the following interfaces:
FastEthernet 0/0: 192.168.100.1/24
FastEthernet 0/1: 192.168.101.1/24
FastEthernet 0/2: 192.168.102.1/24
FastEthernet 0/3: 192.168.103.1/24
Serial 1/0: 10.100.100.1/30
Serial 1/1: 10.100.100.5/30
It is possible to enable OSPF area 0 on all interfaces with the following command:
Router(router-config)# network 0.0.0.0 255.255.255.255 area 0Another way of achieving the same result is to break up the command into the 10 networks and the 192 networks, as follows:
Router(router-config)# network 10.0.0.0 0.255.255.255 area 0 Router(router-config)# network 192.168.100.0 0.0.3.255 area 0
A third way is to enable it independently on each interface, as follows:
Router(router-config)# network 192.168.100.1 0.0.0.0 area 0 Router(router-config)# network 192.168.101.1 0.0.0.0 area 0 Router(router-config)# network 192.168.102.1 0.0.0.0 area 0 Router(router-config)# network 192.168.103.1 0.0.0.0 area 0 Router(router-config)# network 10.100.100.1 0.0.0.0 area 0 Router(router-config)# network 10.100.100.5 0.0.0.0 area 0
These three examples achieve exactly the same result. All six interfaces are enabled, placed in area 0, and begin to process OSPF traffic.
By using the first approach (one all-encompassing statement), you may inadvertently include interfaces that you might not want included. The third option involves a lot of typing, but gives the administrator more control. The technique you choose to use is a function of your particular network topology, and generally you should choose the technique that is the most straightforward to document and explain. You need to be intimately familiar with the use of the wildcard mask with the network command to enable OSPF on router interfaces.
Configuration Options for an Internal Router
The following options allow you to tune the OSPF configuration of an internal router:
Router ID
Loopback interface
cost command
priority command
Defining the Router ID and Loopback Interfaces
The router needs an ID to participate in the OSPF domain. The router ID is used to identify LSAs in the OSPF database. The router ID can be defined by an administrator or left to the discretion of the router. Most people define the ID so that it is easier to track events in the network, for internal documentation, and for other system-administration purposes.
The OSPF router ID can be defined by the router-id command. If the router-id command is not present, then the router ID will be the highest IP address of a loopback interface. If no loopbacks are present, then the router ID will be the highest IP address of the first active interface.
Generally, using the router-id command is not recommended because BGP and OSPF normally pick a router ID the same way. Manually specifying a router ID can result in these IDs differing, which can be a source of problems with BGP operation.
Router(config)# router ospf Router(config-router)# router-id ip-address
The preferred way to control the router ID is to use a loopback interface address. A loopback interface is a virtual interface and is always active. The following shows how to configure a loopback interface:
Router(config)# interface loopback interface-number Router(config-if)# ip address ip-address subnet-mask
Loopbacks are typically assigned a /32 mask to minimize their use of address space.
Once the router ID of the router has been chosen, the router ID is stable and is not subject to the flippancy of physical interfaces on a router. Changing the router ID can break some OSPF configurations, such as virtual links. Loopback interfaces, which do not physically exist, can never go down and are therefore more stable than physical interfaces.
Note
Consider including the loopback interface address in the network commands. This gives you an easy point to ping to, regardless of the state of the network.
Changing the Default Cost
The cost metric is calculated as 100,000,000 bps divided by the bandwidth of the interface in bits per second. Sometimes—especially when dealing with faster lines or other vendor routers that use a different cost—it is useful to change this default value. The cost command manually overrides the default:
Router(config-if)# ip ospf cost cost
Cost is a 16-bit value (0 to 65,535) and lower values are preferred. Table 5-4 shows examples of default costs
| Link Type | Default Cost |
|---|---|
| 56-kbps serial link | 1785 |
| T1 (1.544-Mbps serial link) | 64 |
| Ethernet | 10 |
| Fast Ethernet | 1 |
| Gigabit Ethernet | 1 |
As shown in Table 5-4, the calculation of bandwidth gives Fast Ethernet and Gigabit Ethernet a metric of 1. In this situation, you might want to manipulate the default cost to prefer the faster path.
A second way to deal with high-bandwidth paths is to change the numerator in the automatic calculation. The ospf auto-cost reference-bandwidth router-configuration command changes the numerator in the metric formula to account for higher speeds:
Router(config-router)# ospf auto-cost reference-bandwidth reference-bandwidth
Here, reference-bandwidth is in megabytes per second. The range is 1 to 4,294,967; the default is 100. Set it to 1000 to give Gigabit links a cost of 1 and FastEthernet paths a cost of 10.
Note
It is strongly recommended that changes to the ospf auto-cost reference-bandwidth command be replicated on all routers in an area. Also, note that the ip ospf cost command overrides the calculated cost resulting from changes in auto-cost reference-bandwidth
Determining the Designated Router Using the priority Command
Remember that hello messages include a priority field and thus provide a mechanism by which the DR and BDR are elected. To be "up for election," the priority must be a positive integer between 1 and 255. If its priority is 0, the router cannot participate in the election. Otherwise, highest priority wins. All Cisco routers have a default priority of 1, and the highest router ID is used as a tiebreaker. As previously discussed in the "Electing DRs and BDRs" section, the command to adjust priority on an interface-by-interface basis is
Router(config-if)# ip ospf priority number
A Working Configuration of OSPF on a Single Router
Example 5-2 is a working configuration of OSPF on a single router. The Charlotte router will be the DR on F1/0 unless another device on the segment has a priority greater than 100. The link attached to F1/0 has a cost of 1. The cost on F3/0 has been changed to 10.
Example 5-2. Configuring OSPF
Charlotte(config)# router ospf 100 Charlotte(config-router)# network 140.100.0.0 0.0.255.255 area 3 Charlotte(config-router)# interface FastEthernet1/0 Charlotte(config-if)# ip address 140.100.17.129 255.255.255.240 Charlotte(config-if)# ip ospf priority 100 Charlotte(config-if)# interface FastEthernet3/0 Charlotte(config-if)# ip address 140.100.17.193 255.255.255.240 Charlotte(config-if)# ip ospf cost 10 |
Checking the Configuration of Single-Area OSPF
The set of commands shown in Table 5-5 configuration and maintenance of a live OSPF network.
| Command Option | Description |
|---|---|
| show ip ospf | Shows OSPF process details—for example, how many times the router has recalculated its routing table. |
| show ip ospf database | Shows contents of the topological database. |
| show ip ospf interface | Gives information about how OSPF has been configured on each interface. |
| show ip ospf neighbor | Displays neighbor information. Used to verify that all neighbors are present. |
| show ip protocols | Shows IP routing protocol configuration on the router. |
| show ip route | Shows networks of which the router is aware. Also shows preferred paths and gives next hop for each path. |
The OSPF show commands are very detailed and give a comprehensive understanding of the state of the network. You need to understand the concepts in this chapter to interpret the output of the show commands provided in subsequent sections.
The show ip ospf Command
The show ip ospf command shows how OSPF is running on a particular router. It includes the number of times that the SPF routing algorithm has run, which is indicative of the stability of the network. To issue the command, use the following syntax:
Router# show ip ospf [process-id]
Example 5-3 shows the output of this command. Table 5-6 explains how to interpret this information.
Example 5-3. The show ip ospf process-id Command Output
SanJose# show ip ospf 100
Routing Process "ospf 100" with ID 140.100.32.10
Supports only single TOS(TOS0) routes
It is an internal router
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
Number of external LSA 0. Checksum Sum 0x0
Number of DCbitless external LSA 0
Number of DoNotAge external LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Area 3
Number of interfaces in this area is 3
Area has no authentication
SPF algorithm executed 10 times
Area ranges are
Link State Update Interval is 00:30:00 and due in 00:18:54
Link State Age Interval is 00:20:00 and due in 00:08:53
Number of DCbitless LSA 2
Number of indication LSA 0
Number of DoNotAge LSA 0 |
| Field | Explanation |
|---|---|
| Routing Process "ospf 100" with ID 140.100.32.10 | Shows the local process ID and the router ID for OSPF. |
| It is an internal router | Type of router (internal, ABR, or ASBR). |
| SPF schedule delay | Specifies how long to wait to start SPF after receiving an LSA to prevent running SPF too often. |
| Hold time between two SPFs | Specifies the minimum time between SPF calculations. |
| Number of DCbitless external LSA | Used with OSPF demand circuits. |
| Number of DoNotAge external LSA | Used with OSPF demand circuits, such as ISDN. |
| Area 3
Number of interfaces in this area is 3 Area has no authentication SPF algorithm executed 10 times Area ranges are | Specifies the number of areas of which this router is a member. It is an internal router because it is only configured for a single area. It is possible to see how many of the router's interfaces are in an area and whether the router is using MD5 security. It is useful to see the number of times that the SPF algorithm has been executed. The area ranges show summarization that has been configured. |
| Link State Update Interval is 00:30:00 and due in 00:18:54 | The default for the LSA update timer is 30 minutes. This is used to ensure the integrity of the topological database. This field shows when the next update is and that the default has not been changed. |
| Link State Age Interval is 00:20:00 and due in 00:08:53 | Specifies the MAX-AGED deletion interval and shows when out-of-date routes will next be purged. |
The show ip ospf database Command
The show ip ospf database command displays the contents of the router's topological database and the different LSAs that have populated the database:
Internal routers, the primary subject of this chapter, will only display router and network LSAs. This command has many parameters that enable you to examine very specific information.
Example 5-4 shows the output of the show ip ospf database command. Table 5-7 explains the important fields.
Example 5-4. The show ip ospf database Command Output
SanJose# show ip ospf database
OSPF Router with ID (140.100.32.10) (Process ID 100)
Router Link States (Area 3)
Link ID ADV Router Age Seq# Checksum Link count
140.100.17.131 140.100.17.131 471 0x80000008 0xA469 1
140.100.17.132 140.100.17.132 215 0x80000007 0xA467 1
140.100.17.194 140.100.17.194 1489 0x8000000B 0xFF16 1
140.100.23.1 140.100.23.1 505 0x80000006 0x56B3 1
140.100.32.10 140.100.32.10 512 0x8000000C 0x46BA 3
140.100.32.11 140.100.32.11 150 0x80000006 0x6A73 1
140.100.32.12 140.100.32.12 1135 0x80000002 0x8E30 1
Net Link States (Area 3)
Link ID ADV Router Age Seq# Checksum
140.100.17.130 140.100.23.1 220 0x80000007 0x3B42
140.100.17.194 140.100.17.194 1490 0x80000002 0x15C9
140.100.32.11 140.100.32.11 150 0x80000004 0x379E |
