Chapter 8: Single-Area OSPF

Open Shortest Path First (OSPF) is a link-state routing protocol that was developed as an alternative for the distance vector routing protocol, RIP. RIP was an acceptable routing protocol in the early days of networking and the Internet. However, RIP's reliance on hop count as the only metric for determining best route quickly became problematic. Using hop count does not scale well in larger networks with multiple paths of varying speeds. OSPF has significant advantages over RIP in that it offers faster convergence and scales to much larger network implementations.

OSPF is a classless routing protocol that uses the concept of areas for scalability. This chapter covers basic, single-area OSPF implementations and configurations.

1. Evolution of OSPF

As shown in Figure 1, OSPF version 2 (OSPFv2) is available for IPv4 while OSPF version 3 (OSPFv3) is available for IPv6.

Click the dates in Figure 2 to see historical events related to OSPF.

The initial development of OSPF began in 1987 by the Internet Engineering Task Force (IETF) OSPF Working Group. At that time, the Internet was largely an academic and research network funded by the U.S. government.

In 1989, the specification for OSPFv1 was published in RFC 1131. Two implementations were written. One implementation was developed to run on routers and the other to run on UNIX workstations. The latter implementation became a widespread UNIX process known as GATED. OSPFv1 was an experimental routing protocol and was never deployed.

In 1991, OSPFv2 was introduced in RFC 1247 by John Moy. OSPFv2 offered significant technical improvements over OSPFv1. It is classless by design; therefore, it supports VLSM and CIDR.

At the same time the OSPF was introduced, ISO was working on a link-state routing protocol of their own, Intermediate System-to-Intermediate System (IS-IS). IETF chose OSPF as their recommended Interior Gateway Protocol (IGP).

In 1998, the OSPFv2 specification was updated in RFC 2328, which remains the current RFC for OSPF.

In 1999, OSPFv3 for IPv6 was published in RFC 2740. OSPF for IPv6, created by John Moy, Rob Coltun, and Dennis Ferguson, is not only a new protocol implementation for IPv6, but also a major rewrite of the operation of the protocol.

In 2008, OSPFv3 was updated in RFC 5340 as OSPF for IPv6.

In 2010, the support of the Address Families (AF) feature in OSPFv3 was introduced with RFC 5838. The use of address families allows a routing protocol to support both IPv4 and IPv6 within a single unified configuration process. OSPFv3 with address families is beyond the scope of this curriculum.

Note: In this chapter, unless explicitly identified as OSPFv2 or OSPFv3, the term OSPF is used to indicate concepts that are shared by both.

2. Features of OSPF

OSPF features, as shown in Figure 1, include:

• Classless - OSPFv2 is classless by design; therefore, it supports IPv4 VLSM and CIDR.

• Efficient - Routing changes trigger routing updates (no periodic updates). It uses the SPF algorithm to choose the best path.

• Fast convergence - It quickly propagates network changes.

• Scalable - It works well in small and large network sizes. Routers can be grouped into areas to support a hierarchical system.

• Secure - OSPFv2 supports Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) authentication. OSPFv3 uses Internet Protocol Security (IPsec) to add authentication for OSPFv3 packets. When authentication is enabled, OSPF routers only accept encrypted routing updates from peers with the same pre-shared password.

Administrative distance (AD) is the trustworthiness (or preference) of the route source. OSPF has a default administrative distance of 110. As shown in Figure 2, OSPF has a lower number (making it a preferred routing protocol over IS-IS and RIP) on Cisco devices.

3. Components of OSPF

All routing protocols share similar components. They all use routing protocol messages to exchange route information. The messages help build data structures, which are then processed using a routing algorithm.

The three main components of the OSPF routing protocol include:

Data Structures

OSPF creates and maintains three databases: (see Figure 1).

• Adjacency database - Creates the neighbor table.

• Link-state database (LSDB) - Creates the topology table.

• Forwarding database - Creates the routing table.

These tables contain a list of neighboring routers to exchange routing information with and are kept and maintained in RAM.

Routing Protocol Messages

Layer 3 devices (such as routers) running OSPF exchange messages to convey routing information using five types of packets. These packets, as shown in Figure 2, are:

• Hello packet

• Database description packet

• Link-state request packet

• Link-state update packet

• Link-state acknowledgment packet

These packets are used to discover neighboring routers and also to exchange routing information to maintain accurate information about the network.

Algorithm

The router builds the topology table using results of calculations based on the Dijkstra SPF algorithm. The SPF algorithm is based on the cumulative cost to reach a destination.

The SPF algorithm creates an SPF tree by placing each router at the root of the tree and calculating the shortest path to each node. The SPF tree is then used to calculate the best routes. OSPF places the best routes into the forwarding database, which is used to make the routing table.

4. Link-State Operation

To maintain routing information, OSPF routers complete the following generic link-state routing process to reach a state of convergence:

1. Establish Neighbor Adjacencies (Figure 1) - OSPF-enabled routers must recognize each other on the network before they can share information. An OSPF-enabled router sends Hello packets out all OSPF-enabled interfaces to determine if neighbors are present on those links. If a neighbor is present, the OSPF-enabled router attempts to establish a neighbor adjacency with that neighbor.

2. Exchange Link-State Advertisements (Figure 2) - After adjacencies are established, routers then exchange link-state advertisements (LSAs). LSAs contain the state and cost of each directly connected link. Routers flood their LSAs to adjacent neighbors. Adjacent neighbors receiving the LSA immediately flood the LSA to other directly connected neighbors, until all routers in the area have all LSAs.

3. Build the Topology Table (Figure 3) - After LSAs are received, OSPF-enabled routers build the topology table (LSDB) based on the received LSAs. This database eventually holds all the information about the topology of the network.

4. Execute the SPF Algorithm (Figures 4 and 5) - Routers then execute the SPF algorithm. The gears in the figure are used to indicate the execution of the SPF algorithm. The SPF algorithm creates the SPF tree.

The contents of the R1 SPF tree are displayed in Figure 6.

From the SPF tree, the best paths are offered to the IP routing table. The route will be inserted into the routing table unless there is a route source to the same network with a lower administrative distance, such as a static route. Routing decisions are made based on the entries in the routing table.

5. Single-Area and Multiarea OSPF

To make OSPF more efficient and scalable, OSPF supports hierarchical routing using areas. An OSPF area is a group of routers that share the same link-state information in their LSDBs.

OSPF can be implemented in one of two ways:

• Single-Area OSPF - In Figure 1, all routers are in one area called the backbone area (area 0).

• Multiarea OSPF - In Figure 2, OSPF is implemented using multiple areas, in a hierarchal fashion. All areas must connect to the backbone area (area 0). Routers interconnecting the areas are referred to as Area Border Routers (ABRs).

With multiarea OSPF, OSPF can divide one large routing domain into smaller areas, to support hierarchical routing. With hierarchical routing, routing still occurs between the areas (interarea routing), while many of the processor intensive routing operations, such as recalculating the database, are kept within an area.

For instance, any time a router receives new information about a topology change within the area (including the addition, deletion, or modification of a link) the router must rerun the SPF algorithm, create a new SPF tree, and update the routing table. The SPF algorithm is CPU-intensive and the time it takes for calculation depends on the size of the area.

Note: Routers in other areas receive messages regarding topology changes, but these routers only update the routing table, not rerun the SPF algorithm.

Too many routers in one area would make the LSDBs very large and increase the load on the CPU. Therefore, arranging routers into areas effectively partitions a potentially large database into smaller and more manageable databases.

The hierarchical-topology design options with multiarea OSPF can offer these advantages:

• Smaller routing tables - Fewer routing table entries because network addresses can be summarized between areas. Route summarization is not enabled by default.

• Reduced link-state update overhead - Designing multiarea OSPF with smaller areas minimizes processing and memory requirements.

• Reduced frequency of SPF calculations - Localizes the impact of a topology change within an area. For instance, it minimizes routing update impact because LSA flooding stops at the area boundary.

Figure 3 illustrates these advantages.

For example, R2 is an ABR for area 51. As an ABR, it would summarize the area 51 routes into area 0. When one of the summarized links fails, LSAs are exchanged within area 51 only. Routers in area 51 must rerun the SPF algorithm to identify the best routes. However, the routers in area 0 and area 1 do not receive any updates; therefore, they do not execute the SPF algorithm.

The focus of this chapter is on single-area OSPF.

6. Encapsulating OSPF Messages

OSPFv2 messages transmitted over an Ethernet link contain the following information:

• Data Link Ethernet Frame Header - Identifies the destination multicast MAC addresses 01-00-5E-00-00-05 or 01-00-5E-00-00-06 when encapsulating an OSPFv2 message. (Figure 1)

• IPv4 Packet Header -Identifies the IP source address and destination address. The destination address is one of two OSPFv2 multicast addresses, 224.0.0.5 or 224.0.0.6. The header also contains a protocol field which will contain the code of 89 for OSPF. (Figure 2)

• OSPF Packet Header - Identifies the OSPF packet type, the router ID and the area ID. (Figure 3)

• OSPF Packet Type Specific Data - Contains the OSPF packet type information. The content differs depending on the packet type. (Figure 4)

7. Types of OSPF Packets

OSPF uses link-state packets (LSPs) to establish and maintain neighbor adjacencies and exchange routing updates.

The figure shows the five different types of LSPs used by OSPFv2. OSPFv3 has similar packet types. Each packet serves a specific purpose in the OSPF routing process:

• Type 1: Hello packet - Used to establish and maintain adjacency with other OSPF routers.

• Type 2: Database Description (DBD) packet - Contains an abbreviated list of the sending router’s LSDB and is used by receiving routers to check against the local LSDB. The LSDB must be identical on all link-state routers within an area to construct an accurate SPF tree.

• Type 3: Link-State Request (LSR) packet - Receiving routers can then request more information about any entry in the DBD by sending an LSR.

• Type 4: Link-State Update (LSU) packet - Used to reply to LSRs and to announce new information. LSUs contain seven different types of LSAs.

• Type 5: Link-State Acknowledgment (LSAck) packet - When an LSU is received, the router sends an LSAck to confirm receipt of the LSU. The LSAck data field is empty.

8. Hello Packet

ello Packet

The OSPF Type 1 packet is the Hello packet. Hello packets are used to:

• Discover OSPF neighbors and establish neighbor adjacencies.

• Advertise parameters on which two routers must agree to become neighbors.

• Elect the Designated Router (DR) and Backup Designated Router (BDR) on multiaccess networks like Ethernet and Frame Relay. Point-to-point links do not require DR or BDR.

The figure displays the fields contained in the OSPFv2 Type 1 Hello packet. Important fields shown in the figure include:

• Type - Identifies the type of packet. A one (1) indicates a Hello packet. A value 2 identifies a DBD packet, 3 an LSR packet, 4 an LSU packet, and 5 an LSAck packet.

• Router ID - A 32-bit value expressed in dotted decimal notation (like an IPv4 address) used to uniquely identify the originating router.

• Area ID – Number of the area from which the packet originated.

• Network Mask - Subnet mask associated with the sending interface.

• Hello Interval - Specifies the frequency, in seconds, at which a router sends Hello packets. The default Hello interval on multiaccess networks is 10 seconds. This timer must be the same on neighboring routers; otherwise, an adjacency is not established.

• Router Priority - Used in a DR/BDR election. The default priority for all OSPF routers is 1, but can be manually altered from 0 to 255. The higher the value, the more likely the router becomes the DR on the link.

• Dead Interval - Is the time in seconds that a router waits to hear from a neighbor before declaring the neighboring router out of service. By default, the router Dead Interval is four times the Hello interval. This timer must be the same on neighboring routers; otherwise, an adjacency is not established.

• Designated Router (DR) - Router ID of the DR.

• Backup Designated Router (BDR) - Router ID of the BDR.

• List of Neighbors - List that identifies the router IDs of all adjacent routers.

Click each of the highlighted fields in the figure for more information.

9. Hello Packet Intervals

As shown in the figure, OSPF Hello packets are transmitted to multicast address 224.0.0.5 in IPv4 and FF02::5 in IPv6 (all OSPF routers) every:

• 10 seconds (default on multiaccess and point-to-point networks)

• 30 seconds (default on non-broadcast multiple access [NBMA] networks; for example, Frame Relay)

The Dead interval is the period that the router waits to receive a Hello packet before declaring the neighbor down. If the Dead interval expires before the routers receive a Hello packet, OSPF removes that neighbor from its LSDB. The router floods the LSDB with information about the down neighbor out all OSPF-enabled interfaces.

Cisco uses a default of 4 times the Hello interval:

• 40 seconds (default on multiaccess and point-to-point networks)

• 120 seconds (default on NBMA networks; for example, Frame Relay)

10. Link-State Updates

Routers initially exchange Type 2 DBD packets, which is an abbreviated list of the sending router’s LSDB and is used by receiving routers to check against the local LSDB.

A Type 3 LSR packet is used by the receiving routers to request more information about an entry in the DBD.

The Type 4 LSU packet is used to reply to an LSR packet.

A Type 5 packet is used to acknowledge the receipt of a Type 4 LSU.

LSUs are also used to forward OSPF routing updates, such as link changes. Specifically, an LSU packet can contain 11 different types of OSPFv2 LSAs, as shown in the figure. OSPFv3 renamed several of these LSAs and also contains two additional LSAs.

Note: The difference between the LSU and LSA terms can sometimes be confusing because these terms are often used interchangeably. However, an LSU contains one or more LSAs.

11. Establish Neighbor Adjacencies

When OSPF is enabled on an interface, the router must determine if there is another OSPF neighbor on the link. To accomplish this, the router forwards a Hello packet that contains its router ID out all OSPF-enabled interfaces. The OSPF router ID is used by the OSPF process to uniquely identify each router in the OSPF area. A router ID is a 32-bit number formatted like an IP address and assigned to uniquely identify a router among OSPF peers.

When a neighboring OSPF-enabled router receives a Hello packet with a router ID that is not within its neighbor list, the receiving router attempts to establish an adjacency with the initiating router.

Refer to R1 in Figure 1. When OSPFv2 is enabled, the enabled Gigabit Ethernet 0/0 interface transitions from the Down state to the Init state. R1 starts sending Hello packets out all OSPF-enabled interfaces to discover OSPF neighbors to develop adjacencies with.

In Figure 2, R2 receives the Hello packet from R1 and adds the R1 router ID to its neighbor list. R2 then sends a Hello packet to R1. The packet contains the R2 Router ID and the R1 Router ID in its list of neighbors on the same interface.

In Figure 3, R1 receives the Hello and adds the R2 Router ID in its list of OSPF neighbors. It also notices its own Router ID in the Hello packet’s list of neighbors. When a router receives a Hello packet with its Router ID listed in the list of neighbors, the router transitions from the Init state to the Two-Way state.

The action performed in Two-Way state depends on the type of inter-connection between the adjacent routers:

• If the two adjacent neighbors are interconnected over a point-to-point link, then they immediately transition from the Two-Way state to the database synchronization phase.

• If the routers are interconnected over a common Ethernet network, then a designated router DR and a BDR must be elected.

Because R1 and R2 are interconnected over an Ethernet network, a DR and BDR election takes place. As shown in Figure 4, R2 becomes the DR and R1 is the BDR. This process only occurs on multi-access networks such as Ethernet LANs.

Hello packets are continually exchanged to maintain router information.

12. OSPF DR and BDR

Why is a DR and BDR election necessary?

Multiaccess networks can create two challenges for OSPF regarding the flooding of LSAs:

• Creation of multiple adjacencies - Ethernet networks could potentially interconnect many OSPF routers over a common link. Creating adjacencies with every router is unnecessary and undesirable. It would lead to an excessive number of LSAs exchanged between routers on the same network.

• Extensive flooding of LSAs - Link-state routers flood their LSAs any time OSPF is initialized, or when there is a change in the topology. This flooding can become excessive.

To understand the problem with multiple adjacencies, we must study a formula:

For any number of routers (designated as n) on a multiaccess network, there are n (n – 1) / 2 adjacencies.

Figure 1 shows a simple topology of five routers, all of which are attached to the same multiaccess Ethernet network. Without some type of mechanism to reduce the number of adjacencies, collectively these routers would form 10 adjacencies:

5 (5 – 1) / 2 = 10

This may not seem like much, but as routers are added to the network, the number of adjacencies increases dramatically, as shown in Figure 2.

To understand the problem of extensive flooding of LSAs, play the animation in Figure 3. In the animation, R2 sends out an LSA. This event triggers every other router to also send out an LSA. Not shown in the animation are the required acknowledgments sent for every LSA received. If every router in a multiaccess network had to flood and acknowledge all received LSAs to all other routers on that same multiaccess network, the network traffic would become quite chaotic.

The solution to managing the number of adjacencies and the flooding of LSAs on a multiaccess network is the DR. On multiaccess networks, OSPF elects a DR to be the collection and distribution point for LSAs sent and received. A BDR is also elected in case the DR fails. All other routers become DROTHERs. A DROTHER is a router that is neither the DR nor the BDR.

Note: The DR is only used for the dissemination of LSAs. The router will still use the best next-hop router indicated in the routing table for the forwarding of all other packets.

Play the animation in Figure 4 to see the role of DR.

13. Synchronizing OSPF Databases

After the Two-Way state, routers transition to database synchronization states. While the Hello packet was used to establish neighbor adjacencies, the other four types of OSPF packets are used during the process of exchanging and synchronizing LSDBs.

In the ExStart state, the two routers decide which router will send the DBD packets first. The router with the higher router ID will be the first router to send DBD packets during the Exchange state. In Figure 1, R2 has the higher router ID and sends it’s DBD packets first.

In the Exchange state, the two routers exchange one or more DBD packets. A DBD packet includes information about the LSA entry header that appears in the router’s LSDB. The entries can be about a link or about a network. Each LSA entry header includes information about the link-state type, the address of the advertising router, the link’s cost, and the sequence number. The router uses the sequence number to determine the newness of the received link-state information.

In Figure 2, R2 sends a DBD packet to R1. When R1 receives the DBD, it performs the following actions:

1. It acknowledges the receipt of the DBD using the LSAck packet.

2. R1 then sends DBD packets to R2.

3. R2 acknowledges R1.

R1 compares the information received with the information it has in its own LSDB. If the DBD packet has a more current link-state entry, the router transitions to the Loading state.

For example, in Figure 3, R1 sends an LSR regarding network 172.16.6.0 to R2. R2 responds with the complete information about 172.16.6.0 in an LSU packet. Again, when R1 receives an LSU, it sends an LSAck. R1 then adds the new link-state entries into its LSDB.

After all LSRs have been satisfied for a given router, the adjacent routers are considered synchronized and in a full state.

As long as the neighboring routers continue receiving Hello packets, the network in the transmitted LSAs remain in the topology database. After the topological databases are synchronized, updates (LSUs) are sent only to neighbors:

• When a change is perceived (incremental updates)

• Every 30 minutes

14. OSPF Network Topology

Introduced in 1991, OSPFv2 is a link-state routing protocol for IPv4. OSPF was designed as an alternative to another IPv4 routing protocol, RIP.

The figure shows the topology used for configuring OSPFv2 in this section. The types of serial interfaces and their associated bandwidths may not necessarily reflect the more common types of connections found in networks today. The bandwidths of the serial links used in this topology were chosen to help explain the calculation of the routing protocol metrics and the process of best path selection.

The routers in the topology have a starting configuration, including interface addresses. There is currently no static routing or dynamic routing configured on any of the routers. All interfaces on routers R1, R2, and R3 (except the loopback on R2) are within the OSPF backbone area. The ISP router is used as the routing domain’s gateway to the Internet.

Note: In this topology the loopback interface is used to simulate the WAN link to the Internet.

15. Router OSPF Configuration Mode

Figure 1 is the reference topology for this topic. OSPFv2 is enabled using the router ospf process-id global configuration mode command. The process-id value represents a number between 1 and 65,535 and is selected by the network administrator. The process-id value is locally significant, which means that it does not have to be the same value on the other OSPF routers to establish adjacencies with those neighbors.

Figure 2 provides an example of entering router OSPFv2 configuration mode on R1.

Note: The list of commands has been altered to display only the commands that are used in this chapter. For a complete list of commands, use the Syntax Checkers in Figure 3.

Use the Syntax Checker in Figure 3 to enter OSPFv2 router configuration mode on R2 and list the commands available at the prompt.

16. Router IDs

Every router requires a router ID to participate in an OSPF domain. The router ID can be defined by an administrator or automatically assigned by the router. The router ID is used by the OSPF-enabled router to:

• Uniquely identify the router - The router ID is used by other routers to uniquely identify each router within the OSPF domain and all packets that originate from them.

• Participate in the election of the DR - In a multiaccess LAN environment, the election of the DR occurs during initial establishment of the OSPF network. When OSPF links become active, the routing device configured with the highest priority is elected the DR. Assuming there is no priority configured, or there is a tie, then the router with the highest router ID is elected the DR. The routing device with the second highest router ID is elected the BDR.

But how does the router determine the router ID? As illustrated in the figure, Cisco routers derive the router ID based on one of three criteria, in the following preferential order:

• The router ID is explicitly configured using the OSPF router-id rid router configuration mode command. The rid value is any 32-bit value expressed as an IPv4 address. This is the recommended method to assign a router ID.

• If the router ID is not explicitly configured, the router chooses the highest IPv4 address of any of configured loopback interfaces. This is the next best alternative to assigning a router ID.

• If no loopback interfaces are configured, then the router chooses the highest active IPv4 address of any of its physical interfaces. This is the least recommended method because it makes it more difficult for administrators to distinguish between specific routers.

If the router uses the highest IPv4 address for the router ID, the interface does not need to be OSPF-enabled. This means that the interface address does not need to be included in one of the OSPFnetwork commands for the router to use that IPv4 address as the router ID. The only requirement is that the interface is active and in the up state.

Note: The router ID looks like an IPv4 address, but it is not routable and, therefore, is not included in the routing table, unless the OSPF routing process chooses an interface (physical or loopback) that is appropriately defined by anetwork command.

17. Configuring an OSPF Router ID

se the router-id rid router configuration mode command to manually assign a 32-bit value expressed as an IPv4 address to a router. An OSPF router identifies itself to other routers using this router ID.

As shown in Figure 1, R1 is configured with a router ID of 1.1.1.1, R2 with 2.2.2.2, and R3 with 3.3.3.3.

In Figure 2, the router ID 1.1.1.1 is assigned to R1. Use the show ip protocols command to verify the router ID.

Note: R1 had never been configured with an OSPF router ID. If it had, then the router ID would have to be modified.

If the router ID is the same on two neighboring routers, the router displays an error message similar to the one below:

%OSPF-4-DUP_RTRID1: Detected router with duplicate router ID.

To correct this problem, configure all routers so that they have unique OSPF router IDs.

Use the Syntax Checker in Figure 3 to assign a router ID to R2 and R3.

18. Modifying a Router ID

Sometimes a router ID needs to be changed, for example, when a network administrator establishes a new router ID scheme for the network. However, after a router selects a router ID, an active OSPFv2 router does not allow the router ID to be changed until the router is reloaded or the OSPFv2 process cleared.

In Figure 1, notice that the current router ID is 192.168.10.5. The router ID should be 1.1.1.1.

In Figure 2, the router ID 1.1.1.1 is being assigned to R1. Notice how an informational message appears stating that the OSPFv2 process must be cleared or that the router must be reloaded. The reason is because R1 already has adjacencies with other neighbors using the router ID 192.168.10.5. Those adjacencies must be renegotiated using the new router ID 1.1.1.1.

Clearing the OSPF process is the preferred method to reset the router ID.

In Figure 3, the OSPFv2 routing process is cleared using the clear ip ospf process privileged EXEC mode command. This forces OSPFv2 on R1 to transition to the Down and Init states. Notice the adjacency change messages from full to down and then from loading to full. The show ip protocols command verifies that the router ID has changed.

Use the Syntax Checker in Figure 4 to modify the router ID for R1.

19. Using a Loopback Interface as the Router ID

A router ID can also be assigned using a loopback interface.

The IPv4 address of the loopback interface should be configured using a 32-bit subnet mask (255.255.255.255). This effectively creates a host route. A 32-bit host route does not get advertised as a route to other OSPF routers.

The example in the figure displays how to configure a loopback interface with a host route on R1. R1 uses the host route as its router ID, assuming there is no router ID explicitly configured or previously learned.

Note: The router-id command is the preferred method. However, some older versions of the IOS do not recognize the router-id command; therefore, the best way to set the router ID on those routers is by using a loopback interface.

20. Enabling OSPF on Interfaces

The network command determines which interfaces participate in the routing process for an OSPFv2 area. Any interfaces on a router that match the network address in the network command are enabled to send and receive OSPF packets. The network command also indicates the network (or subnet) address for the interface is included in OSPF routing updates.

The basic command syntax is network network-address wildcard-mask area area-id.

The area area-id syntax refers to the OSPF area. When configuring single-area OSPFv2, the network command must be configured with the same area-id value on all routers. Although any area ID can be used, it is good practice to use an area ID of 0 with single-area OSPFv2. This convention makes it easier if the network is later altered to support multiarea OSPFv2.

The figure displays the reference topology.

21. Wildcard Mask

OSPFv2 uses the argument combination ofnetwork-address wildcard-mask to enable OSPF on interfaces. OSPF is classless by design; therefore, the wildcard mask is always required. When identifying interfaces that are participating in a routing process, the wildcard mask is typically the inverse of the subnet mask configured on that interface.

A wildcard mask is a string of 32 binary digits used by the router to determine which bits of the address to examine for a match. In a subnet mask, binary 1 is equal to a match and binary 0 is not a match. In a wildcard mask, the reverse is true:

• Wildcard mask bit 0 - Matches the corresponding bit value in the address.

• Wildcard mask bit 1 - Ignores the corresponding bit value in the address.

The easiest method for calculating a wildcard mask is to subtract the network subnet mask from 255.255.255.255.

The example in Figure 1 calculates the wildcard mask from the network address of 192.168.10.0/24. To do so, the subnet mask 255.255.255.0 is subtracted from 255.255.255.255, providing a result of 0.0.0.255. Therefore, 192.168.10.0/24 is 192.168.10.0 with a wildcard mask of 0.0.0.255.

The example in Figure 2 calculates the wildcard mask from the network address of 192.168.10.64/26. Again, the subnet mask 255.255.255.192 is subtracted from 255.255.255.255 providing a result of 0.0.0.63. Therefore, 192.168.10.0/26 is 192.168.10.0 with a wildcard mask of 0.0.0.63.

22. The network Command

There are several ways to identify the interfaces that will participate in the OSPFv2 routing process.

Figure 1 displays the required commands to determine which interfaces on R1 participate in the OSPFv2 routing process for an area. Notice the use of wildcard masks to identify the respective interfaces based on their network addresses. Because this is a single-area OSPF network, all area IDs are set to 0.

As an alternative, OSPFv2 can be enabled using the network intf-ip-address 0.0.0.0 area area-id router configuration mode command.

Figure 2 provides an example of specifying the interface IPv4 address with a quad 0 wildcard mask. Entering network 172.16.3.1 0.0.0.0 area 0 on R1 tells the router to enable interface Serial0/0/0 for the routing process. As a result, the OSPFv2 process will advertise the network that is on this interface (172.16.3.0/30).

The advantage of specifying the interface is that the wildcard mask calculation is not necessary. OSPFv2 uses the interface address and subnet mask to determine the network to advertise.

Some IOS versions allow the subnet mask to be entered instead of the wildcard mask. The IOS then converts the subnet mask to the wildcard mask format.

Use the Syntax Checker in Figure 3 to advertise the networks connected to R2 (172.16.2.0/24, 172.16.3.0/30, and 192.168.10.8/30).

Note: While completing the syntax checker, observe the informational messages describing the adjacency between R1 (1.1.1.1) and R2 (2.2.2.2). The IPv4 addressing scheme used for the router ID makes it easy to identify the neighbor.

23. Passive Interface

By default, OSPF messages are forwarded out all OSPF-enabled interfaces. However, these messages really only need to be sent out interfaces connecting to other OSPF-enabled routers.

Refer to the topology in the figure. OSPFv2 messages are forwarded out of all three routers G0/0 interface even though no OSPFv2 neighbor exists on that LAN. Sending out unneeded messages on a LAN affects the network in three ways:

• Inefficient Use of Bandwidth - Available bandwidth is consumed transporting unnecessary messages. Messages are multicasted; therefore, switches are also forwarding the messages out all ports.

• Inefficient Use of Resources - All devices on the LAN must process the message and eventually discard the message.

• Increased Security Risk - Advertising updates on a broadcast network is a security risk. OSPF messages can be intercepted with packet sniffing software. Routing updates can be modified and sent back to the router, corrupting the routing table with false metrics that misdirect traffic.

24. Configuring Passive Interfaces

Use the passive-interface router configuration mode command to prevent the transmission of routing messages through a router interface, but still allow that network to be advertised to other routers, as shown in Figure 1. Specifically, the command stops routing messages from being sent out the specified interface. However, the network that the specified interface belongs to is still advertised in routing messages that are sent out other interfaces.

For instance, there is no need for R1, R2, and R3 to forward OSPF messages out of their LAN interfaces. The configuration identifies the R1 G0/0 interface as passive.

It is important to know that a neighbor adjacency cannot be formed over a passive interface. This is because link-state packets cannot be sent or acknowledged.

The show ip protocols command is then used to verify that the Gigabit Ethernet interface was passive, as shown in Figure 2. Notice that the G0/0 interface is now listed under the Passive Interface(s) section. The network 172.16.1.0 is still listed under Routing for Networks, which means that this network is still included as a route entry in OSPFv2 updates that are sent to R2 and R3.

Note: OSPFv2 and OSPFv3 both support thepassive-interface command.

Use the Syntax Checker in Figure 3 to configure the G0/0 LAN interface as a passive interface on R2.

As an alternative, all interfaces can be made passive using the passive-interface default command. Interfaces that should not be passive can be re-enabled using the no passive-interface command.

Continue using the Syntax Checker in Figure 3 and configure the G0/0 LAN interface as a passive interface on R3.

Note: While completing the syntax checker, notice the OSPFv2 informational state messages as the interfaces are all rendered passive and then the two serial interfaces are made non-passive.

25. Packet Tracer - Configuring OSPFv2 in a Single-area

In this activity, the IPv4 addressing is already configured. You are responsible for configuring the three router topology with basic single-area OSPFv2, and then verifying connectivity between end devices.

Packet Tracer - Configuring OSPFv2 in a Single-area Instructions

Packet Tracer - Configuring OSPFv2 in a Single-area - PKA