DHCP Server, Relay, and Snooping

DHCP Server, Relay, and Snooping

Quick Answer: DHCP assigns IP, mask, gateway, DNS, and lease using DORA (Discover → Offer → Request → Ack). The server listens on UDP 67; the client uses UDP 68. Use a local DHCP server when clients and the server share a broadcast domain; use DHCP relay when they do not. DHCP snooping marks ports trusted/untrusted to stop rogue servers.

IP addressing by hand does not scale for campus user VLANs, guest Wi-Fi, or temporary labs. HCIA-Datacom expects you to explain how Dynamic Host Configuration Protocol (DHCP) delivers parameters, when a Huawei device must relay instead of answer locally, what belongs in an address pool, and how DHCP snooping protects the network from unauthorized servers. These topics appear both as pure concept items and as “why did the PC get no address?” troubleshooting scenarios.

Why DHCP matters on campus networks

Without DHCP, every host needs a static IP, mask, default gateway, and DNS—error-prone and slow. DHCP centralizes those parameters in a pool so clients configure themselves at boot or when their lease expires. On Huawei campus designs you commonly see:

Exam stems often hide a simple topology fact: DHCP Discover is a broadcast. Broadcasts do not cross routers. If the client VLAN and the DHCP server IP are in different Layer 3 domains, something must relay the request—or the client never receives an Offer.

Ports and message direction

Memorize the transport pair before any CLI:

Clients that do not yet have an IP address use 0.0.0.0 as the source and often 255.255.255.255 as the destination for Discover. After a lease is granted, renewals can be unicast to the server that owns the binding. ACL and firewall questions may filter UDP 67/68; blocking them breaks address assignment even when routing is perfect.

The DORA process

DHCP acquisition for a new client is taught as four steps:

1. Discover — Client broadcasts “I need an address.” Any listening DHCP server may respond.
2. Offer — Server proposes an IP (and typically other options) from a pool, often after checking that the address is free (for example via ICMP/ARP conflict detection on many platforms).
3. Request — Client broadcasts which offer it accepts (important when multiple servers replied).
4. Ack — Chosen server confirms the lease; client applies IP, mask, gateway, DNS, and lease timers.

Related messages you should recognize by name:

• Nak — Server refuses a Request (wrong network, expired, or policy deny); client restarts discovery.
• Decline — Client rejects an offered address it believes is already in use.
• Release — Client returns the address early (graceful shutdown).
• Inform — Client that already has an IP asks only for other options (less common on HCIA stems).

Exam trap: Confusing Offer with Ack. The client does not finish configuration after Offer alone; it must Request and receive Ack. Another trap is assuming DORA works unchanged across a router without a relay—Discover never reaches a remote server.

Address pools, gateway option, and lease

A DHCP address pool is the policy object that defines what clients receive. Conceptual fields on Huawei VRP and most platforms:

The gateway option is frequently tested because a client can receive a valid IP and still have “no Internet” if the gateway is wrong or missing. The lease balances address reuse (short lease for guest Wi-Fi) against control-plane load (longer lease for stable offices). Halfway through the lease, clients typically attempt renewal with the original server; if that fails, they rebind more broadly before the lease fully expires.

Conceptual VRP-oriented workflow (commands vary slightly by version; understand the objects):

1. Enable the DHCP service globally.
2. Create a pool tied to a subnet or interface network.
3. Configure gateway, DNS, and lease inside the pool.
4. Exclude the interface IP and other static hosts.
5. Bind the pool to the correct interface/VLANIF so offers match the client subnet.

If the server interface IP is not in the pool’s network, clients may get offers that do not match their broadcast domain—another classic misconfiguration.

DHCP server versus DHCP relay

Relay is sometimes called a helper in multi-vendor language. On the client-facing interface you point to the remote DHCP server address(es). The relay rewrites and forwards the request so the server sees a giaddr (gateway IP address) of the client subnet—critical so the server selects the correct pool for that network.

Design rule for the exam: Same broadcast domain → server (or any host server on that LAN) can answer. Different broadcast domains (routed VLANs, remote data center server) → relay required on the first-hop gateway for that client VLAN.

Multiple server IPs on a relay provide redundancy: if the primary DHCP server is down, a secondary may still answer. The client still completes a single DORA conversation with whichever server wins.

Option 82 (relay agent information)

DHCP Option 82 lets the relay agent insert information before forwarding the packet to the server. Sub-options commonly discussed at associate level:

• Circuit ID — Identifies the interface, VLAN, or port path the client is attached to.
• Remote ID — Identifies the relay device itself (hostname, MAC, or configured string).

Why it matters:

HCIA does not require deep Option 82 TLV encoding, but you must know that Option 82 is added by the relay, not by ordinary clients, and that servers must be configured to accept and interpret it when the feature is enabled end-to-end.

DHCP snooping: defending against rogue servers

A rogue DHCP server (malware, misconfigured PC, or unauthorized appliance) can hand out wrong gateways and redirect traffic (man-in-the-middle). DHCP snooping on access switches classifies ports:

Snooping builds a binding table of MAC, IP, VLAN, port, and lease data from legitimate exchanges. That table feeds related features (IP source guard, dynamic ARP inspection concepts) in broader security designs. For HCIA focus:

1. Enable snooping globally and per VLAN as required.
2. Trust only the path toward the authorized DHCP server or relay.
3. Leave access ports untrusted by default.
4. Verify bindings when a host “has IP but cannot pass traffic” after a security change.

Exam trap: Enabling snooping without marking the uplink trusted blacks out all DHCP Offers—every client fails to get an address even though the server is healthy. Another trap: trusting all ports “to make it work,” which defeats the protection.

Troubleshooting checklist (HCIA style)

Use display commands on VRP to inspect pool usage, relay statistics, and snooping bindings when labs allow—exam questions often describe the same symptoms in prose.

Practice goals before the next section

1. Sketch DORA and label UDP 67 versus 68 on each message.
2. Decide server versus relay for three topologies (same VLAN, remote server, dual servers).
3. List pool options required for full Internet access (IP, mask, gateway, DNS).
4. Mark trusted and untrusted ports on a two-tier access/aggregation diagram.

Master these behaviors here; the next section uses address translation (NAT) so private DHCP ranges can reach public networks without consuming a public IP per host.