Network Troubleshooting Simulation

Competition starts in twenty minutes. Eight computers, two switches, one router, one internet connection, one game service. Something doesn't work.

The network

The Robotnix Arena Network: PC-01 through PC-04 connect through Switch-A; PC-05 through PC-08 connect through Switch-B; both switches connect to one router, which reaches the internet and the game service. Additional services on the network: DHCP, DNS, an authentication service, and a voice service.

Your technical team

Groups of four, one role each, rotating between scenarios.

Incident Lead. Keeps the team focused and decides which test happens next.

Network Mapper. Uses the topology and marks affected components.

Test Technician. Requests diagnostic tests.

Recorder. Documents each test, its result, what it rules out, and the next hypothesis.

The rule: four diagnostic actions per scenario

You do not get unlimited tests. Each scenario gives you exactly four diagnostic actions, because "restart everything" isn't a strategy — you need tests that actually produce useful information, chosen deliberately.

Available actions, depending on the scenario: check other stations, check the physical connection, check the local network, check internet access, check DNS, check service status, compare with a known-good PC, swap a known-good cable, try the account on another PC, check network configuration, or check switch status. No real network tools are required — the simulation provides the results.

Scenario 1: one station down

PC-03 can't reach any online service; no other players have reported problems. Choose your first test.

Checking PC-02 shows it works fine — that tells you the router, internet, and game service are likely functioning, at least for a nearby station, so the focus narrows toward PC-03 specifically. Checking PC-03's physical connection shows no connection detected. Swapping in a known-good cable restores the connection. Likely issue: the physical connection path. Document it carefully, including what you didn't confirm (was the original cable actually damaged, or just poorly seated?).

Scenario 2: half the lab goes dark

PC-01 through PC-04 lose connectivity simultaneously; PC-05 through PC-08 still work. What's shared? Looking at the topology, PCs 01-04 all run through Switch-A — a strong clue, but test it before committing to it.

Scenario 3: the internet works, kinda

All PCs can open websites; nobody can reach the game login. Checking game authentication status reveals the authentication service is reporting an outage. Root cause: not the school network. The right action here is mostly to document, notify the appropriate people, and wait for the remote service to recover — not to make unnecessary local changes. Knowing when not to change the system is a real technical skill, not a lack of one.

Scenario 4: names don't work

PC-06 can connect to a fictional service by IP address but not by name; other stations work normally. The layer worth investigating: DNS configuration.

Scenario 5: everything outside is gone

All stations can reach local resources; no station can reach anything external. Local is functioning; the external path is failing further upstream. A reasonable next test: router status.

Scenario 6: voice only

Game works, internet works, other applications work — but one student's microphone doesn't transmit. The student announces "NETWORK PROBLEM!" Could it be? Maybe, but is it your strongest first hypothesis? Probably not — check the narrower layers first: microphone, OS input settings, application settings, permissions. Weeks 15 and 16 overlap here on purpose, because real systems overlap too.

Scenario 7: intermittent failure

The hardest one. During practice, PC-08 disconnects for a few seconds several times, then reconnects. By the time you look at it, the problem has vanished. Document time, symptom, duration, what else was affected, connection status, and any pattern you can spot. Intermittent problems often need evidence gathered over time rather than a single clean test result.

Don't invent certainty

If your evidence only supports "likely cable or switch port," write that. Don't write "definitely a bad Ethernet controller" because it sounds more technical — the most professional possible answer is sometimes "more evidence required."

Your Network Troubleshooting Case Report

Choose one scenario and document nine things:

1. Initial symptom. What was reported?

2. Scope. Who or what was affected?

3. Network path. Draw the relevant path.

4. Initial hypotheses. At least three.

5. Tests. For each: what you chose, why you chose it, the result, and what it changed about your thinking.

6. Likely cause. What explanation fits the evidence best?

7. Action. What should happen next?

8. Verification. How would you prove the original problem is actually resolved?

9. Confidence. Rate it supported, likely, confirmed, or more evidence needed, and explain why.

Troubleshooting timeline

Include a short sequence with fictional timestamps: symptom reported, scope established, test performed, hypothesis narrowed, action taken, verification. Exact times don't matter — the sequence does.

Team defense

Your instructor asks: why did you choose Test 2 before Test 3? A weak answer is "because." A strong answer sounds like: "Test 2 helped us determine whether the failure was limited to PC-03 or affected the shared network path, which eliminated several upstream hypotheses before we changed anything." That's technical reasoning, not a guess dressed up afterward.

The fastest fix isn't always the best investigation

Suppose "restart the router" fixes everything. Great — but what actually failed? No idea. If it happens again tomorrow, you're still working from no idea. Operational pressure sometimes requires a quick recovery, but good maintenance also asks why it happened in the first place — a question the technology-operations work ahead will keep returning to.

Final requirements

Your Network Troubleshooting Case Report needs: a clear symptom; scope; a relevant network diagram; at least three hypotheses; at least three diagnostic tests with reasoning; recorded results; a likely or confirmed cause; a corrective action; a verification method; an evidence-based confidence rating; and a short incident timeline.

Before you leave

Complete:

1. The test that gave us the most information was __________ because __________.
2. The test we almost performed but decided against was __________ because __________.

Choosing not to run a useless test is part of troubleshooting too.

Source note

This simulation directly supports Middle Township Unit 5 expectations involving network reliability, routers, switches, servers, topology, addressing, system evaluation, maintenance, and repair.

The Robotnix Arena network simulator, the incident roles, the limited-test mechanic, the evidence-confidence scale, and the Network Troubleshooting Case Report are original Robotnix Academy components.