SNMP: come monitorare router, switch e apparati di rete

Un apparato che non viene monitorato è un apparato di cui scopri i problemi dai reclami degli utenti. SNMP (Simple Network Management Protocol) è ancora oggi lo standard più diffuso per leggere lo stato di router, switch, ONT, UPS e server: gira su UDP 161, è supportato praticamente da qualsiasi hardware di rete e costa pochissimo in termini di risorse.

Come funziona in due minuti

L'apparato monitorato espone un agent SNMP. Il sistema di monitoraggio (Zabbix, LibreNMS, PRTG, Observium, Checkmk) fa da manager e interroga l'agent a intervalli regolari — tipicamente ogni 60 secondi. Ogni valore leggibile è identificato da un OID (Object Identifier), una sequenza numerica gerarchica tipo 1.3.6.1.2.1.2.2.1.10.3.

Gli OID sono organizzati in MIB (Management Information Base), file che traducono i numeri in nomi leggibili. 1.3.6.1.2.1.2.2.1.10 corrisponde a ifInOctets — i byte in ingresso su un'interfaccia. L'ultimo numero (.3) è l'indice dell'interfaccia specifica.

Esistono due modalità di raccolta:

• Polling: il manager chiede, l'agent risponde. Buono per metriche continue (traffico, CPU, temperatura).
• Trap / Inform: l'agent invia spontaneamente un messaggio al manager quando accade un evento (link down, reboot, alimentatore guasto). Arrivano su UDP 162 e sono immediate, senza attendere il prossimo ciclo di polling.

Un monitoraggio serio usa entrambe: polling per i grafici, trap per gli allarmi che non possono aspettare 60 secondi.

Le versioni: usa SNMPv3, ma sappi perché

Il problema di v1 e v2c è che la community string viaggia in chiaro. Chi intercetta il traffico legge la stringa e da quel momento può interrogare l'apparato — o scriverci, se hai lasciato attiva una community RW.

I contatori a 32 bit di SNMPv1 (ifInOctets) vanno in overflow ogni 4,29 GB: su un'interfaccia a 1 Gbps significa un wrap ogni ~34 secondi, quindi grafici completamente inaffidabili. SNMPv2c introduce i contatori a 64 bit (ifHCInOctets, gli High Capacity counters): su qualsiasi link moderno devi usare quelli.

SNMPv3 aggiunge tre livelli di sicurezza:

• noAuthNoPriv — nessuna autenticazione, inutile
• authNoPriv — autenticazione HMAC (SHA), dati in chiaro
• authPriv — autenticazione + cifratura AES, l'unico da usare

Configurazione su MikroTik

Esempio con SNMPv3 in authPriv, limitato all'IP del server di monitoraggio:

# Crea la community v3 con autenticazione e cifratura
/snmp community
add name=monitoring \
    security=private \
    authentication-protocol=SHA1 \
    authentication-password="PasswordAuthLunga" \
    encryption-protocol=AES \
    encryption-password="PasswordCryptDiversa" \
    addresses=10.0.50.20/32   # solo il server NMS, mai 0.0.0.0/0

# Abilita l'agent
/snmp
set enabled=yes contact="noc@esempio.it" location="POP Catania - Rack A3" \
    trap-version=3 trap-community=monitoring trap-target=10.0.50.20

Il campo location sembra un dettaglio cosmetico: quando hai 40 apparati e un allarme alle 3 di notte, è la differenza tra sapere dove intervenire e aprire la documentazione.

Sul firewall aggiungi una regola esplicita e chiudi il resto:

/ip firewall filter
add chain=input protocol=udp dst-port=161 src-address=10.0.50.20 action=accept \
    comment="SNMP dal NMS"
add chain=input protocol=udp dst-port=161 action=drop comment="SNMP - blocca tutto il resto"

Cosa monitorare davvero

Raccogliere tutto è controproducente: produce rumore e allarmi che nessuno guarda. Le metriche che contano:

• Traffico per interfaccia (ifHCInOctets / ifHCOutOctets) — base per capacity planning e per accorgersi di saturazioni
• Errori e discard (ifInErrors, ifOutDiscards) — errori crescenti su una porta significano cavo, SFP o duplex mismatch
• Stato operativo link (ifOperStatus) — via trap, non via polling
• CPU e memoria — soglia di allarme sensata all'80% sostenuto per 5 minuti, non su picchi istantanei
• Temperatura e alimentatori — sugli apparati in colo è il primo segnale di un problema fisico
• Uptime (sysUpTime) — un reset a zero inatteso è un reboot da investigare
• Potenza ottica RX/TX sugli SFP — un degrado graduale anticipa il guasto della tratta

Errori ricorrenti

• Community public lasciata attiva: è il primo tentativo di qualsiasi scanner. Un snmpwalk anonimo espone topologia, versioni firmware, ARP table e interfacce — ricognizione perfetta per un attaccante.
• SNMP esposto su interfaccia pubblica: UDP è banale da spoofare e SNMP si presta all'amplificazione DDoS. Ascolta solo sulla rete di management.
• Polling troppo aggressivo: intervalli sotto i 30 secondi su apparati con CPU modesta causano più problemi di quanti ne risolvano.
• Nessuna soglia configurata: raccogliere dati senza alert significa avere grafici belli da guardare dopo il disservizio.
• MIB proprietari non caricati: senza il MIB del vendor vedi OID numerici e perdi le metriche specifiche dell'hardware.

Quando SNMP non basta

SNMP è ottimo per contatori e stato, meno per configurazione e telemetria a alta frequenza. Sulle reti moderne si affianca a:

• Syslog centralizzato per gli eventi testuali e la correlazione temporale
• NetFlow / IPFIX per capire quale traffico satura un link, non solo quanto
• Streaming telemetry (gNMI, gRPC) dove serve granularità al secondo
• NETCONF / RESTCONF per la gestione della configurazione

Il punto di partenza resta però lo stesso: se un apparato in produzione non è in SNMP, per il tuo monitoraggio non esiste.