Wait before turning modem/computer back on?

[Heika Werner]

I was talking with a tech support person about a problem I was having with my modem. I was instructed to turn off the modem and computer and wait three minutes before turning them back on.

This is not the first time I've been told to wait before turning the equipment back on, but no one explains why I have to wait.

Why?

[Mr. Pickles]

I think you just need to turn the modem off (I unplug it) and leave it off for 3-5 minutes. The lack of power I guess flushes the internal smarts, and resets it, so it works again.

[cedric_r]

It's a generic request. In reality it depends on your setup. The point of switching the modem off is to reload the configuration and put it back to a stable state, possibly also re-establish a messed up connection with the modem at the exchange. 3-5 minutes aren't necessary in theory, but they ensure that the memory has been cleared.
Switching off the computer can be useful if it holds your IP and you want to renew it for some reason (e.g. in case of routing problems). In some cases the modem (when also router) that holds the IP, but in some cases it's the computer. So to be sure you're usually asked to switch them both off.

[Paul Shields]

It could also help to reset the DHCP if you're on cable modem. Some DHCP servers will notice if a connection is down for a short while and give you a new lease.

[cside]

Most of the time, turning the power off is sufficient to clear all memory and setups. No more than 10 seconds are required to do this, however the reason you wait for a longer period is actually to prevent damage to the PC as cycling power to the components can damage it. So its more to protect the pc than to reset it..

[brian.austin]

You're all wrong. Sorry but I do this for a living...

1. Initial power off clears the configuration and memory of your cable modem. Call it 10 seconds or until you hear the fan stop if you have a fan (that says all residual power is drained in most firmware-based devices).

But...that's not long enough sometimes.

2. The next hop between you and the "Internet" is typical a router that accepts cable connections, such as some Cisco or Juniper routers, or has some some of media transceiver between you and it to convert coax to Ethernet. This devices learns of everything downstream of it by using a technique called Address Resolution Protocol (ARP) and layer 2 tables. Read up on ARP here if you're interested in more: http://en.wikipedia.org/wiki/Address...ution_Protocol

Once your MAC address is learned via ARP, it's stored in a table that matches IP addresses to MAC addresses on the router. Another table, called the Layer 2 table, matches MAC addresses with physical ports (ie this MAC goes out this port). Cisco called them CAM tables when I used those, otherwise everyone else seems to call them Layer 2 tables (which makes more sense). The timeout on this table and the ARP table can often be longer on environments that aren't as dynamic. If the timeout for the L2 table is 60 seconds and the timeout for the ARP table is 60 seconds, that's a possible 2 minutes before your system can start "talking" again, depending on how they are set up.

3. DHCP is not a server-based controlled system. DHCP relies on requests FIRST. The DHCP won't "notice" if a client is down because DHCP doesn't monitor client connection status. Instead, what happens is the client requests an IP address again, the DHCP server looks up the MAC address and says "Hey, you had this one before. You can have it again." and gives it back. Some DHCP servers can be set up to give new addresses on every request (a mistake in my opinion). Halfway through the lease time (the "allowed" time the server gives out the IP address), there is another conversation where the client basically gets an extension on its lease since it's still active.

Some routers are tied to DHCP and can learn IP addresses by forwarding DHCP requests, accepting the responses and "cheating" by filling in their ARP and L2 tables as they forward the response packet to the client. This is actually good practice since it resets the ARP and L2 tables for that entry.

Typical defaults are 30 seconds for both ARP and L2 table refreshes but they are easily configurable. Some ISPs adjust the timeouts to reduce CPU and traffic.

Unless your PC is hooked directly up to the cable system (with an internal modem), there is actually no reason to shut down the PC. Power off the modem, wait 60 seconds (or if you're like me, just wait 10 seconds knowing that it might not work but probably will), power it back up, wait another 10-20 seconds for the modem to boot up and get its IP address, then jump on the Internet. If your computer can't get on due to lack of an IP address (if you're directly connected to the modem) or your firewall can't get out, unplug the Ethernet connection feeding it from the cable modem, wait 10 seconds and plug it back in. The upstream device (computer/firewall) will send out a DHCP request automatically.

[Paul Shields]

Well we may all be wrong, but having worked in an Internet environment for many years and having been involved in the implementation and roll out of DHCP devices for the largest ISP in the UK I can safely say that a client reset can result in the DHCP server giving out a new lease. It may very well be the same IP address, and of course it is the client initiating the request, but the act of powering off the cable modem and waiting a short period can trigger the DHCP server to offer a new lease and for the client to accept it.

The point is (and the point I think you are also making) - it is the act of resetting the client that allows a new negotiation to begin. There are many reasons for clients getting its knickers in a twist (as an example, we still have many 'old' cable modems on our network that make dozens of DHCP requests per second due to bad firmware). A reset on the client side is often the cure for such misbehaviour.

[brian.austin]

Originally Posted by PaulS

Well we may all be wrong, but having worked in an Internet environment for many years and having been involved in the implementation and roll out of DHCP devices for the largest ISP in the UK I can safely say that a client reset can result in the DHCP server giving out a new lease. It may very well be the same IP address, and of course it is the client initiating the request, but the act of powering off the cable modem and waiting a short period can trigger the DHCP server to offer a new lease and for the client to accept it.

The point is (and the point I think you are also making) - it is the act of resetting the client that allows a new negotiation to begin. There are many reasons for clients getting its knickers in a twist (as an example, we still have many 'old' cable modems on our network that make dozens of DHCP requests per second due to bad firmware). A reset on the client side is often the cure for such misbehaviour.

Sorry. Didn't mean to come across mightier than thou. Your previous statement implied that the DHCP server was monitoring the connection when it's obviously not (which you pointed out in this post).

You can get the same renew function from unplugging the cable connection...but it's easier to powercycle than unscrewing those @#$( CATV connections.

[Paul Shields]

No worries, I think we were all singing from the same hymn sheet in the end . I understand and agree with your points around DHCP as a protocol, but implementations can interpret this quite widely (e.g. I've seen some servers that have ridiculously short lease times), or there may be examples of CMs that may issue a dhcprelease request on power-off (thus removing the lease). And that's not including the various devices in between (uBR's, routers etc). It's a minefield as I'm sure you know. More often than not though, a cable modem reset can often fix a 'broken' client.

[brian.austin]

I have ridiculously short lease times on my corporate DHCP servers, unfortunately. It's because of the goofy setup between DHCP, DNS and Active Directory in Microsoft networks. Short lease times refresh DNS more often, avoiding "host not found" errors with my client management systems. Don't even get me started on bad apps that use reverse lookups for host "authentication" and end up pointing at wireless connections that someone shuts down a few minutes after they log in. Ugh.

I used to work on some of the fiber optic trunks connecting NYC and points in GB for Globalcrossing, as well as some of the newer (at the time) POPs around Europe. Is GBLX still around over there?