I85PREP
⌘ K
RSMSSB Computor study materials
RSMSSB Computor study resources

Intermittent Internet on One Desktop in a Block Office LAN

RSMSSB Computor · Put your knowledge to work in context.

All case studies

Intermittent Internet on One Desktop in a Block Office LAN

A block-level office at a Rajasthan district headquarters runs 18 desktops on a 24-port unmanaged switch. The switch uplinks to a fibre ONT that performs NAT and also acts as the DHCP server, with its pool set to 192.168.1.100–192.168.1.120. Last week two new desktops and a Wi-Fi network printer were added. Since then, the accountant's PC at 192.168.1.105 loses internet for two or three minutes every afternoon and then recovers by itself. The network printer occasionally prints the same page twice. From another desktop, pinging the gateway 192.168.1.1 returns alternate replies: time=1ms and Destination host unreachable. The technician has already replaced the accountant's patch cable and re-crimped both RJ-45 ends, and the fault persists. The office has no managed switch, no VLANs and no written IP register. The accountant must upload an e-payment file at 4 p.m. every day.

1. Identify the most probable root cause of the intermittent failure on 192.168.1.105, and state which evidence in the setup rules out a bad cable or a dead switch port.

Read the worked answer

The pool holds only 21 addresses (100–120), but the office now has 18 desktops + 2 new desktops + a network printer = 21 devices, and any staff phone or laptop on Wi-Fi competes for the same pool. Once the pool is exhausted, a device either fails to get a lease and self-assigns an APIPA address (169.254.x.x) or keeps using an address whose lease has expired - producing an IP address conflict or an unreachable gateway.

Evidence that points here rather than to hardware:

  • The failure is time-of-day dependent (afternoon, when every seat is occupied). A dead port or a bad cable would fail continuously, not for three minutes and then heal.
  • ping alternating between a 1 ms reply and Destination host unreachable is the classic signature of two hosts answering for the same address, or of ARP resolving to a different MAC each time.
  • The cable and both connectors were already replaced, which removes the most common physical cause.
  • The printer printing a page twice fits a duplicate-address/retransmission problem on the same segment.

2. Give the sequence of checks you would run at the accountant's desk and on the router, and state exactly what you would change in the DHCP configuration.

Read the worked answer

On the affected PC (Windows):

  1. ipconfig /all - note whether the address is 192.168.1.105 with a valid lease, or a 169.254.x.x self-assigned address.
  2. ipconfig /release then ipconfig /renew - if the PC gets a different address and the problem vanishes, the conflict is confirmed.
  3. arp -a while pinging the gateway repeatedly - a MAC that changes between replies proves two devices share an address.

On the ONT/router admin page: open the DHCP client list, count active leases, and look for a device manually set to an address inside the pool.

Correction, in this order:

  1. Widen the pool to 192.168.1.100–192.168.1.200 so 21 devices plus guest phones fit comfortably.
  2. Move the printer to a fixed address outside the pool (for example 192.168.1.20), set on the printer itself, and record it in a register.
  3. Release/renew every machine, then re-test at the same afternoon hour.

3. Why must the printer's fixed address be outside the DHCP pool rather than simply chosen as 192.168.1.110? What would you write in the office's IP register?

Read the worked answer

192.168.1.110 sits inside the 100–120 pool. The DHCP server has no way of knowing that address has been taken by hand, so on the next lease cycle it can hand 192.168.1.110 to a visiting laptop. The printer and the laptop then both answer for the same address and the original symptom returns - this time blamed on the printer.

Keeping fixed addresses outside the dynamic range works because the two sets never overlap, and it does not depend on the DHCP server understanding reservations. If the router does support reservations, a MAC-bound reservation is equally safe, but then the address should still be documented, because a replacement printer or a factory reset silently breaks the link.

The register should carry, at minimum: device name, room, MAC address, IP address, whether DHCP or static, and the date. Without that record the next technician repeats today's diagnosis from scratch. The office's real failure here was not the pool size alone but the absence of any record of what had been added to the network.