Practice: small network troubleshooting

Dev has a habit for new technicians' last week of networking training. He picks five real tickets from the past year, removes the answers, and hands them over one at a time with the evidence that was available when each one arrived. Jordan's job is to work each one through the method from lesson 10, using the commands from lesson 9, and to write the resolution as if closing the ticket. This lesson follows those five cases. Try each one yourself before reading the solution; together they draw on almost every topic in this course and match the kind of reasoning the CCST Networking exam asks for.

The exam, Cisco 100-150, is a 50-minute test; Cisco's exam page lists the price as 125 US dollars and offers it in several languages. Cisco does not publish the number of questions or a passing score, so check the current exam page and the official exam topics before booking. The topics fall under six areas: standards and concepts, addressing and subnet formats, and endpoints and media types, which CSCO-111 covers, and infrastructure, diagnosing problems and security, which this course covers. Jordan plans to sit CCST Networking after his IT Support exam, once both courses are behind him.

Case 1: The new exam room

Ticket. Prairie Paws has opened a new exam room. The PC there shows a network connection, but cannot open the practice-management system or the internet. Every other room works.

Evidence. On the PC, ipconfig shows 10.20.30.58 with gateway 10.20.30.1. On the switch, show interfaces status shows port Gi1/0/14, labeled Exam-Room-4, connected in VLAN 30.

Jordan reasons through it. Only one PC is affected, so the cause is local to that PC, its cable or its switch port. The PC has a valid address, so DHCP works, but the address is in 10.20.30.0/24, the guest subnet. The switch confirms the port is in VLAN 30. Guests are allowed only to the internet through the captive portal, which a desktop PC without a browser session never passes, so nothing works. The cause is a port assigned to the wrong VLAN, probably copied from the waiting-room port next to it.

SW-PP1(config)# interface gigabitEthernet1/0/14
SW-PP1(config-if)# switchport access vlan 10
SW-PP1(config-if)# end
SW-PP1# copy running-config startup-config

C:\> ipconfig /release
C:\> ipconfig /renew
   IPv4 Address. . . . . . . . . . . : 10.20.10.61
   Default Gateway . . . . . . . . . : 10.20.10.1

Resolution. Port Gi1/0/14 moved from VLAN 30 (Guest) to VLAN 10 (Staff); PC renewed to 10.20.10.61; practice-management system and internet confirmed working by the receptionist; switch configuration saved and the port added to the site's port map.

Case 2: Monday morning at the bakery

Ticket. At Kettle & Crumb's second shop, the office laptop and both tablets have no internet after a long weekend. The payment terminals, which use a cellular backup, are working.

Evidence. The laptop shows 169.254.88.4 and no gateway. The shop's small router, which also acts as the DHCP server, has its power light on but its internet light off. The building had a power cut on Sunday, according to the shop manager.

Several devices fail together, so Jordan looks at shared equipment. The 169.254 address says DHCP is not answering. The router is the DHCP server and appears to be in a bad state after the power cut. Before restarting it, Jordan checks remotely: the router does not answer Brightline's monitoring, and the shop's internet line shows no sync on the provider's portal. A power cut can leave a router hung and a modem without sync. He asks the manager to power-cycle the modem first and then the router, in that order, waiting for each to settle.

After the restart the modem syncs, the router's internet light comes on, and the laptop obtains 192.168.12.40 from DHCP. Jordan checks the router's log, which shows it rebooted into a half-finished state when power returned. Resolution. Modem and router power-cycled in order; DHCP and internet restored; recommended a small battery backup for the shop's network cabinet, logged as a proposal for the client.

Case 3: Names, not numbers

Ticket. Riverside Family Law: since a firewall replacement on Friday evening, users can reach websites by clicking links in email but typing addresses into the browser fails. The document system, a SaaS service, also fails.

Evidence. ping 1.1.1.1 succeeds. ping portal.riversidefamilylaw.com reports that the host could not be found. nslookup with no server shows a timeout from the configured DNS server, 10.5.1.10, the firm's internal DNS server. nslookup with a public server, nslookup example.com 1.1.1.1, works.

Pinging an address works, so routing and NAT are fine; names fail, so it is DNS. Asking a public server directly works, so the internet path for DNS is open from the PC. The internal DNS server is timing out. Jordan considers what changed: the firewall. The internal DNS server forwards queries it cannot answer to public resolvers, and the new firewall's outbound rules were copied from a template that allows web traffic but not DNS from servers. Links in emails worked only because some pages were already cached.

C:\> nslookup example.com
Server:  UnKnown
Address:  10.5.1.10
DNS request timed out.

C:\> nslookup example.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1
Non-authoritative answer:
Name:    example.com

Resolution. Added a firewall rule allowing the internal DNS server to send DNS (UDP and TCP port 53) to the approved public resolvers; verified name resolution and the document system on three PCs; logged the missing rule against the firewall change ticket so the template is corrected for future installations.

Case 4: The slow upstairs office

Ticket. Northfield Center: the upstairs office PCs are very slow to open files from the server downstairs, while everyone downstairs is fine. It has been like this since an electrician worked in the building.

Evidence. iperf3 between an upstairs PC and the server shows about 6 megabits per second. show interfaces status on the downstairs switch shows the port to the upstairs switch running at 100 Mb/s half duplex. show interfaces for that port shows thousands of CRC errors and late collisions, still rising.

The problem affects everything behind one link, so Jordan follows the path to that link. The link has negotiated 100 Mb/s half duplex instead of 1 Gb/s full duplex, and rising CRC errors and late collisions confirm a physical and duplex problem. Gigabit Ethernet needs all four pairs of a cable; if a pair is damaged, autonegotiation often falls back to 100 Mb/s, and if one end has been set to fixed speed and duplex settings, the other may fall back to half duplex. Jordan checks the configuration: both ends are set to auto, so the cable is the likely cause. The electrician's work gives a strong clue.

A cable tester on the run shows one pair broken at a junction box the electrician had moved. Resolution. Cable repaired and certified by Brightline's cabling contractor; link restored to 1000 Mb/s full duplex; counters cleared and stable after an hour; iperf3 now shows about 940 megabits per second; ticket notes added to the building's cabling records.

Case 5: The guest network that went too far

Ticket. Prairie Paws: a staff member noticed that her personal phone, connected to the waiting-room guest Wi-Fi, could open the web page of the clinic's label printer.

Evidence. The guest SSID maps to VLAN 30. The printer is at 10.20.10.80 in VLAN 10. On the router, the access rules for the guest subinterface were reviewed: the first rule permits any traffic from 10.20.30.0/24 to any destination, and the rule meant to block guests from internal networks is below it.

This is a security problem, so Jordan follows Brightline's procedure and tells Keisha Moreau before changing anything. The cause is clear from the rule order: access lists stop at the first match, and the broad permit comes before the deny, so the deny never takes effect. Keisha checks the router's logs to see whether any guest device reached internal systems beyond the printer page, finds no sign that it did, and approves the fix.

Before (wrong order):
 10 permit ip 10.20.30.0 0.0.0.255 any
 20 deny   ip 10.20.30.0 0.0.0.255 10.20.0.0 0.0.255.255

After (specific deny first):
 10 deny   ip 10.20.30.0 0.0.0.255 10.20.0.0 0.0.255.255
 20 deny   ip 10.20.30.0 0.0.0.255 10.21.0.0 0.0.255.255
 30 permit ip 10.20.30.0 0.0.0.255 any

Resolution. Guest access list reordered so internal networks at both clinics are denied before internet access is permitted; tested from a phone on guest Wi-Fi (printer unreachable, internet working); client isolation confirmed on the guest SSID; reviewed with the security analyst; change recorded and the configuration backed up.

What the five cases have in common

Each case was solved by the same steps. Jordan established the scope before guessing, used the cheapest tests first, let the evidence rather than habit point to the cause, changed one thing, verified with the user and wrote down the cause, not just the symptom. Two of the five, the guest VLAN port and the firewall template, came from earlier changes that were not checked, which is why change management and documentation matter as much as commands.

Preparing for the exam

Exam questions describe situations like these in a few lines and ask what is wrong, what to check next or which setting fixes it. A few habits help. Read the symptom carefully and note its scope. Look for the detail that rules options out, such as an address range, a status word or a counter. Remember the standard values the exam can rely on: private ranges, the 169.254 range, DHCP and DNS ports, default administrative distances, the meaning of each interface status and the order of the troubleshooting steps. Practice reading command output until the important line jumps out. Jordan uses a free network simulator and virtual routers on his laptop, as lesson 6 mentioned, to rehearse configurations and break them on purpose.