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 Working Code: Python Network Discovery Tools
These Python scripts demonstrate DHCP and ARP concepts with real network operations. Run them on a Raspberry Pi or Linux gateway to discover and manage IoT devices on your local network.
26.6.1 ARP Scanner: Discover All Devices on Your Network
# arp_scanner.py — Discover all devices on a local subnet
# Requirements: pip install scapy
# Run with: sudo python3 arp_scanner.py
from scapy.all import ARP, Ether, srp
import socket
import struct
import fcntl
def get_local_ip(interface="eth0"):
"""Get the IP address of a network interface."""
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
return socket.inet_ntoa(fcntl.ioctl(
s.fileno(), 0x8915, # SIOCGIFADDR
struct.pack('256s', interface.encode()[:15])
)[20:24])
def arp_scan(network="192.168.1.0/24", timeout=3):
"""
Scan a subnet using ARP requests.
Returns list of (IP, MAC) tuples for all responding devices.
"""
# Build ARP request: broadcast Ethernet + ARP who-has
arp_request = ARP(pdst=network)
broadcast = Ether(dst="ff:ff:ff:ff:ff:ff")
packet = broadcast / arp_request
# Send and collect responses
answered, _ = srp(packet, timeout=timeout, verbose=False)
devices = []
for sent, received in answered:
devices.append({
"ip": received.psrc,
"mac": received.hwsrc,
"oui": received.hwsrc[:8].upper() # First 3 octets = manufacturer
})
return sorted(devices, key=lambda d: socket.inet_aton(d["ip"]))
# Common IoT manufacturer OUI prefixes
IOT_OUIS = {
"24:0A:C4": "Espressif (ESP32/ESP8266)",
"B4:E6:2D": "Espressif (ESP32)",
"DC:4F:22": "Espressif (ESP8266)",
"A4:CF:12": "Espressif (ESP32-S2)",
"00:1E:C0": "Microchip Technology",
"F0:08:D1": "Sonos",
"B0:CE:18": "Philips Hue",
"D0:73:D5": "TP-Link (Kasa Smart)",
}
if __name__ == "__main__":
print("Scanning network for IoT devices...")
devices = arp_scan("192.168.1.0/24")
print(f"\nFound {len(devices)} devices:\n")
print(f"{'IP Address':<18} {'MAC Address':<20} {'Manufacturer'}")
print("-" * 60)
for d in devices:
manufacturer = IOT_OUIS.get(d["oui"], "Unknown")
print(f"{d['ip']:<18} {d['mac']:<20} {manufacturer}")
# What to observe:
# - ESP32 devices show OUI 24:0A:C4 or B4:E6:2D
# - Each ARP response = one active device on the subnet
# - Devices in sleep mode (PSM) may not respond to ARP
# - Run periodically to detect new/rogue devices joining the network26.6.2 DHCP Lease Monitor: Track Device Connections
# dhcp_monitor.py — Monitor DHCP lease assignments in real time
# Works with ISC DHCP server lease file on Linux gateways
import os
import time
from datetime import datetime
LEASE_FILE = "/var/lib/dhcp/dhcpd.leases" # Standard ISC DHCP path
def parse_leases(filepath):
"""Parse ISC DHCP lease file into structured records."""
leases = {}
current_lease = None
if not os.path.exists(filepath):
print(f"Lease file not found: {filepath}")
return leases
with open(filepath, "r") as f:
for line in f:
line = line.strip()
if line.startswith("lease "):
current_lease = {"ip": line.split()[1]}
elif current_lease:
if "hardware ethernet" in line:
current_lease["mac"] = line.split()[-1].rstrip(";")
elif "ends" in line and "never" not in line:
parts = line.split()
current_lease["expires"] = f"{parts[2]} {parts[3].rstrip(';')}"
elif "client-hostname" in line:
current_lease["hostname"] = line.split('"')[1]
elif line == "}":
leases[current_lease["ip"]] = current_lease
current_lease = None
return leases
def check_lease_health(leases):
"""Flag potential issues in DHCP assignments."""
issues = []
mac_to_ips = {}
for ip, lease in leases.items():
mac = lease.get("mac", "unknown")
if mac in mac_to_ips:
mac_to_ips[mac].append(ip)
else:
mac_to_ips[mac] = [ip]
# Detect duplicate MACs (same device getting multiple IPs)
for mac, ips in mac_to_ips.items():
if len(ips) > 1:
issues.append(f"WARNING: MAC {mac} has {len(ips)} leases: {ips}")
return issues
if __name__ == "__main__":
leases = parse_leases(LEASE_FILE)
print(f"Active DHCP Leases: {len(leases)}\n")
for ip, info in sorted(leases.items()):
hostname = info.get("hostname", "unknown")
mac = info.get("mac", "unknown")
expires = info.get("expires", "unknown")
print(f" {ip:<16} {mac:<20} {hostname:<20} expires: {expires}")
issues = check_lease_health(leases)
if issues:
print(f"\nHealth Issues ({len(issues)}):")
for issue in issues:
print(f" {issue}")
# What to observe:
# - Each IoT device gets one lease entry with IP, MAC, hostname
# - Short lease times (1h) cause frequent renewals = more DHCP traffic
# - Duplicate MAC entries suggest device connectivity issues
# - Missing hostnames indicate devices not sending option 1226.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):
# 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
Steps:
Verify the ARP table on the gateway:
$ arp -a 192.168.10.45 24:0A:C4:12:34:56 dynamic (Sensor A - correct) 192.168.10.45 24:0A:C4:78:9A:BC dynamic (Sensor B - CONFLICT!) 192.168.10.67 (incomplete)Analyze the root cause:
Sensor B's ARP entry shows 192.168.10.45, but DHCP assigned .67 Diagnosis: Sensor B has a statically configured IP that conflicts with Sensor A's DHCP-assigned address.Verify by pinging and checking ARP changes:
$ ping 192.168.10.45 Reply from 192.168.10.45: bytes=32 time<1ms (MAC: 24:0A:C4:12:34:56) Reply from 192.168.10.45: bytes=32 time<1ms (MAC: 24:0A:C4:78:9A:BC) ARP table alternates between two MACs - confirmed IP conflict!Resolve the conflict:
- Option A: Reconfigure Sensor B to use DHCP
- Option B: Create DHCP reservation for both sensors
- Option C: Assign static IPs outside DHCP range
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)
Device A's subnet calculation:
- 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: 192.168.1.0 ≠ 192.168.2.0 → "Different network, send to gateway"Problem case: Device A configured with wrong mask /16:
Device A's (incorrect) subnet calculation:
- My IP: 192.168.1.50
- My mask: 255.255.0.0 (/16) ← WRONG
- My network: 192.168.0.0
- Target: 192.168.2.100
- Target AND mask: 192.168.0.0
- Result: 192.168.0.0 = 192.168.0.0 → "Same network, send directly via 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
# Sample DHCP server log
192.168.10.75 lease to sensor-42 (MAC: 24:0A:C4:12:34:56) expires in 1 hour
192.168.10.75 lease to sensor-99 (MAC: DC:A6:32:AB:CD:EF) expires in 59 minutesWhat’s wrong? Two different sensors have been assigned the same IP (192.168.10.75).
Task 2: Check ARP Cache
$ arp -a
192.168.10.75 24:0A:C4:12:34:56 dynamic
192.168.10.75 DC:A6:32:AB:CD:EF dynamicDiagnosis: 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:
host sensor-99 {
hardware ethernet DC:A6:32:AB:CD:EF;
fixed-address 192.168.10.99; # Unique address in DHCP range
}26.12 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.13 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 |