First, the essential ideas
- DHCPv4
- Dynamic Host Configuration Protocol for IPv4 supplies an address and related settings for a limited lease time. It does not carry the later web application traffic.
- Client, server and relay
- A client asks for settings. A server chooses and records a lease. A relay forwards DHCP messages between the client's local network and a server on another network.
- Subnet and gateway
- A /24 subnet uses mask 255.255.255.0. Hosts in 192.0.2.0/24 use 192.0.2.1 here as their gateway, the next router for other networks.
- Broadcast and unicast
- A broadcast addresses the local broadcast domain. A unicast addresses one destination. An ordinary routed interface does not forward the client's initial local broadcast into another subnet.
- Pool, exclusion and binding
- A pool describes assignable settings for a subnet. An exclusion reserves addresses against dynamic allocation. A binding records a particular client's assigned address and lease.
- DORA
- Discover seeks a server, Offer proposes settings, Request identifies the selected offer, and Acknowledge confirms the lease. Renewal is not necessarily this complete four-message exchange.
- UDP and giaddr
- User Datagram Protocol uses numbered application ports: DHCP clients use 68 and servers use 67. The DHCP gateway-address field, giaddr, lets the relay identify the client's subnet to the server.
- Console and IOS modes
- The GNS3 Console is the node's text window. > is user EXEC, # is privileged EXEC, (config)# is global configuration and (config-if)# selects an interface. Type commands without these prompts.
- Baseline, fault and rollback
- Record working settings and actual tests first. A safe fault changes one known item only in this disposable lab. Rollback restores that item and repeats the original test.
- Lease renewal
- A client asks to extend a lease before expiry. It can continue using a still-valid lease while a new broadcast path is broken, so an existing address is not proof that new allocation works.
Read the three roles separately before following the cables. Client1 is a router used as a DHCP client, Relay1 is its gateway, and Server1 runs the DHCP service. All result statements below are predictions to compare with your own observations, not recorded executions.
See the idea
DHCP crosses a router through a relay
The helper carries the request; the pool matches the client subnet; the reply must reach the client.
Ask from the client LAN
Client1 has no static address. Relay1 receives the initial local request on its client-facing interface.
What this model leaves out: Conceptual initial DHCP exchange on the two lab cables. Broadcast and unicast details vary by client state. This is not a capture, and existing leases may survive a relay fault.
Full visual explanation and references
Client1 sends through Relay1 to Server1. Server1 selects a client-subnet lease, and its response returns through Relay1 to Client1.
Conceptual initial DHCP exchange on the two lab cables. Broadcast and unicast details vary by client state. This is not a capture, and existing leases may survive a relay fault.
- Ask from the client LAN
Client1 has no static address. Relay1 receives the initial local request on its client-facing interface.
www.cisco.comwww.rfc-editor.org - Select the right pool
Relay1 forwards toward Server1 and identifies the client subnet. Server1 chooses from 192.0.2.0/24, not the transit subnet.
www.cisco.comwww.cisco.com - Return to Client1
The server response returns through Relay1 to Client1. Check the confirmed client lease and matching server binding after the exchange.
www.rfc-editor.org
One idea at a time
Start with something familiar.
Begin with the address table and label each cable endpoint. A router can be a DHCP client on one interface; its device type does not force it to be the server. Keep every Console open so losing a lease cannot remove your control.
Why learn this?
An address assignment problem can stop work before a user can even reach a gateway. Changing a server pool blindly may miss a broken relay or return route and can introduce duplicate addressing.
An everyday comparison
A reception desk can temporarily assign a numbered locker. A messenger can carry a request from a different floor, while stating which floor needs the locker.
What happens in a network
The temporary assignment resembles a lease; the floor identifier resembles the relay's client-subnet information. The desk's list resembles the server binding record.
Where the comparison stopsThe analogy does not define packet destinations, timers or trust. A relay is not an approval authority, and receiving settings does not prove that a server is legitimate.
Follow one worked example
- Identify the subnet that needs an address.
Client1 has no static address on GigabitEthernet1. Relay1's attached interface is 192.0.2.1/24, so Server1 must offer from the 192.0.2.0/24 pool.
Why: The server-facing transit subnet is not the subnet from which this client should receive a lease.
- Carry the request to the remote service.
The helper on Relay1 GigabitEthernet1 targets Server1 at 198.51.100.2. Server1 uses relay information and its configured pool to choose appropriate settings.
Why: A route alone does not carry the initial local DHCP broadcast across the router.
- Inspect both ends of the assignment.
Read Client1's address and lease, then compare Server1's binding and pool. Test Client1 to 192.0.2.1 and 198.51.100.2.
Why: A server record and a client configuration are complementary evidence, not interchangeable claims.
- Break only fresh acquisition, then restore it.
Remove the helper and remove/reapply DHCP on Client1. Compare acquisition with the working baseline, restore the helper and repeat the same process.
Why: An already valid lease or unicast renewal can hide the missing initial broadcast relay.
Your first small task
On paper, write Client1 beside 192.0.2.0/24, Relay1 beside 192.0.2.1 and Server1 beside 198.51.100.2. Circle which interface receives the client's broadcast and which subnet belongs in the server pool.
Show a hint
Choose the client's network, even though the server has its own interface address on a different network.
Check the expected result
The client-facing Relay1 GigabitEthernet1 receives the broadcast. The pool is 192.0.2.0/24, not the 198.51.100.0/30 transit link.
Pause and explain it in your own words
A client still has an address after the helper is removed. Does that prove the helper was unnecessary?
Show a hint
Ask whether the address was acquired before or after the change and whether its lease is still valid.
Show the explanation
No. Existing lease state can remain valid, and renewal may use unicast. To evaluate the initial relay path, record the baseline and deliberately start a fresh acquisition on this isolated test client.
Short answer
What should you understand today?
DHCPv4 leases an address and options to a client. A relay on the client-facing router interface forwards requests to a remote server and identifies the client subnet. Successful allocation needs the client, correct pool, available addresses and both routed directions. An old lease can remain usable after relay failure, so test a fresh acquisition as well as inspecting existing settings.
Before you begin
Learning targets
- Recall that /24 means 255.255.255.0 and different subnets need routing.
- Practice Day 15 Console access and Day 31 static routes before changing this isolated project.
- Use three independently entitled C8000v IOS XE 17.12.1a instances in GNS3 2.2.55, or use the paper alternative.
- Trace Discover, Offer, Request and Acknowledge without assuming every message is broadcast.
- Configure the IOS DHCP client, an excluded address range, a server pool and a client-facing relay.
- Verify lease state, pool availability, helper placement and the return route.
- Compare a missing-helper fault with wrong client settings and exhausted or mismatched pools.
- Restore the known helper and reacquire a lease without clearing unrelated bindings.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
DHCPv4
Dynamic Host Configuration Protocol for IPv4 supplies an address and related settings for a limited lease time. It does not carry the later web application traffic.
Client, server and relay
A client asks for settings. A server chooses and records a lease. A relay forwards DHCP messages between the client's local network and a server on another network.
Subnet and gateway
A /24 subnet uses mask 255.255.255.0. Hosts in 192.0.2.0/24 use 192.0.2.1 here as their gateway, the next router for other networks.
Broadcast and unicast
A broadcast addresses the local broadcast domain. A unicast addresses one destination. An ordinary routed interface does not forward the client's initial local broadcast into another subnet.
Pool, exclusion and binding
A pool describes assignable settings for a subnet. An exclusion reserves addresses against dynamic allocation. A binding records a particular client's assigned address and lease.
DORA
Discover seeks a server, Offer proposes settings, Request identifies the selected offer, and Acknowledge confirms the lease. Renewal is not necessarily this complete four-message exchange.
UDP and giaddr
User Datagram Protocol uses numbered application ports: DHCP clients use 68 and servers use 67. The DHCP gateway-address field, giaddr, lets the relay identify the client's subnet to the server.
Console and IOS modes
The GNS3 Console is the node's text window. > is user EXEC, # is privileged EXEC, (config)# is global configuration and (config-if)# selects an interface. Type commands without these prompts.
Baseline, fault and rollback
Record working settings and actual tests first. A safe fault changes one known item only in this disposable lab. Rollback restores that item and repeats the original test.
Lease renewal
A client asks to extend a lease before expiry. It can continue using a still-valid lease while a new broadcast path is broken, so an existing address is not proof that new allocation works.
One service, three different responsibilities
DHCP separates asking, assigning and forwarding. The client requests configuration; the server owns its pool and lease decisions; a relay carries messages across a routed boundary. The server's address is not the client's gateway merely because it supplied settings. In this lab the remote server is 198.51.100.2, but the client's gateway is the locally reachable 192.0.2.1.
- DHCP configures an interface; it does not create every required route.
- A router can perform a client role, a server role or a relay role.
DORA is a starting exchange, not every DHCP packet
During initial selection, Discover finds servers, Offer proposes a lease, Request identifies the chosen offer and Acknowledge confirms it. A client can hear multiple offers. Do not treat Offer alone as completed allocation. UDP ports identify the DHCP applications, not physical cable ports. Whether replies use broadcast or unicast depends on client state, flags and the relay path.
- Inspect transaction state rather than assuming every message is a broadcast.
- DHCP does not encrypt its ordinary address offers or prove server identity.
Pool selection must match the client, not the server cable
An IOS server pool declares a network and its mask. The excluded range keeps infrastructure addresses from dynamic assignment. Relay information tells the server which remote subnet is involved; a nonzero giaddr commonly supplies the client-facing relay address. The server also needs a route back toward that address. Pool naming is local organization, not a VLAN or a routing command.
- Exclusions, active bindings and conflicts affect availability differently.
- A pool for 198.51.100.0/30 would describe the transit network, not this client LAN.
Build both directions before judging the service
Relay1 has a connected route to each cable network. Server1 needs an explicit route to 192.0.2.0/24 via 198.51.100.1. Put ip helper-address on the interface receiving client broadcasts, not reflexively on the server-facing interface. On IOS the helper can forward additional UDP services; this isolated exercise is not a production hardening policy.
- Configuration syntax, service state and tested behavior are separate evidence.
- Keep service dhcp enabled on the server and relay in this lab.
Diagnose client, relay and server faults independently
Start with the client's interface state and whether DHCP is configured. Then inspect the relay's client-facing address, helper destination and routes. Finally inspect server pools, bindings and conflicts. A missing address is a symptom, not a verdict against the server. An address conflict should be investigated before any record is cleared; deleting a warning does not remove the duplicate host.
- Never clear every production lease to test one classroom client.
- Record the actual address, client identifier, time and commands accepted.
State coverage and the limit of a successful lease
CCNA v1.1 remains current through 2 February 2027; announced v2.0 starts 3 February 2027. This lesson addresses the DHCP portion of v1.1 4.3 and client/relay practice in 4.6. Server setup also supports v2.0 1.7 troubleshooting. These are authored exercises, not proof the learner executed every outcome or covered DNS, which is next.
- Inspect lease contents and connectivity rather than calling any address success.
- Use the coverage record and assessment pointers, not a domain title, to track learning.
Real-world walkthrough
Old clients work while new clients cannot join
In a fictional branch, already connected devices still reach an internal service, but a new client receives no lease. A recent change removed the helper from the client-facing interface. Existing leases make the network look healthy during a quick inspection. The operator must separate retained state from a fresh service transaction.
- Ask when each client acquired its lease and record the affected subnet. Do not use the oldest working client as the sole service test.
- Inspect the client-facing interface and compare its helper destination with the approved baseline. Keep the management console available.
- Confirm the server pool contains available addresses for that subnet and has a return route toward the relay's client-facing address.
- Restore only the approved helper line, then run a fresh acquisition on the disposable test client and compare both endpoint records.
- Verify gateway and server reachability separately. Record any remaining DNS or application issue as a separate investigation rather than expanding the DHCP conclusion.
Guided GNS3 lab
Three IOS roles and one missing-helper fault
Configure Client1, Relay1 and Server1, obtain a lease, remove one helper, observe fresh-acquisition behavior, and restore it. All expected results are predictions. Authoring performed source and structural checks, not IOS execution.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| Client1 | GigabitEthernet1 | DHCP: 192.0.2.101-254/24 | Client lease; actual host address is not predetermined. |
| Relay1 | GigabitEthernet1 | 192.0.2.1/24 | Client gateway and relay-facing address. |
| Relay1 | GigabitEthernet2 | 198.51.100.1/30 | Server transit link. |
| Server1 | GigabitEthernet1 | 198.51.100.2/30 | DHCP server and helper destination. |
Set up the lab
- Use GNS3 2.2.55 and three fresh, independently entitled C8000v 17.12.1a instances with these exact ports. Stop if the available image differs; adapt only using its official documentation.
- Create the two listed links and start the three nodes. Decline an initial configuration dialog on disposable nodes. Do not import employer configurations.
- Capture clean-project snapshots and keep all three Consoles open. Use no external network adapters; a DHCP server must never leak into a shared LAN.
- Paper alternative: draw the address table, simulate the DORA messages and diagnose the three fault cases. Mark every result predicted; no Cisco image execution is implied.
Inspect the clean relay
In GNS3, right-click Relay1 and choose Console before typing. Start at > or # and inspect the device before making changes. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
enable
show version
show ip interface brief
show running-configWhat each command means
enable- Enter privileged EXEC (#) from user EXEC (>); use only your authorized lab credentials.
show version- Record the actual platform and IOS XE release; compare it with the reference image.
show ip interface brief- Inspect interface names, addresses and line/protocol states before connecting the configured roles.
show running-config- Record the clean baseline privately; stop if unexpected configuration or secrets appear.
- What you should see
- The recorded ports match the topology; no existing service is overwritten.
- Why this step matters
- The change is interpretable only when image, interfaces and initial configuration are known.
Address both relay interfaces
In GNS3, right-click Relay1 and choose Console before typing. Start at #. Configure the client side first, then the transit side. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
interface GigabitEthernet1
ip address 192.0.2.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet2
ip address 198.51.100.1 255.255.255.252
no shutdown
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select the exact port cabled to Client1 GigabitEthernet1.
ip address 192.0.2.1 255.255.255.0- Set the client subnet gateway using the /24 dotted-decimal mask.
no shutdown- Enable the selected client-facing interface.
exit- Return from interface configuration to global configuration.
interface GigabitEthernet2- Select the port cabled to Server1 GigabitEthernet1.
ip address 198.51.100.1 255.255.255.252- Set the relay transit address with a /30 mask.
no shutdown- Enable the server-facing transit interface.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- Both planned addresses appear on the correct interfaces once peers are enabled.
- Why this step matters
- Reversing these addresses would change relay subnet identification and break the planned route.
Address the server and return route
In GNS3, right-click Server1 and choose Console before typing. Start at > or #; Server1 must route replies back to the client subnet. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
enable
configure terminal
interface GigabitEthernet1
ip address 198.51.100.2 255.255.255.252
no shutdown
exit
ip route 192.0.2.0 255.255.255.0 198.51.100.1
endWhat each command means
enable- Enter privileged EXEC (#) from user EXEC (>); use only your authorized lab credentials.
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select the server port cabled to Relay1 GigabitEthernet2.
ip address 198.51.100.2 255.255.255.252- Configure Server1's directly connected transit address.
no shutdown- Enable the selected server interface.
exit- Return to global configuration before entering a route.
ip route 192.0.2.0 255.255.255.0 198.51.100.1- Route the client /24 toward Relay1's adjacent transit address.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- Server1 has a connected transit route and a static route toward the client LAN.
- Why this step matters
- A server can receive a relayed request yet fail to deliver its reply if its return routing is wrong.
Create a bounded address pool
In GNS3, right-click Server1 and choose Console before typing. Start at #. Reserve infrastructure addresses and define client settings. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
service dhcp
ip dhcp excluded-address 192.0.2.1 192.0.2.100
ip dhcp pool CLIENTS
network 192.0.2.0 255.255.255.0
default-router 192.0.2.1
lease 0 1
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
service dhcp- Enable the IOS DHCP service; this is not a client address command.
ip dhcp excluded-address 192.0.2.1 192.0.2.100- Exclude the inclusive range .1 through .100 from dynamic allocation.
ip dhcp pool CLIENTS- Create the local pool named CLIENTS and enter DHCP pool mode.
network 192.0.2.0 255.255.255.0- Select the client's /24 network, not the server transit subnet.
default-router 192.0.2.1- Offer Relay1's local client-facing address as the gateway.
lease 0 1- Set a one-hour lease: zero days and one hour.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- CLIENTS describes 192.0.2.0/24 with excluded infrastructure addresses and the correct gateway.
- Why this step matters
- The pool needs explicit values a beginner can compare with the plan; this lab deliberately offers no DNS service.
Enable the client-side relay
In GNS3, right-click Relay1 and choose Console before typing. Start at #. Apply the helper where Client1's initial broadcast arrives. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
service dhcp
interface GigabitEthernet1
ip helper-address 198.51.100.2
end
ping 198.51.100.2What each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
service dhcp- Enable DHCP relay/server functionality on this clean lab router.
interface GigabitEthernet1- Choose the interface receiving broadcasts from Client1.
ip helper-address 198.51.100.2- Forward supported UDP broadcasts, including DHCP, toward this exact server address.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
ping 198.51.100.2- Test Relay1's IP reachability to Server1 before testing DHCP.
- What you should see
- The helper is on GigabitEthernet1, and Server1 should respond to the transit ping.
- Why this step matters
- A helper on the wrong interface cannot receive the intended local client broadcast.
Request a lease on an IOS client
In GNS3, right-click Client1 and choose Console before typing. Start at > or #. Do not assign a static address to this interface. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
enable
configure terminal
interface GigabitEthernet1
ip address dhcp
no shutdown
end
show dhcp lease
show ip interface briefWhat each command means
enable- Enter privileged EXEC (#) from user EXEC (>); use only your authorized lab credentials.
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select Client1's only cabled interface toward Relay1.
ip address dhcp- Ask DHCP to supply the interface address and supported options.
no shutdown- Enable the client interface so it can transmit requests.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
show dhcp lease- Inspect the actual acquired lease, server and timing; do not invent the assigned address.
show ip interface brief- Compare the leased address with the planned subnet and interface status.
- What you should see
- A lease in the available 192.0.2.0/24 range should appear after exchange and address checks.
- Why this step matters
- Using an IOS client explicitly practices client configuration instead of assuming an endpoint has already done it.
Record server and traffic baseline
In GNS3, right-click Server1 and choose Console before typing. Start at #. Capture pool, binding and route evidence before any fault. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
show ip dhcp pool
show ip dhcp binding
show ip dhcp conflict
show ip route 192.0.2.0What each command means
show ip dhcp pool- Inspect available and allocated pool capacity; do not infer exhaustion from one failed client.
show ip dhcp binding- Record the actual client identifier, assigned address and lease expiry.
show ip dhcp conflict- Inspect addresses marked conflicting without clearing them.
show ip route 192.0.2.0- Check that the client subnet's route points toward 198.51.100.1.
- What you should see
- Server1's binding agrees with Client1's observed lease and the return route is present.
- Why this step matters
- A lease record alone does not prove the client applied the offer or that the remote path works.
Test the leased client's path
In GNS3, right-click Client1 and choose Console before typing. Start at #. Stop here if there is no lease or the subnet is wrong. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
ping 192.0.2.1
ping 198.51.100.2What each command means
ping 192.0.2.1- Test the local gateway from the leased interface.
ping 198.51.100.2- Test the remote DHCP server using the client's learned gateway and the server return route.
- What you should see
- Both tests should receive replies after initial address discovery; record actual results.
- Why this step matters
- This provides a working baseline distinct from the mere presence of server configuration.
Remove exactly one helper
In GNS3, right-click Relay1 and choose Console before typing. Start at # only after the working lease and pings were recorded. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
interface GigabitEthernet1
no ip helper-address 198.51.100.2
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select the same client-facing relay interface as before.
no ip helper-address 198.51.100.2- Remove only the known DHCP server helper destination.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- The helper line is absent, but both physical interfaces remain enabled.
- Why this step matters
- This changes the initial broadcast forwarding dependency without changing the pool, routes or cables.
Test fresh acquisition after the fault
In GNS3, right-click Client1 and choose Console before typing. Start at #. First note the existing lease. Removing and reapplying DHCP is allowed only on this disposable client. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
show dhcp lease
configure terminal
interface GigabitEthernet1
no ip address dhcp
ip address dhcp
end
show dhcp leaseWhat each command means
show dhcp lease- Record retained state before forcing a new acquisition attempt.
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select only the lab client's DHCP interface.
no ip address dhcp- Remove DHCP address acquisition from this interface and its current DHCP-derived address state.
ip address dhcp- Restart DHCP acquisition on the same enabled interface.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
show dhcp lease- Inspect whether a new lease was obtained; distinguish old display state from a new acknowledged lease.
- What you should see
- Fresh acquisition should not complete through the removed helper. A retained lease before reset is not a contrary result.
- Why this step matters
- If the test still succeeds, inspect alternate helpers, duplicate servers, client state and actual requests instead of manufacturing failure.
Restore the relay baseline
In GNS3, right-click Relay1 and choose Console before typing. Start at #. Restore the one line removed; leave all other settings unchanged. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
interface GigabitEthernet1
ip helper-address 198.51.100.2
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Return to the original client-facing interface.
ip helper-address 198.51.100.2- Restore the exact server destination used by the working baseline.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- The original helper destination is present again on the original interface.
- Why this step matters
- Rollback is a known inverse in this lab, not a broad reset of DHCP services or router configuration.
Reacquire and close the experiment
In GNS3, right-click Client1 and choose Console before typing. Start at #. Repeat acquisition after restoration, then inspect Server1 with the earlier baseline commands. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
interface GigabitEthernet1
no ip address dhcp
ip address dhcp
end
show dhcp lease
ping 192.0.2.1
ping 198.51.100.2What each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select the same test client interface for a comparable acquisition.
no ip address dhcp- Remove the test client's existing DHCP configuration before restarting it.
ip address dhcp- Request an address again through the restored relay path.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
show dhcp lease- Record the newly observed lease and server rather than assuming the original address returns.
ping 192.0.2.1- Retest the exact gateway used in the baseline.
ping 198.51.100.2- Retest the exact remote server destination used in the baseline.
- What you should see
- A valid lease and the original reachability tests should recover; compare with Server1's binding.
- Why this step matters
- Successful retest supports this particular repair; DNS, applications and actual production reliability remain unmeasured.
Verify
- Record actual image releases, both cables, client lease and server binding; never substitute the guide's predicted values for output.
- Check pool CLIENTS, exclusion range, correct default-router and Server1's return route to 192.0.2.0/24.
- Show that fresh acquisition differs with the helper absent and restored while addresses and cables remain unchanged.
- Repeat Client1's gateway and remote server pings after rollback and label any initial discovery loss.
- State explicitly that no DNS, Internet, redundancy, encryption or other operating-system client behavior was tested.
Troubleshoot
- No client lease: inspect interface status and ip address dhcp, then helper placement, service dhcp, pool subnet and free addresses before blaming the server.
- Binding exists but remote ping fails: compare the leased gateway and Server1's return route; DHCP success cannot repair a routing fault.
- Missing-helper test still succeeds: check retained client state, duplicate servers and extra helper lines. Preserve evidence rather than broadening the fault.
- Conflicting address: locate and remove the unauthorized duplicate in this isolated project before clearing a specific conflict; never clear a whole shared server database.
GNS3 does not provide Cisco software images. Use Cisco images only when the applicable license or entitlement permits this environment. Do not share or redistribute image files. Cisco Modeling Labs is an official alternative; its supplied reference images are licensed for CML, not automatically for export to GNS3. Use the labeled paper alternative when authorized software is unavailable. No emulator execution is claimed by this lesson.
- Restore the helper and retain the final successful lease evidence; stop all three nodes after the exercise.
- To return to a completely clean state, discard this disposable project or revert the prelab snapshots. Do not merge an old startup configuration as a claimed universal rollback.
Practice set
Answer before you reveal
01Which subnet belongs in the remote server's pool?
The server transit address is not the client's network. The relay identifies the client-facing subnet, allowing a matching pool to be selected.
02Why can an old client work after a helper is removed?
The initial broadcast exchange and later client traffic are different operations. An existing lease or unicast renewal can hide a broken new-allocation path.
03Does an Offer prove the client has a confirmed lease?
An offer is a proposal. Multiple servers can offer settings, so the final accepted lease must be checked on the client and compared with server state.
04What keeps the gateway address out of this dynamic pool?
Infrastructure addressing must not be leased to an unrelated client. The pool name alone imposes no such restriction.
05Which route is required on Server1?
The server's directly connected transit subnet does not include the relay's client-facing address or the assigned client address.
06Does a successful server ping prove name resolution?
The test used a numeric address. DNS answers, web responses and secure server identity require their own tests and cannot be inferred from an ICMP reply.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- DHCP client, server and relay are roles, not fixed device categories.
- A relay identifies the client subnet and requires a routed return path.
- Exclude infrastructure addresses and inspect actual pool capacity.
- A valid existing lease can mask a broken initial acquisition path.
- Verify the lease, the gateway and the remote destination separately.
- Keep predicted lab results distinct from actual observations.