Video Summary - SNMP Monitoring with Zabbix | Real Time Packet Level Analysis using Wireshark & Cisco

Main ideas, concepts, and lessons

SNMP (Simple Network Management Protocol) is a network monitoring communication protocol used to exchange monitoring data between:
- an SNMP manager (part of the monitoring/monitoring server tool), and
- an SNMP agent running on network devices (router/switch).

The session focuses on SNMP monitoring with Zabbix, using Wireshark packet captures and Cisco device behavior to understand:

SNMP concepts and architecture
Message types (with real examples)
OID/MIB usage (how an agent knows what information to return)
Polling vs traps (request/response vs one-way notifications)

A practical workflow is demonstrated conceptually:

Configure SNMP on network devices (routers/switches).
Add those devices to the monitoring server (Zabbix).
Observe communication in real time via Wireshark.
Test by triggering events (e.g., shutting an interface down) and verifying trap alerts.

SNMP architecture and terminology (as explained)

NMS / Monitoring System (Manager)
- Represented in the video by the monitoring server / “jobex/zabbix” server.
- Sends SNMP requests (polling) to devices.
Managed Device (Agent)
- Routers/switches contain an SNMP agent.
- The agent answers requests and sends traps when events occur.
MIB (Management Information Base)
- Described as a database inside the agent.
- It maps OID values to meaningful data (e.g., system name, interface status).
OID / “O value” and “Y value”
- The talk refers repeatedly to “OID” (described in subtitles as “O value”) and “Y values” (likely subtitle confusion).
- Core idea: the manager asks for a specific OID, and the agent uses its MIB to return the corresponding information/value.

SNMP communication flow (polling vs traps)

1) Polling / Request-Response (manager → agent)

The monitoring server sends SNMP request messages (speaker lists the types).
The device responds with SNMP responses containing the requested values.

2) Traps / Notifications (agent → manager)

Traps are described as one-way communication:
- Devices send traps to the monitoring server when events occur (e.g., interface down, CPU high, or faults).
- In the described flow, the server does not acknowledge traps.

SNMP ports and transport protocol (as stated)

Transport protocol: UDP
UDP 161: used for polling (manager requests to the agent; e.g., GET, GETNEXT, GETBULK, SET as applicable)
UDP 162: used for traps (device → monitoring server notifications)

SNMP message types mentioned (with what they do)

GET
- Requests a specific OID value.
- The agent responds with the value.
GETNEXT
- Retrieves the next OID in a sequence.
GETBULK
- Retrieves multiple OIDs/rows efficiently (bulk data).
SET
- Writes/changes configuration values on the agent (mentioned as one of the request types).
TRAP
- One-way event notification from agent to manager.
INFORM / RESPONSE
- Mentioned as additional message categories (listed, but not deeply demonstrated in the shown examples).

Tooling and packet analysis (method shown)

Wireshark: captures and inspects SNMP traffic.
GNS3: referenced as the lab/network emulator environment.
Zabbix (“jobex”): the monitoring platform integrated with SNMP.

Zabbix-style setup steps for SNMP monitoring (detailed instruction bullets)

A) Configure SNMP on a Cisco router/switch (device-side)

Key mandatory parameters emphasized:

Set the device hostname
- Required so the monitoring server can identify the device.
Configure SNMP community string
- Examples given: “public” and “private”
- The community name on the device must match what you configure on the monitoring server.
Configure SNMP server location / contact information
- Location example used: “GNS3” (can represent a name/label; or be a company/site location).
- Configure contact as identification/administrative metadata too.
Choose SNMP version
- Video mentions v1, v2c, v3
- Noted behavior:
  - SNMP v2c is visible in packet captures (not encrypted).
  - SNMP v3 encrypts SNMP traffic, so values may not be readable in Wireshark captures.
Specify interface/address for monitoring
- For interface-related monitoring, configure relevant interfaces.
- Speaker notes loopback can be used conceptually for router ID, but for interface-down monitoring, relevant physical/interface addressing must match what the agent reports.

B) Add the device to the monitoring server (manager-side)

In Zabbix, under host/data collection:

Create a host
- Host name: must match the device hostname configured on the router.
- Visible name: any user-friendly label.
- Template selection
  - Templates depend on device type/OS.
  - Cisco IOS templates contain required MIB/OID mappings (as mentioned).
Host groups
- Example in the lab: grouping under a Linux server host group.
Interface
- Configure the device IP/interface IP used by SNMP polling.
- Port: SNMP agent uses UDP 161 (implied by the flow).
- SNMP version: match device configuration.
- Community string: match device configuration.

After adding:

Items transition to green when SNMP works and data is available.
If not green, the server likely cannot poll successfully (example troubleshooting includes IP mismatch).

Testing and verification steps shown

Verification with SNMP walk
- Use snmpwalk from the monitoring server to confirm it can query device values.
- Demonstrated concept:
  - Query an OID (system/interface-related).
  - The agent returns values including the router hostname.
Packet capture verification
- In Wireshark:
  - Polling: packets from server IP → device IP using UDP 161
  - Traps: packets from device → server using UDP 162
Trap test (event generation)
- The speaker shuts down an interface on the device (e.g., G4/0 on R2).
- Expected outcome:
  - the device sends a trap immediately to the monitoring server
  - the trap includes data mapping to the affected interface (via OID/MIB-derived values)
- Zabbix should show an alert for interface down, including whether it’s administratively down vs down.

Alert/notification configuration (as described)

After triggers occur (e.g., interface down), the monitoring server can send notifications.
Notification examples mentioned:
- Email (Gmail)
- Telegram
The speaker references configuring:
- alerts
- media type (notification channel)
- enabling notification delivery when a trigger is raised

Clarifications / corrections stated during the session

SNMP is not itself a monitoring tool
- It is a protocol/language used between monitoring tools and devices.
“Jobex” (Zabbix) is framed as the monitoring tool
- Like a doctor checking a patient: it observes health/status and raises issues.
Device addition is necessary
- If a device isn’t added to the monitoring platform, it won’t be monitored.

Speakers / sources featured (identified from subtitles)

Primary speaker/instructor (unidentified; repeated “sir” and “guys” addressing audience)
Audience participants / responders (unidentified; confirmation voices such as “yes screen visible”, “yes understood”, etc.)
Software/tools referenced as sources:
- SNMP (protocol standard)
- Zabbix (“jobex” in subtitles)
- Wireshark
- GNS3
- Cisco IOS (device OS; templates mentioned)

SNMP Monitoring with Zabbix | Real Time Packet Level Analysis using Wireshark & Cisco

Key takeaways