ADSL Troubleshooting Methodology
ADSL Troubleshooting Methodology by ComputerNerd22
Overview
In this document, you will be introduced to troubleshooting and the
methodology behind it. You will also learn how to isolate the problem. I work for a major ISP in the United States of America. I was recently in a traing class and I asked the Trainer if it would be cool if I use this information he said by all means. So here it is troubleshooting ADSL. Please keep in there are various DSL Technologies such as: ADSL, HDSL, IDSL, SDSL, RADSL, VDSL, UADSL. each technology is resolved with different trouble shooting. This lesson covers 'ADSL'. When you see Acronymons like CPE, PPPOE, DSLAM, ATM, (Customer Premise Equipment) PPPOE (Point to Point Protocol Over Ethernet) DSLAM (DSL Access Multiplexer) = Used to connect digital subscriber lines to the ATM network. A key component in the ADSL network infastructure. ATM (Asynchronous Transfer Mode) = An ultra high-speed cell-based data transmission protocol that may be run over ADSL.
This Lesson Topic?
Troubleshooting Methodology
Isolating the problem
Layers
Troubleshooting Methodology
Troubleshooting a technical issue is not always an easy task. Most of the
problems that are presented to the technicians are generic like:
The customer can?t surf?
or
The customer can?t send/receive e-mails
This can be misleading and cause incorrect troubleshooting of the applications
and operating system when the problem is in fact with the customer?s hardware.
Basic troubleshooting methodology is a technique in which a person can
efficiently close in on a customer?s issue using a systematic approach. In
general, each step is a logical approach that can save a person from
undertaking wasteful and time-consuming efforts.
Using the Troubleshooting Methodology, you will be able to more efficiently
target and resolve the customer?s problem.
Note: This lesson topic addresses troubleshooting at a high-level. Future
lessons and lesson topics will TArget the specific steps to take once a
particular root cause has been identified.
Troubleshooting Methodology (cont?)
Below are the steps that should be used to Diagnose and resolve a customer?s
issue:
1) Identify the symptoms.
2) Identify the scope of the problem.
3) Establish if anything has changed on the system. Recent hardware or software
changes may be causing the symptoms.
4) Determine the most probable cause of the problem.
5) Implement a solution.
6) Test the solution.
7) Recognize the potential effects of the solution.
8) Document the solution.
Let?s go through and describe each step?
Troubleshooting Methodology (cont?)
Steps for troubleshooting PC and network problems are as follow:
1) Identify the symptoms.
· This primarily consists of listening to what the customer tells you is
happening (i.e. ?I get Page Cant be displayed?).
2) Identify the scope of the problem- Layer 1
· The scope of the problem is determining the outer borders of the
problem. For example if a customer can?t surf. We then find out if she has
connectivity with any program. If she does not, then the scope of the problem
is a connectivity issue (sync no surf).
3) Establish if any changes have been made to the system.
· Recent hardware or software changes may be causing the symptoms. If a
customer has added a firewall or installed a NIC incorrectly, the customer may
experience problems that can lead to no surf issues.
4) Determine the most probable cause of the problem- Layers 2 through 6
· Determining the most probably cause of a problem is perhaps one of the
more difficult tasks to accomplish while troubleshooting. There will be times
that a probable cause is not always clear. It is important to have an
understanding about the problem and the general idea of the exact cause of the
problem. For example, if you determine that a customer has a winsock error,
you may not always know what caused the error, but you do know that it was a
corrupt winsock which caused the customer to be unable to surf.
We will focus on ?Layers? later in this lesson.
Troubleshooting Methodology (cont?)
5) Implement a solution.
· After finding the cause of the customer?s issue, you locate the
appropriate solution in database and walk the customer through the steps to
implement it.
6) Test the solution.
· Testing the solution is see whether or not the solution you implemented
actually resolves the customer?s issue.
7) Recognize the potential effects of the solution.
· This is very important because an action that you perform may impact
the customer?s computer drastically. For example, if you disable a firewall on
a customer?s computer and they are able to surf, you need to recognize that you
disabled the firewall and explain the effects of that action to the customer.
8) Document the solution.
· Make sure to completely document the call and place proper notes into
the database. This ensures that the steps you took are documented as well as
providing a template for a future agent who may run into the same problem with
this customer.
Troubleshooting Methodology and Layers
Now that we have established the step-by-step approach to troubleshooting an
issue, let?s focus on the first four steps in the process, which are:
1) Identify the symptoms.
2) Identify the scope of the problem- Layer 1
3) Establish if anything has changed on the system. Recent hardware or software
changes may be causing the symptoms.
4) Determine the most probable cause of the problem- Layers 2 through 6.
These four steps are probably the most crucial in the entire process, as it is
where we drill down to where the problem resides. To do so, it is important to
have a good idea of the various places where a failure can happen. Both the
physical representation of a customer?s DSL connection and the process behind
the connections can best be thought of in terms of ?layers?. We?ve identified
6 layers:
Layer 1- Probing Applications
Layer 2- Verifying Sync
Layer 3- Verifying LAN IP
Layer 4- Router/Modem GUI
Layer 5-Authentication
Layer 6- Applications
Let?s look at each layer individually?
At Layer 1, your goal is to find the extent of the issue. Instead of having a
very broad problem such as customer can?t surf, you want to narrow it down to
determine if it is a connectivity issue or a particular application that is
having the problem.
For example, when a customer calls stating that he/she can?t surf, first verify
if the customer can use other applications such as e-mail clients, chat
programs or surf to other web pages.
If the customer has connectivity using one of the other applications, then that
will be a good indication that there is a problem with the Layer 6
(Applications)
If the customer cannot connect using any other application, then proceed to
Layer 2 (Verifying Sync).
Layer 2 ? Verifying sync
Layer 2 concerns the interaction between the CPE and the DSLAM. It is at this
level that you check the CPE for Sync. A customer without sync won?t be able to
surf, send/receive e-mails, or chat with other users.
Some of the things to check here are:
· For changes in customer?s premises (Added Alarm system,
satellite/cable, new phones/fax, etc)
· Account status (change orders, cancellations)
· Cables Ethernet (CAT5) RJ-11 (Telephone)
· E-Repair tests
Layer 3 deals with the communication from the LAN side of the customer?s CPE to
the customer?s PC. Here, it is important that the customer receive a valid LAN
IP. For customers using their own (Westell or 2-Wire) or third party
routers, there will not be a PPPoE client installed on the customer?s PC.
Instead, the CPE or third party router will handle the PPPoE authentication.
In which case, the PC will obtain the IP address from the DHCP server on the
CPE itself.
Some of the things to check here are:
NIC in device manager
If TCP/IP is installed
TCP/IP configuration
At Layer 4, we focus on the connection from the customer?s PC to the CPE GUI.
Here we want to ensure the customer is able to connect. Keep in mind that sync
is not the same as connection. Sync is the ?connection? between the CPE (modem)
and the DSLAM.
Some of the things to check are:
If the customer can open the GUI using the default gateway IP address (ex
192.168.1.254).
If the customer can ping the default gateway in case he is unable to open the
GUI. That could indicate a browser/winsock issue.
While in the CPE GUI if it will connect and obtain a valid IP from some ISP
(Wan IP). If the customer is unable to surf, continue to layer 5 (verifying
WAN).
Layer 5 ? Authentication/WAN IP
At Layer 5, we deal with the connection from the WAN IP side of the CPE through
the some ISP network (i.e. Redbacks and authentication servers). If there is
a disruption here, a customer may experience a username/password failure or
similar error.
Some the things to consider when troubleshooting this Layer are as follows:
The WAN should not start with: 169.x.x.x, 192.x.x.x, 172.x.x.x, 10.x.x.x. (The
TCP/IP server provides 169 IPs to the TCP/IP client when the client can?t
connect with the server, and are not valid. 176 IPs, 192 IPs, or 10 IPs are
private IPs. They are used in LANs and are not routable over the Internet.)
Is the WAN IP pingable and/or can you run a trace route? (Some firewalls and
CPEs might block the ICMP (ping) requests and you won?t receive a reply for
pings or traceroutes.)
Layer 6 ? Applications
Layer 6 deals with the applications on the customer?s computer. From a
connectivity standpoint, these are the software on the customer?s computer that
access the internet, such as E-mail clients, Internet Browsers, and Instant
messaging programs. Within these programs, there are settings that need to be
checked and tested. These include:
· LAN settings
· Proxy settings
· PING
· Trace Route
· Anti-virus
· Firewalls
· Winsock
Troubleshooting Methodology -Example
We?ve outlined the step-by-step approach to troubleshooting. We?ve also
discussed the various Layers that we go through when using the step-by-step
approach. Now let?s look at an example that uses the troubleshooting
methodology and takes us through the 6 Layers towards resolution.
Troubleshooting Methodology Example (cont?)
Let?s say a customer calls in and tells you that he/she cannot surf. With this
statement alone, we have performed Step One- Identify the Symptom
We would begin by determining if the issue is connectivity or IE malfunctioning.
In other words, we want to Identify the Scope of the Problem- Step Two.
You would have the customer open Internet Explorer and read the error message.
Then, have the customer try to surf to other web pages. If this is
unsuccessful, you will then have the customer open up an email client or chat
program and check for activity. If there is no activity and they are unable to
use these applications as well, we know that the problem is not limited to a
single application. Thus, we have successfully probed the applications (Layer
1) and identified the scope of the problem- Step Two.
Troubleshooting Methodology Example (cont?)
We?ve identified the scope of the problem- the customer is having connectivity
issues. We would ask the customer if they have made any hardware or software
changes (Step 3). Let?s assume the customer has not.
We proceed to Step 4- Determining the most probably cause. At this step, we
proceed logically through Layers 2 through 6, starting with Layer 2- Verifying
Sync. This is done by simply looking at the CPE and checking the DSL light.
If the light is not solid green, we would focus our troubleshooting on this
Layer. If the light is solid green, we then know the customer is in sync and we
would proceed to Layer 3- Verifying LAN IP.
For this example the modem is in sync, so we proceed to Layer 3.
Troubleshooting Methodology Example (cont?)
At Layer 3, we want to verify that the customer?s computer has a valid IP
address, subnet mask, and default gateway. We can accomplish this by doing
ipconfig at the command prompt.
Verifying that these are correct, go into the TCP/IP properties to make sure
that the computer is set to obtain an IP address automatically. This will
ensure that the customer?s computer is talking to the CPE. All these things
being done, we want to try and get to the modem?s GUI- Layer 4.
Troubleshooting Methodology Example (cont?)
If you received the correct information in Layer 3, then you will need to try to
ping the CPE to establish two way communication and surf into the CPE (this is
the default gateway address, which is usually 192.168.1.254).
If we are successful in pinging the CPE and surfing into the CPE GUI, we can
then try to authenticate via PPPoE and validate the username and password-
Layer 5.
However, in this case we are unable to surf into the GUI. This means we bypass
Layer 5 and proceed to Layer 6- Applications.
Troubleshooting Methodology Example (cont?)
Let?s go over the details of our example, thus far...
Layer 1: We have determined that the customer is unable to surf.
Layer 2; We have checked to make sure the customer is in sync and that there are
no problems with the customers account such as provision issues in SOEG or
suspension of the account.
Layer 3: We have also checked to make sure that the customer?s computer is
receiving a valid IP address.
Layer 4: We have checked to make sure there is two way communication between the
computer and CPE. We accomplished this task by pinging the default gateway.
Layer 5: We were unable to surf into the CPE so we could not check the CPE
status nor could be check the authentication layer.
Now what??? Layer 6!!!
Troubleshooting Methodology Example (cont?)
ABSOLUTELY!
Now we are troubleshooting the application layer- Layer 6. There are several
tasks that should be performed here. You will need to check for winsock, proxy
settings, and firewalls. These are the main culprits for a sync no surf issue
when you reach the application layer.
The first step is to check for a winsock error. Opening a command prompt and
running an ftp test accomplishes this. The command that you will use is ftp
127.0.0.1. Depending on the error that is returned, you will know if you are
finished troubleshooting. In our case we received a winsock error message.
Note: Had this not been the case, we could have then checked the proxy settings
in IE and then check to see if the customer has a software firewall installed
on his computer.
So we?ve now determined the probably cause (Step 4) and would now move to Step
5- Implement the solution. You would proceed to database to find the correct
solution and walk the customer through the steps to fix a winsock error.
Troubleshooting Methodology Example (cont?)
Having fixed the winsock error, we move to Step 6- Test the solution.
Let?s assume in this case that the winsock error was resolved. We would test the
solution by attempting to surf in the CPE GUI, and if successful, authenticate
and attempt to surf. In this example, the customer can successfully surf.
There are no adverse affects resulting from the application of the solution
(Step 7- Recognize the potential effects), thus we ensure the customer is
satisfied with the service we?ve provided and proceed to document the call in
Call Tracker (Step 8- Document the Solution).
Had this not been the case we could have then checked the proxy settings in
internet explorer and then check to see if the customer has a software/hardware firewall
installed on his/her computer.
Summary
Being able to successfully resolve a customer?s issue is best achieved when
following a specific process. In this lesson, we have learned the basics of
just such a process. The Troubleshooting Methodology, when applied, will help
you isolate problems and come to logical conclusions regarding the necessary
solutions. In addition, we walked through a troubleshooting example that
follows both the Troubleshooting Methodology as well as the Layers within the
Methodology With this information you should be able to help pinpoint the
customers issues more quickly and effectively.
