Lab 18 — Network Troubleshooting Methodology and Fault Isolation

Mission Information

Item	Details
Lab	18
Lab Name	Network Troubleshooting Methodology and Fault Isolation
Track	CompTIA Network+
Difficulty	Intermediate
Estimated Time	150–180 minutes
Primary Role	Network Technician / Network Administrator
Environment	Network+ Enterprise Troubleshooting Lab
Primary Systems	NETPLUS-CLIENT01, NETPLUS-SW01, NETPLUS-RTR01, NETPLUS-SERVER01, NETPLUS-NMS01
Primary Tools	Ping, Traceroute, ipconfig, ip, nslookup, dig, arp, route, Wireshark, SNMP, Syslog, Device CLI
Skills	Troubleshooting Methodology, Fault Isolation, Root Cause Analysis, OSI Troubleshooting, Verification, Escalation, Documentation

Mission Objective: Investigate a series of intentionally introduced enterprise network failures using a repeatable troubleshooting methodology. Identify symptoms, determine scope, establish and test theories, isolate root causes, implement corrective actions, verify functionality, and document each incident.

Mission Scenario

The GHC Enterprise network has been operating normally.

Your monitoring dashboard suddenly reports:

Multiple Connectivity Alerts

DNS Resolution Failures

Interface State Changes

Increased Packet Loss

Application Availability Problems

At the same time, the help desk receives reports:

"I cannot access the network."

"The Internet isn't working."

"The application server is unavailable."

"I can ping the server but cannot open it by name."

"Wi-Fi keeps disconnecting."

"The network is extremely slow."

The dangerous approach would be:

Guess
 ↓
Change Configuration
 ↓
Test
 ↓
Change Something Else
 ↓
Hope It Works

Instead, you will use:

Evidence
   ↓
Methodology
   ↓
Fault Isolation
   ↓
Root Cause
   ↓
Corrective Action
   ↓
Verification

Mission Objectives

By completing this lab, you will be able to:

• apply the CompTIA troubleshooting methodology

• identify and document symptoms

• determine the scope of a network problem

• question users effectively

• identify recent environmental changes

• establish probable-cause theories

• test theories systematically

• isolate Layer 1 problems

• isolate Layer 2 problems

• isolate Layer 3 problems

• troubleshoot DHCP

• troubleshoot DNS

• troubleshoot default gateways

• troubleshoot VLAN configuration

• troubleshoot routing

• troubleshoot wireless connectivity

• troubleshoot network services

• troubleshoot performance degradation

• use monitoring evidence

• use packet captures

• perform root cause analysis

• develop corrective action plans

• verify full functionality

• determine when escalation is required

• document troubleshooting results

1. Build the Troubleshooting Environment

Use the following topology:

                    Internet / WAN
                         |
                         |
                   NETPLUS-RTR01
                    10.10.10.1
                         |
                         |
                   NETPLUS-SW01
                  /      |       \
                 /       |        \
                /        |         \
       CLIENT01      SERVER01      NMS01
      10.10.10.20   10.10.20.30  10.10.30.50

Your exact addressing can follow your existing Network+ lab environment.

2. Establish a Known-Good State

Before introducing faults, verify:

Physical Connectivity

Interface Status

VLAN Membership

IP Addressing

Default Gateway

DHCP

DNS

Routing

Server Reachability

Internet Reachability

Monitoring

This gives you a:

Known-Good Baseline

3. Verify CLIENT01

Windows:

ipconfig /all

Record:

IPv4 Address:

Subnet Mask:

Default Gateway:

DNS Server:

DHCP Server:

MAC Address:

4. Verify Basic Connectivity

Test:

ping 127.0.0.1

Then:

ping <CLIENT01-IP>

Then:

ping <DEFAULT-GATEWAY>

Then:

ping <SERVER-IP>

Then an external destination if your lab permits it.

5. Verify DNS

Run:

nslookup server01.ghc.lab

Record:

DNS Server:

Query:

Resolved Address:

6. Verify the Network Path

Run:

tracert <SERVER-IP>

or Linux:

traceroute <SERVER-IP>

Save the known-good path.

7. Verify Switch State

On SW01:

show interfaces status

Then:

show vlan brief

Then:

show mac address-table

Record the normal state.

8. Verify Router State

On RTR01:

show ip interface brief

Then:

show ip route

Record:

Interface State

Connected Networks

Default Route

Learned Routes

9. Review Monitoring Baseline

From Lab 17, verify:

Device Availability

Interface State

Latency

Packet Loss

Interface Utilization

Syslog

SNMP

You now have evidence of what:

Healthy

looks like.

10. Understand the Troubleshooting Methodology

Use the following process:

Identify the Problem
        ↓
Establish a Theory
        ↓
Test the Theory
        ↓
Establish a Plan of Action
        ↓
Implement the Solution
        ↓
Verify Full Functionality
        ↓
Implement Preventive Measures
        ↓
Document Findings

This should become your default troubleshooting workflow.

11. Step 1 — Identify the Problem

Start by collecting information.

Ask:

What exactly is failing?

Who is affected?

When did it begin?

Is the problem constant?

Is it intermittent?

What changed recently?

Does the problem affect one device?

One VLAN?

One building?

Everyone?

12. Define the Symptom

Avoid vague descriptions such as:

Network is broken.

Replace them with measurable symptoms:

CLIENT01 cannot ping its default gateway.

or:

CLIENT01 resolves no DNS names,
but IP connectivity works.

This immediately narrows the investigation.

13. Determine Scope

Classify the scope:

Single Host

Multiple Hosts

Single VLAN

Single Application

Single Network Segment

Entire Site

Multiple Sites

Scope is one of your strongest troubleshooting clues.

14. Check for Recent Changes

Investigate:

Configuration Changes

Firewall Changes

VLAN Changes

Routing Changes

Cable Changes

Software Updates

Firmware Updates

Device Reboots

New Equipment

Maintenance

A recent change does not automatically mean it caused the incident, but it provides useful context.

15. Step 2 — Establish a Theory

Based on the evidence, create a probable cause.

Example:

Symptom:
CLIENT01 cannot reach gateway.

Evidence:
NIC is up.
IP address is valid.
Switch port is down.

Theory:
Physical connection or switch-port problem.

16. Avoid Random Theories

Do not investigate:

DNS

when the host cannot even reach:

Default Gateway

Start with the evidence closest to the failure.

17. Step 3 — Test the Theory

Test one theory at a time.

Example:

Theory:
Cable failure.

Test:
Replace cable with known-good cable.

If connectivity returns:

Theory Confirmed

If not:

Theory Rejected

Continue investigating.

18. Step 4 — Establish a Plan of Action

Before making a production change, determine:

What Will Change?

What Could Be Affected?

Is Maintenance Required?

Is Backup Required?

Can the Change Be Reversed?

What Is the Rollback Plan?

19. Step 5 — Implement the Solution

Make the minimum required corrective change.

Avoid:

Changing Multiple Variables Simultaneously

Otherwise, you may not know which change fixed the problem.

20. Step 6 — Verify Full Functionality

Do not stop when:

Ping Works

Verify:

IP Connectivity

DNS

Routing

Application Access

Network Services

Monitoring

User Functionality

21. Step 7 — Implement Preventive Measures

Where appropriate, determine whether recurrence can be reduced through:

Monitoring

Configuration Backup

Documentation

Redundancy

Capacity Planning

Firmware Management

Cable Management

Change Control

22. Step 8 — Document Findings

Record:

Problem

Scope

Symptoms

Evidence

Theory

Tests

Root Cause

Corrective Action

Verification

Preventive Recommendation

23. Understand Bottom-Up Troubleshooting

Bottom-up starts with:

Layer 1

and progresses upward:

Physical
   ↓
Data Link
   ↓
Network
   ↓
Transport
   ↓
Application

Useful when symptoms suggest:

No Connectivity

24. Understand Top-Down Troubleshooting

Top-down starts at:

Application

and moves downward.

Useful when:

Network Connectivity Works

but:

Application Does Not

25. Understand Divide-and-Conquer

Divide-and-conquer starts somewhere in the middle.

Example:

Can CLIENT01 ping the default gateway?

If:

YES

you can often move investigation beyond local Layer 1/2 connectivity.

If:

NO

investigate closer to the client.

26. Fault Scenario 1 — Disconnected Cable

Introduce the fault by disconnecting CLIENT01 from SW01.

User symptom:

No network connection.

27. Investigate Scenario 1

Run:

ipconfig /all

Then:

ping <DEFAULT-GATEWAY>

Check:

NIC Link Indicator

Switch Port

Cable

Interface State

28. Switch Evidence

Run:

show interfaces status

You may observe:

CLIENT01 Port:
notconnect

or equivalent.

29. Root Cause — Scenario 1

Document:

Layer:
1 — Physical

Root Cause:
Disconnected Ethernet cable

Corrective Action:
Reconnect cable

Verification:
Link restored
Gateway reachable
Server reachable

30. Fault Scenario 2 — Administratively Disabled Port

Configure a test port:

interface <CLIENT01-PORT>
 shutdown

CLIENT01 loses connectivity.

31. Investigate Scenario 2

Physical cable:

Connected

but switch reports:

Administratively Down

This demonstrates why:

Cable Connected

does not guarantee:

Interface Operational

32. Correct Scenario 2

Configure:

interface <CLIENT01-PORT>
 no shutdown

Verify:

Link Up

Client Connectivity Restored

33. Fault Scenario 3 — Incorrect VLAN

Move CLIENT01’s port into the wrong VLAN.

Example:

Expected:
VLAN 10

Actual:
VLAN 20

34. Investigate VLAN Membership

Run:

show vlan brief

Then inspect the interface:

show interfaces <interface> switchport

Compare:

Expected VLAN
vs
Actual VLAN

35. Correct Scenario 3

Restore:

switchport mode access
switchport access vlan 10

Verify:

Correct VLAN

DHCP

Gateway

Server Access

36. Fault Scenario 4 — Incorrect IP Address

Configure CLIENT01 with:

10.10.50.20

instead of:

10.10.10.20

37. Investigate IP Configuration

Run:

ipconfig /all

Compare against your addressing documentation.

Check:

IP Address

Subnet Mask

Gateway

DNS

38. Root Cause — Scenario 4

Document:

Layer:
3

Root Cause:
Incorrect client IP configuration

Corrective Action:
Restore valid address or DHCP configuration

39. Fault Scenario 5 — Incorrect Subnet Mask

Configure:

IP:
10.10.10.20

Mask:
255.255.255.0

then deliberately replace it with an incorrect mask appropriate for demonstrating the fault.

Observe which destinations the host incorrectly considers local or remote.

40. Investigate Subnet Mask

Compare:

Host IP

Destination IP

Subnet Mask

Determine whether the host believes the destination is:

Local

or:

Remote

An incorrect mask can change forwarding behavior.

41. Fault Scenario 6 — Incorrect Default Gateway

Configure CLIENT01 with an invalid gateway.

Example:

10.10.10.254

when the actual router is:

10.10.10.1

42. Test Local vs Remote Connectivity

Test:

ping <LOCAL-HOST>

Then:

ping <REMOTE-SERVER>

You may observe:

Local:
Works

Remote:
Fails

This is a strong clue toward:

Default Gateway / Routing

43. Verify Gateway Configuration

Run:

ipconfig /all

Then:

route print

Inspect:

0.0.0.0

default route.

44. Fault Scenario 7 — DHCP Failure

Disable or misconfigure the lab DHCP service.

Then renew CLIENT01:

ipconfig /release
ipconfig /renew

Observe the result.

45. Recognize APIPA

A Windows client may self-assign an address from:

169.254.0.0/16

This is:

APIPA

and strongly suggests the client failed to obtain normal DHCP configuration.

46. Troubleshoot DHCP

Check:

Physical Connectivity

VLAN

DHCP Client

DHCP Server

DHCP Scope

Available Leases

DHCP Relay

Firewall

Use:

ipconfig /all

to inspect whether DHCP is enabled.

47. DHCP Relay Scenario

If DHCP server exists on another subnet:

CLIENT
   ↓
Broadcast
   ↓
Router
   ↓
DHCP Server

a relay may be required.

Check router configuration for the appropriate helper/relay mechanism.

48. Fault Scenario 8 — DNS Failure

Keep IP connectivity operational.

Break CLIENT01 DNS configuration.

Then test:

ping <SERVER-IP>

Expected:

Success

Then:

ping server01.ghc.lab

Expected:

Failure

49. Recognize DNS Symptoms

If:

IP Connectivity:
Working

but:

Hostname Connectivity:
Failing

investigate:

DNS

50. Troubleshoot DNS

Run:

ipconfig /all

Then:

nslookup server01.ghc.lab

Check:

Configured DNS Server

DNS Server Reachability

DNS Record

Query Response

51. Clear DNS Cache

Windows:

ipconfig /flushdns

Linux with systemd-resolved:

sudo resolvectl flush-caches

Use only when cache behavior is relevant to the fault.

52. Fault Scenario 9 — Missing Route

Remove a lab route required to reach SERVER01’s network.

User symptom:

Local network works.

Remote server unavailable.

53. Investigate Routing

On RTR01:

show ip route

Look for the destination network.

If absent:

Route Missing

becomes a strong theory.

54. Use Traceroute

From CLIENT01:

tracert <SERVER-IP>

Observe where the path stops.

Compare against your known-good traceroute.

55. Correct the Route

Restore the appropriate route using the routing mechanism used in your lab.

Then verify:

Route Present

Server Reachable

Application Reachable

56. Fault Scenario 10 — Incorrect Static Route

Suppose the intended route is:

10.10.20.0/24
→
Correct Next Hop

but configuration points toward an incorrect next hop.

Investigate:

Destination Network

Prefix

Next Hop

Outgoing Interface

57. Fault Scenario 11 — Duplicate IP Address

Assign the same IPv4 address to two lab hosts.

Possible symptoms:

Intermittent Connectivity

ARP Changes

Connection Resets

Unexpected MAC Mapping

58. Investigate ARP

Windows:

arp -a

Linux:

ip neigh

Observe whether the same IP appears to resolve unexpectedly to different MAC addresses.

59. Verify Duplicate Address

Check both hosts directly.

Document:

Host A IP:

Host A MAC:

Host B IP:

Host B MAC:

Correct the duplicate assignment.

60. Fault Scenario 12 — DNS Record Points to Wrong Server

Configure a lab DNS record so:

server01.ghc.lab

resolves to the wrong IP.

Run:

nslookup server01.ghc.lab

The query succeeds—but returns incorrect information.

This demonstrates:

Successful DNS Query
≠
Correct DNS Data

61. Fault Scenario 13 — Service Port Unavailable

Keep SERVER01 reachable.

Stop a lab web service.

Then test:

ping <SERVER-IP>

Result:

Success

But application access fails.

62. Test the Service Port

Windows PowerShell:

Test-NetConnection <SERVER-IP> -Port 80

Linux:

curl -I http://<SERVER-IP>

or:

nc -vz <SERVER-IP> 80

63. Interpret the Evidence

If:

Ping:
Success

Route:
Success

DNS:
Success

TCP Port:
Failure

move your investigation toward:

Application Service

Server Firewall

Listening Port

64. Check Listening Services

Linux server:

ss -tulpn

Determine whether the expected service is listening.

65. Fault Scenario 14 — Firewall Blocking Application Traffic

Keep server and application operational.

Introduce a lab firewall rule blocking the application port.

You may observe:

Ping:
Success

DNS:
Success

Application:
Failure

66. Compare Layer 3 and Layer 4

This demonstrates:

Layer 3 Reachability

does not guarantee:

Layer 4 Service Reachability

Check:

Firewall Rules

ACLs

Security Policies

Service Port

67. Fault Scenario 15 — Trunk/VLAN Problem

Introduce a VLAN/trunk mismatch between switches where your lab supports it.

Symptoms may include:

Some VLANs Work

One VLAN Fails

Trunk Remains Up

68. Investigate Trunk

Use:

show interfaces trunk

Check:

Trunk State

Native VLAN

Allowed VLANs

Active VLANs

69. Recognize the Scope

If:

VLAN 10:
Works

VLAN 20:
Fails

VLAN 30:
Works

the problem is probably not:

Entire Trunk Down

Investigate VLAN-specific configuration.

70. Fault Scenario 16 — Wireless Connectivity Failure

Use your Network+ wireless lab.

Introduce one fault such as:

Incorrect SSID

Incorrect Password

Wrong Security Mode

Disabled AP

Weak Signal

DHCP Failure

71. Troubleshoot Wireless Systematically

Check:

Is Wi-Fi Enabled?

Is Correct SSID Visible?

Is Signal Adequate?

Can Client Associate?

Does Authentication Succeed?

Does Client Receive IP?

Can Gateway Be Reached?

Can DNS Resolve?

Can Application Be Reached?

72. Wireless Layering

Think:

RF / Signal
    ↓
Association
    ↓
Authentication
    ↓
IP Configuration
    ↓
Routing
    ↓
DNS
    ↓
Application

Do not classify every Wi-Fi complaint as:

Signal Problem

73. Fault Scenario 17 — Performance Degradation

Introduce controlled traffic load using the Lab 16 environment.

Users report:

Network is slow.

Do not treat this as a connectivity failure.

74. Measure Performance

Collect:

Latency

Packet Loss

Jitter

Throughput

Interface Utilization

Errors

Retransmissions

Compare with the Lab 16 baseline.

75. Performance Evidence

Example:

Baseline Latency:
4 ms

Current Latency:
95 ms

Interface Utilization:
98%

Packet Loss:
3%

Probable cause:

Congestion

76. Fault Scenario 18 — Physical Errors

Introduce or simulate a physical-layer problem where safe.

Monitoring shows:

CRC Errors Increasing

Packet Loss Increasing

Throughput Falling

Investigate:

Cable

Connector

Transceiver

NIC

Switch Port

77. Fault Scenario 19 — Speed Negotiation Problem

Expected:

1 Gbps

Actual:

100 Mbps

Check:

NIC

Cable

Switch Port

Auto-Negotiation

Configured Speed

78. Fault Scenario 20 — Duplex Mismatch

Where supported in your lab, simulate:

Side A:
Full Duplex

Side B:
Half Duplex

Observe:

Poor Throughput

Errors

Retransmissions

Restore matching configuration afterward.

79. Use Wireshark for Fault Isolation

Capture traffic during selected scenarios.

Useful filters include:

arp

dns

icmp

dhcp

or:

bootp

depending on Wireshark version.

80. Analyze DHCP Exchange

A healthy DHCP process follows:

Discover
   ↓
Offer
   ↓
Request
   ↓
Acknowledgment

Remember:

DORA

81. Diagnose Missing DHCP Messages

If capture shows:

Discover
Discover
Discover

but no:

Offer

investigate:

DHCP Server

DHCP Relay

VLAN

Broadcast Path

Firewall

82. Analyze DNS

Filter:

dns

Observe:

Query

Response

Requested Name

Returned Address

Response Code

83. Analyze ICMP

Filter:

icmp

Look for:

Echo Request

Echo Reply

Destination Unreachable

Time Exceeded

These messages can provide valuable fault-isolation clues.

84. Use Monitoring Evidence

Review NMS01 for:

Interface Down Alerts

High Utilization

Packet Loss

CPU Alerts

Device Availability

SNMP Traps

Syslog Events

Do not troubleshoot only from the user’s description.

85. Correlate Syslog

Example:

10:14:02
Interface Gi0/1 Down

followed by:

10:14:05
CLIENT01 unreachable

This provides a timeline.

86. Correlate SNMP

Example:

ifOperStatus:
Down

plus:

Syslog:
Link Down

plus:

Ping:
Failure

strongly supports a link/interface fault.

87. Build an Evidence Timeline

Use:

Time	Evidence	Source
10:14:02	Interface down	Syslog
10:14:03	Trap received	SNMP
10:14:05	Host unreachable	Monitoring
10:15:20	Cable replaced	Technician
10:15:24	Interface up	Syslog
10:15:30	Host reachable	Monitoring

88. Understand Root Cause Analysis

Do not confuse:

Symptom

with:

Root Cause

Example:

Symptom:
DNS resolution fails.

Immediate Finding:
DNS server unreachable.

Root Cause:
Incorrect VLAN configuration prevents access to DNS subnet.

89. Use the Five Whys Concept

Example:

Why can't users access application?

Because DNS resolution fails.

Why does DNS fail?

DNS server is unreachable.

Why is it unreachable?

Gateway cannot reach DNS subnet.

Why?

Required route is missing.

Why?

Static route was removed during maintenance.

Root cause:

Routing configuration change

90. Understand Escalation

Not every problem should be solved by the first technician.

Escalate when:

Issue Exceeds Authority

Issue Exceeds Technical Skill

Production Risk Is High

Security Incident Suspected

Provider Involvement Required

Change Approval Required

Hardware Replacement Required

91. Good Escalation

Do not escalate with:

Network doesn't work.

Escalate with:

CLIENT01 cannot reach 10.10.20.0/24.

Layer 1 and VLAN configuration verified.

Gateway reachable.

RTR01 routing table does not contain 10.10.20.0/24.

Issue began after routing maintenance at 14:05.

No changes made pending network engineering approval.

This makes escalation actionable.

92. Understand Change Control

Before making significant production changes:

Identify Change

Assess Impact

Obtain Approval

Schedule Change

Create Rollback Plan

Implement

Validate

Document

Your lab allows experimentation.

Production environments require discipline.

93. Troubleshooting Decision Tree

Use:

User Reports Network Problem
          ↓
Physical Link Up?
     ┌────┴────┐
    NO        YES
     ↓          ↓
Layer 1      Valid IP?
              ┌─┴─┐
             NO  YES
              ↓    ↓
          DHCP/IP Gateway Reachable?
                    ┌─┴─┐
                   NO  YES
                    ↓    ↓
                L2/L3   Remote IP Reachable?
                          ┌─┴─┐
                         NO  YES
                          ↓    ↓
                    Routing   DNS Works?
                               ┌─┴─┐
                              NO  YES
                               ↓    ↓
                              DNS  Service Port?
                                    ┌─┴─┐
                                   NO  YES
                                    ↓    ↓
                               Firewall/ App/
                               Service   Performance

94. Build the Layer-Based Fault Matrix

Layer	Common Faults
Layer 1	Cable, connector, NIC, transceiver, power
Layer 2	VLAN, trunk, STP, MAC, duplex
Layer 3	IP, subnet mask, gateway, routing
Layer 4	Port, ACL, firewall
Layer 7	DNS, application, service

Use the OSI model as an isolation framework, not merely an exam definition.

95. Mission Challenge 1

User reports:

No network.

Evidence:

NIC:
No Link

Switch:
Port Down

First investigation:

Layer 1

96. Mission Challenge 2

Evidence:

IP:
169.254.20.50

Likely problem area:

DHCP

Investigate why the client failed to receive a lease.

97. Mission Challenge 3

Evidence:

Ping 10.10.20.30:
Success

Ping server01.ghc.lab:
Failure

Likely problem:

DNS

98. Mission Challenge 4

Evidence:

Local Hosts:
Reachable

Default Gateway:
Reachable

Remote Network:
Unreachable

Investigate:

Routing

99. Mission Challenge 5

Evidence:

Server Ping:
Success

TCP 443:
Failure

Investigate:

Application Service

Firewall

ACL

Listening Port

100. Mission Challenge 6

Evidence:

VLAN 10:
Working

VLAN 20:
Not Working

VLAN 30:
Working

Investigate:

VLAN 20 configuration

Allowed VLAN list

Access ports

Gateway

rather than assuming the entire switch has failed.

101. Mission Challenge 7

Evidence:

Average Latency:
120 ms

Utilization:
99%

Packet Loss:
4%

Likely:

Congestion

102. Mission Challenge 8

Evidence:

CRC Errors:
Increasing

Throughput:
Poor

Packet Loss:
Increasing

Investigate:

Physical Layer

103. Mission Challenge 9

Evidence:

DNS Query:
Successful

Returned IP:
Wrong

Root cause area:

DNS Record

104. Mission Challenge 10

Evidence:

SSID:
Visible

Authentication:
Successful

IP:
169.254.x.x

Wireless association is working.

Investigate:

DHCP

rather than RF authentication.

105. Final Capstone Fault

Create a multi-layer incident.

Example:

CLIENT01 cannot access
portal.ghc.lab

Do not tell the learner which component is broken.

The learner must investigate from scratch.

106. Capstone Initial Ticket

Provide only:

INC-NET-018

User:
Finance Department

Issue:
Internal portal unavailable

Started:
Approximately 15 minutes ago

Affected:
Multiple Finance users

Recent Change:
Unknown

107. Capstone Investigation

The learner must determine:

Scope

Physical State

IP Configuration

VLAN

Gateway

Routing

DNS

Application Port

Monitoring Evidence

Recent Events

108. Capstone Rule

Do not randomly change configurations.

For every action record:

Observation

Theory

Test

Result

Example:

Observation:
Users can reach gateway.

Theory:
Local switching is functioning.

Test:
Ping remote server IP.

Result:
Fails after gateway.

Continue narrowing the fault.

109. Create a Root Cause Statement

A good statement should explain:

What Failed

Why It Failed

What Was Affected

Example:

Finance users lost access to the internal portal because
VLAN 40 was removed from the SW01–RTR01 trunk during a
configuration change, preventing Finance clients from
reaching their default gateway and upstream services.

110. Create a Corrective Action

Document:

Restored VLAN 40 to the trunk allowed-VLAN list.

Then verify:

Gateway Reachability

DNS

Portal IP

Portal TCP Port

Portal Application

Monitoring

111. Create Preventive Recommendations

Examples:

Configuration Backup

Change Review

Automated Configuration Validation

Interface Monitoring

Syslog Alerting

Network Documentation

Post-Change Testing

Preventive measures should address the actual root cause.

112. Create the Lab Workspace

On your administration workstation:

mkdir -p ~/NetworkPlus-Labs/LAB18/{Captures,Screenshots,Configs,Incidents,Notes}

Create:

touch ~/NetworkPlus-Labs/LAB18/Notes/lab18-notes.md

113. Create Incident Records

Create:

INC01-physical-failure.md

INC02-disabled-interface.md

INC03-vlan-failure.md

INC04-ip-addressing.md

INC05-subnet-mask.md

INC06-default-gateway.md

INC07-dhcp.md

INC08-dns.md

INC09-routing.md

INC10-static-route.md

INC11-duplicate-ip.md

INC12-dns-record.md

INC13-service-failure.md

INC14-firewall.md

INC15-trunk.md

INC16-wireless.md

INC17-performance.md

INC18-physical-errors.md

INC19-speed.md

INC20-duplex.md

INC21-capstone.md

114. Use the Incident Template

# Network Incident Investigation

## Incident ID

## Date and Time

## Reported Problem

## Affected Users

## Scope

## Symptoms

## Recent Changes

## Initial Evidence

## Theory 1

### Test

### Result

### Conclusion

## Theory 2

### Test

### Result

### Conclusion

## Root Cause

## Corrective Action

## Verification

## Preventive Measures

## Escalation Required

## Final Status

115. Evidence to Capture

Capture:

01-known-good-topology.png

02-client-baseline.png

03-switch-baseline.png

04-router-baseline.png

05-monitoring-baseline.png

06-physical-link-failure.png

07-switch-port-down.png

08-disabled-interface.png

09-vlan-mismatch.png

10-incorrect-ip.png

11-subnet-mask-fault.png

12-gateway-fault.png

13-apipa-address.png

14-dhcp-failure.png

15-dhcp-wireshark.png

16-dns-failure.png

17-dns-nslookup.png

18-dns-wireshark.png

19-missing-route.png

20-traceroute-failure.png

21-duplicate-ip.png

22-arp-investigation.png

23-wrong-dns-record.png

24-service-port-failure.png

25-listening-services.png

26-firewall-block.png

27-trunk-vlan-failure.png

28-wireless-failure.png

29-performance-degradation.png

30-crc-errors.png

31-speed-negotiation.png

32-duplex-problem.png

33-snmp-alert.png

34-syslog-event.png

35-evidence-timeline.png

36-capstone-initial-state.png

37-capstone-investigation.png

38-capstone-root-cause.png

39-capstone-corrective-action.png

40-final-verification.png

116. Validation Checklist

Troubleshooting Methodology

• Problem identified

• Scope determined

• Symptoms documented

• Recent changes reviewed

• Theory established

• Theory tested

• Action plan developed

• Solution implemented

• Full functionality verified

• Preventive measures considered

• Findings documented

Troubleshooting Approaches

• Bottom-up understood

• Top-down understood

• Divide-and-conquer understood

• OSI model used for fault isolation

Layer 1

• Disconnected cable diagnosed

• Disabled interface diagnosed

• Physical errors investigated

• CRC errors understood

• Speed problem investigated

• Duplex problem investigated

Layer 2

• VLAN mismatch diagnosed

• Access port configuration verified

• Trunk configuration verified

• Allowed VLANs verified

• MAC information reviewed

Layer 3

• IP address verified

• Subnet mask verified

• Default gateway verified

• Routing table inspected

• Missing route diagnosed

• Incorrect route diagnosed

• Traceroute used

DHCP

• DHCP failure reproduced

• APIPA recognized

• DHCP scope considered

• DHCP relay understood

• DORA captured

• Missing DHCP Offer investigated

DNS

• DNS server verified

• Name resolution tested

• DNS query captured

• Incorrect DNS record diagnosed

• IP vs hostname testing performed

Services

• Server reachability tested

• TCP port tested

• Listening service verified

• Firewall/ACL considered

• Network vs application fault distinguished

Wireless

• SSID checked

• Signal checked

• Association checked

• Authentication checked

• DHCP checked

• Gateway checked

• DNS checked

Performance

• Latency measured

• Packet loss measured

• Throughput reviewed

• Utilization reviewed

• Congestion identified

• Performance compared with baseline

Monitoring

• SNMP evidence reviewed

• Syslog reviewed

• Interface alerts reviewed

• Performance alerts reviewed

• Monitoring evidence correlated

Root Cause Analysis

• Symptoms distinguished from root cause

• Evidence timeline created

• Root cause statement written

• Five Whys concept applied

• Corrective action documented

Escalation

• Escalation criteria understood

• Actionable escalation notes created

• Change-control requirements understood

• Rollback planning understood

Final Capstone

• Initial ticket reviewed

• Scope established

• Evidence collected

• Theories documented

• Tests performed systematically

• Root cause identified

• Corrective action implemented

• Full functionality verified

• Preventive recommendation created

• Incident closed

117. Mission Review

Throughout the Network+ labs you have learned how individual networking technologies work.

You have configured and investigated:

Ethernet
   ↓
Switching
   ↓
VLANs
   ↓
Routing
   ↓
IP Addressing
   ↓
DHCP
   ↓
DNS
   ↓
Wireless
   ↓
Network Services
   ↓
Performance
   ↓
Monitoring

This mission adds the operational skill that connects all of them:

Troubleshooting

You moved from:

Something is broken.

to:

What is the exact symptom?
        ↓
Who is affected?
        ↓
What still works?
        ↓
What changed?
        ↓
At which layer does failure begin?
        ↓
What evidence supports the theory?
        ↓
How can the theory be tested?
        ↓
What is the root cause?
        ↓
What is the safest corrective action?
        ↓
Has full functionality been restored?

The most important principle is:

Do not troubleshoot by guessing. Define the symptom, determine the scope, gather evidence, establish a theory, test it, isolate the root cause, implement the smallest appropriate corrective action, verify full functionality, and document what happened.

Skills Developed

After completing this mission, you should be able to:

• apply a professional troubleshooting methodology

• gather useful incident information

• determine incident scope

• identify recent changes

• troubleshoot systematically

• use bottom-up troubleshooting

• use top-down troubleshooting

• use divide-and-conquer troubleshooting

• isolate Layer 1 faults

• isolate Layer 2 faults

• isolate Layer 3 faults

• troubleshoot DHCP

• troubleshoot DNS

• troubleshoot routing

• troubleshoot VLANs and trunks

• troubleshoot network services

• troubleshoot wireless connectivity

• troubleshoot performance problems

• interpret SNMP monitoring evidence

• interpret Syslog evidence

• analyze packet captures

• build incident timelines

• distinguish symptoms from root causes

• perform root cause analysis

• implement corrective actions

• verify full functionality

• recommend preventive measures

• create actionable escalations

• document network incidents professionally

What’s Next?

Lab 19 — Enterprise Network Troubleshooting Capstone

You have now practiced individual faults.

The next mission removes the guidance.

Instead of being told:

This is a DHCP problem.

or:

This is a VLAN problem.

you will receive:

User Tickets

Monitoring Alerts

Partial Documentation

Network Diagrams

Packet Captures

Device Logs

You must determine what is actually wrong.

The capstone will combine:

• physical connectivity failures

• VLAN problems

• trunk problems

• IPv4 configuration

• DHCP failures

• DNS failures

• routing problems

• wireless problems

• application connectivity

• network performance

• SNMP monitoring

• Syslog

• packet analysis

• multiple simultaneous faults

• root cause analysis

• escalation

• remediation

• verification

• final incident report

The progression becomes:

Networking Fundamentals
        ↓
Configuration
        ↓
Services
        ↓
Performance
        ↓
Monitoring
        ↓
Troubleshooting
        ↓
Enterprise Incident
        ↓
Fault Isolation
        ↓
Root Cause Analysis
        ↓
Remediation
        ↓
Verification
        ↓
Professional Documentation

➡️ Next: Lab 19 — Enterprise Network Troubleshooting Capstone