This section provides information to help you plan your DHCP strategy. When planning your implementation of DHCP, consider the following:
Your existing network topology (how you set up your routers and subnets) provides a basic configuration for the distribution of DHCP resources such as Subnet objects, Subnet Address Range objects, and IP Address objects.
Your existing eDirectory implementation should be incorporated into your planning. Place the Locator object near the top of your eDirectory tree where it can be easily accessed by all servers.
The length of time you set for your leases affects traffic on the network.
For more information, see the following:
Your existing network topology provides a basic configuration for the distribution of DHCP resources. There are two paths, however, depending on whether you are migrating from an existing DHCP solution or you are installing and configuring DHCP for the first time. See the following sections:
You can import your existing Novell DHCP 2.0 database or BOOTP-based configuration files by using the iManager utility or the Management Console. The import function enables you to specify the context into which you import the data.
If you are planning to use DHCP for the first time, you must gather a significant amount of information. You need to make a list of all hosts to be served by the DHCP server. You must include all devices that use network addresses in every segment of your network. You must also compile lists of IP address assignments.
Organize your lists of hosts and IP addresses by geographic location. For example, if your network is spread over a WAN, make a list for each location to help you organize the distribution of DHCP resources.
You must have a list of all permanently assigned network addresses. You might also want to make a list of devices that are to be denied IP addresses and those hosts that are to receive strict limitations on leases.
After you gather the necessary information, you need to create the necessary objects to represent this information. This is done by creating subnet address ranges for contiguous network addresses and other more specific information. You will probably have a separate subnet address range for each LAN segment of your network. You will also create objects of subnets and DHCP servers. Although there is no limitation on the size or number of subnets when you configure DHCP, we recommend that the IP address in each subnet is not more than 2048. A Novell DHCP server can support several large subnets in a DHCP configuration. However, the higher the number of IP addresses, the greater the impact on DHCP run-time performance.
Plan to create an Organizational Unit (OU), Country (C), or Locality (L) container object near the top of your eDirectory tree. Plan to locate the DNS/DHCP Group and Locator objects under the container object.
The DNS/DHCP Locator object must be easily accessible to all DHCP servers on the network. Plan to have multiple routes for DHCP servers to access the DNS/DHCP Group object.
Create Subnet objects to represent each LAN segment. Then create one or more Subnet Address Range objects to represent all of your contiguous strings of IP addresses.
Place the NetWare Core Protocol™ (NCP™) servers that will provide DCHP service near the data to be updated and close to a writable partition. For fast access and availability, a DHCP server should be on the same LAN as or geographically close to the writable partitions the DHCP server uses.
When a DHCP server makes or modifies address assignments, the database is updated. The partition where this database is stored should have at least two writable replicas. Having only one replica might be unsafe because of fault tolerance considerations, but three might be too costly in terms of eDirectory performance.
In deciding how long to set your client leases, consider the following factors:
Your site’s and clients’ usage patterns
Your network’s goals
Availability of servers
Availability of network (IP) addresses
Another important consideration is that clients attempt to renew their leases half way through the lease duration. The longer the lease, the longer it takes for client configuration changes to be registered with the DHCP server. It also takes longer for the server to realize that a previously assigned address is no longer in use.
Another issue to consider concerns outages and access to the DHCP server. If a client loses access to its DHCP server before renewing its lease, it must stop using the network after the lease expires. If a client is turned on and connected to the network at the time of the outage, however, the lease does not expire.
The longest lease provided by a DHCP server determines the length of time you might need to wait before configuration changes can be propagated within a network. This length of time could mean manually restarting every client or waiting the amount of time required for all leases to be renewed before the changes take effect. If your site policy is to turn off workstation power at the end of the day, clients could acquire configuration changes at least once per day.
NOTE:All lease considerations refer to DHCP clients or devices only. For clients or devices that use BOOTP, you must bring down the device and restart it to acquire any new configuration changes.
For more information, see:
When considering the length of leases, ask these questions:
Will the default of three days work well in your environment?
The default of three days provides a good balance between a long-lease and a short-lease duration.
Do you have more clients than IP addresses?
If you have more clients than IP addresses, keep leases short to allow access to more users. A short lease could be two to four hours, or even a matter of days.
If your site’s usage pattern shows that all clients request an address every day and you have half as many addresses as users, lease times in hours or minutes would provide access to more users.
Do you provide support for remote access?
If your site has mobile users or provides remote access to clients, plan to provide service for these clients on a specific subnet. Providing support, including special options the clients might require, makes network administration of the clients easier.
Do you support a minimum lease time?
If your site’s usage pattern indicates that your users typically use an address for only one or two hours, that should be your minimum lease time.
How many clients do you plan to support?
Shorter leases support more clients, but shorter leases also increase the load on the DHCP server and network bandwidth. A lease of two hours is long enough to serve most users, and the network load should be negligible. A lease of one hour or less might increase network load to a point that requires attention.
How fast are your communications connections between your clients and the DHCP server?
By locating a DHCP server in close proximity to its users, the network load should be negligible over LAN connections. If a DHCP server must communicate over WAN links to provide service to clients, slowdowns and time-outs might occur.
How long does your typical server outage last?
If your typical server outage lasts two hours, a lease of four hours would avoid loss of lease to clients that were active at the time of the server outage.
We recommend setting your lease times to twice the length of a typical server outage.
The same recommendation applies to communications line outages. If a communications line is down long enough that leases expire, you might see a significant network load when the service is restored.
How long can your clients operate without access to the DHCP server?
If you have users who require a lease for important job functions, consider lease times for them that are twice the length of a maximum server outage. For example, if your DHCP server went down on Friday evening and required the entire workday Monday to be restored, that would be an outage of three days. In this case, a six-day lease covers that situation.
Do you have users who advertise their IP addresses for services they render?
If you have users setting up Web pages or archiving data for others to access, they want addresses that do not change. You might want to assign permanent addresses for these users instead of assigning long lease times.
The relevant length of time is the maximum amount of time you want to allow a client to keep an address, even if the host computer is turned off. For example, if an employee takes a four-week vacation and you want the employee to keep his or her address, a lease of eight weeks or longer is required.
The following table lists examples of lease times and the reasons these times were chosen.
Table 2-1 Examples of Lease Times and Reasons
There is usually a trade-off when you attempt to control specific client access to leases. Typically, you would manually configure each client and dedicate an IP address permanently to each client. However, the Novell DHCP server provides control based on the client’s hardware address.
This section describes how to identify your IP addresses, how to subnet your addresses, what to do with addresses assigned by other sources, and how to restrict address assignments to clients.
If you have been using a previous version of Novell DHCP, another vendor’s product, or another method of tracking your IP address information, information about your addresses should be close at hand. To prevent communication problems, we recommend verifying the accuracy of your IP address records by performing a site audit.
If you are unsure of the range of your IP addresses, contact your Internet Service Provider (ISP) or check other records you have on file.
One of the more difficult configuration tasks is configuring your routers if you have multiple subnets. Each router might require one or more subnets, depending on your router configuration. Create a Subnet object for each LAN segment that requires dynamic IP address assignment.
Your site might have devices, such as servers and printers, that have addresses assigned by means other than DHCP. Assign addresses to these devices manually.
You must also provide these devices with any specific configuration information they might require. If you want to provide configuration by using DHCP, the device must be capable of acting as a DHCP client. You can assign a static address to a device and still provide configuration information by using DHCP.
To ensure that the assigned addresses are not used by DHCP, use the iManager utility or the Management Console to exclude the addresses from assignment. You can use the utility to exclude single addresses or entire ranges from address assignment.
IP addresses are represented by IP Address objects under Subnet container objects. Novell DNS/DHCP Services stores the address information and attributes of these objects, such as hostnames, hardware addresses, the time when an address lease will expire, and fully qualified domain names (FQDNs), in eDirectory. You can view this information by using the iManager utility or the Management Console.
By using static address assignment, you can ensure that a device capable of acting as a BOOTP or DHCP client receives the same address from the DHCP server each time it is started. You can also explicitly exclude an address assignment to a device based on the device’s hardware address. This is done by setting DHCP Global Preferences. To invoke the DHCP Global Preferences window, click .
Every host on your network that uses the Internet or that can be reached from the Internet should have a name. Each resource record has a hostname field.
The following simple rules are used for hostnames to conform to accepted Internet standards:
Hostnames are called labels and can have alphabetic and numeric characters.
A hyphen is allowed if it separates two character strings.
Labels might not be all numbers, but they can have a leading digit.
Labels must begin and end only with a letter or digit.