Almost every production Lattice site uses relays. Clients broadcast Discover on their VLAN. A router, L3 switch, or firewall unicasts that packet to the DHCP server and sets giaddr to its own address on that VLAN. Lattice uses giaddr to pick the subnet.
If you ran Microsoft DHCP, you already did this. The command on Cisco is ip helper-address. The idea is identical. Two Lattice-specific traps: trusted relays, and Community dhcpd living in Docker (broadcast on the server VLAN often misses).
Windows/SSH: windows-admin. First subnet: first-subnet.
Vendor documentation (CLI and GUI names differ by OS version). Use these for the latest ip helper-address / DHCP-relay steps; this page is what Lattice does with giaddr and trusted relays.
| Platform | Official docs |
|---|---|
| Cisco IOS / IOS XE | DHCP relay agent |
| Cisco NX-OS | Search Cisco’s current NX-OS “DHCP relay” / ip dhcp relay address guide for your train |
| Microsoft RRAS | Search Microsoft Learn for “DHCP Relay Agent” on your Server version |
| Meraki MX | DHCP relay |
| FortiGate / Palo Alto / UniFi | That vendor’s current DHCP-relay administration guide |
Just show me the steps — helper + trusted relays + prove, at the bottom.
1. What you configure (network side)
On the default gateway of the client VLAN (not on Lattice, not on the PC):
| Platform | What to set |
|---|---|
| Cisco IOS / NX-OS | ip helper-address 10.0.0.11 (HA: the VIP, e.g. 10.0.0.10) under the SVI / interface |
| FortiGate / Palo Alto / many firewalls | DHCP relay / helper targeting that IPv4, UDP 67 |
| Windows Server RRAS | DHCP relay agent → same IPv4 |
| Meraki / UniFi / similar | “DHCP relay” / “DHCP server” field = Lattice, not the old Windows box |
Use one destination while you cut over. Two helpers (Windows DHCP and Lattice) on the same VLAN means two Offers and a mess. migrate.
HA: helpers point at the VIP, not at a node IP you might forget after failover. Extra site: helpers at that site point at a dhcp-only node, not the distant VIP. ha.
Health-check load balancers with HTTP /readyz, never “UDP 67 answered.” DHCP will answer on a dead database.
2. What giaddr is
The relay stamps giaddr = “I am the router for this client network.” Example: client VLAN 10.20.20.0/24, SVI 10.20.20.1 → giaddr 10.20.20.1.
Lattice looks up a subnet whose CIDR contains that address. If you created subnet 10.20.20.0/24, it matches. If you only created a pool object and no subnet, or the subnet is 10.20.20.0/25 and the SVI is .1 on the other half, you get silence (no Offer), not a NAK.
Work → Relays lists helpers Lattice saw but could not map. That is the first place to look when a VLAN gets nothing.
3. Trusted relays (Lattice Settings)
Microsoft DHCP accepts relays from anywhere it can receive a packet. Lattice does not.
More → Settings → Trusted relays
| List | Effect |
|---|---|
| Empty (default) | Relayed packets are dropped. Direct clients on the wire still served. |
| Relay IPv4s / CIDRs | UDP source or giaddr. HA keepalived IPVS NAT + Docker often rewrite the UDP source to a docker bridge; giaddr (the SVI) still matches. |
0.0.0.0/0 | Any relay (lab / “I know my firewall”) |
Add the relay’s address as Lattice sees it (often the SVI, sometimes a NAT in front of the helper). giaddr still selects the subnet; trusted relays match source or giaddr. If Work → Relays is non-zero, the helper is talking and Lattice is ignoring it — paste that source IP into Settings.
lattice-dhcptest on the VM uses a loopback source and still works with an empty list. That is deliberate so you can prove dhcpd without opening relays.
A stolen admin token must not punch host firewall holes. UFW is an SSH/installer job, not a console toggle. install-prerequisites §7.
4. Why a laptop next to Community Lattice gets nothing
Community dhcpd runs inside Docker, UDP 67. A Windows PC on the same VLAN sending a broadcast Discover often never enters the container. Hyper-V/VMware “same port group as the guest” does not fix that.
That is not a failed install. Prove with:
- A helper from another VLAN, or
- On the VM:
lattice-dhcptest -server 127.0.0.1:67 -giaddr <gateway-in-subnet>
Then ipconfig /renew from a relayed client.
Paid HA puts DHCP on a VIP via keepalived; relays still unicast. Same-VLAN broadcast to the VIP can work depending on the hypervisor — still prefer helpers. They are how every campus already works.
5. Option 82
Circuit-id / remote-id are stored on the lease (you can see them on the row). They do not pick the subnet in v1. Subnet selection is giaddr (or RFC 3527 link-selection if present). Do not design “option 82 policy routing” into Lattice yet.
Just the steps
Confirm helper syntax on your vendor’s page (Cisco: DHCP relay agent).
On the client VLAN gateway (one destination: Lattice VM or HA VIP, not the old Windows DHCP):
interface Vlan20
ip address 10.20.20.1 255.255.255.0
ip helper-address 10.0.0.11
In Lattice: subnet CIDR contains that SVI; pool exists; gateway is Don’t offer. More → Settings → Trusted relays: add the helper IP Lattice sees (often 10.20.20.1). Empty list drops relayed DHCP.
Prove on the VM (works with an empty trusted list):
lattice-dhcptest -server 127.0.0.1:67 -giaddr 10.20.20.1
Then ipconfig /renew from a relayed client. Health-check HTTP /readyz, never UDP 67.