Sixteen Machines on the Wrong Subnet
A 20-node COPA lab runs Windows 10 with DHCP on the lab router at 192.168.1.1, scope 192.168.1.100 to 192.168.1.150, lease time 8 hours. On Monday at 09:15, sixteen machines hold addresses in the range 192.168.0.101 to 192.168.0.116 and cannot open the shared folder on the instructor's PC at 192.168.1.5; the remaining four machines work normally. Those four had static addresses 192.168.1.11 to 192.168.1.14 set during last week's addressing practical and were never reverted. All 20 switch port LEDs are green and pinging 127.0.0.1 succeeds on every machine. A trainee admits he plugged his personal travel router into wall port P-19 on Friday so his phone could use Wi-Fi, and it is still connected. The batch has a file-sharing assessment in 45 minutes.
1. Explain what has happened, why the four static machines still work, and why the affected machines report 'network connected' yet cannot reach 192.168.1.5.
Read the worked answer
The travel router is acting as a second, unauthorised DHCP server. Its LAN side hands out 192.168.0.x with a /24 mask and itself as gateway, so the sixteen clients that renewed over the weekend took a lease on a different subnet. Link state is genuinely up - the NIC, cable and switch port are all fine - but 'connected' only means Layer 1/2 is alive, not that Layer 3 routing works.
The four static machines kept 192.168.1.11–.14 and therefore remain on the correct subnet with the correct default gateway, so \\192.168.1.5 resolves over the local subnet and succeeds. The sixteen others would need a router to reach 192.168.1.0/24; their gateway is the travel router, which performs NAT to its WAN side and has no route back into the lab subnet in a usable way, so the SMB connection fails or times out.
The diagnostic signature to teach is ipconfig /all: correct-looking media state, wrong subnet, wrong DHCP server address, wrong lease origin. That single screen separates this from a cable fault or a dead switch port.
2. Give the ordered remediation for the next 20 minutes, and state the risk of the trainee suggestion: 'just set static IPs on all twenty machines and start the assessment'.
Read the worked answer
Order matters - remove the cause before repairing the symptom.
- Unplug the travel router from P-19 and take it out of the lab. If left connected, any renewal re-poisons the clients.
- Confirm the legitimate DHCP scope is healthy on 192.168.1.1 (pool not exhausted, service running).
- On each affected machine:
ipconfig /release,ipconfig /renew, thenipconfig /allto verify 192.168.1.100–.150, gateway 192.168.1.1, and the correct DHCP server field. - Verify with
ping 192.168.1.5, then open the share by UNC path, not by a stale mapped drive. - Sweep the other wall ports for a second rogue device before declaring the lab fit.
Why not blanket static addressing: twenty hand-typed addresses invite duplicate-IP conflicts that are harder to find than the original fault and can knock out the four working machines mid-assessment; it also hides the real cause, so the fault returns when leases expire; and it removes central control of the address plan. Static addressing was correct for last week's lesson precisely because it was a lesson - the lab standard is DHCP with reservations for the instructor PC and printers.
3. How would you handle the trainee and convert the incident into a lesson, given the assessment is in 45 minutes?
Read the worked answer
Separate the technical fix from the conduct conversation - do not run both at once in front of a stressed batch.
Now: the trainee helps unplug and re-lease machines under supervision. This is restitution, not reward; it also teaches him the consequence directly. Keep the tone factual and avoid a public lecture.
After the assessment: a short private conversation covering three points - he connected an unapproved device to an institute network; that device could have exposed shared folders or carried malware; and the batch lost practical time. Ask him what he would check before plugging anything into a lab port. Record the conversation as per institute practice rather than improvising a punishment.
For the whole batch (10 minutes, next theory slot): demonstrate a rogue DHCP server with the same travel router on an isolated bench, show ipconfig /all before and after, and introduce three defences - disable unused wall ports or use port security, enable DHCP snooping on managed switches where available, and adopt a simple rule: no personal networking hardware on lab ports. Add a written lab-usage line to the practical record so the rule is documented, not just spoken.