Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
centos:dhcp_c7 [11.02.2016 11:20. ] – [IPv4] django | centos:dhcp_c7 [28.12.2022 08:40. ] (aktuell) – [DHCP-Adressvergabe] django | ||
---|---|---|---|
Zeile 39: | Zeile 39: | ||
Sep 12 21:34:12 nss dhcpd: DHCPACK on 192.168.10.61 to 00: | Sep 12 21:34:12 nss dhcpd: DHCPACK on 192.168.10.61 to 00: | ||
Der gesamte erfolgreiche Ablauf aus Sicht des DHCP-Servers entspricht folgendem Diagramm. | Der gesamte erfolgreiche Ablauf aus Sicht des DHCP-Servers entspricht folgendem Diagramm. | ||
- | < | + | <uml> |
title erfolgreiche Ablauf aus Sicht des DHCP-Servers\n | title erfolgreiche Ablauf aus Sicht des DHCP-Servers\n | ||
- | skin BlueModern | + | |
participant " | participant " | ||
participant " | participant " | ||
Zeile 155: | Zeile 155: | ||
# man 5 dhcpd.conf | # man 5 dhcpd.conf | ||
- | < | + | < |
+ | |||
NAME | NAME | ||
Zeile 161: | Zeile 163: | ||
DESCRIPTION | DESCRIPTION | ||
- | The dhcpd.conf file contains configuration information for dhcpd, the Internet Systems | + | |
+ | | ||
- | | + | The dhcpd.conf file is a free-form ASCII text file. |
- | dhcpd. | + | parser |
- | insensitive. | + | Keywords in the file are case-insensitive. |
- | character and end at the end of the line. | + | (except within quotes). |
- | The file essentially consists of a list of statements. | + | |
- | declarations. | + | |
- | | + | |
- | (e.g., should dhcpd provide addresses to unknown clients), or what parameters to provide to the client (e.g., | + | to do something (e.g., should dhcpd provide addresses to unknown clients), or what parameters to |
- | gateway 220.177.244.7). | + | provide to the client (e.g., use gateway 220.177.244.7). |
- | | + | |
- | addresses that can be assigned to clients, or to apply a group of parameters to a group of declarations. | + | work, to provide addresses that can be assigned to clients, or to apply a group of parameters to |
- | group of parameters | + | a group of declarations. |
- | those parameters may be specified. | + | specified before any declarations which depend on those parameters may be specified. |
- | | + | |
- | | + | clients on a subnet |
- | clients with statically assigned addresses, or for installations | + | within the subnet declaration. |
- | such client | + | |
- | not related strictly on a per-subnet basis, the group declaration can be used. | + | If parameters |
+ | per-subnet basis, the group declaration can be used. | ||
- | For every subnet which will be served, and for every subnet to which the dhcp server is connected, there must be | + | For every subnet which will be served, and for every subnet to which the dhcp server |
- | one subnet | + | |
- | | + | is on that subnet. |
+ | be dynamically allocated on that subnet. | ||
- | Some installations have physical networks on which more than one IP subnet operates. | + | |
- | site-wide | + | ple, if there is a site-wide requirement that 8-bit subnet masks be used, but a department |
- | expands to the point where it has more than 254 nodes, it may be necessary to run two 8-bit subnets | + | a single physical ethernet network expands to the point where it has more than 254 nodes, it may |
- | ethernet | + | be necessary to run two 8-bit subnets on the same ethernet until such time as a new physical |
- | two networks must be enclosed in a shared-network declaration. | + | network |
+ | enclosed in a shared-network declaration. | ||
- | Note that even when the shared-network declaration is absent, an empty one is created by the server to contain the | + | Note that even when the shared-network declaration is absent, an empty one is created |
- | subnet | + | server |
- | DHCP clients, which are not tied to addresses (and therefore | + | purposes, this means that " |
- | stateful ones. | + | |
- | Some sites may have departments which have clients on more than one subnet, but it may be desirable | + | Some sites may have departments which have clients on more than one subnet, but it may be desir‐ |
- | clients a uniform set of parameters which are different than what would be offered to clients from other | + | |
- | | + | offered |
- | | + | declared explicitly with host declarations, |
- | clients | + | |
- | to group parameter assignments based on information the client sends. | + | addresses will be dynamically assigned, class declarations and conditional declarations |
+ | used to group parameter assignments based on information the client sends. | ||
- | When a client is to be booted, its boot parameters are determined by consulting that client' | + | |
- | any), and then consulting any class declarations matching the client, | + | host declaration (if any), and then consulting any class declarations matching the client, |
- | | + | |
- | lexical | + | client. |
- | tions. Scopes are never considered twice, and if parameters are declared in more than one scope, | + | at less specific lexical scopes are also consulted for client option |
+ | never considered twice, and if parameters are declared in more than one scope, | ||
| | ||
- | When dhcpd tries to find a host declaration for a client, it first looks for a host declaration which has a fixed- | + | |
- | address declaration that lists an IP address that is valid for the subnet or shared network on which the client is | + | which has a fixed-address declaration that lists an IP address that is valid for the subnet |
- | booting. | + | shared |
+ | find an entry which has no fixed-address declaration. | ||
EXAMPLES | EXAMPLES | ||
Zeile 252: | Zeile 261: | ||
} | } | ||
- | | + | Figure 1 |
- | | + | |
- | organization' | + | things |
- | so on. So, for example: | + | |
option domain-name " | option domain-name " | ||
option domain-name-servers ns1.isc.org, | option domain-name-servers ns1.isc.org, | ||
- | | + | Figure 2 |
- | | + | As you can see in Figure 2, you can specify host addresses |
- | their numeric IP addresses. | + | names rather than their numeric IP addresses. |
- | has two ethernet interfaces), | + | address (for example, if that host has two ethernet |
+ | addresses are supplied to the client. | ||
- | | + | |
- | sity, has its own router. | + | subnet, of necessity, has its own router. |
+ | something like: | ||
option routers 204.254.239.1; | option routers 204.254.239.1; | ||
- | Note that the address here is specified numerically. | + | |
- | | + | ferent domain name for each interface on your router, |
- | the numeric address. | + | domain name for that interface instead of the numeric address. |
- | and it would not be appropriate to use that name here. | + | be only one domain name for all of a router' |
+ | use that name here. | ||
- | | + | In Figure 1 there is also a group statement, which provides common parameters for a set of three |
- | beppo and harpo. | + | hosts - zappo, beppo and harpo. |
- | group-specific parameter to override the domain name supplied to these hosts: | + | so it might make sense for a group-specific parameter to override the domain name supplied to |
+ | these hosts: | ||
option domain-name " | option domain-name " | ||
- | Also, given the domain they' | + | Also, given the domain they' |
- | nism, we might set the lease timeout somewhat shorter than the default: | + | DHCP leasing mechanism, we might set the lease timeout somewhat shorter than the default: |
max-lease-time 120; | max-lease-time 120; | ||
default-lease-time 120; | default-lease-time 120; | ||
- | You may have noticed that while some parameters start with the option keyword, some do not. Parameters | + | |
- | with the option keyword correspond to actual DHCP options, while parameters that do not start with the option | + | Parameters starting |
- | | + | that do not start with the option |
- | client parameters that are not optional in the DHCP protocol (for example, server-name and filename). | + | how long a lease dhcpd will give out), or specify client parameters that are not optional in the |
+ | DHCP protocol (for example, server-name and filename). | ||
- | | + | |
- | name of a file to upload (the filename parameter) and the address of the server from which to upload the file (the | + | hostname option, the name of a file to upload (the filename parameter) and the address |
- | next-server | + | server from which to upload the file (the next-server parameter). |
- | applied according to the scope in which the parameter appears. | + | appear anywhere that parameters are allowed, and will be applied according to the scope in which |
+ | the parameter appears. | ||
- | | + | |
- | want to specify | + | of models, and you want to specify the boot files for each model. |
- | server and group them by model: | + | to have host declarations for each server and group them by model: |
group { | group { | ||
Zeile 330: | Zeile 346: | ||
ADDRESS POOLS | ADDRESS POOLS | ||
- | The pool declaration can be used to specify a pool of addresses that will be treated differently than another pool | + | The pool declaration can be used to specify a pool of addresses that will be treated differently |
- | of addresses, | + | than another pool of addresses, even on the same network segment or subnet. |
- | addresses that can be assigned to DHCP clients that are registered | + | may want to provide a large set of addresses that can be assigned to DHCP clients that are reg‐ |
- | set of addresses, | + | |
- | wall, you may be able to arrange for addresses from one pool to be allowed access to the Internet, while addresses | + | lease times, that are available for unknown clients. |
- | in | + | arrange for addresses from one pool to be allowed access to the Internet, |
- | pair of pool declarations: | + | |
+ | would set up a pair of pool declarations: | ||
| | ||
Zeile 358: | Zeile 375: | ||
} | } | ||
- | It is also possible to set up entirely different subnets for known and unknown clients - address | + | It is also possible to set up entirely different subnets for known and unknown clients - address |
- | the level of shared networks, so address ranges within pool declarations can be on different subnets. | + | pools exist at the level of shared networks, so address ranges within pool declarations can be |
+ | on different subnets. | ||
- | As you can see in the preceding example, pools can have permit lists that control which clients are allowed access | + | As you can see in the preceding example, pools can have permit lists that control which clients |
- | to the pool and which aren' | + | are allowed |
- | If a pool has a permit list, then only those clients that match specific entries on the permit list will be eligi‐ | + | |
- | | + | match specific |
- | any entries on the deny list will be eligible. | + | pool. If a pool has a deny list, then only those clients that do not match any entries |
+ | deny list will be eligible. | ||
that match the permit list and do not match the deny list will be allowed access. | that match the permit list and do not match the deny list will be allowed access. | ||
DYNAMIC ADDRESS ALLOCATION | DYNAMIC ADDRESS ALLOCATION | ||
- | | + | |
- | If the client thinks it has a valid lease and sends a DHCPREQUEST to initiate | + | DHCPDISCOVER message. |
- | only three choices - it can ignore the DHCPREQUEST, | + | |
- | address, or send a DHCPACK, telling the client to go ahead and use the address for a while. | + | send a DHCPNAK to tell the client it should stop using the address, or send a DHCPACK, telling |
+ | the client to go ahead and use the address for a while. | ||
- | | + | If the server finds the address the client is requesting, and that address is available |
- | will send a DHCPACK. | + | client, |
- | will send a DHCPNAK. | + | isn't permitted to have it, the server will send a DHCPNAK. |
- | incorrect for the network segment to which the client has been attached and the server is authoritative | + | the address, |
- | network segment, in which case the server will send a DHCPNAK even though it doesn' | + | which the client has been attached and the server is authoritative for that network segment, |
+ | which case the server will send a DHCPNAK even though it doesn' | ||
- | | + | |
- | address declaration that lists an IP address that is valid for the network | + | contains a fixed-address declaration that lists an IP address that is valid for the network |
- | | + | |
- | required to take the address specified in the host declaration. | + | address allocation. |
- | address, the server will respond with a DHCPNAK. | + | host declaration. |
+ | respond with a DHCPNAK. | ||
- | | + | When the DHCP server allocates a new address for a client (remember, this only happens |
- | DHCPDISCOVER), | + | client |
- | old IP address | + | on an IP address, or if there is an old IP address the client had before that hasn' |
- | address and check it to see if the client is still permitted to use it. If the client is no longer | + | reassigned. |
- | use it, the lease is freed if the server thought it was still in use - the fact that the client has sent a | + | is still permitted to use it. If the client is no longer permitted |
- | DHCPDISCOVER | + | freed if the server thought it was still in use - the fact that the client has sent a DHCPDIS‐ |
+ | COVER proves to the server that the client is no longer using the lease. | ||
- | If no existing lease is found, or if the client is forbidden to receive the existing lease, then the server | + | If no existing lease is found, or if the client is forbidden to receive the existing lease, then |
- | look in the list of address pools for the network segment to which the client is attached for a lease that is not | + | the server will look in the list of address pools for the network segment to which the client is |
- | in use and that the client is permitted to have. It looks through each pool declaration in sequence | + | attached for a lease that is not in use and that the client is permitted |
- | declarations that appear outside of pool declarations are grouped into a single pool with no permit list). | + | through |
- | permit list for the pool allows the client to be allocated an address from that pool, the pool is examined to see | + | declarations are grouped into a single pool with no permit list). |
- | if | + | pool allows the client to be allocated an address from that pool, the pool is examined to see if |
- | next pool is tested. | + | there is an address available. |
- | client. | + | Otherwise, |
+ | client, no response is sent to the client. | ||
- | | + | If an address is found that the client is permitted to have, and that has never been assigned to |
- | | + | any client |
- | been previously | + | |
- | has never before been assigned to a client. | + | looking in hopes of finding an address that has never before been assigned to a client. |
- | The DHCP server generates the list of available IP addresses from a hash table. | + | The DHCP server generates the list of available IP addresses from a hash table. |
- | not sorted | + | the addresses are not sorted in any particular order, and so it is not possible to predict |
- | allocate IP addresses. | + | order in which the DHCP server will allocate IP addresses. |
- | server | + | ISC DHCP server may have become accustomed to the DHCP server allocating IP addresses in ascend‐ |
- | | + | |
+ | version 3 of the ISC DHCP server. | ||
IP ADDRESS CONFLICT PREVENTION | IP ADDRESS CONFLICT PREVENTION | ||
- | The DHCP server checks IP addresses to see if they are in use before allocating them to clients. | + | The DHCP server checks IP addresses to see if they are in use before allocating them to clients. |
- | sending | + | |
- | a second, the address is assumed to be free. This is only done for leases | + | ICMP Echo reply is received within a second, the address is assumed to be free. |
- | statements, | + | done for leases that have been specified in range statements, and only when the lease is thought |
- | failover peer has not listed the lease as in use. | + | by the DHCP server to be free - i.e., the DHCP server or its failover peer has not listed |
+ | lease as in use. | ||
- | If a response is received to an ICMP Echo request, the DHCP server assumes that there is a configuration | + | |
- | | + | figuration error - the IP address is in use by some host on the network |
- | doned, and will not assign it to clients. | + | client. |
- | If a DHCP client tries to get an IP address, but none are available, but there are abandoned | + | |
- | the DHCP server will attempt to reclaim an abandoned IP address. | + | addresses, then the DHCP server will attempt to reclaim an abandoned IP address. |
- | the same ICMP Echo request check described previously. | + | IP address |
- | address is assigned to the client. | + | there is no answer to the ICMP Echo request, the address is assigned to the client. |
- | The DHCP server does not cycle through abandoned IP addresses if the first IP address it tries to reclaim is free. | + | The DHCP server does not cycle through abandoned IP addresses if the first IP address |
- | Rather, when the next DHCPDISCOVER comes in from the client, it will attempt | + | to reclaim |
- | method described here, and will typically try a new IP address. | + | attempt a new allocation using the same method described here, and will typically try a new IP |
+ | address. | ||
DHCP FAILOVER | DHCP FAILOVER | ||
- | | + | |
- | failover-12.txt. | + | ietf-dhc-failover-12.txt. |
- | vendors' | + | |
- | dard. If you wish to use the failover protocol, make sure that both failover peers are running the same version | + | that this implementation conforms to the standard. If you wish to use the failover |
- | of the ISC DHCP server. | + | make sure that both failover peers are running the same version of the ISC DHCP server. |
- | | + | |
- | will have about half of the available IP addresses in the pool at any given time for allocation. | + | pool. Each server will have about half of the available IP addresses in the pool at any given |
- | fails, | + | time for allocation. |
- | roughly half of available addresses that it had when communications with the other server were lost. | + | the pool, and will allocate new addresses out of the roughly half of available addresses that it |
+ | had when communications with the other server were lost. | ||
- | It is possible during a prolonged failure to tell the remaining server that the other server | + | |
- | case the remaining | + | down, in which case the remaining server will (over time) reclaim all the addresses |
- | tion, and begin to reuse them. This is called putting the server into the PARTNER-DOWN state. | + | server had available for allocation, and begin to reuse them. This is called putting the server |
+ | into the PARTNER-DOWN state. | ||
- | You can put the server into the PARTNER-DOWN state either by using the omshell (1) command | + | You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by |
- | server, editing the last failover state declaration in the lease file, and restarting | + | stopping the server, editing the last failover state declaration in the lease file, and restart‐ |
- | last method, change the "my state" line to: | + | |
| | ||
Zeile 460: | Zeile 489: | ||
It is only required to change "my state" as shown above. | It is only required to change "my state" as shown above. | ||
- | When the other server comes back online, it should automatically detect that it has been offline | + | When the other server comes back online, it should automatically detect that it has been offline |
- | complete update from the server that was running in the PARTNER-DOWN state, and then both servers will resume | + | and request |
- | | + | then both servers will resume |
- | It is possible to get into a dangerous situation: if you put one server into the PARTNER-DOWN | + | It is possible to get into a dangerous situation: if you put one server |
- | *that* | + | state, |
- | was in the PARTNER-DOWN state, and may issue addresses | + | will not know that the first server was in the PARTNER-DOWN state, and may issue addresses |
- | resulting in IP address conflicts. | + | |
- | other server will not restart automatically. | + | Before putting a server into PARTNER-DOWN state, therefore, make sure that the other server will |
+ | not restart automatically. | ||
- | The failover protocol defines a primary server role and a secondary server role. There are some differences | + | The failover protocol defines a primary server role and a secondary server role. There are some |
- | how primaries | + | differences in how primaries and secondaries act, but most of the differences simply have to do |
- | peer to behave in the opposite way from the other. | + | with providing a way for each peer to behave in the opposite way from the other. |
- | must be configured as secondary, and it doesn' | + | must be configured as primary, and the other must be configured as secondary, |
+ | matter too much which one is which. | ||
FAILOVER STARTUP | FAILOVER STARTUP | ||
- | When a server starts that has not previously communicated with its failover peer, it must establish communications | + | When a server starts that has not previously communicated with its failover peer, it must estab‐ |
- | with its failover peer and synchronize with it before it can serve clients. | + | lish communications |
- | have just configured | + | This can happen |
- | servers has failed catastrophically and lost its database. | + | for the first time, or because one of your failover servers has failed catastrophically and lost |
+ | its database. | ||
- | The initial recovery process is designed to ensure that when one failover peer loses its database and then resyn‐ | + | |
- | chronizes, any leases | + | base and then resynchronizes, any leases that the failed server gave out before it failed |
- | starts up, it notices that it has no saved failover state, and attempts to contact its peer. | + | be honored. |
+ | and attempts to contact its peer. | ||
- | When it has established contact, it asks the peer for a complete copy its peer's lease database. | + | When it has established contact, it asks the peer for a complete copy its peer's lease database. |
- | sends its complete database, and sends a message indicating that it is done. The failed server then waits until | + | The peer then sends its complete database, and sends a message indicating that it is done. The |
- | MCLT has passed, and once MCLT has passed both servers make the transition back into normal operation. | + | failed server then waits until MCLT has passed, and once MCLT has passed both servers |
- | | + | transition |
- | have expired. | + | server may have given out while out of contact with its partner will have expired. |
- | While the failed server is recovering, its partner remains in the partner-down state, which means that it is serv‐ | + | While the failed server is recovering, its partner remains |
- | | + | means that it is |
- | into normal operation. | + | clients until it has made the transition into normal operation. |
- | In the case where both servers detect that they have never before communicated with their partner, they both come | + | In the case where both servers detect that they have never before communicated with their |
- | up in this recovery state and follow the procedure we have just described. | + | ner, they |
- | | + | In this case, no service will be provided |
CONFIGURING FAILOVER | CONFIGURING FAILOVER | ||
- | In order to configure failover, you need to write a peer declaration that configures | + | In order to configure failover, you need to write a peer declaration |
- | you need to write peer references in each pool declaration for which you want to do failover. | + | failover |
- | do failover for all pools on a given network segment. | + | want to do failover. |
- | | + | You must not tell one server it's doing failover on a particular |
- | not doing failover. | + | it is not. You must not have any common address pools on which you are not doing failover. |
+ | pool declaration that utilizes failover would look like this: | ||
pool { | pool { | ||
Zeile 511: | Zeile 545: | ||
}; | }; | ||
- | | + | |
- | are using failover for. | + | in pools that you are using failover for. |
- | | + | |
- | odd ways. I would recommend therefore that you either do failover or don't do failover, but don't do any mixed | + | will just fail in odd ways. I would recommend therefore that you either do failover or don't |
- | pools. | + | do failover, but don't do any mixed pools. |
- | | + | both |
- | | + | the master file. This will help you to avoid configuration |
- | primary | + | evolves, |
+ | mary server might look like this: | ||
| | ||
Zeile 542: | Zeile 577: | ||
[ primary | secondary ]; | [ primary | secondary ]; | ||
- | This determines whether the server is primary or secondary, as described earlier under DHCP FAILOVER. | + | This determines whether the server is primary or secondary, as described |
+ | FAILOVER. | ||
The address statement | The address statement | ||
Zeile 548: | Zeile 584: | ||
| | ||
- | The address statement declares the IP address or DNS name on which the server should listen for connections from | + | |
- | its failover | + | for connections from its failover peer, and also the value to use for the DHCP Failover |
- | value is used as an identifier, it may not be omitted. | + | |
The peer address statement | The peer address statement | ||
peer address address; | peer address address; | ||
- | The peer address statement declares the IP address or DNS name to which the server should | + | The peer address statement declares the IP address or DNS name to which the server should |
- | failover peer for failover messages. | + | |
The port statement | The port statement | ||
Zeile 562: | Zeile 599: | ||
port port-number; | port port-number; | ||
- | | + | The port statement declares the TCP port on which the server |
- | peer. This statement may be omitted, in which case the IANA assigned port number 647 will be used by default. | + | from its failover peer. This statement may be omitted, in which case the IANA assigned port |
+ | number 647 will be used by default. | ||
The peer port statement | The peer port statement | ||
Zeile 569: | Zeile 607: | ||
peer port port-number; | peer port port-number; | ||
- | The peer port statement declares the TCP port to which the server should connect to reach its failover peer for | + | The peer port statement declares the TCP port to which the server should connect to reach its |
- | | + | failover |
- | by default. | + | assigned port number 647 will be used by default. |
The max-response-delay statement | The max-response-delay statement | ||
Zeile 577: | Zeile 615: | ||
| | ||
- | The max-response-delay statement tells the DHCP server how many seconds may pass without | + | The max-response-delay statement tells the DHCP server |
- | from its failover peer before it assumes that connection has failed. | + | receiving a message from its failover peer before it assumes that connection has failed. |
- | transient network failure that breaks the connection will not result in the servers being out of communication | + | number should be small enough that a transient network failure that breaks the connection will |
- | for a long time, but large enough that the server isn't constantly making and breaking connections. | + | not result |
- | eter must be specified. | + | the server isn't constantly making and breaking connections. |
+ | fied. | ||
The max-unacked-updates statement | The max-unacked-updates statement | ||
| | ||
- | The max-unacked-updates statement tells the remote DHCP server how many BNDUPD messages it can send before | + | |
- | receives | + | The max-unacked-updates statement tells the remote DHCP server how many BNDUPD messages it can |
- | for this is, but 10 seems to work. This parameter must be specified. | + | send before it receives a BNDACK from the local system. |
+ | experience to say what a good value for this is, but 10 seems to work. This parameter must be | ||
+ | specified. | ||
The mclt statement | The mclt statement | ||
Zeile 594: | Zeile 635: | ||
mclt seconds; | mclt seconds; | ||
- | The mclt statement defines the Maximum Client Lead Time. It must be specified on the primary, and may not be | + | The mclt statement defines the Maximum Client Lead Time. It must be specified on the primary, |
- | specified on the secondary. | + | and may not be specified on the secondary. |
- | without contacting the other. | + | be renewed by either failover peer without contacting the other. |
- | recover | + | longer |
- | will experience when they are not communicating. | + | DOWN state. |
- | again bear in mind that we have no real operational experience with this. | + | not communicating. |
+ | mind that we have no real operational experience with this. | ||
The split statement | The split statement | ||
Zeile 605: | Zeile 647: | ||
split index; | split index; | ||
- | | + | The split statement specifies the split between the primary and secondary for the purposes |
- | Whenever a client makes a DHCP request, the DHCP server runs a hash on the client identification, | + | load balancing. |
- | value from 0 to 255. This is used as an index into a 256 bit field. | + | client identification, |
- | | + | bit field. |
- | | + | index is not set, the secondary is responsible. |
- | to serve more clients than the secondary. | + | leading |
- | 255, of which the most reasonable is 128. | + | serve more clients than the secondary. |
+ | between 0 and 255, of which the most reasonable is 128. | ||
The hba statement | The hba statement | ||
Zeile 617: | Zeile 660: | ||
hba colon-separated-hex-list; | hba colon-separated-hex-list; | ||
- | | + | |
- | theoretically allows for finer-grained control. | + | than a cutoff, which theoretically allows for finer-grained control. |
- | control, however. | + | probably no need for such fine-grained control, however. |
hba ff: | hba ff: | ||
| | ||
- | | + | |
- | a split of 128, but are not identical: | + | also equivalent to a split of 128, but are not identical: |
hba aa: | hba aa: | ||
Zeile 633: | Zeile 676: | ||
| | ||
- | They are equivalent, because half the bits are set to 0, half are set to 1 (0xa and 0x5 are 1010 and 0101 binary | + | They are equivalent, because half the bits are set to 0, half are set to 1 (0xa and 0x5 are |
- | respectively) | + | 1010 and 0101 binary |
- | identical, because the actual peers this would load balance to each server are different for each example. | + | equally between the servers. |
+ | balance to each server are different for each example. | ||
- | You must only have split or hba defined, never both. For most cases, the fine-grained control that hba offers | + | You must only have split or hba defined, never both. For most cases, the fine-grained control |
- | isn't necessary, and split should be used. | + | that hba offers isn't necessary, and split should be used. |
The load balance max seconds statement | The load balance max seconds statement | ||
Zeile 644: | Zeile 688: | ||
load balance max seconds seconds; | load balance max seconds seconds; | ||
- | | + | This statement allows you to configure a cutoff after which load balancing is disabled. |
- | the number of seconds since the client sent its first DHCPDISCOVER or DHCPREQUEST message, and only works with | + | cutoff |
- | clients | + | DHCPREQUEST message, and only works with clients that correctly implement |
- | something like 3 or 5. The effect of this is that if one of the failover peers gets into a state where it is | + | fortunately |
- | responding | + | of this is that if one of the failover peers gets into a state where it is responding |
- | over its client load automatically as the clients retry. | + | failover |
+ | take over its client load automatically as the clients retry. | ||
The auto-partner-down statement | The auto-partner-down statement | ||
Zeile 655: | Zeile 700: | ||
| | ||
- | This statement instructs the server to initiate a timed delay upon entering the communications-interrupted state | + | This statement instructs the server to initiate a timed delay upon entering |
- | (any situation | + | tions-interrupted state (any situation of being out-of-contact with the remote failover peer). |
- | server will automatically enter the partner-down state. | + | At the conclusion of the timer, the server will automatically enter the partner-down |
- | partner' | + | This permits |
- | operating at the time (the two servers will give conflicting bindings). | + | STOS+MCLT timer expires, which can be dangerous if the partner is in fact operating |
+ | time (the two servers will give conflicting bindings). | ||
- | Think very carefully before enabling this feature. | + | Think very carefully before enabling this feature. |
- | intentionally | + | |
- | its peer, but still has the ability to receive and reply to requests from DHCP clients. | + | server |
- | | + | to requests from DHCP clients. |
- | such as by a dedicated hardwired link ("a heartbeat cable" | + | |
+ | hardwired link ("a heartbeat cable" | ||
- | A zero value disables the auto-partner-down feature (also the default), and any positive | + | A zero value disables the auto-partner-down feature (also the default), and any positive value |
- | time in seconds to wait before automatically entering partner-down. | + | indicates the time in seconds to wait before automatically entering partner-down. |
The Failover pool balance statements. | The Failover pool balance statements. | ||
Zeile 677: | Zeile 724: | ||
max-balance seconds; | max-balance seconds; | ||
- | | + | This version of the DHCP Server evaluates pool balance on a schedule, rather than on demand as |
- | cated. The latter approach proved to be slightly klunky when pool misbalanced reach total saturation...when any | + | leases are allocated. The latter approach proved to be slightly klunky when pool misbalanced |
- | server ran out of leases to assign, it also lost its ability to notice it had run dry. | + | reach total saturation...when any server ran out of leases to assign, it also lost its ability |
+ | to notice it had run dry. | ||
- | | + | In order to understand pool balance, some elements of its operation first need to be defined. |
- | ´free´ and ´backup´ leases. | + | First, |
- | free states´ for the purpose of this document. | + | leases´. |
- | leases unless under special | + | difference |
+ | | ||
- | When pool balance is performed, the only plausible expectation is to provide a 50/50 split of the free state | + | When pool balance is performed, the only plausible expectation is to provide a 50/50 split of |
- | leases | + | the free state leases |
- | relative load placed upon the two servers, so giving each server half the leases gives both servers | + | server will fail, regardless of the relative load placed upon the two servers, so giving |
- | amount of ´failure endurance´. | + | server |
- | very small windows we will describe shortly. | + | there is no way to configure any different behaviour, outside of some very small windows |
+ | will describe shortly. | ||
- | The first thing calculated on any pool balance run is a value referred to as ´lts´, or " | + | The first thing calculated on any pool balance run is a value referred to as ´lts´, or " |
- | simply, | + | To Send" |
- | difference in the backup and free leases, divided by two. The resulting value is signed: if it is positive, the | + | two. |
- | local server | + | The resulting value is signed: if it is positive, the local server is expected |
- | would need to send leases to balance the pool. Once the lts value reaches zero, the pool is perfectly | + | leases |
+ | leases to balance the pool. Once the lts value reaches zero, the pool is perfectly | ||
(give or take one lease in the case of an odd number of total free state leases). | (give or take one lease in the case of an odd number of total free state leases). | ||
- | | + | |
- | lease-misbalance statement. | + | |
- | if lts is less than free+backup * max-lease-misbalance | + | fixed value in previous versions: if lts is less than free+backup * max-lease-misbalance |
- | (it won't bother moving any leases, even if some leases " | + | cent, then the server will skip balancing a given pool (it won' |
- | somewhat | + | even if some leases |
- | | + | loaded, however, in that it also governs the estimation of when to attempt to balance the pool |
- | they have resided in their respective queues is used as an estimate to indicate how much time it is probable it | + | |
- | would take before the leases at the top of the list would be consumed (and thus, how long it would take to use | + | examined. |
- | all leases in that state). | + | indicate |
- | falls within the min-balance and max-balance configured values. | + | would be consumed (and thus, how long it would take to use all leases in that state). |
- | | + | percentage |
- | | + | the min-balance and max-balance configured values. |
- | that the remote system will be woken up into action. | + | moved in a downwards direction, it is never increased. |
+ | this number in the negative | ||
+ | protocol POOLREQ message, in the hopes that the remote system will be woken up into action. | ||
- | | + | |
- | leases are moved to the remote server. | + | described above, leases are moved to the remote server. |
- | In the first pass, only leases whose most recent bound client would have been served | + | In the first pass, only leases whose most recent bound client would have been served |
- | according | + | remote server - according to the Load Balance Algorithm (see above split and hba configuration |
- | the peer. This first pass will happily continue to give away leases, decrementing the lts value by one for | + | statements) - are given away to the peer. This first pass will happily continue to give away |
- | each, until the lts value has reached the negative | + | leases, |
- | ownership percentage. | + | |
- | for the purpose of giving the peer more than a 50/50 share of leases in the hopes that their clients might some | + | through this value that you can permit a small misbalance of the lease pools - for the purpose |
- | day return and be allocated by the peer (operating normally). | + | of giving the peer more than a 50/50 share of leases in the hopes that their clients |
- | Affinity´, | + | some |
- | affinity is applied to leases when they enter the state ´free´ from ´expired´ or ´released´. | + | to as ´MAC Address Affinity´, but this is somewhat misnamed: it applies equally to DHCP Client |
- | leases will not be moved from free to backup if the secondary already has more than its share. | + | Identifier |
+ | ´free´ from ´expired´ or ´released´. | ||
+ | backup if the secondary already has more than its share. | ||
- | | + | |
- | free state leases multiplied by the max-lease-ownership percentage. | + | total number of free state leases multiplied by the max-lease-ownership percentage. |
- | over to the peer without second thought about the Load Balance | + | pass, the oldest leases are given over to the peer without second thought about the Load Bal‐ |
- | under this value. | + | |
- | would normally load balance to itself. | + | local server will also happily keep a small percentage of the leases that would normally load |
+ | balance to itself. | ||
- | So, the max-lease-misbalance value acts as a behavioural gate. Smaller values will cause more leases to transi‐ | + | So, the max-lease-misbalance value acts as a behavioural gate. Smaller values will cause more |
- | tion states to balance the pools over time, higher values will decrease the amount of change (but may lead to | + | leases |
- | pool starvation if there' | + | amount of change (but may lead to pool starvation if there' |
- | | + | The max-lease-ownership value permits a small (percentage) skew in the lease balance of a per‐ |
- | total number of free state leases. | + | |
- | | + | |
- | able timeframe (not to be thrown off by, for example, a 7 year old free lease). | + | within a reasonable |
- | | + | |
- | from one another (once lts exceeds 50% of the free state leases, one server must therefore | + | indistinguishable |
- | leases | + | must therefore have 100% of the leases in its respective free state). |
- | than the value selected for the max-lease-misbalance value. | + | select |
- | misbalance defaults to 15. | + | misbalance value. |
+ | 15. | ||
- | | + | |
- | local time_t value), but default to values 60 and 3600 respectively (to place balance events | + | the limit of your local time_t value), but default to values |
- | and 1 hour). | + | place balance events between 1 minute and 1 hour). |
CLIENT CLASSING | CLIENT CLASSING | ||
- | | + | |
- | | + | in. This separation |
- | is possible to specify a limit on the total number of clients within a particular class or subclass that may hold | + | within |
- | leases at one time, and it is possible to specify automatic subclassing | + | within a particular class or subclass that may hold leases at one time, and it is possible |
- | packet. | + | specify automatic subclassing based on the contents of the client packet. |
- | | + | To add clients to classes based on conditional evaluation, you can specify a matching expression |
- | statement: | + | in the class statement: |
class " | class " | ||
Zeile 767: | Zeile 824: | ||
} | } | ||
- | Note that whether you use matching expressions or add statements (or both) to classify clients, | + | Note that whether you use matching expressions or add statements (or both) to classify |
- | write a class declaration for any class that you use. If there will be no match statement and no in-scope | + | you must always write a class declaration for any class that you use. If there will be no match |
- | | + | statement and no in-scope |
class " | class " | ||
Zeile 775: | Zeile 832: | ||
SUBCLASSES | SUBCLASSES | ||
- | In addition to classes, it is possible to declare subclasses. | + | In addition to classes, it is possible to declare subclasses. |
- | | + | same name as a regular |
- | speed hack - the main difference between five classes with match expressions and one class with five subclasses is | + | matching. |
- | that it will be quicker to find the subclasses. Subclasses work as follows: | + | match expressions and one class with five subclasses is that it will be quicker to find the sub‐ |
+ | | ||
class " | class " | ||
Zeile 803: | Zeile 861: | ||
} | } | ||
- | | + | The data following the class name in the subclass declaration is a constant |
- | expression for the class. | + | matching the match expression for the class. |
- | look the result | + | |
- | and the subclass. | + | the client is considered a member of both the class and the subclass. |
- | | + | |
- | allow some clients | + | subclass is to allow some clients access to one address pool, while other clients |
- | subclasses are declared without scopes. | + | access |
- | values for some clients, you might want to declare some subclasses with scopes. | + | |
+ | to declare some subclasses with scopes. | ||
- | In the above example, if you had a single client that needed some configuration parameters, while most didn' | + | |
- | might write the following subclass declaration for that client: | + | while most didn' |
| | ||
Zeile 821: | Zeile 880: | ||
} | } | ||
- | In this example, we've used subclassing as a way to control address allocation on a per-client | + | In this example, we've used subclassing as a way to control address allocation on a per-client |
- | it' | + | basis. |
- | the vendor-class-identifier option to determine what values to send in the vendor-encapsulated-options option. | + | - for example, to use the value of the vendor-class-identifier option to determine |
- | example of this is shown under the VENDOR ENCAPSULATED OPTIONS head in the dhcp-options(5) manual page. | + | to send in the vendor-encapsulated-options option. |
+ | ENCAPSULATED OPTIONS head in the dhcp-options(5) manual page. | ||
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION | PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION | ||
- | | + | You may specify a limit to the number of clients in a class that can be assigned |
- | be to make it difficult for a new client in a class to get an address. | + | effect of this will be to make it difficult for a new client in a class to get an address. |
- | its limit, | + | a class with such a limit has reached its limit, the only way a new client in that class can get |
- | lease, either by letting it expire, or by sending a DHCPRELEASE packet. | + | a lease is for an existing client to relinquish its lease, either by letting it expire, or by |
- | as follows: | + | sending a DHCPRELEASE packet. |
class " | class " | ||
Zeile 840: | Zeile 900: | ||
SPAWNING CLASSES | SPAWNING CLASSES | ||
- | | + | It is possible to declare a spawning class. |
- | based on what the client sends. | + | duces subclasses |
- | lease-limited classes on the fly. The envisioned application is a cable-modem environment where the ISP wishes to | + | was to make it possible to create lease-limited classes on the fly. The envisioned |
- | provide clients at a particular site with more than one IP address, but does not wish to provide such clients with | + | is a cable-modem environment where the ISP wishes to provide clients at a particular site with |
- | their own subnet, | + | more than one IP address, but does not wish to provide such clients with their own subnet, |
- | connected. | + | give them an unlimited number of IP addresses from the network segment to which they are con‐ |
+ | nected. | ||
- | Many cable modem head-end systems can be configured to add a Relay Agent Information option to DHCP packets | + | Many cable modem head-end systems can be configured to add a Relay Agent Information |
- | relaying | + | DHCP packets when relaying them to the DHCP server. |
- | identifies the customer site. To take advantage of this, you can write a class declaration as follows: | + | remote ID option that uniquely identifies the customer site. To take advantage of this, you can |
+ | write a class declaration as follows: | ||
class " | class " | ||
Zeile 856: | Zeile 918: | ||
} | } | ||
- | Now whenever a request comes in from a customer site, the circuit ID option will be checked | + | |
- | hash table. | + | against the class' |
- | and treated accordingly. | + | will be classified in that subclass and treated accordingly. |
- | the dhcpd.leases file, and the client will be classified in this new class. | + | the circuit ID, a new one will be created and logged in the dhcpd.leases file, and the client |
- | it will be treated according to the rules of the class, including, in this case, being subject | + | will be classified in this new class. |
+ | according to the rules of the class, including, in this case, being subject | ||
limit of four leases. | limit of four leases. | ||
- | | + | |
- | given only because it is a fairly straightforward one. | + | ticular example is given only because it is a fairly straightforward one. |
COMBINING MATCH, MATCH IF AND SPAWN WITH | COMBINING MATCH, MATCH IF AND SPAWN WITH | ||
- | In some cases, it may be useful to use one expression to assign a client to a particular | + | In some cases, it may be useful to use one expression to assign a client to a particular |
- | expression | + | and a second expression to put it into a subclass of that class. |
- | statements, or the match if and match statements. | + | the match if and spawn with statements, or the match if and match statements. |
class " | class " | ||
Zeile 883: | Zeile 946: | ||
} | } | ||
- | This allows you to have two classes that both have the same spawn with expression without | + | This allows you to have two classes that both have the same spawn with expression |
- | the two classes confused with each other. | + | ting the clients in the two classes confused with each other. |
DYNAMIC DNS UPDATES | DYNAMIC DNS UPDATES | ||
- | The DHCP server has the ability to dynamically update the Domain Name System. | + | |
- | can define how you want the Domain Name System to be updated. | + | |
- | server supporting RFC 2136 should be able to accept updates from the DHCP server. | + | updates |
+ | updates from the DHCP server. | ||
- | | + | Two DNS update schemes are currently implemented, |
- | are the ad-hoc DNS update mode and the interim DHCP-DNS interaction draft update mode. In the future we plan to | + | rently |
- | add a third mode which will be the standard DNS update method based on the RFCS for DHCP-DNS interaction and DHCID | + | update mode. In the future we plan to add a third mode which will be the standard |
- | The DHCP server must be configured to use one of the two currently-supported methods, or not to do dns updates. | + | method |
- | This can be done with the ddns-update-style configuration parameter. | + | to use one of the two currently-supported methods, or not to do dns updates. |
+ | with the ddns-update-style configuration parameter. | ||
THE AD-HOC DNS UPDATE SCHEME | THE AD-HOC DNS UPDATE SCHEME | ||
- | | + | The ad-hoc Dynamic DNS update scheme is now deprecated and does not work. In future releases of |
- | server, this scheme will not likely be available. | + | the ISC DHCP server, this scheme will not likely be available. |
- | be used. The following description is left here for informational purposes only. | + | for failover, and should now be used. The following description is left here for informational |
+ | purposes only. | ||
- | | + | The ad-hoc Dynamic DNS update scheme implemented in this version of the ISC DHCP server |
- | which does not have much to do with the standard update method that is being standardized in the IETF DHC working | + | prototype |
- | group, | + | standardized in the IETF DHC working group, but rather implements some very basic, |
- | failover protocol because it does not account for the possibility of two different DHCP servers updating the same | + | update |
- | set of DNS records. | + | account for the possibility of two different DHCP servers updating the same set of DNS records. |
- | | + | For the ad-hoc DNS update method, the client' |
- | Then, the domain name is determined, and appended to the hostname. | + | |
- | The DHCP server determines the client' | + | The DHCP server determines the client' |
- | using that if it is present. | + | |
- | option sent by the client. | + | for a valid hostname in the FQDN option sent by the client. |
- | used. | + | wise, if the client sent a host-name option, that is used. Otherwise, if there is a host decla‐ |
- | be used. If none of these applies, the server will not have a hostname for the client, and will not be able to do | + | |
- | a DNS update. | + | these applies, the server will not have a hostname for the client, and will not be able to do a |
+ | DNS update. | ||
- | | + | |
- | | + | figuration for this option is: |
| | ||
- | So if this configuration option is not configured to a different value (over-riding the above default), | + | So if this configuration option is not configured to a different value (over-riding |
- | domain-name | + | default), |
- | DNS update. | + | server will not attempt to perform a DNS update. |
- | The client' | + | The client' |
- | will be stored. | + | which an " |
- | already an A record with the same name in the DNS server, no update of either the A or PTR records | + | was assigned in its lease. |
- | this prevents | + | server, no update of either the A or PTR records will occur - this prevents a client from claim‐ |
- | have a fileserver called " | + | |
+ | called | ||
done for that client, and an error message will be logged. | done for that client, and an error message will be logged. | ||
- | | + | If the A record update succeeds, a PTR record update for the assigned IP address will be done, |
- | record. | + | pointing |
- | the IP address has been assigned to the DHCP server, this should be safe. | + | record of the same name exists. |
+ | should be safe. | ||
- | | + | |
- | two network interfaces will see unpredictable behavior. | + | face. A client with two network interfaces will see unpredictable behavior. |
- | release. | + | a bug, and will be fixed in a later release. |
- | this same behavior. | + | client parameter so that roaming clients do not trigger this same behavior. |
- | The DHCP protocol normally involves a four-packet exchange - first the client sends a DHCPDISCOVER | + | The DHCP protocol normally involves a four-packet exchange - first the client sends a |
- | the server | + | |
- | | + | server sends a DHCPACK. |
- | has sent the DHCPACK. | + | after it has received the DHCPREQUEST, |
- | order to minimize the impact on the DHCP server. | + | DNS update if it has not sent one for the client' |
+ | impact on the DHCP server. | ||
- | When the client' | + | |
- | remove | + | it operates) will remove the client' |
- | DHCPRELEASE message, the server will likewise remove the A and PTR records. | + | releases |
+ | PTR records. | ||
THE INTERIM DNS UPDATE SCHEME | THE INTERIM DNS UPDATE SCHEME | ||
- | The interim DNS update scheme operates mostly according to several drafts | + | The interim DNS update scheme operates mostly according to several |
- | drafts | + | IETF. |
- | between our code and the final RFCs. We plan to update our code, probably adding a standard DNS update option, at | + | and there are some differences between our code and the final RFCs. We plan to update our code, |
- | some time. The basic framework is similar with the main material difference being that a DHCID RR was assigned in | + | probably adding a standard DNS update option, at some time. The basic framework is similar with |
- | the RFCs whereas our code continues to use an experimental TXT record. | + | the main material difference being that a DHCID RR was assigned in the RFCs whereas |
- | resemblance | + | continues |
- | RFCs are: | + | to the DHCID RR but it is not equivalent (MD5 vs SHA1, field length differences etc). The stan‐ |
+ | dard RFCs are: | ||
- | | + | RFC 4701 (updated by RF5494) |
- | RFC 4702 | + | |
- | RFC 4703 | + | |
And the corresponding drafts were: | And the corresponding drafts were: | ||
- | draft-ietf-dnsext-dhcid-rr-?? | + | |
- | | + | draft-ietf-dhc-fqdn-option-?? |
- | | + | draft-ietf-dhc-ddns-resolution-?? |
- | | + | |
- | update style here. | + | operation of this update style here. |
- | The first point to understand about this style of DNS update is that unlike the ad-hoc style, the DHCP server does | + | The first point to understand about this style of DNS update is that unlike |
- | not necessarily always update both the A and the PTR records. | + | the DHCP server |
- | the client, indicates that the client wishes to update its own A record. | + | option includes a flag which, when sent by the client, |
- | | + | update |
- | updates; or the statement ignore client-updates; | + | client' |
+ | the statement ignore client-updates; | ||
- | If the server is configured to allow client updates, then if the client sends a fully-qualified domain name in the | + | |
- | FQDN option, the server will use that name the client sent in the FQDN option to update the PTR record. | + | domain name in the FQDN option, the server will use that name the client sent in the FQDN option |
- | ple, let us say that the client is a visitor from the " | + | to update |
- | server is for the " | + | " |
- | " | + | The DHCP client |
- | does not attempt to set up an A record for the client, but does set up a PTR record for the IP address | + | indicates that it wants to update its own A record. |
- | | + | to set up an A record for the client, but does set up a PTR record for the IP address that it |
- | A record, assuming that the " | + | |
+ | can update its own A record, assuming that the " | ||
- | If the server is configured not to allow client updates, or if the client doesn' | + | If the server is configured not to allow client updates, or if the client doesn' |
- | server | + | own update, the server will simply choose a name for the client from either the fqdn option |
- | (if present). | + | present) |
- | update both the A and PTR record, using the name that it chose for the client. | + | just as in the ad-hoc update scheme. |
- | | + | name that it chose for the client. |
- | above, | + | fqdn option, the server uses only the leftmost part of the domain name - in the example |
+ | " | ||
- | | + | |
- | DHCP packet, using the FQDN Option, that implies to the client that it should | + | a response in the DHCP packet, using the FQDN Option, that implies to the client that it should |
- | chooses | + | perform |
- | updates. | + | which indicates the client may not perform updates. |
- | Also, if the use-host-decl-names configuration option is enabled, then the host declaration' | + | Also, if the use-host-decl-names configuration option is enabled, then the host declaration' |
- | used in place of the hostname option, and the same rules will apply as described above. | + | hostname |
+ | described above. | ||
- | The other difference between the ad-hoc scheme and the interim scheme is that with the interim scheme, a method is | + | The other difference between the ad-hoc scheme and the interim scheme is that with the interim |
- | used that allows more than one DHCP server to update the DNS database | + | scheme, |
- | shouldn' | + | |
+ | should be added. | ||
- | | + | |
- | client' | + | over the DHCP client' |
- | name the server chose and a TXT record containing the hashed identifier string (hashid). | + | update |
- | the server is done. | + | identifier string (hashid). |
- | If the update fails because the A record already exists, then the DHCP server attempts to add the A record | + | If the update fails because the A record already exists, then the DHCP server |
- | the prerequisite that there must be a TXT record in the same name as the new A record, and that TXT record' | + | the A record with the prerequisite that there must be a TXT record in the same name as the new A |
- | | + | record, and that TXT record' |
- | fails, | + | the client |
- | this point the DHCP server gives up trying to do a DNS update for the client until the client chooses a new name. | + | assigned (or requested) is in use, and can't be used by the client. |
+ | server gives up trying to do a DNS update for the client until the client chooses a new name. | ||
- | The interim DNS update scheme is called interim for two reasons. | + | |
- | RFCs call for a new DHCID RRtype while he interim DNS update scheme uses a TXT record. | + | |
- | called for the DHCP server to put a DHCID RR on the PTR record, but the interim update method does not do this. | + | TXT record. |
- | In the final RFC this requirement was relaxed such that a server may add a DHCID RR to the PTR record. | + | record, but the interim update method does not do this. In the final RFC this requirement |
+ | relaxed such that a server may add a DHCID RR to the PTR record. | ||
- | | + | |
- | involves a round trip to the DNS server, there is a cost associated with doing updates even if they do not | + | each DNS update involves a round trip to the DNS server, there is a cost associated |
- | | + | updates even if they do not actually |
- | (this information is stored on the lease) and does not attempt to update records that it thinks | + | or not it has updated the record in the past (this information is stored on the lease) and does |
- | updated. | + | not attempt to update records that it thinks it has already updated. |
- | | + | |
- | mechanism, but the server never again updates the DNS because it thinks the data is already there. | + | through some other mechanism, but the server never again updates the DNS because it thinks |
- | the data can be removed from the lease through operator intervention, | + | data is already |
- | updated the next time the client renews. | + | intervention, |
+ | renews. | ||
DYNAMIC DNS UPDATE SECURITY | DYNAMIC DNS UPDATE SECURITY | ||
- | When you set your DNS server up to allow updates from the DHCP server, you may be exposing | + | When you set your DNS server up to allow updates from the DHCP server, you may be exposing it to |
- | | + | unauthorized |
- | shared secret key. As long as you protect the secrecy of this key, your updates should | + | |
- | however, that the DHCP protocol itself provides no security, and that clients can therefore provide information to | + | key, your updates should also be secure. |
- | the DHCP server which the DHCP server will then use in its updates, with the constraints described previously. | + | no security, |
+ | DHCP server will then use in its updates, with the constraints described previously. | ||
- | The DNS server must be configured to allow updates for any zone that the DHCP server will be updating. | + | The DNS server must be configured to allow updates for any zone that the DHCP server |
- | ple, let us say that clients in the sneedville.edu domain will be assigned addresses on the 10.10.17.0/ | + | updating. |
- | In that case, you will need a key declaration for the TSIG key you will be using, and also two zone declarations - | + | addresses on the 10.10.17.0/ |
- | one for the zone containing A records that will be updates and one for the zone containing PTR records - for ISC | + | TSIG key you will be using, |
- | BIND, something | + | records that will be updates and one for the zone containing PTR records - for ISC BIND, |
+ | | ||
key DHCP_UPDATER { | key DHCP_UPDATER { | ||
Zeile 1053: | Zeile 1135: | ||
| | ||
}; | }; | ||
+ | |||
zone " | zone " | ||
type master; | type master; | ||
Zeile 1065: | Zeile 1148: | ||
}; | }; | ||
- | You will also have to configure your DHCP server to do updates to these zones. | + | |
- | | + | need to add something |
key DHCP_UPDATER { | key DHCP_UPDATER { | ||
Zeile 1083: | Zeile 1166: | ||
} | } | ||
- | | + | The primary statement specifies the IP address of the name server whose zone information |
- | addition to the primary statement there are also the primary6 , secondary and secondary6 statements. | + | be updated. |
- | statement | + | secondary6 statements. |
- | name servers to be used if the primary does not respond. | + | The secondaries provide for additional addresses for name servers to be used if the primary does |
- | use before giving up is limited and is currently set to three. | + | not respond. |
- | | + | limited and is currently set to three. |
- | ple, there must be an SOA record for " | + | |
- | a subdomain " | + | Note that the zone declarations have to correspond to authority records in your name server - in |
- | Also keep in mind that zone names in your DHCP configuration should end in a " | + | the above example, there must be an SOA record |
- | If you do not end your zone name in a " | + | addr.arpa." |
+ | could not write a zone declaration for " | ||
+ | your DHCP configuration | ||
+ | your zone name in a " | ||
| | ||
- | You should choose your own secret key, of course. | + | |
- | | + | a program for generating |
- | more random key, so we recommend you use that one even if you are not using BIND 9 as your DNS server. | + | is likely |
- | using BIND 9's dnssec-keygen, | + | you are not using BIND 9 as your DNS server. |
+ | key would be created as follows: | ||
dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER | dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER | ||
- | If you are using the BIND 8 dnskeygen program, the following command will generate a key as seen above: | + | If you are using the BIND 8 dnskeygen program, the following command will generate a key as seen |
+ | above: | ||
dnskeygen -H 128 -u -c -n DHCP_UPDATER | dnskeygen -H 128 -u -c -n DHCP_UPDATER | ||
- | | + | You may wish to enable logging of DNS updates on your DNS server. |
- | like the following: | + | logging statement |
| | ||
Zeile 1129: | Zeile 1217: | ||
}; | }; | ||
- | You must create the / | + | You must create the / |
- | For more information on configuring ISC BIND, consult the documentation that accompanies it. | + | the name server. |
+ | accompanies it. | ||
REFERENCE: EVENTS | REFERENCE: EVENTS | ||
- | | + | There are three kinds of events that can happen regarding a lease, and it is possible to declare |
- | occur when any of these events happen. | + | statements that occur when any of these events happen. |
- | of a certain | + | the server |
- | and the expiry event, when the commitment expires. | + | client has released the server from its commitment, and the expiry event, |
+ | expires. | ||
- | To declare a set of statements to execute when an event happens, you must use the on statement, | + | |
- | name of the event, | + | followed by the name of the event, followed by a series of statements to execute when the event |
- | Events are used to implement DNS updates, so you should not define your own event handlers if you are using the | + | happens, enclosed in braces. |
- | built-in DNS update mechanism. | + | your own event handlers if you are using the built-in DNS update mechanism. |
- | | + | The built-in version of the DNS update mechanism |
- | want to use events for things other than DNS updates, and you also want DNS updates, you will have to start out by | + | server/ |
- | copying this code into your dhcpd.conf file and modifying | + | DNS updates, you will have to start out by copying this code into your dhcpd.conf file and modi‐ |
+ | | ||
REFERENCE: DECLARATIONS | REFERENCE: DECLARATIONS | ||
Zeile 1152: | Zeile 1243: | ||
include " | include " | ||
- | | + | |
- | entered in place of the include statement. | + | though it were entered in place of the include statement. |
The shared-network statement | The shared-network statement | ||
Zeile 1162: | Zeile 1253: | ||
} | } | ||
- | The shared-network statement is used to inform the DHCP server that some IP subnets actually share the same physi‐ | + | The shared-network statement is used to inform the DHCP server that some IP subnets |
- | | + | share the same |
- | specified in the shared-network statement will be used when booting clients on those subnets | + | shared-network statement. |
- | provided at the subnet or host level override them. If any subnet in a shared network has addresses available for | + | when booting |
- | dynamic allocation, those addresses are collected into a common pool for that shared | + | override them. If any subnet in a shared network has addresses available |
- | | + | tion, those addresses are collected into a common pool for that shared network and assigned to |
+ | | ||
+ | should boot. | ||
- | | + | |
- | be descriptive for the shared network. | + | sages, so it should be descriptive for the shared network. |
- | never be used as such), or it may be any arbitrary name, enclosed in quotes. | + | valid domain |
+ | enclosed in quotes. | ||
The subnet statement | The subnet statement | ||
Zeile 1180: | Zeile 1274: | ||
} | } | ||
- | | + | The subnet statement is used to provide dhcpd with enough information to tell whether or not an |
- | that subnet. | + | IP address is on that subnet. |
- | dynamically | + | specify what addresses may be dynamically allocated to clients booting |
- | tion. | + | addresses are specified using the range declaration. |
- | The subnet-number should be an IP address or domain name which resolves to the subnet number of the subnet | + | |
- | described. | + | the subnet being described. |
- | being described. | + | to the subnet mask of the subnet being described. |
- | address is on the specified subnet. | + | are sufficient to determine whether any given IP address is on the specified subnet. |
- | | + | |
- | subnet masks at a site, a subnet-mask option statement be used in each subnet declaration to set the desired | + | is any variance in subnet masks at a site, a subnet-mask option statement be used in each subnet |
- | | + | declaration to set the desired |
+ | the subnet mask declared in the subnet statement. | ||
The subnet6 statement | The subnet6 statement | ||
+ | |||
subnet6 subnet6-number { | subnet6 subnet6-number { | ||
[ parameters ] | [ parameters ] | ||
Zeile 1200: | Zeile 1296: | ||
} | } | ||
- | | + | The subnet6 statement is used to provide dhcpd with enough information to tell whether or not an |
- | on that subnet6. | + | IPv6 address is on that subnet6. |
- | dynamically allocated to clients booting on that subnet. | + | to specify what addresses may be dynamically allocated to clients booting on that subnet. |
The subnet6-number should be an IPv6 network identifier, specified as ip6-address/ | The subnet6-number should be an IPv6 network identifier, specified as ip6-address/ | ||
Zeile 1210: | Zeile 1306: | ||
range [ dynamic-bootp ] low-address [ high-address]; | range [ dynamic-bootp ] low-address [ high-address]; | ||
- | | + | For any subnet on which addresses will be assigned dynamically, |
- | range statement gives the lowest and highest IP addresses in a range. | + | statement. |
- | the subnet in which the range statement is declared. | + | addresses |
- | specified range may be dynamically assigned to BOOTP clients as well as DHCP clients. | + | dynamic-bootp flag may be specified if addresses in the specified |
- | address, high-address can be omitted. | + | assigned |
+ | address can be omitted. | ||
The range6 statement | The range6 statement | ||
Zeile 1223: | Zeile 1320: | ||
| | ||
- | For any IPv6 subnet6 on which addresses will be assigned dynamically, | + | For any IPv6 subnet6 on which addresses will be assigned dynamically, |
- | The range6 statement can either be the lowest and highest IPv6 addresses in a range6, or use CIDR notation, | + | range6 |
- | | + | range6, or use CIDR notation, |
- | declared. | + | should be in the subnet6 in which the range6 statement is declared. |
- | The temporary variant makes the prefix (by default on 64 bits) available for temporary (RFC 4941) addresses. A new | + | |
- | address | + | 4941) addresses. A new address per prefix in the shared network is computed at each request with |
- | ignores temporary addresses. | + | an IA_TA option. Release and Confirm ignores temporary addresses. |
- | Any IPv6 addresses given to hosts with fixed-address6 are excluded from the range6, as are IPv6 addresses | + | |
- | server itself. | + | addresses on the server itself. |
The prefix6 statement | The prefix6 statement | ||
Zeile 1239: | Zeile 1336: | ||
| | ||
- | | + | The prefix6 is the range6 equivalent for Prefix Delegation (RFC 3633). Prefixes of bits length |
- | between low-address and high-address. | + | are assigned between low-address and high-address. |
- | Any IPv6 prefixes given to static entries (hosts) with fixed-prefix6 are excluded from the prefix6. | + | |
+ | fix6. | ||
This statement is currently global but it should have a shared-network scope. | This statement is currently global but it should have a shared-network scope. | ||
Zeile 1253: | Zeile 1351: | ||
} | } | ||
- | The host declaration provides a scope in which to provide configuration information about a specific | + | The host declaration provides a scope in which to provide configuration information about a spe‐ |
- | also provides | + | |
- | to identify a DHCP or BOOTP client, and also a way to assign the client a static IP address. | + | provides a way for the DHCP server to identify a DHCP or BOOTP client, and also a way to assign |
+ | the client a static IP address. | ||
- | If it is desirable to be able to boot a DHCP or BOOTP client on more than one subnet with fixed addresses, | + | |
- | than one address may be specified in the fixed-address declaration, | + | addresses, more than one address may be specified in the fixed-address declaration, |
- | | + | one host statement may be specified |
- | If client-specific boot parameters must change based on the network to which the client is attached, then multiple | + | |
- | host declarations | + | attached, then multiple host declarations should be used. The host declarations will only match |
- | statements is viable on the subnet (or shared network) where the client is attached. | + | a client |
- | laration | + | where the client is attached. |
- | may therefore need a mixture of host declarations for any given client...some | + | cated a dynamic address, it must not have any fixed-address statements. |
- | others | + | a mixture of host declarations for any given client...some having fixed-address statements, |
+ | ers without. | ||
- | | + | |
- | used. | + | host, hostname is used. |
- | Host declarations are matched to actual DHCP or BOOTP clients | + | Host declarations are matched to actual DHCP or BOOTP clients by matching the dhcp-client-iden‐ |
- | client-id options specified in the host declaration to the one supplied by the client, or, if the host declaration | + | |
- | or the client does not provide a dhcp-client-identifier or pxe-client-id options, by matching the hardware | + | client, or, if the host declaration or the client does not provide a dhcp-client-identifier |
- | | + | pxe-client-id options, by matching the hardware |
- | provide a dhcp-client-identifier, | + | hardware address supplied by the client. |
- | BOOTP protocol. | + | identifier, |
+ | | ||
- | | + | |
- | fixed value to identify hosts. | + | any option with a fixed value to identify hosts. |
- | | + | |
- | used to match a host declaration, | + | address can be used to match a host declaration, |
- | not possible to match a host declaration to a host-name option. | + | DHCPv6 |
- | guaranteed | + | option. |
- | are at least theoretically | + | client, |
+ | | ||
The group statement | The group statement | ||
Zeile 1294: | Zeile 1396: | ||
} | } | ||
- | The group statement is used simply to apply one or more parameters to a group of declarations. | + | The group statement is used simply to apply one or more parameters to a group of declarations. |
- | group hosts, shared networks, subnets, or even other groups. | + | It can be used to group hosts, shared networks, subnets, or even other groups. |
REFERENCE: ALLOW AND DENY | REFERENCE: ALLOW AND DENY | ||
- | The allow and deny statements can be used to control the response of the DHCP server to various sorts of requests. | + | |
- | The allow and deny keywords actually have different meanings depending on the context. | + | sorts of requests. |
- | keywords | + | the context. |
- | control general server behavior with respect to clients based on scope. | + | allocation pools. |
- | can be used in place of the deny keyword to prevent logging of denied requests. | + | respect |
+ | place of the deny keyword to prevent logging of denied requests. | ||
ALLOW DENY AND IGNORE IN SCOPE | ALLOW DENY AND IGNORE IN SCOPE | ||
- | The following usages of allow and deny will work in any scope, although it is not recommended that they be used in | + | The following usages of allow and deny will work in any scope, although it is not recommended |
- | pool declarations. | + | that they be used in pool declarations. |
The unknown-clients keyword | The unknown-clients keyword | ||
Zeile 1314: | Zeile 1417: | ||
ignore unknown-clients; | ignore unknown-clients; | ||
- | The unknown-clients flag is used to tell dhcpd whether or not to dynamically assign addresses to unknown | + | The unknown-clients flag is used to tell dhcpd whether or not to dynamically assign addresses to |
- | | + | unknown clients. |
- | has no host declaration. | + | unknown client is simply a client that has no host declaration. |
- | The use of this option is now deprecated. | + | |
- | you should | + | to known clients, you should use deny unknown-clients; |
- | WITHIN POOL DECLARATIONS. | + | under the heading ALLOW AND DENY WITHIN POOL DECLARATIONS. |
The bootp keyword | The bootp keyword | ||
Zeile 1328: | Zeile 1431: | ||
ignore bootp; | ignore bootp; | ||
- | The bootp flag is used to tell dhcpd whether or not to respond to bootp queries. | + | |
- | default. | + | are allowed by default. |
The booting keyword | The booting keyword | ||
Zeile 1337: | Zeile 1440: | ||
ignore booting; | ignore booting; | ||
- | | + | The booting flag is used to tell dhcpd whether or not to respond to queries |
- | | + | client. |
- | | + | |
+ | to get an address from the DHCP server. | ||
The duplicates keyword | The duplicates keyword | ||
Zeile 1346: | Zeile 1450: | ||
deny duplicates; | deny duplicates; | ||
- | | + | |
- | network hardware type and MAC address. | + | on the client' |
- | with that MAC address - even clients with different client identifiers. | + | declaration |
- | | + | identifiers. |
- | NetBSD or Linux. | + | operating system installed on it - for example, Microsoft Windows and NetBSD or Linux. |
- | The duplicates flag tells the DHCP server that if a request is received from a client that matches the MAC address | + | |
- | of a host declaration, | + | matches the MAC address of a host declaration, |
- | UID is not the same. This is a violation of the DHCP protocol, but can prevent clients whose client identifiers | + | be discarded |
- | change regularly from holding many leases at the same time. By default, duplicates are allowed. | + | protocol, but can prevent clients whose client identifiers change regularly |
+ | leases at the same time. By default, duplicates are allowed. | ||
The declines keyword | The declines keyword | ||
Zeile 1363: | Zeile 1468: | ||
ignore declines; | ignore declines; | ||
- | The DHCPDECLINE message is used by DHCP clients to indicate that the lease the server has offered | + | |
- | When the server receives a DHCPDECLINE for a particular address, it normally | + | offered is not valid. |
- | some unauthorized system is using it. Unfortunately, | + | |
- | completely | + | a malicious or buggy client |
- | is running through the pool, it may cause serious thrashing in the DNS, and it will also cause the DHCP server | + | server' |
- | | + | through the pool, it may cause serious thrashing in the DNS, and it will also cause the |
+ | server to forget old DHCP client address allocations. | ||
- | | + | |
- | ignore in a particular scope, the DHCP server will not respond to DHCPDECLINE messages. | + | set to deny or ignore in a particular scope, the DHCP server will not respond |
+ | messages. | ||
The client-updates keyword | The client-updates keyword | ||
+ | |||
allow client-updates; | allow client-updates; | ||
deny client-updates; | deny client-updates; | ||
- | The client-updates flag tells the DHCP server whether or not to honor the client' | + | |
- | of its A record. | + | do its own update of its A record. |
- | THE INTERIM DNS UPDATE SCHEME for details. | + | the documentation under the heading THE INTERIM DNS UPDATE SCHEME for details. |
The leasequery keyword | The leasequery keyword | ||
Zeile 1386: | Zeile 1494: | ||
deny leasequery; | deny leasequery; | ||
- | The leasequery flag tells the DHCP server whether or not to answer DHCPLEASEQUERY packets. The answer | + | |
- | | + | answer to a DHCPLEASEQUERY |
- | expire. By default, the server will not respond to these packets. | + | was issued and when it will expire. By default, the server will not respond to these packets. |
ALLOW AND DENY WITHIN POOL DECLARATIONS | ALLOW AND DENY WITHIN POOL DECLARATIONS | ||
- | The uses of the allow and deny keywords shown in the previous section work pretty much the same way whether | + | |
- | client is sending a DHCPDISCOVER or a DHCPREQUEST message - an address will be allocated to the client (either the | + | way whether the client is sending a DHCPDISCOVER or a DHCPREQUEST message - an address |
- | old address it's requesting, or a new address) and then that address will be tested to see if it's okay to let the | + | allocated to the client (either the old address it's requesting, or a new address) and then that |
- | client | + | address will be tested to see if it's okay to let the client have it. If the client |
- | wise, the server will simply | + | it, and it's not okay, the server will send a DHCPNAK message. |
- | server will send a DHCPACK message. | + | |
+ | send a DHCPACK message. | ||
- | | + | |
- | | + | cation policies are different. |
- | ment. In order for this to work, access control has to be done during address allocation, not after address | + | another |
- | | + | done during address allocation, not after address |
- | When a DHCPREQUEST message is processed, address allocation simply consists of looking up the address | + | When a DHCPREQUEST message is processed, address allocation simply consists of looking |
- | is requesting | + | address |
- | address pool permit lists and the relevant in-scope allow and deny statements to see if it' | + | then the DHCP server checks both the address pool permit lists and the relevant |
- | lease to the client. | + | and deny statements |
- | | + | DHCPDISCOVER message, the allocation process is done as described |
+ | ALLOCATION section. | ||
- | When declaring permit lists for address allocation pools, the following | + | |
- | allow or deny keywords: | + | following the allow or deny keywords: |
known-clients; | known-clients; | ||
- | | + | If specified, this statement either allows or prevents allocation from this pool to any client |
- | declaration (i.e., is known). | + | that has a host declaration (i.e., is known). |
- | scope. | + | any scope, not just the current scope. |
unknown-clients; | unknown-clients; | ||
- | | + | If specified, this statement either allows or prevents allocation from this pool to any client |
- | declaration (i.e., is not known). | + | that has no host declaration (i.e., is not known). |
members of " | members of " | ||
- | If specified, this statement either allows or prevents allocation from this pool to any client that is a member of | + | |
- | the named class. | + | that is a member of the named class. |
dynamic bootp clients; | dynamic bootp clients; | ||
- | If specified, this statement either allows or prevents allocation from this pool to any bootp client. | + | If specified, this statement either allows or prevents allocation from this pool to any bootp |
+ | client. | ||
authenticated clients; | authenticated clients; | ||
- | | + | |
- | authenticated using the DHCP authentication protocol. | + | that has been authenticated using the DHCP authentication protocol. |
unauthenticated clients; | unauthenticated clients; | ||
- | If specified, this statement either allows or prevents allocation from this pool to any client that has not been | + | If specified, this statement either allows or prevents allocation from this pool to any client |
- | authenticated using the DHCP authentication protocol. | + | that has not been authenticated using the DHCP authentication protocol. |
+ | | ||
all clients; | all clients; | ||
- | If specified, this statement either allows or prevents allocation from this pool to all clients. | + | If specified, this statement either allows or prevents allocation from this pool to all clients. |
- | when you want to write a pool declaration for some reason, but hold it in reserve, or when you want to renumber | + | This can be used when you want to write a pool declaration for some reason, but hold it in |
- | your network | + | reserve, or when you want to renumber your network quickly, and thus want the server |
- | pool to obtain new addresses | + | all clients |
+ | | ||
after time; | after time; | ||
- | If specified, this statement either allows or prevents allocation from this pool after a given date. This can be | + | If specified, this statement either allows or prevents allocation from this pool after a given |
- | used when you want to move clients from one pool to another. The server adjusts the regular lease time so that the | + | date. This can be used when you want to move clients from one pool to another. The server |
- | latest expiry time is at the given time+min-lease-time. | + | adjusts the regular lease time so that the latest expiry time is at the given time+min-lease- |
- | longer | + | time. A short min-lease-time enforces a step change, whereas a longer min-lease-time allows for |
- | 4 2007/08/24 09:14:32 or a string with time zone offset in seconds e.g. 4 2007/08/24 11:14:32 -7200 | + | a gradual change. |
+ | 09:14:32 or a string with time zone offset in seconds e.g. 4 2007/08/24 11:14:32 -7200 | ||
REFERENCE: PARAMETERS | REFERENCE: PARAMETERS | ||
Zeile 1462: | Zeile 1576: | ||
| | ||
- | When the number of allocated leases within a pool rises above the percentage given in this statement, | + | |
- | server | + | statement, the DHCP server decreases the lease length for new clients within this pool to min- |
- | an already valid (long) leases get at least the remaining time from the current lease. Since the leases | + | lease-time seconds. Clients renewing an already valid (long) leases get at least the remaining |
- | faster, | + | time from the current lease. Since the leases expire faster, the server |
- | | + | more quickly |
+ | below the threshold, the server reverts back to normal lease times. | ||
| | ||
Zeile 1473: | Zeile 1588: | ||
| | ||
- | | + | |
- | the BOOTP message header. | + | the flags field of the BOOTP message header. |
- | receive | + | not do this, and therefore may not receive responses from the DHCP server. |
- | clients by setting this flag to ´on´ for the relevant scope; relevant | + | can be made to always broadcast its responses to clients by setting this flag to ´on´ for the |
- | statement, | + | relevant |
- | broadcast traffic on your network, we recommend that you restrict the use of this option to as few clients | + | class, or as a parameter for a host declaration. |
- | | + | on your network, |
- | and ISC DHCP clients. | + | |
+ | the OpenTransport | ||
The always-reply-rfc1048 statement | The always-reply-rfc1048 statement | ||
| | ||
- | Some BOOTP clients expect RFC1048-style responses, but do not follow RFC1048 when sending their requests. | + | |
- | can tell that a client is having this problem if it is not getting the options you have configured for it and if | + | their requests. |
- | you see in the server log the message " | + | options |
+ | rfc1048)" | ||
- | If you want to send rfc1048 options to such a client, you can set the always-reply-rfc1048 | + | If you want to send rfc1048 options to such a client, you can set the always-reply-rfc1048 |
- | client' | + | option |
- | flag can be set in any scope, and will affect all clients covered by that scope. | + | RFC-1048-style vendor options field. |
+ | clients covered by that scope. | ||
The authoritative statement | The authoritative statement | ||
Zeile 1499: | Zeile 1618: | ||
not authoritative; | not authoritative; | ||
- | The DHCP server will normally assume that the configuration information about a given network | + | |
- | known to be correct and is not authoritative. | + | segment is not known to be correct and is not authoritative. |
- | understanding how to configure it, it does not send spurious DHCPNAK messages | + | installs |
- | addresses from a legitimate DHCP server on the network. | + | DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the |
+ | network. | ||
- | | + | |
- | tive; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK | + | write authoritative; at the top of their configuration file to indicate that the DHCP server |
- | misconfigured | + | should |
- | subnets until their old lease has expired, which could take quite a long time. | + | unable to get a correct IP address after changing subnets until their old lease has expired, |
+ | which could take quite a long time. | ||
- | | + | |
- | to be set up so that it is aware of some networks for which it is authoritative | + | if a DHCP server is to be set up so that it is aware of some networks for which it is authori‐ |
- | is not, it may be more appropriate to declare authority on a per-network-segment basis. | + | |
+ | on a per-network-segment basis. | ||
- | Note that the most specific scope for which the concept of authority makes any sense is the | + | Note that the most specific scope for which the concept of authority makes any sense is the |
- | | + | physical network |
- | statement. | + | contained within a shared-network statement. |
- | network, | + | is authoritative |
- | some host declarations and not others. | + | nor is it meaningful to specify that the server is authoritative for some host declarations |
+ | and not others. | ||
The boot-unknown-clients statement | The boot-unknown-clients statement | ||
Zeile 1523: | Zeile 1646: | ||
| | ||
- | If the boot-unknown-clients statement is present and has a value of false or off, then clients for which there | + | If the boot-unknown-clients statement is present and has a value of false or off, then clients |
- | is no host declaration will not be allowed to obtain IP addresses. | + | for which there is no host declaration will not be allowed to obtain IP addresses. |
- | value of true or on, then clients without host declarations will be allowed to obtain IP addresses, as long as | + | statement |
- | those addresses are not restricted by allow and deny statements within their pool declarations. | + | will be allowed to obtain IP addresses, as long as those addresses are not restricted by allow |
+ | and deny statements within their pool declarations. | ||
The db-time-format statement | The db-time-format statement | ||
Zeile 1532: | Zeile 1656: | ||
| | ||
- | | + | The DHCP server software outputs several timestamps when writing leases to persistent storage. |
- | tion parameter selects one of two output formats. | + | This configuration |
- | while the local format | + | day, date, and time in UTC, while the local format prints the system seconds-since-epoch, |
- | system timezone in a comment. | + | helpfully provides the day and time in the system timezone in a comment. |
+ | described in detail in the dhcpd.leases(5) manpage. | ||
The ddns-hostname statement | The ddns-hostname statement | ||
Zeile 1541: | Zeile 1666: | ||
| | ||
- | The name parameter should be the hostname that will be used in setting up the client' | + | |
- | ddns-hostname | + | PTR records. |
- | that varies for each of the different update methods. | + | |
The ddns-domainname statement | The ddns-domainname statement | ||
Zeile 1549: | Zeile 1674: | ||
| | ||
- | The name parameter should be the domain name that will be appended to the client' | + | The name parameter should be the domain name that will be appended to the client' |
- | qualified domain-name (FQDN). | + | form a fully-qualified domain-name (FQDN). |
The ddns-rev-domainname statement | The ddns-rev-domainname statement | ||
- | | + | |
- | reversed IP address to produce a name for use in the client' | + | to the client' |
- | but the default can be overridden here. | + | default, this is " |
- | | + | The reversed IP address to which this domain name is appended is always the IP address of the |
- | quad notation, reversed - for example, if the IP address | + | client, |
- | reversed | + | client is 10.17.92.74, |
- | of 10.17.92.74.in-addr.arpa. | + | address would, by default, be given a PTR record of 10.17.92.74.in-addr.arpa. |
The ddns-update-style parameter | The ddns-update-style parameter | ||
Zeile 1567: | Zeile 1692: | ||
| | ||
- | The style parameter must be one of ad-hoc, interim or none. The ddns-update-style statement is only meaningful | + | |
- | in the outer scope - it is evaluated once after reading the dhcpd.conf file, rather than each time a client is | + | is only meaningful in the outer scope - it is evaluated |
- | assigned an IP address, so there is no way to use different | + | file, rather than each time a client is assigned an IP address, so there is no way to use dif‐ |
- | is none. | + | |
The ddns-updates statement | The ddns-updates statement | ||
Zeile 1576: | Zeile 1701: | ||
ddns-updates flag; | ddns-updates flag; | ||
- | | + | The ddns-updates parameter controls whether or not the server will attempt to do a DNS update |
- | confirmed. | + | when a lease is confirmed. |
- | updates | + | within a certain scope. |
- | update-style statement, setting the style to none. | + | in all scopes, it is preferable to use the ddns-update-style statement, setting the style to |
+ | none. | ||
The default-lease-time statement | The default-lease-time statement | ||
Zeile 1585: | Zeile 1711: | ||
| | ||
- | Time should be the length in seconds that will be assigned to a lease if the client requesting | + | Time should be the length in seconds that will be assigned to a lease if the client requesting |
- | not ask for a specific expiration time. This is used for both DHCPv4 and DHCPv6 leases (it is also known as the | + | the lease does not ask for a specific expiration time. This is used for both DHCPv4 and |
- | "valid lifetime" | + | DHCPv6 leases (it is also known as the "valid lifetime" |
+ | onds. | ||
The delayed-ack and max-ack-delay statements | The delayed-ack and max-ack-delay statements | ||
| | ||
- | Count should be an integer value from zero to 2^16-1, and defaults to 28. The count represents | + | |
- | replies | + | |
- | reached, a database commit event (commonly resulting in fsync() and representing a performance penalty) will be | + | |
- | made, and the reply packets will be transmitted in a batch afterwards. | + | fsync() and representing a performance penalty) will be made, and the reply packets |
- | that " | + | transmitted in a batch afterwards. |
- | returns | + | be updated prior to replying to clients. |
+ | | ||
- | | + | |
- | an fsync, and performing the fsync. | + | |
- | ond). | + | and defaults to 250,000 (1/4 of a second). |
- | | + | |
- | | + | piled in by default, but must be enabled at compile time with ´./ |
+ | ack´. | ||
The do-forward-updates statement | The do-forward-updates statement | ||
Zeile 1610: | Zeile 1740: | ||
| | ||
- | The do-forward-updates statement instructs the DHCP server as to whether it should | + | |
- | client' | + | update a DHCP client' |
- | are enabled and ddns-update-style is set to interim. | + | has no effect unless DNS updates are enabled and ddns-update-style is set to interim. |
- | is used to disable forward updates, the DHCP server will never attempt to update the client' | + | updates are enabled by default. |
- | only ever attempt to update the client' | + | DHCP server will never attempt to update the client' |
- | PTR | + | update the client' |
- | of the client-updates flag. | + | |
+ | honor the setting of the client-updates flag. | ||
The dynamic-bootp-lease-cutoff statement | The dynamic-bootp-lease-cutoff statement | ||
Zeile 1622: | Zeile 1753: | ||
| | ||
- | The dynamic-bootp-lease-cutoff statement sets the ending time for all leases | + | The dynamic-bootp-lease-cutoff statement sets the ending time for all leases assigned |
- | clients. | + | |
- | expire, by default dhcpd assigns infinite leases to all BOOTP clients. | + | don't know that their leases could expire, by default dhcpd assigns |
- | | + | BOOTP clients. |
- | when a facility is closed and all machines are required to be powered off. | + | BOOTP leases - for example, the end of a school term, or the time at night when a facility |
+ | closed and all machines are required to be powered off. | ||
- | Date should be the date on which all assigned BOOTP leases will end. The date is specified in the form: | + | Date should be the date on which all assigned BOOTP leases will end. The date is specified in |
+ | the form: | ||
- | | + | W YYYY/MM/DD HH:MM:SS |
- | W is the day of the week expressed as a number from zero (Sunday) to six (Saturday). | + | W is the day of the week expressed as a number from zero (Sunday) to six (Saturday). |
- | | + | the year, |
- | 1. HH is the hour, from zero to 23. MM is the minute and SS is the second. | + | the day of the month, counting from 1. HH is the hour, from zero to 23. MM is the minute and |
- | Universal Time (UTC), not local time. | + | SS is the second. |
The dynamic-bootp-lease-length statement | The dynamic-bootp-lease-length statement | ||
Zeile 1641: | Zeile 1774: | ||
| | ||
- | | + | |
- | clients. | + | assigned to BOOTP clients. |
- | used BOOTP or DHCP to get its address within a certain time period. | + | longer |
- | | + | time period. |
- | length, so a BOOTP client that boots frequently enough will never lose its lease. | + | using BOOTP during |
+ | client that boots frequently enough will never lose its lease. | ||
ter should be adjusted with extreme caution. | ter should be adjusted with extreme caution. | ||
Zeile 1652: | Zeile 1786: | ||
| | ||
- | The filename statement can be used to specify the name of the initial boot file which is to be loaded | + | The filename statement can be used to specify the name of the initial boot file which is to be |
- | client. | + | loaded by a client. |
- | expected to use to load the file. | + | protocol the client can be expected to use to load the file. |
The fixed-address declaration | The fixed-address declaration | ||
| | ||
- | The fixed-address declaration is used to assign one or more fixed IP addresses to a client. | + | |
- | appear | + | The fixed-address |
- | assigned the address that corresponds to the network on which it is booting. | + | It should only appear in a host declaration. |
- | fixed-address | + | the client boots, it will be assigned the address that corresponds to the network on which it |
- | the host declaration containing that fixed-address declaration. | + | is booting. |
- | should be either an IP address or a domain name that resolves to one or more IP addresses. | + | to which the client is connected, that client will not match the host declaration containing |
+ | that fixed-address declaration. | ||
+ | either an IP address or a domain name that resolves to one or more IP addresses. | ||
The fixed-address6 declaration | The fixed-address6 declaration | ||
Zeile 1670: | Zeile 1806: | ||
| | ||
- | The fixed-address6 declaration is used to assign a fixed IPv6 addresses to a client. | + | |
- | host declaration. | + | should only appear in a host declaration. |
The get-lease-hostnames statement | The get-lease-hostnames statement | ||
Zeile 1677: | Zeile 1813: | ||
| | ||
- | The get-lease-hostnames statement is used to tell dhcpd whether or not to look up the domain name corresponding | + | The get-lease-hostnames statement is used to tell dhcpd whether or not to look up the domain |
- | to the IP address of each address in the lease pool and use that address for the DHCP hostname option. | + | name corresponding |
- | is true, then this lookup is done for all addresses in the current scope. | + | for the DHCP hostname option. |
- | lookups are done. | + | the current scope. |
The hardware statement | The hardware statement | ||
Zeile 1686: | Zeile 1822: | ||
| | ||
- | | + | |
- | clause in the host statement. | + | using a hardware clause in the host statement. |
- | only the ethernet | + | hardware |
- | would also be desirable. | + | although support for a fddi hardware type (and others) would also be desirable. |
- | separated by colons. | + | address should be a set of hexadecimal octets (numbers from 0 through ff) separated by colons. |
+ | The hardware statement may also be used for DHCP clients. | ||
The host-identifier option statement | The host-identifier option statement | ||
Zeile 1696: | Zeile 1833: | ||
| | ||
- | | + | This identifies a DHCPv6 client in a host statement. |
- | for the option that the client will send. The option-data must be a constant value. | + | data is the value for the option that the client will send. The option-data must be a constant |
+ | value. | ||
The infinite-is-reserved statement | The infinite-is-reserved statement | ||
Zeile 1703: | Zeile 1841: | ||
| | ||
- | ISC DHCP now supports ´reserved´ leases. | + | ISC DHCP now supports ´reserved´ leases. |
- | server | + | flag is on, the server will automatically reserve leases allocated to clients which requested |
- | time. | + | an infinite (0xffffffff) lease-time. |
The default is off. | The default is off. | ||
Zeile 1713: | Zeile 1851: | ||
| | ||
- | Name should be the name of the DHCP server' | + | |
- | statement | + | / |
- | have no effect. | + | |
- | variable. | + | effect if overridden by the -lf flag or the PATH_DHCPD_DB environment variable. |
The limit-addrs-per-ia statement | The limit-addrs-per-ia statement | ||
Zeile 1722: | Zeile 1860: | ||
| | ||
- | | + | |
- | to permit clients to hang onto multiple addresses at a time, configure a larger number here. | + | address. |
+ | larger number here. | ||
- | Note that there is no present method to configure the server to forcibly | + | |
- | address per each subnet on a shared network. | + | with one IP address per each subnet on a shared network. |
The dhcpv6-lease-file-name statement | The dhcpv6-lease-file-name statement | ||
Zeile 1732: | Zeile 1871: | ||
| | ||
- | Name is the name of the lease file to use if and only if the server is running in DHCPv6 mode. By default, this | + | Name is the name of the lease file to use if and only if the server is running in DHCPv6 mode. |
- | is / | + | By default, this is / |
- | configuration | + | appear in the outer scope of the configuration file. It has no effect if overridden |
- | If dhcpv6-lease-file-name is not specified, but lease-file-name is, the latter value will be used. | + | -lf flag or the PATH_DHCPD6_DB environment variable. |
+ | fied, but lease-file-name is, the latter value will be used. | ||
The local-port statement | The local-port statement | ||
Zeile 1741: | Zeile 1881: | ||
| | ||
- | This statement causes the DHCP server to listen for DHCP requests on the UDP port specified in port, rather than | + | This statement causes the DHCP server to listen for DHCP requests on the UDP port specified in |
- | on port 67. | + | port, rather than on port 67. |
The local-address statement | The local-address statement | ||
Zeile 1748: | Zeile 1888: | ||
| | ||
- | | + | |
- | requests sent to all addresses. | + | address, rather than requests sent to all addresses. |
- | respond | + | clients implies that the server must respond to requests sent to the all-ones IP address, this |
- | attached networks...it is only realistically useful for a server whose only clients | + | option cannot be used if clients are on directly attached networks...it is only realistically |
- | such as via DHCP relay agents. | + | useful |
+ | agents. | ||
- | | + | |
- | which is default on a small number of operating systems, and must be explicitly chosen at compile-time | + | # |
- | others. | + | explicitly chosen at compile-time for all others. |
+ | with USE_SOCKETS if you see lines of this format at startup: | ||
Listening on Socket/eth0 | Listening on Socket/eth0 | ||
- | | + | |
- | | + | address may be supported |
The log-facility statement | The log-facility statement | ||
| | ||
- | This statement causes the DHCP server to do all of its logging on the specified log facility once the dhcpd.conf | ||
- | | ||
- | auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, ntp, security, syslog, user, uucp, and local0 | ||
- | | ||
- | | ||
- | In addition to setting this value, you may need to modify your syslog.conf file to configure logging of the DHCP | + | This statement causes the DHCP server to do all of its logging on the specified |
- | server. | + | |
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | In addition | ||
+ | logging of the DHCP server. | ||
local7.debug / | local7.debug / | ||
- | | + | The syntax of the syslog.conf file may be different on some operating systems |
- | page to be sure. To get syslog to start logging to the new file, you must first create the file with correct | + | syslog.conf |
- | ownership | + | first create the file with correct ownership and permissions (usually, the same owner and per‐ |
- | | + | |
- | or program | + | to syslogd. |
- | doesn' | + | |
+ | grow uncontrollably. | ||
- | | + | |
- | dhcpd.conf | + | while parsing the dhcpd.conf file or before parsing it are logged to the default log facility. |
- | file included with this distribution, | + | To prevent this, see the README file included with this distribution, |
- | | + | change |
- | that the log will be as complete as possible. | + | startup message a second time after parsing the configuration file, so that the log will be as |
+ | complete as possible. | ||
The max-lease-time statement | The max-lease-time statement | ||
Zeile 1794: | Zeile 1940: | ||
| | ||
- | Time should be the maximum length in seconds that will be assigned to a lease. | + | |
- | | + | defined, the default |
- | | + | BOOTP lease lengths, which are not specified |
The min-lease-time statement | The min-lease-time statement | ||
| | ||
- | Time should be the minimum length in seconds that will be assigned to a lease. | + | |
- | 300 seconds or max-lease-time. | + | Time should be the minimum length in seconds that will be assigned to a lease. |
+ | the minimum of 300 seconds or max-lease-time. | ||
The min-secs statement | The min-secs statement | ||
Zeile 1808: | Zeile 1955: | ||
| | ||
- | | + | |
- | DHCP server will respond to its request. | + | lease before |
- | maximum value that the client can report is 255 seconds. | + | what the client reports, and the maximum value that the client |
- | server not responding to the client' | + | Generally, |
+ | first request, but always responding to its second request. | ||
- | This can be used to set up a secondary DHCP server which never offers an address to a client until the primary | + | This can be used to set up a secondary DHCP server which never offers an address to a client |
- | server | + | until the primary server has been given a chance to do so. If the primary server is down, the |
- | server, but otherwise clients should always bind to the primary. Note that this does not, by itself, | + | client will bind to the secondary server, but otherwise clients should always bind to the pri‐ |
- | primary server and a secondary server to share a pool of dynamically-allocatable addresses. | + | mary. |
+ | share a pool of dynamically-allocatable addresses. | ||
The next-server statement | The next-server statement | ||
Zeile 1822: | Zeile 1971: | ||
| | ||
- | | + | The next-server statement is used to specify the host address of the server |
- | (specified in the filename statement) is to be loaded. | + | initial |
- | name. If no next-server statement applies to a given client, the address 0.0.0.0 is used. | + | be a numeric IP address or a domain name. If no next-server |
+ | client, the address 0.0.0.0 is used. | ||
The omapi-port statement | The omapi-port statement | ||
Zeile 1830: | Zeile 1980: | ||
| | ||
- | | + | |
- | statement is required to enable the OMAPI protocol, which is used to examine and modify the state of the DHCP | + | |
- | server as it is running. | + | and modify the state of the DHCP server as it is running. |
The one-lease-per-client statement | The one-lease-per-client statement | ||
Zeile 1838: | Zeile 1988: | ||
| | ||
- | If this flag is enabled, whenever a client sends a DHCPREQUEST for a particular lease, the server will automati‐ | + | |
- | cally free any other leases the client holds. | + | server will automatically |
- | forgotten | + | client |
- | it does not remember leases it's holding on networks to which it is not currently attached. | + | i.e., the client has only a single network interface and it does not remember |
- | assumptions are guaranteed or provable, so we urge caution in the use of this statement. | + | holding |
+ | | ||
The pid-file-name statement | The pid-file-name statement | ||
Zeile 1848: | Zeile 1999: | ||
| | ||
- | | + | Name should be the name of the DHCP server' |
- | process ID is stored when the server starts. | + | DHCP |
- | statement, | + | / |
- | | + | outer scope of the configuration file. It has no effect if overridden |
+ | PATH_DHCPD_PID environment variable. | ||
The dhcpv6-pid-file-name statement | The dhcpv6-pid-file-name statement | ||
Zeile 1857: | Zeile 2009: | ||
dhcpv6-pid-file-name name; | dhcpv6-pid-file-name name; | ||
- | Name is the name of the pid file to use if and only if the server is running in DHCPv6 | + | Name is the name of the pid file to use if and only if the server |
- | | + | |
- | | + | |
- | able. If dhcpv6-pid-file-name is not specified, but pid-file-name is, the latter value will be used. | + | |
+ | | ||
The ping-check statement | The ping-check statement | ||
Zeile 1866: | Zeile 2019: | ||
ping-check flag; | ping-check flag; | ||
- | When the DHCP server is considering dynamically allocating an IP address to a client, it first sends an ICMP | + | When the DHCP server is considering dynamically allocating an IP address to a client, |
- | | + | |
- | | + | |
- | | + | |
- | This ping check introduces a default one-second delay in responding to DHCPDISCOVER | + | This ping check introduces a default one-second delay in responding to DHCPDISCOVER |
- | | + | sages, which can be a problem for some clients. |
- | ter. The ping-check configuration parameter can be used to control checking - if its value is false, no ping | + | |
- | | + | |
The ping-timeout statement | The ping-timeout statement | ||
Zeile 1880: | Zeile 2033: | ||
ping-timeout seconds; | ping-timeout seconds; | ||
- | If the DHCP server determined it should send an ICMP echo request (a ping) because the ping-check statement | + | If the DHCP server determined it should send an ICMP echo request |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
+ | | ||
The preferred-lifetime statement | The preferred-lifetime statement | ||
Zeile 1890: | Zeile 2044: | ||
preferred-lifetime seconds; | preferred-lifetime seconds; | ||
- | IPv6 addresses have ´valid´ and ´preferred´ lifetimes. | + | IPv6 addresses |
- | | + | |
- | | + | |
- | | + | |
- | The preferred lifetime defaults to the renew+rebind timers, or 3/4 the default lease time if none were speci‐ | + | The preferred lifetime defaults to the renew+rebind timers, or 3/4 the default |
- | fied. | + | |
The remote-port statement | The remote-port statement | ||
Zeile 1902: | Zeile 2056: | ||
remote-port port; | remote-port port; | ||
- | This statement causes the DHCP server to transmit DHCP responses to DHCP clients upon the UDP port specified | + | This statement |
- | | + | |
- | | + | |
- | | + | |
- | | + | mits |
+ | | ||
The server-identifier statement | The server-identifier statement | ||
Zeile 1912: | Zeile 2067: | ||
server-identifier hostname; | server-identifier hostname; | ||
- | The server-identifier | + | The server-identifier statement can be used to define the value that is sent in the DHCP |
- | option for a given scope. | + | |
- | able by all clients served by a particular scope. | + | |
- | The use of the server-identifier statement is not recommended - the only reason to use it is to force a value | + | The use of the server-identifier statement is not recommended - the only reason to use it |
- | | + | |
- | | + | |
+ | | ||
- | The usual case where the server-identifier statement needs to be sent is when a physical interface has more | + | The usual case where the server-identifier statement needs to be sent is when a physical |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | Supplying | + | Supplying |
- | | + | |
The server-duid statement | The server-duid statement | ||
Zeile 1937: | Zeile 2093: | ||
server-duid LL [ hardware-type hardware-address ] ; | server-duid LL [ hardware-type hardware-address ] ; | ||
- | The server-duid statement configures the server DUID. You may pick either LLT (link local address plus time), | + | The server-duid statement configures the server DUID. You may pick either LLT (link local |
- | | + | |
- | If you choose LLT or LL, you may specify the exact contents of the DUID. Otherwise the server will generate | + | If you choose |
- | | + | |
If you choose EN, you must include the enterprise number and the enterprise-identifier. | If you choose EN, you must include the enterprise number and the enterprise-identifier. | ||
+ | |||
The default server-duid type is LLT. | The default server-duid type is LLT. | ||
Zeile 1950: | Zeile 2107: | ||
server-name name ; | server-name name ; | ||
- | The server-name statement can be used to inform the client of the name of the server from which it is | + | The server-name statement can be used to inform the client of the name of the server |
- | ing. Name should be the name that will be provided to the client. | + | |
The site-option-space statement | The site-option-space statement | ||
Zeile 1957: | Zeile 2114: | ||
site-option-space name ; | site-option-space name ; | ||
- | The site-option-space | + | The site-option-space statement can be used to determine from what option space site-local |
- | | + | |
- | | + | |
- | cific uses, but are frequently used by vendors of embedded hardware | + | |
- | | + | |
- | | + | |
- | | + | |
- | ditional | + | |
+ | | ||
The stash-agent-options statement | The stash-agent-options statement | ||
Zeile 1970: | Zeile 2128: | ||
stash-agent-options flag; | stash-agent-options flag; | ||
- | If the stash-agent-options parameter is true for a given client, the server | + | If the stash-agent-options parameter is true for a given client, the server will record the |
- | information options sent during the client' | + | |
- | | + | |
- | | + | |
- | | + | |
+ | | ||
directly to the server and not sent through a relay agent. | directly to the server and not sent through a relay agent. | ||
Zeile 1981: | Zeile 2140: | ||
update-conflict-detection flag; | update-conflict-detection flag; | ||
- | If the update-conflict-detection parameter is true, the server will perform standard DHCID multiple-client, | + | If the update-conflict-detection parameter is true, the server will perform standard DHCID |
- | | + | |
- | | + | |
- | | + | |
The update-optimization statement | The update-optimization statement | ||
Zeile 1990: | Zeile 2149: | ||
update-optimization flag; | update-optimization flag; | ||
- | If the update-optimization parameter is false for a given client, the server will attempt a DNS update | + | If the update-optimization parameter is false for a given client, the server will attempt a |
- | | + | |
- | | + | ing an update when it appears to be necessary. |
- | | + | base |
- | | + | |
- | | + | |
- | | + | |
+ | | ||
+ | | ||
The update-static-leases statement | The update-static-leases statement | ||
Zeile 2002: | Zeile 2163: | ||
update-static-leases flag; | update-static-leases flag; | ||
- | The update-static-leases flag, if enabled, causes the DHCP server to do DNS updates for clients even if those | + | The update-static-leases flag, if enabled, causes the DHCP server to do DNS updates |
- | clients | + | |
- | | + | |
- | | + | |
- | | + | |
- | lease, which could have a significant performance impact in environments that place heavy demands on the DHCP | + | |
- | | + | lease, which could have a significant performance impact in environments that place heavy |
+ | | ||
The use-host-decl-names statement | The use-host-decl-names statement | ||
Zeile 2014: | Zeile 2176: | ||
use-host-decl-names flag; | use-host-decl-names flag; | ||
- | If the use-host-decl-names parameter is true in a given scope, then for every host | + | If the use-host-decl-names parameter is true in a given scope, then for every host declara‐ |
- | | + | tion within that scope, the name provided for the host declaration will be supplied to the |
- | | + | |
group { | group { | ||
Zeile 2035: | Zeile 2197: | ||
} | } | ||
- | An option host-name statement within a host declaration will override the use of the name in the host | + | An option |
- | ration. | + | |
- | It should | + | It should be noted here that most DHCP clients completely ignore the host-name option |
- | | + | |
- | | + | |
- | | + | |
+ | | ||
The use-lease-addr-for-default-route statement | The use-lease-addr-for-default-route statement | ||
Zeile 2047: | Zeile 2210: | ||
use-lease-addr-for-default-route flag; | use-lease-addr-for-default-route flag; | ||
- | If the use-lease-addr-for-default-route parameter is true in a given scope, then instead of sending the value | + | If the use-lease-addr-for-default-route parameter is true in a given scope, then instead of |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
+ | | ||
The vendor-option-space statement | The vendor-option-space statement | ||
Zeile 2057: | Zeile 2221: | ||
vendor-option-space string; | vendor-option-space string; | ||
- | The vendor-option-space parameter determines from what option space vendor options are taken. | + | The vendor-option-space |
- | | + | |
- | | + | ual page, in the VENDOR ENCAPSULATED OPTIONS section. |
SETTING PARAMETER VALUES USING EXPRESSIONS | SETTING PARAMETER VALUES USING EXPRESSIONS | ||
- | | + | |
- | has sent. | + | value that the client has sent. To do this, you can use expression |
- | expressions. | + | eval(5) |
+ | to an option, define the option as follows: | ||
| | ||
Zeile 2074: | Zeile 2239: | ||
RESERVED LEASES | RESERVED LEASES | ||
- | | + | |
- | with fixed-address | + | Host statements with fixed-address clauses exist to a certain extent to serve this purpose, but |
- | intended to approximate ´static configuration´, | + | because host statements are intended to approximate ´static configuration´, |
- | Services, such as dynamic DNS, failover, ´on events´ and so forth. | + | being referenced |
- | + | | |
- | If a standard dynamic lease, as from any range statement, is marked ´reserved´, | + | |
- | this lease to the client it is identified by (be that by client identifier or hardware address). | + | |
- | + | ||
- | In practice, this means that the lease follows the normal state engine, enters ACTIVE state when the client | + | |
- | | + | |
- | | + | |
- | | + | |
- | the state it may allocate from - and the leases are not placed on the queue for allocation | + | |
- | | + | |
- | | + | |
- | If a standard dynamic lease, as from any range statement, is marked ´reserved´, | + | If a standard dynamic lease, as from any range statement, is marked ´reserved´, |
- | this lease to the client it is identified by (be that by client identifier or hardware address). | + | will only allocate this lease to the client it is identified by (be that by client identifier or |
+ | hardware address). | ||
- | In practice, this means that the lease follows the normal state engine, enters ACTIVE state when the client | + | In practice, this means that the lease follows the normal state engine, enters ACTIVE state when |
- | bound to it, expires, | + | the client |
- | events are processed normally, as with any other dynamic lease. | + | |
- | treat reserved | + | |
- | the state it may allocate from - and the leases are not placed on the queue for allocation | + | the FREE or BACKUP states - each server applies the lease into the state it may allocate from - |
- | Instead | + | and the leases |
+ | only be ´found´ by client identity. | ||
ing client. | ing client. | ||
- | Care should probably be taken to ensure that the client only has one lease within a given subnet that it is | + | Care should probably be taken to ensure that the client only has one lease within a given subnet |
- | | + | that it is identified |
- | | + | |
- | this is applicable to your environment and mixture of clients). | + | |
- | It should also be noted that leases marked ´reserved´ are effectively treated the same as leases marked ´bootp´. | + | It should also be noted that leases marked ´reserved´ are effectively treated the same as leases |
+ | marked ´bootp´. | ||
REFERENCE: OPTION STATEMENTS | REFERENCE: OPTION STATEMENTS | ||
Zeile 2113: | Zeile 2271: | ||
REFERENCE: EXPRESSIONS | REFERENCE: EXPRESSIONS | ||
- | | + | |
+ | | ||
SEE ALSO | SEE ALSO | ||
Zeile 2119: | Zeile 2278: | ||
AUTHOR | AUTHOR | ||
- | | + | |
- | Internet Systems Consortium. | + | project was provided by Internet Systems Consortium. |
+ | | ||
- | | + | |
+ | |||
+ | | ||
</ | </ | ||
=== Konfigurationsbeispiel === | === Konfigurationsbeispiel === | ||
Zeile 2464: | Zeile 2626: | ||
| | ||
</ | </ | ||
+ | |||
====== Links ====== | ====== Links ====== | ||
* **[[wiki: | * **[[wiki: | ||
* **[[http:// | * **[[http:// | ||
- | ~~DISCUSSION~~ | ||