Troubleshooting network traffic

What may be anticipated from this guide/process

Some people recommend a “bottom-up” approach, which would mean starting by checking physical connectivity. Then, following the bottom-up approach strictly would mean checking that the MAC addresses are working as desired. Then, check IP addresses as troubleshooting continues to move up the OSI Model. Other people have expressed favor in the “top-down” approach, which is to start focusing on Application-level issues, and then later making sure that software is listening to the expected TCP ports, and then focusing on IP addresses.

In practice, a “middle” approach is often used by experienced technicians. Since IP-based troubleshooting is often some of the easiest, quickest, and very informative bit of troubleshooting, that is often tried first. Then, people move up or down the OSI Model as appropriate.

In truth, the best way to troubleshoot an issue is to make sure there is clarity of what the known problem is, and to think about what might be causing that issue. Doing that may help someone to select between a middle-first, bottom-up, or top-down approach.

However, sometimes the problem can be quite elusive. When basic IP communications do not seem to be working as expected, this guide provides several steps to help make sure that network-based traffic is taking the route expected.

This is not meant to cover some of the most obscure problems such as a lack of support for IPv6 Routing Header Type 0 traffic. This really just covers some types of connectivity that are common enough that many network administrators will encounter them, but many of them will encounter the issues infrequently. Hopefully this will help resolve many issues, and add some clarity to other problems so that they are narrowed down better.

Even an industry-certified network professional can easily struggle with some of these issues, in part because there are so many possibilities for certain basic things to go wrong. Just having a checklist can help address issues in an orderly fashion without accidentally skipping some useful troubleshooting. Following the guide may help speed up efforts to isolate a problem to a more narrowed-down issue.

Also, for those who are more experienced, this checklist may be a pleasantly fast way to quickly provide some assistance that can help a technician to successfully isolate an issue.

Care of impact

Determine what impact(s) will likely occur when actions are taken.


If a technician is remotely working on a computer, and plans to disable a network interface and then re-enable the network interface, what happens after the network face is disabled? The technician may lose the remote access connection, and be unable to re-enable the network interface. Such situations can often be resolved by using some sort of process that will automatically re-enable the interface once it is disabled. Just think about what will happen.

Before changing settings, make a documented note (whether electronic documentation, or paper documentation) on what the old setting was. Many people have encountered easily avoided troubles because they just tried to remember settings, but then found a reason to try some other technique to fix an issue, and then ten minutes later find themselves wanting to reverse their actions, but by then they forgot the previous settings. (Such a problem may be more common when the settings are somewhat lengthy, like an IP address, rather than a simple radio button.)

Who is affected

For instance, on a test network controlled by a single technician, and really only used that person, there may be little reason to avoid making changes to functional equipment. If the equipment being worked on serves an entire business with dozens of employees, shutting down an Internet connection may be a bigger problem. On the other hand, removing power from a DSL modem might not cause any real troubles if Internet access is not working for anybody anyway.

New professional technicians, or technicians in training, might be best off reporting their plans to supervisors before proceeding with actions (like adjusting cords, or guiding someone over the phone so that person adjust cords) that affects network infrastructure devices in ways like removing power from a device, re-wires devices, or alters the configuration of network infrastructure devices.


If actions, or non-actions, may affect other people, communicate. For instance, if there is an alerting system that informs technicians of some unexpected network non-connectivity, and then a technician gets a phone call from somebody who says the network is down, then the technician may want to check to see if the alerting system has generated an alert about the problem. Also, the technician may want to make a note (in a chat room on a private server used only by employees who are on-duty, or in the ticketing system... whatever is standard practice for the organization) so that other employees know what is going on in case another employee ends up noticing an automated alert or a phone call that points out the downtime.

[#iprtckfw]: Checking firewalls

This is something to keep in mind as a possible issue. Firewall settings could affect each of the other stages of this troubleshooting. Although a firewall is not necessarily the first item to check, and often might even (sensibly?) be about the last item checked, do always keep this in mind as a possible issue.

The most common firewall setting that people will often think of is a firewall on the destination address. Another possibility, which can often affect things, is a firewall on the source computer which is blocking the reply traffic. This is fairly common and prevents TCP connections from establishing, and (of course) reply traffic from other protocols. When troubleshooting communications, do keep both directions of IP traffic in mind. Other possibilities are a firewall (on the source, or the destination sending a reply) blocking outgoing traffic, or some firewall/“traffic shaper” in the middle adjusting traffic. However, firewalls in the middle are typically a less likely issue if the middle seemed to respond to appropriate tools (including using an appropriate traceroute-style command to the desired remote destination, and ICMP (ping) to device in the middle).

If the problem seems to be with a firewall setting, fix that setting. If the problem has not been identified with a firewall, but a firewall is running, consider whether the firewall may temporarily be safely turned off completely. (This might be a disaster for heavily used network defence equipment that protects an entire network for attacks. It may be non-impacting if talking about the software-based firewall bundled with the operating system of an individual client computer.) If turning off the firewall would be safe temporarily, do so. Then see if the traffic is fixed. Then, regardless of whether or not the traffic is fixed, turn the firewall back on before forgetting to do so. Then, if turning off the firewall did fix things, figure out how to adjust the firewall (or determine the expected consequences of leaving it off forever). (For details on adjusting the firewall, see: Firewall Implementations or, more broadly, Firewalls.)

[#iprtcksf]: Can the system ping itself?

Determine how well the system can ping itself with both a non-loopback address and a loopback address.

Be able to identify common “loopback” addresses
Self IP non-loopback address

Choose an address that is not a loopback address. Run ping on that address.

If the computer cannot ping its own IP address, that usually means an incorrect IP address assignment. (In other words, the IP is not set at all, or the IP address setting has the wrong IP address.) See: getting a current IP address.

If the system really does show the right IP address, but it is not working, then verify if communication with a loopback address works. (If not, then fixing communication over loopback might be simpler than communicating with the non-loopback address. However, perhaps usually due to possible firewall configurations or requirements for configuring loopback addresses (as seen on Cisco IOS), that may not always be the case: loopback might not be easier to troubleshoot.)

If communication works with loopback but not non-loopback, this might be because of a firewall. (See: checking for a firewall.) Otherwise, the problem is likely a more unusual issue with the network implementation: it may be an issue with the driver for a NIC (particularly if it affects only one network card), or an issue with the TCP/IP support (as described by MS KB 169790). Take a serious look at those possibilities before spending time trying some of the later troubleshooting steps.


Can the system ping the loopback address(es)?

This has been known to be an early check to perform on some operating systems: MS KB 169790 recommended it. That article was for Windows Millennium Edition and earlier, including Windows 2000. XP Pro documentation for testing TCP/IP mentioned this as an early test.

In truth, this is very rarely the problem, and this technique has been de-emphasized in newer documents: both MS KB 314067 for Windows XP, and TechNet: Test Network With Some ICMP-using Commands cite this as being an unnecessary step if the address was manually verified after running IPConfig.

Still, on many platforms, if this does not work, that may represent a severe problem with TCP/IP functionality. (This is not a problem with Cisco IOS by default, since by default there are no configured loopback addresses. For many other systems, a problem communicating over loopback does indeed represent a severe problem with the relevant TCP/IP functionality.) MS KB 169790 recommended removal and then re-installation of TCP/IP support (as a rather standard process for fixing this type of problem).

[#iprtcksb]: Check: communication with a subnet

Determine how well the system can communicate with any other system on the same subnet.

Determining if a device is on the same subnet

Understanding subnets will help with that. In a nutshell, a certain amount of the network address bits need to match, and so a certain portion of the first decimal and/or hexadecimal digits tend to match.

However, for those looking for simple steps: Very often devices on the same subnet can be located by finding a device that is connected to the same switch or wireless access point, so that the network traffic does not need to do any sort of routing (or NAT). For wireless connections, this means a device using the same wireless connection (using the same SSID). For wired connections, this involves communicating with a router or firewall or wireless access point, or a device on the same side of the network as any of those devices, but not a device that is on the remote side of any of those devices. If communicating with one of those devices, make sure to communicate with the IP address that is part of the same wired network connector. If the network needs to involve another network connector on one of these types of devices, that often indicates they are part of a different subnet. There are exceptions, though, like if a firewall is bridging traffic and providing functionality that is no more advanced than what a simple switch provides. So, consider this whole paragraph to be a bunch of generalizations.

Here are some possible addresses to consider:

  • The destination address (if it is on the same subnet)
  • The default gateway (often visible where network settings are set up; even more likely to be visible by viewing the routing tables)
  • Addresses found in neighbor cache
    • For IPv6, Unix users may run: “ndp -a
    • For IPv6 and “arp -a” for IPv4
  • Any other address that is suspected to be responsive. (Network documentation may help to find this.)
If this communication fails...

If communication does not work with other devices on the subnet, double-check that the IP address is set correctly.

Also double-check that a correct value is being used for the “prefix length” (or a similar setting, such as “Subnet mask” which is commonly used with IPv4). Some people may think that an incorrect subnet mask will completely break communications, although it is possible that some subnet mask values may permit communications with some IP addresses while preventing communications from working with other IP addresses.

Use “media sense” to check that the networking link is up. (In WinXP, check if a “Media State” line exists. If so, it may say “Media State”. Media sense might also currently be discussed at: troubleshooting methdos page.) If the link is disconnected, many other aspects to network communication will not be working, so fixing the link may be a top priority.

Make sure that each of these checks is performed on both the sender and the receiver. (There may be cases where delaying such tests on some equipment makes sense: if the equipment has been functional, and/or checking the equipment is more of a challenge like if it is administered by different technical staff or needs physical interaction and is at a remote location, then perhaps delay those checks, but do keep this in mind as a troubleshooting step that is worth performing.)

Check that firewalls are not causing problems: see checking firewalls.

Verify that the hardware appears to be working as expected. This may mean checking that link lights are lit.

Make sure that checking if a system can properly communicate with itself has been performed.

Consider replacing equipment, such as an Ethernet cable.

Buffer issues
Issue description

This issue has been cited on OpenBSD, and apparently also FreeBSD. It seems like the reported error messages are likely specific to this implementation, so other operating systems may be less likely to behave identically.

Sometimes, a system may be unable to contact the local gateway. When the system is experiencing this sort of issue, a message might appear, such as:

However, sometimes the issue doesn't seem to get resolved quite so easily.

Info gathering

Post by Claudio Jeker notes that this error “means an ENOBUF error was returned. On modern systems ENOBUF is almost only generated by the interfaces and their queues”. man page mentions ENOBUFS.

First, gather some details. Run:

ifconfig output

Look at the status. (“status: active” is a good sign.)

If status is active, also check for the “OACTIVE” flag, which is a less good sign. The “OACTIVE” flag indicates that the system is trying to transmit (the O apparently stands for “outgoing”). If that flag is remaining active, the transmission is likely unsuccessful.

netstat -m
Example when a system is working well, right after a reboot: 19 mbufs in use:
\t12 mbufs allocated to data
\t2 mbufs allocated to packet headers
\t5 mbufs allocated to socket names and addresses
9/20/6144 mbuf 2048 byte clusters in use (current/peak/max)
0/8/6144 mbuf 4096 byte clusters in use (current/peak/max)
0/8/6144 mbuf 8192 byte clusters in use (current/peak/max)
0/8/6144 mbuf 9216 byte clusters in use (current/peak/max)
0/8/6144 mbuf 12288 byte clusters in use (current/peak/max)
0/8/6144 mbuf 16384 byte clusters in use (current/peak/max)
0/8/6144 mbuf 65536 byte clusters in use (current/peak/max)
0 Kbytes allocated to network (0% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Example when a system wasn't working well: 301 mbufs in use:
\t292 mbufs allocated to data
\t3 mbufs allocated to packet headers
\t6 mbufs allocated to socket names and addresses
288/310/6144 mbuf 2048 byte clusters in use (current/peak/max)
0/8/6144 mbuf 4096 byte clusters in use (current/peak/max)
0/8/6144 mbuf 8192 byte clusters in use (current/peak/max)
0/8/6144 mbuf 9216 byte clusters in use (current/peak/max)
0/8/6144 mbuf 12288 byte clusters in use (current/peak/max)
0/8/6144 mbuf 16384 byte clusters in use (current/peak/max)
0/8/6144 mbuf 65536 byte clusters in use (current/peak/max)
0 Kbytes allocated to network (0% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
post about unbound shows Kbytes allocated. post shows 78% in use.
systat mbufs
Example on a system that was working well:
    1 users    Load 0.26 0.34 0.21                     Wed Feb  3 21:50:50 2016

System                    0   256    26           4
                             2048    17          16
em0                          2048    13     2   256    13
Example on a system that was not working well:
    1 users    Load 0.26 0.34 0.21                     Wed Feb  3 21:50:50 2016

System                    0   256   304          65
                             2048   292         155
em0                          2048    26     2   256    26
Note: It seems potentially interesting that the number of ALIVE mbufs matched netstat -m's output.
Quick remedy

The issue might be a bit intermittant. Here are some steps to get connectivity back right away:


You may wish to try increasing the buffer space. However, if this works, consider that it will probably be a temporary fix. That may fix things for several minutes or hours, and be the fastest way to get a bit more uptime. However, expect further issues to be likely unless something else is also done to address this situation.

Unfortunately, the way to do this may differ between different operating systems. Changing a sysctl is common. pfsense: pfsense: mbufs suggests “kern.ipc.nmbclusters”. FreeBSD list post suggests also checking the “dev.em.1” sysctl. Stuart's post pointed out net.inet.udp.sendspace (and net.inet.udp.recvspace). (It seems interesting that the setting references “udp”; the issue doesn't seem to be UDP-specific.) TCP tuning shows kern.mbuf.nmbclusters for NetBSD.

If this doesn't fix things, try following this up with a bounce (as described next), in case some part of an initialization process (like re-running a DHCP client) ends up being helpful.


You may wish to try bringing the NIC down and back up. This might be as simple as flipping the UP flag for the NIC. If that doesn't work, try the more complex step of performing the network initialization (e.g., in OpenBSD, netstart on the applicable NIC).

If the NIC is USB-based, maybe turning the NIC off/on (via a command that affects USB power?). Or, turn off the NIC via some other means (if the NIC has a power switch)?


Rebooting the whole system. This does “fix” the issue, in the short term. The speed of a recurrence may seem to change. For instance, Fernando's message posting indicates this could crop up in a couple of days, or a week.

This plus side is that there are many instances where a system reboot has been known to clear up the buffer space, so this may be very likely to fix things in the short term. Then, additional changes may be done at a chosen time (in the near future).

Long term fix

This is highly elusive. Possible approaches could be:

  • Excessive traffic has been known to cause this. This cause for these problems has been known to be certain settings in the firewall configuration, specifically related to traffic prioritization (queues). If you have made recent changes of this type, then Post by Claudio Jeker recommends looking at the output of “pfctl -sq -vv”. Otherwise, numerous success stories come from people who simply reverted recent changes. Forum post indicates the cause may be “running into the qlimit”.
  • Check hardware. Issue has been known to be caused by:
  • Some discussions have suggested that the issues may be related to certain network card drivers. Consider updating the card's network driver (which might typically be done as part of an “operating system” upgrade, for some platforms) or changing hardware so that a different driver may be used.
  • Maybe other approaches: pfsense documentation of network card buffers filling
[#iprtcksp]: Check: Communication involving special restricted subnets
IP address ranges reserved for “Private” use

Probably the most common issue involving restricted subnets, this involves communications with an address range that is reserved for “private” (locally assignable) use. For IPv6, these are generally addresses that start with the FD00::/8 block and perhaps also the FEC0::/10 block. For IPv4, these are IPv4 addresses that start with 192.168. or 10. or 172.16. through 172.31. (which means the addresses are in: 10/8 or 172.16/12 or 192.168/16).

If addresses from any of these ranges are trying to communicate with addresses that are outside of those ranges, then some considerations need to be dealt with. Make sure that forwarding is enabled (which, quite possibly, will often not be the problem). If these are IPv6 addresses, some proponents will suggest re-numbering to use public IPv6 addresses. The other approach, which works for IPv6 and is probably a required approach when working with IPv4, is to enable NAT. See: enabling NAT for IPv4, handling traffic routing, NAT.

Link-local addresses
IPv4 169.254/16

For IPv4, know that addresses in most of 169.254/16 subnet are “link-local”, and generally should not be able to communicate with any devices that are outside that IP address range. Also, these IP addresses cannot communicate beyond the local subnet.

Note that IPv4 devices do not typically have multiple IPv4 addresses (except for multicast addresses, although even that is a bit uncommon just because IPv4 multicast is often not used). So, if a device has a link-local IPv4 address, this generally means that it does not have an IPv4 which is not link-local. That is the problem.

The most common reason that a device shows an IPv4 address from this range is because the device tried to use DCHP/IPv4 but failed to get a DHCPAcknowledgement (usually because the device did not get a DHCPOffer). The best way to handle this is usually to fix communication with the DCHP/IPv4 server (including making sure that the DCHP/IPv4 server software is actively running). Otherwise, using a non-conflicting statically-assigned IPv4 may be a helpful short-term resolution (until DCHP/IPv4 gets fixed). In Microsoft Windows (perhaps XP and newer; not Win98SE), the next best way to deal with this may be to visit the “Alternate Configuration” tab of the window for “TCP/IPv4 Properties” (or just “TCP/IP Properties” for pre-Vista operating systems).

IPv6 FE80::/10

NICs using IPv6 will have an address from the FE80::/10 IPv6 block (which is a requirement that can be determined using information from RFC 4291: IPv6 Addressing Architecture (“ADDRARCH”), section 2.8: “A Node's Required Addresses” and RFC 4291: IPv6 Addressing Architecture (“ADDRARCH”), section 2.5.6: “Link-Local IPv6 Unicast Addresses, and details like understanding the binary mentioned in those documents). So, at least one address from this range is a basic requirement, unlike in IPv4 where the presense of a link-local address is often an indicator of an automatic addressing failure.

Because every enabled NIC has an FE80::/10 address, connecting to a remote system's FE80::/10 address is not as easy as looking on the local machine to find a NIC with the FE80::/10 subnet configured. Any communications to a remote FE80::/10 address will typically need to specify which NIC to use. This may be rather inconvenient because it means most software supporting all IPv6 addresses will need a way to have a NIC be specified, as well as the IPv6 address.

[#iprtcknr]: Check: Communication with another subnet

Check: Communication with another subnet.

Determining if an IP address is on a remote subnet

Understanding subnets will help with that.

However, for those looking for simple steps: Very often other subnets can be located by finding a device that performs some sort of routing (or NAT), such as a router or firewall or wireless access point, and seeing the IP address of a different network connector on that device.) Then, make sure the communication involves using at least two network connectors (like two Ethernet ports, or a wireless antenna as well as an Ethernet port). If the network needs to involve another network connector on one of these types of devices, that often indicates they are part of a different subnet. There are exceptions, though, like if a firewall is bridging traffic and providing functionality that is no more advanced than what a simple switch provides. So, consider this whole paragraph to be a bunch of generalizations.

If communication is not getting past a remote device, and that device has IP addresses on multiple subnets, try communiating with the device's IP addresses on a remote subnet. (Specifically, it is generally best to try using subnet that is on a different NIC of the device. That is usually what happens anyway, when communicating to different subnets.)

If communication works with at least one address on the remote subnet, but not other devices on the subnet, then the problem is probably one of the following situations:

Remote device is not forwarding packets

On the remote device, enable forwarding. (See: Implementations of traffic fowarding: how to forward traffic.)

Dealing with private addresses

See (the prior section about) special, restricted addresses.

Routing issues

This may be on the device initiating the traffic, the device that should be receiving traffics (as it might receive traffic but be unable to reply), or the device in the middle. See the steps to view routing tables. The “default” route (which might be labeled as default or 0/0 (::/0 in IPv6 or in IPv4) contains all unspecified subnets. Keeping that in mind, make sure the routing table has an appropriate route for the network traffic that is not working. Also, make sure that the destination for that route accurately shows the correct IP address for the next hop or, perhaps less commonly, the correct network interface (NIC).

Make sure that the remote system is set up to route the replies. (announcing new subnets.)

Note that some programs seem to report issues like “No route available” (or something like that) even if the routing table is fine. The issue may just be an inability to create a connection to the default gateway, which could be caused by firewall restrictions or issues like network failure (due to hardware issues, or critical buffer memory filling (possibly due to hardware issues), etc). So if error messages complain about routing, then do due diligence by checking the routing table. (Experience suggests that actual routing issues, which can be verified by investigating the routing table, are actually the most common cause of such messages.) However, if the routing table seems correct, do suspect that something other than routing could be the cause. An inability to communicate with another device, on the same link/subnet, may be the actual issue.

(If each of the previous steps has not revealed any solutions, perform all the recommended checks related to communication within a subnet.)

Check communications with a more remote system of a remote subnet
Able to communicate with an IP address used by a NIC on a remote machine, but nothing else in that subnet

In some cases, the problem may allow an intermediate router to seem to be able to communicate with its own NIC, but not remote NICs. (This is especially likely if the problem is actually with the remote system.)

This may make the problem less likely to be an issue with the local machine's routing. However, all of the other troubleshooting steps mentioned in Check: Communication with another subnet seem like likely fixes.

Having just stated what is most likely, the local machine's configuration could somehow affect traffic in at least one direction. So, make those tests last (for the sake of efficiency), but don't rule them out completely.

If a system is able to communicate with all sorts of internal devices, but not the public Internet

If the problem is with IPv4 communications, make sure that the “private” locally assigned IP addresses are not being sent to the Internet. With IPv4 this generally means to start using NAT. See: Check: Communication involving special restricted subnets. (If that resolves the problem, then shame is deserved because of skipping that step earlier.)

Make sure that communication with the default gateway is working.

If the default gateway is an internal device, make sure that communication with that device's default gateway is working. For networks of homes and small businesses, this process will eventually mean checking communications with the default gateway of a device like a DSL modem or a cable modem. This effectively tests communication to the ISP.

When it seems like communication with the ISP is broken

A possible cause is that communication to the ISP is, indeed, broken.

If communication from a computer to with that ISP IP is not working, check if the connection device (like the DSL modem or cable modem) is capable of running network tests with the Internet provider.

If communications with the Internet provider are not working, look to see what connection status indicators are showing for the device. This generally means looking for lights with names of “Power”, “Internet”, and either “DSL” or something similar (like “Cable”). All of those lights should be lit. If they are not lit, or if one of them seems to be red or some other odd color (like a yellow/orange light when all other lights are green), then make a clear note of what lights are lit. Then, flip off the power switch on the device (if there is a power switch, which often there is not) or unplug the power from the device for a length of time.

DSL info

CenturyLink.com “No internet connection?” page states:

Check the lights on your modem

In general, when everything is working correctly the modem lights should look like:

  • Power light: green (solid)
  • DSL light: green (solid)
  • Internet (INT) light: green (flashing)
  • Wireless light: green (flashing), if you have wireless capabilities
  • Ethernet light: green (flashing), if you are connected by an Ethernet cable

Lights don't look right? Learn what to do when the modem lights aren't the right color.

Following are some details that may be applicable to some known major provider(s)...

CenturyLink DSL
Internet outage

Obtain your CenturyLink account number. In many cases, this will be needed to successfully resolve a problem. If you don't have that readily available, that is unfortunate. Find some paperwork (which may have come with the modem), and get that information, and then make sure it is documented in a known location (which you can get to when the CenturyLink DSL modem is down). Also know (or have documented) the 5-digit billing ZIP code. Simply knowing the details that are used to pay the bill is often insufficient.

You may want to try the online troubleshooter. Realize that this might lead to a spot where the CenturyLink account number is required.

CenturyLink Service Troubleshooter

Go to ServiceAssistance.CenturyLink.com: Service Troubleshooter

If the next page says “Test Result:” “We checked your account for conditions that might be affecting your service, but didn't find anything.”, then...

... click on “Internet Problems”, and then “Run Data Link Test”.

If the website directs you to contact technical support, this hyperlink may be useful: technical support. (Again, that is a resource that will ask for the account number.)

Chat has proven to be slow (simply due to staff members being very slow to respond, even to simple and direct inquiries following a customer providing useful technical details) on multiple occassions. If you'd prefer to call, you may wish to try a technical support line: 1-800-247-7285

Outgoing SMTP traffic
Port 25 Filtering: see http://qwest.centurylink.com/internethelp mentions “Port 25 Filtering.

The length of time to keep the device powered off can vary. If time is critical and gambling for likely quickest resolution is desired, then typically five seconds is plenty.) This probably fixes things 80-95% of the time. On a very rare occasion, a device seems to malfunction until power has been completely removed for a much longer time, like 90 seconds. If this quicker-length power cycle attempt does not lead to any improvement within a few minutes after plugging the device back in, do try leaving the device powered off for 90 seconds to 2 minutes. People who don't wait to gamble for a fast fix could just leave the device powered off for two full minutes. The longer power cycles are quite rare to actually fix things, but multiple experienced technicians have found that this is occassionally true.

After plugging the device back in, there may be a need to wait for some time (like two or three minutes), so don't be shocked if it takes some time for things to start working. If things are still not working, then make a note on what lights are lit, and contact the Internet provider. If there is alternate working Internet access, then the Internet provider might have a website to document known outages and estimated resolution times, as well as having an online chat representative. (Still, don't fall for overly-broad outage descriptions. If the statement says that “all of the western portion of Washington State” has an outage, that may be a tell-tale sign that people in Seattle will be having troubles. If the statement just says that affected areas include Washington State, that might mean that only parts of Washington State are affected, so gaining additional clarity may be worthwhile.

When communication to the ISP works, but a remote Internet site is not working

Check if other Internet connectivity is working. If so, see if the remote site can be visited from a remote location.

If the problem seems to be limited to just one site, the problem is very often caused by that site. If the unresponsive Internet site is a web server, and the goal is just to get non-interactive information from the site (with no need to log into the site), then check public web mirrors such as the Wayback Machine @ Archive.org, Google Cache, the smaller WebCite at webcitation.org, or other smaller archive sites.

If other machines can reach the web server, the issue might be with the web client. Make sure that name resolution is working as expected (so there are no interfering entries in a HOSTS file, or software that provides alternat DNS roots). Web proxy settings in a web browser could affect things. If those settings are correctly set (most often being cleared/blanked), try using a different web browser.

(This didn't get stuffed into the Tutorials section, because this is probably quite useful for troubleshooting. At the time of this writing, most of the Tutorials section is focused more on guiding people to do previously-unfamiliar things. However, admittedly this does certainly seem like a tutorial.)

See also: Troubleshooting: section related to networking.