Table of Contents

Name

dhcpd.conf - configuration file for dhcpd (BootP and DHCP server)

Synposis

/etc/dhcpd.conf

Description

The file /etc/dhcpd.conf contains configuration information used by the BootP and DHCP server, dhcpd(8).

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:

readconfinterval

The readconfinterval statement is optional, and may be used to reduce the frequency at which dhcpd(8) checks the dhcpd.conf(5) file for changes.

Specify

readconfinterval
n

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.

readtabinterval

The readtabinterval statement is optional, and may be used to reduce the frequency at which dhcpd(8) checks the bootptab(5) file for changes.

Specify

readtabinterval
n

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.

delay_reply_dhcpoffer, delay_reply_dhcpack, delay_reply_dhcpnak, delay_reply_bootpreply, delay_reply_default

These statements are optional, and may be used to cause the server to add a delay before sending BOOTPREPLY, DHCPOFFER, DHCPACK, and DHCPNAK packets.

Specify:

delay_reply_dhcpoffer
n
delay_reply_dhcpack
n
delay_reply_dhcpnak
n
delay_reply_bootpreply
n
delay_reply_default
n

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.

flushitems, flushinterval

The flushitems and flushinterval statements are each optional, and may be used to change the frequency at which dhcpd(8) flushes lastbinding changes from memory to disk.

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:

flushitems
n

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:

flushinterval
n

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.

gcinterval

The gcinterval statement is optional, and may be used to change the frequency at which dhcpd(8) examines the current bindings in memory to locate those that have expired. During garbage collection, expired bindings are deleted, and any associated dynamically-assigned IP addresses are returned to the pools of IP addresses available for dynamic assignment. By default, garbage collection is performed every 30 seconds. You may wish to increase this; a value of 300 seconds is not unreasonable.

Specify:

gcinterval
n

where n is an integer (n < 2^32-1) specifying the number of seconds that should elapse between garbage collections.

expire_infinite_dynamics

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:

expire_infinite_dynamics
n

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.)

network

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:

network
poolname netnumber netmask accessflags relayagentipaddress relayagentnetmask [ relayagentipaddress relayagentnetmask ]...

where:

poolname
The poolname is an arbitrary name you associate with this network. The name you choose is unimportant, but each poolname must be unique. The poolname will be used again in the gateway statement, and optionally in networkalso statements, later in this dhcpd.conf file.
netnumber netmask
The netnumber and netmask represent the range of this pool. All of the IP address in bootptab(5) that fall within this range and have the :dy: flag set will be placed into this pool. The range you specify must not overlap the range specified in any other network or networkalso statement in your dhcpd.conf(5) file; such an error will not be detected, and will lead to problems. As the range you specify only defines the boundaries of the pool, rather than an actual IP network, it is valid to specify a range smaller than an actual IP network; that permits you to use multiple network statements to define multiple (non-overlapping) pools (e.g. perhaps with different accessflags) which lie on the same IP network. If you need to specify multiple (non-overlapping) ranges for a single pool, specify the first in a network statement, and specify each additional (non-overlapping) range in its own networkalso statement.
accessflags
The accessflags is a string consisting of one or more of the following words, separated by vertical bars:
bootp,dhcp, or both
Exactly one of these words must be specified. Specify bootp if dynamic IP addresses in this pool may be assigned only to BootP clients. Specify dhcp if dynamic IP addresses in this pool may be assigned only to DHCP clients. Specify both if dynamic IP addresses in this pool may be assigned to both BootP and DHCP clients.
registered or roaming or unregistered
Zero or one of these words may be specified.
Specify
registered if dynamic IP addresses in this pool should only be assigned to clients who appear somewhere in the bootptab(5) file. If registered is specified, before assigning a dynamic IP address in this pool to a client, the server looks for the Client Identifier in the bootptab(5) file; if it appears in any entry (regardless of whether that entry specifies a static IP address), the client is considered to be "registered," and may be assigned a dynamic IP address fro this pool. If the Client Identifier is not found in any entry, no dynamic IP address from this pool will be assigned to this client.
Specify
unregistered if dynamic IP addresses from this pool should only be assigned to clients who which do not appear somewhere in the bootptab(5) file. If unregistered is specified, before assigning a dynamic IP address from this pool to a client, the server looks for the Client Identifier in the bootptab(5) file; if it appears in any entry (regardless of whether that entry specifies a static IP address), the client is considered to be "registered," and may not be assigned a dynamic IP address from this pool.
Specify
roaming if dynamic IP addresses from this pool may only be assigned to those clients who not only appear in the the bootptab(5), but also have the boolean :ro: (roaming) tag specified in the entry.
Specify none of
registered, unregistered nor roaming if dynamic IP addresses from this pool may be assigned to a client regardless of whether or not the client appears in the bootptab (or contains a :ro: tag in its bootptab entry).
relayagentipaddress relayagentnetmask
If requests from clients using this pool may traverse a BootP Relay Agent to reach this server, specify that relay agent’s IP address and netmask. If there are multiple relay agents (the client’s request packet may traverse any one of several BootP Relay Agents) specify additional relayagentipaddress relayagentnetmask pairs. Otherwise, if the pool is used on a network that is directly attached to one of this server’s interfaces (so that requests from clients using this pool do not traverse a BootP Relay Agent to reach the server) then specify the (primary) IP address (and associated) netmask of the server’s own interface that will receive those requests; pretend the server is a BootP Relay Agent for the purpose of this statement.

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.

networkalso

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:

networkalso
poolname netnumber netmask

where:

poolname
The poolname must be one that was defined in an earlier network statement.
netnumber netmask
The netnumber and netmask represent an additional range for this pool. All of the IP address in bootptab(5) that fall within this range and have the :dy: flag set will be added to this pool. The range you specify must not overlap the range specified in any other network or networkalso statement in your dhcpd.conf(5) file; such an error will not be detected, and will lead to problems. You may specify more than one networkalso statement for a particular poolname; each will add an additional range of dynamic IP addresses to that pool. All the additional ranges you specify for a given poolname are governed by the same set of accessflags, relayagentipaddress, and relayagentnetmask values specified in the original network statement.

gateway

The gateway statement is used to describe each BootP Relay Agent on the network, as well as the server’s own interfaces. The format is:
gateway
ipaddress netmask [ poolname ]...

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.

proxy

The proxy statement is used to describe secondary IP networks that share a wire with an IP network served by a previously-defined relay agent or server interface. The format is:
proxy
ipaddress network netmask [ network netmask ]...

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.

known_server_identifier

The known_server_identifier statement is optionally used to describe each DHCP Server on the network. The format is:
known_server_identifier
ipaddress

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.

client_steering_enable

The client_steering_enable statement is used to enable the Client Steering feature. The format is
client_steering_enable [client_steering_enable_bootpreply_static] [client_steering_enable_bootpreply_dynamic] [client_steering_enable_dhcpoffer_static] [client_steering_enable_dhcpoffer_dynamic]

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.

client_steering_hash_source

The client_steering_hash_source statement is used to specify what data source should be used to compute the Client Steering Hashcode. Its value is unused when Client Steering is disabled. The format is:
client_steering_hash_source [ chaddr | clientid ]

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.

client_steering_hash_function

The client_steering_hash_function statement is used to specify which hash function should be used to compute the Client Steering Hashcode. The format is:
client_steering_hash_source [ popx31 | lastbyte ]

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.

client_steering_server_myself

The client_steering_server_myself statement is used to assign a server number for this server for use by the Client Steering feature. Its value is unused when Client Steering is disabled. The format is:
client_steering_server_myself
server_number

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).

client_steering_delay_secs

The client_steering_delay_secs statement is used to specify the numbers of seconds that the Client Steering feature should use as thresholds when deciding if it should respond to a client. Its value is unused when Client Steering is disabled. The format is:
client_steering_delay_secs
seconds1 [ seconds2 [ seconds3 ]... ]

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

ping_offer_dynamic_tries

The ping_offer_dynamic_tries statement is optional, and may be used to change the number of times dhcpd(8) pings a dynamically-assigned IP address to verify the IP address is not in use before sending a DHCPOFFER containing that IP address. By default, this value is 3. To disable the ping entirely, specify 0.

Specify:

ping_offer_dynamic_tries
n

where n is an positive integer (n < 2^32-1).

ping_offer_dynamic_timeout_secs, ping_offer_dynamic_timeout_us

The ping_offer_dynamic_timeout_secs and ping_offer_dynamic_timeout_us statements are optional, and may be used to change the timeout dhcpd(8) uses when performing each ping specified by ping_offer_dynamic_tries. ping_offer_dynamic_timeout_secs specifies a number of seconds, and ping_offer_dynamic_timeout_us specifies a number of microseconds. The timeout is the sum of the two values. By default, ping_offer_dynamic_timeout_secs is 0 and ping_offer_dynamic_timeout_us is 500000 so the default timeout is 0.5 seconds. These values are not used when ping_offer_dynamic_tries is 0.

Specify:

ping_offer_dynamic_timeout_secs
n
ping_offer_dynamic_timeout_us
n

where n is an positive integer (n < 2^32-1).

Examples

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

Bugs

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.

Files

/etc/dhcpd.conf

See Also

dhcpd(8), bootptab(5), dhcp-bindings-tool(8).

Internet Requests for Comments:

RFC2132
DHCP Options and BootP Vendor Extensions
RFC951
Bootstrap Protocol
RFC1534
Interoption Between DHCP and BootP
RFC1542
Clarifications and Extensions for the Bootstrap Protocol
RFC1700
Assigned Numbers
RFC2131
Dynamic Host Configuration Protocol
RFC2241
DHCP Options for Novell Directory Services
RFC2242
NetWare/IP Domain Name and Information
RFC2485
DHCP Option for The Open Group’s User Authentication Protocol
RFC2610
DHCP Options for Service Location Protocol
RFC2937
The Name Service Search Option for DHCP
RFC2939
Procedure and IANA Guidelines for Definition of New DHCP Options and Message Types
RFC3004
The User Class Option for DHCP
RFC3011
The IPv4 Subnet Selection Option for DHCP
RFC3046
DHCP Relay Agent Information Option
RFC3942
Reclassifying DHCPv4 Options

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/


Table of Contents