When a Cisco access switch inserts DHCP Option 82 and a Cisco router relays the request with ip helper-address, a healthy DHCP exchange can stop at the router. The usual symptom is simple: clients behind the switch send DHCP requests, but the DHCP server never sees them after Option 82 is enabled.

That behavior is a safety control. A first-hop relay normally rejects a client-side DHCP packet that already contains relay information while the gateway address (giaddr) is zero. Otherwise an endpoint could inject Option 82 data and make the DHCP server treat untrusted metadata as an access-network signal.

The answer is not automatically ip dhcp relay information trust-all. Trust only the router interface that receives Option 82 from a known, controlled downstream switch.

Recognize the topology before changing policy

This article applies to a path like this:

client -> Catalyst access switch (inserts Option 82) -> Cisco relay router -> DHCP server

The access switch is not the Layer 3 relay. It adds Option 82 to a client broadcast, then the router receives that packet with giaddr still zero. The router sees pre-existing relay information on a client-facing path and drops it unless that path has been explicitly trusted.

This differs from a router that adds Option 82 itself, a multi-relay topology, or a DHCP server connected directly to the switch. Draw the real packet path before changing the router. “The switch uplink” is not precise enough when a stack, redundant paths, or an aggregation layer is involved.

Start with Configure DHCP Option 82 on Cisco Catalyst Switches Safely and What Is DHCP Option 82? Relay Agent Information Explained if you need the access-switch or protocol context.

Confirm that Option 82 is the failure

Do not change relay trust because a client has no lease. Establish the before and after evidence:

1. Confirm the client can obtain a lease when Option 82 insertion is disabled on the downstream switch.
2. Enable Option 82 only on a pilot VLAN and reproduce the failure with one test client.
3. Capture DHCP on the router-facing switch link or inspect relay and server logs. Confirm the request contains Option 82 when it reaches the router.
4. Confirm the router has the expected ip helper-address and can reach the DHCP server. A missing helper address or ACL problem is a different repair.
5. Identify the exact incoming router interface. That is the candidate trust boundary—not every interface on the router.

Cisco IOS XE documents this default behavior and distinguishes an interface-level trust setting from the global trust-all override.

Prefer per-interface trust

On the router interface that receives Option 82 only from the controlled access switch or aggregation device, use the narrow configuration:

configure terminal
interface GigabitEthernet0/0
 description Trusted downstream Catalyst Option 82 path
 ip dhcp relay information trusted
end

Replace the interface with the one that actually receives the request. Then verify the configured trust sources:

show ip dhcp relay information trusted-sources

The command says this interface is a trusted source of already-inserted relay information; it does not make every endpoint or routing interface trusted. Now renew the pilot client’s lease and verify that the server receives the expected Option 82 fields, the OFFER and ACK return to the client, and router logs show no relay-information drops.

If the router is also the DHCP server, Cisco documents the same interface trust requirement when a relay inserts Option 82 without setting giaddr. Check the server-side interface and address-pool policy separately; fixing transit does not prove the server’s Option 82 match is correct.

Why trust-all is rarely the first move

This global command exists:

configure terminal
ip dhcp relay information trust-all
end

It accepts pre-inserted relay information from every interface. Cisco documents it as useful when a known switch between clients and the relay inserts Option 82, but that is a topology description, not a reason to discard interface-level trust.

Use global trust only when every interface that can carry such requests is inside the same controlled boundary and you have documented why an interface-by-interface policy is impractical. In most enterprise networks there is no upside to trusting Option 82 from a guest segment, lab interface, or unknown downstream device.

If you inherited trust-all, treat it as an audit item. List the interfaces, identify which ones legitimately receive pre-inserted Option 82, then test a migration to explicit interface trust during a maintenance window.

Related relay settings need deliberate choices

Cisco IOS and IOS XE can expose controls for Option 82 insertion, reply validation, and reforwarding policy (drop, keep, or replace) on supporting releases. These are not cosmetic toggles. Do not change a reforwarding policy merely to make a failing packet move. The right choice depends on which relay owns the metadata, which downstream element is trusted, and what the DHCP server expects.

The Cisco IOS XE DHCP relay guide is a useful primary reference, but feature support still varies by hardware and release. Capture packets and read the guide for the exact platform before changing that behavior.

Rollback preserves the boundary

If the pilot fails after adding the interface command, collect the router configuration, trust-source output, a packet capture or DHCP logs, and the client’s lease state. Then remove only the pilot trust:

configure terminal
interface GigabitEthernet0/0
 no ip dhcp relay information trusted
end

That returns the interface to the default untrusted behavior. Do not leave trust-all behind as an emergency workaround. If service only returns after a global override, the topology or relay-policy design still needs investigation.

The operational rule

DHCP Option 82 is useful because it carries context supplied by a trusted network element. Preserve that premise at the relay. Trust the specific ingress allowed to supply the information, verify that the server handles it as expected, and expand one controlled path at a time.

That gives you a configuration you can explain during an incident: this interface is trusted because this managed switch inserts Option 82 here. It is a far better story than “we trusted everything because DHCP stopped working.”

For more DHCP design and troubleshooting context, read Demystifying DHCP: A Network Engineer’s Guide. For more networking and systems notes, visit Slaptijack.