> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # DHCP and DNS on Cisco Networks: Roles, Relay, and ip helper-address - URL: https://www.pinglabz.com/dhcp-and-dns-cisco/ - Published: 2026-07-10T23:18:04.000Z - Updated: 2026-08-24T09:42:32.000Z - Description: DHCP discovery is broadcast and routers do not forward broadcasts, yet central DHCP servers work fine. This article builds server, relay, and client on three IOS XE routers and shows how ip helper-address makes relay work, reading state on all three. - Author: Jaime - Tags: IP Services, Fundamentals, CCNA, #Import 2026-08-01 19:54 DHCP hands a host its network identity; DNS makes names usable instead of addresses. The CCNA asks you to keep their roles straight and to configure a router as a DHCP server and relay, and the relay part is where real understanding shows: DHCP discovery is broadcast, routers do not forward broadcasts, and yet every enterprise runs central DHCP servers several hops away from their clients. This article builds that exact scenario on real Cisco IOS XE (server on R1, relay on R2, client on R3) and reads the state on all three, as part of the [IP Services complete guide](https://www.pinglabz.com/ip-services/). ## DHCP vs DNS: Two Jobs, Often Confused **DHCP** Leases network configuration to hosts: IP address, mask, default gateway, DNS server addresses, domain name. UDP 67 (server) / 68 (client). A host uses it once at attach time and at renewals. **DNS** Resolves names to addresses (and back) on demand: UDP/TCP 53\. A host uses it constantly, for nearly every connection it opens. The link between them: one of the most important options DHCP hands out is *which DNS servers to use*. Get the DHCP pool's `dns-server` option wrong and every client on that subnet "has no internet" even though routing is perfect (nothing resolves). ## DORA, and What the Relay Actually Does A fresh client finds a server with four messages: Discover, Offer, Request, Ack. Discover and Request are broadcasts (the client has no address yet, and may not even know the server). Broadcasts die at the router, so on any subnet without a local DHCP server you configure the router's LAN interface as a **relay agent** with `ip helper-address`. The relay picks up the broadcast, stamps the receiving interface's address into the packet's `giaddr` (gateway address) field, and forwards it as *unicast* to the server. The server uses giaddr to pick the right pool, and replies unicast back to the relay, which delivers the answer to the client's LAN. ## The Lab: Server, Relay, Client on Three Routers R1 is the central DHCP server, two hops from the client LAN (10.0.40.0/24). Its pool: ``` ip dhcp excluded-address 10.0.40.1 10.0.40.9 ip dhcp pool LAN40 network 10.0.40.0 255.255.255.0 default-router 10.0.40.1 dns-server 192.168.99.100 domain-name pinglabz.lab ``` R2 owns the client LAN and relays toward R1 (1.1.1.1 is R1's loopback, reachable via OSPF): ``` R2#show run interface Ethernet0/3 interface Ethernet0/3 description LAN40-DHCP-RELAY ip address 10.0.40.1 255.255.255.0 ip helper-address 1.1.1.1 end ``` R3 plays the client with `ip address dhcp` on its interface. Now the state on all three, starting with the client: ``` R3#show ip interface brief | include Ethernet0/3 Ethernet0/3 10.0.40.10 YES DHCP up up R3#show dhcp lease | include IP|Lease|serv Temp IP addr: 10.0.40.10 for peer on Interface: Ethernet0/3 DHCP Lease server: 10.0.12.1, state: 5 Bound Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs ``` Method `DHCP`, state `Bound`, and the three timers every DHCP client runs: renew at 50% of the lease (unicast to the original server), rebind at 87.5% (broadcast to any server), expire at 100% (start over with Discover). On the server, the lease appears in the binding table: ``` R1#show ip dhcp binding IP address Client-ID/ Lease expiration Type State Interface Hardware address/ User name 10.0.40.10 0063.6973.636f.2d61. Jul 11 2026 10:38 PM Automatic Active Ethernet0/1 R1#show ip dhcp pool Pool LAN40 : Total addresses : 254 Leased addresses : 1 Excluded addresses : 9 Current index IP address range Leased/Excluded/Total 10.0.40.11 10.0.40.1 - 10.0.40.254 1 / 9 / 254 ``` Notice the binding's Interface column says Ethernet0/1: that is where the *relayed unicast* arrived from R2, proof the broadcast-to-unicast conversion happened. The server statistics show the DORA conversation counters: ``` R1#show ip dhcp server statistics Message Received DHCPDISCOVER 17 DHCPREQUEST 1 Message Sent DHCPOFFER 6 DHCPACK 1 ``` (Seventeen Discovers for one lease? The client started broadcasting at boot, before OSPF had converged and before the relay could reach 1.1.1.1\. Real networks show this pattern after power events, and it is normal: the client retries until the path exists.) ## Beyond the Basic Pool: Reservations, Options, and Conflicts Three pool features come up constantly in real deployments. A **manual binding** (DHCP reservation) pins a specific host to a specific address by its client identifier, giving you the stability of a static address with the central management of DHCP: ``` ip dhcp pool PRINTER-1 host 10.0.40.50 255.255.255.0 client-identifier 0100.1122.3344.55 ``` **Options** carry vendor-specific bootstrap data beyond gateway and DNS. The two you will meet on Cisco networks: option 150 (TFTP server list for IP phones fetching their config) and option 43 (controller addresses for access points joining a [wireless LAN controller](https://www.pinglabz.com/wireless/)). If phones or APs on a subnet will not come up, the pool's options are the first suspect. And **conflicts**: before offering an address, the server pings it; if something answers, the address is quarantined in the conflict table rather than leased. A growing `show ip dhcp conflict` table almost always means someone has been hand-configuring static addresses inside the DHCP range, which is what excluded-address ranges are for. ## The DNS Side on IOS Routers are DNS *clients* too, and the CCNA expects the client-side commands. Point the router at a resolver and let it resolve names in ping/traceroute/logs: ``` ip name-server 192.168.99.100 ip domain lookup ip domain name pinglabz.lab ``` `ip domain lookup` is on by default, which is why a typo at the CLI hangs while the router tries to resolve it as a hostname; many engineers disable it on lab boxes (`no ip domain lookup`, exactly what this lab's base config does) and enable it deliberately where name resolution is wanted. A router can even be a modest DNS server (`ip dns server`) for small sites, though in practice DNS service lives on dedicated infrastructure and the router's job is simply to hand out the right resolver addresses via its DHCP pools. ## The DNS Records a Network Engineer Actually Touches You do not need to run BIND to need DNS literacy. Four record types cover nearly every infrastructure conversation: **A** maps a name to an IPv4 address, **AAAA** to an IPv6 address, **CNAME** aliases one name to another (monitoring dashboards love pointing at CNAMEs so the backend can move), and **PTR** maps an address back to a name. PTR records are the sleeper: reverse lookups are what make your traceroutes readable, your syslog collector display hostnames, and some services (mail, strict SSH configs) actively check them. When the NOC says "traceroute shows weird names," someone's PTR zone is stale, not the routing. On the resolution path itself, remember the client asks a *recursive* resolver (the address DHCP handed out), and that resolver walks the authoritative hierarchy on the client's behalf; caching at every layer is why a DNS change "takes time" (the TTL on the record is the contract). ## Troubleshooting the Chain When a client gets no address, walk the chain in order: is the client actually sending Discovers (interface up, `ip address dhcp` present)? Does the LAN's router interface have the `ip helper-address`? Can the relay reach the server address (ping it *sourced from the client-facing interface*, since that becomes giaddr and the server's replies go there)? Does the server have a pool matching the giaddr subnet, with addresses left in it (`show ip dhcp pool`)? And if the client gets an address but "nothing works," check what came *with* the lease: wrong `default-router` or `dns-server` options break connectivity in ways that look like routing failures. `debug ip dhcp server events` on the server shows each DORA step live when you need the ground truth. ## Key Takeaways DHCP leases identity (address, gateway, DNS servers); DNS resolves names; the exam and real life both hinge on not blurring them. Relay agents (`ip helper-address`) convert client broadcasts to unicasts and stamp giaddr so a central server can serve every subnet, which the lab proved end to end: client Bound at 10.0.40.10, binding on the server two hops away, DORA counters ticking. Excluded ranges protect static addresses, the pool's options matter as much as the addresses, and lease timers (50% renew, 87.5% rebind) explain most "it fixed itself" stories. The rest of the operational services live in the [IP Services complete guide](https://www.pinglabz.com/ip-services/).