Zabbix SNMP Switch Monitoring with LLD

Network gear is a closed system: you cannot install an agent on it, so SNMP is how switches tell you they are in trouble. Doing it well in Zabbix means three things – a secure device-side SNMP configuration, a template with low-level discovery (LLD) so 48 interfaces become 48 monitored items automatically, and triggers written on the metric that actually predicts an outage. This guide covers all three with a Cisco example and notes for Huawei and MikroTik.

Configure the device side

configure terminal
 snmp-server community N0tPublic RO
 snmp-server contact netops@example.com
 snmp-server location "DC1 Rack 42"
 snmp-server enable traps snmp linkdown linkup
 snmp-server host 192.168.1.100 version 2c N0tPublic
 snmp-server host 192.168.1.100 traps bgp
 write memory

For SNMPv3 – the right choice on any network you do not fully trust – create a group and a user with authentication and privacy:

snmp-server group MONITOR v3 priv
snmp-server user zbx MONITOR v3 auth sha AuthPass123 priv aes 128 PrivPass123

Restrict polling sources with an SNMP ACL, and store credentials in Zabbix macros rather than in templates that non-admins can read. Before touching Zabbix, validate from the server:

snmpwalk -v3 -l authPriv -u zbx -a SHA -A 'AuthPass123' -x AES -X 'PrivPass123' 10.10.20.1 sysDescr.0
snmpwalk -v 2c -c N0tPublic 10.10.20.1 | head

Install the vendor MIBs on the Zabbix server so OIDs resolve to names – troubleshooting numeric OIDs is a self-imposed handicap.

Create the host and attach templates

Add the host with an SNMP interface, set the SNMP version and credentials, and link a template that matches the OS or platform (Zabbix ships templates such as Cisco IOS SNMP and vendor-specific 3750/Catalyst templates). The template supplies the item prototypes, discovery rules and trigger prototypes, so the host starts working immediately after the first discovery cycle.

What LLD gives you for free

• One interface item per discovered interface (ifHCInOctets, ifHCOutOctets, errors, discards) named and tagged with {#IFNAME}, {#IFALIAS}.
• Per-interface triggers on operational status, error rates and utilisation, with the interface name in the alert.
• Bulk discovery through ifAlias so that a description written on the switch appears in the alert text.

Use 64-bit counters (ifHCInOctets) with a "delta per second" preprocessing step; 32-bit counters wrap on anything faster than a few hundred Mbit/s and produce negative spikes that look like outages.

Triggers that matter

{Template:net.if.in[{#SNMPINDEX}].avg(5m)} > threshold     ! interface load
{Template:ifOperStatus[{#SNMPINDEX}].last()} = 2            ! link down
{Template:ifInErrors[{#SNMPINDEX}].change()} > 0            ! errors growing
{Template:snmp.uptime.last()} < 86400                       ! unexpected reboot

• Uptime below a threshold is the cheapest "device restarted unexpectedly" detector – it catches power and crash events that link-down triggers miss.
• Correlate interface errors with actual traffic volume; a small number of errors on an idle port is noise.
• Dependencies: put uplink triggers as parents of access-port triggers so one cable fault does not generate 48 alerts.
• Polling intervals: keep interface counters at 1 minute, CPU/temperature at 5 minutes, and avoid sub-minute polling on cheap switch CPUs – SNMP walks are CPU load on that device.

Traps versus polling

Traps are fast and give you events (link down, BGP neighbour change, power supply failure) but are lossy and require the trap receiver, item and trigger to be configured separately. Polling is the reliable baseline; enable traps for events you cannot poll cheaply. MikroTik devices follow the same logic:

/snmp set enabled=yes contact="IT Dept" location="DC1"
/snmp community set [find] name=N0tPublic addresses=192.168.1.100/32

Operations

• Keep a gold template per platform and resist per-device item edits – they multiply maintenance.
• Enable value cache and check the queue in Administration → Queue when polling a large fleet; the queue is the first sign of an undersized Zabbix server.
• Review SNMP credentials and ACLs quarterly; SNMPv2c community strings are sent in clear text.
• Monitor the monitor: alert when the SNMP poller fails to reach a device for two consecutive cycles.

Related: SNMPv3 security levels and engine ID, Alertmanager routing and silences, and NetFlow v9 on Cisco IOS.

原文链接：https://zabbix.com/documentation/current/en/manual/guides/monitor_switch