Monitoring, Log Triage, and Route or Service Troubleshooting Lab
Key Takeaways
- PBQ troubleshooting is faster when you separate monitoring evidence, log evidence, path evidence, and service evidence.
- Interface counters, syslog, SNMP, flow data, and packet captures answer different questions.
- Routing issues are often visible through missing routes, wrong gateways, ACL blocks, or asymmetric paths.
- Service failures require checking name resolution, port reachability, process health, certificates, and dependencies.
- A clear escalation note should include scope, symptoms, timestamps, tests performed, findings, and next action.
Monitoring and Troubleshooting Lab
Many Network+ performance-based questions provide a small set of logs, counters, route tables, or command outputs. The goal is to decide what changed, where the failure begins, and which fix matches the evidence.
Scenario
Users in VLAN 10 report that the intranet is unavailable. Users in VLAN 30 can reach the same intranet server. Internet access still works for VLAN 10.
Evidence:
| Evidence | Result |
|---|---|
| User IP | 172.20.10.55/24 |
| User gateway | 172.20.10.1 |
| Intranet server | 172.20.30.25 |
| Ping gateway | Success |
| Ping intranet server | Fails |
| DNS lookup intranet name | 172.20.30.25 |
| TCP 443 test to intranet | Timeout |
| Firewall log | Deny 172.20.10.55 to 172.20.30.25 TCP 443 rule 90 |
The evidence says DNS works, the local gateway works, and the destination IP is known. The firewall deny log is the strongest clue. The next action is to review the rule set and allow the required user-to-intranet HTTPS flow if it is approved.
Evidence Types
| Tool or source | Best for | Example clue |
|---|---|---|
| Syslog | Device events and severity | Interface changed state, denied traffic, authentication failure |
| SNMP | Health and performance polling | Interface utilization, errors, CPU, memory |
| NetFlow or flow data | Who talked to whom and how much | Top talkers, unusual destination ports |
| Packet capture | Packet-level proof | TCP SYN retransmits, TLS alert, ARP behavior |
| Interface counters | Link quality and errors | CRC errors, drops, duplex mismatch clues |
| Route table | Path selection | Missing default route, wrong next hop |
| DNS tools | Name resolution | Wrong record, no response, split DNS issue |
Route Triage
| Symptom | Likely issue | Useful command family |
|---|---|---|
| Can reach local gateway but not remote network | Route, ACL, firewall, or upstream issue | ping, traceroute, route table |
| Traceroute stops at firewall | Policy block or missing route after firewall | firewall logs, route table |
| One direction works, return fails | Asymmetric routing or missing return route | route tables on both sides |
| Only one subnet affected | VLAN interface, ACL, route advertisement, or DHCP option | interface status, ACL, DHCP lease |
Service Triage
| Layer | Question | Test |
|---|---|---|
| DNS | Does the name resolve to the expected IP address? | nslookup or dig |
| Network path | Can the client reach the destination network? | ping or traceroute where allowed |
| Transport | Is the expected port reachable? | tcping, nc, Test-NetConnection, or packet capture |
| Application | Is the service process healthy? | service status, HTTP response, logs |
| Security | Is a firewall, ACL, certificate, or authentication control blocking it? | firewall logs, TLS details, auth logs |
Do not stop at "ping fails" if ICMP is blocked by policy. For web services, a TCP 443 test and firewall logs may be more useful than ping.
Example Log Triage
| Log line | Interpretation |
|---|---|
| %LINK-3-UPDOWN: Interface Gi1/0/24 changed state to down | Physical or data link event on a switchport |
| Deny TCP 172.20.10.55:51512 to 172.20.30.25:443 | Firewall policy blocked a web session |
| DHCPDISCOVER from client, no DHCPOFFER observed | DHCP server, relay, VLAN, or trunk issue |
| OSPF neighbor down, dead timer expired | Routing adjacency failure |
| High CRC errors on Gi1/0/12 | Cable, transceiver, interference, or duplex issue |
Escalation Note Template
Use concise notes in PBQs when asked to document the issue:
- Scope: VLAN 10 users cannot reach intranet HTTPS; VLAN 30 users can.
- Time: Reports began after the 09:15 firewall change.
- Tests: Gateway ping succeeds; DNS resolves; TCP 443 times out.
- Evidence: Firewall denies VLAN 10 to 172.20.30.25 TCP 443 on rule 90.
- Next action: Review rule 90 and add or move approved HTTPS allow rule above deny.
Common PBQ Traps
- Replacing cabling when logs show an explicit firewall deny.
- Treating DNS as broken after the name resolved correctly.
- Assuming ping failure means the server is down when ICMP is blocked.
- Ignoring return routes and asymmetric routing.
- Looking only at average bandwidth and missing interface errors or drops.
- Escalating without timestamps, affected scope, or evidence.
A client resolves a server name correctly, can reach its gateway, but TCP 443 to the server times out and firewall logs show a deny. What is the most likely cause?
Which evidence source is best for identifying CRC errors and drops on a physical switch interface?
Which details belong in a useful network escalation note? Select three.
Select all that apply