ADSL Troubleshooting Methodology
Results 1 to 6 of 6

Thread: ADSL Troubleshooting Methodology

  1. #1
    AO's MMA Fanatic! Computernerd22's Avatar
    Join Date
    Mar 2003
    Location
    Miami, FL
    Posts
    765

    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.

  2. #2
    AFLAAACKKK!!
    Join Date
    Apr 2004
    Posts
    1,065
    You don't think this deserves to go in the tutorial section??
    I am the uber duck!!1
    Proxy Tools

  3. #3
    Senior Member
    Join Date
    Feb 2004
    Posts
    270
    someone move this to the tutorials.

    It deserves it.
    Since the beginning of time, Man has searched for the answers to the big questions: \'How did we get here?\' \'Is there life after death?\' \'Are we alone?\' But today, in this very theatre, you will be asked to answer the biggest question of them all...WHO LIVES IN A PINEAPPLE UNDER THE SEA?

  4. #4
    Senior Member
    Join Date
    Oct 2002
    Posts
    1,130
    While this is indeed a very good tutorial, I believe it is someone else's work, and although you have clear permission to use it, remember that by placing it here you are giving EnterpriseITPlanet a license to use it. Your trainer might not have agreed to this had he been aware of this. There may well be legal hurdles to posting this content of whilch both you and I are unaware of.

    Also, when posting someone else's work, you should really add your own comments to the material to make it your own. This would set it apart from your source. The sticky in the tutorials form explains that
    In other words, you can copy a small portion but cutting and pasting an entire article is not allowed. If you do want to cut and paste the entire thing, then you need to include a lot of criticism/comment/reporting/teaching, so that the cut and paste is not the primary part of your post.
    (I think Souleman originally wrote that)

    Now don't get me totally wrong. The information is very useful to a lot of people here. It's just treading on thin legal and ethical ice.

    Cast my vote in to move to the tutorials forum also.
    Government is like fire - a handy servant, but a dangerous master - George Washington
    Government is not reason, it is not eloquence - it is force. - George Washington.

    Join the UnError community!

  5. #5
    Super Moderator
    Know-it-All Master Beaver

    Join Date
    Jan 2003
    Posts
    3,914
    Hey Hey,

    It's definately a nice piece of information... I haven't fully read it, but I will later when I'm awake..

    Since it's not an original work, I wouldn't vote to put it in Tutorials... however I think it should be removed from Newbiew Sec Questions... perhaps, Networking Security... but since I don't see any security corelation, I'd prolly suggest Computer Discussions.. .

    You can tell that it's obviously a cut and paste from some sort of document, and while it's good information to share, I think that it should be cleaned up a bit... The ? in place of ' and things like that are one of the things I noticed.. The other was the first paragraph, which seems like it had a table of some sort, and the data was just CnP right out of it.... Because the terms and the definitons don't meet up and are scattered...

    Anyways... thanks for sharing... I'm going to read it over more in depth later.

    Peace,
    HT
    IT Blog: .:Computer Defense:.
    PnCHd (Pronounced Pinched): Acronym - Point 'n Click Hacked. As in: "That website was pinched" or "The skiddie pinched my computer because I forgot to patch".

  6. #6
    THE Bastard Sys***** dinowuff's Avatar
    Join Date
    Jun 2003
    Location
    Third planet from the Sun
    Posts
    1,250
    While I agree that tut's MUST be your own, there is a lot of value here. Touching on the OSI model and, though somewhat fragmented, keeping with logical methodologies in troubleshooting; perhaps this should be placed in the Tutorials section. If the original author did indeed give permission, why not? As long as the author is credited.

    Anyway, well done. I think I will post more in the A.M. I need to digest a little more. Each layer has it's own relationships and unique definitions as to the "why's and why-not's" in troubleshooting.

    Please post the source - if you have permission.

    Thanks,

    Dino
    09:F9:11:02:9D:74:E3:5B8:41:56:C5:63:56:88:C0

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides