Two Rooms, Two Hubs and a Subnet That Is Too Small
Two adjacent computer rooms in a school at Bathinda are to be networked. Room A has 25 student computers plus one server; Room B has 20 student computers. Both rooms are wired in a star through two 8-port hubs that are uplinked to each other, and every computer is on the single subnet 192.168.10.0/27. The rooms use 40-metre CAT5e cables run along the floor. There is no DHCP server, so a clerk typed every address into every machine by hand and wrote the list in a register.
Three complaints arrive in the same week. Copying a 40 MB video from one computer in Room A to another takes about four minutes, and the whole room slows down whenever anyone starts a large copy. A computer in Room B shows "IP address conflict" every morning at 9 a.m. Teachers can reach the server at 192.168.10.2 but not by typing the server's name.
The head of department wants the two rooms joined into one managed network next session: the server on a fixed address, everyone else configured automatically, and room to add 15 more machines later.
1. Diagnose the slow file copy. Explain what a hub does to the traffic of 26 machines, calculate roughly what throughput the observed copy implies, and justify the replacement device and topology you would recommend.
Read the worked answer
Every port of a hub is in the same collision domain: all attached stations share one bandwidth pool and use CSMA/CD to take turns. With 26 machines in Room A, every frame - including the one travelling between two computers that only need to talk to each other - is repeated out of every port, so all 26 hosts contend for the medium. Ethernet also runs at half duplex here, which roughly halves useful throughput and forbids simultaneous send and receive.
Numbers. 40 MB is about 320 megabits. Four minutes is 240 seconds, so the copy achieved roughly 320/240 ≈ 1.3 Mbps - about 1% of a 100 Mbps link. That is consistent with heavy contention, retransmissions after collisions and half-duplex operation, not with a faulty cable.
Recommendation. Replace both hubs with switches of at least 24 ports (one per room, uplinked, or one 48-port switch). A switch learns MAC addresses and forwards a frame only out of the port leading to the destination, so each port is its own collision domain and can run full duplex - the copy becomes a private conversation, and a large transfer no longer degrades other users. Keep the physical star wiring, which is already correct. The 40 m runs are well inside the 100 m limit for CAT5e, so cabling need not change; check that the uplink between switches is not the bottleneck, and use Gigabit on that link if large video copies are routine. Name resolution is a separate issue needing DNS or a local hosts entry, which the switch will not fix.
2. Check whether 192.168.10.0/27 can serve the planned network of 25 + 20 + 1 = 46 devices (with the server fixed and clients automatic), and give the correct mask and usable range if it cannot. Also explain what most likely causes the 9 a.m. "IP address conflict" in Room B.
Read the worked answer
Sizing. /27 borrows 3 bits, giving 2^5 = 32 addresses: 30 usable after the network and broadcast addresses. The school needs 46 devices now and 61 after adding 15 machines - far beyond 30. The plan is invalid before any cable is pulled.
Correct choice. 61 hosts needs 6 host bits: 2^6 = 64 addresses, 62 usable. That is /26, mask 255.255.255.192, network 192.168.10.0, usable 192.168.10.1 – 192.168.10.62, broadcast 192.168.10.63. A /25 or /24 would also work but wastes addressing; /26 fits with one spare address, so if the "15 more later" figure might grow, /25 (126 usable) is the safer judgement call and should be raised with the head of department now rather than renumbered later.
Server. Give the server 192.168.10.2 as a static address outside the DHCP pool, or a DHCP reservation tied to its MAC address, so its address never changes and the teachers' bookmark keeps working.
The 9 a.m. conflict. Something joins the network at 9 a.m. with an address that is already manually assigned - a student laptop, a staff device, or a machine reinstalled from an old copy of the register with a duplicate typed in. With hand-typed addressing, one transposed digit is enough, and nobody owns the list. A DHCP server on the router or server, with a documented scope and an excluded range for fixed devices, removes the whole class of error: the server records every lease so a conflict can be traced to a device and a time.
3. A teacher argues: "DHCP caused these problems - give every machine a fixed address typed by hand, like we do now." Evaluate that advice and state what you would keep fixed, what you would automate, and why.
Read the worked answer
The advice inverts cause and effect. The conflicts come from hand-typed addressing, not from DHCP - the school has no DHCP server at all, so DHCP cannot be blamed. With 46 (later 61) machines, manual addressing means transposed digits, stale entries in the register, duplicated addresses after a reinstall, and no record of which machine took which number. Nobody can answer "which device is 192.168.10.37?" at 9 a.m. without walking the rooms. Every added machine, and every change of subnet mask (which the school must make anyway, from /27 to /26), becomes a manual visit to dozens of machines.
Keep fixed: devices whose address other machines must know and which must never move - the server, the network printer, the switch management address, and the router or gateway. Implement them as static addresses reserved outside the DHCP scope, or as DHCP reservations bound to MAC addresses, so configuration stays in one place.
Automate: all student and staff machines, which only need to reach the server. DHCP hands out address, mask, gateway and DNS together, so a mask change is made once on the server.
Guardrails: enable a rogue-DHCP check, keep the reservation list in the same register the clerk already maintains, and document the scope. If the DHCP server itself fails, keep one spare static address and a printed copy of the scope so the lab can be brought up manually. Justify the split by what the failure costs: a wrong server address breaks everyone, a wrong student address breaks one seat and is fixed by reconnecting.