APIPA Addresses and an Accidental Loop in the Station LAN
A police station LAN has 12 desktops, one network printer fixed at 192.168.1.50, and a router at 192.168.1.1 running DHCP with a pool of 192.168.1.100 to 192.168.1.150. Last month 8 IP cameras and one NVR were added: the vendor set the cameras to 192.168.1.60 to 192.168.1.67 and the NVR to 192.168.1.68. A second 8-port unmanaged switch was bought and, "for speed", connected to the first switch with two cables. One constable, tired of waiting for a print, set his desktop to a fixed 192.168.1.50. Now three desktops intermittently show 169.254.x.x addresses, two users get an IP address conflict warning, and cameras drop off the NVR for minutes at a time. Everything sits on one flat subnet, nobody recorded which cable goes where, and there is no VLAN-capable switch or spare budget this quarter.
1. Explain the 169.254.x.x addresses and the conflict warning, and name the single change that removes most symptoms.
Read the worked answer
169.254.x.x is APIPA - the self-assigned address Windows uses when no DHCP server replies. The pool holds 51 addresses for 12 desktops, so exhaustion is not the cause; the request is not reaching the router.
The pattern points to Layer 2. Two cables between two unmanaged switches make a physical loop. With no Spanning Tree Protocol on consumer switches, the frame is flooded out of both ports, comes back on the other, and repeats. The switch backplane saturates, DHCP OFFERs never arrive, and the camera video stream stalls. The intermittency fits a broadcast storm better than a broken cable: a dead cable would break things permanently, not for a few minutes at a time.
The conflict warning is separate and already explained: the constable manually set his desktop to 192.168.1.50, the printer's address. Two devices answer ARP for the same address and Windows reports the duplicate. Cameras at .60 to .67 are static and outside the DHCP pool, which is correct practice.
Single change: unplug one of the two inter-switch cables, keep one, then power-cycle both switches so their MAC tables clear. Then return the desktop to automatic addressing. The second cable cannot add speed - that requires link aggregation, which unmanaged switches do not support.
2. Is splitting 192.168.1.0/24 into two /26 networks the correct fix here? Justify your answer with an addressing plan.
Read the worked answer
Count first. 12 desktops + 1 printer + 8 cameras + 1 NVR + 1 router = 23 devices on a subnet with 254 usable addresses. Address exhaustion is not the problem, so subnetting is not solving the stated fault.
The /26 arithmetic works, the design does not. A /26 gives 62 usable hosts (64 addresses minus network and broadcast), so two of them hold 124 hosts, comfortably enough. But on a single unmanaged switch without VLANs, both ranges remain in one broadcast domain. A host at 192.168.1.20 and one at 192.168.1.70 still see each other's broadcasts and still participate in the same storm; the mask only tells them who is local, it does not enforce separation. Splitting the range now would create an addressing scheme that nothing on the network enforces - worse than a flat network, because it creates a false belief in isolation.
What to do instead: keep one /24, document it in a station LAN register, and reserve by function: .1 router, .2 to .49 infrastructure and switches, .50 to .99 printers, NVR and cameras as static, .100 to .150 DHCP (narrow it if possible), .151 to .254 spare. Cameras outside the pool is already right; the missing piece is documentation.
When to subnet: after a managed switch arrives. Then move cameras to a separate VLAN and subnet so camera broadcast traffic never reaches the desktops, and the boundary is real.
3. A video conference with the SP starts in 30 minutes. Sequence your actions and state what you will not attempt today.
Read the worked answer
Now (minutes 0 to 10): physical layer. Check link lights on both switches, remove the second inter-switch cable, power-cycle the switches. This is the only change that fixes the underlying fault and it does not need anyone's approval.
Next (10 to 20): protect the conference. The conference needs working desktops and a printer, not cameras. Confirm the printer answers a ping, print a test page, and on the three APIPA machines run ipconfig /release then ipconfig /renew and confirm they land in .100 to .150. Correct the manually set desktop back to DHCP, which clears the conflict warning.
Then (20 to 30): leave the cameras and NVR untouched but note the drop times; a firmware or NVR change during a live conference is how a small fault becomes a big one.
Not today: recabling, static reservations for all eight cameras, firmware updates, buying a switch, or re-addressing anything. Each needs either downtime or money.
Before leaving: start the LAN register - device, MAC, switch port, IP, static or DHCP. The absence of that register is why a single stray cable took an hour to find, and it will cause the next incident too.