Chapter18.Frame Relay Troubleshooting Scenarios


Chapter 18. Frame Relay Troubleshooting Scenarios

This chapter includes some common, real-life scenarios that are designed to demonstrate the Frame Relay troubleshooting techniques covered in Chapter 17, "Frame Relay Troubleshooting." Another objective of this chapter is to give troubleshooting engineers some practical recommendations that deal with Frame Relay troubleshooting issues and to increase their practical knowledge about typical Frame Relay problems.

The greatest advantage of enterprise troubleshooting is that you always see both sides of the connection, and the necessary information about the development of the service is available to you. It is important that you have access to the proper data to fully understand the environment that you are troubleshooting. This includes the provisioning information, the requirements for the design, the configuration solution, and finally, the expected baseline. It is also important to understand the use of different IOS commands and tools, because the screen outputs from some of the recommended commands may or may not provide the information you require. The scenarios provided in this chapter represent some of the most common Frame Relay issues that you might experience when working with different service providers, routers, and solutions.

Five troubleshooting scenarios are provided in this chapter. Each scenario covers the most common troubleshooting issues that occur and how to pinpoint the exact causes of the problems. The topics covered in this chapter are as follows:

  • Scenario 1: New Install Issues

  • Scenario 2: Mismatched DLCI Settings

  • Scenario 3: Performance Issues from Flapping Lines and Traffic Shaping Issues

  • Scenario 4: IP Multicast Issues in Frame Relay

  • Scenario 5: Frame Relay Host Migration

NOTE

Most troubleshooting engineers recommend that you have two telnet sessions open for some of the more chatty IOS commands. The reason behind this is that you can force the router to crash if you don't know how much output to expect. One of the sessions is used with the #terminal monitor or (config)#logging console command and the appropriate debug command. For the second telnet session, have the undebug all command ready in case use exceeds reasonable levels. The logging console command only logs to the console, so you must have a telnet session open or be directly connected to the console port. Logging to the console is more processor intensive than logging to the terminal because of the default slow speed of the console port. Another alternative is to send the log messages to a syslog server and then view them there without logging on the router at all.





Troubleshooting Remote Access Networks CCIE Professional Development
Troubleshooting Remote Access Networks (CCIE Professional Development)
ISBN: 1587050765
EAN: 2147483647
Year: 2002
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net