Configuring a dhcrelay Server

The DHCP relay agent (dhcrelay) is provided as part of the dhcpd distribution. The relay agent listens for DHCP boot requests, and forwards those requests to a DHCP server. The relay agent must be attached to the same subnet as the DHCP client because the request from the client uses the limited broadcast address. However, the relay does not need to share a subnet with the server because it uses the server's IP address to send the request directly to the server. The server then sends the DHCP reply packet back to the relay. The relay is responsible for broadcasting the reply packet on the local subnet so that the client can retrieve it.

Use the dhcrelay command to run a DHCP relay. A simple dhcrelay command is dhcrelay -q 172.16.70.3

The -q option tells dhcrelay not to print out network configuration information when it starts. Normally, it does. If the dhcrelay command is placed in a startup script such as rc.local, use the -q option to prevent the configuration from printing out during the boot.

The IP address on the command line is the address of the DHCP server. When dhcrelay receives a DHCP request on the local network, it sends that request to 172.16.70.3. To use more than one DHCP server, specify multiple servers on the command line, as follows:

dhcrelay -q 172.16.70.3 172.16.90.4

dhcrelay sends the request to all of the servers listed on the command line.

On occasion, the DHCP relay service is configured on a Linux system that is also acting as a router for a small network. In that case, the router has more than one interface, and should be configured to provide DHCP relay service for the correct interface. For example, assume that you have a small router with two Ethernet interfaces: eth0 and eth1. eth0 is connected to a backbone network with other routers. eth1 is connected to a local subnet that has DHCP clients that need DHCP relay service. The dhcrelay command for this situation might be dhcrelay -i eth1 172.16.70.3

This command tells dhcrelay to listen for DHCP requests only on interface eth1. When it receives any, it forwards them to 172.16.70.3.

The placement of DHCP servers and relays, and the coordination between all of these systems is an important part of planning a DHCP service. A conflict exists between centralizing control to reduce configuration errors, and improving booting efficiency and redundancy by placing the configuration servers close to the clients. The centralized solution places one large DHCP server in the central facility and a relay server on each subnet; the distributed solution uses no central server and places a DHCP server on every subnet. A real-life solution that combines elements of both is described in the following sidebar, "Placing DHCP Servers."

Placing DHCP Servers

An enterprise network composed of about 60 subnets decided to deploy DHCP servers. About 40 of the subnets were located at the sprawling headquarters facility. The remaining networks were located about 1500 miles away at a large production facility. The two sites were connected directly by a private leased circuit.

Clearly, the remote production facility could not depend on headquarters for configuration services. The company was forced to accept some level of distribution. Their computer services group offered two types of network support. For one level of support, they handled everything from setup to maintenance, and they used an internal billing mechanism to recover the cost of support from their internal customers. The other level of support allowed an organization to run its own subnet. The organization was assigned a subnet number, and was connected to the rest of the enterprise through a router run by the services group. This service was much less expensive. These two support models offered freedom when the organization could handle it, and offered support when the organization wanted and needed it.

Pleased with their support model, the company decided to replicate this service model in its configuration server architecture. Every organization that ran its own subnet was encouraged to buy and install its own DHCP server; because those organizations handled their own maintenance and had the best idea of their own requirements, the final decision on using DHCP was left to them. Every subnet that was under central support was given a DHCP server. These servers were not quite central servers, and they were not quite distributed servers because each server was co-located with one of the routers run by the central services group. The DHCP server was then directly connected to each of the subnets coming into the router.

The 36 subnets that were under central support were covered by 10 Linux servers. Here's a sample configuration from one of those servers:

# Define global values that apply to all systems, option subnet-mask 255.255.255.0; option domain "foobirds.org";

option domain-name-servers 172.16.55.1, 172.16.12.3;

# Identify the subnets subnet 172.16.42.0 netmask 255.255.255.0 { option routers 172.16.42.254; option broadcast-address 172.16.41.255; range 172.16.42.50 172.16.42.250;

subnet 172.16.52.0 netmask 255.255.255.0 { option routers 172.16.52.254; option broadcast-address 172.16.52.255; range 172.16.52.50 172.16.52.250;

subnet 172.16.62.0 netmask 255.255.255.0 { option routers 172.16.62.254; option broadcast-address 172.16.62.255; range 172.16.62.50 172.16.62.250;

subnet 172.16.72.0 netmask 255.255.255.0 { option routers 172.16.72.254; option broadcast-address 172.16.72.255;

range 172.16.72.50 172.16.72.250;

No DHCP relay servers were required for this configuration. Sharing space with the routers made it possible to directly connect centrally maintained servers to every subnet. These "area" servers provided the advantages of central control with the speed and redundancy of distributed servers.

Was this article helpful?

0 0

Post a comment