Chapter4.Troubleshooting Approaches, Models, and Tools

Chapter 4. Troubleshooting Approaches, Models, and Tools

This is the final chapter of Part I, "Remote Access Fundamentals." The rest of the book covers material related to troubleshooting dial, ISDN, Frame Relay, and Virtual Private Network (VPN) solutions. Remote access troubleshooting in this book is focused more on the communication subsystem of the Open System Interconnection (OSI) model than on higher levels of the model. Some common models, approaches, and troubleshooting tools are available for the test engineers , which need to be clarified before covering troubleshooting specific remote access networks. This chapter covers these models, approaches, and troubleshooting tools so that this material doesn't need to be repeated for each remote access technology covered hereafter. As such, this chapter outlines fundamental troubleshooting information that the remaining chapters will assume that you are familiar with. The main topics covered in this chapter are as follows :

• Interconnection models The Department of Defense (DoD)model and the seven-layer OSI model

• Troubleshooting models The layer-by-layer approach

• Common troubleshooting tools and techniques

• Cisco-specific troubleshooting tools

Troubleshooting is often considered an intuitive activity, where knowledge is sometimes not enough to successfully and effectively perform the task. However, knowledge and hands-on experience plays a decisive role in the troubleshooting process.

This book's focus is to help the troubleshooting engineer in day-to-day operations. Sometimes, your soft skills are as important as your technical skills, so here are some brief reminders about approaching troubleshooting in general:

• Be passionate , but professional. Be ready to go the extra mile for your user , but don't get personally involved.

• Know the technology. When working with providers, knowledge beyond just your piece of the puzzle might save you a lot of frustration. Be familiar with and use professional terms and acronyms. Understand your provider's internal procedures and specifics and be supportive.

• Try to build mutual trust in your relationship with your customer; the customer is in trouble, but you can get in trouble, too. Show that you care for the customer's problem. Work with the customer as your partner.

• Know your options. Be ready to say no if a request goes against rules, procedures, or policies.

Beyond your technical knowledge, all these components define your professionalism and these soft skills can be decisive in your next troubleshooting case.

A troubleshooting engineer needs to have a systematic approach for analyzing issues. Typically, in the case of an enterprise remote access environment where the engineer sees both ends of the connection, it is convenient to reduce the number of focus points to two or three: the remote user, the cloud, and the core router. Depending on your perspective or location, these also can be referred to as the near end of the connection, the far end of the connection, and the cloud in between. Based on this, some authors recognize the following approaches to troubleshooting:

• Start from the near end

• Start from the far end

• Divide by half and start toward the near end or toward the far end

These approaches seem to be logical and systematic, given the fact that some networks can be complex. When troubleshooting, it is best to focus on one issue rather than jumping randomly from hop to hop, virtually dividing the network to three pseudo-independent segments: remote end, service provider(s), and near end. VPN solutions might seem to be an exception to this rule, but they are not. The remote user (equipment or client), Internet, and enterprise termination point create the same triad of componentsa simplified version of a complex solution.

Given the fact that all components of every remote access design conform to one or more industry agreements (standards and protocols), another approach to troubleshooting is feasible . It is based on the industry's accepted layered models. The troubleshooting process can start from any end, but you should follow a layer-by-layer troubleshooting process, starting with layer one. This technology-based approach is used throughout later parts of this book.

NOTE

Of course, you can choose many other troubleshooting approaches. Regardless, it's most important that the method be systematic and consistent, and that you are comfortable using it.