skip to content

How does DHCP snooping on an access switch stop a rogue DHCPv4 server, and which messages does it drop on untrusted ports?

level: middleimportance: must knowfreq 38%

answer

  1. a vendor feature, not an RFC
  2. trusted and untrusted ports
  3. messages only servers send
  4. OFFER, ACK and NAK
  5. chaddr against source MAC

basics

~10 s

DHCP snooping, a switch vendor feature with no RFC, drops server messages (DHCPOFFER, DHCPACK, DHCPNAK) arriving on untrusted access ports, so only ports marked trusted, toward the real server or relay, can answer clients.

solid answer

~40 s

DHCP snooping is a vendor feature with no RFC. The switch inspects every DHCPv4 packet on the VLAN and classifies each port as trusted or untrusted. On an untrusted port, where hosts sit, it forwards client messages (`DHCPDISCOVER`, `DHCPREQUEST`, `DHCPDECLINE`, `DHCPRELEASE`, `DHCPINFORM`) but drops server messages (`DHCPOFFER`, `DHCPACK`, `DHCPNAK`), so a rogue server's offer dies at its own port. Ports toward the legitimate server or relay are trusted. Most implementations also check client messages: `chaddr` must equal the frame's source MAC, a `DHCPRELEASE` or `DHCPDECLINE` must come from the port its binding was learnt on, and client traffic is rate-limited. The ACKs it forwards build a binding table that other features read. The IETF's standardised counterparts are SAVI-DHCP's DHCP-Trust attribute (RFC 7513) and DHCPv6-Shield (RFC 7610).

code

pseudocode · 16 lines
pseudocode
on dhcpv4_packet(frame, msg, in_port):
    type = msg.option(53)
    if type in {DHCPOFFER, DHCPACK, DHCPNAK}:
        if not in_port.trusted:
            drop(); count(in_port); return
        if type == DHCPACK:
            p = port_of(msg.chaddr)
            bindings.add(msg.chaddr, msg.yiaddr, msg.option(51), vlan, p)
        forward(); return
    if not in_port.trusted:
        if over_rate_limit(in_port): drop(); return
        if msg.chaddr != frame.src_mac: drop(); return
        if type in {DHCPRELEASE, DHCPDECLINE}:
            if not bindings.on_port(msg.chaddr, in_port): drop(); return
            bindings.remove(msg.chaddr, in_port)
    forward()

go deeper

for a junior

Recall that snooping splits ports into trusted and untrusted, and that server messages such as DHCPOFFER and DHCPACK are dropped when they arrive on an untrusted port.

for a middle

Explain the per-message table, the checks on client messages such as chaddr against source MAC, and how forwarded DHCPACKs become the binding table.

for a senior

Describe what snooping cannot see — rogues behind trusted ports, hosts on an unmanaged switch, DHCPv6 — and which counters prove it is working.

for a principal

Judge the cost of relying on a vendor feature with no RFC: behaviour differs between implementations, so a mixed estate needs its own tested baseline.

## The gap snooping closes DHCPv4 has no server authentication: a client accepts whichever offer it chooses, and RFC 2131 section 7 warns that unauthorized DHCP servers "may be easily set up". Clients cannot fix that, so the switch does. **DHCP snooping** is a feature switch vendors built for this purpose; no RFC defines it, and its counters, limits and defaults differ between implementations. Its core rule is the same everywhere: a port may send server-to-client DHCP messages only if an operator has marked it **trusted**. ## Trusted and untrusted ports With snooping enabled on a VLAN, the switch intercepts DHCPv4 packets (UDP ports 67 and 68) and reads each message type from option 53: | Message (option 53 value) | Sent by | On an untrusted port | On a trusted port | |---|---|---|---| | `DHCPDISCOVER` (1) | client | forwarded, after client checks | forwarded | | `DHCPOFFER` (2) | server | **dropped** | forwarded | | `DHCPREQUEST` (3) | client | forwarded, after client checks | forwarded | | `DHCPDECLINE` (4) | client | forwarded if it matches a binding on that port | forwarded | | `DHCPACK` (5) | server | **dropped** | forwarded, and a binding is recorded | | `DHCPNAK` (6) | server | **dropped** | forwarded | | `DHCPRELEASE` (7) | client | forwarded if it matches a binding on that port | forwarded | | `DHCPINFORM` (8) | client | forwarded | forwarded | In typical implementations every port starts untrusted, which suits access ports where hosts — and any test server someone plugs in — sit. Trusted ports face the legitimate server, the relay agent, or the next switch toward them. A rogue on an access port may still hear client broadcasts (some implementations forward client messages only toward trusted ports), but its `DHCPOFFER` never leaves the port it arrived on, so clients only see offers from the trusted side. ## Checks on client messages Dropping server messages stops the rogue server. Most implementations also police what clients send on untrusted ports: - **`chaddr` against the frame's source MAC.** The client hardware address inside the DHCP message must equal the Ethernet source address, so one port cannot pose as many clients by forging only `chaddr`. - **Release and decline tied to the port.** RFC 2131 identifies a lease by client identifier or `chaddr` plus the address — all fields the sender writes. A `DHCPRELEASE` or `DHCPDECLINE` is honoured only from the port where the binding was learnt, so a neighbour cannot free a victim's lease. - **Rate limits.** A per-port ceiling on DHCP packets per second keeps one port from flooding the server or the switch's own processor. - **Relay agent information.** Many implementations insert Option 82 (RFC 3046) into client requests and drop client packets that arrive already carrying it. ## The binding table falls out of it Every `DHCPACK` the switch forwards toward an untrusted port tells it which MAC now holds which address, on which VLAN and port, and for how long. Snooping records that as a **binding table**. ARP inspection reads it to reject ARP packets whose sender does not match a binding; IP source guard reads it to drop packets from unbound source addresses. Both are vendor features with no RFC. ## What snooping does not cover 1. A rogue behind a **trusted** port — on the server segment, or on a misconnected uplink — passes untouched. 2. Hosts sharing an **unmanaged switch or hub** with the rogue below one access port receive its offers directly; the managed switch never sees that exchange. 3. **DHCPv6** needs its own filter; DHCPv6-Shield (RFC 7610, BCP 199) is the IETF's specification of it. 4. It belongs on **every switch in the layer 2 domain**. RFC 7610 notes, for its DHCPv6 equivalent, that a switch cascaded below another must allow server messages from its uplink and relies on the upstream switch to filter them. The IETF wrote the trust rule down for both protocol versions in **SAVI-DHCP** (RFC 7513): its **DHCP-Trust** attribute marks attachments permitted to send server-to-client messages, and such messages from any other attachment "MUST be discarded".

  • A host with a statically configured address sits on an untrusted port. Does DHCP snooping block it?
    Not by itself: snooping filters DHCP messages, and a static host sends none. The trouble starts when ARP inspection or IP source guard read the binding table, because the host never had a `DHCPACK` and so has no binding; its traffic is dropped unless an operator adds a static binding for it.
  • What should you watch on a switch running DHCP snooping, and why?
    The per-port count of server messages dropped on untrusted ports. A non-zero count names the access port where a rogue or misconfigured server sits. RFC 7610 makes the same point for DHCPv6: a drop SHOULD be logged as a security alert, and a per-port drop counter is useful.

Snooping works like an office building where any room's phone can call the front desk, but only the front-desk line is wired to the overhead speakers. Someone announcing from a meeting-room phone is simply not connected to the speakers, however official they sound.

saying these in an interview costs you the question

  • DHCP snooping authenticates the DHCP server with a shared key.
  • Snooping drops all DHCP traffic on untrusted ports, client requests included.
  • DHCP snooping is specified in RFC 2131 as part of DHCP.
  • With snooping on, a rogue anywhere in the VLAN is blocked, even behind a trusted port.
  • Snooping protects hosts that share an unmanaged switch with the rogue.