Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
centos:dhcp_c7 [11.02.2016 10:10. ] – [Optimierung bei mehreren Netzwerkkarten] 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 152: | Zeile 152: | ||
==== IPv4 ==== | ==== IPv4 ==== | ||
+ | === dhcp manpage === | ||
+ | # man 5 dhcpd.conf | ||
+ | |||
+ | < | ||
+ | |||
+ | |||
+ | |||
+ | NAME | ||
+ | | ||
+ | |||
+ | DESCRIPTION | ||
+ | | ||
+ | tium DHCP Server. | ||
+ | |||
+ | The dhcpd.conf file is a free-form ASCII text file. | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | to do something (e.g., should dhcpd provide addresses to unknown clients), or what parameters to | ||
+ | | ||
+ | |||
+ | | ||
+ | work, to provide addresses that can be assigned to clients, or to apply a group of parameters to | ||
+ | a group of declarations. | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | tions where only known clients will be served, each such client must have a host declaration. | ||
+ | | ||
+ | | ||
+ | |||
+ | For every subnet which will be served, and for every subnet to which the dhcp server | ||
+ | | ||
+ | is on that subnet. | ||
+ | be dynamically allocated on that subnet. | ||
+ | |||
+ | | ||
+ | ple, if there is a site-wide requirement that 8-bit subnet masks be used, but a department | ||
+ | a single physical ethernet network expands to the point where it has more than 254 nodes, it may | ||
+ | be necessary to run two 8-bit subnets on the same ethernet until such time as a new physical | ||
+ | | ||
+ | | ||
+ | |||
+ | Note that even when the shared-network declaration is absent, an empty one is created | ||
+ | | ||
+ | | ||
+ | fore subnets) will receive the same configuration as stateful ones. | ||
+ | |||
+ | Some sites may have departments which have clients on more than one subnet, but it may be desir‐ | ||
+ | able to offer those clients a uniform set of parameters which are different than what would be | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | used to group parameter assignments based on information the client sends. | ||
+ | |||
+ | | ||
+ | host declaration (if any), and then consulting any class declarations matching the client, | ||
+ | | ||
+ | | ||
+ | | ||
+ | never considered twice, and if parameters are declared in more than one scope, | ||
+ | | ||
+ | |||
+ | | ||
+ | which has a fixed-address declaration that lists an IP address that is valid for the subnet | ||
+ | | ||
+ | find an entry which has no fixed-address declaration. | ||
+ | |||
+ | EXAMPLES | ||
+ | A typical dhcpd.conf file will look something like this: | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | range 204.254.239.10 204.254.239.30; | ||
+ | } | ||
+ | |||
+ | | ||
+ | | ||
+ | range 204.254.239.42 204.254.239.62; | ||
+ | } | ||
+ | |||
+ | | ||
+ | | ||
+ | range 204.254.239.74 204.254.239.94; | ||
+ | } | ||
+ | |||
+ | group { | ||
+ | | ||
+ | host zappo.test.isc.org { | ||
+ | | ||
+ | } | ||
+ | host beppo.test.isc.org { | ||
+ | | ||
+ | } | ||
+ | host harpo.test.isc.org { | ||
+ | | ||
+ | } | ||
+ | } | ||
+ | |||
+ | | ||
+ | |||
+ | |||
+ | | ||
+ | | ||
+ | mon to the entire organization), | ||
+ | |||
+ | option domain-name " | ||
+ | option domain-name-servers ns1.isc.org, | ||
+ | |||
+ | | ||
+ | |||
+ | As you can see in Figure 2, you can specify host addresses | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | option routers 204.254.239.1; | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | 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 | ||
+ | hosts - zappo, beppo and harpo. | ||
+ | | ||
+ | these hosts: | ||
+ | |||
+ | option domain-name " | ||
+ | |||
+ | Also, given the domain they' | ||
+ | DHCP leasing mechanism, we might set the lease timeout somewhat shorter than the default: | ||
+ | |||
+ | max-lease-time 120; | ||
+ | default-lease-time 120; | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | 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). | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | the parameter appears. | ||
+ | |||
+ | | ||
+ | of models, and you want to specify the boot files for each model. | ||
+ | to have host declarations for each server and group them by model: | ||
+ | |||
+ | group { | ||
+ | | ||
+ | | ||
+ | |||
+ | host ncd1 { hardware ethernet 0: | ||
+ | host ncd4 { hardware ethernet 0: | ||
+ | host ncd8 { hardware ethernet 0: | ||
+ | } | ||
+ | |||
+ | group { | ||
+ | | ||
+ | | ||
+ | |||
+ | host ncd2 { hardware ethernet 0: | ||
+ | host ncd3 { hardware ethernet 0: | ||
+ | } | ||
+ | |||
+ | group { | ||
+ | | ||
+ | | ||
+ | |||
+ | host ncd1 { hardware ethernet 0: | ||
+ | host ncd4 { hardware ethernet 0: | ||
+ | host ncd8 { hardware ethernet 0: | ||
+ | } | ||
+ | |||
+ | ADDRESS POOLS | ||
+ | The pool declaration can be used to specify a pool of addresses that will be treated differently | ||
+ | than another pool of addresses, even on the same network segment or subnet. | ||
+ | | ||
+ | | ||
+ | lease times, that are available for unknown clients. | ||
+ | | ||
+ | | ||
+ | would set up a pair of pool declarations: | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | # Unknown clients get this pool. | ||
+ | pool { | ||
+ | | ||
+ | | ||
+ | range 10.0.0.200 10.0.0.253; | ||
+ | allow unknown-clients; | ||
+ | } | ||
+ | |||
+ | # Known clients get this pool. | ||
+ | pool { | ||
+ | | ||
+ | | ||
+ | range 10.0.0.5 10.0.0.199; | ||
+ | deny unknown-clients; | ||
+ | } | ||
+ | } | ||
+ | |||
+ | It is also possible to set up entirely different subnets for known and unknown clients - address | ||
+ | | ||
+ | on different subnets. | ||
+ | |||
+ | As you can see in the preceding example, pools can have permit lists that control which clients | ||
+ | | ||
+ | duced with the allow or deny keyword. | ||
+ | | ||
+ | | ||
+ | | ||
+ | that match the permit list and do not match the deny list will be allowed access. | ||
+ | |||
+ | DYNAMIC ADDRESS ALLOCATION | ||
+ | | ||
+ | | ||
+ | tiate or renew that lease, the server has only three choices - it can ignore | ||
+ | | ||
+ | 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 | ||
+ | | ||
+ | | ||
+ | | ||
+ | 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' | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | When the DHCP server allocates a new address for a client (remember, this only happens | ||
+ | | ||
+ | on an IP address, or if there is an old IP address the client had before that hasn' | ||
+ | | ||
+ | is still permitted to use it. If the client is no longer permitted to use it, the lease is | ||
+ | | ||
+ | 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 will look in the list of address pools for the network segment to which the client is | ||
+ | | ||
+ | | ||
+ | | ||
+ | pool allows the client to be allocated an address from that pool, the pool is examined to see if | ||
+ | there is an address available. | ||
+ | | ||
+ | | ||
+ | |||
+ | If an address is found that the client is permitted to have, and that has never been assigned to | ||
+ | any client before, the address is immediately allocated to the client. | ||
+ | able for allocation but has been previously assigned to a different client, the server will keep | ||
+ | | ||
+ | |||
+ | The DHCP server generates the list of available IP addresses from a hash table. | ||
+ | the addresses are not sorted in any particular order, and so it is not possible to predict | ||
+ | | ||
+ | ISC DHCP server may have become accustomed to the DHCP server allocating IP addresses in ascend‐ | ||
+ | | ||
+ | | ||
+ | |||
+ | IP ADDRESS CONFLICT PREVENTION | ||
+ | The DHCP server checks IP addresses to see if they are in use before allocating them to clients. | ||
+ | | ||
+ | ICMP Echo reply is received within a second, the address is assumed to be free. | ||
+ | done for leases that have been specified in range statements, and only when the lease is thought | ||
+ | by the DHCP server to be free - i.e., the DHCP server or its failover peer has not listed | ||
+ | lease as in use. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | 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 | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | DHCP FAILOVER | ||
+ | | ||
+ | | ||
+ | | ||
+ | that this implementation conforms to the standard. | ||
+ | make sure that both failover peers are running the same version of the ISC DHCP server. | ||
+ | |||
+ | | ||
+ | | ||
+ | time for allocation. | ||
+ | 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. | ||
+ | |||
+ | | ||
+ | down, in which case the remaining server will (over time) reclaim all the addresses | ||
+ | | ||
+ | into the PARTNER-DOWN state. | ||
+ | |||
+ | You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by | ||
+ | | ||
+ | ing the server. | ||
+ | |||
+ | | ||
+ | my state partner-down; | ||
+ | peer state state at date; | ||
+ | } | ||
+ | |||
+ | 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 | ||
+ | | ||
+ | then both servers will resume processing together. | ||
+ | |||
+ | It is possible to get into a dangerous situation: if you put one server | ||
+ | | ||
+ | will not know that the first server was in the PARTNER-DOWN state, and may issue addresses | ||
+ | | ||
+ | | ||
+ | not restart automatically. | ||
+ | |||
+ | The failover protocol defines a primary server role and a secondary server role. There are some | ||
+ | | ||
+ | | ||
+ | must be configured as primary, and the other must be configured as secondary, | ||
+ | | ||
+ | |||
+ | FAILOVER STARTUP | ||
+ | When a server starts that has not previously communicated with its failover peer, it must estab‐ | ||
+ | lish communications with its failover peer and synchronize with it before it can serve clients. | ||
+ | | ||
+ | for the first time, or because one of your failover servers has failed catastrophically and lost | ||
+ | its database. | ||
+ | |||
+ | | ||
+ | base and then resynchronizes, | ||
+ | | ||
+ | and attempts to contact its peer. | ||
+ | |||
+ | When it has established contact, it asks the peer for a complete copy its peer's lease database. | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | While the failed server is recovering, its partner remains | ||
+ | | ||
+ | | ||
+ | |||
+ | In the case where both servers detect that they have never before communicated with their part‐ | ||
+ | | ||
+ | In this case, no service will be provided to DHCP clients until MCLT has expired. | ||
+ | |||
+ | CONFIGURING FAILOVER | ||
+ | In order to configure failover, you need to write a peer declaration | ||
+ | | ||
+ | want to do failover. | ||
+ | You must not tell one server it's doing failover on a particular address pool and tell the other | ||
+ | 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 { | ||
+ | failover peer " | ||
+ | pool specific parameters | ||
+ | }; | ||
+ | |||
+ | | ||
+ | in pools that you are using failover for. | ||
+ | |||
+ | | ||
+ | | ||
+ | do failover, but don't do any mixed pools. | ||
+ | | ||
+ | the master file. This will help you to avoid configuration | ||
+ | | ||
+ | mary server might look like this: | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | port 647; | ||
+ | peer address trantor.rc.vix.com; | ||
+ | peer port 847; | ||
+ | | ||
+ | | ||
+ | mclt 3600; | ||
+ | split 128; | ||
+ | load balance max seconds 3; | ||
+ | } | ||
+ | |||
+ | | ||
+ | |||
+ | The statements in the peer declaration are as follows: | ||
+ | |||
+ | The primary and secondary statements | ||
+ | |||
+ | [ primary | secondary ]; | ||
+ | |||
+ | This determines whether the server is primary or secondary, as described | ||
+ | | ||
+ | |||
+ | The address statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | for connections from its failover peer, and also the value to use for the DHCP Failover Proto‐ | ||
+ | col server identifier. | ||
+ | |||
+ | The peer address statement | ||
+ | |||
+ | peer address address; | ||
+ | |||
+ | The peer address statement declares the IP address or DNS name to which the server should con‐ | ||
+ | nect to reach its failover peer for failover messages. | ||
+ | |||
+ | The port statement | ||
+ | |||
+ | port port-number; | ||
+ | |||
+ | The port statement declares the TCP port on which the server | ||
+ | | ||
+ | | ||
+ | |||
+ | The peer port statement | ||
+ | |||
+ | peer port port-number; | ||
+ | |||
+ | The peer port statement declares the TCP port to which the server should connect to reach its | ||
+ | | ||
+ | | ||
+ | |||
+ | The max-response-delay statement | ||
+ | |||
+ | | ||
+ | |||
+ | The max-response-delay statement tells the DHCP server | ||
+ | | ||
+ | | ||
+ | | ||
+ | the server isn't constantly making and breaking connections. | ||
+ | fied. | ||
+ | |||
+ | The max-unacked-updates statement | ||
+ | |||
+ | | ||
+ | |||
+ | The max-unacked-updates statement tells the remote DHCP server how many BNDUPD messages it can | ||
+ | send before it receives a BNDACK from the local system. | ||
+ | | ||
+ | | ||
+ | |||
+ | The mclt statement | ||
+ | |||
+ | mclt seconds; | ||
+ | |||
+ | The mclt statement defines the Maximum Client Lead Time. It must be specified on the primary, | ||
+ | | ||
+ | be renewed by either failover peer without contacting the other. | ||
+ | | ||
+ | DOWN state. | ||
+ | | ||
+ | mind that we have no real operational experience with this. | ||
+ | |||
+ | The split statement | ||
+ | |||
+ | split index; | ||
+ | |||
+ | The split statement specifies the split between the primary and secondary for the purposes | ||
+ | | ||
+ | | ||
+ | | ||
+ | index is not set, the secondary is responsible. | ||
+ | | ||
+ | serve more clients than the secondary. | ||
+ | | ||
+ | |||
+ | The hba statement | ||
+ | |||
+ | hba colon-separated-hex-list; | ||
+ | |||
+ | | ||
+ | than a cutoff, which theoretically allows for finer-grained control. | ||
+ | | ||
+ | |||
+ | hba ff: | ||
+ | | ||
+ | |||
+ | | ||
+ | also equivalent to a split of 128, but are not identical: | ||
+ | |||
+ | hba aa: | ||
+ | | ||
+ | |||
+ | hba 55: | ||
+ | | ||
+ | |||
+ | They are equivalent, because half the bits are set to 0, half are set to 1 (0xa and 0x5 are | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | You must only have split or hba defined, never both. For most cases, the fine-grained control | ||
+ | that hba offers isn't necessary, and split should be used. | ||
+ | |||
+ | The load balance max seconds statement | ||
+ | |||
+ | load balance max seconds seconds; | ||
+ | |||
+ | This statement allows you to configure a cutoff after which load balancing is disabled. | ||
+ | | ||
+ | | ||
+ | | ||
+ | of this is that if one of the failover peers gets into a state where it is responding | ||
+ | | ||
+ | take over its client load automatically as the clients retry. | ||
+ | |||
+ | The auto-partner-down statement | ||
+ | |||
+ | | ||
+ | |||
+ | This statement instructs the server to initiate a timed delay upon entering | ||
+ | | ||
+ | At the conclusion of the timer, the server will automatically enter the partner-down | ||
+ | | ||
+ | | ||
+ | time (the two servers will give conflicting bindings). | ||
+ | |||
+ | Think very carefully before enabling this feature. | ||
+ | | ||
+ | | ||
+ | to requests from DHCP clients. | ||
+ | ments where the failover servers are directly connected to one another, such as by a dedicated | ||
+ | | ||
+ | |||
+ | A zero value disables the auto-partner-down feature (also the default), and any positive value | ||
+ | | ||
+ | |||
+ | The Failover pool balance statements. | ||
+ | |||
+ | max-lease-misbalance percentage; | ||
+ | max-lease-ownership percentage; | ||
+ | min-balance seconds; | ||
+ | max-balance seconds; | ||
+ | |||
+ | This version of the DHCP Server evaluates pool balance on a schedule, rather than on demand as | ||
+ | | ||
+ | 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. | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | When pool balance is performed, the only plausible expectation is to provide a 50/50 split of | ||
+ | | ||
+ | | ||
+ | | ||
+ | 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 " | ||
+ | To Send" | ||
+ | | ||
+ | The resulting value is signed: if it is positive, the local server is expected | ||
+ | | ||
+ | | ||
+ | (give or take one lease in the case of an odd number of total free state leases). | ||
+ | |||
+ | | ||
+ | ence of the max-lease-misbalance statement. | ||
+ | | ||
+ | cent, then the server will skip balancing a given pool (it won' | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | would be consumed (and thus, how long it would take to use all leases in that state). | ||
+ | | ||
+ | the min-balance and max-balance configured values. | ||
+ | moved in a downwards direction, it is never increased. | ||
+ | this number in the negative direction, the local server will ´panic´ and transmit | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | In the first pass, only leases whose most recent bound client would have been served | ||
+ | | ||
+ | | ||
+ | | ||
+ | tive of the total number of leases multiplied by the max-lease-ownership percentage. | ||
+ | | ||
+ | of giving the peer more than a 50/50 share of leases in the hopes that their clients | ||
+ | | ||
+ | to as ´MAC Address Affinity´, but this is somewhat misnamed: it applies equally to DHCP Client | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | total number of free state leases multiplied by the max-lease-ownership percentage. | ||
+ | | ||
+ | ance Algorithm, and this continues until the lts falls under this value. | ||
+ | | ||
+ | | ||
+ | |||
+ | So, the max-lease-misbalance value acts as a behavioural gate. Smaller values will cause more | ||
+ | | ||
+ | | ||
+ | |||
+ | The max-lease-ownership value permits a small (percentage) skew in the lease balance of a per‐ | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | must therefore have 100% of the leases in its respective free state). | ||
+ | | ||
+ | | ||
+ | 15. | ||
+ | |||
+ | | ||
+ | the limit of your local time_t value), but default to values | ||
+ | place balance events between 1 minute and 1 hour). | ||
+ | |||
+ | CLIENT CLASSING | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | To add clients to classes based on conditional evaluation, you can specify a matching expression | ||
+ | in the class statement: | ||
+ | |||
+ | class " | ||
+ | match if substring (option dhcp-client-identifier, | ||
+ | } | ||
+ | |||
+ | Note that whether you use matching expressions or add statements (or both) to classify | ||
+ | you must always write a class declaration for any class that you use. If there will be no match | ||
+ | | ||
+ | |||
+ | class " | ||
+ | } | ||
+ | |||
+ | SUBCLASSES | ||
+ | In addition to classes, it is possible to declare subclasses. | ||
+ | | ||
+ | | ||
+ | match expressions and one class with five subclasses is that it will be quicker to find the sub‐ | ||
+ | | ||
+ | |||
+ | class " | ||
+ | match pick-first-value (option dhcp-client-identifier, | ||
+ | } | ||
+ | |||
+ | class " | ||
+ | match pick-first-value (option dhcp-client-identifier, | ||
+ | } | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | pool { | ||
+ | allow members of " | ||
+ | range 10.0.0.11 10.0.0.50; | ||
+ | } | ||
+ | pool { | ||
+ | allow members of " | ||
+ | range 10.0.0.51 10.0.0.100; | ||
+ | } | ||
+ | } | ||
+ | |||
+ | The data following the class name in the subclass declaration is a constant | ||
+ | | ||
+ | uate the match expression and then look the result up in the hash table. | ||
+ | the client is considered a member of both the class and the subclass. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | pose of the subclass were to define different parameter values for some clients, you might want | ||
+ | to declare some subclasses with scopes. | ||
+ | |||
+ | | ||
+ | while most didn' | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | } | ||
+ | |||
+ | In this example, we've used subclassing as a way to control address allocation on a per-client | ||
+ | | ||
+ | - for example, to use the value of the vendor-class-identifier option to determine | ||
+ | to send in the vendor-encapsulated-options option. | ||
+ | | ||
+ | |||
+ | PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION | ||
+ | You may specify a limit to the number of clients in a class that can be assigned | ||
+ | | ||
+ | a class with such a limit has reached its limit, the only way a new client in that class can get | ||
+ | | ||
+ | | ||
+ | |||
+ | class " | ||
+ | lease limit 4; | ||
+ | } | ||
+ | |||
+ | This will produce a class in which a maximum of four members may hold a lease at one time. | ||
+ | |||
+ | SPAWNING CLASSES | ||
+ | It is possible to declare a spawning class. | ||
+ | | ||
+ | was to make it possible to create lease-limited classes on the fly. The envisioned | ||
+ | | ||
+ | more than one IP address, but does not wish to provide such clients with their own subnet, | ||
+ | | ||
+ | | ||
+ | |||
+ | Many cable modem head-end systems can be configured to add a Relay Agent Information | ||
+ | DHCP packets when relaying them to the DHCP server. | ||
+ | | ||
+ | write a class declaration as follows: | ||
+ | |||
+ | class " | ||
+ | spawn with option agent.circuit-id; | ||
+ | lease limit 4; | ||
+ | } | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | the circuit ID, a new one will be created and logged in the dhcpd.leases file, and the client | ||
+ | | ||
+ | | ||
+ | limit of four leases. | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | 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 | ||
+ | | ||
+ | the match if and spawn with statements, or the match if and match statements. | ||
+ | |||
+ | class " | ||
+ | match if option dhcp-vendor-identifier = " | ||
+ | spawn with option agent.circuit-id; | ||
+ | lease limit 4; | ||
+ | } | ||
+ | |||
+ | class " | ||
+ | match if option dhcp-vendor-identifier = " | ||
+ | spawn with option agent.circuit-id; | ||
+ | lease limit 16; | ||
+ | } | ||
+ | |||
+ | This allows you to have two classes that both have the same spawn with expression | ||
+ | ting the clients in the two classes confused with each other. | ||
+ | |||
+ | DYNAMIC DNS UPDATES | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | Two DNS update schemes are currently implemented, | ||
+ | | ||
+ | | ||
+ | | ||
+ | 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 Dynamic DNS update scheme is now deprecated and does not work. In future releases of | ||
+ | the ISC DHCP server, this scheme will not likely be available. | ||
+ | | ||
+ | | ||
+ | |||
+ | The ad-hoc Dynamic DNS update scheme implemented in this version of the ISC DHCP server | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | For the ad-hoc DNS update method, the client' | ||
+ | name is determined. | ||
+ | |||
+ | The DHCP server determines the client' | ||
+ | tion option, and using that if it is present. | ||
+ | for a valid hostname in the FQDN option sent by the client. | ||
+ | wise, if the client sent a host-name option, that is used. Otherwise, if there is a host decla‐ | ||
+ | | ||
+ | these applies, the server will not have a hostname for the client, and will not be able to do a | ||
+ | DNS update. | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | So if this configuration option is not configured to a different value (over-riding | ||
+ | | ||
+ | | ||
+ | |||
+ | The client' | ||
+ | | ||
+ | was assigned in its lease. | ||
+ | | ||
+ | ing that its hostname is the name of some network server. | ||
+ | | ||
+ | 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, | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The DHCP protocol normally involves a four-packet exchange - first the client sends a DHCPDIS‐ | ||
+ | | ||
+ | | ||
+ | | ||
+ | DNS update if it has not sent one for the client' | ||
+ | | ||
+ | |||
+ | | ||
+ | it operates) will remove the client' | ||
+ | | ||
+ | PTR records. | ||
+ | |||
+ | THE INTERIM DNS UPDATE SCHEME | ||
+ | The interim DNS update scheme operates mostly according to several | ||
+ | | ||
+ | and there are some differences between our code and the final RFCs. We plan to update our code, | ||
+ | | ||
+ | the main material difference being that a DHCID RR was assigned in the RFCs whereas | ||
+ | | ||
+ | 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: | ||
+ | |||
+ | draft-ietf-dnsext-dhcid-rr-?? | ||
+ | draft-ietf-dhc-fqdn-option-?? | ||
+ | draft-ietf-dhc-ddns-resolution-?? | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | The first point to understand about this style of DNS update is that unlike | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | the statement ignore client-updates; | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | " | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | can update its own A record, assuming that the " | ||
+ | |||
+ | If the server is configured not to allow client updates, or if the client doesn' | ||
+ | own update, the server will simply choose a name for the client from either the fqdn option | ||
+ | | ||
+ | just as in the ad-hoc update scheme. | ||
+ | | ||
+ | fqdn option, the server uses only the leftmost part of the domain name - in the example | ||
+ | " | ||
+ | |||
+ | | ||
+ | a response in the DHCP packet, using the FQDN Option, that implies to the client that it should | ||
+ | | ||
+ | which indicates the client may not perform updates. | ||
+ | |||
+ | Also, if the use-host-decl-names configuration option is enabled, then the host declaration' | ||
+ | | ||
+ | | ||
+ | |||
+ | The other difference between the ad-hoc scheme and the interim scheme is that with the interim | ||
+ | | ||
+ | out accidentally deleting A records that shouldn' | ||
+ | | ||
+ | |||
+ | | ||
+ | over the DHCP client' | ||
+ | | ||
+ | | ||
+ | |||
+ | If the update fails because the A record already exists, then the DHCP server | ||
+ | the A record with the prerequisite that there must be a TXT record in the same name as the new A | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | low the RFCs. The RFCs call for a new DHCID RRtype while he interim DNS update | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | each DNS update involves a round trip to the DNS server, there is a cost associated | ||
+ | | ||
+ | or not it has updated the record in the past (this information is stored on the lease) and does | ||
+ | not attempt to update records that it thinks it has already updated. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | DYNAMIC DNS UPDATE SECURITY | ||
+ | When you set your DNS server up to allow updates from the DHCP server, you may be exposing it to | ||
+ | | ||
+ | | ||
+ | key, your updates should also be secure. | ||
+ | | ||
+ | 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 | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | thing like this: | ||
+ | |||
+ | key DHCP_UPDATER { | ||
+ | | ||
+ | | ||
+ | }; | ||
+ | |||
+ | zone " | ||
+ | type master; | ||
+ | file " | ||
+ | allow-update { key DHCP_UPDATER; | ||
+ | }; | ||
+ | |||
+ | zone " | ||
+ | type master; | ||
+ | file " | ||
+ | allow-update { key DHCP_UPDATER; | ||
+ | }; | ||
+ | |||
+ | | ||
+ | need to add something like this to your dhcpd.conf file: | ||
+ | |||
+ | key DHCP_UPDATER { | ||
+ | | ||
+ | | ||
+ | }; | ||
+ | |||
+ | zone EXAMPLE.ORG. { | ||
+ | | ||
+ | key DHCP_UPDATER; | ||
+ | } | ||
+ | |||
+ | zone 17.127.10.in-addr.arpa. { | ||
+ | | ||
+ | key DHCP_UPDATER; | ||
+ | } | ||
+ | |||
+ | The primary statement specifies the IP address of the name server whose zone information | ||
+ | | ||
+ | | ||
+ | The secondaries provide for additional addresses for name servers to be used if the primary does | ||
+ | not respond. | ||
+ | | ||
+ | |||
+ | Note that the zone declarations have to correspond to authority records in your name server - in | ||
+ | the above example, there must be an SOA record | ||
+ | | ||
+ | could not write a zone declaration for " | ||
+ | | ||
+ | your zone name in a " | ||
+ | | ||
+ | |||
+ | | ||
+ | a program for generating secret keys called 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 | ||
+ | |||
+ | If you are using the BIND 8 dnskeygen program, the following command will generate a key as seen | ||
+ | | ||
+ | |||
+ | dnskeygen -H 128 -u -c -n DHCP_UPDATER | ||
+ | |||
+ | You may wish to enable logging of DNS updates on your DNS server. | ||
+ | | ||
+ | |||
+ | | ||
+ | channel update_debug { | ||
+ | file "/ | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | }; | ||
+ | channel security_info | ||
+ | file "/ | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | }; | ||
+ | |||
+ | category update { update_debug; | ||
+ | category security { security_info; | ||
+ | }; | ||
+ | |||
+ | You must create the / | ||
+ | the name server. | ||
+ | | ||
+ | |||
+ | REFERENCE: EVENTS | ||
+ | There are three kinds of events that can happen regarding a lease, and it is possible to declare | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | your own event handlers if you are using the built-in DNS update mechanism. | ||
+ | |||
+ | The built-in version of the DNS update mechanism | ||
+ | | ||
+ | DNS updates, you will have to start out by copying this code into your dhcpd.conf file and modi‐ | ||
+ | fying it. | ||
+ | |||
+ | REFERENCE: DECLARATIONS | ||
+ | The include statement | ||
+ | |||
+ | include " | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | The shared-network statement | ||
+ | |||
+ | shared-network name { | ||
+ | [ parameters ] | ||
+ | [ declarations ] | ||
+ | } | ||
+ | |||
+ | The shared-network statement is used to inform the DHCP server that some IP subnets | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The subnet statement | ||
+ | |||
+ | subnet subnet-number netmask netmask { | ||
+ | [ parameters ] | ||
+ | [ declarations ] | ||
+ | } | ||
+ | |||
+ | The subnet statement is used to provide dhcpd with enough information to tell whether or not an | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | the subnet being described. | ||
+ | to the subnet mask of the subnet being described. | ||
+ | are sufficient to determine whether any given IP address is on the specified subnet. | ||
+ | |||
+ | | ||
+ | is any variance in subnet masks at a site, a subnet-mask option statement be used in each subnet | ||
+ | | ||
+ | the subnet mask declared in the subnet statement. | ||
+ | |||
+ | The subnet6 statement | ||
+ | |||
+ | subnet6 subnet6-number { | ||
+ | [ parameters ] | ||
+ | [ declarations ] | ||
+ | } | ||
+ | |||
+ | The subnet6 statement is used to provide dhcpd with enough information to tell whether or not an | ||
+ | IPv6 address is on that subnet6. | ||
+ | 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 range statement | ||
+ | |||
+ | range [ dynamic-bootp ] low-address [ high-address]; | ||
+ | |||
+ | For any subnet on which addresses will be assigned dynamically, | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The range6 statement | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | For any IPv6 subnet6 on which addresses will be assigned dynamically, | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | 4941) addresses. A new address per prefix in the shared network is computed at each request with | ||
+ | an IA_TA option. Release and Confirm ignores temporary addresses. | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | The prefix6 statement | ||
+ | |||
+ | | ||
+ | |||
+ | The prefix6 is the range6 equivalent for Prefix Delegation (RFC 3633). Prefixes of bits length | ||
+ | are assigned between low-address and high-address. | ||
+ | |||
+ | | ||
+ | fix6. | ||
+ | |||
+ | This statement is currently global but it should have a shared-network scope. | ||
+ | |||
+ | The host statement | ||
+ | |||
+ | host hostname { | ||
+ | [ parameters ] | ||
+ | [ declarations ] | ||
+ | } | ||
+ | |||
+ | The host declaration provides a scope in which to provide configuration information about a spe‐ | ||
+ | | ||
+ | | ||
+ | the client a static IP address. | ||
+ | |||
+ | | ||
+ | | ||
+ | one host statement may be specified matching the same client. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | where the client is attached. | ||
+ | | ||
+ | a mixture of host declarations for any given client...some having fixed-address statements, oth‐ | ||
+ | ers without. | ||
+ | |||
+ | | ||
+ | host, hostname is used. | ||
+ | |||
+ | Host declarations are matched to actual DHCP or BOOTP clients by matching the dhcp-client-iden‐ | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | any option with a fixed value to identify hosts. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The group statement | ||
+ | |||
+ | group { | ||
+ | [ parameters ] | ||
+ | [ declarations ] | ||
+ | } | ||
+ | |||
+ | The group statement is used simply to apply one or more parameters to a group of declarations. | ||
+ | It can be used to group hosts, shared networks, subnets, or even other groups. | ||
+ | |||
+ | REFERENCE: ALLOW AND DENY | ||
+ | | ||
+ | sorts of requests. | ||
+ | | ||
+ | | ||
+ | | ||
+ | place of the deny keyword to prevent logging of denied requests. | ||
+ | |||
+ | 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 pool declarations. | ||
+ | |||
+ | The unknown-clients keyword | ||
+ | |||
+ | allow unknown-clients; | ||
+ | deny unknown-clients; | ||
+ | ignore unknown-clients; | ||
+ | |||
+ | The unknown-clients flag is used to tell dhcpd whether or not to dynamically assign addresses to | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | to known clients, you should use deny unknown-clients; | ||
+ | under the heading ALLOW AND DENY WITHIN POOL DECLARATIONS. | ||
+ | |||
+ | The bootp keyword | ||
+ | |||
+ | allow bootp; | ||
+ | deny bootp; | ||
+ | ignore bootp; | ||
+ | |||
+ | | ||
+ | are allowed by default. | ||
+ | |||
+ | The booting keyword | ||
+ | |||
+ | allow booting; | ||
+ | deny booting; | ||
+ | ignore booting; | ||
+ | |||
+ | The booting flag is used to tell dhcpd whether or not to respond to queries | ||
+ | | ||
+ | ing is allowed, but if it is disabled for a particular client, then that client will not be able | ||
+ | to get an address from the DHCP server. | ||
+ | |||
+ | The duplicates keyword | ||
+ | |||
+ | allow duplicates; | ||
+ | deny duplicates; | ||
+ | |||
+ | | ||
+ | on the client' | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The declines keyword | ||
+ | |||
+ | allow declines; | ||
+ | deny declines; | ||
+ | ignore declines; | ||
+ | |||
+ | | ||
+ | | ||
+ | mally abandons that address, assuming that some unauthorized system is using it. Unfortunately, | ||
+ | a malicious or buggy client | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | set to deny or ignore in a particular scope, the DHCP server will not respond | ||
+ | | ||
+ | |||
+ | The client-updates keyword | ||
+ | |||
+ | allow client-updates; | ||
+ | deny client-updates; | ||
+ | |||
+ | | ||
+ | do its own update of its A record. | ||
+ | the documentation under the heading THE INTERIM DNS UPDATE SCHEME for details. | ||
+ | |||
+ | The leasequery keyword | ||
+ | |||
+ | allow leasequery; | ||
+ | deny leasequery; | ||
+ | |||
+ | | ||
+ | | ||
+ | was issued and when it will expire. By default, the server will not respond to these packets. | ||
+ | |||
+ | ALLOW AND DENY WITHIN POOL DECLARATIONS | ||
+ | | ||
+ | way whether the client is sending a DHCPDISCOVER or a DHCPREQUEST message - an address | ||
+ | | ||
+ | | ||
+ | | ||
+ | ply not respond to the client. | ||
+ | send a DHCPACK message. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | done during address allocation, not after address allocation is done. | ||
+ | |||
+ | When a DHCPREQUEST message is processed, address allocation simply consists of looking | ||
+ | | ||
+ | then the DHCP server checks both the address pool permit lists and the relevant | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | known-clients; | ||
+ | |||
+ | If specified, this statement either allows or prevents allocation from this pool to any client | ||
+ | that has a host declaration (i.e., is known). | ||
+ | any scope, not just the current scope. | ||
+ | |||
+ | unknown-clients; | ||
+ | |||
+ | If specified, this statement either allows or prevents allocation from this pool to any client | ||
+ | that has no host declaration (i.e., is not known). | ||
+ | |||
+ | members of " | ||
+ | |||
+ | | ||
+ | that is a member of the named class. | ||
+ | |||
+ | dynamic bootp clients; | ||
+ | |||
+ | If specified, this statement either allows or prevents allocation from this pool to any bootp | ||
+ | | ||
+ | |||
+ | authenticated clients; | ||
+ | |||
+ | | ||
+ | that has been authenticated using the DHCP authentication protocol. | ||
+ | |||
+ | unauthenticated clients; | ||
+ | |||
+ | If specified, this statement either allows or prevents allocation from this pool to any client | ||
+ | | ||
+ | | ||
+ | |||
+ | all clients; | ||
+ | |||
+ | If specified, this statement either allows or prevents allocation from this pool to all clients. | ||
+ | | ||
+ | | ||
+ | | ||
+ | ately when they next renew. | ||
+ | |||
+ | after time; | ||
+ | |||
+ | If specified, this statement either allows or prevents allocation from this pool after a given | ||
+ | | ||
+ | | ||
+ | | ||
+ | a gradual change. | ||
+ | | ||
+ | |||
+ | REFERENCE: PARAMETERS | ||
+ | The adaptive-lease-time-threshold statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | time from the current lease. Since the leases expire faster, the server | ||
+ | | ||
+ | below the threshold, the server reverts back to normal lease times. | ||
+ | | ||
+ | |||
+ | The always-broadcast statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | the flags field of the BOOTP message header. | ||
+ | | ||
+ | can be made to always broadcast its responses to clients by setting this flag to ´on´ for the | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | the OpenTransport and ISC DHCP clients. | ||
+ | |||
+ | The always-reply-rfc1048 statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | their requests. | ||
+ | | ||
+ | | ||
+ | |||
+ | If you want to send rfc1048 options to such a client, you can set the always-reply-rfc1048 | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The authoritative statement | ||
+ | |||
+ | | ||
+ | |||
+ | not authoritative; | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | write authoritative; | ||
+ | | ||
+ | | ||
+ | which could take quite a long time. | ||
+ | |||
+ | | ||
+ | if a DHCP server is to be set up so that it is aware of some networks for which it is authori‐ | ||
+ | | ||
+ | on a per-network-segment basis. | ||
+ | |||
+ | Note that the most specific scope for which the concept of authority makes any sense is the | ||
+ | | ||
+ | | ||
+ | | ||
+ | nor is it meaningful to specify that the server is authoritative for some host declarations | ||
+ | and not others. | ||
+ | |||
+ | The boot-unknown-clients statement | ||
+ | |||
+ | | ||
+ | |||
+ | If the boot-unknown-clients statement is present and has a value of false or off, then clients | ||
+ | for which there is no host declaration will not be allowed to obtain IP addresses. | ||
+ | | ||
+ | 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 DHCP server software outputs several timestamps when writing leases to persistent storage. | ||
+ | This configuration parameter selects one of two output formats. | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The ddns-hostname statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | PTR records. | ||
+ | name automatically, | ||
+ | |||
+ | The ddns-domainname statement | ||
+ | |||
+ | | ||
+ | |||
+ | The name parameter should be the domain name that will be appended to the client' | ||
+ | form a fully-qualified domain-name (FQDN). | ||
+ | |||
+ | The ddns-rev-domainname statement | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The reversed IP address to which this domain name is appended is always the IP address of the | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The ddns-update-style parameter | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | is only meaningful in the outer scope - it is evaluated | ||
+ | file, rather than each time a client is assigned an IP address, so there is no way to use dif‐ | ||
+ | | ||
+ | |||
+ | The ddns-updates statement | ||
+ | |||
+ | ddns-updates flag; | ||
+ | |||
+ | The ddns-updates parameter controls whether or not the server will attempt to do a DNS update | ||
+ | | ||
+ | | ||
+ | | ||
+ | none. | ||
+ | |||
+ | The default-lease-time statement | ||
+ | |||
+ | | ||
+ | |||
+ | Time should be the length in seconds that will be assigned to a lease if the client requesting | ||
+ | | ||
+ | | ||
+ | onds. | ||
+ | |||
+ | The delayed-ack and max-ack-delay statements | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | sents how many DHCPv4 replies maximum will be queued pending transmission until after a data‐ | ||
+ | | ||
+ | | ||
+ | | ||
+ | be updated prior to replying to clients. | ||
+ | | ||
+ | |||
+ | | ||
+ | ing a packet pending an fsync, and performing the fsync. | ||
+ | and defaults to 250,000 (1/4 of a second). | ||
+ | |||
+ | | ||
+ | piled in by default, but must be enabled at compile time with ´./ | ||
+ | | ||
+ | |||
+ | The do-forward-updates statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | has no effect unless DNS updates are enabled and ddns-update-style is set to interim. | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | honor the setting of the client-updates flag. | ||
+ | |||
+ | The dynamic-bootp-lease-cutoff statement | ||
+ | |||
+ | | ||
+ | |||
+ | The dynamic-bootp-lease-cutoff statement sets the ending time for all leases assigned | ||
+ | | ||
+ | | ||
+ | | ||
+ | BOOTP leases - for example, the end of a school term, or the time at night when a facility | ||
+ | | ||
+ | |||
+ | 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). | ||
+ | | ||
+ | the day of the month, counting from 1. HH is the hour, from zero to 23. MM is the minute and | ||
+ | SS is the second. | ||
+ | |||
+ | The dynamic-bootp-lease-length statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | time period. | ||
+ | | ||
+ | | ||
+ | ter should be adjusted with extreme caution. | ||
+ | |||
+ | The filename statement | ||
+ | |||
+ | | ||
+ | |||
+ | The filename statement can be used to specify the name of the initial boot file which is to be | ||
+ | | ||
+ | | ||
+ | |||
+ | The fixed-address declaration | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | It should only appear in a host declaration. | ||
+ | | ||
+ | is booting. | ||
+ | | ||
+ | that fixed-address declaration. | ||
+ | | ||
+ | |||
+ | The fixed-address6 declaration | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | The get-lease-hostnames statement | ||
+ | |||
+ | | ||
+ | |||
+ | The get-lease-hostnames statement is used to tell dhcpd whether or not to look up the domain | ||
+ | | ||
+ | for the DHCP hostname option. | ||
+ | the current scope. | ||
+ | |||
+ | The hardware statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | using a hardware clause in the host statement. | ||
+ | | ||
+ | | ||
+ | | ||
+ | The hardware statement may also be used for DHCP clients. | ||
+ | |||
+ | The host-identifier option statement | ||
+ | |||
+ | | ||
+ | |||
+ | This identifies a DHCPv6 client in a host statement. | ||
+ | data is the value for the option that the client will send. The option-data must be a constant | ||
+ | | ||
+ | |||
+ | The infinite-is-reserved statement | ||
+ | |||
+ | | ||
+ | |||
+ | ISC DHCP now supports ´reserved´ leases. | ||
+ | | ||
+ | an infinite (0xffffffff) lease-time. | ||
+ | |||
+ | The default is off. | ||
+ | |||
+ | The lease-file-name statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | / | ||
+ | tion file - if it appears in some other scope, it will have no effect. | ||
+ | | ||
+ | |||
+ | The limit-addrs-per-ia statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | with one IP address per each subnet on a shared network. | ||
+ | |||
+ | The dhcpv6-lease-file-name statement | ||
+ | |||
+ | | ||
+ | |||
+ | Name is the name of the lease file to use if and only if the server is running in DHCPv6 mode. | ||
+ | | ||
+ | | ||
+ | | ||
+ | fied, but lease-file-name is, the latter value will be used. | ||
+ | |||
+ | The local-port statement | ||
+ | |||
+ | | ||
+ | |||
+ | This statement causes the DHCP server to listen for DHCP requests on the UDP port specified in | ||
+ | port, rather than on port 67. | ||
+ | |||
+ | The local-address statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | # | ||
+ | | ||
+ | with USE_SOCKETS if you see lines of this format at startup: | ||
+ | |||
+ | Listening on Socket/eth0 | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | The log-facility statement | ||
+ | |||
+ | | ||
+ | |||
+ | This statement causes the DHCP server to do all of its logging on the specified | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | local7.debug / | ||
+ | |||
+ | The syntax of the syslog.conf file may be different on some operating systems | ||
+ | | ||
+ | first create the file with correct ownership and permissions (usually, the same owner and per‐ | ||
+ | | ||
+ | to syslogd. | ||
+ | | ||
+ | grow uncontrollably. | ||
+ | |||
+ | | ||
+ | while parsing the dhcpd.conf file or before parsing it are logged to the default log facility. | ||
+ | To prevent this, see the README file included with this distribution, | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | The max-lease-time statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | BOOTP lease lengths, which are not specified by the client, are not limited by this maximum. | ||
+ | |||
+ | The min-lease-time statement | ||
+ | |||
+ | | ||
+ | |||
+ | 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 | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | what the client reports, and the maximum value that the client | ||
+ | | ||
+ | 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 server has been given a chance to do so. If the primary server is down, the | ||
+ | | ||
+ | | ||
+ | share a pool of dynamically-allocatable addresses. | ||
+ | |||
+ | The next-server statement | ||
+ | |||
+ | | ||
+ | |||
+ | The next-server statement is used to specify the host address of the server | ||
+ | | ||
+ | be a numeric IP address or a domain name. If no next-server | ||
+ | | ||
+ | |||
+ | The omapi-port statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | fied port. This 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. | ||
+ | |||
+ | The one-lease-per-client statement | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | i.e., the client has only a single network interface and it does not remember | ||
+ | | ||
+ | | ||
+ | |||
+ | The pid-file-name statement | ||
+ | |||
+ | | ||
+ | |||
+ | Name should be the name of the DHCP server' | ||
+ | | ||
+ | / | ||
+ | | ||
+ | | ||
+ | |||
+ | The dhcpv6-pid-file-name statement | ||
+ | |||
+ | dhcpv6-pid-file-name name; | ||
+ | |||
+ | Name is the name of the pid file to use if and only if the server | ||
+ | mode. By default, this is / | ||
+ | must appear in the outer scope of the configuration file. It has no effect | ||
+ | by the -pf flag or the PATH_DHCPD6_PID environment variable. | ||
+ | not specified, but pid-file-name is, the latter value will be used. | ||
+ | |||
+ | The ping-check statement | ||
+ | |||
+ | ping-check flag; | ||
+ | |||
+ | When the DHCP server is considering dynamically allocating an IP address to a client, | ||
+ | first sends an ICMP Echo request (a ping) to the address being assigned. | ||
+ | second, and if no ICMP Echo response has been heard, it assigns the address. | ||
+ | is heard, the lease is abandoned, and the server does not respond to the client. | ||
+ | |||
+ | This ping check introduces a default one-second delay in responding to DHCPDISCOVER mes‐ | ||
+ | sages, which can be a problem for some clients. | ||
+ | configured using the ping-timeout parameter. | ||
+ | used to control checking - if its value is false, no ping check is done. | ||
+ | |||
+ | The ping-timeout statement | ||
+ | |||
+ | ping-timeout seconds; | ||
+ | |||
+ | If the DHCP server determined it should send an ICMP echo request | ||
+ | ping-check | ||
+ | DHCP server should wait for an ICMP Echo response to be heard, if no ICMP Echo response has | ||
+ | been received before the timeout expires, it assigns the address. | ||
+ | the lease is abandoned, and the server does not respond to the client. | ||
+ | ping-timeout defaults to 1 second. | ||
+ | |||
+ | The preferred-lifetime statement | ||
+ | |||
+ | preferred-lifetime seconds; | ||
+ | |||
+ | IPv6 addresses | ||
+ | what point at lease might be said to have expired, and is no longer useable. | ||
+ | lifetime | ||
+ | currently valid addresses (should there still be any open TCP sockets or similar). | ||
+ | |||
+ | The preferred lifetime defaults to the renew+rebind timers, or 3/4 the default | ||
+ | if none were specified. | ||
+ | |||
+ | The remote-port statement | ||
+ | |||
+ | remote-port port; | ||
+ | |||
+ | This statement | ||
+ | UDP port specified in port, rather than on port 68. In the event that the UDP response | ||
+ | transmitted | ||
+ | Should the DHCP Relay happen to be addressed as 127.0.0.1, however, the DHCP Server | ||
+ | mits its response | ||
+ | for testing purposes, and this configuration value should generally not be used. | ||
+ | |||
+ | The server-identifier statement | ||
+ | |||
+ | server-identifier hostname; | ||
+ | |||
+ | The server-identifier statement can be used to define the value that is sent in the DHCP | ||
+ | Server | ||
+ | the DHCP server, and must be reachable 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 other than the default value to be sent on occasions where the default | ||
+ | value would be incorrect. | ||
+ | physical network interface on which the request arrived. | ||
+ | |||
+ | The usual case where the server-identifier statement needs to be sent is when a physical | ||
+ | interface has more than one IP address, and the one being sent by default isn't appropriate | ||
+ | for some or all clients served by that interface. | ||
+ | defined for the purpose of having a consistent IP address for the DHCP server, | ||
+ | desired that the clients use this IP address when contacting the server. | ||
+ | |||
+ | Supplying | ||
+ | identifier statement. | ||
+ | |||
+ | The server-duid statement | ||
+ | |||
+ | server-duid LLT [ hardware-type timestamp hardware-address ] ; | ||
+ | |||
+ | server-duid EN enterprise-number enterprise-identifier ; | ||
+ | |||
+ | 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), EN (enterprise), | ||
+ | |||
+ | If you choose | ||
+ | server will generate a DUID of the specified type. | ||
+ | |||
+ | If you choose EN, you must include the enterprise number and the enterprise-identifier. | ||
+ | |||
+ | The default server-duid type is LLT. | ||
+ | |||
+ | The server-name statement | ||
+ | |||
+ | server-name name ; | ||
+ | |||
+ | The server-name statement can be used to inform the client of the name of the server | ||
+ | which it is booting. | ||
+ | |||
+ | The site-option-space statement | ||
+ | |||
+ | site-option-space name ; | ||
+ | |||
+ | The site-option-space statement can be used to determine from what option space site-local | ||
+ | options will be taken. | ||
+ | statement. | ||
+ | than 224. These options are intended for site-specific uses, but are frequently | ||
+ | vendors of embedded hardware that contains DHCP clients. | ||
+ | allocated on an ad hoc basis, it is quite possible that one vendor' | ||
+ | the same option code that another vendor' | ||
+ | option-space option can be used to assign a different set of site-specific options for each | ||
+ | such vendor, using conditional evaluation (see dhcp-eval (5) for details). | ||
+ | |||
+ | The stash-agent-options statement | ||
+ | |||
+ | stash-agent-options flag; | ||
+ | |||
+ | If the stash-agent-options parameter is true for a given client, the server will record the | ||
+ | relay agent information options sent during the client' | ||
+ | the client | ||
+ | subsequent DHCPREQUEST messages sent in the RENEWING state. | ||
+ | with relay agent information options, which is that they usually not appear in DHCPREQUEST | ||
+ | messages sent by the client in the RENEWING | ||
+ | directly to the server and not sent through a relay agent. | ||
+ | |||
+ | The update-conflict-detection statement | ||
+ | |||
+ | update-conflict-detection flag; | ||
+ | |||
+ | If the update-conflict-detection parameter is true, the server will perform standard DHCID | ||
+ | multiple-client, | ||
+ | server | ||
+ | the new binding without question. | ||
+ | |||
+ | The update-optimization statement | ||
+ | |||
+ | update-optimization flag; | ||
+ | |||
+ | If the update-optimization parameter is false for a given client, the server will attempt a | ||
+ | DNS update for that client each time the client renews its lease, rather than only attempt‐ | ||
+ | ing an update when it appears to be necessary. | ||
+ | base inconsistencies | ||
+ | DNS updates. | ||
+ | only affects the behavior of the interim DNS update scheme, and has no effect on the ad-hoc | ||
+ | DNS update scheme. | ||
+ | only update when the client information changes, the client gets a different lease, or the | ||
+ | client' | ||
+ | |||
+ | The update-static-leases statement | ||
+ | |||
+ | update-static-leases flag; | ||
+ | |||
+ | The update-static-leases flag, if enabled, causes the DHCP server to do DNS updates | ||
+ | clients | ||
+ | statement - that is, the client is being given a static assignment. | ||
+ | with the interim DNS update scheme. | ||
+ | way to tell that the update has been done, and therefore will not delete the record when it | ||
+ | is not in use. Also, the server must attempt the update each time the client renews its | ||
+ | lease, which could have a significant performance impact in environments that place heavy | ||
+ | demands on the DHCP server. | ||
+ | |||
+ | The use-host-decl-names statement | ||
+ | |||
+ | use-host-decl-names flag; | ||
+ | |||
+ | 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 | ||
+ | client as its hostname. | ||
+ | |||
+ | group { | ||
+ | use-host-decl-names on; | ||
+ | |||
+ | host joe { | ||
+ | hardware ethernet 08: | ||
+ | fixed-address joe.fugue.com; | ||
+ | } | ||
+ | } | ||
+ | |||
+ | is equivalent to | ||
+ | |||
+ | host joe { | ||
+ | hardware ethernet 08: | ||
+ | fixed-address joe.fugue.com; | ||
+ | option host-name " | ||
+ | } | ||
+ | |||
+ | An option | ||
+ | in the host declaration. | ||
+ | |||
+ | It should be noted here that most DHCP clients completely ignore the host-name option | ||
+ | by the DHCP server, and there is no way to configure them not to do this. So you generally | ||
+ | have a choice of either not having any hostname to client | ||
+ | client | ||
+ | describe how to make this determination. | ||
+ | |||
+ | The use-lease-addr-for-default-route statement | ||
+ | |||
+ | 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 | ||
+ | address of the lease being assigned is sent to the client. | ||
+ | machines to ARP for all IP addresses, which can be helpful if your router is configured for | ||
+ | proxy ARP. The use of this feature is not recommended, | ||
+ | clients. | ||
+ | |||
+ | The vendor-option-space statement | ||
+ | |||
+ | vendor-option-space string; | ||
+ | |||
+ | The vendor-option-space | ||
+ | taken. | ||
+ | ual page, in the VENDOR ENCAPSULATED OPTIONS section. | ||
+ | |||
+ | SETTING PARAMETER VALUES USING EXPRESSIONS | ||
+ | | ||
+ | value that the client has sent. To do this, you can use expression | ||
+ | | ||
+ | to an option, define the option as follows: | ||
+ | |||
+ | | ||
+ | |||
+ | For example: | ||
+ | |||
+ | | ||
+ | substring (hardware, 1, 6)); | ||
+ | |||
+ | RESERVED LEASES | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | If a standard dynamic lease, as from any range statement, is marked ´reserved´, | ||
+ | will only allocate this lease to the client it is identified by (be that by client identifier or | ||
+ | | ||
+ | |||
+ | In practice, this means that the lease follows the normal state engine, enters ACTIVE state when | ||
+ | | ||
+ | mally be supplied during these events are processed normally, as with any other dynamic | ||
+ | | ||
+ | the FREE or BACKUP states - each server applies the lease into the state it may allocate from - | ||
+ | | ||
+ | only be ´found´ by client identity. | ||
+ | ing client. | ||
+ | |||
+ | Care should probably be taken to ensure that the client only has one lease within a given subnet | ||
+ | that it is identified by. | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | It should also be noted that leases marked ´reserved´ are effectively treated the same as leases | ||
+ | | ||
+ | |||
+ | REFERENCE: OPTION STATEMENTS | ||
+ | DHCP option statements are documented in the dhcp-options(5) manual page. | ||
+ | |||
+ | REFERENCE: EXPRESSIONS | ||
+ | | ||
+ | ual page. | ||
+ | |||
+ | SEE ALSO | ||
+ | | ||
+ | |||
+ | AUTHOR | ||
+ | | ||
+ | | ||
+ | tium can be found at https:// | ||
+ | |||
+ | |||
+ | |||
+ | dhcpd.conf(5) | ||
+ | </ | ||
=== Konfigurationsbeispiel === | === Konfigurationsbeispiel === | ||
Ein rudimentäres Konfigurationsbeispiel finden wir in der Datei **/// | Ein rudimentäres Konfigurationsbeispiel finden wir in der Datei **/// | ||
Zeile 492: | Zeile 2626: | ||
| | ||
</ | </ | ||
+ | |||
====== Links ====== | ====== Links ====== | ||
* **[[wiki: | * **[[wiki: | ||
* **[[http:// | * **[[http:// | ||
- | ~~DISCUSSION~~ | ||