OSPF Network Design Solutions

Preparing for Network Failure

You can always recover from a network failure easier if you are prepared ahead of time. To see if you are prepared for a network failure, answer the following questions:

•  Do you have an accurate physical and logical map of your internetwork? Does your organization or department have an up-to-date internetwork map that outlines the physical location of all of the devices on the network and how they are connected, as well as a logical map of network addresses, network numbers, subnetworks, router interfaces, and so forth?

•  Do you have a list of all network protocols implemented in your network? For each of the protocols implemented, do you have a list of the network numbers, IP addresses, DLCIs, subnetworks, zones, areas, and so on that are associated with them?

•  Do you know which protocols are being routed? For each of these protocols, do you have a correct, updated router configuration? You also need to keep router configuration files before and after major network changes. This helps ensure that a readily available backup exists in case the change must be reversed.

•  Do you know which protocols are being bridged? Are there any filters configured in any of these bridges, and do you have a copy of these configurations?

•  Do you know all the points of contact to external networks, including any connections to the Internet? For each external network connection, do you know what routing protocol is being used? Do you have adequate security in place and documented? How are the external networks being advertised into your OSPF network?

•  Do you have an established baseline for your network? Has your organization documented the baseline or normal network behavior and performance so that you can compare current problems with a baseline? This documentation is essential to understanding the network and judging the impact of changes to your network. These changes can be related to either a network failure or the introduction of new network service.

•  Is this information stored in a central location so that it is accessible to everyone concerned with the network operation and management? Having the information is only half the battle. The information must be available so that if needed, it can be readily accessed in order to reduce network downtime.

Troubleshooting Methodology

Internetworks come in a variety of topologies and levels of complexity; from single-protocol, point-to-point links connecting cross-town campuses, to highly-meshed, large-scale WANs traversing multiple time zones and international boundaries. The industry trend is toward increasingly complex environments, involving multiple types of media, multiple protocols, and often providing interconnection to “unknown” networks.

Consequently, the potential for connectivity and performance problems in internetworks is high, and the sources of such problems are often elusive. The goal of this section is to help you isolate and resolve the most common connectivity and performance problems within your OSPF Network.

Symptoms, Problems, and Solutions

Failures in internetworks are characterized by certain symptoms. These symptoms might be general (such as clients being unable to access specific servers) or more specific (routes not in the routing table). Each symptom can be traced to one or more problems or causes by using specific troubleshooting tools and techniques. After they are identified, each problem can be remedied by implementing a solution consisting of a series of actions.

The section that follows describes how to define symptoms, identify problems, and implement solutions as apply to a OSPF network but the basics can also apply to any generic network environment. Always apply the specific context in which you are troubleshooting to determine how to detect symptoms and diagnose problems for your specific environment.

General Problem-Solving Model

When troubleshooting problems within an OSPF networked environment, a systematic approach works best. Define the specific symptoms, identify all potential problems that could be causing the symptoms, and then systematically eliminate each potential problem (from most likely to least likely) until the symptoms disappear.

This process is not a rigid outline for troubleshooting an internetwork. Rather, it is a solid foundation from which you can build a problem-solving process to suit the particular needs of your OSPF environment.

The following seven steps detail the problem-solving process:

1.  Clearly define the problem.

2.  Gather facts.

3.  Consider possible problems.

4.  Create an action plan.

5.  Implement the action plan.

6.  Gather results.

7.  Reiterate the process.

Step 1: Clearly Define the Problem

When analyzing a network problem, make a clear problem statement. You should define the problem in terms of a set of symptoms and potential causes. To do this, identify the general symptoms and then ascertain what kinds of problems (causes) could result in these symptoms.

For example, hosts might not be responding to service requests from clients (a symptom). Possible causes might be a misconfigured host, bad interface cards, or missing router configuration commands.

Step 2: Gather Facts

Gather the facts you need to help isolate possible causes by asking questions of your peers and others such as:

Users that are affected. What type of problems are they experiencing?

Network Administrators. Has anything changed or been added to the network?

Your Peers and Associates. Have they seen this problem before, or do they know something that might help?