Detailed explanation of DHCP protocol Application

For the use of the DHCP protocol, many enterprise network settings will involve relevant content. So how to set the relevant content? Here we will look at the use of dhcpd. First, let's look at the configuration file.

Name

Dhcpd. conf-dhcpd configuration file

Description

The dhcpd. conf file contains the configuration information of the dhcpd of isc dhcp.

The dhcpd. conf file is an ASCII code document in common format, which is interpreted by the built-in recursive parser.

The dhcpd. file may contain many additional tabs, spaces, and empty rows. They are designed to make the file easier to read. The keywords are not case sensitive. The comment statement can be placed anywhere except in quotation marks.) The comment statement starts with #. The comment statement ends naturally at the end of this line.

The file contains a set of statements in a pair of braces, including parameters and declarations.

Parameter statements describe how to do one thing, for example, how long the lease period is), or whether to do one thing. (For example, whether or not dhcpd provides an address for an unknown customer), or what parameter is provided to the customer (for example, use the gateway 220.177.244.7 ).

The Declaration is used to describe the network topology and the customers on the network. It provides the addresses that can be allocated to the client or the group parameter for a client group. In any group parameter, all these group parameters must appear first than statements using these group parameters.

The Network Declaration contains a multi-subnet network. It is difficult to understand the network definition. Here it is called "Multi-subnet network") and the topology Declaration of the subnet. For subnet clients to be dynamically allocated addresses, the subnet declaration must contain a range declaration statement. Each client must use a host declaration statement for Statically assigned addresses or known client installations. If a parameter is applied to a set of declarations that are not only related to a specific subnet, you can define a "group parameter ".

For each subnet to be served, the subnet connected to each dhcp server must have a subnet declaration to tell dhcpd how to handle the address on that subnet. Even if a subnet does not need to be assigned any address, a subnet declaration is required.

In some physical networks, there is not only one IP subnet. For example, if a network requires an eight-bit subnet, but when the business develops, the total number of nodes exceeds 254, you need to add an eight-bit subnet. A new physical network is added. In this case, the subnet Declaration of the two networks must be included in a "Multi-subnet network declaration super scope.

Some network clients not only have one subnet, but may assign some parameters to some clients in the same subnet different from those of other clients. In this way, you can use the host statement to define some parameters. Some parameters can also be defined in the "Group Parameters" Statement, which are called by these clients. For clients that need to obtain different addresses according to different situations, the statements "class Declaration class declarations)" and "condition declaration conditional declarations)" may be used, in this way, the parameters assigned to the client can be determined based on the information sent by the client.

When a client is started, the server first checks whether there is a host statement that matches the client. If not, check whether there is a matched "class Declaration class declarations)" statement, then, check whether there is a "pool" match, "subnet" match with "Multi-subnet network super scope) shared-net-work" match. According to the matching,) the client parameters will be provided to it. Each parameter is not analyzed for 2nd times. If they appear twice or more times, the most accurate location will be used.

Dhcpd first checks whether the client has a host statement containing a fixed IP address. The address must be in the subnet that the client starts or in the "Multi-subnet network". If no corresponding host statement matches, find the non-fixed address statement.

For example:

A typical dhcpd. conf file will look like the following:

 
 

  
  
global parameters...  
  
  
subnet 204.254.239.0 netmask 255.255.255.224 {  
  
  
subnet-specific parameters...  
  
  
range 204.254.239.10 204.254.239.30;  
  
  
}  
  
  
subnet 204.254.239.32 netmask 255.255.255.224 {  
  
  
subnet-specific parameters...  
  
  
range 204.254.239.42 204.254.239.62;  
  
  
}  
  
  
subnet 204.254.239.64 netmask 255.255.255.224 {  
  
  
subnet-specific parameters...  
  
  
range 204.254.239.74 204.254.239.94;  
  
  
}  
  
  
group {  
  
  
group-specific parameters...  
  
  
host zappo.test.isc.org {  
  
  
host-specific parameters...  
  
  
}  
  
  
host beppo.test.isc.org {  
  
  
host-specific parameters...  
  
  
}  
  
  
host harpo.test.isc.org {  
  
  
host-specific parameters...  
  
  
}  
  
  
} 
 
 

Figure 1

Note the beginning of the file. It is the place where global parameters are placed. It may be:

The domain name of the organization, the address of the DNS server if the server is the same for the entire network) and other. For example:

 
 

  
  
option domain-name "isc.org";  
  
  
option domain-name-servers ns1.isc.org, ns2.isc.org; 
 
 

Figure 2

As shown in 2, you can use the DNS server name instead of its IP address. If you specify more than one DNS server address, all the addresses will be provided to the client whenever possible.

The most likely required parameter to be specified for each subnet is router, as shown in 1. So for the first subnet, it should look like this

 
 

  
  
option routers 204.254.239.1; 
 
 

Note that the address here is in the digital format. If each gateway has a domain name, this is not necessary and the domain name is valid. However, in many cases, multiple gateways have only one domain name, so that they cannot be used.

In Figure 1, a group statement provides common parameters for a group of host statements zappo, beppo, and harpo. As you can see, these hosts are all in the field test.isc.org, so that it specifies in "group parameters" that will overwrite the global setting parameters:

 
 

  
  
option domain-name "test.isc.org"; 
 
 

In addition, specifying their domains may be used in testing machines. If we want to test the DHCP protocol lease mechanism, we can set a lease that is shorter than the default value here:

 
 

  
  
max-lease-time 120;  
  
  
default-lease-time 120; 
 
 

You may notice that some parameters start with the option keyword and some do not. The statements starting with the option keyword correspond to the actual DHCP options. Options starting with the option keyword do not control the server (for example, lease period) or client options are not in the DHCP protocol, for example, server name or file name)

In Figure 1, each host has a specified parameter, which contains the file name (filename parameter) to be uploaded, such as the hostname option ), the address of the server to be uploaded (the next-server parameter ). Generally, any parameter can appear anywhere, and the application range is determined based on the location where the parameter appears.

Suppose there are many X terminals without CD in your environment. These terminals have different models. You want to determine a STARTUP file for each model, one way is to use the host statement for each server and group:

 
 

  
  
group {  
  
  
filename "Xncd19r";  
  
  
next-server ncd-booter;  
  
  
host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }  
  
  
host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }  
  
  
host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }  
  
  
}  
  
  
group {  
  
  
filename "Xncd19c";  
  
  
next-server ncd-booter;  
  
  
host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }  
  
  
host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }  
  
  
}  
  
  
group {  
  
  
filename "XncdHMX";  
  
  
next-server ncd-booter;  
  
  
host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }  
  
  
host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }  
  
  
host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }  
  
  
} 
 
 

Address pool

The "pool" statement is used to define an address pool. Several pools can be defined even in the same CIDR block or subnet. The system will distinguish them through the "pool. For example, you may want to provide a short lease address for an unknown customer when a large IP address is assigned to the DHCP client. If there is a firewall, you may arrange an address pool for Internet access, and the other address pool for Internet access. This will encourage users to register in the DHCP protocol system, so they also need to establish two address pools:

 
 

  
  
subnet 10.0.0.0 netmask 255.255.255.0 {  
  
  
option routers 10.0.0.254;  
  
  
# Unknown clients get this pool.  
  
  
pool {  
  
  
option domain-name-servers bogus.example.com;  
  
  
max-lease-time 300;  
  
  
range 10.0.0.200 10.0.0.253;  
  
  
allow unknown-clients;  
  
  
}  
  
  
# Known clients get this pool.  
  
  
pool {  
  
  
option domain-name-servers ns1.example.com, ns2.example.com;  
  
  
max-lease-time 28800;  
  
  
range 10.0.0.5 10.0.0.199;  
  
  
deny unknown-clients;  
  
  
}  
  
  
} 
 
 

In the above example, known customers and unknown customers are in the same subnet, and may also allocate known and unknown customers in different subnets, or in "Multi-subnet Level Super scope) in this way, the address pool range may span across different subnets. As in the previous example, an address pool can allow or deny a group that controls user access. The group name must have the allow or deny keyword before it.

If a pool has an allowed list, only the matched clients can obtain the address of the address pool. If the pool has a deny list, only clients that do not match can obtain the address in the pool, if both allow and deny lists exist, the addresses in the pool can be obtained only by clients in the allow list and not in the deny list.

Dynamic Address Allocation

Address Allocation is actually completed only when the client is in the initial state and sends a DHCPDISCOVER message. If the client considers it to have a valid lease and sends a DHCPREQUEST message to initialize or update the lease, the server has only three options: 1) It can ignore the DHCPREQUEST information, in addition, a DHCPNAK message is returned to tell the client to stop using this address. 2) or send a DHCPACK message to tell the client to continue using this address for a while, if the server finds the Address requested by the client and the address is also available to this customer, the server sends a DHCPACK message. If the address is no longer available, the client cannot use it, at this time, the server will send a DHCPNAK message. 3) if the server does not know the address, it will first remain silent unless the address is incorrect for the address segment attached to the client, in this case, the server sends a DHCPNAK even if it does not know the address at all.

If a host statement defines the client and the host statement contains the fixed address fixed-address, this IP address is also valid for the actual network segment connected to the client, in this case, the DHCP server does not dynamically allocate addresses, but sends the addresses specified by the host statement. If the user sends a DHCPREQUEST message to obtain other addresses, the server will respond to a DHCPNAK message and refuse to allocate other addresses to the user.

When a DHCP server assigns a new address to the client (Remember, this only happens when the client sends DHCPDISCOVER information), it first looks for the lease file, check whether there is a valid address lease on the client, or whether the client has an address that has expired.) If yes, the server checks the address, check whether the client is allowed to use this address. If the client is no longer allowed to use this address, it is usually because the client has logged on from another subnet, or this address is occupied by other clients ), in addition, the original lease still exists in the server lease file, and the server releases the lease. In fact, the DHCPDISCOVER information sent by the client has proved that the client does not actually use the lease. If an existing lease is not found, or the client is forced to receive an existing lease, the server will find the address pool of the client's network segment, find an address that allows the client to use but is not used, it traverses each address pool in order (all the "range" range definition statements outside the address pool constitute a separate pool without a list of allowed ). If the allow list of the address pool allows the client to get the address in a pool, the address pool will be checked for available addresses. If yes, the client will get the address; otherwise, check the next address pool. If no available address is found, the server will not send a response. If you find an address that has never been used by any client before, the address will be allocated to the client immediately. If the address has been assigned to another client, the server will try to find an unallocated address to the client.

The DHCP server uses a hash table to generate a group of available IP addresses. This means that the addresses are not stored in any specific order, so that the next address to be allocated by the DHCP server cannot be predicted. In the previous version, the isc dhcp server uses a descending order to allocate addresses. Now it is not. In this version, there is no way to configure the order of Server distribution addresses (isc dhcp 3 ).

Prevents IP address conflicts

The DHCP server checks whether IP addresses are used to prevent conflicts before assigning IP addresses. It sends ICMP Echo request information to the IP address to be allocated. If the ICMP Echo reply information is not received within one second, it is assumed that the address is available. This applies only to the lease specified in the range statement and is valid when the lease is considered available by the DHCP server. For example, a DHCP server or its hot standby server does not list the lease in use. If an ICMP Echo response is received, the DHCP server assumes that a configuration error occurs-the IP address is used by the host on the network, and then it marks the address as an "obsolete address ", it is no longer assigned to the client. If the DHCP client tries to get an address but there is no available address, the server will randomly mark an "obsolete address" as "available ", then, send the same ICMP Echo request to this address. If no ICMP Echo reply response is received, this address will be allocated to this customer.

If the first IP address to be withdrawn is available, the DHCP server will not recycle the "obsolete IP Address ". In addition, when the DHCPDISCOVER information of the next customer arrives, it will start a new allocation in the same way and try to assign a new IP address.