Simple Network Management Protocol remains one of the most widely used methods for monitoring network and infrastructure devices.
It is commonly used with:
SNMP provides standardized access to operational metrics without requiring a Zabbix agent on the monitored device.
A reliable SNMP design requires more than entering a community string and linking a template.
It must address:
SNMP allows a monitoring system to query structured management information from a device.
A typical polling workflow is:
Zabbix Server or Proxy
│
│ SNMP request
▼
Network Device
│
│ SNMP response
▼
Zabbix Server or Proxy
The monitoring platform requests a specific object identifier and the device returns the current value.
Typical values include:
SNMP is especially useful where installing an agent is impossible or unsupported.
A production SNMP architecture should define which component performs the polling.
Possible designs include:
Central Zabbix Server
│
▼
Network Devices
or:
Central Zabbix Server
│
▼
Zabbix Proxy
│
▼
Network Devices
The proxy-based model is usually preferable for remote sites.
Benefits include:
The main SNMP versions used in production are:
Each version provides different security and operational characteristics.
SNMPv1 is the original protocol version.
It provides:
Limitations include:
SNMPv1 should be used only where required by legacy hardware.
SNMPv2c is still widely used.
It provides:
Its primary weakness is security.
The community string is transmitted without modern encryption and acts similarly to a shared password.
SNMPv2c may be acceptable on:
It should not be exposed across untrusted networks.
SNMPv3 introduces a modern security model.
It can provide:
SNMPv3 should be the preferred version where supported.
The available security levels are:
| Security level | Authentication | Encryption |
|---|---|---|
| noAuthNoPriv | No | No |
| authNoPriv | Yes | No |
| authPriv | Yes | Yes |
For production environments, use:
authPriv
where possible.
SNMPv3 commonly uses:
The exact algorithms depend on device support.
Use the strongest mutually supported algorithms.
Avoid:
A typical modern baseline is:
Security level: authPriv
Authentication: SHA
Privacy: AES
Where supported, stronger SHA and AES variants may be used.
SNMP should be considered a management-plane protocol.
It may expose information such as:
This information can help an attacker understand the infrastructure.
SNMP access should therefore be restricted by:
Monitoring should use read-only SNMP access.
Write access is rarely required for Zabbix monitoring.
A read-write community or SNMPv3 user may allow changes to:
Recommended principle:
Zabbix SNMP account = read-only
Never reuse administrative SNMP credentials for monitoring unless there is a documented technical requirement.
SNMP views restrict which object identifiers a user may access.
A view can permit:
It can deny:
A dedicated monitoring view reduces exposure if credentials are compromised.
SNMP traffic should remain on a trusted management path.
Recommended design:
Core Firewall
│
┌──────────────┴──────────────┐
│ │
▼ ▼
Production VLAN Management VLAN
│
▼
Zabbix Proxy
│
▼
Network Devices
The Zabbix server or proxy should not require unrestricted access to all device management interfaces.
Only the required protocol should be allowed.
SNMP polling normally uses:
UDP 161
SNMP traps normally use:
UDP 162
A minimal rule set may look like:
Zabbix Proxy → Network Device
UDP 161
Network Device → SNMP Trap Receiver
UDP 162
Recommended firewall policy:
SNMP supports two different monitoring models:
They serve different purposes.
With polling, Zabbix periodically requests values.
Examples:
Polling provides:
Polling is the primary SNMP monitoring method.
Traps are unsolicited messages sent by the device.
Examples:
Traps provide faster event notification but have limitations.
A trap may be:
Traps should normally supplement polling.
They should not be the only source of truth for critical conditions.
A practical model is:
Polling = current state
Traps = event notification
For example:
Trap:
Interface changed to down
Polling:
Interface is currently down
The trap provides fast notification.
The poll confirms the persistent state.
A Management Information Base defines the structure and meaning of SNMP objects.
A MIB contains symbolic names for object identifiers.
Example:
sysUpTime.0
may represent:
1.3.6.1.2.1.1.3.0
MIB files improve readability but do not change the actual protocol communication.
The device and monitoring system exchange numerical OIDs.
An object identifier uniquely identifies an SNMP value.
Example:
1.3.6.1.2.1.1.3.0
This OID represents system uptime in standard SNMP implementations.
OID structure follows a hierarchy.
iso
└── org
└── dod
└── internet
└── mgmt
└── mib-2
Vendor-specific objects are typically located under:
1.3.6.1.4.1
This branch is known as the private enterprise tree.
Standard OIDs provide common metrics.
Examples include:
Vendor-specific OIDs provide additional details such as:
A complete template often uses both.
SNMP values are commonly divided into:
A scalar represents one value.
Example:
sysUpTime.0
A table contains multiple indexed rows.
Example interface table:
ifDescr.1
ifDescr.2
ifDescr.3
The index identifies a specific interface.
Tables are typically handled using low-level discovery.
SNMP tables use indexes to identify rows.
An interface may have:
ifIndex=5
Its related values may be:
ifDescr.5
ifOperStatus.5
ifInOctets.5
ifOutOctets.5
Indexes may change after:
Templates should avoid assuming that a fixed interface always uses a fixed index.
Discovery should map interfaces dynamically.
An SNMP walk queries a sequence of OIDs.
Example:
snmpwalk -v2c \
-c COMMUNITY_STRING \
192.168.10.1 \
1.3.6.1.2.1.1
This retrieves the system branch.
A full walk may produce a large amount of data.
Use targeted walks rather than walking the entire device unnecessarily.
An SNMP get requests a single value.
Example:
snmpget -v2c \
-c COMMUNITY_STRING \
192.168.10.1 \
1.3.6.1.2.1.1.3.0
This is useful for validating:
SNMPv2c and SNMPv3 support bulk operations.
Bulk requests improve efficiency when retrieving tables.
They reduce:
Zabbix can use bulk processing for suitable SNMP items.
However, some devices implement bulk operations poorly.
If a device returns incomplete or incorrect results, bulk requests may need to be disabled for that host or template.
Before building a template, determine:
Device documentation should be treated as the primary source.
Do not assume that two models from the same vendor expose identical objects.
Credentials should be unique by trust boundary.
Avoid using one global community string for every customer and site.
A better model is:
Customer A SNMP credentials
Customer B SNMP credentials
Internal infrastructure credentials
Laboratory credentials
For SNMPv3, use separate users where operationally feasible.
This reduces the impact of credential exposure.
For SNMPv2c, community strings should:
Unsafe examples:
public
private
monitoring
zabbix
companyname
Community strings should be stored using secret macros.
Templates should not contain real credentials.
Use macros such as:
{$SNMP_COMMUNITY}
{$SNMP.USER}
{$SNMP.AUTH.PASSWORD}
{$SNMP.PRIV.PASSWORD}
Credential values may be assigned at:
The host or customer level is usually safer for multi-tenant environments.
A standardized macro set may include:
{$SNMPV3.USER}
{$SNMPV3.SECURITYLEVEL}
{$SNMPV3.AUTHPROTOCOL}
{$SNMPV3.AUTHPASSPHRASE}
{$SNMPV3.PRIVPROTOCOL}
{$SNMPV3.PRIVPASSPHRASE}
{$SNMPV3.CONTEXT}
Macro names should remain consistent across templates.
This simplifies host onboarding and automation.
Every SNMP host requires an SNMP interface.
Example:
Type:
SNMP
IP address:
192.168.10.1
Port:
161
The selected address must be reachable from the assigned Zabbix server or proxy.
Use the management IP rather than a production service IP where possible.
The SNMP interface should use a stable management address.
Preferred options:
Avoid using:
The monitored address should represent the management identity of the device.
A remote SNMP device should normally be monitored by a local proxy.
Example:
Central Zabbix Server
│
▼
Customer Proxy
│
▼
MikroTik Router
Benefits include:
The proxy must have access to the management address of the device.
A template should match:
Do not link multiple broad SNMP templates without checking for overlap.
Possible conflicts include:
Official Zabbix templates are useful starting points.
They may include:
Before production use, review:
Official does not automatically mean optimal for every environment.
A custom template may be required when:
Custom templates should be:
Interface discovery is one of the most common SNMP use cases.
It typically discovers:
A discovery rule may then create:
Devices may expose several identifiers:
ifName
ifDescr
ifAlias
ifIndex
Their meaning varies by platform.
Example:
ifName:
ether1
ifDescr:
ether1
ifAlias:
WAN uplink
ifIndex:
1
Templates should display the identifier most useful to administrators.
Often the best display format combines technical and descriptive values.
Example:
Interface ether1: WAN uplink
Not every discovered interface should be monitored.
Common exclusions include:
Discovery filters should be based on:
Overrides allow different behavior for selected interfaces.
Examples:
Overrides should be preferred over duplicating entire templates.
SNMP commonly exposes:
ifAdminStatus
ifOperStatus
Represents the configured state.
Typical values:
up
down
testing
Represents the actual state.
Typical values:
up
down
testing
unknown
dormant
notPresent
lowerLayerDown
A useful trigger often compares both values.
Example logic:
Administrative state = up
AND
Operational state = down
This avoids alerts for intentionally disabled interfaces.
Traffic monitoring uses byte or octet counters.
Common objects include:
ifInOctets
ifOutOctets
ifHCInOctets
ifHCOutOctets
The HC counters are 64-bit high-capacity counters.
They should be preferred for high-speed interfaces.
32-bit counters wrap quickly on fast interfaces.
At high traffic rates, a 32-bit counter may reset within minutes.
This can produce:
Use 64-bit counters where supported.
SNMP counters usually return cumulative values.
Zabbix converts them into rates using change-per-second preprocessing.
Conceptually:
Current counter - Previous counter
----------------------------------
Time difference
The result may be stored as:
bits per second
When the device returns bytes, multiply by eight to calculate bits.
Interface utilization requires a reliable speed value.
Common sources include:
ifSpeed
ifHighSpeed
Potential problems include:
Utilization triggers should not rely blindly on device-reported speed.
Important interface quality metrics include:
A rising counter may indicate:
Triggers should normally evaluate counter rate or change, not the cumulative total.
SNMP availability should be combined with ICMP where appropriate.
Example:
ICMP unavailable
SNMP unavailable
These conditions provide different information.
Possible states:
| ICMP | SNMP | Interpretation |
|---|---|---|
| Up | Up | Device reachable and SNMP available |
| Up | Down | Device reachable, SNMP failure |
| Down | Up | ICMP blocked or inconsistent routing |
| Down | Down | Device or path likely unavailable |
This distinction improves troubleshooting.
System uptime is commonly monitored using:
sysUpTime
A sudden decrease may indicate:
Some devices reset SNMP uptime without a full system reboot.
Vendor-specific uptime values may provide more accurate results.
CPU and memory OIDs vary widely between vendors.
Potential issues include:
Validate returned values against the device’s own management interface.
Vendor-specific MIBs may expose:
These items should use:
A hardware state value such as 3 is not useful without interpretation.
Temperature thresholds should account for:
Do not apply one global temperature threshold to all devices.
A CPU sensor and ambient rack sensor require different limits.
Use macros or sensor-specific discovery contexts.
Wireless devices may expose:
Wireless metrics can change rapidly.
Polling intervals should balance:
MikroTik RouterOS devices are commonly monitored using SNMP.
Typical metrics include:
A typical architecture is:
Zabbix Proxy
│
│ SNMPv3
▼
MikroTik Router
Use a dedicated read-only SNMPv3 user where supported.
MikroTik environments may contain:
Monitoring every interface may generate unnecessary data.
Discovery filters should exclude or classify:
WAN, LAN and VPN interfaces may require different alert policies.
WAN monitoring should combine several metrics.
Recommended signals:
A WAN link should not be considered healthy only because the physical interface is up.
Example:
Physical interface: Up
Provider gateway: Reachable
External target: Unreachable
This may indicate an upstream routing or provider problem.
For redundant WAN or uplink designs, alerts should reflect service impact.
Example:
WAN1 failed
WAN2 active
Service remains available
This may be:
Severity: Warning
If both links fail:
Severity: Disaster
Trigger dependencies and service-level logic should prevent unnecessary critical alarms during successful failover.
SNMP uses UDP and does not guarantee delivery.
Timeouts may occur because of:
Timeout values should not be increased blindly.
First determine whether the problem is:
Frequent retries can amplify load during outages.
When hundreds of devices stop responding, the monitoring system may spend significant resources waiting for timeouts.
This can create:
Capacity planning must include failure scenarios, not only normal operation.
Monitor Zabbix internal metrics such as:
Persistently high utilization may require:
Process tuning should follow measurement.
Recommended example intervals:
| Metric | Interval |
|---|---|
| Device availability | 30–60 seconds |
| Interface state | 60 seconds |
| Interface traffic | 60 seconds |
| CPU and memory | 1–5 minutes |
| Hardware sensors | 1–5 minutes |
| Device inventory | 12–24 hours |
| Serial number | 24 hours |
| Firmware version | 1–6 hours |
Static values should not be polled frequently.
If thousands of items run at the same exact interval, they may create polling bursts.
Example:
All items run every 60 seconds
This can cause periodic load spikes.
Flexible intervals, preprocessing and proxy distribution can help smooth the workload.
Large deployments should review queue behavior over time.
SNMP values may require preprocessing.
Common operations include:
Example:
Raw counter:
123456789 bytes
Preprocessing:
Change per second
Multiply by 8
Stored value:
bits per second
A device may return:
noSuchObject
noSuchInstance
endOfMibView
Possible causes:
Unsupported values should be investigated rather than permanently ignored.
Firmware upgrades may change:
After a firmware upgrade, validate:
Monitoring is part of firmware change validation.
When replacing a device, consider whether to:
Reusing a host preserves historical continuity but may mix data from different hardware.
Creating a new host provides clearer asset separation.
The decision should follow asset and audit requirements.
A trap-processing architecture typically includes:
Network Device
│
│ UDP 162
▼
SNMP Trap Daemon
│
▼
Trap Processing
│
▼
Zabbix Server
Common components include:
Trap processing should be tested end to end.
Trap receivers should accept messages only from authorized sources.
Controls may include:
An unrestricted trap receiver can be abused to generate:
Vendor traps vary significantly.
A normalization layer may be required to convert different formats into consistent events.
Example:
Vendor A:
linkDown
Vendor B:
portStatusChanged
Normalized event:
Interface operational state changed to down
Normalization improves:
A single device failure may generate many traps.
Examples:
Without correlation, one incident may generate many alerts.
Use:
Raw trap logs may contain valuable diagnostic information.
Retention should consider:
Trap logs should be rotated and protected from uncontrolled growth.
Example connectivity test:
snmpget \
-v2c \
-c COMMUNITY_STRING \
192.168.10.1 \
1.3.6.1.2.1.1.3.0
Example system walk:
snmpwalk \
-v2c \
-c COMMUNITY_STRING \
192.168.10.1 \
1.3.6.1.2.1.1
Example interface names:
snmpwalk \
-v2c \
-c COMMUNITY_STRING \
192.168.10.1 \
1.3.6.1.2.1.31.1.1.1.1
Example:
snmpget \
-v3 \
-l authPriv \
-u zabbix \
-a SHA \
-A AUTH_PASSWORD \
-x AES \
-X PRIVACY_PASSWORD \
192.168.10.1 \
1.3.6.1.2.1.1.3.0
Example walk:
snmpwalk \
-v3 \
-l authPriv \
-u zabbix \
-a SHA \
-A AUTH_PASSWORD \
-x AES \
-X PRIVACY_PASSWORD \
192.168.10.1 \
1.3.6.1.2.1.1
Avoid entering real credentials into shell history on shared systems.
Use packet capture when required.
Example:
tcpdump -ni any udp port 161
For traps:
tcpdump -ni any udp port 162
Packet capture can confirm:
Encrypted SNMPv3 payloads will not reveal the monitored value.
Possible causes:
Possible causes:
Possible causes:
Possible causes:
Use a structured process.
ping -c 4 <DEVICE_IP>
ip route get <DEVICE_IP>
snmpget ...
Confirm:
Confirm:
tail -n 100 /var/log/zabbix/zabbix_server.log
or:
tail -n 100 /var/log/zabbix/zabbix_proxy.log
tcpdump -ni any host <DEVICE_IP> and udp port 161
SNMP through NAT may work, but it introduces complexity.
Potential problems include:
A local Zabbix proxy is usually preferable.
Central Zabbix Server
│
▼
Remote Zabbix Proxy
│
▼
Private SNMP Devices
This avoids exposing UDP 161 across the Internet.
A site-to-site VPN is suitable when:
For larger sites, use a local proxy even when a VPN exists.
The proxy provides buffering and reduces central dependencies.
Managed service environments should isolate customer SNMP access.
Recommended model:
Customer A
├── Dedicated proxy
├── Customer-specific credentials
└── Customer-specific host groups
Customer B
├── Dedicated proxy
├── Customer-specific credentials
└── Customer-specific host groups
Avoid:
SNMP may populate inventory fields such as:
Automatically collected inventory should be validated.
Some devices return:
Manual correction may still be required.
A device should not be considered fully onboarded until the following are verified:
After onboarding, establish a performance baseline.
Review:
Thresholds should be based on actual operating conditions where possible.
SNMP templates frequently generate noise if left at default settings.
Common sources include:
Alert tuning should not simply disable problems.
It should identify whether the cause is:
Changes to SNMP configuration should be documented.
Examples:
A change record should include:
SNMP credentials should be rotated periodically and after:
For large environments, use a staged process:
Create new credential
→ Configure device
→ Update Zabbix
→ Validate monitoring
→ Remove old credential
Avoid changing every device simultaneously without validation.
The SNMP monitoring system itself should be monitored.
Important signals include:
A widespread increase in SNMP timeouts may indicate a monitoring platform issue rather than many simultaneous device failures.
A scalable reference model:
Central Zabbix Server
│
▼
Zabbix Database
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
Site A Proxy Site B Proxy Customer Proxy
│ │ │
┌─────┼─────┐ ┌─────┼─────┐ ┌─────┼─────┐
│ │ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
Router Switch UPS Router Switch AP Router NAS Firewall
Each proxy should poll local devices using the strongest supported SNMP version.
Use the following baseline where technically possible:
SNMP version:
SNMPv3
Security level:
authPriv
Authentication:
SHA or stronger
Privacy:
AES or stronger
Access:
Read-only
Source restriction:
Zabbix proxy IP only
Network:
Dedicated management VLAN
Credentials:
Unique per customer or trust boundary
For legacy SNMPv2c devices:
Use random community strings
Restrict by source IP
Use isolated management networks
Avoid Internet exposure
Plan replacement or protocol upgrade
Avoid the following:
public as the community string;For enterprise SNMP monitoring:
SNMP provides scalable monitoring for network and infrastructure devices, but its reliability depends on architecture, security and template quality.
A strong SNMP implementation uses:
The next chapter explains how to deploy and operate Zabbix agent-based monitoring for Linux and Windows systems.