How DHCP Works – Dynamic Host Configuration Protocol

1. What Is DHCP?

DHCP (Dynamic Host Configuration Protocol) is an application-layer protocol defined in RFC 2131 that automatically assigns IP addresses and network configuration parameters to devices the moment they connect to a network. Without DHCP, every device would require manual IP configuration — a practical impossibility at scale.

DHCP operates on a client-server model over UDP — the server listens on port 67, the client sends from port 68. The server maintains a pool of available IP addresses and leases them to clients for a configurable period of time.

A single DHCP exchange delivers everything a client needs to communicate on the network:

Parameter	DHCP Option	Purpose	Example
IP Address	yiaddr field	Unique Layer 3 identity on the network	192.168.1.15
Subnet Mask	Option 1	Defines local vs. remote destinations	255.255.255.0
Default Gateway	Option 3	Router IP for off-subnet traffic	192.168.1.1
DNS Server(s)	Option 6	Name resolution for hostnames	8.8.8.8, 8.8.4.4
Lease Time	Option 51	How long the IP assignment is valid	86400 seconds (1 day)
Domain Name	Option 15	DNS search domain for short hostnames	company.local
NTP Server	Option 42	Time synchronisation server	10.0.0.123
TFTP Server / Boot file	Option 66/67	PXE boot server for diskless devices	10.0.0.69 / pxelinux.0

2. The DORA Process — Four Messages, One IP Address

Every DHCP IP lease begins with a four-message exchange known as DORA: Discover → Offer → Request → Acknowledge.

  Client                                             DHCP Server
    │                                                     │
    │──── DHCP DISCOVER (broadcast) ────────────────────▶│
    │     Src: 0.0.0.0:68   Dst: 255.255.255.255:67      │
    │     "I need an IP address — is anyone out there?"  │
    │                                                     │
    │◀─── DHCP OFFER (broadcast or unicast) ─────────────│
    │     "I can offer you 192.168.1.15/24               │
    │      Gateway: 192.168.1.1  DNS: 8.8.8.8            │
    │      Lease: 86400 seconds"                         │
    │                                                     │
    │──── DHCP REQUEST (broadcast) ─────────────────────▶│
    │     Src: 0.0.0.0:68   Dst: 255.255.255.255:67      │
    │     "I accept 192.168.1.15 from server 192.168.1.1 │
    │      (broadcast so ALL servers know I chose this)" │
    │                                                     │
    │◀─── DHCP ACK (broadcast or unicast) ───────────────│
    │     "Confirmed — 192.168.1.15 is yours             │
    │      Lease expires in 86400 seconds"               │
    │                                                     │
  Client configures:
  IP: 192.168.1.15/24  GW: 192.168.1.1  DNS: 8.8.8.8

3. DHCP Discover — Message 1

The DHCP Discover is the first message sent by a client that has no IP address. It is broadcast to the entire local network segment to locate any available DHCP server.

Field	Value	Why
Source IP	`0.0.0.0`	Client has no IP yet — cannot use any real address
Destination IP	`255.255.255.255`	Broadcast — sent to all devices on the local segment
Source Port	`68` (DHCP client)	DHCP client always uses UDP port 68
Destination Port	`67` (DHCP server)	DHCP servers listen on UDP port 67
Client MAC (chaddr)	Client's hardware address	Server uses this to identify the client and track the offer
Transaction ID (xid)	Random 32-bit number	Matches the DORA messages together — the Offer/Request/Ack all echo this same ID

Why broadcast? The client has no IP address and no knowledge of any DHCP server's address. Sending a broadcast ensures every device on the local segment receives the request. This also means DHCP Discovers are stopped by routers — they do not cross subnet boundaries unless a relay agent is configured (see Section 8).

4. DHCP Offer — Message 2

Any DHCP server that receives the Discover and has an available IP address responds with a DHCP Offer. The Offer proposes an IP address and all associated configuration parameters — but the client has not yet accepted.

Field	Value	Why
Source IP	DHCP server's IP (e.g., `192.168.1.1`)	Server identifies itself so the client can choose which Offer to accept
Destination IP	`255.255.255.255` (or client MAC via unicast)	Broadcast because client still has no IP; some servers unicast to client MAC
yiaddr ("your IP")	Proposed IP for the client (e.g., `192.168.1.15`)	The IP being offered — temporarily reserved by the server
Options	Subnet mask, gateway, DNS, lease time, server ID	Complete network configuration package
Transaction ID (xid)	Same value from the Discover	Client matches the Offer to its original Discover request

Multiple DHCP servers: If multiple DHCP servers exist on the segment, all of them may respond with separate Offers. Each Offer proposes a different IP address and the client will receive all of them. The client typically selects the first Offer received and ignores the rest — which is why the DHCP Request that follows is sent as a broadcast (to inform all servers which one was chosen).

5. DHCP Request — Message 3

The client sends a DHCP Request to formally accept one of the Offers received. This message is still sent as a broadcast — even though the client now knows the server's IP — because there may be multiple DHCP servers on the network, and all of them need to know which one was chosen so the others can release their temporarily reserved IPs.

Field	Value	Why
Source IP	`0.0.0.0`	Still no confirmed IP — the lease is not final until the ACK
Destination IP	`255.255.255.255`	Broadcast — all DHCP servers see this; unchosen servers release their reserved IPs
Requested IP (Option 50)	The IP from the accepted Offer (e.g., `192.168.1.15`)	Specifies which IP the client is formally requesting
Server Identifier (Option 54)	IP of the chosen DHCP server (e.g., `192.168.1.1`)	Tells all servers which one was selected — unchosen servers see this and release their offers

DHCP Request is also used for lease renewal — not just initial IP requests. When a client renews its lease at T1, it sends a DHCP Request unicast directly to the original server. The format is the same message type, but the behaviour differs (see Section 7).

6. DHCP Acknowledge (ACK) and NAK — Message 4

The selected DHCP server finalises the lease by sending a DHCP ACK. The client receives this, applies the configuration, and begins using the IP address. If the server cannot honour the request, it sends a DHCP NAK instead.

DHCP ACK

Confirms the IP address lease is granted.
Contains the full configuration: IP, mask, gateway, DNS, lease time, and all options.
After receiving the ACK, the client performs an ARP probe (optional but common) to verify no other device already uses the offered IP — a precaution against duplicate IPs if the server's conflict detection failed.
If ARP probe detects a conflict, the client sends a DHCP Decline back to the server and the server marks that IP as conflicted.

DHCP NAK (Negative Acknowledgement)

A DHCP NAK is sent by the server when it cannot or will not honour the Request:

The requested IP address is no longer available (already assigned to another client).
The client has moved to a different subnet and its previously held IP is no longer valid for the current network.
The lease has expired and the server no longer recognises the client's binding.

Client response to NAK: Upon receiving a DHCP NAK, the client must discard any IP configuration it was using and restart the entire DORA process from DHCP Discover. The client cannot negotiate — NAK is final.

DHCP Decline

If the client receives a DHCP ACK but its ARP probe detects the offered IP is already in use, it sends a DHCP Decline to the server. The server marks that IP as conflicted and withholds it from future assignments until an administrator clears the conflict. The client then restarts DORA.

7. DHCP Lease Renewal — T1, T2, and Expiry

DHCP leases are temporary. Clients must renew their leases before they expire to maintain uninterrupted network connectivity. The renewal process uses three timers:

Timer	When	Action	Unicast or Broadcast
T1 (Renewal)	50% of lease duration	Client sends DHCP Request unicast directly to original server to renew	Unicast to original server
T2 (Rebinding)	87.5% of lease duration	If T1 failed (no ACK from original server), client broadcasts DHCP Request to find any available DHCP server to rebind the lease	Broadcast to 255.255.255.255
Expiry	100% of lease duration	Lease expired. Client immediately stops using the IP, clears configuration, and restarts the full DORA process from scratch	DORA restart (Broadcast)

Lease Renewal Timeline

  Lease: 86400 seconds (24 hours)

  │ 0s               43200s            75600s           86400s │
  │  ├──────────────────┼────────────────┼────────────────────┤ │
  │  Lease Start        T1 (50%)        T2 (87.5%)    Expiry   │
  │  IP Assigned        Unicast         Broadcast              │
  │                     Request to      Request to any         │
  │                     original        available server       │
  │                     server          (rebinding)            │

  Typical T1 for a 24-hour lease = 12 hours
  Typical T2 for a 24-hour lease = 21 hours

Why T1 is unicast: At T1, the client knows the original server's IP (from Option 54 in the original ACK). Unicasting directly is more efficient — no need to broadcast to the entire subnet. At T2, the original server hasn't responded (possibly down), so the client broadcasts to find any available DHCP server.

8. DHCP Relay Agent — Crossing Subnet Boundaries

DHCP broadcasts (Discover and Request) are stopped by routers — they do not cross Layer 3 boundaries. In networks where the DHCP server is on a different subnet from the clients, a DHCP Relay Agent is needed on the router or Layer 3 switch interface connecting to the client subnet.

  Client Subnet                   Router (Relay)         DHCP Server
  192.168.10.0/24                 GigabitEthernet0/0     10.0.0.5
        │                               │                     │
        │─── DHCP DISCOVER (broadcast)─▶│                     │
        │    Src: 0.0.0.0:68            │                     │
        │    Dst: 255.255.255.255:67    │── Unicast DISCOVER──▶│
        │                               │   Src: 192.168.10.1  │
        │                               │   Dst: 10.0.0.5:67   │
        │                               │   giaddr: 192.168.10.1│
        │                               │                     │
        │                               │◀── DHCP OFFER ───────│
        │◀── DHCP OFFER ────────────────│                     │
        │    Offer from 10.0.0.5        │                     │
        │    for 192.168.10.x subnet    │                     │

  Key: giaddr (Gateway IP) = relay agent's interface IP on the client subnet
       The server uses giaddr to select the correct pool (192.168.10.0/24)

Configuring DHCP Relay (ip helper-address)

! On the router interface or Layer 3 switch SVI facing the client subnet:
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip helper-address 10.0.0.5    ! DHCP server's IP

ip helper-address is more than just DHCP. By default, it also forwards several other UDP broadcast protocols: TFTP (69), DNS (53), Time (37), NetBIOS (137/138), IEN-116 (42), and TACACS (49). If you only want to relay DHCP and nothing else, disable the others with no ip forward-protocol udp <port>.

See: DHCP Overview | DHCP Relay Agent Lab

9. DHCP Message Types — Complete Reference

Message Type	Sent By	Purpose	Transport
DHCP Discover	Client	Locate available DHCP servers	Broadcast (0.0.0.0 → 255.255.255.255)
DHCP Offer	Server	Propose an IP address and configuration	Broadcast or unicast to client MAC
DHCP Request	Client	Accept an Offer (initial) or renew/rebind a lease	Initial: Broadcast; T1 renewal: Unicast; T2 rebind: Broadcast
DHCP ACK	Server	Confirm and finalise the IP lease	Broadcast or unicast to client
DHCP NAK	Server	Reject the Request — IP unavailable or client on wrong subnet	Broadcast to 255.255.255.255
DHCP Decline	Client	Inform server offered IP is already in use (detected via ARP probe)	Unicast to server
DHCP Release	Client	Voluntarily return the IP lease to the server before expiry	Unicast to server
DHCP Inform	Client	Request configuration options from server without requesting an IP (client already has a static IP but needs DNS/gateway info)	Unicast to server

10. APIPA — When DHCP Fails

If a client sends DHCP Discover messages repeatedly and receives no response, it falls back to APIPA (Automatic Private IP Addressing). The client self-assigns a link-local address in the 169.254.0.0/16 range — chosen randomly from 169.254.1.0 to 169.254.254.255, then verified by ARP probe to ensure uniqueness.

APIPA allows limited local communication between devices on the same segment that all have APIPA addresses.
There is no gateway or DNS — APIPA addresses cannot reach the internet or other subnets.
The client continues sending DHCP Discover broadcasts in the background every few minutes — it will switch to a DHCP-assigned address the moment a server responds.
On Windows, the fallback delay before APIPA is approximately 60 seconds (after 4 Discover attempts).

Diagnostic significance: Seeing a 169.254.x.x address on a client is a reliable indicator that DHCP is failing for that client. Common causes: DHCP server down, pool exhausted, missing ip helper-address on the VLAN SVI, or DHCP Snooping blocking the response.

11. Common DHCP Options — What Gets Sent in the Offer/ACK

DHCP parameters beyond the IP address itself are carried as options in the DHCP message. Each option has a standardised option code number.

Option Code	Parameter	Notes
1	Subnet Mask	Defines the network prefix length
3	Router (Default Gateway)	Can list multiple gateways in priority order
6	DNS Servers	Up to 8 DNS servers in order of preference
15	Domain Name	DNS search domain (e.g., company.local)
42	NTP Servers	Network Time Protocol servers for clock sync
43	Vendor Specific Info	Used by APs (Cisco WLC discovery), IP phones
51	Lease Time	Seconds until lease expires; determines T1 and T2
53	DHCP Message Type	Identifies the message as Discover/Offer/Request/ACK/NAK etc.
54	DHCP Server Identifier	IP of the server sending this message — used by client to identify chosen server
58	T1 Renewal Time	Seconds until first unicast renewal attempt (default: 50% of lease)
59	T2 Rebinding Time	Seconds until broadcast rebinding attempt (default: 87.5% of lease)
43 / 66 / 67	TFTP Server / Boot File	PXE boot configuration for diskless devices

12. DHCP Security — Threats and Defences

DHCP has no built-in authentication — any device can act as a DHCP server on a network segment. This creates two significant attack vectors:

Rogue DHCP Server Attack

An attacker connects an unauthorised device running a DHCP server. When clients broadcast DHCP Discovers, the rogue server responds faster than the legitimate server and offers clients a malicious gateway (the attacker's IP) — redirecting all traffic through the attacker (Man-in-the-Middle).

  Normal:  Client ─── DHCP Discover ──▶ Legitimate Server
                   ◀── DHCP Offer ─────  GW: 192.168.1.1 (real router)

  Attack:  Client ─── DHCP Discover ──▶ Rogue Server (wins race)
                   ◀── DHCP Offer ─────  GW: 192.168.1.99 (attacker's machine)
           Client sends all traffic through attacker's machine!

DHCP Starvation Attack

An attacker sends thousands of DHCP Discovers with spoofed MAC addresses, exhausting the DHCP server's address pool. Legitimate clients receive no IP addresses (pool is "starved"). This is a Denial of Service (DoS) attack against DHCP.

Defence — DHCP Snooping

Cisco switches implement DHCP Snooping as the primary defence:

Ports are classified as trusted (connected to legitimate DHCP servers or uplinks) or untrusted (connected to end clients).
DHCP Offer and DHCP ACK messages arriving on untrusted ports are dropped — the switch blocks all rogue server responses at the hardware level.
A DHCP Snooping Binding Table records all validated DHCP leases (IP, MAC, VLAN, port, expiry) — used by DAI (Dynamic ARP Inspection) to prevent ARP spoofing.
Rate limiting on untrusted ports prevents DHCP starvation attacks.

See: DHCP Snooping & Dynamic ARP Inspection (Step-by-Step)

13. Real-World Examples

Example 1 — Home Network

A laptop connects to a home Wi-Fi network:

Laptop sends DHCP Discover broadcast (0.0.0.0 → 255.255.255.255)
Home router (DHCP server) responds with DHCP Offer: 192.168.1.10/24, GW: 192.168.1.1, DNS: 8.8.8.8, Lease: 24 hours
Laptop broadcasts DHCP Request accepting 192.168.1.10
Router responds with DHCP ACK — lease confirmed
After 12 hours (T1), laptop unicasts DHCP Request to router to renew
Router responds with DHCP ACK — lease extended for another 24 hours

Example 2 — Enterprise Multi-VLAN Network

A PC in VLAN 20 (192.168.20.0/24) connects. The DHCP server is at 10.0.0.5 on a separate management VLAN. The Layer 3 switch SVI for VLAN 20 has ip helper-address 10.0.0.5:

PC sends DHCP Discover broadcast on VLAN 20
Layer 3 switch intercepts the broadcast, inserts giaddr = 192.168.20.1 (the SVI IP), and unicasts the Discover to 10.0.0.5
DHCP server sees giaddr = 192.168.20.1, selects the VLAN20_POOL (192.168.20.0/24)
Server sends DHCP Offer for 192.168.20.15 back to the relay
Relay forwards Offer to PC on VLAN 20
DORA completes — PC gets 192.168.20.15/24, GW: 192.168.20.1

Example 3 — DHCP Failure (APIPA fallback)

A PC connects but the Layer 3 switch SVI for its VLAN has no ip helper-address:

PC sends 4 DHCP Discovers over ~60 seconds — no response
PC falls back to APIPA: assigns itself 169.254.x.x address
PC can ping other APIPA hosts on same VLAN but cannot reach internet or other subnets
Admin adds ip helper-address 10.0.0.5 to the SVI
PC's next DHCP Discover is relayed — DORA completes — PC gets proper IP

14. Common Misconceptions About DHCP

"The DHCP Request is unicast to the chosen server."
The initial DHCP Request (message 3 of DORA) is always broadcast — even though the client knows the server's IP. This is intentional: all other DHCP servers that sent Offers need to see the broadcast Request containing the chosen server's ID so they can release their temporarily reserved IPs. Only the T1 renewal Request is unicast.
"DHCP only provides an IP address."
DHCP delivers a complete network configuration package via options: subnet mask, default gateway, DNS servers, domain name, NTP servers, lease time, and more. The IP address is just one of many parameters.
"A DHCP ACK means the IP is permanently assigned."
A DHCP ACK grants a lease — a time-limited assignment. The client must renew the lease at T1 or T2 to keep the IP. If the lease expires without renewal, the IP returns to the pool and the client loses it.
"169.254.x.x means DHCP is configured wrong on the server."
An APIPA address means the client received no DHCP response — the problem is often with the network path (missing relay, blocked port, wrong VLAN) rather than the server itself. The server may be working perfectly for other clients.
"DHCP works across routers without any special configuration."
DHCP uses broadcasts which are stopped at Layer 3 boundaries. A relay agent (ip helper-address on each client-facing interface) is required whenever the DHCP server is on a different subnet than the clients.

15. Key Points & Exam Tips

DHCP uses UDP port 67 (server) and UDP port 68 (client).
DORA sequence: Discover → Offer → Request → Acknowledge — client sends D and R; server sends O and A.
DHCP Discover: Src 0.0.0.0, Dst 255.255.255.255 — broadcast because client has no IP.
DHCP Request (initial): also broadcast — not unicast — so other servers release their reserved IPs.
T1 = 50% of lease → unicast Request to original server.
T2 = 87.5% of lease → broadcast Request to any available server.
DHCP NAK: server rejects the Request → client restarts full DORA.
DHCP Decline: client rejects the Offer (ARP probe detected IP in use) → server marks IP as conflicted, client restarts DORA.
DHCP Release: client voluntarily returns IP early.
APIPA (169.254.x.x): client self-assigns when no DHCP response after ~60s; local-only, no gateway.
ip helper-address on the client-facing interface converts DHCP broadcasts to unicast for the DHCP server — required when server is on different subnet.
DHCP Snooping: blocks rogue DHCP servers by dropping Offer/ACK on untrusted ports.

16. How DHCP Works Quiz

1. A laptop connects to a network and sends a DHCP Discover. Two DHCP servers (Server A and Server B) both respond with Offers. The laptop accepts Server A's offer. How does Server B learn that its Offer was rejected so it can release the IP it temporarily reserved?

A. Server B sends the laptop a DHCP NAK to withdraw its Offer B. Server A sends a notification directly to Server B C. The laptop broadcasts the DHCP Request containing Server A's IP in the Server Identifier option — Server B sees this broadcast, recognises its IP is not chosen, and releases its reserved IP D. Server B's reserved IP automatically expires after 30 seconds with no action needed

Correct answer is C. The DHCP Request (message 3 of DORA) is always sent as a broadcast (0.0.0.0 → 255.255.255.255), not unicast to Server A. The Request contains Option 54 (Server Identifier) with Server A's IP. Every DHCP server on the segment receives this broadcast. Server B reads Option 54, sees its own IP is not selected, and releases the IP it had temporarily reserved for this client. This is the precise reason the Request must be broadcast — to allow all servers to clean up their reservations.

2. A client's DHCP lease is 8 hours. At what exact times does the client attempt lease renewal, and by what method each time?

A. T1 at 1 hour (broadcast), T2 at 6 hours (unicast) B. T1 at 2 hours (broadcast), T2 at 7 hours (unicast) C. T1 at 4 hours (unicast), T2 at 7 hours (broadcast) — client always restarts DORA at T1 D. T1 at 4 hours (unicast to original server), T2 at 7 hours (broadcast to any server)

Correct answer is D. T1 = 50% × 8 hours = 4 hours. At T1, the client sends a unicast DHCP Request directly to the original DHCP server (it knows the server's IP from Option 54 in the original ACK). T2 = 87.5% × 8 hours = 7 hours. At T2, the client has not received a T1 renewal response (original server may be down), so it broadcasts a DHCP Request to find any available DHCP server. If neither T1 nor T2 succeeds, the lease expires at 8 hours and the client restarts DORA.

3. A client receives a DHCP ACK and configures 192.168.1.50 as its IP address. It then sends an ARP probe for 192.168.1.50 and receives an ARP reply from another device. What should the client do next, and what happens to 192.168.1.50?

A. The client ignores the ARP reply and uses 192.168.1.50 anyway — the server already confirmed it B. The client sends a DHCP Decline to the server; the server marks 192.168.1.50 as conflicted and withholds it; the client restarts DORA C. The client sends a DHCP NAK to the server and waits for a new ACK D. Both devices use 192.168.1.50 and the operating system handles the conflict

Correct answer is B. After receiving an ACK, the client performs an ARP probe for the offered IP. If another device responds (meaning the IP is already in use), the client sends a DHCP Decline message to the server, informing it that the offered IP has a conflict. The server records 192.168.1.50 in its conflict table (visible via show ip dhcp conflict) and withholds it from future assignments. The client then clears its configuration and restarts DORA to get a different IP. NAK is a server-to-client message — clients do not send NAKs.

4. A PC shows an IP address of 169.254.87.45. A network engineer checks the DHCP server and confirms it has available addresses in the pool. What is the most likely cause of the APIPA address?

A. The DHCP Discover broadcast from the PC is not reaching the server — likely a missing ip helper-address on the client's VLAN SVI or a network path issue B. The server sent a DHCP NAK and the client chose to use APIPA C. APIPA is automatically assigned when DHCP leases IP addresses above 169.254.x.x range D. The DHCP server pool is exhausted even though it shows available addresses

Correct answer is A. APIPA is assigned when a client sends multiple DHCP Discovers and receives no response. Since the server has available addresses, the problem is not the server itself — the Discover broadcasts are not reaching it. Common causes: (1) Missing ip helper-address on the Layer 3 switch SVI for this client's VLAN, (2) Firewall or ACL blocking UDP port 67, (3) The client's VLAN is misconfigured and traffic is not routed to the correct segment. A DHCP NAK would mean the client reached the server but was rejected — with APIPA the server never saw the client at all.

5. Which DHCP option number carries the default gateway IP that the server sends to clients, and what happens to a client that receives an ACK without this option?

A. Option 6 — the client uses 0.0.0.0 as its gateway if this option is missing B. Option 51 — the client cannot complete DORA without a gateway option C. Option 3 — the client gets an IP and can reach local subnet hosts but cannot communicate with any other subnet or the internet D. Option 43 — the client broadcasts ARP requests for the gateway until one is found

Correct answer is C. DHCP Option 3 (Router) carries the default gateway IP address. Without a gateway, the client can only communicate with devices on its own directly connected subnet (same /24 or whatever prefix it received). Any traffic destined for a different subnet would have no next-hop and be dropped. The client would have an IP and subnet mask but no ability to route beyond the local segment — no internet access, no access to other VLANs. Option 6 is DNS servers. Option 51 is lease time.

6. What is the key difference between a DHCP NAK and a DHCP Decline, and which device sends each one?

A. Both are sent by the server — NAK rejects a new request, Decline rejects a renewal B. NAK is sent by the server to reject the client's Request; Decline is sent by the client to reject the server's Offer after detecting the offered IP is already in use via ARP probe C. NAK is sent by the client when it refuses an Offer; Decline is sent by the server when the pool is exhausted D. Both mean the DORA process succeeded but the lease was cancelled

Correct answer is B. DHCP NAK (Negative Acknowledgement) is sent by the server in response to a DHCP Request when it cannot honour the request — the IP is already taken, the client is on the wrong subnet, or the lease binding is invalid. DHCP Decline is sent by the client after receiving an ACK and performing an ARP probe that reveals the offered IP is already in use by another device. Both result in the client restarting DORA, but they are triggered by different parties and different conditions.

7. A device already has a static IP (10.10.10.50) but wants to learn its DNS server and NTP server from DHCP without changing its IP address. Which DHCP message type allows this?

A. DHCP Discover — the server will recognise the static IP and not offer a different one B. DHCP Request — unicast to the server with Option 50 set to 10.10.10.50 C. DHCP Release — returns the static IP first so DHCP can reassign it D. DHCP Inform — sent by a client that already has an IP to request only the configuration options without asking for an IP address

Correct answer is D. DHCP Inform is a specialised message type where the client already has a valid IP address (static or previously configured) but needs additional configuration options from the DHCP server — such as DNS servers, NTP servers, or domain name. The client sends a DHCP Inform unicast directly to the server with its current IP in the ciaddr field. The server responds with a DHCP ACK containing only the requested options — it does not assign or change the client's IP address. This is used by IP phones, access points, and devices with static IPs that still need centralised configuration.

8. A switch with DHCP Snooping enabled has all ports in untrusted state. Users on access ports cannot get IP addresses even though the DHCP server is reachable via the uplink port (Gi0/48). What single change fixes this?

A. Configure ip dhcp snooping trust on GigabitEthernet0/48 — this tells the switch that DHCP Offer/ACK messages from the uplink are legitimate and should not be dropped B. Disable DHCP Snooping entirely with no ip dhcp snooping C. Add the DHCP server's IP to the snooping binding table with ip dhcp snooping binding D. Configure ip helper-address on Gi0/48

Correct answer is A. DHCP Snooping marks all ports as untrusted by default. DHCP Offer and DHCP ACK messages arriving on untrusted ports are dropped — the switch treats them as potential rogue server responses. The DHCP server's Offers are arriving on Gi0/48 (the uplink), which is untrusted, so they are silently dropped. Configuring ip dhcp snooping trust on Gi0/48 tells the switch to allow DHCP server messages from this port. Access ports remain untrusted — which is correct for end devices that should never send Offers.

9. A DHCP server assigns a 7-day lease. At exactly day 3.5 (50% = T1), the client sends a renewal request. The server is unavailable and does not respond. The client has not been rebooted. Describe what happens at days 3.5, 6.125, and 7.

A. Day 3.5: IP is released. Day 6.125: New DORA started. Day 7: APIPA assigned B. Day 3.5: Unicast renewal fails silently. Day 6.125: IP released. Day 7: DORA restarts C. Day 3.5 (T1): Unicast renewal attempt fails — client keeps IP and continues. Day 6.125 (T2 = 87.5%): Client broadcasts to find any DHCP server. Day 7: Lease expires — client releases IP and restarts full DORA D. Day 3.5: Client immediately starts APIPA fallback. Day 7: DORA restarts if APIPA also fails

Correct answer is C. At T1 (50% = day 3.5), the client sends a unicast DHCP Request to the original server. If there's no ACK, the client retains its IP address — it does not release it or fall to APIPA yet. The lease is still valid. At T2 (87.5% = day 6.125), the client tries again with a broadcast DHCP Request to find any DHCP server — the original may still be down. If no server responds to the T2 broadcast either, the client waits until lease expiry at day 7, then releases the IP and restarts DORA from scratch. APIPA is only a fallback from DORA — not from failed renewal if a lease is still active.

10. An attacker on a corporate LAN runs a rogue DHCP server that responds to DHCP Discovers faster than the legitimate server. Clients receive the rogue server's Offer with a malicious default gateway. Which switch feature, correctly configured, would have prevented this attack?

A. Port security with maximum 1 MAC per port B. DHCP Snooping with only the uplink port marked as trusted — the rogue server's DHCP Offers on an access port would be dropped at the switch hardware level before reaching any client C. Dynamic ARP Inspection (DAI) — prevents ARP spoofing and therefore also prevents DHCP Offer spoofing D. VLAN Trunking — isolating the rogue server in a separate VLAN prevents it reaching clients

Correct answer is B. DHCP Snooping is the specific defence for rogue DHCP server attacks. By marking only the uplink port(s) — connected to the legitimate DHCP server — as trusted, all other access ports are untrusted. When the rogue DHCP server sends a DHCP Offer from an untrusted access port, the switch drops it at hardware level before any client can receive it. Clients only ever see Offers from the legitimate server via the trusted uplink. Port security limits MAC addresses but doesn't filter DHCP messages by type. DAI prevents ARP spoofing (a separate attack) and actually depends on DHCP Snooping's binding table to work — it doesn't prevent rogue DHCP servers directly.

← Back to Home