Lab 17 — Network Monitoring with SNMP and Syslog

Mission Information

Item	Details
Lab	17
Lab Name	Network Monitoring with SNMP and Syslog
Track	CompTIA Network+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Network Technician / Junior Network Administrator
Environment	Network+ Monitoring and Logging Lab
Primary Systems	NETPLUS-NMS01, NETPLUS-RTR01, NETPLUS-SW01, NETPLUS-SERVER01
Primary Tools	SNMP Tools, Syslog Server, Router/Switch CLI, Linux Utilities, Wireshark
Skills	SNMP, OIDs, MIBs, Polling, SNMP Traps, SNMPv3, Syslog, Severity Levels, Monitoring, Alerting, Baselining

Mission Objective: Build a centralized network-monitoring environment that collects operational data from infrastructure devices, receives asynchronous alerts and Syslog messages, tracks availability and performance, and helps administrators detect problems before users report them.

Mission Scenario

GHC Enterprise now has a functioning network with:

Switching
   ↓
Routing
   ↓
DHCP
   ↓
DNS
   ↓
NAT
   ↓
Wireless
   ↓
Network Services
   ↓
Performance Monitoring

The network team currently troubleshoots by manually running commands such as:

ping

show interfaces

show ip route

show spanning-tree

show ip ospf neighbor

This approach works when responding to a known issue.

But enterprise operations require something more proactive.

The goal is to know:

A Link Went Down

before:

A User Opens a Ticket

You have been asked to build a monitoring architecture using:

SNMP
+
Syslog

The new workflow should become:

Network Device
      ↓
Operational Metrics
      ↓
SNMP Polling
      ↓
Monitoring Server
      ↓
Threshold Evaluation
      ↓
Alert

and:

Network Event
      ↓
Device Generates Message
      ↓
Syslog / SNMP Trap
      ↓
Central Monitoring Platform
      ↓
Administrator Investigation

Mission Objectives

By completing this lab, you will be able to:

explain network monitoring
understand monitoring baselines
explain SNMP architecture
distinguish SNMP managers and agents
understand SNMP polling
identify UDP ports 161 and 162
understand MIBs
understand OIDs
query SNMP information
understand SNMP GET operations
understand SNMP traps
compare SNMPv1, SNMPv2c, and SNMPv3
understand SNMP communities
understand SNMPv3 authentication and privacy
configure basic SNMP monitoring in a lab
explain Syslog
understand Syslog severity levels
configure centralized Syslog
generate and review network events
monitor interface availability
monitor interface utilization
monitor CPU and memory
establish alert thresholds
recognize false positives
troubleshoot missing SNMP data
troubleshoot missing Syslog messages
correlate monitoring events

1. Build the Monitoring Lab

Use:

                     NETPLUS-NMS01
                      10.10.30.50
                           |
                           |
                     NETPLUS-SW01
                    /      |      \
                   /       |       \
                  /        |        \
          NETPLUS-RTR01 SERVER01  CLIENT01

For this mission:

NETPLUS-NMS01

acts as the centralized:

Network Monitoring System
+
Syslog Server

2. Define the Monitoring Addressing Plan

Use:

Device	IP
NETPLUS-NMS01	`10.10.30.50`
NETPLUS-RTR01	`10.10.30.1`
NETPLUS-SW01	`10.10.30.2`
NETPLUS-SERVER01	`10.10.30.30`

Adjust according to your existing management VLAN if needed.

3. Verify Basic Connectivity

From NMS01:

ping -c 3 10.10.30.1

Then:

ping -c 3 10.10.30.2

Then:

ping -c 3 10.10.30.30

All monitored devices should be reachable before SNMP troubleshooting begins.

4. Understand Network Monitoring

Network monitoring answers questions such as:

Is the Device Up?

Is the Interface Up?

How Much Bandwidth Is Being Used?

Is CPU Usage High?

Is Memory Usage Increasing?

Did a Routing Neighbor Fail?

Did a Port Change State?

Did a Device Reboot?

The goal is:

Continuous Visibility

instead of:

Manual Point-in-Time Checks

5. Reactive vs Proactive Operations

Reactive

User Reports Problem
      ↓
Administrator Investigates

Proactive

Monitoring Detects Problem
      ↓
Alert Generated
      ↓
Administrator Investigates
      ↓
User Impact Reduced

Enterprise operations aim to become increasingly proactive.

6. Understand Monitoring Baselines

A monitoring baseline records normal behavior.

Examples:

Normal WAN Utilization:
20–40%

Normal CPU:
15–30%

Normal Latency:
10–15 ms

Normal Packet Loss:
0%

A baseline makes abnormal conditions easier to detect.

7. Understand SNMP

SNMP stands for:

Simple Network Management Protocol

It allows management systems to collect and sometimes modify information on network-enabled devices.

Common monitored devices include:

Routers

Switches

Firewalls

Wireless Controllers

Servers

Printers

UPS Systems

8. Understand SNMP Architecture

SNMP commonly involves:

Manager
+
Agent

Conceptually:

NETPLUS-NMS01
SNMP Manager
      ↓
SNMP Query
      ↓
NETPLUS-RTR01
SNMP Agent

9. Understand SNMP Manager

The SNMP manager is the monitoring system.

It:

Sends Queries

Receives Responses

Stores Metrics

Evaluates Thresholds

Generates Alerts

In this lab:

NETPLUS-NMS01

is the manager.

10. Understand SNMP Agent

An SNMP agent runs on the monitored device.

The agent exposes information about:

Interfaces

Traffic Counters

CPU

Memory

Uptime

Device Identity

depending on the platform.

11. Understand SNMP Ports

SNMP commonly uses:

UDP 161

for:

Manager Queries
→
SNMP Agent

and:

UDP 162

for:

SNMP Trap / Notification
→
Manager

12. Build the Port Reference

Function	Port	Transport
SNMP Queries	161	UDP
SNMP Traps	162	UDP

These are important Network+ ports.

13. Understand SNMP Polling

Polling means:

Monitoring Server
      ↓
Ask Device for Metric
      ↓
Device Responds

Example:

NMS:
What is interface utilization?

Router:
35%

This happens repeatedly according to a polling schedule.

14. Polling Example

Suppose NMS01 queries RTR01 every:

5 minutes

It may collect:

09:00
Interface Up

09:05
Interface Up

09:10
Interface Up

09:15
Interface Down

The monitoring server can then create:

Interface Down Alert

15. Understand SNMP GET

A basic SNMP operation is:

GET

Conceptually:

Manager
      ↓
GET specific OID
      ↓
Agent
      ↓
Value

Example:

Request:
System uptime

Response:
12 days

16. Understand SNMP GETNEXT

SNMP can also use:

GETNEXT

to move through sequential objects in the management tree.

Conceptually:

OID A
 ↓
GETNEXT
 ↓
OID B

This supports walking through device information.

17. Understand SNMP Walk

An:

SNMP Walk

queries a sequence of related OIDs.

Example:

Interface Table
      ↓
Interface 1
Interface 2
Interface 3
...

This is useful when discovering available device information.

18. Understand MIB

MIB stands for:

Management Information Base

The MIB defines managed objects available through SNMP.

Conceptually:

Device Information
      ↓
Organized Data Structure
      ↓
MIB

19. Understand OIDs

OID stands for:

Object Identifier

An OID uniquely identifies a managed object.

Examples of objects can include:

System Name

System Uptime

Interface Status

Interface Traffic Counter

CPU Utilization

20. MIB vs OID

Think of:

MIB
=
Catalog / Structure

and:

OID
=
Specific Item in the Catalog

21. Common System OID Concepts

Typical SNMP system information includes:

System Description

System Uptime

System Contact

System Name

System Location

These are often part of standard MIB structures.

22. Prepare NMS01

On a Linux monitoring workstation, install SNMP tools if required.

Example:

sudo apt update
sudo apt install snmp

Verify:

snmpget --version

23. Understand SNMP Versions

Common versions include:

SNMPv1

SNMPv2c

SNMPv3

24. Understand SNMPv1

SNMPv1 is an older implementation.

It lacks strong modern security controls.

You should understand it historically, but it is not preferred for secure enterprise monitoring.

25. Understand SNMPv2c

SNMPv2c improves capabilities over v1 but still commonly relies on:

Community Strings

These effectively act like shared SNMP credentials.

Traffic is not strongly protected.

26. Understand Community Strings

Example lab community:

GHC-NETWORK-LAB

A read-only community may allow:

SNMP GET

SNMP WALK

without allowing device configuration changes.

Do not use predictable/default communities in production.

27. Common Unsafe Community Examples

Avoid relying on defaults such as:

public

private

in real environments.

They are widely known and create unnecessary risk.

28. Configure SNMPv2c for the Lab

On a supported network device, configure a read-only community.

Cisco-like conceptual example:

snmp-server community GHC-NETWORK-LAB RO

Where supported, restrict access to the NMS management address.

29. Restrict SNMP Source

Conceptually:

Only:
10.10.30.50

should be allowed to query SNMP on the device.

This follows:

Least Privilege

30. Test Basic SNMP Query

From NMS01:

snmpget -v2c -c GHC-NETWORK-LAB 10.10.30.1 1.3.6.1.2.1.1.1.0

This commonly queries:

System Description

depending on the device.

31. Query System Name

Use the relevant OID or symbolic object if available.

Example:

snmpget -v2c -c GHC-NETWORK-LAB 10.10.30.1 1.3.6.1.2.1.1.5.0

Record:

System Name:

32. Query System Uptime

Example:

snmpget -v2c -c GHC-NETWORK-LAB 10.10.30.1 1.3.6.1.2.1.1.3.0

Record:

System Uptime:

33. Perform an SNMP Walk

Use:

snmpwalk -v2c -c GHC-NETWORK-LAB 10.10.30.1 1.3.6.1.2.1.1

Review:

System Description

Uptime

System Name

System Contact

Location

where supported.

34. Walk the Interface Table

Use an appropriate interface subtree.

Conceptually:

Interfaces
      ↓
ifIndex

ifDescr

ifType

ifSpeed

ifAdminStatus

ifOperStatus

35. Understand Administrative vs Operational Status

Interface:

Administrative Status

means:

What Configuration Says

Operational status means:

What Interface Is Actually Doing

Examples:

Admin:
Up

Operational:
Down

could indicate a physical or link problem.

36. Monitor Interface Counters

Useful interface statistics can include:

Input Octets

Output Octets

Input Errors

Output Errors

Discarded Packets

Monitoring systems compare counter values over time to calculate traffic rates.

37. Understand Counter-Based Monitoring

Suppose:

09:00
Input Octets:
1,000,000

and:

09:05
Input Octets:
31,000,000

The difference represents:

30,000,000 bytes

received over:

5 minutes

Monitoring platforms perform these calculations automatically.

38. Understand Interface Utilization Monitoring

A monitor may display:

Interface Capacity:
1 Gbps

Current Utilization:
620 Mbps

or:

62%

This allows administrators to identify capacity trends.

39. Monitor CPU

Depending on vendor and MIB support, SNMP can expose:

CPU Utilization

Example baseline:

Normal:
15–30%

Warning:
70%

Critical:
90%

Threshold values must be adapted to the device and environment.

40. Monitor Memory

Memory monitoring may reveal:

Used Memory

Free Memory

Memory Utilization

A sudden change or sustained high usage may indicate:

Resource Pressure

Memory Leak

Heavy Processing

Unexpected Workload

41. Understand Thresholds

A threshold defines when a measurement should generate an alert.

Example:

Interface Utilization
> 80%
for 10 minutes

could generate:

High Utilization Warning

42. Avoid Single-Sample Alerts

Suppose CPU briefly reaches:

92%

for:

2 seconds

That may be normal.

A better alert could be:

CPU > 90%
for 10 minutes

This helps reduce:

False Positives

43. Understand Alert Severity

Monitoring systems may classify alerts as:

Informational

Warning

High

Critical

The exact terminology varies by platform.

The goal is to prioritize operational response.

44. Understand SNMP Traps

Polling works like:

NMS asks device

A trap works like:

Device tells NMS

Conceptually:

Interface Fails
      ↓
Router Detects Event
      ↓
SNMP Trap
      ↓
NMS01

45. Polling vs Trap

Feature	Polling	Trap
Initiated by	Manager	Device
Frequency	Scheduled	Event-driven
Port	UDP 161	UDP 162
Detects events	At next poll	Potentially immediately
Reliability	Repeated queries	Trap may be missed

A robust monitoring environment often uses both.

46. Configure Trap Destination

On a supported device:

snmp-server host 10.10.30.50 version 2c GHC-NETWORK-LAB

Then enable desired trap categories according to platform.

47. Trigger an Interface Event

In the isolated lab, select a non-critical test interface.

Disable:

interface <test-interface>
 shutdown

The device may generate:

Link Down

notification.

48. Restore the Interface

Configure:

interface <test-interface>
 no shutdown

This may generate:

Link Up

notification.

49. Capture SNMP Traffic

On NMS01, start Wireshark.

Filter:

snmp

Generate an SNMP query.

Observe:

Manager
      ↓
UDP 161
      ↓
Agent

50. Capture an SNMP Trap

Filter:

udp.port == 162

Trigger the interface event.

Inspect:

Source

Destination

Trap Information

Associated OIDs

51. Understand SNMPv3

SNMPv3 provides improved security.

It can support:

Authentication

Integrity Protection

Encryption / Privacy

depending on security level.

52. SNMPv3 Security Levels

At a high level:

noAuthNoPriv

means:

No Authentication
No Privacy

authNoPriv

means:

Authentication
No Encryption

authPriv

means:

Authentication
+
Encryption

For secure environments:

authPriv

is generally preferred.

53. Compare SNMP Versions

Feature	v1	v2c	v3
Community string	Yes	Yes	No traditional community model
Strong authentication	No	No	Yes
Encryption	No	No	Supported
Modern enterprise preference	No	Limited	Yes

54. Understand Why SNMPv3 Is Preferred

SNMP can expose valuable infrastructure information.

This may include:

Device Names

Interfaces

Traffic Volumes

Routing Information

System Details

Therefore monitoring access should be protected.

55. Understand Syslog

Syslog is a standard approach for sending:

Event Messages

System Messages

Network Device Logs

to a centralized logging system.

Conceptually:

Router
Switch
Firewall
Server
   \  |  /
    \ | /
 Syslog Server

56. Why Centralized Logging Matters

Without centralized logging:

Router Logs
on Router

Switch Logs
on Switch

Firewall Logs
on Firewall

Administrators must inspect each system independently.

With centralized logging:

All Events
      ↓
Central Log Platform
      ↓
Search

Correlation

Alerting

Retention

57. Syslog Transport

Traditional Syslog commonly uses:

UDP 514

Some implementations support:

TCP 514

and secure logging may use:

TLS-based transport

depending on platform.

For Network+, remember:

Syslog
UDP 514

as the common default.

58. Understand Syslog Messages

A Syslog event may contain:

Timestamp

Hostname

Facility

Severity

Message

Example conceptually:

2026-08-26
RTR01
INTERFACE
WARNING
GigabitEthernet0/1 changed state to down

59. Understand Syslog Severity Levels

Syslog defines severity levels:

Level	Name
0	Emergency
1	Alert
2	Critical
3	Error
4	Warning
5	Notice
6	Informational
7	Debug

Lower numbers indicate greater severity.

60. Remember Syslog Severity Direction

This is important:

0
=
Most Severe

while:

7
=
Debug

Do not assume higher number means higher severity.

61. Syslog Severity Example

A catastrophic system failure may use:

0 — Emergency

A routine informational event may use:

6 — Informational

Debugging information:

7 — Debug

62. Configure NMS01 as Syslog Receiver

On Linux, you may use:

rsyslog

or another approved Syslog receiver.

Check:

systemctl status rsyslog

63. Configure Network Device Syslog

Cisco-like conceptual example:

logging host 10.10.30.50

Then select an appropriate logging level.

Example:

logging trap informational

Exact syntax varies by platform.

64. Generate a Syslog Event

On a lab interface:

interface <test-interface>
 shutdown

Then restore:

no shutdown

These events commonly generate device log messages.

65. Review Syslog on NMS01

Depending on your Linux configuration:

sudo tail -f /var/log/syslog

or inspect the configured remote-log file.

Look for:

Device Hostname

Timestamp

Interface

Event

Severity

66. Capture Syslog Traffic

Wireshark:

udp.port == 514

Generate a log event.

Observe:

Source Device

Destination NMS

Message Content

Traditional UDP Syslog content may be visible in cleartext.

67. Understand Syslog and Security

Traditional Syslog over UDP does not inherently provide:

Encryption

Strong Delivery Guarantee

Secure enterprise designs may use:

TCP

TLS

Authenticated Log Pipelines

depending on platform capabilities.

68. Understand Logging Levels

Sending:

Everything

from:

Emergency
through
Debug

may generate extremely large volumes of logs.

Operational logging should balance:

Visibility

Storage

Noise

Performance

69. Debug Logging Risk

Debug logs can be extremely verbose.

Avoid enabling extensive debug logging on production devices without:

Change Control

Operational Need

Resource Awareness

70. Build a Monitoring Dashboard

Your monitoring platform should conceptually display:

Device Availability

Interface Status

Bandwidth Utilization

CPU Usage

Memory Usage

Packet Loss

Latency

Errors

Active Alerts

71. Create Device Availability Monitor

Monitor:

RTR01

SW01

SERVER01

Track:

Up

Down

over time.

72. Understand Availability Percentage

Suppose a device is monitored for:

30 days

and unavailable for:

1 hour

Availability can be calculated as:

Total Time - Downtime
───────────────────── × 100
Total Time

73. Monitor Interface State

Track critical interfaces such as:

WAN Uplink

Core Trunk

Server Uplink

Wireless AP Uplink

Alert when:

Operational State
changes to
Down

74. Monitor Bandwidth Utilization

Collect:

Input Traffic

Output Traffic

over time.

Build a trend such as:

This helps with capacity planning.

75. Monitor Errors

Track:

CRC Errors

Input Errors

Output Errors

Discards

Alert if counters unexpectedly increase.

76. Monitor Device Uptime

A sudden uptime reset can indicate:

Device Reboot

Crash

Power Failure

Planned Maintenance

Monitoring can help correlate the reboot with user impact.

77. Monitor CPU and Memory

Example dashboard:

RTR01 CPU:
24%

SW01 CPU:
12%

SERVER01 CPU:
44%

Compare with established baselines.

78. Create Warning Thresholds

Example lab thresholds:

CPU > 70%
for 10 minutes
→ Warning

CPU > 90%
for 5 minutes
→ Critical

These are training examples, not universal production thresholds.

79. Create Interface Threshold

Example:

Interface Utilization > 80%
for 15 minutes
→ Warning

This can help detect sustained congestion before users complain.

80. Create Packet Loss Threshold

Example:

Packet Loss > 2%
for 5 minutes
→ Warning

The appropriate threshold depends heavily on network and application requirements.

81. Create Latency Threshold

Example:

WAN RTT > 100 ms
for 10 minutes
→ Warning

Again, compare with:

Normal Baseline

rather than selecting arbitrary values.

82. Understand Alert Fatigue

If monitoring sends:

Hundreds of Alerts

for minor or expected events, administrators may begin ignoring them.

This is:

Alert Fatigue

Good monitoring aims for:

Actionable Alerts

83. Understand False Positives

False Positive

occurs when monitoring reports a problem that is not actually operationally significant.

Example:

CPU:
95%
for 1 second

may not justify a critical incident.

84. Understand False Negatives

False Negative

occurs when a real problem exists but monitoring fails to detect it.

Example:

Interface Errors Increasing

but no alert has been configured.

85. Correlate SNMP and Syslog

Suppose:

14:31:05
Syslog:
Interface Gi0/1 Down

then:

14:31:10
SNMP Poll:
ifOperStatus = Down

then:

14:31:12
Monitoring Alert:
WAN Interface Down

These independent data points strengthen the diagnosis.

86. Correlate Performance Data

Suppose monitoring shows:

14:00
WAN Utilization:
98%

then:

14:02
Latency:
120 ms

and:

14:03
Packet Loss:
4%

This may indicate:

Network Congestion

consistent with Lab 16.

87. Troubleshooting Scenario 1 — SNMP Query Times Out

From NMS01:

snmpget -v2c -c GHC-NETWORK-LAB 10.10.30.1 1.3.6.1.2.1.1.1.0

times out.

Check:

Basic IP Connectivity

UDP 161

SNMP Agent

Community String

ACL

Source Restrictions

88. Verify IP Connectivity First

Run:

ping 10.10.30.1

If ping fails:

Do Not Start with SNMP Configuration

Investigate basic networking first.

89. Troubleshooting Scenario 2 — Wrong Community String

Configured:

GHC-NETWORK-LAB

but query uses:

GHC-LAB

Expected:

SNMP Failure

Correct the credential.

90. Troubleshooting Scenario 3 — SNMP ACL Blocks NMS

Device allows SNMP only from:

10.10.30.60

but NMS is:

10.10.30.50

The SNMP configuration may appear enabled, but NMS cannot query it.

Correct the source restriction.

91. Troubleshooting Scenario 4 — UDP 161 Blocked

Ping:

Success

SNMP:

Timeout

Check:

Host Firewall

Network ACL

Firewall Policy

for:

UDP 161

92. Troubleshooting Scenario 5 — Trap Not Received

Polling works.

Interface is shut down.

No SNMP trap appears.

Investigate:

Trap Destination

UDP 162

Trap Category Enabled?

Community / SNMPv3 Configuration

Routing

Firewall

93. Troubleshooting Scenario 6 — Syslog Not Received

Device logs the event locally.

NMS receives nothing.

Check:

Syslog Destination

NMS Address

UDP/TCP Port

Logging Severity

Routing

Firewall

Syslog Service

94. Troubleshooting Scenario 7 — Severity Filter Too High

Suppose NMS receives only:

Critical

and above.

An:

Informational Interface Event

may never be sent.

Review logging level configuration.

95. Troubleshooting Scenario 8 — Incorrect Timestamp

Logs arrive but device time is wrong.

Example:

Router:
13:15

NMS:
14:15

This makes event correlation difficult.

Check:

NTP

from Lab 15.

96. Why NTP Supports Monitoring

Central monitoring depends on accurate timestamps.

Use:

NTP
      ↓
Consistent Device Time
      ↓
Accurate Log Correlation

97. Troubleshooting Scenario 9 — Interface Graph Flatlines

The interface is active, but monitoring graph shows:

0 Mbps

Possible causes:

Wrong Interface OID

Incorrect Interface Index

Counter Polling Failure

SNMP Permissions

Counter Rollover Handling

Monitoring Configuration

98. Understand Interface Indexes

SNMP interface data often uses:

ifIndex

to identify interfaces.

If interfaces change after:

Hardware Change

Reboot

Configuration Change

some monitoring platforms may need to rediscover interface mappings.

99. Troubleshooting Scenario 10 — Too Many Alerts

NMS generates alerts every time:

Interface Utilization
briefly reaches
80%

Adjust:

Threshold

Duration

Averaging

Alert Suppression

to make alerts meaningful.

100. Build the Monitoring Troubleshooting Workflow

Use:

Monitoring Data Missing
      ↓
Is Device Reachable?
      ↓
Correct Management IP?
      ↓
SNMP/Syslog Service Enabled?
      ↓
Correct Protocol Version?
      ↓
Correct Credentials?
      ↓
Correct Source Restriction?
      ↓
UDP/TCP Port Allowed?
      ↓
Correct OID / Metric?
      ↓
Polling Working?
      ↓
Trap Destination Correct?
      ↓
Syslog Destination Correct?
      ↓
Time Synchronized?
      ↓
Threshold Correct?
      ↓
Alert Generated?

101. Mission Challenge — Identify SNMP Port

SNMP manager sends queries to:

UDP 161

Answer:

SNMP Agent Port

102. Mission Challenge — Identify Trap Port

Network device sends trap to:

UDP 162

Answer:

SNMP Trap Receiver

103. Mission Challenge — Identify Syslog Port

Traditional Syslog commonly uses:

UDP 514

104. Mission Challenge — Manager vs Agent

NMS01 requests interface utilization.

NMS01 is:

SNMP Manager

RTR01 is:

SNMP Agent

105. Mission Challenge — MIB vs OID

Question:

What organizes the managed objects?

Answer:

MIB

Question:

What identifies a specific managed object?

Answer:

OID

106. Mission Challenge — Secure SNMP

Which version should generally be preferred for secure enterprise monitoring?

Answer:

SNMPv3

especially with:

Authentication
+
Privacy

where appropriate.

107. Mission Challenge — Syslog Severity

Which is more severe?

Level 2
Critical

or:

Level 6
Informational

Answer:

Level 2 — Critical

because lower Syslog severity numbers represent higher severity.

108. Mission Challenge — Detect Congestion

Monitoring reports:

Interface:
98% Utilization

Latency:
120 ms

Packet Loss:
3%

Likely investigation area:

Congestion / Capacity

109. Mission Challenge — Device Reboot

NMS shows:

System Uptime:
2 minutes

Yesterday:

System Uptime:
43 days

Likely event:

Device Rebooted

Investigate corresponding:

Syslog

Power Events

Maintenance

Crash Logs

110. Mission Challenge — Link Failure Correlation

You observe:

Syslog:
Interface Down

SNMP Trap:
Link Down

SNMP Poll:
Operational Status Down

Ping:
Failure

This provides strong evidence of:

Interface / Link Failure

111. Create the Lab Workspace

On NMS01:

mkdir -p ~/NetworkPlus-Labs/LAB17/{Captures,Screenshots,Configs,Logs,Notes}

Create:

touch ~/NetworkPlus-Labs/LAB17/Notes/lab17-notes.md

112. Save SNMP Evidence

Save output such as:

snmp-system-description.txt

snmp-system-name.txt

snmp-system-uptime.txt

snmp-system-walk.txt

snmp-interface-walk.txt

under:

~/NetworkPlus-Labs/LAB17/Configs/

113. Save Syslog Evidence

Store:

router-syslog.txt

switch-syslog.txt

link-down-event.txt

link-up-event.txt

under:

~/NetworkPlus-Labs/LAB17/Logs/

114. Save Packet Captures

Save:

LAB17-SNMP-POLLING.pcapng

LAB17-SNMP-TRAP.pcapng

LAB17-SYSLOG.pcapng

LAB17-LINK-FAILURE.pcapng

115. Document Your Findings

Use:

# LAB17 — Network Monitoring with SNMP and Syslog

## Monitoring Server

Hostname:
NETPLUS-NMS01

IP:
10.10.30.50

## Monitored Devices

### RTR01

IP:

SNMP Version:

Status:

### SW01

IP:

SNMP Version:

Status:

### SERVER01

IP:

Status:

## SNMP Configuration

Version:

Community / User:

Source Restriction:

Manager IP:

## SNMP Queries

### System Description

OID:

Result:

### System Name

OID:

Result:

### System Uptime

OID:

Result:

## Interface Monitoring

Interface:

ifIndex:

Administrative Status:

Operational Status:

Speed:

Input Traffic:

Output Traffic:

Input Errors:

Output Errors:

## SNMP Trap

Event:

Source:

Destination:

Port:

Timestamp:

Result:

## Syslog

Syslog Server:

Transport:

Port:

Device:

Severity:

Message:

Timestamp:

## Monitoring Baseline

Normal CPU:

Normal Memory:

Normal Interface Utilization:

Normal Latency:

Normal Packet Loss:

## Thresholds

CPU Warning:

CPU Critical:

Interface Utilization Warning:

Packet Loss Warning:

Latency Warning:

## Failure Test

Interface:

Original State:

Failure Time:

SNMP Trap:

Syslog Event:

Polling Result:

Connectivity Result:

Restoration Time:

## Troubleshooting

### SNMP Timeout

Symptom:

Root Cause:

Fix:

### Wrong Community / Credentials

Symptom:

Root Cause:

Fix:

### SNMP Port Blocked

Symptom:

Root Cause:

Fix:

### Trap Failure

Symptom:

Root Cause:

Fix:

### Syslog Failure

Symptom:

Root Cause:

Fix:

### Timestamp Mismatch

Symptom:

Root Cause:

Fix:

### Excessive Alerts

Symptom:

Root Cause:

Fix:

## Final Assessment

Summarize how SNMP polling, traps, Syslog, baselines, and thresholds provided centralized operational visibility.

116. Evidence to Capture

Capture:

01-monitoring-topology.png

02-nms-ip-config.png

03-device-management-connectivity.png

04-snmp-device-config.png

05-snmp-source-restriction.png

06-snmp-system-description.png

07-snmp-system-name.png

08-snmp-uptime.png

09-snmp-system-walk.png

10-snmp-interface-walk.png

11-interface-status-oids.png

12-interface-counters.png

13-snmp-polling-wireshark.png

14-snmp-trap-config.png

15-interface-shutdown.png

16-snmp-link-down-trap.png

17-interface-restored.png

18-snmp-link-up-trap.png

19-syslog-server-config.png

20-device-syslog-config.png

21-interface-down-syslog.png

22-interface-up-syslog.png

23-syslog-wireshark.png

24-syslog-severity.png

25-monitoring-dashboard.png

26-interface-utilization-graph.png

27-cpu-monitoring.png

28-memory-monitoring.png

29-warning-threshold.png

30-critical-alert.png

31-snmp-timeout.png

32-wrong-community.png

33-snmp-port-block.png

34-trap-failure.png

35-syslog-failure.png

36-timestamp-mismatch.png

37-alert-tuning.png

38-final-monitoring-dashboard.png

117. Validation Checklist

Monitoring Fundamentals

Reactive vs proactive monitoring understood
Monitoring baseline understood
Availability monitoring understood
Threshold monitoring understood
Alerting understood

SNMP Fundamentals

SNMP purpose understood
Manager understood
Agent understood
UDP 161 identified
UDP 162 identified
Polling understood
SNMP GET understood
SNMP WALK understood
MIB understood
OID understood

SNMP Configuration

SNMP enabled on RTR01
SNMP enabled on SW01
Read-only monitoring configured
Monitoring source restricted where supported
NMS can query monitored devices
System description retrieved
System name retrieved
System uptime retrieved
Interface information retrieved

SNMP Security

SNMPv1 understood
SNMPv2c understood
Community-string limitations understood
SNMPv3 understood
authNoPriv understood
authPriv understood
SNMPv3 preference understood

Interface Monitoring

Administrative status monitored
Operational status monitored
Interface speed monitored
Input traffic reviewed
Output traffic reviewed
Input errors reviewed
Output errors reviewed
Utilization monitored

SNMP Traps

Trap concept understood
Trap receiver configured
Link-down event generated
Link-down trap observed
Link-up trap observed
Polling vs traps compared

Syslog

Syslog purpose understood
UDP 514 identified
Central Syslog configured
RTR01 sends logs
SW01 sends logs
Syslog message structure understood
Severity levels understood
Severity 0 recognized as most severe
Debug level understood
Syslog traffic captured

Monitoring Metrics

Device uptime monitored
CPU concept monitored
Memory concept monitored
Interface utilization monitored
Packet-loss threshold understood
Latency threshold understood
Error monitoring understood

Alerting

Warning threshold created
Critical threshold created
Duration-based alert concept understood
False positives understood
False negatives understood
Alert fatigue understood

Correlation

SNMP polling correlated with Syslog
SNMP trap correlated with Syslog
Monitoring alert correlated with device state
NTP importance understood

Troubleshooting

SNMP timeout investigated
Wrong community/credential investigated
Source restriction investigated
UDP 161 filtering investigated
Trap failure investigated
Syslog failure investigated
Severity-filter issue understood
Timestamp problem investigated
Flat interface graph scenario understood
Excessive-alert scenario understood

Documentation

Monitoring topology documented
Device inventory documented
SNMP configuration documented
Syslog configuration documented
Baseline documented
Thresholds documented
Failure test documented
Packet captures saved
Screenshots captured
Lab notes completed

118. Mission Review

Before this mission, your troubleshooting workflow was mostly:

Problem Reported
      ↓
Run Troubleshooting Tools
      ↓
Find Problem

You have now introduced continuous monitoring:

Network Infrastructure
      ↓
SNMP Agents
      ↓
Continuous Polling
      ↓
Monitoring Database
      ↓
Baselines
      ↓
Thresholds
      ↓
Alerts

You also introduced event-driven notifications:

Network Event
      ↓
SNMP Trap
      ↓
Monitoring Server

and centralized logging:

Router
Switch
Server
      ↓
Syslog
      ↓
Central Log Server

This creates a stronger operational workflow:

Metric Changes
      ↓
Event Generated
      ↓
SNMP / Syslog
      ↓
Central Monitoring
      ↓
Correlation
      ↓
Alert
      ↓
Administrator Investigation

The key lesson is:

Effective network operations depend on continuous visibility. SNMP provides structured operational metrics, traps provide event-driven notifications, and Syslog centralizes device events so administrators can detect, correlate, and troubleshoot issues before they become larger outages.

Skills Developed

After completing this mission, you should be able to:

explain enterprise network monitoring
distinguish reactive and proactive operations
establish monitoring baselines
explain SNMP architecture
identify SNMP managers and agents
identify SNMP ports 161 and 162
explain polling
explain SNMP GET and WALK
understand MIBs and OIDs
query basic SNMP data
monitor interface states
monitor interface traffic
understand CPU and memory monitoring
explain SNMP traps
compare polling and traps
compare SNMP versions
explain SNMPv3 security
explain Syslog
identify Syslog port 514
interpret Syslog severity levels
configure centralized logging conceptually
correlate SNMP, Syslog, and availability data
create meaningful thresholds
understand alert fatigue
troubleshoot missing monitoring data
troubleshoot missing traps
troubleshoot missing Syslog events

What’s Next?

Lab 18 — Network Troubleshooting Methodology and Fault Isolation

You have now learned how to:

Build Networks
      ↓
Configure Services
      ↓
Measure Performance
      ↓
Monitor Continuously

The next mission brings these skills together into a structured troubleshooting process.

You will work with:

troubleshooting methodology
identifying the problem
establishing a theory
testing the theory
creating an action plan
implementing the solution
verifying full functionality
documenting findings
Layer 1 failures
Layer 2 failures
Layer 3 failures
DHCP failures
DNS failures
routing failures
wireless failures
performance failures
service failures
monitoring evidence
fault isolation
root cause analysis
escalation decisions
final end-to-end troubleshooting challenge

The progression becomes:

Networking Knowledge
      ↓
Monitoring Evidence
      ↓
Structured Troubleshooting
      ↓
Fault Isolation
      ↓
Root Cause
      ↓
Corrective Action
      ↓
Verification
      ↓
Documentation

➡️ Next: Lab 18 — Network Troubleshooting Methodology and Fault Isolation