Arista EOS DHCP Relay: ip helper-address Configuration Guide

DHCP uses Layer 2 broadcasts, so clients cannot reach a DHCP server that lives on a different subnet or VXLAN segment without a relay agent. Arista EOS turns any routed interface - including VLAN SVIs - into a DHCP relay with a single ip helper-address command, and it forwards the client broadcast to every configured helper in parallel. This guide shows how to configure the EOS DHCP relay on an SVI, how the global dhcp relay configuration mode simplifies multi-interface deployments, and how to verify that DHCP Discover packets are being relayed correctly.

DHCP Relay on EOS: When You Need It

DHCPv4 clients broadcast DISCOVER messages to 255.255.255.255. A router that routes between the client VLAN and the server VLAN must pick up the broadcast, insert its own address as the giaddr (gateway IP address), and unicast the request to the server so the server can allocate an address from the correct pool. Without the relay, hosts in a VLAN without a local DHCP server simply never get an address.

You need a relay in every one of these situations, and they are more common than people expect:

• Clients sit in a different subnet from the DHCP server (the ordinary case in a data-center design where the server is centralised).
• Clients sit behind a VXLAN segment and the server is reachable only through the routed underlay.
• Clients are in a VRf (VRF) whose DHCP server cannot be reached by broadcast at all.
• You want a single DHCP server to serve many VLANs, avoiding one server instance per subnet.

The relay is stateless: it does not allocate anything, it simply bridges the broadcast domain of the client to the unicast domain of the server and returns the reply. That is why the giaddr field matters so much - it is the only thing telling the server which pool to use when it has never seen the client's subnet.

How the Relay Forwards the Packet

It helps to see the four steps the relay performs for every transaction:

1. The client broadcasts DISCOVER. The relay receives it because the SVI is the default gateway for that VLAN.
2. The relay rewrites the packet: it sets giaddr to the SVI address, keeps the broadcast destination inside the DHCP payload so the server replies to the relay, and unicasts the frame to every configured helper.
3. The server allocates an address from the pool that matches giaddr and unicasts the OFFER back to the relay.
4. The relay broadcasts the OFFER onto the original client VLAN, where the client receives it.

Because the relay uses its own interface address as giaddr, the DHCP server must have a route back to that address. If the server cannot reach the SVI subnet, requests arrive and offers die on the return path - a failure that looks like "the relay is not working" but is really a missing return route on the server.

Configuring ip helper-address on an SVI

Add one helper per DHCP server. EOS relays the client broadcast to all configured helper addresses in parallel, which is a simple way to build DHCP server redundancy without anycast:

switch(config)# interface Vlan100
switch(config-if-Vl100)# description Client VLAN
switch(config-if-Vl100)# ip address 172.16.0.4/24
switch(config-if-Vl100)# ip helper-address 10.0.0.2
switch(config-if-Vl100)# ip helper-address 10.0.0.3

The helper address must be reachable through the routing table; the relay uses the interface's own unicast IP as the giaddr in the forwarded packet. When you list two helpers, both servers receive every DISCOVER, so the client takes whichever OFFER arrives first and the second server simply ages out the transaction. This is active/active redundancy at the DHCP layer and it requires no coordination between servers as long as their pools do not overlap.

One caveat on the same SVI: do not fabricate a helper address in a subnet that does not exist. EOS will happily accept the configuration, and show ip interface will show it, but no packet will ever egress because there is no route. Always confirm the next hop with show ip route <helper-address> before declaring the change complete.

Global DHCP Relay Configuration Mode

When many interfaces relay to the same server, EOS offers a global relay configuration that applies a default helper to every interface you list, with per-interface overrides where needed:

switch(config)# dhcp relay
switch(config-dhcp-relay)# default-gateway 10.0.0.5

Then a plain ip helper-address under an individual routing interface overrides the global default for that interface:

switch(config)# interface Ethernet1
switch(config-if-Et1)# ip helper-address 10.0.0.3

IPv6 DHCP relay is configured the same way with ipv6 helper-address, forwarding to the DHCPv6 server's multicast or unicast address. For DHCPv6 the relay typically forwards to the well-known All_DHCP_Relay_Agents_and_Servers multicast group (ff02::1:2) on the client-facing link and to the server's unicast or multicast address on the server-facing side.

The global mode is worth adopting on a campus or leaf-spine build where forty SVIs all point at the same pair of servers: you set the default once, and any SVI that needs a different server overrides it locally. Fewer lines means fewer chances for one VLAN to be accidentally left without a helper.

Relay in a VXLAN and EVPN Fabric

In a VXLAN-EVPN fabric, the DHCP relay is often the distributed anycast gateway address itself. Clients broadcast on the leaf, the local SVI relays to the server over the underlay, and the reply comes back to the leaf that holds the client's MAC. Two design points matter:

• Use a stable loopback as the source interface for relay traffic where the platform supports it, so the server sees a consistent giaddr even when the anycast gateway is shared across leaves.
• Confirm the relay traffic has a clean underlay path. If the server is reachable only through a specific VRF, the helper address must be resolved in that VRF's routing table, not the default table.

Verifying the DHCP Relay

switch# show ip interface Vlan100
switch# show dhcp relay statistics
switch# show dhcp server
switch# show ip route 10.0.0.2

Read show ip interface Vlan100 first: it confirms the SVI is up and lists the helper addresses EOS is actually using. show dhcp relay statistics then proves packets are moving - inbound DISCOVER counters should climb while a client is booting, and outbound relay counters should match. If the inbound counter rises but the client never gets an address, the problem is downstream of the relay: a return path, a firewall rule, or a server pool that does not cover the subnet the giaddr implies.

When DHCP snooping is active, show ip dhcp snooping shows the snooping state per VLAN and the Option-82 circuit and remote IDs the switch inserts; show ip dhcp snooping counters debug explains exactly why any snooped packet was dropped. Snooping and relay coexist happily as long as the port facing the DHCP server is trusted - an untrusted server port is the number one reason a working relay suddenly stops allocating addresses.

Troubleshooting Checklist

Walk the table top to bottom. The overwhelming majority of "DHCP is broken" tickets are one of two things: a helper address that has no route, or a snooping trust configuration that flipped when a port was re-cabled. Both are visible in two show commands.

Option 82 and Relay Agent Information

EOS can insert Option 82 (Relay Agent Information) into relayed packets so the server learns not just the subnet but the exact port the client is attached to. The switch fills in a circuit ID, usually derived from the VLAN and interface, plus an optional remote ID; the server can then apply per-port policy, hand out a specific address, or log which access port a lease was requested from.

switch(config)# ip dhcp relay information option
switch(config)# ip dhcp relay information option circuit-id format %p
switch(config)# ip dhcp relay information policy keep

Three policy choices exist for packets that already carry the option: keep preserves whatever a downstream device inserted, replace overwrites it with the local value, and drop discards the packet entirely - the right setting when untrusted access gear must not be allowed to forge relay information. Whichever you choose, the DHCP server has to be configured to echo the option back inside its replies, otherwise some client stacks silently discard the OFFER and the client appears to never get an address even though the relay and server both did their job.

Verifying with a Packet Capture

switch# monitor session 1 source interface Ethernet10 both
switch# monitor session 1 destination interface Ethernet48
switch# tcpdump -i et10 -n udp port 67 or udp port 68

A capture on the client-facing port should show the DISCOVER as a broadcast with giaddr 0.0.0.0. The same transaction captured on the uplink should show giaddr set to the SVI address and the destination rewritten to the DHCP server. Seeing giaddr still 0.0.0.0 on the uplink means the relay never engaged - look for a missing ip helper-address, a VLAN mismatch, or an SVI that is administratively down.

Design Notes and Best Practices

Keep a single documented helper pair per VLAN, and record it next to the subnet plan so a second engineer can reason about the design without reverse-engineering the running config. Prefer two helpers over one so a server maintenance window does not become a site outage. Treat the relay configuration as part of the routing design, not an afterthought: the giaddr carries your routing semantics, and any change to the SVI addressing must be reflected in the server pools. When a subnet is renumbered, update the DHCP scope and the SVI together, or clients will keep receiving addresses the relay cannot deliver.

Related Arista EOS Reading

See our Cisco ip helper-address DHCP relay guide for the IOS equivalent, the Arista EOS VLAN step-by-step configuration, and EOS VARP active-active gateway with MLAG. On the server side, the ISC DHCP server dhcpd.conf guide shows how to build the subnets and ranges the relay expects.

原文链接：https://www.arista.com/um-eos/eos-configuring-dhcp