Section 39 – OSPF

Section 39 Tasks

• Read today’s lesson notes (below)
• Review yesterday’s lesson notes
• Complete today’s lab
• Read the ICND2 cram guide
• Spend 15 minutes on the subnetting.org website

As with EIGRP, we could discuss OSPF over several days, but we need to stick to what you need to know for your exam. Even CCNA-level OSPF knowledge wouldn’t be sufficient to design and deploy it on most networks.

Today you will learn about the following:

• OSPF operations
• DR and BDR
• Configuring OSPF
• Troubleshooting OSPF

This lesson maps to the following CCNA syllabus requirements:

• Configure and verify OSPF (single area)
• Neighbour adjacencies
• OSPF states
• Discuss multi-area
• Configure OSPFv2
• Router ID
• LSA types

Designated and Backup Designated Routers

As stated in the Day 12 module, OSPF elects a Designated Router (DR) and/or a Backup Designated Router (BDR) on Broadcast and Non-Broadcast network types. It is important to understand that the BDR is not a mandatory component on these network types. In fact, OSPF will work just as well when only a DR is elected and there is no BDR; however, there will be no redundancy if the DR fails and the OSPF routers need to go through the election process again to elect a new DR.

On the segment (on Broadcast and Non-Broadcast network types), each individual non-DR/BDR
router establishes an adjacency with the DR and, if one has also been elected, the BDR, but not with any other non-DR/BDR routers on the segment. The DR and BDR routers are fully adjacent with each other and all other routers on the segment. The non-DR/BDR routers send messages and updates to the AllDRRouters Multicast group address 224.0.0.6. Only the DR/BDR routers listen to Multicast messages sent to this group address. The DR then advertises messages to the AllSPFRouters Multicast group address 224.0.0.5. This allows all other OSPF routers on the segment to receive the updates.

It is important to understand the sequence of message exchanges when a DR and/or a BDR router have been elected. As an example, imagine a Broadcast network with four routers, which are R1, R2, R3, and R4. Assume that R4 has been elected DR, and R3 has been elected BDR. R2 and R1 are neither DR nor BDR and are therefore referred to as DROther routers in Cisco OSPF terminology. A configuration change is made on R1, and R1 then sends an update to the AllDRRouters Multicast group address 224.0.0.6. R4, the DR, receives this update and sends an acknowledgement back to the AllSPFRouters Multicast group address 224.0.0.5. R4 then sends this update to all other non-DR/BDR routers using the AllSPFRouters Multicast group address. This update is received by the other DROther router, R2, and R2 sends an acknowledgement to the AllDRRouters Multicast group 224.0.0.6. This is illustrated in Figure 39.1 below:

Figure 39.1 – OSPF DR and BDR Advertisements

NOTE: The BDR simply listens to the packets sent to both Multicast groups.

In order for a router to be the DR or the BDR for the segment, the router must be elected. This election is based on the following:

• The highest router priority value
• The highest router ID

By default, all routers have a default priority value of 1. This value can be adjusted using the ip ospf priority <0-255> interface configuration command. The higher the priority, the greater the likelihood the router will be elected DR for the segment. The router with the secondhighest priority will then be elected BDR. If a priority value of 0 is configured, the router will not participate in the DR/BDR election process. The highest router priority and router ID are important only if OSPF processes loads at the same time on all routers participating in the DR/BDR election process. Otherwise the router that finishes loading the OSPF process first will become the DR on the segment.

When determining the OSPF router ID, Cisco IOS selects the highest IP address of configured Loopback interfaces. If no Loopback interfaces are configured, the software uses the highest IP address of all configured physical interfaces as the OSPF router ID. Cisco IOS software also allows administrators to specify the router ID manually using the router-id [address] router configuration command.

It is important to remember that with OSPF, once the DR and the BDR have been elected, they will remain as DR/BDR routers until a new election is held. For example, if a DR and a BDR exist on a Multi-Access network and a router with a higher priority or IP address is added to the same segment, the existing DR and BDR routers will not change. If the DR fails, the BDR will assume the role of the DR, not the new router with the higher priority or IP address. Instead, a new election will be held and that router will most likely be elected BDR. In order for that router to become the DR, the BDR must be removed or the OSPF process must be reset using the clear ip ospf command, forcing a new DR/BDR election. Once elected, OSPF uses the DR and the BDR routers as follows:

• To reduce the number of adjacencies required on the segment
• To advertise the routers on the Multi-Access segment
• To ensure that updates are sent to all routers on the segment

To better understand these fundamental concepts, reference the basic OSPF network topology illustrated in Figure 39.2 below:

Figure 39.2 – OSPF DR and BDR Fundamentals

Referencing Figure 39.2, each router on the segment establishes an adjacency with the DR and the BDR but not with each other. In other words, non-DR/BDR routers do not establish an adjacency with each other. This prevents the routers on the segment from forming N(N-1) adjacencies with each other, which reduces excessive OSPF packet flooding on the segment.

For example, without the concept of a DR/BDR on the segment, each individual router would need to establish an adjacency with every other router on the segment. This would result in 4(4-1) or 12 adjacencies on the segment. However, with the DR/BDR, each individual router needs to establish an adjacency with only these two routers and no other non-DR and BDR routers. The DR and the BDR also establish an adjacency between themselves. This reduces the number of adjacencies required on the segment and on each individual OSPF router, which in turn reduces resources consumption (e.g., memory and processor utilisation) on the routers.

Regarding the second point, OSPF views a link as a connection between two routers or nodes. In Multi-Access networks, such as Ethernet, multiple routers can reside on the same segment, as illustrated in Figure 39.2. On such networks, 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, this LSA allows those routers to know about the other routers on the Multi-Access segment.

To further clarify this point, referencing Figure 39.2, assuming that all routers on the segment have the default OSPF priority value of 1 (and load the OSPF process at the same time), R4 is elected as the DR for the segment because it has the highest router ID. R3 is elected as the BDR for the segment because it has the second-highest router ID. Because R2 and R1 are neither the DR nor the BDR, they are referred to as DROther routers in Cisco terminology. This can be validated using the show ip ospf neighbor command on all routers, as follows:

R1#show ip ospf neighbor
Neighbor ID   Pri   State           Dead Time   Address         Interface
2.2.2.2         1   2WAY/DROTHER    00:00:38    192.168.1.2     Ethernet0/0
3.3.3.3         1   FULL/BDR        00:00:39    192.168.1.3     Ethernet0/0
4.4.4.4         1   FULL/DR         00:00:38    192.168.1.4     Ethernet0/0

R2#show ip ospf neighbor
Neighbor ID  Pri   State            Dead Time   Address         Interface
1.1.1.1        1   2WAY/DROTHER     00:00:32    192.168.1.1     FastEthernet0/0
3.3.3.3        1   FULL/BDR         00:00:33    192.168.1.3     FastEthernet0/0
4.4.4.4        1   FULL/DR          00:00:32    192.168.1.4     FastEthernet0/0

R3#show ip ospf neighbor
Neighbor ID  Pri   State            Dead Time   Address         Interface
1.1.1.1        1   FULL/DROTHER     00:00:36    192.168.1.1     FastEthernet0/0
2.2.2.2        1   FULL/DROTHER     00:00:36    192.168.1.2     FastEthernet0/0
4.4.4.4        1   FULL/DR          00:00:35    192.168.1.4     FastEthernet0/0

R4#show ip ospf neighbor
Neighbor ID  Pri   State            Dead Time   Address         Interface
1.1.1.1        1   FULL/DROTHER     00:00:39    192.168.1.1     FastEthernet0/0
2.2.2.2        1   FULL/DROTHER     00:00:39    192.168.1.2     FastEthernet0/0
3.3.3.3        1   FULL/BDR         00:00:30    192.168.1.3     FastEthernet0/0

NOTE: The DROther routers remain in the 2WAY/DROTHER state because they exchange their databases only with the DR and BDR routers. Therefore, because there is no full database exchange between the DROther routers, they will never reach the OSPF FULL adjacency state.

Because R4 has been elected DR, it generates the Network LSA, which advertises the other routers on the Multi-Access segment. This can be verified using the show ip ospf database network [link state ID] command on any router on the segment or the show ip ospf database network self-originate command on the DR only. The following illustrates the output of the show ip ospf database network self-originate command on the DR (R4):

R4#show ip ospf database network self-originate
            OSPF Router with ID (4.4.4.4) (Process ID 4)
                Net Link States (Area 0)
  Routing Bit Set on this LSA
  LS age: 429
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 192.168.1.4 (address of Designated Router)
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000006
  Checksum: 0x7E08
  Length: 40
  Network Mask: /24
        Attached Router: 4.4.4.4
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2
        Attached Router: 3.3.3.3

Referencing the output above, the DR (R4) originates the Type 2 (Network) LSA representing the 192.168.1.0/24 subnet. Because multiple routers exist on this subnet, this 192.168.1.0/24 subnet is referred to as a transit link in OSPF terminology. The Advertising Router field shows the router that originated this LSA. The Network Mask field shows the subnet mask of the transit network, which is 24-bit or 255.255.255.0.

The Attached Router field lists the router IDs of all routers that are on the network segment. This allows all of the routers on the segment to know what other routers also reside on the segment. The output of the show ip ospf database network [link state ID] command on R1, R2, and R3 reflects the same information, as illustrated in the following outputs:

R2#show ip ospf database network
            OSPF Router with ID (2.2.2.2) (Process ID 2)
                Net Link States (Area 0)
  Routing Bit Set on this LSA
  LS age: 923
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 192.168.1.4 (address of Designated Router)
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000006
  Checksum: 0x7E08
  Length: 40
  Network Mask: /24
        Attached Router: 4.4.4.4
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2
        Attached Router: 3.3.3.3

R1#show ip ospf database network
            OSPF Router with ID (1.1.1.1) (Process ID 1)
                Net Link States (Area 0)
  Routing Bit Set on this LSA
  LS age: 951
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 192.168.1.4 (address of Designated Router)
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000006
  Checksum: 0x7E08
  Length: 40
  Network Mask: /24
        Attached Router: 4.4.4.4
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2
        Attached Router: 3.3.3.3
            OSPF Router with ID (4.4.4.4) (Process ID 4)

R3#show ip ospf database network
            OSPF Router with ID (3.3.3.3) (Process ID 3)
                Net Link States (Area 0)
  Routing Bit Set on this LSA
  LS age: 988
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 192.168.1.4 (address of Designated Router)
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000006
  Checksum: 0x7E08
  Length: 40
  Network Mask: /24
        Attached Router: 4.4.4.4
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2
        Attached Router: 3.3.3.3

The functionality of the Network LSA and how it is correlated to another LSA, specifically the Router LSA (Type 1), will be described in detail later in this module. For this section, primary emphasis should be placed on understanding that the DR generates and advertises the Network LSA on the Multi-Access segment to advertise other routers that reside on the same segment. This is because routers on the segment establish an adjacency only with the DR and BDR routers and not with each other. Without an adjacency with each other, the routers will never know about other non-DR/BDR routers on the Multi-Access segment.

Finally, regarding the third point made on DR/BDR routers, the DR/BDR routers ensure that all routers on the segment have complete databases. Non-DR/BDR routers send updates to the Multicast group address 224.0.0.6 (AllDRRouters). The DR then advertises these updates to other non-DR/BDR routers by sending the update to the Multicast group address 224.0.0.5 (AllSPFRouters). Figure 39.3 below illustrates an update from R1 (a DROther) to the DR group address referencing the routers illustrated in Figure 39.2:

Figure 39.3 – DROther Update to DR/BDR Group Address

R4 (DR) receives this update and in turn sends the same to Multicast group address 224.0.0.5. This group address is used by all OSPF routers, ensuring that all other routers on the segment receive this update. This update from the DR (R4) is illustrated in Figure 39.4 below:

Figure 39.4 – DR Update to OSPF Group Address

NOTE: You can see that this is the Update from R1 because the Advertising Router field in both Figures 39.3 and 39.4 contains the router ID (RID) of R1, which is 1.1.1.1.

NOTE: The other LSAs used by OSPF will be described in detail later in this module.

Additional Router Types

In addition to the Designated Router and the Backup Designated Router on Multi-Access segments, OSPF routers are also described based on their location and function within the OSPF network. The additional router types that are commonly found within the OSPF network include the following:

• Area Border Routers
• Autonomous System Boundary Routers
• Internal routers
• Backbone routers

Figure 39.5 below illustrates a basic OSPF network comprised of two areas, the OSPF backbone area (Area 0) and an additional normal OSPF area (Area 2). R2 has an external BGP neighbour relationship with R1. This diagram will be used to describe the different OSPF router types within this network.

Figure 39.5 Additional OSPF Router Types

An Area Border Router (ABR) is an OSPF router that connects one or more OSPF areas to the OSPF backbone. This means that it must have at least one interface in Area 0 and another interface, or interfaces, within a different OSPF area. ABRs are members of all areas to which they belong, and they keep a separate Link State Database for every area to which they belong. Referencing Figure 39.5, R3 would be considered an ABR, as it connects Area 2 to the OSPF backbone, or Area 0.

An Autonomous System Boundary Router (ASBR), in the traditional sense, resides at the edge of the routing domain and defines the boundary between the internal and the external networks. Referencing Figure 39.5, R2 would be considered an ASBR. In addition to injecting routing information from other protocols (e.g., BGP), a router can also be classified as an ASBR if it injects static routes or connected subnets into the OSPF domain.

Internal routers maintain all operational interfaces within a single OSPF area. Based on the network topology illustrated in Figure 39.5, R4 would be considered an internal router because its only interface resides within a single OSPF area.

Backbone routers are routers that have an interface in the OSPF backbone. Backbone routers can include routers that have interfaces only in the OSPF backbone area, or routers that have an interface in the OSPF backbone area as well as interfaces in other areas (ABRs). Based on the topology illustrated in Figure 39.5, both R2 and R3 would be considered backbone routers.

NOTE: OSPF routers can have multiple roles. For example, R2 is both an ASBR and a backbone router, while R3 is both a backbone router and an ABR. Throughout this module, we will take a detailed look at these types of routers and their roles and functions within the OSPF domain.

OSPF Packet Types

The different types of packets sent by OSPF routers are contained in the common 24-byte OSPF header. While delving into the specifics of the OSPF header is beyond the scope of the CCNA exam requirements, it is still important to have a basic understanding of the fields contained within this header and what they are used for. Figure 39.6 below illustrates the common 24- octet OSPF header:

Figure 39.6 – The OSPF Packet Header

The 8-bit Version field specifies the OSPF version. The default value for this field is 2. However, when OSPFv3 is enabled, this field is also set to 3. OSPFv3 was described in detail in the Day 13 module.

The 8-bit Type field is used to specify the OSPF packet type. The five main OSPF packet types, which are described in detail later in this module, are as follows:

• Type 1 = Hello packet
• Type 2 = Database Description packet
• Type 3 = Link State Request packet
• Type 4 = Link State Update packet
• Type 5 = Link State Acknowledgement packet

The 16-bit Packet Length field is used to specify the length of the protocol packet. This length includes the standard OSPF header.

The 32-bit Router ID field is used to specify the IP address of the router from which the packet originated. On Cisco IOS devices, this field will contain the highest IP address of all physical interfaces configured on the device running OSPF. If Loopback interfaces are configured on the device, the field will contain the highest IP address of all configured Loopback interfaces. Alternatively, this field can also contain a manually configured router ID if one has been explicitly configured or specified by the administrator.

NOTE: When the router ID has been selected, it will never change unless the router is reloaded, the interface that the IP address was derived from is shut down or removed, or the OSPF process is reset using the clear ip ospf process privileged EXEC command on the router.

The 32-bit Area ID field is used to identify the OSPF area of the packet. A packet can belong only to a single OSPF area. If the packet is received via a virtual link, then the Area ID will be the OSPF backbone, or Area 0. Virtual links are described in detail later in this module.

The Checksum field is 16-bits long and indicates the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit Authentication Data field. If the packet’s length is not an integral number of 16-bit words, the packet is padded with a byte of zero before being checksummed.

The 16-bit Authentication (Auth) Type field identifies the type of authentication used. This field is valid only for OSPFv2 and may contain one of the following three codes:

• Code 0 – This means that there is null (no) authentication; this is the default
• Code 1 – This means that the authentication type is plain text
• Code 2 – This means that the authentication type is Message Digest 5 (MD5)

Finally, the 64-bit Authentication Data field is for the actual authentication information or data, if authentication has been enabled. It is important to remember that this field is valid only for OSPFv2. If plain text authentication is being used, this field contains the authentication key. However, if MD5 authentication is being used, this field is redefined into several other fields, which are beyond the scope of the CCNA exam requirements. Figure 39.7 below shows the different fields as they appear in a wire capture of an OSPF packet:

Figure 39.7 – OSPF Packet Header Wire Capture

Within the OSPF packet header, the 8-bit Type field is used to specify the OSPF packet type. Again, the five OSPF packet types are as follows:

• Type 1 = Hello packet
• Type 2 = Database Description packet
• Type 3 = Link State Request packet
• Type 4 = Link State Update packet
• Type 5 = Link State Acknowledgement packet

OSPF Hello Packets

Hello packets are used to discover other directly connected OSPF routers and to establish OSPF adjacencies between OSPF routers. OSPF uses Multicast to send Hello packets for Broadcast and Point-to-Point network types. These packets are addressed to the AllSPFRouters Multicast group address 224.0.0.5. For Non-Broadcast links (e.g., Frame Relay), OSPF uses Unicast to send Hello packets directly to statically configured neighbours.

NOTE: By default, all OSPF packets (i.e., Multicast and Unicast) are sent with an IP TTL of 1. This limits these packets to the local link. In other words, you cannot establish an OSPF adjacency with another router that is more than one hop away. This is also applicable to EIGRP.

OSPF Hello packets are also used on Broadcast links to elect a DR and a BDR. The DR listens specifically to the Multicast address 224.0.0.6 (AllDRRouters). The DR and the BDR were described in detail previously in this module. Figure 39.8 below illustrates the fields contained within the OSPF Hello packet:

Figure 39.8 – OSPF Hello Packet

The 4-byte Network Mask field contains the subnet mask of the advertising OSPF interface. The network mask is checked only on Broadcast media. Unnumbered Point-to-Point interfaces and virtual links, both of which will be described later in this module, set this value to 0.0.0.0.

The 2-byte Hello field displays the value of the Hello interval, which is the number of seconds between two Hello packets, requested by the advertising router. Possible values range from 1 to 255. By default, the Hello interval is 10 seconds on Broadcast and Point-to-Point media and 30 seconds on all other media.

The 1-byte Options field is used by the local router to advertise optional capabilities. Each bit in the Options field represents a different function. Going into them is outside the scope of the CCNA exam requirements.

The 1-byte Router Priority field contains the priority of the local router. By default, this field has a value of 1. The value is used in the election of the DR and the BDR. Possible values range from 0 to 255. The higher the priority, the higher the chances the local router will become the
DR. A priority value of 0 means that the local router will not participate in the DR or the BDR election.

The 4-byte Router Dead Interval field shows the value of the dead interval. The dead interval is the time (seconds) before a neighbour router is declared dead. This value is requested by the advertising router. The default value for the dead interval is four times the value of the Hello interval, which would be a default of 40 seconds on Broadcast and Point-to-Point interfaces and 120 seconds on all other types of media.

The 4-byte Designated Router field lists the IP address of the DR. A value of 0.0.0.0 is used when no DR has been elected, for example, on a Point-to-Point link or when a router has been explicitly configured not to participate in this election.

The 4-byte Backup Designated Router field identifies the BDR and lists the interface address of the current BDR. A value of 0.0.0.0 is used when no BDR has been elected.

Finally, the (Active) Neighbor field is a variable length field that displays the router ID of all OSPF routers for which a Hello packet has been received on the network segment.

Database Description Packets

Database Description packets are used during the database exchange when each OSPF router advertises its local database information. These packets are commonly referred to as DBD packets or as DD packets. The first DBD packet is used for the Master and Slave election for database exchange. The DBD packet also contains the initial sequence number selected by the Master. The router with the highest router ID becomes the Master and initiates database synchronisation. This is the only router that can increment the sequence number. The Master router begins the database exchange and polls the Slave for information. The Master and Slave election is held on a per-neighbour basis.

It is important to understand that the Master and Slave election process is not the same as the DR and BDR election process. This is commonly incorrectly assumed. The Master and Slave election process is based solely on the router with the highest IP address; however, the DR/BDR election process may be determined using either the IP address or the priority value.

Assume, for example, two routers named R1 and R2 are beginning the adjacency establishment process. R1 has a RID of 1.1.1.1, while R2 has a RID of 2.2.2.2. The network administrator has configured R1 with an OSPF priority value of 255 to ensure that this router will be elected the DR. During the Master and Slave determination process, R2 will be elected master by virtue of the higher RID. However, the priority value configured on R1 results in R1 being elected the DR. In essence, the DR (R1) can be the Slave during the Master and Slave election process.

After the Master and Slave have been elected, DBD packets are used to summarise the local database by sending LSA headers to the remote router. The remote router analyses these headers to determine whether it lacks any information within its own copy of the LSDB. The OSPF Database Description packet is illustrated in Figure 39.9 below:

Figure 39.9 – OSPF Database Description Packet

Within the DBD packet, the 2-byte Interface MTU field contains the MTU value, in octets, of the outgoing interface. In other words, this field contains the largest data size that can be sent through the associated interface (in bytes). When the interface is used on a virtual link, the field is set to a value of 0x0000. In order for an OSPF neighbour adjacency to be established successfully, the MTU must be the same on all routers. If you change this value on one router, you must configure the same value on all other routers on the same subnet (or use the ip ospf mtu-ignore command).

NOTE: The interface MTU values for EIGRP do not have to be the same in order for an EIGRP neighbour relationship to be established successfully.

The 1-byte Options field contains the same options contained within the OSPF Hello packet. For brevity, these options will not be described again.

The Database Description or Flags field is a 1-byte field that provides an OSPF router with the capability to exchange multiple DBD packets with a neighbour during an adjacency formation.

The 4-byte DBD Sequence Number field is used to guarantee that all DBD packets are received and processed during the synchronisation process through the use of a sequence number. The Master router initialises this field to a unique value in the first DBD packet, with each subsequent packet being incremented by 1. The sequence number is incremented only by the Master.

Finally, the variable length LSA Header field carries the LSA headers describing the local router’s database information. Each header is 20 octets in length and uniquely identifies each LSA in the database. Each DBD packet may contain multiple LSA headers.

Link State Request Packets

Link State Request (LSR) packets are sent by OSPF routers to request missing or out-of-date database information. These packets contain identifiers that uniquely describe the requested Link State Advertisement. An individual LSR packet may contain a single set of identifiers or multiple sets of identifiers to request multiple LSAs. LSR packets are also used after database exchange to request LSAs that were seen during the database exchange that the local router does not have. Figure 39.10 below illustrates the format of the OSPF LSR packet:

Fig. 39.10 – OSPF Link State Request Packet

The 4-byte Link State Advertisement Type field contains the type of LSA being requested. It may contain one of the following fields:

• Type 1 = Router Link State Advertisement
• Type 2 = Network Link State Advertisement
• Type 3 = Network Summary Link State Advertisement
• Type 4 = ASBR Summary Link State Advertisement
• Type 5 = AS External Link State Advertisement
• Type 6 = Multicast Link State Advertisement
• Type 7 = NSSA External Link State Advertisement
• Type 8 = External Attributes Link State Advertisement
• Type 9 = Opaque Link State Advertisement – Link Local
• Type 10 = Opaque Link State Advertisement – Area
• Type 11 = Opaque Link State Advertisement – Autonomous System

NOTE: Some of the LSAs listed above are described in detail in the following sections.

The 4-byte Link State ID field encodes information specific to the LSA. The information that is contained in this field depends upon the type of LSA. Finally, the 4-byte Advertising Router field contains the RID of the router that first originated the LSA.

Link State Update Packets

Link State Update (LSU) packets are used by the router to advertise LSAs. LSU packets may be Unicast to an OSPF neighbour in response to a received LSR from that neighbour. Most commonly, however, they are reliably flooded throughout the network to the AllSPFRouters Multicast group address 224.0.0.5 until each router has a copy. The flooded updates are then acknowledged in the LSA Acknowledgement packet. If the LSA is not acknowledged, it will be retransmitted every five seconds, by default. Figure 39.11 below shows an LSU sent to a neighbour in response to an LSR:

Figure 39.11 – Unicast LSU Packet

Figure 39.12 below illustrates an LSU that is reliably flooded to the Multicast group address 224.0.0.5:

Figure 39.12 – Multicast LSU Packet

The LSU is comprised of two parts. The first part is the 4-byte Number of LSAs field. This field displays the number of LSAs carried within the LSU packet. The second part is one or more Link State Advertisements. This variable-length field contains the complete LSA. Each type of LSA has a common header format along with specific data fields to describe its information. An LSU packet may contain a single LSA or multiple LSAs.

Link State Acknowledgement Packets

The Link State Acknowledgement (LSAck) packet is used to acknowledge each LSA and is sent in response to LSU packets. By explicitly acknowledging packets with LSAcks, the flooding mechanism used by OSPF is considered reliable.

The LSAck contains the common OSPF header followed by a list of LSA headers. This variablelength field allows the local router to acknowledge multiple LSAs using a single packet. LSAcks are sent using Multicast. On Multi-Access networks, if the router sending the LSAck is a DR or a BDR, then LSAcks are sent to the Multicast group address 224.0.0.5 (AllSPFRouters). However, if the router sending the LSAcks is not a DR or a BDR device, then LSAck packets are sent to the Multicast group address 224.0.0.6 (AllDRRouters). Figure 39.13 below illustrates the format of the LSAck:

Figure 39.13 – Link State Acknowledgement Packet

In conclusion, it is important to remember the different OSPF packet types and what information they contain. This not only will benefit you in the exam but also will aid you in understanding the overall operation of OSPF as a protocol.

In Cisco IOS software, you can use the show ip ospf traffic command to view OSPF packet statistics. This command shows the total count for the sent and received OSPF packets, and then segments this further to the individual OSPF process and, finally, to the interfaces enabled for OSPF routing under that process. This command can also be used to troubleshoot OSPF adjacency establishment and is not as processor intensive as debugging. The information printed by this command is illustrated in the following output:

R4#show ip ospf traffic
OSPF statistics:
  Rcvd: 702 total, 0 checksum errors
        682 hello, 3 database desc, 0 link state req
        12 link state updates, 5 link state acks
  Sent: 1378 total
        1364 hello, 2 database desc, 1 link state req
        5 link state updates, 6 link state acks
            OSPF Router with ID (4.4.4.4) (Process ID 4)
OSPF queue statistics for process ID 4:
                   InputQ     UpdateQ    OutputQ
  Limit            0          200        0
  Drops            0          0          0
  Max delay [msec] 4          0          0
  Max size         2          2          2
    Invalid        0          0          0
    Hello          0          0          1
    DB des         2          2          1
    LS req         0          0          0
    LS upd         0          0          0
    LS ack         0          0          0
  Current size     0          0          0
    Invalid        0          0          0
    Hello          0          0          0
    DB des         0          0          0
    LS req         0          0          0
    LS upd         0          0          0
    LS ack         0          0          0
Interface statistics:
    Interface Serial0/0
OSPF packets received/sent
    Invalid  Hellos   DB-des   LS-req   LS-upd   LS-ack   Total
Rx: 0        683      3        0        12       5        703
Tx: 0        684      2        1        5        6        698
OSPF header errors
  Length 0, Auth Type 0, Checksum 0, Version 0,
  Bad Source 0, No Virtual Link 0, Area Mismatch 0,
  No Sham Link 0, Self Originated 0, Duplicate ID 0,
  Hello 0, MTU Mismatch 0, Nbr Ignored 0,
  LLS 0, Unknown Neighbor 0, Authentication 0,
  TTL Check Fail 0,
OSPF LSA errors
  Type 0, Length 0, Data 0, Checksum 0,
    Interface FastEthernet0/0
OSPF packets received/sent
    Invalid  Hellos   DB-des   LS-req   LS-upd   LS-ack   Total
Rx: 0        0        0        0        0        0        0
Tx: 0        682      0        0        0        0        682
OSPF header errors
  Length 0, Auth Type 0, Checksum 0, Version 0,
  Bad Source 0, No Virtual Link 0, Area Mismatch 0,
  No Sham Link 0, Self Originated 0, Duplicate ID 0,
  Hello 0, MTU Mismatch 0, Nbr Ignored 0,
  LLS 0, Unknown Neighbor 0, Authentication 0,
  TTL Check Fail 0,
OSPF LSA errors
  Type 0, Length 0, Data 0, Checksum 0,
Summary traffic statistics for process ID 4:
  Rcvd: 703 total, 0 errors
        683 hello, 3 database desc, 0 link state req
        12 link state upds, 5 link state acks, 0 invalid
  Sent: 1380 total
        1366 hello, 2 database desc, 1 link state req
        5 link state upds, 6 link state acks, 0 invalid

Establishing Adjacencies

Routers running OSPF transition through several states before establishing an adjacency. The routers exchange different types of packets during these states. This exchange of messages allows all routers that establish an adjacency to have a consistent view of the network. Additional changes to the current network are simply sent out as incremental updates. The different states are the Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, and Full states, as described below:

• The Down state is the starting state for all OSPF routers. However, the local router may also show a neighbour in this state when no Hello packets have been received within the specified router dead interval for that interface.
• The Attempt state is valid only for OSPF neighbours on NBMA networks. In this state, a Hello has been sent but no information has been received from the statically configured neighbour within the dead interval; however, some effort is being made to establish an adjacency with this neighbour.
• The Init state is reached when an OSPF router receives a Hello packet from a neighbour but the local RID is not listed in the received Neighbor field. If OSPF Hello parameters, such as timer values, do not match, then OSPF routers will never progress beyond this state.
• The 2-Way state indicates bidirectional communication (each router has seen the other’s Hello packet) with the OSPF neighbour(s). In this state, the local router has received a Hello packet with its own RID in the Neighbor field and Hello packet parameters are identical on the two routers. At this state, a router decides whether to become adjacent with this neighbour. On Multi-Access networks, the DR and the BDR are elected during this phase.
• The Exstart state is used for the initialisation of the database synchronisation process. It is at this stage that the local router and its neighbour establish which router is in charge of the database synchronisation process. The Master and Slave are elected in this state, and the first sequence number for DBD exchange is decided by the Master in this stage.
• The Exchange state is where routers describe the contents of their databases using DBD packets. Each DBD sequence is explicitly acknowledged, and only one outstanding DBD is allowed at a time. During this phase, LSR packets are also sent to request a new instance of the LSA. The M (More) bit is used to request missing information during this stage. When both routers have exchanged their complete databases, they will both set the M bit to 0.
• In the Loading state, OSPF routers build an LSR and Link State Retransmission list. LSR packets are sent to request the more recent instance of an LSA that has not been received during the Exchange process. Updates that are sent during this phase are placed on the Link State Retransmission list until the local router receives an acknowledgement. If the local router also receives an LSR during this phase, it will respond with a Link State Update that contains the requested information.
• The Full state indicates that the OSPF neighbours have exchanged their entire databases and both agree (i.e., have the same view of the network). Both neighbouring routers in this state add the adjacency to their local database and advertise the relationship in a Link State Update packet. At this point, the routing tables are calculated, or recalculated if the adjacency was reset. Full is the normal state for an OSPF router. If a router is stuck in another state, it’s an indication that there are problems in forming adjacencies. The only exception to this is the 2-Way state, which is normal in Broadcast and Non-Broadcast Multi-Access networks where routers achieve the Full state with their DR and BDR only. Other neighbours always see each other as 2-Way.

In order for an OSPF adjacency to be established successfully, certain parameters on both routers must match. These parameters include the following:

• The interface MTU values (can be configured to be ignored)
• The Hello and Dead timers
• The Area ID
• The Authentication type and password
• The Stub Area flag
• Compatible network types

These parameters will be described as we progress through this module. If these parameters do not match, the OSPF adjacency will never fully establish.

NOTE: In addition to mismatched parameters, it is also important to remember that on a Multi-Access network, if both routers are configured with a priority value of 0, then the adjacency will not be established. The DR must be present on such network types.

OSPF LSAs and the Link State Database (LSDB)

As stated in the previous section, OSPF uses several types of Link State Advertisements. Each LSA begins with a standard 20-byte LSA header. This header contains the following fields:

• Link State Age
• Options
• Link State Type
• Link State ID
• Advertising Router
• Link State Sequence Number
• Link State Checksum
• Length

The 2-byte Link State Age field states the time (in seconds) since the LSA was originated. The maximum age of the LSA is 3600 seconds, which means that if the age reaches 3600 seconds, the LSA is removed from the database. To avoid this, the LSA is refreshed every 1800 seconds.

The 1-byte Options field contains the same options as those in the OSPF Hello packet.

The 1-byte Link State Type field represents the types of LSAs. These different LSA packet types are described in detail in the following sections.

The 4-byte Link State ID field identifies the portion of the network that is being described by the LSA. The contents of this field depend upon the advertisement’s LS type.

The 4-byte Advertising Router field represents the router ID of the router originating the LSA.

The 1-byte Link State Sequence Number field detects old or duplicate Link State Advertisements. Successive instances of an LSA are given successive Link State Sequence Numbers. The first sequence number 0x80000000 is reserved; therefore, the actual first sequence number is always 0x80000001. This value is incremented as packets are sent. The maximum sequence number is 0x7FFFFFFF.

The 2-byte Link State Checksum field performs the Fletcher checksum of the complete contents of the LSA, including the LSA header. The Link State Age field is not included in the checksum. The checksum is performed because Link State Advertisements can be corrupted while being stored in memory due to router software or hardware issues or during flooding due to Physical Layer errors, for example.

NOTE: The checksum is performed at the time the LSA is generated or is received. In addition, the checksum is performed at every CheckAge interval, which is 10 minutes. If this field has a value of 0, then it means that the checksum has not been performed.

The 2-byte Length field is the final field and includes the length (in bytes) of the LSA. This includes the 20-byte LSA header. Figure 39.13 below illustrates the LSA header:

Figure 39.13 – Link State Advertisement Header

While OSPF supports 11 different types of Link State Advertisements, only LSA Types 1, 2, and 3, which are used to calculate internal routes, and LSA Types 4, 5, and 7, which are used to calculate external routes, are within the scope of the CCNA exam requirements. Because there is really no need to go into great detail on the other LSAs for the CCNA exam, these LSAs will not be described further in this guide. However, a brief outline and a printable guide are provided at www.in60days.com.

In Cisco IOS software, the show ip ospf database command is used to view the contents of the Link State Database. This command, when used without any keywords, prints out a summary of LSAs in all areas to which the router is connected. The command supports several keywords that provide greater granularity in allowing network administrators to restrict output only to specific types of LSAs, LSAs advertised by the local router, or even LSAs advertised by other routers within the OSPF domain.

While illustrating the output of the usage of each keyword is unrealistic, the following section describes the different LSAs and the common keywords used in conjunction with the show ip ospf database command to view detailed information on these LSAs. The keywords supported by this command are illustrated in the following output:

R3#show ip ospf database ?
  adv-router        Advertising Router link states
  asbr-summary      ASBR Summary link states
  database-summary  Summary of database
  external          External link states
  network           Network link states
  nssa-external     NSSA External link states
  opaque-area       Opaque Area link states
  opaque-as         Opaque AS link states
  opaque-link       Opaque Link-Local link states
  router            Router link states
  self-originate    Self-originated link states
  summary           Network Summary link states
  |                 Output modifiers
  <cr>

Router Link State Advertisements (Type 1)

Type 1 LSAs are generated by each router for each area to which it belongs. The Router LSA lists the originating router’s router ID (RID). Each individual router will generate a Type 1 LSA for the area in which it resides. The Router LSAs are the first LSA types printed in the output of the show ip ospf database command.

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/BDRs do not establish adjacencies with each other, the Network LSA allows those routers to know about the other routers on the Multi-Access segment.

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 both inter-area and intra-area routing information. The Network Summary 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 LSA 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 nonbackbone areas for both intra-area (i.e., Area 0 Type 1 and Type 2 LSAs) and interarea routes (i.e., for the Type 3 LSAs flooded into the backbone by other ABRs).

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 will be described in the following sections. Type 7 LSAs will be described later in this module when we discuss the different types of OSPF areas.

ASBR Summary Link State Advertisements (Type 4)

The Type 4 LSA describes information regarding the 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 on 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 39.2:

Table 39.2 – Type 3 and Type 4 Summary LSAs

AS External 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.

OSPF Areas

In addition to the backbone (Area 0) and other non-backbone areas described and used in the examples in previous sections of this module, the OSPF specification also defines several “special” types of areas. The configuration of these areas is used primarily to reduce the size of the Link State Database on routers residing within those areas by preventing the injection of different types of LSAs (primarily Type 5 LSAs) into certain areas, which include the following:

• Not-so-stubby Areas
• Totally Not-so-stubby Areas
• Stub Areas
• Totally Stubby Areas

Not-so-stubby Areas (NSSAs)

Not-so-stubby Areas (NSSAs) are a type of OSPF Stub Area that allows the injection of external routing information by an ASBR using an NSSA External LSA (Type 7). As stated in the previous section, Type 4, Type 5, and Type 7 LSAs are used for external route calculation. We will not examine Type 7 LSAs in detail or how they are used in NSSAs.

Totally Not-so-stubby Areas (TNSSAs)

Totally Not-so-stubby Areas (TNSSAs) are an extension of NSSAs. Like NSSAs, Type 5 LSAs are not allowed into a TNSSA; unlike NSSAs, Summary LSAs are also not allowed into a TNSSA. In addition, when a TNSSA is configured, the default route is injected into the area as a Type 7 LSA. TNSSAs have the following characteristics:

• Type 7 LSAs are converted into Type 5 LSAs at the NSSA ABR
• They do not allow Network Summary LSAs
• They do not allow External LSAs
• The default route is injected as a Summary LSA

Stub Areas

Stub areas are somewhat similar to NSSAs, with the major exception being that external routes (Type 5 or Type 7) are not allowed into Stub Areas. It is important to understand that Stub functionality in OSPF and EIGRP is not at all similar. In OSPF, the configuration of an area as a Stub Area reduces the size of the routing table and the OSPF database for the routers within the Stub Area by preventing external LSAs from being advertised into such areas without any further configuration. Stub Areas have the following characteristics:

• The default route is injected into the Stub Area by the ABR as a Type 3 LSA
• Type 3 LSAs from other areas are permitted into these areas
• External route LSAs (i.e., Type 4 and Type 5 LSAs) are not allowed

Totally Stubby Areas

Totally Stubby Areas (TSAs) are an extension of Stub Areas. However, unlike Stub Areas, TSAs further reduce the size of the LSDB on routers in the TSA by restricting Type 3 LSAs, in addition to the external LSAs. TSAs are typically configured on routers that have a single ingress and egress point into the network, for example in a traditional hub-and-spoke network. The area routers forward all external traffic to the ABR. The ABR is also the exit point for all backbone and inter-area traffic to the TSA, which has the following characteristics:

• The default route is injected into Stub Areas as a Type 3 Network Summary LSA
• Type 3, Type 4, and Type 5 LSAs from other areas are not permitted into these areas

Route Metrics and Best Route Selection

In the following sections, you will learn about the OSPF metric and how it is calculated.

Calculating the OSPF Metric

The OSPF metric is commonly referred to as the cost. The cost is derived from the bandwidth of a link using the formula 108 / bandwidth (in bps). This means that different links are assigned different cost values, depending on their bandwidth. Using this formula, the OSPF cost of a 10Mbps Ethernet interface would be calculated as follows:

• Cost = 108 / bandwidth (bps)
• Cost = 100 000 000 / 10 000 000
• Cost = 10

Using the same formula, the OSPF cost of a T1 link would be calculated as follows:

• Cost = 108 / bandwidth (bps)
• Cost = 100 000 000 / 1 544 000
• Cost = 64.77

NOTE: When calculating the OSPF metric, point math is not used. Therefore, any such values are always rounded down to the nearest integer. Regarding the previous example, the actual cost for a T1 link would be rounded down to 64.

The OSPF cost of an interface can be viewed using the show ip ospf interface [name] command, as was illustrated previously. The default reference bandwidth used in metric calculation can be viewed in the output of the show ip protocols command, as is illustrated in the following output:

R4#show ip protocols
Routing Protocol is “ospf 4”
  Outgoing update filter list for all interfaces is not se
  Incoming update filter list for all interfaces is not set
  Router ID 4.4.4.4
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    0.0.0.0 255.255.255.255 Area 2
Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    3.3.3.3              110      00:00:03
  Distance: (default is 110)

The default reference bandwidth used in OSPF cost calculation can be adjusted using the autocost reference-bandwidth <1-4294967> router configuration command and specifying the reference bandwidth value in Mbps. This is particularly important in networks that have links that have a bandwidth value over 100Mbps, for example, GigabitEthernet links. In such networks, the default value assigned to the GigabitEthernet link would be the same as that of a FastEthernet link. In most cases, this is certainly not desirable, especially if OSPF attempts to load balance across both links.

To prevent this skewed calculation of cost value, the auto-cost reference-bandwidth 1000 router configuration command should be issued on the router. This results in a recalculation of cost values on the router using the new reference bandwidth value. For example, following this configuration, the cost of a T1 link would be recalculated as follows:

• Cost = 109 / bandwidth (bps)
• Cost = 1 000 000 000 / 1 544 000
• Cost = 647.66

NOTE: Again, because the OSPF metric does not support point values, this would be rounded down to a metric value of simply 647, as illustrated in the following output:

R4#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
  Internet Address 10.0.2.4/24, Area 2
  Process ID 4, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 647
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 60, Wait 60, Retransmit 5
    oob-resync timeout 60
    Hello due in 00:00:01
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress Hello for 0 neighbor(s)

When the auto-cost reference-bandwidth 1000 router configuration command is issued, Cisco IOS software prints the following message indicating that this same value should be applied to all routers within the OSPF domain. This is illustrated in the following output:

R4(config)#router ospf 4
R4(config-router)#auto-cost reference-bandwidth 1000
% OSPF: Reference bandwidth is changed.
        Please ensure reference bandwidth is consistent across all routers.

While this may seem like an important warning, keep in mind that the use of this command simply affects the local router. It is not mandatory to configure it on all routers; however, for exam purposes, ensure that a consistent configuration is implemented on all routers.

Influencing OSPF Metric Calculation

The calculation of the OSPF metric can be directly influenced by performing the following:

• Adjusting the interface bandwidth using the bandwidth command
• Manually specifying a cost using the ip ospf cost command

The use of the bandwidth command was described in a previous module when we discussed EIGRP metric calculation. As stated earlier, the default OSPF cost is calculated by dividing the link bandwidth by a reference bandwidth of 108, or 100 Mbps. Either incrementing or decrementing the link bandwidth directly affects the OSPF cost for the particular link. This is typically a path control mechanism used to ensure that one path is preferred over another.

However, as was described in the previous module, the bandwidth command affects more than just the routing protocol. It is for this reason that the second method, manually specifying a cost value, is the recommended method for influencing OSPF metric calculation.

The ip ospf cost <1-65535> interface configuration command is used to manually specify the cost of a link. The lower the value, the greater the probability that the link will be preferred over other links to the same destination network but with higher cost values. The following example illustrates how to configure an OSPF cost of 5 for a Serial (T1) link:

R1(config)#interface Serial0/0
R1(config-if)#ip ospf cost 5
R1(config-if)#exit

This configuration can be validated using the show ip ospf interface [name] command, as illustrated in the following output:

R1#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
  Internet Address 10.0.0.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 5
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 4
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2
  Suppress Hello for 0 neighbor(s)

OSPF Default Routing

Unlike EIGRP, which supports several different ways of generating and advertising the default route, OSPF uses only the default-information originate [always] [metric <value>] [metrictype <1|2>] [route-map <name>] router configuration command to advertise dynamically the default route.

The default-information originate command used by itself will configure the router to advertise a default route only if a default route is already present in the routing table. However, the [always] keyword can be appended to this command to force the router to generate a default route, even when one does not exist in the routing table. This keyword should be used with caution, as it may result in the black-holing of traffic within the OSPF domain or the forwarding of packets for all unknown destinations to the configured router.

The [metric <value>] keyword is used to specify the route metric for the generated default route. The [metric-type <1|2>] keyword can be used to change the metric type for the default route. Finally, the [route-map <name>] keyword configures the router to generate a default route only if the conditions specified in the named route map are met.

The following configuration example illustrates how to configure an OSPF-enabled router to generate and advertise a default route if one already exists in the routing table. The existing default route can be a static route or even a default route from another routing protocol if multiple routing protocols have been configured on the router. The output below illustrates this configuration based on a configured static default route:

R4(config)#ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 172.16.4.254
R4(config)#router ospf 4
R4(config-router)#network 172.16.4.0 0.0.0.255 Area 2
R4(config-router)#default-information originate
R4(config-router)#exit

By default, the default route is advertised as a Type 5 LSA.

Configuring OSPF

Basic OSPF can be enabled on the router with one line of configuration, and then by adding the network statement that specifies on which interfaces you want to run OSPF, not necessarily networks you wish to advertise:

1. 1Router ospf 9 ← locally significant number
2. 2network 10.0.0.0 0.255.255.255 area 0

OSPF won’t become active until at least one interface is up/up, and remember that at least one area must be Area 0. A Sample OSPF network is illustrated in Figure 39.14 below:

Figure 39.14 – A Sample OSPF Network

Router A configuration:

router ospf 20
network 4.4.4.4 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
router-id 4.4.4.4

Router B configuration:

router ospf 22
network 172.16.1.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
router-id 192.168.1.2

Router C configuration:

router ospf 44
network 1.1.1.1 0.0.0.0 area 1
network 172.16.1.0 0.0.0.255 area 0
router-id 1.1.1.1
RouterC#show ip route
Gateway of last resort is not set
     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/129] via 172.16.1.1, 00:10:39, Serial0/0/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, Serial0/0/0
O     192.168.1.0/24 [110/128] via 172.16.1.1, 00:10:39, Serial0/0/0

Troubleshooting OSPF

Once again, Open Shortest Path First is an open-standard Link State routing protocol that advertises the state of its links. When a Link State router begins operating on a network link, information associated with that logical network is added to its local Link State Database (LSDB). The local router then sends Hello messages on its operational links to determine whether other Link State routers are operating on the interfaces as well. OSPF runs directly over Internet Protocol using IP number 89.

While it is not possible to delve into all potential OSPF problem scenarios, the sections to follow discuss some of the most common problem scenarios when OSPF is implemented as the IGP of choice.

Troubleshooting Neighbour Relationships

Routers running OSPF transition through several states before establishing an adjacency. These different states are the Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, and Full states. The preferred state for an OSPF adjacency is the Full state. This state indicates that the neighbours have exchanged their entire databases and both have the same view of the network. While the Full state is the preferred adjacency state, it is possible that during the adjacency establishment process, the neighbours get “stuck” in one of the other states. For this reason, it is important to understand what to look for in order to troubleshoot the issue.

The Neighbour Table Is Empty

There are several reasons why the OSPF neighbour table may be empty (i.e., why the output of the show ip ospf neighbor command might not yield any results). Common reasons are as follows:

• Basic OSPF misconfigurations
• Layer 1 and Layer 2 issues
• ACL filtering
• Interface misconfigurations

Basic OSPF misconfigurations span a broad number of things. These could include mismatched timers, area IDs, authentication parameters, and stub configuration, for example. A plethora of tools is available in Cisco IOS software to troubleshoot basic OSPF misconfigurations. For example, you could use the show ip protocols command to determine information (e.g., about OSPF-enabled networks); the show ip ospf command to determine area configuration and the interfaces per area; and the show ip ospf interface brief command to determine which interfaces reside in which area, and for which OSPF process IDs those interfaces have been enabled, assuming that OSPF has been enabled for the interface.

Another common misconfiguration is specifying the interface as passive. If this is so, then the interface will not send out Hello packets, and a neighbour relationship will not be established using that interface. You can verify which interfaces have been configured or specified as passive using either the show ip protocols or the show ip ospf interface commands. The following is a sample output of the latter command on a passive interface:

R1#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
  Internet Address 172.16.0.1/30, Area 0
  Process ID 1, Router ID 10.1.0.1, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    No Hellos (Passive interface)
  Supports Link-Local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

Finally, when enabling OSPF over NBMA technologies such as Frame Relay, remember that the neighbours must be defined statically, as OSPF does not use Multicast transmission for neighbour discovery for the default Non-Broadcast network type. This is a common reason for empty neighbour tables when implementing OSPF.

Layer 1 and Layer 2 issues can also result in no formation of OSPF neighbour relationships. Layer 1 and Layer 2 troubleshooting was described in detail in previous modules. Use commands such as the show interfaces command to check for interface status (i.e., line protocol), as well as any received errors on the interface. If the OSPF-enabled routers reside in a VLAN that spans multiple switches, verify that there is end-to-end connectivity within the VLAN and that all ports or interfaces are in the correct Spanning Tree states, for example.

ACL filtering is another common cause for adjacencies failing to establish. It is important to be familiar with the topology in order to troubleshoot such issues. For example, if the routers failing to establish an adjacency are connected via different physical switches, it may be that the ACL filtering is being implemented in the form of a VACL that has been configured on the switches for security purposes. A useful troubleshooting tool that may indicate that OSPF packets are being either blocked or discarded is the show ip ospf traffic command, which prints information on transmitted and sent OSPF packets as illustrated in the output below:

R1#show ip ospf traffic Serial0/0
    Interface Serial0/0
OSPF packets received/sent
    Invalid  Hellos   DB-des   LS-req   LS-upd   LS-ack   Total
Rx: 0        0        0        0        0        0        0
Tx: 0        6        0        0        0        0        6
OSPF header errors
  Length 0, Auth Type 0, Checksum 0, Version 0,
  Bad Source 0, No Virtual Link 0, Area Mismatch 0,
  No Sham Link 0, Self Originated 0, Duplicate ID 0,
  Hello 0, MTU Mismatch 0, Nbr Ignored 0,
  LLS 0, Unknown Neighbor 0, Authentication 0,
  TTL Check Fail 0,
OSPF LSA errors
  Type 0, Length 0, Data 0, Checksum 0,

In the output above, notice that the local router is sending OSPF Hello packets but is not receiving any. If the configuration on the routers is correct, check ACLs on the routers or intermediate devices to ensure that OSPF packets are not being filtered or discarded.

Another common reason for an empty neighbour table is interface misconfigurations. Similar to EIGRP, OSPF will not establish a neighbour relationship using secondary interface addresses. However, unlike EIGRP, OSPF will also not establish a neighbour relationship if interface subnet masks are not consistent.

EIGRP-enabled routers will establish neighbour relationships even if the interface subnet masks are different. For example, if two routers, one with an interface using the address 10.1.1.1/24 and another with an interface using the address 10.1.1.2/30 are configured in back-to-back EIGRP implementation, they will successfully establish a neighbour relationship. However, it should be noted that such implementations could cause routing loops between the routers. In addition to mismatched subnet masks, EIGRP-enabled routers also ignore Maximum Transmission Unit (MTU) configurations and establish neighbour relationships even if the interface MTU values are different. Use the show ip interfaces and show interfaces commands to verify IP address and mask configuration.

Troubleshooting Route Advertisement

As is the case with EIGRP, there may be times when you notice that OSPF is not advertising certain routes. For the most part, this is typically due to some misconfigurations versus a protocol failure. Some common reasons for this include the following:

• OSPF is not enabled on the interface(s)
• The interface(s) is/are down
• Interface addresses are in a different area
• OSPF misconfigurations

A common reason why OSPF does not advertise routes is that the network is not advertised via OSPF. In current Cisco IOS versions, networks can be advertised using the network router configuration command or the ip ospf interface configuration command. Regardless of the method used, the show ip protocols command can be used to view which networks OSPF is configured to advertise, as can be seen in the following output:

R2#show ip protocols
Routing Protocol is “ospf 1”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 2.2.2.2
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    10.2.2.0 0.0.0.128 Area 1
    20.2.2.0 0.0.0.255 Area 1
  Routing on Interfaces Configured Explicitly (Area 1):
    Loopback0
Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    1.1.1.1              110      00:00:17
  Distance: (default is 110)

Additionally, keep in mind that you can also use the show ip ospf interfaces command to find out for which interfaces OSPF has been enabled, among other things. In addition to network configuration, if the interface is down, OSPF will not advertise the route. You can use the show ip ospf interface command to determine the interface state, as follows:

R1#show ip ospf interface brief
Interface    PID   Area     IP Address/Mask   Cost  State  Nbrs F/C
Lo100        1     0        100.1.1.1/24      1     DOWN   0/0
Fa0/0        1     0        10.0.0.1/24       1     BDR    1/1

Referencing the output above, you can see that Loopback100 is in a DOWN state. Taking a closer look, you can see that the issue is because the interface has been administratively shut, as illustrated in the following output:

R1#show ip ospf interface Loopback100
Loopback100 is administratively down, line protocol is down
  Internet Address 100.1.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1
  Enabled by interface config, including secondary ip addresses
  Loopback interface is treated as a stub Host

If you debugged IP routing events using the debug ip routing command and then issued the no shutdown command under the Loopback100 interface, then you would see the following:

R1#debug ip routing
IP routing debugging is on
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface Loopback100
R1(config-if)#no shutdown
R1(config-if)#end
R1#
*Mar 18 20:03:34.687: RT: is_up: Loopback100 1 state: 4 sub state: 1 line: 0 has_route: False
*Mar 18 20:03:34.687: RT: SET_LAST_RDB for 100.1.1.0/24
 NEW rdb: is directly connected
*Mar 18 20:03:34.687: RT: add 100.1.1.0/24 via 0.0.0.0, connected metric [0/0]
*Mar 18 20:03:34.687: RT: NET-RED 100.1.1.0/24
*Mar 18 20:03:34.687: RT: interface Loopback100 added to routing table
...
[Truncated Output]

When multiple addresses are configured under an interface, all secondary addresses must be in the same area as the primary address; otherwise, OSPF will not advertise these networks. As an example, consider the network topology illustrated in Figure 39.15 below:

Figure 39.15 – OSPF Secondary Subnet Advertisement

Referencing Figure 39.15, routers R1 and R2 are connected via a back-to-back connection. These two routers share the 10.0.0.0/24 subnet. However, in addition, R1 has been configured with some additional (secondary) subnets under its FastEthernet0/0 interface so that the interface configuration on R1 is printed as follows:

R1#show running-config interface FastEthernet0/0
Building configuration...
Current configuration : 183 bytes
!
interface FastEthernet0/0
ip address 10.0.1.1 255.255.255.0 secondary
ip address 10.0.2.1 255.255.255.0 secondary
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
end

OSPF is enabled on both R1 and R2. The configuration implemented on R1 is as follows:

R1#show running-config | section ospf
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 10.0.0.1 0.0.0.0 Area 0
network 10.0.1.1 0.0.0.0 Area 1
network 10.0.2.1 0.0.0.0 Area 1

The configuration implemented on R2 is as follows:

R2#show running-config | section ospf
router ospf 2
router-id 2.2.2.2
log-adjacency-changes
network 10.0.0.2 0.0.0.0 Area 0

By default, because the secondary subnets have been placed into a different OSPF area on R1, they will not be advertised by the router. This can be seen on R2, which displays the following when the show ip route command is issued:

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0

To resolve this issue, the secondary subnets must also be assigned to Area 0, as follows:

R1(config)#router ospf 1
R1(config-router)#network 10.0.1.1 0.0.0.0 Area 0
*Mar 18 20:20:37.491: %OSPF-6-AREACHG: 10.0.1.1/32 changed from Area 1 to Area 0
R1(config-router)#network 10.0.2.1 0.0.0.0 Area 0
*Mar 18 20:20:42.211: %OSPF-6-AREACHG: 10.0.2.1/32 changed from Area 1 to Area 0
R1(config-router)#end

After this configuration change, the networks are now advertised to router R2, as follows:

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     10.0.0.0/24 is subnetted, 3 subnets
O       10.0.2.0 [110/2] via 10.0.0.1, 00:01:08, FastEthernet0/0
C       10.0.0.0 is directly connected, FastEthernet0/0
O       10.0.1.0 [110/2] via 10.0.0.1, 00:01:08, FastEthernet0/0

In addition to the three common causes described above, poor design, implementation, and misconfigurations are another reason OSPF may not advertise networks as expected. Common design issues that cause such issues include a discontiguous or partitioned backbone and area type misconfigurations, such as configuring areas as Totally Stubby, for example. For this reason, it is important to have a solid understanding of how the protocol works and how it has been implemented in your environment. This understanding will greatly simplify the troubleshooting process, as half the battle is already won before you even start troubleshooting the problem or issue.

Debugging OSPF Routing Issues

In the final section of this module, we will look at some of the more commonly used OSPF debugging commands. OSPF debugging is enabled using the debug ip ospf command. This command can be used in conjunction with the following additional keywords:

R1#debug ip ospf ?
adj             OSPF adjacency events
database-timer  OSPF database timer
events          OSPF events
flood           OSPF flooding
hello           OSPF hello events
lsa-generation  OSPF lsa generation
mpls            OSPF MPLS
nsf             OSPF non-stop forwarding events
packet          OSPF packets
retransmission  OSPF retransmission events
spf             OSPF spf
tree            OSPF database tree

The debug ip ospf adj command prints real-time information on adjacency events. This is a useful troubleshooting tool when troubleshooting OSPF neighbour adjacency problems. Following is a sample of the information that is printed by this command. The example below illustrates how this command can be used to determine that an MTU mismatch is preventing the neighbour adjacency from reaching the Full state:

R1#debug ip ospf adj
OSPF adjacency events debugging is on
R1#
*Mar 18 23:13:21.279: OSPF: DR/BDR election on FastEthernet0/0
*Mar 18 23:13:21.279: OSPF: Elect BDR 2.2.2.2
*Mar 18 23:13:21.279: OSPF: Elect DR 1.1.1.1
*Mar 18 23:13:21.279:        DR: 1.1.1.1 (Id)   BDR: 2.2.2.2 (Id)
*Mar 18 23:13:21.283: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar 18 23:13:21.283: OSPF: DR/BDR election on FastEthernet0/0
*Mar 18 23:13:21.283: OSPF: Elect BDR 2.2.2.2
*Mar 18 23:13:21.283: OSPF: Elect DR 1.1.1.1
*Mar 18 23:13:21.283:        DR: 1.1.1.1 (Id)   BDR: 2.2.2.2 (Id)
*Mar 18 23:13:21.283: OSPF: Rcv DBD from 2.2.2.2 on FastEthernet0/0 seq 0xA65 opt 0x52 flag 0x7 len 32  mtu 1480 state EXSTART
*Mar 18 23:13:21.283: OSPF: Nbr 2.2.2.2 has smaller interface MTU
*Mar 18 23:13:21.283: OSPF: NBR Negotiation Done. We are the SLAVE
*Mar 18 23:13:21.287: OSPF: Send DBD to 2.2.2.2 on FastEthernet0/0 seq 0xA65 opt 0x52 flag 0x2 len 192
*Mar 18 23:13:26.275: OSPF: Rcv DBD from 2.2.2.2 on FastEthernet0/0 seq 0xA65 opt 0x52 flag 0x7 len 32  mtu 1480 state EXCHANGE
*Mar 18 23:13:26.279: OSPF: Nbr 2.2.2.2 has smaller interface MTU
*Mar 18 23:13:26.279: OSPF: Send DBD to 2.2.2.2 on FastEthernet0/0 seq 0xA65 opt 0x52 flag 0x2 len 192
...
[Truncated Output]

From the output above, you can conclude that the MTU on the local router is larger than 1480 bytes because the debug output shows that the neighbour has the smaller MTU value. The recommended solution would be to adjust the smaller MTU value so that both neighbours have the same interface MTU values. This will allow the adjacency to reach the Full state.

The debug ip ospf lsa-generation command prints information on OSPF LSAs. This command can be used to troubleshoot route advertisement when using OSPF. Following is a sample output of the information that is printed by this command:

R1#debug ip ospf lsa-generation
OSPF summary lsa generation debugging is on
R1#
R1#
*Mar 18 23:25:59.447: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from FULLto DOWN, Neighbor Down: Interface down or detached
*Mar 18 23:25:59.511: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 fromLOADING to FULL, Loading Done
*Mar 18 23:26:00.491: OSPF: Start redist-scanning
*Mar 18 23:26:00.491: OSPF: Scan the RIB for both redistribution and translation
*Mar 18 23:26:00.499: OSPF: max-aged external LSA for summary 150.0.0.0 255.255.0.0,scope: Translation
*Mar 18 23:26:00.499: OSPF: End scanning, Elapsed time 8ms
*Mar 18 23:26:00.499: OSPF: Generate external LSA 192.168.4.0, mask 255.255.255.0, type5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000001
*Mar 18 23:26:00.503: OSPF: Generate external LSA 192.168.5.0, mask 255.255.255.0, type5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000001
*Mar 18 23:26:00.503: OSPF: Generate external LSA 192.168.1.0, mask 255.255.255.0, type5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000001
*Mar 18 23:26:00.503: OSPF: Generate external LSA 192.168.2.0, mask 255.255.255.0, type5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000001
*Mar 18 23:26:00.507: OSPF: Generate external LSA 192.168.3.0, mask 255.255.255.0, type5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000001
*Mar 18 23:26:05.507: OSPF: Generate external LSA 192.168.4.0, mask 255.255.255.0, type5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000006
*Mar 18 23:26:05.535: OSPF: Generate external LSA 192.168.5.0, mask 255.255.255.0, type5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000006

The debug ip ospf spf command provides real-time information about Shortest Path First algorithm events. This command can be used in conjunction with the following keywords:

R1#debug ip ospf spf ?
  external   OSPF spf external-route
  inter      OSPF spf inter-route
  intra      OSPF spf intra-route
  statistic  OSPF spf statistics
  <cr>

As is the case with all debug commands, consideration should be given to factors such as the size of the network and the resource utilisation on the router before debugging SPF events. The following is a sample of the output from the debug ip ospf spf statistic command:

R1#debug ip ospf spf statistic
OSPF spf statistic debugging is on
R1#clear ip ospf process
Reset ALL OSPF processes? [no]: y
R1#
*Mar 18 23:37:27.795: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 18 23:37:27.859: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Mar 18 23:37:32.859: OSPF: Begin SPF at 28081.328ms, process time 608ms
*Mar 18 23:37:32.859:       spf_time 07:47:56.328, wait_interval 5000ms
*Mar 18 23:37:32.859: OSPF: End SPF at 28081.328ms, Total elapsed time 0ms
*Mar 18 23:37:32.859:       Schedule time 07:48:01.328, Next wait_interval 10000ms
*Mar 18 23:37:32.859:       Intra: 0ms, Inter: 0ms, External: 0ms
*Mar 18 23:37:32.859:       R: 2, N: 1, Stubs: 2
*Mar 18 23:37:32.859:       SN: 0, SA: 0, X5: 0, X7: 0
*Mar 18 23:37:32.863:       SPF suspends: 0 intra, 0 total

NOTE: Prior to enabling SPF debug commands, consider using show commands first, such as the show ip ospf statistics and show ip ospf commands, when beginning the troubleshooting process.

Section 39 Questions

1. OSPF operates over IP number _______.
2. OSPF does NOT support VLSM. True or false?
3. Any router which connects to Area 0 and another area is referred to as an _______ _______ _______ or _______.
4. If you have a DR, you must always have a BDR. True or false?
5. The DR/BDR election is based on which two factors?
6. By default, all routers have a default priority value of _______. This value can be adjusted using the _______ _______ _______ <0-255> interface configuration command.
7. When determining the OSPF router ID, Cisco IOS selects the highest IP address of configured Loopback interfaces. True or false?
8. What roles do the DR and the BDR carry out?
9. Which command would put network 10.0.0.0/8 into Area 0 on a router?
10. Which command would set the router ID to 1.1.1.1?
11. Name the common troubleshooting issues for OSPF.

Section 39 Answers

1. 89.
2. False.
3. Area Border Router or ABR.
4. False.
5. The highest router priority and the highest router ID.
6. 1, ip ospf priority.
7. True.
8. To reduce the number of adjacencies required on the segment; to advertise the routers on the Multi-Access segment; and to ensure that updates are sent to all routers on the segment.
9. The network 10.0.0.0 0.255.255.255 area 0 command.
10. The router-id 1.1.1.1 command.
11. Neighbour relationships and route advertisement.

Section 39 Lab

OSPF Lab

Topology

Purpose

Learn how to configure basic OSPF.

Walkthrough

1. 1Configure all IP addresses based on the topology above. Make sure you can ping across the Serial link.
2. 2Add OSPF to Router A. Put the network on Loopback0 into Area 1 and the 10 network into Area 0.

RouterA(config)#router ospf 4
RouterA(config-router)#network 172.20.1.0 0.0.0.255 area 1
RouterA(config-router)#network 10.0.0.0 0.0.0.3 area 0
RouterA(config-router)#^Z
RouterA#
%SYS-5-CONFIG_I: Configured from console by console
RouterA#show ip protocols
Routing Protocol is “ospf 4”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 172.20.1.1
  Number of areas in this router is 2. 2 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    172.20.1.0 0.0.0.255 area 1
    10.0.0.0 0.0.0.3 area 0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.20.1.1           110      00:00:09
  Distance: (default is 110)

3. Add OSPF on Router B. Put the Loopback network into OSPF Area 40.

RouterB(config)#router ospf 2
RouterB(config-router)#net 10.0.0.0 0.0.0.3 area 0
RouterB(config-router)#
00:22:35: %OSPF-5-ADJCHG: Process 2, Nbr 172.20.1.1 on Serial0/1/0 from LOADING to FULL,
Loading Done
RouterB(config-router)#net 192.168.1.0 0.0.0.63 area 40

RouterB(config-router)#  ^Z
RouterB#show ip protocols
Routing Protocol is “ospf 2”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 192.168.1.1
  Number of areas in this router is 2. 2 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    10.0.0.0 0.0.0.3 area 0
    192.168.1.0 0.0.0.63 area 40
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.20.1.1           110      00:01:18
    192.168.1.1          110      00:00:44
  Distance: (default is 110)

4. Check the routing table on your routers. Look for the OSPF advertised network. You will see an IA, which means IA – OSPF inter-area. You will also see the AD for OSPF, which is 110.

RouterA#sh ip route
...
[Truncated Output]
        10.0.0.0/30 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Serial0/1/0
        172.20.0.0/24 is subnetted, 1 subnets
C       172.20.1.0 is directly connected, Loopback0
        192.168.1.0/32 is subnetted, 1 subnets
O IA    192.168.1.1 [110/65] via 10.0.0.2, 00:01:36, Serial0/1/0
RouterA#

5. Issue some of the available OSPF commands on either router.

RouterA#sh ip ospf ?
<1-65535>       Process ID number
border-routers  Border and Boundary Router Information
database        Database summary
interface       Interface information
neighbor        Neighbor list