With all these configurations we have learned in our previous article for OSPF we have encountered so far (which are only the tip of the iceberg), it is a relief to have some of these configurations simplified by the web-based SDM GUI.

To begin, we should take similar steps as we did with the CLI configuration, which is to create a loopback interface. You can do this by selecting configuration, interface, and connections. From there, select the Edit Interface/Connection tab, and choose the Add Tool at the top of the window. Choose New Logical Interface, Loopback, as shown in the picture below, to bring up the loopback configuration pop-up window.

Here you need to select a static IP address from the pull-down menu. This allows you to input your IP address and subnet mask for this logical interface, as shown in the picture below, which will inevitably become the router ID for your OSPF routing process.

With our loopback interface in place, it is time to configure the OSPF routing protocol parameters. Select Configuration, Routing. Click the Edit button in the Dynamic Routing selection. In the Edit IP Dynamic Routing dialog box, shown in the picture below, choose the OSPF tab. Identify your process ID for OSPF, and click the Add button to add networks to the network List.

The Add an OSPF dialog box asks for the networks, wildcard masks, and area IDs for that OSPF process. As soon as all the networks have been advertised, the configurations are added to the running-config after you click OK.

Verifying OSPF

Because there are so many aspects to OSPF, you have a considerable number of show commands at your disposal to verify OSPF operations. As before, you can use the show running-config to verify the local configuration of your routing protocol. In the case of OSPF, this is useful to ensure that you configured the network and wildcard mask correctly, as well as associated the network with the correct area. In addition, show ip protocols again shows you information about the networks you are advertising with OSPF.

Recall that OSPF maintains three separate tables in its routing process; the routing table, the neighbor table, and the topology table. You are already familiar with the show IP route command to view the routing table and verify whether you are receiving OSPF networks from the neighbors:

RouterA>show ip route
Codes: C-connected, S-static, I-IGRP, 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, E-EGP, i-IS-IS, L1-IS-IS level-1, L2-IS-IS level-2, *-candidate default, U-per-user static route, o-ODR

Gateway of last resort is not set

O   IA    172.17.0.0/16     [110/74]  via 192.168.1.6, Serial0/0
C   172.16.0.0/16 is directly connected, FastEthernet0/0
O   172.18.0.1/16     [110/65] via 192.168.1.6, Serial0/0
    10.0.0.0/32 is sub netted, 1 subnets
C   10.1.42.1 is directly connected, Loopback0
    192.168.1.0/30 is sub netted, 1 subnets
C   192.168.1.4 is directly connected, Serial0/0/0

The 172.17.0.0 and 172.18.0.0 networks in this example were learned via OSPF through the Serial0/0/0 interface. Notice that the 172.17.0.0 entry has an IA (Inter-Area) indicator. It signifies that this network was learned from an ABR and that the network resides in another area.

To see a listing of the neighbors that were discovered through LSA hello advertisements, you can look in your router’s neighbor table by using the show ip ospf neighbor command:

routerA>show ip ospf neighbour
neighbour ID  Pri    state      Dead Time     Address       Interface
10.1.42.100   10     Full/DR    00:00:39      192.168.1.6   Serial0/0

The Neighbor ID is actually the Router ID of the neighbor that is being advertised in the neighbor’s Hello messages. The pri field indicates the priority configured on your neighbor’s interfaces. Because the default priority is 1 and this neighbor has a priority of 10, that router happens to be the DR for that segment, as shown in the State field. The other possible values for this state are BDR and DROTHER (not DR or BDR), depending on whether those routers won the election on that segment.

The show ip ospf database command shows the third table that OSPF maintains the topology table. This table lists all the network entries and the advertising routers for those entries. From this table, the SPF algorithm is run, and the routes with the lowest cumulative cost are put in the routing table. Here you can see the output of the show ip ospf database summary command because the information is presented in a more intelligible output.

routerA>show ip ospf database summary
OSPF Router with ID (10.1.42.1) (Process ID 1) summary Net link states (Area 51)
Routing Bit Set on this LSA LS age; 537
Options: (No TOS-capability, DC) LS Type: Summary Links (Network)
Link State ID: 172.17.0.0 (summary Network Number) Advertising
Router: 10.1.42.100
LS Seq Number: 80000001
Checksum: 0x7863
Length: 28
Network Mask: /16
TOS: 0 Metric: 10

You can see the 172.17.0.0 network you learned from the neighbor router, 10.1.42.100, and the cost of the link associated with that network. The final show command for OSPF is actually extremely useful when you want to gather information about the network topologies that are connected to the router’s interfaces. The show ip ospf interface command yields a wealth of information, such as the local router’s Router ID, interface topology type, link cost and priority, router ID for the DR and BDR on the segment, hello/dead intervals, and a count of how many neighbors and adjacencies formed:

RouterA#show ip ospf interface FastEthernet0/0
Is up, line protocol is up Internet Address
172.16.0.1/16, Area 51
Process ID 4, Router ID 10.1.42.1, Network Type BROADCAST, Cost: I
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.1.42.1, Interface address 172.16.0.1
No backup designated router on this network
Timer intervals configured, Hello 10, Dead, Wait 40, Retransmit 5
Obb resync timeout 40
Hello due in 00:00:03
Supports Link-Local signalling (LLS) Index 2/2, 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 neighbour count is 0
Suppress hello for 0 neighbor (s) Serial0/0/0 is up, line
Protocol is up Internet address 192.168.1.5/30, Area 0
Process ID 4, Router ID 192.168.100.155, 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
Obb resync timeout 40
Hello due in 00:00:07
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 neighbour count is 0
Suppress hello for 0 neighbor (s)

Troubleshooting OSPF

At the risk of sounding like a broken record, you should begin your troubleshooting by using the show commands discussed in the previous article to ensure that your configurations are correct. Some of the more common problems that occur with OSPF configurations are simple mistakes such as those that occur with incorrect network statements (incorrect network ID, wildcard mask, or area) and forgetting to configure each router as a stub in a stub area.

In cases where the configuration checks out, OSPF also can debug routing information in real-time if you use the debug ip ospf events command. This command is useful if you are trying to troubleshoot occurrences such as routers that cannot form a neighbor relationship. In the following example, you can see that a hello message has been received from 10.1.42.100. Notice that no real routing information is shown in these hello messages because OSPF does not send entire routing updates in its hello LSAs.

routerA#debug ip ospf events
OSPF events debugging is on
00:57:13:OSPF:Rcv hello from 10.1.42.100 area 51 from serial0/0 192.168.1.6
00:57:13:OSPF:End of hello processing