OSPF Configuration Fundamentals
This section describes OSPF configuration fundamentals and builds upon the configuration of OSPF as described in the CCNA and CCNP certification course. Please also read our OSPF Configuration guide.
Enabling OSPF in Cisco IOS Software
OSPF configuration is enabled in Cisco IOS software by issuing the router ospf [process id] global configuration command. The [process id] is locally significant and does not need to be the same on all routers in the network in order to establish an adjacency. The use of the locally significant process ID allows you to configure multiple instances of OSPF on the same router.
The OSPF process ID is an integer between 1 and 65535. Each OSPF process maintains its own separate Link State Database; however, all routes are entered into the same IP routing table. In other words, there is no unique IP routing table for each individual OSPF process configured on the router. A separate routing table is used only when OSPF Virtual Routing and Forwarding or VPN Routing and Forwarding (VRF) configuration is implemented on the router. VRF will be described in detail later in this guide.
In earlier versions of Cisco IOS software, OSPF would not be enabled if the router did not have at least one interface configured with a valid IP address in the up/up state. This restriction has been removed in current versions of Cisco IOS software. In the event that the router has no interfaces configured with a valid IP address and in the up/up state, Cisco IOS will create a
Proximity Database (PDB) and allow the process to be created. However, it is important to remember that the process will be inactive until a router ID is selected, which can be performed in the following two ways:
- Configuring a valid IP address on an interface and bringing the interface up
- Configuring the router ID manually using the router-id command
As an example, consider the following router, which has all interfaces disabled:
| R3#show ip interface brief
Interface IP-Address OK? Method Status Protocol FastEthernet0/0 unassigned YES manual administratively down down Serial0/0 unassigned YES NVRAM administratively down down Serial0/1 unassigned YES unset administratively down down |
Next, OSPF is enabled on the router using the router ospf [process id] global configuration command as illustrated in the following output:
| R3(config)#router ospf 1
R3(config-router)#exit |
Based on this configuration, Cisco IOS software assigns the process a default router ID of 0.0.0.0 as illustrated in the following output of the show ip protocols command:
| R3#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 0.0.0.0 Number of areas in this router is 0. 0 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: Reference bandwidth unit is 100 mbps Routing Information Sources: Gateway Distance Last Update Distance: (default is 110) |
However, the show ip ospf [process id] command reveals that the process is not actually active and indicates that a router ID needs to be configured as illustrated below:
| R3#show ip ospf 1
%OSPF: Router process 1 is not running, please configure a router-id |
Enabling OSPF Routing for Interfaces or Networks
After OSPF has been enabled, two actions can be performed to enable OSPF routing for one or more networks or interfaces on the router as follows:
- Using the [network] [wildcard] area [area id] router configuration command
- Using the ip ospf [process id] area [area id] interface configuration command
The network [network] [wildcard] area [area id] router configuration command is a legacy method (regarding the newer Cisco IOS versions) of enabling OSPF routing for one or more links. Unlike EIGRP, the wildcard mask is mandatory in OSPF and must be configured; however, as is the case with EIGRP, it serves the same function in that it matches interfaces within the range specified. As an example, the statement network 10.0.0.0 0.255.255.255 Area 0 would enable OSPF routing for interfaces with the IP address and subnet mask combination of 10.0.0.1/30, 10.5.5.1/24, and even 10.10.10.1/25. The interfaces would all be assigned to OSPF Area 0 based on the OSPF network configuration.
NOTE: The wildcard mask for OSPF configuration can also be entered in the same format as a traditional subnet mask, for example, network 10.0.0.0 255.0.0.0 Area 0. In this case, Cisco IOS software will invert the subnet mask and the wildcard mask will be entered into the running configuration. In addition, it is important to remember that OSPF also supports the use of the all ones or all zeros wildcard mask to enable OSPF routing for a specific interface. This configuration enables OSPF on a particular interface but the router advertises the actual subnet mask configured on the interface itself.
After the network [network] [wildcard] area [area id] command has been issued, the router sends out Hello packets on interfaces matching the specified network and wildcard mask combination and attempts to discover neighbors. The connected subnet is then advertised to one or more neighbor routers during the OSPF database exchange, and, finally, this information is then added to the OSPF Link State Database of the OSPF routers.
When the network [network] [wildcard] area [area id] command is issued, the router matches the most specific entry in order to determine the area the interface will be assigned to. Consider the following OSPF network statement configurations, as an example:
- First configuration statement: network 10.0.0.0 0.255.255.255 Area 0
- Second configuration statement: network 10.1.0.0 0.0.255.255 Area 1
- Third configuration statement: network 10.1.1.0 0.0.0.255 Area 2
- Fourth configuration statement: network 10.1.1.1 0.0.0.0 Area 3
- Fifth configuration statement: network 0.0.0.0 255.255.255.255 Area 4
Following this configuration on the router, the Loopback interfaces shown in Table 3-1below are then configured on the same router:
Table 1. Assigning Interfaces to OSPF Areas
| Interface | IP Address/Mask |
| Loopback 0 | 10.0.0.1/32 |
| Loopback 1 | 10.0.1.1/32 |
| Loopback 2 | 10.1.0.1/32 |
| Loopback 3 | 10.1.1.1/32 |
| Loopback 4 | 10.2.0.1/32 |
As was previously stated, when the network [network] [wildcard] area [area id] command is issued, the router matches the most specific entry in order to determine the area in which the interface will be assigned. Taking the network statement configuration and the Loopback interfaces configured on the router, the show ip ospf interface brief command would show that the interfaces were assigned to the following OSPF areas:
| R1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C Lo4 1 0 10.2.0.1/32 1 LOOP 0/0 Lo1 1 0 10.0.1.1/32 1 LOOP 0/0 Lo0 1 0 10.0.0.1/32 1 LOOP 0/0 Lo2 1 1 10.1.0.1/32 1 LOOP 0/0 Lo3 1 3 10.1.1.1/32 1 LOOP 0/0 |
NOTE: Regardless of the order in which the network statements are entered, within the running configuration, the most specific entries are listed first in the output of the show running-config command on the router.
The ip ospf [process id] area [area id] interface configuration command negates the need to use the network [network] [wildcard] area [area id] router configuration command. This command enables OSPF routing for the specified interface and assigns the interface to the specified OSPF area. These two commands perform the same basic function and may be used interchangeably.
Additionally, if, for example, two routers are connected back-to-back, with one router configured using the ip ospf [process id] area [area id] interface configuration command and the neighbor router configured using the network [network] [wildcard] area [area id] router configuration command, then, assuming the area IDs are the same, the routers will successfully establish an OSPF adjacency.
Using the OSPF Configuration Interface and Network Commands
There are several important reasons for using both the ip ospf [process id] area [area id] interface configuration command and the network [network] [wildcard] area [area id] router configuration command with which you should be familiar. These aspects are described in detail in the sections that follow.
The first important reason is that if an interface is already enabled for OSPF routing via the use of the network command, and the ip ospf interface configuration command is issued assigning the interface to a different OSPF process or area, then the explicit interface configuration will be used. Assume that a Cisco IOS router has the following Loopback interfaces configured on it:
| R2#show ip interface brief | include Loopback
Loopback0 10.2.2.2 YES manual up up Loopback1 20.2.2.2 YES manual up up |
Next, an OSPF process ID of 1 is enabled on the router and both Loopback interfaces are assigned to Area 1 under this process as illustrated in the following output:
| R2(config)#router ospf 1
R2(config-router)#network 10.2.2.2 0.0.0.0 Area 1 R2(config-router)#network 20.2.2.2 0.0.0.0 Area 1 R2(config-router)#exit |
Based on this configuration, the Loopback interfaces are both assigned to Area 1 under an OSPF process ID of 1. This can be validated using the show ip ospf interface brief command as illustrated in the following output:
| R2#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C Lo0 1 1 10.2.2.2/32 1 LOOP 0/0 Lo1 1 1 20.2.2.2/32 1 LOOP 0/0 |
This same information can be validated by using the show ip ospf interface command as illustrated in the following output:
| R2#show ip ospf interface Loopback0
Loopback0 is up, line protocol is up Internet Address 10.2.2.2/32, Area 1 Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1 Loopback interface is treated as a stub Host |
Now the ip ospf interface configuration command is issued under Loopback 0 using a local process ID of 2 and assigning this interface to Area 2 as follows:
| R2(config)#interface Loopback0
R2(config-if)#ip ospf 2 Area 2 R2(config-if)#exit |
Based on this configuration, the ip ospf interface-specific configuration takes precedence over the network configuration and the interface will be removed from process ID 1 and reattached to process ID 2. This is illustrated in the following output:
| R2#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C Lo1 1 1 20.2.2.2/32 1 LOOP 0/0 Lo0 2 2 10.2.2.2/32 1 LOOP 0/0 |
A detailed look at the interface reveals that it is configured using interface-specific configuration and not the network router configuration command as illustrated in the following output:
| R2#show ip ospf interface Loopback0
Loopback0 is up, line protocol is up Internet Address 10.2.2.2/32, Area 2 Process ID 2, Router ID 2.2.2.3, Network Type LOOPBACK, Cost: 1 Enabled by interface config, including secondary ip addresses Loopback interface is treated as a stub Host |
By default, the ip ospf interface configuration command also enables OSPF routing for any secondary addresses configured on the interface as illustrated above. However, this default behavior can be disabled by issuing the ip ospf [process id] area [area id] secondaries none interface configuration command when enabling OSPF under the desired interface. This is illustrated in the following configuration output:
| R2(config)#interface Loopback0
R2(config-if)#ip ospf 1 Area 1 secondaries none R2(config-if)#exit |
The show ip ospf interface command can be used to validate this configuration as illustrated in the following output:
| R2#show ip ospf interface Loopback0
Loopback0 is up, line protocol is up Internet Address 10.2.2.2/32, Area 1 Process ID 1, Router ID 10.2.2.2, Network Type LOOPBACK, Cost: 1 Enabled by interface config, excluding secondary ip addresses Loopback interface is treated as a stub Host |
In addition, also keep in mind that even though the ip ospf interface configuration command has been issued for the Loopback interface, the network configuration is not removed from the configuration. It must be removed manually from the router configuration.
The second important reason is that the ip ospf interface configuration command can be used even if the router ospf command has not been issued. In such cases, Cisco IOS software simply creates the OSPF process ID specified using the interface configuration command. This is performed transparently; that is, there is no warning or other message printed on the console indicating that a new OSPF process has been enabled based on the new interface configuration.
The third important reason is that if the interface is included for the same OSPF configuration process ID and resides in the same area for both the network and the ip ospf interface configuration commands, then, again, the ip ospf interface configuration command takes precedence and the router will indicate that the interface has been configured using an interface-specific command, even though the network statement is retained. As an example, assume that Loopback 0 is enabled under a process ID of 1 and is assigned to Area 1 as illustrated in the following configuration:
| R2(config)#router ospf 1
R2(config-router)#network 10.2.2.2 0.0.0.0 Area 1 R2(config-router)#exit |
The output of the show ip ospf interface command reveals that the interface falls under the process ID of 1 configuration and is assigned to Area 1 as follows:
| R2#show ip ospf interface Loopback0
Loopback0 is up, line protocol is up Internet Address 10.2.2.2/32, Area 1 Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1 Loopback interface is treated as a stub Host |
Next, the interface-specific configuration is applied using the same OSPF process ID and area allocation as illustrated in the following output:
| R2(config)#interface Loopback0
R2(config-if)#ip ospf 1 Area 1 R2(config-if)#exit |
The output of the show ip ospf interface command now displays the following:
| R2#show ip ospf interface Loopback0
Loopback0 is up, line protocol is up Internet Address 10.2.2.2/32, Area 1 Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1 Enabled by interface config, including secondary ip addresses Loopback interface is treated as a stub Host |
NOTE: You can also use the show ip protocols command to determine which interfaces have interface-specific configuration applied to them as follows:
| 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.2 0.0.0.0 Area 1 20.2.2.2 0.0.0.0 Area 1 Routing on Interfaces Configured Explicitly (Area 1): Loopback0 Reference bandwidth unit is 100 mbps Routing Information Sources: Gateway Distance Last Update Distance: (default is 110) |
The fourth important reason is that if OSPF routing is enabled for an interface using ip ospf interface-specific configuration and the no router ospf [process id] command is issued on the router specifying the process ID configured on the interface, then the interface-specific configuration is removed along with all other configuration for that OSPF process.
However, if OSPF routing is enabled for an interface using the ip ospf interface-specific configuration, and the same process is also configured globally on the router with one or more network commands, then issuing the no ip ospf interface configuration command does not remove the global OSPF configuration on the router.
OSPF Area Fundamentals
The OSPF area ID may be configured either as an integer between 0 and 4294967295 or using dotted-decimal notation (i.e., using IP address format). Unlike the OSPF process ID, the OSPF area ID must match in order for adjacency to be established. Mismatched area IDs are analogous to mismatched EIGRP autonomous system numbers. The most common type of OSPF area configuration is using an integer to specify the OSPF area. However, ensure that you are familiar with both supported methods of area configuration.
Please also read the Cisco OSPF configuration notes.
Leave a Reply