Lab 19 — Enterprise Network Troubleshooting Capstone

Mission Information

Item	Details
Lab	19
Lab Name	Enterprise Network Troubleshooting Capstone
Track	CompTIA Network+
Difficulty	Advanced
Estimated Time	180–240 minutes
Primary Role	Network Technician / Junior Network Administrator
Environment	GHC Enterprise Network
Mission Type	Capstone Investigation
Primary Systems	CLIENT01, CLIENT02, SW01, SW02, RTR01, SERVER01, DNS01, NMS01, AP01
Primary Tools	Ping, Traceroute, ipconfig, ip, arp, nslookup, dig, Wireshark, SNMP, Syslog, Device CLI
Skills	Troubleshooting, Fault Isolation, Packet Analysis, Monitoring, RCA, Remediation, Verification, Escalation, Documentation

Mission Objective: Take responsibility for a degraded enterprise network without being told where the faults are located. Use user reports, monitoring alerts, network documentation, device configuration, packet captures, logs, and systematic testing to identify multiple independent and related faults, restore services, determine root causes, and produce a professional incident report.

Mission Scenario

It is:

09:10 AM
Monday Morning

Employees have started arriving at the GHC Enterprise office.

Within minutes, the service desk receives several tickets.

At the same time:

NMS01

begins generating alerts.

Management reports:

Several business services are unavailable or unstable. Determine what is happening and restore normal network operations.

You are the network technician assigned to the incident.

You are not given the root causes.

Your investigation begins with only:

User Tickets

Monitoring Alerts

Network Diagram

IP Addressing Documentation

Device Access

Logs

Packet Captures

Your job is to turn those pieces of evidence into:

Symptoms
    ↓
Scope
    ↓
Evidence
    ↓
Theory
    ↓
Testing
    ↓
Fault Isolation
    ↓
Root Cause
    ↓
Remediation
    ↓
Verification

Capstone Rules

This mission is different from previous labs.

You must not:

Randomly Change Configuration

Reboot Devices Without Evidence

Disable Security Controls to "Test"

Change Multiple Variables Simultaneously

Assume the User's Diagnosis Is Correct

Immediately Reset Everything

Every major troubleshooting action must follow:

Observation
    ↓
Theory
    ↓
Test
    ↓
Result
    ↓
Decision

Mission Objectives

By completing this capstone, you will demonstrate your ability to:

interpret user-reported network symptoms
determine incident scope
establish a known-good baseline
use the Network+ troubleshooting methodology
isolate Layer 1 faults
investigate switching problems
troubleshoot VLAN configuration
troubleshoot trunking
troubleshoot IPv4 addressing
troubleshoot DHCP
troubleshoot DNS
troubleshoot default gateways
troubleshoot routing
troubleshoot wireless connectivity
troubleshoot application connectivity
troubleshoot network performance
analyze packet captures
interpret Syslog events
interpret SNMP monitoring data
correlate multiple evidence sources
identify simultaneous faults
distinguish symptoms from root causes
prioritize incidents by business impact
create remediation plans
implement controlled corrective actions
verify end-to-end functionality
determine when escalation is required
perform root cause analysis
produce a professional incident report

1. Enterprise Network Topology

Use the following logical environment:

                         INTERNET
                             |
                             |
                       ┌───────────┐
                       │  RTR01    │
                       │ Edge/Core │
                       └─────┬─────┘
                             |
                        802.1Q Trunk
                             |
                       ┌───────────┐
                       │   SW01    │
                       │   Core    │
                       └─────┬─────┘
                       _____/ \_____
                      /             \
                     /               \
              Trunk /                 \ Trunk
                   /                   \
          ┌───────────┐           ┌───────────┐
          │   SW02    │           │   SW03    │
          │  Access   │           │  Access   │
          └─────┬─────┘           └─────┬─────┘
                |                       |
        ┌───────┼───────┐         ┌─────┼─────┐
        |       |       |         |     |     |
     CLIENT01 CLIENT02 AP01    SERVER01 DNS01 NMS01

2. Enterprise VLAN Architecture

Use:

VLAN	Name	Network	Purpose
10	USERS	`10.10.10.0/24`	Employee endpoints
20	SERVERS	`10.10.20.0/24`	Internal servers
30	MANAGEMENT	`10.10.30.0/24`	Network management
40	WIRELESS	`10.10.40.0/24`	Corporate wireless
50	GUEST	`10.10.50.0/24`	Guest wireless

Default gateways:

VLAN 10 → 10.10.10.1

VLAN 20 → 10.10.20.1

VLAN 30 → 10.10.30.1

VLAN 40 → 10.10.40.1

VLAN 50 → 10.10.50.1

3. Critical Systems

System	Address	Function
RTR01	`10.10.30.1`	Routing / Gateway
SW01	`10.10.30.2`	Core switching
SW02	`10.10.30.3`	User access
SW03	`10.10.30.4`	Server access
SERVER01	`10.10.20.30`	Internal application
DNS01	`10.10.20.53`	DNS
NMS01	`10.10.30.50`	Monitoring / Syslog
AP01	`10.10.30.60`	Wireless AP

4. Expected Healthy Network

Before troubleshooting, understand what should work.

CLIENT01
   ↓
VLAN 10
   ↓
10.10.10.1
   ↓
Inter-VLAN Routing
   ↓
SERVER01

DNS should operate:

CLIENT01
   ↓
DNS Query
   ↓
DNS01
10.10.20.53
   ↓
portal.ghc.lab
   ↓
10.10.20.30

Wireless users should follow:

Laptop
   ↓
AP01
   ↓
VLAN 40
   ↓
DHCP
   ↓
Gateway
   ↓
Enterprise Services

Monitoring should follow:

Routers
Switches
Servers
AP
   ↓
SNMP / Syslog
   ↓
NMS01

5. Initial Incident Tickets

At 09:10, the following tickets exist.

INC-1901 — Finance Connectivity

User:
Finance Department

Problem:
Several desktop users cannot access the internal portal.

Reported:
09:04

Affected:
Multiple Finance users

Location:
Floor 2

Additional Information:
Users say the network worked Friday.

INC-1902 — Hostname Failure

User:
Operations

Problem:
The internal portal does not open using portal.ghc.lab.

Reported:
09:06

Additional Information:
One technician says the server responds when using its IP address.

INC-1903 — Wireless Problem

User:
Sales

Problem:
Corporate Wi-Fi connects, but users cannot access network resources.

Reported:
09:07

Affected:
Several wireless users

INC-1904 — Network Performance

User:
Engineering

Problem:
Network access is unusually slow.

Reported:
09:08

Symptoms:
Slow file transfers
Intermittent application delay
Occasional packet loss

6. Initial Monitoring Alerts

NMS01 reports:

08:58
SW02 uplink state changed

09:01
Multiple VLAN 10 endpoints unreachable

09:05
DNS query failure rate increased

09:07
Wireless client connectivity degraded

09:08
SW01 uplink utilization exceeded 90%

09:09
Packet loss threshold exceeded

Do not assume:

One Alert
=
One Root Cause

The environment may contain multiple simultaneous faults.

7. Prioritize the Incidents

Before troubleshooting, classify:

Business Impact

Number of Users

Critical Services

Network Scope

Security Impact

Create:

Incident	Impact	Scope	Priority
INC-1901
INC-1902
INC-1903
INC-1904

Explain your prioritization.

8. Start with Scope

Determine:

One User?

Several Users?

One VLAN?

One Access Switch?

One Service?

All Wireless Users?

Entire Network?

Scope can dramatically reduce the search space.

9. Investigate CLIENT01

Run:

ipconfig /all

Record:

IPv4 Address:

Subnet Mask:

Default Gateway:

DNS Server:

DHCP Enabled:

DHCP Server:

MAC Address:

10. Test the Local TCP/IP Stack

Run:

ping 127.0.0.1

Then:

ping <CLIENT01-IP>

If these fail, investigate the endpoint before investigating the wider network.

11. Test the Default Gateway

Run:

ping 10.10.10.1

Record:

Success / Failure:

Latency:

Packet Loss:

12. Test the Internal Server by IP

Run:

ping 10.10.20.30

Then:

Test-NetConnection 10.10.20.30 -Port 443

Record the results separately.

Remember:

ICMP Reachability
≠
Application Reachability

13. Test DNS

Run:

nslookup portal.ghc.lab

Record:

DNS Server:

Query:

Response:

Returned Address:

Response Time:

14. Compare Name vs IP Connectivity

Test:

https://10.10.20.30

and:

https://portal.ghc.lab

where supported by the lab application.

Determine whether the problem affects:

Network Connectivity

DNS

Application Service

Certificate / Application Layer

15. Investigate SW02

Check:

show interfaces status

Then:

show vlan brief

Then:

show interfaces trunk

Then:

show mac address-table

Do not modify anything yet.

16. Compare Expected vs Actual VLAN State

Document:

Interface	Expected VLAN	Actual VLAN	Status
CLIENT01	10
CLIENT02	10
AP01	Appropriate VLAN
Uplink	Trunk

17. Investigate the Uplink

Check:

Physical State

Administrative State

Operational State

Speed

Duplex

Errors

CRC Errors

Utilization

Trunk State

A link can be:

UP

while still being:

Misconfigured

or:

Degraded

18. Investigate SW01

Run:

show interfaces status

show interfaces trunk

show vlan brief

show mac address-table

Compare SW01 and SW02.

19. Investigate Allowed VLANs

Determine whether required VLANs are allowed across each trunk.

Expected conceptually:

VLAN 10

VLAN 20

VLAN 30

VLAN 40

VLAN 50

according to your design.

A missing VLAN can create:

Selective Connectivity Failure

while the trunk remains operational.

20. Use the Scope as Evidence

Suppose:

VLAN 10 users:
Failing

VLAN 20:
Working

VLAN 30:
Working

This suggests investigating:

VLAN 10 Specific Configuration

rather than:

Complete Switch Failure

21. Investigate Routing

On RTR01:

show ip interface brief

Then:

show ip route

Verify routes for:

10.10.10.0/24

10.10.20.0/24

10.10.30.0/24

10.10.40.0/24

10.10.50.0/24

22. Verify Gateway Interfaces

Check:

10.10.10.1

10.10.20.1

10.10.30.1

10.10.40.1

10.10.50.1

Ensure required interfaces or subinterfaces are:

Administratively Up

Operationally Up

23. Run Traceroute

From CLIENT01:

tracert 10.10.20.30

Record:

Hop 1:

Hop 2:

Failure Point:

Compare with the expected topology.

24. Investigate DHCP

On a failing endpoint:

ipconfig /all

Look for:

169.254.x.x

If present, investigate:

DHCP Server

Scope

Relay

VLAN

Broadcast Path

25. Capture DHCP Traffic

Wireshark filter:

dhcp

or:

bootp

Look for:

Discover
   ↓
Offer
   ↓
Request
   ↓
Acknowledgment

26. Interpret DHCP Evidence

If you observe:

Discover

Discover

Discover

without:

Offer

the client is asking for configuration but receiving no DHCP response.

Investigate upstream.

27. Investigate DNS01

Verify connectivity:

ping 10.10.20.53

Then query directly:

nslookup portal.ghc.lab 10.10.20.53

Record the returned address.

28. Validate DNS Data

Expected:

portal.ghc.lab
        ↓
10.10.20.30

Do not assume a successful DNS response is correct.

Compare:

Expected IP
vs
Returned IP

29. Capture DNS Traffic

Wireshark:

dns

Observe:

Query

Response

Hostname

Returned Address

Response Code

Response Time

30. Investigate Wireless Users

For INC-1903, separate:

RF Connectivity

Association

Authentication

IP Configuration

Routing

DNS

Application Access

31. Wireless Troubleshooting Workflow

Use:

SSID Visible?
     ↓
Client Associated?
     ↓
Authentication Successful?
     ↓
Valid IP Address?
     ↓
Gateway Reachable?
     ↓
DNS Reachable?
     ↓
Application Reachable?

32. Inspect Wireless Client Configuration

Record:

SSID:

Signal:

IPv4:

Subnet Mask:

Gateway:

DNS:

DHCP:

If the client has:

169.254.x.x

do not immediately blame:

Wi-Fi Signal

Association may already be working.

33. Investigate AP01

Verify:

AP Availability

Management Connectivity

SSID Configuration

Security Configuration

VLAN Mapping

DHCP Path

Uplink

34. Investigate Performance Incident

For INC-1904, establish measurable evidence.

Run:

ping <DEFAULT-GATEWAY> -n 50

Then:

ping 10.10.20.30 -n 50

Record:

Minimum RTT:

Maximum RTT:

Average RTT:

Packet Loss:

35. Compare Against Baseline

From previous labs, compare:

Normal Latency
vs
Current Latency

Normal Packet Loss
vs
Current Packet Loss

Normal Utilization
vs
Current Utilization

36. Inspect Interface Utilization

Use NMS01.

Identify interfaces showing:

> 80%

> 90%

> 95%

Determine whether high utilization is:

Momentary

or:

Sustained

37. Inspect Interface Errors

Check:

Input Errors

Output Errors

CRC Errors

Discards

Drops

Increasing counters may indicate:

Physical Problem

Congestion

Duplex Problem

Faulty Transceiver

Faulty Cable

38. Check Speed and Duplex

Compare both ends.

Expected:

1 Gbps
Full Duplex

Example abnormal state:

Side A:
1 Gbps Full

Side B:
100 Mbps

or another intentionally introduced mismatch.

39. Analyze Traffic with Wireshark

Useful filters:

arp

icmp

dns

tcp.analysis.retransmission

tcp.analysis.duplicate_ack

Use packet analysis as evidence—not as a replacement for structured troubleshooting.

40. Investigate Retransmissions

Large numbers of:

TCP Retransmissions

may indicate:

Packet Loss

Congestion

Physical Errors

Unstable Path

Correlate with:

Interface Statistics

Latency

Packet Loss

Monitoring

41. Review Syslog

Search logs around:

08:50–09:15

Look for:

Interface State Changes

Trunk Changes

VLAN Changes

Routing Events

Authentication Events

Device Reboots

Configuration Changes

42. Build the Incident Timeline

Example:

Time	Event	Source
08:55	Configuration session started	Syslog
08:58	SW02 uplink changed	Syslog
09:01	VLAN 10 hosts unreachable	NMS
09:04	Finance ticket opened	Service Desk
09:05	DNS failures increased	NMS
09:07	Wireless issue reported	Service Desk
09:08	Utilization exceeded 90%	SNMP
09:09	Packet loss threshold exceeded	NMS

43. Investigate Configuration Changes

Where supported:

show running-config

Compare with:

Known-Good Configuration

or configuration backup.

Look specifically for differences affecting:

Interfaces

VLANs

Trunks

Routing

DHCP Relay

ACLs

Logging

44. Do Not Automatically Roll Back Everything

A configuration difference is:

Evidence

not automatically:

Root Cause

Determine whether it explains the observed symptoms.

45. Create a Theory Matrix

Use:

Theory	Evidence For	Evidence Against	Test	Result
Physical failure
VLAN issue
DHCP failure
DNS failure
Routing failure
Wireless issue
Congestion

46. Fault Isolation Principle

Every successful test should reduce the possible fault domain.

Example:

CLIENT01 NIC
     ↓
Working

CLIENT01 → SW02
     ↓
Working

SW02 VLAN Membership
     ↓
Working

SW02 → SW01 Trunk
     ↓
Failure

Your fault domain has now narrowed significantly.

47. Investigate ARP

Windows:

arp -a

Linux:

ip neigh

Look for:

Incomplete Entries

Unexpected MAC Addresses

Duplicate IP Symptoms

48. Duplicate IP Investigation

If connectivity is intermittent:

Ping Works
     ↓
Ping Fails
     ↓
Ping Works

and ARP mappings change unexpectedly, investigate:

Duplicate IPv4 Address

49. Validate the Application Service

If SERVER01 responds to ping:

Test-NetConnection 10.10.20.30 -Port 443

If:

Ping:
Success

TCP 443:
Failure

investigate:

Application

Server Firewall

ACL

Listening Service

50. Verify Server Listening Ports

On Linux SERVER01:

ss -tulpn

or:

sudo ss -lntp

Confirm the expected service is listening.

51. Separate Network and Application Problems

Do not escalate to networking solely because:

Application Does Not Open

Likewise, do not escalate to application support when:

Server Network Is Unreachable

Determine the failing layer.

52. Identify Fault 1

Your first root cause should explain one or more tickets.

Document:

Fault ID:
FAULT-01

Affected Systems:

Affected VLAN:

Symptoms:

Evidence:

Root Cause:

Corrective Action:

53. Remediate Fault 1

Before changing anything:

Record Current Configuration

Document Proposed Change

Determine Impact

Create Rollback Plan

Then make only the required change.

54. Verify Fault 1

After remediation, test:

Client IP Configuration

Gateway Reachability

Server Reachability

DNS

Application

Monitoring

Do not close the entire incident yet.

Other faults may remain.

55. Identify Fault 2

Continue investigating unresolved tickets.

Document:

FAULT-02

Symptoms:

Scope:

Evidence:

Root Cause:

Corrective Action:

56. Verify Fault 2

Perform:

Before Test

Corrective Action

After Test

Record measurable differences.

Example:

Before:
portal.ghc.lab → 10.10.20.99

After:
portal.ghc.lab → 10.10.20.30

57. Identify Fault 3

Investigate the wireless incident separately if necessary.

Document:

FAULT-03

Wireless Association:

Authentication:

IP Address:

Gateway:

DNS:

Root Cause:

58. Verify Wireless Recovery

Test:

SSID Association

Authentication

DHCP Lease

Gateway

DNS

Internal Application

Internet

where permitted.

59. Identify Fault 4

Investigate performance degradation.

Record:

FAULT-04

Latency:

Packet Loss:

Utilization:

Errors:

Speed:

Duplex:

Retransmissions:

60. Verify Performance Recovery

Repeat the same measurements used before remediation.

Compare:

Metric	Before	After
Latency
Packet Loss
Utilization
Errors
Throughput

61. Optional Hidden Fault — Duplicate IP

For instructor-led deployment, introduce:

Duplicate Address

between two non-critical lab systems.

Do not tell the learner.

Symptoms should be:

Intermittent Reachability

Changing ARP Entry

Unexpected Connection Failures

62. Optional Hidden Fault — Incorrect DNS Record

Change:

portal.ghc.lab

from:

10.10.20.30

to:

10.10.20.99

The learner should discover that:

DNS Works

but:

DNS Data Is Wrong

63. Optional Hidden Fault — Missing VLAN

Remove VLAN 10 or VLAN 40 from one trunk’s allowed list.

The trunk remains:

UP

but selected traffic fails.

64. Optional Hidden Fault — DHCP Relay

Remove the required relay configuration for the wireless VLAN.

Wireless clients should:

Associate Successfully

but fail to obtain:

Valid DHCP Configuration

65. Optional Hidden Fault — Physical Degradation

Introduce a controlled physical problem that generates:

CRC Errors

Packet Loss

Poor Throughput

This forces learners to distinguish:

Congestion

from:

Physical Degradation

66. Optional Hidden Fault — Application Service

Stop the HTTPS service on SERVER01.

Network connectivity remains operational.

The learner should isolate the failure above Layer 3.

67. Multiple Fault Principle

A critical capstone lesson is:

Fixing One Problem
≠
Incident Resolved

After every remediation:

Retest All Reported Symptoms

68. Recheck the Ticket Queue

After each corrective action, ask:

INC-1901 resolved?

INC-1902 resolved?

INC-1903 resolved?

INC-1904 resolved?

Continue until all known symptoms are accounted for.

69. Verify Monitoring Recovery

NMS01 should eventually show:

Devices:
UP

Critical Interfaces:
UP

Packet Loss:
Normal

Latency:
Normal

Utilization:
Within Baseline

Active Critical Alerts:
None

70. Verify Syslog

Confirm no new unexpected:

Link Flaps

Routing Failures

VLAN Changes

Device Errors

appear after remediation.

71. Verify SNMP

Review:

Interface Operational Status

Traffic Counters

CPU

Memory

Errors

Utilization

Confirm the environment is stable.

72. Perform End-to-End Validation

From CLIENT01:

CLIENT01
   ↓
SW02
   ↓
SW01
   ↓
RTR01
   ↓
SERVER VLAN
   ↓
SERVER01

Test every major dependency.

73. Validate Layer 1

Confirm:

Link Up

Correct Speed

Correct Duplex

No Increasing Errors

74. Validate Layer 2

Confirm:

Correct VLAN

Correct Trunk

Required VLANs Allowed

Expected MAC Learning

75. Validate Layer 3

Confirm:

Correct IP

Correct Mask

Correct Gateway

Required Routes Present

76. Validate DHCP

Confirm:

Discover

Offer

Request

ACK

and verify correct lease parameters.

77. Validate DNS

Confirm:

portal.ghc.lab
        ↓
Correct IP

Test both:

Forward Lookup

and any other relevant records used in the lab.

78. Validate Application

Test:

Test-NetConnection 10.10.20.30 -Port 443

Then open:

portal.ghc.lab

Confirm actual application functionality.

79. Validate Wireless

Confirm:

SSID

Authentication

DHCP

Gateway

DNS

Application

80. Validate Performance

Run:

Latency Test

Packet-Loss Test

Throughput Test

Monitoring Review

Compare with baseline.

81. Determine Root Cause vs Contributing Factors

Your report should distinguish:

Root Cause

from:

Contributing Factor

Example:

Root Cause:
VLAN 10 removed from trunk.

Contributing Factor:
No configuration-change alert was enabled.

82. Create Root Cause Statements

Each statement should answer:

What Failed?

Why Did It Fail?

What Was Affected?

Why Was It Not Detected Earlier?

83. Example Root Cause Statement

Finance users lost connectivity because VLAN 10 was
removed from the SW02 uplink's allowed VLAN list during
a configuration change.

The physical trunk remained operational, causing basic
interface monitoring to remain healthy while VLAN 10
traffic could no longer traverse the uplink.

Notice that this explains:

Failure

Cause

Impact

Detection Gap

84. Create Preventive Recommendations

Consider:

Configuration Backups

Automated Configuration Comparison

Change Control

Post-Change Validation

SNMP Monitoring

Syslog Alerting

DHCP Monitoring

DNS Monitoring

Synthetic Application Tests

Interface Error Monitoring

Capacity Alerts

85. Avoid Generic Recommendations

Instead of:

Improve Monitoring

write:

Configure an alert when critical VLANs disappear from
core-to-access trunk allowed-VLAN lists.

Specific recommendations are more useful.

86. Determine Whether Escalation Was Required

For each fault, document:

Resolved Locally

or:

Escalated

If escalated, record:

Team:

Reason:

Evidence Provided:

Business Impact:

87. Build an Escalation Package

A professional escalation should include:

Incident ID

Affected Systems

Scope

Start Time

Symptoms

Tests Completed

Evidence

Suspected Fault Domain

Changes Already Made

Business Impact

88. Example Escalation

INC-1904

Engineering users are experiencing 15–20% packet loss
across the SW01 WAN uplink.

Local access switching, VLAN configuration, and client
addressing have been verified.

SNMP reports increasing input errors on the WAN
interface beginning at 08:52.

Packet capture shows significant TCP retransmissions.

No configuration changes have been made to the WAN
interface.

Requesting network engineering/provider investigation.

89. Create the Capstone Workspace

Create:

mkdir -p ~/NetworkPlus-Labs/LAB19/{Tickets,Evidence,Captures,Configs,Logs,Screenshots,Reports}

90. Create Investigation Files

Create:

INC-1901-finance.md

INC-1902-dns.md

INC-1903-wireless.md

INC-1904-performance.md

FAULT-01.md

FAULT-02.md

FAULT-03.md

FAULT-04.md

incident-timeline.md

root-cause-analysis.md

final-incident-report.md

91. Use the Fault Investigation Template

# Fault Investigation

## Fault ID

## Related Incident

## Reported Symptom

## Scope

## Initial Evidence

## Theory 1

### Evidence Supporting Theory

### Test

### Result

### Conclusion

## Theory 2

### Evidence Supporting Theory

### Test

### Result

### Conclusion

## Root Cause

## Corrective Action

## Verification

## Preventive Recommendation

## Status

92. Build the Incident Timeline

Use:

# Incident Timeline

| Time | Event | Evidence Source | Significance |
|---|---|---|---|
| | | | |
| | | | |
| | | | |

Include:

Monitoring Events

User Reports

Configuration Changes

Tests

Remediation

Recovery

93. Create the Root Cause Analysis

Use:

# Root Cause Analysis

## Executive Summary

## Business Impact

## Incident Scope

## Timeline

## Fault 01

### Symptoms

### Evidence

### Root Cause

### Corrective Action

### Verification

## Fault 02

### Symptoms

### Evidence

### Root Cause

### Corrective Action

### Verification

## Fault 03

### Symptoms

### Evidence

### Root Cause

### Corrective Action

### Verification

## Fault 04

### Symptoms

### Evidence

### Root Cause

### Corrective Action

### Verification

## Contributing Factors

## Detection Gaps

## Preventive Recommendations

## Final Status

94. Create the Final Incident Report

Use:

# Enterprise Network Incident Report

## Incident ID

NET-CAPSTONE-019

## Incident Date

## Start Time

## Resolution Time

## Total Duration

## Severity

## Business Impact

## Affected Users

## Affected Services

## Initial Symptoms

## Incident Timeline

## Technical Investigation

## Root Causes

## Corrective Actions

## Validation Results

## Monitoring Status

## Preventive Actions

## Lessons Learned

## Final Status

RESOLVED / ESCALATED

95. Evidence to Capture

Capture:

01-enterprise-topology.png

02-initial-ticket-queue.png

03-initial-monitoring-alerts.png

04-client01-ipconfig.png

05-client01-gateway-test.png

06-server-ip-test.png

07-dns-test.png

08-sw02-interface-status.png

09-sw02-vlan-status.png

10-sw02-trunk-status.png

11-sw01-trunk-status.png

12-routing-table.png

13-traceroute.png

14-dhcp-client-state.png

15-dhcp-capture.png

16-dns-query.png

17-dns-capture.png

18-wireless-client-state.png

19-ap-status.png

20-performance-ping.png

21-interface-utilization.png

22-interface-errors.png

23-speed-duplex.png

24-tcp-retransmissions.png

25-syslog-timeline.png

26-snmp-alerts.png

27-configuration-comparison.png

28-fault01-evidence.png

29-fault01-remediation.png

30-fault02-evidence.png

31-fault02-remediation.png

32-fault03-evidence.png

33-fault03-remediation.png

34-fault04-evidence.png

35-fault04-remediation.png

36-dhcp-verification.png

37-dns-verification.png

38-wireless-verification.png

39-performance-verification.png

40-final-monitoring-dashboard.png

41-final-application-test.png

42-final-network-validation.png

96. Final Validation Checklist

Incident Management

All tickets reviewed
Business impact determined
Incident scope established
Priorities assigned
Incident timeline created

Layer 1

Physical connectivity verified
Interface status verified
Speed verified
Duplex verified
Error counters reviewed

Layer 2

VLAN membership verified
Trunks verified
Allowed VLANs verified
MAC address tables reviewed

Layer 3

Client addressing verified
Subnet masks verified
Default gateways verified
Routing tables verified
Traceroute performed

DHCP

DHCP configuration verified
Lease information reviewed
DORA process understood
DHCP packet capture analyzed
Relay configuration checked where applicable

DNS

DNS server reachable
DNS configuration verified
Direct DNS query performed
Returned address validated
DNS capture analyzed

Wireless

SSID verified
Association verified
Authentication verified
DHCP verified
Gateway verified
DNS verified
Application connectivity verified

Services

SERVER01 reachable
Required TCP port reachable
Listening service verified
Firewall/ACL considered
Application functionality verified

Performance

Latency measured
Packet loss measured
Utilization reviewed
Interface errors reviewed
TCP retransmissions reviewed
Before/after metrics compared

Monitoring

SNMP reviewed
Syslog reviewed
Alerts correlated
Event timeline created
Monitoring returned to baseline

Troubleshooting

Symptoms documented
Scope determined
Theories created
Theories tested
Evidence collected
Fault domains isolated
Multiple faults considered
Root causes identified

Remediation

Proposed changes documented
Impact considered
Rollback considered
Corrective actions implemented
All original symptoms retested

Root Cause Analysis

Root causes documented
Contributing factors documented
Detection gaps identified
Preventive recommendations created

Documentation

Tickets completed
Fault investigation files completed
Packet captures saved
Screenshots saved
Incident timeline completed
RCA completed
Final incident report completed

97. Capstone Success Criteria

You successfully complete the mission when:

All Critical Interfaces
=
Operational

Client Addressing
=
Correct

DHCP
=
Operational

DNS
=
Correct

Routing
=
Operational

Wireless
=
Operational

Internal Application
=
Reachable

Packet Loss
=
Within Baseline

Network Performance
=
Within Baseline

Monitoring
=
Healthy

and:

Every Root Cause
=
Documented

98. Mission Review

This capstone represents the transition from:

Learning Networking Technologies

to:

Operating Networks

Throughout the Network+ labs you built knowledge across:

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

In this mission, those topics were no longer isolated.

A real incident may begin with:

"The portal doesn't work."

But the actual fault could exist in:

Physical Connectivity

VLAN Configuration

Routing

DHCP

DNS

Firewall

Application Service

Wireless

Network Performance

Your responsibility is not to guess.

Your responsibility is to:

Observe
   ↓
Measure
   ↓
Form a Theory
   ↓
Test
   ↓
Narrow the Fault Domain
   ↓
Identify Root Cause
   ↓
Remediate
   ↓
Verify
   ↓
Document

The most important lesson from this capstone is:

Professional network troubleshooting is an evidence-driven process. The objective is not merely to make the network work again, but to understand what failed, why it failed, what was affected, how the fix was verified, and how the organization can reduce the likelihood or impact of the same failure occurring again.

Skills Developed

After completing this capstone, you should be able to:

troubleshoot enterprise network incidents systematically
prioritize incidents based on business impact
determine fault scope
interpret endpoint configuration
troubleshoot physical connectivity
troubleshoot VLANs and trunks
troubleshoot IPv4 addressing
troubleshoot gateways
troubleshoot routing
troubleshoot DHCP
troubleshoot DNS
troubleshoot wireless connectivity
troubleshoot network services
troubleshoot application reachability
troubleshoot network performance
analyze packet captures
interpret interface counters
interpret SNMP monitoring
interpret Syslog
correlate multiple evidence sources
construct incident timelines
investigate multiple simultaneous faults
isolate fault domains
distinguish symptoms from root causes
create controlled remediation plans
verify end-to-end functionality
determine when escalation is required
write root cause statements
recommend preventive controls
produce professional incident documentation

What’s Next?

Lab 20 — Network+ Final Practical Assessment

You have now completed guided configuration labs, troubleshooting missions, and an enterprise troubleshooting capstone.

The final lab removes most of the guidance.

You will receive:

Business Requirements

Network Diagram

Device Inventory

User Requirements

Security Requirements

Service Requirements

Your responsibility will be to:

Design
   ↓
Configure
   ↓
Validate
   ↓
Secure
   ↓
Monitor
   ↓
Troubleshoot
   ↓
Document

The final assessment will test your ability to combine the complete Network+ skill set into one practical enterprise networking mission.

➡️ Next: Lab 20 — Network+ Final Practical Assessment