Broadband expert John Navas of The Navas Group shares his top tips for keeping your connection up and running.

Page 1  2  3
Troubleshooting

  1. Can you get to your service provider? PING your DNS server.
    Internet providers supply at least one, and usually two, DNS servers (which convert names into actual Internet addresses) to subscribers. These are "nearby" nodes that usually respond to PING -- a good way to test your basic connection. Call your provider to request the numbered IP address of the DNS server. PING the numbered IP address at least 10 times. You should get consistently low latency with no packet loss, as in the example above. If you don't, run a traceroute/tracert to pinpoint the problem.

    • Problem 1A: Your local Internet connection
      Symptom: Erratic latency or packet loss starting on node 1
      If you're on a cable modem, your local subnet may be overloaded, particularly if you see this problem predominately at times of peak demand. If you're on DSL, then your DSL modem may be having problems with synch or errors. Either problem needs to be addressed by your provider.
      Example of problem 1A
      tracert 192.168.0.11
      Tracing route to ns1.example.com [192.168.0.11] over a maximum of 30 hops:
      1 21 ms 285 ms 316 ms gateway.example.com [192.168.0.9]
      2 291 ms 18 ms 192 ms ns1.example.com [192.168.0.11]
      Trace complete.
    • Problem 1B: Your provider's network or DNS server
      Symptom: Node 1 is OK, but erratic latency or packet loss on node 2 or up
      The DNS server or your provider's internal network may be overloaded or malfunctioning. These are serious problems that can be fixed only by your provider.
      Example of problem 1B
      tracert 192.168.0.11
      Tracing route to ns1.example.com [192.168.0.11] over a maximum of 30 hops:
      1 21 ms 19 ms 23 ms gateway.example.com [192.168.0.9]
      2 291 ms 18 ms 192 ms ns1.example.com [192.168.0.11]
      Trace complete.

  2. Can you get outside of your provider? Traceroute to a remote node.


    • Problem 2A: DNS failure
      Symptom: Can't resolve DNS name
      You may have the name wrong. Check it. Also check other names. If the name is valid, particularly if other names are also failing, either your Internet configuration is screwed up (e.g. DNS servers are not being configured correctly) or the provider's DNS server is acting up. You may be able to fix a configuration problem yourself (e.g. by manual configuration of DNS servers), but a DNS server problem is a serious issue that can be fixed only by your provider.
      Example of problem 2A -- deliberately bogus name
      tracert ss.techtv.com
      Unable to resolve target system name ss.techtv.com.
    • Problem 2B: Internet transit overload
      Symptom: Sudden jump in latency or packet loss at your provider's transit router
      Most providers are connected to the Internet by means of "transit" links, typically a small number of high-speed circuits that each carry traffic from a large number of subscribers. If a transit link gets saturated, which can easily happen if a provider isn't proactive about keeping capacity ahead of subscriber traffic growth, latency will climb at the provider's "border" router (node) as packets are queued to wait their turn. If the border router runs out of queuing capacity, it copes by simply discarding packets (packet loss). The solution is for your provider to install more capacity or for you to find a better provider if the problem isn't fixed right quick! In the following example, note the big jump in latency at the transition between the dummy ISP (example.net) and the transit. Each "*" is a lost packet. What matters is the first node at which the problem shows up.
      Example of problem 2B
      tracert www.techtv.com
      Tracing route to www.techtv.com [64.95.116.134] over a maximum of 30 hops:
      1 21 ms 17 ms 15 ms gateway.example.net
      2 18 ms 18 ms 21 ms internal.example.net
      3 19 ms 20 ms 17 ms border.example.net
      4 824 ms 565 ms 918 ms aaa.transit.invalid
      5 656 ms * 707 ms bbb.transit.invalid
      6 * 943 ms * ccc.backbone.invalid
    • Problem 2C: Internet overload
      Symptom: Latency or packet loss starting beyond the transit
      Capacity problems on Internet "backbone" circuits and major connection nodes are much less common than some providers would have us believe. Further, most providers will claim they're not at fault when it happens. However, they do sometimes occur, particularly when there's a critical failure (e.g. major cable inadvertently cut by a clumsy backhoe operator). This would be much like the example immediately above, except that the problem shows up at a later node.
    • Problem 2D: Routing problem
      Symptom: Packets 'looping' until the trace expires
      When routing "tables" (the Internet "map") get messed up, packets may get sent to the wrong place or even stuck in a loop. There usually isn't much your provider can do about this except to report the problem. Note how the following example gets stuck in a loop (that continues until the packet expires) between ccc and ddd.
      Example of problem 2D
      tracert www.techtv.com
      Tracing route to www.techtv.com [64.95.116.134] over a maximum of 30 hops:
      1 21 ms 17 ms 15 ms gateway.example.net
      2 18 ms 18 ms 21 ms internal.example.net
      3 19 ms 20 ms 17 ms border.example.net
      4 25 ms 27 ms 22 ms aaa.transit.invalid
      5 24 ms 24 ms 21 ms bbb.transit.invalid
      6 34 ms 33 ms 33 ms ccc.backbone.invalid
      7 32 ms 41 ms 38 ms ddd.backbone.invalid
      8 35 ms 31 ms 44 ms ccc.backbone.invalid
      9 46 ms 37 ms 39 ms ddd.backbone.invalid
      10 33 ms 34 ms 34 ms ccc.backbone.invalid



Page 1  2  3