One Flat /24 for Three Labs: DHCP Exhaustion, a Rogue Server and a Duplex Mismatch
A government computer institute in a Rajasthan district headquarters has 96 trainee machines in three labs - Lab A 58, Lab B 26, Lab C 12 - plus a server room holding a marks server, a proxy and a shared network printer. The ISP provides one static public IP. The router does NAT and everything hangs off one flat 192.168.1.0/24 network on unmanaged switches daisy-chained from lab to lab. The DHCP scope is 192.168.1.100–192.168.1.200. Three symptoms: (a) from 11 a.m. trainees in Lab C get 'no IP address' or an address of 169.254.x.x while Lab A works normally; (b) a trainer's laptop plugged into a Lab B wall port starts handing out addresses and several machines lose the marks server; (c) after a cable in Lab A was re-terminated by a trainee, that machine negotiates 10 Mbps half duplex and file copies crawl, although the switch port LED is green.
1. Produce a VLSM plan on 192.168.1.0/24 that gives each lab and the server room its own subnet with room to grow. Give subnet, mask, usable range and broadcast for each, and explain how this design prevents symptom (a).
Read the worked answer
Allocate in descending size so the large blocks are not fragmented:
| Segment | Subnet | Mask | Usable | Broadcast |
|---|---|---|---|---|
| Lab A (58, grow to ~60) | 192.168.1.0 | /26 | .1–.62 | .63 |
| Lab B (26, grow to 30) | 192.168.1.64 | /27 | .65–.94 | .95 |
| Lab C (12, grow to 14) | 192.168.1.96 | /28 | .97–.110 | .111 |
| Server room | 192.168.1.112 | /28 | .113–.126 | .127 |
.128–.255 stays free for a Wi-Fi or staff segment. A /26 gives 62 usable addresses for 58 machines, which is tight but correct; if you expect 5 spare, take a /25 for Lab A and shift the rest, which is the better call for a lab that will grow.
Each subnet becomes a VLAN (10, 20, 30, 40) terminated on router subinterfaces or an L3 switch, with one DHCP scope per VLAN and the servers given static addresses outside the pools.
Why (a) happened: one broadcast domain for 96+ machines and one pool of 101 addresses, in which phones, laptops, the printer and the servers all drew leases. By 11 a.m. the pool was empty and Lab C got no OFFER, so Windows self-assigned 169.254.x.x (APIPA). Per-VLAN pools mean Lab C's leases cannot be consumed by Lab A, and a broadcast storm in one lab no longer reaches the others.
2. Diagnose symptom (b) and give two controls, one at the switch and one at the DHCP/service level. Note the constraint that the switches are currently unmanaged.
Read the worked answer
The trainer's laptop is running a DHCP service - Windows Internet Connection Sharing, a 'mobile hotspot', or a virtual machine with a bridged NAT adapter. It answers DISCOVER faster than the real server, so clients take a lease with the laptop as default gateway and DNS, and the marks server becomes unreachable. This is a rogue DHCP server, not a server fault.
Switch control: DHCP snooping with only the uplink toward the real DHCP server configured as trusted; client ports are untrusted and drop OFFER/ACK. Add port security (one MAC per wall port) and disable unused wall ports, so a random laptop cannot join at all. Honest constraint: snooping needs managed switches, so this is a procurement decision, not a configuration one. Interim, cheaper measures are port security on any managed switch in the chain and physically locking patch panels.
DHCP/service control: enable conflict detection on the real DHCP server, and split the scope so each lab has its own pool (from the VLSM plan) - the damage from a rogue server is then confined to one VLAN. Do not rely on MAC filtering as the primary control; it is an inventory job that decays.
Judgement: the durable fix is trusted-port DHCP snooping plus per-VLAN pools; the trainer conversation fixes today only.
3. Diagnose symptom (c) and say what you would actually check and change, including one fix you would reject as harmful.
Read the worked answer
The LED being green only means the link is up at layer 1; it says nothing about duplex. A machine that shows 10 Mbps half duplex after a hand re-termination almost always has a physical fault: wrong pinout order (split pair), a damaged or unterminated pair, a bad RJ-45 crimp, or a cable over 100 m. With only two good pairs, 100BASE-TX cannot run and the PHY falls back to 10BASE-T.
Check in this order: re-test the cable with a wire-map tester for continuity and pinout on all four pairs, inspect the crimp, swap the patch cord and try another switch port, and read the switch interface counters for late collisions, FCS/CRC errors and runts. If the counters climb, the physical layer is the culprit. If the cable tests clean and both ends are auto/auto, suspect a NIC driver or a forced setting on the far end.
Fix: re-terminate to a consistent standard (T568B at both ends), keep the run under 100 m, and leave both ends on auto-negotiation.
Rejected fix: hard-coding the switch port to 100 Mbps full duplex while the PC stays at 10/half (or vice versa). That creates a duplex mismatch, and the resulting late collisions give worse throughput than the original problem, with an interface that still reports 'up'.