Monitoring Troubleshooting an OSPF Network | OSPF Network Design Solutions

Table of Contents

Step 3: Consider Possible Problems

Very soon after our initial observations were made and the facts were gathered, we determined that hardware did not seem to be a problem. However, we recognized that there were actually two problems to confront:

• Routing issues. No OSPF adjacencies were being created on three of the four WAN links. Consequently, these links were not passing any routed customer information. Because we had previously ruled out hardware as an issue, we decided to it would be necessary confront this problem from a software configuration standpoint.

• Performance issues. A large number of output drops and input drops on the WAN link seemed to be directly related to user slowdowns. However, a circuit problem could not be fully ruled out at this time—if the circuits were truly being over utilized, they could potentially require an upgrade in speed. However, we determined that increasing the circuit speed might require more investigation after the routing issues were fully resolved.

Step 4: Create an Action Plan

Based on the previous troubleshooting methodology, we decided to use a “divide and conquer” approach by breaking up the problem into two pieces: routing issues and performance issues.

As part of our action plan, we decided we would correct the routing issues first, then proceed with the performance issues. We also decided that we would change only one variable at a time (that is, only make one router configuration change at a time), so that we could clearly understand the solution, after it is discovered.

Step 5: Implement the Action Plan

One of the best troubleshooting commands to use for dealing with OSPF routing issues is show ip ospf neighbors. The output of this command will display very useful information about OSPF adjacencies in any OSPF network; and as you know, OSPF routing is highly influenced by adjacencies.

The initial output of this command on ROUTER A and ROUTER B gave some very useful information, as shown in the following output.

    ROUTER_A# show ip ospf neighbors    177.36.253.6      1    FULL/DR    00:00:32    177.4.255.32    Ethernet1

Our findings (from the show ip ospf neighbors output that follows) showed that Router A was adjacent with Router B and vice-versa. Router B was fully adjacent with C’s backup link (0K CIR). These links were running at 0K CIR and all packets going into the network were being marked discard eligible. This helped us to understand why performance was so slow.

    ROUTER_B# show ip ospf neighbors    177.36.253.1    1   FULL/BDR-    00:00:32    177.4.255.31    Ethernet1    177.36.252.5    1   FULL/ -      00:00:32    177.65.252.45   Serial2.1

Later, you will see that once the routing issues were corrected, the output of the same command on Router A will yield the following:

    ROUTER_A# show ip ospf neighbors    177.36.252.1      1    2WAY/DROTHER    00:00:32    177.4.255.32    Ethernet1    177.36.252.5      1    FULL/ -         00:00:34    177.65.252.1    Serial1.1         ***FULL T1 (768K CIR) Link to ROUTER C    177.65.252.25     1    FULL/ -         00:00:32    177.65.252.29    Serial2.1         ***FULL T1 (768K CIR) Link to ROUTER D

Step 6: Gather Results

In this step, we begin to gather the results of the action plan that we had created to deal with the reported network problem.

Our first step in determining why the adjacencies were not being formed over the WAN links was to confirm that OSPF was enabled on them. By using the show ip ospf interfaces command, we quickly determined that indeed OSPF was NOT enabled on the WAN interfaces for Router A. Specifically, OSPF was not enabled for the WAN links to Routers C and D. As noted in the preceding command output, Ethernet0 on Router A had correctly formed an adjacency with Router B. The output of the show ip ospf interfaces command is as follows:

    ROUTER_A# Show ip ospf interface    Ethernet0 is up, line protocol is up       Internet Address 177.2.255.1/24, Area 0       Process ID 202, Router ID 177.36.252.1 Network Type BROADCAST, Cost:       10       Transmit Delay is 1 sec, State DROTHER, Priority 1       Designated Router (ID) 177.2.255.4, Interface address 177.2.255.4       Backup Designated router (ID) 177.32.252.6, Interface address       177.2.255.5       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5            Hello due in 00:00:02       Neighbor Count is 1, Adjacent neighbor count is 1            Adjacent with neighbor 177.36.253.6 (Designated Router)    Serial0 is up, line protocol is up        OSPF not enabled on this interface    Serial0.1 is up, line protocol is up        OSPF not enabled on this interface    Serial1 is up, line protocol is up        OSPF not enabled on this interface    Serial1.2 is up, line protocol is up        OSPF not enabled on this interface

This message “OSPF not enabled on this interface” explained why OSPF would not form an adjacency—simply because it had not been enabled!

Step 7: Reiterate the Process, if Needed, in Steps 4-7

Our action plan was successful, and we had identified errors in the router configurations that needed to be corrected. The question then became: “How do I turn on OSPF on the WAN interfaces s0.1 and s1.2 of router A?” A new solution was achieved in three steps:

1. Determine the networks that belong to s0.1 and s1.2. This was done by using the Cisco commands: show ip int s0.1 and show ip int s0.2. The output from those commands will yield the IP address of each interface and the subnet mask that each is configured.

2. Add the network number(s) obtained in Step 1 to the OSPF process and area number to Router A’s configuration.

3. Enable area authentication, because the design specification requires simple cleartext OSPF authentication.

At this point, it is necessary to reiterate the troubleshooting process and its steps to now begin making the changes to the router’s configuration identified in the preceding three-step process.

Step 4: Create a New Action Plan

Remember that it is important to change only one variable at a time while executing an action plan. Additionally, it is considered good practice to log any changes that you are making to the router’s configuration. Many terminal tools allow the terminal output to be redirected into an ASCII file. I highly recommend creating an audit trail for later retrieval and reference. This information is also good if you ever have to write an after action report or a case study!

Table of Contents