In a campus configuration, WINS servers may be deployed at the distribution layer in order to provide redundancy. The challenge for most designers is to limit the number of servers—and like most other things, simpler is better. Two or three WINS servers should not prove to be a significant problem regarding replication overhead and administration. However, some early deployments opted for a WINS server per domain or per department. Such a design quickly falls into the “bad thing” category.

DNS and Dynamic DNS

The Domain Name Service (DNS) was originally developed to provide name resolution for Unix hosts and their IP addresses. It was fundamentally easier to telnet to Cygnus, a server, than it was to telnet to 192.168.67.219. In BIND, or the DNS daemon process in Unix, administrators manually and statically entered name and IP address information. The static nature of DNS is also its most significant negative, as the administrator must manually establish and maintain each entry. This precludes the use of DNS in DHCP environments, where the address is assigned dynamically.

A fairly new enhancement to DNS has emerged within the past year— Dynamic DNS (DDNS). The DDNS specification is compatible with traditional DNS, but information regarding addresses and host names is learned dynamically. This makes DNS compatible with DHCP, which is a significant enhancement in the address assignment arena.

In Windows NT, it is also possible to configure the interchange of WINS information into the DNS structure. This permits non-Windows-based systems—Unix hosts, primarily—to use name references. Most large network designs create a sub-domain for names learned via this method. Thus, an existing Unix DNS structure is maintained for company.com, for example, while a sub-domain of wins.company.com is referenced for the dynamic entries. In addition, Windows clients may use DNS information for name resolution.

	A number of third-party programs are available to integrate WINS, DHCP, and DNS/DDNS functions. Yet as the enterprise grows, many administrators find that the integrated applications are not powerful enough. Some applications worth considering include NetID and Meta IP from Nortel and Checkpoint, respectively.

DHCP

The Dynamic Host Configuration Protocol (DHCP) is actually an open standard that is used by Unix and Macintosh clients as well as Windows-based systems. However, the protocol attained mainstream, corporate recognition when the server module was incorporated into Windows NT.

DHCP allows a host to learn its IP address dynamically. This process is termed a lease, as the address assigned belongs to the host for an administratively defined time. By default, on Windows implementations this assignment is for 72 hours.

	DHCP leases are discussed in the following section.

From a router perspective, DHCP requires one of two components—a DHCP server on the local subnet or a method for forwarding the broadcast across the router. DHCP requests are broadcasts, so the designer needs a DHCP server presence on each segment in the network. This clearly would not scale well and is impractical in most network designs; however, this would provide addressing information to the clients.

The alternative is to provide a little help to DHCP. This is accomplished with the IP helper address, a statically defined address on each router inter-face that is connected to the local segment requiring the help, which in turn points to the DHCP server. Broadcast requests for addresses are sent to the helper address as unicasts or directed broadcasts, significantly reducing overall broadcast traffic. Most DHCP implementations, including Microsoft’s, can provide a great deal of information to the client as well, including time servers, default gateways, and other address-based services.

When designing for DHCP, most architects and administrators consider the following:

•  DHCP lease length

•  DHCP server redundancy

•  Address assignments

	Cisco routers can provide limited DHCP services; however, most installations make use of a dedicated server.

DHCP Lease Length

The length of the DHCP lease governs the amount of time a host “owns” the address. In order for the host to continue using the address, it must renew with the server before the lease expires. Designers must consider the over-head of this renewal traffic and the impact of failed or unavailable DHCP servers. In general, fixed configurations are appropriate venues for long leases, and short leases are applicable in more dynamic installations.

Consider a fully functioning network with a hundred workstations and a lease length of five minutes. This is an extreme example (DHCP typically sends a renewal request at an interval equal to one-half of the lease timer), but the overhead incurred would be 6000 requests per hour for just IP addresses. This is a high amount of overhead for information that should not change under normal circumstances. In addition, when a lease expires, the host must release its IP address. Without a DHCP server, it would be unable to communicate on the network for want of an address.

The alternative to a short lease is to make the lease very long. Consider the impact of a lease equal to 60 days. Should the hosts remain on a local subnet with very few changes, this would substantially reduce the volume of traffic. However, this would not be appropriate for a hotelling installation. Hotelling is a concept introduced years ago where notebook users would check into a cubicle for a day or even a week. DHCP is a great solution for such an installation as the MAC addresses are constantly changing, but a long lease time would be inappropriate here. Consider a scenario where each visitor connects once per quarter, or every 90 days. And, for this example, presume that there are 800 users of the service, and the pool is a standard Class C network of 254 host addresses. If the lease were long—90 days for this example— only the first 250 users would be able to obtain an address. Clearly, this is not appropriate to the type of installation—an important consideration for the designer.

As mentioned earlier, the default DHCP lease renewal interval is 72 hours. This results in renewal requests every 36 hours (typically, this process begins at 50 percent of the lease period). For reference, the mechanism by which DHCP obtains an address is illustrated in Figure 7.3. Note that DHCP uses a system of discovery to locate the DHCP server—a phase that makes use of the helper function. Once the DHCP server is found, the offer is returned to the workstation, and the request is acknowledged or declined.

FIGURE 7.3  The DHCP process