Four Complaints in a Newly Networked Police Station
A newly computerised police station in a Uttar Pradesh district has 14 desktops, one shared laser printer and one server at 192.168.1.10 that hosts the FIR application on port 8080. The ISP router at 192.168.1.1 also acts as the DHCP server and delivers about 100 Mbps. On Tuesday the operator logs four complaints. (1) PC-07 shows "site cannot be reached" for the FIR application, yet it prints to the shared printer and opens google.com normally; a ping to 192.168.1.10 succeeds. (2) PC-03 and PC-11 each display "This IP address is already in use" at boot. (3) Every day between 15:00 and 16:00 the whole network becomes very slow. (4) The shared printer can be reached from only 4 of the 14 desktops. A part-time technician had earlier 'fixed' things by assigning static addresses from 192.168.1.10 to 192.168.1.30 on ten machines, and nobody recorded which machine holds which address.
1. For PC-07, which commands should the operator run, what does each result rule out, and what is the most likely cause?
Read the worked answer
Work up the layers instead of re-installing anything.
ipconfig /all- confirms PC-07's own IP, subnet mask, default gateway and DNS. If the mask is wrong (say 255.255.0.0 instead of 255.255.255.0), the machine misjudges which addresses are local; that alone can break access to one host while leaving others working.ping 192.168.1.10- already succeeds, so cabling, switch port, PC-07's NIC and basic IP routing are all fine. Physical-layer repairs are excluded.ping firserver(if a hostname is used) - distinguishes a name-resolution (DNS) failure from a connectivity failure.telnet 192.168.1.10 8080orTest-NetConnection 192.168.1.10 -Port 8080- this is the decisive test. If the ping succeeds but port 8080 is refused or times out, the network path is fine and something on PC-07 is blocking or redirecting that port.
Most likely cause: PC-07's local firewall or antivirus is blocking outbound port 8080, or a proxy setting / stale entry in the hosts file is redirecting the FIR application's URL. Fix by checking the browser's proxy settings, the hosts file, and adding an allow rule for port 8080. If the application is reached by hostname, an outdated hosts entry is a strong candidate, since google.com resolves through DNS and works.
2. Explain what is causing the IP conflict messages on PC-03 and PC-11 and design a simple addressing scheme that prevents this from recurring.
Read the worked answer
Cause: the router's DHCP pool is the default 192.168.1.100–192.168.1.199 (or similar), but the technician assigned static addresses 192.168.1.10–192.168.1.30 to ten machines without recording them. Two failures follow:
- Duplicate statics. Two machines can easily have been given the same 'free' address, producing exactly the message seen on PC-03 and PC-11 - the second machine to come up finds the address already taken by ARP.
- Static inside the DHCP range. If a static address happens to fall inside the DHCP pool, the router can hand the same address to a laptop, and the conflict appears at random.
Scheme:
192.168.1.1- router only.192.168.1.2–192.168.1.9- network devices (switch, printer, access point).192.168.1.10–192.168.1.29- servers only (the FIR server stays at .10).192.168.1.30–192.168.1.99- reserved, unused.192.168.1.100–192.168.1.199- DHCP pool only.- Desktops should use DHCP; where a fixed address is genuinely required, add a DHCP reservation by MAC address so the router records it, and log it in a register kept at the station.
Detection tools: arp -a on a suspect machine, and the router's DHCP client list, which shows every lease and its MAC address.
3. Give the likely causes of the daily 15:00–16:00 slowdown and say how each can be confirmed or ruled out, and what should be done about the printer reachable from only 4 desktops.
Read the worked answer
The slowdown is time-correlated, so look for a recurring 15:00 job before blaming the ISP.
- A scheduled backup or antivirus scan pushing a large file to the server at exactly that hour. Confirm in Task Scheduler and in the antivirus console's scan log; if confirmed, move the backup to 21:00.
- Bandwidth saturation by legitimate traffic - one machine streaming video, a large Windows update download, or cloud backup. Confirm with the router's per-device traffic graph or a bandwidth monitor; the fix is QoS rules and a block on streaming sites at the router.
- A looping or faulty machine flooding the switch (broadcast storm, a failing NIC, a patch cable loop between two switch ports). Confirm by looking at switch port LEDs that blink continuously and by unplugging suspect ports one at a time; a loop is cured by enabling spanning tree or removing the redundant cable.
- Duplex mismatch on a link (one side hard-set to 100 full, the other auto-negotiating) shows high collision and error counters on the switch port even at low load. Confirm from the switch statistics; fix by setting both ends to auto.
- ISP-side congestion is the last suspect, because slowness confined to exactly one hour each day rarely comes from the provider. Confirm by running a speed test at 14:00 and 15:30 from the same wired PC.
Printer reachable from only 4 desktops: the printer is almost certainly shared from one PC rather than networked, so only machines in that PC's workgroup or with a mapped share can see it. Fix: give the printer a fixed IP outside the DHCP pool, install it on each desktop as a TCP/IP port, or share it from the server with proper permissions. Also check that Network Discovery and File and Printer Sharing are enabled on the affected machines and that all are on the same subnet and workgroup.