Runbook 01 — Network Connectivity Troubleshooting

Runbook Information

Item	Details
Runbook	01
Runbook Name	Network Connectivity Troubleshooting
Track	CompTIA Network+
Type	Network Operations Runbook
Primary Role	Network Technician / Network Administrator
Difficulty	Intermediate
Use Case	Network connectivity failure or degradation
Primary Tools	Ping, Traceroute, ipconfig, ip, ARP, nslookup, dig, Wireshark, SNMP, Syslog, Device CLI
Outcome	Isolate, remediate, verify, escalate, and document connectivity incidents

Runbook Objective: Provide network operations teams with a consistent procedure for investigating connectivity incidents from the endpoint through the network infrastructure to the destination service.

When to Use This Runbook

Use this runbook when users report:

"No network connection."

"I cannot access the server."

"The Internet is not working."

"I cannot reach another network."

"The application is unavailable."

"The network keeps disconnecting."

"Some users can connect but others cannot."

"I can access the server by IP but not by name."

This runbook can be used for:

• single-user connectivity incidents

• multiple-user outages

• VLAN connectivity problems

• gateway failures

• routing problems

• DHCP failures

• DNS failures

• network-service connectivity

• intermittent connectivity

• partial network outages

• site-level connectivity incidents

1. Troubleshooting Principle

Do not begin with configuration changes.

Begin with:

Symptom
   ↓
Scope
   ↓
Evidence
   ↓
Fault Domain
   ↓
Theory
   ↓
Test
   ↓
Root Cause
   ↓
Remediation
   ↓
Verification

The objective is not simply:

Make It Work

The objective is:

Understand Why It Failed
        +
Restore Service Safely
        +
Verify Recovery
        +
Prevent Recurrence

2. Record the Incident

Create an incident record.

Capture:

Incident ID:

Date:

Time:

Reported By:

Affected User(s):

Location:

Affected Device(s):

Affected Service:

Business Impact:

Current Status:

Example:

Incident ID:
INC-NET-1042

Reported:
09:15

Affected:
Finance Department

Problem:
Users cannot access internal application.

Impact:
15 users unable to process transactions.

3. Record the Exact Symptom

Avoid:

Network is down.

Instead document:

CLIENT01 cannot reach 10.10.20.30.

Default gateway remains reachable.

or:

Users can reach 10.10.20.30 by IP but
portal.ghc.lab does not resolve.

Precise symptoms dramatically improve troubleshooting.

4. Determine Scope

Identify whether the problem affects:

One User

One Device

Multiple Users

One Department

One VLAN

One Switch

One Application

One Site

Multiple Sites

Entire Network

Ask:

Who is affected?

Who is not affected?

What works?

What does not work?

5. Determine Business Impact

Classify:

Low

Medium

High

Critical

Consider:

Number of Users

Criticality of Service

Revenue Impact

Operational Impact

Security Impact

Duration

6. Check for Known Incidents

Before deep troubleshooting, check:

Monitoring Dashboard

Service Desk

Maintenance Calendar

Provider Status

Change Records

Network Alerts

Determine whether the problem is already known.

7. Check Recent Changes

Ask:

What changed recently?

Review:

• switch configuration

• router configuration

• firewall rules

• VLAN configuration

• routing changes

• DHCP changes

• DNS changes

• firmware upgrades

• device replacements

• cable changes

• maintenance activity

Record:

Recent Change:

Change ID:

Time:

Engineer:

8. Establish the Expected Path

Determine the expected communication path.

Example:

CLIENT01
   ↓
SW02
   ↓
SW01
   ↓
RTR01
   ↓
SW03
   ↓
SERVER01

Identify every major dependency.

9. Start with the Endpoint

Check physical connectivity.

Verify:

Power

Ethernet Cable

Link Indicator

NIC Enabled

Wi-Fi Enabled

Correct SSID

If Ethernet:

Link LED:
UP / DOWN

If wireless:

Associated:
YES / NO

10. Check Interface State

Windows:

Get-NetAdapter

or:

ipconfig /all

Linux:

ip link

Look for:

UP

DOWN

DISCONNECTED

DISABLED

11. Verify TCP/IP Stack

Windows:

ping 127.0.0.1

Linux:

ping -c 4 127.0.0.1

If loopback fails, investigate the local TCP/IP stack or endpoint.

12. Check IP Configuration

Windows:

ipconfig /all

Linux:

ip addr

Record:

IP Address:

Subnet Mask / Prefix:

Default Gateway:

DNS Server:

DHCP Enabled:

DHCP Server:

13. Check for APIPA

Windows may assign:

169.254.x.x

when DHCP fails.

If APIPA exists:

Investigate DHCP

Do not immediately troubleshoot DNS or application services.

14. Validate the IP Address

Compare the client’s address against the expected VLAN.

Example:

Expected:

VLAN 10
10.10.10.0/24

Actual:

10.10.20.45

Possible causes:

Incorrect VLAN

Incorrect Static IP

Incorrect DHCP Scope

15. Validate the Subnet Mask

Check whether the configured subnet mask or prefix is correct.

Incorrect masks can cause hosts to incorrectly classify destinations as:

Local

or:

Remote

16. Validate the Default Gateway

Verify the configured gateway belongs to the client’s subnet.

Example:

Client:
10.10.10.20/24

Expected Gateway:
10.10.10.1

17. Test the Client Address

Windows:

ping <CLIENT-IP>

If this fails, continue investigating the endpoint.

18. Test the Default Gateway

Run:

ping <DEFAULT-GATEWAY>

or:

ping -c 4 <DEFAULT-GATEWAY>

Record:

Gateway Reachable:
YES / NO

19. Decision Point — Gateway Unreachable

If the gateway cannot be reached, investigate:

Physical Connectivity

NIC

Cable

Switch Port

VLAN

IP Address

Subnet Mask

Gateway

ARP

Do not move directly to DNS troubleshooting.

20. Check ARP

Windows:

arp -a

Linux:

ip neigh

Look for the gateway.

Expected:

Gateway IP
   ↓
Gateway MAC Address

21. Clear ARP Only When Required

Windows:

arp -d *

Use cache clearing only when stale or incorrect ARP information is a reasonable theory.

Do not use cache clearing as a default troubleshooting action.

22. Check the Access Switch

Identify the endpoint’s switch port.

Run:

show interfaces status

Verify:

Port:
UP

Speed:
Expected

Duplex:
Expected

23. Check Interface Errors

Inspect:

CRC Errors

Input Errors

Output Errors

Drops

Discards

Link Flaps

Increasing errors can indicate:

Bad Cable

Bad Transceiver

NIC Problem

Duplex Problem

Physical Interference

24. Verify VLAN Membership

Run:

show vlan brief

Confirm:

Endpoint Port
        ↓
Expected VLAN

25. Inspect the Switch Port

Where supported:

show interfaces <interface> switchport

Verify:

Administrative Mode

Operational Mode

Access VLAN

Native VLAN

26. Verify MAC Learning

Run:

show mac address-table

Confirm the endpoint’s MAC address appears on the expected interface.

If no MAC is learned, investigate:

Endpoint

Cable

NIC

Switch Port

VLAN

27. Check Trunk Connectivity

If traffic must cross switches:

show interfaces trunk

Verify:

Trunk:
UP

Required VLAN:
Allowed

Required VLAN:
Active

28. Look for Selective VLAN Failure

Example:

VLAN 10:
FAILED

VLAN 20:
WORKING

VLAN 30:
WORKING

This suggests:

VLAN-Specific Problem

rather than:

Complete Trunk Failure

29. Test Another Device

Test another endpoint on:

Same VLAN

Then test an endpoint on:

Different VLAN

This helps determine scope.

30. Test a Remote IP

If the gateway works:

ping <REMOTE-IP>

Example:

ping 10.10.20.30

Record:

Remote IP Reachable:
YES / NO

31. Decision Point — Remote IP Fails

If:

Gateway:
WORKING

Remote IP:
FAILING

investigate:

Routing

ACLs

Firewall

Remote Network

Return Route

Destination Host

32. Run Traceroute

Windows:

tracert 10.10.20.30

Linux:

traceroute 10.10.20.30

Identify:

Last Successful Hop

and:

First Failure Point

33. Check Router Interfaces

Run:

show ip interface brief

Verify required interfaces are:

UP / UP

34. Check Routing Table

Run:

show ip route

Verify a route exists for the destination network.

Example:

10.10.20.0/24

35. Validate the Route

Check:

Destination Network

Prefix Length

Next Hop

Outgoing Interface

Route Source

A route can exist and still be incorrect.

36. Check the Return Path

Connectivity requires:

Forward Path
+
Return Path

A valid route from:

CLIENT → SERVER

does not guarantee a valid route from:

SERVER → CLIENT

37. Test DNS Separately

If remote IP connectivity works but hostname access fails:

nslookup portal.ghc.lab

or Linux:

dig portal.ghc.lab

38. Decision Point — DNS Failure

If:

IP Connectivity:
WORKING

Hostname Connectivity:
FAILING

investigate:

DNS Client Configuration

DNS Server Reachability

DNS Records

DNS Service

Firewall

39. Verify Configured DNS Server

Windows:

ipconfig /all

Linux:

cat /etc/resolv.conf

or:

resolvectl status

40. Query DNS Directly

Example:

nslookup portal.ghc.lab 10.10.20.53

Determine whether:

DNS Server Responds

Record Exists

Returned Address Is Correct

41. Successful DNS Is Not Enough

Suppose:

portal.ghc.lab

returns:

10.10.20.99

but expected:

10.10.20.30

DNS is responding, but the record is wrong.

42. Test the Application Port

If IP and DNS work:

Test-NetConnection 10.10.20.30 -Port 443

Linux:

nc -vz 10.10.20.30 443

or:

curl -I https://portal.ghc.lab

43. Decision Point — Port Failure

If:

Ping:
SUCCESS

DNS:
SUCCESS

TCP 443:
FAILURE

investigate:

Application Service

Host Firewall

Network Firewall

ACL

Listening Port

44. Check the Server

On Linux:

ss -lntp

Verify the expected service is listening.

Example:

TCP 443
LISTENING

45. Check Firewalls and ACLs

Review controls between:

Source
   ↓
Destination

Verify:

Source Address

Destination Address

Protocol

Port

Direction

Action

Do not disable the firewall simply to see whether connectivity returns.

46. Troubleshoot DHCP

If the endpoint lacks valid addressing:

Windows:

ipconfig /release
ipconfig /renew

Then:

ipconfig /all

47. Check DHCP Scope

Verify:

Scope Active

Available Addresses

Correct Subnet

Correct Mask

Correct Gateway

Correct DNS

Exclusions

Reservations

48. Check DHCP Relay

If DHCP exists on another subnet, verify the gateway/relay configuration.

Expected:

Client
   ↓
DHCP Broadcast
   ↓
Gateway / Relay
   ↓
DHCP Server

49. Capture DHCP Traffic

Wireshark:

dhcp

or:

bootp

Look for:

Discover
Offer
Request
ACK

50. Interpret DHCP Capture

If:

Discover
Discover
Discover

but no:

Offer

investigate:

DHCP Server

Relay

VLAN

Broadcast Path

Firewall

51. Troubleshoot Wireless Connectivity

For wireless users, follow:

RF
 ↓
SSID
 ↓
Association
 ↓
Authentication
 ↓
DHCP
 ↓
Gateway
 ↓
Routing
 ↓
DNS
 ↓
Application

52. Check Wireless State

Record:

SSID:

Signal Strength:

Authentication:

IPv4 Address:

Gateway:

DNS:

53. Wi-Fi Connected Does Not Mean Network Connected

A client may successfully:

Associate
+
Authenticate

but still fail:

DHCP

or:

Routing

or:

DNS

Treat each stage separately.

54. Troubleshoot Intermittent Connectivity

If connectivity is intermittent, investigate:

Link Flaps

Packet Loss

Duplicate IP

Wireless Interference

Interface Errors

Congestion

Routing Instability

DHCP Lease Issues

55. Measure Packet Loss

Windows:

ping <DESTINATION> -n 50

Linux:

ping -c 50 <DESTINATION>

Record:

Sent:

Received:

Lost:

Loss Percentage:

Average Latency:

56. Check for Duplicate IP Addresses

Symptoms can include:

Intermittent Connectivity

Changing ARP Entries

Unexpected Session Drops

Check:

arp -a

or:

ip neigh

57. Troubleshoot Slow Connectivity

If users report:

"The network is slow."

measure:

Latency

Packet Loss

Jitter

Throughput

Utilization

Interface Errors

Do not treat performance complaints as binary connectivity failures.

58. Check Interface Utilization

Use the monitoring platform.

Compare:

Current Utilization
vs
Baseline

Sustained:

90–100%

may indicate congestion.

59. Check Monitoring Alerts

Review:

Device Down

Interface Down

High Utilization

Packet Loss

Latency

CPU

Memory

Interface Errors

Correlate alert timestamps with user reports.

60. Review Syslog

Look for:

Interface Down

Interface Up

Configuration Changes

VLAN Changes

Routing Events

Device Reboots

Authentication Events

61. Review SNMP Evidence

Check:

Interface Status

Interface Counters

Errors

Discards

Utilization

Device Availability

62. Build an Incident Timeline

Example:

Time	Event	Source
09:12	Interface down	Syslog
09:13	Host unreachable	NMS
09:15	User ticket opened	Service Desk
09:20	Cable fault identified	Technician
09:23	Cable replaced	Technician
09:24	Interface restored	Syslog
09:25	Host reachable	NMS

63. Determine the Fault Domain

Classify the fault.

Domain	Examples
Physical	Cable, NIC, transceiver
Switching	Port, VLAN, trunk
Addressing	IP, mask, gateway
DHCP	Scope, relay, server
Routing	Missing/incorrect route
DNS	Server, record, resolver
Security	ACL, firewall
Wireless	RF, authentication, VLAN
Application	Service, listening port
Performance	Congestion, errors, packet loss

64. Create a Root Cause Statement

Avoid:

Switch problem.

Use:

CLIENT01 lost connectivity because its access port was
incorrectly assigned to VLAN 20 instead of VLAN 10
during a switch configuration change.

A good root cause statement identifies:

What Failed

Why

Impact

65. Plan the Corrective Action

Before remediation, document:

Proposed Change:

Expected Impact:

Risk:

Rollback Plan:

Approval Required:
YES / NO

66. Implement the Minimum Required Change

Prefer:

One Controlled Change

over:

Multiple Simultaneous Changes

This preserves troubleshooting evidence.

67. Verify the Local Fix

Retest the exact original symptom.

If the problem was:

Cannot reach gateway

verify:

Gateway Reachable

But do not stop there.

68. Perform Full Verification

Test:

Local Interface

Default Gateway

Remote IP

DNS

Application Port

Application

Monitoring

69. Compare Before and After

Document:

Test	Before	After
Gateway
Remote IP
DNS
Application Port
Application
Packet Loss

70. Verify Other Users

If multiple users were affected, verify more than one endpoint.

Example:

CLIENT01:
Recovered

CLIENT02:
Recovered

CLIENT03:
Recovered

71. Verify Monitoring Recovery

Confirm:

Device:
UP

Interface:
UP

Packet Loss:
Normal

Latency:
Normal

Errors:
Stable

Critical Alerts:
Cleared

72. Determine Whether Escalation Is Required

Escalate when:

• fault exceeds your authority

• provider involvement is required

• production risk is high

• hardware replacement is required

• security compromise is suspected

• routing architecture requires senior engineering

• firewall changes require another team

• root cause cannot be isolated within the defined troubleshooting window

73. Prepare an Escalation Package

Include:

Incident ID

Business Impact

Affected Users

Affected Systems

Exact Symptoms

Tests Performed

Results

Monitoring Evidence

Relevant Logs

Suspected Fault Domain

Changes Already Made

74. Example Escalation

INC-NET-1042

15 Finance users cannot reach 10.10.20.30.

CLIENT01–CLIENT03 have valid VLAN 10 addresses.

Default gateway 10.10.10.1 is reachable.

Traceroute fails after RTR01.

RTR01 routing table does not contain 10.10.20.0/24.

No routing changes made because modification requires
Network Engineering approval.

Requesting routing investigation.

75. Close the Incident

Before closure confirm:

Original Symptom Resolved

Affected Users Confirm Recovery

Monitoring Normal

No Related Alerts

Corrective Action Documented

Root Cause Documented

76. Document Preventive Measures

Examples:

Configuration Backups

Change Control

Post-Change Testing

Interface Monitoring

VLAN Monitoring

DHCP Scope Monitoring

DNS Monitoring

Redundant Links

Capacity Monitoring

Recommendations should relate directly to the incident.

77. Network Connectivity Decision Tree

Connectivity Problem
       ↓
Physical Link Up?
   ┌───┴───┐
  NO      YES
   ↓        ↓
Layer 1   Valid IP?
        ┌───┴───┐
       NO      YES
        ↓        ↓
     DHCP/IP   Gateway Reachable?
               ┌───┴───┐
              NO      YES
               ↓        ↓
          L2 / VLAN   Remote IP Reachable?
                      ┌───┴───┐
                     NO      YES
                      ↓        ↓
                   Routing   DNS Works?
                            ┌───┴───┐
                           NO      YES
                            ↓        ↓
                           DNS    TCP Port?
                                  ┌───┴───┐
                                 NO      YES
                                  ↓        ↓
                            Firewall /   Application /
                              Service    Performance

78. Quick Command Reference

Windows

ipconfig /all

ping <IP>

tracert <IP>

arp -a

nslookup <hostname>

route print

Test-NetConnection <IP> -Port <PORT>

Linux

ip addr

ip route

ip neigh

ping <IP>

traceroute <IP>

dig <hostname>

ss -lntp

curl -I <URL>

79. Switch Quick Reference

show interfaces status

show vlan brief

show interfaces trunk

show mac address-table

show interfaces <interface>

show interfaces <interface> switchport

80. Router Quick Reference

show ip interface brief

show ip route

show running-config

81. Wireshark Quick Reference

Purpose	Filter
ARP	arp
DNS	dns
DHCP	dhcp
ICMP	icmp
TCP	tcp
Retransmissions	tcp.analysis.retransmission

82. Operational Checklist

Incident Intake

• Incident ID created

• Exact symptom documented

• Scope identified

• Business impact identified

• Recent changes reviewed

• Existing alerts checked

Endpoint

• Physical connectivity verified

• Interface enabled

• IP address verified

• Subnet mask verified

• Gateway verified

• DNS verified

• APIPA checked

Layer 2

• Switch port operational

• Interface errors checked

• Correct VLAN verified

• MAC learning verified

• Trunks verified

• Required VLANs allowed

Layer 3

• Gateway reachable

• Remote IP tested

• Traceroute performed

• Router interfaces verified

• Routing table checked

• Return path considered

DHCP

• DHCP client verified

• Scope checked

• Available leases checked

• Relay checked

• DORA reviewed where required

DNS

• DNS server reachable

• Client DNS configuration verified

• Direct DNS query performed

• Returned record validated

Services

• Destination IP reachable

• Required TCP/UDP port tested

• Server service verified

• Firewall/ACL reviewed

Wireless

• Correct SSID

• Association successful

• Authentication successful

• Valid DHCP address

• Gateway reachable

• DNS operational

Performance

• Latency measured

• Packet loss measured

• Utilization reviewed

• Interface errors reviewed

• Baseline comparison performed

Monitoring

• SNMP checked

• Syslog checked

• Alerts correlated

• Timeline created where required

Remediation

• Root cause identified

• Corrective action planned

• Risk assessed

• Rollback considered

• Minimum required change implemented

Verification

• Original symptom retested

• Gateway verified

• Remote connectivity verified

• DNS verified

• Application verified

• Multiple affected users verified

• Monitoring returned to normal

Closure

• Root cause documented

• Corrective action documented

• Preventive recommendation documented

• User recovery confirmed

• Incident closed

83. Incident Documentation Template

# Network Connectivity Incident

## Incident Information

Incident ID:

Date:

Start Time:

Resolution Time:

Severity:

## Business Impact

## Affected Users

## Affected Systems

## Reported Symptoms

## Incident Scope

## Recent Changes

## Initial Evidence

## Network Path

## Troubleshooting Actions

### Observation 1

### Theory

### Test

### Result

### Conclusion

## Root Cause

## Corrective Action

## Verification

## Monitoring Status

## Preventive Recommendation

## Escalation

## Final Status

RESOLVED / ESCALATED

84. Runbook Success Criteria

The runbook is successfully completed when:

Root Cause
=
Identified

Connectivity
=
Restored

Affected Services
=
Validated

Monitoring
=
Healthy

and:

Incident
=
Documented

Runbook Review

A connectivity incident may initially appear simple:

"I cannot connect."

But connectivity depends on multiple layers:

Physical
    ↓
Switching
    ↓
VLAN
    ↓
IP Addressing
    ↓
Gateway
    ↓
Routing
    ↓
DNS
    ↓
Firewall
    ↓
Application

The purpose of this runbook is to prevent troubleshooting from becoming:

Guess
 ↓
Change
 ↓
Reboot
 ↓
Try Again

Instead, use:

Observe
   ↓
Determine Scope
   ↓
Test
   ↓
Isolate
   ↓
Identify Root Cause
   ↓
Remediate
   ↓
Verify
   ↓
Document

A professional network technician does not simply ask whether the network works. They determine exactly where communication stops, gather evidence explaining why it stops, restore service using the minimum necessary change, and verify the entire communication path after remediation.

What’s Next?

Runbook 02 — VLAN and Trunk Troubleshooting

The next runbook focuses specifically on Layer 2 segmentation and switching incidents involving:

• incorrect VLAN assignments

• missing VLANs

• access-port configuration

• 802.1Q trunks

• allowed VLAN lists

• native VLAN mismatches

• trunk negotiation

• MAC address learning

• inter-switch connectivity

• selective VLAN outages

• configuration changes

• fault isolation

• remediation and verification

The operational progression becomes:

Network Connectivity
        ↓
Layer 2 Fault Isolation
        ↓
VLAN Investigation
        ↓
Trunk Investigation
        ↓
Root Cause
        ↓
Remediation
        ↓
Validation

➡️ Next: Runbook 02 — VLAN and Trunk Troubleshooting