26 DHCP and Address Resolution
26.2 Learning Objectives
By the end of this chapter, you will be able to:
- Configure DHCP: Set up automatic IP assignment for IoT devices
- Choose lease times: Select appropriate durations for different device types
- Explain ARP: Describe how IPv4 addresses resolve to MAC addresses and diagnose ARP-related failures
- Apply Neighbor Discovery: Use IPv6’s improved address resolution mechanism
- Troubleshoot addressing issues: Diagnose IP conflicts and ARP problems
MVU: Minimum Viable Understanding
Core concept: DHCP automatically assigns IP addresses to devices, while ARP (IPv4) and Neighbor Discovery (IPv6) resolve IP addresses to physical MAC addresses for local delivery.
Why it matters: Manual IP assignment for 1,000 sensors would take 83 hours - DHCP does it in seconds. ARP problems cause mysterious connectivity failures.
Key takeaway: Use DHCP with long leases (7-30 days) for fixed IoT sensors, DHCP reservations for infrastructure devices, and watch for ARP flapping as a sign of IP conflicts.
26.3 Prerequisites
Before diving into this chapter, you should be familiar with:
- IPv4 Addressing Fundamentals: Understanding of IP address structure
- Subnetting and CIDR: Knowledge of subnet boundaries
For Beginners: DHCP and ARP
DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addresses to devices when they connect to a network. When your IoT sensor powers on, it broadcasts “I need an IP address!” and a DHCP server responds with one.
Why DHCP is essential:
- 1,000 sensors × 5 minutes manual config = 83 hours
- DHCP: automatic, instant, error-free
ARP (Address Resolution Protocol) solves a different problem: your device knows the IP address it wants to reach (192.168.1.100), but the network hardware needs the physical MAC address. ARP broadcasts “Who has 192.168.1.100?” and the target device responds with its MAC address.
Common problems:
- IP conflict: Two devices claiming the same IP → ARP flapping
- DHCP failure: Device gets no IP → link-local address (169.254.x.x)
Sensor Squad: The Automatic Address Machine!
“I just joined the network, but nobody told me my address!” said Sammy the Sensor, looking lost. Max the Microcontroller pointed to the DHCP server. “No worries! Just shout ‘I need an address!’ and the DHCP server will give you one automatically.”
“It works like a hotel front desk,” Lila the LED explained. “You walk in (Discover), the desk offers you a room key (Offer), you say ‘Yes, I will take it!’ (Request), and they confirm your booking (Acknowledge). D-O-R-A – four simple steps and you have an IP address!”
“But what about finding OTHER devices?” asked Sammy. “I know the gateway’s IP address is 192.168.1.1, but the network needs its MAC address to actually deliver my data.” Max said, “That is where ARP comes in! You broadcast ‘Who has 192.168.1.1?’ and the gateway replies ‘That is me! My MAC address is AA:BB:CC:DD:EE:FF.’ Problem solved.”
Bella the Battery added, “Without DHCP, someone would have to manually type in addresses for all 1,000 of us sensors – that would take 83 hours! DHCP does it in seconds and never makes typos. That is automation at its finest!”
How It Works: DHCP and Address Resolution
When an IoT device powers on, DHCP and address resolution work together in a specific sequence:
Step 1: DHCP Discovery - Device broadcasts “I need an IP address!” (DHCP Discover)
Step 2: DHCP Offer - DHCP server responds with available IP address and configuration (Offer)
Step 3: DHCP Request - Device accepts the offer (Request)
Step 4: DHCP Acknowledgment - Server confirms assignment and provides IP, subnet mask, gateway, DNS (Acknowledge)
Step 5: ARP Resolution - When device needs to send data to another local device, it broadcasts “Who has IP 192.168.1.1?” (ARP Request)
Step 6: ARP Reply - Target device responds “That’s me! My MAC is AA:BB:CC:DD:EE:FF” (ARP Reply)
Step 7: Local Communication - Device now knows the MAC address and can send Ethernet frames directly on the local segment
This DORA (Discover, Offer, Request, Acknowledge) process happens automatically, eliminating manual configuration for thousands of IoT devices.
26.4 DHCP (Dynamic Host Configuration Protocol)
26.4.1 Why DHCP for IoT?
Manual IP Assignment Problems:
- 1,000 sensors × 5 minutes each = 83 hours of configuration
- Human error (duplicate IPs, typos)
- No visibility into which addresses are used
- Difficult to reconfigure (moving sensors, network changes)
DHCP Solution:
- Automatic IP assignment
- Centralized management
- Lease tracking
- Easy reconfiguration
26.4.2 DHCP Operation (DORA Process)
DHCP Ports:
- Server listens on UDP port 67
- Client listens on UDP port 68
26.4.3 DHCP Lease Management
Lease Time: Duration for which IP is assigned (e.g., 24 hours, 7 days)
Lease Renewal Process:
- At 50% of lease time (T1), client tries to renew with original server
- At 87.5% of lease time (T2), client broadcasts renewal to any server
- If lease expires, client must restart DORA process
Putting Numbers to It
DHCP lease timing uses precise fractional intervals. For a 7-day lease:
\[T_1 = \text{Lease} \times 0.5 = 7 \times 0.5 = 3.5 \text{ days}\]
\[T_2 = \text{Lease} \times 0.875 = 7 \times 0.875 = 6.125 \text{ days}\]
For example, a sensor with a 604,800-second (7-day) lease: \[T_1 = 604800 \times 0.5 = 302400 \text{ seconds} = 3.5 \text{ days}\] \[T_2 = 604800 \times 0.875 = 529200 \text{ seconds} = 6.125 \text{ days}\]
This means the sensor attempts renewal at day 3.5, tries broadcast renewal at day 6.125, and loses its IP if the DHCP server stays down past day 7. With a 30-day lease (2,592,000 seconds), the DHCP server could be offline for 15 days before devices lose connectivity — why longer leases suit fixed IoT deployments.
IoT Lease Considerations:
| Device Type | Recommended Lease | Reasoning |
|---|---|---|
| Fixed sensors | 7-30 days | Rarely move, long leases reduce DHCP traffic |
| Mobile devices | 1-4 hours | Frequent movement, need quick IP changes |
| Temporary devices | 30 minutes | Testing, commissioning |
| Critical infrastructure | Static assignment | Guaranteed address, no DHCP dependency |
26.4.4 DHCP Options for IoT
Beyond IP address, DHCP provides additional configuration via options:
| Option | Purpose | Example | IoT Relevance |
|---|---|---|---|
| 3 | Default Gateway | 192.168.1.1 | Routes to internet/cloud |
| 6 | DNS Servers | 8.8.8.8, 1.1.1.1 | Resolve cloud hostnames |
| 15 | Domain Name | sensors.example.com | Device FQDN |
| 42 | NTP Servers | 216.239.35.0 | Clock synchronization (IP addresses only) |
| 66 | TFTP Server | 192.168.1.50 | Firmware updates |
| 150 | TFTP Server (Cisco) | 192.168.1.50 | Cisco-specific firmware |
26.4.5 DHCP Reservations (Static DHCP)
Best of both worlds: Combine DHCP convenience with static IP predictability
How it works:
- DHCP server maps MAC address to specific IP
- Device always gets the same IP via DHCP
- Example: Camera with MAC
00:11:22:33:44:55always gets192.168.1.100
Benefits:
- Centralized management (all IPs configured in DHCP server)
- Predictable addressing (gateways, cameras always at known IPs)
- Easy to change (update DHCP server, not each device)
IoT Best Practice:
- Static DHCP for critical infrastructure (gateways, access points, NVRs)
- Dynamic DHCP for sensors, actuators
- Static manual for network infrastructure (routers, switches, DHCP server itself)
26.5 Address Resolution (ARP and Neighbor Discovery)
26.5.1 ARP (Address Resolution Protocol) for IPv4
Problem: IP addresses are logical, but Ethernet requires physical MAC addresses. How does a device find the MAC address for an IP?
Solution: ARP broadcasts “Who has IP 192.168.1.100?” and the device responds with its MAC address.
ARP Cache:
- Devices store IP→MAC mappings in ARP cache
- Reduces broadcast traffic
- Typical cache timeout: 5-20 minutes
Check ARP cache:
# Linux/macOS
arp -a
# Windows
arp -a
# Example output:
# 192.168.1.1 11:22:33:44:55:66 dynamic
# 192.168.1.100 aa:bb:cc:dd:ee:ff dynamicARP Limitations:
- Broadcasts consume bandwidth (problematic in large networks)
- Security vulnerabilities (ARP spoofing attacks)
- No authentication (any device can claim any IP)
26.5.2 Neighbor Discovery (ND) for IPv6
IPv6 Neighbor Discovery replaces ARP with a more efficient, secure protocol using ICMPv6 messages.
Key ND Messages:
| Message Type | Purpose | IPv4 Equivalent |
|---|---|---|
| Router Solicitation (RS) | “Are there any routers?” | None |
| Router Advertisement (RA) | “I’m a router, here’s network config” | DHCP (partially) |
| Neighbor Solicitation (NS) | “What’s your MAC address?” | ARP Request |
| Neighbor Advertisement (NA) | “My MAC is X” | ARP Reply |
| Redirect | “Use this router instead” | ICMP Redirect |
Advantages over ARP:
- Uses multicast instead of broadcast: Only interested devices process packets
- Duplicate Address Detection (DAD): Prevents IP conflicts automatically
- Router Discovery: Devices auto-discover gateways (no DHCP needed for basic config)
- Stateless Address Autoconfiguration (SLAAC): Devices self-assign IPs based on network prefix
- Integrated security: IPsec can secure ND messages (prevents spoofing)
SLAAC (Stateless Address Autoconfiguration):
IoT Implications:
- IPv6 sensors can self-configure without DHCP server
- Reduced infrastructure requirements
- Faster deployment (plug-and-play)
Level 1: Beginner Example - Single Device DHCP Lease
Scenario: Configure DHCP for 10 temperature sensors on a single floor
Configuration:
# Simple DHCP range for 10 sensors + 5 growth buffer
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.114; # 15 addresses
option routers 192.168.1.1;
option domain-name-servers 8.8.8.8;
default-lease-time 604800; # 7 days
}Expected Behavior: Each sensor receives an IP from .100-.114, lease lasts 7 days (sensors rarely move).
Level 2: Intermediate Example - DHCP Reservations
Scenario: 50 sensors where 5 critical devices need predictable IPs
Configuration:
subnet 192.168.1.0 netmask 255.255.255.0 {
# Dynamic pool for regular sensors
range 192.168.1.100 192.168.1.199;
# Reservations for critical devices
host gateway-sensor {
hardware ethernet aa:bb:cc:dd:ee:01;
fixed-address 192.168.1.10;
}
host alert-sensor {
hardware ethernet aa:bb:cc:dd:ee:02;
fixed-address 192.168.1.11;
}
}Why This Works: Critical devices get same IP every time (based on MAC), while regular sensors use dynamic pool.
Level 3: Advanced Example - Multi-Subnet with Lease Policies
Scenario: 200 devices across 3 buildings, different lease times based on device mobility
Configuration:
# Building A - Fixed sensors (long lease)
subnet 10.1.0.0 netmask 255.255.255.0 {
range 10.1.0.50 10.1.0.149;
default-lease-time 2592000; # 30 days
max-lease-time 7776000; # 90 days
}
# Building B - Mobile devices (short lease)
subnet 10.2.0.0 netmask 255.255.255.0 {
range 10.2.0.50 10.2.0.149;
default-lease-time 14400; # 4 hours
max-lease-time 86400; # 24 hours
}
# Building C - Mixed (medium lease)
subnet 10.3.0.0 netmask 255.255.255.0 {
range 10.3.0.50 10.3.0.149;
default-lease-time 604800; # 7 days
# Special class for temporary test devices
class "test-devices" {
match if substring (option host-name, 0, 5) = "test-";
}
pool {
allow members of "test-devices";
range 10.3.0.200 10.3.0.220;
default-lease-time 3600; # 1 hour
}
}Advanced Feature: Test devices (hostname starts with “test-”) get separate pool with 1-hour leases, automatically expire when testing completes.
26.6 Optional Investigation: Network Discovery Tools
The chapter concepts can be understood without writing code. If you later use a Raspberry Pi, Linux gateway, or managed router, focus on the evidence these tools reveal rather than the program that collects it.
26.6.1 ARP Scanner: Discover Active Devices
An ARP scanner asks every address in the local subnet, “Who has this IP?” Devices that are awake reply with their MAC address. That is enough to build a simple live-device inventory.
| Observation | What It Means | What to Do Next |
|---|---|---|
| One IP maps to one MAC address | Normal local address resolution | Record the device type and expected location |
| One IP alternates between two MAC addresses | Likely IP conflict or misconfigured static address | Compare DHCP leases, reservations, and device labels |
| Expected sensor is missing | Device may be asleep, disconnected, or outside the subnet | Check power state, radio link, and subnet mask |
| Unknown MAC prefix appears | A new or rogue device joined the LAN | Identify the vendor OUI and confirm whether it belongs |
Beginner reading task: Given the table below, identify the possible conflict and the device that needs investigation.
| IP Address | MAC Address | Vendor Hint | Interpretation |
|---|---|---|---|
| 192.168.1.1 | 00:11:22:AA:10:01 | Gateway | Expected default router |
| 192.168.1.45 | 24:0A:C4:12:34:56 | ESP32 sensor | Expected temperature sensor |
| 192.168.1.45 | 24:0A:C4:78:9A:BC | ESP32 sensor | Conflict: two devices claim the same IP |
| 192.168.1.80 | B0:CE:18:44:20:10 | Smart lighting | Expected building device |
26.6.2 DHCP Lease Monitor: Track Address Assignments
A DHCP lease monitor reads the server’s lease table. It answers a different question from ARP: “Which IP address did the DHCP server assign, to which MAC address, and for how long?”
| Lease Evidence | Healthy Reading | Warning Sign |
|---|---|---|
| IP address | Inside the intended DHCP pool or reservation range | Inside a reserved/static-only range |
| MAC address | Matches the physical device label or asset record | Same MAC appears with several active leases |
| Hostname | Meaningful device name, such as temp-sensor-03 |
Blank or generic name for managed IoT equipment |
| Expiry time | Long for fixed sensors, short for mobile devices | Fixed sensors renewing every few minutes or hours |
Troubleshooting pattern: If ARP says a device is using 192.168.1.45 but DHCP says the same MAC should have 192.168.1.67, suspect a manually configured static IP on the device. Fix the device configuration or create a DHCP reservation outside the dynamic pool.
26.7 Practical Exercise: DHCP Configuration Planning
Scenario: Configure DHCP for a smart building with: - 200 IoT sensors (fixed locations, rarely change) - 50 employee smartphones (frequent connects/disconnects) - 10 security cameras (critical, need predictable IPs) - 5 network infrastructure devices (gateways, access points)
Design the DHCP configuration:
Solution:
| Device Type | Assignment Method | IP Range | Lease Time | Rationale |
|---|---|---|---|---|
| Infrastructure | Static (manual) | 192.168.1.1-10 | N/A | Must be reachable even if DHCP fails |
| Cameras | DHCP Reservation | 192.168.1.11-20 | 30 days | Predictable IPs for NVR, long lease |
| IoT Sensors | Dynamic DHCP | 192.168.1.50-249 | 7 days | Fixed locations, long lease reduces traffic |
| Smartphones | Dynamic DHCP | 192.168.1.50-249 | 2 hours | Shared pool with sensors, short lease for mobility |
DHCP Server Configuration (example):
Optional ISC DHCP configuration example
# Subnet declaration
subnet 192.168.1.0 netmask 255.255.255.0 {
# Dynamic pool (sensors and phones share)
range 192.168.1.50 192.168.1.249;
# DHCP options
option routers 192.168.1.1;
option domain-name-servers 8.8.8.8, 1.1.1.1;
option ntp-servers 192.168.1.1;
option domain-name "smartbuilding.local";
# Default lease time: 7 days (sensors dominate the pool)
default-lease-time 604800;
max-lease-time 2592000;
# Note: smartphones request shorter leases via DHCP option 51 (lease time request)
# or use vendor class matching to assign different default-lease-time per device class
}
# Camera reservations (predictable IPs)
host camera-lobby {
hardware ethernet aa:bb:cc:dd:ee:01;
fixed-address 192.168.1.11;
default-lease-time 2592000; # 30 days
}
host camera-entrance {
hardware ethernet aa:bb:cc:dd:ee:02;
fixed-address 192.168.1.12;
default-lease-time 2592000;
}Key Design Decisions:
- Infrastructure devices get static IPs (DHCP server must know their address)
- Cameras use DHCP reservations (centralized management + predictability)
- Sensors and phones share dynamic pool (efficient address utilization)
- Lease times match device mobility (fixed devices = long leases)
26.8 Worked Example: Troubleshooting IP Address Conflict
Scenario: Your smart factory suddenly experiences intermittent connectivity issues. Two temperature sensors are reporting sporadically, and network monitoring shows MAC address flapping alerts.
Given:
- Sensor A: MAC 24:0A:C4:12:34:56, assigned DHCP IP 192.168.10.45
- Sensor B: MAC 24:0A:C4:78:9A:BC, assigned DHCP IP 192.168.10.67
- Symptom: Both sensors show as 192.168.10.45 in ARP table intermittently
Troubleshooting sequence:
| Step | Evidence to Check | What the Evidence Means |
|---|---|---|
| 1. Verify ARP on the gateway | 192.168.10.45 appears with MAC 24:0A:C4:12:34:56 and also with MAC 24:0A:C4:78:9A:BC |
Two physical devices are claiming the same IP address |
| 2. Compare against DHCP leases | DHCP assigned Sensor A .45 and Sensor B .67 |
Sensor B should not be using .45 if it follows DHCP |
| 3. Ping and re-check ARP | Replies from .45 alternate between the two MAC addresses |
The conflict is active, not just an old cache entry |
| 4. Fix the addressing plan | Reconfigure Sensor B for DHCP, create DHCP reservations, or move static IPs outside the dynamic range | Each device must have one unique address source |
Result: After reconfiguring Sensor B to use DHCP and creating MAC-based reservations, both sensors receive unique IP addresses and connectivity is restored.
Key Insight: IP address conflicts cause “ARP flapping” where the switch’s MAC address table constantly updates, randomly delivering packets to either device. Always segment your address space into static and dynamic ranges.
26.9 Common Pitfalls
Pitfall: Misconfiguring Subnet Masks Causing Silent Routing Failures
The Mistake: Developers assign IP addresses with incorrect subnet masks (e.g., using /24 when the network is /16), causing devices to incorrectly determine whether destinations are local or remote.
Why It Happens: Many IoT tutorials use “255.255.255.0” as a universal subnet mask without explaining its meaning. When copying configurations between networks, the subnet mask is often left unchanged.
The Fix: Understand and verify the subnet calculation:
Scenario: Device A (192.168.1.50/24) tries to reach Device B (192.168.2.100)
| Correct /24 Calculation | Value |
|---|---|
| My IP | 192.168.1.50 |
| My mask | 255.255.255.0 (/24) |
| My network | 192.168.1.0 |
| Target | 192.168.2.100 |
| Target AND mask | 192.168.2.0 |
| Result | Different network, send to the gateway |
Problem case: Device A configured with wrong mask /16:
| Incorrect /16 Calculation | Value |
|---|---|
| My IP | 192.168.1.50 |
| My mask | 255.255.0.0 (/16) - wrong for this network |
| My network | 192.168.0.0 |
| Target | 192.168.2.100 |
| Target AND mask | 192.168.0.0 |
| Result | Same network, incorrectly send directly with ARP |
With the wrong /16 mask, Device A tries to ARP for 192.168.2.100 directly instead of sending through the gateway. Communication silently fails.
Diagnostic commands:
# Linux: Verify route decision
ip route get 192.168.2.100
# Should show "via <gateway>" if correctly configuredPrevention: Always verify subnet masks match the actual network topology. Use DHCP for automatic configuration.
26.10 Concept Relationships
| Concept | Depends On | Enables | Common With |
|---|---|---|---|
| DHCP | Functioning network infrastructure | Automatic IP configuration | DNS, NTP options |
| ARP | IP addresses assigned | MAC address discovery | Ethernet switching |
| Neighbor Discovery | IPv6 stack | Stateless autoconfiguration (SLAAC) | Router advertisements |
| DHCP Reservations | MAC addresses known | Predictable IPs with central management | Static IP benefits |
| IP Conflicts | Multiple devices claiming same IP | ARP flapping, connectivity failures | Misconfigured DHCP/static IPs |
26.11 See Also
Related chapters and resources:
- IPv4 Addressing Fundamentals - Understanding IP address structure and classes
- Subnetting and CIDR - Planning network segments that DHCP serves
- IPv6 for IoT - IPv6 Neighbor Discovery and SLAAC as DHCP alternatives
- Ports and NAT - How DHCP-assigned devices communicate through NAT
- Networking Labs - Hands-on DHCP configuration exercises
- Transport Protocols - UDP transport used by DHCP
Try It Yourself: DHCP Troubleshooting Lab
Exercise: A sensor network has sporadic connectivity issues. Diagnose using DHCP logs.
Given:
- Network: 192.168.10.0/24
- DHCP pool: 192.168.10.50 - 192.168.10.150 (100 addresses)
- Devices: 85 sensors deployed
- Symptom: Random sensors lose connectivity every few days
Task 1: Analyze DHCP Lease Log
| Log Entry | IP | MAC | Lease Status |
|---|---|---|---|
| sensor-42 | 192.168.10.75 | 24:0A:C4:12:34:56 | Expires in 1 hour |
| sensor-99 | 192.168.10.75 | DC:A6:32:AB:CD:EF | Expires in 59 minutes |
What’s wrong? Two different sensors have been assigned the same IP (192.168.10.75).
Task 2: Check ARP Cache
| ARP Cache IP | MAC Address | Meaning |
|---|---|---|
| 192.168.10.75 | 24:0A:C4:12:34:56 | Sensor-42 is claiming this IP |
| 192.168.10.75 | DC:A6:32:AB:CD:EF | Sensor-99 is also claiming this IP |
Diagnosis: ARP table shows IP conflict - same IP mapped to two MACs.
Task 3: Root Cause Check DHCP lease database: - Sensor-42: Has DHCP-assigned IP 192.168.10.75 - Sensor-99: Configured with STATIC IP 192.168.10.75 (not using DHCP)
Solution:
- Change Sensor-99 static IP to 192.168.10.200 (outside DHCP range)
- OR: Configure DHCP reservation for Sensor-99 based on MAC address
- Best practice: Document all static IPs in spreadsheet to prevent future conflicts
Hint: Always separate static IP ranges from DHCP pools. Use 192.168.10.1-49 for static, 192.168.10.50-254 for DHCP.
Solution: Reconfigure Sensor-99 to use DHCP reservation:
| Reservation Field | Value | Why It Matters |
|---|---|---|
| Host label | sensor-99 | Human-readable inventory name |
| MAC address | DC:A6:32:AB:CD:EF | The physical device identifier |
| Reserved IP | 192.168.10.99 | Unique address managed by DHCP |
26.12 Review: Match DHCP Concepts to Descriptions
26.13 Review: DHCP Address Assignment Sequence
26.14 Label the Diagram
26.15 Code Challenge
26.16 Summary
- DHCP automates IP assignment using the DORA process (Discover, Offer, Request, Acknowledge), saving hours of manual configuration
- Lease times should match device mobility: 7-30 days for fixed sensors, hours for mobile devices
- DHCP options provide additional configuration: gateway (option 3), DNS (option 6), NTP (option 42)
- DHCP reservations combine automatic management with predictable addresses by mapping MAC addresses to specific IPs
- ARP resolves IPv4 addresses to MAC addresses via broadcast queries, with results cached to reduce traffic
- IPv6 Neighbor Discovery improves on ARP with multicast, automatic duplicate detection (DAD), and SLAAC
- IP conflicts cause ARP flapping - alternating MAC addresses in ARP cache indicates two devices claiming the same IP
- Subnet mask misconfigurations cause silent routing failures when devices incorrectly determine local vs remote destinations
26.17 What’s Next
Now that you have configured DHCP and analyzed address resolution, continue with related chapters:
| Topic | Chapter | Description |
|---|---|---|
| Addressing Overview | Networking Addressing Index | Return to the main addressing overview covering IP, subnetting, and DHCP together |
| Subnetting | Subnetting and CIDR | Design the subnet boundaries that DHCP pools are built on |
| IPv6 | IPv6 for IoT | Neighbor Discovery and SLAAC as alternatives to DHCP in IPv6 networks |
| NAT | Ports and NAT | How DHCP-assigned private addresses communicate through NAT to the internet |
| Routing | Routing Fundamentals | How routers use DHCP-assigned addressing information to forward packets |
| Labs | Network Labs and Quiz | Hands-on DHCP configuration exercises and troubleshooting challenges |