Transmission Control Protocol/Internet Protocol (TCP/IP) enables communication between machines with configured addresses. Part of the burden a network administrator must face is address assignment and parameter distribution for all machines on the network. Commonly, this is a process in which the administrator dictates the configuration to each user, allowing the user to configure his own machine. However, misconfigurations and misunderstandings can generate service calls that the administrator must deal with individually. The Dynamic Host Configuration Protocol (DHCP) gives the network administrator a method to remove the end user from this configuration problem and maintain the network configuration in a centralized location.
DHCP is an application-layer protocol that allows a client machine on the network, to get an IP address and other configuration parameters from the server. It gets information by exchanging packets between a daemon on the client and another on the server. Most operating systems now provide a DHCP client in their base package.
To obtain an address, the DHCP client daemon (dhcpcd) broadcasts a DHCP discover message, which is received by the server and processed. (Multiple servers can be configured on the network for redundancy.) If a free address is available for that client, a DHCP offer message is created, This message contains an IP address and other options that are appropriate for that client. The client receives the server DHCP offer and stores it while waiting for other offers. When the client chooses the best offer, it broadcasts a DHCP request that specifies which server offer it wants.
All configured DHCP servers receive the request. Each checks to see if it is the requested server. If not, the server frees the address assigned to that client. The requested server marks the address as assigned and returns a DHCP acknowledgement, at which time, the transaction is complete. The client has an address for the period of time (lease) designated by the server.
When half of the lease time is used, the client sends the server a renew packet to extend the lease time. If the server is willing to renew, it sends a DHCP acknowledgement. If the client does not get a response from the server that owns its current address, it broadcasts a DHCP rebind packet to reach the server if, for example, the server has been moved from one network to another. If the client has not renewed its address after the full lease time, the interface is brought down and the process starts over. This cycle prevents multiple clients on a network from being assigned the same address.
The DHCP server assigns addresses based on keys. Four common keys are network, class, vendor, and client ID. The server uses these keys to get an address and a set of configuration options to return to the client.
These keys can be used by the configuration either singularly or in combinations. If multiple keys are provided by the client and multiple addresses can be assigned, only one is chosen, and the option set is derived from the chosen key first. For more detailed information about the selection of keys and addresses, see Configuring DHCP.
A relay agent is needed so initial broadcasts from the client can leave the local network. This agent is called the BOOTP relay agent. The relay agents act as forwarding agents for DHCP and BOOTP packets.
Beginning with AIX 4.3.1, the DHCP server has been segmented into three main pieces, a database, a protocol engine, and a set of service threads, each with its own configuration information.
The db_file.dhcpo database is used to track clients and addresses and for access control (for example, allowing certain clients on some networks but not others, or disabling BOOTP clients on a particular network). Options are also stored in the database for retrieval and delivery to clients. The database is implemented as a dynamically loadable object, which allows for easy server upgrade and maintenance.
Using the information in the configuration file, the database is primed and verified for consistency. A set of checkpoint files handles updates to the database and reduces the overhead of writes to the main storage file. The database also contains the address and option pools, but these are static and are discussed in Configuring DHCP.
The main storage file and its back up are flat ASCII files that can be edited. The format for the database main storage files are:
DF01 "CLIENT ID" "0.0.0.0" State LeaseTimeStart LeaseTimeDuration LeaseTimeEnd "Server IP Address" "Class ID" "Vendor ID" "Hostname" "Domain Name" "CLIENT ID" "0.0.0.0" State LeaseTimeStart LeaseTimeDuration LeaseTimeEnd "Server IP Address" "Class ID" "Vendor ID" "Host Name" "Domain Name" ...
The first line is a version identifier for the file: DF01c. The lines that follow are client record definition lines. The server reads from the second line to the end of the file. (The parameters in quotes must be enclosed in quotes.)
The syntax for the checkpoint files is not specified. If the server crashes or you have to shut down and cannot do a normal closing of the database, the server can process the checkpoint and backup files to reconstruct a valid database. The client that is being written to the checkpoint file when the server crashes is lost. The default files are:
The DHCP server for AIX 4.3.1 and later is threaded. To maintain high throughput, database operations (including save operations) are thread-efficient. When a save is requested, the existing checkpoint file is rotated to the next checkpoint file, the existing database file is copied to the backup file, and the new save file is created. Each client record is then logged and a bit is toggled to indicate that the client should use the new checkpoint file for logging. When all client records are recorded, the save is closed, and the backup and old checkpoint files are deleted. Clients can still be processed and, depending on whether the client record has been saved, database changes go into a new save file or to a new checkpoint file.
For AIX 4.3.1 and later, the DHCP protocol engine has been updated to RFC 2131, but is still compatible with RFC 1541. (The server can also process options as defined in RFC 2132.) The protocol engine uses the database to determine what information is returned to the client.
The configuration of the address pools have some configuration options that affect the state of each machine. For example, the DHCP server pings addresses before it hands them out. The amount of time the server waits for a response is now configurable for each address pool.
The last piece of the DHCP server is actually a set of operations that are used to keep things running. Since the DHCP server is threaded, these operations are actually set up as threads that occasionally do things to make sure everything is together.
The first thread, the main thread, handles the SRC requests (such as startsrc, stopsrc, lssrc, traceson, and refresh). This thread also coordinates all operations that affect all threads and handles signals. For example,
The next thread, the dadmin thread, interfaces with dadmin client program and the DHCP server. The dadmin tool can be used to get status as well as modify the database to avoid editing the database files manually. Previous versions of the DHCP server prevented any clients from getting addresses if a status request was running. With the addition of the dadmin and src threads, the server can handle service requests and still handle client requests.
The next thread is the garbage thread, which runs timers that periodically clean the database, save the database, purge clients that do not have addresses, and remove reserved addresses that have been in reserve state for too long. All these timers are configurable (see Configuring DHCP). The other threads are packet processors. The number of these is configurable; the default is 10. Each of these can handle a request from a DHCP client. The number of packet processors required is somewhat load- and machine-dependent. If the machine is used for other services than DHCP, it is not wise to start up 500 threads.
To use this protocol, the network administrator needs to set up a DHCP server and configure BOOTP relay agents on links that do not have a DHCP server. Advance planning can reduce DHCP load on the network. For example, one server can be configured to handle all your clients, but all packets must be passed through it. If you have a single router between two large networks, it is wiser to place two servers in your network, one on each link.
Another aspect to consider is that DHCP implies a pattern of traffic. For example, if you set your default lease time to fewer than two days and your machines are powered off for the weekend, Monday morning becomes a period of high DHCP traffic. Although DHCP traffic does not cause huge overhead for the network, it needs to be considered when deciding where to place DHCP servers on a network and how many to use.
After enabling DHCP to get the client on the network, a client has no requirement to enter anything. The DHCP client, dhcpcd, reads the dhcpcd.ini file, which contains information on logging and other parameters needed to start running. After installation, decide which method to use for TCP/IP configuration: minimum configuration or DHCP. If DHCP is selected, choose an interface and specify some optional parameters. To choose the interface, select the keyword any, which tells dhcpcd to find the first interface that works and use it. This method minimizes the amount of input on the client side.
By default, the DHCP server is configured by reading the /etc/dhcpsd.cnf file, which specifies the initial database of options and addresses. The server is started in the /etc/rc.tcpip file. It can also be started from Web-based System Manager, from SMIT, or through SRC commands. The DHCP client can be configured by running Web-based System Manager, the System Management Interface Tool (SMIT), or editing a flat ASCII file.
Configuring the DHCP server is usually the hardest part of using DHCP in your network. First, decide what networks you want to have DHCP clients on. Each subnet in your network represents a pool of addresses that the DHCP server must add to its database. For example:
database db_file
{
subnet 9.3.149.0 255.255.255.0
{ option 3 9.3.149.1 # The default gateway clients on this network should use
option 6 9.3.149.2 # The nameserver clients on this network should use
}
... options or other containers added later
}
The example above shows a subnet, 9.3.149.0, with a subnet mask 255.255.255.0. All addresses in this subnet, 9.3.149.1 through 9.3.149.254, are in the pool. Optionally, a range can be specified on the end of the line or a range or exclude statement can be included in the subnet container. See DHCP Server File Known Options for common configuration methods and definitions.
The database clause with db_file indicates which database method to use for processing this part of the configuration file. Comments begin with a # (pound sign). Text from the initial #, to the end of the line, is ignored by the DHCP server. Each option line is used by the server to tell the client what to do. DHCP Server File Known Options describes the currently supported and known options. See DHCP Server File Syntax for General Server Operation for ways to specify options that the server does not know about.
If the server does not understand how to parse an option, it uses default methods to send the option to the client. This also allows the DHCP server to send site-specific options that are not RFC defined, but may be used be certain clients or client configurations.
The configuration file has an address section and an option definition section. These sections use containers to hold options, modifiers, and, potentially, other containers.
A container (basically, a method to group options) uses an identifier to classify clients into groups. The container types are subnet, class, vendor, and client. Currently, there is not a generic user-definable container. The identifier uniquely defines the client so that the client can be tracked if, for example, it moves between subnets. More than one container type can be used to define client access.
Options are identifiers that are returned to the client, such as default gateway and DNS address.
Modifiers are single statements that modify some aspect of a container, such as lease time default.
When the DHCP server receives a request, the packet is parsed and identifying keys determine which containers, options, and addresses are extracted.
The previous example shows a subnet container. Its identifying key is the position of the client in the network. If the client is from that network, then it falls into that container.
Each type of container uses a different option to identify a client:
Except for subnets, each container allows the specification of the value that matchs it, including regular expression matching.
There is also an implicit container, the global container. Options and modifiers are placed in the global container unless overridden or denied. Most containers can be placed inside other containers implying a scope of visibility. Containers may or may not have address ranges associated with them. Subnets, by their nature, have ranges associated with them.
The basic rules for containers and subcontainers are:
Given the above rules, you can generate a hierarchy of containers that segment your options into groups for specific clients or sets of clients.
If a client matches multiple containers, how are options and addresses handed out? The DHCP server receives messages, it passes the request to the database (db_file in this case), and a container list is generated. The list is presented in order of depth and priority. Priority is defined as an implicit hierarchy in the containers. Strict containers are higher priority than regular containers. Clients, classes, vendors, and finally subnets are sorted, in that order, and within container type by depth. This generates a list ordered by most specific to least specific. For example:
Subnet 1
--Class 1
--Client 1
Subnet 2
--Class 1
----Vendor 1
----Client 1
--Client 1
The example shows two subnets, Subnet 1 and Subnet 2. There is one class name, Class 1, one vendor name, Vendor 1, and one client name, Client 1. Class 1 and Client 1 are defined in multiple places. Because they are in different containers, their names can be the same but values inside them can be different. If Client 1 sends a message to the DHCP server from Subnet 1 with Class 1 specified in its option list, the DHCP server would generate the following container path:
Subnet 1, Class 1, Client 1
The most specific container is listed last. To get an address, the list is examined in reverse hierarchy to find the first available address. Then, the list is examined in forward hierarchy to get the options. Options override previous values unless an option deny is present in the container. Also, because Class 1 and Client 1 are in Subnet 1, they are ordered according to the container priority. If the same client is in Subnet 2 and sends the same message, the container list generated is:
Subnet 2, Class 1, Client 1 (at the Subnet 2 level), Client 1 (at the Class 1 level)
Subnet 2 is listed first, then Class 1, then the Client 1 at the Subnet 2 level (because this client statement is only one level down in the hierarchy). The hierarchy implies that a client matching the first client statement is less specific than the client matching Client 1 of Class 1 within Subnet 2.
Priority selected by depth within the hierarchy is not superseded by the priority of the containers themselves. For example, if the same client issues the same message and specifies a vendor identifier, the container list is:
Subnet 2, Class 1, Vendor 1, Client 1 (at Subnet 2 level), Client 1 (at Class 1 level)
Container priority improves search performance because it follows a general concept that client containers are the most specific way to define one or more clients. The class container holds less specific addresses than a client container; vendor is even less specific; and subnet is the least specific.
Any container type can have associated addresses ranges; subnets must have associated address ranges. Each range within a container must be a subset of the range and must not overlap with ranges of other containers. For example, if a class is defined within a subnet and the class has a range, the range must be a subset of the subnet range. Also, the range within that class container cannot overlap with any other ranges at its level.
Ranges can be expressed on the container line and modified by range and exclude statements to allow for disjoint address sets associated with a container. If you have the top ten addresses and the second ten addresses of a subnet available, the subnet can specify these addresses by range in the subnet clause to reduce both memory use and the chance of address collision with other clients not in the specified ranges.
Once an address has been selected, any subsequent container in the list that contains address ranges is removed from the list along with its children. Network-specific options in removed containers are not valid if an address is not used from within that container.
After the list has been culled to determine addresses, a set of options is generated for the client. In this selection process, options overwrite previously selected options unless a deny is encountered, in which case, the denied option is removed from the list being sent to the client. This method allows inheritance from parent containers to reduce the amount of data that must be specified.
Modifiers are items that change some aspect of a particular container, such as access or lease time. Define the address and option pools before modifying the container. The most common modifyers are leasetimedefault, supportBootp, and supportUnlistedclients.
Other modifiers are listed in DHCP Server File Syntax for db_file Database.
After selecting modifiers, the next item to set up is logging. Logging parameters are specified in a container like the database, but the container keyword is logging_info. When learning to configure DHCP, it is advisable to turn logging to its highest level. Also, it is best to specify the logging configuration before any other configuration file data to ensure that configuration errors are logged after the logging subsystem is initialized. Use the logitem keyword to turn on a logging level or remove the logitem keyword to disable a logging level. Other keywords for logging allow the specification of the log filename, file size, and the number of rotating log files.
The last set of parameters to specify are server-specific options that allow the user to control the number of packet processors, how often the garbage collection threads are run, and so on..
For example, two server-specific options are:
These options are useful if you have several clients that broadcast DISCOVER messages and, either they do not broadcast their REQUEST message, or their REQUEST message gets lost in the network. Using these parameters keeps addresses from being reserved indefinitely for a noncompliant client.
Another particularly useful option is SaveInterval, which indicates how often saves occur. All server-specific options are listed in DHCP Server File Syntax for General Server Operation with the logging keywords.
It is important to understand that certain configuration keywords and the structure of the configuration file have an effect on the memory use and performance of the DHCP server.
First, excessive memory use can be avoided by understanding the inheritance model of options from parent to child containers. In an environment that supports no unlisted clients, the administrator must explicitly list each client in the file. When options are listed for any specific client, the server uses more memory storing that configuration tree than when options are inherited from a parent container (for example, the subnet, network, or global containers). Therefore, the administrator should verify whether any options are repeated at the client level within the configuration file and determine whether these options can be specified in the parent container and shared by the set of clients as a whole.
Also, when using the logItem entries INFO and TRACE, numerous messages are logged during the processing of every DHCP client message. Appending a line to the log file can be an expensive operation; therefore, limiting the amount of logging improves the performance of the DHCP server. When an error with the DHCP server is suspected, logging can be dynamically re-enabled using either the SRC traceson or dadmin commands.
Finally, selecting a numprocessors value depends on the size of the DHCP-supported network, the pingTime db_file configuration parameter, and the typical propagation delay on the network. Because each packet processor thread issues an ICMP Echo Request to verify the status of a server-owned address before offering it to a client, the amount of time that any Echo Response is waited for directly affects the amount of processing time for a DISCOVER message. Essentially, the packet processor thread is able to do nothing more than wait for any response or for the pingTime timeout. Lowering the numprocessors value improves the response time of the server by lowering the number of client retransmissions, yet still maintaining the ping benefit of the server design.
For best performance, select a pingTime based on the propagation delay of any remote networks supported by the DHCP server. Also, select the numprocessors value based on this pingTime value and the size of the network. Selecting a value that is too small can cause all packet processing threads to be stopped. The server is then caused to wait for any Echo Responses while incoming DHCP client messages are queueing on the server port. This causes the server to handle client messages in batches rather than in a constant stream.
A selected value that is too small can cause all packet processing threads to be stopped waiting for any Echo Responses , which would result in the .
To prevent this situation, set the value for numprocessors to a number higher than the estimated number of DISCOVER messages that can be received within one pingTime interval during a period of high DHCP client activity. However, do not set the numprocessors value so high that it could burden the kernel with thread management.
For example, the values numprocessors 5 and pingTime 300 cause poor performance in an environment with a potential 10 DISCOVER messages per second because at peak demand, only 5 messages are handled every 3 seconds. Configure this environment with values similar to numprocessors 20 and pingTime 80.
Many networks include multiple client types; for example, a single network may include computers running a variety of operating systems, such as Windows, OS/2, Java OS, and UNIX. Each of these require unique vendor identifiers (the field used to identify the type of machine to the DHCP server). Java OS clients and IBM Thin Client machines can require unique parameters such as bootfiles, and configuration options that need to be tailored specifically for them. Windows 95 computers do not handle Java-specific options well.
Machine-specific options can be encapsulated within vendor containers if the rimary use for certain machines is based on the type of user for those machines. For instance, the development staff might use this operating system's clients for programming, the marketing staff might use the OS/2 clients, sales might use Java OS clients and IBM Thin Client machines, and accounting might use Windows 95 machines. Each of these user families might need different configuration options (different printers, nameservers, or default web servers, and so forth). In this case, such options could be included in the vendor container, since each group uses a different machine type.
If the same machine type is used by multiple groups, placing the options within a subordinate class identifier instead, would allow your marketing managers, for example, to use a specific set of printers that other employees could not access.
Note: The following fictional example represents part of a configuration file. Comments are preceded by a pound sign (#) and describe how each line defines the installation.
vendor "AIX_CLIENT"
{
# No specific options, handles things based on class
}
vendor "OS/2 Client"
{
# No specific options, handles things based on class
}
vendor "Windows 95"
{ option 44 9.3.150.3 # Default NetBIOS Nameserver
}
vendor "Java OS"
{ bootstrapserver 9.3.150.4 # Default TFTP server for the Java OS boxes
option 67 "javaos.bin" # The bootfile of the Java OS box
}
vendor "IBM Thin Client"
{ bootstrapserver 9.3.150.5 # Default TFTP server for Thin Client boxes
option 67 "thinos.bin" # Default bootfile for the Thin Client boxes
}
subnet 9.3.149.0 255.255.255.0
{ option 3 9.3.149.1 # The default gateway for the subnet
option 6 9.3.150.2 # This is the nameserver for the subnet
class accounting 9.3.149.5-9.3.149.20
{ # The accounting class is limited to address range 9.3.149.5-9.3.149.20
# The printer for this group is also in this range, so it is excluded.
exclude 9.3.149.15
option 9 9.3.149.15 # The LPR server (print server)
vendor "Windows 95"
{
option 9 deny # This installation of Windows 95 does not support
# this printer, so the option is denied.
}
}
. . .
}
The DHCP server provides options that enable operation in a DDNS environment. To use DHCP in a DDNS environment, you must set and use a Dynamic Zone on a DNS server.
After the DDNS server is configured, decide if the DHCP server is going to do A-record updates, PTR-record updates, updates for both record types, or none at all. This decision depends on whether a client machine can do part or all of this work.
The DHCP server has a set of configuration keywords that allow you to specify a command to run when an update is required. These are:
These keywords specify executable strings that the DHCP server runs when an update is required. The keyword strings must contain four %s (percent symbol, letter s). The first %s is the hostname; the second is the domain name; the third is the IP address; and the fourth is the lease time. These are used as the first four parameters for the dhcpaction command. The remaining two parameters for the dhcpaction command indicate the record to update (A, PTR, NONE, or BOTH) and whether NIM should be updated (NIM or NONIM). See DHCP and Network Installation Management (NIM) Interactions and Suggestions for more information about NIM and DHCP interaction. For example:
updatednsA "/usr/sbin/dhcpaction '%s' '%s' '%s' '%s' A NONIM"
# This does the dhcpaction command only on the A record
updatednsP "/usr/sbin/dhcpaction '%s' '%s' '%s' '%s' PTR NONIM"
# This does the command only on the PTR record
updatedns "/usr/sbin/dhcpaction '%s' '%s' '%s' '%s' BOTH NIM"
# This does the command on both records and updates NIM
The DHCP server also has a set of keywords to remove the DNS entries when a lease is released or expires. The keywords are:
These keywords specify executable strings that the DHCP server runs when an address is released or expired. The dhcpremove command works similarly to dhcpaction, but only takes three parameters:
For example:
releasednsA "/usr/sbin/dhcpremove '%s' A NONIM"
# This does the dhcpremove command only the A record
releasednsP "/usr/sbin/dhcpremove '%s' PTR NONIM"
# This does the command only on the PTR record
removedns "/usr/sbin/dhcpremove '%s' BOTH NIM"
# This does the command on both records and updates NIM
The dhcpaction and dhcpremove scripts do some parameter checking, then set up a call to nsupdate, which has been updated to work with this operating system's servers and with OS/2 DDNS servers. See the nsupdate command description for more information.
If NIM interaction is NOT required by the name update, the DHCP
server can be configured to use a socket transfer between the DHCP
daemon and the nsupdate command to improve performance and enable
DNS updates to be retried upon failure. To configure this option, the
updateDNSA, updateDNSP, releaseDNSA, or the
releaseDNSP keyword must specify "nsupdate_daemon" as the first
quoted word. The parameters and flags for this update are identical to
those that are accepted by the nsupdate command.
Additionally, the following variable names can be used for substitution:
| $hostname | Replaced by the host name of the client on DNS update or the host name previously associated with the client for DNS removal. |
| $domain | Replaced by the DNS domain for the update or the previously used domain of the client host name for a DNS removal. |
| $ipadress | Replaced by the IP address to be associated or disassociated from the DHCP client name. |
| $leasetime | Replaced by the lease time (in seconds). |
| $clientid | Replaced by the string representation of the DHCP client identifier or the combination hardware type and hardware address for BOOTP clients. |
For example:
updateDNSA "nsupdate_daemon -p 9.3.149.2 -h $hostname -d $domain -s"d;a;*;a;a;$ipaddress;s;$leasetime;3110400"" updateDNSP "nsupdate_daemon -p 9.3.149.2 -r $ipaddress -s"d;ptr;*;a;ptr;$hostname.$domain.;s;$leasetime;3110400"" releaseDNSA "nsupdate_daemon -p 9.3.149.2 -h $hostname -d $domain -s"d;a;*;s;1;3110400"" releaseDNSP "nsupdate_daemon -p 9.3.149.2 -r $ipaddress -s"d;ptr;*;s;1;3110400""
See the nsupdate command description for more information.
Also, administrator-defined policies have been added for hostname exchanges between the server and the clients. By default, the hostname that is returned to the client and used for a DDNS update is option 12 (defined in the server configuration file). Alternatively, the default hostname can be the client-suggested hostname, either through option 81 (the DHCPDDNS option) or through option 12 (the HOSTNAME option). However, the administrator can override the default hostname by using the hostnamepolicy, proxyarec, and appenddomain configuration keywords. These options and their parameters are defined in DHCP Server File Syntax for db_file Database.
The DHCP server for AIX 4.3.1 and later recognizes the previous versions configuration and database files, dhcps.ar and dhcps.cr. It parses the old configuration files and generates new database files in the old locations. The old databases are converted automatically to the new file. The configuration file itself is not converted.
The DHCP server database module, db_file, can read the old format. The DHCP server can recognize when a database container is not in the configuration file and treats the whole file as configuring the server parameters, logging parameters, and the db_file database parameters.
Notes: Some old configuration file syntax is deprecated, but is still supported. Other deprecations are:
- The network container is completely deprecated. To specify correctly, either convert the network clause with a range into a valid subnet container with a subnet address, subnet netmask, and the range. If the network container has subnet containers, remove the network container keyword and its braces and then place the subnet mask in the appropriate place on the line. To start using the database container, group everything that pertains to networks and client access into one database container of type db_file.
- The updatedns and removedns keywords are deprecated and replaced in favor of specifying the action for A and PTR records separately.
- The clientrecorddb and addressrecorddb keywords have been deprecated to clientrecorddb and backupfile, respectively.
- The option sa and option ga keywords have been replaced by bootstrapserver and giaddrfield keywords, respectively. See DHCP Server File Syntax for General Server Operation and DHCP Server File Syntax for db_file Database for more information.
Note: The options that are shown in the following table as not allowed to be specified (No in the Can Specify? column) can be specified in the configuration file, but are overwritten by the correct value. For a better definition of each option, see RFC 2132.
| Option Number | Default Data Type | Can Specify? | Description/Use |
|---|---|---|---|
| 0 | None | No | The server pads the option field, if necessary. |
| 1 | Dotted quad | No | The net mask of the subnet from which the address was drawn. |
| 2 | 32-bit integer | Yes | Specifies the offset of the client subnet, in seconds from Coordinated Universal Time (UTC). |
| 3 | One or more dotted quads | Yes | A list of the default gateways' IP addresses. |
| 4 | One or more dotted quads | Yes | A list of time server IP addresses. |
| 5 | One or more dotted quads | Yes | A list of name server IP addresses. |
| 6 | One or more dotted quads | Yes | A list of DNS IP addresses. |
| 7 | One or more dotted quads | Yes | A list of log server IP addresses. |
| 8 | One or more dotted quads | Yes | A list of cookie server IP addresses. |
| 9 | One or more dotted quads | Yes | A list of LPR server IP addresses. |
| 10 | One or more dotted quads | Yes | A list of Impress server IP addresses. |
| 11 | One or more dotted quads | Yes | A list of Resource Location server IP addresses. |
| 12 | An ASCII string | Yes | A hostname for the client to use. |
| 13 | 16-bit unsigned integer | Yes | The size of the bootfile. |
| 14 | An ASCII string | Yes | The path for Merit Dump file. |
| 15 | An ASCII string | Yes | The default DNS domain name. |
| 16 | An IP address | Yes | The address of the Swap server. |
| 17 | An ASCII string | Yes | The default root path. |
| 18 | An ASCII string | Yes | The path to extensions for the client. |
| 19 | Yes, No, True, False, 1, 0 | Yes | Specify whether IP Forwarding should be turned on. |
| 20 | Yes, No, True, False, 1, 0 | Yes | Specify whether non-local source routing should be used. |
| 21 | One or more pairs of dotted quads, in the form DottedQuad:DottedQuad | Yes | The filter policies for IP addresses. |
| 22 | 16-bit unsigned integer | Yes | The maximum size to allow for datagram fragments. |
| 23 | 8-bit unsigned integer | Yes | The IP time-to-live (TTL). |
| 24 | 32-bit unsigned integer | Yes | The number of seconds to use in the Path MTU aging timeout. |
| 25 | List of one or more 16-bit unsigned integers | Yes | The path MTU Plateau table. Specifies a set of values that represent the MTU sizes to use when using Path MTU discovery. |
| 26 | 16-bit unsigned integer | Yes | Specifies MTU size for the receiving interface. |
| 27 | Yes, No, True, False, 1, 0 | Yes | Specifis whether all subnets are local. |
| 28 | An IP address (dotted quad) | Yes | Specifies broadcast address for the interface. |
| 29 | Yes, No, True, False, 1, 0 | Yes | Specifies whether ICMP netmask discovery should be used. |
| 30 | Yes, No, True, False, 1, 0 | Yes | Specifies whether client should become an ICMP netmask supplier. |
| 31 | Yes, No, True, False, 1, 0 | Yes | Specifies whether ICMP Router Discovery messages should be used. |
| 32 | IP address (dotted quad) | Yes | Specifies address to use for router solicitation. |
| 33 | One or more IP address pairs, in the form DottedQuad:DottedQuad | Yes | Each address pair represents a static route. |
| 34 | Yes/No, True/False, 1/0 | Yes | Specifies whether trailer encapsulation should be used. |
| 35 | 32-bit unsigned integer | Yes | ARP cache timeout value. |
| 36 | Yes/No, True/False, 1/0 | Yes | Spcifies whether Ethernet encapsulation should be used. |
| 37 | 8-bit unsigned integer | Yes | The TCP time-to-live (TTL). |
| 38 | 32-bit unsigned integer | Yes | The TCP keep alive interval. |
| 39 | Yes/No, True/False, 1/0 | Yes | Specifies whether TCP keep alive should be used. |
| 40 | An ASCII string | Yes | The NIS default domain. |
| 41 | One or more dotted quads | Yes | Specifies the IP addresses of the NIS servers. |
| 42 | One or more dotted quads | Yes | Specifies the IP addresses of the NTP servers. |
| 43 | hex string of digits, in the form of hex "digits", hex "digits", or 0xdigits | Yes, but really only specified with vendor container | Encapsulated option container for the vendor container. |
| 44 | One or more dotted quads | Yes | Specifies NetBIOS name server IP addresses. |
| 45 | One or more dotted quads | Yes | Specifies NetBIOS datagram distribution server IP addresses. |
| 46 | 8-bit unsigned integer | Yes | Specifies NetBIOS Node Type. |
| 47 | hex string of digits, in form of hex "digits", hex "digits", or 0xdigits | Yes | NetBIOS Scope. |
| 48 | One or more dotted quads | Yes | Specifies X Windows font server IP addresses. |
| 49 | One or more dotted quads | Yes | Specifies X Windows Display Manager. |
| 50 | None | No | Requested IP Address, used by client to indicate the address it wants. |
| 51 | 32-bit unsigned integer | Yes | Lease time for the returned address. By default, the DHCP server uses the leasetimedefault keyword, but direct specification of option 51 overrides it. |
| 52 | None | No | Option overload. Client uses this to indicate the sname and file fields of the BOOTP packet may have options. |
| 53 | None | No | DHCP server or client uses this option to indicate the type of DHCP message. |
| 54 | None | No | DHCP server or client uses this option to indicate the server's address or the server to which the message is directed. |
| 55 | None | No | DHCP client uses this to indicate desired options. |
| 56 | An ASCII string | Yes | A string the DHCP server sends to the client. In general, this can be used by the DHCP server and client to indicate problems. |
| 57 | No | No | DHCP client uses this option to tell the DHCP server the maximum DHCP packet size the client can receive. |
| 58 | 32-bit unsigned integer | Yes | Specifies the number of seconds until the client should send a renew packet. |
| 59 | 32-bit unsigned integer | Yes | Specifies the number of seconds until the client should send a rebind packet. |
| 60 | None | No | DHCP client uses this option to indicate its vendor type. The DHCP server uses this field to match vendor containers. |
| 61 | None | No | DHCP client uses this to uniquely identify itself. The DHCP server uses this field to match client containers. |
| 64 | An ASCII string | Yes | Specifies the NIS+ domain. |
| 65 | One or more dotted quads | Yes | IP Addresses of NIS+ servers. |
| 66 | An ASCII string | Yes | Specifies the TFTP server name. This is a hostname and is used instead of the siaddr field if the client understands this option. |
| 67 | An ASCII string | Yes | Specifies the bootfile name. This can be used instead of the bootfile keyword, which places the file in the filename field of the packet. |
| 68 | One or more dotted quads, or NONE | Yes | Specifies addresses of home agents. |
| 69 | One or more dotted quads | Yes | Specifies default SMTP servers to use. |
| 70 | One or more dotted quads | Yes | Specifies default POP3 servers to use. |
| 71 | One or more dotted quads | Yes | Specifies default NNTP servers to use. |
| 72 | One or more dotted quads | Yes | Specifies default WWW servers to use. |
| 73 | One or more dotted quads | Yes | Specifies default Finger servers to use. |
| 74 | One or more dotted quads | Yes | Specifies default IRC servers to use. |
| 75 | One or more dotted quads | Yes | Specifies default Street Talk servers to use. |
| 76 | One or more dotted quads | Yes | Specifies default Street Talk directory assistance servers to use. |
| 77 | An ASCII string | Yes | The user site class identifier. The DHCP server uses this field to match class containers. |
| 81 | An ASCII string plus other items | No | The DHCP client uses this option to define the policy the DHCP server should use with respect to DDNS. |
| 93 | None | No | The DHCP client uses this option to define the client system architecture. |
| 94 | None | No | The DHCP client uses this option to define the client network interface identifier. |
| 255 | None | No | DHCP server and client use this option to indicate the end of an option list. |
When supporting a preboot execution environment (PXE) client, the DHCP
server passes the following option to the BINLD server, which is used by BINLD
to configure itself:
| Opt Num | Default Data Type | Can Specify? | Description |
|---|---|---|---|
| 7 | one dotted quad | Yes | Multicast IP address. Boot server discovery multicast IP address. |
The following example shows how this option can be used:
pxeservertype proxy_on_dhcp_server
Vendor pxeserver
{
option 7 9.3.4.68
}
In the above example, the DHCP server informs the client that the proxy server is running on the same machine but is listening on port 4011 for client requests. The vendor container is required here because the BINLD server broadcasts an INFORM/REQUEST message on port 67 with option 60 set to "PXEServer." In response, the DHCP server sends the Multicast IP address on which the BINLD has to listen for PXEClient's request.
In the following example, the dhcpsd server either gives the bootfile name to the PXEClient or it directs the PXEClient to the BINLD server by sending suboptions. The pxeboofile keyword is used to create a list of boot files for a given client architecture and major and minor versions of the client system.
pxeservertype dhcp_pxe_binld
subnet default
{
vendor pxe
{
option 6 2 # Disable Multicast
option 8 5 4 10.10.10.1 12.1.1.15 12.5.5.5 12.6.6.6\
2 2 10.1.1.10 9.3.4.5 1 1 10.5.5.9\
1 1 9.3.149.15\
4 0
option 9 5 "WorkSpace On Demand" 2 "Intel"\
1 "Microsoft WindowsNT" 4 "NEC ESMPRO"
option 10 2 "Press F8 to View Menu"
}
vendor pxeserver
{
option 7 239.0.0.239
}
}
subnet 9.3.149.0 255.255.255.0
{
option 3 9.3.149.1
option 6 9.3.149.15
vendor pxe
{
option 6 4 # bootfile is present in the offer packet
pxebootfile 1 2 1 os2.one
pxebootfile 2 2 1 aix.one
}
}
Each option line in pxe container is used by the server to tell the client what to do. PXE Vendor Container Suboptions describes the currently supported and known PXE sub-options.
Note: Time Units (time_units) shown in the following table are optional and represent a modifier to the actual time. The default time unit is minutes. Valid values are seconds (1), minutes (60), hours (3600), days (86400), weeks (604800), months (2392000), and years (31536000). The number shown in parentheses is a multiplier applied to the specified value n to express the value in seconds.
| Keyword | Form | Subcontainers? | Default Value | Meaning |
|---|---|---|---|---|
| database | database db_type | Yes | None | The primary container that holds the definitions for the address pools, options, and client access statements. db_type is the name of a module that is loaded to process this part of the file. The only value currently available is db_file. |
| logging_info | logging_info | Yes | None | The primary logging container that defines the logging parameters. |
| logitem | logitem NONE | No | All default to not enabled. | Enables the logging level. Multiple lines are allowed. |
| logitem SYSERR | ||||
| logitem OBJERR | ||||
| logitem PROTOCOL | ||||
| logitem PROTERR | ||||
| logitem WARN | ||||
| logitem WARNING | ||||
| logitem CONFIG | ||||
| logitem EVENT | ||||
| logitem PARSEERR | ||||
| logitem ACTION | ||||
| logitem ACNTING | ||||
| logitem STAT | ||||
| logitem TRACE | ||||
| logitem RTRACE | ||||
| logitem START | ||||
| numLogFiles | numLogFiles n | No | 0 | Specifies the number of log files to create. The log rotates when the first one fills. n is the number of files to create. |
| logFileSize | logFileSize n | No | 0 | Specifies the size of each log file in 1024-byte units. |
| logFileName | logFileName path | No | None | Specifies the path to the first log file. The original log file is named filename or filename.extension. The filename must be eight or fewer characters. When a file is rotated, it is renamed beginning with the base filename, then either appending a number or replacing the extension with a number. For example, if the original file name is file, the rotated file name becomes file01. If the original file name is file.log, it becomes file.01. |
| CharFlag | charflag yes | No | true | Not applicable to this operating system's DHCP server, but the OS/2 DHCP server uses it to produce debug windows. |
| charflag true | ||||
| charflag false | ||||
| charflag no | ||||
| StatisticSnapShot | StatisticSnapShot n | No | -1, never | Specifies how often statistics are written to the log file in seconds. |
| UsedIpAddressExpireInterval | UsedIpAddressExpireInterval n time_units | No | -1, never | Specifies how often addresses placed in the BAD state are recouped and retested for validity. |
| leaseExpireInterval | leaseExpireInterval n time_units | No | 900 seconds | Specifies how often addresses in the BOUND state are checked to see if they have expired. If the address has expired, the state is moved to EXPIRED. |
| reservedTime | reservedTime n time_units | No | -1, never | Specifies how long addresses should sit in RESERVED state before being recouped into the FREE state. |
| reservedTimeInterval | reservedTimeInterval n time_units | No | 900 seconds | Specifies how often addresses in the RESERVE state are checked to see if they should be recouped into the FREE state. |
| saveInterval | saveInterval n time_units | No | 3600 seconds | Specifies how often the DHCP server should force a save of the open databases. For heavily loaded servers, this should be 60 or 120 seconds. |
| clientpruneintv | clientpruneintv n time_units | No | 3600 seconds | Specifies how often the DHCP server has the databases remove clients are not associated with any address (in the UNKNOWN state). This reduces the memory use of the DHCP server. |
| numprocessors | numprocessors n | No | 10 | Specifies the number of packet processors to create. Minimum of one. |
| userObject | userObject obj_name | Yes | None | Indicates that the server should load a user-defined shared object and call routines within this object through each interaction with DHCP clients. The object to be loaded is located in the /usr/sbin directory by the name obj_name.dhcpo. See the DHCP Server User-Defined Extension API for more information. |
| pxeservertype | pxeservertype server_type | No | dhcp_only | Indicates the type of dhcpd server that it is.
server_type can be one of the following:
The default is dhcp_only, meaning the dhcpsd does not support PXE clients in default mode. |
Notes: Time Units (time_units) shown in the following table are optional and represent a modifier to the actual time. The default time unit is minutes. Valid values are seconds (1), minutes (60), hours (3600), days (86400), weeks (604800), months (2392000), and years (31536000). The number shown in parentheses is a multiplier applied to the specified value n to express the value in seconds.Also, items that are specified in one container can be overridden inside a subcontainer. For example, you could globally define BOOTP clients, but within a certain subnet allow BOOTP clients by specifying the supportBootp keyword in both containers.
The client, class, and vendor containers allow for regular expression support. For class and vendor, a quoted string with the first character after the quote being an exclamation point (!) indicates that the rest of the string should be treated as a regular expression. The client container allows for regular expressions on both the hwtype and the hwaddr fields. A single string is used to represent both fields with the following format:
decimal_number-dataIf decimal_number is zero, then data is an ASCII string. If any other number, data is hex digits.
| Keyword | Form | Subcontainers? | Default Value | Meaning |
|---|---|---|---|---|
| subnet | subnet default | Yes | None | Specifies a subnet without an associated range. This subnet is used by the server only when responding to a client INFORM/REQUEST packet from the client and the client's address does not have another matching subnet container. |
| subnet | subnet subnet id netmask | Yes | None | Specifies a subnet and a pool of addresses. All addresses are assumed to be in the pool unless a range is specified on the line or addresses are modified later in the container by a range or exclude statement. The optional range is a pair of IP addresses in dotted quad format separated by a dash. An optional label and priority can be specified. These are used by virtual subnets to identify and order the subnets in the virtual subnet. The label and priority are separated by a colon. These containers are only allowed at the global or database container level. |
| subnet subnet id netmask range | ||||
| subnet subnet id netmask label:priority | ||||
| subnet subnet id netmask range label:priority | ||||
| subnet | subnet subnet id range | Yes | None | Specifies a subnet that goes within a network container. It
defines a range of addresses that is the whole subnet unless the optional
range part is specified. The netmask associated with the subnet is
taken from the surrounding network container.
Note: This method is deprecated in favor of the other subnet forms. |
| option | option number data ... | No | None | Specifies an option to send to a client or, in the case of deny, an option to prevent from being sent to the client. The option * deny clause means all options not specified in the current container are not to be returned to the client. The option numberdeny only denies the specified option. number is an unsigned 8-bit integer. data is specific to the option (see above) or can be specified as a quoted string (indicating ASCII text) or 0xhexdigits or hex"hexdigits" or hex "hexdigits". If the option is in a vendor container, the option will be encapsulated with other options in an option 43. |
| option numberdeny | ||||
| option * deny | ||||
| exclude | exclude an IP address | No | None | Modifies the range on the container in which the exclude statement is in. The exclude statement is not valid in the global or database container levels. The exclude statement removes the specified address or range from the current range on the container. The exclude statement allows you to create non-contiguous ranges for subnets or other containers. |
| exclude dotted_quad-dotted_quad | ||||
| range | range IP_address | No | None | Modifies the range on the container in which the range statement is in. The range statement is not valid in the global or database container levels. If the range is the first in the container that does not specify a range on the container definition line, then the range for the container becomes the range specified by the range statement. Any range statement after the first range or all range statements for a containers that specifies ranges in its definition are added to the current range. With the range statement, a single address or set of addresses can be added to the range. The range must fit inside the subnet container definition. |
| range dotted_quad-dotted_quad | ||||
| client | client hwtype hwaddr NONE | Yes | None | Specifies a client container that denies the client specified by the hwaddr and hwtype from getting an address. If hwtype is 0, then hwaddr is an ASCII string. Otherwise, hwtype is the hardware type for the client and hwaddr is the hardware address of the client. If the hwaddr is a string, then quotes are accepted around the string. If the hwaddr is a hexstring, then the address may be specified by 0xhexdigits or hex digits. range allows the client specified by the hwaddr and hwtype to get an address in the range. Must be regular expressions to match multiple clients. |
| client hwtype hwaddr ANY | ||||
| client hwtype hwaddr dotted_quad | ||||
| client hwtype hwaddr range | ||||
| class | class string | Yes | None | Specifies a class container with name string. String can be quoted or not. If quoted, the quotes are removed before comparison. Quotes are required for strings with spaces or tabs. This container is valid at any level. A range can be supplied to indicate a set of addresses to hand out to a client with this class. The range is either a single dotted quad IP address or two dotted quad IP addresses separated by a dash. |
| class string range | ||||
| network | network network id netmask | Yes | None | Specifies a network ID using class information (for example,
9.3.149.0 with a netmask of
255.255.255.0 would be network
9.0.0.0 255.255.255.0). This
version of the network container is used to hold subnets with the same network
ID and netmask. When a range is provided, all the addresses in the
range are in the pool. The range must be in the network ID's
network. This uses class full addressing. This is only valid in
the global or database container level.
Note: The network keyword is deprecated in favor of the subnet container. |
| network network id | ||||
| network network id range | ||||
| vendor | vendor vendor_id | Yes | None | Specifies a vendor container. Vendor containers are used to return option 43 to the client. The vendor id may be specified in a quoted string or a binary string in the form 0xhexdigits or hex"digits". An optional range may be placed after the vendor id. The range is specified as two dotted quads separated by a dash. After the optional range, an optional hexstring or ASCII string can be specified as the first part of the option 43. If options are in the container, they are appended to the option 43 data. After all options are processed an End Of Option List Option is appended to the data. To return options outside of an option 43, use a regular expression client that matches all clients to specify normal options to return based on the vendor ID. |
| vendor vendor_id hex"" | ||||
| vendor vendor_id hex "" | ||||
| vendor vendor_id 0xdata | ||||
| vendor vendor_id "" | ||||
| vendor vendor_id range | ||||
| vendor vendor_id range hex"" | ||||
| vendor vendor_id range hex "" | ||||
| vendor vendor_id range 0xdata | ||||
| vendor vendor_id range "" | ||||
| inoption | inoption number option_data | Yes | None | Specifies a container to be matched against any arbitrary incoming option specified by the client. number specifies the option number. option_data specifies the key to match for this container to be selected during address and option selection for the client. option_data is specified in expected form -- quoted string, IP address, integer value -- for well known options, or it can be optionally specified as a hexadecimal string of bytes if preceded by the characters 0x. For options that are not well known to the server, a hexadecimal string of bytes can be specified in the same fashion. Additionally, the option_data can indicate a regular expression to be compared against the string representation of the client's option data. Regular expressions are specified in a quoted string beginning "! (double quote followed by an exclamation mark). The string form of options not well known to the server will be a hexadecimal string of bytes NOT preceded with the characters 0x. |
| inoption number option_data range | ||||
| virtual | virtual fill id id ... | No | None | Specifies a virtual subnet with a policy. fill means use all addresses in the container before going to the next container. rotate means select an address from the next pool in the list on each request. sfill and srotate are the same as fill and rotate, but a search is done to see if the client matches containers, vendors, or classes in the subnet. If a match is found that can supply an address, the address is taken from that container instead of following the policy. There can be as many IDs as needed. id is either the subnet ID from the subnet definition or the label from the subnet definition. The label is required if there are multiple subnets with the same subnet id. |
| virtual sfill id id ... | ||||
| virtual rotate id id ... | ||||
| virtual srotate id id ... | ||||
| inorder: | inorder: id id ... | No | None | Specifies a virtual subnet with a policy of fill, which means use all addresses in the container before going to the next container. There can be as many IDs as needed. id is either the subnet ID from the subnet definition or the label from the subnet definition. The label is required if there are multiple subnets with the same subnet ID. |
| balance: | balance: id id ... | No | None | Specifies a virtual subnet with a policy of rotate, which means use the next address in the next container. There can be as many IDs as needed. id is either the subnet ID from the subnet definition or the label from the subnet definition. The label is required if there are multiple subnets with the same subnet ID. |
| supportBootp | supportBootp true | No | Yes | Specifies whether the current container and all below it (until overridden) should support BOOTP clients. |
| supportBootp 1 | ||||
| supportBootp yes | ||||
| supportBootp false | ||||
| supportBootp 0 | ||||
| supportBootp no | ||||
| supportUnlistedclients | supportUnlistedclients BOTH | No | Both | Specifies whether the current container and all below it (until
overridden) should support unlisted clients. The value indicates
whether all clients should be allowed access without specific client
statements, DHCP clients only, BOOTP clients only, or no one.
Note: The true and false values are supported for compatibility with previous versions and are deprecated. The true value corresponds to BOTH and the false value corresponds to NONE. |
| supportUnlistedclients DHCP | ||||
| supportUnlistedclients BOOTP | ||||
| supportUnlistedclients NONE | ||||
| supportUnlistedclients true | ||||
| supportUnlistedclients yes | ||||
| supportUnlistedclients 1 | ||||
| supportUnlistedclients false | ||||
| supportUnlistedclients no | ||||
| supportUnlistedclients 0 | ||||
| addressrecorddb | addressrecrddb path | No | None | If specified, it works like the backupfile keyword.
Only valid in the global or database container level.
Note: This method is deprecated. |
| backupfile | backupfile path | No | /etc/db_file.crbk | Specifies the file to use for database backups. Only valid in the global or database container level. |
| checkpointfile | checkpointfile path | No | /etc/db_file.chkpt | Specifies the database checkpoint files. The first checkpoint file is the path. The second checkpoint file is path with the last character replaced with a 2. So, the checkpoint file should not end in 2. Only valid in the global or database container level. |
| clientrecorddb | clientrecorddb path | No | /etc/db_file.cr | Specifies the database save file. The file contains all the client records the DHCP server has serviced. Only valid in the global or database container level. |
| bootstrapserver | bootstrapserver IP address | No | None | Specifies the server clients should use from which to TFTP files after receiving BOOTP or DHCP packets. This value fills in the siaddr field in the packet. This is valid at any container level. |
| giaddrfield | giaddrfield IP address | No | None | Specifies the giaddrfield for response packets.
Note: This specification is illegal in the BOOTP and DHCP protocols, but some clients require the giaddr field to be the default gateway for the network. Because of this potential conflict, giaddrfield should only be used within a client container, although it can work at any level. |
| pingTime | pingTime n time_unit | No | 3 seconds | Specifies the amount of time to wait for a ping response before handing out an address. The default time unit is hundredths of a second. The time unit value is defined in the note preceding this table. This is valid at any container level. The time_unit parameter is optional. |
| bootptime | bootptime n time_unit | No | -1, infinite | Specifies the amount of time to lease an address to a BOOTP client. The default is -1, which means infinite. The normal time unit values are available. The time unit parameter is optional. This is valid at any container level. |
| AllRoutesBroadcast | allroutesbroadcast no | No | 0 | Specifies whether responses should be broadcast to all routes, if a broadcast response is required. This is valid at any container level. This is ignored by the operating system's DHCP servers, because the actual MAC address of the client, including RIFs, are stored for the return packet. This is valid at any container level. |
| allroutesbroadcast false | ||||
| allroutesbroadcast 0 | ||||
| allroutesbroadcast yes | ||||
| allroutesbroadcast true | ||||
| allroutesbroadcast 1 | ||||
| addressassigned | addressassigned "string" | No | None | Specifies a quoted string to execute when an address is assigned to a client. The string should have two %s. The first %s is the client id in the form type-string. The second %s is an IP address in dotted quad format. This is valid at any container level. |
| addressreleased | addressreleased "string" | No | None | Specifies a quoted string to execute when an address is released by a client. The string should have one %s. The %s is the IP address being released in dotted quad format. This is valid at any container level. |
| appenddomain | appenddomain 0 | No | No | Specifies whether to append the defined option 15 domain name to the client-suggested hostname in the event that the client does not suggest a domain name as well. This is valid at any container level. |
| appenddomain no | ||||
| appenddomain false | ||||
| appenddomain 1 | ||||
| appenddomain yes | ||||
| appenddomain true | ||||
| canonical | canonical 0 | No | 0 | Specifies that the client id is in canonical format. This is valid only in the client container. |
| canonical no | ||||
| canonical false | ||||
| canonical 1 | ||||
| canonical yes | ||||
| canonical true | ||||
| leaseTimeDefault | leaseTimeDefault n time_unit | No | 86400 seconds | Specifies the default lease time for clients. This is valid at any container level. The time_unit parameter is optional. |
| proxyarec | proxyarec never | No | usedhcpddnsplus | Specifies what options and methods should be used for A record updates in the DNS. never means never update the A record. usedhcpddns means use option 81 if the client specifies it. usedhcpddnsplus means use option 81 or option 12 and 15, if specified. always means do the A record update for all clients. XXXXprotected modifies the nsupdate command to make sure the client is allowed. standard is a synonym for always. protected is a synonym for alwaysprotected. This is valid at any container level. |
| proxyarec usedhcpddns | ||||
| proxyarec usedhcpddnsplus | ||||
| proxyarec always | ||||
| proxyarec usedhcpddnsprotected | ||||
| proxyarec usedhcpddnsplusprotected | ||||
| proxyarec alwaysprotected | ||||
| proxyarec standard | ||||
| proxyarec protected | ||||
| releasednsA | releasednsA "string" | No | None | Specifies the execution string to use when an address is released. The string is used to remove the A record associated with the address released. This is valid at any container level. |
| releasednsP | releasednsP "string" | No | None | Specifies the execution string to use when an address is released. The string is used to remove the PTR record associated with the address released. This is valid at any container level. |
| removedns | removedns "string" | No | None | Specifies the execution string to use when an address is released.
The string is used to remove the PTR and A record associated with the address
released. This is valid at any container level.
Note: This is deprecated in favor of the releasednsA and releasednsP keywords. |
| updatedns | updatedns "string" | No | None | Specifies the execution string to use when an address is bound.
The string is used to update both the A and the PTR record associated with the
address. This is valid at any container level.
Note: This is deprecated in favor of the updatednsA and updatednsP keywords. |
| updatednsA | updatednsA "string" | No | None | Specifies the execution string to use when an address is bound. The string is used to update the A record associated with the address. This is valid at any container level. |
| updatednsP | updatednsP "string" | No | None | Specifies the execution string to use when an address is bound. The string is used to update the PTR record associated with the address. This is valid at any container level. |
| hostnamepolicy | hostnamepolicy suggested | No | default | Specifies which hostname to return to the client. Default policy is to prefer the defined hostname and domain name over suggested names. Other policies imply strict adherence (for example: defined will return the defined name or none if no name is defined in the configuration). Also, policies using the always modifier will dictate the server to return the hostname option regardless of whether the client requested it through the parameter list option. Note that suggesting a hostname also implies requesting it, and hostnames can be suggested through option 81 or through options 12 and 15. This keyword is valid at any container level. |
| hostnamepolicy resolved | ||||
| hostnamepolicy always_resolved | ||||
| hostnamepolicy defined | ||||
| hostnamepolicy always_defined | ||||
| hostnamepolicy default | ||||
| bootfilepolicy | bootfilepolicy suggested | No | suggested | Specifies a preference for returning the bootfile name to a client. suggested prefers the client-suggested bootfile name to any server-configured name. merge appends the client suggested name to the server-configured home directory. defined prefers the defined name over any suggested bootfile name. always returns the defined name regardless of whether the client requests the bootfile option through the parameter list option. |
| bootfilepolicy merge | ||||
| bootfilepolicy defined | ||||
| bootfilepolicy always | ||||
| stealfromchildren | stealfromchildren true | No | No | Specifies whether the parent container should "steal" from children containers when the parent container runs out of addresses. This means that if you have a subnet with class defined with a range of addresses, those addresses are reserved for those clients that specify that class. If stealfromchildren is true, then addresses will be pulled from a child to try and satisfy the request. The default is to not steal an address. |
| stealfromchildren 1 | ||||
| stealfromchildren yes | ||||
| stealfromchildren false | ||||
| stealfromchildren 0 | ||||
| stealfromchildren no | ||||
| homedirectory | homedirectory path | No | None | Specifies the home directory to use in the file section of the response packet. This can be specified at any container level. The bootfile policy defines how items specified in the file section of the incoming packet interact with the bootfile and the home directory statements. |
| bootfile | bootfile path | No | None | Specifies the bootfile to use in the file section of the response packet. This can be specified at any container level. The bootfile policy defines how items specified in the file section of the incoming packet interact with the bootfile and the home directory statements. |
| pxebootfile | pxebootfile system_architecture major_version minor_version boofilename | No | None | Specifies the bootfile to be given for a client. This is used only when dhcpsd supports PXE clients (pxeservertype is dhcp_pxe_binld). The configuration file parser generates an error if the number of parameters after pxebootfile is less than four, and it ignores any additional parameters. pxebootfile can only be used within a container. |
The concept of dynamically assigning Internet Protocol (IP) addresses is fairly new. The following suggestions are provided to help with DHCP and NIM interaction.
updatedns "/usr/sbin/dhcpaction '%s' '%s' '%s' '%s' NONE NONIM"
In the /etc/dhcpsd.cnf file, change the updatedns line to:
updatedns "/usr/sbin/dhcpaction '%s' '%s' '%s' '%s' BOTH NIM"
Note: When a NIM object is placed into the BOS installation-pending state, the dhcpsd server might pass arguments that are different from those originally intended. Minimize the time the client is in this pending state to avoid this situation.
These suggestions allow the NIM environment to work with dynamic clients.
For more information on Network Installation Management, see AIX 5L Version 5.1 Network Installation Management Guide and Reference.