17

I originally titled this "how to tell if your internet is down or your network is just screwed up" and Jeff's AI said that this questioned would probably be closed.

Nevertheless, someone here is always on the phone with the ISP and it's usually our fault. What are some of the best techniques for telling whether you've got an issue or they've got an issue.

I know this might be too much of a blanket question, but in a case where there's intermittent latency and disconnects (not just overall outages [i.e. can't ping google.com]) what do you do before calling the ISP?

Peter Turner
  • 2,048
  • 9
  • 33
  • 45

9 Answers9

16

Things I check when troubleshooting a network issue with a provider. Note here that 'ping' means 'do an extended ping, sweeping a range of sizes, and sending at least 1000 packets at each size, looking for latency, loss and errors'.

  1. Ping your ISP's hand-off from a device on the same subnet. (Confirms that there are no L2 problems between you and your ISP).
  2. Ping your ISP's hand-off from a device on one of your internal subnets. (Confirms that you have no routing/security issues between your internal network and your ISP)
  3. Ping an IP in your provider's network. If you can't find one that's publicly listed, or the helpdesk won't give you one, do a traceroute to something in the internet, and use the second or third hop. This confirms that routing between you and your ISP is configured correctly.
  4. Ping an internet IP. I normally use 4.2.2.1, one of Level3's DNS servers that is easily remembered. This confirms that routing from your ISP to the specific IP you've pinged is correctly configured.
  5. Ping an internet domain name. This verifies your/your provider's DNS configuration is correct.

If steps 1 or 2 fail, it's most likely a problem on your internal network.

If step 3 fails, there would appear to be a problem in your provider's network. Note, though, that if you get no response at all then your ISP may have simply blocked ICMP to/from their infrastructure addresses.

Step 4 failing indicates a potential problem between your ISP and one of their upstream providers.

Step 5 failing indicates issues with name resolution.

Hope that helps.

Murali Suriar
  • 10,166
  • 8
  • 40
  • 62
  • This is a fairly good procedure for your help desk to have documented to open a ticket with the provider reactively before having to call the network admins to confirm. Always nice to have the ISP notified ASAP when the business is offline. – sclarson May 26 '09 at 20:07
  • How do I know what my ISP's "hand-off" is? – jvriesem Aug 30 '15 at 20:26
6

A handy test site is: http://downforeveryoneorjustme.com/

Pings and traceroutes are some of the first and best tests when beginning this sort of investigation. Firewalls may block this traffic however.

Don't just stop at normal pings. Try ping <ip address> -l 2048 to send some big packets and make sure it's not a fragmentation/MTU issue.

Check your utilization -- your tubes may be full.

sjagr
  • 103
  • 4
Peter
  • 5,403
  • 1
  • 25
  • 32
  • 2
    www.keynote.com also provides a lot of useful info, as well as running the www.internethealthreport.com site. – gharper May 26 '09 at 20:59
  • Jeff Atwood mentioned this site http://just-ping.com/index.php in this question (http://serverfault.com/questions/42678/dns-failing-to-propagate-worldwide) which could also be handy for testing from a global perspective. – Peter Jul 31 '09 at 19:49
  • @Peter: when I try that command you suggested, I never get anything back. Is there perhaps a limit of 1024 to the ping server buffer sizes? – jvriesem Aug 30 '15 at 20:21
  • @jvriesem the host or a firewall along the path may be set to not respond to pings. Try regular pings & traceroutes. – Peter Sep 16 '15 at 18:34
  • I use isup.me much shorter – briankip Sep 18 '15 at 10:41
2

It's also good to check TCP connection count with for example

Some applications might spawn a lot of TCP connection simultaneously and this causes that you cannot create new connections but existing connections like SSH still keeps going.

DSL modem can also choke on lots of connections.

This usually only affects Windows machines.

raspi
  • 811
  • 1
  • 9
  • 21
1

We had an issue with our ISP and the tool Ping Plotter came in very helpful. You can set it to ping a router at the ISP's internet gateway, or in our example we told it to ping from a regional office back to the corporate office. In this example, it was going through a couple different ISPs. Best of all you can set it up on an old desktop or a virtual machine, and let is sit there pinging away collecting data until you need it.

Because it shows each router in the path, and the time it takes each one of those routers to return a response it is very useful to spotting trouble spots further downstream.

Aaron
  • 1,002
  • 1
  • 12
  • 18
  • Smokeping can be used in a similar way, although you'd have to add several hosts in the path as it doesn't traceroute, only ping. – LapTop006 May 27 '09 at 13:15
0
  1. Examine your switches and routers to see if there are high collisions or traffic
  2. Try plugging a single machine to your outbound router to see if the problem goes away.
Jack B Nimble
  • 1,505
  • 1
  • 10
  • 13
0

There is a wonderful, simple to use tool on linux called MTR (short for My Trace Route) which will show you packet loss at every step of the route, and can even help you hunt down flapping routes.

Matt
  • 1
0

The best tool is the scientific method. Form a hypothesis about the cause of the problem. Write it down. Formulate an experiment that will test the hypothesis. Write it down. Conduct the experiment. Write the result down. If the experiment confirms the hypothesis, then you're done. If it fails to confirm the hypothesis then you need a new hypothesis. If it's inconclusive then you need a new experiment.

Mike Scott
  • 7,903
  • 29
  • 26
-1

If you can ping past your router, it's probably their fault. If you can't, then it's yours. Use tracert to figure out where the packets are falling.

Orihara
  • 607
  • 5
  • 11
-3

Try pinging any Outbound website. If you can do so, everything is fine within you network. Contact your ISP.

Anonymous
  • 1
  • 1
    I can think up any number of scenarios where this statement is fundamentally wrong. – Sven Jul 22 '16 at 11:15