Advice to Troubleshooters–Cisco Troubleshooting
Troubleshooting is a difficult skill. It is easy to become tangled up in trivia or chase the wrong set of symptoms, and it takes far longer to find and fix a problem than it might seem it should.
This section contains some advice from years of experience troubleshooting complex problems in all kinds of networks.
Be careful of false positives. Sometimes things will look broken, although they are not. It is easy to see something that looks a little odd, think this odd thing must be the source of the problem, and spend hours pursuing the problem—only to discover the “odd thing” is normal.
Knowing what normal looks like and understanding how protocols work are essential. If you think something is the root of the problem or even related to the problem, ask others and search the Internet for what you are seeing.
Be careful of cutting yourself off. Network engineers saw off the limb they are troubleshooting for more often than they like to admit. Several large-scale outages have been stretched from minutes to days while someone is dispatched to the router’s location so someone can plug into the console port. Always think about what you are about to do and its impact on your access to the network.
Be careful of turning on expansive debugging output. Routers, switches, and hosts can crash because of debug output.
Don’t focus on MTTI. Your job as a network engineer does not end when you have proven the problem is not in the network. If you are involved in a problem, take ownership, and help where you can. Teams with a wide variety of experience and expertise find and solve problems faster than more specialized teams.
Build relationships with other parts of the organization. You do not—you cannot—know every part of the system. Accept what you do know and be willing to ask questions when you do not know. Existing relationship are much more useful when you are asking for help, so build relationships with adjacent teams before the first outage.
There is nothing more permanent than a temporary fix. Do not allow temporary fixes to become permanent. It often feels much simpler to leave a temporary fix in place. But if you add enough temporary fixes into a network, the entire network becomes a huge unmaintainable mess.
Chapter Review
Troubleshooting is yet another one of those important skills network engineers need to develop and practice over time. It is fine to start with the obvious but quickly move to the formal half-split method. Document where you have looked, what you have measured, and the various theories you have developed about the cause of the problem.
Some other tools discussed in this chapter include the post-mortem—fix the problem, not the blame—and packet captures.
The next chapter is the last technically oriented chapter in this book. It covers configuring a small network from start to finish, showing how to use the CLI to configure Cisco devices and verify their operation.
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material using either the tools in the book or interactive tools for the same material found on the book’s companion website. Refer to the online Appendix D, “Study Planner,” element for more details.
Table 22-2 outlines the key review elements and where you can find them. To better track your study progress, record when you completed these activities in the second column.
Table 22-2 Chapter Review Tracking
Review All the Key Topics
Table 22-3 lists the key topics for this chapter.
Table 22-3 Key Topics for Chapter 22
Concepts and Actions
Review the concepts considered in this chapter using Table 22- 4. You can cover the right side of this table and describe each concept or action in your own words to verify your understanding.
Table 22-4 Concepts and Actions
