Lab 2: Repair No Internet After an Office Move

Scenario: Moved Desks, Broken Access

A row of users moved over the weekend. Monday morning: two users have no Internet, one can print but not browse, and one works normally. The office uses wired Ethernet to wall jacks, a patch panel in the closet, an access switch, and a router/firewall as the default gateway. Your goal is not to redesign anything; it is to gather evidence, repair simple physical faults, and escalate accurately.

Step 1: Establish Scope

The single most valuable first move is to define blast radius. Ask: one user, one desk row, one switch, one application, or the whole site? The pattern tells you where to look.

Swap a known-good device onto the failing jack. If a good device also fails there, suspect the jack/patch/switch port. If the failing device works at a known-good jack, the endpoint itself is fine and the original path is the suspect. This swap test is the single fastest way to split the problem in half: it tells you whether the fault travels with the device or stays with the location. Note that the partial-failure user (prints but cannot browse) is itself a clue: printing is local same-subnet traffic, so Layers 1-3 work, and the break is in routing, DNS, or Internet access beyond the gateway.

The pattern across the four users already hints that this is not one shared outage but a mix of physical and service faults.

Step 2: Inspect the Physical Path

The classic move-day error is patching a desk into the wrong thing: an unused port, a voice-only port, a guest jack, or a switch with no live uplink. Verify the endpoint cable is seated and undamaged, read the wall-jack label, and trace the matching patch-panel port if permitted. Observe link and activity LEDs on both endpoint and switch. A solid link LED with no activity LED can mean the cable carries link but the port is in a blocking or wrong-VLAN state. Replace any obviously bad cable with a known-good cord and retest.

Movers commonly crush a cable under a desk leg or bend it past its minimum radius; a cable that worked on Friday can fail Monday purely from physical stress, so do not assume an undisturbed cable is healthy.

Step 3: Compare IP Settings, Then Test in Layers

A healthy client here might show 10.20.30.145/24, gateway 10.20.30.1, DNS from DHCP. Always read the healthy client's settings first so you have a known-good baseline to compare against, rather than trying to recall the design from memory. Interpret deviations:

• 169.254.x.x = no DHCP (APIPA).
• Guest range 10.99.10.x = wrong VLAN on the new switch port.
• Correct IP, blank/wrong gateway = off-subnet traffic fails.
• Correct IP, pings 8.8.8.8 but not www.cisco.com = DNS.

Run the layered sequence: link, then IP, then ping gateway, then ping a local resource, then an external IP such as 8.8.8.8, then a name such as www.cisco.com. Record both failures and successes. A useful intermediate tool is tracert (Windows) or traceroute (Linux/macOS): if it reaches the gateway hop but dies immediately after, the break is at or just past the gateway; if it never reaches the gateway, the problem is local. Each test you log narrows the fault domain and prevents the next technician from repeating the same checks.

Step 4: Escalate With a Clear Story

Compare 'Internet down' to: 'Link up, DHCP 10.20.30.151, gateway ping OK, 8.8.8.8 fails for two users on switch ports 17-18; known-good user on port 22 works.' The second tells the network engineer the fault is almost certainly a switch-side issue on ports 17-18 (wrong VLAN or trunk), not the router, because a router or ISP outage would knock out port 22 as well. The clean contrast between failing and working ports is what makes the ticket actionable. Escalate switch/VLAN, uplink/transceiver, or routing/NAT/ISP findings with move timing, affected users, jack labels, switch ports, and IP settings.

Always name the change event - the weekend move - because correlating the symptom start with a recent change is often the fastest route to root cause for the next tier.

Reading the Four-User Pattern Together

The value of an integrated lab is forcing you to synthesize, not isolate. Lay the four reports side by side. Two users with no Internet on adjacent move-day jacks plus one user working normally on a non-moved jack is a strong signal of a localized switch-side or patching fault, not a site outage. The print-but-no-browse user is a separate sub-problem at Layer 3 or above. The normal user is your control. A junior technician who reacts to the loudest complaint first may waste an hour on the router when the real fault is two miswired patch cords.

Cisco's bottom-up method exists precisely to stop that: confirm the cheap, fast, physical checks before touching shared infrastructure.

When you do find the fix, retest end to end and confirm with the user before closing. A jack that now passes a ping to the gateway but was never tested to the Internet can reopen the ticket an hour later. Document the final working state: jack, switch port, IP settings obtained, and the specific tests that now pass. If the repair was a cable swap, note the old cable's disposition so it is not reinstalled. This closes the loop and turns a one-off fix into a record the team can reuse after the next move.

Common Traps

• Concluding 'whole network is down' from one row of failures.
• Changing endpoint settings before comparing to a known-good device.
• Ignoring the weekend move as the change event in the ticket.
• Closing the ticket after one passing ping without an end-to-end retest.