skip to content

When a DHCP snooping switch inserts Option 82 but leaves giaddr at zero, why can the upstream relay agent discard the client's request?

level: seniorimportance: nice to knowfreq 9%

answer

  1. a layer 2 switch is not the relay
  2. trusted and untrusted circuits
  3. RFC 3046 section 2.1
  4. a client may not bring its own
  5. echoed, then stripped

basics

~20 s

RFC 3046 tells a relay agent to discard a packet from an untrusted circuit that has giaddr zero but already carries Option 82. A snooping switch that inserts Option 82 without setting giaddr produces exactly that, so the relay must trust that circuit.

solid answer

~50 s

Many DHCP snooping implementations insert the relay agent information option, Option 82 from RFC 3046, with an Agent Circuit ID and Agent Remote ID describing the access port and switch. The switch is a layer 2 device, not the router for the client subnet, so it leaves `giaddr` at zero. To the relay agent upstream, that packet looks like a client that wrote its own Option 82, and RFC 3046 section 2.1 says a relay receiving such a packet on an untrusted circuit "SHALL discard the packet and increment an error count". Clients get no offer and the only clue is that counter. The fix is to mark the circuit as trusted on the relay, which RFC 3046 allows when a trusted downstream bridge adds the option, or to stop inserting it. The server echoes Option 82, and whoever added it MUST strip it before the reply reaches the client.

go deeper

for a junior

Recall that Option 82 lets the network tell the DHCP server which port and switch a request came from, and that clients are not meant to set it.

for a middle

Explain giaddr's role, why a layer 2 switch leaves it at zero, and the RFC 3046 rule that discards such packets on untrusted circuits.

for a senior

Diagnose the silent failure from the relay's error counter, choose between trusting the circuit and disabling insertion, and know what each fix gives up.

for a principal

Decide where per-port identity should be trusted in the estate — switch, relay or server — and make that boundary explicit so new switches do not break it.

## Why a snooping switch adds Option 82 Many **DHCP snooping** implementations (a vendor feature with no RFC) can insert the **relay agent information option** — Option 82, defined in RFC 3046 — into client requests before passing them upstream. It carries sub-options set by the network, not by the host: - sub-option 1, **Agent Circuit ID**, typically identifying the access port and VLAN; - sub-option 2, **Agent Remote ID**, typically identifying the switch. A server that understands the option can tie a lease to a physical port, which is useful for per-port address policy, per-port lease caps against starvation, and finding where a host is plugged in. RFC 3046's security considerations list "IP spoofing, Client ID spoofing, MAC address spoofing, and DHCP server address exhaustion" among the attacks the option helps address. A snooping switch is a layer 2 device on the client's VLAN, not the router for that subnet. So it adds Option 82 but leaves `giaddr` — the address a relay agent fills in so the server can tell which subnet the client is on — at zero. The router further up, acting as the real relay agent, is expected to set `giaddr` as usual. ## The RFC 3046 rule that discards it RFC 3046 section 2.1 anticipates this topology and draws a line between **trusted** and **untrusted** circuits: | What the relay agent receives | What RFC 3046 requires | |---|---| | Untrusted circuit, `giaddr` zero, Option 82 already present | SHALL discard the packet and increment an error count | | Trusted circuit, `giaddr` zero, Option 82 added by a downstream bridge | Does not add a second Option 82; forwards it and sets `giaddr` as it deems appropriate | | `giaddr` non-zero and equal to one of this agent's own addresses (agent configured to add Option 82) | SHALL discard, as a spoofed `giaddr` | | `giaddr` non-zero and valid | Forwards it without adding Option 82 and without changing `giaddr` | The reasoning: a packet arriving with `giaddr` zero claims to come straight from a client, and a client has no business supplying circuit and remote IDs. A host that could write its own Option 82 could claim another subscriber's port and the policy attached to it. Unless the operator has told the relay that the circuit holds a trusted bridge, the relay must assume the option was forged. How a circuit is marked trusted is, in RFC 3046's words, "specific to the type of circuit termination equipment, and may involve local administration". So where access switches insert Option 82 and a router relays to a central server, a relay that still treats that interface as untrusted discards every `DHCPDISCOVER` arriving on it. Clients get no offer, nothing reaches the server's logs, and the only clue is an error counter on the relay. ## The server and the reply path - A server that supports the option SHALL echo the entire Option 82 in its replies, and SHOULD place it last. - A server unaware of it ignores it and does not echo it — the specified behaviour for any unknown option. - The echoed option MUST be removed by whichever element added it — the relay agent or the trusted downstream bridge — before the reply reaches the client. - When the server sits on the client's own VLAN with no relay in between, it receives `giaddr` zero plus Option 82 directly. RFC 3046 does not tell a server to discard that, but some server implementations refuse it, so the same symptom can appear with no relay involved. ## Fixes and what each costs 1. **Trust the circuit on the relay.** The relay accepts the switch-added option and the server gets per-port information. The cost: any device on that circuit able to inject Option 82 is now believed, so the access switches must drop client packets that arrive already carrying it. 2. **Stop inserting Option 82 on the switch.** Port filtering and the binding table keep working; the server loses per-port policy and per-port lease caps. 3. **Let an on-link server accept it.** That is a setting in the server implementation, not an RFC rule, and it moves the trust decision to the server. Whichever you choose, write it down beside the snooping configuration: the failure is silent, and the next engineer to enable insertion on a new switch will meet it again.

  • Why should a snooping switch drop client packets on untrusted ports that already carry Option 82?
    The server treats Option 82 as identity supplied by the network. A host that writes its own could copy another port's Agent Circuit ID to claim that port's reserved address or policy, or vary the Agent Remote ID to slip past per-port lease caps. RFC 3046 assumes the remote ID comes from the access network, "not by client premise equipment", so a client-supplied one must not survive.
  • Who removes Option 82 from the server's reply, and why does RFC 3046 insist on it?
    The element that added it — the relay agent, or the trusted downstream bridge such as a snooping switch — MUST strip it before forwarding the reply to the client. The option describes the operator's network, not the client. RFC 3046 also notes that any future client-server authentication must leave the option out of its calculations, which is why it is a single option the network adds and removes.

saying these in an interview costs you the question

  • A snooping switch should put its management address in giaddr when it adds Option 82.
  • A relay agent always adds its own Option 82, even when one is already present.
  • Option 82 is one of the options defined in RFC 2132.
  • Hosts on access ports should be allowed to supply their own Option 82.
  • The DHCP server strips Option 82 before it sends the reply.