Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| centos:dhcp_c7 [11.02.2016 09:40. ] – angelegt django | centos:dhcp_c7 [28.12.2022 08:40. ] (aktuell) – [DHCP-Adressvergabe] django | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== DHCP-Server Konfigurieren unter CentOS 7.x ====== | ====== DHCP-Server Konfigurieren unter CentOS 7.x ====== | ||
| + | Für die Zuweisung der Netzwerkkonfiguration an den Klienten durch unseren Server bedienen wir uns des DHCP((**D**ynamic **H**ost **C**onfiguration **P**rotocol)), | ||
| + | |||
| + | Mittels DHCP ist die automatische Einbindung eines neuen Klienten in unser bestehendes Netzwerk ohne große manuelle Konfiguration möglich. Am Klient muss daher nur der automatische Bezug der IP-Adresse eingestellt sein. Beim Start des Klienten am Netz kann dieser die IP-Adresse, die Netzmaske, das Gateway, DNS-Server und weitere Konfigurationsparameter vom DHCP-Server beziehen. Neben diesen klassischen Parametern zählen hierzu auch die Verwendung einer Reihe von weiteren IP-Variablen, | ||
| + | |||
| + | Beim Starten eines Klienten frägt dieser über einen Broadcast im gesamten Netzwerk nach (s)einer IP-Adresse. Als Antwort auf seinen Broadcast erhält er die beiden wichtigsten Parameter: | ||
| + | * IP-Adresse | ||
| + | * Lease-Time | ||
| + | Darüber hinaus können optional noch weitere Parameter mit übergeben werden, wie z.B.: | ||
| + | * Default-Route | ||
| + | * Netzmaske | ||
| + | * DNS-Server-Adressen | ||
| + | * WINS-Server | ||
| + | * Broadcast-Adresse | ||
| + | * IP-Varialen | ||
| + | * sowie noch weitere Parameter | ||
| + | ===== DHCP-Adressvergabe ===== | ||
| + | Der grundsätzliche Ablauf bei der Adress-Anfrage folgt dabei folgendem Schema. Die Kommunikation zwischen dem Server (Port 67) und dem Klienten (Port 68) erfolgte mittels UPD((**U**nreliable **D**atagram **P**rotocol)). | ||
| + | |||
| + | Beim Booten des Klienten frägt dieser mit einer // | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | Sep 12 21:34:12 nss dhcpd: DHCPDISCOVER from 00: | ||
| + | Dieses Broadcast-Paket beantwortet nun der DHCP-Server mit einer // | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | Sep 12 21:34:12 nss dhcpd: DHCPOFFER on 192.168.10.61 to 00: | ||
| + | Der Klient hat also vom DHCP-Server ein sogenanntes Angebot (//offer//) bekommen und entscheidet nun, ob es für ihn so in Ordnung ist. Trifft dies zu, sendet er eine // | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | Sep 12 21:34:12 nss dhcpd: DHCPREQUEST for 192.168.10.61 (192.168.10.1) from 00: | ||
| + | Der DHCP-Server bestätigt dies und sendet eine // | ||
| + | |||
| + | {{ : | ||
| + | |||
| + | 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. | ||
| + | <uml> | ||
| + | |||
| + | title erfolgreiche Ablauf aus Sicht des DHCP-Servers\n | ||
| + | |||
| + | participant " | ||
| + | participant " | ||
| + | |||
| + | |||
| + | |||
| + | links <-- rechts : (Port 67) | ||
| + | note right : DHCPDISCOVER mit \nMAC 00: | ||
| + | links -> rechts : DHCPOFFER | ||
| + | note left : DHCPOFFER mit Angabe \nder IP 192.168.10.61 \nan MAC 00: | ||
| + | links <-- rechts : (Port 67) | ||
| + | note right : DHCPREQUEST mit Angabe \nder IP 192.168.10.61 \nund MAC 00: | ||
| + | links -> rechts : DHCPACK | ||
| + | note left : DHCPACK mit Angabe \nder IP 192.168.10.61 \nund der MAC 00: | ||
| + | |||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | Im **syslog** des DHCP-Servers wird der Ablauf wie folgt festgehalten: | ||
| + | < | ||
| + | Sep 12 21:34:12 nss dhcpd: DHCPOFFER on 192.168.10.61 to 00: | ||
| + | Sep 12 21:34:12 nss dhcpd: DHCPREQUEST for 192.168.10.61 (192.168.10.1) from 00: | ||
| + | Sep 12 21:34:12 nss dhcpd: DHCPACK on 192.168.10.61 to 00: | ||
| + | Sollte die ganze Prozedur Fehl schlagen, z.B. weil der Klient herausgefunden hat, daß die IP-Adresse doppelt vergeben ist, sendet er eine // | ||
| + | |||
| + | Zusammen mit seiner IP-Adresse erhält der Klient in der DHCPACK-Nachricht auch eine Lease-Time mitgeteilt, welche ihm mitteilt, wie lange die IP-Adresse für ihn reserviert ist. Im RFC Standard wurde definiert, daß der Klient nach der Hälfte der Lease-Time einen erneuten DHCPREQUEST sendet. So teilt er dem Server mit, daß er weiterhin die für ihn reservierte IP-Adresse behalten möchte. Nach Erhalt dieser Nachricht sendet der DHCP-Server eine identische DHCPACK-Nachricht an den Client zurück, in der dann die aktuelle neue Lease-Time mitgeteilt wird. Die IP-Adresse ist somit verlängert und der DCHP-Refresh ist komplett. Sollte der Klient es versäumen eine Verlängerung zu beantragen, muss er die Konfiguration des Netzwerkinterfaces verwerfen und der DHCP-Request startet erneut mit einer DHCPDISCOVER-Nachricht. | ||
| + | |||
| + | Beim Herunterfahren eines Klienten kann dieser dem Server mit einer // | ||
| + | Sep 12 21:58:17 nss dhcpd: DHCPRELEASE of 192.168.10.238 from 00: | ||
| + | Der Klient hat aber auch die Möglichkeit, | ||
| + | Dann entfallen die Initialisierungsschritte und der Klient schickt direkt eine // | ||
| + | Sep 12 22:01:13 nss dhcpd: DHCPREQUEST for 192.168.10.15 from 00: | ||
| + | Sep 12 22:01:13 nss dhcpd: DHCPACK on 192.168.10.15 to 00: | ||
| + | |||
| + | ===== Installation ===== | ||
| + | Die Installation und Konfiguration des DHCP-Servers gestaltet sich relativ einfach. | ||
| + | |||
| + | Zuerst ist via **yum** der dhcp-Server zu installieren. | ||
| + | # yum install dhcp -y | ||
| + | |||
| + | ===== RPM Inhalte ===== | ||
| + | Um sich einen ersten Überblick zum gerade eben installiertem RPM-Paket zu verschaffen, | ||
| + | |||
| + | # rpm -qil dhcp | ||
| + | < | ||
| + | Epoch : 12 | ||
| + | Version | ||
| + | Release | ||
| + | Architecture: | ||
| + | Install Date: Thu 11 Feb 2016 10:43:32 AM CET | ||
| + | Group : System Environment/ | ||
| + | Size : 1452508 | ||
| + | License | ||
| + | Signature | ||
| + | Source RPM : dhcp-4.2.5-42.el7.centos.src.rpm | ||
| + | Build Date : Thu 19 Nov 2015 10:40:07 PM CET | ||
| + | Build Host : worker1.bsys.centos.org | ||
| + | Relocations : (not relocatable) | ||
| + | Packager | ||
| + | Vendor | ||
| + | URL : http:// | ||
| + | Summary | ||
| + | Description : | ||
| + | DHCP (Dynamic Host Configuration Protocol) is a protocol which allows | ||
| + | individual devices on an IP network to get their own network | ||
| + | configuration information (IP address, subnetmask, broadcast address, | ||
| + | etc.) from a DHCP server. The overall purpose of DHCP is to make it | ||
| + | easier to administer a large network. | ||
| + | |||
| + | To use DHCP on your network, install a DHCP service (or relay agent), | ||
| + | and on clients run a DHCP client daemon. | ||
| + | the ISC DHCP service and relay agent. | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | /etc/dhcp | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | |||
| + | |||
| + | ===== Konfiguration ===== | ||
| + | Die Konfiguration eines DHCP-Servers erfolgt für die beiden Adress-Varianten **IPv4** und **IPv6** in zwei getrennten Daemon. | ||
| + | Im ersten Schritt werden wir nun einen DHCP-Daemon für IPv4 aufsetzen. | ||
| + | |||
| + | ==== 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 === | ||
| + | Ein rudimentäres Konfigurationsbeispiel finden wir in der Datei **/// | ||
| + | # less / | ||
| + | |||
| + | < | ||
| + | # | ||
| + | # Sample configuration file for ISC dhcpd | ||
| + | # | ||
| + | |||
| + | # option definitions common to all supported networks... | ||
| + | option domain-name " | ||
| + | option domain-name-servers ns1.example.org, | ||
| + | |||
| + | default-lease-time 600; | ||
| + | max-lease-time 7200; | ||
| + | |||
| + | # Use this to enble / disable dynamic dns updates globally. | ||
| + | # | ||
| + | |||
| + | # If this DHCP server is the official DHCP server for the local | ||
| + | # network, the authoritative directive should be uncommented. | ||
| + | # | ||
| + | |||
| + | # Use this to send dhcp log messages to a different log file (you also | ||
| + | # have to hack syslog.conf to complete the redirection). | ||
| + | log-facility local7; | ||
| + | |||
| + | # No service will be given on this subnet, but declaring it helps the | ||
| + | # DHCP server to understand the network topology. | ||
| + | |||
| + | subnet 10.152.187.0 netmask 255.255.255.0 { | ||
| + | } | ||
| + | |||
| + | # This is a very basic subnet declaration. | ||
| + | |||
| + | subnet 10.254.239.0 netmask 255.255.255.224 { | ||
| + | range 10.254.239.10 10.254.239.20; | ||
| + | option routers rtr-239-0-1.example.org, | ||
| + | } | ||
| + | |||
| + | # This declaration allows BOOTP clients to get dynamic addresses, | ||
| + | # which we don't really recommend. | ||
| + | |||
| + | subnet 10.254.239.32 netmask 255.255.255.224 { | ||
| + | range dynamic-bootp 10.254.239.40 10.254.239.60; | ||
| + | option broadcast-address 10.254.239.31; | ||
| + | option routers rtr-239-32-1.example.org; | ||
| + | } | ||
| + | |||
| + | # A slightly different configuration for an internal subnet. | ||
| + | subnet 10.5.5.0 netmask 255.255.255.224 { | ||
| + | range 10.5.5.26 10.5.5.30; | ||
| + | option domain-name-servers ns1.internal.example.org; | ||
| + | option domain-name " | ||
| + | option routers 10.5.5.1; | ||
| + | option broadcast-address 10.5.5.31; | ||
| + | default-lease-time 600; | ||
| + | max-lease-time 7200; | ||
| + | } | ||
| + | |||
| + | # Hosts which require special configuration options can be listed in | ||
| + | # host statements. | ||
| + | # allocated dynamically (if possible), but the host-specific information | ||
| + | # will still come from the host declaration. | ||
| + | |||
| + | host passacaglia { | ||
| + | hardware ethernet 0: | ||
| + | filename " | ||
| + | server-name " | ||
| + | } | ||
| + | |||
| + | # Fixed IP addresses can also be specified for hosts. | ||
| + | # should not also be listed as being available for dynamic assignment. | ||
| + | # Hosts for which fixed IP addresses have been specified can boot using | ||
| + | # BOOTP or DHCP. Hosts for which no fixed address is specified can only | ||
| + | # be booted with DHCP, unless there is an address range on the subnet | ||
| + | # to which a BOOTP client is connected which has the dynamic-bootp flag | ||
| + | # set. | ||
| + | host fantasia { | ||
| + | hardware ethernet 08: | ||
| + | fixed-address fantasia.fugue.com; | ||
| + | } | ||
| + | |||
| + | # You can declare a class of clients and then do address allocation | ||
| + | # based on that. The example below shows a case where all clients | ||
| + | # in a certain class get addresses on the 10.17.224/ | ||
| + | # other clients get addresses on the 10.0.29/24 subnet. | ||
| + | |||
| + | class " | ||
| + | match if substring (option vendor-class-identifier, | ||
| + | } | ||
| + | |||
| + | shared-network 224-29 { | ||
| + | subnet 10.17.224.0 netmask 255.255.255.0 { | ||
| + | option routers rtr-224.example.org; | ||
| + | } | ||
| + | subnet 10.0.29.0 netmask 255.255.255.0 { | ||
| + | option routers rtr-29.example.org; | ||
| + | } | ||
| + | pool { | ||
| + | allow members of " | ||
| + | range 10.17.224.10 10.17.224.250; | ||
| + | } | ||
| + | pool { | ||
| + | deny members of " | ||
| + | range 10.0.29.10 10.0.29.230; | ||
| + | } | ||
| + | }</ | ||
| + | |||
| + | |||
| + | Damit der DHCP-Server richtig funktioniert, | ||
| + | |||
| + | Als nächstes folgen in dieser Hierarchie die Subnetze. Hier dürfen ebenfalls Parameter für die Klienten festgelegt werden, die sich in diesem Subnetz befinden. So könnte z.B. jedes Subnetz einen eigenen Default-Router besitzen. Die Parameter innerhalb des Subnetzes überschreiben die global definierten Parameter! Bei solchen Subnetzen ist es wichtig, dass der DHCP-Server nur auf Anfragen aus dem Subnetz antwortet, welche in der dhcpd.conf definiert wurden. Wurde ein Subnetz nicht beschrieben, | ||
| + | |||
| + | Die nächste Hierarchiestufe ist der Pool, dieser wird innerhalb eines Subnetzes angelegt. In so einem Pool können auch Bereiche angelegt werden, so können z.B. auch mehrere Pools in einem Subnetz existieren. | ||
| + | |||
| + | Als letzte Stufe in der Hierarchie gibt es die Host-Stufe. In dieser Stufe können einzelne Rechner konfiguriert werden, wenn z.B. diese immer die gleiche IP bekommen sollen. Diese //festen IP-Adressen// | ||
| + | |||
| + | Das " | ||
| + | |||
| + | Vergebene Adressen werden in der Datei **/ | ||
| + | |||
| + | |||
| + | ==== Konfigurationsdatei bearbeiten ==== | ||
| + | Anschließend wird die Konfigurationsdatei unter **/ | ||
| + | # vim / | ||
| + | <file | / | ||
| + | subnet 10.0.10.0 netmask 255.255.255.192 { | ||
| + | |||
| + | option routers | ||
| + | option subnet-mask | ||
| + | |||
| + | option nis-domain | ||
| + | option domain-name | ||
| + | option domain-search " | ||
| + | option domain-name-servers | ||
| + | |||
| + | option time-offset | ||
| + | option ntp-servers | ||
| + | option log-servers | ||
| + | |||
| + | range dynamic-bootp 10.0.10.50 10.0.10.62; | ||
| + | default-lease-time 21600; | ||
| + | max-lease-time 43200; | ||
| + | |||
| + | } | ||
| + | |||
| + | host pml010010 | ||
| + | { hardware ethernet 00: | ||
| + | fixed-address 10.0.10.10; | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | ===== DHCP-Konfiguration überprüfen ===== | ||
| + | Bevor wir nun unseren DHCP-Server das erste mal starten, überprüfen wir unsere Konfiguration mit: | ||
| + | # service dhcpd configtest | ||
| + | |||
| + | | ||
| + | ===== DHCP-Server starten ===== | ||
| + | Den ersten Start unseres DHCP-Server nehmen wir wie folgt vor. | ||
| + | # service dhcpd start | ||
| + | |||
| + | dhcpd starten: | ||
| + | Im syslog wird der erfolgreiche Start entsprechend quittiert: | ||
| + | < | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Copyright 2004-2010 Internet Systems Consortium. | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: All rights reserved. | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: For info, please visit https:// | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Not searching LDAP since ldap-server, | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Wrote 0 deleted host decls to leases file. | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Wrote 0 new dynamic host decls to leases file. | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Wrote 2 leases to leases file. | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Listening on LPF/ | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Sending on | ||
| + | Oct 6 15:36:23 vml000020 dhcpd: Sending on | ||
| + | </ | ||
| + | Beim Starten eines Klienten, in unserem Faller der Host **proton** mit der MAC-Adresse **00: | ||
| + | < | ||
| + | Oct 4 21:36:14 vml000020 dhcpd: DHCPOFFER on 10.0.10.10 to 00: | ||
| + | Oct 4 21:36:14 vml000020 dhcpd: DHCPREQUEST for 10.0.10.10 (10.0.10.1) from 00: | ||
| + | Oct 4 21:36:14 vml000020 dhcpd: DHCPACK on 10.0.10.10 to 00: | ||
| + | </ | ||
| + | |||
| + | ===== automatisches Starten des Dienste beim Systemstart ===== | ||
| + | Damit nun unser DHCP-server beim Booten automatisch gestartet wird, nehmen wir noch folgende Konfigurationsschritte vor. | ||
| + | # chkconfig dhcpd on | ||
| + | Anschließend überprüfen wir noch unsere Änderung: | ||
| + | # chkconfig --list | grep dhcpd | ||
| + | |||
| + | | ||
| + | | ||
| + | |||
| + | ===== lease-File des DHCP Servers ===== | ||
| + | Mit nachfolgendem Befehl, kann die sogenannte Lease-Datei eingesehene werden, die standardmäßig im den | ||
| + | Verzeichnis // | ||
| + | * / | ||
| + | * / | ||
| + | |||
| + | # cat / | ||
| + | |||
| + | <file | / | ||
| + | # The format of this file is documented in the dhcpd.leases(5) manual page. | ||
| + | # This lease file was written by isc-dhcp-4.1.1-P1 | ||
| + | |||
| + | lease 10.0.10.50 { | ||
| + | starts 6 2011/08/20 20:34:41; | ||
| + | ends 0 2011/08/21 02:34:41; | ||
| + | tstp 0 2011/08/21 02:34:41; | ||
| + | cltt 6 2011/08/20 20:34:41; | ||
| + | binding state free; | ||
| + | hardware ethernet 00: | ||
| + | } | ||
| + | lease 10.0.10.51 { | ||
| + | starts 5 2011/08/26 03:01:55; | ||
| + | ends 5 2011/08/26 09:01:55; | ||
| + | tstp 5 2011/08/26 09:01:55; | ||
| + | cltt 5 2011/08/26 03:01:55; | ||
| + | binding state free; | ||
| + | hardware ethernet f0: | ||
| + | } | ||
| + | server-duid " | ||
| + | |||
| + | </ | ||
| + | ====== Überwachung der ARP Tabelle mit arpwatch ====== | ||
| + | Mit dem Netzwerktool **// | ||
| + | |||
| + | **// | ||
| + | |||
| + | ^ Meldung | ||
| + | | New Activity | ||
| + | | New Station | ||
| + | | Changed MAC Address | Die MAC Adresse hat sich geändert | ||
| + | | Flip Flop | Die MAC Adresse hat sich zu einer schon mal verwendeten MAC Adresse geändert | | ||
| + | |||
| + | Tritt mindestens eines dieser Ereignisse auf, kann der **BOfH**((**B**astard **O**perator **F**rom **H**ell)) unmittelbar via eMail gewarnt und informiert werden. | ||
| + | Ferner werden im Syslog folgende Ereignisse protokolliert: | ||
| + | |||
| + | |||
| + | ^ Meldung | ||
| + | | MAC broadcast | ||
| + | | ip broadcast | ||
| + | | Bogon | Die IP-Adresse des Hosts gehört nicht in dieses Subnetz | ||
| + | | MAC mismatch | ||
| + | | reused old MAC address | Die MAC Adresse hat sich auf eine MAC Adresse geändert, die entweder der drittletzten oder noch älteren MAC Adresse entspricht | | ||
| + | |||
| + | Mit diesem Überwachungs-Programm können wir nun sehr schnell doppelte MAC- und IP-Adressen, | ||
| + | |||
| + | In der Datei // | ||
| + | < | ||
| + | 0: | ||
| + | 0: | ||
| + | 0: | ||
| + | 0: | ||
| + | ===== Installation ===== | ||
| + | Die Installation unter CentOS geht am einfachsten via **yum**. | ||
| + | # yum install arpwatch -y | ||
| + | Was uns das Programmpaket mitbringt, erkunden wir mit der Option **iql** beim Programm **rpm**. | ||
| + | # rpm -qil arpwatch | ||
| + | < | ||
| + | Name : arpwatch | ||
| + | Version | ||
| + | Release | ||
| + | Install Date: Sat 20 Aug 2011 10:26:47 PM CEST Build Host: c6b3.bsys.dev.centos.org | ||
| + | Group : Applications/ | ||
| + | Size : 462477 | ||
| + | Signature | ||
| + | Packager | ||
| + | URL : http:// | ||
| + | Summary | ||
| + | Description : | ||
| + | The arpwatch package contains arpwatch and arpsnmp. | ||
| + | arpsnmp are both network monitoring tools. | ||
| + | Ethernet or FDDI network traffic and build databases of Ethernet/IP | ||
| + | address pairs, and can report certain changes via email. | ||
| + | |||
| + | Install the arpwatch package if you need networking monitoring devices | ||
| + | which will automatically keep track of the IP addresses on your | ||
| + | network. | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | </ | ||
| + | |||
| + | ===== Konfiguration ===== | ||
| + | Viel gibt es nicht zu Konfigurieren, | ||
| + | # vim / | ||
| + | <file | / | ||
| + | # -u < | ||
| + | # -e < | ||
| + | # -s < | ||
| + | # | ||
| + | # Django : 2011-08-20 arpwatch individualisiert | ||
| + | OPTIONS=" | ||
| + | </ | ||
| + | |||
| + | ===== Programmstart ===== | ||
| + | ==== erster Programmstart ==== | ||
| + | Den **arpwatch** daemon starten wir einfach mit dem Aufruf: | ||
| + | # service arpwatch start | ||
| + | | ||
| + | Der erfolgreiche Programmstart wird uns im syslog dokumentiert: | ||
| + | < | ||
| + | Oct 1 20:33:37 vml000020 arpwatch: listening on eth0 | ||
| + | Oct 1 20:33:39 vml000020 arpwatch: new station 10.0.10.10 0: | ||
| + | </ | ||
| + | ==== automatischer Programmstart ==== | ||
| + | Damit nun unser **arpwatch**-Daemon beim Booten automatisch gestartet wird, nehmen wir noch folgende Konfigurationsschritte vor. | ||
| + | # chkconfig arpwatch on | ||
| + | Anschließend überprüfen wir noch unsere Änderung: | ||
| + | # chkconfig --list | grep arpwatch | ||
| + | |||
| + | | ||
| + | ===== Status-eMail ===== | ||
| + | Beschafft sich nun ein Klient von unserem DHCP-Server eine Adresse, so wird nunmehr diese Aktion an den Sys-Admin per eMail gemeldet: | ||
| + | < | ||
| + | Datum : Sat, 20 Aug 2011 22:37:12 +0200 (CEST) [20.08.2011 22:37:12 CEST] | ||
| + | Von : " | ||
| + | An : | ||
| + | Betreff: | ||
| + | |||
| + | hostname: proton.intra.nausch.org | ||
| + | ip address: 10.0.10.51 | ||
| + | ethernet address: f0: | ||
| + | | ||
| + | | ||
| + | </ | ||
| + | |||
| + | ====== Links ====== | ||
| + | * **[[wiki: | ||
| + | * **[[http:// | ||
| + | |||
django