The Dynamic Host Configuration Protocol (DHCP) is used to assign IP addresses, host names, netmasks, default gateways and other IP configuration to client machines at startup. Thanks to this protocol, machines can just be connected to the network and obtain a usable configuration automatically. The client configuration is quite simple, it just has to be told whether it must issue a DHCP request or use a static configuration. Configuration on the server side is more complex. At the very least, the server must be given a range of IP addresses it is allowed to assign to clients, as well as the other IP parameters. Most servers also allow rules to further define how IP addresses are assigned. One option is to define a fixed mapping from MAC addresses to IP address. If a machine is not in the list of known MAC addresses, the server can be told to assign it an IP from another block, or to exclude it from the network by not issuing an IP for it.
The DHCP protocol is connectionless. A client sends a DHCP discovery, which is broadcasted, since the client does not have any information on the network it is in. The discovery message tells the MAC address of the client machine to let the server know where to send its answer to. DHCP servers listen for such broadcasts and respond with a DHCP offer message providing the necessary configuration data. After a successful IP assignment, either the client or the server should inform the DNS server about the new hostname - IP pair. Some DHCP servers allow the configuration of this feature, although DHCP clients of all modern Operating Systems can inform the DNS servers by themselves.
If there are several DHCP servers, which is recommended since it increases redundancy in case one of them crashes, there might be more than one DHCP offer sent in response to a discovery broadcast. The client has to choose which offer to take and broadcasts a DHCP request for the selected offer. The server with the selected offer responds with an acknowledgement. The other DHCP servers see the request and treat it as refusal of their offer. If they had reserved an IP for the offer, it is released at this moment. Redundant DHCP servers should be configured to be responsible for distinct blocks of IP addresses, in order to avoid having the same IP assigned to
3.6. DYNAMIC HOST CONFIGURATION PROTOCOL 31
two different machines.
The server response also sets the ‘lease time’, i.e. the time until the information expires and an update should be requested by the client. The server marks the IP it has assigned as used until the lease time is finished. If the client is still running, it can send a request to keep that address.
The client can ask for a specific IP address by specifying it in the request, usually an IP it has previously been assigned. If the address is still available, or reserved for that client, the server will accept the request. However, the address might have been assigned to another machine in the mean time, or come from a different network and would be invalid in the current network. If one of the DHCP servers is responsible for a requested but unavailable IP, it sends a not acknowledged message, causing the client to ask for a new address. But when a machine is moved between two different networks, as happens with laptops, for example, there may be no server responsible for an address. Then the client waits for a response to its request until timeout, which can take several minutes. At least one of the servers should be configured to be authoritative, meaning it will send a not acknowledged message for any address not in the network. In a setup with redundant DHCP servers covering different IP blocks, the authoritative server of course needs to know about all of the blocks, or it might refuse valid requests.
Part II
Network Configuration
Chapter 4
Use Cases
To get an idea of the different tasks a network management solution should support, this chapter presents a series of use cases. It is focused on tasks covered by Verinec, although there are many other challenges in network management.
4.1
Configuring a Complex Network Consistently
Devices involved in the same communication should be set up in a consistent manner. While it is relatively easy to check whether one device is configured with values according to the specifications, it is more difficult to determine whether all of the devices are set up in a way that allows them to communicate with each other.
Figure 4.1: Consistent network. For example, take the case of Figure 4.1. It is
a network in a two-floor building. On each floor, there is a subnet with client machines. Each subnet has a gateway router connecting it to the server. If one of the clients wants to connect to the server, it must use the address of the gateway it is actually connected to. It is ineffective if the client tries to use the gateway of the subnet of the other floor. Should client1 try to use gw-floor2 as its gateway instead of gw-floor1, the client will not be able to contact to it, in spite of the fact that the gateway does exist in the network. A simple search for the gateway in a configuration database of listed machines present in the network is not enough to show that this setting will not work. The network layout has to be taken into account to detect inconsistencies of this kind. Thus, in order to assess the correctness of the config- uration, the management application needs detailed
knowledge of the network layout, as well as the devices in it.
34 CHAPTER 4. USE CASES