Up till now the lab scenarios have been geared to demonstrating how routing protocols work and how to configure them, but in this lab you will ask you to fix a broken network. This lab includes a corrupted script that you use your troubleshooting techniques to isolate the problems and implement a solution. By the end of the lab, you should have a functional network with full end-to-end connectivity.
Although this labs was created as a Cisco Packet Tracer Activity I have included the GNS3 configuration as well as the Initial router configuration and the solution.
[adsense_id=”5″]
Troubleshooting OSPF can sometimes be daunting, especially in a large network. However, a routing problem with OSPF is no different than a routing problem with any other routing protocol; the cause will be one of the following:
- Missing route information
- Inaccurate route information
OSPF Troubleshooting methodology:
An examination of the route table is still the primary source of troubleshooting information. Using the show ip ospf database command to examine the various LSAs will also yield important information. For example, if a link is unstable, the LSA advertising will change frequently. This condition is reflected in a sequence number that is conspicuously higher than that of the other LSAs. Another sign of instability is an LSA whose age never gets very high.
Keep in mind that the link-state database of every router within an area is the same. So unless you suspect that the database itself is being corrupted on some routers, you can examine the link-state database for the entire area by examining a single router’s link-state database. Another good practice is to keep a copy (hard or soft) of the link-state database for each area.
- When examining an individual router’s configuration, consider the following:
- Do all interfaces have the correct addresses and masks?
- Do the network area statements have the correct inverse masks to match the correct interfaces?
- Do the network area statements put all interfaces into the correct areas?
- Are the network area statements in the correct order?
- When examining adjacencies (or the lack thereof), consider these questions:
- Are Hellos being sent from both neighbors?
- Are the timers set the same between neighbors?
- Are the optional capabilities set the same between neighbors?
- Are the interfaces configured on the same subnet (that is, do the address/mask pairs belong to the same subnet)?
- Are the neighboring interfaces of the same network type?
- Is a router attempting to form an adjacency with a neighbor’s secondary address?
If authentication is being used, is the authentication type the same between neighbors? Are the passwords and (in the case of MD5) the keys the same? Is authentication enabled on all routers within the area?
- Are any access lists blocking OSPF?
- If the adjacency is across a virtual link, is the link configured within a stub area?
- When examining an area-wide problem, consider the following issues:
- Is the ABR configured correctly?
- Are all routers configured for the same area type? For example, if the area is a stub area, all routers must have the area stub command.
- If address summarization is configured, is it correct?
Need more information on troubleshooting OSPF try our new search:
Troubleshooting OSPF (4,512 hits)
Packet Tracer 5-3-3 by Cisco (48.3 MiB, 3,580 hits)
You do not have permission to download this file.
Also check out these other assume training resources:
