Dynamic Host Configuration Protocol (DHCP)

DHCP faces a fundamental networking constraint: broadcast traffic doesn't cross routers. A client's DHCP Discover, sent to 255.255.255.255, reaches every device on the local network segment but goes no further. Without intervention, this means every subnet would need its own DHCP server.

For a small office with three subnets, this might mean three DHCP servers. For an enterprise campus with hundreds of VLANs, it would mean hundreds of servers—an administrative nightmare. For a multi-site enterprise, the complexity becomes unmanageable.

DHCP relay agents solve this problem elegantly. A relay agent intercepts broadcast DHCP messages on the local subnet, encapsulates them in unicast packets, and forwards them to DHCP servers on remote subnets. The server's response follows the reverse path. From the client's perspective, DHCP works exactly as if the server were local.

This page examines relay agent operation in detail: the forwarding logic, addressing mechanics, Option 82 enrichment, enterprise deployment patterns, and troubleshooting techniques.

To understand why relay agents are necessary, we must understand the broadcast constraint that DHCP operates under.

Why DHCP Uses Broadcast:

DHCP clients have a bootstrap problem: they need to communicate with a server to get configuration, but they have no configuration until they communicate with the server. The solution is broadcast:

1. Layer 2 Broadcast: Client sends Ethernet frame to FF:FF:FF:FF:FF:FF
2. Layer 3 Broadcast: Client addresses IP packet to 255.255.255.255
3. Source Address: Client uses 0.0.0.0 (no address yet)

Every device on the local subnet receives the broadcast. DHCP servers process it; other devices ignore it.

The Router Barrier:

Routers, by design, do not forward broadcast traffic:

• Each broadcast domain (subnet) has its own broadcast address
• Forwarding broadcasts would flood the entire network
• Broadcasts are meant for local consumption only

Without Relay: One Server Per Subnet

Absent relay functionality, every routed subnet requires a local DHCP server. For a network with 50 VLANs:

• 50 DHCP servers or services
• 50 scope configurations
• 50 points of management
• 50 potential failure points

This doesn't scale. Enterprise networks need centralized DHCP with one or few servers managing all subnets. Relay agents make this possible.

A DHCP relay agent is a network device (typically a router or Layer 3 switch) that intercepts broadcast DHCP messages and unicasts them to configured DHCP servers. The relay agent acts as an intermediary, making the DHCP exchange appear local to both client and server.

Forward Path (Client → Server):

1. Receive Broadcast: Relay receives DHCP Discover/Request on local interface
2. Check giaddr: If giaddr is 0, this is a new message (not already relayed)
3. Set giaddr: Relay sets giaddr to its IP address on the receiving interface
4. Increment hops: Relay increments the hops field
5. Unicast Forward: Relay sends packet to configured DHCP server IP(s)

Key Insight: giaddr

The giaddr (Gateway IP Address) field is the critical information the server needs:

• Tells server which subnet the client is on
• Server uses giaddr to select the correct scope
• Server sends response back to relay at giaddr
• Relay knows which local interface to use for delivery

Return Path (Server → Client):

1. Server Processing: Server sees giaddr ≠ 0, so client is remote
2. Scope Selection: Server uses giaddr to identify client's subnet and select scope
3. Unicast Response: Server sends response to giaddr (the relay)
4. Relay Receives: Response arrives at relay's IP address, port 67
5. Client Delivery: Relay broadcasts (or unicasts) to client on local subnet

Broadcast vs Unicast Delivery:

How does the relay deliver to a client that doesn't have an IP?

• Broadcast: Most common—relay broadcasts on local subnet, client accepts based on xid
• Unicast to MAC: Some relays unicast directly to client's MAC from chaddr
• Depends on flags: If BROADCAST flag is set, relay must broadcast

When a DHCP server receives a relayed request, it must determine which address pool to use. The giaddr field is the key to this selection.

Scope Selection Algorithm:

1. Check giaddr: If giaddr is non-zero, client is remote
2. Match giaddr to scope: Find scope that contains giaddr in its subnet
3. Select address: Allocate from the matching scope
4. Apply scope options: Use scope-specific DNS, gateway, etc.

Example:

Server has three scopes configured:

Request arrives with giaddr = 192.168.2.1:

• Server matches 192.168.2.1 to Scope-2
• Allocates address from 192.168.2.100-200 range
• Gateway option returns 192.168.2.1

The Relay IS the Gateway:

Note that giaddr typically equals the default gateway for the client's subnet. This is by design—the router serving as relay agent is usually the same router serving as default gateway.

Multiple Relay Hops:

In some network designs, DHCP messages may traverse multiple relay agents:

Client → Relay1 (access layer) → Relay2 (distribution layer) → Server

Hop Counting:

• Each relay increments the hops field
• Servers may reject requests exceeding a hop threshold (default often 4)
• Prevents infinite loops if misconfigured
• giaddr remains unchanged after first relay (identifies originating subnet)

Secondary Relay Forwarding:

• If a relay receives a message with giaddr already set, it forwards without modification
• Original giaddr preserved so server identifies correct subnet
• Rarely needed but supported for complex topologies

Option 82 is a powerful extension that allows relay agents to insert additional information about the client's physical network location. This enables sophisticated policies based on where a client connects, not just who the client is.

Option 82 Structure:

Option 82 contains sub-options, with two being most common:

Example Circuit ID:

Option 82, Sub-option 1 (Circuit ID):
  Switch: access-sw-floor3
  Port: Gi0/15
  VLAN: 100

Example Remote ID:

Option 82, Sub-option 2 (Remote ID):
  MAC: 00:1A:2B:3C:4D:5E
  Name: access-sw-floor3.corp.example.com

Option 82 Processing:

At the Relay Agent (Insert):

1. Relay receives DHCP message from client
2. Relay adds Option 82 with local port/switch information
3. Relay forwards to server with Option 82 included

At the Server (Process):

1. Server receives message with Option 82
2. Server can use Option 82 for policy decisions:
   • Scope selection
   • Address reservation
   • Logging and auditing
3. Server includes Option 82 in response (for relay processing)

At the Relay Agent (Strip):

1. Relay receives server response
2. Relay may remove Option 82 before delivering to client
3. Client receives clean DHCP message

Note: The client never sees Option 82—it's a relay-to-server mechanism.

Relay agent configuration varies by platform, but the core requirements are consistent: interface selection and server destination.

Basic Relay Configuration:

Multiple Server Configuration:

For redundancy, configure relay to forward to multiple DHCP servers:

ip helper-address 192.168.10.5   ! Primary
ip helper-address 192.168.10.6   ! Secondary

Behavior:

• Relay forwards client requests to BOTH servers
• Both servers may respond with OFFER
• Client accepts one offer (typically first received)
• Non-selected server releases the offered address

Server Ordering: Most relay implementations forward to all configured servers simultaneously. The 'primary/secondary' distinction is conceptual—whichever responds first usually wins. For deterministic failover, use DHCP failover protocol between servers instead.

Enterprise networks require careful DHCP architecture design. The relay agent model enables centralized management while accommodating complex, hierarchical network topologies.

Common Enterprise Patterns:

DHCP relay issues can be subtle because problems may occur at the client, relay, network path, or server. Systematic troubleshooting requires understanding the complete flow.

Common Relay Problems:

Diagnostic Approach:

1. Verify Client → Relay: Capture on relay; confirm DISCOVER is received

   • Check relay interface is DHCP snooping trusted (if enabled)
   • Verify relay service is running

2. Verify Relay → Server: Capture on server (or path); confirm relayed request arrives

   • Check giaddr is set correctly
   • Verify UDP 67 reaches server

3. Verify Server Processing: Check server logs for scope selection

   • Does giaddr match a configured scope?
   • Are addresses available in the pool?

4. Verify Server → Relay: Capture on relay; confirm server response arrives

   • Server sends to giaddr
   • Check routing and firewalls on return path

5. Verify Relay → Client: Capture on client subnet; confirm OFFER/ACK delivered

   • Relay broadcasts or unicasts to client
   • Client accepts response (matching xid)

We've comprehensively examined DHCP relay agents—the mechanism that enables centralized DHCP across routed networks. Let's consolidate the key takeaways:

Module Complete:

You've now mastered DHCP comprehensively—from the dynamic addressing concepts through the DORA process, message structures, lease management, and relay agent operation. This knowledge prepares you to design, deploy, and troubleshoot DHCP infrastructure in networks of any scale.