Chapter 16 Administration of DHCP
This chapter describes how to administer DHCP, including setting up a network running DHCP, determining a lease time policy, and adding BOOTP relay agents. It also talks about the types of databases DHCP uses and how to create macros within certain databases. It discusses the various options that are implemented in or can be added to DHCP.
Collecting Information Before Setting Up a DHCP Service
To set up a network running DHCP, you must first collect information about your existing network. This includes information about its topology, such as routers, switches, other networks, and services such as name services, file and print services, and so on.
If you plan to support clients on remote networks (clients on a different network from the networks on which you plan to deploy your DHCP services), you must also collect the remote networks' subnet masks, providing the remote network is subnetted. Be sure your netmasks (see netmasks(4)) table, which will be used by your DHCP service, has been updated with this information. You must also collect the IP addresses of the routers on the remote network, or configure clients on the remote network to use router discovery.
After you get all the necessary information, you must decide whether to store data that will be moved across the network in NIS+ or in files. NIS+ is the preferred storage for a multiple service environment, or for an enterprise environment. Files is the preferred storage for a single server, or small environments. After you have collected this information, run dhcpconfig(1M) and configure your remote network.
Choosing a Data Store for DHCP Data
Configuring DHCP name services involves determining which data store resource the DHCP server will use to store its tables and to access host information. The dhcpconfig script sets the DHCP service in the /etc/default/dhcp file. The runtime daemon and administrative utilities will use this file to determine which name service to contact during processing.
How the Datastore Service is Selected
The dhcpconfig command first determines whether NIS+ or files is currently being used by the server system. If NIS+ is currently being used by the system, then nisplus is the default value in the Enter data store prompt. Otherwise, files is the default.
If you choose NIS+ and the server is not running NIS+, a warning message is displayed and you are told how to set up NIS+. The dhcpconfig script continues (although it is likely that errors will occur in the next section when creating DHCP tables).
NIS+ should be used if you have an environment with multiple servers, or an enterprise environment. With NIS+, data can be shared among servers. Files can be used if you have only a single server unless you arrange to share data using NFS.
Create Initial DHCP Tables
The dhcpconfig script creates the following empty DHCP tables in the datastore you selected as shown in Table 16-1.
Table 16-1 Tables Created by the dhcpconfig Script|
DHCP configuration information table |
|
|
DHCP client mapping tables, one per network served by the DHCP server |
DHCP Tables
DHCP uses two types of databases: network tables and a dhcptab configuration macros table. These databases are NIS+ tables if you are using NIS+, or files if you are not using NIS+.
DHCP Network Tables
A DHCP network table contains information related to IP address allocation. Each network has a separate network table. The tables, called dhcp_network tables in DHCP, derive their names from the IP address of the network they serve. For example, the network table for the network 120.146.5.0 is 120_146_5_0, with underscores replacing periods in the IP address notation.
Each subnet in a DHCP network has a dhcp_network table containing entries for the clients in the subnet. When a client boots and a DHCP server answers its request for parameters, information is recorded as a dhcp_network entry for the client. Among other information, the table includes the client's IP address and a pointer into the dhcptab table.
A network table contains the following specific information:
-
IP addresses, both assigned and unassigned
-
Client identifier (for assigned records only)
-
Lease expiration time
-
Flag that indicates the type of lease: dynamic, permanent, manual, unusable or BOOTP only
-
Name of the dhcptab configuration macro for each IP address
-
IP address of the server that owns the original client IP address
The network table functions as a list of the IP addresses that DHCP servers can assign on a particular network. Each network has its own network table. The key element in the network table is the list of IP addresses. All other elements in the table are significant in relation to the IP address. For example, the client ID identifies the client to which a particular IP address is currently assigned. If the IP address is not currently assigned, then the client ID for that IP address is zero. The expiration time is also zero. When the IP address is assigned, then the client ID and lease expiration time are filled in.
In certain implementations, the client ID becomes the hardware address of the client machine, with a prefix that indicates the network type. For example, a client with an Ethernet address would have 0102608BA614C1 as its client ID, where 01 indicates that the client is an Ethernet network. Other implementations of DHCP may use other identifiers, such as DNS names or property numbers. The important thing is that the client IDs must be unique within the network.
When an IP address is assigned, the lease expiration time for that IP address is set to a specific date and time, or it is marked "No Expiration."
The lease flag and the dhcptab configuration macro name are the same, regardless of whether the IP address is currently assigned to a client. When a client gets a particular IP address, it also gets the type of lease specified by the lease flag and the configuration specified by the property name. The lease flag indicates the conditions under which the IP address can be assigned. The pntadm command manages the dhcp_network table. Example 16-1 shows an example of pntadm output.
Example 16-1 Sample Output: pntadm -P 129.146.86.0
Client ID Flags Client IP Server IP Lease Macro Comment
Explanation
010800207CBA2C 04 129.146.86.153 129.146.86.181 Zero mrcoffee
0108002022519C 00 129.146.86.205 129.146.86.181 7/3/1996 inet11
01080011043B65 08 129.146.86.29 129.146.86.181 Zero inet11
0100A024A9BCEE 08 129.146.86.198 129.146.86.181 7/22/1996 inet11
0100A024A791DE 00 129.146.86.200 129.146.86.181 8/4/1996 inet11
0100A02463D6EC 00 129.146.86.199 129.146.86.181 8/1/1996 inet11
0100A024636AB7 00 129.146.86.201 129.146.86.181 8/3/1996 inet11
010080C72EE4A3 00 129.146.86.206 129.146.86.181 7/5/1996 inet11
010020AF4A3B31 0 129.146.86.214 129.146.86.181 Zero hobbs
00 00 129.146.86.202 129.146.86.181 Zero inet11
The dhcptab ConfigurationTable
The dhcptab table contains information related to client configuration. The table is organized as a series of macro definitions that contain all of the information necessary to configure a network client. A client gets its configuration when it is assigned an IP address from the network table. The macro name associated with the IP address corresponds to a macro name in the dhcptab table. After a client gets an IP address from the network table, it gets its network configuration from the dhcptab table.
During the initial configuration of the DHCP server, the dhcptab table is created with macros for each configured network. Each of these macros contains information specific to the network, including subnet mask, network broadcast address, IP packet time to live, maximum datagram size, default router, static routes, DNS domain, NIS domain, DNS servers, and NIS servers, if these are available when the server is configured.
You can control how client machines access a network by changing the information contained in the macros. For example, changing the name of the macro that a particular client machine uses changes the network configuration of that machine. In a different example, changing a single option within a macro changes the reactions of all the machines that use that macro set. The ability to manage IP addresses is one of the major features of DHCP. The dhtadm command manages the dhcptab server configuration table. Example 16-2 shows an example of dhtadm output.
Example 16-2 Sample Output: dhtadm -P
Name Type Value
mrcoffee Macro :Subnet=255.255.255.0:Router=129.146.86.1:Broadcst=129.146.86.255: \
:BootSrvA=129.146.86.175:BootFile="/export/root/JavaDesktop/kona": \
:NISservs=129.146.86.33:NISdmain=sunsoft.eng.sun.com: \
:DNSdmain=Eng.Sun.COM: \
:DNSserv=129.146.1.151 129.146.1.152 129.144.1.57 129.144.134.19: \
:Include=Locale: \
:Timeserv=129.144.1.3:LeaseTim=3600:T1Time=1800: \
:T2Time=3060:
Locale Macro :UTCoffst=25200:SN_TZ="PST8PDT":
inet11 Macro :Include=Locale:Timeserv=129.146.86.181:LeaseTim=259200: \
:DNSdmain=Eng.Sun.COM: \
:DNSserv=129.146.1.151 129.146.1.152 129.144.1.57 129.144.134.19:
hobbs Macro :Subnet=255.255.255.0:Router=129.146.86.1:Broadcst=129.146.86.255: \
:BootSrvA=129.146.86.32:BootFile="819256D6.PREP":
129.146.89.0 Macro :Subnet=255.255.255.0:Router=129.146.89.1:Broadcst=129.146.89.255: \
:NISdmain=sunsoft.eng.sun.com:NISservs=129.146.89.33: \
:NetBNms=129.146.171.31:NetBNdT=8:
129.146.88.0 Macro :Subnet=255.255.255.0:Router=129.146.88.1:Broadcst=129.146.88.255: \
:NISdmain=sunsoft.eng.sun.com:NISservs=129.146.88.33: \
:NetBNms=129.146.171.31:NetBNdT=8:
129.146.87.0 Macro :Subnet=255.255.255.0:Router=129.146.87.1:Broadcst=129.146.87.255: \
:NISdmain=sunsoft.eng.sun.com:NISservs=129.146.87.33:
:NetBNms=129.146.171.31:NetBNdT=8:
129.146.86.0 Macro :Broadcst=129.146.86.255:Subnet=255.255.255.0:MTU=1500: \
:Router=129.146.86.1:NISdmain=sunsoft.eng.sun.com: \
:NISservs=129.146.86.33:NetBNms=129.146.171.31:NetBNdT=8: \
:BootSrvA=129.146.86.32:
129.146.85.0 Macro :Subnet=255.255.255.0:Router=129.146.85.1:Broadcst=129.146.85.255: \
:NISdmain=sunsoft.eng.sun.com:NISservs=129.146.85.33: \
:NetBNms=129.146.171.31:NetBNdT=8:
129.146.84.0 Macro :Subnet=255.255.255.0:Router=129.146.84.1:Broadcst=129.146.84.255: \
:NISdmain=sunsoft.eng.sun.com:NISservs=129.146.84.33: \
:NetBNms=129.146.171.31:NetBNdT=8:
129.146.83.0 Macro :Subnet=255.255.255.0:Router=129.146.83.1:Broadcst=129.146.83.255: \
:NISdmain=sunsoft.eng.sun.com: \
:NISservs=129.146.83.33:NetBNms=129.146.171.31:NetBNdT=8:
129.146.82.0 Macro :Subnet=255.255.255.0:Router=129.146.82.1:Broadcst=129.146.82.255: \
:NISdmain=sunsoft.eng.sun.com:NISservs=129.146.82.33: \
:NetBNms=129.146.171.31:NetBNdT=8:
129.146.81.0 Macro :Subnet=255.255.255.0:Router=129.146.81.1:Broadcst=129.146.81.255: \
:NISdmain=sunsoft.eng.sun.com:NISservs=129.146.81.33: \
:NetBNms=129.146.171.31:NetBNdT=8:
SN_TZ Symbol Vendor=SUNW,13,ASCII,1,0
Configure Each Subnet for DHCP
This section discusses using dhcpconfig to configure subnets, based on your responses to three questions for each subnet:
-
What range of IP addresses do you want to be searched for unused IP addresses to allocate?
-
Do you want the DHCP daemon to respond to requests for a specific subnet?
-
For each monitored subnet, how many clients do you want to be assigned dynamically-allocated IP addresses?
How Each Subnet for DHCP is Configured
The dhcpconfig script creates a table--called the dhcp_network table--for each subnet being configured on the server system. The table name is the same as the IP address, but with decimal points replaced by underscores. For example, the subnet 129.148.5.0 has a dhcp_network table 129_148_5_0 in the name service being used by DHCP. For NIS+, this is a table in the org_dir object. For files, this is a file in the /var/dhcp directory.
Each client system being managed by DHCP has an entry in the dhcp_network table (the table corresponding to the subnet on which the client machine is attached). Entries may be permanent, with the IP address permanently assigned to the machine. Or, entries may be dynamic, where the DHCP server assigns an IP address when the client is first configured and provides a lease, a specified amount of time for which the IP address can be used. It is these dynamic clients that this step attempts to set up. Permanent clients can be set up with pntadm after the DHCP environment is fully configured.
Start the DHCP Service Daemon
This section describes three functions performed by the dhcpconfig script:
-
Installs the start/stop script for the DHCP daemon processes into the /etc/init.d directory
-
Sets up links to this script in the /etc/rc{0,3}.d directories
-
Starts the daemon processes
The start/stop script is named dhcp and the links are S34dhcp (to start the daemons) and K34dhcp (to stop the daemons). This follows standard SVR4 procedure for daemon process execution at boot time.
One daemon process, in.dhcpd, is started. The in.dhcpd daemon is the DHCP server process, which responds to the client DHCP requests and forwards the network configurations, which have been established in the dhcptab table.
Lease Time Policy
DHCP provides a mechanism for dynamically allocating IP addresses. These IP addresses carry a lease period, which you can set to permanent or temporary. Your site policy must include decisions about the number of temporary and permanent IP addresses, and the lease period of temporary IP addresses.
To reap the most benefit from your DHCP service, it's best to allow DHCP to dynamically manage your IP address assignment for you. With DHCP, the client and the server negotiate a loan of an IP address configuration for a certain time period, known as a lease time. You can set a lease time policy based on server, network, client vendor class, or individual client IP address through the use of the LeaseTim and LeaseNeg symbols in certain macro definitions in your dhcptab.
The LeaseNeg and LeaseTim symbols allow you to set policy for your site. LeaseTim is a relative time, such as 24 hours, or 2 hours, or 10 hours. When a client is assigned an IP address (or renegotiates a lease on an IP address it is already assigned), the LeaseTim value is added to the absolute time the client received its DHCP reply. Absolute time is the time now, such as September 27, 1996. The LeaseTim value plus the absolute current time is stored in the client's dhcp_network record as an absolute future time when the client's lease on its IP address expires.
The LeaseTim symbol setting defines the maximum lease time interval you allow to clients. Typically, this value should remain relatively small, so that: clients and servers stay in synch; IP addresses that are not being used are reclaimed in the most timely fashion; and the renumbering of networks happens more smoothly.
However, the value must be large enough so that if your DHCP server becomes unavailable, your clients continue to function until the machine(s) running the DHCP service can be repaired. One to 3 days is an optimal LeaseTim policy. Select values that work well in your environment.
The LeaseNeg symbol determines whether or not a client can renegotiate its lease with the server before the lease expires. If this symbol is present, then the client can renegotiate its lease. LeaseNeg allows clients to operate on the network without lease-related interrupts of existing connections.
Omitting LeaseNeg is useful for environments where you have more machines than you have IP addresses, and thus want to enforce a time limit on the use of any IP address. Enforcing a time limit on machines in a Computer Science class lab is an example of this. Like LeaseTim, LeaseNeg can be used in a variety of different macros in your dhcptab. See dhcptab(4) and dhcp_network(4) for more information.
Machines that export services such as mail or web pages must retain their IP address. However, you'd still like to be able to detect when the IP address used by this node is no longer being used (perhaps when the machine is retired). You can achieve this by marking this node's dhcp_network record as being manually assigned (by you) and by setting the node's flag field to MANUAL. For example, if the hostname is gandalf and the network is 10.50.0.0, type pntadm - gandalf -f MANUAL 10.50.0.0.
You can allocate IP addresses with permanent leases. However, you will not be able to use the DHCP service to automatically reclaim these IP addresses for you. Therefore, keep the number of permanent IP addresses to a minimum, manageable number.
The DHCP service uses this field to determine when dhcp_network record entries have expired and can be reclaimed. You can alter this value through the e option of the pntadm command. Through this command, you can set a client's lease expiration time to the past, although we recommend that you only set it into the future to avoid adversely affecting the client and the client's user(s).
Each time the DHCP service allocates a dynamic IP address or renegotiates a lease on an existing binding, this field in the dhcp_network table is updated.
The lease flag indicates the conditions under which the IP address can be assigned. The flag setting can be a combination of the following:
- 0 (Dynamic)
-
The IP address lease has an expiration time. When the lease expires it can be renewed, if that is indicated by the site policy. If the current client does not renew the lease, then the IP address can be assigned to another client. When the flag is set to 0, the client can request that the lease time be changed.
- 1 (Permanent)
-
The IP address lease is assigned permanently, and the client cannot change the lease time. However, the client using the IP address can release it. When it is released, it can be assigned to another client.
- 2 (Manual)
-
The IP address is assigned to a specific client machine. It cannot be released by the client. As long as the flag is set to 2, the IP address can be reassigned only if an administrator changes it manually.
- 4 (Unusable)
-
The IP address is unusable. You can set the flag to 4 to prevent an IP address from being assigned. The DHCP server marks an IP address as unusable if it attempts to locate the IP address and finds that it is already in use. Before it assigns an IP address, the DHCP server normally pings it to see if it is already in use for some reason. This setting is configurable in dhcpconfig.
The flag can also have a combination of settings. For example, if the flag is set to 3, it is a combination of 1 and 2; that is, it is both permanent and manual. The IP address has a permanent lease, and was assigned by the administrator.
Setting Up a BOOTP Relay Agent
First, determine if your router or routers has a built-in relay agent. If the router does, read the documentation to understand how to use the relay agent. If your router does not have a built-in relay agent, choose a Solaris 2.6 machine on the client's network to act as the relay agent. Install SUNWdhcsr and SUNWdhcsu on the machine. Then run dhcpconfig and select Configure BOOTP relay agent.
Enter the IP addresses or hostnames of the BOOTP/DHCP servers to which you want to send BOOTP/DHCP requests.
Standard DHCP Options
The Solaris 2 DHCP server implements all of the standard DHCP options. These options contain network information such as:
-
Server names
-
Router address
-
DNS Domain Name
-
TCP Time to Live
-
Connection options
-
Server options
-
IP layer options
-
Time options
Vendor Options
Vendor options are DHCP options that are defined by the DHCP client software vendor. When a client broadcasts a request for a configuration, the client includes its vendor client class. If this client class matches any client classes in the dhcptab database, then the options specified for that class are sent to the client, along with other configuration options. The Solaris 2 DHCP server can be configured to support any DHCP client vendor's options.
Adding Vendor and Site Options
To create additional vendor or site options, you must define:
-
Vendor class, which is the name used to distinguish clients by vendor. The class name is an ASCII character string. It is not specified when you are defining a site option.
-
Value type, which specifies the type of data contained in this option. The supported data types are:
-
ASCII text
-
Octet, an ASCII representation of binary data
-
IP, the dotted decimal form of an Internet address
-
Number, an 8-bit, 16-bit, 32-bit, or 64-bit number
-
-
Option Code, which is the DHCP option number you want to assign to the new options. Vendor codes can be between 1 and 254; site codes can be between 128 and 254.
-
Granularity, which specifies how many objects of this value type make up a single instance of this option. For example, the static route symbol is a list of routes. Each route consists of two IP addresses, so the value type is defined as IP and the granularity is defined as 2.
-
Length, which specifies the minimal granularity permissible in this option. For example, a subnet mask can be only one IP address, so the length for the subnet mask option is 1. A value of zero means that a variable number of items, up to 16, is permitted.
Because site options are specific to your site, you can create any meaningful option. In the case of vendor options, however, you can add only options that are meaningful to a specific client vendor. Some options are predefined, but others must be created. In that case, you may need to create a list of vendor options on the server that are appropriate to the specific vendor. The list typicall is provided by the client vendor.
Creating Macro Definitions
When you create a macro for the dhcptab table, you must specify all of the relevant standard, vendor, and site options. You do not have to specify all the options available. How many you specify depends on how your network is configured.
IP Address Leases
IP address leases are assigned as temporary by default. Temporary leases are useful if users and their machines change subnets frequently, or if systems come in and out of use fairly often.
Each site can specify whether the temporary leases on the site are renewable. You can set this site policy in the properties table with the LeaseNeg symbol. If you omit this symbol, the client cannot renegotiate its lease when it expires. If a client does not renew its IP address when it expires, it can be reused.
Customization Examples
To change an NIS server value for the network 126.147.100.0:
-
Edit the macro 129.147.100.0 with:
dhtadm -M -m 129.147.100.0 -e `NISserv = 129.147.100.1 129.147.100.2'
-
Type:
/etc/init.d/dhcp stop
-
Type:
/etc/init.d/dhcp start
Or, instead of steps 2 and 3, use the -t option to in.dhcpd.
To add addresses from 10-15 to 129.147.100.0
for addr in 10 11 12 13 14 15 do pntadm -A 129.147.100.$addr -m server -h hundred-$addr 129.147.100.0 done
To add a symbol definition for a timezone; SN_TZ
-
Type:
dhtadm -A -s SN_TZ -d 'Vendor="SUNW.PCW.LAN SUNW.Solaris", 13, ASCII, 1, 0'
-
Type:
dhtadm -M -m Locale -e `:SN_TZ = "EST5EDT4":'
-
Type:
/etc/init.d/dhcp stop
-
Type:
or -t option
/etc/init.d/dhcp start
To delete the Timeserv value from the jurassic macro:
-
Type:
dhtadm -D -m jurassic -e `Timeserv=`
-
Type:
/etc/init.d/dhcp stop
-
Type:
or -t option
/etc/init.d/dhcp start
Always return hostnames to the client of the server jurassic.
-
Type:
dhtadm -M -m jurassic -e `Hostname= _NULL_VALUE_'
-
Type:
/etc/initd/dhcp stop
-
Type:
or -t option
/etc/init.d/dhcp start
If it is important to maintain the hostname-to-IP address association for a host named canoepoint to an IP address association, mark the canoepoint entry on the peds network as MANUAL.
In order to mark 129.147.100.87 as BOOTP and permanent:
-
Type:
pntadm -M 129.147.100.87 -f `BOOTP + PERMANENT' 129.147.100.0
or
-
Type:
pntadm -M 129.147.100.87 -f 09 129.147.100.0
Maintenance
This shell script first checks any IP addresses marked as unusable to verify that they are not in use. If they are not, the script then reclaims the IP addresses.
#!/bin/ksh
# This shell script reclaims addresses which were marked as unusable, after
# first verifying that they're no longer in use.
if [ ${#} -eq 0 ]
then
echo "reclaim <network> ..." >&2
exit 1
fi
while [ ${#} -ne 0 ]
do
pntadm -P ${1} | awk ' $2 == 04 { printf("%s %s\n", $1, $3); }' |
while read cid addr
do
if [ ${?} -ne 0 ]
then
pntadm -M ${addr} -i 00 -f DYNAMIC -e 0 ${1}
if [ ${?} -eq 0 ]
then
echo "${addr} has been reclaimed from client ${cid}."
fi
else
echo "${addr} is in use!" >&2
fi
done
shift
done
exit 0
|
Enabling the Solaris DHCP Client
By default, the Solaris DHCP client is disabled. To enable it, you must create a DHCP enable file for each network interface you want to configure with DHCP. The format of the DHCP enable file is: /etc/dhcp.interface_name, where interface_name is the name of the network interface you want configured by DHCP.
For example, if you would like to configure network interface le1 using DHCP, you would create the empty file /etc/dhcp.le1. If you have multiple network interfaces that you would like to configure using DHCP, you must create a DHCP enable file for each interface.
Increasing Boot Process Suspension Time
Using DHCP to configure an interface may increase the boot time. In particular, if no DHCP server is present to answer the client's requests, a delay of approximately 30 seconds occurs for each interface. If you want your Solaris DHCP client to suspend the booting process until the network interface is configured (regardless of how long this takes), edit the network interface's DHCP enable file (/etc/dhcp.interface_name) and add the phrase wait forever.
If you want your client to suspend its booting process for a shorter period of time, you can specify the number of seconds to wait instead of using the keyword forever. For example, if you want to allow DHCP one hour to configure the network interface before the booting process continues, specify wait 3600.
Note -
Even if the suspend time is exhausted, the Solaris DHCP client will continue asynchronously to configure the network interface until it is successful. To avoid this, you can specify the drop option to the ifconfig(1M) command. For example: ifconfig le0 dhcp drop. This will remove the specified interface (in this case, le0) from the control of the DHCP agent, which should cause the asynchronous address allocation attempts to terminate.
Designating a Network Interface as Primary
Many DHCP configuration parameters are not specific to a network interface. Instead, the parameters specify more general information. Examples of this type of general parameter are: NIS server, NIS domain, DNS servers, and DNS domain. If your Solaris machine has only a single network interface, there does not need to be a distinction between the general and interface-specific parameters.
However, if your machine has multiple network interfaces (it is multihomed), and DHCP is to configure more than one interface, then it is possible to receive multiple sets of general configuration parameters that may conflict. For example, which DNS parameters should be used? Those received when using DHCP to configure interface le0 or those received for le1?
The Solaris DHCP client solves this problem by allowing you to specify one network interface as the primary network interface. Interface-specific parameters (such as subnet mask) will be retrieved from the DHCP parameters for that specific interface. General parameters are retrieved only from the DHCP information received on the primary interface.
To designate a network interface as the primary interface, add the keyword primary to the DHCP enable file for that interface. For example, suppose you want to use qe2 as the primary interface. Edit /etc/dhcp.qe2 and add the word primary.
If the keyword primary is not added (no interface has been designated as primary), the Solaris machine receives parameters from the first interface that is configured successfully.
Network Topologies That Limit Effective Use of DHCP/BOOTP
DHCP and BOOTP clients initially have no information about the local IP network, and therefore use the 0.0.0.0 (the default network address) for their IP address. The clients send their DHCP or BOOTP requests to the 255.255.255.255 IP address (broadcast address) which will be received by all IP devices attached to the local IP network.
DHCP and BOOTP servers determine the client's IP network attachment based on following factors:
-
Which network hardware interface the DHCP or BOOTP request was received on?
-
Was the DHCP or BOOTP request received from a BOOTP relay agent?
BOOTP relay agents insert the IP address of their network hardware interface that is attached to the same IP network as the DHCP or BOOTP client. The absence of this IP address signals to the server that the client is on a directly-attached IP network. The presence of this IP address indicates that the client is attached to an IP network remote from the server and that the server is to send responses back to the client using the BOOTP relay agent's IP address.
-
Is the IP network the client is attached to subnetted?
The servers, using the IP address as a key, consults the contents of the netmasks table (which contains subnet mask information) using either:
-
The IP address of the server's network hardware interface if the client is on a directly-attached IP network (indicated by an IP address of 0.0.0.0 in the packet's relay address field)
-
The IP address specified if a BOOTP relay agent specified its IP address in the client's request
-
This procedure for determining the client's IP network attachment is only effective if there is only one IP network present on the network hardware media (for example, Ethernet). DHCP does not work well in IP network environments where, either through the use of multiple network hardware interfaces or multiple logical interfaces, there is more than one IP network sharing the same network hardware media. In this case, a DHCP client's request appears on all network hardware interfaces, making the client "appear" to be attached to all of the IP networks simultaneously. Since DHCP servers dynamically allocate IP addresses to requesting clients, the server is unable to determine which IP address to allocate to the client. DHCP clients, attempting to validate IP addresses they presently hold, will be seen to originate on all the logical IP networks, not just the network the client has been assigned to.
Such network topologies should be avoided, either though the use of Variable Length Subnet Masks (VLSM) to preserve the one-to-one mapping of IP network to network hardware media through more efficient subnetting, or by configuring the DHCP or BOOTP service to serve just one of the logical IP networks. See netmasks(4) for additional information.
- © 2010, Oracle Corporation and/or its affiliates