In DHCP snooping, which port do you trust, and does a wrong choice free a rogue or starve the rack?
answer
- trust is a direction, not a device
- only one path may answer
- untrusted ports may ask, never answer
- the table is built from what passes trusted
- wrong trust frees a rogue or starves a rack
basics
~20 sTrust is a direction, not a device: the switch accepts DHCP server replies only from trusted ports, normally the link toward the real server. Mark the wrong port and either a rogue keeps offering leases or the segment gets none.
solid answer
~50 sTrust is a property of the direction, not of the device on the end of the cable. DHCP snooping gives every port one of two roles: on an untrusted port the switch forwards client requests but discards server-sourced messages such as offers and acknowledgements, and it records what the real server hands out into a binding table keyed by MAC, IP, VLAN and port. Trusted ports are exempt from both the filtering and, normally, from the neighbour-claim validation that later reads that table. So trust belongs only on the path toward the real server and to peer switches. Both mistakes hurt: trust an access port and a host on it can offer leases and answer for the gateway unchallenged while the control reports clean; leave the server path untrusted and you drop the genuine offers, so nothing renews and the rack loses off-subnet reachability as leases expire.
go deeper
Be ready to say which way trust points and what the switch does with a DHCP server reply that arrives on an untrusted port.
Explain what a binding records and how the trusted/untrusted split fills the table, including why a client request from an untrusted port is still forwarded.
Show both failure directions in a real rack: a trusted access port voids the control silently, an untrusted server path starves the segment at the next renewal.
Own the decision to exempt an aggregating uplink. Name who accepts that everything behind it is unvalidated, and what you demand in exchange for that signature.
## What "trusted" actually means DHCP snooping is a switch function that watches DHCP exchanges crossing the switch and writes down what it learns. Every port carries one of two roles. - **Untrusted**: the switch forwards client-sourced messages (a host asking for an address) but discards server-sourced messages — offers and acknowledgements. A host plugged into an untrusted port can ask for a lease, and it can never answer someone else's request. - **Trusted**: everything passes, and what the switch observes there is treated as authoritative. Trust is therefore a claim about a *direction in the topology* — "the real DHCP server is that way", or "that link goes to another switch that is already doing this job". It is not a claim that the device on the far end is well behaved, and reading it that way is the classic first mistake. ## What the switch builds from it As the real server hands out addresses, the switch records a **binding**: client MAC, assigned IP, VLAN, ingress interface, and the remaining lease. Those bindings are the only ground truth the switch has about which address legitimately lives behind which port, and two controls read them: - **Dynamic ARP inspection** examines ARP frames on untrusted ports and discards any whose sender MAC/IP pair has no matching binding. - **IP source guard** filters forwarded IP traffic whose source address does not match a binding on that port. Both are designed to skip trusted ports. That is the detail that makes trust placement a security decision rather than a plumbing one: a trusted port is exempt from the checks as well as from the filtering. ## The adversary this is aimed at One host on the segment, with nothing more than a live port, doing either of two things: answering ARP for the default gateway's address so traffic leaving the subnet passes through it first, or offering leases that name itself as gateway and resolver. Snooping plus binding-table validation is the counter — untrusted ports may ask, never answer, and may only use the address they were actually given. ## The two symmetric mistakes | Mistake | Who pays | What you see | | --- | --- | --- | | An access port marked trusted | everyone on that segment | rogue offers and gateway claims pass unchallenged, and the control's counters stay clean because nothing was ever evaluated | | The path to the real server left untrusted | the whole rack | genuine offers dropped, no host renews, and off-subnet reachability dies gradually as leases expire rather than all at once | The second failure is the reason first-hop deployments get rolled back. It is not loud at the moment of the change; it appears at the first renewal, which for most clients is halfway through the lease, so the change looks successful for hours before the rack begins to fall off. ## Where it gets hard in a data-centre fabric Two populations complicate the tidy picture. A **top-of-rack uplink carrying a hypervisor link** aggregates many guests behind one physical port. Trusting it is tempting because it makes the deployment stop breaking things, but it exempts every guest behind that link from validation: a compromised guest can then claim the gateway for the whole segment, which is precisely the attack the deployment exists to stop. The honest shape is to trust only the path to the server, keep the guest-bearing link untrusted, and accept that each guest must either lease through the switch or carry a binding. **Statically addressed appliances** — storage controllers, out-of-band management interfaces — never ask for a lease, so no binding is ever learned for them. They are not solved by trust placement at all; they need static bindings entered by hand, or they will be dropped the moment validation stops logging and starts discarding. ## What a good answer contains Say that trust points toward the server; that untrusted means "may request, may not answer"; that the table built from those exchanges is what later validation compares against; and that both directions of error are real — a wrongly trusted access port silently voids the control, while a wrongly untrusted server path starves the segment. Naming the aggregating uplink as the place the temptation to over-trust actually appears is what separates a memorised answer from an operational one.
- Your top-of-rack uplink carries one hypervisor link with hundreds of guests behind it. Do you trust that port?Only if the DHCP server is genuinely reachable that way, and only knowing the cost: a trusted port is exempt from the binding checks, so any guest behind that link can offer leases or answer for the gateway and nothing on the switch will contest it. The safer shape is to trust only the path to the server, keep the guest-bearing link untrusted, and require every guest to lease through the switch or carry a binding.
- Does a host on an untrusted port still get an address?Yes. Untrusted only means server-sourced messages arriving there are discarded. The client's request is forwarded normally, the reply comes back from the trusted side, and a binding is installed. The host notices nothing. What it can no longer do is answer for somebody else, because its own offers never leave the port.
- Why is the binding table, not the trusted-port list, what actually stops a gateway claim?The port roles only decide who may hand out addresses. The claim is stopped by validation that reads the binding table: an ARP frame or IP packet from an untrusted port whose sender pair matches no binding is discarded. With an empty table there is nothing to compare against, so port classification on its own prevents very little.
Trust here is like a mailroom door: anyone may post a request, but only the slot wired to the real post office is allowed to deliver an answer.
saying these in an interview costs you the question
- Says trusted means the connected device is trustworthy
- Marks uplinks trusted so the rollout stops breaking things
- Thinks an untrusted port cannot obtain a lease at all
- Assumes validation still applies to traffic on a trusted port
- Believes port roles alone block a gateway claim