Relay agent design issues

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Relay agent design issues

There are important design issues to consider before you set up relay agents on your network.

When you have multiple DHCP servers, Microsoft recommends that you place your DHCP servers on different subnets, to achieve a degree of fault tolerance, rather than having all of them on one subnet. The servers should not have common IP addresses in their scopes (each server should have a unique pool of addresses).

If the DHCP server on the local subnet shuts down, requests are relayed to a remote subnet. The DHCP server at that location can respond to DHCP requests if it maintains a scope of IP addresses for the requesting subnet. If the remote server has no scope defined for the requesting subnet, it cannot provide IP addresses even if it has available addresses for other scopes. If each DHCP server has a pool of addresses for each subnet, then it can provide IP addresses for remote clients whose own DHCP server is offline.

Recommended

The following relay agent implementation is recommended for best routed DHCP network performance. It uses two DHCP servers that are attached to two different subnets. The relay agents operating on each of the routers used to connect the subnets have varied delay intervals (one is set to 4 seconds, the other uses no delay). This eliminates the risk of undesirable floods of DHCP packets through randomly selected network paths.

Not recommended

The following relay agent implementation is not recommended. It has the same number of DHCP servers and subnets as in the previous example, but less caution has been used. There is a higher risk of DHCP discovery messages (DHCPDISCOVERs), which are broadcast by the DHCP clients at startup, being randomly forwarded or duplicated when destined for the other subnets. Moreover, the relay agents do not use any delay interval. This increases the likelihood that both relay agents (routers) duplicate any client broadcasted messages, which could potentially flood the remote subnets.