Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

14.2. Configuring a DHCP Server

The dhcp package contains an Internet Systems Consortium (ISC) DHCP server. Install the package as root: 
~]# yum install dhcp
Copy to Clipboard Toggle word wrap
Installing the dhcp package creates a file, /etc/dhcp/dhcpd.conf, which is merely an empty configuration file. As root, issue the following command: 
~]# cat /etc/dhcp/dhcpd.conf
#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.example
#   see dhcpd.conf(5) man page
#
Copy to Clipboard Toggle word wrap
The example configuration file can be found at /usr/share/doc/dhcp-version;/dhcpd.conf.example. You should use this file to help you configure /etc/dhcp/dhcpd.conf, which is explained in detail below.
DHCP also uses the file /var/lib/dhcpd/dhcpd.leases to store the client lease database. See Section 14.2.2, “Lease Database” for more information.

14.2.1. Configuration File
Link kopieren

The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Use this file to declare options for client systems.
The configuration file can contain extra tabs or blank lines for easier formatting. Keywords are case-insensitive and lines beginning with a hash sign (#) are considered comments.
There are two types of statements in the configuration file:
  • Parameters — State how to perform a task, whether to perform a task, or what network configuration options to send to the client.
  • Declarations — Describe the topology of the network, describe the clients, provide addresses for the clients, or apply a group of parameters to a group of declarations.
The parameters that start with the keyword option are referred to as options. These options control DHCP options; whereas, parameters configure values that are not optional or control how the DHCP server behaves.
Parameters (including options) declared before a section enclosed in curly brackets ({ }) are considered global parameters. Global parameters apply to all the sections below it.

Important

If the configuration file is changed, the changes do not take effect until the DHCP daemon is restarted with the command systemctl restart dhcpd.

Note

Instead of changing a DHCP configuration file and restarting the service each time, using the omshell command provides an interactive way to connect to, query, and change the configuration of a DHCP server. By using omshell, all changes can be made while the server is running. For more information on omshell, see the omshell man page.
In Example 14.1, “Subnet Declaration”, the routers, subnet-mask, domain-search, domain-name-servers, and time-offset options are used for any host statements declared below it.
For every subnet which will be served, and for every subnet to which the DHCP server is connected, there must be one subnet declaration, which tells the DHCP daemon how to recognize that an address is on that subnet. A subnet declaration is required for each subnet even if no addresses will be dynamically allocated to that subnet.
In this example, there are global options for every DHCP client in the subnet and a range declared. Clients are assigned an IP address within the range.

Example 14.1. Subnet Declaration

subnet 192.168.1.0 netmask 255.255.255.0 {
        option routers                  192.168.1.254;
        option subnet-mask              255.255.255.0;
        option domain-search              "example.com";
        option domain-name-servers       192.168.1.1;
        option time-offset              -18000;     # Eastern Standard Time
	range 192.168.1.10 192.168.1.100;
}
Copy to Clipboard Toggle word wrap
To configure a DHCP server that leases a dynamic IP address to a system within a subnet, modify the example values from Example 14.2, “Range Parameter”. It declares a default lease time, maximum lease time, and network configuration values for the clients. This example assigns IP addresses in the range 192.168.1.10 and 192.168.1.100 to client systems.

Example 14.2. Range Parameter

default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-search "example.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.100;
}
Copy to Clipboard Toggle word wrap
To assign an IP address to a client based on the MAC address of the network interface card, use the hardware ethernet parameter within a host declaration. As demonstrated in Example 14.3, “Static IP Address Using DHCP”, the host apex declaration specifies that the network interface card with the MAC address 00:A0:78:8E:9E:AA always receives the IP address 192.168.1.4.
Note that you can also use the optional parameter host-name to assign a host name to the client.

Example 14.3. Static IP Address Using DHCP

host apex {
   option host-name "apex.example.com";
   hardware ethernet 00:A0:78:8E:9E:AA;
   fixed-address 192.168.1.4;
}
Copy to Clipboard Toggle word wrap
Red Hat Enterprise Linux 7 supports assigning static IP addresses to InfiniBand IPoIB interfaces. However, as these interfaces do not have a normal hardware Ethernet address, a different method of specifying a unique identifier for the IPoIB interface must be used. The standard is to use the option dhcp-client-identifier= construct to specify the IPoIB interface’s dhcp-client-identifier field. The DHCP server host construct supports at most one hardware Ethernet and one dhcp-client-identifier entry per host stanza. However, there may be more than one fixed-address entry and the DHCP server will automatically respond with an address that is appropriate for the network that the DHCP request was received on.

Example 14.4. Static IP Address Using DHCP on Multiple Interfaces

If a machine has a complex configuration, for example two InfiniBand interfaces, and P_Key interfaces on each physical interface, plus an Ethernet connection, the following static IP construct could be used to serve this configuration: 
Host apex.0 {
    option host-name “apex.example.com”;
    hardware ethernet 00:A0:78:8E:9E:AA;
    option dhcp-client-identifier=ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:31:7b:11;
    fixed-address 172.31.0.50,172.31.2.50,172.31.1.50,172.31.3.50;
}

host apex.1 {
    option host-name “apex.example.com”;
    hardware ethernet 00:A0:78:8E:9E:AB;
    option dhcp-client-identifier=ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:31:7b:12;
    fixed-address 172.31.0.50,172.31.2.50,172.31.1.50,172.31.3.50;
}
Copy to Clipboard Toggle word wrap
In order to find the right dhcp-client-identifier for your device, you can usually use the prefix ff:00:00:00:00:00:02:00:00:02:c9:00 and then add the last 8 bytes of the IPoIB interface (which happens to also be the 8 byte GUID of the InfiniBand port the IPoIB interface is on). On some older controllers, this prefix is not correct. In that case, we recommend using tcpdump on the DHCP server to capture the incoming IPoIB DHCP request and gather the right dhcp-client-identifier from that capture. For example: 
]$ tcpdump -vv -i mlx4_ib0
tcpdump: listening on mlx4_ib0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
23:42:44.131447 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0x975cb024, Flags [Broadcast] (0x8000)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Hostname Option 12, length 10: "rdma-qe-03"
            Parameter-Request Option 55, length 18:
              Subnet-Mask, BR, Time-Zone, Classless-Static-Route
              Domain-Name, Domain-Name-Server, Hostname, YD
              YS, NTP, MTU, Option 119
              Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Static-Route
              Option 252, NTP
            Client-ID Option 61, length 20: hardware-type 255, 00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:02:00:21:ac:c1
Copy to Clipboard Toggle word wrap
The above dump shows the Client-ID field. The hardware-type 255 corresponds to the initial ff: of the ID, the rest of the ID is then quoted exactly as it needs to appear in the DHCP configuration file.
All subnets that share the same physical network should be declared within a shared-network declaration as shown in Example 14.5, “Shared-network Declaration”. Parameters within the shared-network, but outside the enclosed subnet declarations, are considered to be global parameters. The name assigned to shared-network must be a descriptive title for the network, such as using the title “test-lab” to describe all the subnets in a test lab environment.

Example 14.5. Shared-network Declaration

shared-network name {
    option domain-search            "test.redhat.com";
    option domain-name-servers      ns1.redhat.com, ns2.redhat.com;
    option routers                  192.168.0.254;
    #more parameters for EXAMPLE shared-network
    subnet 192.168.1.0 netmask 255.255.252.0 {
        #parameters for subnet
        range 192.168.1.1 192.168.1.254;
    }
    subnet 192.168.2.0 netmask 255.255.252.0 {
        #parameters for subnet
        range 192.168.2.1 192.168.2.254;
    }
}
Copy to Clipboard Toggle word wrap
As demonstrated in Example 14.6, “Group Declaration”, the group declaration is used to apply global parameters to a group of declarations. For example, shared networks, subnets, and hosts can be grouped.

Example 14.6. Group Declaration

group {
   option routers                  192.168.1.254;
   option subnet-mask              255.255.255.0;
   option domain-search              "example.com";
   option domain-name-servers       192.168.1.1;
   option time-offset              -18000;     # Eastern Standard Time
   host apex {
      option host-name "apex.example.com";
      hardware ethernet 00:A0:78:8E:9E:AA;
      fixed-address 192.168.1.4;
   }
   host raleigh {
      option host-name "raleigh.example.com";
      hardware ethernet 00:A1:DD:74:C3:F2;
      fixed-address 192.168.1.6;
   }
}
Copy to Clipboard Toggle word wrap

Note

You can use the provided example configuration file as a starting point and add custom configuration options to it. To copy this file to the proper location, use the following command as root: 
~]# cp /usr/share/doc/dhcp-version_number/dhcpd.conf.example /etc/dhcp/dhcpd.conf
Copy to Clipboard Toggle word wrap
... where version_number is the DHCP version number.
For a complete list of option statements and what they do, see the dhcp-options(5) man page.

14.2.2. Lease Database
Link kopieren

On the DHCP server, the file /var/lib/dhcpd/dhcpd.leases stores the DHCP client lease database. Do not change this file. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.
All times in the lease database are in Coordinated Universal Time (UTC), not local time.
The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~ and the temporary lease database is written to dhcpd.leases.
The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the dhcpd.leases file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

14.2.3. Starting and Stopping the Server
Link kopieren

Important

When the DHCP server is started for the first time, it fails unless the dhcpd.leases file exists. You can use the command touch /var/lib/dhcpd/dhcpd.leases to create the file if it does not exist. If the same server is also running BIND as a DNS server, this step is not necessary, as starting the named service automatically checks for a dhcpd.leases file.
Do not create a new lease file on a system that was previously running. If you do, all old leases are lost which causes many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.
To start the DHCP service, use the following command: 
systemctl start dhcpd.service
Copy to Clipboard Toggle word wrap
To stop the DHCP server, type: 
systemctl stop dhcpd.service
Copy to Clipboard Toggle word wrap
By default, the DHCP service does not start at boot time. For information on how to configure the daemon to start automatically at boot time, see Red Hat Enterprise Linux System Administrator's Guide.
If more than one network interface is attached to the system, but the DHCP server should only listen for DHCP requests on one of the interfaces, configure the DHCP server to listen only on that device. The DHCP daemon will only listen on interfaces for which it finds a subnet declaration in the /etc/dhcp/dhcpd.conf file.
This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users cannot connect to the daemon through the Internet.
To specify command-line options, copy and then edit the dhcpd.service file as the root user. For example, as follows: 
~]# cp /usr/lib/systemd/system/dhcpd.service /etc/systemd/system/
~]# vi /etc/systemd/system/dhcpd.service
Copy to Clipboard Toggle word wrap
Edit the line under section [Service]: 
ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid your_interface_name(s)
Copy to Clipboard Toggle word wrap
Then, as the root user, restart the service: 
~]# systemctl --system daemon-reload
~]# systemctl restart dhcpd
Copy to Clipboard Toggle word wrap
Command line options can be appended to ExecStart=/usr/sbin/dhcpd in the /etc/systemd/system/dhcpd.service unit file under section [Service]. They include:
  • -p portnum — Specifies the UDP port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responds to the client on port 68. If a port is specified here and the DHCP relay agent is used, the same port on which the DHCP relay agent should listen must be specified. See Section 14.3, “DHCP Relay Agent” for details.
  • -f — Runs the daemon as a foreground process. This is mostly used for debugging.
  • -d — Logs the DHCP server daemon to the standard error descriptor. This is mostly used for debugging. If this is not specified, the log is written to /var/log/messages.
  • -cf filename — Specifies the location of the configuration file. The default location is /etc/dhcp/dhcpd.conf.
  • -lf filename — Specifies the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is /var/lib/dhcpd/dhcpd.leases.
  • -q — Do not print the entire copyright message when starting the daemon.
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat