DHCP Relay Agents
Bridging the Broadcast Boundary
The Broadcast Dilemma
DHCP's four-way handshake (DISCOVER, OFFER, REQUEST, ACK) begins with a broadcast. A client with no IP address sends a DHCPDISCOVER to — the limited broadcast address, which routers do not forward by design. In a flat network with one VLAN and one subnet, this works fine: the DHCP server sits in the same broadcast domain.
Scale this to a university campus with 500 VLANs, or a hospital with 200 isolated clinical segments, or an ISP with thousands of subscriber VLANs. Deploying individual DHCP servers in each segment is operationally impossible and creates an enormous management surface for IP address conflicts, scope mismanagement, and security gaps. The solution is centralized DHCP services — accessed across Layer 3 boundaries via DHCP Relay.
Internal Header Modification: GIADDR in Depth
The key to the relay mechanism is the GIADDR (Gateway IP Address) field in the BOOTP/DHCP packet header. When a relay agent intercepts a DHCPDISCOVER, it:
- Sets the GIADDR field to the IP address of its interface on the client's subnet (not its management interface).
- Increments the "hops" field by 1 (each relay agent increments this; servers reject packets with hops exceeding a threshold, preventing loops).
- Forwards the modified packet to the DHCP server as a unicast.
The DHCP server uses the GIADDR to identify the correct scope (pool). It selects an available IP address from the matching subnet and sends the DHCPOFFER back to the GIADDR address as destination.
DHCP Option 82: Circuit-Level Metadata
In large ISP or campus environments, knowing the source subnet is insufficient. A DHCP server managing cable modem or DSL subscribers needs to know exactly which physical port, which DSLAM, and which subscriber line originated a request to enforce per-subscriber policies. Option 82 (RFC 3046) — the Relay Agent Information Option — addresses this.
Option 82 is a container option with sub-options inserted by the relay agent:
- Sub-option 1 — Agent Circuit ID: Identifies the specific VLAN and physical port on the access switch (e.g., "Gi0/1, VLAN 100"). Format is vendor-specific but commonly encodes switch hostname, slot/port, and VLAN ID.
- Sub-option 2 — Agent Remote ID: Identifies the relay agent itself — typically its MAC address or SNMP system name. Useful when multiple relay agents forward to the same server.
- Sub-option 5 — Link Selection: Allows the relay agent to specify a different subnet for scope matching than implied by GIADDR — useful in VRF-aware or complex multi-tenant deployments.
The DHCP server uses these sub-options to assign addresses from policy-defined pools, enforce MAC-to-port bindings, trigger subscriber activation workflows, or log events for billing and audit systems.
The Return Path and Relay in HA Environments
The DHCP server addresses its DHCPOFFER to the unicast GIADDR. The relay agent receives the offer and must relay it back to the client. For clients that do not yet have an IP (during DISCOVER/OFFER), the relay agent broadcasts the offer onto the local VLAN. For DHCPREQUEST and DHCPACK (where the client knows its tentative IP), many implementations switch to unicast delivery, reducing VLAN noise.
In high-availability gateway designs — HSRP, VRRP, GLBP — relay configuration requires careful attention. The IP Helper-Address (Cisco's relay configuration command) must be identically configured on both active and standby routers. If the standby lacks the helper, clients only obtain addresses when the active peer is forwarding. The GIADDR should be set to the SVI (Switched Virtual Interface) address on the physical device — NOT the virtual gateway IP — so the server can return packets correctly regardless of which router is active.
DHCPv6 and the Relay Equivalent
IPv6 uses DHCPv6 (RFC 3315) with a similar relay architecture. DHCPv6 Relay Agents forward messages encapsulated in Relay-Forward messages using the interface's link-local address as the peer-address. Option 18 (Interface ID) and Option 37 (Remote ID) serve the same roles as Option 82 sub-options 1 and 2. In dual-stack networks, both DHCP and DHCPv6 relay must be configured independently on the gateway interface — they use separate databases, separate scopes, and separate relay processes even when running on the same hardware.
DHCP Relay Troubleshooting: Systematic Diagnostics for IP Allocation Failures
DHCP relay failures are among the most challenging network problems to diagnose because the failure can occur at any layer and at any point in the four-message DORA (Discover, Offer, Request, Acknowledge) exchange. A systematic troubleshooting methodology is essential. The first diagnostic step is to determine whether the DHCP client is sending a Discover message at all. On the client device, running a packet capture (using Wireshark or tcpdump) on the client's network interface will show whether the client is generating DHCP Discover packets. Common reasons for a client not sending a Discover include: the client's network interface is disabled, the DHCP client service is not running (on Windows, the "DHCP Client" service must be started), or the client has been configured with a static IP address that bypasses DHCP. Once the client is confirmed to be sending Discover messages, the next step is to verify that the Discover message reaches the DHCP server. On the DHCP server, a packet capture on the server's network interface will show whether the server is receiving Discover messages. If the server is not receiving the Discover messages, the relay agent is not forwarding them, and the engineer must examine the relay agent configuration.
The most common misconfiguration of a DHCP relay agent is an incorrect helper-address pointing to the wrong DHCP server, or a missing helper-address entirely. On Cisco IOS, the "ip helper-address [server-IP]" command must be configured on the interface that receives the DHCP client broadcasts—typically the VLAN interface (SVI) or the routed interface facing the clients. A common mistake is to configure the helper-address on the wrong interface (e.g., on the interface facing the DHCP server instead of the interface facing the clients). Another common issue is that the helper-address is configured but the DHCP server is on a different VRF. In VRF-lite deployments, the DHCP server may be in a different VRF from the client VLAN, and the relay agent cannot forward the unicast DHCP messages across VRF boundaries unless the relay agent is configured with the "ip helper-address vrf [VRF-name] [server-IP]" syntax. This VRF mismatch is a particularly insidious failure mode because the relay agent appears to be configured correctly (the "show ip interface" command shows the helper address), but the DHCP server never receives the relayed messages because the relay agent is trying to forward them in the wrong VRF routing table.
If the DHCP server is receiving Discover messages but not sending Offer messages, the problem is typically on the DHCP server itself. The most common cause is that the DHCP scope for the client's subnet is not configured or is full (no available IP addresses). On a Windows DHCP server, the "DHCP Server Service" must be running, and the scope must be "Active" and must have available addresses in the exclusion range. On an ISC DHCP server (common on Linux), the subnet declaration in the dhcpd.conf file must match the GIADDR field in the relayed Discover message. The GIADDR (Gateway IP Address) is set by the relay agent to the IP address of the interface on which the original Discover was received. The DHCP server uses this GIADDR to select the appropriate scope for the client. If the DHCP server does not have a scope matching the GIADDR, it will not respond to the Discover message. This is a common source of failure when a relay agent's interface IP address is changed (e.g., during a subnet renumbering) but the DHCP server's scope configuration is not updated to match.
When the DHCP server sends an Offer message but the client never receives it, the failure is typically in the return path of the relay agent. The DHCP server sends the Offer as a unicast IP packet to the GIADDR (the relay agent), which the relay agent is expected to convert back to a broadcast Ethernet frame on the client's subnet. If the return path from the DHCP server to the relay agent is blocked (by a firewall, access control list, or routing issue), the client never receives the Offer. The firewall between the DHCP server and the relay agent must permit UDP ports 67 (BOOTPS) and 68 (BOOTPC) for both client-to-server (Discover/Request) and server-to-client (Offer/Ack) traffic. It is important to note that the direction of the traffic changes after the initial Discover: the client-to-server messages are broadcast with source port 68 and destination port 67, while the server-to-client messages are unicast with source port 67 and destination port 68. Some firewall rules only permit the client-to-server direction, causing the server-to-client messages to be blocked. This asymmetric firewall blocking is one of the most common DHCP relay troubleshooting findings in enterprise networks.
The interaction between DHCP relay and other Layer 2 features can introduce additional failure modes that are difficult to diagnose. DHCP snooping, when enabled on the switch that connects the client, intercepts all DHCP messages and validates them against the DHCP snooping binding database before forwarding them. If the DHCP snooping database is corrupted or if the switch is not configured to trust the DHCP server port, the switch may drop legitimate DHCP Offer or Ack messages, preventing the client from obtaining an IP address. The solution is to verify that the port connecting to the DHCP server (or the DHCP relay agent) is configured as a "trusted" port for DHCP snooping: "ip dhcp snooping trust" on Cisco switches. Similarly, Dynamic ARP Inspection (DAI) can interfere with DHCP relay if the DHCP server's MAC address is not correctly recorded in the DAI database. Port security (which limits the number of MAC addresses on a switch port) can also interfere: if the client's MAC address changes during the DHCP process (which happens with some NIC drivers that use a randomized MAC address for DHCP), port security may block the client's traffic. The systematic troubleshooting of DHCP relay failures must therefore consider not only the relay agent and server configuration but also the broader Layer 2 security framework that may be filtering the DHCP messages.
DHCP Option 82: Security Implications and Deployment Considerations
DHCP Option 82 (Relay Agent Information Option) was originally designed to solve IP address management problems in broadband aggregation networks, but it has become a critical security tool for enterprise networks as well. Option 82 allows the DHCP relay agent (typically a switch) to insert additional information into DHCP messages, including the switch port and the VLAN ID on which the client request was received. This information enables the DHCP server to assign IP addresses based on the client's physical location in the network, rather than simply based on its MAC address. For example, in a university dormitory network, the DHCP server can be configured to assign IP addresses from the "Residential" subnet range when the client is connected to a port in a dormitory building, and from the "Academic" subnet range when the client is connected to a port in a classroom building—even if all building switches are on the same VLAN. This location-based IP assignment is implemented by configuring the DHCP server to examine the Option 82 circuit ID (which identifies the switch and port) and to select the scope based on matching the circuit ID pattern.
The security implications of Option 82 are profound. Because Option 82 carries physical location information in the DHCP message, an attacker can manipulate Option 82 to trick the DHCP server into assigning an IP address from a different subnet. This is known as an "Option 82 spoofing" attack. An attacker connected to a guest network port could forge an Option 82 field in their DHCP Discover message, claiming to be connected to a management network port, and potentially obtain a management IP address that provides access to infrastructure devices. The defense against Option 82 spoofing is to configure the switch to "trust" or "untrust" the Option 82 information in DHCP messages based on the port. On Cisco switches, the "ip dhcp relay information trust-all" command enables the switch to accept Option 82 information from any port, which is only appropriate for ports connected to other switches or relay agents. On access ports connected to end users, the switch should be configured to "ip dhcp relay information option-insert" which causes the switch to overwrite any Option 82 information inserted by the client and insert its own trusted information. This ensures that the DHCP server always sees the accurate physical location of the client, regardless of any Option 82 spoofing attempt by the attacker.
The deployment of Option 82 introduces operational considerations that the network engineer must carefully plan. The most significant consideration is the impact on DHCP server performance: when Option 82 is enabled, each DHCP message is 18–32 bytes larger than without Option 82 (depending on the sub-options included), which increases the bandwidth consumption and processing overhead on the DHCP server. For a network with 1,000 new DHCP leases per hour (typical for a large enterprise), the additional overhead is negligible. However, for a service provider network with 100,000+ concurrent DHCP clients and high lease churn rates (as residential customers connect and disconnect), the Option 82 overhead can add significant load to the DHCP server's CPU and memory. The DHCP server must also be configured to parse the Option 82 information and apply the appropriate scope selection policy, which adds processing overhead per lease request. Service providers deploying Option 82 at scale typically use hardware-accelerated DHCP appliances or load-balanced DHCP server clusters to manage the additional processing load.
Option 82 also introduces complexity in DHCP failover and high-availability deployments. In a typical DHCP failover configuration (using the "failover peer" mechanism in ISC DHCP or the "DHCP in Windows Failover Clustering" feature), both DHCP servers maintain synchronized lease databases so that if the primary server fails, the secondary server can continue to assign leases. When Option 82 is used, the DHCP failover mechanism must also synchronize the Option 82-based scope selection policies. If the secondary server does not have the same Option 82 policy configuration as the primary, it will assign IP addresses from the wrong subnet when it takes over—potentially causing routing failures for the affected clients. The solution is to replicate the complete DHCP server configuration, including the Option 82 class definitions and scope selection policies, to all DHCP servers in the failover group. This configuration replication must be verified during the DHCP failover testing that is part of every major network maintenance window.
The future of DHCP relay and Option 82 is being shaped by the transition to IPv6 and the corresponding DHCPv6 protocol. DHCPv6 (RFC 3315) uses a different message format than DHCPv4 and has a corresponding relay agent option, Option 37 (Interface-Id), which serves the same role as Option 82 in DHCPv4. However, DHCPv6 relay operates differently from DHCPv4 relay in several important respects. DHCPv6 clients do not use broadcasts; they use multicast (the All_DHCP_Relay_Agents_and_Servers multicast address FF02::1:2), which means that the relay agent must be configured to listen for this multicast traffic. The GIADDR field in DHCPv6 (called the "link-address" field in the Relay-Forward message) contains the IPv6 address of the relay agent's interface on the client's subnet. The DHCPv6 relay agent configuration on Cisco IOS is similar to DHCPv4: "ipv6 dhcp relay destination [server-IPv6-address]" on the client-facing interface. The deployment of DHCPv6 relay with Option 37 is expected to grow significantly as enterprise networks complete their IPv6 transition, and the troubleshooting and security considerations that have been developed for DHCPv4 Option 82 will be directly applicable to the IPv6 equivalent, ensuring that network engineers who have mastered DHCPv4 relay will be well-prepared for the DHCPv6 deployment challenges ahead.