DHCP

Certify and Increase Opportunity.
Be
Govt. Certified Linux Administrator

Dynamic Host Configuration Protocol (DHCP) is a network protocol to automatically assign an IP address and other network configuration to a computer from a defined range of numbers (i.e., a scope) configured for a given network. DHCP assigns an IP address when a system is started as

A user turns on a computer with a DHCP client.
The client computer sends a broadcast request (called a DISCOVER or DHCPDISCOVER), looking for a DHCP server to answer.
The router directs the DISCOVER packet to the correct DHCP server.
The server receives the DISCOVER packet. Based on availability and usage policies set on the server, the server determines an appropriate address (if any) to give to the client. The server then temporarily reserves that address for the client and sends back to the client an OFFER (or DHCPOFFER) packet, with that address information. The server also configures the client’s DNS servers, WINS servers, NTP servers, and sometimes other services as well.
The client sends a REQUEST (or DHCPREQUEST) packet, letting the server know that it intends to use the address.
The server sends an ACK (or DHCPACK) packet, confirming that the client has a been given a lease on the address for a server-specified period of time.

A computer is manually configured to use specified IP address but it can result in error or inattention to detail resulting in IP address conflict hence, DHCP is used. DHCP server uses three methods for allocating IP-addresses as

Dynamic allocation- A range of IP addresses is assigned to DHCP server and each client requests an IP address from DHCP server for a lease with a controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed.
Automatic allocation- The DHCP server permanently assigns a IP address to a requesting client from the range defined. But DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.
Static allocation- The DHCP server allocates an IP address based on a table with MAC address/IP address pairs, which are manually filled by administrator. It is not supported by all DHCP servers.

DHCP uses two ports destination UDP port 67 for sending data to the server, and UDP port 68 for data to the client. DHCP communications are connectionless in nature. DHCP clients and servers on the same subnet communicate via UDP broadcasts else for different subnets, a DHCP Helper or DHCP Relay Agent is used.

DHCP is useful for automatic configuration of client network interfaces. When configuring the client system, the administrator chooses DHCP instead of specifying an IP address, netmask, gateway, or DNS servers. The client retrieves this information from the DHCP server. DHCP is also useful if an administrator wants to change the IP addresses of a large number of systems. Instead of reconfiguring all the systems, he can just edit one DHCP configuration file on the server for the new set of IP addresses. If the DNS servers for an organization changes, the changes are made on the DHCP server, not on the DHCP clients. When the administrator restarts the network or reboots the clients, the changes will go into effect.

If an organization has a functional DHCP server properly connected to a network, laptops and other mobile computer users can move these devices from office to office.

Working

The client daemon, dhclient (part of the dhcp package), contacts the server daemon, dhcpd, to obtain the IP address, netmask, broadcast address, nameserver address, and other networking parameters. The server provides a lease on the IP address to the client. The client can request the specific terms of the lease, including its duration; the server can, in turn, limit these terms. While connected to the network, a client typically requests extensions of its lease as necessary so its IP address remains the same. The lease can expire once the client is disconnected from the network, with the server giving the client a new IP address when it requests a new lease. You can also set up a DHCP server to provide static IP addresses for specific clients

DHCP is broadcast based, so both client and server must be on the same subnet

DHCP server

The DHCP server maintains a list of IP addresses and other configuration parameters. When requested to do so, the DHCP server provides configuration parameters to a client.

Execute these two steps before configuring DHCP –

dhcp – Run chkconfig to cause dhcpd to start when the system enters multiuser mode – # /sbin/chkconfig dhcpd on
Start dhcpd: # /sbin/service dhcpd start

$cat /etc/dhcp/dhcpd.conf

default-lease-time 600;

max-lease-time 86400;

option subnet-mask 255.255.255.0;

option broadcast-address 192.168.1.255;

option routers 192.168.1.1;

option domain-name-servers 192.168.1.1;

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.2 192.168.1.200;

}

The preceding configuration file specifies a LAN where the router and DNS are both located on 192.168.1.1. The default-lease-time specifies the number of seconds the dynamic IP lease will remain valid if the client does not specify a duration. The max-lease-time is the maximum time allowed for a lease.

The information in the option lines is sent to each client when it connects. The names following the word option specify what the following argument represents. For example, the option broadcast-address line specifies the broadcast address of the network. The routers and domain-name-servers options can be followed by multiple values separated by commas.

The subnet section includes a range line that specifies the range of IP addresses that the DHCP server can assign. If you define multiple subnets, you can define options, such as subnet-mask, inside the subnet section. Options defined outside all subnet sections are global and apply to all subnets.

The preceding configuration file assigns addresses in the range between 192.168.1.2 and 192.168.1.200. The DHCP server starts at the bottom (FEDORA) or top (RHEL) of this range and attempts to assign a new IP address to each new client. Once the DHCP server reaches the top/bottom of the range, it starts reassigning IP addresses that have been used in the past, but are not currently in use. If you have fewer systems than IP addresses, the IP address of each system should remain fairly constant. You cannot use the same IP address for more than one system at a time. Once you have configured a DHCP server, you can start (or restart) it by using the dhcpd init script:

#/sbin/service dhcpd restart

Once the server is running, clients configured to obtain an IP address from the server using DHCP should be able to do so.

Other command line options that can be specified in /etc/sysconfig/dhcpd 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 responses 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.
-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/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.

A DHCP server can be configured with more than one range (subnet) of IP addresses. The parameters specified above the “subnet” declaration are global parameters which are applied to all subnet declarations, while the parameters inside each subnet override the global parameters.

Parameter	Definition
ddns-update-style	Type of DDNS update to use with local DNS Server
ignore client-updates	Ignore all client requests for DDNS update
lease-file-name	Filename that stores list of active IP lease allocations
authoritative	Set as master server, protects against rogue DHCP servers and misconfigured clients
option domain-name	Specifies the Internet Domain Name to append to a client’s hostname
option domain-name-servers	The DNS servers the clients should use for name resolution
default-lease-time	The default time in seconds that the IP is leased
max-lease-time	The max time in seconds that the IP is leased
option routers	Specifies the Gateway for the client to use
option subnet-mask	The subnet mask specific to the lease range
option broadcast-address	The broadcast address specific to the lease range
option ntp-servers	Network Time Protocol servers available to the clients
option netbios-name-server	The NetBIOS name server (WINS)
option netbios-node-type	The NetBIOS name resolution method (8=hybrid)
range	The range of valid IP addresses available for client offer

The DHCP server can be quite tricky to configure and normally does not provide any error messages when it fails to start as a service. Ensure your configuration file is formatted similar to the example above, and that semicolons complete all the parameter lines.

If the network on which the DHCP server is broadcasting does not have a WINS server, then the netbios-name-server and netbios-node-type options should be removed.

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. For example, you may want to provide a large set of addresses that can be assigned to DHCP clients that are registered to your DHCP server, while providing a smaller set of addresses, possibly with short lease times, that are available for unknown clients. If you have a firewall, you may be able to arrange for addresses from one pool to be allowed access to the Internet, while addresses in another pool are not, thus encouraging users to register their DHCP clients.

Dynamic Address Allocation – Address allocation is actually only done when a client is in the INIT state and has sent a DHCPDISCOVER message. If the client thinks it has a valid lease and sends a DHCPREQUEST to initiate or renew that lease, the server has only three choices – it can ignore the DHCPREQUEST, send a DHCPNAK to tell the client it should stop using the address, or send a DHCPACK, telling the client to go ahead and use the address for a while.

If the server finds the address the client is requesting, and that address is available to the client, the server will send a DHCPACK. If the address is no longer available, or the client isn’t permitted to have it, the server will send a DHCPNAK. If the server knows nothing about the address, it will remain silent, unless the address is incorrect for the network segment to which the client has been attached and the server is authoritative for that network segment, in which case the server will send a DHCPNAK even though it doesn’t know about the address.

There may be a host declaration matching the client’s identification. If that host declaration contains a fixed-address declaration that lists an IP address that is valid for the network segment to which the client is connected. In this case, the DHCP server will never do dynamic address allocation. In this case, the client is required to take the address specified in the host declaration. If the client sends a DHCPREQUEST for some other address, the server will respond with a DHCPNAK.

When the DHCP server allocates a new address for a client (remember, this only happens if the client has sent a DHCPDISCOVER), it first looks to see if the client already has a valid lease on an IP address, or if there is an old IP address the client had before that hasn’t yet been reassigned. In that case, the server will take that address and check it to see if the client is still permitted to use it. If the client is no longer permitted to use it, the lease is freed if the server thought it was still in use – the fact that the client has sent a DHCPDISCOVER 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 attached for a lease that is not in use and that the client is permitted to have. It looks through each pool declaration in sequence (all range declarations that appear outside of pool declarations are grouped into a single pool with no permit list). If the permit list for the 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 so, then the client is tentatively assigned that address. Otherwise, the next pool is tested. If no addresses are found that can be assigned to the client, no response is sent to the client.

If an address is found that the client is permitted to have, and that has never been assigned to any client before, the address is immediately allocated to the client. If the address is available for allocation but has been previously assigned to a different client, the server will keep looking in hopes of finding an address that has never before been assigned to a client.

The DHCP server generates the list of available IP addresses from a hash table. This means that the addresses are not sorted in any particular order, and so it is not possible to predict the order in which the DHCP server will allocate IP addresses. Users of previous versions of the ISC DHCP server may have become accustomed to the DHCP server allocating IP addresses in ascending order, but this is no longer possible, and there is no way to configure this behavior with version 3 of the ISC DHCP server.

IP Address Conflict Prevention – The DHCP server checks IP addresses to see if they are in use before allocating them to clients. It does this by sending an ICMP Echo request message to the IP address being allocated. If no ICMP Echo reply is received within a second, the address is assumed to be free. This is only 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 the lease as in use.

If a response is received to an ICMP Echo request, the DHCP server assumes that there is a configuration error – the IP address is in use by some host on the network that is not a DHCP client. It marks the address as abandoned, and will not assign it to clients.

If a DHCP client tries to get an IP address, but none are available, but there are abandoned IP addresses, then the DHCP server will attempt to reclaim an abandoned IP address. It marks one IP address as free, and then does the same ICMP Echo request check described previously. If there is no answer to the ICMP Echo request, the address is assigned to the client.

The DHCP server does not cycle through abandoned IP addresses if the first IP address it tries to reclaim is free. Rather, when the next DHCPDISCOVER comes in from the client, it will attempt a new allocation using the same method described here, and will typically try a new IP address.

DHCP Failover – This version of the ISC DHCP server supports the DHCP failover protocol as documented in draft-ietf-dhc-failover-07.txt. This is not a final protocol document, and we have not done interoperability testing with other vendors’ implementations of this protocol, so you must not assume that this implementation conforms to the standard. If you wish to use the failover protocol, make sure that both failover peers are running the same version of the ISC DHCP server.

The failover protocol allows two DHCP servers (and no more than two) to share a common address pool. Each server will have about half of the available IP addresses in the pool at any given time for allocation. If one server fails, the other server will continue to renew leases out of the pool, and will allocate new addresses out of the roughly half of available addresses that it had when communications with the other server were lost.

It is possible during a prolonged failure to tell the remaining server that the other server is down, in which case the remaining server will (over time) reclaim all the addresses the other server had available for allocation, and begin to reuse them. This is called putting the server into the PARTNER-DOWN state.

You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by stopping the server, editing the last peer state declaration in the lease file, and restarting the server. If you use this last method, be sure to leave the date and time of the start of the state blank:

failover peer name state {

my state partner-down;

peer state state at date;

}

When the other server comes back online, it should automatically detect that it has been offline and request a complete update from the server that was running in the PARTNER-DOWN state, and then both servers will resume processing together.

It is possible to get into a dangerous situation: if you put one server into the PARTNER-DOWN state, and then *that* server goes down, and the other server comes back up, the other server will not know that the first server was in the PARTNER-DOWN state, and may issue addresses previously issued by the other server to different clients, resulting in IP address conflicts. Before putting a server into PARTNER-DOWN state, therefore, make sure that the other server will not restart automatically.

Static IP

There may be a time when it is necessary for a workstation to be assigned a fixed address, this can be easily achieved by setting the following details in the bottom of the /etc/dhcpd.conf file.

host wkstn1 {

hardware ethernet 00:0d:62:d7:a0:12;

fixed-address 192.168.1.5;

}

Setting fixed addresses saves the operator time by avoiding the manual adjustments needed at each workstation. Be sure to remove the fixed address when it is no longer required, this is particularly important on larger networks where IP allocation needs careful management.

DHCP Client

Now that the server is configured and running successfully, its time to test the server by requesting an IP lease from a Linux or Windows client. The DHCP protocol uses UDP on port 67 to broadcast for and reply to DHCP requests, ensure that the clients have access through any firewall system to successfully obtain an IP address.

Linux Client – If the Linux client distribution you are testing uses the dhclient package from the Internet Systems Consortium, then use the following command to obtain a lease for the eth0 network device.

[bash]# dhclient eth0 (EXECUTED ON CLIENT WORKSTATION)

Internet Systems Consortium DHCP Client V3.0.1

For info, please visit http://www.isc.org/products/DHCP

Listening on LPF/eth0/00:0d:62:d7:a0:12

Sending on LPF/eth0/00:0d:62:d7:a0:12

Sending on Socket/fallback

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4

DHCPOFFER from 192.168.1.1

DHCPREQUEST on eth0 to 255.255.255.255 port 67

DHCPACK from 192.168.1.1

bound to 192.168.1.5 — renewal in 20509 seconds.

By viewing the system log after renewing a DHCP client’s lease, the transaction between client and server can be viewed. The following transaction records the fixed address 192.168.1.5 that was covered earlier being assigned to the reserved MAC address.

[bash]# grep dhcpd /var/log/messages (EXECUTED ON DHCP SERVER)

galaxy dhcpd: DHCPDISCOVER from 00:0d:62:d7:a0:12 via eth0

galaxy dhcpd: DHCPOFFER on 192.168.1.5 to 00:0d:62:d7:a0:12 via eth0

galaxy dhcpd: DHCPREQUEST for 192.168.1.5 (192.168.1.1) from 00:0d:62:d7:a0:12 via eth0

galaxy dhcpd: DHCPACK on 192.168.1.5 to 00:0d:62:d7:a0:12 via eth0

If your Linux client is using the pump dhcpclient, then the following commands can be used to release, obtain, or view the status of the client.

[bash]# pump -i eth0

[bash]# pump -i eth0 –release

[bash]# pump -i eth0 –status

Windows Client – Testing a Windows based DHCP client is best done from a command prompt in the DOS shell, as more information is returned to the user than the standard graphical tools.

To release and renew your windows based IP address, follow these examples (expected results are provided).

C:\>ipconfig /release

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :

IP Address. . . . . . . . . . . . : 0.0.0.0

Subnet Mask . . . . . . . . . . . : 0.0.0.0

Default Gateway . . . . . . . . . :

C:\>ipconfig /renew

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : example.com