Year end review: DHCP vs. Static IPs

[Doug Sherman [MVP]]

I was reading through some old posts (because I have no life) and I see that
over the course of the past year there have been a great many posts
regarding the failure of DHCP on small networks. Frequently the failure of a
machine to automatically obtain an address was a symptom of some larger and
more serious problem. However, in a large number of cases the problem was
confined to DHCP and the machine functioned fine when statically configured.
As a general rule I recommend that small networks where DHCP services are
provided by low end routers or ICS, use static addresses for the following
reasons:

1. The rudimentary DHCP services provided by ICS and bottom end Internet
routers are primarily useful only if one or both of the following are true:

a. You have a large number of machines on the network such that manual
configuration is truly burdensome.

b. You have laptops or other machines which will frequently be moved to
another network where they need different settings. Note that with XP you
can have an alternate static configuration for use when DHCP is not
available. Also, there is nothing to prevent you from providing DHCP on a
small network, but then configuring most of the machines with static
addresses.

2. Many people have spent a great deal of time troubleshooting DHCP issues
on small networks where relying on DHCP provides little benefit and
unnecessarily creates a single point of failure which could easily be
avoided with static addressing.

3. With static addresses you can reliably connect to another machine by
using \\<IPaddress>. You don't have to memorize the addresses. You can
create lmhosts files which will map the computer names to their static
addresses; and these mappings can be loaded into memory upon machine
startup. You can also create desktop shortcuts to them. If you were to do
this, then you could still connect to shared resources even if DHCP, bowser
service, and broadcasts all failed. Note that DHCP, bowser service, and
broadcasts are all broadcast based or initiated such that they are prone to
occasional failure even on perfectly healthy networks.

4. For the reasons stated in #3, even on large networks with sophisticated
DHCP servers, machines providing shared files or printers are typically
configured with static addresses.

Disclaimer: I do not think that it is a waste of time to troubleshoot small
network DHCP issues; but there have been too many cases where DHCP failure
has crippled such networks unnecessarily. In any event, I invite comments,
thoughts, criticisms, etc.

Doug Sherman, MCSE, MCSA, MCP+I, MVP

HAPPY NEW YEAR

 

[Guest]

Good points made there, and if people tried to avoid the failure-points like
DHCP in network design then there might be less trouble in general.

The only proviso about DHCP is that laptop-users find a fixed IP to be
problematic if they roam between sites, or use hotel services. A workaround
for XP-users is to allow DHCP when present, but change the default
'automatic' IP Windows uses to one whin the main site's range. That way, if
DHCP fails to work, the machine is still usable on the main site at least.

On the subject of IP ranges, I favour the use of a 10-series, 255.255.0.0
network over the more-usual 192.168.1.x/24 arrangement even when I'm setting
up a very small site. The reasons are twofold: The two-user office you're
networking might become a corporation one day, and if they do they'll thank
you for being foresighted enough to allow for a larger network. That, and it
gives you enough leeway to allocate a range to each function or department.
This is particularly useful if other installers also work on the site; for
example I can give the printer-guys their own range to play with, and if they
create an IP-conflict within that range, then that's their problem, not mine.

The other point, that name-resolution problems make-up a huge proportion of
the posts in the networking section is very true. It would seem that people
find name-resolution in both peer-groups and DNS in domains very problematic.
I can vouch for that too, there have been many times when computers simply
would not resolve local names, despite meticulous care in their setup. The
workaround is to avoid peer-sharing altogether; if the computers only need to
resolve one or two servers with fixed IPs, and printers are accessed via LPR,
again with fixed IPs, then the problem largely goes away, and network
reliability/availability is greatly improved. Yet another reason (among many)
to discourage peer-to-peer working.

 

[Hans-Georg Michna]

The only proviso about DHCP is that laptop-users find a fixed IP to be
problematic if they roam between sites, or use hotel services. A workaround
for XP-users is to allow DHCP when present, but change the default
'automatic' IP Windows uses to one whin the main site's range. That way, if
DHCP fails to work, the machine is still usable on the main site at least.

Ian,

there is a compromise solution that should be tried. Keep DHCP
enabled for those mobile computers, but give stationary
computers a fixed IP address anyway. Of course you have to set
up the DHCP server for an address range outside your fixed
address range.

As long as that works, it is a good solution. It also has the
advantage that guest computers are easily accommodated through
DHCP.

Hans-Georg