This manual page describes the dhcpd.conf file read by Carnegie Mellon University’s dhcpd(8) version 3.3.7 with the Princeton patches (patchlevel 12) installed.
The default location of this file is /etc/dhcpd.conf, but that may be overridden via a commandline option to dhcpd(8) or a compile-time option when building dhcpd.
The file consists of a series of statements, one per line. Each statement begins with a keyword followed by zero or more arguments (depending on the keyword); keywords and arguments are separated by spaces or tabs.
Blank lines are ignored. Lines for which the first character is a ’#’ are treated as comments.
Throughout the discussion below, network refers to an IP network or subnet.
The keywords are as follows:
Specify
where n is an integer (n < 2^32-1)
If unspecified (or specified as 0), then before processing each received packet, the server checks the dhcpd.conf(5) file’s modification time. If the file’s modification time is newer than the file’s modification time at the time the file was last read, the server re-reads the dhcpd.conf(5) file.
If a positive value is specified, then before processing each received packet, the server checks whether the specified number of seconds have passed since the dhcpd.conf(5) file was last read. If fewer seconds have passed, the server does not check file’s modification time; the file is not re-read. If the specified number of seconds have passed, the server proceeds to examine the dhcpd.conf(5) file’s modification time (as described earlier).
This feature allows you to reduce the frequency of the (relatively) expensive retrieval of the dhcpd.conf(5) file’s modification time.
The dhcpd.conf(5) is still re-read when the server is signalled to do so, regardless of the use of readconfinterval. It is also re-read whenever the server re-reads the bootptab(5) file.
Specify
where n is an integer (n < 2^32-1)
If unspecified (or specified as 0), then before processing each received packet, the server checks the bootptab(5) file’s modification time. If the file’s modification time is newer than the file’s modification time at the time the file was last read, the server re-reads the bootptab(5) file.
If a positive value is specified, then before processing each received packet, the server checks whether the specified number of seconds have passed since the bootptab(5) file was last read. If fewer seconds have passed, the server does not check file’s modification time; the file is not re-read. If the specified number of seconds have passed, the server proceeds to examine the bootptab(5) file’s modification time (as described earlier).
This feature allows you to reduce the frequency of the (relatively) expensive retrieval of the bootptab(5) file’s modification time.
The bootptab(5) is still re-read when the server is signalled to do so, regardless of the use of readtabinterval.
Specify:
where n is an integer (n < 2^32-1) specifying the number of microseconds (millionths of a second) to delay. The delay_reply_default value is used when a no value specific to the flavor of packet has been specified. All values default to 0.
By default, changes to the lastbindings data are cached in-memory, and written out to disk once 20 changes have accumulated in the cache, or 30 seconds have elapsed, whichever comes first. They are also written out whenever the server is shut down normally. By default, they are written to the /etc/bindings directory.
Specify:
where n is an integer (n < 2^32-1) specifying the number of items that should accumulate in the cache before the cache is flushed to disk.
Specify:
where n is an integer (n < 2^32-1) specifying the number of seconds that should elapse between cache flushes.
If both flushitems and flushinterval are specified, the cache will be flushed when either condition is met.
As these tunables reduce the amount of information that is not written to disk in the event of an abnormal termination, they need only be set to small values if you often experience server crashes. Otherwise, it makes sense to increase these values.
Specify:
where n is an integer (n < 2^32-1) specifying the number of seconds that should elapse between garbage collections.
The expire_infinite_dynamics statement is optional, and is used to enable the Expire Infinite Dynamics feature. See dhcpd(8) for information about the this feature.
Specify:
where n is an integer (n < 2^32-1) specifying the number of seconds that a BootP-assigned dynamic IP address assiggment should be considered valid. Such assignments are normally of infinite duration; enabling the Expire Infinite Dynamics feature causes each such assignment instead to be expired n seconds after the assignment is made.
If the expire_infinite_dynamics statement is not present, the Expire Infinite Dyamics feature is not enabled. (The feature is also not enabled if n is 0.)
The network statement is used to declare each pool of dynamically-assigned IP addresses. (If the server does not provide dynamically-assigned IP addresses, then the file will contain no network statements.)
If the server will provide dynamically-assigned IP addresses on several IP networks, specify a network statement for each of these pools. The statement defines the name of the "pool" of dynamic addresses for that network, the pool’s network range (number and netmask), the BootP Relay Agents in front of the network where the pool is used, and which clients may obtain the dynamic addresses. It does not list the actual IP addresses that comprise the pool; those are defined in the bootptab(5) file. The pools network range specified here is used to select the IP addresses from the bootptab(5) file.
The format of the network statement is:
where:
Although the network statement declares each pool of dynamically-assigned IP addresses, it does not list the specific IP addresses that may be so assigned. Those IP addresses are defined in the bootptab(5) file; what makes them dynamic addresses is that their bootptab(5) entries must contain the :dy: tag, and must not contain any :ht: (hardware type), :ha: (hardware address), or :cl: client identifier), tags. (When the server parses such a bootptab entry, it will determine in which pool of dynamic IP addresses the address belongs by comparing its IP address to the netnumber and netmask values for each network and networkalso statement in the dhcpd.conf(5) file.
The networkalso statement is used to specify an additional network range to be added to a pool defined in an earlier network statement.
The format of the networkalso statement is:
where:
One gateway statement is required for each interface on the server. Specify the interface’s (primary) IP address and IP netmask. If this server is to serve dynamically-allocated IP addresses on that network associated with this interface, also specify the poolname(s) associated with that network. The poolname(s) are the same arbitrary name(s) specified in network statement(s) earlier.
One gateway statement is also required for every BootP Relay Agent which may forward client requests to the server. Specify the (primary) IP address and netmask corresponding to the relay agent’s interface on the network for which the agent is acting. If this server is to serve dynamically-allocated IP addresses on that IP network, also specify the poolname(s) associated with that network. A poolname is the same arbitrary name specified in a network statement earlier.
If a BootP Relay Agent is embedded in an IP router, it typically acts as a relay agent for the network on the far side of the router, from the point of view of the dhcpd(8) server. Therefore, you typically list the (primary) IP address and netmask of the IP router’s far interface, not its near one. If the router has additional physical interfaces configured to provide BootP Relay Agents, specify each in its own gateway statement.
Specify the ipaddress of the relay agent or server interface attached to the wire; this should be the device’s primary IP address, and should already appear in an earlier gateway statement. Specify the network and netmask describing the secondary IP network running on the wire. If additional IP networks run on the same wire, you may include additional network and netmask pairs, or specify each pair in its own proxy statement.
If the server is to serve dynamically-allocated IP addresses on a secondary network, specify the poolname(s) associated with the secondary network in the earlier gateway statement describing the relay agent or server interface. The poolname is the same arbitrary name specified in a network statement earlier.
Specify the ipaddress of a DHCP server operating on your internetwork. If there are multiple DHCP servers, specify each in a separate statement.
This statement is optional; if present, the server will attempt to log each time a client specifies a Server Identifier Option containing a value that is neither my_ip_addr nor one of those specified as a known_server_identifier. This may help alert you to rogue DHCP servers.
The server checks for a Server Identifier Option in DHCPREQUEST messages (when a client is SELECTING), DHCPRELEASE messages, and DHCPDECLINE messages. When the Server Identifier Option is specified in one of these messages, but is not equal to my_ip_addr, the server checks to see if you have specified any known_server_identifier values. If so, it checks to see if the Server Identifier Option matches one of those; if it matches none of them, the server logs it as an "unknown Server Identifier."
Since the server does not examine the known_server_identifier values when the Server Identifier Option matches my_ip_addr, you need not list your server’s own IP address as a known_server_identifier.
The known_server_identifier statement is optional; if you have none, the server skips the check; it will not log any "unknown Server Identifier."
This check is only used to provide you with some hint that there may be rogue DHCP servers operating on your network. It is possible for rogue DHCP servers to operate on your network and not be noticed by this check.
Note the statement does not allow you to declare a set of Server Identifier Option values that the server will consider equivalent to itself.
One or more arguments may be specified; each of the possible arguments enables Client Steering for a particular kind of response packet sent by the server.
The client_steering_enable_bootpreply_static argument specifies that Client Steering should be enabled for BOOTPREPLY packets that contain static IP addresses The client_steering_enable_bootpreply_dynamic argument specifies that Client Steering should be enabled for BOOTPREPLY packets that contain dynamic IP addresses. The client_steering_enable_dhcpoffer_static argument specifies that Client Steering should be enabled for DHCPOFFER packets that contain static IP addresses. The client_steering_enable_dhcpoffer_dynamic argument specifies that Client Steering should be enabled for DHCPOFFER packets that contain dynamic IP addresses.
The statement may appear more than once in the file; if it does, the arguments are concatenated.
The default behavior is for Client Steering to be disabled.
If Client Steering is enabled, the configuration file must also contain the client_steering_server_myself and client_steering_delay_secs statements.
If chaddr is specified, the bootp_chaddr (client hardware address) field is used. If clientid is specified, the DHCP Client Identifier option value is used. (If the packet contains no explicit DHCP Client Identifier option, the server synthesizes a DHCP Client Identifier value by concatenating the bootp_htype (hardware type) and bootp_chaddr (client hardware address) fields.
If left unspecified, client_steering_hash_source defaults to using clientid.
If popx31 is specified, the hash is computed using a general purpose hash function.
If lastbyte is specified, the hash is computed based on the last byte of the input string, ignoring the rest of the input string. That’s faster than the popx31 hash function. It’s only suitable to use when you believe the last byte of the input string will be uniformly distributed relative to the number of hash buckets, and the number of hash buckets is < 256. That’s typically true if you have decided to use the client’s chaddr as the client_steering_hash_source. It’s also typically true if you have decided to use the clientid as the client_steering_hash_source if you are also requiring the DHCP Client Identifier to match the bootp_htype concatenated with the bootp_chaddr. But for the more general case of arbitrary DHCP Client Identifier values, it is not true, so the lastbyte hash function is not appropriate to use in the more general case.
If left unspecified, client_steering_hash_source default to using popx31.
The value specified must be an integer in the range 1 through the number of values specified in the client_steering_delay_secs statements. In order to specify this value, the configuration file must also specify at least one client_steering_delay_secs value.
The value specified has no particular significance. It’s simply used to determine the position of this server in an ordered list of servers. You assign a different value to each server to allow the Client Steering feature to differentiate each server from the others.
For example, if you specified three values in the client_steering_delay_secs statement, then the client_steering_server_myself value should be 1 on one server, 2 on another server, and 3 on another server.
It is permissible to specify the same value on multiple servers (to cause multiple servers to make the same decisions with regard to the Client Steering feature).
One or more whitespace-separated values may be specified; each value is an integral number of seconds in the range 0 through 2^16-1. The statement may appear more than once; if it does, the values are concatendated as if they had all appeared in a single statement.
These values are only used when the Client Steering feature is enabled for the particular request packet the server is considering.
Based upon the value client_steering_server_myself and a client_steering_hashcode computed based on the client’s chaddr or DHCP Client Identifier, the server determines if it this client’s "most preferred" server, "second-most preferred server", "third-most preferred server", etc.
If the server is this client’s "most preferred" server, it will suppress any reply if the request’s bootp_secs field is less than seconds1. If the server is this client’s "second-most preferred" server, it will suppress any reply if the request’s bootp_secs field is less than seconds2. If the server is this client’s "third-most preferred" server, it will suppress any reply if the request’s bootp_secs field is less than seconds3, and so on.
The first value typically will be 0. You would normally specify the same set of values on all your servers.
For example, if you have three servers, you might specify the values: 0, 3, 6. IAMHERE
Specify:
where n is an positive integer (n < 2^32-1).
Specify:
where n is an positive integer (n < 2^32-1).
An example /etc/dhcpd.conf file follows:
# Sample dhcpd.conf file # Only check the bootptab file’s modification time (to learn if we need to re-read the file) # if more than 60 seconds have passed since the last time we actually read the bootptab file. readtabinterval 60 # Only check the configuration file’s modification time (to learn if we need to re-read the file) # if more than 60 seconds have passed since the last time we actually read the configuration file. readconfinterval 60 # flush lastbinding changes from cache to disk every 10 changes or 60 seconds, whichever comes first. flushitems 10 flushinterval 60 # reclaim expired bindings every 300 seconds gcinterval 300 # Before sending a DHCPOFFER containing a dynamically-allocated IP address, # how many times should we ping the IP address to verify it is not in-use? # Any response terminates the timeout and cancels any further tries. # Specifying 0 disables the ping attempt. # Default is 3. ping_offer_dynamic_tries 2 # When we perform each ping try specified by ping_offer_dynamic_tries, how long should we wait (at most) for a response # to each ping request? # Timeout is sum of ping_offer_dynamic_timeout_secs (seconds) + ping_offer_dynamic_timeout_us (microseconds). # Default is 0 seconds + 500000 microseconds (= 0.5 seconds). # Unused when ping_offer_dynamic_tries is 0. ping_offer_dynamic_timeout_secs 0 ping_offer_dynamic_timeout_us 400000 # delay DHCPOFFERs by 1000 microseconds (1 millisecond) delay_reply_dhcpoffer 1000 # report any Server Identifier Option values we see other than my_ip_addr and the following known DHCP servers known_server_identifier 192.120.245.1 known_server_identifier 192.120.245.2 # We serve dynamic IP addresses on four networks. # # On plaidnet we’ll serve both dhcp and bootp clients. The clients need not be in our bootptab. # The network is directly attached (no BootP Relay Agents every involved). network plaidnet 192.120.245.0 255.255.255.0 both # # Clients on scramblenet must be registered use dhcp to get a dynamic address. # There’s one relay agent involved. network scramblenet 128.112.192.0 255.255.252.0 dhcp|registered 128.112.192.7 255.255.252.0 # # Clients on foobar must use bootp and not appear in bootptab to get a dynamic address. # There are two bootp relay agents that may relay requests to us. network foobar 128.112.208.0 255.255.252.0 bootp|unregistered 128.112.208.1 255.255.252.0 128.112.210.36 255.255.252.0 # # Clients on gumby may use bootp or dhcp to get a dynamic address, but must appear in bootptab # with a :ro: tag. There’s just one bootp relay agent. network gumbynet 192.120.216.0 255.255.255.0 both|roaming 128.112.216.1 255.255.252.0 # # Clients behind 128.112.22.89 are served by several dynamic pools. # They must speak dhcp to get a dynamic address. # Those that do not appear in bootptab are served by both the flyers and walkers pools. # Those that are appear in bootptab without a :ro: tag are served by both the floaters and walkers pools. # Those that are appear in bootptab wit a :ro: tag are served by both the wanderers and walkers pools. # There’s only one bootp relay agent. network wanderers 128.112.20.0 255.255.255.0 dhcp|roaming 128.112.22.89 128.112.252.0 network floaters 128.112.21.0 255.255.255.0 dhcp|registered 128.112.22.89 128.112.252.0 network flyers 128.112.80.0 255.255.255.128 dhcp|unregistered 128.112.22.89 128.112.252.0 network walkers 128.112.84.0 255.255.255.0 dhcp 128.112.22.89 128.112.252.0 # Clients behind 10.17.0.9 are served by several dynamic pools. # They must speak dhcp to get a dynamic address. # Those that are appear in bootptab are served by the wallace pool. # The wallace pool contains IP address that fall into ranges: 10.17.0.0/24, 10.17.2.0/23, and 10.17.4.0/24. # Those that do not appear in bootptab are served by the gromit pool. # The gromit pool contains IP address that fall into the range: 10.17.1.0/24. network wallace 10.17.0.0 255.255.255.0 dhcp|registered 10.17.0.9 255.255.0.0 networkalso wallace 10.17.2.0 255.255.254.0 networkalso wallace 10.17.4.0 255.255.255.0 network gromit 10.17.1.0 255.255.255.0 dhcp|unregistered 10.17.0.9 255.255.0.0 # This server has two interfaces. # # the server is directly attached to network 192.120.245.0 and serves dynamic addresses on it gateway 192.120.245.117 255.255.255.0 plaidnet # # the server is directly attached to network 192.120.240.0 # network 192.120.253.0/255.255.255.128 runs on the same wire # we do not serve dynamic addresses on either network gateway 192.120.240.12 255.255.255.0 proxy 192.120.240.12 192.120.253.0 255.255.255.128 # Describe all the Bootp Relay Agents that may relay requests to this server. # # there is one relay agent for network 128.112.192.0 and we serve dynamic addresses for that network gateway 128.112.192.7 255.255.252.0 scramblenet # # there two relay agents for network 128.112.208.0, we serve dynamic addresses for that network gateway 128.112.208.1 255.255.252.0 foobar gateway 128.112.210.36 255.255.252.0 foobar # # there is one relay agent for network 128.112.112.0, we do not serve dynamic addresses on it gateway 128.112.112.1 255.255.252.0 # # there are two relay agents for network 140.180.128.0, and we do not serve dynamic addresses on it gateway 140.180.128.1 255.255.192.0 gateway 140.180.163.3 255.255.192.0 # # there is one relay agent for network 128.112.216.0, and we serve dynamic addresses on it gateway 128.112.216.1 255.255.252.0 gumbynet # # there is one relay agent for network 128.112.16.0 # the same wire runs three secondary IP networks (128.112.17.0, 128.112.18.0, and 140.180.128.0) gateway 128.112.16.32 255.255.255.0 proxy 128.112.16.32 128.112.17.0 255.255.255.0 proxy 128.112.16.32 128.112.18.0 255.255.255.0 proxy 128.112.16.32 140.180.128.0 255.255.192.0 # the three previous statements could also be written as follows: # proxy 128.112.16.32 128.112.17.0 255.255.255.0 128.112.18.0 255.255.255.0 140.180.128.0 255.255.192.0 # # there is one relay agent for network 128.112.20.0 # the same wire runs two secondary IP networks (128.112.80.0 and 128.112.84.0) # we serve dynamic IP addresses on the networks. gateway 128.112.22.89 255.255.252.0 wanderers floaters flyers walkers proxy 128.112.22.89 128.112.80.0 255.255.255.128 proxy 128.112.22.89 128.112.84.0 255.255.255.0 # # There is one relay agent for network 10.17.0.0, and we serve dynamic addresses on it gateway 10.17.0.9 255.255.0.0 wallace gromit # Enable Client Steering for DHCPOFFER packets containing dynamic IP addresses client_steering_enable client_steering_enable_dhcpoffer_dynamic # # Specify the threshholds used by the Client Steering feature, if it is enabled. # # If we are the client’s most preferred server, we will respond when bootp_secs >= 0 (seconds). # If we are the client’s second-most preferred server, we will respond when bootp_secs >= 3 (seconds). # If we the client’s third-most preferred server, we will respond when bootp_secs >= 6 (seconds). client_steering_delay_secs 0 3 6 # Assign a server number to myself for use by the Client Steering feature, if it is enabled. client_steering_server_myself 2
Each line is limited to 1024 characters, and the maximum number of tokens per line is 256.
Some of the information in the network and gateway statements is repetitious.
Internet Requests for Comments:
Internet Engineering Task Force draft documents are listed at the official IETF DHCP Working Group page: http://www.ietf.org/html.charters/dhc-charter.html
Additional DHCP resources are at: http://www.dhcp.org/