Lab 6: Escalation, Documentation, and Handoff

Scenario: Build the Handoff

You have worked several small-network symptoms: a desk move caused wrong patching, an employee joined the guest SSID, a DHCP scope handed out the wrong DNS server, and a home router added a second private subnet. Some fixes are within entry-level support scope: replace a damaged patch cable, help a user join the correct SSID, record IP settings, or follow an engineer's instructions to identify Cisco device status LEDs. Others require escalation: managed-switch configuration, router/firewall policy, DHCP scope changes, DNS records, VLAN mapping, or security decisions.

The Three Escalation Decisions

If you cannot change a switch-port VLAN, firewall rule, DHCP scope, or SSID mapping, do not improvise. Document the evidence and hand it to the authorized team. Escalation is not an admission of failure - it is the correct technician action when the fix requires authority, access, tools, or design knowledge beyond your role. The CCST objectives explicitly include knowing when to escalate, so on the exam, an option that says 'escalate with documented evidence' is frequently the right answer when the change touches shared infrastructure or security.

An entry-level technician who makes an unauthorized VLAN or firewall change to look helpful can cause a far larger outage than the original ticket.

Anatomy of a High-Quality Ticket

A good ticket reads like a lab report. Include, in order:

1. Who and when: affected users and the start time/change event.
2. Expected design: e.g., 'employee wired clients should receive 172.16.8.x/24, gateway 172.16.8.1, DNS 172.16.8.10.'
3. Observed facts: e.g., 'three clients on jacks C-21 to C-23 receive 169.254.x.x; link LEDs on; the same laptops work on jack C-10.'
4. Tests in order: checked cable, swapped patch cord, verified link, renewed DHCP lease, pinged gateway, tested a DNS name, compared to a known-good client.
5. What was not changed and any open questions.

Compare 'Wi-Fi broken' to that structure. Vague tickets force the next tier to restart from zero; structured tickets let them target the fix.

Saving Diagnostic Output

Save key output in the ticket or attach files per local process. Windows commands include ipconfig /all, ping, tracert, and nslookup. Linux/macOS commands include ip, ifconfig, ping, traceroute, dig, and nslookup. Paste the actual output, not a summary - the exact address, hop, or error message is what lets the next tier diagnose without re-running everything. If an engineer requests a packet capture, use Wireshark, scope it tightly to the issue by capturing only during the DHCP renewal or DNS lookup, and stop as soon as you have the event.

Name the file with date, device, and symptom, for example 2026-05-06-laptop23-dhcp-renewal.pcapng, so it is self-describing in a shared folder. Do not capture unrelated sensitive traffic for longer than needed; broad all-day captures create privacy risk and are harder to analyze. Performing a Wireshark capture and saving it to a file is an explicit CCST Networking exam objective.

Communication and Cross-Domain Thinking

Tell users what is known, what is escalated, and any workaround (use wired Ethernet, or move to a known-good jack); record whether the workaround was accepted. Avoid promising a root cause before evidence supports it. Finally, recognize that symptoms cross domains: a 'DHCP failure' may be a VLAN problem; a 'printer failure' may be guest isolation; a 'DNS complaint' may be a wrong DHCP option; a 'no-Internet' report may be gateway, firewall, NAT, or ISP. Integrated labs matter because real tickets never arrive neatly labeled.

Honest Tickets and Workaround Tracking

The most common way a handoff fails is selective honesty. A technician who omits a test that did not work, or quietly reverts a change without recording it, forces the next tier to rediscover the same dead end. State plainly what you tried, what worked, what failed, and what you deliberately did not touch. A line such as 'renewed the lease - no change; did not modify the DHCP scope' is more valuable than it looks, because it both narrows the cause and tells the engineer the scope is still in its original state. Failed tests are data, not embarrassments.

Track workarounds as first-class facts. If you moved a user to a wired jack or a known-good port to restore productivity, that is a temporary fix, not a closed ticket - the underlying fault still exists and the workaround must be recorded so it can be undone after the real repair. Note whether the user accepted the workaround and whether any data or settings depend on it. When you hand off, give the user a plain-language status: what is known, what is being escalated, and roughly what to expect, without promising a root cause the evidence does not yet support. Clear, honest communication is itself part of the technician's value.

Common Traps

• Omitting the change event (the move, the AP swap) from the ticket.
• Hiding a failed test to look thorough.
• Capturing all-day traffic instead of the scoped event.
• Treating a workaround as a closed ticket and never undoing it.