In enterprise networks, DHCP servers are often centralized in a data center for security and manageability. But what happens when clients in remote VLANs need to obtain IP addresses from that server? DHCP relay is the solution, and it's a must-know topic for the CCNA 200-301 exam (objective 4.3). Mastering DHCP relay ensures you can connect clients across subnets without requiring a DHCP server in every VLAN—a common real-world scenario that saves time and resources.
Jump to a section
Imagine a large hotel where guests in different rooms (clients) want to order room service from a central kitchen (DHCP server). The kitchen is located on the ground floor, but guests are on floors 2 through 10. The hotel doesn't have a kitchen on every floor—that would be expensive and inefficient. Instead, each floor has a concierge desk (the router interface acting as DHCP relay). When a guest wants to order food, they call the concierge on their floor (broadcast DHCP Discover). The concierge knows the central kitchen's phone number (IP address of the DHCP server) and forwards the order to the kitchen, but with a twist: the concierge puts their own extension number (IP address of the router interface facing the guest) on the order so the kitchen knows which floor to deliver to. The kitchen prepares the food and calls back the concierge (unicast DHCP Offer), who then delivers it to the guest. This relay process ensures that guests on any floor can get room service without needing a kitchen on every floor. In networking, the router intercepts DHCP broadcast packets from clients, unicasts them to the DHCP server, and includes its own IP address (giaddr field) so the server knows which subnet to assign an IP from. The server replies to the router, which then broadcasts the reply on the client's VLAN. Without DHCP relay, clients in different VLANs couldn't get IP addresses from a centralized DHCP server—just as guests on upper floors couldn't order from a ground-floor kitchen without a relay mechanism.
What is DHCP Relay and Why Does It Exist?
DHCP (Dynamic Host Configuration Protocol) allows clients to automatically obtain IP addresses and other configuration parameters from a DHCP server. By default, DHCP relies on broadcast messages: clients send DHCP Discover messages as IP broadcasts (destination 255.255.255.255) and UDP broadcasts (port 67). Routers, by design, do not forward broadcasts across subnets. This means that if a DHCP server is not on the same subnet as the client, the client's request will never reach the server. In a modern enterprise network, it is impractical to place a DHCP server on every VLAN. Instead, we centralize DHCP servers and use DHCP relay agents (typically routers or Layer 3 switches) to forward DHCP messages between clients and servers.
DHCP relay is defined in RFC 1542 (and updated in RFC 2131). The relay agent listens for DHCP broadcast messages on its interfaces, modifies them by inserting its own IP address (the interface address on which the broadcast was received) into the giaddr (gateway IP address) field, and then unicasts the message to the configured DHCP server(s). The server uses the giaddr to determine which subnet the client belongs to and assigns an appropriate IP address. The server's response is unicast back to the relay agent, which then broadcasts it on the original subnet.
How DHCP Relay Works Step by Step
The DHCP relay process involves the following steps, using the classic DORA (Discover, Offer, Request, Acknowledge) exchange:
Client sends DHCP Discover (broadcast): The client, which has no IP address, sends a DHCP Discover message to IP broadcast 255.255.255.255, destination UDP port 67. The source IP is 0.0.0.0, source MAC is the client's MAC.
Relay agent receives the broadcast: The router (or Layer 3 switch) configured with the ip helper-address command on the interface facing the client receives the broadcast. The router does not drop it because it is configured to relay DHCP.
Relay agent modifies the packet: The router changes the destination IP address to the DHCP server's IP (unicast), sets the source IP to its own interface IP (the one that received the broadcast), and inserts the same interface IP into the giaddr field of the DHCP packet. The giaddr tells the server which subnet the client is on.
Relay agent forwards to server: The router sends the modified Discover message as a unicast to the DHCP server.
Server responds with DHCP Offer (unicast): The server sees the giaddr and selects an IP address from the corresponding subnet pool. It sends a DHCP Offer back to the relay agent's IP (the giaddr), unicast to the router.
Relay agent broadcasts the Offer: The router receives the Offer, changes the destination IP back to 255.255.255.255, sets the source IP to its own interface IP, and broadcasts it on the client's subnet. The client recognizes the Offer because it contains its own MAC address.
Client sends DHCP Request (broadcast): The client broadcasts a DHCP Request to accept the offer. The relay agent again intercepts, modifies, and unicasts to the server.
Server sends DHCP Ack (unicast): The server sends an Ack to the relay agent, which broadcasts it to the client.
The client now has an IP address. Note that the relay agent must be configured with the ip helper-address command on the interface that receives the client broadcasts. The helper address can point to one or more DHCP servers (multiple helper addresses can be configured).
Key States, Timers, and Defaults
The default DHCP client timer for retrying Discover is 4 seconds, doubling each time up to a maximum of 64 seconds (exponential backoff).
The ip helper-address command is configured per interface. It forwards not only DHCP but also other UDP broadcasts by default (TFTP, DNS, Time, NetBIOS, etc.). To limit which broadcasts are forwarded, use ip forward-protocol to disable specific UDP ports.
The relay agent does not need to be configured on the server side; the server simply sees a unicast packet with a giaddr.
The relay agent does not maintain state; it simply forwards messages.
Cisco routers support up to 255 helper addresses per interface.
The giaddr field is a 4-byte field in the DHCP packet. If multiple relay agents exist, only the first one writes the giaddr; subsequent relays should not overwrite it (but in practice, they may).
IOS CLI Verification Commands
To verify DHCP relay configuration and operation, use the following commands:
R1# show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.1.1.1/24
Broadcast address is 10.1.1.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is 192.168.1.10
...R1# debug ip dhcp server packetR1# show ip dhcp relay information trustedHow It Interacts with Related Protocols
DHCP relay interacts with DHCP snooping (a security feature on switches) and with IP routing. DHCP snooping can be configured to trust certain ports (e.g., ports facing DHCP servers) and to rate-limit DHCP messages to prevent rogue servers. DHCP relay is transparent to DHCP snooping; the relay agent's packets are treated as any other DHCP traffic. Also, the relay agent must have a route to the DHCP server, and the server must have a route back to the relay agent's interface IP (the giaddr). If the server is on a different subnet, routing must be in place.
Configuration Example
Consider a topology where a client is in VLAN 10 (10.1.10.0/24) and the DHCP server is at 192.168.1.10/24. The router has interface GigabitEthernet0/0 in VLAN 10 with IP 10.1.10.1, and interface GigabitEthernet0/1 connected to the server subnet 192.168.1.0/24 with IP 192.168.1.1. The configuration on the router:
interface GigabitEthernet0/0
ip address 10.1.10.1 255.255.255.0
ip helper-address 192.168.1.10
no shutdownThis configuration enables DHCP relay on interface G0/0. The router will forward DHCP broadcasts from VLAN 10 to the server at 192.168.1.10. The server will see the giaddr as 10.1.10.1 and assign an IP from the 10.1.10.0/24 pool.
Identify Client VLANs and Server Location
Before configuring DHCP relay, determine which VLANs have clients that need DHCP services and where the DHCP server is located. In a typical enterprise, the server is in a centralized data center VLAN. Note the subnet of each client VLAN and the server's IP address. Ensure the router or Layer 3 switch has an interface (SVI or routed port) in each client VLAN. The relay agent must have an IP address in the client's subnet to set the giaddr correctly. For example, if client VLAN 10 uses subnet 10.1.10.0/24, the router's interface in that VLAN should have an IP like 10.1.10.1.
Configure DHCP Pool on Server
Before clients can receive IPs, the DHCP server must have a scope/pool for each client subnet. For example, on a Cisco IOS DHCP server, create a pool for VLAN 10: `ip dhcp pool VLAN10` then `network 10.1.10.0 255.255.255.0` and `default-router 10.1.10.1`. The default-router should be the relay agent's IP. Without this, the server won't have an appropriate IP to offer. Note: The server does not need any special relay configuration; it just uses the giaddr to match the pool.
Configure ip helper-address on Client-Facing Interface
On the router that acts as the relay agent, enter the interface that faces the client VLAN (e.g., GigabitEthernet0/0 or VLAN interface 10) and issue the command `ip helper-address <DHCP-server-IP>`. For example: `interface GigabitEthernet0/0` then `ip helper-address 192.168.1.10`. This enables the router to forward DHCP broadcasts received on this interface to the specified server. Multiple helper addresses can be configured for redundancy. The command is per interface; you must repeat it for each client VLAN that needs relay.
Verify Reachability Between Relay Agent and Server
Ensure the relay agent can reach the DHCP server via IP routing. Use `ping` from the router to the server: `ping 192.168.1.10`. If the ping fails, check routing (static routes or dynamic routing protocol). The server must also be able to route back to the relay agent's interface IP (the giaddr). This return path is critical because the server unicasts the DHCP Offer to the relay agent's IP. If routing is broken, the relay never receives the server's response.
Test DHCP Client Operation
Connect a client to the client VLAN (e.g., plug a PC into a switch port in VLAN 10) and force a DHCP renew (e.g., `ipconfig /release` then `ipconfig /renew` on Windows). The client should obtain an IP from the server's pool. Use `show ip dhcp binding` on the server to see active leases. On the relay agent, use `debug ip dhcp server packet` to observe the relay process. Look for the giaddr being set correctly. If the client does not get an IP, verify that the client can send broadcasts and that the relay interface is up.
Troubleshoot with Show and Debug Commands
If DHCP fails, start with `show ip interface <interface>` to confirm the helper address is listed. Use `show ip route` to ensure the route to the server exists. On the relay agent, use `debug ip packet` (carefully, as it's CPU-intensive) to see if packets are being forwarded. On the server, use `debug ip dhcp server events` to see if the server receives the Discover and sends an Offer. Common issues: helper address on wrong interface, incorrect default-router in pool, or ACLs blocking UDP port 67/68. Also check that the client is not receiving a DHCP Offer from a rogue server.
In a typical campus network, a large organization might have dozens of VLANs spread across multiple buildings. Placing a DHCP server in each VLAN would be a management nightmare. Instead, network engineers centralize DHCP servers in the data center and configure DHCP relay on the Layer 3 switches or routers that serve as the default gateways for each VLAN. For example, a university might have separate VLANs for student dorms, faculty offices, and administrative buildings. The core switch in the data center has an SVI for each VLAN, and each SVI is configured with ip helper-address pointing to a pair of redundant DHCP servers. This setup allows all clients across the campus to obtain IP addresses from a single pool.
Another common scenario is a branch office that connects to a central DHCP server over a WAN link. The branch router acts as the relay agent. The DHCP server is located at headquarters, and the branch router forwards DHCP broadcasts from the local LAN to the server. This is efficient because the branch doesn't need its own DHCP server, reducing hardware and administrative overhead. However, if the WAN link goes down, clients in the branch cannot get new IP addresses (though existing leases may still work until they expire). To mitigate this, some organizations deploy a backup DHCP server locally or use DHCP local server on the branch router as a fallback.
Performance considerations: DHCP relay adds minimal latency because it only modifies a few fields in the packet and forwards it. The real bottleneck is the DHCP server itself, which must handle all requests. For large networks, multiple DHCP servers can be configured with helper addresses pointing to each server. The relay agent will forward to all configured servers, and the client will accept the first Offer. This provides redundancy but also increases server load. Misconfiguration can cause severe issues: if the helper address points to the wrong server, clients might get IPs from an incorrect subnet (e.g., a server that has no pool for the client's VLAN). If the giaddr is not set correctly (e.g., due to an ACL filtering the giaddr), the server may assign an IP from the wrong pool. Also, if the relay agent is not configured on the correct interface, clients will never receive a response. In production, always verify with show ip dhcp binding on the server that the assigned IPs match the expected subnet.
On the CCNA 200-301 exam, DHCP relay is tested under objective 4.3: "Configure and verify DHCP client and relay." The exam expects you to know how to configure ip helper-address on an interface, understand the role of the giaddr field, and troubleshoot common issues. You will not be asked to configure a DHCP server in detail, but you must know how to verify relay operation.
Common wrong answers and traps: 1. "The DHCP server must be on the same subnet as the client." This is false; the whole point of relay is to allow cross-subnet DHCP. Candidates often confuse relay with the traditional broadcast limitation. 2. "The relay agent changes the source MAC address to its own." While the relay agent does rewrite the source MAC to its own (since it forwards the packet), the key point is that it sets the giaddr field. The exam may ask what field the relay agent modifies. 3. "The `ip helper-address` command is configured on the interface facing the DHCP server." This is backward. The helper address is configured on the interface facing the clients. The command tells the router to forward broadcasts from that interface to the helper address. 4. "The relay agent forwards DHCP broadcasts as broadcasts to the server." No, it unicasts them. The server expects unicast messages from the relay agent.
Specific values and commands to memorize:
The command is ip helper-address <server-ip>.
The giaddr field contains the IP address of the relay agent's interface that received the client broadcast.
To verify helper address: show ip interface <interface>.
To see DHCP bindings on the server: show ip dhcp binding.
The default UDP ports forwarded by ip helper-address include DHCP (67/68), TFTP (69), DNS (53), Time (37), NetBIOS (137-138).
For scenario questions, use this decision rule: If a client cannot get an IP and the server is on a different subnet, suspect missing or incorrect ip helper-address on the client's default gateway. If the client gets an IP from the wrong subnet, suspect the giaddr is not being set correctly (maybe an ACL is stripping it, or the relay agent's interface IP is not in the client's subnet).
DHCP relay allows clients in one subnet to obtain IP addresses from a DHCP server in a different subnet by forwarding broadcast DHCP messages as unicast.
The relay agent is configured with the `ip helper-address <server-ip>` command on the interface facing the clients.
The relay agent sets the giaddr (gateway IP address) field in the DHCP packet to its own interface IP, allowing the server to select the correct subnet pool.
The server unicasts responses back to the relay agent, which then broadcasts them on the client's subnet.
Default forwarded UDP ports by `ip helper-address` include DHCP, TFTP, DNS, Time, and NetBIOS; use `ip forward-protocol` to control this.
Verify DHCP relay configuration with `show ip interface <interface>` and check for the helper address.
Common misconfiguration: placing the helper address on the interface facing the server instead of the client-facing interface.
These come up on the exam all the time. Here's how to tell them apart.
DHCP Relay
Forwards DHCP broadcasts across subnets to a centralized server.
Configured on routers/L3 switches using `ip helper-address`.
Modifies the giaddr field to indicate the client's subnet.
Operates at Layer 3 (IP routing).
Essential for centralized DHCP in multi-VLAN networks.
DHCP Snooping
Filters DHCP messages to prevent rogue DHCP servers.
Configured on switches using `ip dhcp snooping`.
Builds a DHCP snooping binding table for security.
Operates at Layer 2 (port-level filtering).
Used to enhance security in access layer switches.
Mistake
The DHCP relay agent must be configured on the same interface as the DHCP server.
Correct
The `ip helper-address` command is configured on the interface facing the clients, not the server. The relay agent forwards client broadcasts to the server.
Candidates often think the helper address is for the server's network, but it's actually for the client network.
Mistake
The relay agent forwards DHCP messages as broadcasts to the server.
Correct
The relay agent changes the destination IP to the server's unicast address and sends it as a unicast packet.
Because the original client message is a broadcast, many assume the relay agent keeps it as broadcast.
Mistake
The DHCP server uses the source IP of the relay agent to determine the client's subnet.
Correct
The server uses the giaddr field, which contains the relay agent's interface IP, not the source IP of the packet.
The source IP is the relay agent's IP, but the giaddr is the specific field designed for subnet identification.
Mistake
You need to configure the DHCP relay agent on both the client-facing and server-facing interfaces.
Correct
Only the client-facing interface needs the `ip helper-address` command. The server-facing interface needs no special DHCP relay configuration.
Candidates may think symmetry is required, but the relay only intercepts broadcasts from clients.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can configure multiple `ip helper-address` commands on the same interface. The router will forward the client's DHCP Discover to all configured servers. The client will accept the first Offer it receives. This provides redundancy and load sharing. However, be aware that this increases network traffic and server load. Each server will respond, but only one Offer is accepted by the client.
Yes, DHCPv6 also uses relay agents. For DHCPv6, the command is `ipv6 dhcp relay destination <server-ipv6-address>`. The relay agent sets the link-address field (similar to giaddr in DHCPv4). DHCPv6 uses multicast instead of broadcast, but the relay concept is similar. CCNA 200-301 focuses on DHCPv4, but you should know that DHCPv6 relay exists.
`ip helper-address` is the Cisco IOS command to configure DHCP relay for IPv4. It is a general-purpose UDP broadcast forwarder. There is no separate `ip dhcp relay` command in classic IOS; however, some platforms use `ip dhcp relay` for DHCP-specific relay with additional options. In the CCNA context, stick with `ip helper-address`. For DHCPv6, use `ipv6 dhcp relay destination`.
After the relay agent forwards the Discover to the server, the server unicasts the Offer back to the relay agent's IP address (the giaddr). If the server does not have a route to that subnet, the Offer will be dropped. This is a common misconfiguration: the relay agent can reach the server, but the server cannot reach the relay agent. Ensure routing is bidirectional.
No, a pure Layer 2 switch cannot act as a DHCP relay agent because it does not have IP routing capabilities. A Layer 3 switch (with IP routing enabled) or a router is required. The relay agent must be able to process IP packets and modify the giaddr field. However, some advanced switches with DHCP relay features exist, but they are essentially operating as Layer 3 devices.
The relay agent should not overwrite an existing giaddr if it is non-zero. RFC 2131 states that a relay agent should only set the giaddr if it is zero. If a packet already has a giaddr, it means it has already been relayed. However, in practice, some relay agents may still overwrite it. This can cause issues if multiple relays exist. Cisco routers typically set the giaddr only if it is zero.
You can use a packet generator or simulate a client with tools like `dhcping` or by manually crafting a DHCP Discover using Python. On the router, you can use `debug ip dhcp server packet` to see incoming requests. On the server, use `debug ip dhcp server events`. Also, you can use `show ip dhcp binding` to see if any leases are assigned. A simple test is to plug in a laptop and run `ipconfig /renew`.
You've just covered Lab: Configure DHCP Relay — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?